26 Apr

Container names and docker-compose

You learn new things every day. Quite often by accident because something is not working as you expect or it just stopped working. This is one of those situations where I learned to be careful how to use container names using docker-compose and how containers refer to each other names. This is very important if they share the same network.

To perform some tests I created a lab where I run Ansible AWX (the free Ansible Tower version) and Netbox IPAM. I decided to use docker-compose because it gave me an easy way to manage the lab. By default, both AWX and Netbox is put in dedicated Network just for the containers of each installation. This means the isolation – the desired way you want to run containers. But in my lab, AWX need to talk to Netbox API to pull inventory. Because it is my lab I did the simplest thing.

Simple way with docker-compose

What would be the simplest solution? I hope you thought about the same approach as I did – putting all containers to share the same subnet. This way I don’t have to think about bridging or even about bigger things like Swarm. I created a new network on my local docker host

<br />
NETWORK ID NAME DRIVER SCOPE<br />
5a712ec0ca4f LAB bridge local<br />

Then I added this network to docker-compose.yml files of both AWX and Netbox projects – those files are provided by the developers and you download them from GitHub as part of the project. I just extended original files adding my newly created network

<br />
networks:<br />
    default:<br />
        external:<br />
            name: LAB<br />

Then I added the network definition to each container, here is an example from the Netbox project

<br />
postgres:<br />
    image: postgres:10.2-alpine<br />
    env_file: postgres.env<br />
    volumes:<br />
    - netbox-postgres-data:/var/lib/postgresql/data<br />
    networks:<br />
    - default<br />

Both projects consist of several containers. I start them with two docker-compose.yml files. Should work? Well, when both projects are running one of them cannot access its database. Hmmm, strange, isn’t it?

Problem with the names

After some investigation, I found that I was not aware that it is very important how I named containers in each project. In AWX I also had a container with an assigned name “postgres”

<br />
postgres:<br />
    image: postgres:9.6<br />
    restart: unless-stopped<br />
    volumes:<br />
    - /var/pgdocker:/var/lib/postgresql/data:Z<br />
    environment:<br />
    POSTGRES_USER: xxx<br />
    POSTGRES_PASSWORD: xxx<br />
    POSTGRES_DB: xxx<br />
    PGDATA: /var/lib/postgresql/data/pgdata<br />
    networks:<br />
    - default<br />

This is a different version of the Postgres database, but the container name is the same. So the first one started takes over the “postgres” name. Remember that you use names to refer to other containers in the same network, you do not use the IP addresses as those are assigned dynamically.

There are two simple solutions to such problem. If you list the running containers you can see that each of the postgres containers has a different name assigned

<br />
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES<br />
73f31411d94c postgres:9.6 &quot;docker-entrypoint...&quot; 2 weeks ago Up 28 minutes 5432/tcp awx_postgres_1<br />
d83747abc45e postgres:10.2-alpine &quot;docker-entrypoint...&quot; 2 weeks ago Up 28 minutes 5432/tcp netboxdocker_postgres_1<br />

So all I had to do is edit the configuration file so one of the apps uses not the “postgres” name but the assigned container name, like “awx_postgres_1”.

The second approach is similar but instead of changing only the configuration files of one of the apps you can change the name of the container in both projects and then change the names in configurations of both applications so it refers to its own database.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: