Differences

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

--- wiki:public:docker_default_networks [2018/09/27 04:43] – 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 30: / Line 36: @@
 </file>
-<file yaml docker-compose.yml>
+Being largely unchanged from the YAML provided on the [[https://hub.docker.com/_/wordpress/|Docker Hub page dedicated to the project]] I expected this to work, and it kind of did. The problem was as soon as I ran ''docker-compose up -d'' I lost my remote connection to the machine. I discovered the problem remarkably fast given the oddness of the issue. My local network in my home is on the subnet 172.18.0.0/24, which just happens to be the same subnet that gets built for the docker0 internal network. This means that after the docker daemon brought up that network, the host OS stopped using the default route to get to my home network. It should be noted that my home network has a routed VPN to the network where that host exists; if I was crossing the Internet without tunneling my network the problem wouldn't have occurred.
+The solution to this particular networking problem comes from modifying ''/etc/docker/daemon.json''. On my machine this file was empty before I made the change, which ultimately resulted in this:
+<file json daemon.json>
+{
+  "bip": "10.255.255.1/24",
+  "fixed-cidr": "10.255.255.0/25"
+}
+</file>
+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:
+<file yaml docker-compose.yml [highlight_lines_extra="6,7,8,9,22,23,24,25,36,37,38,39,40,41,42"]>
 version: '3.3'
@@ Line 74: / 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.