Le docker Le programme CLI est indépendant du démon Docker qui exécute vos conteneurs. Bien que les deux composants s'exécutent généralement sur votre ordinateur local, vous pouvez exécuter docker commandes sur 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 son docker exec local commande.
Les hôtes distants sont plus souvent utiles lorsque vous avez un serveur puissant inutilisé. Si votre ordinateur portable est lent ou manque 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 docker local CLI dans votre terminal.
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 un socket TCP. Exécutez 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 des 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 atteindre ce dernier avec systemd , que la plupart des distributions Linux utilisent pour la gestion des services.
Modifier /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
La CLI Docker utilise le DOCKER_HOST variable d'environnement pour déterminer l'hôte auquel se connecter. Le socket Unix du démon local sera utilisé 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 variables :
DOCKER_HOST=tcp://192.168.0.1:2375 docker run httpd:latest -d
Cela démarrera un nouveau conteneur à partir du httpd:latest image utilisant le 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
Vous pouvez faire docker utilisez toujours un hôte distant en définissant DOCKER_HOST globalement dans le fichier de configuration de votre shell. Voici comment procéder 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é. Toute personne pouvant 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 ordinateur local :
ssh -L /var/run/docker.sock:/var/run/docker.sock
Maintenant, vous n'avez plus 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 .
CONNEXE : Qu'est-ce qu'un fichier PEM et comment l'utiliser ?
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 variables 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 docker.sock local et un pour une connexion à distance.
Vous pouvez basculer entre les contextes à l'aide de l'docker context use commande :
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 affirmation 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 pas gérer vos conteneurs.
Vous devez disposer d'une connexion réseau haut débit fiable si vous envisagez d'utiliser un hôte distant comme serveur de construction 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 constitue un risque pour la sécurité. Vous devez vous assurer que l'accès est limité aux utilisateurs et appareils autorisés. L'exposition involontaire d'un socket de démon Docker pourrait donner aux attaquants un accès illimité à l'hôte. Docker s'exécute généralement en tant que root il est donc essentiel que seules des 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 ordinateur de développement local. 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 veiller à auditer la sécurité de votre implémentation. Un socket TCP ordinaire 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 une clé.