So it’s almost the end of the year, I’ve got about 10 days of vacation for the holidays and a bit of time on my hands.
Since I’ve been doing quite a bit of work on LXC lately in prevision for the LXC 1.0 release early next year, I thought that it’d be a good use of some of that extra time to blog about the current state of LXC.
As a result, I’m preparing a series of 10 blog posts covering what I think are some of the most exciting features of LXC. The planned structure is:
- LXC 1.0: Your first Ubuntu container [1/10]
- LXC 1.0: Your second container [2/10]
- LXC 1.0: Advanced container usage [3/10]
- LXC 1.0: Some more advanced container usage [4/10]
- LXC 1.0: Container storage [5/10]
- LXC 1.0: Security features [6/10]
- LXC 1.0: Unprivileged containers [7/10]
- LXC 1.0: Scripting with the API [8/10]
- LXC 1.0: GUI in containers [9/10]
- LXC 1.0: Troubleshooting and debugging [10/10]
While they are all titled LXC 1.0, most of the things I’ll be showing will work just as well on older LXC. However some of the features will need a very very recent version of LXC (as in, current upstream git). I’ll try to make that clear and will explain how to use our stable backports in Ubuntu or current upstream snapshots from our PPA.
I’ll be updating this first blog post with links to all of the posts in the series. So if you want to bookmark or refer to these, please use this post.
Github
Twitter
LinkedIn
Mastodon
RSS feed
Hello Stéphane!
Thanks for the series of great articles. We run our complete infrastructure within LXC. In the past we had to exchange physical servers pretty often. They were all Ubuntu 12.04. Unfortunately, we did not find a way to copy LXC machines between servers.
If it’s possible, can you please describe it in these series?
Hi!
I’ll try to cover it in one of the upcoming posts but very quickly, unless you are using some unusual way of spring your containers, copying /var/lib/lxc from one host to another will do the trick. Just make sure to copy all attributes either by making a tarball or by using something like rsync -a –hard-links –sparse –numeric-ids
Thanks for the reply. Is this going to work, even if hardware is pretty different? Another interesting point would be to explain how this sort of container copy/move differences from conventional vms (virtual box and vmware)?
You obviously need both hosts to support the container’s architecture but besides that, Linux distributions don’t really care about what hardware is in your server.
The kernel takes care of that much and since LXC containers use the host’s kernel, nothing should be needed there.
As for containers vs VMs, containers should be slightly easier to move because you can move them to a server with fewer CPU capabilities without having to reconfigure them.
Not that reconfiguring VMs is required in all cases, but depending on the technology used and the kind of feature passthrough that they use, it may happen.
In practice, in most cases, moving a VM requires moving a bunch of disk images and a configuration file, moving a container requires moving a directory, so all in all not do different.
Hi Stéphane,
Thx for all your work on LXC.
I plan to work with LXC container app. I don’t want to debootstrap in it, I don’t need an entire system in it. Will you talk about this particular case in your post ?
I plan to translate your post into french to break the language barrier. But I need you authorization to publish it. In fact, because you’re speak french, I’m wondering if you’ll be interested in reading and correct me ? All my sources are published in rst here : https://github.com/Winael/LXC-LXC-1.0/tree/master/_sources/fr
(I’ll generate an online doc/odt/pdf/epub too, english and french, ‘coz I kind of need it for my personnal use :p but I think it could help lot’s of people)
Happy holidays
Winael
Hi,
I wasn’t planning on covering application containers in this series though maybe I will if I’m running out of things to talk about in one of the posts 🙂
Anyway, in your case, I suspect you’ll either want to create a minimal rootfs similar to what’s done with the busybox template or even run against the host rootfs by using something like:
lxc-execute -n p5 — /path/to/service
As for translating and publishing translations of my posts, feel free to go ahead and I’ll try to take a look at them if/when I find the time!
Enjoy the holidays!
Where does Docker fit into all of this? We’re thinking about using it on top of LXC. What are your thoughts on Docker versus native LXC?
That is actually a good question posted by Robert Breton. But I believe Docker runs on top of LXC so they do not go in competition or against (am I wrong?).
Moreover, it would be great to know your opinion, Stéphane as well.
I for one, am already working on some APIs to automate some functionalities of Docker in Python. I’m already thinking of a general purpose engine but plugged with APIs to create individual environments, all powered by Docker and LXC under the hood; this should pack some tremendous power for Quality Assurance, Testing and Development Testing stage of software (e.g. unittests but where heavy load is needed).
Would be great to know if LXC development may head towards this view as well? Maybe partnership with Docker? Who knows what awaits… 🙂
In any case, thanks for all your work
Docker builds on top of LXC, with some added features like git-like functionality.
Are you sure that’s still true? I read that Docker uses its own “libcontainer” now.
Imho there is a communication problem with LXC, not only because of a lack of communication, engagement, involvement from the LXC team about their project but also the Docker project which leverages LXC. Because of the way the docker team has decided to communicate and with LXC being relatively unknown there is now plenty of potential for confusion, that a nascent project that needs support like LXC can do without.
Visit the docker page and read the about section including the embedded slideshare and the getting started page you do get the impression its Docker which is providing the capabilities provided by LXC. There is no mention of LXC, and this can be slightly to hugely misleading. This has to be one of the main reasons why there are many people who appear to be confused about docker and LXC and what exactly LXC is and what capabilities Docker adds to it. Its a management and deployment layer that can be done in LXC itself, or with some scripts.
A bit like for example UFW and iptables. UFW does not provide the capabilities of iptables, it leverages them, but its fundamentally iptables that is providing these capabilities. It would be odd for UFW to showcase powerful iptables functionality without making it clear its a management scripting layer on top of iptables.
I think docker should be clearer about what it is doing, as the vagueness creates needless confusion and detracts from exciting capabilities and possibilities that LXC brings, pushing it into the background as some boring infrastructure container stuff provided by the kernel, when it LXC and the work done by Stephane and team that is fundamentally providing all these capabilities, and needs to be widely known and supported.
Couldn’t say it better. Even though the Mailinglist is quite active (been registered for a while now) whenever someone mentions Docker, people just treat it very cold. Maybe is the relationship you’ve described raul that creates this effect, albeit to be honest, I fully agree with you.
In the end it could be that this hinders both projects. On the other side you could see why this is, as you’ve mentioned:
1) LXC needs to be focused on its functionalities, thus developing i t, debugging, kernel analysis and whatever else may be needed drains time and there is little left for popularizing it (more than the ML, Canonical – sort of and whatever other events there may be).
2) Docker builds on top of LXC, so they already have most of the functionality like you’ve said, they have more time in providing their layering but this is permits (more?) time to have a better strategy on the “market”. Maybe this is why was coded in Go in the first place? To be honest this attitude leaves me cold but… yeah.
Anyways, in the end as for LXC, if you’re active in RSS feeds like LWN.net you cannot hear of it (actually there I find the the news related to the release of 1.0).
Maybe is just me…
Docker aims to provide slightly different functionality than LXC. Docker is built as a framework on top of containers (and other technology going forward) that provides workflow and lifecycle for building and managing applications. It does this by helping you specify and build “containers” to hold applications and services. It provides tools and an API to deploy and manage those containers. I consider LXC to be handling the “building containers” at an infrastructure level whilst Docker works at the application level.
Additionally, since Docker 0.9, we’ve removed the dependency on LXC in favor of our own native container format called libcontainer. Libcontainer natively interacts with cgroups and namespaces to create your own containers and their configuration. You can still use LXC under Docker by the default containerization technology is now our native variant. We’ve done this primarily to reduce the number of variables/components in the stack we run and to limit our exposure to changes in LXC requiring updates to Docker (In fairness our implementation/integration to LXC was little more than a wrapper around the lxc binaries so issues were frequent).
Hope this helps clarify and feel free to reach out to me – james@docker.com or on the #docker Freenode channel – if you have any queries or questions about Docker and our plans.
Ritual disclaimer: I work at Docker.
I am “slightly” confused between LXC, Docker and other tools like OpenVZ, Proxmox…
Hello Stéphane
This is Qin Guang, I have one question about LXC IPC.
Currently i already set network option in lxc.conf to use private network space. below is example:
lxc.network.type = veth
lxc.network.hwaddr = 00:01:02:03:04:05
lxc.network.flags = up
lxc.network.link = br0
lxc.network.ipv4 = 192.168.2.1/24
but i still want to let one process inside lxc communicate with process running outside lxc container using UNIX domain socket such as /tmp/testunixsocket.
I dont want to use TCP/UPD socket.
Would you please tell me how to let this work?
Thanks,
Qin Guang
Sorry to bother you on my trivial problem. I am an 81 year old enthusiast of kubuntu, at novice level. Have tried to install lxc, but got errors and have a real mess on my hands. It’s totally beyond my expertise, so could you advise as to how I can totally undo all of this.
So far I’ve installed part of lxc container: Created a 32bit container,
Then start the container; at the console login prompt…..
Then
bumpy@my32bitbox:~$ sudo apt-get install software-properties-commonReading package lists... Error!
E: Type ‘deb-src-src’ is not known on line 10 in source list /etc/apt/sources.list
E: The list of sources could not be read.
E: The package lists or status file could not be parsed or opened.
bumpy@my32bitbox:~$ cd /etc/apt/sources.list
-bash: cd: /etc/apt/sources.list: Not a directory
bumpy@my32bitbox:~$ /etc/apt/sources.list
-bash: /etc/apt/sources.list: Permission denied
bumpy@my32bitbox:~$ sudo /etc/apt/sources.list
sudo: /etc/apt/sources.list: command not found
bumpy@my32bitbox:~$ cd /etc/apt/sources.list
-bash: cd: /etc/apt/sources.list: Not a directory
bumpy@my32bitbox:~$ cd /etc/apt
bumpy@my32bitbox:/etc/apt$ dir
apt.conf.d preferences.d sources.list sources.list.d trusted.gpg trusted.gpg~ trusted.gpg.d
bumpy@my32bitbox:/etc/apt$ sources.list
-bash: sources.list: command not found
bumpy@my32bitbox:/etc/apt$
bumpy@my32bitbox:/etc/apt$ dir
apt.conf.d preferences.d sources.list sources.list.d trusted.gpg trusted.gpg~ trusted.gpg.d
bumpy@my32bitbox:/etc/apt$ print sources.list
Warning: unknown mime-type for "sources.list" -- using "application/octet-stream"
Error: no "print" mailcap rules found for type "application/octet-stream"
bumpy@my32bitbox:/etc/apt$ sources.list
-bash: sources.list: command not found
bumpy@my32bitbox:/etc/apt$ sudo apt-get update
E: Type ‘deb-src-src’ is not known on line 10 in source list /etc/apt/sources.list
E: The list of sources could not be read.
bumpy@my32bitbox:/etc/apt$ sudo sudo sources.list
sudo: sources.list: command not found
bumpy@my32bitbox:/etc/apt$ sudo sources.list
sudo: sources.list: command not found
bumpy@my32bitbox:/etc/apt$ cd ..
bumpy@my32bitbox:/etc$ cd ..
bumpy@my32bitbox:/$ sudo apt-get update
E: Type ‘deb-src-src’ is not known on line 10 in source list /etc/apt/sources.list
E: The list of sources could not be read.
bumpy@my32bitbox:/$ sudo apt-get update
E: Type ‘deb-src-src’ is not known on line 10 in source list /etc/apt/sources.list
E: The list of sources could not be read.
bumpy@my32bitbox:/$ deb http://ca.archive.ubuntu.com/ubuntu/ trusty-updates main restricted
-bash: deb: command not found
bumpy@my32bitbox:/$
How can I delete all this? It's far too complicated for me.
When using an overlay, are system updates a problem?
For example, suppose I create a basic ubuntu container, then create a few overlay containers based off it: one for chromium, another for wine, another for doing android development, one for steam, and another for playing some old game that requires a legacy version of some library.
I’m concerned that running system updates on the base image could render one or more containers unusable. Obviously I could protect myself from that by making a snapshot of the base image and restoring it if something goes wrong, but that creates a potential point of failure.
-Brian
@Peter,
while this is outside the discussion at hand, what you could do is :-
$sudo cat /etc/apt/sources.listNormally even without a sudo command you should get listing of the /etc/apt/sources.list file. This is the listing of my sources on a Debian box :-
$ cat /etc/apt/sources.list
#### testing #########
deb http://ftp.debian.org/debian jessie main contrib non-free
deb http://ftp.debian.org/debian/ jessie-updates main contrib non-free
deb http://security.debian.org/ jessie/updates main contrib non-free
#### unstable #########
deb http://http.debian.net/debian/ unstable main contrib non-free
#### experimental #########
deb http://http.debian.net/debian/ experimental main contrib
From the errors shared by you, it seems only a single word and hypen are out of place. Your 10th line should have started with only ‘deb-src’ instead of ‘deb-src-src’ which is the actual problem.
@Stephane just discovered these blog post series so will be perusing and trying to learn from them as time permits, thank you for the documentation.
I have installed and created/started LXC containers in Ubuntu 15.10, and the major problem I encountered was that I cannot get them to be visible from outside the host. Setting up an IP of 10.0.3.1 and not having any clear documentation on how to bridge the lxcbr0 network interface is the big shortcoming for me. In VirtualBox, Jails, and Zones, this issue is trivially solved. In LXC the issue was insurmountable, at least for me. And it does seem as if one of the big uses of LXC containers would be hooking them up easily to your network, to run web-facing stuff in them securely. I am reluctant to use a system like Docker. So I can’t follow why putting containers on a NAT-like 10.0.3.1 sub-net is useful.
0 0 منم نشد.من تازه کارم.این دستور میده:E: dpkg was interrupted, you must manlulay run sudo dpkg configure -a’ to correct the problemباید چی کار کنم؟
Hi Stephane,
This is R Hudumula and I have been following your blog series and find them very useful.
I am trying to create a container image out of a running VM. I created a tarball of the root file-system and used to it generate a container image using “lxc image import …” But the container so created is restarting continuously.
Can you please help me on how to generate a container image using the VM’s root file-system.
Thanks,
R Hudumula