Flexibility in docker container images

Following from my previous article.

Problem: in building a docker compose, like below, what happens when you change the container_name value?

services:
  container1:
    container_name: container1
    image: ...
  
  container2:
    container_name: containerA 
    image: ...
    
  container2A:
    container_name: containerA
    image: ...
    

If you jump into container1, and run curl -v http://containerA, which configuration will respond?

In this case, the answer is indeterminant.  There is not enough info in the docker compose to determine. Or another answer is, the container that is running.  

We use this feature quite often.  Take a scenario like support for keycloak which seems to have a major version release once a quarter.  As we have some time between the previously supported version and testing support for the newer version, we have to be able to test each scenario independently.  To do this, we start our test stack with a list of containers.  docker compose up container1 container2A will allow container1 to connect to “containerA” to be able to test our new version without having to change where container1 is looking.

For our DNS topic, it is the container name that determines the DNS entry.

Next question: how do you support ports in a simple scenario?