Keywords: Docker networks | overlay networks | Swarm scope
Abstract: This article delves into the core concepts of Docker network scopes, particularly the access restrictions of overlay networks in Swarm mode. By analyzing the root cause of the "Error response from daemon: network myapp not found" error, it explains why docker run commands cannot access Swarm-level networks and provides correct solutions. Combining multiple real-world cases, the article details the relationship between network scopes and container deployment levels, helping developers avoid common configuration mistakes.
Basic Concepts of Docker Network Scopes
In the Docker ecosystem, network scope is a critical yet often overlooked concept. Network scope defines the accessible range of a network, directly impacting communication capabilities between containers and services. Docker supports various network scopes, including local scope and Swarm scope, each corresponding to different use cases and limitations.
Overlay Networks and Swarm Scope
Overlay networks are a special type of Docker network designed for cross-host container communication. When creating an overlay network, its scope must be specified. If a network is created with Swarm scope, it means the network is only visible and usable at the Swarm cluster level. This design ensures consistency and security of network resources in distributed environments.
A common misconception is that all Docker networks can be accessed via the docker run command. In reality, the docker run command runs containers on a single node, operating at the local level. In contrast, Swarm-scoped networks are only visible to Swarm-level operations, such as services created via docker service create. This hierarchical isolation is the core reason behind the "network myapp not found" error.
Error Analysis and Solutions
When developers attempt to use the command sudo docker run --rm -it --name=test_cont --net=myapp ubuntu bash, if the myapp network is a Swarm-scoped overlay network, the Docker daemon returns an error because locally run containers cannot recognize Swarm-level network resources. This is not due to the network's absence but rather a mismatch in access permissions.
The correct solution is to use Swarm-level commands for container deployment. For example, creating a service via docker service create --network myapp, as services operate at the Swarm level and can correctly identify and use Swarm-scoped networks. This approach ensures consistency between network and deployment levels, preventing access errors.
Other Related Cases and Supplementary Measures
In some scenarios, abnormal network states may cause similar errors. For instance, after executing docker system prune, networks might enter an inconsistent state. In such cases, restarting the Docker daemon can clear invalid network caches, as shown in examples: running systemctl restart docker.service and recreating the network resolves the issue.
Additionally, when using docker-compose, forcing container recreation with docker-compose up --force-recreate can help refresh network connections, but note that this may not address root causes, especially for scope mismatches.
Practical Recommendations and Summary
To avoid the "network myapp not found" error, developers should clearly distinguish between local and Swarm-level operations. When creating networks, choose the appropriate scope based on use cases. If networks are needed in Swarm clusters, ensure deployment uses docker service commands. Regularly check network status with docker network ls to verify network existence and scope, aiding in quick problem diagnosis.
In summary, understanding Docker network scopes is key to efficiently using container technology. By correctly matching network scopes with deployment levels, common configuration errors can be avoided, enhancing application maintainability and stability.