Select Page

NETWAYS Blog

Schulungsnotebooks in neuem Gewand

In diesem Jahr konnten wir endlich wieder mehr Vor-Ort Trainings durchführen als in den vergangenen Jahren und sogar vereinzelte Inhouse-Trainings bei Kunden waren möglich. Bisher haben wir bei unseren Präsenztrainings oder auch -workshops auf Notebooks mit CentOS 7 gesetzt, und zwar deshalb weil die automatische Provisionierung durch unseren sog. “Event”-Foreman in Kombination mit Puppet seit langer Zeit gut funktioniert.

Recovery-Eintrag

Da es in der Vergangenheit für die Kollegen allerdings sehr aufwändig war die Notebooks nach jedem Training wieder ins Büro zu schleppen, sie zu verkabeln und sie dann von Grund auf neu zu installieren, haben wir uns einen Trick einfallen lassen: Nach der automatischen Grundinstallation des Betriebssystems wird ein LVM-Snapshot des Base Images erstellt. Grob gesagt heißt das der Stand des Base Images wird eingefroren und alles was neu hinzukommt bzw. verändert wird (z.B. individuelle Schulungsvorbereitungen für verschiedene Trainings) belegt zusätzlichen Plattenplatz. Damit lässt sich das ursprüngliche Base Image ohne Neuinstallation eines Notebooks schnell wieder herstellen und kann so auf das nächste Training angepasst werden.

Ein weiterer Vorteil des Ganzen ist das die Schulungsteilnehmer ihre Arbeitsumgebung so gestalten können wie sie möchten und beispielsweise auch uns nicht bekannte Passwörter setzen können, mit dem Löschen des LVM-Snapshots ist alles wieder vergessen. Um es auch technisch nicht so affinen Kollegen einfach möglich zu machen Notebooks “zurückzusetzen”, gibt es hierfür beim Booten unser Schulungsnotebooks einen “Recovery”-Eintrag im GRUB-Bootloader der den LVM-Snapshot des Base Images ohne jedes Zutun zurückspielt und das Notebook anschließend neu startet.

Wie kommen aber nun die individuellen Schulungsvorbereitungen auf die Notebooks? Ist die Frage die wir uns auch gestellt haben. Individuelle Schulungsvorbereitungen können z.B. die virtuelle Maschine(n) für das Training sein, meistens auf Basis von Virtual Box, SSH Keys, Hosteinträge, bestimmte Browser oder andere Applikationen um den Schulungsteilnehmern die praktischen Übungen überhaupt möglich bzw. so einfach wie nur denkbar zu machen. Sie in den Provisionierungsprozess einzubauen scheidet ja aus, da die Notebooks wenn überhaupt nur unregelmäßig neu installiert werden sollen.

Also haben wir uns auch hier etwas überlegt: Wir haben im allgemeinem Base Image ein Bash-Skript mit einem statischen Link zur Nextcloud abgelegt. Dort findet sich ein weiteres Skript das auf die aktuell angebotenen Trainings und die jeweils dafür benötigten Schulungsvorbereitungen verweist. D.h. hier liegen beispielsweise dann auch die aktuellen virtuellen Maschinen. Um das Ganze auf den Notebooks umzusetzen verwenden wir wieder Puppet, hier war die Transition leichter da wir das in der Vergangenheit so ähnlich eh schon im Foreman hatten. Damit auch jeder der Kollegen ein Notebook individualisieren kann, gibt’s hierfür natürlich auch einfache Auswahldialoge. Wurde ein Notebook für ein bestimmtes Training vorbereitet, so löscht sich das Skript zur Vorbereitung und kann erst nach dem Recovery wieder ausgeführt werden.

Beispielhafter Auswahldialog für individuelle Schulungsvorbereitung (teils mit historischen Trainings)

Das alles sollte nun natürlich auch weiterhin funktionieren. Da CentOS 7 ab 2024 keine Maintenance Updates mehr bekommt und wir bei manchen Schulungen die nativ auf den Notebooks durchgeführt werden auch etwas mit den veralteten Versionsständen zu kämpfen haben, fiel unsere Entscheidung auf CentOS Stream 9 als neues Betriebssystem für unsere Schulungsnotebooks. Damit wir überhaupt dran denken konnten CentOS Stream zu provisionieren musste erstmal das Debian auf unserem “Event”-Foreman angehoben werden, danach folgten viele kleine Updates von Foreman 1.22 bis zum aktuellen Release 3.4.0 und auch Puppet bzw. die Puppetmodule mussten aktualisiert werden. Im Foreman selbst waren die Mirrors für CentOS Stream einzurichten, Bereitstellungsvorlagen anzupassen und auch die Partitionierung haben wir aufgrund der gestiegenen Plattenkapazität der Notebooks adaptiert. Für einen automatischen Ablauf der Provisionierung nutzen wir das Foreman Discovery Plugin.

Foreman Discovery der Schulungsnotebooks

Wer sich nun selbst ein Bild von unseren Schulungsnotebooks machen möchte, dem kann ich natürlich auch nicht nur deswegen eines unserer Trainings oder einen unserer angebotenen Workshops ans Herz legen. Vielleicht auch im Zuge der diesjährigen OSMC (Open Source Monitoring Conference).

Markus Waldmüller
Markus Waldmüller
Head of Strategic Projects

Markus war bereits mehrere Jahre als Sysadmin in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Senior Manager Services gelandet. Seit September 2023 kümmert er sich bei der NETWAYS Gruppe um strategische Projekte. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

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
Manager Consulting

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.

Orchestration-Automation in einem Rutsch

Gerade für Testzwecke ist es von Vorteil, wenn man z.B. in der Cloud virtuelle Maschinen (VM’s) ohne großen Aufwand installieren und verwalten kann. Nur kommt noch die Installation von Programmen und Tools dazu, um die Testumgebung fertig zu bekommen, damit Test-Szenarien abgebildet werden können. Tools wie Terraform, Ansible oder Puppet und Bolt kommen da meistens zum Einsatz. Aber wie wäre es, wenn zum Beispiel sein Terraform-Deployment Verzeichnis  mit den .tf files schon vorhanden ist und nur alles in einem Rutsch ausrollen möchte. Da ich mich mit puppet-bolt schon mal auseinander gesetzt hatte, suchte ich nach einer Lösung und wurde fündig, denn Bolt kann terraform apply  ausführen, puppet-agent darauf installieren und der anschließend ein Puppet Manifest ausrollen. In meinem Kurz-Beispiel wird eine Ubuntu  VM erzeugt, Apache2 installiert und eine Webseite erstellt.

Wie das funktioniert erkläre ich in diesem Post:
Voraussetzung:
Terraform, puppet-agent und puppet-bolt müssen installiert sein.

Ich habe mir ein Verzeichnis angelegt z.B. terraform_puppet und in diesem sind folgende Dateien abgelegt:

├── bolt-project.yaml
├── data
│   └── common.yaml
├── files
│   └── site.html
├── hiera.yaml
├── inventory.yaml
├── manifests
├── plans
│   └── init.pp

Wichtig von den Dateien ist die bolt-project.yaml, die inventory.yaml und die init.pp, deren Inhalt sieht folgendermaßen aus:

bolt-project.yaml
---
name: terraform_puppet
modulepath: ~/puppet/modules

inventory.yaml
---
groups:
- name: terraform
targets: []
config:
transport: ssh
ssh:
private-key: ~/.ssh/passwordlesskey/id_rsa
user: ubuntu
host-key-check: false

Die ganze Magie passiert aber in dem Skript init.pp

plan terraform_puppet(String $tf_path) {
$localhost = get_targets('localhost')

# Create infrastructure with terraform apply
run_command("cd ${tf_path} && terraform apply --auto-approve && sleep 20", $localhost)
$ip_string = run_command("cd ${$tf_path} && terraform output instance_ips",
$localhost).map |$r| { $r['stdout'] }
$ips = Array($ip_string).map |$ip| { $ip.strip }

# Turn IPs into Bolt targets, and add to inventory
$targets = $ips.map |$ip| {
Target.new("${$ip}").add_to_group('terraform')
}

# Deploy website
apply_prep($targets, _run_as => 'root', _required_modules => ['apache'])

apply($targets, _run_as => 'root') {
include apache
file { '/var/www/html/index.html':
ensure => 'file',
source => 'puppet:///modules/terraform_puppet/site.html',
}
}
return $ips
# Or diagnose issues across your terraform infrastructure
run_command('uptime', $targets)
}

Ich habe das ganz bei uns im Openstack umgesetzt, es kann aber auch in anderen Cloud Umgebungen übernommen werden und muss diesbezüglich angepasst werden.

So um das ganze jetzt in Gang zu setzen führt man folgendes Kommando in diesem terraform_puppet Verzeichnis aus:

bolt plan run terraform_puppet -i inventory.yaml tf_path=~/terraform/vmdir

Für alle die, die Puppet und Ruby Wissen haben, sollte das selbsterklärend sein, ansonsten grobe kurze Erklärung:

Bolt führt ein Skript aus das ein Terraform apply triggert und die IP als Variable speichert und als inventory Host-Target zu den groups hinzufügt,
damit diese als $target Variable vom Bolt inventory und dann per puppet apply genutzt werden kann. Das puppet Module Apache wird dazwischen auch mit eingelesen und genutzt.
Das schöne ist, die Funktion von bolt apply_prep, diese sorgt dafür, das für das per terraform installierte VM-OS der puppet-agent installiert und ausgeführt werden kann, wenn man das ganze laufen lässt sieht man es als command durchlaufen.
Anschließend wird per bolt apply ein puppet code  per puppet apply ausgeführt, der in unserem Fall den Apache2 installiert und einen index.html an die entsprechende Stelle kopiert (die man vorher unter files selber anlegen muss) und dann den Apache2 Service startet.

Das Ergebnis sollte dann die Webseite der index.html sein , wenn man die IP-Adresse der VM im Browser (http://$ipaddress_vm eingibt.

Das ist natürlich nur ein ganz vereinfachtes Beispiel, aber die Möglichkeiten die man damit hat, finde ich genial.

Natürlich bieten wir zum Thema Puppet auch Trainings an, wo man die Grundlagen der Automatisierung mit Puppet vermittelt bekommt.

Viel Spaß und Erfolg beim Ausprobieren.

Johannes Carraro
Johannes Carraro
Senior Systems Engineer

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Team Operations als Senior Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren.

Orchestration mit Puppet Bolt

Viele von den SysAdmins kennen das Tool mit dem A und deswegen möchte einen kleinen Einstieg zu Puppet Bolt geben.
Um Bolt nutzen zu können muss auf der Distribution seiner Wahl das Repository https://yum.puppet.com eingebunden sein und das Paket puppet-tools installiert sein. Zusätzlich brauchen wir für unseren kleinen Test das Paket docker und docker-compose, das auf dem System zu Verfügung stehen muss, da wir das die Aktionen auf Docker Containern deployen wollen.

Zuerst werden wir ein Bolt-Projekt Verzeichnis erstellen, wo dann das Modul-Verzeichnis darin erstellt wird:
mkdir my_infra && cd my_infra

Verzeichnis als bolt Arbeitsverzeichnis verifizieren:
bolt project init my_infra
In dem Verzeichnis befindet sich eine bolt-project.yaml womit Einstellungen für das Projekt vorgenommen werden können und eine inventory.yaml für zukünftige Hosts / Hostgruppen

Modul-Verzeichnis anlegen:
mkdir -p apache/plans && mkdir -p apache/files

So sollte die Struktur jetzt aussehen:
|── bolt-project.yaml
├── inventory.yaml
└── apache
├── files
└── plans

Jetzt erstellen wir den Container via Dockerfile, wo bolt später die Pakete installiert:
vim Dockerfile
FROM rastasheep/ubuntu-sshd
RUN apt-get update && apt-get -y install libssl-dev
EXPOSE 80
CMD ["/usr/sbin/sshd", "-D"]

kurze Erklärung: Hier wird ein Docker Container mit einem lauschenden SSH-Service unter Ubuntu erstellt, da Bolt auch über SSH kommuniziert

Dann erstellen wir die docker-compose.yaml, in dieser Datei wird festgelegt, wie viele Container erstellt werden und mit welchen Port diese von Außen erreichbar sind.
vim docker-compose.yaml
version: '3'
services:
target1:
build: .
ports:
- '3000:80'
- '2000:22'
container_name: webserver1
target2:
build: .
ports:
- '3001:80'
- '2001:22'
container_name: webserver2

Hier werden zwei Container erstellt auf dem der Port 22 auf 2000 und 2001 gebunden ist sowie der Port 80 auf 3000/3001.

Um die Container jetzt bauen zu lassen brauchen wir folgenden Befehl:
docker-compose up -d --build
Es werden jetzt Container-Images heruntergeladen und die beiden Container gebaut

Damit Bolt weiß wo das ganze dann angewendet werden soll, vervollständigen wir das inventory.yaml
vim inventory.yaml
groups:
- name: containers
targets:
- uri: 127.0.0.1:2000
name: webserver1
- uri: 127.0.0.1:2001
name: webserver2
config:
transport: ssh
ssh:
user: root
password: root
host-key-check: false

Um jetzt zu testen ob das Inventory File passt, prüft man mit folgendem Kommando:
bolt command run whoami -t all

Damit jetzt auf den Container Pakete installiert werden, müssen wir einen Task anlegen:
vim module/apache/plans/install.yaml
parameters:
targets:
type: TargetSpec

steps:
- name: install_apache
task: package
targets: $targets
parameters:
action: install
name: apache2
description: "Install Apache using the packages task"

Ich denke viel Erklärung braucht es hier nicht sollte selbsterklärend sein

Mit folgendem Kommando kann man den Plan ausführen um Apache auf dem Containern zu installieren:
bolt plan run apache::install -t containers

Das Ergebnis kann man sehen, wenn man im Browser http://127.0.0.1:3000 eingibt

Als keine Einführung in Puppet Bolt sollte das vorerst genügen, weiteres kann noch modifiziert und erweitert werden, siehe Quelle.

Quelle des Artikels: https://puppet.com/docs/bolt/latest/getting_started_with_bolt.html

Johannes Carraro
Johannes Carraro
Senior Systems Engineer

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Team Operations als Senior Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren.

NETWAYS wird Puppet Authorized Reseller

Seit vielen Jahren unterstützt NETWAYS bereits erfolgreich Kunden bei der Konzeptionierung, dem Aufbau, der Erweiterung sowie der Migration von Puppet Umgebungen. Dabei lag der Schwerpunkt bislang auf der Open Source Variante, obwohl es im Puppet ENTERPRISE Segment viele interessante und hilfreiche Erweiterungen gibt, die wir im Rahmen der Dienstleistung nicht direkt anbieten konnten.

Diesen Zustand wollten wir ändern! Wir freuen wir uns, dass wir seit Kurzem offizieller Authorized Reseller von Puppet sind. Für unsere Kunden ändert sich an unseren bestehenden Leistungen dadurch nichts. Wir bieten weiterhin die professionellen Dienstleistungen im Open Source Bereich an, die sie von uns gewohnt sind. Der Vorteil dieser Partnerschaft ist eine Erweiterung unseres Portfolios. Anforderungen unserer Kunden können wir jetzt noch besser umsetzen, da wir nun in der Lage sind, ENTERPRISE Lizenzen selbst anzubieten und sämtliche Leistungen damit direkt von uns beziehbar sind.

Puppet als starker Partner

Für unsere Kunden ergibt sich aus dieser Partnerschaft zudem ein zusätzlicher deutlicher Vorteil: Neben den Open Source Themen können wir nun nicht nur die ENTERPRISE Lösungen anbieten, sondern auch mit Puppet und unseren Kunden gemeinsam in den Dialog treten können, um das Configuration Management passgenau beim Kunden zu installieren und zu konfigurieren.

Durch das breite Partner Netzwerk von Puppet können wir auf bisherige Erfahrungen von Puppet in ähnlichen Umgebungen zurückgreifen und mögliche Herausforderungen sowie Anforderungen frühzeitig identifizieren.

Nächster Halt: Solution Provider

Als nächster Schritt steht bei uns jetzt noch aus, dass wir Puppet Solution Provider werden. Damit ergibt sich für unsere Kunden noch eine Vielzahl an weiteren Vorteilen, da unsere Kollegen in diesem Fall offiziell von Puppet zertifiziert werden und somit auch ein Nachweis darüber vorhanden ist. Hierdurch können wir dann auch unser langjähriges Engagement und Know-How, das wir mit Puppet gesammelt haben, schriftlich unter Beweis stellen.

Habt Ihr Interesse an unseren Puppet Dienstleistungen oder Puppet ENTERPRISE? Dann nutzt doch einfach unser Kontaktformular und nehmt Kontakt mit uns auf! Wir freuen uns auf eure Anfragen!

Christian Stein
Christian Stein
Manager Sales

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".