🥇Systematischer Ansatz für Variablen in Ansible

ansible devops codestyle

Hey! Ich heiße Denis Kaljužnyj Ich arbeite als Ingenieur in der Abteilung für die Automatisierung von Entwicklungsprozessen. Jeden Tag werden neue Anwendungsbuilds auf Hunderten von Servern des Unternehmens bereitgestellt. In diesem Artikel teile ich meine Erfahrungen mit Ansible für diese Zwecke.

Dieser Leitfaden bietet einen Ansatz zur Organisation von Variablen im Deployment. Er richtet sich an diejenigen, die bereits Rollen in ihren Playbooks verwenden und BestPractices, aber auf ähnliche Probleme stoßen:

Beim Finden einer Variablen im Code ist es oft nicht sofort klar, wofür sie verantwortlich ist;
Es gibt mehrere Rollen, und die Variablen müssen mit einem Wert verknüpft werden, aber es funktioniert nicht;
Es gibt Schwierigkeiten, anderen zu erklären, wie die Logik der Variablen in Ihren Playbooks aufgebaut ist.

Mit diesen Problemen sind wir in Projekten in unserem Unternehmen konfrontiert worden, was uns zu den Regeln für die Gestaltung der Variablen in unseren Playbooks geführt hat, die diese Probleme teilweise gelöst haben.

Variablen in Rollen

Eine Rolle ist ein separates Objekt des Deployment-Systems. Wie jedes Objekt des Systems muss es eine Schnittstelle zur Interaktion mit dem Rest des Systems haben. Diese Schnittstelle sind die Variablen der Rolle.

Nehmen wir zum Beispiel die Rolle API, die eine Java-Anwendung auf dem Server installiert. Welche Variablen könnte sie haben?

Variablen einer Rolle können in 2 Typen unterteilt werden:

1. Eigenschaften
    a) umgebungsunabhängig
    b) umgebungsabhängig
2. Verbindungen
    a) Listener 
    b) Anfragen innerhalb des Systems
    c) Anfragen an die Umgebung

Eigenschaftsvariablen sind Variablen, die das Verhalten der Rolle bestimmen.

Anfragevariablen sind Variablen, deren Werte verwendet werden, um externe Ressourcen, die sich nicht innerhalb der Rolle befinden, zu kennzeichnen.

Listener-Variablen sind Variablen, deren Werte verwendet werden, um Anfragevariablen zu bilden.

Andererseits sind 1a, 2a, 2b - Variablen, die nicht von der Umgebung abhängen (Hardware, externe Ressourcen usw.) und mit Standardwerten in den Defaults der Rolle gefüllt werden können. Variablen vom Typ 1b und 2c hingegen können nicht mit Werten außer 'example' gefüllt werden, da sie je nach Umgebung von Stand zu Stand variieren.

Code-Stil

Der Name der Variable sollte unbedingt mit dem Namen der Rolle beginnen. Dies ermöglicht es, später leicht zu erkennen, aus welcher Rolle die Variable stammt und wofür sie verantwortlich ist.
Bei der Verwendung von Variablen in Rollen müssen Sie unbedingt dem Prinzip der Kapselung folgen und Variablen verwenden, die entweder innerhalb der Rolle oder in den Rollen definiert sind, von denen die aktuelle abhängt.
Versuchen Sie, keine Wörterbücher für Variablen zu verwenden. Ansible erlaubt es nicht, einzelne Werte in einem Wörterbuch bequem zu überschreiben.
Beispiel für eine schlechte Variable:
```
myrole_user:
    login: admin
    password: admin
```
Hier ist login eine umgebungsunabhängige Variable, und password ist abhängig. Aber
da sie in einem Wörterbuch zusammengefasst sind, müssen Sie sie immer vollständig angeben.
Was sehr unpraktisch ist. Besser so:
```
myrole_user_login: admin
myrole_user_password: admin
```

Variablen in Bereitstellungsplaybooks

Bei der Erstellung eines Bereitstellungsplaybooks (nachfolgend Playbook genannt) halten wir uns an die Regel, dass es in einem separaten Repository abgelegt werden muss. Genau wie bei Rollen: Jede in ihrem eigenen Git-Repository. Dies ermöglicht es zu erkennen, dass Rollen und Playbook unterschiedliche unabhängige Objekte des Bereitstellungssystems sind und Änderungen in einem Objekt die Funktionalität des anderen nicht beeinträchtigen sollten. Dies wird durch die Änderung der Standardwerte der Variablen erreicht.

Bei der Erstellung eines Playbooks gibt es, um es zusammenzufassen, die Möglichkeit, die Standardwerte der Rollenvariablen an zwei Stellen zu überschreiben: in den Playbook-Variablen und in den Inventarvariablen.

mydeploy                        # Bereitstellungsverzeichnis
├── deploy.yml                  # Bereitstellungs-Playbook
├── group_vars                  # Verzeichnis für Playbook-Variablen
│   ├── all.yml                 # Datei für die Variablen aller Systeme
│   └── myapi.yml               # Datei für die Variablen der Gruppe myapi
└── inventories                 #
    └── prod                    # Verzeichnis der Umgebung prod
       ├── prod.ini            # Inventardatei
       └── group_vars          # Verzeichnis für die Inventarvariablen
           └── myapi           #
               ├── vars.yml    # Umgebungsabhängige Variablen der Gruppe myapi
               └── vault.yml   # Geheimnisse (immer umgebungsabhängig) *

* — Variablen und Vaults

Der Unterschied besteht darin, dass die Playbook-Variablen immer beim Aufruf der Playbooks verwendet werden, die sich auf derselben Ebene befinden. Das bedeutet, dass diese Variablen hervorragend geeignet sind, um die Standardwerte von umgebungsunabhängigen Variablen zu ändern. Umgekehrt werden die Inventarvariablen nur für die jeweilige Umgebung verwendet, was ideal für umgebungsabhängige Variablen ist.

Es ist wichtig zu beachten, dass die Priorität der Variablen es Ihnen nicht ermöglicht, Variablen zuerst in den Playbook-Variablen und dann separat in einer Inventarliste zu überschreiben.

Das bedeutet, dass Sie bereits in diesem Schritt entscheiden müssen, ob die Variable umgebungsabhängig ist oder nicht, und sie am richtigen Ort platzieren müssen.

Zum Beispiel war in einem Projekt die Variable, die für die Aktivierung von SSL verantwortlich war, lange umgebungsabhängig, da wir aus uns nicht bekannten Gründen SSL auf einem der Stände nicht aktivieren konnten. Nachdem wir dieses Problem behoben hatten, wurde sie umgebungsunabhängig und wurde in die Playbook-Variablen verschoben.

Eigenschaftsvariablen für Gruppen

Erweitern wir unser Modell in Abbildung 1, indem wir 2 Gruppen von Servern mit einer anderen Java-Anwendung, jedoch mit unterschiedlichen Einstellungen hinzufügen.

Lassen Sie uns ansehen, wie das Playbook in diesem Fall aussehen würde:

- hosts: myapi
  roles:
    - api

- hosts: bbauth
  roles:
    - auth

- hosts: ghauth
  roles:
    - auth

Wir haben drei Gruppen im Playbook, daher wird empfohlen, ebenso viele Gruppendateien in group_vars der Inventarvariablen und den Playbook-Variablen zu erstellen. Eine Gruppendatei beschreibt in diesem Fall eine Komponente Ihrer Anwendung im Playbook. Wenn Sie die Gruppendatei in den Playbook-Variablen öffnen, sehen Sie sofort alle Abweichungen vom Standardverhalten der auf die Gruppe angewendeten Rollen. In den Inventarvariablen: Verhaltensunterschiede zwischen den Ständen.

Code-Stil

Versuchen Sie, host_vars-Variablen überhaupt nicht zu verwenden, da sie das System nicht beschreiben, sondern nur einen Einzelfall, was langfristig zu Fragen führen könnte: "Warum unterscheidet sich dieser Host von den anderen?", auf die nicht immer leicht zu antworten ist.

Beziehungsvariablen

Das betrifft die Eigenschaftenvariablen, aber wie steht es um die Beziehungsvariablen?
Ihr Unterschied besteht darin, dass sie in verschiedenen Gruppen den gleichen Wert haben müssen.

Zunächst war da die Idee eine monströse Konstruktion wie:
hostvars[groups['bbauth'][0]]['auth_bind_port'], aber diese wurde sofort verworfen
da sie Nachteile hat. Erstens, die Unhandlichkeit. Zweitens, die Abhängigkeit von einem bestimmten Host in der Gruppe. Drittens, es ist notwendig, vor dem Deployment Fakten von allen Hosts zu sammeln, wenn wir nicht mit einem Fehler bei einer undefinierten Variable konfrontiert werden wollen.

Letztendlich wurde beschlossen, Beziehungsvariablen zu verwenden.

Beziehungsvariablen — das sind Variablen, die zum Playbook gehören und für die Verbindung von Systemobjekten benötigt werden.

Die Verbindungsvariablen werden in den allgemeinen Variablen des Systems ausgefüllt group_vars/all/vars und entstehen durch das Herausnehmen aller Listener-Variablen aus jeder Gruppe und das Hinzufügen des Gruppennamens, aus der der Listener entnommen wurde, zu Beginn der Variablen.

Auf diese Weise wird Eindeutigkeit und Nichtüberschneidbarkeit der Namen gewährleistet.

Wir versuchen, die Variablen aus dem obigen Beispiel zu verknüpfen:

Stellen wir uns vor, dass wir Variablen haben, die voneinander abhängen:

# roles/api/defaults:
# Переменная запроса
api_auth1_address: "http://example.com:80"
api_auth2_address: "http://example2.com:80"

# roles/auth/defaults:
# Переменная слушатель
auth_bind_port: "20000"

Lassen Sie uns alle Listener in die allgemeinen Variablen überführen group_vars/all/vars und den Gruppennamen hinzufügen:

# group_vars/all/vars
bbauth_auth_bind_port: "20000"
ghauth_auth_bind_port: "30000"

# group_vars/bbauth/vars
auth_bind_port: "{{ bbauth_auth_bind_port }}"

# group_vars/ghauth/vars
auth_bind_port: "{{ ghauth_auth_bind_port }}"

# group_vars/myapi/vars
api_auth1_address: "http://{{ bbauth_auth_service_name }}:{{ bbauth_auth_bind_port }}"
api_auth2_address: "http://{{ ghauth_auth_service_name }}:{{ ghauth_auth_bind_port }}"

Wenn wir also den Wert des Connectors ändern, sind wir sicher, dass die Anfrage an den Ort geht, an dem sich der Port befindet.

Code-Stil

Da Rollen und Gruppen unterschiedliche Objekte im System sind, müssen sie unterschiedliche Namen haben, damit die Verbindungsvariablen genau anzeigen, dass sie zu einer bestimmten Gruppe von Servern und nicht zu einer Rolle im System gehören.

Umgebungsabhängige Dateien

In Rollen können Dateien verwendet werden, die sich von Umgebung zu Umgebung unterscheiden.

Ein Beispiel für solche Dateien sind SSL-Zertifikate. Es ist nicht sehr praktisch, sie im Textformat
als Variable zu speichern. Es ist jedoch praktisch, den Pfad zu ihnen innerhalb der Variablen zu speichern.

Zum Beispiel verwenden wir die Variable api_ssl_key_file: "/path/to/file".

Da offensichtlich ist, dass sich das Zertifikat je nach Umgebung ändert, ist dies eine umgebungsabhängige Variable, und sie sollte sich in der Datei
group_vars/myapi/vars der Variableninventar befinden und den Wert 'zum Beispiel' enthalten.

Am praktischsten ist es in diesem Fall, die Schlüsseldatei im Playbook-Repository unter dem Pfad
files/prod/certs/myapi.key, dann wäre der Wert der Variablen:
api_ssl_key_file: "prod/certs/myapi.key". Der Vorteil liegt darin, dass die Personen, die für die Bereitstellung des Systems auf einem bestimmten Stand verantwortlich sind, ebenfalls ihren eigenen Platz im Repository zur Speicherung ihrer Dateien haben. Gleichzeitig bleibt die Möglichkeit bestehen, den absoluten Pfad zum Zertifikat auf dem Server anzugeben, falls die Zertifikate von einem anderen System bereitgestellt werden.

Mehrere Stände in einer Umgebung

Es besteht häufig die Notwendigkeit, mehrere praktisch identische Stände in einer Umgebung mit minimalen Unterschieden zu erweitern. In diesem Fall teilen wir umgebungsabhängige Variablen in solche ein, die sich innerhalb dieser Umgebung nicht ändern, und solche, die variieren. Letztere bringen wir direkt in die Inventardateien ein. Nach dieser Manipulation wird es möglich, ein weiteres Inventar direkt im Umgebungsverzeichnis zu erstellen.

Es wird die Möglichkeit geben, die Inventar group_vars wiederzuverwenden und einige Variablen direkt nach Bedarf zu überschreiben.

Die endgültige Verzeichnisstruktur für das Deployment-Projekt:

mydeploy                        # Deployment-Verzeichnis
├── deploy.yml                  # Deployment-Playbook
├── files                       # Verzeichnis für Deployment-Dateien
│   ├── prod                    # Verzeichnis für umgebungsabhängige Dateien des prod-Stands
│   │   └── certs               # 
│   │       └── myapi.key       #
│   └── test1                   # Verzeichnis für umgebungsabhängige Dateien des test1-Stands
├── group_vars                  # Verzeichnis für Playbook-Variablen
│   ├── all.yml                 # Datei für systemweite Variablen
│   ├── myapi.yml               # Datei für Gruppenvariablen der Gruppe myapi
│   ├── bbauth.yml              # 
│   └── ghauth.yml              #
└── inventories                 #
    ├── prod                    # Verzeichnis der prod-Umgebung
    │   ├── group_vars          # Verzeichnis für Inventarvariablen
    │   │   ├── myapi           #
    │   │   │   ├── vars.yml    # Umgebungsabhängige Variablen der Gruppe myapi
    │   │   │   └── vault.yml   # Geheimnisse (immer umgebungsabhängig)
    │   │   ├── bbauth          # 
    │   │   │   ├── vars.yml    #
    │   │   │   └── vault.yml   #
    │   │   └── ghauth          #
    │   │       ├── vars.yml    #
    │   │       └── vault.yml   #
    │   └── prod.ini            # Inventar des prod-Stands
    └── test                    # Verzeichnis der test-Umgebung
        ├── group_vars          #
        │   ├── myapi           #
        │   │   ├── vars.yml    #
        │   │   └── vault.yml   #
        │   ├── bbauth          #
        │   │   ├── vars.yml    #
        │   │   └── vault.yml   #
        │   └── ghauth          #
        │       ├── vars.yml    #
        │       └── vault.yml   #
        ├── test1.ini           # Inventar des test1-Stands in der test-Umgebung
        └── test2.ini           # Inventar des test2-Stands in der test-Umgebung

Zusammenfassung

Nachdem die Variablen gemäß dem Artikel organisiert wurden: Jede Datei mit Variablen ist für eine bestimmte Aufgabe verantwortlich. Da eine Datei spezifische Aufgaben hat, ist es möglich geworden, jemanden für die Korrektheit jeder Datei verantwortlich zu machen. Zum Beispiel wird der Entwickler des Systemdeployments für die Korrektheit der Variablen im Playbook verantwortlich, während der Administrator, dessen Stand im Inventar beschrieben ist, für das Ausfüllen der Inventarvariablen zuständig ist.

Rollen sind zu einer eigenständigen Einheit in der Entwicklung mit einer eigenen Benutzeroberfläche geworden, was es dem Rollenersteller ermöglicht hat, Funktionen zu entwickeln, anstatt die Rolle an das System anzupassen. Besonders dieses Problem betraf allgemeine Rollen für alle Systeme in der Kampagne.

Systemadministratoren müssen sich nicht mehr mit dem Deployment-Code auseinandersetzen. Alles, was sie für ein erfolgreiches Deployment benötigen, ist das Ausfüllen der dateibezogenen Variablen.