Le National Environmental Satellite Data Information Service (NESDIS) a réduit ses coûts de gestion de configuration pour Red Hat Enterprise Linux (RHEL) de 35 % en migrant de Puppet Enterprise vers Ansible Tower. Dans cette vidéo « comment nous l'avons fait », l'ingénieur système Michael Rau explique les arguments en faveur de cette migration, partageant des conseils utiles et les leçons apprises lors du passage d'un SCM à un autre.
À partir de cette vidéo, vous apprendrez :
- comment justifier auprès de la direction la faisabilité du passage de Puppet Enterprise à Ansible Tower ;
- quelles stratégies utiliser pour rendre la transition aussi fluide que possible ;
- des conseils pour transcoder les manifestes PE dans Ansible Playbook ;
- 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 le service NESDIS de la National Oceanic and Atmospheric Administration (NOAA). Aujourd'hui, nous allons parler de la réduction des chaînes - ma propre expérience de migration de Puppet Enterprise vers Ansible Tower. Le thème de cette présentation est de « jeter un œil à mes cicatrices » laissées après avoir effectué cette transition plus tôt dans l’année. Je souhaite partager ce que j’ai appris grâce à ce processus. Ainsi, lorsque vous entreprenez quelque chose comme celui-ci, grâce à mon expérience, vous pouvez effectuer la transition sans aucun travail supplémentaire.
Vous voyez des diapositives similaires à celle-ci au début de chaque présentation à Ansible Fest. Cette diapositive présente 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 » utilisant la ligne de commande et des scripts simples (playbooks). Fin 2017, j'ai contacté ma direction pour connaître les bonnes raisons de migrer vers Ansible Tower. Dans une minute, je vous parlerai des raisons qui m'ont poussé à franchir cette étape. Après avoir reçu l'accord de la direction, il a fallu encore plusieurs mois pour finaliser le plan, et j'ai effectué la transition en janvier-février de cette année. Nous avons donc 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 capacité d'écrire et d'utiliser des rôles et des playbooks. Les rôles sont parfaits pour créer des tâches distinctes mais liées et pour regrouper toutes les données liées à ces tâches au même endroit. Un playbook est une syntaxe YAML, un fichier de script qui décrit les actions d'un ou plusieurs hôtes. Je parle de ces fonctionnalités aux utilisateurs, principalement aux développeurs de logiciels. Ansible Tower vous donne la possibilité de dire : « non, vous n'avez pas accès au shell, mais je vous donne la possibilité d'exécuter tous les processus Tower et de redémarrer le service lorsque vous en avez besoin. » Je vous parlerai de l'environnement de travail et des équipements que nous utilisons.
Il s'agit d'un LAN fédéral, de 7 sites physiques connectés via cloud MPLS, de 140 serveurs RHEL dont 99% virtuels (vSphere), de matériel SuperMicro, de stockage réseau NexentaStore, d'un ensemble de commutateurs Cisco, Arista et Cumulus et d'une gestion unifiée des menaces Fortinet UTM. outils sur chaque site .
Le réseau fédéral m'oblige à utiliser toutes les mesures de sécurité des informations prévues par la loi. Gardez à l’esprit que Puppet Enterprise ne prend pas en charge la plupart du matériel que nous utilisons. Nous sommes obligés d'utiliser du matériel budgétaire car les agences gouvernementales ont des difficultés à financer ce poste de dépense. C'est pourquoi nous achetons du matériel SuperMicro et assemblons nos équipements à partir de pièces détachées dont la maintenance est garantie par des contrats gouvernementaux. Nous utilisons Linux et c'est l'une des raisons importantes pour lesquelles nous passons à Ansible.
Notre histoire avec Puppet est la suivante.
En 2007, nous disposions d'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 » 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, nous sommes passés à PE 2014 en 3.3, effectuant une transition complète avec une 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é le langage. Un an plus tard, lorsque le support de la version 3 de Puppet Enterprise a pris fin, nous avons été contraints de migrer vers PE 2015.2. Nous avons dû réécrire le manifeste pour les nouveaux serveurs et acheter une licence avec une réserve de 100 nœuds, alors qu'à l'époque nous n'avions que 85 nœuds.
Seulement 2 ans se sont écoulés et nous avons encore dû faire beaucoup de travail pour migrer vers la nouvelle version PE 2016.4. Nous avons acheté une licence pour 300 nœuds, n'en ayant que 130. Nous avons encore dû apporter des modifications majeures au manifeste car la nouvelle version du langage avait une syntaxe différente de celle du langage de la version 2015. En conséquence, notre SCM est passé du contrôle de version SVN à Bitbucket (Git). C'était notre « relation » avec Puppet.
J'ai donc dû expliquer à la direction pourquoi nous devions passer à un autre SCM en utilisant les arguments suivants. Le premier est le prix élevé du service. J'ai parlé aux gars de RedHat et ils m'ont dit que le coût de fonctionnement d'un réseau à 300 nœuds avec Ansible Tower était la moitié du coût de Puppet Enterprise. Si vous achetez également Ansible Engine, 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 publique financée par le budget fédéral, c’est un argument assez puissant.
Le deuxième argument est la polyvalence. Puppet ne prend en charge que le matériel doté d'un agent Puppet. Cela signifie qu'un agent doit être installé sur tous les commutateurs et qu'il doit s'agir de la dernière version. Et si certains de vos commutateurs prennent en charge une version et d'autres une autre, vous devrez y installer une nouvelle version de l'agent PE afin qu'ils puissent tous fonctionner dans le même système SCM.
Le système Ansible Tower fonctionne différemment car il ne dispose d'aucun agent, mais il dispose de modules prenant 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 contrôleurs de stockage réseau 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 tant pour moi que pour notre administration, est la facilité d'utilisation. J'ai passé 10 ans à maîtriser les modules Puppet et le code manifeste, mais j'ai appris Ansible en une semaine car ce SCM est beaucoup plus facile à utiliser. Bien sûr, si vous exécutez des fichiers exécutables, à moins que vous ne le fassiez inutilement, des gestionnaires intelligents et réactifs travailleront avec eux. Les 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 son fonctionnement.
Pour être honnête, Puppet rend votre travail de développeur beaucoup plus difficile car il est basé sur l'utilisation de Puppet Master. C'est 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 de Puppet Master, c'est-à-dire configurer le fichier /etc/hosts de Puppet Master pour connecter tous les clients et démarrer le service Puppet Server. Ce n'est qu'après cela que vous pourrez tester le fonctionnement des équipements réseau sur un hôte. C'est une procédure plutôt douloureuse.
Tout est beaucoup plus simple dans Ansible. Tout ce que vous avez à faire est de développer du code pour une machine capable de communiquer via SSH avec l'hôte testé. C'est beaucoup plus facile à travailler.
Le prochain grand avantage d'Ansible Tower est la possibilité d'exploiter votre système de support existant et de maintenir votre configuration matérielle existante. Ce SCM utilise toutes les informations disponibles sur votre infrastructure et votre matériel, vos machines virtuelles, vos serveurs, etc. sans aucune étape supplémentaire. Il peut communiquer avec vos serveurs RH Satellite, si vous en avez un, et vous offre des intégrations que vous n'obtiendrez jamais avec Puppet.
Une autre chose importante est un contrôle détaillé. Vous savez que Puppet est un système modulaire, c'est une application client-serveur, vous devez donc définir les aspects existants de toutes vos machines dans un long manifeste. Dans ce cas, l'état de chaque élément du système doit être testé toutes les demi-heures - c'est la période par défaut. C'est ainsi que fonctionne Puppet.
Tower vous en épargne. Vous pouvez exécuter une variété de processus sur une variété d'équipements sans restrictions ; vous pouvez effectuer un travail de base, exécuter d'autres processus importants, configurer un système de sécurité et travailler avec des bases de données. Vous pouvez faire tout ce qui est difficile dans Puppet Enterprise. Ainsi, si vous l'avez configuré sur un hôte, il faudra du temps pour que les modifications prennent effet sur les hôtes restants. Dans Ansible, toutes les modifications prennent effet en même temps.
Enfin, regardons le module de sécurité. Ansible Tower l'implémente de manière tout simplement incroyable, avec beaucoup de précision et de soin. Vous pouvez accorder aux utilisateurs l'accès à des services spécifiques ou à des hôtes spécifiques. Je fais cela avec mes employés habitués à travailler sous Windows, en limitant leur accès au shell Linux. Je m'assure qu'ils ont accès à Tower afin qu'ils puissent uniquement effectuer le travail et gérer uniquement les services qui les concernent.
Examinons les choses que vous devez faire à l'avance pour faciliter votre transition vers Ansible Tower. Tout d’abord, vous devez préparer votre matériel. Si certains éléments de votre infrastructure ne sont pas déjà dans la base de données, vous devez les y ajouter. Il existe des systèmes qui ne modifient pas leurs caractéristiques et ne figurent donc pas dans 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 s’agit peut-être d’une base de données préliminaire « sale », mais elle doit contenir des informations sur tout l’équipement dont vous disposez. Par conséquent, vous devez écrire un script matériel dynamique qui transmettra automatiquement toutes les modifications d'infrastructure dans la base de données. Ansible saura alors quels hôtes doivent être présents sur le nouveau système. Vous n'aurez pas besoin d'indiquer à ce SCM quels hôtes vous avez ajoutés et quels hôtes n'existent plus, car il saura tout cela automatiquement. Plus il y a de données dans la base de données, plus Ansible sera utile et flexible. Cela fonctionne comme s'il lisait simplement le code-barres d'état du matériel à partir d'une base de données.
Passez du temps à vous familiariser avec la ligne de commande dans Ansible. Exécutez des commandes personnalisées 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 courante et couramment rencontrée. Jouez avec ces choses, testez comment cela fonctionne. De cette façon, vous apprendrez à utiliser les outils de création de bibliothèque utilisés dans Tower. J'ai déjà dit qu'il m'a fallu environ 3 mois pour préparer la transition. Je pense que d'après mon expérience, vous pourrez le faire plus rapidement. Ne considérez pas ce temps comme une perte, car plus tard vous ressentirez tous les bénéfices 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 nu, sur des machines virtuelles nues ? Ou souhaitez-vous conserver les conditions de fonctionnement et les réglages d’origine des équipements existants ? Il s'agit d'un aspect très important pour les 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 priorisez-la.
Commencez ensuite à écrire du code de script et des rôles qui permettront les tâches que vous prévoyez d'accomplir. Combinez-les dans des projets, une collection logique de playbooks pertinents. Chaque projet appartiendra à un référentiel Git distinct ou à un référentiel différent selon le gestionnaire de code que vous utilisez. Vous pouvez gérer les scripts et les répertoires du playbook en les plaçant manuellement dans le chemin de base du projet sur le serveur Tower, ou en plaçant le playbook dans n'importe quel système de gestion de code source (SCM) pris en charge par Tower, notamment Git, Subversion, Mercurial et Red Hat. Connaissances. Dans un 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 éléments principaux de RedHat, un script pour le noyau Linux et des scripts pour le reste des lignes de base. Ainsi, dans un projet, une variété de rôles et de scénarios étaient gérés à partir d'un seul référentiel Git.
Exécuter toutes ces choses via la ligne de commande est un bon moyen de tester leur fonctionnalité. Cela vous préparera à l’installation de la tour.
Parlons un peu du transcodage du manifeste Puppet, car j'ai passé beaucoup de temps là-dessus jusqu'à ce que je comprenne ce qui devait réellement être fait.
Comme je l'ai déjà dit, Puppet stocke tous les paramètres et options matérielles dans un long manifeste, et ce manifeste stocke tout ce que ce SCM doit faire. Lors de 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 être placé. Certains éléments du réseau autonome doivent être regroupés en groupes pour lesquels des scripts peuvent être créés. Des éléments d'infrastructure plus complexes qui impliquent un grand nombre de ressources, y compris des classes autonomes, peuvent être combinés en rôles. Avant de migrer, vous devez en décider. Si vous créez des rôles ou des scénarios volumineux qui ne tiennent pas sur un seul écran, vous devez utiliser des balises pour pouvoir capturer des parties spécifiques de l'infrastructure.
18:00
Quelques publicités 🙂
Merci de rester avec nous. Vous aimez nos articles ? Vous voulez voir du contenu plus intéressant ? Soutenez-nous en passant une commande ou en recommandant à vos amis, , un analogue unique des serveurs d'entrée de gamme, que nous avons inventé pour vous : (disponible avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).
Dell R730xd 2 fois moins cher dans le centre de données Equinix Tier IV à Amsterdam ? Ici seulement aux Pays-Bas! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - à partir de 99$ ! En savoir plus
Source: habr.com