docker stack deploy ignores network name in compose file

Description

I would like to explicitly name the networks created when deploying a stack on Docker's Swarm Mode, by using the corresponding syntax introduced in Compose file 3.5.

docker stack deploy seems to ignore this though and creates the network with the default name.

Definitely not crucial, but it would be a good-to-have.

Steps to reproduce the issue:

Create a Compose file using the name top-level network parameter introduced in Compose file 3.5 (example file)
Deploy using docker stack deploy -c docker-compose.yml stack-name

Describe the results you received:

paris@ceryx-staging:/opt/ceryx$ docker stack deploy -c docker-compose.yml ceryx
Creating network ceryx_default  # ← **NOT EXPEXTED**
Creating service ceryx_ceryx
Creating service ceryx_api
Creating service ceryx_redis

Describe the results you expected:

paris@ceryx-staging:/opt/ceryx$ docker stack deploy -c docker-compose.yml ceryx
Creating network ceryx  # ← **EXPEXTED**
Creating service ceryx_ceryx
Creating service ceryx_api
Creating service ceryx_redis

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker version:

Client:
 Version:	18.03.0-ce
 API version:	1.37
 Go version:	go1.9.4
 Git commit:	0520e24
 Built:	Wed Mar 21 23:10:01 2018
 OS/Arch:	linux/amd64
 Experimental:	false
 Orchestrator:	swarm

Server:
 Engine:
  Version:	18.03.0-ce
  API version:	1.37 (minimum version 1.12)
  Go version:	go1.9.4
  Git commit:	0520e24
  Built:	Wed Mar 21 23:08:31 2018
  OS/Arch:	linux/amd64
  Experimental:	false

Output of docker info:

Containers: 3
 Running: 3
 Paused: 0
 Stopped: 0
Images: 90
Server Version: 18.03.0-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: active
 NodeID: 3o1e616nds6qyq70y8aw8cxdw
 Is Manager: true
 ClusterID: h6q4x6d8qy7vvdx3xr9chrw3z
 Managers: 1
 Nodes: 1
 Orchestration:
  Task History Retention Limit: 5
 Raft:
  Snapshot Interval: 10000
  Number of Old Snapshots to Retain: 0
  Heartbeat Tick: 1
  Election Tick: 3
 Dispatcher:
  Heartbeat Period: 5 seconds
 CA Configuration:
  Expiry Duration: 3 months
  Force Rotate: 0
 Autolock Managers: false
 Root Rotation In Progress: false
 Node Address: 172.16.2.4
 Manager Addresses:
  172.16.2.4:2377
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: cfd04396dc68220d1cecbe686a6cc3aa5ce3667c
runc version: 4fc53a81fb7c994640722ac585fa9ca548971871
init version: 949e6fa
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.4.0-98-generic
Operating System: Ubuntu 16.04.3 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 6.795GiB
Name: sl-nbg-staging
ID: 4SGU:KRFP:OJ4L:5O57:L34G:M7AJ:4QM5:EK6F:DDZS:B2XQ:WIAW:PZGU
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

WARNING: No swap limit support

Additional environment details (AWS, VirtualBox, physical, etc.):

Running on an Azure Ubuntu machine, installed via apt-get.

@parisk

@parisk thx for the issue report. It should be fixed by #941. Sadly, I think it's only be available in 18.04 and later.

cc @thaJeztah

Indeed. Thanks for the heads up. Closing this, since there is no further action needed to be taken from now on.

I'm running 18.09.1 and this seems to be an issue still or am I doing something incorrectly?

I'm getting app-name_default even though I did not specify any networks in my compose file. I expected default in my docker network list.

@ademeglio

@ademeglio that's expected; when deploying a stack, the services are connected to a default network for that stack. The network that's created is prefixed with the stack name, so that it doesn't conflict with other "default" networks

@thaJeztah

@thaJeztah OK, thank you. I think it is a user error mistake on my part then ;-) I did not see adding adding a network name within the network call in part 5 of the tutorial. I'm going to try that now.
-- update
That was the trick. For anyone else that comes across this post...

services:
  yourService:
    image: yourImage
    ...
    networks:
      - yourNetworkName
networks:
  yourNetworkName:
    name: yourNetworkName

If you don't want to set the network for each service, I think you can also set the name for the stack's default network;

services:
  yourService:
    image: yourImage
    ...
networks:
  default:
    name: yourNetworkName

@thaJeztah

@thaJeztah
The challenge I am having is that I still can't access the service in the swarm if I go to the ip address on my browser. Server is running in our internal network. If I start the app up as a container I can. So I must be missing something. I'm using Deploy Stack. Should I be adding net: host to my networks?

The service must publish a port to be accessible; after that it should be available at <ip-address of host>:<port>. The network you specify is only used for inter-container communication (communication between services)

So, you had me thinking and this morning I went back to the tutorial and I was able to create a service and connect just fine from the browser. I redeployed the application I'm using to test my CI/CD process and as a stack, even though the service shows the port exposed the same as the lone service, will not connect. So there must be something I'm doing incorrectly when doing docker stack deploy.

OK, now I'm confused. Here is the output of the service after performing a service ls and then a service inspect.

ID                  NAME                MODE                REPLICAS            IMAGE                                                                                                           PORTS
0mievozkd2vm        r2es-test_r2es      replicated          1/1                 vml-repo-code.barthavisual.local:5005/ademeglio/r2-event-sync/review:c9b556143995c72a3953004ae582cf270de268c2   *:80->80/tcp

[deployAgent@VML-App-Test ~]$ docker service inspect r2es-test_r2es --pretty

ID:             0mievozkd2vm9mc3hbgy5yvr0
Name:           r2es-test_r2es
Labels:
 com.docker.stack.image=vml-repo-code.barthavisual.local:5005/ademeglio/r2-event-sync/review:c9b556143995c72a3953004ae582cf270de268c2
 com.docker.stack.namespace=r2es-test
Service Mode:   Replicated
 Replicas:      1
Placement:
UpdateConfig:
 Parallelism:   1
 On failure:    pause
 Monitoring Period: 5s
 Max failure ratio: 0
 Update order:      stop-first
RollbackConfig:
 Parallelism:   1
 On failure:    pause
 Monitoring Period: 5s
 Max failure ratio: 0
 Rollback order:    stop-first
ContainerSpec:
 Image:         vml-repo-code.barthavisual.local:5005/ademeglio/r2-event-sync/review:c9b556143995c72a3953004ae582cf270de268c2@sha256:7b5dd0317c95e0ac3a25bafb9eebf16cbcdcecacc3613457a953ba9beb957724
Resources:
Networks: bavlocal
Endpoint Mode:  vip
Ports:
 PublishedPort = 80
  Protocol = tcp
  TargetPort = 80
  PublishMode = ingress

Then I ran docker service update --publish-add published=80,target=80 r2es-test_r2es

ID                  NAME                MODE                REPLICAS            IMAGE                                                                                                           PORTS
0mievozkd2vm        r2es-test_r2es      replicated          1/1                 vml-repo-code.barthavisual.local:5005/ademeglio/r2-event-sync/review:c9b556143995c72a3953004ae582cf270de268c2   *:80->80/tcp

ID:             0mievozkd2vm9mc3hbgy5yvr0
Name:           r2es-test_r2es
Labels:
 com.docker.stack.image=vml-repo-code.barthavisual.local:5005/ademeglio/r2-event-sync/review:c9b556143995c72a3953004ae582cf270de268c2
 com.docker.stack.namespace=r2es-test
Service Mode:   Replicated
 Replicas:      1
Placement:
UpdateConfig:
 Parallelism:   1
 On failure:    pause
 Monitoring Period: 5s
 Max failure ratio: 0
 Update order:      stop-first
RollbackConfig:
 Parallelism:   1
 On failure:    pause
 Monitoring Period: 5s
 Max failure ratio: 0
 Rollback order:    stop-first
ContainerSpec:
 Image:         vml-repo-code.barthavisual.local:5005/ademeglio/r2-event-sync/review:c9b556143995c72a3953004ae582cf270de268c2@sha256:7b5dd0317c95e0ac3a25bafb9eebf16cbcdcecacc3613457a953ba9beb957724
Resources:
Networks: bavlocal
Endpoint Mode:  vip
Ports:
 PublishedPort = 80
  Protocol = tcp
  TargetPort = 80
  PublishMode = ingress

I don't see any difference between the two, but I was able to access the app without any other changes. Would that be an issue with stack deploy not acting on the publish lines of the docker-compose file?

@thaJeztah

So, I'm not sure what I changed, but after redeploying again, it works as expected. @thaJeztah I appreciate your help and insight, Cheers, Anthony

Navigation Menu

Repository navigation

docker stack deploy ignores network name in compose file #971

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

docker stack deploy ignores network name in compose file #971

Description

Activity

vdemeester commented on Mar 27, 2018

parisk commented on Mar 27, 2018

ademeglio commented on Jan 10, 2019

thaJeztah commented on Jan 10, 2019

ademeglio commented on Jan 10, 2019

thaJeztah commented on Jan 10, 2019

ademeglio commented on Jan 10, 2019

thaJeztah commented on Jan 10, 2019

ademeglio commented on Jan 11, 2019

ademeglio commented on Jan 11, 2019

ademeglio commented on Jan 11, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions