🥇Ansible : Migration de la configuration de 120 VM de CoreOS vers CentOS en 18 mois

Ceci est la transcription de la présentation à DevopsConf 2019-10-01 et SPbLUG 2019-09-25.

C'est l'histoire d'un projet qui utilisait un système de gestion des configurations fait maison et pourquoi la migration vers Ansible a duré 18 mois.

Jour n° -XXX : Avant le début

Au départ, l'infrastructure se composait de plusieurs hôtes autonomes gérés par Hyper-V. Créer une machine virtuelle nécessitait de nombreuses actions : placer les disques au bon endroit, configurer le DNS, réserver le DHCP, placer la configuration de la VM dans un dépôt git. Ce processus était partiellement automatisé, mais par exemple, les VMs étaient réparties entre les hôtes manuellement. Cependant, les développeurs pouvaient appliquer une configuration de VM en la modifiant dans git et en redémarrant la VM.

Solution de gestion de configuration personnalisée

L'idée de départ, je le soupçonne, était conçue comme IaC : de nombreuses VMs sans état, qui réinitialisaient leur état lors du redémarrage. Que représentait la gestion des configurations des VMs ? Cela semblait simple schématiquement :

Pour les VMs, un MAC statique était fixé.
On connectait à la VM un ISO avec CoreOS et un disque de démarrage.
CoreOS exécute un script de personnalisation en le téléchargeant depuis un serveur WEB en fonction de son IP.
Le script récupère la configuration de la VM via SCP en se basant sur l'adresse IP.
Une série de fichiers unitaires systemd et une série de scripts bash sont lancés.

Cette solution avait de nombreux problèmes évidents :

L'ISO dans CoreOS était obsolète.
Nombreux actes et magie difficilement automatissables lors de la migration/création des VMs.
Difficulté de mise à jour lorsque certains logiciels nécessitent une version donnée. C’est encore plus amusant avec les modules du noyau.
Les VMs n'étaient pas si dépourvues de données, c'est-à-dire qu'il y avait des VMs avec un disque monté contenant des données utilisateur en supplément.
Quelqu'un avait constamment des problèmes avec les dépendances des unités systemd et lors du redémarrage, CoreOS se bloquait. Il était difficile de repérer ça avec les outils disponibles dans CoreOS.
Gestion des secrets.
La gestion de configuration était quasiment inexistante. Il y avait des scripts bash et des configurations YML de CoreOS.

Pour appliquer la configuration de la VM, il fallait la redémarrer, mais elle pouvait ne pas redémarrer. Cela semble être un problème évident, mais il n'y avait pas de disques persistants — les journaux n'avaient nulle part où être enregistrés. Eh bien, d'accord, essayons d'ajouter des options de démarrage du noyau pour transmettre les journaux. Mais non, tout cela est si compliqué.

Jour n°0 : Reconnaissance du problème

C'était une infrastructure de développement classique : jenkins, environnements de test, surveillances, registry. CoreOS était conçu pour l'hébergement de clusters k8s, c'est-à-dire que le problème était comment CoreOS était utilisé. La première étape a été de choisir la stack. Nous avons opté pour :

CentOS comme distribution de base, car c'est la distribution la plus proche des environnements de production.
Ansible pour la gestion des configurations, car il y avait une vaste expertise à ce sujet.
Jenkins comme framework d'automatisation des processus existants, car il était déjà utilisé de manière active pour les processus de développement.
Hyper-V comme plateforme de virtualisation. Il y a plusieurs raisons qui vont au-delà de ce récit, mais en résumé — nous ne pouvons pas utiliser le cloud, nous devons utiliser notre propre matériel.

Jour n°30 : Formalisation des accords existants — Agreements as Code

Une fois la stack définie, la préparation à la migration a commencé. Formaliser les accords existants sous forme de code (Agreements as Code!). Migration travail manuel -> mécanisation -> qui permet de tester, déployer et livrer de nouvelles fonctionnalités aux utilisateurs beaucoup plus rapidement. Par exemple, dans tous nos projets, un pipeline CI est automatiquement créé à chaque commit. Celui-ci construit l'image, la teste, la déploie dans divers environnements Kubernetes pour le débogage et les vérifications restantes, et si tout va bien, les modifications atteignent l'utilisateur final. Ce n'est plus une science-fusée, mais une banalité pour beaucoup — probablement pour vous également, puisque vous lisez cet article..

1. Configurer les VM

Ansible gère très bien cette tâche. Avec un minimum d'efforts, nous pouvons prendre en charge les configurations des VM :

Créons un dépôt git.
Nous plaçons la liste des VM dans l'inventaire, les configurations dans des playbooks et des rôles.
Nous configurons un esclave jenkins spécial à partir duquel nous pourrons exécuter ansible.
Créons un job, configurons Jenkins.

Le premier processus est prêt. Les accords sont formalisés.

2. Créer une nouvelle VM

Ici, tout n'était pas très pratique. Il n'est pas très commode de créer des VM sous Hyper-V depuis Linux. Une des tentatives de mécaniser ce processus a été :

Ansible se connecte via WinRM à l'hôte Windows.
Ansible exécute un script powershell.
Le script Powershell crée une nouvelle VM.
Avec Hyper-V/ScVMM, lors de la création de la VM, le nom d'hôte est configuré dans le système d'exploitation invité.
La VM, lors de la mise à jour du bail DHCP, envoie son nom d'hôte.
L'intégration standard ddns & dhcp du côté du Contrôleur de Domaine configure l'enregistrement DNS.
Nous pouvons ajouter la VM à l'inventaire et la configurer avec Ansible.

3. Créer un modèle de VM

Ici, nous n'avons rien inventé — nous avons pris packer.

Nous plaçons la configuration de packer, kickstart dans le dépôt git.
Nous configurons un esclave jenkins spécial avec hyper-v et Packer.
Créons un job, configurons Jenkins.

Comment ce lien fonctionne :

Packer crée une VM vide, y attache l'ISO.
La VM démarre, Packer entre dans le chargeur de démarrage la commande d'utiliser notre fichier kickstart depuis la disquette ou http.
Anaconda se lance avec notre configuration, la mise en place initiale de l'OS se fait.
Packer attend la disponibilité de la VM.
Packer exécute Ansible à l'intérieur de la VM en mode local.
Ansible utilise exactement les mêmes rôles que dans l'étape n°1.
Packer exporte le modèle de VM.

Jour n°75 : Refactorisation des accords sans casser = Test ansible + Testkitchen

Fixer les accords dans le code peut être insuffisant. En effet, si tu veux changer quelque chose en profondeur dans le processus, tu risques de tout casser. C'est pourquoi, en matière d'infrastructure, il devient crucial de tester cette même infrastructure. Pour synchroniser les connaissances au sein de l'équipe, nous avons commencé à tester les rôles Ansible. Je ne vais pas entrer dans les détails, car il existe un article qui décrit les événements à ce moment-là. Teste-moi si tu peux ou les programmeurs YML rêvent-ils de tester ansible ?(spoiler, ce n'était pas la version finale et tout est devenu plus compliqué par la suite) Comment commencer à tester Ansible, refactoriser un projet en un an et ne pas perdre la raison.).

Jour n°130 : Et si CentOS+ansible n'était pas nécessaire ? Peut-être openshift ?

Il faut comprendre que le processus d'intégration de l'infrastructure n'était pas unique et qu'il y avait des sous-projets connexes. Par exemple, une demande est arrivée pour déployer notre application sur openshift, ce qui a entraîné des recherches durant plus d'une semaine. Nous déployons l'application sur Openshift et comparons les outils existants. Ce qui a retardé le processus de migration. Au final, il s'est avéré qu'openshift ne satisfait pas tous les besoins, il faut du matériel réel, ou au moins la possibilité de jouer avec le noyau.

Jour n°170 : Openshift n'est pas adapté, prenons le risque avec Windows Azure Pack ?

Hyper-V n'est pas très amical, SCVMM ne l'améliore pas beaucoup. Mais il existe un outil appelé Windows Azure Pack, qui est une surcouche à SCVMM et imite Azure. Cependant, en réalité, le produit semble abandonné : documentation avec des liens cassés et plutôt succinte. Mais dans le cadre de la recherche de solutions pour simplifier notre cloud, nous avons également examiné cela.

Jour n°250 : Windows Azure Pack n'est pas super. Nous restons sur SCVMM.

Windows Azure Pack semblait prometteur, mais il a été décidé de ne pas introduire WAP avec ses complications dans le système pour des fonctionnalités inutiles et nous sommes restés avec SCVMM.

Jour n°360 : Nous mangeons l'éléphant morceau par morceau.

Ce n'est qu'un an plus tard que la plateforme à laquelle migrer a été prête et le processus de migration a commencé. Pour cela, une tâche S.M.A.R.T. a été définie. Nous avons dressé une liste de toutes les VMs et avons commencé à examiner leur configuration une par une, à la décrire sur Ansible et à la couvrir de tests.

Jour n°450 : Quel système a été obtenu ?

Le processus lui-même n'est pas intéressant. Il est routinier, on peut noter que la plupart des configurations étaient relativement simples ou isomorphes et selon le principe de Pareto, 80 % des configurations ont nécessité 20 % du temps. De la même manière, 80 % du temps a été consacré à la préparation du déménagement et seulement 20 % au déménagement lui-même.

Jour n°540 : La finale

Que s'est-il passé en 18 mois ?

Les accords sont devenus un code.
Travail manuel -> Mécanisation -> Automatisation.

Liens

Source : habr.com