2020
Dezember
21
2020

Cloud-Orchestrierung mit Ansible Collections

Ansible ist ein weit verbreitetes Automatisierungs-Werkzeug für IT-Infrastrukturen, und die erste Integration für unsere Cloud-API kam bereits mit dessen Version 2.3. Seither haben wir kontinuierlich in die Unterstützung investiert und diese erweitert. Anhand von drei einfachen Beispielen möchten wir Ihnen in diesem Beitrag einen Einblick geben in die neusten Verbesserungen, welche allein mit bzw. seit Erscheinen von Ansible 2.10.0 hinzugekommen sind.

Ansible Collection "cloudscale_ch.cloud"

Nebst Terraform ist Ansible eines der beliebtesten IT-Orchestrierungs-Werkzeuge. Bei cloudscale.ch verwenden wir Ansible intern z.B. zum Verwalten unserer Netzwerkkomponenten und praktisch der gesamten Cloud-Infrastruktur. Und natürlich sind wir bestrebt, auch unseren Kunden das Konfigurieren und Betreiben von Cloud-Ressourcen so einfach wie möglich zu gestalten.

Mit Ansible 2.10 wurde die Entwicklung und Pflege von Community-Plugins in sogenannte "Collections" ausgelagert. Viele Plugins fanden in der Collection "community.general" ein neues Zuhause, bei anderen, wie z.B. der cloudscale.ch-Integration, wurde die Entwicklung in eigene Quellcode-Repositories und Organisationen abgespalten, um eine schnellere Entwicklung und eigene Releasezyklen zu ermöglichen. So gibt es heute bereits rund 75 selbstorganisierende Collections für Ansible 2.10.

Mit unserer eigenen Ansible Collection "cloudscale_ch.cloud" erreichen wir gleich mehrere Vorteile: Zum einen können wir Erweiterungen unserer API zeitnah in unseren Plugins abbilden, zum anderen lassen sich unsere Plugins einfacher und unabhängig vom restlichen Ansible-Projekt automatisiert testen.

Die passende Version für jeden Bedarf

Die 3-wöchentlich bereitgestellten Releases von Ansible 2.10 beinhalten auch die neusten Releases der Collections, d.h. die jeweils neuste Version von "cloudscale_ch.cloud" wird automatisch im offiziellen Ansible-Paket ausgeliefert und mitinstalliert. Wer ausserhalb dieses Releasezyklus einen bestimmten Feature-Umfang nutzen möchte, kann mittels ansible-galaxy selbst Hand anlegen und die gewünschte Version unserer Collection auch mit seiner vorhandenen Ansible-Version verwenden.

Der Nachvollziehbarkeit wegen empfehlen wir, eine Datei requirements.yml zu erstellen, um über alle externen Collections wie auch Rollen die Übersicht zu behalten:

collections:
  - name: cloudscale_ch.cloud
    version: 1.3.0

Danach kann die Collection wie gewohnt über ansible-galaxy installiert werden:

ansible-galaxy collection install -r requirements.yml

Zu beachten ist, dass bisherige Playbooks ohne Anpassungen weiter funktionieren. Nur bei Plugins, welche seit Ansible 2.10 neu dazugekommen sind, muss zwingend der "Fully Qualified Collection Name" (FQCN) verwendet werden. Es spricht aber nichts dagegen, auch in bestehenden Playbooks generell auf FQCN umzustellen.

Wie gehabt ohne FQCN:

- cloudscale_server:
    name: web1.example.com
    ...

Oder entsprechend mit FQCN:

- cloudscale_ch.cloud.server:
    name: web1.example.com
    ...

Beispiel 1: Netzwerk-Management mit Subnets

In Version 1.2.0 unserer Collection wurde die Network-API integriert. Mit der aktuellsten Version 1.3.0 lassen sich nun zusätzlich auch Subnets verwalten. Dabei können Subnets angelegt und bei bestehenden Subnets die Gateway-IP sowie die DNS-Server angepasst werden:

- name: Ensure network exists
  cloudscale_ch.cloud.network:
    name: Private in LPG1
    zone: lpg1
    auto_create_ipv4_subnet: false

- name: Ensure subnet exists
  cloudscale_ch.cloud.subnet:
    cidr: 10.11.0.0/16
    gateway_address: 10.11.0.1
    dns_servers:
      - 10.11.0.2
      - 10.11.0.3
    network:
      name: Private in LPG1
      zone: lpg1

Beispiel 2: Objects Users

Bereits mit Version 1.1.0 unserer Collection – und somit gleich in Ansible 2.10.0 – hinzugekommen ist das Modul zum Verwalten von Objects Users. Dieses erlaubt zum Beispiel das automatisierte Erstellen einer Backup-Konfiguration mit Verwendung unseres Object Storage:

- name: Create a backup user
  cloudscale_ch.cloud.objects_user:
    display_name: backup for ACME
    tags:
      customer: ACME Inc.
  register: res_object_user

- name: Configure S3cfg
  template:
    src: s3cfg.j2
    dest: ~/.s3cfg

Im Template s3cfg.j2 verwenden wir die vom Modul zurückgelieferten Keys:

# {{ ansible_managed }}
[default]
access_key = {{ res_object_user.keys.access_key }}
secret_key = {{ res_object_user.keys.secret_key }}
check_ssl_certificate = True
guess_mime_type = True
host_base = objects.lpg.cloudscale.ch
host_bucket = objects.lpg.cloudscale.ch
use_https = True

Beispiel 3: Floating IPs

Auch bestehende Module haben Verbesserungen erfahren; so ist es nun möglich, Floating IPs idempotent zu erstellen. Dies wurde durch einen zusätzlichen name Parameter realisiert. Um die Rückwärtskompatibilität zu gewährleisten, ist dieser Parameter zurzeit noch optional. Erst ab der nächsten Majorversion unserer Collection wird dieser Parameter zwingend mit angegeben werden müssen.

- name: Start cloudscale.ch server
  cloudscale_ch.cloud.server:
    name: mx1.example.com
    image: debian-10
    flavor: flex-2
    ssh_keys: ssh-rsa XXXXXXXXXX...XXXX ansible@cloudscale-ch
    zone: lpg1
  register: server

- name: Request Floating IPs for my server
  cloudscale_ch.cloud.floating_ip:
    name: mx1.example.com
    ip_version: "{{ item }}"
    reverse_ptr: mx1.example.com
    server: "{{ server.uuid }}"
  with_items:
    - 4
    - 6

Mit Ansible und unserer "cloudscale_ch.cloud" Collection steht Ihnen ein mächtiges und dennoch einfaches Werkzeug zur Verfügung, um selbst eine grössere Cloud-Infrastruktur sowohl schnell als auch nachvollziehbar zu erstellen und zu betreiben. Und für alle, die sich (wie wir) für Open-Source engagieren: Der Quellcode unserer Collection steht unter der GPLv3 und ist auf GitHub verfügbar.

Stolzer Teil des Ansible-Universums,
Ihr cloudscale.ch-Team

Zurück zur Übersicht