Ask HN: What is the actual purpose of Docker?
I'm hearing about Docker every other day, but when I look into it, I don't understand the purpose of it.
I run many websites/applications that need isolation from each other on a single server, but I just use the pretty-standard OpenVZ containers to deal with that (yes I know I could use KVM servers instead, but I haven't ran into any issues with VZ so far).
What's the difference between Docker and normal virtualization technology (OpenVZ/KVM)? Are there any good examples of when and where to use Docker over something like OpenVZ?
158 comments
[ 2.9 ms ] story [ 217 ms ] threadAdd in image registries and a decent CLI and the developer ergonomics are outstanding.
Technologies only attract buzz when they're accessible to mainstream developers on a mainstream platform. The web didn't matter until it was on Windows. Virtualization was irrelevant until it reached x86, containerization was irrelevant until it reached Linux.
Disclaimer: I work for a company, Pivotal, which has a more-than-passing interest in containers. I did a presentation on the history which you might find interesting: http://livestre.am/54NLn
The potential minimalism of a container is also an important concept to mention, with fast startup-times and less services that could potentially be vulnerable.
Application runtime dependencies are a common source of communication breakdowns between development and infrastructure teams. Making the application container a maintained build file on the project improves this communication.
docker provides:
* a standard format for building container images (the Dockerfile)
* a series of optimizations for working with images and containers (immutable architecture etc).
* a community of pre-built images
* a marketplace of hosting providers
All at the cost of linux only, which is ok for many shops.
https://news.ycombinator.com/item?id=9805056
This is the core that Docker solves, and in such a way that developers can do most of the dependency wrangling for me. I don't even mind Java anymore because the CLASSPATHs can be figured out once, documented in the Dockerfile in a repeatable programatic fashion, and then ignored.
In my opinion the rest of it is gravy. Nice tasty gravy, but I don't care so much about the rest at the moment.
Edit: As danesparz points out, nobody has mentioned immutable architecture. This is what we do at Clarify.io. See also: https://news.ycombinator.com/item?id=9845255
Also, how do you manage your containers in production?
Management: We create AMIs using Packer. Packer runs a provisioning tool which downloads tho container and the configuration and sets up the process monitoring. It then builds a machine image, and then we launch new servers.
Lots of people write their own scripts to do this; I wrote Tiller (http://github.com/markround/tiller) to standardise this usage pattern. While I have written a plugin to support storing values in a Zookeeper cluster, I tend to prefer to keep things in YAML files inside the container - at least, for small environments that don't change often. It just reduces a dependency on an external service, but I can see how useful it would be in larger, dynamic environments.
I'm not terribly fond of using environment variables for configuration, personally. That method requires either a startup shim or development work to make your program aware of the variables, and your container manager has to have access to all configuration values for the services it starts up.
I don't really see the point of lightweight virtualization. It provides an illusion of isolation which will likely come crashing down at some probably very inconvenient point (e.g. when you discover a bug caused by a different version of glibc or a different kernel).
I don't care about the isolation for isolation sake, I care about it for the artifact sake.
I care about tracking down issues before they reach production. Meaning that I want an environment that mirrors production as closely as possible. Meaning heavyweight not lightweight virtualization.
Our build scripts get tested a dozen times a day and cannot tolerate half-assed broken build scripts.
Our deployment pipeline (after verifying the image is good enough to be deployed) packs the docker image into a machine image along with several other containers. The machine image is then deployed to staging. If the machine image passes staging, it goes to production. If there is an issue which has hit production exclusively (it has happened only a handful of times,) it is simply an issue of rolling back to the previous machine image.
Well, it gets you a step closer to accurately mimicking production.
>It also doesn't "cover up" broken build scripts.
That seems to be what that 'build once' rule is for. If your building process isn't risky, why the need to prohibit running it twice?
Just because I can install the operating system doesn't mean I want to do this on every deploy of an application.
What is this rule to only build once? I can see not wanting to create multiple artifacts of your codebase, but with machines it is possible to continually update them and sometimes desirable as well. In the "cloud" world, you can arguably rebuild a server every time it needs updates, but at the physical level you don't always have capacity to absorb the hit of rebuilding multiple boxes at once. The physical servers need to get updated and managed post-install.
Unless you're snapshotting that vagrant box and then deploying that to all your servers somehow, you are building multiple times.
> What is this rule to only build once?
I'd recommend reading the book Continuous Delivery. It is a fantastically helpful read.
I prefer not to update my machines, but that is because I follow immutable deployments. But, even if I did update my machines, it is far cleaner (and easier to roll back!) to deploy an asset which has all its dependencies in the box. than to push out code and maybe have to upgrade or install new packages. The gemfile.lock and friends make this a bit less of a problem, but you also get to lock things like libxml version or ffmpeg or...
> In the "cloud" world, you can arguably rebuild a server every time it needs updates, but at the physical level you don't always have capacity to absorb the hit of rebuilding multiple boxes at once.
Totally true, and we don't do this. We build a machine image and do a rolling-deploy replacing existing servers with the new machine image.
> The physical servers need to get updated and managed post-install.
One of the reasons I try not to work with hardware. Physical hardware is hard, and avoiding it makes my life much simpler. I love it.
You're also configuring many things in many different potentially complex ways.
The docker method of using environment variables as a configuration hack to get around this is pretty horrible, IMHO. Especially compared to ansible's YAML/jinja2 configuration.
http://12factor.net/config
I think the point is not to conflate configuration that is equivalent to code (which, sure, put it in version control) with configuration that is specific to how code is deployed (which your deployment tool should just tell you, via env vars).
YAML/jinja2 is just terrible. When you have to introduce a templating system to programmatically generate your YAML configuration files, what you have really needed the whole time is an actual programming language.
Taking out the turing completeness restricts the mess which you can make and lets non-programmers do more while still being customizable.
Which one? The one by Humble and Farley (Addison-Wesley) is from 2010, is it still relevant?
The book is excellent. I was surprised that it wasn't older.
If your cycle is "build, test, build, deploy", then you are not deploying those artifacts that you tested.
Any number of factors (different dependency version, toolchain difference, environment differences, non-reproducible builds) could lead to the second build being different from the first one, and then you deploy an untested artifact.
Not to mention that rebuild can be resource intenstive.
Packer is not quite an apt comparison, but would be a better comparison, than Vagrant.
The advantage is you do the steps that could possibly fail at build time. The downside is you need to learn to get away from doing runtime configuration for upgrades.
http://michaeldehaan.net/post/118717252307/immutable-infrast...
I wrote Ansible, and I wouldn't even want to use it in Docker context to build or deploy VMs if I could just write a docker file - assumes I might not need to template anything in it, probably. I would still use Ansible to set up my "under cloud" as it were, and I might possibly use it to control upgrades (container version swapping) - until software grows to control this better (it's getting there).
However, if you were developing in an environment that also wanted to target containers, using a playbook might be a good way to have something portable between a Docker file and Vagrant if a simple shell script and the Vagrant shell provisioner wouldn't do.
I'd venture in many cases it would.
Agree and add that Python's paths (forget what they're called) (as well as Java CLASSPATHS) have been a problem for me on occasion too which means Docker would probably help with all these types of path issues.
I don't think your statement is true at this point in time. OpenVZ is used by a ton of companies in the hosting industry and by large companies such as Groupon and smaller ones like TravisCI [1]. I would't make a statement that that Docker has a wider adoption than OpenVZ at this point in time. Maybe in five years, yes it may have a wider adoption than OpenVZ. OpenVZ and commercial VZ have been doing full OS containers since the early 2000s and it has the production track record to do very well in many server applications. I wouldn't hesitate to use it over Docker in production for my future projects.
[1]: http://changelog.travis-ci.com/post/45177235333/builds-now-r...
https://engineering.groupon.com/2014/misc/dotci-and-docker/ http://www.meetup.com/Docker-Chicago/events/220936626/
Source: I work at 600 W Chicago, the Groupon World HQ, where they frequently host Docker meetups on the 6th floor.
(from linux.git):
$ git log --pretty=oneline --no-merges --author='@parallels.com' | wc -l 695
I also suspect that it won't take super long for container technologies like Docker to take over OpenVZ/Virtuozzo if not only for projects like Kubernetes, which is backed by Google, and is the basis for commercial PaaS offerings such as Openshift v3 from Redhat. Virtuozzo is great tech, but using it for a new buildout seems like a bad idea for the forseeable future. Docker is not as good, but will be soon, and is supported out of the box on every modern distribution.
[1] http://blog.travis-ci.com/2014-12-17-faster-builds-with-cont...
I agree that the hosting industry isn't what it used to be. Most of the larger hosting providers are not keeping up with the current trends and deployment methods, but that is mostly due to the fact that they do not need change. Most people who are buying commodity hosting don't have a team of developers and operations guys to use all the new cool cloud methods like Docker.
docker is a glorified chroot and cgroup wrapper.
There is also a library of prebuilt docker images (think of it as a tar of a chroot) and a library of automated build instructions.
The library is the most compelling part of docker. everything else is basically a question of preference.
You will hear a lot about build once, deploy anywhere. whilst true in theory, your mileage will vary.
what docker is currently good for:
o micro-services that talk on a messaging queue
o supporting a dev environment
o build system hosts
However if you wish to assign ip addresses to each service, docker is not really mature enough for that. Yes its possible, but not very nice. You're better off looking at KVM or vmware.
There is also no easy hot migration. So there is no real solution for HA clustering of non-HA images. (once again possible, but not without lots of lifting, Vmware provides it with a couple of clicks.)
Basically docker is an attempt at creating a traditional unix mainframe system (not that this was the intention) A large lump of processors and storage that is controlled by a singular CPU scheduler.
However, true HA clustering isn't easy. Fleet et al force the application to deal with hardware failures, whereas Vmware and KVm handle it in the hypervisor.
docker is a process container not a system container.
> docker is a glorified chroot and cgroup wrapper.
that is fairly immaterial, suffice to say that the underlying linux core tech that enables docker has matured enough lately to enable a tool like docker. I built many containers and I never thought about them in terms of the underlying tech.
> There is also a library of prebuilt docker images (think of it as a tar of a chroot)
yes
> and a library of automated build instructions
more accurate to say there is a well defined SDL for defining containers.
> You will hear a lot about build once, deploy anywhere. whilst true in theory, your mileage will vary.
have to agree, this is oversold as most of the config lives in attached volumes and needs to be managed outside of the container.
> However if you wish to assign ip addresses to each service, docker is not really mature enough for that. Yes its possible, but not very nice. You're better off looking at KVM or vmware.
Have to disagree here, primarily because each service should live in each own container, docker is a process container, not a system container. Assemble a system out of several containers, don't mash it all up into one - most people don't seem to get this about docker.
> There is also no easy hot migration. So there is no real solution for HA clustering of non-HA images. (once again possible, but not without lots of lifting, Vmware provides it with a couple of clicks.)
None is required. Containers are ephemeral and generally don't need to be migrated, they are simply destroyed and started where needed. Requiring 'hot migration' in the docker universe generally means you are doing it wrong. Not to say that there is no place for that.
As a final note, all my docker hosts are kvm vm's.
> docker is a process container not a system container.
Valid. However the difference between docker image and openVZ images is the inclusion of an init system.
> Have to disagree here, primarily because each service should live in each own container, docker is a process container, not a system container. Assemble a system out of several containers, don't mash it all up into one - most people don't seem to get this about docker.
I understand your point,
I much prefer each service having an IP that is registered to DNS. This means that I can hit up service.datacenter.company.com and get a valid service. (using well tested dns load balancing and health checks to remove or re-order individual nodes)
Its wonderfully transparent and doesn't require a special custom service discovery in both the client and service. because like etcd it has the concept of scope you can find local instances trivially. using DCHP you can say connect servicename and let dhcpd set your scope for you.
> None is required. Containers are ephemeral and generally don't need to be migrated, they are simply destroyed and started where needed. Requiring 'hot migration' in the docker universe generally means you are doing it wrong. Not to say that there is no place for that.
This I have to disagree with you. For front end type applications, ones that hold no state, you are correct.
However for anything that requires shared state, or data its a bad thing. Take your standard database cluster ([no]SQL or whatever) of 5 machines. You are running at 80% capacity, and one of your hosts is starting to get overloaded. You can kill a node, start up a warm node on a fresh machine.
However now you are running at 100% capacity, and you now need to take some bandwidth to bring up a node to get back to 80%. Running extra machines for the purpose of allowing CPU load balancing aggrieves me.
I'm not advocating writing apps that cannot be restarted gracefully. I'm also not arguing against ephemeral containers, its more a case of easy load balancing, and disaster migration. Hot migration means that software is genuinely decoupled from the hardware.
No it isn't. Most people don't use an init system with Docker images. However, one of the top-10 popular images uses one -- the Passenger Phusion base images. They make a pretty compelling argument why you should.
None of these arguments are relevant in the big picture. Where Docker shines is the package management, not the virtualization. As a package management system, it is brilliant -- though incomplete. The package management could be fully content-addressable, and at which point, we'll have something more brilliant than what it is now. But it isn't, and I doubt anyone will try it until after this core concept gets adopted into the mainstream.
Ten years ago in 2005, I've heard these same types of arguments about cloud providers, the Zen hypervisors, and the AWS API. I've seen old mainframe folks rolling their eyes saying the technology is old, and this is hyped up. Of course it's hyped up; but unless you can look past the hype and your contempt, you won't see what's really there. No one is really arguing about cloud technology now, and the hold-outs are outnumbered by the majority.
There are docker-backed service management tools that will automatically this for you(assign public/private dns per service cluster inc load balancing), like Empire https://github.com/remind101/empire
Care to elaborate on this? Do you use the linking system described here? https://docs.docker.com/userguide/dockerlinks/
I mean, your various containers still communicate over IP, right? Just a private IP network within the host, rather than outside?
(Obviously I've never used Docker.)
I don't understand. If you can't assign IPs to each service (or it's difficult/unreliable to do so) how can processes talk to each other and the outside world?
You should have no way to login to the docker container
Dockers networking does not allow that for that IP to be visable.
You can tear down the host server, then recreate it with not much more than a `git clone` and `docker run`.
2. Precise test environment. I can mirror my entire production environment onto my laptop. No internet connection required! You can be on a train, on a plane, on the beach, in a log cabin in the woods, and have a complete testing environment available.
Docker is not a security technology. You still need to run each service on a separate host kernel, if you want them to be properly isolated.
This is a simple bind-mount and isn't special at all.
Also, virtual machines have had things like 9p that allow the same thing.Where I've worked in the past, setting up a new development or production environment has been difficult and relied on half-documented steps, semi-maintained shell scripts, and so on. With a simple setup of a Dockerfile and a Makefile, projects can be booted by installing one program (Docker) and running "make".
You could do that with other tools as well, but Docker, and even moreso the emerging "standards" for container specification, seems like an excellent starting point.
If the docker tool will have something like `docker serve` and start his own local registry will be more than great.
For this case when I switch to Go was a great solution, building the binary is everything you need.
About docker being helpful for development, definitively yes, I switch to postgres, elasticsearch and redis containers instead of installing them on my computer, is easy to flush and restart and having different versions of services is also more manageable
Docker gives you the ability to version your architecture and 'roll back' to a previous version of a container.
You get most of the benefits of immutable builds anyhow by having scripts which can reliably set up servers from scratch on the fly.
You shut down a VM and instruct the hypervisor system to take a "snapshot" which locks the original VHD file and creates a new one. When writes happen, they're performed on the new VHD, and reads have to use both the main and the snapshot VHD. And you can create a chain of snapshots, each pointing to the previous snapshot, for versioning. Or you can have several VM snapshots use the same master VHD, like for CI or data deduplication.
To roll back, it's usually as simple as shutting down the VM and removing the snapshot file.
The way VMs handle this doesn't carry the same semantics as the way you can with Docker. There's a finer-grain composability with Docker that is much more awkward with VMs.
Docker may not be as great as a virtualization tool as VMs -- security concerns, complexity, etc. -- but it is a much better package management tool.
OpenVZ, LXC, solaris zones and bsd jails on the other hand or mainly run complete OS and the focus is quite different from packaging your applications and deployments.
You can also have a look at this blog which explains the differences more in detail: http://blog.risingstack.com/operating-system-containers-vs-a...
- Docker is nothing new - it's a packaging of pre-existing technologies (cgroups, namespaces, AUFS) into a single place
- Docker has traction, ecosystem, community and support from big vendors
- Docker is _very_ fast and lightweight compared to VMs in terms of provisioning, memory usage, cpu usage and disk space
- Docker abstracts applications, not machines, which is good enough for many purposes
Some of these make a big difference in some contexts. I went to a talk where someone argued that Docker was 'just a packaging tool'. A sound argument, but packaging is a big deal!
Another common saw is "I can do this with a VM". Well, yes you can, but try spinning up 100 vms in a minute and see how your MacBook Air performs.
The down side about docker is that it takes longer to set up your docker in the first place, it is harder to keep secure, and it runs slower than a traditionally deployed application, but compared to VM deployed applications the performance is usually better.
http://docs.vagrantup.com/v2/provisioning/docker.html
Docker is about running isolated environments in reproducible ways. I get a container working just so on my desktop, ship it to an internal registry, where it gets pulled to run on dev and qa. It works identically to how it works on my desktop, then I ship it to production. One image that works the same on all environments. That is what docker was for, developer productivity.
I think thats the best way I can summarise what Docker _is_.
Docker is exactly like OpenVZ. It became popular because they really emphasize their OpenVZ Application Templates feature, and made it much more user friendly.
So users of Docker, instead of following this guide: https://openvz.org/Application_Templates
They write a Dockerfile, which in a simple case might be:
So no fuzzing with finding a VE somewhere, downloading it customizing it, and then installing stuff manually, stopping the container and tarring it, Docker does that all for you when you run `docker build`.Then you can push your nice website container to the public registry, ssh to your machine and pull it from the registry. Of course you can have your own private registry (we do) so you can have proprietary docker containers that run your apps/sites.
From my perspective, the answer to your question would be: Always prefer Docker over OpenVZ, they are the same technology but Docker is easier to use.
But I've never really invested in OpenVZ so maybe there's some feature that Docker doesn't have.
Docker does that, too. Actually, I'm running docker containers as a fast and easy replacement for VirtualBox VMs.
I had to change /etc config files, mange where logfiles went and how they were handled, all of this is described on a diffing filesystem.
I might be misinterpreting what you mean though. I have no experience with OpenVZ and little with Docker.
They are built around the same set of kernel features and as far as I can see offer exactly the same abstractions.
For example Phusion Baseimage is a Docker baseimage that's similar to an OpenVZ container in the sense that it emulates a full running Ubuntu environment. It has is uses but the Docker community rather sees containers that encapsulate a single application with no external processes.
But they add little features to claim their right of existence.