moby: Error response from daemon: rpc error: code = 9 desc = service needs ingress network, but no ingress network is present

Description

Port forwarding fails on docker service create with “Error response from daemon: rpc error: code = 9 desc = service needs ingress network, but no ingress network is present”

Steps to reproduce the issue: Facing this issue on 10 node docker swarm mode cluster. Not sure how to reproduce

Describe the results you received:

Error response from daemon: rpc error: code = 9 desc = service needs ingress network, but no ingress network is present screenshot from 2017-05-27 19 24 08

Describe the results you expected:

create service

Output of docker version:

Client:
 Version:      17.05.0-ce
 API version:  1.29
 Go version:   go1.7.5
 Git commit:   89658be
 Built:        Wed May 10 22:45:11 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.05.0-ce
 API version:  1.29 (minimum version 1.12)
 Go version:   go1.7.5
 Git commit:   89658be
 Built:        Wed May 10 22:45:11 2017
 OS/Arch:      linux/amd64
 Experimental: false

Output of docker info:

Containers: 7
 Running: 0
 Paused: 0
 Stopped: 7
Images: 6
Server Version: 17.05.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
Swarm: active
 NodeID: l0j7jl95mzzvrc7puwccyhuik
 Is Manager: true
 ClusterID: k1ww6j2k2nagulfphn93doa2v
 Managers: 4
 Nodes: 9
 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
 Node Address: 172.18.2.127
 Manager Addresses:
  172.18.2.127:2377
  172.18.2.133:2377
  172.18.2.139:2377
  172.18.2.147:2377
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 9048e5e50717ea4497b757314bad98ea3763c145
runc version: 9c2d8d184e5da67c95d601382adf14862e4f2228
init version: v0.13.2 (expected: 949e6facb77383876aeff8a6944dde66b3089574)
Security Options:
 seccomp
  Profile: default
 selinux
Kernel Version: 4.11.0-coreos
Operating System: Container Linux by CoreOS 1409.0.0 (Ladybug)
OSType: linux
Architecture: x86_64
CPUs: 3
Total Memory: 7.801GiB
Name: swarmd-1.igloo.vztelematics.in
ID: MPWK:IK7C:MQQJ:LBVI:M7AD:VPTO:6OGV:QTQ6:CZPP:PLCW:LJNJ:FHRR
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 registry.igloo.vztelematics.in:5000
 127.0.0.0/8
Live Restore Enabled: false

coreos 1409.0.0

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 2
Comments: 22 (6 by maintainers)

Most upvoted comments

Sounds like you’ve removed your ingress network. You can recreate it with docker network create --ingress --driver overlay ingress

+54

cpuguy83 on May 27, 2017

@thaJeztah can confirm your suspicion here, just ran into the same issue on my dev environment: installed a swarm in the past, upgraded Docker and ran docker system prune while the swarm was offline, brought the swarm back up and got this. docker network create --ingress --driver overlay ingress resolved the issue.

cabloo on Jun 17, 2017

Ok, I suspect what happened, is that this was a version of docker that was upgraded from an older version. Older versions marked “ingress” networks in a different way, and there was a bug in 17.05 which prevented docker from recognising such networks. As a result, docker network prune (or docker system prune) removed the ingress network if no container / service was attached to it.

That situation will be resolved in docker 17.06 (see https://github.com/moby/moby/pull/33286). If I’m correct, an ingress network created with docker 17.05 will not be removed by docker network prune, so if you would run docker network prune again, the network should not be removed.

I’ll go ahead and close this issue, because this will be addressed in docker 17.06, but feel free to continue the conversation 👍

thaJeztah on May 29, 2017

https://github.com/moby/moby/issues/31255 actually is an issue with docker 1.12.4. Note that Docker 17.03.0 is actually what 1.13.2 would have been, so no functional changes from 1.13.0, only bug fixes. For production, I’d recommend installing the “quarterly” releases, unless upgrading once a month is no problem for your situation. For longer support cycles, Docker EE provides 1 year of support (bug fixes and security fixes), so may be worth considering for production

thaJeztah on May 31, 2017

Can you provide information what breaks?

In 1.13, I faced issues with selinux https://github.com/moby/moby/issues/31255.
In 17.05-ce I faced above issue https://github.com/moby/moby/issues/33420.

Will try out 17.06. Hope we can use it in prod 😃

Thanks for the help.

adityacs on May 30, 2017

In any of the docker versions after 1.12 some thing will break.

Can you provide information what breaks?

Could you please let me know which is the most stable version for use in production for docker swarm mode?

The 17.03.x and 17.06.x (to be released soon), are “quarterly” releases, which have a 4-month support cycle for critical bug fixes (community edition), and are supported for 1 year (enterprise edition)

thaJeztah on May 30, 2017