Docker 0.4.0 release note

https://github.com/dotcloud/docker/wiki/Docker-0.4.0-release-note,-June-3-2013

by thu • 13 years ago

97 51 13 years ago

SnowLprd2• 13 years ago

Many thanks to shykes, mdaniel, backjlack, and the many others that contributed to this terrific release. So much has been accomplished in just a few months, which augurs well for what Docker will look like by year's end. Bravo, everyone.

shykes8• 13 years ago

TLDR: Docker is an open-source engine which automates the deployment of applications as highly portable, self-sufficient containers.

Version 0.4 introduces a remote HTTP api, a new Build functionality, and an experimental Openstack integration.

nutanc• 13 years ago

Would be nice if every post had a TLDR;

Maybe someone should hack a tool, point an URL and get a TLDR; version

Orva• 13 years ago

I think that if post has so trivial amount of information that it can be shortened to TLDR, there is never any need to actually read it

StavrosK4• 13 years ago

Isn't that what http://tldr.io/ does?

fintler2• 13 years ago

On my list of things to do: compare docker to zerovm to libvirt to ??? and figure out which one works will work best with rdma (infiniband) networks. Combined with nixos (maybe), this could work wonders for hpc data provenance.

shykes8• 13 years ago

Docker could be customized to run on ZeroVM :)

darkarmani3• 13 years ago

What about OpenVZ? It isn't as light as Docker (you get a whole OS) and solves a different problem, but it is solid at providing a OS virtualized container.

shykes8• 13 years ago

OpenVZ is almost identical to LXC, which is what Docker uses under the hood. You could port Docker to OpenVZ very easily. In fact, there is a plugin planned to do exactly that.

Fun fact: before running on lxc, dotCloud (where Docker originated from) was initially based on OpenVZ (which was great). As the mainline kernel's support for containers improved (in large part, I believe, thanks to the pioneering work of OpenVZ), eventually we moved over to that.

gtaylor• 13 years ago

I'm not sure I'm asking this question correctly, but what kind of performance hit do I take by using a Docker container within an EC2 instance instead of just running straight on the EC2 instance's userspace?

I'm not looking for any kind of concrete number, but let's say I've got a Postgres running on an m1.large. Any idea how running Postgres under Docker would change my performance characteristics?

fintler2• 13 years ago

Almost nothing in most cases, but it depends on what you're doing. Take a look at the benchmarks for lxc.

http://lxc.sourceforge.net/index.php/about/kernel-namespaces...

Postgres is a beast tho (albeit a cute and friendly beast), it's probably doing something weird that lxc won't like.

shykes8• 13 years ago

That's correct, you can approximate the overhead of LXC (and any other similar containerization such as OpenVZ, Solaris Zones, BSD jails etc.) as zero. In terms of performance they are closer to chroot than to a virtual machine.

tachion• 13 years ago

One of the reasons why I really enjoy while reading the notes is the fact that Docker does not shut itself into Linux world and promises working with alternative technologies, like BSD Jails. That's a great news and I am looking forward to see it happening!

chrisfarms2• 13 years ago

Feels like there is some wheel-reinventing going on here. Maybe someone could help me out on why the build scripts here would be preferable over something like Chef to manage the repeatable builds within a new container? Or maybe I've totally missed the point.

shykes8• 13 years ago

Dockerfiles are not a replacement for chef or puppet scripts. They're a very lightweight way to assemble a container by running unix commands, and then freezing that container into an immutable, portable unit of deployment. Some of thos unix commands may be calls to Chef.

If you're a chef user, you can use docker to "just-in-time" compile your chef recipes into a container almost as portable as a static binary. You can then send that container to me, and I'll be able to run it regardless of what configuration management I like to use on my machine.

chrisfarms2• 13 years ago

Cool, makes sense thanks.

bryanlarsen2• 13 years ago

It seems to me that you should be able to roll back an built via a Dockerfile back to any step in the build, and then rebuild from that point. A deployment via another CM tool would probably lose that ability.

Perhaps it's my inexperience, but I find chef scripts to be very fragile because of the large amount of external dependencies they generally contain. All of these dependencies are very stable: nobody takes down tarballs and packages randomly, but a large number of low probability events can add up to a high probability.

That makes image based deployments appealing, but you still need to have a reliable, repeatable capture of the steps that went into building the image...

wiremine• 13 years ago

I think the confusion is the difference between a box and a container: I grok that I would use a dockerfile to configure a container, and I would use chef/puppet to configure a box. But, _why_ can't I use chef/puppet to configure a container? Why is a dockerfile (in concept or syntax) _better_ than chef/puppet?

StavrosK4• 13 years ago

> then freezing that container into an immutable, portable unit of deployment.

Doesn't doing that make a git repo of all the files currently in the container? Wouldn't it take ages to upload this to your machine, versus just uploading a dockerfile and having it rebuild the image from scratch?

I get that Docker containers are sort-of VMs, but I don't really understand the freeezing functionality at the moment... It seems to me that you'd have to freeze the entire binary image, whereas an ansible script/Docker build file would be much more portable and result in the same thing.

SnowLprd2• 13 years ago

If someone is able to accomplish what they want using the new build script functionality, why would they want to incur the learning curve, overhead, and complexity of Chef? Don't get me wrong — Chef is a powerful tool and has its place. But for many use cases, it's totally overkill. I think Docker's new build scripts may fit the bill nicely for a sizeable number of folks without needing to figure out how to integrate with an external configuration management system.

Edit: As shykes mentions, the two are really more complementary than overlapping. I'm planning to use Docker's new build scripts to construct pre-built Docker images, which I will subsequently deploy via Ansible (a configuration management tool akin to Chef). Up until today I was building Docker images via Ansible, but now I can handle that within Docker itself, freeing up Ansible to handle tasks better suited to its bailiwick.

StavrosK4• 13 years ago

Can you post your sample before/after configs? It'd greatly help me understand how Docker can help me, as I can't run it on any of my machines currently (although I just retried it and the "unexpected EOF" error seems to have gone away).

zimbatm• 13 years ago

There surely is an overlap. Chef is meant to manage an heterogeneous environment of machines. Things like per-operating-system templates and attributes for example don't really make sense if you're targeting a single container.

shykes8• 13 years ago

It all depends on the use case. You may have the luxury of building all your containers from a single OS distro - but others might use containers to automate the testing of the same build across a large matrix of distros and application versions. In that case using Chef would allow them to keep the variation between Dockerfiles minimal.

Another example is using Chef to maintain your Docker deployment and the distributed system supporting it, then using Docker to deploy your application payload.

andyl2• 13 years ago

Chef and Docker do different things.

To create a virtual machine, you could use EC2, VmWare, Linode, VirtualBox, LXC, libvirt, Jails, Zones, etc. Now Docker is another option.

Once the virtual machine is created, you could use Chef/Puppet/Custom Scripts to install and configure software packages.

incision• 13 years ago

I've been dabbling with docker quite a bit. I'm finding it solid despite the disclaimer against production use.

cdoxsey2• 13 years ago

FWIW I've found precisely the opposite. I ended up having to roll my own lxc wrapper. Maybe in a few months docker will be there, but not right now.

thelarry2• 13 years ago

I started off using my own implementation and was thinking about switching to docker... what made you switch away from docker?

atsaloli2• 13 years ago

So how does Docker compare to Vagrant (http://www.vagrantup.com/) ? They sound very similar.

krakensden• 13 years ago

Docker lets you run separate userspaces on the same kernel.

Vagrant provisions Virtualbox, which lets you run separate kernels, on various different virtualized CPU architectures.

andyl2• 13 years ago

It is possible to use docker/lxc as a Vagrant provider. This means when you run 'vagrant up', your 'machine' could be a lxc container instead of a VirtualBox VM.

https://github.com/dotcloud/docker/issues/404

http://fabiorehm.com/blog/2013/04/28/lxc-provider-for-vagran...

atsaloli2• 13 years ago

Oh, I see. So Docker is more lightweight compared to Virtualbox. Kind of like Solaris zones. Thanks!

iso8859-1• 13 years ago

http://stackoverflow.com/q/16647069/309483

thelarry2• 13 years ago

Remote api is pretty cool and makes my life easier, but how much functionality does docker provide over running lxc-* style commands?

philwhln• 13 years ago

I interviewed one of the creators of Docker, Solomon Hykes, last week. Blog post is here. https://news.ycombinator.com/item?id=5816622

rdtsc• 13 years ago

The main question I have is since it uses LXC, which shares the kernel, I can't have Windows running in Docker or even a different Linux distro (presumably unless they happen to have the same Linux kernel)?

montecarl• 13 years ago

You are correct. You must run linux, but since most distros aren't too picky about what kernel version you run, you should be able to run any distro you want.

sosedoff• 13 years ago

Any plans for btrfs ?

bgentry• 13 years ago

Sounds like it: https://github.com/dotcloud/docker/wiki/Docker-0.4.0-release...

darkarmani3• 13 years ago

Please, please prioritize shared filesystems/storage with the host. I know it was hotly debated when talking about sharing data between containers, but sharing data with the host is very useful.

Docker 0.4.0 release note

Related Stories