Agence web » Actualités du digital » Comment et pourquoi utiliser un hôte Docker distant –

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.

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.

★★★★★