I was working locally with some containers running over docker-compose. Everything was OK, except I could not access a specific service within our network. Here is the issue: docker by default assigns IP addresses to containers from the 172.17.0.0/16 pool and docker-compose from 172.18.0.0/16. It just so happened that what I needed to access lived on 172.18.0.0/16 space. So what to do to overcome the nuisance? Obviously you cannot renumber a whole network for some temporary IP overlapping. Let’s abuse reserved IP space instead. Here is the relevant part of my daemon.json now:
{
"default-address-pools": [
{ "base": "192.0.2.0/24", "size": 28 },
{ "base": "198.51.100.0/24", "size": 28 },
{ "base": "203.0.113.0/24", "size": 28 }
]
}
According to RFC5737 are reserved for documentation purposes. I’d say local work is close enough to documentation to warrant the abuse, since we also adhere to its operational implications. Plus I wager that most of the people while they always remember classic RFC1918 addresses, seldom take into account TEST-NET-1 and friends.
Managing organized complexity 
Does it work if you use a fixed subnet for your compose network?
Example from a docker-compose in production:
“`
version: ‘3.5’
networks:
web-network:
ipam:
driver: default
config:
– subnet: “172.18.131.0/24”
“`
I never configure networks on `docker-compose.yml`. It becomes too cumbersome for others. But thank you for the suggestion.