Hacker News Reader

Comment by mtrimpe | Hacker News Reader

I just came here to basically say the same; which I guess is the question shared by 80% of Docker's target market.

I have a box sitting somewhere which, like virtually any dedicated machine, is wildly overprovisioned for it's current usage patterns.

I would like to virtualize my services so that I can one day, when my needs outgrow my box, scale out without having to rewrite any code.

My box has limited IPs available, so I'll need the network between services to be private/internal.

How do I set that up with Docker?

I think it won't be until you can truly easily answer that question that Docker will really take off.

View on HN

I'm probably just going to show my ignorance, here...but why doesn't container linking solve this problem?

Could you not run multiple docker containers/services behind a single nginx or apache container on a production server? Then the nginx container basically gets one of your public IP addresses, and you use linking to that container to provide it with knowledge of the other running processes' IP addresses (each within their own container, of course). In that way, you have one public facing container which has knowledge of the other containers and can use the information provided through -link to configure the nginx server to route requests appropriately. This requires a bit of bash script / sed command line hackery to update your nginx configuration to accommodate the changing IP addresses of the other containers on restart (unless you can set them by hand now using Docker, we still don't), but once you get it setup you never have to think about it again.

Like I said, maybe I'm just showing my ignorance, but something like the above scenario is how we get around hosting multiple services with limited public IP addresses available.

I don't like the container linking because it is basically tied to one server without extra complexity.

CoreOS' "fleet" ( https://coreos.com/docs/launching-containers/launching/launc... ) gives a cluster-wide solution.

But even without using fleet, the overall mechanism is fairly easy to adapt: Either use systemd dependencies like in their example, or have a script that queries docker on each host to spot changes in running containers, and update an etcd instance (or whichever your preferred config server is).

The "extra complexity" needed for multi-machine setups over linking containers is actually pretty minor.

Your services need to read something to get the IP, which ultimately comes from an ENV variable. In the linked container scenario Docker sets that variable. Otherwise you set it manually. That's the only extra complexity.

I was worried about this too, so I tried it out[1]. In this case I have a YAML config file, which can be overridden by ENV variables (which may come from Docker).

This isn't as automatic as CoreOS (eg, no failover etc), but it is a lot less complex.

[1] https://github.com/nlothian/Acuitra/blob/master/services/que...

Why not use ipv6 for the network between services?

I'd love to see an article on a setup using ipv6, that'd be cool.

Reply on news.ycombinator.com