Das Wissensportal für IT-Professionals. Entdecke die Tiefe und Breite unseres IT-Contents in exklusiven Themenchannels und Magazinmarken.

SIGS DATACOM GmbH

Lindlaustraße 2c, 53842 Troisdorf

Tel: +49 (0)2241/2341-100

kundenservice@sigs-datacom.de

Cloudbasierte Schulungen?!

Die Novatec GmbH bietet Schulungen zum Thema Cloud-Computing an und lehrt hierbei die Software Docker/ Kubernetes. Da diese Softwareprodukte teilweise aufwendig installiert werden müssen, sind sogenannte Schulungsumgebungen im Einsatz. In ihnen sind alle für eine Schulung notwendigen Softwarepakete vorab konfiguriert. Dies gelingt mithilfe von Infrastructure as Code. Dabei kommen die Softwarekomponenten Ansible, Docker, Terraform und Kubernetes zum Einsatz.
Author Image
Immanuel Haag

Author


  • 23.04.2021
  • Lesezeit: 15 Minuten
  • 81 Views

Es ist in den letzten Jahren viel davon zu lesen, dass innerhalb des deutschen IT-Arbeitsmarkts ein Fachkräftemangel herrsche. Laut der Statistik aus dem Jahr 2018 [Sta] stiegen diese Zahlen im Zeitraum 2012 bis 2015 um ganze 10 Prozent bei den befragten ITK-Unternehmen an. Befragte Unternehmen waren im Jahr 2019 zu 54 Prozent bereit, mehr Budget in Aus- und Weiterbildungsmaßnahmen zu investieren. Um Personal weiterzubilden sind Offline-Seminare (Schulungen) prädestiniert (vgl. [Bit], S. 17). Die Mehrheit der Umfrageteilnehmer (54 Prozent) einer weiteren Studie [Amp] gab zudem an, dass ganztägige Präsenzschulungen zu den IT-Schulungsoptionen gehören, die im Hinblick auf den Zeitaufwand den meisten Mehrwert bieten. Die Novatec Consulting GmbH offeriert eine solche Präsenzschulung zum Thema Cloud-Computing. Sie lehrt den Umgang mit den Softwareprodukten Docker und Kubernetes. Für die Nutzung dieser Produkte finden sich kostenlose Online-Schulungsplattformen auf dem Markt. Diese sind bei den ersten Anwendungsversuchen ausreichend. Jedoch eignen sie sich nicht für mehrtägige Schulungen. Die User Experience ist in einer solchen Sandbox-Umgebung nicht mit realen Gegebenheiten vergleichbar. Darüber hinaus kann kein Einfluss auf die Konfiguration der Software genommen werden. Daraus resultierte die Notwendigkeit, eine selbst entwickelte cloudbasierte Schulungsumgebung zu generieren, die nach eigenen Wünschen anpassbar ist, um Docker und Kubernetes umfangreich zu schulen.

IaC und Tech-Stack

In den letzten Jahren hat sich im Umfeld des Cloud-Computings und der Bereitstellung von Plattformen auf den Angeboten der Cloud-Provider das Paradigma Infrastructure as Code (zukünftig als „IaC“ abgekürzt) etabliert. Konkret handelt es sich hierbei darum, dass nicht nur Applikationen in Form von Quelltext beschrieben werden, sondern dass Infrastruktur, wie gemietete Server/Architektur, ebenfalls als Code dargestellt ist:

“[...] (IAC) is that you write and execute code to define, deploy, update, and destroy your infrastructure. This represents an important shift in mindset in which you treat all aspects of operations as software – even those aspects that represent hardware (e.g., setting up physical servers). In fact, a key insight of DevOps is that you can manage almost everything in code, including servers, databases, networks, log files, application configuration [...]“ [Bri19]

IaC beschreibt somit alle Maßnahmen, die notwendig sind, um Infrastruktur in Form von Quelltext zu behandeln. Beim Einsatz von IaC können die in der Vergangenheit angewendeten Praktiken der Softwareentwicklung deshalb auch auf Infrastrukturkomponenten Anwendung finden:

“The premise is that modern tooling can treat infrastructure as if it were software and data. This allows people to apply software development tools such as version control systems (VCS), automated testing libraries, and deployment orchestration to manage infrastructure. It also opens the door to [...] continuous integration (CI), and continuous delivery (CD)“ [Mor16]

Es gibt eine Vielzahl an Werkzeugen, die nach dem Prinzip von IaC arbeiten. Geht es darum, initial durch die Programmierschnittstelle eines Cloud-Providers IaaS-Komponenten (z. B. eine virtuelle Maschine) aufzusetzen, kann unter anderem Pulumi, Terraform (zukünftig als „TF” abgekürzt), OpenStack Heat oder Ansible verwendet werden.

Chef, Puppet, Salt Stack und Ansible eignen sich im Anschluss dazu, sogenanntes Configuration/Server Management zu betreiben. Diese können die Installation von Softwarepaketen übernehmen, um den gewünschten Status auf der Infrastruktur herzustellen [Bri19, Mor16]. Damit diese Werkzeuge nicht manuell ausgeführt werden müssen, bieten sich konfigurierte CI/CD-Pipelines an, die Zugriff auf den Quelltext dieser Werkzeuge besitzen. Eine weitere IaC-Kategorie ist das Server Templating. Werkzeuge wie Docker, Packer und Vagrant sind hier anzusiedeln. Es werden Abbilder (Images) von Servern als Momentaufnahme der tatsächlich installierten Software und allen im System befindlichen Dateien erstellt. Diese Images können dann auf anderen Servern mit genau diesen Konfigurationen ausgeführt werden. Es ist notwendig, Virtuelle Maschinen (VM) und Container zu verwalten, um die Übersicht zu behalten. Dies gelingt durch Orchestration. Kubernetes ist ein solches Werkzeug, weitere sind zum Beispiel Marathon/Mesos, Amazon Elastic Container Service (Amazon ECS), Docker Swarm und Nomad. [Bri19] Um die benötigten Infrastrukturkomponenten der neuen Schulungsumgebung in der Microsoft (zukünftig als „MS“ abgekürzt) Azure Cloud anzulegen, kommt TF zum Einsatz. Gewünschte Software wird mithilfe von Ansible in VMs der Schulungsumgebung installiert. Docker und Kubernetes nehmen einen besonderen Stellenwert ein, da sie zum einen durch die Schulungsumgebung vermittelt werden sollen und zum anderen einen großen Teil der Architektur darstellen. Selbstverständlich sind die eingesetzten Softwarekomponenten austauschbar. So könnte zum Beispiel von Ansible auf das Werkzeug Chef mit entsprechendem Aufwand gewechselt werden. Der Autor wählte diesen Tech-Stack aufgrund vorhandener Expertise.

Ein erster Prototyp

Zunächst wurde ein Prototyp nach dem Build-and-Fix-Verfahren1 entwickelt. Er nutzt eine CI/CD-Release-Pipeline von MS Azure DevOps mit zugehöriger Remote-State-Verwaltung von TF und ein GIT-Repository. Zudem wird ein Ansible Playbook eingesetzt. Mithilfe des Prototyps kann eine Schulungsumgebung für mehrere Schulungsteilnehmer angelegt werden. Das Erstellen geschieht halbautomatisiert durch die CI/CD-Release-Pipeline (bestehend aus vier Schritten). Ein Trainer muss die notwendigen Parameter, wie den Namen der Schulungsumgebung und die Teilnehmerzahl, in der Weboberfläche als Variablen manuell hinterlegen. Startet er den Vorgang, geschieht das Bereitstellen und Konfigurieren der Komponenten anschließend automatisiert.

1 ) Laut Alexander Schatten: „Grundsätzlich ist es natürlich auch möglich, Software ohne Plan, Rahmen oder Konzept zu erstellen. In diesem sogenannten Build-and-Fix-Verfahren werden Anforderungen quasi ‚auf Zuruf‘ umgesetzt und bestehende Lösungen geändert oder erweitert.“ [Sch10]

Abb. 1: Prototyp P1 – Architektur Gesamtübersicht

Abbildung 1 zeigt die Architektur des Prototyps. Die Abbildung ist in zwei Teilbereiche separiert. So befinden sich im oberen Drittel jegliche Funktionen, die durch MS Azure DevOps (hellblaues Rechteck) umgesetzt sind. Die beiden CI/CD-Release-Pipelines zum Erstellen (Create Lab) und Löschen (Destroy Lab) einer Schulungsumgebung sind im grauen Rechteck abgebildet. Sowohl der Administrator als auch der Trainer, welcher die Möglichkeit hat, eine Schulungsumgebung anzulegen, werden ebenfalls in der Abbildung dargestellt. In der unteren Hälfte der Abbildung sind die Elemente zu erkennen, die außerhalb von MS Azure DevOps angesiedelt sind. In diesem Fall geht es konkret um MS Azure Cloud-Funktionalitäten, welche auch als Computing-Funktionalitäten der MS Azure Cloud bezeichnet werden. Dies beinhaltet alle Komponenten, die sich in der Abbildung innerhalb des violetten Rechtecks befinden. Dazu gehört unter anderem ein Cloudspeicher (Storage Account – Blob), der dem zentralisierten Speichern des TF State dient und oben links zu finden ist. In diesem Cloudspeicher sind die Ansible Inventory-Datei und eine statische Webseite gespeichert. Diese Webseite wird durch den Einsatz der Hugo-Software generiert und ermöglicht es den Trainern, ihre Schulungsunterlagen über das Internet zugänglich anzubieten. Die VMs, welche mit entsprechender Software vorbereitet wurden, sind in der Mitte des lila Rechtecks zu erkennen. Die zugehörige Architektur und die Endbenutzer der VMs (Schulungsteilnehmer) sind ebenfalls dort zu sehen. Es gibt verschiedene Wege, um den Teilnehmern ein Kubernetes-Cluster zur Verfügung zu stellen. Bei der Entwicklung von Prototyp Nummer Eins wurden unterschiedliche lokale Lösungen getestet. Bei diesen Testumgebungen handelt es sich meist um One-Node-Cluster, da es lokal nur über Umwege möglich ist, mehrere Knoten zu simulieren. Eine in Docker-Containern bereitgestellte Kubernetes-Umgebung (wie z. B. kind) ist für die Schulungsumgebung nicht praktikabel, denn die Schulungsteilnehmer erstellen beziehungsweise löschen im Verlauf der Docker-Schulung Container und würden so ein Container-basierten Kubernetes-Cluster in ihrer Umgebung eventuell ungewollt entfernen. Daher wurde mithilfe von Minikube innerhalb einer Schulungsteilnehmer-VM eine verschachtelte VM auf Basis des Virtualbox-Treibers installiert. Dadurch wird eine logische Trennung zwischen den Schulungsteilnehmern und dem Minikube-Kubernetes-Cluster geschaffen.

Da es sich bei der Rechnereinheit der Schulungsteilnehmer bereits um eine VM handelt, musste die für Minikube notwendige VM durch Nested Virtualization konzipiert werden. Damit die Nested Virtualization innerhalb der MS Azure Cloud VMs funktional ist, müssen entsprechende VMs vom Typ Dv3 oder Ev3 eingesetzt werden [Azu]. Durch den Optimierungsvorgang, bei dem Kubernetes als verschachtelte VM durch Minikube im Prototyp eingesetzt wird, ist es den Benutzern nicht mehr möglich, die Cluster-IP-Adressen lokal zu erreichen. Damit eine Zuordnung einer IP-Adresse zum Servicetyp Loadbalancer ebenfalls innerhalb des Prototyps stattfindet, wird im Minikube-Kubernetes-Cluster die Software metalLB bereitgestellt. [Med] So ist gewährleistet, dass sich der Minikube-Kubernetes-Cluster möglichst ähnlich wie ein gemieteter Kubernetes-Cluster eines Cloud-Providers verhält. Damit ausreichend Performanz für die verschachtelte VM des Kubernetes-Clusters bereitsteht, wurden große VMs vom Typ Standard_E8_v3 in MS Azure verwendet. Diese Maschinentypen verursachen allerdings verhältnismäßig hohe Kosten (knapp 0,60 € pro Stunde)2 in der Region Westeuropa.

2) Diese Werte waren zum Erstellungszeitpunkt aktuell. Sie können daher in der Zukunft abweichen

Design und Umsetzung eines neuen Prototyps

Der Autor führte Befragungen innerhalb eines Workshops durch, um den bestehenden Prototyp zu bewerten und um neue technische Anforderungen zur Verbesserung zu finden. Das hieraus resultierende Arbeitspaket wurde ausgehend von Prototyp Nummer Eins (nachfolgend als “P1“ abgekürzt) in einen neuen Prototyp (nachfolgend als “P2“ abgekürzt) und Prototyp Nummer Zwei Strich (nachfolgend als “P2’“ abgekürzt) iterativ überführt.

Umbau der Architektur (P2)
In P2 wird nun anstatt Minikube ein separater Multi-Node Kubernetes-Cluster in Azure Computing durch TF bereitgestellt (MS AKS). Die Ansible-Tasks, welche für das Installieren und anschließende Konfigurieren des Minikube Kubernetes-Clusters in den VMs zuständig waren, wurden entfernt. Abbildung 2 zeigt dies in einer vereinfachten Architektur-Übersicht. Damit der AKS (Azure Kubernetes Service) entsprechend für die Schulungsteilnehmer separiert werden kann, muss RBAC (role-based access control) im Cluster aktiv sein. Pro VM wird ein Kubernetes Namespace angelegt. Damit die VM mit dem Namespace interagieren kann, wird ein Service Account benötigt. Dieser Account kann umgangssprachlich als Benutzer angesehen werden. Zusätzlich werden Berechtigungen in Form einer Role definiert. Durch diese wird beschrieben, welche Elemente des Kubernetes API verwendbar sind. Mit einem Role Binding wird die Role dem Service Account im entsprechenden Namespace zugeordnet. Dadurch gelingt eine Aufteilung des Kubernetes-Clusters. Damit jede VM ihren eigenen Namespace im AKS verwenden kann, wird ein Helfer-Skript beim Provisionieren der VMs aufgerufen. Dieses Skript bereitet eine kubectl-Konfiguration basierend auf dem AKS Kubernetes-Cluster für die Mandantenfähigkeit der VMs vor. Durch einen Ansible-Task wird die Systemumgebung des VM-Benutzers so angepasst, dass zukünftig beim Einloggen die jeweilige kubectl-VM-Konfiguration zum Einsatz kommt. Somit ist jede VM für ihre eigene kubectl-Konfiguration zuständig.

Abb. 2: Prototyp P2 – Umbau der Architektur

Erweiterung um eine grafische Oberfläche (P2’)
Apache Guacamole ist eine Client-/Server-Anwendung, die auf einem Tomcat-Webserver und einem eigenen Protokoll mit dem Namen Guacamole basiert. Sie bietet die Möglichkeit, eine Verbindung zu einer entfernten Oberfläche eines Computers direkt über HTTP-Kommunikation herzustellen. Eingaben und Steuerbefehle können durch den Anwender ohne zusätzliche Software mithilfe von Apache Guacamole in einem Browser-Fenster getätigt werden. Für die Übertragung der Oberflächen (Remote Desktops) werden die Protokolle SSH, RDP und VNC unterstützt. So ist es möglich, eine Kommandozeilenschnittstelle, aber auch eine komplette grafische Desktop-Oberfläche zu verwenden. Apache Guacamole agiert somit als HTML5-basierter Remote Desktop Gateway, der zentralisiert den Zugriff auf eine beliebige Anzahl von Rechnern verwaltet. Pro Rechner kann eine Verbindung zu einem der angebotenen Protokolle hinzugefügt werden. [Gua]
In P2’ wurde auf ein gewartetes und fertig konfiguriertes Image vom Bitnami-Projekt aus dem Marketplace der MS Azure Cloud gesetzt. Dies gelingt durch ein angepasstes TF-Skript mit der entsprechenden Image ID. Zusätzlich wurde das Ansible Playbook erweitert, da in den Schulungsteilnehmer-VMs eine grafische Oberfläche und die Unterstützung des RDP-Protokolls verfügbar sein müssen. Aufgrund von Kompatibilitätsproblemen mit dem eingesetzten Betriebssystem Ubuntu 16.04 LTS in Verbindung mit dem RDP-Protokoll wurde eine Migration auf Ubuntu 18.04 LTS vorgenommen [Ask-a, Ask-b]. Die nach Abschluss dieser Implementierungsschritte resultierende Architektur der Schulungsumgebung zeigt Abbildung 3.

Abb. 3: Prototyp P2‘ – Apache Guacamole in der Architektur

Verbindet sich ein Benutzer durch die bereitgestellte Apache Guacamole VM mit der RDP-Verbindung seiner Schulungsteilnehmer-VM, kann er die installierte grafische LXDE-Oberfläche nutzen. In Abbildung 4 ist zu erkennen, dass der Benutzer ein Terminal, den Chromium-Browser und MS Visual Studio Code geöffnet hat. Nach einer Validierung von P2’ lässt sich sagen, dass noch weitere Erfahrungen mit Apache Guacamole gesammelt werden müssen, da es teilweise zu Performanz-Einbrüchen in Form von längeren Wartezeiten bei Texteingaben/Verwendung des Mauszeigers gekommen ist. Es sollte geprüft werden, ob ein größerer VM-Maschinentyp die Performanz und Usability der Apache Guacamole Software positiv verändert.

Abb. 4: Apache Guacamole, Ansicht des RDP-Desktops einer User VM, Screenshot

Fazit und Ausblick

Das Ziel des Projekts war es, eine eigene cloudbasierte Schulungsumgebung durch die Konzepte von IaC zu konzipieren. Durch die Werkzeuge Docker, Kubernetes, TF und Ansible wurde ein erster evolutionärer Prototyp nach dem Build-and-Fix-Verfahren erstellt. Allerdings stellte sich heraus, dass Prototyp P1 ebenfalls Schwachstellen in Bezug auf die vorhandene Performanz und in der Cloud verursachte Kosten aufwies, woraufhin P2 und P2’ entwickelt wurden. Es kann resümiert werden, dass bereits durch P1 eine Schulungsumgebung auf Basis von IaC in Form einer Eigenentwicklung geschaffen wurde. Die Software Apache Guacamole sollte in ferner Zukunft durch ein eigenes Deployment auf Kubernetes-Basis zum Einsatz kommen. Die Performanz einer RDP-Verbindung in Apache Guacamole ist zwar verbesserungswürdig, bietet allerdings eine erleichterte Bedienbarkeit der Schulungsumgebung, weil lediglich ein Web-Browser für den Zugriff benötigt wird. Da die verfügbare Software in den Schulungsumgebungen durch Ansible installiert wird, lässt sich die geschaffene Lösung als generisch ansehen. Denn es ist möglich, Linux-basierte Software durch zusätzliche Ansible-Tasks zu installieren. Eine Schulungsumgebung könnte somit theoretisch für andere Zwecke eingesetzt werden. Zum Beispiel als Entwicklungsumgebungen für Projekte, auf denen ein bestimmter Softwarestand notwendig ist. Die jüngsten Ereignisse rund um die Covid-19-Pandemie haben gezeigt, dass Distance Learning ein wichtiger Aspekt innerhalb der Lehre, vor allem in Krisenzeiten, ist. Videokonferenz- und Chat-Plattformen, wie Zoom, Slack und MS Teams, sind seither noch häufiger im Einsatz. Eine bei Novatec intern durchgeführte Schulung hat gezeigt, dass die Dockerund Kubernetes-Schulungseinheit mit entsprechendem Mehraufwand vollständig über das Internet durchführbar ist. Es mussten vorab allerdings Vorkehrungen für die eingesetzten Werkzeuge Zoom und Slack getroffen werden. Daher würde es sich in der Zukunft anbieten, die Schulungsumgebung um entsprechende Werkzeuge in einer neuen Version zu erweitern. Beispielsweise könnte ein Mattermost als Alternative zu Slack im Kubernetes-Cluster bei Erstellung der Schulungsumgebung eingesetzt werden. Dann könnten anstelle von Präsenzschulungen zukünftig nur noch Online-Schulungen stattfinden. Die neue cloudbasierte Schulungsumgebung ist somit für Schulungseinheiten vollumfänglich prädestiniert und hat bewiesen, dass es möglich ist, durch IaC eine solche Lösung zu schaffen.

Literatur & Links

[Amp] L. Adato, Celebrating IT Pro Day 2019 by Building Confidence for Tech Pros of Tomorrow, 17.9.2019, siehe: https://www.apmdigest.com/it-pro-day-2019

[Ask-a] Tripod. 16.04 – Xrdp Failed (Problem Connecting) […], 2019, siehe: https://askubuntu.com/questions/1108550/xrdp-failed-problem-connecting-when-package-was-auto-updated

[Ask-b] ilvubuntu13. Remote Desktop - Issues with xRDP and Ubuntu Server, 2019, siehe: https://askubuntu.com/questions/1176503/issues-with-xrdp-and-ubuntu-server

[Azu] J. Fan. Nested Virtualization in Azure, Microsoft Azure Blog and Updates, 13.7.2017, siehe: https://azure.microsoft.com/de-de/blog/nested-virtualization-in-azure/

[Bit] Bitkom/VdTÜV, Weiterbildung für die digitale Arbeitswelt, 2018, siehe: https://www.bitkom.org/Bitkom/Publikationen/Weiterbildung-fuer-die-digitale-Arbeitswelt.html

[Bri19] Y. Brikman. Terraform up and Running. 2019. ISBN: 978-1-4920-4690-5

[Gua] Apache Software Foundation, Guacamole Manual. 2020, siehe: https://guacamole.apache.org/doc/gug/

[Med] Emir Mujic, Istio and MetalLB on Minikube, Medium, 24.10.2018, siehe:
https://medium.com/@emirmujic/istio-and-metallb-on-minikube-242281b1134b

[Mor16] K. Morris, Infrastructure as Code, O’Reilly Media, 2016

[Sch10] A. Schatten u. a., Best Practice Software-Engineering, Spektrum Akademischer Verlag, 2010

[Sta] Bitkom e. V., Anteil der deutschen Unternehmen, die der Meinung sind, dass ein Mangel an IT-Spezialisten herrsche, 2019, siehe: https://de.statista.com/statistik/daten/studie/165936/umfrage/meinung-von-itk-unternehmen-zum-fachkraeftemangel-in-deutschland/

. . .

Author Image

Immanuel Haag

Author
Zu Inhalten
Immanuel Haag ist Consultant bei der Novatec Consulting GmbH. Er unterstützt Kunden und Mitarbeiter bei der Auswahl und dem Einsatz der passenden Cloud-Technologien und insbesondere beim Aufbau notwendiger Fähigkeiten. Der Fokus liegt dabei auf Schulungen, Infrastructure as Code, Containern und Cloud-Plattformen.

Artikel teilen