Our images range from 600MiB to 2GiB in general. When you say share port numbers what exactly are you referring to? App X listening to port M in eth0 and app Y listening to port M in eth1? We don't really have this use case so for us it has been pretty simple.

I think that your use case is a lot more complex than ours or I'm misunderstanding some part, are you using bare metal servers in your own data center? I'm trying to grasp what's your architecture like so I can see what parallel can I make to ours.

You didn't mention how long deploys take. 2GiB x 80 servers = 160GiB; assuming a 1Gb/s interface on the repository, it'll take a minimum of 22 minutes for all the servers to get their new bits.

The nice part about Docker is the images are composed of layers, so you only have to re-download a layer when it changes. In practice, we pull all of our base layers when we bake our AMIs, so spinning up a new instance is pretty quick and each new deploy only has to update the top layer that contains our code.

Honestly, the only issue when it comes to image size is the initial developer pull either when they onboard to a team or when they bork their boot2docker install (which, disturbingly, happens way too often).

Many applications are very large (consider a Rails app with all of its prerequisite Gems). Granted, this isn't Docker's problem, but it presents practical distribution bandwidth constraints that Docker doesn't currently solve well.

Not every server runs the same applications, we mostly do deploys on 5-6 servers at a time, it takes around 3 minutes to deploy our biggest apps, most of them deploy in under 30 seconds.

600 MiB? That more than a complete OS install. Isn't an image supposed to be one application only? Do you store data in them, or why are they so big?

Not sure about sharing port numbers - you can do something like:

  docker -d -p 80:8000 repo/container

isn't this good enough? Can you give more detailed example?

How does that help? All this does is establish a local PAT; you can still only bind one application to port 80 on on the host. If you have more than one service that needs to listen to port 80 and be reached by clients, you're still out of luck.

This is a pretty easy solve...haproxy + consul + consul-template allows you to spin up a new container, register it with consul and have the consul-template watcher regenerate the haproxy config to route to the new port.

It's a little overkill if you're running it on a single machine, but in a real production environment, it's a pretty lightweight solution.

Easy in theory, but in practice, you have to configure and monitor it all. Adding components and orchestration logic is not cost-free.

Well it's not so hard. If there is good document steps for it. It's really abut getting consul working right.