👷🏻 👗 👩🏾 Comment devenir ingénieur DevOps en six mois ou plus vite. Partie 5. Déploiement 🍿 🧜🏻 👞

Comment devenir ingénieur DevOps en six mois ou plus vite. Partie 1. Introduction
Comment devenir ingénieur DevOps en six mois ou même plus rapidement. Partie 2. Configuration
Comment devenir ingénieur DevOps en six mois ou même plus rapidement. Partie 3. Versions
Comment devenir ingénieur DevOps en six mois ou même plus rapidement. Partie 4. Packaging logiciel

Rafraîchissez la mémoire

L'image ci-dessus montre à quoi devrait ressembler un déploiement de code typique. Permettez-moi de vous rappeler où nous en sommes maintenant conformément à la feuille de route:

si vous avez passé un mois sur l'étude de chaque section, vous en êtes maintenant à 4 mois. À ce stade, vous devez déjà savoir comment fournir l'infrastructure qui fonctionnera avec votre logiciel, comment gérer correctement les versions logicielles et comment les empaqueter pour un déploiement futur. Dans cet article, nous verrons comment déployer correctement votre code!

Déploiement de code

Avez-vous remarqué que j'ai dit «comment faire» et non «comme c'est facile»? Ce n'est pas seulement ça. Malheureusement, le déploiement correct du code de l'environnement de développement vers l'environnement de production est toujours un processus douloureux, semé d'erreurs et de plantages. Il y a plusieurs raisons à cela, mais, à mon avis, cela se résume principalement aux différences entre l'environnement dans lequel le code est créé et l'environnement dans lequel il est exécuté.

Minimiser ces différences est la meilleure chose que vous puissiez faire non seulement pendant le processus de déploiement, mais également pendant son exécution après le déploiement. Alors, comment pouvons-nous réduire et / ou éliminer les différences entre nos environnements prod et non prod?

Et ça marche sur ma voiture!

Si votre infrastructure de développement ressemble à ceci:

Et l' infrastructure de production ressemble à ceci:

Tenez compte de votre problème. Si vous utilisez l'infrastructure en tant que code et ne configurez pas les choses manuellement, vous pouvez le résoudre à 90%. Sinon, ne désespérez pas - vous n'êtes pas seul. Mettez en surbrillance l'après-midi, déterminez les lacunes que vous avez (apprentissage, culture, personnes, processus, etc.) et comblez-les méthodiquement une par une.

L'essentiel est que vous ne réussirez pas à gérer une pile de technologies modernes si vous configurez toujours des choses manuellement. Ceci est un axiome. La première chose que vous devez faire est de vous assurer que tout ce qui concerne la prod est l'artefact versionné déployé par votre serveur de déploiement.

En supposant que tout cela a été fait, je me permettrai d'affirmer que la meilleure façon de déployer du code est de ne pas le déployer du tout.

Approche de déploiement moderne

Il est vrai que le déploiement de code sur des machines fait écho aux années 1990. Le plus gros problème lors du déploiement de code sur un ensemble de machines de production est que, par définition, vos serveurs de production (sur lesquels le code est exécuté) sont différents de vos serveurs de développement (où ce code est écrit). Il n'est pas surprenant qu'immédiatement après le déploiement, il y ait beaucoup de problèmes qui n'ont jamais été remarqués auparavant, car maintenant les conditions ont changé!

Donc, avant de déployer, vous devez vous assurer que votre artefact de déploiement est l'intégralité du runtime, et non une partie du code. En d'autres termes, déployez votre code une fois dans l'environnement de développement, clonez la machine entière sur laquelle votre code s'exécute, puis copiez-le où il devrait être.

Ceci est appelé «déploiement immuable» et est un modèle très puissant qui vous fera économiser de nombreuses heures de maux de tête après le déploiement. Bien sûr, si vous exécutez des conteneurs, la même idée s'applique: vous déployez le même conteneur partout. Vous pouvez dire: «arrêtez! Ma prod est différente de dev! "Et c'est vrai, parce que les noms d'utilisateur / mots de passe de la base de données, les chaînes de connexion, les emplacements du compartiment S3 sont toutes des choses différentes! Oui, ce sont des choses très différentes.

La façon de résoudre ce problème est d'utiliser le principe de la configuration de l' application à 12 facteurs. Une application de douze facteurs stocke la configuration dans des vars env ou des variables d'environnement env. Les variables d'environnement peuvent être facilement modifiées entre les déploiements sans changer le code. Contrairement aux fichiers de configuration, il est moins probable de les stocker accidentellement dans un référentiel de code, et contrairement aux fichiers de configuration personnalisés ou à d'autres mécanismes de configuration, tels que les propriétés du système Java, ils sont une norme indépendante du langage et du système d'exploitation. Ainsi, toute votre configuration doit être externalisée et transférée en tant que variables d'environnement à votre ordinateur.

Par exemple, si vous êtes dans AWS, utilisez SSM comme référentiel externe de paramètres - il s'intègre parfaitement avec CloudFormation. Il est également très facile de définir des variables d'environnement directement à partir des commandes AWS ssm cli. Bien sûr, d'autres fournisseurs de cloud ont des mécanismes similaires.

En outre, résistez à l'envie de «réparer» vos machines de production en cas de problème. Les machines doivent être immuables, ce qui signifie que toutes les corrections que vous apportez doivent provenir de dev. Votre objectif devrait être d'empêcher tout accès aux machines de production. Ni ssh, ni scp, ni accès prod - jamais à personne, ni à lui-même, ni aux pirates débutants.

Mais que faire si j'ai besoin de journaux pour résoudre le problème? Vous l'avez deviné - vos magazines devraient également être externalisés, idéalement envoyés vers un autre emplacement, soit en utilisant la pile ElasticSearch / Logstash / Kibana (ELK), soit en utilisant des logiciels commerciaux tels que SumoLogic ou Datadog.

Quoi que vous fassiez, vos machines prod sont un «bétail de travail» qui est remplacé au moindre signe de mauvaise santé. Ce ne sont pas des "animaux de compagnie" qui doivent être soignés pour être guéris en passant des heures à dépanner.

Je sais que cette analogie est utilisée trop souvent, et j'entends des gens qui se soucient vraiment du bétail que ce n'est pas entièrement vrai, mais l'essence est la même - ne «réparez» pas vos prod-machines, corrigez simplement votre développement et redéployez-le .

Mécaniques de déploiement de code

Donc, vous savez quoi faire, mais vous ne savez pas comment. Malheureusement, c'est là que Jenkins apparaît. Si vous ne le savez pas, Jenkins est l'un des serveurs d'automatisation de déploiement open source les plus populaires.

Je dis «malheureusement» parce que Jenkins (et son prédécesseur Hudson) sont autour de nous depuis près de dix ans, et cela se remarque. Il est compliqué à mettre en place et encore plus difficile à entretenir. Il est livré avec des millions de plugins de qualité douteuse. Ces plugins, en règle générale, se cassent au moment le plus inopportun, laissant tout le reste derrière eux. En fait, vraiment stables, les ateliers Jenkins sont rares et ne sont généralement vus que dans les plus grandes organisations.

Pourquoi je vous recommande de commencer avec Jenkins? Parce que, malgré toutes ses lacunes, il est toujours extrêmement populaire et largement utilisé dans le domaine informatique. Connaître Jenkins, en particulier la façon dont le fichier Jenkins est structuré , est un énorme avantage pour les perspectives d'emploi et ne peut être ignoré. Lorsque vous explorez Jenkins, assurez-vous de prendre le nouveau plugin Pipeline BlueOcean , et non le pipeline de travaux Jenkins obsolète. Cela est essentiel si vous souhaitez que votre pipeline CI / CD vive directement dans votre code de dépôt GitHub / GitLab. Ainsi, le pipeline lui-même est un morceau de code versionné!

En fait, c'est tellement important qu'il vaut la peine de le répéter: tout est code! Votre application, comment elle est déployée, comment elle est suivie, comment elle est configurée, etc. sont toutes des extraits de code correctement versionnés stockés dans GitHub / GitLab / Anywhere. L'objectif est de créer un environnement exempt d'incohérences pour les principaux développeurs (ingénieurs logiciels qui écrivent du code fonctionnel).

Par exemple, je devrais pouvoir:

écrivez votre propre petit microservice;
ajouter tous les tests que je considère nécessaires;
Ajouter Jenkinsfile
ajouter une configuration de surveillance en tant que code;
spécifiez mes paramètres dans le fichier env.yaml;
enregistrez tout cela dans un référentiel;
faire en sorte que Jenkins détecte automatiquement le référentiel spécifié;
construisez votre microservice;
Essaye-le;
Expand (en utilisant la méthode Canary ou Blue-Green);
organiser l'envoi d'un message à votre e-mail lorsque cela est fait!

Tel est l'objectif, dont la réalisation est l'essence même de la mission principale des ingénieurs DevOps.

Alternatives à Jenkins

Comme je l'ai dit plus tôt, Jenkins existe depuis des lustres, et aujourd'hui il y en a d'autres, à mon avis, meilleures, bien que moins populaires. L'un d'eux est AWS CodeDeploy . Il a des limites, mais les développeurs ont apporté des améliorations significatives au cours de la dernière année, et si vous travaillez dans AWS, je vous invite à essayer CodeDeploy.

La deuxième alternative est le module d'intégration continue GitLab CI. Si votre organisation exécute GitLab, vous devriez probablement commencer à travailler avec elle, car elle est assez bien intégrée au reste de GitLab.

Enfin, GitHub a annoncé son propre outil de déploiement d'applications Actions , soutenu par leur propre automatisation.

En fait, je ne pense pas que les outils soient si importants ici. Il est important de savoir que tout, y compris les pipelines de déploiement de code, sont des artefacts versionnés, et rien ne va à prod sauf s'il provient de dev.

Quoi qu'il en soit, si vous commencez avec Jenkins, essayez de le configurer en tant que conteneur. Ce n'est pas très difficile et ce sera une formidable opportunité d'apprendre à déployer un serveur de conteneur Jenkins avec des nœuds de travail Jenkins de conteneur de traction. En fait, vous pouvez démarrer sans aucune orchestration de conteneur, qui fait l'objet du prochain article.

A suivre très prochainement ...

Un peu de publicité :)

Merci de rester avec nous. Aimez-vous nos articles? Vous voulez voir des matériaux plus intéressants? Soutenez-nous en passant une commande ou en recommandant à vos amis, le cloud VPS pour les développeurs à partir de 4,99 $ , un analogue unique de serveurs d'entrée de gamme que nous avons inventé pour vous: Toute la vérité sur VPS (KVM) E5-2697 v3 (6 cœurs) 10 Go DDR4 480 Go SSD 1 Gbit / s à partir de 19 $ ou comment diviser le serveur? (les options sont disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).

Dell R730xd 2 fois moins cher au centre de données Equinix Tier IV à Amsterdam? Nous avons seulement 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV à partir de 199 $ aux Pays-Bas!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - à partir de 99 $! En savoir plus sur la création d'un bâtiment d'infrastructure. classe c utilisant des serveurs Dell R730xd E5-2650 v4 coûtant 9 000 euros pour un sou?

Comment devenir ingénieur DevOps en six mois ou plus vite. Partie 5. Déploiement