In the post you link above, it seems like you're mainly comparing Docker to traditional, non-virtualized setups. Do you (or does anybody) have thoughts on comparing it to virtualized environments? I recently experimented with Xen as a way to isolate services, and it seemed awfully heavy; does Docker end up being a lighter burden?
I'd also love to hear more stories about Docker vs the other virtualized setups. It generally seems to be a dramatic improvement in usability, performance, etc, but I'd love to hear more about the specifics from those who have made the switch.
Here's a few production users: http://www.docker.com/resources/usecases/ http://blog.docker.com/2013/12/baidu-using-docker-for-its-pa...
We provided CI for the 2500 teams and also ran the competition using Docker (both on top of AWS EC2 instances). I think that without Docker the implementation would have been a lot more painful and almost impossible given the time constraints we had for the project.
Fast starting and fast shutdown of build and test processes allowed us to run CI builds efficiently on a fairly small amount of nodes. This saved us money and also helped to keep the infrastructure manageable.
Also the additional level of security was really nice since we were running possibly malicious code from 2500 sources. The malicious part became even more evident when Kevin Mitnick tweeted that he might participate: https://twitter.com/kevinmitnick/status/446359450614378496
The Docker image repository was also really handy when we ran the races. We needed build the bots only once and then we could just use the prebuilt images on on race nodes.
Building the actual base image was fairly painful. We support about 20 different programming languages and also package in quite a few libraries. Once the base image build was fully automatized and we had the Docker related processes fully working, it was almost a revelation on how Docker could improve things over the classical virtual machine approach. I can't wait to try it out on another project :)
By the way, the competition finals are today (Tuesday) and streamed live @ https://helloworldopen.com/ (in English and Finnish)
* half git-syntax/half package manager-syntax is cumbersome to me.
* Inability to compile Docker from source without using the Docker Project's provided "black box" binary Docker.
* No formal explanation of how to create your own base image from scratch (ie. not using a Docker Project provided base image).
* Defaults to storing images in the Docker "cloud" repo. (would have preferred a git-like setup where pushing my images to a repo of my choice was more "normal")
* GO Lang is still pretty obscure for most developers, and an interesting choice given the language's youth and likely-hood to change rapidly as it matures.
* Docker is built on-top of existing Linux technologies, mainly LXC, making it more-or-less disposable in the future (as someone else figures out how to abstract/manage LXC better)
* Docker is mainly built by Dotcloud - a for-profit company. Dotcloud has been very generous in their effort... but, being for-profit, what is their take out of it? (It can't be "just for the goodness of Linux").
For what it does, the syntax seems pretty natural, but that's all subjective, so of course YMM(and clearly does)V.
> Inability to compile Docker from source without using the Docker Project's provided "black box" binary Docker.
I think this is more accurately phrased as "no simple documentation of the dependencies to build docker from source without using the pre-built dev container".
> No formal explanation of how to create your own base image from scratch (ie. not using a Docker Project provided base image).
Well, there's an explanation-by-example @ http://docs.docker.com/articles/baseimages/ which seems to indicate that the process is "take the root file system of the Linux system you want to make into an image, tar it up with specified options, and then import the tar."
Admittedly, this documentation could be improved.
> Defaults to storing images in the Docker "cloud" repo. (would have preferred a git-like setup where pushing my images to a repo of my choice was more "normal")
I agree.
> GO Lang is still pretty obscure for most developers, and an interesting choice given the language's youth and likely-hood to change rapidly as it matures.
Its "Go" not "GO". And why is this a gripe? If it was true (and it doesn't seem to be, Go has a stable 1.0 release with a strong backward-compatibility commitment), that might be an added dev cost for the Docker team, but unless there was a reason to think that the cost didn't have sufficient benefits, shouldn't be a reason for a potential user to complain.
> Docker is built on-top of existing Linux technologies, mainly LXC, making it more-or-less disposable in the future (as someone else figures out how to abstract/manage LXC better)
Docker is first and has momentum, and doesn't seem like its going to stop development just because it hit 1.0. So, yeah, something better might come along, but its not like Docker is a stationary target.
> Docker is mainly built by Dotcloud - a for-profit company. Dotcloud has been very generous in their effort... but, being for-profit, what is their take out of it? (It can't be "just for the goodness of Linux").
The whole list of services (training, consulting, and support) that they announced today [1], which were previewed in the earlier blog post about Docker 1.0 [2], makes that pretty clear.
[1] http://blog.docker.com/2014/06/docker-announces-new-enterpri... [2] http://blog.docker.com/2014/06/its-here-docker-1-0/ : "In addition, to provide a full solution for using Docker in production we’re also delivering complete documentation, training programs, professional services, and enterprise support."
You can compile it from source (assuming you have a go environment and set GOPATH properly):
$ sudo apt-get install libdevmapper-dev libsqlite3-dev btrfs-tools
$ go get -u github.com/dotcloud/docker/docker
docker will be in your $GOPATH/bin
> GO Lang is still pretty obscure for most developers, and an interesting choice given the language's youth and likely-hood to change rapidly as it matures.
Go1 promise will be kept by Go team[0].
> Docker is built on-top of existing Linux technologies, mainly LXC, making it more-or-less disposable in the future (as someone else figures out how to abstract/manage LXC better)
No, docker right now is built on top of libcontainer[1].
0. http://golang.org/doc/go1compat
1. http://blog.docker.com/2014/03/docker-0-9-introducing-execut...
Edit 1: Format
The go authors have committed to keeping major versions stable since v1 and are unlikely to massively change anything.
I'm sure much of google's infrastructure is coming to rely on go (and docker!) so they will be as unhappy about such drastic change as others.
However, this doesn't excuse the remaining gripes listed above.
You mean 14 months ago?
Offer them some suggestions on how to clean up the UI.
"Inability to compile Docker from source without using the Docker Project's provided "black box" binary Docker."
Addressed in a different comment.
"No formal explanation of how to create your own base image from scratch (ie. not using a Docker Project provided base image)."
As usual, documentation rarely keeps up pace with the rest of the project despite best intentions. Mind you, despite some holes, their documentation is quite impressive.
"Defaults to storing images in the Docker "cloud" repo."
This will probably change now that Google is embracing it.
"GO Lang is still pretty obscure for most developers, and an interesting choice given the language's youth and likely-hood to change rapidly as it matures."
Addressed in a different comment.
"Docker is built on-top of existing Linux technologies, mainly LXC, making it more-or-less disposable in the future (as someone else figures out how to abstract/manage LXC better)"
This is a benefit of Docker! I'd rather see them build it with existing components wherever they can.
"Docker is mainly built by Dotcloud - a for-profit company. Dotcloud has been very generous in their effort... but, being for-profit, what is their take out of it? (It can't be "just for the goodness of Linux")."
They're following a tried-and-true pattern for generating revenue off an open source model (giving away the product for free and making money on support and consulting). Companies that try to throw out a crappy product and charge for support quickly find themselves with no customers. Also, now that Google is on-board, you can expect the product to improve significantly as they contribute to the repo even more.
I also found this particular annoying.
To build it from source, make sure to install all dependencies (check the provided Dockerfile for details), add both docker and docker/vendor to your GOPATH and then execute `bash hack/make.sh dynbinary`
http://docs.docker.com/articles/baseimages/
Some links there for examples. Ultimately the base image is a tarball of a filesystem.
You still need to be able to configure everything inside the container (thus the need for a CM tool), and then also the environment and infrastructure inside which the containers live (thus the need for infra management tools).
Docker really doesn't make infrastructure management markedly easier—just faster, more flexible, and slightly more powerful. It's one layer of abstraction over a VM, IMO, and that's a good thing, but carries with it it's own set of complexities.
I'm missing something, but in what scenarios would you need to do something more complex than what can be expressed in a few RUN and ADD commands in a Dockerfile?
My limited experience is that indeed, orchestration is still completely needed. We underestimated that and now we have a bunch of hacky shell scripts that build and start and stop docker containers at various moments. But the docker containers themselves are pretty simple.
That can indicate some deeper problems, but in some circumstances (and especially when making updates to your container images), using configuration management for individual containers can be helpful for the same reasons even CM-ifying a small single-purpose standalone VM can.