Get best of the week

Fil de coupe: migration de Puppet Enterprise vers Ansible Tower. Partie 1

Le National Environmental Satellite Information Service (NESDIS) a réduit ses coûts de gestion de la configuration de Red Hat Enterprise Linux (RHEL) de 35% en passant de Puppet Enterprise à Ansible Tower. Dans cette vidéo de la catégorie «comment nous l'avons fait», l'ingénieur système Michael Rau justifie la mise en œuvre de cette migration, partage des conseils utiles et l'expérience acquise lors de la transition d'un SCM à l'autre.

De cette vidéo, vous apprendrez:

  • Comment justifier la gestion de la faisabilité de passer de Puppet Enterprise à Ansible Tower;
  • quelles stratégies utiliser pour une transition en douceur;
  • conseils pour transcoder les manifestes PE dans Ansible Playbook;
  • Meilleures pratiques pour l'installation d'Ansible Tower.



Salutations à 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) de NESDIS. Aujourd'hui, nous allons parler du découpage de ligne - ma propre expérience de migration de Puppet Enterprise vers Ansible Tower. Le thème de cette présentation est de «regarder mes cicatrices» laissées après avoir fait cette transition en début d'année. Je veux dire ce que j'ai appris au cours de ce processus. Donc, lorsque vous faites cela, en utilisant mon expérience, vous pouvez faire la transition sans trop de difficulté.

Vous voyez des diapositives similaires à cela au début de chaque présentation à Ansible Fest. Cette diapositive montre l'historique 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, comme beaucoup d'autres utilisateurs de ce produit, j'ai été attiré par la possibilité de «trucs» en utilisant la ligne de commande et des scripts simples (playbooks). Fin 2017, je me suis tourné vers mon leadership sur les bonnes raisons de déménager à Ansible Tower. Dans une minute, je parlerai des raisons qui m'ont poussé à franchir cette étape. Après avoir obtenu le consentement de la direction, il a fallu plusieurs mois pour réaliser le plan, et j'ai effectué la transition en janvier-février de cette année. Donc, nous avons complètement abandonné Puppet au profit d'Ansible, et c'est une bonne chose.



Ce qui m'attire le plus chez Ansible, c'est la possibilité d'écrire et d'utiliser des rôles et des scripts (playbooks). Les rôles sont parfaits pour créer des tâches (tâches) différentes mais interdépendantes et pour placer toutes les données liées à ces tâches en un seul endroit. Playbook est la syntaxe YAML, un fichier de script qui décrit les actions pour un ou plusieurs hôtes. Je parle de ces fonctionnalités aux utilisateurs, principalement aux développeurs de logiciels. Ansible Tower permet de dire: "Non, vous n'avez pas accès au 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 des équipements que nous utilisons.



Il s'agit d'un LAN fédéral, 7 sites physiques connectés via MPLS basés sur le cloud, 140 serveurs RHEL, dont 99% sont virtuels (vSphere), du matériel SuperMicro, du NAS NexentaStore, un ensemble de commutateurs Cisco, Arista et Cumulus et des outils de gestion des menaces unifiées Fortinet UTM sur chaque site .

Le réseau fédéral signifie que je dois utiliser tous les moyens de protection de l'information prévus par les actes législatifs. Vous devez garder à l'esprit que Puppet Enterprise ne prend pas en charge la plupart des équipements que nous utilisons. Nous sommes obligés d'utiliser du matériel budgétaire parce que les agences gouvernementales ont du mal à financer ce poste de dépenses. Par conséquent, nous achetons du matériel de classe SuperMicro et assemblons nos équipements à partir de pièces individuelles, dont la maintenance est garantie par des contrats gouvernementaux. Nous utilisons Linux, et c'est l'une des raisons importantes de passer à Ansible.

Notre histoire avec Puppet est la suivante.



En 2007, nous avions un petit réseau de 20-25 nœuds, dans lequel nous avons déployé Puppet. Fondamentalement, ces nœuds n'étaient que des «boîtes» de RedHat. En 2010, nous avons commencé à utiliser l'interface Web Puppet Dashboard pour 45 nœuds. Alors que le réseau continuait de s'étendre, en 2014, nous sommes passés à PE 3.3, effectuant une transition complète avec la réécriture du manifeste pour 75 nœuds. Cela devait être fait parce que Puppet aime changer les règles du jeu, et dans ce cas, ils ont complètement changé la langue. Un an plus tard, lorsque la prise en charge de la version 3 de Puppet Enterprise s'est arrêtée, nous avons été contraints de migrer vers PE 2015.2. J'ai encore une fois dû réécrire le manifeste pour les nouveaux serveurs et acheter une licence avec une réserve de 100 nœuds, même si à l'époque nous n'avions que 85 nœuds.

Seulement 2 ans se sont écoulés, et encore une fois, nous avons dû faire beaucoup de travail pour passer à la nouvelle version de PE 2016.4. Nous avons acheté une licence pour 300 nœuds, avec un total de 130. Nous avons de nouveau dû apporter des modifications majeures au manifeste, car la nouvelle version de la langue avait une syntaxe différente de celle de la version 2015. En conséquence, notre SCM est passé d'un système de contrôle de version SVN à Bitbucket (Git). C'était notre «relation» avec Puppet.

J'ai donc dû expliquer à la direction pourquoi nous devons passer à un autre SCM en utilisant les arguments suivants. Le premier est le prix élevé du service. J'ai parlé avec les gars de RedHat et ils ont dit que le coût de la maintenance d'un réseau de 300 nœuds à l'aide d'Ansible Tower est la moitié du coût de Puppet Enterprise. Si vous achetez un autre moteur Ansible, le coût sera à peu près le même, mais vous obtiendrez beaucoup plus de fonctionnalités que PE. Puisque nous sommes une entreprise d'État financée par le budget fédéral, c'est un argument assez important.



Le deuxième argument est la polyvalence. Puppet prend uniquement en charge le matériel avec un agent Puppet. Cela signifie que vous devez installer un agent sur tous les commutateurs et qu'il doit s'agir de la dernière version. Et si une partie de vos commutateurs prend en charge une version, et une partie - une autre, vous devrez installer une nouvelle version de l'agent PE sur eux afin qu'ils puissent tous fonctionner sur le même système SCM.

Le système Ansible Tower fonctionne différemment car il n'a pas d'agent, mais il existe des modules qui prennent en charge les commutateurs Cisco et tous les autres commutateurs. Ce SCM prend en charge Qubes OS, Linux et 4.NET UTM. Ansible Tower prend également en charge les NAS NexentaStore basés sur le noyau Illumos, un système d'exploitation open source basé sur Unix. C'est très peu de support, mais Ansible Tower le fait quand même.

Le troisième argument, très important pour moi et pour notre administration, est la facilité de développement. J'ai maîtrisé les modules et le code du manifeste Puppet pendant 10 ans, mais j'ai étudié Ansible pendant une semaine, car il est beaucoup plus facile de travailler avec ce SCM. Si vous exécutez des fichiers exécutables, bien sûr, si vous ne le faites pas inutilement, des gestionnaires raisonnables et réactifs travaillent avec eux. Les scripts de playbooks basés sur YAML sont faciles à apprendre et rapides à utiliser. 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 votre travail de développeur, car il est basé sur l'utilisation de Puppet Master. Il s'agit de la seule machine autorisée à communiquer avec les agents Puppet. Si vous avez apporté des modifications au manifeste et souhaitez tester votre code, vous devez réécrire le code du Puppet Master, c'est-à-dire configurer le fichier maître Puppet / etc / hosts pour connecter tous les clients et démarrer le service Puppet Server. Ce n'est qu'alors que vous pouvez tester le fonctionnement de l'équipement réseau sur un hôte. Il s'agit d'une procédure assez douloureuse.
Dans Ansible, tout est beaucoup plus simple. Il suffit de développer du code pour une machine pouvant communiquer via SSH avec l'hôte testé. C'est beaucoup plus facile de travailler avec.

Le prochain gros avantage d'Ansible Tower est la possibilité de tirer parti de votre système de support existant et d'enregistrer votre configuration matérielle existante. Ce SCM sans aucune action supplémentaire utilise toutes les informations disponibles sur votre infrastructure et équipement, machines virtuelles, serveurs, etc. Il peut communiquer avec vos serveurs RH Satellite, le cas échéant, et vous offre une intégration que vous n'obtiendrez jamais lorsque vous travaillez 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, vous devez donc déterminer les aspects existants 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. C'est ainsi que Puppet fonctionne.

La tour vous sauve de cela. Vous pouvez effectuer divers processus sur une grande variété d'équipements sans restrictions, vous pouvez effectuer le travail principal, démarrer d'autres processus importants, configurer le système de sécurité, travailler avec des bases de données. Vous pouvez faire tout ce qui vient avec certaines difficultés dans Puppet Enterprise. Ainsi, si vous avez configuré sur un hôte, il faudra du temps pour que les modifications prennent effet sur les autres hôtes. Dans Ansible, toutes les modifications prennent effet simultanément.

Enfin, considérez le module de sécurité. Dans Ansible Tower, il est mis en œuvre simplement de manière étonnante, avec une grande précision et une minutie. Vous pouvez fournir aux utilisateurs un accès à des services spécifiques ou à des hôtes spécifiques. Je le fais avec mes employés habitués à travailler sur Windows, en leur restreignant l'accès au shell Linux. Je leur donne accès à la Tour afin qu'ils ne puissent faire que le travail et exécuter uniquement les services qui sont de leur compétence.



Examinons à l'avance les choses que vous devez faire pour faciliter la transition vers Ansible Tower. Tout d'abord, il est nécessaire de préparer votre équipement. Si des éléments de votre infrastructure ne figurent pas encore dans la base de données, vous devez les y ajouter. Il existe des systèmes qui ne changent pas leurs caractéristiques et sont donc absents de la base de données Puppet, mais si vous ne les ajoutez pas avant de passer à Tower, vous perdrez un certain nombre d'avantages. Il peut s'agir d'une base de données préliminaire «sale», mais elle devrait contenir des informations sur tout l'équipement dont vous disposez. Par conséquent, vous devez écrire un script matériel dynamique qui apportera automatiquement toutes les modifications d'infrastructure à la base de données, puis Ansible saura quels hôtes devraient être dans le nouveau système. Vous n'aurez pas besoin d'informer ce SCM,quels hôtes vous avez ajoutés et quels hôtes n'existent plus, car elle le saura automatiquement. Plus il y aura de données dans la base de données, plus Ansible sera utile et flexible. Cela fonctionne comme s'il lisait simplement un code-barres de l'état de l'équipement dans la base de données.

Passez un peu de temps à découvrir la ligne de commande dans Ansible. Exécutez des commandes spéciales pour tester le script matériel, écrivez et exécutez des scripts de playbook simples mais utiles, utilisez les modèles Jinja2 le cas échéant. Essayez d'écrire un rôle et un script pour un processus complexe en plusieurs étapes à l'aide d'une configuration matérielle standard fréquemment rencontrée. Jouez avec ces choses, testez comment cela fonctionne. De cette façon, vous apprendrez à travailler avec les outils de création de bibliothèques utilisés dans la tour. J'ai déjà dit qu'il m'a fallu environ 3 mois pour préparer la transition. Je pense que sur la base de mon expérience, vous pourrez le faire plus rapidement. Ne considérez pas ce temps perdu, car plus tard vous ressentirez tous les avantages du travail effectué.

Ensuite, vous devez décider ce que vous attendez d'Ansible Tower, ce que ce système devrait faire exactement pour vous.



Avez-vous besoin de déployer le système sur du matériel vide, sur des machines virtuelles vides? Ou souhaitez-vous conserver les conditions de travail et les réglages d'origine des équipements existants? Il s'agit d'un aspect très important pour le travail des entreprises publiques, vous devez donc être sûr de pouvoir migrer et déployer Ansible sur votre configuration existante. Identifiez les processus administratifs de routine que vous souhaitez automatiser. Découvrez si vous devez déployer des applications et des services spécifiques sur le nouveau système. Faites une liste de ce que vous voulez faire et établissez des priorités.

Commencez ensuite à écrire du code pour les scripts et les rôles qui vous aideront à accomplir vos tâches planifiées. Combinez-les dans Projects, une collection logique de scripts de playbooks pertinents. Chaque projet sera lié à un référentiel Git distinct ou à un autre référentiel en fonction du gestionnaire de code que vous utilisez. Vous pouvez gérer les scripts de playbook et les répertoires de playbook en les plaçant manuellement dans Project Base Path sur le serveur Tower, ou en plaçant le playbook dans n'importe quel système de gestion de code source (SCM) de la tour, y compris Git, Subversion, Mercurial et Red Hat Insights. Dans un même projet, vous pouvez placer autant de scripts que vous le souhaitez. Par exemple, j'ai créé un projet de base, dans lequel j'ai placé un script pour les principaux éléments de RedHat, un script pour les bases de Linux,Scénarios pour les lignes de base restantes. Ainsi, dans un projet, il y avait une grande variété de rôles et de scripts qui étaient gérés à partir d'un référentiel Git.

Exécutez toutes ces choses via la ligne de commande, c'est un bon moyen de tester leurs performances. De cette façon, vous vous préparez pour l'installation de la tour.

Parlons un peu du transcodage du manifeste Puppet, parce que j'y ai passé beaucoup de temps jusqu'à ce que je trouve ce qui devait vraiment être fait.



Comme je l'ai déjà dit, Puppet stocke tous les paramètres et paramètres d'équipement dans un long manifeste, et ce manifeste contient tout ce que ce SCM doit faire. Pendant la transition, 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, scripts, balises, groupes et ce qui devrait y aller. Certains des éléments de réseau autonomes doivent être regroupés en groupes pour lesquels vous pouvez créer des scripts. Des éléments d'infrastructure plus complexes qui impliquent un grand nombre de ressources, y compris des classes autonomes, peuvent être combinés dans des rôles. Avant la migration, vous devez décider de cela. Si vous créez des rôles ou des scripts volumineux qui ne tiennent pas sur un seul écran, vous devez utiliser des balises pour pouvoir capturer des parties individuelles de l'infrastructure.

18:00

Découpage des threads: migration de Puppet Enterprise vers Ansible Tower. Partie 2

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?

More articles:


All Articles