container network aliases fail with docker 1.13

[james-nesbitt]

When using the following components in my compose yml file:

  ####
  # FPM node
  #
  # @NOTE in production, the source volumes should be source:ro
  #  but local devs may need to write to settings.php

  fpm:
    image: quay.io/wunder/fuzzy-alpine-php-dev
    volumes:
      - "./drupal/current/web:/app/web"
      - "./drupal/current/vendor:/app/vendor"
      - "./drupal/sync:/app/config"
      - "./drupal/code/modules/custom:/app/web/modules/custom"
      - "./drupal/code/themes/custom:/app/web/themes/custom"
      - "assets-public:/app/web/sites/default/files"
     networks:
      default:
        aliases:
          - fpm  
    links:
      - "db:db"
      - "memcache:memcache"

  ####
  # WWW node
  #
  www:
    image: quay.io/wunder/fuzzy-alpine-nginx-pagespeed-drupal
    volumes:
      - "./drupal/current/web:/app/web"
      - "./drupal/current/vendor:/app/vendor"
      - "./drupal/sync:/app/config"
      - "./drupal/code/modules/custom:/app/web/modules/custom"
      - "./drupal/code/themes/custom:/app/web/themes/custom"
      - "assets-public:/app/web/sites/default/files"
    ports:
      - 80:80
    links:
      - "fpm:fpm"

The nginx server is unable to see the fpm server:

[www_1]-->2017/02/21 14:31:14 [emerg] 1#0: host not found in upstream "fpm:9000" in /etc/nginx/conf.d/nginx_upstream.conf:11

When execing a shell in the containers, I find that they are truly unable to see each other using service name. They can of course see each other when using the particular container name.

When using the python docker-compose this orchestration produces containers that can see each other.

I discovered the following network differences in the two implementations when I inspect the containers:

Here is the network inspect for docker-compose:

                "weqwe_default": {
                    "IPAMConfig": null,
                    "Links": [
                        "weqwe_db_1:db.app",
                        "weqwe_db_1:db_1",
                        "weqwe_db_1:weqwe_db_1",
                        "weqwe_memcache_1:memcache.app",
                        "weqwe_memcache_1:memcache_1",
                        "weqwe_memcache_1:weqwe_memcache_1"
                    ],
                    "Aliases": [
                        "fpm",
                        "69ee22e4f5ad"
                    ],
                    "NetworkID": "ca2d78c64a8c7b86e0b1d0bdd1b2900231361741bf9694b9c384d11cc073cfca",
                    "EndpointID": "",
                    "Gateway": "",
                    "IPAddress": "",
                    "IPPrefixLen": 0,
                    "IPv6Gateway": "",
                    "GlobalIPv6Address": "",
                    "GlobalIPv6PrefixLen": 0,
                    "MacAddress": ""
                }

And here it is for libcompose:

                "weqwe_default": {
                    "IPAMConfig": null,
                    "Links": null,
                    "Aliases": [
                        "404d4b24bab7"
                    ],
                    "NetworkID": "00bc3ca3de034fb125c29c188a120fb4ecb08da668620e929245301ed4e79b94",
                    "EndpointID": "",
                    "Gateway": "",
                    "IPAddress": "",
                    "IPPrefixLen": 0,
                    "IPv6Gateway": "",
                    "GlobalIPv6Address": "",
                    "GlobalIPv6PrefixLen": 0,
                    "MacAddress": ""
                }

The is the current status.

Now according to recent docker documentation, the whole --links thing is out of fashion, and we should be using internal networking instead. And any container on the same network, is supposed to see other containers. This works, but docker-compose uses service names. We cannot utilize full container name without bringing the project name into the service definition.

Questions:

1. Should we not expect libcompose to set up the network aliases needed to make communication between services possible?
2. If not, can we expect libcompose to allow the service network definition of alias?

** I understand the following: **

1. that direct conversion of a service to a container name is a difficult task in the scope of a scalable node, but it is not by any means impossible;
2. --link is outdated and can be removed (I tested without them to make sure that wasn't breaking stuff)
3. the current libcompose does not honour the network aliases option (I tested without it)

[james-nesbitt]

I meant to clarify, that this is a new issue for our code, that only appeared with docker 1.13. This occurred both with and without swarm mode.

[james-nesbitt]

To elaborate on the core logical issue about container aliases in scale-able environments:

If you have multiple containers for a scaled service in one node, then to which container should a dependent container be linked, and how. In the docker layer, we of course have the containers named sequentially project_service_X but the built image for the dependending server will want to use URI service.

It is impossible using network aliases to provide a mechanism where project_service_1 is seen as service in project_depending_1, but not in project_depending_2. Therefore there is a fundamental failure of the attempt give give scaling services in nodes without having services do their own discovery.

The successful application would be to scale nodes, instead of services.

I believe that this should not block libcompose from implementing the non-scale-able aliasing in libcompose, as no alternative is provided at this time. This would maintain the API of the previous version.