Vaut-il la peine de passer de Powershell DSC à Ansible et comment le faire

Peu de choses sont écrites sur IaC sous Windows, car DevOps / SRE est principalement associé à Linux et Kubernetes. Nous avons décidé de remédier à cette situation et de comparer les outils pouvant être utilisés pour gérer l'IaC sous Windows. L'article sera utile pour les développeurs qui travaillent avec l'infrastructure Windows et choisissent des méthodes de gestion, et pour ceux qui ont déjà implémenté Powershell DSC ou Ansible, mais ont des doutes sur leur décision. Ci-dessous, nous partagerons notre expérience et vous dirons:

• comment fonctionne Powershell DSC et en quoi il diffère d'Ansible lors de la gestion de l'infrastructure sous Windows;
• pourquoi nous sommes passés à Ansible;
• à quels problèmes ils ont été confrontés et comment ils ont été résolus;
• comment les attentes et la réalité se comparent après le passage à Ansible;
• qui devrait choisir Powershell DSC et qui devrait choisir Ansible.

Pourquoi PowerShell DSC a été choisi à l'origine

Mindbox a développé une culture DevOps / SRE, malgré l'infrastructure à prédominance Windows: Hyper-V, IIS, MS SQL Server. Et bien que l'entreprise passe progressivement à Linux et Open Source, Windows l'emporte toujours.



Pour gérer cette infrastructure, ils ont prévu d'utiliser le code d'infrastructure: l'écrire, l'enregistrer dans le référentiel, puis utiliser un outil pour transformer le code en véritable infrastructure. Bien qu'Ansible soit l'outil de gestion d'infrastructure basé sur le code le plus populaire, il a traditionnellement été associé au monde Linux. Nous voulions quelque chose de natif et spécifique à Windows, nous avons donc choisi PowerShell DSC.

Fonctionnement de Powershell DSC

PowerShell Desired State Configuration (DSC) est un service fourni avec Windows prêt à l'emploi et vous aide à gérer votre infrastructure via des fichiers de configuration. Il accepte le code d'infrastructure dans PowerShell comme entrée et le transforme en interne en commandes qui configurent le système. En plus des opérations simples, telles que l'installation de composants Windows, la modification des clés de registre, la création de fichiers ou la configuration de services, il peut faire beaucoup de choses que les scripts PowerShell font habituellement. Par exemple, un cycle complet de configuration DNS ou une instance MS SQL Server hautement disponible.







Liens utiles vers le diagramme:

Exemple de configuration simple pour les documents DSC

Comment utiliser les fichiers de données

SQL Server- Windows Server 2019

DSC pull server SQL Windows Server 2019

DSC Ansible

, DSC

Les attentes de DSC n'ont pas été satisfaites de toutes les manières. De plus, au cours des travaux, de nouveaux besoins sont apparus qui n'ont pu être satisfaits avec l'aide de DSC.



Les développeurs ne peuvent pas utiliser l'outil seuls sans l'aide du SRE. Bien que presque toutes les équipes disposent d'un SRE, l'outil IaC doit être suffisamment simple pour qu'un développeur puisse l'utiliser et ne pas y consacrer plus d'une demi-heure. DSC vous permet d'utiliser non seulement du code déclaratif, mais également toutes les constructions Powershell. Cela signifie qu'il y a de fortes chances de créer du code qui sera difficile à maintenir ou qui conduira à une défaillance de l'infrastructure. Par exemple, déployer une application avec des paramètres incorrects dans le mauvais environnement.



Impossible de sauter la configuration de la marche à sec avant de rouler,pour voir exactement quels changements seront appliqués et lesquels ne le seront pas.



Il est difficile pour DSC d'organiser les vérifications de syntaxe et de style de code. Il existe peu d'outils de validation et ne sont pas mis à jour. Nous l'avons déjà fait pour Ansible.



En mode push DSC, il n'existe aucun moyen pratique de suivre l'état des tâches. Si la configuration a été appliquée avec une erreur, des actions supplémentaires doivent être prises pour les diagnostics: exécutez des commandes pour obtenir l'état de l'application de configuration, consultez les journaux d'événements. Si l'erreur s'est produite sur plusieurs serveurs, cela prend du temps.



Le mode Pull n'est jamais devenu un avantage.Dans celui-ci, la configuration est appliquée de manière asynchrone - il est impossible de savoir exactement quand l'application de la nouvelle configuration est terminée sans sangles et béquilles.



Utilisation abusive de deux outils IaC distincts qui configurent les serveurs. Ansible peut faire la même chose que DSC, et nous utilisons déjà Ansible pour configurer les hôtes Linux et l'équipement réseau.

Comment avez-vous envisagé de passer de DSC à Ansible?

Au début, la tâche semblait simple, pendant environ un mois. Nous avons identifié trois étapes de travail:

• apprenez à vous connecter aux hôtes Windows à l'aide d'Ansible;
• réécrire les configurations DSC à l'aide des modules Ansible;
• supprimer le serveur d'extraction DSC, sa base de données et d'autres artefacts.

Voici ce qu'était le flux de travail sur DSC et comment nous prévoyions de l'organiser dans Ansible:









La structure standard des rôles dans Ansible



Sur Ansible, nous avons prévu de séparer le code complexe qui configure et installe quelque chose dans le code de rôle et diviser les rôles en différents référentiels. Dans le référentiel Ansible principal, seuls les appels aux rôles, les remplacements de paramètres de rôle et les listes de serveurs par groupe doivent rester. Ainsi, non seulement SRE, mais aussi n'importe quel développeur peut déployer le rôle sur les serveurs requis ou modifier le paramètre sans se plonger dans la logique du code d'infrastructure. Le développeur ne peut corriger le code de rôle qu'après la révision SRE.

Quelles difficultés avez-vous rencontrées lors du passage à Ansible et comment elles ont été résolues

Lorsque le travail a commencé, nous avons réalisé que nous avions tort: ​​la tâche n'était pas facile. Il n'y avait pas de problèmes uniquement avec le référentiel, et dans d'autres domaines, j'ai dû faire beaucoup de recherches et améliorer les développements.

WinRM ou SSH

La première surprise a été le choix du type de connexion. Dans le cas de Windows, il y en a deux - WinRM et SSH. Il s'est avéré qu'Ansible est lent à exécuter WinRM. Cela étant dit, Ansible ne recommande pas d'utiliser OpenSSH prêt à l'emploi pour Windows Server 2019. Et nous avons trouvé une nouvelle solution:

1. Forked et refait le rôle de Galaxy.
2. Nous avons écrit un livre de jeu qui ne conteste que ce rôle. C'est le seul playbook qui se connecte aux hôtes via WinRM.
3. Prometheus Blackbox Exporter surveille le port 22 / tcp et la version OpenSSH en tant qu'outils standard :
   
   
   
   - alert: SSHPortDown

  expr: probe_success{job=~".*-servers-ssh",instance!~".*domain..ru"} == 0

  for: 1d

  annotations:

   summary: "Cannot reach {{`{{ $labels.instance }}`}} with SSH"
   
   
   
   
4. LDAP- , Windows- :
   
   
   
   plugin: ldap_inventory

domain: 'ldaps://domain:636'

search_ou: "DC=domain,DC=ru"

ldap_filter: "(&(objectCategory=computer)(operatingSystem=*server*)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))"

validate_certs: False

exclude_hosts:

 - db-

account_age: 15

fqdn_format: True
   
   
   
   
5. OpenSSH , Windows- SSH .
6. OpenSSH . Packer, Ansible:
   
   
   
   "type": "shell-local",

"tempfile_extension": ".ps1",

"execute_command": ["powershell.exe", "{{.Vars}} {{.Script}}"],

"env_var_format": "$env:%s=\"%s\"; ",

"environment_vars": [

"packer_directory={{ pwd }}",

"ldap_machine_name={{user `ldap_machine_name`}}",

"ldap_username={{user `ldap_username`}}",

"ldap_password={{user `ldap_password`}}",

"ansible_playbooks={{user `ansible_playbooks`}}",

"github_token={{user `github_token`}}"

],

"script": "./scripts/run-ansiblewithdocker.ps1"


   
   
   
   

Lorsque nous réécrivions le code pour Ansible, nous nous heurtions périodiquement à une duplication de code. Par exemple, presque toutes les configurations DSC contenaient un paramètre windows_exporter. La seule chose qui était différente était les collecteurs que l'exportateur devait utiliser:







pour se débarrasser du code dupliqué, nous avons déplacé windows_exporter dans un rôle Ansible séparé, et les paramètres de ce paramètre - dans des variables de groupe d'hôtes.

Authentification du deuxième saut

L'authentification du deuxième saut est probablement le problème le plus courant rencontré par ceux qui ont commencé à utiliser Ansible sous Windows: cette conception provoque l'erreur Accès refusé en raison du fait que par défaut, il est impossible de déléguer les informations d'identification pour l'autorisation sur une ressource distante sans paramètres supplémentaires. Pour contourner l'erreur, par exemple, new_credentials aide. Mais nous avons préféré profiter du fait qu'Ansible peut appeler des ressources DSC via le module win_dsc. Nous appelons la ressource File DSC, qui par défaut s'exécute sous le compte d'ordinateur. La délégation Kerberos n'est pas nécessaire dans ce cas:



- name: Custom modules loaded into module directory

   win_copy:

    src: '\\share\dsc\modules'

    dest: 'C:\Program Files\WindowsPowerShell\Modules'

    remote_src: yes











- name: Custom modules loaded into module directory

   win_dsc:

    resource_name: File

    SourcePath: '\\share\dsc\modules'

    DestinationPath: 'C:\Program Files\WindowsPowerShell\Modules'

    Type: Directory

    Recurse: true

    Force: true

    MatchSource: true







Dans le même temps, il n'y a pas de contradiction à abandonner DSC, mais à utiliser ses ressources si elles résolvent mieux le problème que le module Ansible. L'objectif principal est d'arrêter d'utiliser les configurations DSC, car c'est l'écosystème DSC qui ne nous convenait pas, et non les ressources elles-mêmes. Par exemple, si vous devez créer un commutateur Hyper-V virtuel, vous devrez utiliser la ressource DSC - Ansible ne dispose pas encore d'outils pour gérer la configuration Hyper-V.

Déconnexion du réseau

Certaines tâches provoquent une déconnexion (déconnexion) du réseau sur des serveurs configurables. Par exemple, création d'un commutateur virtuel Hyper-V à partir de l'exemple ci-dessus: Le problème est que dans DSC, un tel appel fonctionne, mais dans Ansible, il échoue car l'hôte géré s'est déconnecté. En effet, Windows se déconnecte toujours lors de la création d'un commutateur externe virtuel. La solution consiste à ajouter un argument asynchrone à la tâche : c'est ainsi qu'Ansible envoie la tâche à l'hôte, attend un temps spécifié et ne demande ensuite l'état.



- name: External switch present

   win_dsc:

     resource_name: xVMSwitch

     Ensure: 'Present'

     Name: 'Virtual Network'

     Type: 'External'

     NetAdapterName: 'TEAM_LAN'

     AllowManagementOS: True











async: 10

Infrastructure de dérive

Lorsque nous avons commencé à porter le code, nous avons constaté une dérive de configuration. Ce sont les différences réelles entre ce qui est décrit dans le code et la configuration réelle du serveur ou du logiciel. La raison en est que dans certains cas, DSC n'a fait qu'une partie du travail, et le reste a été effectué soit par des scripts, soit manuellement selon les instructions.



Pour faciliter le travail avec IaC, nous avons rassemblé tous les scripts et documents et rendu des instructions uniformes et sans ambiguïté. De plus, nous avons organisé le processus de manière à ce que personne n'apporte de modifications accidentelles à Ansible. Nous stockons tout le code d'infrastructure dans GitHub et attribuons des tâches aux ingénieurs via des projets GitHub, nous avons donc la possibilité d'associer des modifications du code d'infrastructure (pull requests) à des tâches. Ainsi, nous pouvons voir les changements pour chaque tâche terminée. Si la tâche ne comporte aucune modification, elle ne sera pas acceptée et sera renvoyée pour révision.

Bogues de collecte de faits

Contrairement à DSC, Ansible rassemble des informations sur les hôtes gérés au démarrage afin que le développeur puisse déterminer le comportement des tâches en fonction de l'état de l'hôte. Lors de la collecte de faits à partir d'hôtes Windows, Ansible peut générer une erreur en raison d'un code de module incorrect. Pour résoudre ce problème, vous devez connecter la collection ansible.windows. Le pipeline pour Ansible, avant de lancer chaque playbook, vérifie la présence de fichiers requirements.yml avec une liste des rôles et des collections requis, puis les installe. C'est là que nous avons ajouté la collection ansible.windows. Les collections



[WARNING]: Error when collecting bios facts: New-Object : Exception calling ".ctor" with "0" argument(s): "Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index" At line:2

char:21 + ... $bios = New-Object -TypeName













Est un nouveau concept de développement pour Ansible. Si auparavant seuls les rôles étaient distribués dans Galaxy, vous pouvez maintenant y trouver des collections de divers plugins et modules, playbooks et rôles.

Des tests

Avant de remettre la boîte à outils IaC aux développeurs, nous voulions nous assurer que le code Ansible serait fiable et ne casserait rien. Dans le cas du DSC, il n'y a pas eu de tests spéciaux, bien qu'il existe un cadre spécial pour cette tâche. Les configurations étaient généralement validées sur des serveurs intermédiaires, dont la défaillance n'entraînait pas de défauts.



Ansible est généralement testé à l'aide de l'outil molécule . comme wrapper pour exécuter des tests. C'est un outil pratique pour les rôles Linux, mais il y a un problème avec Windows. Auparavant, la molécule pouvait augmenter l'infrastructure elle-même, mais maintenant les développeurs ont supprimé cette opportunité. Désormais, l'infrastructure est mise en place soit à l'aide d'une molécule dans Docker, soit en dehors d'une molécule. Le test des rôles Windows dans Docker est le plus souvent impossible: Hyper-V et la plupart des autres fonctionnalités Windows ne seront pas installés dans un conteneur Docker. Nous devrons déployer l'infrastructure pour les tests en dehors de la molécule et utiliser le pilote délégué dans la molécule.



Nous n'avons pas encore résolu ce problème, mais nous avons trouvé des outils permettant de détecter les erreurs les plus évidentes:

Comment fonctionne Ansible

Après avoir implémenté Ansible et surmonté toutes les difficultés, le processus d'actions des ingénieurs et de lancements automatiques s'est formé:

1. , Linux-. , , pull request GitHub-, .
2. pull request GitHub Actions, . Linux-, . , , .
3. pull request. , -, .
4. . requirements.yml, GitHub- . — . . , Ansible, . pull request, .
5. pull request GitHub Actions, Octopus Deploy. .
6. Octopus Deploy . , ansible-playbook: --tags, --limit --extra-vars.
7. , , . , .

Ansible

: DSC Ansible

Evgeny Berendyaev, ingénieur SRE