Comment configurer l'accès à distance au démon Docker [Guide détaillé]

J'ai écrit en détail sur la façon de SSH dans un conteneur docker. Ce didacticiel porte le même concept à un autre niveau en permettant l'accès à distance à Docker.

Avec l'accès à distance docker, chaque fois que vous exécutez une commande docker sur votre hôte local, les effets se produisent sur le serveur distant.

Laissez-moi vous expliquer cela en détail.

Qu'est-ce que l'accès à distance Docker ?

Avant de vous plonger dans la configuration, permettez-moi de rappeler le fonctionnement de docker.

Docker fonctionne dans ce qu'on appelle une architecture client-serveur. Le composant principal qui gère tous vos conteneurs, volumes, réseaux, etc. est le démon docker qui s'exécute en arrière-plan.

Le docker la commande n'est rien d'autre que l'application cliente. Le client et le démon communiquent via l'API docker via un socket Unix traditionnel que vous pouvez trouver sur /run/docker.sock ou /var/run/docker.sock . Le client demande au démon de faire quelque chose ou de récupérer des informations, et c'est exactement ce que fait le démon.

En quoi cela vous intéresse-t-il ? Étant donné que le protocole de communication utilisé entre le client docker et le serveur est HTTP simple, vous devriez pouvoir envoyer des requêtes au serveur à distance, si vous pouvez faire en sorte que le démon écoute les requêtes HTTP sur un port au lieu d'un socket UNIX local.

Il s'avère que vous pouvez tout à fait le faire. Le démon peut en effet écouter non seulement le socket UNIX mais aussi un port TCP. Comme si cela ne suffisait pas, à partir de la version 18.09 de Docker, vous pouvez même utiliser SSH pour le protocole de communication.

Dans ce didacticiel, je vais vous expliquer tout le processus de configuration de votre hôte et d'un serveur distant, afin que vous puissiez utiliser docker commandes d'un hôte et les exécuter sur un autre hôte, sans avoir à se connecter en SSH au serveur distant.

Avantages de l'utilisation de l'accès docker à distance

Vous vous interrogez toujours sur les avantages de cette approche ? En voici quelques-uns :

• Pas besoin de se connecter à un serveur pour démarrer ou arrêter un service. Tout peut être fait à distance.
• De nombreux outils de surveillance, tels que Portainer, ont besoin d'accéder au point de terminaison de l'API Docker pour surveiller des détails tels que les réseaux, l'exécution de conteneurs, etc. Normalement, pour ajouter un serveur à la liste des points de terminaison, vous devez déployer un agent Portainer sur le serveur. d'abord et liez un port du conteneur à l'hôte. Au lieu de cela, vous pouvez simplement le laisser accéder directement au démon docker, cela économiserait beaucoup de vos ressources.
• Vous pouvez écrire divers scripts d'automatisation directement sur votre ordinateur local pour contrôler/gérer un ou plusieurs serveurs Docker distants. Comme vous n'avez pas besoin de vous connecter en SSH au serveur distant, il n'est pas nécessaire de maintenir une connexion stable. Cela peut être une bonne option si votre connexion Internet est instable ou lente.
• Si votre système local n'est pas assez puissant pour exécuter des conteneurs, ou si vous n'avez pas assez de stockage, vous pouvez utiliser un serveur distant pour votre hôte docker et le contrôler à distance via un port TCP ou SSH.
• Pour développer le point précédent, les serveurs sur le cloud sont aujourd'hui très évolutifs. Tant que vous êtes d'accord avec les coûts, vous pouvez faire évoluer l'hôte Docker autant que nécessaire sans avoir à vous soucier de l'achat d'un SSD ou d'un HDD plus récent (si vous l'utilisez toujours).

Les avantages eux-mêmes peuvent être augmentés ou réduits, selon que la personne en question en a vraiment besoin ou non. Si vous ne le faites pas, c'est bien. Mais si vous le faites, vous êtes au bon endroit.

L'accès à distance Docker est-il sécurisé ?

Des amis de Docker y ont déjà pensé. En utilisant SSH pour le protocole intermédiaire, il est aussi sécurisé que vos sessions SSH. Plus d'informations à ce sujet dans la section ultérieure de ce didacticiel.

Si vous ne souhaitez pas utiliser SSH, exposer l'API via un port public, sans aucune forme d'authentification, n'est pas exactement la meilleure idée maintenant, n'est-ce pas ?

C'est pourquoi nous avons l'authentification TLS. À moins que quelqu'un d'autre n'ait obtenu un certificat signé par votre autorité de certification (avec le certificat de l'autorité de certification), il ne devrait pas pouvoir vous faire de mal.

Le schéma suivant explique cela :

Je vais d'abord parler de la façon dont vous pouvez configurer vos serveurs locaux et distants pour cette configuration, avec SSH. C'est beaucoup plus facile et je vous recommande de suivre cette voie si l'autre méthode vous semble un peu délicate.

De quoi avez-vous besoin pour cette configuration ?

Avant d'aller de l'avant, vous avez besoin de quelques éléments, certains obligatoires, d'autres facultatifs.

• Comme c'est déjà assez clair, vous aurez besoin d'un serveur sur le cloud, je recommande personnellement Linode.
• Docker doit être installé sur ce serveur distant. Vous pouvez vous référer à notre guide sur l'installation de Docker sur Ubuntu et CentOS.
• Facultativement, une certaine connaissance de openssl peut être utile si vous envisagez d'utiliser la méthode du port TCP.
• Accès au serveur via l'authentification par clé publique SSH.

Méthode 1 :Configurer l'accès Docker à distance à l'aide de SSH

L'un des avantages de l'utilisation de SSH ici est qu'il nécessite beaucoup moins de travail que l'autre méthode. Si vous avez déjà configuré des clés SSH, il s'agit littéralement d'un processus en une seule étape.

Avant d'aller de l'avant, je veux que vous ayez cette image mentale en place, pour comprendre comment cette méthode SSH fonctionne et pourquoi elle est configurée comme elle est configurée.

Lors de l'utilisation du protocole SSH pour l'accès docker à distance, le client docker exécute en fait une commande ssh sur l'hôte local, avec une commande docker cachée (docker system dial-stdio) sur l'hôte distant, qui établit une connexion à la télécommande. dockerd endpoint qui est presque toujours /var/run/docker.sock, et transmettre la connexion aux commandes stdio.

Pour confirmer la déclaration ci-dessus, exécutez n'importe quel docker commande à la fin de cette section (pendant le test) avec le -l debug drapeau. Cela imprimera la commande exacte en cours d'exécution sur votre ordinateur local.

Prérequis

Les prérequis pour cette configuration sont les suivants :

1. Authentification par clé publique SSH

Vous devez avoir activé l'authentification par clé publique SSH entre les machines participantes. Voici un bref récapitulatif sur la façon dont vous pouvez le faire,

1. Utilisez la commande ssh-keygen pour générer une paire de clés publique et privée.
2. Utilisez ssh-copy-id [email protected] commande pour copier la clé publique sur le serveur distant.
3. Assurez-vous que PubKeyAuthentication est défini sur yes dans le fichier de configuration SSHD distant. De plus, je recommande de désactiver l'authentification par mot de passe (définissez PasswordAuthentication à no ).

Comment ajouter une clé publique SSH au serveur L'authentification par clé publique vous permet d'accéder à un serveur via SSH sans mot de passe. Voici deux méthodes pour copier la clé ssh publique sur le serveur. Manuel LinuxAbhishek Prakash

2. L'utilisateur de connexion doit appartenir au groupe docker

Étant donné que vous vous connectez en tant qu'utilisateur et que vous demandez le docker serveur des informations ou pour faire quelque chose, l'utilisateur distant (avec lequel vous vous connectez) doit avoir suffisamment d'autorisations pour envoyer la demande via le "DOCKER_HOST" local de la télécommande (qui est, comme indiqué précédemment, principalement /var/run/docker.sock ). Vous pouvez obtenir cette autorisation en ajoutant cet utilisateur distant au docker groupe.

Par "DOCKER_HOST local distant", j'entends le DOCKER_HOST local du serveur distant.

Cela peut être un désagrément pour beaucoup de personnes comme moi, car personnellement, je n'aime pas utiliser le docker groupe pour un sudo -moins d'exécution.

Vous pouvez utiliser la commande usermod pour ajouter un utilisateur existant au docker groupe.

sudo usermod -aG docker [username]

Modifications de configuration sur votre système local

Voici les éléments que vous devez modifier sur votre système personnel local à partir duquel vous contrôlerez les serveurs Docker.

1. Modifiez DOCKER_HOST sur votre système local

Croyez-le ou non, il n'y a qu'une chose à faire ici. Définissez la variable d'environnement DOCKER_HOST à la combinaison correcte du nom d'utilisateur distant, de l'adresse IP du serveur et du port sur lequel sshd s'exécute. Comme ceci :

DOCKER_HOST=ssh://[email protected]:22

Alternativement, vous pouvez également utiliser le -H drapeau comme je l'ai fait ici avec le docker commande

docker -H ssh://[email protected] info

Vous pouvez ajouter un alias sous Linux comme ceci à la place :

alias docker="docker -H ssh://[email protected]:22"

Tester la configuration

Peu importe la méthode que vous avez choisie (variable d'environnement ou alias), le test consiste simplement à exécuter une simple commande docker telle que docker info .

Essayez également d'exécuter docker -l debug info et remarquez que la commande est en cours d'exécution.

Méthode 2 :Utilisation d'un port TCP public avec authentification TLS

Cette méthode est plus compliquée que la précédente, mais a ses avantages comme ne pas avoir à utiliser le docker groupe du tout.

L'idée ici est simple, vous allez créer vos propres certificats et clés privées, puis utiliser un port TCP pour accéder au docker démon via HTTP non simple, mais un canal HTTPS sécurisé.

Il est analogue à un site Web. Dans le cas d'un site Web, vous le configurez avec un serveur Web pour utiliser différentes clés et certificats, qui sont ensuite confirmés par le navigateur qu'ils sont valides et ils sont vérifiés par une organisation de confiance (comme Let's Encrypt ou DigiCert). Une fois cette vérification effectuée, des requêtes HTTP cryptées sont envoyées au serveur Web pour obtenir les données nécessaires.

De même, ici, au lieu d'un serveur Web traditionnel, vous configurerez le docker serveur du démon pour utiliser certains certificats et clés privées. Par conséquent, chaque fois que quelqu'un est sur le point d'envoyer une requête au serveur démon, la première étape consiste à s'assurer que les participants sont dignes de confiance, tant que le client a le même certificat CA et que les certificats sont signés par cette CA, une connexion sera établie. et le client pourra envoyer des requêtes [chiffrées] au serveur.

Préparer les certificats et les clés

Dans les étapes suivantes, vous allez générer des certificats et des clés privées pour votre serveur et votre client.

Autorité de certification

Pour simplifier les transactions, j'utiliserai ma machine cliente pour générer tous les fichiers. Vous pouvez utiliser une machine séparée pour cela si nécessaire. Un certificat CA n'est rien d'autre qu'un certificat auto-signé.

Mais d'abord, vous devez générer la clé privée de votre autorité de certification. Utilisez la commande suivante pour le faire

openssl genrsa -aes256 -out ca-key.pem 4096

Décomposons la commande :

• genrsa  :Cette option indique à openssl pour générer une clé privée basée sur l'algorithme RSA.
• -aes256 :Cela crypte la clé privée avec une phrase de passe fournie par l'utilisateur, en utilisant AES 256 bits. AES est simplement une technique de chiffrement (Advanced Encryption Standard).
• -sortie :spécifie le nom du fichier de sortie.
• Enfin, j'ai mis la longueur de la clé (en bits).

Fournissez une phrase de passe pour sécuriser la clé. Ensuite, vous allez créer un certificat pour votre autorité de certification, qui sera signé avec la clé que vous venez de créer. Créez-le à l'aide de la commande suivante :

openssl req -x509 -new -key ca-key.pem -days 365 -subj '/CN=CertificateAuthority' -out ca-cert.pem

Pour beaucoup, cela peut sembler un mystère, comme que fait-il exactement ? Eh bien, laissez-moi vous expliquer :

• exigence :Cette option est principalement utilisée pour créer des CSR. Ici, nous l'utilisons pour créer un certificat auto-signé.
• -x509  :Cela indique à openssl pour générer un certificat signé au lieu d'un CSR.
• nouveau  :Cela crée une nouvelle demande de certificat et demande à l'utilisateur les valeurs de champ pertinentes.
• -clé :La clé qui va être utilisée.
• -jours :Validité du certificat en jours.
• -subj :Au lieu d'être invité pour chaque détail, nous attribuons directement les valeurs de champ pertinentes avec cette option. J'ai défini le nom commun ici uniquement. Vous pouvez omettre cet indicateur et vous serez invité à fournir chaque détail.
• -sortie :Le nom du fichier de sortie.

Fournissez la phrase secrète de la clé lorsque vous y êtes invité.

Serveur Docker

Ensuite, vous devez générer les certificats et les clés privées de votre serveur.

Pour cela, vous allez d'abord créer un CSR, une demande de signature de certificat, puis il sera signé par l'autorité de certification. Générez d'abord la clé privée :

openssl genrsa -out server-key.pem 2048

La syntaxe est la même que celle que vous avez utilisée précédemment, à quelques exceptions près. Premièrement, ne pas chiffrer la clé cette fois. Étant donné que d'autres programmes devront lire ce fichier sans surveillance, s'il est chiffré, vous serez confronté à des erreurs. Deux, la longueur de la clé est de 256 octets ici. J'ai opté pour une clé plus longue pour le CA. Vous pouvez également utiliser la même longueur pour celui-ci, ceci afin de vous montrer les différentes options disponibles à votre disposition.

Générez ensuite le CSR :

openssl req -new -key server-key.pem -subj '/CN=docker-host' -out server.csr

Modifier le /etc/hosts fichier et ajoutez l'adresse IP de l'hôte Docker avec un nom d'hôte constant. Vous devrez l'ajouter à tous vos clients souhaitant accéder à cet hôte. Si cet hôte a un nom de domaine complet attribué à son IP, vous pouvez l'utiliser à la place. Un FQDN, nom de domaine complet est un nom de domaine qui est associé à votre adresse IP dans les serveurs DNS. Ce n'est pas votre nom d'hôte local. Un FQDN est résolu sur votre adresse IP non seulement dans votre LAN, mais partout dans le monde tant qu'il fait partie d'un enregistrement DNS public et que le résolveur utilise ce serveur DNS.

Les drapeaux sont les mêmes que ceux que vous avez utilisés lors de la génération de votre certificat CA. Ici, je n'ai pas le -x509 flag, comme il ne s'agit pas d'un certificat auto-signé, votre autorité de certification signera celui-ci. Par conséquent, signez-le,

openssl x509 -req -days 365 -in server.csr -CA ca-cert.pem -CAkey ca-key.pem -CAcreateserial -extfile <(echo "extendedKeyUsage = serverAuth") -out server-cert.pem

• x509  :Cette option est utilisée pour signer les CSR.
• -req :Cette option existe pour openssl s'attendre à un CSR.
• -dans :Transmet le fichier CSR.
• Les options -CA , -CAkey prend respectivement le certificat CA et la clé CA comme arguments.
• -CAcreateserial :Avec cette option, openssl crée un fichier de numéro de série CA s'il n'en existe pas déjà.
• -extfile :Passe le fichier contenant les extensions de certificat à utiliser. Ici, j'ai utilisé le extendedKeyUsage extension.

Vous devriez maintenant avoir le certificat de serveur signé par l'autorité de certification server-cert.pem et la clé privée du serveur server-key.pem .

Client Docker

Vous devez maintenant configurer votre client Docker. Le processus est un peu le même qu'avant. Créez une clé privée> générez une CSR> signez cette CSR avec votre autorité de certification.

Pour plus de clarté, je vais quand même les documenter ici. Générez la clé privée :

openssl genrsa -out client-key.pem 2048   

Ensuite, générez le CSR :

openssl req -new -key client-key.pem -subj '/CN=docker-client' -out client.csr

Ici, entrez le nom d'hôte de votre client pour la valeur du CN. Enfin, signez le CSR :

openssl x509 -req -days 365 -in client.csr -CA ca-cert.pem -CAkey ca-key.pem -CAcreateserial -extfile <(echo "extendedKeyUsage = clientAuth") -out client-cert.pem

Ici, la seule différence est la valeur d'extension "utilisation étendue de la clé". J'ai clientAuth au lieu de serverAuth . Saisissez votre phrase de passe lorsque vous y êtes invité.

Configuration de l'environnement

Une fois que les certificats et les clés privées sont prêts, vous devez en informer votre moteur Docker et votre client, en exposant l'API du moteur à un port TCP public et en laissant le client utiliser le moteur Docker qui n'est pas installé sur la machine locale.

Les étapes suivantes passent exactement par là.

L'hôte docker

Tout d'abord, copiez sur trois fichiers de la machine de l'administrateur, le certificat CA (ca-cert.pem ), la clé privée de cet hôte (server-key.pem ) et certificat signé CA (server-cert.pem ). Créez un répertoire /etc/docker/certs pour conserver ces fichiers.

sudo mkdir /etc/docker/certs

Ensuite, ouvrez le fichier de configuration du démon et ajoutez ce qui suit (vous trouverez la configuration dans /etc/docker/daemon.json ):

{
    "tlsverify": true,
    "tlscacert": "/etc/docker/certs/ca-cert.pem",
    "tlscert": "/etc/docker/certs/server-cert.pem",
    "tlskey": "/etc/docker/certs/server-key.pem",
    "host": "tcp://0.0.0.0:2376"
}

La dernière option indique au démon d'écouter le port TCP 2376. Enregistrez le fichier et redémarrez docker.

sudo systemctl restart docker

Tandis que l'équipe derrière docker recommande d'utiliser le port 2376 pour cela, théoriquement, vous pouvez utiliser n'importe quel autre port inutilisé/non réservé.

Le client

Le côté client est sans doute plus facile à configurer. Créer un répertoire ~/.docker :

mkdir ~/.docker

À l'intérieur de ce répertoire, placez trois fichiers, avec le nom correct, comme ci-dessous (les noms que nous avons utilisés précédemment au cours de cet article sont placés à l'intérieur de ces crochets)

• ca.pem :Le certificat CA (ca-cert.pem ).
• clé.pem :Clé privée du client (client-key.pem ).
• cert.pem :Certificat du client (client-cert.pem ).

Ensuite, configurez deux variables d'environnement

• DOCKER_HOST Définissez la valeur de cette variable sur tcp://docker-host:2376 . Utilisez le nom d'hôte que vous avez défini dans /etc/hosts fichier pour l'hôte/ip correspondant.
• DOCKER_TLS_VERIFY Réglez-le sur 1.

Vous pouvez utiliser ~/.bashrc pour les configurer automatiquement. Utilisez la commande d'exportation pour définir ces variables :

export DOCKER_HOST=tcp://docker-host:2376
export DOCKER_TLS_VERIFY=1

Encore une fois, pour le nom d'hôte, utilisez la valeur appropriée de /etc/hosts . Si vous avez un FQDN pour cette IP, utilisez-le à la place.

Tester la configuration

Maintenant que tout est fait, vous pouvez le tester en exécutant docker info , ou exécutez n'importe quel conteneur aléatoire, selon ce qui vous vient à l'esprit. Vous pouvez également utiliser curl pour le tester (vous vous souvenez ? Ce sont de simples requêtes HTTP). Utilisez ce qui suit comme alternative à docker info

curl https://docker-host:2376/info --cert ~/.docker/cert.pem --key ~/.docker/key.pem --cacert ~/.docker/ca.pem

Cela produira un objet JSON que vous pouvez analyser en utilisant quelque chose comme jq . Vous pouvez également essayer d'exécuter un serveur Nginx avec docker et voir quel système l'exécute. Parce que visuellement, il semble que docker s'exécute sur votre système local, c'est un excellent exemple/test que vous pouvez effectuer. Exécutez simplement

docker run -d --rm --name remote_nginx -p 8080:80 nginx:latest

Maintenant, utilisez curl pour vérifier à la fois localhost et l'adresse IP distante. Premier hôte local,

curl http://localhost:8080

Vous devriez voir une sortie comme celle-ci

curl: (7) Failed to connect to localhost port 8080: Connection refused

Maintenant, essayez la même chose avec l'adresse IP distante,

curl http://docker-host:8080

Vous devriez y voir le site de modèles de nginx. Vous pouvez également simplement utiliser un navigateur pour surfer sur ces emplacements, hôte local et hôte distant.

Quelle méthode utiliser ? TCP ou SSH ?

Les deux méthodes ont leurs propres mérites. La méthode SSH est plus facile si vous ne voulez pas passer par de nombreux cerceaux. Mais certaines applications comme Portainer ne fonctionneront pas avec la méthode SSH pour l'accès au démon à distance. L'utilisation de la méthode TCP élimine également les problèmes d'"utilisation ou non du groupe docker" par défaut. Choisissez la méthode qui répond à votre objectif.

J'espère que ce tutoriel a été utile et instructif. Si vous avez des questions, faites-le moi savoir dans les commentaires ci-dessous.