Im zweiten Teil seiner Container-Trilogie geht Volker Weiler darauf ein, wie bei der Umstellung von virtuellen Maschinen auf Containervirtualisierung die Entwicklung und Bereitstellung – im Sinne von Continuous Integration und Continuous Deployment/ Delivery (CI/CD) – miteinander verbunden werden können.
Das Vorgehen bei der Umstellung von Micro Focus Application Lifecycle Management (kurz: ALM) auf Containervirtualisierung lässt sich daher auch den Phasen des DevSecOps-Prozesses zuordnen.
CI/CD – Arbeitsmittel für DevSecOps
Die Grundlage für DevSecOps – also der fließende Übergang zwischen Entwicklung (Dev), Security (Sec) und IT-Betrieb (Ops) – ist ein möglichst hoher Automatisierungsgrad. Auf Basis von CI/CD-Pipelines lässt sich ein geschlossener Prozess abbilden, mit dessen Hilfe sich nicht nur die Geschwindigkeit, sondern auch die Softwarequalität steigern lässt.
Abbildung 1: CI/CD Pipeline https://www.snp.com/blog/devops-devsecops
Um bei der Erstellung eines Images für ALM einen möglichst automatisierten Prozessablauf zu gewährleisten, wurde eine CI/CD-Pipeline definiert. Diese Pipeline durchläuft die folgenden Phasen des DevSecOps-Prozesses:
- Plan
- Code
- Build
- Test
- Release
Sowohl die Wartung des Images als auch die Integration neuer Versionen werden durch die Pipeline erleichtert und können schneller vonstattengehen. In den folgenden Punkten werden die einzelnen Phasen des DevSecOps-Prozesses erklärt und mit der Erstellung eines ALM-Images in Verbindung gesetzt.
Abbildung 2: CI/CD Pipeline for ALM QC Image
Plan – Anforderungen an die Software
Die Architektur und der Code der Software wird durch die Voraussetzungen des Produkts, in diesem Falle ALM QC, definiert. Die Anwendung ALM benötigt:
- Application Server mit der Anwendung Micro Focus ALM auf Basis von Java
- Datenbank Server (Oracle bzw. MSSQL)
Die Anforderungen an ALM sind durch die Nutzung im Support klar definiert. Die Instanzen sind nicht darauf ausgelegt, produktive Daten zu benutzen und zu speichern. Dadurch stehen Punkte wie Datensicherheit sowie high availability nicht im Fokus. Viel wichtiger ist das schnelle Deployment einer funktionierenden Instanz in der gewünschten Version, Sprache und Patchlevel.
Als Grundlage dafür benötigt ALM einen Container für den Application Server und einen Container mit der dazugehörigen Datenbank. Sowohl für Oracle als auch für MSSQL-Datenbanken gibt es bereits offizielle Images. Das Image des ALM Application Servers muss neu erstellt werden. Genauso muss nach erfolgreicher Erstellung die Kommunikation mit der Datenbank sichergestellt, Konfigurationen angepasst und Parameter verändert werden. Mit den kompletten Anforderungen an die Software kann mit der Implementierung begonnen werden – Code(n).
Code – Erstellung und Wartung des Quellcodes
Die Ablage und Versionierung des Codes erfolgt über ein Source Code Management System, zum Beispiel GIT. Dort liegen sämtliche für das Deployment notwendigen Dateien. Jeder Branch repräsentiert eine Version von ALM mit Sprache und Patchlevel. Änderungen an der Software werden – nach DevSecOps – nur an dieser Stelle vorgenommen. Durch die Definition der CI/ CD-Pipeline werden alle weiteren Schritte automatisiert und damit möglichst zeitsparend und qualitätsgesichert ausgeführt.
Für die erfolgreiche Durchführung der Pipeline – Bauen des Images, Deploy, Testing und Push-to-registry – sind folgenden Dateien notwendig:
Das Dockerfile beschreibt wie das Image gebaut werden soll und legt fest:
- Auswahl des Basis Images | openjdk:8
- Erstellen von benötigten Ordnern
- Download der ALM.zip Datei
- Kopieren der benötigten Skripte / Config-Dateien
- Ändern von Berechtigungen für gewählte Ordner
- Entrypoint bei dem der Container beginnt, sobald er deployed wird
Das qcConfigFile.properties beinhaltet die für die Installation notwendigen Konfigurationen, wie zum Beispiel Datenbank, Username, Passwort, Installationsverzeichnisse und so weiter. Da beim Start des Containers keine manuellen Eingaben erforderlich sein sollen, wird eine „silent-installation“ ausgeführt.
Skripte die sicherstellen, dass:
- Die Datenbank vor dem Start von ALM verfügbar ist
- ALM erst nach dem Start des Containers installiert wird, damit noch eine Testlizenz eingespielt werden kann
- Nach erfolgreicher Installation der Zugriff vorhanden ist
- Ein Demo-Projekt importiert und aktiviert wird
Das docker-compose.yml steuert das Deployment auf Basis von Docker. Darin wird festgelegt, dass der Service ALM eine Datenbank und einen Application Server besitzt, beide im gleichen Zuge deployed werden und die Kommunikation sichergestellt ist.
Das Jenkinsfile definiert die CI/CD-Pipeline, mit der Build, Test und Release automatisiert durchgeführt werden. Die Jenkinspipeline hat folgende Schritte:
- Build Docker Image
- Deploy test environment
- Run smoke test
- Undeploy test environment
- Push to Image Repository
Build – Bauen der Software
Im Build-Step wird auf Basis des Quellcodes ein Objektcode erzeugt, sprich die Software, die deployed werden soll, gebaut. Im Falle von Docker / Containern bedeutet dies das „Bauen“ eines Images mit docker.build. In Vorbereitung auf Tests wird mit dem gebauten Image eine Testinstanz deployed, auf welcher die Tests durchgeführt werden.
Test – Verfügbarkeit der Anwendung gewährleistet?
Mit Tests während der Entwicklung werden frühzeitig Fehler identifiziert, Kosten gespart und eine hohe Qualität gewährleistet. In diesem Fall prüft der Test, ob eine Anmeldung über die API-Schnittstelle bei der ALM-Instanz möglich ist. Ist eine Anmeldung bei ALM möglich, wird das Test-Deployment heruntergefahren. Wenn es sich bei der zu testenden Anwendung um eine produktiv einzusetzende Software handelt, müssen an dieser Stelle weitere Tests durchgeführt werden, welche die Funktionalität, Verfügbarkeit und Sicherheit gewährleisten.
Release – Pushen in eine Image Registry
Mit der erfolgreichen Testdurchführung kann das Image in ein Image Repository wie z.B. nexus gepusht werden. Bei erfolgreicher Durchführung der Pipeline für jeden Branch sind einsetzbare Images für jede Version, Sprache und Patchlevel vorhanden, auf deren Basis der Support künftig Instanzen deployen kann.
Operate/ Monitoring – nicht für den Support
In der definierten Pipeline wird nicht der komplette DevSecOps-Prozess durchlaufen. Die Phasen Operate und Monitoring sind bei diesem Anwendungsfall nicht Teil der Anforderungen. Da es sich bei der Anwendung um keine produktiv eingesetzte Anwendung handelt, steht sie nicht ständig zur Verfügung. Daher muss weder der Betrieb der Anwendung gewährleistet noch der aktuelle Status der Anwendung gemonitored werden. Mehr Informationen zu diesen Phasen finden sie unter den profi.com-Dienstleistungen.
Die Phase des Deployments ist in unserem Anwendungsfall, wenn der Support eine Instanz benötigt und diese bestellt. Als produktive Plattform für das Deployment dient Red Hat Openshift. Wie der Support die gewünschte Instanz mit ein paar Klicks bestellen kann und welche Herausforderungen bei dem Deployment auf Openshift noch auftreten, werden im nächsten Beitrag dieser Reihe erklärt.
„Von VM auf Container – profi.com containerisiert Legacy-Anwendungen“ – vom 10. August 2020 enthält folgende Punkte:
- Erstellung eines eigenen Images für ALM auf Basis von Docker
- Bereitstellung/ Wartung eines aktuellen Images nach CI/CD mittels Pipeline
„Openshift – DevSecOps-Plattform für Containervirtualisierung“ – am 7. September 2020 wird folgende Punkte enthalten:
- Überführung auf Openshift
- Herausforderungen/ technische Details
