I think perhaps the approach to perform the registration of the service after launching the container. Other containers can then perform a registry lookup to discover these services.

Update

The maestro project gives an example of how the containers are configured externally and then launched to setup a cooperating network of containers.

I've had trouble with this too. I believe the mistake in your thinking is that the container itself is the only one knowing what it does.

Containers are not self-aware entities that are serving MySQL today, and decide to become a queue processor tomorrow.

Instead, there is a controller (which may just be an automated system, or you on the command line), and that controller knows that a particular app should run, that to run this app, a certain set of services is needed, and that is why a containers is started in the first place.

The controller knows that a MySQL service is needed, and that a MySQL service represents a single host:port to connect to. If the case, it may also know that a service is made up of two or three ports.

It is therefore architecturally correct for the host/controller to either tell the container with which address to register, or to ask it which local port it is serving on (or more likely, to know the port based on the container definition).

In practice, the host may tell the container "run your service on the LAN interface on this specific port and I'll register it", "run your service yourself on any port on this LAN interface and register it yourself" or "run your service on this port and register it with host:port and I'll setup mappings to make sure it is available there".

All of these would architecturally be fine: In the end, it is always the host/controller deciding, because it is really the only one to both know what services run and where they are accessible.

I find that a practical problem with this in docker is tha container IPs and host mapped ports are assigned dynamically in such a way that you can't really get either information until after the container runs; which is why Flynn picks the host port mappings itself rather than let docker automatically do it.

I've written up some of my thoughts on this.