Für den abschließenden Teil hat sich Volker mit Red Hat Openshift beschäftigt und gibt Tipps, was es beim Wechsel von Docker auf Openshift zu beachten gibt.
Mit dem Wechsel von Docker auf Openshift lassen sich Anwendungen nicht nur sicherer deployen. Als eine DER profess
ionellen Plattformen für Containerdeployment und -orchestrierung bietet Openshift auch in den Bereichen Operations und Development viele Vorteile. Dazu gehört unter anderem, dass man Anwendungen per Template mit ein paar Klicks deployen kann.
Openshift – Containerorchestrierung auf Basis von Kubernetes
Red Hat Openshift ist eine Kubernetes-Anwendungsplattform. Kubernetes ist eine Open-Source-Plattform zur Verwaltung von Containern und Services, mit der sowohl Konfiguration als auch Automatisierung erleichtert werden. Kubernetes koordiniert Computer-, Netzwerk- und Speicherinfrastruktur je nach Auslastung durch Container / Services. Openshift erweitert diese Funktionalitäten. Mit Openshift lassen sich Anwendungen nicht nur automatisiert deployen, sondern mit einer internen Container Registry, Überwachung der deployten Anwendungen und Authentifizierungskonzepten werden Prozesse vereinheitlicht und sicherer gestaltet. Das macht Openshift zu einer ausgezeichneten Plattform um Software nach DevSecOps zu entwickeln, zu betreuen und sicher zu gestalten.
Abbildung 1: Openshift Funktionalitäten (https://www.openshift-anwender.de/was-ist-openshift)
Von Docker auf Openshift – was muss beachtet werden?
Bei der Umstellung eines Deployment von Docker auf Openshift / Kubernetes müssen einige Punkte beachtet werden. Neben der anderen Architektur in Openshift ist der wichtigste Punkt die Ausführung der Container als "non-root User". Anders als bei Docker werden Container in Openshift nicht als root/ Administrator ausgeführt. Der ausführende User befindet sich zwar in der Gruppe „0“ (root-Gruppe), hat allerdings eingeschränkte Rechte. So ist sein Zugriff auf gewisse Ordner/ Dateien eingeschränkt, ebenso seine Möglichkeiten, Ordner und Dateien zu bearbeiten. Durch die Ausführung des Containers als non-root User wird die Sicherheit aller Anwendungen sowie des ganzen Clusters erhöht.
Für den Anwender bedeutet dies, dass das verwendete Image darauf vorbereitet werden muss als non-root ausgeführt zu werden. Aktionen, die nur als root-User ausgeführt werden können, müssen daher – wenn möglich – im build-step ausgeführt werden, da dies die einzige Möglichkeit ist, als root zu agieren. Andere Aktionen können nach wie vor im Container ausgeführt werden, allerdings muss der User auf Ordner / Dateien berechtigt werden. Wird beispielsweise bei der Installation oder bei der Ausführung von Skripten auf Ordner zugegriffen oder Dateien erstellt und verändert, müssen diese zuerst dem User zugeordnet werden.
Die Ordner müssen explizit der root-Gruppe zugewiesen werden und die Berechtigungen für vollen Zugriff gesetzt werden.
ALM Quality Center auf einen Klick
Openshift bietet die Möglichkeit, Applikationen aus einem Katalog zu bestellen. Der Openshift-eigene Katalog beinhaltet schon viele Applikationen. Mithilfe eines Templates können Anwender und Entwickler mit wenigen Klicks gewünschte Applikationen, je nach definierten Einstellungen, deployen. Bei der Bestellung aus dem Katalog werden automatisch die benötigten Dateien und yamls in das Projekt importiert.
Um ALM QC zu deployen muss das Template folgendes enthalten:
- ALM QC Deployment
- ALM QC Service
- MS SQL 2017 Deployment
- MS SQL 2017 Service
- Image-Pull-Secret
- Route für ALM Applikation
- Deployment-Parameter
Das ALM QC-Deployment beschreibt den Container, der für den "ALM Applikation Server" erstellt wird. Neben Namen und Labels wird definiert, welches Image verwendet wird und welche Variablen im Container zur Verfügung stehen.
Da das Image in einer internen Registry liegt, muss noch ein Pull-Secret definiert werden, auf Basis dessen das Image gepulled werden kann.
Damit Container kommunizieren können, wird ein Service – ein Networking-Element von Openshift – benötigt. Im Service wird definiert, welcher Container dahinter liegt und mit welchem Port man kommunizieren kann.
Das MS SQL 2017 Deployment beschreibt den Container für die verwendete Datenbank. Die Parameter, die im Container zur Verfügung stehen müssen, werden von Microsoft vorgegeben. Da es sich bei MS SQL um das offizielle Image von Microsoft handelt wird kein Pull-Secret benötigt. Das Repository ist öffentlich.
Damit der Applikation Server mit der Datenbank kommunizieren und Daten schicken kann, benötigt auch die Datenbank einen Service.
An diesem Punkt ist ALM als lauffähige Instanz im Openshift verfügbar. Das Image kann aus den jeweiligen Repositories gepulled werden und das Deployment kann starten. Ab dieser Stelle hat der Benutzer allerdings keine Möglichkeit mehr, das Deployment nach seinen Wünschen zu konfigurieren. Auch der Zugriff von außerhalb des Openshift-Clusters ist nicht möglich.
Für den Zugriff von außerhalb des Clusters, z.B. über eine URL oder per API, wird eine Route benötigt. Durch die Route wird eine spezifische URL nach außen freigegeben. Die Route leitet alle Anfragen an diese URL an den dahinter liegenden Service weiter. Da der Benutzer auf ALM zugreifen will, muss eine Route definiert werden, die auf den Service von ALM verweist.
Die Paramater, die der Benutzende eingeben können soll, müssen im Template hinterlegt werden. Im Template wird definiert, welche Eingabemöglichkeiten der User hat, ob der Parameter zwingend erforderlich ist und welches Format der Parameter hat.
Mit den gesetzten Parametern kann der Benutzer:
- Eigene Zugangsdaten für ALM festlegen
- ALM in der gewünschten Version deployen
ALM QC in 11 Minuten
Mit der Bestellung über das Openshift-Template steht unserem 1st-Level Support, und auch jedem unserer Consultants, ALM in gewünschter Version, Sprache und Patchlevel nach zirka 11 Minuten zu Verfügung.
Durch das schnelle Deployment über Container müssen daher keine virtuellen Maschinen mehr vorgehalten werden und die benötigten Ressourcen sind anderweitig verfügbar. Da über das Template jeder Mitarbeitende ALM bestellen kann, sind die Anwendungsmöglichkeiten nicht nur auf den Support beschränkt, sondern erstrecken sich auch über PreSales, Schulungen oder Testumgebungen.
Mit der Definition der CI-/CD-Pipeline zum Bauen, Testen und Pushen des Images ist sichergestellt, dass bei Änderungen des Codes immer ein aktuelles, voll funktionsfähiges Image zu jeder Version vorhanden ist. Die Automatisierung des kompletten Prozesses macht diesen nicht nur qualitätssicherer, sondern schafft auch freie Kapazitäten bei unseren Consultants, die damit arbeiten.
Mit Openshift erfolgt das Deployment auf einer professionellen Plattform für DevSecOps und Containerdeployment. Dessen Features im Bereich Operating, Monitoring und Security gestalten die Deployments sicher, gut wartbar und schnell verfügbar.
