On Sun, May 11, 2014 at 1:18 AM, Johannes Kastl <[email protected]> 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@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@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 _______________________________________________ lxc-users mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-users
