Docker est un outil de développement populaire car il simplifie le démarrage d’instances isolées de votre application avec une configuration reproductible. Il peut également être utilisé en production, où il garantit que les déploiements en direct sont identiques à votre environnement de développement.
La mise en production d’un conteneur n’est pas toujours aussi simple que l’exécution de docker run sur votre machine locale. Ce n’est pas une bonne idée de pousser manuellement des images dans un registre, de se connecter à un hôte Docker distant et de démarrer vos conteneurs. Cela repose sur l’intervention humaine, ce qui prend du temps et est source d’erreurs.
Dans ce guide, nous allons examiner trois stratégies différentes que vous pouvez utiliser pour automatiser facilement les déploiements de Docker et maintenir une configuration cohérente. Ces approches peuvent être scriptées dans le cadre d’un pipeline CI pour démarrer de nouveaux conteneurs chaque fois que votre code est modifié. Vous devrez construire vos images Docker et les pousser vers un registre comme première étape de votre script, puis utiliser l’une des techniques ci-dessous pour extraire l’image et démarrer les conteneurs dans votre environnement de production.
Sommaire
Docker Compose via SSH
Docker Compose vous permet de démarrer plusieurs conteneurs avec une seule commande. De plus, Compose est configuré via un fichier YAML, ce qui vous aide à gérer les changements de version et à garantir des déploiements reproductibles.
Vous avez peut-être déjà utilisé Compose comme outil de développement local. Vous devez créer un fichier docker-compose.yml dans votre répertoire de travail, puis ajouter un ou plusieurs services qui définissent les conteneurs à démarrer :
version : 3
services :
app :
image : example.com/app:latest
ports :
– 80:80
base de données :
image : mysql:8.0
exposer :
– 3306
Une fois que vous avez obtenu un fichier Compose, utilisez la commande docker-compose up -d pour lancer vos conteneurs. Si vous modifiez le fichier, répétez la commande pour appliquer vos changements. Compose mettra à jour ou remplacera les conteneurs pour obtenir le nouvel état déclaré.
L’ajout de l’indicateur –pull indique à Compose d’essayer de tirer des images mises à jour avant de lancer les conteneurs. Vous pouvez également utiliser –force-recreate pour forcer la création de nouveaux conteneurs, même si leur configuration sous-jacente n’a pas changé.
Quel est le lien entre tout cela et les déploiements de production ? Cela signifie que vous pouvez utiliser Compose dans le cadre de votre pipeline CI pour démarrer sans effort les conteneurs qui satisfont à l’état que vous déclarez dans votre fichier docker-compose.yml. L’exécution de docker-compose up -d –pull dans chaque pipeline vous donnera un ensemble de conteneurs qui exécutent chacun la dernière version de leur image.
Il existe plusieurs façons de mettre en œuvre cette méthode. La voie la plus simple et la plus sûre consiste à installer Docker et Compose sur votre hôte de production, puis à vous y connecter par SSH. Vous devrez utiliser les paramètres de votre fournisseur de CI pour stocker les informations d’identification SSH en tant que variables accessibles à votre pipeline. Vous devrez ensuite configurer le client SSH dans votre pipeline, copier le fichier docker-compose.yml sur votre hôte distant et exécuter la commande docker-compose up.
Voici un exemple de script :
mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo $SSH_PRIVATE_KEY | ssh-add –
echo $SSH_HOST_KEY > ~/.ssh/known_hosts
scp docker-compose.yml:[email protected]:/home/ci-user/docker-compose.yml
ssh -t [email protected] docker-compose up -d
Vous pouvez également utiliser les contextes Docker pour exécuter le binaire Compose localement, dans l’environnement de votre pipeline. Pour ce faire, vous devez exposer le socket Docker sur votre hôte distant. Comme cela peut présenter un risque pour la sécurité, cette approche est généralement moins favorable dans les situations où SSH peut également être utilisé.
En suivant cette méthode, vous devez installer Docker et Compose sur l’hôte qui exécute vos pipelines. Dans le script de votre pipeline, vous enregistrez et sélectionnez un contexte Docker qui pointe vers votre hôte de production distant. Les détails de la connexion doivent être fournis sous forme de variables définies dans le panneau de configuration de votre fournisseur de CI. Une fois le contexte sélectionné, vous exécutez docker-compose up -d dans l’environnement de votre pipeline, mais vous voyez la commande exécutée sur le serveur distant.
Utiliser une plate-forme en tant que service (PaaS)
L’adoption d’une offre de plate-forme en tant que service (PaaS) est une autre façon d’exécuter des conteneurs Docker en production. Vous pouvez faire votre propre hébergement avec des solutions comme Dokku ou choisir une offre hébergée comme Amazon ECS, DigitalOcean App Platform ou Heroku.
Un PaaS supprime la complexité de la création d’images, du maintien de configurations détaillées et du provisionnement de vos propres hôtes Docker. Vous pouvez utiliser Git pour pousser directement votre dépôt vers la plateforme ou exécuter une commande CLI pour télécharger vos modifications. Le PaaS gère la création de conteneurs à partir de vos ressources sources, de vos fichiers Docker ou de votre fichier de configuration spécifique à la plateforme.
Les solutions PaaS sont un excellent moyen d’être rapidement en ligne avec un minimum d’interaction avec Docker. Elles sont faciles à intégrer dans votre pipeline CI et la plupart des grands fournisseurs proposent des scripts types pour vous aider à démarrer. Cependant, il est possible de devenir trop grand pour un PaaS, ce qui peut signifier que vous devrez repenser votre infrastructure à l’avenir.
Les étapes pour automatiser le déploiement sur la plateforme de votre choix varient selon le fournisseur. Si vous utilisez Dokku ou un PaaS similaire avec intégration de Git, votre script CI pourrait être aussi simple que deux lignes :
git remote add dokku [email protected]:app-name
git push dokku master
Le script ajoute votre serveur Dokku comme distant Git et pousse le contenu du dépôt. Dokku va automatiquement construire une image à partir de votre Dockerfile et démarrer les instances du conteneur. Vous devez ajouter la clé publique SSH de votre serveur CI à Dokku pour que cela fonctionne ; sinon, votre script CI ne pourra pas s’authentifier sur la plateforme.
Orchestration avec Kubernetes/Docker Swarm
L’utilisation d’un orchestrateur tel que Kubernetes ou Docker Swarm est sans doute le moyen le plus courant d’exécuter des instances de conteneurs en direct. Ces outils sont spécialement conçus pour déployer et mettre à l’échelle des conteneurs dans des environnements de production.
Les orchestrateurs suppriment les complexités de la gestion de l’infrastructure, vous permettant ainsi de vous concentrer sur votre application et ses composants. Comme Docker Compose, ils adoptent une approche déclarative de la configuration de l’état où vous définissez l’état final. L’orchestrateur détermine la séquence correcte d’actions pour atteindre cet état.
Kubernetes est l’orchestrateur le plus populaire. Une façon d’interagir avec les clusters Kubernetes est d’utiliser Kubectl, l’outil de gestion CLI officiel. Kubectl vous permet d’appliquer des fichiers manifestes au format YAML qui définissent les ressources de conteneurs à créer dans votre cluster.
Voici un manifeste simple qui crée une seule instance de conteneur :
apiVersion : apps/v1
kind : Déploiement
métadonnées :
nom : demo
spec :
répliques : 1
sélecteur :
matchLabels :
app : demo
modèle :
metadata :
labels :
app : demo
spec :
conteneurs :
– nom : demo
image : exemple.com/image:latest
Vous pouvez utiliser Kubectl pour appliquer ce manifeste à un cluster :
kubectl apply -f manifest.yaml
Les modifications ultérieures du fichier sont appliquées en répétant la commande. Kubernetes prend automatiquement les mesures nécessaires pour atteindre le nouvel état déclaré.
Cela fait de Kubernetes une excellente option pour les déploiements de production automatisés. Vous pouvez utiliser kubectl apply dans vos pipelines pour prendre les manifestes de votre référentiel et appliquer l’état déclaré à votre cluster. En créant un nouveau tag image pour chaque commit, Kubernetes récupère cette image et démarre de nouveaux conteneurs pour le déploiement.
Pour mettre en place ce système, vous devez fournir le contenu d’un fichier de configuration Kubeconfig comme variable de pipeline. Cela donne à Kubectl les informations d’identification à utiliser pour votre connexion au cluster. Le binaire local de Kubectl fonctionnera alors sur votre cluster distant.
Docker Swarm est une autre option d’orchestration qui est intégrée à Docker. Vous pouvez configurer une pile Swarm à l’aide du même fichier docker-compose.yml que celui décrit précédemment. Des approches de déploiement similaires peuvent alors être utilisées, soit en se connectant à l’hôte Swarm via SSH, soit en utilisant un contexte Docker pour modifier la cible des binaires Docker locaux.
Les orchestrateurs sont beaucoup plus complexes que l’utilisation d’un simple Compose ou d’un PaaS géré. Dans le cas de Kubernetes, vous devez apprendre de nouvelles abstractions, une nouvelle terminologie et de nouveaux formats de fichiers de configuration avant de pouvoir déployer vos conteneurs. Cependant, les clusters vous offrent également des capacités supplémentaires qui facilitent la maintenance des applications à long terme. Vous pouvez facilement faire évoluer les répliques sur plusieurs hôtes, intégrer la redondance et regrouper les journaux et les mesures.
L’orchestration est donc la meilleure option pour les systèmes plus importants exécutant plusieurs conteneurs. Cela ne signifie pas que l’attention portée par l’industrie à ces outils doit vous inciter à utiliser Kubernetes pour chaque déploiement. Compose ou un PaaS sera plus facile à configurer, à raisonner et à maintenir pour les cas d’utilisation plus petits où vous êtes moins préoccupé par l’évolutivité et le verrouillage du fournisseur.
Résumé
Nous avons examiné trois façons différentes d’exécuter des conteneurs en tant que charges de travail de production. Les détails de la mise en œuvre varieront en fonction de la stratégie choisie, de la chaîne d’outils de prise en charge et de l’environnement CI. Nous avons donc omis de décrire précisément la manière dont vous pouvez configurer l’automatisation dans le cadre de votre flux de travail. Cependant, les trois peuvent être facilement intégrés dans un pipeline CI qui s’exécute chaque fois que vous fusionnez ou poussez votre code.
L’orchestration à l’aide d’un outil comme Kubernetes est rapidement devenue la méthode privilégiée pour les déploiements évolutifs de systèmes exécutant plusieurs conteneurs. Bien qu’elle puisse simplifier considérablement l’exploitation des services pour lesquels elle a été conçue, elle implique également une courbe d’apprentissage et des frais de maintenance importants, de sorte que vous ne devriez pas vous lancer sans envisager d’autres solutions.
Les petits systèmes constitués de quelques composants peuvent obtenir de meilleurs résultats en utilisant Compose pour démarrer des conteneurs avec une configuration reproductible sur un hôte Docker existant. Cela permet de bénéficier de certains des avantages de Kubernetes, comme la configuration déclarative, sans la complexité supplémentaire. Vous pourrez vous familiariser plus tard avec l’orchestration en ajoutant la prise en charge de Docker Swarm à votre fichier Compose existant, ce qui vous permettra de démarrer plusieurs répliques distribuées de conteneurs.
Enfin, les options de Platform-as-a-Service accélèrent le déploiement des applications sans vous obliger à réfléchir aux détails granulaires des conteneurs. Ces services offrent la perspective d’une automatisation complète de l’infrastructure à partir d’une configuration minimale. Ils peuvent toutefois s’avérer restrictifs à long terme ; réfléchissez donc à la manière dont votre solution évoluera dans le temps avant de vous engager.
Lorsque vous déployez des conteneurs en production, vous devez également tenir compte de l’hébergement des images et de l’injection de la configuration. Vous pouvez utiliser un service de registre public pour rendre vos images disponibles dans votre environnement de production. Vous pouvez également utiliser votre propre registre privé et fournir des informations d’identification dans le cadre de votre pipeline de CI. Les valeurs de configuration sont généralement fournies sous forme de variables d’environnement que vous pouvez définir dans l’écran des paramètres de votre fournisseur de CI.