pixel
Seite wählen

NETWAYS Blog

Unser Weg von Confluence zu BookStack

Wenn ich auf meine bald 15 Jahre bei NETWAYS zurückblicke, haben wir schon das ein oder andere Tool für Dokumentation verschlissen und verwendet. Die Reise ging von TWiki zu Foswiki, nahm eine kleinen Nebenausflug zu Mediawiki und brachte uns vor vielen Jahren letztendlich zu Confluence.

Die Entscheidung für Confluence fußte damals vor allem auf zwei Argumenten. Zum einen waren wir gerade mal 18 Leute und die Lizenzkosten für eine On-Prem-Installation überschaubar, zum anderen hatte Confluence einen sehr stabilen Eindruck gemacht und wir wollten damals von der „Selbstbeschäftigung“ und Plugin-Hölle der anderen Systeme weg, da wir dafür zu viel Zeit verbraten hatten. Kurzum, eigentlich die klassische „Dann kauf ich halt was“-Geschichte. Es wäre auch unfair zu sagen, dass die Entscheidung für Confluence eine schlechte Entscheidung war. Das Tool hat uns viele Jahre treue Dienste geleistet und obwohl schon einige Zeit nicht mehr aktualisiert, lief es bis zum gestrigen Tag ohne größere Zwischenfälle

Warum etwas Neues?

Die Motivation für ein neues Tool hatte sowohl technische als auch fachliche Gründe. Technisch entsprach die zunehmende Cloud-Only-Strategie von Atlassian, deren Systeme sich in Vergangenheit auch nicht besonders mit Ruhm bekleckert haben, nicht unseren Vorstellungen, da wir das als elementar angesehene System im On-Prem haben wollten. Hinzu sind die Lizenzkosten mit knapp 90 Leuten durchaus ein Argument sich mal etwas anderes anzusehen und ggf. damit einhergehende Aufwände die Berechtigung zu verschaffen.

Auf der anderen Seite hatten wir auch fachliche Argumente, welche für einen Neuaufbau des Systems gesprochen haben. Unser in die Jahre gekommenes Confluence hatte dringend mal einen Frühjahrsputz nötig und gleichzeitig wollten wir mit einem Handbuch gleich alle Unternehmensprozesse und Regelungen fit für ein späteres Audit machen. Persönlich favorisierte ich die Idee alles in ein System zu packen, was mir unsere Heads jedoch in der Diskussion ausredeten. Im Nachhinein klar die richtige Entscheidung, da ein Handbuch schlichtweg andere Anforderungen hat als ein Dokumentationssystem. Somit haben wir jetzt zwei Systeme (Handbook & Docs) mit unterschiedlichen Anforderungen. Das Handbook ist die „Gesetzgebung“ unserer Firma und das für alle verbindliche Regelwerk. Die Docs spiegeln die Arbeitsdokumente der einzelnen Abteilungen wieder und unterscheiden sich somit signifikant von unserem Handbook.

Wieso nun BookStack?

Von Confluence kommend waren die Anforderungen gar nicht so klein. LDAP sollte gehen, individualisierter PDF-Export, Berechtigungen für Extern und Intern, Zeichnungen sollen direkt im Wiki möglich sein, eine API um technische Informationen (bspw. Kunden im NWS-Umfeld) automatisch zu erstellen und natürlich eine gute Suche und Top-Performance. Nach etwas Recherche bin ich immer wieder über zwei Systeme gestolpert, Wiki.js und BookStack. Beide Systeme sind Open Source und machten in ersten Tests mit Docker einen guten Eindruck. Wiki.js war das auf den ersten Blick modernere System und in vielen Punkten sehr ähnlich zu Confluence. Wenn ich ehrlich bin, weiß ich nicht mehr genau, welches Hauptargument gegen den Einsatz von Wiki.js gesprochen hat. Gründe dagegen waren jedoch, dass das ein oder andere Feature für Version 3.0 angekündigt war, deren Milestone immer verschoben wurde und bis heute nicht verfügbar ist. Auch die Tatsache, dass es Confluence sehr ähnlich war, schreckte mich final davor zurück.

Das Hauptargument Wiki.js nicht zu nehmen, war jedoch nicht Wiki.js sondern BookStack. Auf BookStack bin ich bei der Recherche immer wieder gestoßen, hatte es jedoch nie ernsthaft in Betracht gezogen. Mir schienen die Features nicht ausreichend für unsere Bedürfnisse und darüber hinaus hielt ich die feste Struktur von BookStack, welches die Idee hat ein virtuelles Bücherregal darzustellen, für unzureichend. Im Nachhinein hat sich gerade diese Struktur als einer der größten Pluspunkte herausgestellt und daher bin ich bis heute froh, dass wir uns für BookStack entschieden haben. Darüber hinaus hat uns der pragmatische und sehr aufgeräumte Ansatz von BookStack und die permanente Weiterentwicklung überzeugt.

Was macht BookStack aus?

Ziel es Blogposts soll es nicht sein, verschiedene Wiki- und Dokumentationslösungen miteinander zu vergleichen (vielleicht kommt das mal zu einem späteren Zeitpunkt, aber derartige Artikel gibt es sowieso wie Sand am mehr), sondern eher was uns dazu motiviert hat, den Weg mit BookStack zu gehen und wie wir es umgesetzt haben.

Wie bereits oben angesprochen, stellt BookStack ein virtuelles Bücherregal zur Verfügung und ordnet seine eigentlichen Dokumente, bei BookStack Pages genannt, in eine feste Struktur. Es gibt Shelves, Books und Pages, das wars. Bei Bedarf können Pages noch in so genannte Chapter gruppiert werden, was jedoch optional ist. Genau da steckt aus meiner Sicht ein großer Vorteil von BookStack. Das System verbietet einfach endlose Seitenhierarchien aufzubauen, in welchen sich nach kurzer Zeit keiner mehr zurechtfindet. Die flache und vorgegebene Struktur zwingt einen bei Erstellung der Dokumente über den richtigen Ort nachzudenken und gibt dem ganzen System eine solide Grundordnung. Wir repräsentieren heute jeden Unternehmensbereich in einem eigenen Shelf und abstrahieren die fachlichen Strukturen dann in darunter liegenden Books. Darüber hinaus liefert die Suche auch sehr gute Ergebnisse und Dokumente sind im Vergleich zu unserem vorherigen System schnell zu finden. Auch alle anderen genannten Anforderungen hat BookStack erfüllt und neben LDAP, Zeichnungen, PDF-Export und API geht eigentlich alles, was wir so brauchen. Der Editor kann sowohl im WYSIWYG- als auch im Markdown-Modus verwendet werden, was den Bedürfnissen unserer Mitarbeiter:innen entsprechend entgegenkommt.

Wie haben wir den Umzug gemacht?

Den Teil des Handbooks haben wir zu 95% neu geschrieben. Zum einen waren viele Regelungen und Informationen nicht einheitlich bzw. überhaupt nicht vorhanden. Zum anderen war uns wichtig, dass die Dokumente gleich die entsprechenden Vermerke für eine spätere ISO-Zertifizierung beinhalten. Hinzu war entscheidend, dass wir Dinge wie Stellenbeschreibungen, Unternehmensstruktur und Übersicht aller Mitarbeiter:innen automatisch erstellen. Auch die jeweiligen Assets, welche wir in Snipe-IT verwalten, sollten entsprechend ausgelesen und in den Seiten dargestellt werden. Den Teil der dynamischen Generierung haben wir dann mit Python und Verwendung der API realisiert. Das Ganze läuft nun seit gut 6 Monaten ohne größere Schwierigkeiten.

Die API bietet für nahezu alle Bedürfnisse geeignete Endpunkte und ist sehr gut dokumentiert. Unter Verwendung von entsprechenden Tokens werden die Benutzerberechtigungen so an den API-Consumer weitergereicht.

Bei der Dokumentation der einzelnen Bereiche sah das ganze schon anders aus. Auch hier haben wir viele Dokumente neu geschrieben bzw. manuell übernommen. Gerade die ein oder andere Dokumentation, welche bereits vor 10 Jahren erstellt wurde, schien uns als PDF-Export vollkommen ausreichend archiviert und die manuelle Übernahme wäre eher einer Beschäftigungstherapie gleichgekommen.

In Summe haben wir gemeinsam tausende an Dokumenten gesichtet, migriert, gelöscht und neu geschrieben, aber der Aufwand hat sich gelohnt. Der alte Schrott ist weg und wir finden uns in BookStack nun gut zu recht. Die letzten Abteilungen haben ihre Daten noch unter Verwendung von Confluence Exports umgezogen und gestern haben wir das Altsystem in den wohlverdienten Ruhestand geschickt.

Was noch kommt?

Falls Interesse besteht, kann ich zu einem späteren Zeitpunkt gerne noch etwas über unsere Generatoren schreiben. Diese erzeugen nämlich nicht nur die Seiten für Mitarbeiter:innen und Assets, sondern legen auch Übersichtsseiten mit Sozialleistungen und Regelungen an, welche wir auf Basis der Page-Tags generieren. Auch Consulting könnt ihr jederzeit bei uns kaufen. So richtig etabliert haben wir das im Professional Services noch nicht, aber dann komme eben ich vorbei. Noch kenne ich mich aus 🙂

Darüber hinaus werden wir BookStack aller Wahrscheinlichkeit nach in unser NWS-Portfolio übernehmen, da es eine sehr gute Ergänzung zu unseren bestehenden Produkten darstellt. An dieser Stelle auch ein herzlicher Dank an Dan Brown, welcher in Vollzeit an BookStack arbeitet und es als Open Source Software zur Verfügung stellt. Zur Unterstützung des Projekts haben wir einen Supportvertrag abgeschlossen, den wir bisher jedoch noch nie benötigt haben. Auch ein weitergehendes Engagement wird vermutlich bald kommen, aber dazu später mehr.

Fazit

Confluence hat uns einen guten Dienst erwiesen, aber auf Basis von BookStack und dank der Mitarbeit aller haben wir nun eine neue und modulare Basis für unser Handbook und Dokumentation. Jeder manuelle Schritt und die Überarbeitung waren der Qualität zuträglich und haben uns besser gemacht. BookStack hat sich darüber hinaus als unglaublich stabiles und innovatives Produkt erwiesen, welches ich Euch nur ans Herz legen kann. Für mich die Alternative zu Confluence schlechthin.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinen beiden Söhnen und seiner Tochter.

Kickstart your Laptop with Linux

Alle paar Jahre bekomme ich einen neuen Laptop bei Netways. Vor zwei Wochen war es wieder so weit und somit eine gute Gelegenheit mal wieder die Betriebssystem-Frage zu stellen. Die alte Frage also: „Welches Linux ist das Beste?“. Also für mich ganz persönlich. Nicht für die weite Welt. Zur Auswahl stehen die rpm Fraktion wie centos, fedora oder rhel; debianoide wie ubuntu, mint, debian und arch Derivate wie Manjaro oder Endeavour.

Entscheidungsmatrix

  • Suse ist raus, fedora ist mir zu unstable, centos/rhel zu altbacken.
  • ubuntu ist mir zu kommerziell, debian zu rock-stable, mint vereinigt irgendwas dazwischen
  • Manjaro finde ich ganz gut, Endeavour ist ein reines Arch mit beigelegtem installer.

Ergebnis

Ich nehme nichts von alledem, sondern Arch-Linux ohne Verpackung, aus folgenden Gründen.

Ein sehr neuer Laptop hat manchmal aktuelle Chipsätze oder ähnliches, die einen aktuellen Kernel oder andere Tools erfordern. Bei Arch Linux bekommt man immer aktuelle Software und muss nicht auf einen neuen Major-Release der Distro warten, da es sich um einen Rolling-Release handelt.
Für die Installation des OS brauche Endeavour oder Manjaro mehr. Das reine Arch Linux bringt mittlerweile einen terminal basierten Installer mit. Bis vor ein paar Jahren musste man die im Arch-Wiki beschriebene Schritt für Schritt Installation durchführen. Jetzt hat sich das mit archinstall aber sehr vereinfacht. Hier hat man nach circa 5 Minuten ein lauffähiges System. In meinem Fall: Eine LUKS verschlüsselte Basis Partition, darauf ein Gnome mit Wayland. Eine Besonderheit ist mir dabei aufgefallen. Per Default wird nicht mehr grub sondern systemd-boot genutzt. Ein letzter Fallstrick: Man sollte bei „Netzwerk“ angeben, dass der NetworkManager die Verbindungen verwaltet, sonst hat man nach dem Neustart der Installation kein Netzwerk mehr. Damit dann nicht zu langweilig wird ist dann natürlich kein NetworkManager installiert und ohne Internet ist das auhch nicht möglich. Da ifconfig(depricated) auch nicht installiert ist landet man dann schnell an dem Punkt, wo man mit dem *ip* command weiterhelfen muss.
Generell ist das Arch-Wiki eine gute Anlaufstation für Hilfe. Obwohl Arch eine viel kleinere Nutzerbasis hat als Ubnutu oder fedora, ist das Wiki mittlerweile so ausführlich, dass ich darin auch Lösungen für Probleme finde die ich mit anderen Distros habe.
Updates: funktionieren einfach. Ich benutze seit circa sieben Jahren Arch Linux und konnte in der Zeit immer problemlos updaten. Ab und zu muss man mal den keyring aktualisieren wenn die Updates lange ignoriert wurden aber die Updates – an und für sich – funktionieren einfach.
Bei Ubuntu oder Fedora kann man das Glück haben das ein Softwarehersteller direkt Pakete baut und anbietet. Bei Arch nicht. Bei Arch gibt es allerdings das Arch User Repository (AUR). Hier werden an zentraler Stelle Pakete von einer großen Community gepflegt. Ein AUR Paket besteht dabei im Prinzip aus einem Pacman-Install-Skript(PKGBUILD), dass entweder vorkompilierte binaries von *irgendwo* laden oder auch mit Quelltext Binaries on-demand kompilieren kann. Allerdings muss man sich bewusst sein, dass die PKGBUILD zwar im AUR von der Community geprüft werden *können*, aber nicht in jedem Fall sicher sind. Ich finde aber das PKGBUILD-Format ist sehr einfach lesbar und man kann genau nachlesen was genau von wo heruntergeladen und wie installiert wird. Wenn man z.B. spotify aus dem AUR installiert kann man nachlesen, dass das debian Paket hierfür genutzt wird und von repository.spotify.com geladen wird. Außerdem kann man hier sehen, wie gpg genutzt wird um den Inhalt zu verifizieren.

[...]
source=('spotify.protocol'
'LICENSE'
"${pkgname}-${pkgver}-x86_64.deb::http://repository.spotify.com/pool/non-free/s/spotify-client/spotify-client_${pkgver}.${_commit}_amd64.deb"
[...]

Um mit AUR Paketen einfach installieren zu können favorisiere ich YAY, dass als pacman replacement fungiert. Eine Installation von eben genanntem Spotify würde man z.B. mit *yay spotify* anstoßen. Und bevor ich es vergesse: die schicken Icons aus dem Screenshot kommen aus dem buuf icon-set und können auch mit yay installiert werden.

To the moon

Für mich ist Arch aktuell das optimale Betriebssystem und wenn alle Anderen ihren Fehler endlich eingesehen haben könnte 2023 das Jahr des Linux-Desktops werden.

Christoph Niemann
Christoph Niemann
Senior Consultant

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

Ceph auf Raspberry Pi als Bastelstorage

Ceph auf Raspberry Pi als Bastelstorage ist eine (relativ) einfache Möglichkeit, eine Technologie wie Ceph auszuprobieren, ohne gleich Racks voller Server anschaffen zu müssen. Ceph hat mich schon sehr lange gereizt, es mal intensiver ansehen zu können, aber mich hat immer der doch nicht unerhebliche Hardware-Aufwand abgeschreckt. Nach etwas Recherche habe ich aber herausgefunden, dass man, mit einigen Kompromissen, durchaus ein taugliches System auch mit einfacher Hardware zum Laufen bekommen kann.

Da ich oft höre, dass ich zu viele Worte mache, dachte ich, ich lass den technischen Teil diesmal großteils weg und verlinke dafür auf die Anleitung, die ich selber benutzt habe. Doch eine Warnung vorweg: Das, was man sich damit bastelt, ist sicherlich nicht das, was man „Best Practices“ oder auch nur „stabil für Produktion“ nennen würde. Meiner Erfahrung nach reicht es aber auf jeden Fall für’s Home Lab, als Storage für einen Proxmox mit diversen Services für Home Automation (z.B. Homeassistant und Grafana mit InfluxDB) und als Ablöse für eine 10 Jahre alte Qnap (mit entsprechendem Backup jedenfalls).

Was ich verändert habe, zu der Anleitung ist folgendes

  • Statt PoE werden meine Raspis direkt mit Strom versorgt
  • Ich habe nur 3 Raspberry Pi, dafür weitere Knoten (siehe unten)
  • Statt der mikrigen USB Sticks, die hauptsächlich für Tests taugen, hab‘ ich jedem Raspi eine 8TB USB Platte verpasst (Muhahaha!)

Durch die insgesamt 24TB Storage, die sich bei mir ergeben haben, habe ich, trotz ausreichender Redundanz tatsächlich genug Platz, meine VMs und eben den Inhalt der Qnap dorthin übernehmen zu können. Da meine Raspberry Pi jeweils nur 4GB Ram haben, bin ich schon sehr weit von „Best Practices“ entfernt. Aber was soll ich sagen: Es funktioniert doch erstaunlich gut. Aber, es hat sich auf jeden Fall bewährt, einige der Ceph-internen Dienste auf andere Hosts auszulagern. Im nächsten Abschnitt erkläre ich kurz, wie.

Das Ceph nutze ich als Storage Backend für 3 Proxmox Hosts, wofür die drei Raspberry Pi gerade noch ausreichend sind. Spätestens wenn man aber Ceph-FS (also das Filesystem, das man direkt einbinden kann) möchte, braucht man noch weitere Dienste. Das geht sich auf den Raspberry Pis dann insgesamt nicht mehr aus. Nach der Anleitung erhält man über das Ceph Dashboard eine Möglichkeit, Dienste auf Knoten im Cluster zu verschieben. Ein „Dienst“ In diesem Zusammenhang ist dann „unter der Haube“ ein Docker Container, der auf dem angegebenen Host gestartet wird. Dabei sucht sich Ceph per Default einfach Knoten aus, auf denen die Container gestartet werden – meist mehrere für Redundanz. Wenn man das steuern will, kann man den Knoten Tags verpassen und Services an Tags binden. Um jetzt die Last von den Raspberry Pi zu bekommen, habe ich nochmal drei Knoten mit Fedora Server hochgezogen, diesmal aber in Proxmox. Um kein Henne-Ei Problem zu erschaffen liegt deren Storage auf den lokalen SSDs der Proxmox Hypervisor. Damit beantwortet sich auch die Frage, ob man in Ceph verschiedene Architekturen mischen kann: Ja. Im Endeffekt sind jetzt die „OSD“, also die Dienste, die sich ums Storage Management kümmern, auf den Raspis und alles andere auf den VMs auf dem Proxmox.

Ceph-Dashboard

Screenshot meines Ceph Dashboard

Wie geht’s weiter

Das schöne an Ceph ist, dass man beim Ausbau so flexibel ist. Wenn ich bei der Qnap mehr Speicher möchte, müsste ich aktuell eine neue Qnap kaufen und alle Platten ersetzen. Dagegen kann ich bei Ceph einfach noch einen Raspi mit einer weiteren Platte dazu stellen. Damit hätte ich nicht nur mehr Speicher, sondern auch mehr Durchsatz, mehr Ram, mehr CPU und vor allem mehr Redundanz.

Wenn’s mal zu langsam wird, könnte ich auch NUCs oder ähnliches Gerät mit anbinden und Dienste, die besonders viel Geschwindigkeit brauchen, dort laufen lassen.

Was waren die Probleme?

Am meisten geärgert hat mich, dass ich nicht kapiert hatte, dass die Ceph Container nur auf 64 bit Systemen laufen. Das heisst, man braucht erstens einen Raspberry Pi 4 (oder einen bestimmten 3er) und ein 64bit OS. Die Anleitung zeigt hier nur auf die Fedora Installationen. Die 64bit Variante muss man sich erst noch raus suchen. Bevor ich das kapiert hatte, musste ich meine Raspi ein paar mal neu aufsetzen.

Die 8TB Platten wurden mir lange nicht angezeigt. Man kann Platten in der Version des Dashboards, das mir installiert wurde, wohl nicht für die Verwendung vorbereiten. Dafür gibt’s dann folgenden Befehl, der die cephadm CLI in einem eigenen Container startet.

./cephadm ceph-volume lvm zap /dev/sda

Der Befehl plättet dann die Platte /dev/sda und stellt sie als ganzes für Ceph bereit.

Fazit

Sonderlich lange läuft meine Ceph Installation noch nicht, weshalb ich noch keine Langzeiterfahrungen damit anführen kann. Bisher lässt sie sich aber gut an, um Ceph mal kennen zu lernen und auch ausreichend Platz für zuhause bereitstellen zu können. Ich bin froh, dass ich es probiert habe und werde das System wohl langsam und nach Bedarf ausbauen.

Thomas Widhalm
Thomas Widhalm
Lead Systems Engineer

Pronomina: er/ihm. Anrede: "Hey, Du" oder wenn's ganz förmlich sein muss "Herr". Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 ist er bei der NETWAYS. Zuerst als Consultant, jetzt als Leiter vom Operations Team der NETWAYS Professional Services, das unter anderem zuständig ist für Support und Betriebsunterstützung. Nebenbei hat er sich noch auf alles mögliche rund um den Elastic Stack spezialisiert, schreibt und hält Schulungen und macht auch noch das eine oder andere Consulting zum Thema. Privat begeistert er sich für Outdoorausrüstung und Tarnmuster, was ihm schon mal schiefe Blicke einbringt...

Ansible – Testing roles with Molecule

Ansible is a widely used and a powerful open-source configuration and deployment management tool. It can be used for simple repetitive daily tasks or complex application deployments, therefore Ansible is able to cover mostly any situation.

If used in complex or heterogene environments it is necessary to test the code to reduce time to fix code in production. To test Ansible code it is suggested to use Molecule.

Molecule is a useful tool to run automated tests on Ansible roles or collections. It helps with unit tests to ensure properly working code on different systems. Whether using the role internally or provide it to the public, it is useful to test many cases your role can be used. In addition Molecule is easily integrated into known CI/CD tools, like Github Actions or Gitlab CI/CD.

In this short introduction I’ll try get your first Molecule tests configured and running!

Please make sure you installed Molecule beforehand. On most distributions it’s easily installed via PIP.
The fastest and most common way to test roles would be in container. Due to a version problem with systemd currently it’s not possible to start services over systemd in containers. For this reason you can easily start with a vagrant instance and later migrate to docker or podman easily.


pip install molecule molecule-vagrant

If you have a role you can change into the role directory and create a default scenario.


cd ~/Documents/netways/git/thilo.my_config/
molecule init scenario -r thilo.my_config default
INFO     Initializing new scenario default...
INFO     Initialized scenario in /Users/thilo/Documents/netways/git/thilo.my_config/molecule/default successfully.

Below the molecule folder all scenarios are listed. Edit the default/molecule.yml to add the vagrant options.

Add a dependency file with your collections as with newer Ansible versions only the core is available. If needed you can add sudo privileges to your tests.

molecule/default/molecule.yml


---
dependency:
  name: galaxy
  options:
    requirements-file: collections.yml
driver:
  name: vagrant
platforms:
  - name: instance
    box: bento/centos-7
provisioner:
  name: ansible
verifier:
  name: testinfra
  options:
    sudo: true

The converge.yml is basically the playbook to run on your instance. In the playbook you define which variables should be used or if some pre-tasks should be run.

molecule/default/converge.yml


---
- name: Converge
  hosts: all
  become: true
  tasks:
    - name: "Include thilo.my_config"
      include_role:
        name: "thilo.my_config"

Now you can run your playbook with molecule. If you want to deploy and not delete your instance use converge. Otherwise you can use test, then the instance will be created, tested and destroyed afterwards.


python3 -m molecule converge -s default
or 
python3 -m molecule test -s default

Finally we can define some tests, the right tool is testinfra. Testinfra provides different modules to gather informations and check them if they have specific attributes.

Your scenario creates a tests folder with the following file: molecule/default/tests/test_default.py

In this example I’ll test the resources my role should create.


"""Role testing files using testinfra."""


def test_user(host):
    """Validate created user"""
    u = host.user("thilo")

    assert u.exists

def test_authorized_keys(host):
    """Validate pub key deployment"""
    f = host.file("/home/thilo/.ssh/authorized_keys")

    assert f.exists
    assert f.content_string == "ssh-rsa AAAA[...] \n"

And if we already converged our instance, we can verify these definitions against our deployment.


python3 -m molecule verify
INFO     default scenario test matrix: verify
INFO     Performing prerun with role_name_check=0...
[...]
INFO     Running default > verify
INFO     Executing Testinfra tests found in /Users/thilo/Documents/netways/git/thilo.my_config/molecule/default/tests/...
============================= test session starts ==============================
platform darwin -- Python 3.9.12, pytest-6.2.5, py-1.11.0, pluggy-0.13.1
rootdir: /
plugins: testinfra-6.4.0
collected 2 items

molecule/default/tests/test_default.py ..                                [100%]

============================== 2 passed in 1.79s ===============================
INFO     Verifier completed successfully.

With those easy steps you can easily test your roles for any scenario and your deployments can run without any hassle or at least you will be more relaxed during it 😉

Check out our Blog for more awesome posts and if you need help with Ansible send us a message or sign up for one of our trainings!

Thilo Wening
Thilo Wening
Senior Consultant

Thilo hat bei NETWAYS mit der Ausbildung zum Fachinformatiker, Schwerpunkt Systemadministration begonnen und unterstützt nun nach erfolgreich bestandener Prüfung tatkräftig die Kollegen im Consulting. In seiner Freizeit ist er athletisch in der Senkrechten unterwegs und stählt seine Muskeln beim Bouldern. Als richtiger Profi macht er das natürlich am liebsten in der Natur und geht nur noch in Ausnahmefällen in die Kletterhalle.

Kibana: Frontend des Elastic Stacks

Was nutzt das beste Log Management, wenn man sich das Ganze nicht auch ansehen kann? Für den Elastic Stack kann man hier auf Kibana setzen – ein mächtiges Tool, das neben höchster Funktionalität auch noch sehr schick aussieht.

Kibana – was ist das? Die wichtigsten Fakten!

  • Benutzeroberfläche: offen und kostenlos
  • Visualisierung der Elasticsearch-Daten mit folgenden Anzeigeoptionen:
    • Histogramme
    • Liniendiagramme
    • Kreisdiagramme
    • Ringdiagramme und vieles mehr
  • Elastic Maps bietet die Möglichkeit, Topographien und Ebenen zu erstellen – perfekt geeignet für Eure Standortanalysen!
  • Darstellung mithilfe von Graphen und Netzwerken erlaubt das Aufzeigen von bisher unerkannten Zusammenhängen
  • Navigieren im Elastic Stack
  • Suchfunktion und Filter über alle Dokumente hinweg – Abfragen, Transformationen und Visualisierungen werden durch unkomplizierte Ausdrücke erstellt
  • Analyse Eurer Daten anhand von Zeitreihen
  • Erkennen von Anomalien: durch ein selbstständiges Machine Learning kann analysiert werden, wodurch Anomalien auftreten und beeinflusst werden
  • Alarmierung im Falle des Falles! Stellt selbst Eure Schwellenwerte ein, egal ob index- oder metrikbasiert und lasst Euch benachrichtigen über:
  • Alle Alarmierungen können auch als Verlauf angezeigt werden!

Oder wie Elastic es so schön nennt: „Das Fenster in den Elastic Stack.“

Hier noch ein Screenshot, damit man sich auch ein Bild von den Möglichkeiten machen kann:

Quelle: https://www.elastic.co/de/kibana/

Wir haben Euer Interesse an Kibana und dem Elastic Stack geweckt? Ihr wollt vielleicht wissen, ob die Tools als Lösung für Eure Use Cases in Frage kommen? Dann kommt einfach auf uns zu! Wir sind erreichbar unter sales@netways.de oder über unser Kontaktformular.

Auch könnt Ihr über unsere Website direkt Schulungen buchen für Elastic, aber auch für viele andere Produkte wie Graylog oder Icinga 2. Solltet Ihr Euch unsicher sein oder weitere Infos benötigen, dann kontaktiert einfach unsere Kollegen über events@netways.de.

Wer kurzfristig etwas lernen möchte, dem empfehle ich unsere Webinare. Hier findet hier auf unserer Website die bereits gehaltenen Webinare sowie Ankündigungen für neue. Insbesondere haben wir kürzlich Webinare zum Thema Elastic hinzugefügt.