Using names instead of ips

[taliaga]

Hi,
I noticed some parts of the tutorial work with assumption on ips, specifically 127.18.x.x

In my case, ./service start would fail with the message ERROR: Pool overlaps with other one on this address space. The problem was that the subnet ip was overlapping with the one docker gave to the docker_gwbridge. This might happen to people that previously tested docker swarm.

For the records, I had to disable the docker swarm mode of my host (I was not using it) with docker swarm leave --force and then docker network prune to get the docker_gwbridge network deleted.

So, given that the tutorial seems to be using the same network, wouldn't it be a bit safer for example to use service names instead?

[jason-fox]

You could be right, but in the end it comes down to what is the purpose of the tutorial docker-compose files, which kind of fall between being as simple as possible, as educational as possible and as architecturally correct as possible. (and probably fail at all three at times)

If I remember correctly, a specific network was added once Keyrock was introduced to the tutorial set, specifically addressing the following parameters*:

      - "KEYROCK_URL=http://localhost"
      - "KEYROCK_IP_ADDRESS=http://172.18.1.5"

If a network isn't used then KEYROCK_IP_ADDRESS isn't an I.P. Address, it would be a DNS alias for an I.P address which isn't quite so obvious, so I explicitly map an I.P address and explicitly assign an I.P address to Keyrock. Thereafter any tutorial needing the IdM would have had a network added into it. (There is also the problem that the container name, hostname and drive mappings can get quite confusing within docker-compose)

At a minimum, I've recently added a disclaimer at the head of the docker-compose files - trying to justify some of the more dubious architectural decisions, but I'm thinking maybe the right answer to this is to add some sort of troubleshooting section into the Prerequisites guide. docker network prune isn't the only thing I've needed at times, I've also needed docker volume prune or docker system prune at times just to clear out the mess. The alternative would be to add more annotations to the docker compose, but I think we should only be annotating FIWARE parameters there.

As I said, I'm not quite sure what the right solution is here and I'm open to suggestions, so what do you think? Any good ideas?

---

Of course in any non-toy architectural system both KEYROCK_URL and KEYROCK_IP_ADDRESS could be a single URL of a real server - they only exist as separate params to get around OAuth2 forwarding when localhost has different meanings from my browser and the service running in the container.