Nachdem ich eine Ansible Rolle für Dovecot geschrieben hatte, musste nun eine Rolle für Postfix her um mein Mailsetup mit eigenen Rollen abbilden zu können.
Dies ist nun auch meine erste Rolle, die sowohl für CentOS als auch für Ubuntu freigegeben wurde. Ich bin gespannt ob man dadurch die Rolle häufiger im Einsatz sieht, aber wahrscheinlich müsste ich dafür noch ein bisschen an der Dokumentation arbeiten.
Molecule Tests von Ansible Rollen mit GitHub Actions automatisieren
Automatisches Testen ist für mich nicht neu, jedoch versuche ich meine private IT-Landschaft möglichst klein zu halten (mittlerweile zumindest). Also ging es mir nun beispielsweise darum die Installation von einem Jenkins oder einem ähnlichen Produkt zu vermeiden.
Da von Beginn an die Idee da war, meine privaten Ansible Rollen auch zu veröffentlichen, habe die Git-Repositories dazu gleich bei GitHub erstellt (siehe https://github.com/bubebyte) und konnte somit auf die komfortable Funktion der GitHub Actions zurück greifen. Mit GitHub Actions kann man im Handumdrehen Funktionalitäten einrichten wie in meinem Fall das durch den Push getriggerte Testen einer Ansible Rolle. Den Molecule Test muss man natürlich noch selbst schreiben, aber die Build-Pipline samt dem Spawnen von den nötigen Containern, übernimmt die GitHub Action.
Es gibt vorgefertigte GitHub Actions in der Community. Für die Ansible Rolle remi_php74 habe ich die Action von Robert de Bock namens molecule-action genutzt. Bei den Containern, die zum Testen verwendet werden, habe ich auf die Container von Jeff Geerling gesetzt. Die Definition der GitHub Action sah dann initial wie folgt aus und sollte im Git Repo unter .github/workflows abgelegt werden:
---
name: Role testing with Molecule
on:
- push
- pull_request
jobs:
test:
runs-on: ubuntu-20.04
steps:
- name: checkout
uses: actions/checkout@v2
with:
path: "${{ github.repository }}"
- name: molecule
uses: robertdebock/molecule-action@2.6.8
with:
namespace: geerlingguy
image: docker-centos8-ansible
tag: latest
Mit dieser GitHub Action war ich zu Beginn sehr glücklich, da ich für meinen Einsatzzweck nur den Test für CentOS 8 benötigte. Fügt man bei diesem Konstrukt nun einfach weitere Tests für andere Betriebssysteme unten an, würden diese seriell nacheinander abgearbeitet, was die Testdauer natürlich entsprechend verlängert.
Viel besser wäre es, wenn die Tests auf den verschiedenen Betriebssystemen parallel laufen würde. Dies ist auch kein Problem, da man die verschiedenen Betriebssysteme bzw. die verschiedenen Docker Images für die Tests in einer Matrix eintragen kann. Matrix könnte mit meinen Beispiel etwas verwirrend sein, aber es ist auch möglich in dieser Matrix beispielsweise weitere Testszenarien zu defenieren. So würde jedes OS dann mit jedem Testszenario gebaut werden. Aber bleiben wir bei dem Beispiel, mit dem wir den gleichen Test / das gleiche Testszenario auf mehreren Betriebssystemen testen wollen. Die GitHub Action würde dann wie folgt aussehen:
---
name: Role testing with Molecule
on:
- push
- pull_request
jobs:
test:
runs-on: ubuntu-20.04
strategy:
matrix:
image:
- docker-centos7-ansible
- docker-centos8-ansible
steps:
- name: checkout
uses: actions/checkout@v2
with:
path: "${{ github.repository }}"
- name: molecule
uses: robertdebock/molecule-action@2.6.8
with:
namespace: geerlingguy
image: "${{ matrix.image }}"
options: parallel
tag: latest
Diese Action würde zunächst genau das machen, was wir uns gewünscht haben. Das Testszenario würde auf einem CentOS 7 und einem CentOS 8 Container gleichzeitig ausgeführt werden.
Um nun jedoch zu vermeiden, dass uns das Linting gleichzeitig zwei Mal erzählt, dass wir zu viele Leerzeichen am Zeilenende haben, bietet es sich an erstmal das Linting auf einem System durchzuführen und erst wenn dieses keine Fehler erzeugt hat, die Tests parallel laufen zu lassen. Die Definition würde dann wie folgt aussehen:
---
name: Role testing with Molecule
on:
- push
- pull_request
jobs:
lint:
runs-on: ubuntu-20.04
steps:
- name: checkout
uses: actions/checkout@v2
with:
path: "${{ github.repository }}"
- name: molecule
uses: robertdebock/molecule-action@2.6.8
with:
command: lint
test:
needs:
- lint
runs-on: ubuntu-20.04
strategy:
matrix:
image:
- docker-centos7-ansible
- docker-centos8-ansible
steps:
- name: checkout
uses: actions/checkout@v2
with:
path: "${{ github.repository }}"
- name: molecule
uses: robertdebock/molecule-action@2.6.8
with:
namespace: geerlingguy
image: "${{ matrix.image }}"
options: parallel
tag: latest
Wer einen funktionellen Molecule Test mit einem default Szenario implementiert hat, sollte mit dieser Definition direkt das gewüschte Ergebnis erzielen können.
Viel Spaß damit!
Dovecot Ansible Rolle in der Galaxy veröffentlicht
Eine Ansible Rolle für Dovecot nach meinen Wünschen musste her. Zunächst gab ich mich auf die Suche nach einer geigneten Rolle in der Galaxy, jedoch war die einzige Rolle, die mir eigentlich zugesagt hatte nur für Ubuntu Systeme geschrieben. So entschied ich mich eine eigene Rolle zu schreiben und diese in der Galaxy zur Verfügung zu stellen.
Die Rolle dovecot wurde nun für CentOS 7 und CentOS 8 zur Verfügung gestellt. Sobald ich die Zeit finde, werde ich aber auch Tests mit Ubuntu machen. Dies hat aber zur Zeit nicht die höchste Priorität.
Erste Ansible Rolle in der Galaxy veröffentlicht
Da ich im beruflichen Umfeld innerhalb der letzten Jahre viel an Ansible Rollen entwickelt habe, war es nun so weit, dass ich für ein privates Projekt nun meine erste “private” Rolle geschrieben habe und diese auch in der Ansible Galaxy veröffentlicht habe.
Die Rolle remi_php74 ist sehr speziell, denn sie installiert, wie der Name schon erraten lässt, PHP 7.4 aus dem Remi Repo. Bei Bedarf werden auch die dazu nötigen Repositories eingerichtet.
Diese Rolle habe ich erstellt, da mir die anderen PHP Rollen zu generisch waren und bei der Verwendung kam es mir so vor, als müsste man sie sehr verbiegen, bis man wirklich das gewünschte Ergebnis hat. Da bei der Rolle remi_php74 der Einsatzzweck klar eingegrenzt ist, empfinde ich die Nutzung als sehr einfach und ziel-orientiert.
Erste Veröffentlichung von check_bareos_jobs
Was macht check_bareos_jobs?
Das Tool check_bareos_jobs wurde als NRPE Check entworfen und in Go/Golang geschrieben.
Beweggründe
In der Vergangenheit habe ich immer das Python Skript check_bareos.py von Steven Varco genutzt. Da ich mich aber selbst nicht mit Python anfreunden kann und mal Golang ausprobieren wollte, ist check_bareos_jobs entstanden. Mit dieser Entwicklung habe eine Basis geschaffen diesen kleinen Check an meine Wünsche anzupassen.
Download und Anwendung
Version 0.1.0 steht euch nun auf GitHub zum Download zur Verfügung. Infos zur Verwendung könnt ihr auch aus der Readme entnehmen.