Le service national d'information sur les données par satellite sur l'environnement (NESDIS) a réduit ses coûts de gestion de 35 % en passant de Puppet Enterprise à Ansible Tower avec Red Hat Enterprise Linux (RHEL). Dans cette vidéo de la catégorie « comment nous l'avons fait », l'ingénieur système Michael Rau justifie la réalisation de cette migration, partage des conseils utiles et les expériences acquises lors du passage d'un SCM à un autre.
Dans cette vidéo, vous apprendrez :
- comment justifier à la direction la pertinence du passage de Puppet Enterprise à Ansible Tower ;
- quelles stratégies utiliser pour une transition aussi fluide que possible ;
- des conseils pour la transcoding des manifestes PE en Ansible Playbook ;
- des recommandations pour une installation optimale d'Ansible Tower.
Bonjour à tous, je m'appelle Michael Rau, je suis ingénieur système senior chez ActioNet, qui travaille pour la National Oceanic and Atmospheric Administration (NOAA) du service NESDIS. Aujourd'hui, nous allons parler de l'optimisation des chaînes – mon expérience personnelle de migration de Puppet Enterprise vers Ansible Tower. Le sujet de cette présentation est de « regarder mes cicatrices », laissées après avoir effectué cette transition au début de l'année. Je souhaite partager ce que j'ai appris au cours de ce processus. Ainsi, lorsque vous vous lancerez dans une démarche similaire, en utilisant mon expérience, vous pourrez effectuer la transition sans trop de difficultés.
Vous voyez des diapositives semblables à celle-ci au début de chaque présentation lors d'Ansible Fest. Cette diapositive présente l'histoire de l'automatisation de mon entreprise. Je ne suis pas nouveau dans ce domaine, car j'utilise Puppet/Puppet Enterprise depuis 2007. J'ai commencé à travailler avec Ansible en 2016, et j'ai été, comme beaucoup d'autres utilisateurs de ce produit, intéressé par les possibilités d'« astuces » via la ligne de commande et des scénarios simples (playbooks). À la fin de 2017, j'ai abordé ma direction sur des raisons sérieuses de passer à Ansible Tower. Dans une minute, je vous parlerai des raisons qui m'ont poussé à faire ce pas. Après avoir obtenu l'accord de la direction, il a fallu encore plusieurs mois pour réaliser le projet, et j'ai effectué la transition en janvier-février de cette année. Ainsi, nous avons complètement abandonné Puppet au profit d'Ansible, et c'est une belle avancée.
Ce qui m'attire le plus dans Ansible, c'est la possibilité d'écrire et d'utiliser des rôles et des playbooks. Les rôles sont parfaits pour créer différentes tâches interconnectées et centraliser toutes les données relatives à ces tâches au même endroit. Un playbook est un fichier de script en syntaxe YAML qui décrit les actions pour un ou plusieurs hôtes. Je parle de ces fonctionnalités aux utilisateurs, en particulier aux développeurs de logiciels. Ansible Tower permet de dire : « non, vous n'avez pas accès à un shell, mais je vous donne la possibilité de démarrer tous les processus Tower et de redémarrer le service quand vous en avez besoin ». Je vais vous parler de l'environnement de travail et du matériel que nous utilisons.
C'est un LAN fédéral, avec 7 sites physiques connectés via un MPLS en nuage, 140 serveurs RHEL, dont 99 % sont virtuels (vSphere), du matériel SuperMicro, un stockage réseau NexentaStore, un ensemble de commutateurs Cisco, Arista et Cumulus, ainsi que des outils de gestion unifiée des menaces Fortinet UTM sur chaque site.
Un réseau fédéral signifie que je dois utiliser toutes les mesures de protection des informations prévues par les lois. Vous devez garder à l'esprit que Puppet Enterprise ne prend pas en charge la majeure partie du matériel que nous utilisons. Nous sommes contraints d'utiliser du matériel abordable, car les organismes gouvernementaux rencontrent des problèmes de financement. C'est pourquoi nous achetons du matériel de classe SuperMicro et assemblons notre équipement à partir de composants individuels, dont l'entretien est garanti par des contrats gouvernementaux. Nous utilisons Linux, et c'est l'une des raisons importantes de notre transition vers Ansible.
Notre histoire avec Puppet est la suivante.
En 2007, nous avions un petit réseau de 20 à 25 nœuds, sur lequel nous avons déployé Puppet. Principalement, ces nœuds étaient juste des « boîtiers » RedHat. En 2010, nous avons commencé à utiliser l'interface web Puppet Dashboard pour 45 nœuds. Alors que le réseau continuait à s'étendre, en 2014, nous avons migré vers PE 3.3, réalisant une transition complète avec la réécriture du manifeste pour 75 nœuds. Cela a dû être fait parce que Puppet aime changer les règles du jeu, et dans ce cas, ils ont complètement changé de langage. Un an plus tard, lorsque le support de la version 3 de Puppet Enterprise a pris fin, nous avons dû migrer vers PE 2015.2. Nous avons à nouveau dû réécrire le manifeste pour les nouveaux serveurs et acheter une licence supplémentaire pour 100 nœuds, même si nous n'en avions alors que 85.
Deux ans s'étaient à peine écoulés, et nous avons de nouveau dû effectuer un important travail de migration vers la nouvelle version PE 2016.4. Nous avons acheté une licence pour 300 nœuds, alors que nous n'en avions que 130. Nous avons à nouveau dû apporter de sérieuses modifications au manifeste, car la nouvelle version du langage avait une syntaxe différente de celle de la version 2015. En fin de compte, notre SCM est passée de SVN à Bitbucket (Git). Tels étaient nos « rapports » avec Puppet.
Ainsi, j'ai dû expliquer à la direction pourquoi nous devions passer à un autre SCM, en utilisant les arguments suivants. Le premier est le coût élevé du service. J'ai parlé avec des personnes de RedHat, et ils m'ont dit que le coût de maintenance d'un réseau de 300 nœuds avec Ansible Tower représente la moitié de celui de Puppet Enterprise. Si l'on achète également Ansible Engine, le coût sera à peu près le même, mais avec beaucoup plus de fonctionnalités qu'avec PE. Étant donné que nous sommes une entreprise publique financée par le budget fédéral, c'est un argument assez solide.
Le deuxième argument est la polyvalence. Puppet ne prend en charge que le matériel sur lequel un agent Puppet est installé. Cela signifie que chaque commutateur doit avoir un agent installé, et cet agent doit être de la dernière version. Et si une partie de vos commutateurs supporte une version et une autre partie une autre, vous devrez installer la nouvelle version de l'agent PE sur tous pour qu'ils puissent fonctionner dans le même système SCM.
Le système Ansible Tower fonctionne différemment car il n'a pas d'agents, mais il possède des modules qui prennent en charge les commutateurs Cisco et tous les autres commutateurs. Cette SCM prend en charge Qubes OS, Linux et 4.NET UTM. Ansible Tower prend également en charge les contrôleurs de stockage en réseau NexentaStore, basés sur le noyau Illumos - un système d'exploitation open-source basé sur Unix. C'est un support très limité, mais Ansible Tower le fournit quand même.
Le troisième argument, très important pour moi et pour notre administration, est la facilité d'apprentissage. J'ai passé 10 ans à maîtriser les modules et le code des manifestes Puppet, mais j'ai appris Ansible en une semaine, car ce SCM est beaucoup plus simple à utiliser. Si vous exécutez des fichiers exécutables, bien sûr, à moins que vous ne le fassiez sans nécessité, des gestionnaires raisonnables et réactifs s'en occupent. Les scripts playbooks basés sur YAML se caractérisent par un apprentissage facile et une rapidité d'utilisation. Ceux qui n'ont jamais entendu parler de YAML auparavant peuvent simplement lire les scripts et comprendre facilement comment cela fonctionne.
Honnêtement, Puppet complique beaucoup votre travail en tant que développeur car il repose sur l'utilisation du Puppet Master. C'est la seule machine qui a le droit de communiquer avec les agents Puppet. Si vous apportez des modifications à un manifeste et souhaitez tester votre code, vous devez réécrire le code pour le Puppet Master, c'est-à-dire configurer le fichier Puppet-master /etc/hosts pour connecter tous les clients et lancer le service Puppet Server. Ce n'est qu'après cela que vous pourrez tester le matériel réseau sur un seul hôte. C'est une procédure assez douloureuse.
Dans Ansible, tout est beaucoup plus simple. Tout ce que vous devez faire est de développer le code pour une machine capable de se connecter via le protocole SSH à l'hôte testé. C'est beaucoup plus facile à gérer.
Un autre grand avantage d'Ansible Tower est la possibilité d'utiliser votre système de support existant et de conserver la configuration de votre matériel. Cette SCM utilise toutes les informations sur votre infrastructure et vos équipements, machines virtuelles, serveurs, etc., sans aucune action supplémentaire. Elle peut communiquer avec vos serveurs RH Satellite, le cas échéant, et vous offre une intégration que vous n'obtiendrez jamais en travaillant avec Puppet.
Une autre chose importante est le contrôle détaillé. Vous savez que Puppet est un système modulaire, c'est une application client-serveur, donc vous devez définir tous les aspects du fonctionnement de toutes vos machines dans un long manifeste. Dans ce cas, l'état de chaque élément individuel du système doit être testé toutes les demi-heures – c'est la période par défaut. Voici comment fonctionne Puppet.
Tower vous en libère. Vous pouvez exécuter sans restrictions une grande variété de processus sur le matériel le plus divers, effectuer des tâches essentielles, lancer d'autres processus importants, configurer la sécurité, travailler avec des bases de données. Vous pouvez faire tout ce qui présente des difficultés dans Puppet Enterprise. Ainsi, si vous avez configuré un hôte, il faudra du temps pour que les modifications prennent effet sur les autres hôtes. Dans Ansible, tous les changements sont appliqués simultanément.
Enfin, examinons le module de sécurité. Dans Ansible Tower, il est implémenté de manière absolument incroyable, avec une grande précision et un soin méticuleux. Vous pouvez fournir aux utilisateurs un accès à des services spécifiques ou à des hôtes spécifiques. Je fais cela avec mes employés qui sont habitués à travailler sous Windows, en restreignant leur accès à la console Linux. Je leur donne un accès à Tower qui ne leur permet d'exécuter que le travail et de lancer uniquement les services qui relèvent de leur compétence.
Examinons les éléments à préparer à l'avance pour faciliter la transition vers Ansible Tower. Tout d'abord, il est nécessaire de préparer votre équipement. Si certains éléments de votre infrastructure sont absents de la base de données, ils doivent y être ajoutés. Il existe des systèmes dont les caractéristiques ne changent pas et qui sont donc absents de la base de données Puppet, mais si vous ne les ajoutez pas avant de passer à Tower, vous perdrez plusieurs avantages. Cela peut être une base de données préliminaire « sale », mais elle doit contenir des informations sur tout l'équipement dont vous disposez. Vous devez donc rédiger un script dynamique pour votre équipement qui mettra automatiquement à jour tous les changements d'infrastructure dans la base de données, permettant à Ansible de savoir quels hôtes doivent être présents dans le nouveau système. Vous n'aurez pas besoin d'informer ce SCM des hôtes que vous avez ajoutés ou de ceux qui n'existent plus, car tout cela sera découvert automatiquement. Plus il y aura de données dans la base de données, plus Ansible sera utile et flexible. Il fonctionne comme s'il lisait simplement l'état de l'équipement à partir de la base de données.
Consacrez un certain temps à vous familiariser avec les commandes en ligne dans Ansible. Exécutez quelques commandes spéciales pour tester le fonctionnement du script d'équipement, écrivez et lancez de simples mais utiles scripts playbook, utilisez des modèles Jinja2 là où cela est pertinent. Essayez d'écrire un rôle et un script pour un processus complexe en plusieurs étapes, en utilisant une configuration d'équipement standard et courante. Expérimentez avec ces éléments, testez leur fonctionnement. Ainsi, vous apprendrez à travailler avec les outils pour créer les bibliothèques utilisées dans Tower. J'ai déjà mentionné que ma préparation à la transition a duré environ 3 mois. Je pense qu'en vous appuyant sur mon expérience, vous pourrez le faire plus rapidement. Ne considérez pas ce temps comme perdu, car plus tard vous ressentirez tous les avantages du travail accompli.
Ensuite, il faut déterminer ce que vous attendez d'Ansible Tower, ce que ce système doit concrètement faire pour vous.
Avez-vous besoin de déployer le système sur du matériel vierge, sur des machines virtuelles vides ? Ou souhaitez-vous conserver les conditions de travail initiales et les configurations de votre matériel existant ? C'est un aspect très important pour le fonctionnement des entreprises publiques, donc vous devez être sûr de pouvoir effectuer la migration et déployer Ansible sur la configuration existante. Déterminez les processus administratifs routiniers que vous souhaitez automatiser. Découvrez si vous devez déployer des applications et des services spécifiques sur le nouveau système. Dressez une liste de ce que vous souhaitez faire et établissez des priorités.
Ensuite, commencez à écrire le code des scripts et des rôles qui garantiront l'exécution des tâches que vous avez prévues. Regroupez-les dans des Projects, une collection logique de scripts playbooks correspondants. Chaque Project sera associé à un dépôt Git distinct ou à un autre dépôt en fonction de l'outil de gestion de code que vous utilisez. Vous pouvez gérer les scripts playbook et les répertoires de playbook en les plaçant manuellement dans le Project Base Path sur le serveur Tower, ou en plaçant le playbook dans tout système de gestion de code source (SCM) pris en charge par Tower, y compris Git, Subversion, Mercurial et Red Hat Insights. Au sein d'un même Project, vous pouvez inclure autant de scripts que vous le souhaitez. Par exemple, j'ai créé un Project de base dans lequel j'ai placé un script pour les éléments de base de RedHat, un script pour le système Linux, ainsi que des scripts pour d'autres indicateurs de base. Ainsi, un seul projet contenait une grande variété de rôles et de scripts gérés à partir d'un seul dépôt Git.
Exécutez toutes ces commandes via la ligne de commande, c'est un bon moyen de vérifier leur bon fonctionnement. Cela vous préparera à l'installation de Tower.
Parlons un peu de la transcoding du manifeste Puppet, car j'ai passé beaucoup de temps là-dessus avant de comprendre ce qu'il fallait vraiment faire.
Comme je l'ai déjà mentionné, Puppet stocke toutes les configurations et paramètres matériels dans un long manifeste, et c'est dans ce manifeste que se trouve tout ce que doit faire ce SCM. Lors de la migration, vous n'avez pas besoin de regrouper toutes vos tâches dans une seule liste, pensez plutôt à la structure du nouveau système : rôles, scénarios, balises, groupes et ce qui doit y être inclus. Certains des éléments autonomes du réseau doivent être regroupés en groupes pour lesquels des scénarios peuvent être créés. Les éléments d'infrastructure plus complexes, qui utilisent une grande quantité de ressources, y compris les classes autonomes, peuvent être regroupés en rôles. Avant la migration, vous devez trancher là-dessus. Si vous créez de grands rôles ou scénarios qui ne tiennent pas sur un seul écran, vous devriez utiliser des balises pour pouvoir capturer des parties distinctes de l'infrastructure.
18:00
Un peu de publicité 🙂
Merci de rester avec nous. Aimez-vous nos articles ? Voulez-vous voir plus de contenu intéressant ? Soutenez-nous en passants une commande ou en nous recommandant à des amis, , un équivalent unique des serveurs d'entrée de gamme, conçu pour vous : (options disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go DDR4).
Dell R730xd deux fois moins cher dans le data center Equinix Tier IV à Amsterdam ? Uniquement chez nous aux Pays-Bas ! Dell R420 — 2x E5-2430 2.2GHz 6C 128Go DDR3 2x960Go SSD 1Gbps 100To — à partir de 99 $ ! Lisez sur
Source : habr.com
