There’s a massive trend right now to containerise application deployments. It makes sense to do so because there’s no real reason to run every application on it’s own dedicated server. Instead, putting it inside it’s own little box makes it highly portable and a pleasure to deal with… sort of.
I’ve been caught on two different occasions where I assumed using a LXC container would “just work” for my use case.
- In the first use case, I was trying to mount a NFS share inside of a container OS.
- For my second use case I was trying to run docker inside a container OS.
In the first case, despite issuing the mount command as root I was told that the operation was not permitted.
root@mentos:~# mount -t nfs -o ro nfs.devzero.co.za:/share/courses /mnt/nfs
mount.nfs: Operation not permitted
After doing some research I found that I would need to change the configuration of the container, but I wanted to know more and have a better understanding of what else could be changed. I did some more digging and stumbled upon this handy table in the LXD docs. I now had a better understanding of what could be changed and what settings could be done on the fly and which needed a restart of the container.
I issued the following command on the container host to grant the container the additional privileges and then restarted the container for the change to take effect.
dvnt@icecream:~$ sudo lxc config set mentos security.privileged true
dvnt@icecream:~$ lxc stop mentos
dvnt@icecream:~$ lxc start mentos
After this I was able to mount the share from inside the container.
root@mentos:~# mount -t nfs -o ro nfs.devzero.co.za:/share/courses /mnt/nfs
root@mentos:~#
root@mentos:~# df -h
Filesystem Size Used Avail Use% Mounted on
backup/lxd/containers/mentos 1.7T 1.2G 1.7T 1% /
none 492K 4.0K 488K 1% /dev
udev 1.9G 0 1.9G 0% /dev/fuse
tmpfs 100K 0 100K 0% /dev/lxd
tmpfs 100K 0 100K 0% /dev/.lxd-mounts
tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs 1.9G 168K 1.9G 1% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
nfs.devzero.co.za:/share/courses 20G 1.5G 18G 8% /mnt/nfs
In the second case where I was trying to run docker inside the container OS I was returned a somewhat misleading error.
root@mentos:~# docker run hello-world docker: Error response from daemon: error creating aufs mount to /var/lib/docker/aufs/mnt/bd99bf4888008c24535ecaa9ec0b95 1657afa73fbfb88031f9ee33f3a999182e-init: mount target=/var/lib/docker/aufs/mnt/bd99bf4888008c24535ecaa9ec0b951657afa73fb fb88031f9ee33f3a999182e-init data=br:/var/lib/docker/aufs/diff/bd99bf4888008c24535ecaa9ec0b951657afa73fbfb88031f9ee33f3a 999182e-init=rw:/var/lib/docker/aufs/diff/9a3859fed7ed1923a95f4321371be807807455db32c4df1f1f631dd07edc26bb=ro+wh,dio,xin o=/dev/shm/aufs.xino: permission denied.
Essentially what’s happening is a classic case of Inception… a dream within a dream… or rather, a container within a container. So after permitting the container OS to run nested containers using the following command I was able to run a docker application inside the LXC container.
dvnt@icecream:~$ lxc config set mentos security.nesting true
dvnt@icecream:~$ lxc exec mentos bash
root@mentos:~# docker run hello-world
Hello from Docker!
This message shows that your installation appears to be working correctly.
To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
(amd64)
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.
To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash
Share images, automate workflows, and more with a free Docker ID:
https://hub.docker.com/
For more examples and ideas, visit:
https://docs.docker.com/get-started/
root@mentos:~#
