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.
Mettre un conteneur en production n'est pas toujours aussi simple que d'exécuter docker run sur votre ordinateur local. Ce n'est pas une bonne idée de pousser manuellement des images vers un registre, de se connecter à un hôte Docker distant et de démarrer vos conteneurs. Cela repose sur une intervention humaine, ce qui prend du temps et est sujet aux erreurs.
Dans ce guide, nous examinerons trois stratégies différentes que vous pouvez utiliser pour faciliter l'automatisation des déploiements 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 change. Vous devrez créer vos images Docker et les transférer 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.
1. Docker Compose sur SSH
Docker Compose vous permet de démarrer plusieurs conteneurs avec une seule commande. De plus, Compose est configuré via un fichier YAML qui vous aide à changer 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 définissant les conteneurs à démarrer :
version : 3 services : app : image : example.com/app:latest ports : – base de données 80:80 : image : mysql:8.0 exposé : – 3306 Publicité
Une fois que vous avez 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 modifications. Compose mettra à jour ou remplacera les conteneurs pour atteindre le nouvel état déclaré.
L'ajout de l'indicateur –pull indique à Compose d'essayer d'extraire les images mises à jour avant de démarrer 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é.
Comment tout cela est-il lié aux déploiements de production ? Cela signifie que vous pouvez utiliser Compose dans le cadre de votre pipeline CI pour démarrer sans effort des 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 d'implémenter cette méthode. L'itinéraire le plus simple et le plus sûr consiste à installer Docker et Compose sur votre hôte de production, puis à vous y connecter via SSH. Vous devrez utiliser les paramètres de votre fournisseur CI pour stocker les informations d'identification SSH en tant que variables accessibles à votre pipeline. Vous devez 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:ci-user@example.com:/home/ci-user/docker-compose.yml ssh -t ci-user@example.com docker-compose up -d < p>Vous pouvez également utiliser des contextes Docker pour exécuter le binaire Compose localement, dans l'environnement de votre pipeline. Cela vous obligerait à exposer le socket Docker sur votre hôte distant ; comme cela peut constituer un risque pour la sécurité, l'approche est généralement moins favorable dans les situations où SSH pourrait également être utilisé.
En suivant cette méthode, vous installeriez Docker et Compose sur l'hôte qui exécute vos pipelines. Dans votre script de pipeline, vous devez enregistrer et sélectionner un contexte Docker qui pointe vers votre hôte de production distant. Les détails de connexion doivent être fournis sous forme de variables définies dans le panneau de configuration de votre fournisseur CI. Avec le contexte sélectionné, vous exécuterez docker-compose up -d dans l'environnement de votre pipeline, mais vous verrez la commande exécutée sur le serveur distant.
2. Utilisation d'une plate-forme en tant que service (PaaS)
L'adoption d'une offre de plate-forme en tant que service (PaaS) est une autre approche pour exécuter des conteneurs Docker en production. Vous pouvez auto-héberger la vôtre avec des solutions comme Dokku ou choisir une offre hébergée comme Amazon ECS, DigitalOcean App Platform ou Heroku.
Publicité
Un PaaS élimine la complexité de la création d'images, de la maintenance de configurations détaillées et de l'approvisionnement de vos propres hôtes Docker. Soit vous utilisez Git pour pousser directement votre référentiel sur la plate-forme, soit vous exécutez une commande CLI pour télécharger vos modifications. Le PaaS gère la création de conteneurs à partir de vos actifs source, Dockerfiles ou fichier de configuration spécifique à la plate-forme.
Les solutions PaaS sont un excellent moyen de se connecter rapidement avec une interaction Docker minimale. Ils sont faciles à intégrer dans votre pipeline CI et la plupart des principaux fournisseurs proposent des exemples de scripts pour vous aider à démarrer. Cependant, il est possible de devenir trop grand pour un PaaS, ce qui pourrait vous obliger à repenser votre infrastructure à l'avenir.
Les étapes pour automatiser le déploiement sur la plate-forme choisie varient selon le fournisseur. Si vous utilisez Dokku ou un PaaS similaire avec intégration Git, votre script CI peut être aussi simple que deux lignes :
git remote add dokku dokku@example.com:app-name git push dokku master
Le script ajoute votre serveur Dokku en tant que télécommande Git et remonte le contenu du référentiel. Dokku créera automatiquement une image à partir de votre Dockerfile et démarrera les instances de conteneur. Vous devez ajouter la clé publique SSH de votre serveur CI à Dokku pour que cela fonctionne ; sinon, votre script CI ne pourrait pas s'authentifier auprès de la plateforme.
3. 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 conteneur en direct. Ces outils sont spécialement conçus pour déployer et mettre à l'échelle des conteneurs dans des environnements de production.
Publicité
Les orchestrateurs éliminent les complexités de la gestion de l'infrastructure, vous permettant de vous concentrer sur votre application et ses composants. À l'instar de Docker Compose, ils adoptent une approche déclarative de la configuration de l'état dans laquelle vous définissez à quoi doit ressembler l'état final. L'orchestrateur détermine la séquence correcte d'actions pour atteindre cet état.
Kubernetes est l'orchestrateur le plus populaire. L'une des façons 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 conteneur à créer dans votre cluster.
Voici un manifeste simple qui crée une seule instance de conteneur :
apiVersion : apps/v1 type : métadonnées de déploiement : nom : spécification de démonstration : répliques : 1 sélecteur : matchLabels : application : modèle de démonstration : métadonnées : étiquettes : application : spécification de démonstration : conteneurs : – nom : image de démonstration : example.com/image:latest
Vous peut utiliser Kubectl pour appliquer ce manifeste à un cluster :
kubectl apply -f manifest.yaml
Les modifications ultérieures apportées au 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 dans votre référentiel et appliquer l'état déclaré à votre cluster. La création d'une nouvelle balise d'image pour chaque validation permettrait à Kubernetes d'extraire cette image et de démarrer de nouveaux conteneurs pour le déploiement.
Publicité
Pour configurer cela, vous devez fournir le contenu d'un fichier de configuration Kubeconfig en tant que variable de pipeline. Cela donne à Kubectl les informations d'identification à utiliser pour votre connexion au cluster. Le binaire Kubectl local fonctionnerait alors sur votre cluster distant.
Docker Swarm est une autre option d'orchestration intégrée à Docker. Vous pouvez configurer une pile Swarm en utilisant le même fichier docker-compose.yml que celui décrit précédemment. Des approches de déploiement similaires pourraient 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 de Compose simple ou d'un PaaS géré . Dans le cas de Kubernetes, vous devez apprendre de nouvelles abstractions, terminologies et formats de fichiers de configuration avant de pouvoir déployer vos conteneurs. Cependant, les clusters vous offrent également des fonctionnalités supplémentaires qui facilitent la maintenance des applications sur le long terme. Vous pouvez facilement faire évoluer les répliques sur plusieurs hôtes, créer une redondance et agréger les journaux et les métriques.
L'orchestration est donc la meilleure option pour les grands systèmes exécutant plusieurs conteneurs. Cela ne signifie pas que l'attention de l'industrie que les outils reçoivent devrait vous inciter à utiliser Kubernetes pour chaque déploiement. Composer ou un PaaS sera plus facile à configurer, à raisonner et à gérer pour les petits cas d'utilisation où vous êtes moins préoccupé par l'évolutivité et le verrouillage du fournisseur.
Résumé< /h2>
Nous avons examiné trois manières différentes d'exécuter des conteneurs en tant que charges de travail de production. Les détails de mise en œuvre varient 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 une description précise de 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 préférée pour les déploiements évolutifs de systèmes exécutant plusieurs conteneurs. Bien qu'il puisse grandement simplifier le fonctionnement des services pour lesquels il est conçu, il entraîne également une courbe d'apprentissage et une surcharge de maintenance importantes, vous ne devriez donc pas vous lancer sans envisager d'autres solutions.
Publicité
< p>Les systèmes plus petits formés à partir 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 offre certains des avantages de Kubernetes, tels que la configuration déclarative, sans la complexité supplémentaire. Vous pouvez « vous détendre » ; à l'orchestration plus tard en ajoutant la prise en charge de Docker Swarm à votre fichier Compose existant, vous permettant de démarrer plusieurs répliques distribuées de conteneurs.
Enfin, les options de plate-forme en tant que service accélèrent le déploiement d'applications sans vous faire penser à un conteneur granulaire des détails. Ces services offrent la perspective d'une automatisation complète de l'infrastructure à partir d'une configuration minimale. Ils peuvent cependant être restrictifs à long terme, alors réfléchissez à l'évolution de votre solution au fil du temps avant de vous engager.
Lors du déploiement de conteneurs en production, vous devrez également envisager l'hébergement d'images et injection de configuration. Vous pouvez utiliser un service de registre public pour rendre vos images disponibles dans votre environnement de production. Vous pouvez également exécuter votre propre registre privé et fournir des informations d'identification dans le cadre de votre pipeline 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 CI.