Lohnt es sich, von Powershell DSC zu Ansible zu wechseln und wie es geht?

Über IaC unter Windows wird wenig geschrieben, da DevOps / SRE hauptsächlich mit Linux und Kubernetes verbunden ist. Wir haben uns entschlossen, diese Situation zu beheben und die Tools zu vergleichen, mit denen Windows-basiertes IaC verwaltet werden kann. Der Artikel ist nützlich für Entwickler, die mit der Windows-Infrastruktur arbeiten und Verwaltungsmethoden auswählen, sowie für diejenigen, die Powershell DSC oder Ansible bereits implementiert haben, aber Zweifel an ihrer Entscheidung haben. Im Folgenden werden wir unsere Erfahrungen teilen und Ihnen sagen:

• Wie funktioniert Powershell DSC und wie unterscheidet es sich von Ansible bei der Verwaltung der Infrastruktur unter Windows?
• warum wir zu Ansible gewechselt sind;
• mit welchen Problemen sie konfrontiert waren und wie sie gelöst wurden;
• Wie vergleichen sich Erwartungen und Realität nach dem Wechsel zu Ansible?
• Wer sollte sich für Powershell DSC entscheiden und wer sollte sich für Ansible entscheiden?

Warum PowerShell DSC ursprünglich ausgewählt wurde

Mindbox hat trotz der überwiegend Windows-Infrastruktur eine entwickelte DevOps / SRE-Kultur: Hyper-V, IIS, MS SQL Server. Und obwohl das Unternehmen allmählich auf Linux und Open Source umstellt, setzt sich Windows immer noch durch.



Um diese Infrastruktur zu verwalten, planten sie, Infrastrukturcode zu verwenden: Schreiben Sie ihn, speichern Sie ihn im Repository und verwenden Sie dann ein Tool, um den Code in eine echte Infrastruktur umzuwandeln. Während Ansible das beliebteste Code-basierte Infrastruktur-Management-Tool ist, wurde es traditionell mit der Linux-Welt in Verbindung gebracht. Wir wollten etwas natives und Windows-spezifisches, deshalb haben wir uns für PowerShell DSC entschieden.

So funktioniert Powershell DSC

PowerShell Desired State Configuration (DSC) ist ein Dienst, der standardmäßig mit Windows geliefert wird und Sie bei der Verwaltung Ihrer Infrastruktur über Konfigurationsdateien unterstützt. Es akzeptiert den Infrastrukturcode in PowerShell als Eingabe und wandelt ihn intern in Befehle um, die das System konfigurieren. Neben einfachen Vorgängen wie dem Installieren von Windows-Komponenten, dem Ändern von Registrierungsschlüsseln, dem Erstellen von Dateien oder dem Konfigurieren von Diensten kann PowerShell viele Dinge ausführen, die normalerweise ausgeführt werden. Zum Beispiel ein vollständiger Zyklus der DNS-Konfiguration oder eine hochverfügbare MS SQL Server-Instanz.







Nützliche Links zum Diagramm:

Beispiel einer einfachen Konfiguration für DSC-Dokumente

Verwendung von Datendateien

SQL Server- Windows Server 2019

DSC pull server SQL Windows Server 2019

DSC Ansible

, DSC

Die Erwartungen von DSC wurden nicht in jeder Hinsicht erfüllt. Darüber hinaus entstanden während der Arbeit neue Bedürfnisse, die mit Hilfe von DSC nicht befriedigt werden konnten.



Entwickler können das Tool ohne die Hilfe des SRE nicht alleine verwenden. Obwohl fast jedes Team über eine SRE verfügt, sollte das IaC-Tool so einfach sein, dass ein Entwickler es verwenden und nicht mehr als eine halbe Stunde damit verbringen kann. Mit DSC können Sie nicht nur deklarativen Code verwenden, sondern auch alle Powershell-Konstrukte. Dies bedeutet, dass die Wahrscheinlichkeit groß ist, dass Code erstellt wird, der schwer zu warten ist oder zu einem Ausfall der Infrastruktur führt. Beispiel: Bereitstellen einer Anwendung mit falschen Parametern in der falschen Umgebung.



Die Trockenlaufkonfiguration kann vor dem Rollen nicht übersprungen werden.um genau zu sehen, welche Änderungen angewendet werden und welche nicht.



Für DSC ist es schwierig, Syntax- und Codestilprüfungen zu organisieren. Es gibt nur wenige Validierungswerkzeuge, die nicht aktualisiert werden. Wir haben dies bereits für Ansible getan.



Im DSC-Push-Modus gibt es keine bequeme Möglichkeit, den Status von Aufgaben zu verfolgen. Wenn die Konfiguration mit einem Fehler angewendet wurde, sollten zusätzliche Maßnahmen zur Diagnose ergriffen werden: Führen Sie Befehle aus, um den Status der Konfigurationsanwendung abzurufen, und überprüfen Sie die Ereignisprotokolle. Wenn der Fehler auf mehreren Servern aufgetreten ist, ist er zeitaufwändig.



Der Pull-Modus wurde nie zum Vorteil.Darin wird die Konfiguration asynchron angewendet - es ist unmöglich, genau herauszufinden, wann die Anwendung der neuen Konfiguration ohne Gurte und Krücken abgeschlossen ist.



Überbeanspruchung von zwei unterschiedlichen IaC-Tools , die Server konfigurieren. Ansible kann dasselbe wie DSC tun, und wir verwenden Ansible bereits zum Konfigurieren von Linux-Hosts und Netzwerkgeräten.

Wie wollten Sie von DSC zu Ansible wechseln?

Zuerst schien die Aufgabe ungefähr einen Monat lang einfach zu sein. Wir haben drei Arbeitsschritte identifiziert:

• Erfahren Sie, wie Sie mit Ansible eine Verbindung zu Windows-Hosts herstellen.
• DSC-Konfigurationen mit Ansible-Modulen neu schreiben;
• Entfernen Sie den DSC-Pull-Server, seine Datenbank und andere Artefakte.

So war der Workflow in DSC und wie wir ihn in Ansible organisieren wollten:









In der Standardstruktur der Rollen in Ansible



On Ansible wollten wir den komplexen Code, der etwas konfiguriert und in den Rollencode installiert, trennen und die Rollen in separate Teile aufteilen Repositories. Im Haupt-Repository von Ansible sollten nur die Aufrufe von Rollen, Überschreibungen von Rollenparametern und Listen von Servern nach Gruppe verbleiben. So kann nicht nur SRE, sondern auch jeder Entwickler die Rolle auf den erforderlichen Servern bereitstellen oder den Parameter optimieren, ohne sich mit der Logik des Infrastrukturcodes zu befassen. Der Entwickler kann den Rollencode erst nach der SRE-Überprüfung korrigieren.

Welche Schwierigkeiten hatten Sie beim Wechsel zu Ansible und wie wurden sie gelöst?

Als die Arbeit begann, stellten wir fest, dass wir falsch lagen: Die Aufgabe war nicht einfach. Es gab keine Probleme nur mit dem Repository, und in anderen Angelegenheiten musste ich viel recherchieren und die Entwicklungen verbessern.

WinRM oder SSH

Die erste Überraschung war die Wahl des Verbindungstyps. Bei Windows gibt es zwei davon - WinRM und SSH. Es stellte sich heraus, dass Ansible WinRM nur langsam durchläuft. That being said, ist ansible OpenSSH mit nicht zu empfehlen , aus der Box für Windows Server 2019. Und wir fanden eine neue Lösung:

1. Gabelte und machte die Rolle von Galaxy neu.
2. Wir haben ein Spielbuch geschrieben, das nur eine Herausforderung für diese Rolle darstellt. Dies ist das einzige Playbook, das über WinRM eine Verbindung zu Hosts herstellt.
3. Prometheus Blackbox Exporter überwacht Port 22 / tcp und die OpenSSH-Version als Standardtools :
   
   
   
   - 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"


   
   
   
   

Als wir den Code für Ansible neu geschrieben haben, sind wir regelmäßig auf Codeduplizierungen gestoßen. Beispielsweise enthielten fast alle DSC-Konfigurationen eine Windows_Exporter- Einstellung . Das einzige, was anders war, waren die Kollektoren, die der Exporter verwenden musste:







Um den duplizierten Code zu entfernen, haben wir windows_exporter in eine separate Ansible-Rolle verschoben und die Parameter dieser Einstellung - in Hostgruppenvariablen.

Authentifizierung im zweiten Hop

Wahrscheinlich ist die Authentifizierung im zweiten Hop das häufigste Problem für Benutzer, die Ansible unter Windows verwenden: Dieses Design verursacht den Fehler "Zugriff verweigert", da standardmäßig keine Anmeldeinformationen für die Autorisierung auf einer Remoteressource ohne zusätzliche Einstellungen delegiert werden können. Um den Fehler zu umgehen, hilft beispielsweise new_credentials. Wir haben es jedoch vorgezogen, die Tatsache auszunutzen, dass Ansible DSC-Ressourcen über das Modul win_dsc aufrufen kann. Wir rufen die Datei-DSC-Ressource auf, die standardmäßig unter dem Computerkonto ausgeführt wird. In diesem Fall ist keine Kerberos-Delegierung erforderlich:



- 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







Gleichzeitig besteht kein Widerspruch darin, DSC aufzugeben, sondern seine Ressourcen zu nutzen, wenn sie das Problem besser lösen als das Ansible-Modul. Das Hauptziel ist es, die Verwendung von DSC-Konfigurationen einzustellen, da das DSC-Ökosystem nicht zu uns passte und nicht die Ressourcen selbst. Wenn Sie beispielsweise einen virtuellen Hyper-V-Switch erstellen müssen, müssen Sie die DSC-Ressource verwenden. Ansible verfügt noch nicht über Tools zum Verwalten der Hyper-V-Konfiguration.

Netzwerkverbindung trennen

Einige Aufgaben verursachen auf konfigurierbaren Servern eine Netzwerkunterbrechung (Disconnect). Beispiel: Erstellen eines virtuellen Hyper-V-Switches aus dem obigen Beispiel: Das Problem besteht darin, dass ein solcher Aufruf in DSC funktioniert, in Ansible jedoch fehlschlägt, weil der verwaltete Host die Verbindung getrennt hat. Dies liegt daran, dass Windows beim Erstellen eines virtuellen externen Switches immer die Verbindung trennt. Die Lösung besteht darin , der Aufgabe ein asynchrones Argument hinzuzufügen : So sendet Ansible die Aufgabe an den Host, wartet eine bestimmte Zeit und fragt erst dann nach dem Status.



- name: External switch present

   win_dsc:

     resource_name: xVMSwitch

     Ensure: 'Present'

     Name: 'Virtual Network'

     Type: 'External'

     NetAdapterName: 'TEAM_LAN'

     AllowManagementOS: True











async: 10

Drift-Infrastruktur

Als wir mit der Portierung des Codes begannen, stellten wir eine Konfigurationsdrift fest. Dies sind die tatsächlichen Unterschiede zwischen dem, was im Code beschrieben ist, und der tatsächlichen Konfiguration des Servers oder der Software. Der Grund ist, dass DSC in einigen Fällen nur einen Teil der Arbeit erledigte und der Rest entweder durch Skripte oder manuell gemäß den Anweisungen erledigt wurde.



Um die Arbeit mit IaC zu vereinfachen, haben wir alle Skripte und Dokumente gesammelt und einheitliche, eindeutige Anweisungen erstellt. Darüber hinaus haben wir den Prozess so organisiert, dass niemand versehentlich Änderungen an Ansible vorgenommen hat. Wir speichern den gesamten Infrastrukturcode in GitHub und weisen Ingenieuren über GitHub-Projekte Aufgaben zu, sodass wir Änderungen am Infrastrukturcode (Pull-Anforderungen) mit Aufgaben verknüpfen können. So können wir die Änderungen für jede abgeschlossene Aufgabe sehen. Wenn die Aufgabe keine Änderungen aufweist, wird sie nicht akzeptiert und zur Überarbeitung zurückgesandt.

Fact Bathering Bugs

Im Gegensatz zu DSC sammelt Ansible beim Start Fakten zu verwalteten Hosts, sodass der Entwickler das Verhalten von Aufgaben abhängig vom Status des Hosts bestimmen kann. Beim Sammeln von Fakten von Windows-Hosts kann Ansible aufgrund eines falschen Modulcodes einen Fehler auslösen. Um dies zu beheben, müssen Sie die ansible.windows- Sammlung verbinden . Die Pipeline für ansible, vor jedes Textbuch, überprüft das Vorhandensein der Einführung requirements.yml Dateien mit einer Liste der erforderlichen Rollen und Sammlungen, und installiert sich dann. Hier haben wir die ansible.windows-Sammlung hinzugefügt. Sammlungen



[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













Ist ein neues Entwicklungskonzept für Ansible. Wenn früher nur Rollen in Galaxy verteilt wurden, finden Sie dort jetzt Sammlungen verschiedener Plugins und Module, Playbooks und Rollen.

Tests

Bevor wir das IaC-Toolkit an die Entwickler übergeben, wollten wir sicherstellen, dass der Ansible-Code zuverlässig ist und nichts kaputt macht. Im Fall von DSC gab es keine speziellen Tests, obwohl es einen speziellen Rahmen für diese Aufgabe gibt. Konfigurationen wurden normalerweise auf Staging-Servern validiert, deren Ausfall nicht zu Fehlern führte.



Ansible wird in der Regel mit dem getesteten Molekül - Tool. als Wrapper zum Ausführen von Tests. Es ist ein praktisches Tool für Linux-Rollen, aber es gibt ein Problem mit Windows. Früher konnte das Molekül die Infrastruktur selbst erhöhen, jetzt haben die Entwickler diese Möglichkeit entfernt. Jetzt wird die Infrastruktur entweder mit Hilfe eines Moleküls in Docker oder außerhalb eines Moleküls erhöht. Das Testen von Windows-Rollen in Docker ist meistens nicht möglich: Hyper-V und die meisten anderen Windows-Funktionen werden nicht in einem Docker-Container installiert. Wir müssen die Infrastruktur für Tests außerhalb des Moleküls bereitstellen und den delegierten Treiber im Molekül verwenden.



Wir haben dieses Problem noch nicht gelöst, aber wir haben Tools gefunden, die die offensichtlichsten Fehler erkennen:

Wie Ansible funktioniert

Nachdem wir Ansible implementiert und alle Schwierigkeiten überwunden hatten, wurde der Prozess der Aktionen der Ingenieure und der automatischen Starts gebildet:

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, SRE-Ingenieur