Network aliases in multicontainer setting

Good day,

I am trying to setup a custom network infrastructure, as in the future we will want to have containers that are restricted in their connection to other containers.

I tried it basically as depicted in the docker compose in this thread:

Here is a part of my docker compose as an example

version: '2.1'

networks:
  x: {}
  y: {}

services:

  a:
    build: './a'
    privileged: 'true'
    restart: 'always'
    cpu_quota: '400000'
    cpuset: '2,3'
    mem_limit: '1024m'
    hostname: 'a'
    networks:
      x:
    expose:
      - '6379'

  b:
    build: './b'
    privileged: 'true'
    restart: 'always'
    cpu_quota: '100000'
    cpuset: '0,1'
    mem_limit: '256m'
    hostname: 'b'
    networks:
      x:
    expose:
      - '6379'
      - '6380'

Is what I tried, when running “balena inspect <numberStuff>_a” I can see in the bottom most section, that the network x has an alias entry of what seems to be a sha hash but no alias “a” as it has when using the default network. I can “ping a” from the container a itself, but not from another container, like b.

This is more than I got with what I would’ve expected to work in the first place, which is:

version: '2.1'

networks:
  x: {}
  y: {}

services:

  a:
    build: './a'
    privileged: 'true'
    restart: 'always'
    cpu_quota: '400000'
    cpuset: '2,3'
    mem_limit: '1024m'
    networks:
      x:
        aliases:
          - 'a'
    expose:
      - '6379'

  b:
    build: './b'
    privileged: 'true'
    restart: 'always'
    cpu_quota: '100000'
    cpuset: '0,1'
    mem_limit: '256m'
    networks:
      x:
        aliases:
          - 'b'
    expose:
      - '6379'
      - '6380'

In which case I can not even “ping a” from a itself. Pinging the SHA hash does work, but is of no use, as it changes frequently (on rebuild i presume)

Is this behaviour a bug? Should the aliases be added or should at least the containername be added as an alias per default, like in the case of the default network? Is there a way for me to work around this?

EDIT:
Also as additional info, when I push a version, that just adds the aliases to the networks in the docker compose, the containers do not restart, but instead just show as being on the new commit immediately.
In case this might give anyone a hint or something.
I just tried both hostname and aliases in the same dockerfile, but it results in the same behaviour as just using the hostname. Seems like the aliases don’t have any effect at all.

EDIT:
Self suggested workaround would be to parse the IP of each container from “ifconfig”'s eth0 interface and put it in a designated file on a shared volume, from which other containers can read it and connect to it, if they are on the same network. I would love a more elegant solution, remaining in the docker compose, though, if possible.

Thanks for your help and greetings,
Tarek

1 Like

Did no one try docker networking in multi container applications yet?

Hi @Tschebbischeff, it looks like aliases in the network field are not yet supported, but checking with the team about that.

@pcarranzav @CameronDiver do I read the supervisor code correctly, that the network aliases are not yet supported, i.e. this kind of compose file:

services:
  some-service:
    networks:
      some-network:
        aliases:
         - alias1
         - alias3
      other-network:
        aliases:
         - alias2

From the compose docs: https://docs.docker.com/compose/compose-file/compose-file-v2/#aliases

Looking at the source code, seems those might be covered by this TODO marking?

Alright, at least I know what’s going on then, thanks :ok_hand:


States only names are supported for the “networks” field, but I thought the top-level networks field was meant by that.

Maybe if it is easier to implement in a future version of the supervisor the name of the container could be a default alias, like it is for the default network?

As I read from the official docker docs, this should be the default behaviour anyway?

“Aliases (alternative hostnames) for this service on the network. Other containers on the same network can use either the service name or this alias to connect to one of the service’s containers.”

Is there a status or suggested workaround for this?

We are using multiple networks to work around the lack of `network_mode: “service:service_name”``

One container is on two networks (a custom network, and the default network)

We have to specify the default network in addition to our custom network, otherwise the container will not be on the default network. Since only the network name is supported in balena docker compose, the container does not get its regular alias (the service name) on the default network.

This is pretty significant blocker, as it means we cannot route to a container by the service name (or any alias) if it is on more than one network.

Hi @jotham,

There’s actually a PR in progress for this: https://github.com/balena-io/balena-supervisor/pull/933/files - we’ll be getting it merged soon, and then it will come out in an OS release. I can’t provide a precise ETA but hopefully we can get you unblocked soon!

Thanks so much @pcarranzav, that’s great news :smiley:

If there’s anything a user can do to help out, let me know

Hi @pcarranzav - I saw this was merged to balena-supervisor for 9.12.1 https://github.com/balena-io/balena-supervisor/blob/master/CHANGELOG.md#9121---2019-03-28

Is it possible for users to test this on balena devices yet?

i have updated balena os on a device with prod version of the os, and that only gets me to supervisor 9.11.1

Hi @jotham,
The supervisor version will be part of BalenaOS 2.32 but we do not yet have an ETA for that unfortunately.
Regards
Thomas

OK, thanks for the info. I’ll keep an eye our for 2.32