Ubuntu Gets Container-Friendly "Snappy" Core

judgecorp writes: Canonical just announced Ubuntu Core, which uses containers instead of packages. It's the biggest Ubuntu shakeup for 20 years, says Canonical's Mark Shuttleworth, and is based on a tiny core, which will run Docker and other container technology better, quicker and with greater security than other Linux distros. Delivered as alpha code today, it's going to become a supported product, designed to compete with both CoreOS and Red Hat Atomic, the two leading container-friendly Linux approaches. Shuttleworth says it came about because Canonical found it had solved the "cloud" problems (delivering and updating apps and keeping security) by accident — in its work on a mobile version of Ubuntu.

Comments

Re:20 years?

[vux984]

Well TFA says:

"This is in a sense the biggest break with tradition in 10 years of Ubuntu..."

Editor fail.

This actually sounds pretty cool.

[Fwipp]

No dependency management or fooling around packages that require conflicting library versions, possibly near-instant "installation" (depending on if they're distributing Dockerfile-equivalents* or containers directly). Sounds good to me - I'll have to take a look sometime.

*Yes, I know that Docker is not the only way to do containers, but it's easy to imagine they could be using a similar "build" step.

Re:This actually sounds pretty cool.

[Fwipp]

Update: Playing with it, It looks like there isn't a build step. Following the steps here: http://www.ubuntu.com/cloud/to... - it seems that docker is installed under /apps/docker (~20 files total) - they're basically just distributing tarballs which contain all necessary dependencies.

From there, it puts a quick wrapper script at ~/snappy-bin/docker, containing:

#!/bin/sh
##TARGET=/apps/docker/1.3.2.007/bin/docker
#TMPDIR=/run/apps/docker
cd /apps/docker/1.3.2.007
aa-exec -p docker_docker_1.3.2.007 -- /apps/docker/1.3.2.007/bin/docker $@

To build your own "snappy package" looks as simple as "cd mydir; snappy build ."

Re:This actually sounds pretty cool.

[geantvert]

The article indicates that containers can be upgraded by sending only the modified files so upgrading a lib should not cost too much.
If their system is not too stupid then it will manage the container at the file level and will try to share identical files between packages.

That should not be too difficult using checksums and hard links. If they don't do that then the kernel won't be able to share files between applications and the whole system will use a lot more memory. Linux application are sharing libs but also some data files such as TTF fonts.

Re:This actually sounds pretty cool.

[DuckDodgers]

I wrote this elsewhere, but to repeat: the advantage of Docker and similar containers isn't static linking. The advantage is that you get most of the important benefits of whole operating system virtualization with much lower overhead in terms of disk space and resource use. Instead of building one 5GB CentOS or Ubuntu VM that runs a copy of your web server software and pushing that all over your network and having every running instance hold 100MB of RAM just for a virtual kernel in addition to the web server itself, you build a 500MB Apache/Nginx/Whatever Docker container with the same web server and push it everywhere, and its memory and CPU overhead on top of the web server is tiny. And since, yes, it uses statically linked libraries, it doesn't matter if the host OS has a different version of libevent as long as it has a compatible version of Docker or lmctfy or whatever container technology you use.

Now obviously if you wanted to make the virtualized environment available to a remote user as a remote desktop, or for remote login directly into the virtual environment with ssh for configuration changes, you want a full virtualized operating system. In that case you need VirtualBox, KVM, Xen, VMware, Hyper-V, etc... but for deploying identical instances of a configured application to a handful or even hundreds of machines with the smallest feasible overhead and a nice security layer to prevent most breaches of the hosted application from leaking into the host operating system, a container is great. If you look up how Docker and lmctfy work, they are mostly an API wrapper around the Linux kernel cgroup and selinux features for configurable restriction of a process's ability to utilize CPU, RAM, and IO.

Re:OK. I'm throroughly confused

[Anonymous Coward]

Ok let's get you up to speed on containers in 7 paragraphs and there is some pottering hiding somewhere in here to keep folks interested. A VM emulates the entire hardware layer. A container depends on cgroups and namespaces support in the Linux kernel to create a lightweight isolated OS environment with network support. So you could be running a Debian host and multiple Redhat, Centos, Ubuntu, Fedora etc containers and vice versa.

The advantage is because containers are not emulating a hardware layer you get near bare-metal performance, easier access to hosts filesystem via simple bind mounts and easy workload portability across any Linux system. The limitation is you can only run Linux OS containers as it depends on the Linux kernel.

The Linux containers (LXC) project has been baking since 2009, and has been supported by Ubuntu since 2012. However its been a low profile project. A lot of hardcore Linux users have not heard about LXC let alone used it. LXC gives you system containers, ie you get a near complete Linux environment like a lightweight VM.

Docker was using LXC in its previous avatar of dotcloud to run a public PAAS platform and experimented with LXCs support for overlay filesystems like overlayfs and aufs. They then released this as Docker in 2013. Docker basically used LXC as a base to abstract the container away to an app, which is composed of layers of aufs filesystems. Compared to LXC Docker gives you a more constrained OS environment, mainly a single app execution environment made up of aufs read only layers. Running multiple apps, daemons, cron, services will requirments will require workarounds, like a bash script launching multiple apps or processes, or using a process manager like runit or supervisor. And any data produced by the container in the top most aufs read-write layer is transient and has to be commited to a layer, bind mounted to the host eg mysql databases, logs etc or lost.

The big problem occupying brainy minds lately seems to be orchestration of containers and workloads in containers across multiple hosts and this is the problem Ubuntu's recently announced LXD project based on LXC, CoreOS, Docker libswarm, Mesosphere and multiple others are trying to address.

There are also efforts to run container only OSs - ie a bare minimum OS with apps, everything in isolated containers (which is where Lennart Pottering's recent blog post about using btrfs subvolumes, low cost COW snapshots, and containerized apps seems to suggest he is taking systemd to eventually). This is where CoreOS, Redhat's Project Atomic and now Ubuntu Core seem to be moving towards.

A chroot jails is barebones compared to a container. A container can use cgroups to limit memory and cpu per container and network namespaces. LXC can now use usernamespaces support in the kernel to let users run unprivileged containers by non root users.