Slashdot Mirror
Docker 1.0 Released
Graculus writes: "Docker, the company that sponsors the Docker.org open source project, is gaining allies in making its commercially supported Linux container format a de facto standard. Linux containers are a way of packaging up applications and related software for movement over the network or Internet. Once at their destination, they launch in a standard way and enable multiple containers to run under a single host operating system. 15 months and 8,741 commits after the earliest version was made public, Docker 1.0 has been released."
All the real nerds know about it.
What is Docker?
Docker is an open platform for developers and sysadmins to build, ship, and run distributed applications.
How is this different from Virtual Machines?
Virtual Machines
Each virtualized application includes not only the application - which may be only 10s of MB - and the necessary binaries and libraries, but also an entire guest operating system - which may weigh 10s of GB.
Docker
The Docker Engine container comprises just the application and its dependencies. It runs as an isolated process in userspace on the host operating system, sharing the kernel with other containers. Thus, it enjoys the resource isolation and allocation benefits of VMs but is much more portable and efficient.
https://www.docker.com/whatisdocker/
Docker is a lot of things, all rolled up into one so it is difficult to describe without leaving out some detail. What is important to one devops person might be unimportant to another. I have been testing docker for the past few months and there are a couple of things about it that I like quite a bit.
I have to explain a couple of things that I like about it before I get to the one that I really like.
1) It has a repository of very bare bones images for ubuntu, redhat, busybox. Super bare bones, because docker only runs the bare minimum to start with and you build from that.
2) You pull down what you want to work with, and then you figuratively jump into that running image and you can set up that container with what you want it to do.
3) (this is what I really like) That working copy becomes a "diff" of the original base image. You can then save out that working image back to the repository. You can then jump on another machine, and pull down that "diff" image (but you don't even really have to think of it as a "diff", you can just think of it as your new container. docker handles all the magic of it behind the scenes. So if you are familiar with git, it provides a git like interface to managing your server images.
It does a lot more than what I describe above, but it is one of the things I was most impressed with.
No, it's not.
I think of it as something like a version controlled Make or Grunt script with the output being a jail. Setting up your cloud stack as a series of Docker containers makes it much easier to create, upgrade, scale and relocate your services such as web servers, databases, caches, app servers etc.
Try clicking "Try it!" on their web page. Your container is lost at sea :/.
The point is that don't create a VM. Containers runs applications in their own isolated (as in filesystem, memory, processes, network, users, etc) environment, but just one kernel, no hard reservation of memory or disk, it consumes resources pretty much like native apps.Another difference is at it just need the linux kernel, it runs where a linux kernel (modern enough, 2.6.38+) run, including inside VMs, so you can run them on amazon, google app engine, linode and a lot more.
What docker adds over LXC (Linux Containers) is using a copy-on-write filesystem (so if i get the filesystem for i.e. ubuntu for an app, and another application also tries to use the filesystem of ubuntu, the extra disk use is just what both changed, also cached disk works for both), using cgroups to be able to limit what resources the container can use, and a whole management system for deploying, managing, sharing, packaging and constructing. It enables you to i.e. build a container for some service (with all the servers it need to run, with the filesystem of the distribution you need, exposing just the ports you want to give services on), pack it, and use it as a single unit, deploying it in the amount of servers you want without worrying about conflicting libraries, required packages, or having the right distribution.
If you think that is something academical, Google heavily use containers in their cloud, creating 2 billon containers per week. They have their own container technology (LMCTFY, Let Me Contain That For You) but has been adopting lately Docker, and contributing not just code but also a lot of tools to manage containers in a cloud.
Is there such thing as an inverse "no true scotsman" fallacy? https://en.wikipedia.org/wiki/...
Until someone comes along who's running Redhat.
Download .deb
Double click it
Insert password, hit ok
Seriously it is a hell of a lot easier than Windows
Oh, I'm sorry. You need libglib2.0-0 (>= 2.35.9), but I'm on libglib2.0-0 (2.34.8) and upgrading it will cause a conflict with libwtf5.0 (1:5.0.99) and also require installing libancientrelic0.8 (0.8.0.012), which I can't seem to find anywhere. Let me suggest removing a bunch of packages (leaving some things broken). Accept this solution? (y/N) Alternately, I could suggest you blow your weekend learning to build a dummy package just to shut me up... there so many wonderful commands that start with deb and dpkg, you'll love digging thru layers and layers of accumulated shell scripts!
-1, Too Many Layers Of Abstraction
Name a single example of this occurring with a up to date maintained package.
I dare you to link to a .deb file. Go on.
And don't get me started with DLL hell on Windows.
Yep. There was a time that installing software on Linux was a nightmare. It was so bad that some people sat down and really thought about how to make it really good, and then implemented those ideas. With Windows, software installations was always just passable, and that is the way it has stayed.
happened a few months ago to me trying to update XBMC on my HTPC. ended up reinstalling the whole OS. all i wanted to do was "Apt-get upgrade xbmc". doing a standard "apt-get upgrade" would tell me it was held back. even on my current install, i have about 15 packages that are held back because of this kind of package snafu
I went to the web site to learn more. I still don't know what it is. I suspect it's a venture capital extraction method.
Not if you are a web hosting service that has to keep ruby 1.8 around for some clients and ruby 1.9 for others, and can't let the two interact.
More detail in this Redhat talk on containers.
It's the same thing as BSD Jails, however there is one big difference with Docker. A container/jail can be shipped to another system running a completely different kernel. This means you can create an Ubuntu 10.04 container and run it on an Ubuntu 14.04 host or RHEL 7 host.
With BSD Jails, you can only ship your jails to the same system unless you spend enough time fiddling around so you can basically do the same thing. Luckily the Docker team is already adding BSD Jails support.
That's already pretty easy to do with libvirt. I run three commands like this to copy my image, setup the vm on the new host, and start it:
/var/lib/libvirt/images/bitcoin5.qcow2
rsync -avz main_server:/var/lib/libvirt/images/bitcoin.qcow2
virt-install --name=bitcoin5 --arch=x86_64 --vcpus=4 --ram=4096 --os-type=linux --os-variant=rhel6 --hvm --connect=qemu:///system --network bridge:br0 --cdrom=/var/lib/libvirt/images/CentOS-6.5-x86_64-minimal.iso --disk path=/var/lib/libvirt/images/bitcoin5.qcow2 --accelerate --graphics none
...
Except that your stand-alone virtual machines are going to consume about 3GB of disk space and 500MB of RAM per instance.
Docker allows a differential-style "Virtual Machine", so you have 1 base image and the actual containers are only the differences between images. Often no more than 100MB or so. And only consume the RAM and CPU needed for stuff that isn't done in the base instance. And can be defined with service levels to keep them from getting greedy.
"Linux containers are a way of packaging up applications and related software for movement over the network or Internet."
Rewritten not to be shitty:
"Linux containers are a way of packaging up applications and related software."
For movement over the network or Internet.
One of the key attributes of a Docker image is that's it's a commodity. Their logo resembles a container freight vessel for a very good reason.
We've had the ability to package applications for years. That's what things like debs and RPMs are all about. A Docker instance isn't merely a package, it's a complete ready-to-run filesystem image with resource mapping that allows it to be shipped and/or replicated over a wide number of container hosts, then launched without further ado. And destroyed when you don't need it any more.
Not necessarily.
I've had this problem mostly with Debian testing and unstable (where this sort of thing should be expected) but there are times when even apt-get dist-upgrade or aptitude dist-upgrade won't resolve it, and one either must ignore it until all the dependencies are updated or decide "yeah, I didn't need those packages anyway", uninstall the offenders, and complete upgrading other stuff.
Once or twice I told apt to grab a package's dependencies, compiled the package locally, then installed it with stow. This works too if you don't mind updating the package manually.
Hail Eris, full of mischief...
E pluribus sanguinem