Announcing your app from within a container (docker)

Question

I asked this question at docker's IRC over the weekend but had to head off before I'd thought through the answers:

If I have a number of applications running in containers (let's, for the moment, assume they're all running on the same physical hardware, but that needn't be the case) and I want each of them to be able to find each other automatically.

Using some sort of registry (eg. etcd or DNS-SD/Bonjour) you could announce your service and any pertinent details and have the other applications find out about them and route traffic accordingly.

The problem here is that while an application can know which hostname/port it is serving on within a container, this needn't be the port or address it's accessible from. There are two bits of information which need to be joined up:

• Where the service can be accessed; accessible from outside the container
• What the service does (version number, type of service); accessible from inside the container

How would you recommend I get this information across the container barrier?

1. I could expose docker over TCP to the containers, so an app can query where its showing, but this seems to violate the separation of concerns.
2. I could have a file/port open in my container which the host system queries after a container is started in to prepare for an announce, but this feels a bit like I'd be reinventing the WSDL.

Any thoughts or guidance as to how I should solve this problem?

Phile

Answer 1

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.

Pleading

This is what I was trying (poorly) to explain in the point I've now numbered "2". If I wait until after the container is launched I can have the host system do the registration, but then I have no unified way of determining what that container does. (Information like what kind of service(s) is/are held within the container and what versions they are wouldn't be easily obtainable). – Phile

@Phile Understood, it's a chicken and egg problem. I don't think there is any effective way around the problem. The application within the container should ideally be stateless, enabling it to be deployed multiple times. Each instance of that container has different port numbers, ultimately decided by the host system. I suppose docker is a tool to build PAAS systems, not a PAAS in itself. – Feeler

@Phile See link to maestro – Feeler

Answer 2

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.

Nicole

An example of such a controller would be OpenStack, which supports Docker, and can programmatically assign IPs to Docker containers. – Gyrostatics