Regarding who is supposed to use it...
If you like deploying your apps to a Platform-as-a-Service (PaaS) like Heroku, Google AppEngine, or DotCloud, but wanted to run it on your own infrastructure, then Docker could be for you!
It's designed to be a key building block for anyone who wants to create their own PaaS-like service or environment. Why would you need your own PaaS? You might have unique security requirements forcing you to run an app in-house, or you might not want to pay the high prices of a commercial PaaS if your app gets popular.
So I'm used to configuring stuff by hand, and now I see a lot of buzz around docker, vagrant, chef, puppet, salt and they seem like glorified shell scripts. Am I missing something?
Vagrant is a little bit different - it takes the process of booting up a new VM instance (think VirtualBox/VMWare) and automates much of the process of:
1. Choosing OS / flavor / architecture (Debian 7 x64),
2. Setting up networking (private network with its own IP address),
3. Setting up SSH access ($ vagrant ssh),
4. Kicking off provisioning (Chef/Puppet/Salt/Ansible/Bash)
With Vagrant, if you're playing around in your VM and accidently screw something up and can't recover [0], you simply "$ vagrant destroy" and "$ vagrant up" and you'll have a working VM again.
Couple Vagrant with Puppet, and if you destroy/up you'll have your VM go through the process of installing all software and settings and everything for you, meaning your full, working environment is back up and running within minutes, just as it was before you screwed it up.
[0] I experienced this several times when my apt-get stuff would screw up and I couldn't install/remove/purge anything. Google and #debian never let me recover.
These tools let you focus on the bigger picture instead of the nitty-gritty.
Docker and Vagrant are convenient for building (and distributing) consistent environments on top of (potentially wildly) different software or hardware platforms. Docker has a ton of other tricks up its sleeve (one example is "layers:" http://docs.docker.io/en/latest/terms/layer/).
Chef/Puppet/Salt/et al. are configuration management tools which enable programmatic definition of infrastructure. The key point is: you define how the system should look, not the specific steps on how to get there. Abstraction layers (management of files/users/packages/services/etc.) provided by the CM tool shield you from a nightmare of permutations, corner cases, and platform-specific options; it'll just enforce a given configuration regardless of local changes.
Having a central source of truth for systems configuration is a gamechanger in itself; your configuration directives or applications can query (or update) your configuration management database, which enables some very cool automation with very little effort. Then there's the community: for any given stack, there's probably a well-documented, well-tested Chef cookbook or Puppet manifest to build it, instantly plugging you into a rich experience base.
Yes, one could script all of this from scratch, but I'm not sure why one would.
It's basically what you get when you start your deployment toolchain as simple shell scripts, then make them evolve, add features, and at some point, rewrite from scratch with a "real" programming language. I don't know if that matches your definition of "glorified" though :-)
The big difference with just scripts is that you can "freeze" the state of your deployment with strong guarantees that 1) it will not change and 2) it will behave the same way across machines.
Another advantage of containers is that deployment can be made atomic: either container A is running, or container B. You can't end up with a half-finished upgrade which leaves your server in an undefined, broken state. That property becomes very important when you deploy to a large number of servers.
What I do to run applications is this: I fire up a vm or dedicated server on some provider and run my stuff on it. I use Amazon and a couple of other providers.
Ok. That's great. Then let me try to give you some examples #:
Imagine you have setup your SaaS to run from some containers (1 container with your web app, 1 container with your worker, 1 container with your queue and a database somewhere.
Now let's walk through a scenario for a significant new release of your web app:
1) Package your new web app, Launch it for testing (on the same host, cheap) to point to a testing database.
2) Fails? Rebuild, test immediately.
3) Happy? Now relaunch your container to connect to the production database
4) Everything works completely? Now re-route your traffic to the already warmed up container. Chances of failure? < 0.1%
Some other ideas:
- Package your worker. Run it once (on the same host), more load? run it multiple times, run it on multiple servers. -- it is so much quicker and cheaper than spinning up virtual machines.
- So your developer made some changes.. He packages it and you run it. It fails. You now just save the entire container including the last state, logs and everything exactly as you crashed it. And hand that back to him.
Hope it helps.
these examples are based on intended use, because right now the whole development is still moving so fast production deployments are no yet recommended.
Sorry, I dont even understand your first sentence. "Imagine you have setup your SaaS to run from some containers". What is a container? What is a "Worker"? What do you mean with "queue"?
Then you say "Package your new web app, Launch it for testing". I never package my web app. It just runs and runs and runs. And my customers use it. I develop it on another machine, and from time to time I push updates from the development machine to the production machine. Everything seems fine to me. Am I having a problem I dont know about?
A worker is usually something that does background processing. For example a user uploads an image and you need to convert it to multiple sizes. You can either do this on your application server within the scope of the request, or set up a task queue.
Here's an oversimplification of the latter: You have an application server, a queue (something like 0MQ, or redis) and one or multiple workers. When the image is posted, you add a job to the queue, asking for the image to be processed. The worker polls the queue asking if there are any jobs, an if there are, it executes those.
> I never package my web app. It just runs and runs and runs. And my customers use it.
It's designed to be a key building block for anyone who wants to create their own PaaS-like service or environment. Why would you need your own PaaS? You might have unique security requirements forcing you to run an app in-house, or you might not want to pay the high prices of a commercial PaaS if your app gets popular.