Network information in service templates + templates for command parameter

[Jc2k]

Right now docker service create supports text/template templates on a handful of parameters. It would be great if more arguments could be templated, and if more service data was available to the templates. I assume these also work from the API and from docker stack deploy.

So my general problem. Lets say I have a service on 2 networks. It has its own clustering support built in and I need to advertise one of my 2 networks to other nodes in the cluster. I can't leave it to the service to choose, and the service can't handle DNS for this.

  thanos-sidecar:
    image: improbable/thanos:v0.1.0-rc.2
    command:
      - "sidecar"
      - "--prometheus.url=http://prometheus:9090"
      - "--cluster.peers=thanos:10900"
      - "--cluster.advertise-address=my_address_on_thanos:10900"
      - "--grpc-advertise-address=my_address_on_thanos:10901"
    networks:
      - internal
      - thanos

What i'd like to do is something like this:

  thanos-sidecar:
    image: improbable/thanos:v0.1.0-rc.2
    command:
      - "sidecar"
      - "--prometheus.url=http://prometheus:9090"
      - "--cluster.peers=thanos:10900"
      - "--cluster.advertise-address={{.Networks.thanos.IP}}:10900"
      - "--grpc-advertise-address={{.Networks.thanos.IP}}:10901"
    networks:
      - internal
      - thanos

I think this could be very useful for many clustering services. E.g. elasticsearch has network.publish_host.

Right now I think I can work around this with shell foo (e.g. dig before execing underlying service) or by manually configuring ip addresses. I think it would be much cleaner (frankly both work arounds I am about to try are grim) to be able to do it with service templates.

[ieugen]

Hi,

This would be very nice to have. I asked for this on slack: https://dockercommunity.slack.com/archives/C24JP46TE/p1692628670074129 .

hi, is there a way to inject the swarm service IP or container IP as an environment variable ?
Context:
We have a service that does not properly handle multiple network interfces / interface binding milvus-io/milvus#17191 .
One solution that I thought of is to configure the app to always bind to service ip.
But it seems that I can't find a way to handle it.
In kubernetes, this feature is handled by default - ip address and other info are published as env vars : https://kubernetes.io/docs/tutorials/services/connect-applications-service/#accessing-the-service .

I got a reply with a solution involving some bash commands but it comes with a cost.

services:
  my-service:
    image: alpine
    environment:
      IFACE: eth0
    command:
    - /bin/sh
    - -c
    - |
      export IF_IP=$(ip -o -4 addr list $IFACE | awk '{print $4}' | cut -d/ -f1)
      exec "previous command"

thanks for this. it is an option but IMO requires quite the extra work to do (a custom image for example with bash and ip command (extra packages) + the script you mentioned ).
I think the information is available on the swarm scheduler - and could be made available as template same as these others: https://docs.docker.com/engine/swarm/services/#create-services-using-templates

swarm template variables do not have access to this. It would be nice. Perhaps a feature request to moby/moby. I’d +1 it. given your reasons, plus the fact that “eth0” is not necessarily going to be assigned to the first docker network, I am very much in favour of .Task.{Network}.IP becomming available somehow.

[ieugen]

Another comment on slack that is relevant:

Antonio A
Over the years theres been a lot of feature requests for enhanced task metadata availability within containers that would be well-served by something like a metadata api endpoint. Dumping metadata into env vars would be an easier/faster way to go about it. There’s been a lot of times I wished I could read the task definition json from inside a container

[ieugen]

There’s been a lot of times I wished I could read the task definition json from inside a container .

Perhaps one way to have this is to have the data mounted inside the container as a file ?!