Meine Open Mainframe Project Praktikumserfahrung

Das Open Mainframe Project Internship-Programm ist ein Remote-Job für Studenten, um zum Open Mainframe Project beizutragen.

Das Open Mainframe Project soll als Anlaufstelle für den Einsatz und die Nutzung von Linux und Open Source in einer Mainframe-Computing-Umgebung dienen. Das Projekt beabsichtigt, die Zusammenarbeit innerhalb der Mainframe-Community zu verstärken und gemeinsam genutzte Toolsets und Ressourcen zu entwickeln. Darüber hinaus versucht das Projekt, die Beteiligung akademischer Einrichtungen einzubeziehen, um die Lehre und Ausbildung der Mainframe-Ingenieure und -Entwickler von morgen zu unterstützen.

Das Ziel meines Projekts war es, Docker-Images für s390x-basierte Linux-Distributionen von Entwicklungsstacks wie MEAN zu erstellen und verschiedene moderne Frameworks und Sprachen anzudocken. Der zweite Teil des Projekts war die Automatisierung des Builds aller Docker-Images, der gesamten clefOS-Bibliothek, eines der offiziellen Dockerhub-Images, mit Jenkins CI.

Ich habe schon Anfang des Jahres versucht, mich für dieses Programm zu bewerben, und ich war überglücklich, als ich schließlich ausgewählt wurde.

Die vergangenen Wochen waren für mich voller Aufregung und Lernen. Das Ziel meines Projekts war es, Docker-Images für die s390x-Architektur in SUSE Linux Enterprise Server 15 zu erstellen und den geplanten Build-Prozess für clefOS-Images zu automatisieren. Die erste Hälfte des Projekts bestand darin, die Bilder zu machen. Wir hatten ursprünglich vor, die Images für openSUSE zu erstellen. Aber openSUSE wurde mit s390x nicht auf dem neuesten Stand gehalten. Das zwang uns, stattdessen auf SLES15 umzusteigen.

Meine erste Herausforderung bestand darin, ein Basis-Image von SLES15 zu erstellen. Das Basisbild wird dann von allen anderen Bildern verwendet. Dies war eine Herausforderung für mich, da ich noch nie zuvor ein Basis-Image erstellt hatte. Um dies zu erreichen, stellte mir Neale, mein Mentor, eine Instanz von SLES15 Linux Guest zur Verfügung. Ich habe auf die VM zugegriffen und ein Bash-Skript geschrieben, das eine Chroot-Umgebung erstellt, Repos hinzufügt, wichtige Pakete installiert und schließlich einen Tarball erstellt. Dieser Tarball wird dann von unserer Docker-Datei verwendet, die das Basis-Image mit erstellt FROM scratch.

Nachdem ich dieses Ziel erreicht hatte, machte ich mich daran, weitere Images für SLES 15 zu erstellen. Dann kam MEAN Stack. Der Tech-Stack von Mongodb, Express, Angular und Nodejs ist sehr beliebt und wir wollten, dass es ein Docker-Image für s390x-Basis SLES15 ist. Aber wir konnten kein offizielles mongodb-Paket für SLES15 finden. Ich habe versucht, mongodb für SLES12 zu verwenden, aber es hat nicht funktioniert, da es kein Paket finden konnte libcrypto obwohl es installiert war. Wir haben schließlich entschieden, dass wir auf eine offizielle Veröffentlichung von Mongodb für SLES15 warten, bevor wir ein Image für Mongodb und Mean Stack erstellen.

Die nächste Phase des Projekts war der Aufbau eines Systems zur Automatisierung des Erstellungsprozesses der Bilder, damit die Bilder auf dem neuesten Stand bleiben. Ich habe es erreicht, indem ich eine Pipeline in Jenkins gebaut habe. Die Pipeline wird so geplant, dass sie einmal im Monat automatisch ausgeführt wird, wenn ein Commit für die Codebasis oder durchgeführt wird. Die Pipeline führt die entsprechenden Befehle aus, um alle Docker-Images zu erstellen. Mit dieser Funktion können wir auswerten, ob eine Änderung das Image beschädigt und die Pipeline fehlschlägt, wodurch dem Repository CI/CD-Unterstützung hinzugefügt wird. Ich baue eine ähnliche Pipeline auch für alle Images des clefOS-Repositorys auf, die die Images von clefOS auf dem neuesten Stand halten.

Der Bau der Pipeline war an sich schon eine Herausforderung. Jenkinsfile kann zum Ausführen von Bash-Befehlen verwendet werden, und wenn der Jenkins-Server Zugriff auf den Docker-Daemon hat, ist das Erstellen von Images recht einfach. Aber das Problem ist, dass Sie diese Bilder nicht pushen können. Dazu müssen Sie sich beim Docker anmelden und Anmeldeinformationen angeben, was ziemlich unsicher ist. Hier kommt das Docker-Build-Plugin zur Rettung. In einer Skript-Jenkins-Datei können Sie damit ein Docker-Image erstellen, indem Sie einfach Folgendes schreiben:

app = docker.build("repo/name”, "./relative/path/to/Dockerfile")

Auf diese Weise können wir die App verwenden und die Bilder mithilfe des Credentials-Plugins von jenkins an dockerhub übertragen. Aber dieses Plugin hatte ein großes Problem. Das Erstellen von über 100 Bildern mit dieser Methode erfordert viel Code in Jenkinsfile. Dies ist die einzige funktionierende Lösung, die ich gefunden habe, die die Docker-Images erstellt und es uns ermöglicht, sie auch von Jenkins selbst zu übertragen.

Ich muss sagen, dass dies ein sehr herausforderndes und lohnendes Projekt war. Jeden Tag lerne ich etwas Neues und ich beherrsche es, wenn ich es ein paar Mal umsetze. Durch die Arbeit an s390x-Architektur-basierten VMs habe ich gelernt, wie ein s390x-System funktioniert. Ich freue mich darauf, dieses Projekt erfolgreich zu bearbeiten und abzuschließen.

docker-jenkins.png

In der zweiten Phase meines Praktikums bei Open Mainframe Project automatisierte ich den Build der ClefOS-Bibliothek von Bildern und auch meine Docker-Bilder von SLES15 für s390x. Um dies zu erreichen, habe ich Jenkins CI und ein wenig Bash-Skripting verwendet.

Der Aufbau der Pipeline war die große Herausforderung meines Praktikums. Ich habe Jenkins CI verwendet und es mit einem Webhook mit dem Github-Repository verknüpft, das alle Quellcode-Dockerfiles enthält. Dieser Webhook sendet eine POST-Anforderung an den angegebenen Jenkins-Server, wenn ein neuer Commit übertragen wird. Der Jenkins-Server wird auf einer virtuellen s390x ClefOS-Maschine in der LinuxONE-Community gehostet. Der Jenkins-Server ist immer bereit, diese POST-Anforderung zu empfangen. Nach dem Analysieren der Anfrage löst Jenkins meine Pipelines aus. Eine Pipeline ist für ClefOS und die zweite für meine s390x SLES15-Images. Die ClefOS-Pipeline läuft auf dem Master-Knoten und die SLES15-Pipeline läuft auf einem Slave-Knoten. Die Pipelines werden immer dann ausgelöst, wenn ein neuer Commit (oder mehrere Commits) in den Master-Zweig des Repos gepusht wird/werden. Ein einzelnes Repository enthält den Quellcode von ClefOS- und SLES15-Images

Die Pipelines ziehen das Jenkinsfile aus dem Quellcode selbst. Es gab einfach zu viele ClefOS-Images, sodass es umständlich wurde, Jenkins anzuweisen, jedes Image in Jenkinsfile zu erstellen. Stattdessen wurde jedem Bild ein Makefile zugewiesen. Dieses Makefile enthielt Befehle, um alle Bilder aus dem Quellcodeordner zu erstellen, sie zu pushen und das System zu bereinigen. Das anfängliche Problem war also, wenn wir das Bild pushen wollten, mussten wir es mit docker.build() erstellen und es einer Variablen zuweisen, für die wir die Methode push() aufrufen können. Das Docker-Plug-in unterstützt auch eine Image-Methode, mit der wir zuvor erstellte Docker-Images nachverfolgen können. Also habe ich diese beiden Faktoren zu meinem Vorteil genutzt und ein Bash-Skript geschrieben, das alle Ordner durchläuft und ausführt make all in allen. Dieses Skript erstellt alle im ClefOS-Ordner vorhandenen Bilder. Danach verwenden wir einfach docker.image(), um die Bilder einer Variablen zuzuweisen, auf die wir die gesamte Push-Methode anwenden können. Um die Bilder zu entfernen, verwende ich ein ähnliches Bash-Skript, das ausgeführt wird make clean Befehl von Makefiles.

Diese Lösung hat einige Vorteile und auch einige Mängel. Der Hauptvorteil besteht darin, dass alle Bilder mit einem einzigen Befehl in Jenkinsfile erstellt werden. Entfernt jedoch die Flexibilität, individuelle Bilder zu erstellen. Um dieses Problem zu lösen, habe ich auch den Teil codiert, um einzelne Bilder mit docker.build() zu erstellen. Dieser Code ist in Jenkinsfile als Kommentare vorhanden. Wenn jemand den Build eines einzelnen Images im CI überprüfen möchte, kann er die Ausführung des Bash-Skripts „Build all Images“ auskommentieren und den Code zum Erstellen eines Images auskommentieren.

Es gab auch einige Bilder, die fest codierte Versionen in ihrem Quellcode verwendeten. Ich habe das geändert, um die neueste verfügbare Version zu verwenden, indem ich eine .yml-Datei mit einem Bash-Skript kratzte.

Die Pipelines sollen am 22. eines jeden Monats laufen. Dadurch wird sichergestellt, dass die Bilder auf der neuesten Version sind und Entwickler sie sofort verwenden können und sich nicht mit veralteten Bildern herumschlagen müssen.

Similar Posts

Leave a Reply

Your email address will not be published.