Differences

This shows you the differences between two versions of the page.

--- wiki:public:docker_default_networks [2018/09/27 05:06] – jrdalrymple
+++ wiki:public:docker_default_networks [2018/09/27 05:11] (current) – jrdalrymple
@@ Line 1: / Line 1: @@
+========= docker-compose Routing Holes =========
+===== The disappearance of traffic destined for 172.18.0.0/16: =====
 In using docker compose to modernize some of my apps (including this wiki) I discovered some network awkwardness. The first problem I experienced was when I was setting up a new Wordpress, using the following docker-compose.yml:
@@ Line 40: / Line 46: @@
 }
 </file>
-After restarting the docker daemon I still had to //down// and //up// my Wordpress to get the reconfigured network to function properly. This took me directly into my next problem. Wordpress came up and there were no ugly log entries, however I still couldn't get to the app. The behavior was strikingly similar to the last problem... just nothing. I could see the requests in the log, but I was very clearly not getting replies to my browser. A quick look at the new network created ''docker network inspect wp1_default'' (not the docker0 network, but the Wordpress/MySQL network) illustrated my new issue; this network's subnet also overlapped with other local subnets in my environment.
+After restarting the docker daemon I still had to //down// and //up// my Wordpress to get the reconfigured network to function properly.
+===== The disappearance of traffic destined for 172.17.0.0/16: =====
+Moving past the last problem took me directly into my next problem. Wordpress came up and there were no ugly log entries, however I still couldn't get to the app. The behavior was strikingly similar to the last problem... just nothing. I could see the requests in the log, but I was very clearly not getting replies to my browser. A quick look at the new network created ''docker network inspect wp1_default'' (not the docker0 network, but the Wordpress/MySQL network) illustrated my new issue; this network's subnet also overlapped with other local subnets in my environment. This time the network in question was 172.17.0.0/16, a segment that I parse up into multiple /24 subnets in my server environment for various reasons.
 So the problem is the same, but in this case the place to fix it is different. Moreover it seems this is something of a "docker-compose" default and I was unable to identify where I would be able to change that behavior. As such each app spun up on my network will require changes similar to the following:
@@ Line 87: / Line 97: @@
       - subnet: 10.255.254.0/24
 </file>
+Again, after this process I had to //down// and //up//, but directly afterwards all my life was good.