Workshops in da Cloud – Was einem Ansible, Docker und die GitLab CI/CD hierfür bietet

Ansible dient als Open-Source Programm dem Configuration-Management und der Automatisierung von Administrationsaufgaben. Es zeichnet sich durch eine strikte Trennung von Code und Parametern aus. Ziel ist die Abbildung von Infrastruktur als Code (Infrastructure-as-a-Code). Unter Befolgung der Best Practice Guidelines ist Idempotenz jederzeit gewährleistet. 

Somit wird nur an fehlerhaft konfigurierten Dateien Hand angelegt. Die valide Konfiguration wird abgefragt, bleibt aber nach Überprüfung unangetastet. Dies spart Ressourcen und Zeit. Ein weiterer Vorteil von Ansible liegt in der Fülle an bereitgestellten Modulen für Cloud, Datenbanken, Paketmanagement und vielem mehr. Ansible ist somit als Tool für die automatisierte Orchestrierung, Konfiguration und Administration von IT-Systemen zum Aufsetzen der für einen Schulungsbetrieb notwendigen IT prädestiniert.

Bei den von uns angebotenen Trainings wird die Infrastruktur kurz vor Beginn des Workshops hochgezogen. Diese ist dann wenige Tage im Einsatz und wird nach dem Workshop wieder automatisiert gelöscht. Aufgrund dieser Kurzlebigkeit haben wir uns für eine Cloud-basierte Lösung entschieden. Die Versionsverwaltung erfolgt mittels Git. Quelldateien sind auf der Weboberfläche von unserer GitLab Installation direkt einsehbar, sodass die GitLab CI/CD sich für das VM Provisioning anbietet. Bei Start der GitLab Pipeline wird initial nachfolgende gitlab-ci.yml Datei im Git Repository eingelesen.

stages:
  - command
  - only_after_setup
 
.command: &command
  stage: command
  tags:
    - docker
  image:
    name: atix-registry.infra.dev.atix/ansible_hcloud:latest
    entrypoint: ["sh", "-c"]
  script:
    - ansible localhost -m template -a "src=requirements.yaml.j2 dest=requirements.yaml"
    - ansible-galaxy install -r requirements.yaml
    - ansible-playbook --tags "$CI_JOB_NAME" ${VERBOSE:+-vvv} playbook_basic.yaml
    etc.
  when: manual
 
cleanup:
  <<: *command
 
facts:
  <<: *command
 
setup:
  <<: *command
  artifacts:
    paths:
      - artifact.tar
    expire_in: 1 week
 
workshop:
  stage: only_after_setup
  tags:
    - docker
  image:
    name: atix-registry.infra.dev.atix/ansible_hcloud:latest
    entrypoint: ["sh", "-c"]
  dependencies:
    - setup
  script:
    - tar -C / -xvf "${CI_PROJECT_DIR}/artifact.tar"
    - ansible localhost -m template -a "src=requirements.yaml.j2 dest=requirements.yaml"
    - ansible-galaxy install -r requirements.yaml
    - ansible-playbook -i hcloud.py ${VERBOSE:+-vvv} playbook_workshop_specific.yaml
  when: manual

Diese unterteilt sich in die vier Jobs, unterteilt in zwei Stages (“Command” und “Online_after_setup”):

• cleanup” löscht alle VMs und Domains der jeweiligen Schulung (z.B. Ansible, Kubernetes)
• “facts” zeigt alle eingerichteten VMs, HCloud Optionen (VM Größen, Standorte, Volumes etc.) und Domains mitsamt ihren Eigenschaften auf
• “setup” stößt das Provisioning der Workshop Infrastruktur an, wobei hier Ansible Tasks ausgeführt werden, die für alle Schulungen von Belang sind (z.B. Firewall, SSH, Domains)
• “workshop” wird nach “setup” in einem eigenen GitLab CI/CD Stage ausgeführt und passt die Infrastruktur an die Erfordernisse der jeweiligen Schulung an. Es wird zusätzlich Software installiert und konfiguriert (z.B. kubectl für die Kubernetes Schulung), die für andere Schulungen (z.B. Ansible Schulung) nicht benötigt werden.

Unabhängig von dem gewählten Job wird ein Docker Container erstellt, darin die erforderlichen Ansible Galaxy Rollen geladen und das Ansible Playbook zur Erstellung der Cloud-Ressourcen ausgeführt. Im Falle eines Setups wird in einem der letzten Schritte die SSH Konfiguration als Download auf einem Passwort geschützten Webserver (TLS gesichert mit Let’s Encrypt Zertifikaten) den Schulungsteilnehmern bereitgestellt. Aus Sicherheitsgründen wird hierbei bewusst auf USB-Sticks und den Versand als E-Mail Anhang verzichtet.

---
https://k8s.example.org
├── group0-roadwarrior
│   ├── .ssh
│   │   ├── config
│   │   ├── id_rsa
│   │   ├── id_rsa.pub
│   │   └── known_hosts
│   └── ssh.sh
├── group0-roadwarrior.tar
├── group0-roadwarrior.zip
├── group1-roadwarrior
│   ├── .ssh
│   │   ├── config
│   │   ├── id_rsa
│   │   ├── id_rsa.pub
│   │   └── known_hosts
│   └── ssh.sh
├── group1-roadwarrior.tar
└── group1-roadwarrior.zip
```