3

Situation:

  1. docker swarm with 3+ nodes
  2. service running in the swarm with replicas=1 and restart=always
  3. swarm hosts have multiple interfaces - one for each vlan, with the same name
  4. service is deployed as a stack

I want to replace a service running in a VM on a static IP with the same one running docker, but I need to have the same SERVICE_IP on the ETH_SERVER interface.

What options do I have for one or more services to have static ips ?

A. added ipv4_address in docker stack yml - does not seem to be implemented in docker (at least not yet)

B. add a new host with reverse proxies to the docker stack services

C. use keepalived on the docker hosts and map SERVICE_IP - in this way if a host goes down the floating ip gets reassigned - but not sure if I could expose ports with FLOATING_SERVICE_IP:: ...

D. ... ?

Are there any "better" ways of doing this?


I tried doing this:

on each docker host:

docker network create --config-only --subnet="<CIDR>" --ip-range="<CIDR>" -o parent="INTERFACE" "vlan_name_intermediate"

and then a global network for the whole swarm

docker network create -d macvlan --scope swarm --config-from "vlan_name_intermediate" "vlan_name"

Now if I attach a service to network "vlan_name" i can ping it from inside that vlan, but the IP is randomly assigned, not static. I tried adding this to the compose yaml file:

ipv4_address: "192.168.45.56"

where the ip is inside the CIDR ip-range, but the setting is ignored

  • 1
    Why do you need a static ip ? That's the first point to address, addressing the rest if there's no imperious need for a static ip is a XY problem. – Tensibai Jun 4 '18 at 8:46
  • Multiple reasons: (1) legacy software that needs to talk to other legacy software set to specific ip+port via the licence file (and i need to move on service at a time and (2) network-wide services like dhcp / dns which are used via apis by other services in the network that connect via ip+port (no hostname option). – vlad b. Jun 4 '18 at 11:39
  • 1
    Then C is your only option (B is just adding another machine in place of the actual), but surely you shouldn't try to convert those services to containers in first place, you're heading toward a path full of pain twisting technologies for something they've not been built for and just adding a layer between your host and your app for not benefit at all. – Tensibai Jun 4 '18 at 12:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.