Nous commencerons notre blog avec des publications basées sur les derniers discours de notre directeur technique (Dmitri Stolyarov). Tous ont eu lieu en 2016 lors de divers événements professionnels et étaient consacrés au thème DevOps et Docker. Une vidéo de la réunion Docker Moscou au bureau de Badoo, nous l'avons déjà En ligne. Les nouveaux seront accompagnés d'articles reprenant l'essentiel des rapports. Donc…
Le 31 mai à la conférence , organisée dans le cadre du festival « Technologies Internet russes » (RIT++ 2016), la section « Déploiement et déploiement continus » s'est ouverte avec le rapport « Meilleures pratiques de livraison continue avec Docker ». Il a résumé et systématisé les meilleures pratiques pour créer un processus de livraison continue (CD) à l'aide de Docker et d'autres produits Open Source. Nous travaillons avec ces solutions en production, ce qui nous permet de nous appuyer sur une expérience pratique.
Si vous avez la possibilité de passer une heure , nous vous recommandons de le regarder en intégralité. Sinon, vous trouverez ci-dessous le résumé principal sous forme de texte.
Livraison continue avec Docker
sous Livraison continu nous comprenons la chaîne d'événements à la suite de laquelle le code d'application du référentiel Git arrive d'abord en production, puis se retrouve dans l'archive. Cela ressemble à ceci : Git → Build → Test → Release → Operate.
La majeure partie du rapport est consacrée à la phase de construction (assemblage d'applications), et les sujets de publication et d'exploitation sont brièvement abordés. Nous parlerons des problèmes et des modèles qui vous permettent de les résoudre, et les implémentations spécifiques de ces modèles peuvent être différentes.
Pourquoi Docker est-il nécessaire ici ? Ce n’est pas pour rien que nous avons décidé de parler des pratiques de Livraison Continue dans le cadre de cet outil Open Source. Bien que l’intégralité du rapport soit consacrée à son utilisation, de nombreuses raisons apparaissent lorsque l’on considère le principal modèle de déploiement du code d’application.
Modèle de déploiement principal
Ainsi, lorsque nous déployons de nouvelles versions de l'application, nous sommes certainement confrontés à problème de temps d'arrêt, généré lors du changement de serveur de production. Le trafic de l'ancienne version de l'application vers la nouvelle ne peut pas basculer instantanément : nous devons d'abord nous assurer que la nouvelle version est non seulement téléchargée avec succès, mais également « réchauffée » (c'est-à-dire qu'elle est complètement prête à répondre aux demandes).
Ainsi, pendant un certain temps, les deux versions de l'application (ancienne et nouvelle) fonctionneront simultanément. Ce qui conduit automatiquement à conflit de ressources partagées: réseau, système de fichiers, IPC, etc. Avec Docker, ce problème est facilement résolu en exécutant différentes versions de l'application dans des conteneurs distincts, pour lesquels l'isolation des ressources est garantie au sein du même hôte (serveur/machine virtuelle). Bien sûr, vous pouvez vous débrouiller avec quelques astuces sans aucune isolation, mais s'il existe un outil prêt à l'emploi et pratique, alors il y a la raison opposée : ne pas le négliger.
La conteneurisation offre de nombreux autres avantages une fois déployée. Toute application dépend de version spécifique (ou gamme de versions) interprète, disponibilité des modules/extensions, etc., ainsi que leurs versions. Et cela s'applique non seulement à l'environnement exécutable immédiat, mais également à l'environnement dans son ensemble, y compris logiciel système et sa version (jusqu'à la distribution Linux utilisée). Étant donné que les conteneurs contiennent non seulement du code d'application, mais également des logiciels système et d'application préinstallés des versions requises, vous pouvez oublier les problèmes de dépendances.
Résumer modèle de déploiement principal nouvelles versions prenant en compte les facteurs suivants :
- Dans un premier temps, l'ancienne version de l'application s'exécute dans le premier conteneur.
- La nouvelle version est ensuite déployée et « réchauffée » dans un deuxième conteneur. Il est à noter que cette nouvelle version elle-même peut contenir non seulement le code d'application mis à jour, mais également l'une de ses dépendances, ainsi que des composants système (par exemple, une nouvelle version d'OpenSSL ou la distribution complète).
- Lorsque la nouvelle version est entièrement prête à répondre aux demandes, le trafic passe du premier conteneur au second.
- L'ancienne version peut désormais être arrêtée.
Cette approche consistant à déployer différentes versions de l'application dans des conteneurs distincts offre une autre commodité : restauration rapide vers l'ancienne version (après tout, il suffit de basculer le trafic vers le conteneur souhaité).
La première recommandation finale ressemble à quelque chose que même le capitaine ne pouvait trouver à redire : «[lors de l'organisation de la livraison continue avec Docker] Utiliser Docker [et comprends ce que ça donne]" N’oubliez pas qu’il ne s’agit pas d’une solution miracle qui résoudra tous les problèmes, mais d’un outil qui constitue une excellente base.
Reproductibilité
Par « reproductibilité », nous entendons un ensemble généralisé de problèmes rencontrés lors de l’exploitation des applications. Nous parlons de tels cas :
- Les scripts vérifiés par le service qualité pour la mise en scène doivent être fidèlement reproduits en production.
- Les applications sont publiées sur des serveurs pouvant recevoir des packages de différents miroirs de référentiel (au fil du temps, elles sont mises à jour, et avec elles les versions des applications installées).
- « Tout fonctionne pour moi localement ! » (...et les développeurs ne sont pas autorisés à entrer en production.)
- Vous devez vérifier quelque chose dans l'ancienne version (archivée).
- ...
Leur essence générale se résume au fait que le respect total des environnements utilisés (ainsi que l'absence du facteur humain) est nécessaire. Comment garantir la reproductibilité ? Créer des images Docker basés sur le code de Git, puis les utiliser pour n'importe quelle tâche : sur des sites de test, en production, sur les machines locales des programmeurs... En même temps, il est important de minimiser les actions qui sont effectuées après assemblage de l'image : plus c'est simple, moins il y a de risques d'erreurs.
L'infrastructure est du code
Si les besoins en infrastructure (disponibilité du logiciel serveur, sa version, etc.) ne sont pas formalisés et « programmés », alors le déploiement de toute mise à jour d'application peut avoir des conséquences désastreuses. Par exemple, lors de la mise en scène, vous êtes déjà passé à PHP 7.0 et avez réécrit le code en conséquence - alors son apparition en production avec un ancien PHP (5.5) surprendra certainement quelqu'un. Vous n'oublierez peut-être pas un changement majeur dans la version de l'interpréteur, mais « le diable est dans les détails » : la surprise peut résider dans une mise à jour mineure de toute dépendance.
Une approche pour résoudre ce problème est connue sous le nom de IaC (Infrastructure as Code, « infrastructure as code ») et implique de stocker les exigences d'infrastructure avec le code de l'application. Grâce à lui, les développeurs et les spécialistes DevOps peuvent travailler avec le même référentiel d'applications Git, mais sur des parties différentes de celui-ci. A partir de ce code, une image Docker est créée dans Git, dans laquelle l'application est déployée en tenant compte de toutes les spécificités de l'infrastructure. En termes simples, les scripts (règles) d'assemblage des images doivent se trouver dans le même référentiel que le code source et fusionnés.
Dans le cas d'une architecture d'application multicouche - par exemple, il y a nginx, qui se trouve devant une application déjà exécutée dans un conteneur Docker - les images Docker doivent être créées à partir du code dans Git pour chaque couche. Ensuite, la première image contiendra une application avec un interpréteur et d'autres dépendances « proches », et la deuxième image contiendra le nginx en amont.
Images Docker, communication avec Git
Nous divisons toutes les images Docker collectées à partir de Git en deux catégories : temporaires et publiées. Images temporaires étiquetés par le nom de la branche dans Git, peuvent être écrasés lors du prochain commit et sont déployés uniquement pour l'aperçu (pas pour la production). C'est leur principale différence par rapport à celles de la version : vous ne savez jamais quel commit spécifique se trouve dedans.
Il est logique de rassembler dans des images temporaires : la branche master (vous pouvez la déployer automatiquement sur un site séparé pour voir en permanence la version actuelle de master), les branches avec les versions, les branches d'innovations spécifiques.
Une fois que l'aperçu des images temporaires est devenu nécessaire pour les traduire en production, les développeurs ont mis une certaine balise. Collecté automatiquement par tag image de sortie (sa balise correspond à la balise de Git) et est déployée en staging. S'il est vérifié avec succès par le service qualité, il passe en production.
dapp
Tout ce qui est décrit (déploiement, assemblage d'images, maintenance ultérieure) peut être implémenté indépendamment à l'aide de scripts Bash et d'autres outils « improvisés ». Mais si vous faites cela, la mise en œuvre entraînera à un moment donné une grande complexité et une mauvaise contrôlabilité. Comprenant cela, nous en sommes venus à créer notre propre utilitaire de workflow spécialisé pour créer du CI/CD - dapp.
Son code source est écrit en Ruby, open source et publié sur . Malheureusement, la documentation est actuellement le point faible de l'outil, mais nous y travaillons. Et nous écrirons et parlerons du dapp plus d'une fois, parce que... Nous avons sincèrement hâte de partager ses capacités avec l'ensemble de la communauté intéressée, mais en attendant, envoyez vos problèmes et pull request et/ou suivez le développement du projet sur GitHub.
Mis à jour le 13 août 2019 : actuellement un projet dapp renommé en , son code a été entièrement réécrit en Go, et sa documentation a été considérablement améliorée.
Kubernetes
Un autre outil Open Source prêt à l'emploi qui a déjà reçu une reconnaissance significative dans le milieu professionnel est Kubernetes,un cluster de gestion Docker. Le sujet de son utilisation dans le fonctionnement de projets construits sur Docker dépasse le cadre du rapport, la présentation se limite donc à un aperçu de quelques fonctionnalités intéressantes.
Pour le déploiement, Kubernetes propose :
- sonde de préparation : vérification de l'état de préparation d'une nouvelle version de l'application (pour y faire basculer le trafic) ;
- mise à jour continue - mise à jour séquentielle de l'image dans un cluster de conteneurs (arrêt, mise à jour, préparation au lancement, commutation du trafic) ;
- mise à jour synchrone - mise à jour d'une image dans un cluster avec une approche différente : d'abord sur la moitié des conteneurs, puis sur le reste ;
- Canary releases - lancement d'une nouvelle image sur un nombre limité (petit) de conteneurs pour surveiller les anomalies.
Étant donné que la livraison continue n'est pas seulement la sortie d'une nouvelle version, Kubernetes dispose d'un certain nombre de fonctionnalités pour la maintenance ultérieure de l'infrastructure : surveillance et journalisation intégrées pour tous les conteneurs, mise à l'échelle automatique, etc. mise en œuvre dans vos processus.
Recommandations finales
- Utilisez Docker.
- Créez des images Docker d'applications pour tous vos besoins.
- Suivez le principe « L'infrastructure est du code ».
- Liez Git à Docker.
- Réglez l’ordre de déploiement.
- Utilisez une plateforme prête à l'emploi (Kubernetes ou autre).
Vidéos et diapositives
Vidéo de la performance (environ une heure) (le reportage lui-même commence à partir de la 5ème minute - suivez le lien pour jouer à partir de ce moment).
Présentation du rapport :
PS
Autres reportages sur le sujet sur notre blog :
- «» (Dmitry Stolyarov ; 27 mai 2019 à DevOpsConf);
- «» (Dmitry Stolyarov ; 8 novembre 2018 sur HighLoad++);
- «» (Dmitry Stolyarov ; 7 novembre 2017 sur HighLoad++);
- «» (Dmitry Stolyarov ; 6 juin 2017 à RootConf).
Source: habr.com