Michael DeHaan est l'homme qui a créé Ansible. Beaucoup de choses que les administrateurs système, les ingénieurs des versions et DevOps font régulièrement sont, pour le moins, sans intérêt. DeHaan veut que ces personnes libèrent leur temps pour des choses plus intéressantes (au travail ou devant la porte du bureau) et écrivent un code produit qui libère du temps d'administrateur.
Plus de temps, moins d'adrénaline pendant les heures de bureau, moins de scripts et moins d'erreurs.
À propos, vous pouvez terminer la lecture de ce paragraphe en vous connectant à la diffusion en direct le 6 juin
ici .
Si vous continuiez à lire ...
Ansible: intégration et livraison continues
Ansible est un puissant langage d'automatisation open source. Oui, c'est formidable non seulement pour la gestion, mais aussi pour le déploiement et l'orchestration des systèmes informatiques. Ansible a été initialement créé pour résoudre efficacement un large éventail de tâches d'automatisation et comme base universelle simple pour remplacer les commandes traditionnelles, mais il s'est finalement avéré très utile dans de nombreux domaines. Par exemple, tout en garantissant zéro temps d'arrêt lors de l'intégration continue et de la livraison des applications (CI / CD). Habituellement, ce problème est résolu grâce au raffinement extensif des logiciels, à l'utilisation de divers progiciels et à de nombreuses astuces propres à chaque configuration spécifique. Ansible a été initialement conçu spécifiquement pour de tels scénarios d'orchestration et propose une solution clé en main "tout en un".
Intégration continue et livraison d'applications (CI / CD)
Quelques vérités communes. La pratique de développement de systèmes logiciels au cours des 10 dernières années montre que le cycle de vie long des versions logicielles (modèle de développement en cascade) a des frais généraux beaucoup plus élevés par rapport à un cycle court (le développement dit "itératif" ou agile). Il s'agit d'arythmie: lorsque les programmeurs commencent à peine à travailler sur une nouvelle version, il n'y a tout simplement rien à faire pour le personnel informatique responsable des tests et du déploiement. Mais plus la version est proche de la version, plus les informaticiens sont occupés et le plus souvent les programmeurs doivent changer de contexte, alternant entre travailler sur les bugs et planifier la prochaine version.
De plus, un long cycle augmente l'intervalle entre l'identification et l'élimination des erreurs et des défauts logiciels, ce qui est particulièrement critique pour les grands systèmes Web avec une audience d'utilisateurs de plusieurs millions de dollars. Par conséquent, l'industrie du logiciel adopte rapidement des méthodologies agiles sous le slogan «publier plus rapidement et plus souvent» afin que les participants au processus de développement puissent changer leur contexte de travail moins souvent et créer, déboguer et mettre en œuvre des améliorations et des innovations beaucoup plus rapidement.
L'automatisation du contrôle qualité, le développement TDD par le biais de tests et d'autres techniques connexes augmentent encore l'efficacité des nouvelles méthodes de travail. Où est l'automatisation? Où sont les technologies qui font tourner les engrenages plus rapidement et réduisent la participation humaine au strict nécessaire?
Et ici, par exemple, Ansible et Ansible Tower de Red Hat pour orchestrer des systèmes informatiques dans le cadre de processus de développement logiciel modernes.
Aucun temps d'arrêt
Un peu plus évident. Les temps d'arrêt signifient une perte de profits et des clients insatisfaits. Par conséquent, dans les systèmes de files d'attente Web, dont les utilisateurs sont répartis sur tous les fuseaux horaires, l'arrêt planifié n'est autorisé que dans des cas vraiment graves, dont la liste n'inclut pas explicitement la mise à jour des versions d'application. La situation est similaire dans les environnements d'entreprise où l'inaccessibilité d'un intranet ou d'un système comptable réduit considérablement la productivité des employés. Ainsi, toute automatisation de processus doit fournir des mises à jour sans interrompre les opérations - en d'autres termes, sans temps d'arrêt.
Il est tout à fait possible d'obtenir un temps d'arrêt nul, mais pour cela, nous avons besoin d'outils appropriés - tels que pour fournir une orchestration avancée, à plusieurs niveaux et à plusieurs étapes, comme, par exemple, le système Ansible.
Systèmes de création d'applications
La livraison continue (CD) commence par l'intégration continue (CI). Un système qui surveille les référentiels de code source pour les modifications, exécute indépendamment les tests correspondants et crée automatiquement (et idéalement teste) une nouvelle version de l'application avec chaque mise à jour de code, par exemple, le projet Jenkins (jenkins.io).
Pour relayer le témoin au système de CD après avoir correctement assemblé la nouvelle version de l'application, le sous-système de construction du système CI peut appeler Ansible pour fournir immédiatement cette nouvelle version à ceux qui effectuent des tests unitaires ou d'intégration. En particulier, Jenkins peut utiliser Tower pour déployer des assemblages dans divers environnements, et l'environnement de test ou intermédiaire peut être modélisé sur la base de l'environnement de production, ce qui améliore considérablement la prévisibilité tout au long du cycle de vie du logiciel. Les données renvoyées par Ansible à partir des résultats de l'exécution des scripts d'automatisation peuvent être directement impliquées dans les jobs Build Systems du système Tower. En fait, Tower vous permet même de tester des scénarios de déploiement dans un environnement intermédiaire avant de les exécuter sur des serveurs "de combat".
Mise à jour d'application multiniveau une par une
Le système de CD doit être capable d'orchestrer les processus de mise à jour continue des applications multiniveaux. Grâce à l'architecture push et aux capacités d'orchestration multi-niveaux multi-niveaux, Ansible peut faire face à cette tâche en mettant à jour n'importe quelle application niveau par niveau, tout en échangeant des données entre elles.
Pour implémenter les mises à jour une par une, Ansible utilise des scripts Play qui vous permettent de spécifier avec précision le groupe d'hôtes cibles et d'affecter des tâches (rôle) qui doivent être effectuées sur eux. Les tâches sont généralement des annonces selon lesquelles une ressource informatique spécifique doit être dans un état donné, par exemple, pour une version d'un logiciel, un certain package doit être installé, et pour une autre, il est nécessaire de vérifier le référentiel de code. Les topologies d'application Web, en règle générale, nécessitent de les mettre à jour dans un ordre strict, et vous ne pouvez toujours pas mettre à jour les applications et les configurations système sur toutes les machines en même temps.
Lorsque le service est redémarré, il reste indisponible pendant un certain temps et le remplacement de la version de l'application ne se produit pas non plus instantanément. Par conséquent, avant de mettre à jour le système, nous le retirons du pool d'équilibrage. Par conséquent, vous devez avoir la possibilité d'automatiser les opérations de connexion et de déconnexion des machines du pool. Est toujours le mot clé. Ansible peut contrôler très précisément la taille de la fenêtre d'une mise à jour successive. Eh bien, le développement de ces mises à jour est effectué très soigneusement, et si à un certain stade une défaillance se produit, la mise à jour est suspendue afin de ne pas désactiver le reste de l'infrastructure informatique.
Déploiement continu pour les scripts d'automatisation
En plus de la fonctionnalité CD pour les services fonctionnant en mode de fonctionnement commercial, vous pouvez également organiser le déploiement continu des scripts d'automatisation eux-mêmes (jeux d'instructions Ansible Playbook. N'arrêtez pas la lecture, dans la deuxième partie il y aura des exemples de playbooks). Cela permet aux administrateurs système et aux développeurs de gérer les scripts à l'aide du référentiel de code source, de tester ces scripts dans un environnement intermédiaire et de les transférer automatiquement vers l'environnement de production en cas de rodage réussi. En d'autres termes, lorsque vous travaillez avec des scripts, vous bénéficiez de tous les avantages méthodologiques et autres du référentiel de code central auquel vous êtes habitué lors du développement de logiciels.
Apporter des modifications aux configurations logicielles et système est l'une des principales raisons des pannes imprévues. Par conséquent, en plus des tests automatisés, il existe un contrôle humain. Il peut être organisé en s'intégrant à un système d'inspection de code comme
Gerrit , et n'appliquer les modifications qu'après avoir été approuvé par les camarades responsables.
Mises à jour et systèmes d'équilibrage de charge alternatifs
Ansible fonctionne de manière très indépendante avec les systèmes d'équilibrage de charge lors de l'exécution de mises à jour successives. Par conséquent, vous pouvez simplement écrire dans un script Playbook, dans n'importe quel cycle pour un groupe d'hôtes, quelque chose comme "effectuer cette action sur le système X au nom de l'hôte Y", et Ansible se chargera du reste.
Ansible interagit bien avec les équilibreurs de charge de toutes sortes et est en mesure de définir un indicateur pour déconnecter temporairement un hôte afin de désactiver la surveillance de la disponibilité pour lui pendant la période de mise à jour. Le schéma simple "désactiver la surveillance - retirer du pool - mettre à jour le niveau de logiciel souhaité - revenir au pool - activer la surveillance" implémente facilement une mise à jour séquentielle avec zéro temps d'arrêt et sans fausses alarmes. Et tout cela en mode entièrement automatisé, sans intervention de l'opérateur.
Tests intermédiaires intégrés
Tower peut fonctionner avec différents fichiers d'inventaire de ressources (Inventaire), ce qui facilite le test de scénarios de mise à jour successifs dans un environnement intermédiaire avant de les exécuter sur des serveurs "de combat". Pour ce faire, il suffit de simuler l'environnement de production dans l'environnement de test, d'exécuter Ansible avec le paramètre «-i» et d'indiquer quel fichier d'inventaire doit être utilisé lors de l'exécution du script - pour l'environnement de test ou pour l'environnement de production. Le script lui-même n'a pas besoin d'être modifié.
Déploiement du contrôle de version
Certaines personnes aiment emballer des applications avec des packages de système d'exploitation (RPM, debs, etc.) plus chaud, mais souvent, en particulier pour les applications Web, un tel empaquetage n'est pas nécessaire. Par conséquent, Ansible comprend plusieurs modules pour déployer des applications directement à partir de systèmes de contrôle de version. Dans le script Playbook, vous pouvez écrire une réconciliation avec le référentiel de codes pour la balise ou le numéro de version spécifié, après quoi Ansible vérifiera cette condition sur tous les serveurs cibles et activera les étapes suivantes uniquement si la version doit être remplacée, éliminant ainsi les redémarrages de service inutiles.
Intégration avec des outils de surveillance
En tant que système d'orchestration à part entière, Ansible prend en charge l'intégration avec les systèmes de gestion des performances des applications basées sur APM au niveau de la surveillance. Par exemple, pendant la phase de test de déploiement ou d'intégration, vous devez installer ou mettre à niveau l'agent logiciel APM avec l'application. Ansible a un rôle spécial pour cela, et après avoir installé et activé l'agent, Ansible peut le configurer dans la pile de surveillance APM (s'il n'est pas déjà configuré) afin que les gestionnaires d'applications puissent immédiatement vérifier que la nouvelle version a été installée et fonctionne sans problème .
En cas de problème après la mise à jour de l'application dans l'environnement de production, les outils de surveillance peuvent appeler Ansible pour revenir à la version précédente. Bien sûr, seulement si un tel retour en arrière est autorisé.
Notification d'événement
Dans le paradigme CI / CD, tout le monde veut recevoir les notifications d'événements le plus rapidement possible. Ansible offre à la fois des fonctions intégrées, y compris un module de messagerie électronique, ainsi qu'une intégration avec des outils de notification externes, tels que les messageries instantanées, les réseaux sociaux ou les systèmes d'enregistrement d'événements.
Déploiement à l'aide d'un modèle d'état des ressources
L'une des principales caractéristiques d'Ansible, qui en fait un outil très utile pour le déploiement d'applications, est l'utilisation régulière du modèle d'état des ressources dans les processus de mise à jour logicielle, qui a gagné en popularité dans la gestion des configurations système. Contrairement aux contrôles open source traditionnels, Ansible n'a pas besoin d'être équipé d'un logiciel supplémentaire ou de scripts spéciaux pour organiser la livraison des applications.
Dans Ansible, vous pouvez très précisément enregistrer et contrôler l'ordre des événements à différents niveaux architecturaux, ce qui vous permet de déléguer des actions à d'autres systèmes, ainsi que de combiner les directives du modèle de ressource (comme «le package X doit être dans l'état Y») et les commandes de script traditionnelles (comme «exécuter le script» .sh ") dans un même processus.
Ansible facilite également l'exécution de vérifications de diverses conditions et la prise de décisions en fonction de leurs résultats. La combinaison des processus de configuration du système et de déploiement d'applications au sein d'une chaîne d'outils unique est beaucoup plus efficace qu'un schéma avec plusieurs outils spécialisés et, en outre, augmente la cohérence des politiques et des applications du système d'exploitation.
Test de déploiement
Plus il y a d'opportunités, plus la responsabilité est élevée. L'automatisation des processus de livraison continue augmente considérablement le risque de déployer une configuration défaillante sur tous les nœuds du système. Pour réduire les risques, Ansible suggère d'insérer des tests de contrôle dans le script, ce qui interrompra la mise à jour séquentielle en cas de problème. Pour tester diverses conditions, y compris l'état du fonctionnement des services, vous pouvez déployer des tests arbitraires à l'aide des modules de commande ou de script, et même créer de tels tests en tant que modules Ansible distincts.
Le module Fail peut interrompre l'exécution du script sur l'hôte à tout moment, ce qui vous permet de détecter les échecs à un stade précoce de la mise à jour séquentielle. Par exemple, du fait de la différence entre l'environnement intermédiaire et l'environnement de production, ce dernier génère une erreur de configuration qui désactive les serveurs «combat». Dans ce cas, une issue de secours peut être enregistrée dans le script Playbooks à la première étape de la mise à jour séquentielle. Et si vous avez 100 serveurs et que la taille de la fenêtre de mise à jour successive est de 10, un tel arrêt d'urgence vous donnera le temps de le comprendre calmement, de corriger le script et de continuer la mise à jour.
En cas de panne, Ansible ne continue pas de fonctionner, laissant les systèmes dans un état semi-configuré, et génère une erreur pour attirer l'attention de l'opérateur et lui dire quels hôtes le cycle de mise à jour s'est accompagné d'erreurs et combien de modifications ont été apportées sur chaque plateforme. Ansible a un mode d'exécution de simulation, lorsque le système génère un rapport sur les modifications qui auraient été apportées si le script avait été exécuté sans sa véritable exécution.
Contrôle de conformité
Il existe des environnements où les configurations ne changent que lorsqu'il n'y a aucun moyen sans cela. Tout changement dans de tels environnements est pré-analysé. Il utilise des systèmes de livraison continue «avec réserves».
Ansible a un mode d'exécution de simulation (activé par le drapeau «--check»), lorsque le système génère un rapport sur les modifications qui seraient apportées lors de l'exécution du script. Dans ce cas, l'exécution réelle du script ne se produit pas, la simulation ne permet pas de détecter les erreurs, mais aide à mieux comprendre et analyser les détails et les résultats des modifications proposées.
D'un autre côté, même avec le déploiement continu de nouveaux assemblages, Ansible vous permet d'effectuer des contrôles de conformité beaucoup plus souvent pour saisir le moment où certaines choses dans l'environnement de production changent à la suite d'une intervention humaine et doivent être corrigées en exécutant le script Ansible correspondant, par exemple, pour changer version du logiciel, ajuster les autorisations, etc.
Déploiement du pilote automatique
Si vous vivez dans un monde d'orchestration à plusieurs niveaux et à plusieurs niveaux de processus de mise à jour logicielle séquentielle avec aucun temps d'arrêt, le CI / CD est probablement exécuté exclusivement par les opérateurs (à la fois manuellement et avec une automatisation partielle) et nécessite, comme dans une danse ronde, des actions coordonnées de tous les participants au processus. Ansible ainsi que son architecture unique et l'absence d'agents logiciels sur les hôtes cibles (augmentant la sécurité et éliminant le besoin de gérer le système de gestion lui-même) peuvent facilement décrire et automatiser facilement les processus de déploiement complexes, c'est-à-dire qu'Ansible implémente ici le mode de pilote automatique complet.
Des exemples de scripts d'automatisation Ansible peuvent être trouvés sur
GitHub , et maintenant nous allons donner une base et un exemple de la façon d'écrire un script Playbook qui peut être exécuté dans Ansible ou Ansible Tower. Avec une
liste de modules et d'
autres documents, elle vous aidera à apprendre à créer vos propres scripts Playbooks.
Qu'est-ce qu'un playbook?
Un script Playbook est essentiellement un ensemble de lectures qui est envoyé pour s'exécuter sur un seul hôte distant ou groupe d'hôtes. C'est comme un guide d'assemblage de meubles IKEA: suivez exactement les instructions et obtenez exactement ce que vous avez vu dans le magasin. C’est ainsi que fonctionnent les scripts.
Modules
Nous allons créer un Playbook qui installera le serveur Web sur l'hôte RHEL / CentOS 7 et créera un fichier index.html sur celui-ci en fonction du modèle spécifié dans le script. L'exemple de script présenté ici est entièrement opérationnel et prêt à l'emploi. Ci-dessous, nous allons voir un exemple de script Playbook et montrer comment utiliser les modules.
Auteurs (Auteurs)
Un auteur est quelqu'un qui crée des instructions qui seront exécutées par des modules (souvent avec des valeurs supplémentaires: arguments, emplacements, etc.). Les modules sont exécutés sur l'hôte cible dans l'ordre dans lequel ils suivent dans le script Playbook (y compris include'y et les autres fichiers supplémentaires qui y sont inclus). L'état de l'hôte change (ou ne change pas) en fonction des résultats de l'exécution du module, qui sont affichés sous forme de sortie Ansible et Tower.
Exécution du script Playbook
Tout d'abord, vous devez savoir certaines choses sur l'exécution des scripts Playbook. Playbook est une sorte de système symbolique qui informe le module de la nécessité d'effectuer une tâche. Pour lancer votre Playbook avec succès, il est important de comprendre les points suivants:
1. Système cible (cible)Étant donné que les scripts Playbook fournissent des instructions et interagissent avec les modules, Ansible croit que vous comprenez ce que vous essayez de faire et qu'il automatise simplement. C'est pourquoi nous disons que les Playbooks sont comme des instructions ou des directions: vous dites aux éléments automatisés comment vous souhaitez configurer la tâche. Mais en même temps, vous devez vous-même très bien comprendre comment l'hôte cible sur lequel le script Playbook s'exécute fonctionne.
2. TâchesSi vous devez démarrer un serveur Web dans une partie du Playbook, vous devez comprendre comment cela se fait afin de savoir quel module de service utiliser pour cela et démarrer le serveur Web par son nom. Si le Playbook installe le package logiciel, vous devez savoir comment procéder sur l'hôte cible. Vous devez également comprendre, au moins au niveau de base, l'essence des tâches effectuées. Une configuration d'hôte supplémentaire est-elle requise pour le logiciel que vous souhaitez installer? Existe-t-il des branches en fonction des conditions et des valeurs des arguments? Si des variables sont passées dans le processus, vous devez comprendre exactement quoi et pourquoi.
Exemple de script PlaybookL'exemple de script Playbook suivant vous aidera à comprendre ce que vous venez de lire. L'hôte cible est le serveur RHEL / CentOS 7, sur lequel notre script installe le serveur Web NGINX, puis crée le fichier index.html dans le répertoire webroot par défaut. , -.
*: Playbook Ansible Tower inventory .Playbooks YAML (---), :
Name : , Playbook.
Hosts : , Ansible.
Become : , , nginx ( ).
1 --- 2 - name: Install nginx 3 hosts: host.name.ip 4 become: true
Avec l'indentation comme les trois lignes précédentes, il y a les
tâches : directive, après quoi, avec une indentation supplémentaire (selon les règles d'imbrication YAML), les tâches sont répertoriées (jeux). Dans cet exemple, nous avons deux tâches, et les deux utilisent le module Yum. La première tâche ajoute un référentiel epel-release afin que vous puissiez installer nginx. Une fois epel affiché sur le système, la deuxième tâche installe le package nginx.
La directive
state : signifie qu'Ansible doit vérifier l'état de l'hôte cible avant d'effectuer d'autres actions. Dans notre exemple, s'il existe déjà un référentiel ou nginx sur l'hôte, Ansible comprend qu'il n'est pas nécessaire d'effectuer ces deux tâches et passe aux étapes suivantes.
1 tasks: 2 - name: Add epel-release repo 3 yum: 4 name: epel-release 5 state: present 6 7 - name: Install nginx 8 yum: 9 name: nginx 10 state: present
La page de téléchargement, qui est utilisée par défaut dans nginx, est idéale pour vérifier que nginx s'est correctement installé, mais vous voudrez probablement le faire avec votre fichier html de démarrage. Dans cet exemple, par souci de simplicité, le modèle de fichier d'index se trouve dans le même répertoire où le Playbook démarre. La destination est juste le chemin par défaut dans nginix avec aucun site configuré.
1 - name: Insert Index Page 2 template: 3 src: index.html 4 dest: /usr/share/nginx/html/index.html
La dernière ligne de notre Playbook sert uniquement à vérifier que le service nginx a été démarré avec succès (ou à le démarrer sinon).
1 - name: Start NGiNX 2 service: 3 name: nginx 4 state: started
L'ensemble du script Playbook était à peu près de la même longueur que le paragraphe d'ouverture de ce post:
1 --- 2 - name: Install nginx 3 hosts: host.name.ip 4 become: true 5 6 tasks: 7 - name: Add epel-release repo 8 yum: 9 name: epel-release 10 state: present 11 12 - name: Install nginx 13 yum: 14 name: nginx 15 state: present 16 17 - name: Insert Index Page 18 template: 19 src: index.html 20 dest: /usr/share/nginx/html/index.html 21 22 - name: Start NGiNX 23 service: 24 name: nginx 25 state: started
Résumé
Les scripts Playbook sont un moyen facile et pratique de faire beaucoup de choses avec un peu de code. Dans l'exemple ci-dessus, nous avons utilisé trois modules - yum, modèle et service, pour installer le référentiel et le package logiciel sur le serveur, créer un fichier à partir du modèle local, puis démarrer le service qui vient d'être installé. Dans le même temps, notre script Playbook est sorti un peu plus longtemps que cette offre! Et bien que nous l'ayons exécuté sur un seul hôte, il pourrait tout aussi bien le faire sur des dizaines et des centaines de serveurs, pour cela, il n'a besoin que de très petites modifications. De plus, Tower vous permet de placer un script Playbook dans un modèle de tâche à exécuter sur un groupe de serveurs dans le cloud AWS ou dans un centre de données d'entreprise.
Les fonctionnalités architecturales possibles et la possibilité de s'intégrer aux systèmes CI, comme Jenkins, automatisent non seulement les processus de gestion de la configuration, mais également une gamme beaucoup plus large de tâches informatiques. C'est pourquoi nous appelons affectueusement Ansible un système d'orchestration intégré, et pas seulement un outil de déploiement de logiciel et de gestion de configuration.