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

[Fajar A. Nugraha]

On Sun, May 11, 2014 at 1:18 AM, Johannes Kastl <mail at ojkastl.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi everyone,
>
> I thought running a single application inside a container was one of
> the main advantages of lxc over 'full'virtualization like KVM. But it

Sort of. You can set it in a way that a container runs (almost)
nothing else, by disabling most background processess. Regardless, its
resource usage will be more efficient.

> seems I fail to find a nice tutorial how to do this. Any hints?

https://www.stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/ is a good example

> I got this far with running apache inside the container:
> Create a rootfs containing empty directories for proc, sys, ...
> Copy over apache's config into the rootfs


... and that is probably your mistake. Am I right in assuming that
your rootfs ONLY contains apache's config, WITHOUT any binary?

The container need to have ALL files/directories needed to run the
application. The easiest way would be to create a container with
working  full OS (e.g. using "lxc-create" with a template), or
(slightly harder) bind-mount some parts of the host (e.g. /usr, /lib)
in the container and copy over other parts (e.g. /etc, /var).

> I can then run
> lxc-execute -n Apache_Test4 -f /path/to/the/config -- /usr/sbin/httpd2

Personally I would NOT use lxc-execute. Had too many problems with it
in the past. Better just use lxc-start and lxc-attach.

>
> And I get:
>> lxc-execute: Failed to find an lxc-init lxc-execute: invalid
>> sequence number 1. expected 4 lxc-execute: failed to spawn

> And all the links I found for the "failed ...lxc-init" point me to
> installing lxc inside the container.

correct.

> Which is not possible, as it is
> no 'complete' OS inside.

Like I mentioned above, it's easiest to just install full OS in the
container, or bind-mount some parts of the host. If you're pressed for
disk space, using something like btrfs/zfs snapshot/clone would help.

This is an example of what happens when you run lxc-execute (in my
case "build" is the container name), where the container is a working
ubuntu rootfs (i.e. created with "lxc-create -t", and starts correctly
when you run "lxc-start") and has lxc package installed

# lxc-execute -n build -- bash
root at build:/# ip ad li
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
17: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP qlen 1000
    link/ether 00:16:3e:37:ee:23 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::216:3eff:fe37:ee23/64 scope link
       valid_lft forever preferred_lft forever
root at build:/# df -h /
Filesystem       Size  Used Avail Use% Mounted on
rpool/lxc/build  201G  398M  200G   1% /

As you can see, it sets up the correct rootfs for the container, and
it creates the network interfaces, but it does NOT configure the
interface IP. IP configuration is done as part of ubuntu startup
scripts (init/upstart), and since lxc-execute does not invoke those,
you end up with unconfigured interface.

For the network interface part you can work around it by specifying it
in the container config file, but you might need other things
configured as well (e.g. iptables, dependent services like mysql,
etc), which is why I would recommend lxc-start and lxc-attach over
lxc-execute.

-- 
Fajar