Not trolling here, seriously interested in where people see value in the real world.
You can expose more than a single port to the local OS, so it sounds like your experience is frought with misunderstanding, which can only be characterized as our fault :)
Reach out - nick@docker.com
I think it's helpful to frame Docker in terms of encapsulation.
Imagine a basic Java app with multiple dependencies. Rather than build a lean app.jar and rely on the host providing dependency1.jar and dependency2.jar, many folks package it all into a single app_with_dependencies.jar.
But what if your app is a web app with static content? Rather than depending on the host system to serve the static content separately, many folks package it all into a single app_with_content.war.
But what if your app needs a specific version of Java? Rather than depending on the host system to have the exact Java you need, folks are starting to package the app into a Docker image that has their desired Java version.
Each layer of encapsulation simplifies server provisioning and thereby improves app portability. Taken to an extreme, you can treat your hosts as homogenous and run any Docker container from any server.
Honestly, I would prefer to run as many small/medium instances rather than a powerful instance but to host many dockers inside it, because if you put all the eggs in one basket and when then host machine is down, you are having a bigger problem; if you host a single docker on an ec2 instance, and as I said before, you can already solve this via AMI without the overheads/abstraction.
Of course, it is still very useful to run docker on a physical machine when you don't want to setup KVM or mess up with OpenStack.
Big fan of packer.io + AMI / Virtualbox / GCE for this.
See generally: http://www.infoq.com/articles/virtual-panel-immutable-infras...
- We build hundreds if not thousands of docker images a day after each CI commit. Thats not viable with virtual machines or AMIs.
- Docker has the union file system, so pushes and pulls of Docker images after each CI build are tiny;
- Docker is more platform independent whereas AMIs are very EC2 specific. No other cloud provider have anything as sophisiticated as AMI;
- Rollbacks are instant with Docker;
Docker can also be used in conjunction with autoscaling and resilience. We have 10+ containers on a box, but still replicate this 5 or 6 times and will possibly add EC2 AutoScaling in future. Cloud and Docker are complementary not an alternative in my opinion.
Was one port exposed a legacy restriction on Docker?
It's not the case now - you can expose many ports to the OS, and then map them as you wish.
This is actually a massive benefit. We might deploy 10 containers to one box all exposing SSH port on 22 and HTTP port on 80, but then at runtime choose which port the OS exposes and map 10 different ports onto 22/80 in the containers.
The real value I find of Docker in production is the deployments - fast, repeatable, easy to rollback. Once they're on a box, it's much of a muchness once you've mapped the ports.
You create say 3 instances of that image (i.e. 3 containers) with different port mappings 5001:80, 5002:80, 5003:80. These are just specified at the command line (docker run -p5001:80)
Against the same containers you might also do 6001:22, 6002:22, 6003:22 to expose SSHD to different ports on the host.
This allows you to defer the decision of which containers will be listening where to deployment or runtime, giving you lots of flexibility.
OK, how does a client outside of my docker host know to connect to 5001 to get to container1 port 80 and 6001 to get to container1 port 22?
BTW, this was the scenario I mentioned initially as "I could go ham on it and move ports around."
Thanks again for the reply, getting somewhere.
So instead of your apps having hard coded endpoints, they go to some config file, zookeper, etcd to find the services. Your config management piece can register endpoints with the same directories as they come online.
An alternative is just to register with a load balancer dynamically.
This bit does take work but it gives your system a very nice dynamic fungible property.
Happy to discuss more offline with anyone as I'm a massive advocate of docker now! Same username at Twitter.
Docker will soon offer a better solution to service discovery. It will allow taking advantage of the various SD tools out there (zookeeper, etcd, synapse/haproxy, skynet, serf) while keeping your containers compatible with all of them. This will help keep all docker containers compatible with each other, instead of fragmenting them among mutually incompatible service discovery protocols.
Happy to chat about it more on irc - #docker and #docker-dev on Freenode.
To expand on this, a common pattern is to have a local proxy installed on each host machine. To route traffic to a new container, one simply updates the config for the local nginx/haproxy/hipache/other proxy.
A second layer of load balancing exposes the singular, top-level endpoint. All Docker hosts are registered with this LB, but those without live containers for a given service are simply "out of rotation" for that endpoint (health check failure).
This simplifies the service discovery aspect for architectures not already using a more sophisticated mechanism.
"In deployment, a routing layer handles routing requests from a public-facing hostname to the port-bound web processes."
This is called advanced networking, yes?
http://docs.docker.io/use/networking/
They didn't have this when I looked last summer.
I only started playing with Docker last December, and I think this was supported from that point in time, so definitely it could be a recent addition.
Currently I'm envisioning Docker playing a nice role in our CI and development infrastructure at work, where we can choose to start a new docker for any given project, and get a locally accessible IP back in a matter of seconds ... all from our soon-to-be-created CI+deployment web ui ;-)