[lxc-users] Accessing Services Running Inside Nested Containers from Outside Parent Container?

[P. Lowe]

Greetings LXD lovers!

I have to create a system that aggregates 4 child containers nested  
inside a parent container.

A critical requirement is that the parent container have an IP  
address, and each nested child
container also has an IP address, with all 5 IP addresses being  
reachable from outside the parent container.

I'd like to be able to ping both the parent container and any of it's  
child containers from outside the parent container.

Something like this (the question marks means I don't know what it  
would say, e.g. ):

+-------------+---------+-----------------------+------+------------+-----------+
|    NAME     |  STATE  |              IPV4     | IPV6 |    TYPE    |  
SNAPSHOTS |
+-------------+---------+-----------------------+------+------------+-----------+
| nested-outer| RUNNING | 10.0.0.108 (eth0)     |      | PERSISTENT |  
0         |
|             |         | 10.0.1.1 (?     )     |      |            |   
          |
|             |         | 10.0.1.2 (?     )     |      |            |   
          |
|             |         | 10.0.1.3 (?     )     |      |            |   
          |
|             |         | 10.0.1.4 (?     )     |      |            |   
          |
+-------------+---------+-----------------------+------+------------+-----------+

So, in this case, each 10.0.1.x address represents access to a child  
container.

I've been playing around with bridged networking, but quite frankly, I  
don't know how to configure LXD containers to do this.

I create my parent container with the following:

lxc launch ubuntu: nested-outer -c security.nesting=true

Then I go inside the nest-outer:

lxc exec nested-outer /bin/bash

root at nested-outer:~# lxd init
Name of the storage backend to use (dir or zfs): dir

We detected that you are running inside an unprivileged container.
This means that unless you manually configured your host otherwise,
you will not have enough uid and gid to allocate to your containers.

LXD can re-use your container's own allocation to avoid the problem.
Doing so makes your nested containers slightly less safe as they could
in theory attack their parent container and gain more privileges than
they otherwise would.

Would you like to have your containers share their parent's allocation  
(yes/no)? yes
Would you like LXD to be available over the network (yes/no)? no
Do you want to configure the LXD bridge (yes/no)? yes
Warning: Stopping lxd.service, but it can still be activated by:
   lxd.socket
LXD has been successfully configured.

Then, I create the nested-inner container:

root at nested-outer:~# lxc launch ubuntu: nested-inner
Creating nested-inner
Starting nested-inner
root at nested-outer:~# lxc list
+--------------+---------+-----------------------+------+------------+-----------+
|     NAME     |  STATE  |         IPV4          | IPV6 |    TYPE    |  
SNAPSHOTS |
+--------------+---------+-----------------------+------+------------+-----------+
| nested-inner | RUNNING | 10.207.144.104 (eth0) |      | PERSISTENT |  
0         |
+--------------+---------+-----------------------+------+------------+-----------+


But what do I have to do in order to make the nested-inner (child)  
container accessible outside the nested-outer (parent) container?

Has anyone tried doing something like this?

 From outside the nested-outer (parent) container, lxc list shows the  
following:

guest at dev:~$ lxc list
+--------------+---------+--------------------------------+------+------------+-----------+
|     NAME     |  STATE  |              IPV4              | IPV6 |     
TYPE    | SNAPSHOTS |
+--------------+---------+--------------------------------+------+------------+-----------+
| nested-outer | RUNNING | 10.0.0.176 (eth0)              |      |  
PERSISTENT | 0         |
|              |         | 10.207.144.1 (lxdbr0)          |      |      
        |           |
+--------------+---------+--------------------------------+------+------------+-----------+


Thanks,

-P. Lowe