Re: Conclusion un peu hative

docker run -d --name apache repo/apache:latest
docker run -d --name jboss --link apache:apache repo/jboss:latest

Alors comme d'habitude, dans le cas simple, tout marche bien. Après quand tu veux construire tes propres conteneurs, tu vas lire la doc de Docker et euh :

--link=CONTAINER_NAME_or_ID:ALIAS — using this option as you run a container gives the new container's /etc/hosts an extra entry named ALIAS that points to the IP address of the container identified by CONTAINER_NAME_or_ID. This lets processes inside the new container connect to the hostname ALIAS without having to know its IP. The --link= option is discussed in more detail below, in the section Communication between containers. Because Docker may assign a different IP address to the linked containers on restart, Docker updates the ALIAS entry in the /etc/hosts file of the recipient containers.

Et puis :

Whether two containers can communicate is governed, at the operating system level, by two factors.

Does the network topology even connect the containers' network interfaces? By default Docker will attach all containers to a single docker0 bridge, providing a path for packets to travel between them. See the later sections of this document for other possible topologies.

Do your iptables allow this particular connection? Docker will never make changes to your system iptables rules if you set --iptables=false when the daemon starts. Otherwise the Docker server will add a default rule to the FORWARD chain with a blanket ACCEPT policy if you retain the default --icc=true, or else will set the policy to DROP if --icc=false.

It is a strategic question whether to leave --icc=true or change it to --icc=false (on Ubuntu, by editing the DOCKER_OPTS variable in /etc/default/docker and restarting the Docker server) so that iptables will protect other containers — and the main host — from having arbitrary ports probed or accessed by a container that gets compromised.

If you choose the most secure setting of --icc=false, then how can containers communicate in those cases where you want them to provide each other services?

The answer is the --link=CONTAINER_NAME_or_ID:ALIAS option, which was mentioned in the previous section because of its effect upon name services. If the Docker daemon is running with both --icc=false and --iptables=true then, when it sees docker run invoked with the --link= option, the Docker server will insert a pair of iptables ACCEPT rules so that the new container can connect to the ports exposed by the other container — the ports that it mentioned in the EXPOSE lines of its Dockerfile. Docker has more documentation on this subject — see the linking Docker containers page for further details.

C'est compréhensible, mais faut pas que ça merdouille (et forcément, chez moi ça a merdouillé). Et bien sur, tout ça marche plus si la base de données et le site sont pas sur le même hote (on s'en serait douté mais...).

Mais pour un truc faire censé tourner mes conteneurs « anywhere », on y est pas encore (et d'ailleurs, c'est un problème complexe, mais Docker fait croire qu'il le résoud, ce qui n'est pas le cas).