Ceci est une transcription du discours и .
C'est l'histoire d'un projet qui utilisait un système de gestion de configuration auto-écrit et pourquoi le passage à Ansible a pris 18 mois.
Jour n° -ХХХ : Avant le début
Initialement, l'infrastructure se composait de nombreux hôtes distincts exécutant Hyper-V. La création d'une machine virtuelle a nécessité de nombreuses étapes : placer les disques au bon endroit, enregistrer le DNS, réserver le DHCP, mettre la configuration de la VM dans le référentiel git. Ce processus était partiellement mécanisé, mais par exemple, les machines virtuelles étaient distribuées manuellement entre les hôtes. Mais, par exemple, les développeurs pourraient corriger la configuration de la VM dans git et l'appliquer en redémarrant la VM.
Solution de gestion de configuration personnalisée
L'idée originale, je suppose, a été conçue comme IaC : de nombreuses machines virtuelles sans état qui réinitialisent leur état à zéro lors du redémarrage. Qu’est-ce que la gestion de la configuration des VM ? Schématiquement, cela semble simple :
- Un MAC statique a été défini pour la VM.
- Un ISO avec CoreOS et un disque de démarrage étaient connectés à la VM.
- CoreOS lance le script de personnalisation en le téléchargeant depuis le serveur WEB en fonction de son IP.
- Le script télécharge la configuration de la VM via SCP en fonction de l'adresse IP.
- Le chausson des fichiers unitaires systemd et le chausson des scripts bash sont lancés.
Cette solution présentait de nombreux problèmes évidents :
- CoreOS ISO est obsolète.
- Beaucoup d'actions automatisées complexes et de magie lors de la migration/création de VM.
- Difficulté avec la mise à jour et lorsqu'une certaine version du logiciel est nécessaire. Encore plus amusant avec les modules du noyau.
- Les machines virtuelles n'ont pas été obtenues sans données, c'est-à-dire Les machines virtuelles sont apparues avec un disque avec des données utilisateur supplémentaires montées.
- Quelqu'un était constamment en train de bousiller les dépendances de l'unité systemd et CoreOS se bloquait au redémarrage. Il était difficile de détecter cela en utilisant les outils disponibles dans CoreOS.
- Gestion des secrets.
- Il n'y avait pas de CM. Il y avait des configurations bash et YML pour CoreOS.
Pour appliquer la configuration de la VM, vous devez la redémarrer, mais il se peut qu'elle ne redémarre pas. Cela semble être un problème évident, mais il n'y a pas de disques persistants - il n'y a nulle part où enregistrer les journaux. Bon, ok, essayons d'ajouter l'option de chargement du noyau pour que les logs soient envoyés. Mais non, comme tout cela est compliqué.
Jour n°0 : Reconnaître le problème
Il s'agissait de l'infrastructure de développement habituelle : jenkins, environnements de test, surveillance, registre. CoreOS a été conçu pour héberger des clusters k8s, c'est-à-dire le problème était de savoir comment CoreOS était utilisé. La première étape consistait à choisir une pile. Nous avons opté pour :
- CentOS comme distribution de base, car Il s'agit de la distribution la plus proche des environnements de production.
- Ansible pour la gestion de la configuration, car il y a eu un examen approfondi à ce sujet.
- Jenkins comme cadre d'automatisation des processus existants, car il a déjà été activement utilisé pour les processus de développement
- Hyper-V en tant que plateforme de virtualisation. Il existe un certain nombre de raisons qui dépassent le cadre de l'histoire, mais en bref : nous ne pouvons pas utiliser les nuages, nous devons utiliser notre propre matériel.
Jour n°30 : Réparer les accords existants - Les accords comme code
Une fois la pile dégagée, les préparatifs du déplacement commencèrent. Fixation des accords existants sous forme de code (Accords comme code!). Transition travail manuel -> mécanisation -> automatisation.
1. Configurer les machines virtuelles
Ansible fait un excellent travail à cet égard. Avec un minimum de mouvements corporels, vous pouvez prendre le contrôle des configurations des VM :
- Créez un référentiel git.
- Nous mettons la liste des VM en inventaire, les configurations dans les playbooks et les rôles.
- Nous mettons en place un esclave Jenkins spécial à partir duquel vous pouvez exécuter Ansible.
- Nous créons un travail et configurons Jenkins.
Le premier processus est prêt. Les accords sont fixes.
2. Créer une nouvelle VM
Ici, tout n’était pas très pratique. Il n'est pas très pratique de créer des VM sur Hyper-V depuis Linux. L'une des tentatives visant à mécaniser ce processus a été :
- Ansbile se connecte via WinRM à l'hôte Windows.
- Ansible exécute un script PowerShell.
- Le script Powershell crée une nouvelle VM.
- À l'aide d'Hyper-V/ScVMM, lors de la création d'une VM dans le système d'exploitation invité, le nom d'hôte est configuré.
- Lors de la mise à jour du bail DHCP, la VM envoie son nom d'hôte.
- L'intégration DDNS et DHCP standard du côté du contrôleur de domaine configure l'enregistrement DNS.
- Vous pouvez ajouter une VM à votre inventaire et la configurer avec Ansible.
3.Créer un modèle de VM
Ici, ils n'ont rien inventé - ils ont pris un emballeur.
- Ajoutez le packer, la configuration kickstart au référentiel git.
- Mise en place d'un esclave Jenkins spécial avec Hyper-V et Packer.
- Nous créons un travail et configurons Jenkins.
Comment fonctionne ce lien :
- Packer crée une VM vide et récupère l'ISO.
- La VM démarre, Packer entre la commande dans le chargeur de démarrage pour utiliser notre fichier kickstart à partir d'une disquette ou http.
- Anaconda est lancé avec notre configuration et la configuration initiale du système d'exploitation est effectuée.
- Packer attend que la VM soit disponible.
- Packer à l'intérieur de la VM exécute ansible en mode local.
- Ansible utilise exactement les mêmes rôles qu'à l'étape 1.
- Packer exporte le modèle de VM.
Jour #75 : Refactoriser l'accord sans rompre = Test ansible + Testkitchen
Capturer les conventions dans le code peut ne pas suffire. Après tout, si dans les tenants et les aboutissants du processus vous souhaitez changer quelque chose, vous pouvez casser quelque chose. Par conséquent, dans le cas de l’infrastructure, des tests sur cette même infrastructure apparaissent. Pour synchroniser les connaissances au sein de l'équipe, nous avons commencé à tester les rôles Ansible. Je n'entrerai pas dans les détails parce que... il y a un article décrivant les événements à ce moment-là (spoiler ce n'était pas la version finale et après tout est devenu plus compliqué ).
Jour #130 : Peut-être que CentOS+ansible n'est pas nécessaire ? peut-être openshift ?
Nous devons comprendre que le processus d'introduction des infrastructures n'était pas le seul et qu'il y avait des sous-projets parallèles. Par exemple, une demande est arrivée pour lancer notre application en openshift et cela a donné lieu à des recherches de plus d'une semaine ce qui a ralenti le processus de déménagement. Le résultat s'est avéré qu'openshift ne couvre pas tous les besoins : il faut du vrai matériel, ou au moins la possibilité de jouer avec le noyau.
Jour #170 : Openshift ne convient pas, tentons notre chance avec Windows Azure Pack ?
Hyper-V n'est pas très convivial, SCVMM ne l'améliore pas beaucoup. Mais il existe Windows Azure Pack, qui est un module complémentaire à SCVMM et imite Azure. Mais en réalité, le produit semble abandonné : la documentation comporte des liens rompus et est très clairsemée. Mais dans le cadre de l’étude des options permettant de simplifier la vie de notre cloud, ils l’ont également examiné.
Jour #250 : Pack Windows Azure pas très bon. Nous restons sur SCVMM
Windows Azure Pack semblait prometteur, mais il a été décidé de ne pas introduire le WAP et ses complexités dans le système au profit de fonctionnalités inutiles et de rester avec SCVMM.
Jour #360 : Manger l'éléphant morceau par morceau
Seulement un an plus tard, la plateforme de déménagement était prête et le processus de déménagement commençait. A cet effet, une tâche SMART a été définie. Nous avons vérifié toutes les machines virtuelles et commencé à comprendre la configuration une par une, à la décrire dans Ansible et à la couvrir de tests.
Jour #450 : Quel type de système avez-vous obtenu ?
Le processus en lui-même n'est pas intéressant. C'est routine, on peut constater que la plupart des configurations étaient relativement simples ou isomorphes et selon le principe de Pareto, 80% des configurations de VM nécessitaient 20% du temps. Selon le même principe, 80 % du temps a été consacré à la préparation du déménagement et seulement 20 % au déménagement lui-même.
Jour #540 : Finale
Que s'est-il passé en 18 mois ?
- Les accords sont devenus un code.
- Travail manuel -> Mécanisation -> Automation.
Cardan
Source: habr.com