La nouvelle année approchait. Dans tout le pays, des enfants avaient déjà envoyé des lettres au Père Noël ou s'étaient fait des cadeaux, et leur principal exécuteur testamentaire, l'un des principaux détaillants, se préparait à l'apothéose des ventes. En décembre, la charge sur son centre de données augmente plusieurs fois. L'entreprise a donc décidé de moderniser le centre de données et de mettre en service plusieurs dizaines de nouveaux serveurs au lieu d'équipements arrivant en fin de vie. Ceci termine l'histoire sur fond de flocons de neige tourbillonnants et le thriller commence.

Le matériel est arrivé sur le site plusieurs mois avant le pic des ventes. Le service des opérations sait bien entendu comment et quoi configurer sur les serveurs afin de les intégrer dans l'environnement de production. Mais nous devions automatiser cela et éliminer le facteur humain. De plus, les serveurs ont été remplacés avant la migration d'un ensemble de systèmes SAP critiques pour l'entreprise.

La mise en service de nouveaux serveurs était strictement liée à un délai. Et le déplacer signifiait mettre en péril à la fois l’envoi d’un milliard de cadeaux et la migration des systèmes. Même une équipe composée du Père Noël et du Père Noël n'a pas pu changer la date - vous ne pouvez transférer le système SAP pour la gestion des entrepôts qu'une fois par an. Du 31 décembre au 1er janvier, les immenses entrepôts du détaillant, grands au total comme 20 terrains de football, arrêtent leur travail pendant 15 heures. Et c'est la seule période de temps pour déplacer le système. Nous n'avions aucune marge d'erreur lors de l'introduction des serveurs.

Laissez-moi être clair : mon histoire reflète les outils et le processus de gestion de la configuration que notre équipe utilise.

Le complexe de gestion de configuration se compose de plusieurs niveaux. L'élément clé est le système CMS. En exploitation industrielle, l'absence d'un des niveaux conduirait inévitablement à de désagréables miracles.

Gestion de l'installation du système d'exploitation

Le premier niveau est un système de gestion de l'installation des systèmes d'exploitation sur des serveurs physiques et virtuels. Il crée des configurations de base du système d'exploitation, éliminant le facteur humain.

Grâce à ce système, nous avons reçu des instances de serveur standard avec un système d'exploitation adapté à une automatisation plus poussée. Au cours du « versement », ils ont reçu un ensemble minimum d'utilisateurs locaux et de clés SSH publiques, ainsi qu'une configuration cohérente du système d'exploitation. Nous avions la garantie de gérer les serveurs via le CMS et étions sûrs qu'il n'y aurait pas de surprises « en bas » au niveau de l'OS.

La tâche « maximale » du système de gestion d'installation est de configurer automatiquement les serveurs du niveau BIOS/Firmware jusqu'au système d'exploitation. Cela dépend beaucoup de l'équipement et des tâches de configuration. Pour les équipements hétérogènes, vous pouvez envisager API sébaste. Si tout le matériel provient d'un seul fournisseur, il est souvent plus pratique d'utiliser des outils de gestion prêts à l'emploi (par exemple, HP ILO Amplifier, DELL OpenManage, etc.).

Pour installer l'OS sur des serveurs physiques, nous avons utilisé le célèbre Cobbler, qui définit un ensemble de profils d'installation convenus avec le service d'exploitation. Lors de l'ajout d'un nouveau serveur à l'infrastructure, l'ingénieur a lié l'adresse MAC du serveur au profil requis dans Cobbler. Lors du premier démarrage sur le réseau, le serveur a reçu une adresse temporaire et un nouveau système d'exploitation. Ensuite, il a été transféré vers l'adressage VLAN/IP cible et le travail y a continué. Oui, changer de VLAN prend du temps et nécessite une coordination, mais cela offre une protection supplémentaire contre l'installation accidentelle du serveur dans un environnement de production.

Nous avons créé des serveurs virtuels basés sur des modèles préparés à l'aide de HashiСorp Packer. La raison était la même : éviter d’éventuelles erreurs humaines lors de l’installation du système d’exploitation. Mais contrairement aux serveurs physiques, Packer élimine le besoin de modifications PXE, de démarrage réseau et de VLAN. Cela a rendu plus facile et plus simple la création de serveurs virtuels.

Riz. 1. Gérer l'installation des systèmes d'exploitation.

Gérer les secrets

Tout système de gestion de configuration contient des données qui doivent être cachées aux utilisateurs ordinaires, mais qui sont nécessaires à la préparation des systèmes. Il s'agit de mots de passe pour les utilisateurs locaux et les comptes de service, de clés de certificat, de divers jetons API, etc. Ils sont généralement appelés « secrets ».

Si vous ne déterminez pas dès le début où et comment stocker ces secrets, alors, en fonction de la gravité des exigences en matière de sécurité des informations, les méthodes de stockage suivantes sont probables :

• directement dans le code de contrôle de configuration ou dans des fichiers du référentiel ;
• dans des outils spécialisés de gestion de configuration (par exemple, Ansible Vault) ;
• dans les systèmes CI/CD (Jenkins/TeamCity/GitLab/etc.) ou dans les systèmes de gestion de configuration (Ansible Tower/Ansible AWX) ;
• les secrets peuvent également être transférés « manuellement ». Par exemple, ils sont disposés à un emplacement spécifié, puis utilisés par les systèmes de gestion de configuration ;
• diverses combinaisons de ce qui précède.

Chaque méthode a ses propres inconvénients. Le principal problème est l’absence de politiques d’accès aux secrets : il est impossible ou difficile de déterminer qui peut utiliser certains secrets. Un autre inconvénient est le manque d’audit d’accès et de cycle de vie complet. Comment remplacer rapidement, par exemple, une clé publique écrite dans le code et dans un certain nombre de systèmes associés ?

Nous avons utilisé le stockage secret centralisé HashiCorp Vault. Cela nous a permis :

• garder les secrets en sécurité. Ils sont cryptés et même si quelqu'un accède à la base de données Vault (par exemple, en la restaurant à partir d'une sauvegarde), il ne pourra pas lire les secrets qui y sont stockés ;
• organiser des politiques d’accès aux secrets. Seuls les secrets qui leur sont « attribués » sont accessibles aux utilisateurs et aux applications ;
• auditer l’accès aux secrets. Toutes les actions comportant des secrets sont enregistrées dans le journal d'audit de Vault ;
• organiser un « cycle de vie » à part entière de travail avec des secrets. Ils peuvent être créés, révoqués, fixer une date d'expiration, etc.
• facile à intégrer avec d'autres systèmes nécessitant un accès aux secrets ;
• et utilisez également le cryptage de bout en bout, les mots de passe à usage unique pour le système d'exploitation et la base de données, les certificats des centres autorisés, etc.

Passons maintenant au système central d'authentification et d'autorisation. Il était possible de s'en passer, mais l'administration des utilisateurs dans de nombreux systèmes connexes est trop simple. Nous avons configuré l'authentification et l'autorisation via le service LDAP. Sinon, Vault devrait émettre et suivre en permanence des jetons d'authentification pour les utilisateurs. Et supprimer et ajouter des utilisateurs se transformerait en une quête « ai-je créé/supprimé ce compte utilisateur partout ?

Nous ajoutons un autre niveau à notre système : gestion des secrets et authentification/autorisation centrale :

Riz. 2. Gestion des secrets.

Gestion de la configuration

Nous sommes arrivés au cœur : le système CMS. Dans notre cas, il s'agit d'une combinaison d'Ansible et de Red Hat Ansible AWX.

Au lieu d'Ansible, Chef, Puppet, SaltStack peuvent être utilisés. Nous avons choisi Ansible sur la base de plusieurs critères.

• Tout d’abord, c’est la polyvalence. Un ensemble de modules prêts à l'emploi pour le contrôle c'est impressionnant. Et si vous n’en avez pas assez, vous pouvez effectuer une recherche sur GitHub et Galaxy.
• Deuxièmement, il n'est pas nécessaire d'installer et de prendre en charge des agents sur les équipements gérés, de prouver qu'ils n'interfèrent pas avec la charge et de confirmer l'absence de « signets ».
• Troisièmement, Ansible a une faible barrière à l’entrée. Un ingénieur compétent rédigera un manuel de travail littéralement dès le premier jour de travail avec le produit.

Mais Ansible seul dans un environnement de production ne nous suffisait pas. Sinon, de nombreux problèmes surgiraient en matière de restriction d'accès et d'audit des actions des administrateurs. Comment restreindre l'accès ? Après tout, il était nécessaire que chaque département gère (lire : exécuter le playbook Ansible) « son propre » ensemble de serveurs. Comment autoriser uniquement certains employés à exécuter des playbooks Ansible spécifiques ? Ou comment savoir qui a lancé le playbook sans mettre en place beaucoup de connaissances locales sur les serveurs et les équipements exécutant Ansible ?

La part du lion de ces problèmes est résolue par Red Hat Tour Ansible, ou son projet open source en amont AnsibleAWX. C'est pourquoi nous l'avons préféré pour le client.

Et une touche de plus au portrait de notre système CMS. Le playbook Ansible doit être stocké dans les systèmes de gestion de référentiels de code. Nous l'avons GitLabCE.

Ainsi, les configurations elles-mêmes sont gérées par une combinaison Ansible/Ansible AWX/GitLab (voir Fig. 3). Bien entendu, AWX/GitLab est intégré à un système d'authentification unique et le playbook Ansible est intégré à HashiCorp Vault. Les configurations entrent dans l'environnement de production uniquement via Ansible AWX, dans lequel toutes les « règles du jeu » sont précisées : qui peut configurer quoi, où obtenir le code de gestion de configuration du CMS, etc.

Riz. 3. Gestion des configurations.

Gestion des tests

Notre configuration est présentée sous forme de code. Par conséquent, nous sommes obligés de respecter les mêmes règles que les développeurs de logiciels. Nous devions organiser les processus de développement, de tests continus, de livraison et d'application du code de configuration aux serveurs de production.

Si cela n'est pas fait immédiatement, alors les rôles écrits pour la configuration cesseraient d'être pris en charge et modifiés, ou cesseraient d'être lancés en production. Le remède à cette douleur est connu, et il a fait ses preuves dans ce projet :

• chaque rôle est couvert par des tests unitaires ;
• les tests sont exécutés automatiquement chaque fois qu'il y a un changement dans le code qui gère les configurations ;
• les modifications apportées au code de gestion de la configuration ne sont publiées dans l'environnement de production qu'après avoir réussi tous les tests et la révision du code.

Le développement de code et la gestion de la configuration sont devenus plus calmes et plus prévisibles. Pour organiser des tests continus, nous avons utilisé la boîte à outils GitLab CI/CD et pris Molécule ansible.

Chaque fois qu'il y a un changement dans le code de gestion de la configuration, GitLab CI/CD appelle Molecule :

• il vérifie la syntaxe du code,
• soulève le conteneur Docker,
• applique le code modifié au conteneur créé,
• vérifie l'idempotence du rôle et exécute des tests pour ce code (la granularité est ici au niveau du rôle ansible, voir Fig. 4).

Nous avons livré des configurations à l'environnement de production à l'aide d'Ansible AWX. Les ingénieurs d'exploitation ont appliqué les modifications de configuration via des modèles prédéfinis. AWX a « demandé » indépendamment la dernière version du code à la branche principale de GitLab à chaque fois qu'elle était utilisée. De cette façon, nous avons exclu l'utilisation de code non testé ou obsolète dans l'environnement de production. Naturellement, le code n'est entré dans la branche principale qu'après test, examen et approbation.

Riz. 4. Test automatique des rôles dans GitLab CI/CD.

Il existe également un problème lié au fonctionnement des systèmes de production. Dans la vraie vie, il est très difficile d’apporter des modifications à la configuration uniquement via le code CMS. Des situations d'urgence surviennent lorsqu'un ingénieur doit modifier la configuration « ici et maintenant », sans attendre l'édition du code, les tests, l'approbation, etc.

De ce fait, en raison de modifications manuelles, des écarts apparaissent dans la configuration sur un même type d'équipement (par exemple, les paramètres sysctl sont configurés différemment sur les nœuds du cluster HA). Soit la configuration réelle de l'équipement diffère de celle spécifiée dans le code CMS.

Par conséquent, en plus des tests continus, nous vérifions les environnements de production pour déceler les écarts de configuration. Nous avons choisi l'option la plus simple : exécuter le code de configuration du CMS en mode « essai à sec », c'est-à-dire sans appliquer de modifications, mais avec notification de tous les écarts entre la configuration prévue et réelle. Nous avons implémenté cela en exécutant périodiquement tous les playbooks Ansible avec l'option « -check » sur les serveurs de production. Comme toujours, Ansible AWX est responsable du lancement et de la mise à jour du playbook (voir Fig. 5) :

Riz. 5. Vérifie les écarts de configuration dans Ansible AWX.

Après vérifications, AWX envoie un rapport d'écart aux administrateurs. Ils étudient la configuration problématique puis la corrigent grâce à des playbooks ajustés. C'est ainsi que nous maintenons la configuration dans l'environnement de production et le CMS est toujours à jour et synchronisé. Cela élimine les « miracles » désagréables lorsque le code CMS est utilisé sur des serveurs de « production ».

Nous disposons désormais d'une couche de test importante composée d'Ansible AWX/GitLab/Molecule (Figure 6).

Riz. 6. Gestion des tests.

Difficile? Je ne discute pas. Mais un tel complexe de gestion de configuration est devenu une réponse globale à de nombreuses questions liées à l'automatisation de la configuration des serveurs. Désormais, les serveurs standards d'un détaillant ont toujours une configuration strictement définie. CMS, contrairement à un ingénieur, n'oubliera pas d'ajouter les paramètres nécessaires, de créer des utilisateurs et d'effectuer des dizaines ou des centaines de paramètres requis.

Il n’existe aujourd’hui aucune « connaissance secrète » dans les paramètres des serveurs et des environnements. Toutes les fonctionnalités nécessaires sont reflétées dans le playbook. Fini la créativité et les consignes vagues : «Installez-le comme Oracle classique, mais vous devez spécifier quelques paramètres sysctl et ajouter des utilisateurs avec l'UID requis. Demande aux gars en opération, ils savent».

La capacité de détecter les écarts de configuration et de les corriger de manière proactive offre une tranquillité d'esprit. Sans système de gestion de configuration, cela semble généralement différent. Les problèmes s’accumulent jusqu’au jour où ils « se lancent » en production. Puis un débriefing est effectué, les configurations sont vérifiées et corrigées. Et le cycle se répète encore

Et bien sûr, nous avons accéléré la mise en service des serveurs de plusieurs jours à quelques heures.

Eh bien, le soir du Nouvel An, alors que les enfants déballaient joyeusement leurs cadeaux et que les adultes faisaient des vœux au son du carillon, nos ingénieurs ont migré le système SAP vers de nouveaux serveurs. Même le Père Noël dira que les meilleurs miracles sont ceux qui sont bien préparés.

PS Notre équipe est souvent confrontée au fait que les clients souhaitent résoudre les problèmes de gestion de configuration le plus simplement possible. Idéalement, comme par magie – avec un seul outil. Mais dans la vie, tout est plus compliqué (oui, les solutions miracles n'ont pas encore été livrées) : il faut créer tout un processus à l'aide d'outils qui conviennent à l'équipe du client.

Auteur : Sergueï Artemov, architecte du département Solutions DevOps "Systèmes d'information Jet"

Source: habr.com