[lxc-users] Howto/Tutorial wanted: Running an application inside a container

Fajar A. Nugraha list at fajar.net
Wed May 14 07:33:26 UTC 2014


On Wed, May 14, 2014 at 1:59 PM, Johannes Kastl <mail at ojkastl.de> wrote:

> Just one thing, you overlayed the hosts / with another directory
> (/opt/container/data),


On further consideration, it might be better to set it as
/var/lib/lxc/host/rootfs as the overlay mountpoint (to make it consistent
with other containers) and /var/lib/lxc/host/overlay-data for to store the
changes (so that it's in the same directory). Use whatever is best for you
though.



> which should contain the changes compared to /.
>
> But why do you bind-mount /usr and /lib into the container? This
> should be included with the overlayfs, or am I missing something?
>
>
That design is based on the assumptions that "most updates will replace
current binaries, but you can still use old configuration/state". To be
complete, I probably should've bind-mount read-only /bin and /sbin as well.

Without the bind-mount, the container would be able to write things to it's
own /usr and /lib, thus breaking the link with the host. This behavior is
desired for some directories (e.g. /etc, /var), where you want the
container to have it's own copy. However it is NOT desired if you want
updates on the host to propagate to the container.

So with the binary directories bind-mounted read-only:
- the container will have (mostly) it's own writable root fs
- updates on the CONTAINER (including new package installation) will FAIL
due to read-only bind-mount. This is intended.
- updates to binary directories on the HOST will also be seen by the
CONTAINER. This is intended.

-- 
Fajar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20140514/1b8e513e/attachment.html>


More information about the lxc-users mailing list