Comment et pourquoi utiliser un hôte Docker distant –
le docker
Le programme CLI est indépendant du démon Docker qui exécute vos conteneurs. Bien que les deux composants fonctionnent généralement sur votre ordinateur local, vous pouvez exécuter docker
commandes contre un hôte Docker distant.
L’utilisation d’un hôte distant peut être utile dans quelques scénarios. Vous pouvez configurer une installation Docker Engine partagée pour une petite équipe de développement. Chaque développeur pourrait alors se connecter aux conteneurs distants avec leur docker exec
commander.
Les hôtes distants sont souvent plus précieux lorsque vous avez un serveur puissant inutilisé. Si votre ordinateur portable est lent ou à court de stockage, l’utilisation d’un hôte Docker dédié sur votre réseau peut considérablement augmenter les performances. Vous bénéficiez toujours de toute la commodité du local docker
CLI dans votre terminal.
Sommaire
Configuration de l’hôte distant
Assurez-vous que Docker est installé sur le système qui sera votre hôte distant. Vous n’avez besoin que du docker-cli
package sur votre machine locale, car vous n’exécuterez pas Docker Engine.
Une nouvelle installation de Docker fournit un socket Unix par défaut. L’accès à distance nécessite une socket TCP. Cours dockerd
(l’exécutable du démon Docker) avec le -H
flag pour définir les sockets auxquels vous souhaitez vous lier.
sudo dockerd -H unix:///var/run/docker.sock -H tcp://0.0.0.0:2375
Cette commande liera Docker au socket Unix par défaut et au port 2375 sur l’adresse de bouclage de votre machine. Vous pouvez vous lier à des sockets et adresses IP supplémentaires en répétant le -H
drapeau.
Les drapeaux doivent être passés chaque fois que vous exécutez dockerd
. Si vous souhaitez qu’ils persistent après les redémarrages, créez un alias de shell ou modifiez la définition du service Docker. Voici comment vous pouvez réaliser ce dernier avec systemd
, que la plupart des distributions Linux utilisent pour la gestion des services.
Éditer /etc/systemd/system/docker.service.d/options.conf
(ou créez-le s’il n’existe pas). Trouvez le [Service]
section et modifiez le ExecStart
ligne:
[Service] ExecStart=/usr/bin/dockerd -H unix:///var/run/docker.sock -H tcp://0.0.0.0:2375
Rechargez votre systemd
configuration pour appliquer les modifications:
sudo systemctl daemon-reload
Si Docker est déjà en cours d’exécution, utilisez sudo systemctl restart docker
pour redémarrer le service. Le démon Docker se liera désormais au port TCP 2375 à chaque démarrage. Assurez-vous que le trafic vers le port est autorisé par la configuration de votre pare-feu. Si vous utilisez ufw, exécutez ufw allow 2375
pour ouvrir le port.
Connexion à l’hôte distant
L’interface de ligne de commande Docker utilise le DOCKER_HOST
variable d’environnement pour déterminer l’hôte auquel se connecter. La socket Unix du démon local sera utilisée lorsque la variable n’est pas définie.
Vous pouvez utiliser un hôte distant pour un seul docker
commande en ajoutant le DOCKER_HOST
variable:
DOCKER_HOST=tcp://192.168.0.1:2375 docker run httpd:latest -d
Cela lancera un nouveau conteneur à partir du httpd:latest
image à l’aide du moteur Docker à 192.168.0.1:2375
.
Si vous allez exécuter plusieurs commandes en une seule session, exportez le DOCKER_HOST
variable dans votre shell:
export DOCKER_HOST=tcp://192.168.0.1:2375 docker run httpd:latest -d --name httpd docker ps docker rm httpd --force
Tu peux faire docker
utilisez toujours un hôte distant en définissant DOCKER_HOST
globalement dans le fichier de configuration de votre shell. Voici comment vous feriez cela dans Bash:
echo "export DOCKER_HOST=tcp://192.168.0.1:2375" >> ~/.bashrc
Maintenant le DOCKER_HOST
La variable d’environnement sera définie à chaque démarrage de votre shell.
Amélioration de la sécurité
Le socket TCP de base n’est pas protégé. Quiconque peut accéder à votre machine via le réseau peut utiliser le socket Docker pour contrôler vos conteneurs.
Docker prend en charge SSH au lieu de TCP. C’est généralement une meilleure option si l’hôte dispose d’un serveur SSH disponible. Il empêche les utilisateurs non authentifiés d’accéder. L’utilisation de SSH ne nécessite aucune configuration supplémentaire. DOCKER_HOST
vous permet de transmettre une chaîne de connexion SSH:
DOCKER_HOST=ssh://user@hostname docker run -d --name httpd
Vous pouvez également utiliser des liaisons SSH pour lier directement le socket Docker Unix de l’hôte distant à votre machine locale:
ssh -L /var/run/docker.sock:/var/run/docker.sock
Maintenant, vous n’avez pas besoin d’utiliser DOCKER_HOST
du tout. La télécommande docker.sock
sera lié à son homologue local. Docker le détectera automatiquement comme son socket Unix standard.
L’utilisation de l’une des solutions basées sur SSH est la meilleure façon d’aborder la sécurité du démon Docker. Docker prend également en charge TLS si vous fournissez une autorité de certification et des clés serveur et client:
dockerd --tlsverify --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem -H=0.0.0.0:2375
Désormais, les clients pourront se connecter sur le port 2375 s’ils présentent un certificat SSL valide approuvé par l’autorité de certification ca.pem
.
Créer des contextes
Docker vous permet de configurer plusieurs «contextes» pour vous connecter à différents hôtes. Les contextes peuvent être utilisés à la place du DOCKER_HOST
variable d’environnement. Ils facilitent le basculement entre plusieurs hôtes distants.
docker context create --docker host=tcp://192.168.0.1:2375 --description remote docker context create --docker host=unix:///var/run/docker.sock --description local
Ces commandes créent deux contextes différents – un pour votre local docker.sock
et un pour une connexion à distance.
Vous pouvez basculer entre les contextes à l’aide de la docker context use
commander:
docker context use remote # Container is started on "remote" docker run httpd:-latest -d docker context use local # Lists containers running on "local" docker ps
Les contextes sont utiles lorsque vous travaillez avec plusieurs hôtes Docker. Ils sont moins compliqués que de réinitialiser continuellement le DOCKER_HOST
variable lorsque vous vous déplacez entre les hôtes.
Inconvénients des hôtes distants
Nous avons noté précédemment qu’un hôte distant peut améliorer les performances de construction. Cette déclaration n’est vraie que si la machine exécutant Docker Engine est plus rapide que votre matériel local. Le plus gros inconvénient d’un hôte distant est la surcharge supplémentaire liée à l’interaction sur le réseau. Vous devenez également dépendant du réseau – si vous perdez la connectivité, vous ne pourrez plus gérer vos conteneurs.
Vous devez disposer d’une connexion réseau haut débit fiable si vous comptez utiliser un hôte distant comme serveur de build principal. La première docker build
stage envoie le contenu du contexte de construction de votre image (généralement votre répertoire de travail) à Docker Engine. C’est rapide lorsque Docker s’exécute localement, mais le téléchargement sur une machine distante peut prendre beaucoup plus de temps.
L’exposition d’une instance de démon Docker sur le réseau est un risque de sécurité. Vous devez vous assurer que l’accès est limité aux utilisateurs et appareils autorisés. Une exposition non intentionnelle d’un socket de démon Docker pourrait donner aux attaquants un accès illimité à l’hôte. Docker fonctionne généralement comme root
il est donc essentiel que seules les personnes de confiance puissent démarrer des conteneurs.
Conclusion
La configuration d’un hôte Docker distant vous permet de séparer vos instances de conteneur de votre machine de développement locale. Un serveur de build Docker dédié peut offrir des performances améliorées et un plus grand espace de stockage d’images.
Vous devez prendre soin de vérifier la sécurité de votre implémentation. Un socket TCP simple peut être sûr sur un réseau privé mais ne doit pas être déployé dans un environnement sensible. L’utilisation de SSH permet d’atténuer les risques si vous pratiquez une bonne hygiène de sécurité SSH, telle que l’authentification obligatoire basée sur les clés.