Vous vous demandez comment définir le nom d'hôte dans Docker Compose ? Je vais vous montrer ça.
Vous pouvez le définir sous le service comme ceci :
...
letsencrypt:
image: jrcs/letsencrypt-nginx-proxy-companion
hostname: ledocker
...Mais en avez-vous vraiment besoin ? L'objectif général du nom d'hôte est que les ordinateurs du réseau se connaissent et communiquent ainsi entre eux.
De même, l'objectif principal ici est de s'assurer que les conteneurs peuvent communiquer entre eux avec succès au sein d'un réseau Docker.
Je vais discuter de deux manières de rendre cela possible :
Méthode 1 :Communication non explicite
Au sein d'un réseau Docker, les noms de service définis dans un fichier Docker Compose peuvent être utilisés pour tester si les conteneurs peuvent communiquer entre eux.
Prenons par exemple la configuration de proxy inverse suivante :
version: '3.7'
services:
nginx-proxy:
image: jwilder/nginx-proxy
ports:
- "80:80"
- "443:443"
volumes:
- ./html:/usr/share/nginx/html
- ./dhparam:/etc/nginx/dhparam
- ./vhost:/etc/nginx/vhost.d
- ./certs:/etc/nginx/certs:ro
- /var/run/docker.sock:/tmp/docker.sock:ro
- ./client_max_upload_size.conf:/etc/nginx/conf.d/client_max_upload_size.conf
labels:
- "com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy"
restart: always
networks:
- net
letsencrypt:
image: jrcs/letsencrypt-nginx-proxy-companion
env_file:
- ./letsencrypt.env
depends_on:
- nginx-proxy
volumes:
- ./certs:/etc/nginx/certs:rw
- ./vhost:/etc/nginx/vhost.d
- ./html:/usr/share/nginx/html
- /var/run/docker.sock:/var/run/docker.sock:ro
restart: always
networks:
- net
networks:
net:
external: true
Notez que les deux noms de service sont nginx-proxy et letsencrypt . Vous pouvez utiliser ces noms pour tester si les conteneurs peuvent communiquer entre eux ou non. Cela peut s'avérer très utile lors de situations de dépannage.
Tout d'abord, installez ping dans le conteneur Nginx Reverse Proxy :
[email protected]:~/nginx-proxy$ docker-compose exec nginx-proxy bash -c "apt update && apt install -y iputils-ping"
Maintenant, vous pouvez utiliser la commande ping à l'intérieur de ce conteneur pour vérifier s'il peut communiquer avec le conteneur Let's Encrypt (utilisé pour SSL).
[email protected]:~/nginx-proxy$ sudo docker-compose exec nginx-proxy ping letsencrypt
PING letsencrypt (172.18.0.3) 56(84) bytes of data.
64 bytes from nginx-proxy_letsencrypt_1.net (172.18.0.3): icmp_seq=1 ttl=64 time=0.066 ms
64 bytes from nginx-proxy_letsencrypt_1.net (172.18.0.3): icmp_seq=2 ttl=64 time=0.057 ms
^C
--- letsencrypt ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 37ms
Comme vous pouvez le voir ci-dessus, le conteneur de proxy inverse "voit" le deuxième conteneur SSL qui renvoie une réponse ! Dans nginx-proxy_letsencrypt_1.net , nginx-proxy_letsencrypt_1 est le nom du conteneur SSL et net est notre réseau personnalisé.
Vérifions-le rapidement :
[email protected]:~/nginx-proxy$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a9ef56e22f58 jrcs/letsencrypt-nginx-proxy-companion "/bin/bash /app/entr…" 7 minutes ago Up 7 minutes nginx-proxy_letsencrypt_1
563133f5d039 jwilder/nginx-proxy "/app/docker-entrypo…" 7 minutes ago Up 7 minutes nginx-proxy_nginx-proxy_1
Pour vérifier le réseau, vous pouvez utiliser le docker network ls commande.
[email protected]:~/nginx-proxy$ sudo docker network ls
NETWORK ID NAME DRIVER SCOPE
018c50dc4fdc bridge bridge local
27fd2370e735 net bridge local
38ce8d11227b host host local
2440210d0fc5 none null local
Méthode 2 :Communication explicite
Supposons que, pour une raison quelconque, vous souhaitiez spécifier explicitement un nom d'hôte à un conteneur. Docker Compose vous permet de faire cela aussi !
Utilisation du hostname option de configuration, vous pouvez définir un nom d'hôte différent pour tout service défini dans un fichier Docker Compose, comme je l'ai fait pour le service Let's Encrypt ci-dessous :
version: '3.7'
services:
nginx-proxy:
image: jwilder/nginx-proxy
ports:
- "80:80"
- "443:443"
volumes:
- ./html:/usr/share/nginx/html
- ./dhparam:/etc/nginx/dhparam
- ./vhost:/etc/nginx/vhost.d
- ./certs:/etc/nginx/certs:ro
- /var/run/docker.sock:/tmp/docker.sock:ro
- ./client_max_upload_size.conf:/etc/nginx/conf.d/client_max_upload_size.conf
labels:
- "com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy"
restart: always
networks:
- net
letsencrypt:
image: jrcs/letsencrypt-nginx-proxy-companion
hostname: ledocker
env_file:
- ./letsencrypt.env
depends_on:
- nginx-proxy
volumes:
- ./certs:/etc/nginx/certs:rw
- ./vhost:/etc/nginx/vhost.d
- ./html:/usr/share/nginx/html
- /var/run/docker.sock:/var/run/docker.sock:ro
restart: always
networks:
- net
networks:
net:
external: true
Ici, notez que j'ai explicitement ajouté hostname: ledocker dans la définition du service Let's Encrypt. Je veux utiliser ledocker comme nom d'hôte pour le conteneur SSL.
Mais attendez, pouvons-nous revérifier en utilisant la commande ping ?
[email protected]:~/nextcloud$ sudo docker-compose exec nginx-proxy ping ledocker
PING ledocker (172.18.0.3) 56(84) bytes of data.
64 bytes from nginx-proxy_nginx-proxy_1.net (172.18.0.3): icmp_seq=1 ttl=64 time=0.034 ms
64 bytes from nginx-proxy_nginx-proxy_1.net (172.18.0.3): icmp_seq=2 ttl=64 time=0.079 ms
64 bytes from nginx-proxy_nginx-proxy_1.net (172.18.0.3): icmp_seq=3 ttl=64 time=0.061 ms
64 bytes from nginx-proxy_nginx-proxy_1.net (172.18.0.3): icmp_seq=4 ttl=64 time=0.093 ms
64 bytes from nginx-proxy_nginx-proxy_1.net (172.18.0.3): icmp_seq=5 ttl=64 time=0.078 ms
64 bytes from nginx-proxy_nginx-proxy_1.net (172.18.0.3): icmp_seq=6 ttl=64 time=0.075 ms
^C
--- ledocker ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 129ms
rtt min/avg/max/mdev = 0.034/0.070/0.093/0.018 ms
Oui en effet. Ça marche !
Envie de plus de connaissances à ce sujet ? Consultez ce fil GitHub extrêmement informatif.
J'espère que vous avez apprécié cette astuce rapide ! Vous pouvez laisser des questions, des doutes ou des suggestions dans la section des commentaires ci-dessous.