Should docker_containers argument be extended to also include ports

Currently docker_containers is a map between key and address of the container. The idea was that a container will run at some IP address and then primitive can connect to it. Because container is made together with the primitive, primitive can know which port the container is using to communicate.

But when running in Docker-in-Docker mode, this is not really true. Primitive cannot directly connect to containers because containers are running in a different network. What you can do is expose port from the container to the Docker-in-Docker host and then connect to that which is then proxied into a second network. But on which port on host a container port is exposed on? What if two containers are using the same port internally, we cannot just expose them on the same port on host, it would not work.

So we might have to extend docker_containers to also include how ports were mapped, if mapping is necessary.

Or, we do nothing. It is unclear when would we run Docker-in-Docker primitive containers. You can also just run them outside of the container for all primitives and this is it. Docker-in-Docker is useful when you want internal Docker container to control lifetime of those containers, but is this really common? Currently, this is used only during testing.