Die IONOS SE als Teil der United Internet Gruppe verfolgt den Ansatz, die eigenen Services der IONOS
tiefer im Unternehmen zu verankern. Ein Aspekt dieses Ansatzes ist die Nutzung des eigenen Cloud-Anbieters “IONOS Cloud”. YOTRON unterstützt dabei die BI/BigDate-Abteilung bei der Nutzung der IONOS-Cloud für ihre Dienste.

YOTRON unterstützt bei DevOps, Cloud und Kubernetes

Ziel des Einsatzes von Kubernetes und IONOS-Cloud ist die nahtlose Integration in das IONOS Netzwerk als private Cloud ohne direkten Internet Zugang um die IONOS Cloud als “private Cloud” betreiben zu können. Alle BI/BigData-Anwendungen, die in der Cloud laufen, sollen in gewohnter Weise erreicht werden können. Wir unterstützen IONOS dabei, diese Ziele erfolgreich zu erreichen.

Mit dem Projekt Access 4.0 der Deutschen Telekom AG (DTAG) wird ein neuer Weg beschritten um den Zugang der Kunden der DTAG zu deren Gigabit-Produkte wie Telefon, Internet oder MagentaTV zu ermöglichen. Statt wie bisher auf monolithische Systeme zu setzen wird die Zugangsplattform mit normalen Standardkomponenten wie Switches und Server sowie einem breiten Softwareeinsatz ermöglicht das ausschließlich auf OpenSource-Produkte setzt.

Automation und hochmoderner Softwareeinsatz

Ziel des Projektes ist es mehrere hundert Standorte automatisiert mit aller relevanten Software und fachlichen Informationen zu bestücken und auch den Aktualisierungsprozess über moderne CI/CD Prozesse zu steuern ohne manuell eingreifen zu müssen (“Zero-Touch-Provisioning”).

Das Projekt

Aufgabe des DevOps Teams war es Artifact Management auf Basis von jFrog Artifactory (https://jfrog.com/artifactory/) zu betreiben. Das Team war die zentrale Schaltstelle für das Artifact Management innerhalb der Firma.

Das System hatte einen 24/7 SLA und sollte wegen ihrer zentralen Bedeutung mit einem Minimum an Downtime, am besten gar keiner Downtime, laufen. Dafür lief Artifactory in einem Cluster mit drei Knoten, einer PostgreSQL Datenbank im Hintergrund und einem davor geschaltenen Reverseproxy auf Basis von NGINX. Die Artifakte waren physisch in einem S3-Bucket gespeichert.

Modernes DevOps ohne Infrastructure as Code (IaC) ist kaum möglich. In DevOps (Development und Operations) harmonisieren die beiden klassischen IT-Aufgaben Entwicklung der Software und Administration der Infrastruktur. In DevOps kann man beides nicht mehr voneinander trennen. Die alte klassische Vorgehen mit der klaren Trennung zwischen der IT-Administration, die Sie sich um den Kauf und den Betrieb der Infrastruktur kümmerte, und der Entwicklung, die für die Software oder Lösung (Solution) verantwortlich ist, verschmelzen.

Das Deployen neuer Releases war früher mit einem hohen zeitlichen Aufwand verbunden. Der Download, das Bauen, das Testen und das Ausliefern neuer Releases für die klasssichen Umgebungen Entwicklung, Staging (Abnahme) und Produktion hatte je nach System eine umfangreiche Anzahl an Schritten zur Folge.

Schritte bei einem Releasewechsel

Ein Releasewechsel bedeutet im allgemeinen

1. Umbau der Releaseumgebung im lokalen System, d.h. Download der neuen Releases, Anpassung der Konfiguration, Update einer Datenbank, Anpassung ergänzender Module wie WebProxy (Apache, Nginx), Docker usw.

• Umbau der Stagingumgebung, d.h. Wegwerfen der alten Infarstruktur, manueller Neuaufbau der neuen Infrastruktur mit den geänderten Releases, Konfigurationen, Datenbanken, zusätzlichen Modulen
• Funktions-, Performanz- und Integrationstests auf der Stagingumgebung mit späterer Abnahme
• Wenn Abnahme nicht erfolgt, Wiederholen vom ersten Schritt an, mit den notwendigen abnahmeverhinderten Änderungen
• Wenn Abnahme erfolgt, Umbau der Produktivumgebung, d.h. Wegwerfen der alten Infrastruktur, manueller Neuaufbau der neuen Infrastruktur mit den geänderten Releases, Konfigurationen, Datenbanken, zusätzlichen Modulen
• Funktions-, Performanz- und Integrationstests in Produktion vor Freigabe an den Kunden
• Wenn bereits vor der Freigabe in Produktion Probleme auftreten beginnt man wieder von Anfang an

Diese Darstellung der einzelnen Schritte stellt sicherlich ein theoretisches Konstrukt dar, das im Zuge agiler Vorgehensweisen auch veränderbar sind. Faktisch ist es aber so, dass auch agile Methoden diese Schritte implizit mit umfasst, diese sind nur mit in den Entwicklungsprozess integriert.