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
```
ATIX-Crew
Neueste Artikel von ATIX-Crew (alle ansehen)
- Kafka mit Ansible automatisieren - 10. August 2023
- Konfigurationsmanagement über verschiedene Netze mit AWX - 11. Juli 2023
- Vergangenheit, Gegenwart und Zukunft von pulp_deb - 22. Februar 2023