Seite wählen

NETWAYS Blog

Sommer, Sonne, Software – Rückblick CIVO NAVIGATE 2023

Anfang Februar durfte ich nach Tampa, Florida reisen, um auf der IT-Konferenz Civo Navigate zu sprechen, die in diesem Rahmen zum ersten Mal stattfand. Mit Beiträgen rund um Kubernetes, Edge Computing, Machine Learning, DevOps, GitOps, Observability, Security und Cloud Native Transformation war das Angebot an Themen breit gefächert. Sicherlich vor allem aus diesem Grund (und nicht nur wegen Temperaturen bis zu 30 Grad und toller Location) fanden sich zusätzlich zu 50 angekündigten Speakern, u. a. von ARM, GitLab, oder SUSE auch ca. 300-350 Teilnehmer vom 7.-8. Februar in Tampa ein.

Eingeleitet wurde die Konferenz durch einen Keynote-Block auf der Main Stage, wo nach einem Grußwort von Civo’s CEO Mark Boost ein ca. einstündiger Schwenk aus Steve Wozniak’s Leben folgte für viele Besucher bereits das erste Highlight. Im Anschluss ging es dann los mit den verschiedenen Beiträgen, vorgetragen auf drei separaten Tracks – zwei für klassische Talks und einer für praxisbezogenere Workshops. Für mich hieß es direkt ‚Showtime!‘, ich hatte den ersten Slot auf dem Workshop-Track erwischt, wo ich eine einstündige Einführung in Acorn gab.

Kubernetes-Deployments einfacher gestalten!

Acorn ist ein Tool in erster Linie für Entwickler, die ihre Anwendungen in ihre Kubernetes-Cluster deployen möchten, ohne direkt allzu tief in Kubernetes als Framework einsteigen zu wollen. Mein Kollege Markus hatte Acorn vor Kurzem bereits in seinem Blogpost über Application Management in Kubernetes erwähnt, und ich hatte nun die Gelegenheit, einem interessierten Publikum von ca. 20 Teilnehmern die Software näher zu bringen. Ziel des Workshops war es, eine Gästebuch-Anwendung von einem Docker-basierten Deployment mithilfe von Acorn auf Kubernetes umzustellen. Die Folien zu meinem Workshop finden sich unter slides.dbokdy.me, und in Kombination mit den Workshop-Unterlagen auf GitHub könnt ihr den Workshop bei Interesse auch daheim durchgehen. 😉

Auf den erfolgreichen Workshop folgte analog zu Markus‘ Blogartikel eine angeregte Diskussion, welche Tools für Application/Deploy Management auf Kubernetes denn nun am geeignetsten seien. Darauf gibt es natürlich keine eindeutige Antwort, geschweige denn eine Patentlösung, aber im Laufe der Gespräche wurden immer wieder Epinio, entwickelt von SUSE, und Namespace von Namespace Labs genannt – zu Epinio gab es am Folgetag sogar einen weiteren Workshop. Persönlich habe ich mir bisher keine der beiden Lösungen angeschaut, werde das aber nun schleunigst nachholen, und wer weiß, evtl. folgt ja demnächst ein weiterer Blogpost. Die Nachfrage nach Möglichkeiten, Kubernetes und seine Bedienung für den alltäglichen Gebrauch zu abstrahieren, ist auf Entwicklerseite allem Anschein nach auf jeden Fall vorhanden.

GitOps, Security und KI

Im Anschluss hatte ich jedenfalls gut lachen – zwei Stunden nach Konferenzbeginn war ich bereits „nur noch Teilnehmer“ und konnte nach Lust und Laune verschiedene andere Talks besuchen, mich mit interessierten Teilnehmern unterhalten und die sommerlichen Temperaturen von bis zu 30 Grad genießen. Für mich war interessant zu sehen, in welche Schwerpunkte sich der Großteil der Beiträge würde einordnen lassen, und für mich stachen dabei zwei Dinge heraus – GitOps und Absicherung von Kubernetes-Clustern. Zu diesen Themen gab es einige interessante Talks, angefangen bei Best Practice Sammlungen zu GitOps und Tools, die eine Kombination von GitOps und ClickOps ermöglichen, bis hin zum Einsatz von Service Meshes in Kubernetes zur Absicherung von Netzwerkverkehr in Kubernetes-Clustern.

Auch ein sehr interessanter Beitrag über das Hacken von Kubernetes-Clustern war im Programm enthalten, sodass man sich dem Thema „Sicherheit“ auch einmal aus Sicht des Angreifers widmen konnte. Doch auch andere Themen fanden Beachtung – so gab es nicht nur einige Beiträge zu den Themen ML/AI auf Kubernetes und Edge Computing, der Veranstalter Civo stellte im Rahmen seiner Konferenz auch neue Produkte in diesen Bereichen vor, was beispielhaft für die momentanen Trends rund um „Cloud Native“ und Kubernetes gesehen werden kann.

See you later, alligator!

Größter Pluspunkt der Konferenz als Ganzes waren für mich definitiv die Workshops, die durchgängig im Ablauf zu finden waren – so konnte man seinen persönlichen Talk-Marathon über 48 Stunden zwischendurch immer mal wieder mit praktischeren Fingerübungen und Case Studies auflockern und nebenbei noch sein bestehendes Wissen zu bestimmten Tools aufbessern oder komplett neu erwerben. Das nächste Mal stattfinden wird Civo Navigate im September 2023 in London, und wer weiß, evtl. werde ich euch auch dann wieder von meinem Beitrag und der Konferenz allgemein berichten dürfen.

Daniel Bodky
Daniel Bodky
Platform Advocate

Daniel kam nach Abschluss seines Studiums im Oktober 2021 zu NETWAYS und beriet zwei Jahre lang Kunden zu den Themen Icinga2 und Kubernetes, bevor es ihn weiter zu Managed Services zog. Seitdem redet und schreibt er viel über cloud-native Technologien und ihre spannenden Anwendungsfälle und gibt sein Bestes, um Neues und Interessantes rund um Kubernetes zu vermitteln. Nebenher schreibt er in seiner Freizeit kleinere Tools für verschiedenste Einsatzgebiete, nimmt öfters mal ein Buch in die Hand oder widmet sich seinem viel zu großen Berg Lego. In der wärmeren Jahreszeit findet man ihn außerdem oft auf dem Fahrrad oder beim Wandern.

Wer GitLab sucht, wird bei NETWAYS fündig!

Als Softwareentwickler kommt man um eine Anwendung für eine Versionsverwaltung nicht herum.

Mit GitLab haben wir für Euch ein extrem beliebtes und umfangreiches VCS (Version Control System) im Programm. Hiermit könnt Ihr agil und effizient an Euren Software- und Webprojekten arbeiten.

GitLab ist OpenSource, basiert auf Git und wurde im Jahr 2011 in der Programmiersprache Ruby on Rails geschrieben.

GitLab ermöglicht Dir eine teamübergreifende und ortsunabhängige agile Software-Entwicklung. Du kannst Deinen Code geschützt speichern, kooperativ daran arbeiten und Git Repositories und CI/CD Pipelines erstellen. Der Clou ist, dass Ihr in einer einzigen Anwendung zusammenzuarbeiten könnt, anstatt mehrere Arbeitsschritte über verschiedene Tools hinweg verwalten zu müssen.

In der kostenlosen Community Edition (CE) stehen Dir viele Features für die Bereiche Source Code Management, Projekt Management und Sicherheit/Complience ( wie z.B. Wiki, Secret Detection, Time Tracking,…) zur Verfügung. Hierfür benötigst Du auch keine Lizenzen.

Lizenzen

Mit dem Wechsel auf die kostenpflichtige Enterprise Edition (EE) lässt sich das Feature-Set noch einmal gehörig ausbauen. Hier habt Ihr die Wahl zwischen dem Premium- und dem Ultimate-Set. Mit Hilfe der Übersicht findest Du raus, welche Funktionen wo dabei sind.

Als offizieller GitLab Partner kümmern wir uns gerne um die Beschaffung Deiner GitLab Enterprise Lizenzen. Melde Dich einfach hier und fordere ein Lizenz-Angebot bei uns an.

GitLab – lokal oder gehostet?

Egal ob CE oder EE, nun steht noch die Entscheidung an, wo Dein GitLab liegen soll: Du kannst Deine GitLab Instanz lokal auf Deinen eigenen Servern betreiben oder Du buchst Dir einen managed GitLab Service bei dem Hosting Provider Deines Vertrauens.

Für welche Variante Du Dich auch entscheidest, innerhalb unserer NETWAYS Gruppe findest Du für jegliche Vision die richtige Option.

GitLab mit NPS

Unsere Kollegen der NETWAYS Professional Services kümmern sich um die Installation und Konfiguration von GitLab auf Deinen lokalen Systemen und helfen Dir gerne u.a. beim Aufbau einer schlagkräftigen CI/CD Pipeline. Im Rahmen unserer IT Outsourcing Services übernehmen wir auch gerne die anschließende Wartung und kümmern uns um das Einspielen aller Updates.

GitLab mit NWS

Du willst auf das umfangreiche Toolset von GitLab nicht verzichten, hast aber keine freien Rechen-Kapazitäten mehr zur Verfügung und scheust den Hardware-Invest?  Dein GitLab soll lieber auf modernster Hardware in professionellen, zertifizierten Rechenzentren liegen und Du willst mit der Systempflege nichts zu tun haben? Dann bist Du bei unseren NETWAYS Web Services genau richtig.

Wähle einfach auf unserer SaaS Plattform den für Dich passenden GitLab Plan aus und klicke auf Start. Innerhalb von 3-4 Minuten ist die App einsatzbereit und Du kannst loslegen.  Wir kümmern uns im Hintergrund darum, dass das Deine App verfügbar und up to date bleibt. Und wenn Du mal Hilfe benötigst, steht Dir unser SaaS-Team per Mail, Chat oder telefonisch gerne mit Rat und Tat zur Seite.

Für alle Kunden, die besondere Wünsche und spezielle Anforderungen an ihre GitLab-Instanz haben, gibt es in unserem Hosting-Bereich noch eine zweite Möglichkeit:

Unser MyEngineer-Team baut Euch in unserer NETWAYS Cloud (basierend auf OpenStack) eine individuelle GitLab Instanz auf und Ihr bestimmt wie diese aussehen soll.

Hier bekommt Ihr individuelle Gestaltungsmöglichkeiten (GitLab Pages, Plant UML, Service Desk,…).

Ihr bestimmt wann neue Updates eingespielt werden sollen – unser MyEngineer-Team richtet sich ganz nach Eurem Zeitplan.

Die Ressourcen (CPU, RAM, Storage) können jederzeit individuell angepasst werden. Ihr könnt also klein anfangen und bei Bedarf das Setup ausweiten.

So bezahlt Ihr nur das, was Ihr wirklich braucht und bekommt genau das GitLab, das Ihr Euch wünscht.

Trainings mit NES

Du bist von den Möglichkeiten von GitLab überzeugt, Dein Team hat aber noch keinerlei Erfahrungen mit GitLab gemacht?

Kein Problem – auch dafür haben wir eine Lösung.

Über unsere NETWAYS Event Services könnt Ihr einfach unser zweitägiges GitLab- DevOps-Lifecycle – Training buchen.

Dieses gibt es wahlweise als Online-Training oder als Vor-Ort-Veranstaltung mit exquisiter Vollverpflegung in unserem Trainingszentrum.

Es ist auch möglich Inhouse Schulungen in Deiner Firma mit unserem Trainingsteam zu vereinbaren. Hierfür kannst Du Dich einfach bei direkt bei den Kollegen melden.

In der Schulung erhaltet Ihr einen tiefen Einblick in die Basics von Git, dessen Konfiguration sowie Shell- und GUI-Clients. Zudem bekommt Ihr GitLab-Grundwissen rund um Repositories, Issues, Releases und übt die Konfliktlösung in unterschiedlichen Git-Historien und Branches. Später bekommt Ihr praxisnahe Git-Workflows für kleine und große Teams und damit verbundenen Merge-/Rebase-Strategien. Ebenso stehen u.a. Continuous Integration/Continuous Delivery (CI/CD) auf dem Programm.

Am Ende des Trainings ist Dein Team dann fit für den Umstieg auf GitLab.

Ihr seht also: wer GitLab sucht, wird bei NETWAYS fündig.

Kommt einfach auf uns zu und wir finden gemeinsam heraus, welcher Weg für Euch der beste ist.

Stefan Schneider
Stefan Schneider
Account Manager

Vor seiner Zeit bei NETWAYS hat Stefan als Projektmanager in einer Nürnberger Agentur dabei geholfen, Werbeprojekte auf die Straße zu bringen. Seit Juni 2017 ist er nun stolzes Mitglied der NETWAYS-Crew. Hier war er zuerst der Ansprechpartner für unserer Schulungen und kümmert sich aktuell um alle Anfragen rund um unser Hostingangebot. Die Freizeit vertreibt sich Stefan am liebsten mit Sport. Vom Joggen über Slacklining bis zum PennyBoard fahren ist er für alles zu haben.

Announcing Kubernetes v1.24 and v1.25

We’d finally like to announce the release of Kubernetes v1.24 and v1.25 on our Kubernetes Platform. Since 1.24 brought many under the hood changes, our deployment process had to be refactored as well. While Version 1.24 and 1.25 were available on our platform for some time now, we can now safely say that both versions are completely stable and safe to use. For the various changes coming with the new version we recommend creating a test cluster to test your applications. But what are these big changes? Let’s go through some of the highlights.

Deprecation of the docker shim

Easily the biggest change is the deprecation of the docker shim that broke our current deployment method where every component and workload runs in Docker containers. But with this release the docker integration is no more. Kubernetes now officially only supports Container Runtimes implementing the CRI specification. Container Runtimes that implement said spec would be Containerd, CRI-O, Kata and gVisor for example.

Since Containerd is the most common runtime, we settled for it. Even though docker internally uses Containerd, the migration was pretty tricky, as it involved installing and configuring Containerd, as well as making sure that Kubernetes uses it. Finally when kubelet restarts, all containers will be recreated.

Containerd

We initially thought Containerd would behave exactly like docker since Containerd runs the docker containers after all. But for one reason or another that is not the case. Through the CRI interface the containers get created based on a CRI-spec. Unfortunately, the default configuration of Containerd does not set the ulimit properly, which results in some application working and others will be killed by the OOMKiller. It turns out that some application try to check the ulimit by „trial and error“ and since the limit is set too high, the kernel will eventually kill the respective process. Weirdly enough, almost exclusively older applications were effected. For example mysql:8 would work fine, but mysql:5.7 will crash almost instantly. The same problem can be observed with the nfs-server-provisioner and rabbitmq for example.

API Deprecations

Like with any other Kubernetes release, there were a lot of API deprecations that needed us to move the Flannel CNI and other deployments to a new release gracefully. The official Kubernetes Blog has a great write-up on this topic.

Configuration

Another problem we faced is the change in configuration. The core Kubernetes component kubelet now only supports being configured with a special configuration file, which in turn meant that we had to rebuild the configuration from scratch, as all of our configuration involved command line flags that now no longer work. CoreDNS as well had some new configuration options helping to conquer overloading the pod with many concurrent DNS queries. We even support adding new static host entries in CoreDNS. The ConfigMap coredns-extra-hosts sets the entries. This entry hosts.list is empty by default, but can the modified like any other hosts file ( 1.2.3.4 example.com ). After restarting the coredns deployment the host can be queried.

Deprecation of PodSecurityPolicy

PodSecurityPolicies have been deprecated since 1.21. But since 1.24 is the last release with it still active, it’s the last chance to get started with PodSecurityAdmission. However, they don’t provide the same feature set, as it enforces the policy based on 3 Pod Security Standards namespace wide. This means, in order to get the same and even more features solutions like OPA Gatekeeper or Kyverno have to be implemented.

ServiceAccount Tokens

Another noteworthy change is the changed behaviour in token creation. Until now, every ServiceAccount automatically gets a new secret including a token to access the Kubernetes api. This is no longer the case. If you need to create a token, make sure to use the kubectl create token command instead.

Happy upgrading!

Justin Lamp
Justin Lamp
Systems Engineer

Justin hat 2022 die Ausbildung zum Fachinformatiker für Systemintegration im "echten" Norden abgeschlossen. Durch seine große Verbundundenheit zu Open Source hat er aber schnell gemerkt, dass ihm Themen im Kubernetes und OpenStack Bereich mehr liegen als im propreritären Microsoft/ VMWare Umfeld. So hat er beschlossen den Schritt zu wagen und andere Teile Deutschlands zu erkunden, um NETWAYS im Team Web Services tatkräftig zu unterstützen. Wenn er nicht in den Untiefen des Linux-Universum unterwegs ist, macht er leidenschaftlich Leichtathletik, geht Wandern und Mountainbiking.

Divide and Conquer – Verteilte Git-Konfiguration

In meinem zehnten Monat als Consultant bei NETWAYS angekommen, bin ich inzwischen gut in verschiedenste Kundenprojekte integriert. Das sorgt einerseits für einen abwechslungsreichen Alltag mit immer neuen Herausforderungen, andererseits stellte sich irgendwann ein grundlegendes Problem heraus: Ich kann nicht jonglieren!

Dabei wäre das bei der Vielzahl an geschäftlichen Email-Adressen, SSH- und GPG-Schlüsseln und anderen Kleinigkeiten, die sich von Kunde zu Kunde, Plattform zu Plattform und Projekt zu Projekt unterscheiden, dringend notwendig. Ein unsignierter Commit mit falscher Email auf Github, Gitlab oder sonstiger Plattform ist da bei meinem Talent für Schusseligkeit nur eine Frage der Zeit. Glücklicherweise gibt es ein Git-Feature, das hier unterstützen kann: Die hierarchische Einbindung mehrerer .gitconfig Dateien.

Theorie und Möglichkeiten

Standardmäßig liest git die hinterlegte Konfiguration laut offizieller Dokumentation aus vier Verzeichnissen/Dateien aus:

  • $(prefix)/etc/gitconfig – der systemweiten Git-Konfiguration
  • $XDG_CONFIG_HOME – einer userspezifischen Git-Konfiguration, oftmals unter $HOME/.config/git
  • ~/.gitconfig – einer weiteren userspezifischen Git-Konfiguration, auch „globale Git-Konfiguration“ genannt
  • $GIT_DIR/config – einer Git-Konfiguration auf Repositoryebene

Die Dateien werden hierbei von jeder Routine, die auf git-Konfiguration zurückgreift, in obiger Reihenfolge ausgelesen, bei mehrfach definierten Werten greift hierbei der letzte, sodass ein „Feintuning“ von globaler Konfiguration hin zu projektspezifischen Einstellungen im Repository schon einmal möglich ist. Für noch bessere Verteilung und optionale Einbindung von erweiternder Konfiguration gibt Git Dir eine praktische Direktive an die Hand: includeIf.

Sie erlaubt es Dir, optional Konfiguration von beliebigen Stellen in die gerade betrachtete Datei einzubinden – die dort hinterlegten Einstellungen werden also zeitgleich evaluiert. Für eine bessere Kontrolle darüber, wann zusätzliche Einstellungen importiert werden sollen, können wir uns erneut die Dokumentation von git, genauer gesagt den Abschnitt zu Conditional Includes anschauen, denn hier gibt es verschiedene Optionen:

  • gitdir – die Einbindung erfolgt, wenn die Auswertung (via Befehl, Script, etc.) der Git-Konfiguration aus einem der Angabe entsprechenden (Unter-)Verzeichnis erfolgt. gitdir unterstützt Wildcards und Case(in)sensitivity.
  • onbranch – die Einbindung erfolgt aus einem momentan ausgecheckten Branch erfolgt, der der Angabe entspricht. Wildcards und Case(in)sensitivity werden auch hier unterstützt
  • hasconfig:remote.*.url – die Schreibweise ist etwas gewöhnungsbedürftig und auch die Anwendungsmöglichkeiten nicht so geradlinig wie bei den anderen Optionen: Hierbei werden optional Einstellungen eingebunden, wenn sich irgendwo in der lokalen Git-Konfiguration (nicht zwingend in der gleichen betrachteten Datei) eine remote URL findet, die der Angabe entspricht. Das ist bspw. nützlich, um mehrere Repositories mit bestimmter, immer gleicher Konfiguration zu versehen  (z.B. alle Repositories, die Icingaweb2-Module bereitstellen)

Praxis

Doch wie kann so etwas in der Praxis aussehen? Wie eingangs erwähnt, war mir vor Allem die Handhabe mehrerer kundenbezogener Email-Adressen und damit verknüpfter GPG-Schlüssel zu lästig, sodass ich hier für die Konfiguration zu einem hierarchischen Ansatz zurückgriff. Meine globale Git-Konfiguration unter ~/.gitconfig gestaltete ich also wie folgt:

Screenshot einer globalen Gitkonfiguration

Globale Gitkonfiguration unter ~/.gitconfig

Neben „Standardeinstellungen“ wie meinem im Commit zu setzenden Namen, der Defaultbranch bei der Erstellung neuer Repositories, die Anweisung, Commits immer mittels GPG zu signieren und das dafür zu nutzende Programm finden sich hier vier includeIf-Abschnitte.

Diese decken die verschiedenen Unterverzeichnisse meines Entwicklungsverzeichnisses ~/repositories/ ab – die trailing Slashes am Ende der jeweiligen Pfaddefinition sorgen dafür, dass die jeweiligen Unterverzeichnisse rekursiv gematcht werden. Im Beispiel hieße das, dass sowohl ein Repository unter ~/repositories/netways/blogpost_dbodky als auch ein Repository unter ~/repositories/netways/icinga-related/director-patches die zusätzlichen Git-Einstellungen unter ~/repositories/netways/.gitconfig einbinden würde.

In den in meiner globalen Git-Konfiguration referenzierten optional einzubindenden Dateien finden sich dann die Kunden- oder projektspezifischen Einstellungen für Git – das können mal mehr, mal weniger sein, um das Beispiel einfach zu halten hier die minimalistische Version für meine privaten Repositories, in der ich nur meine private Emailadresse sowie den damit verknüpften GPG-Schlüssel für die Signierung angebe:

Screenshot einer spezifischen Gitkonfiguration unter ~/repositories/private/.gitconfig

Spezifische Gitkonfiguration unter ~/repositories/private/.gitconfig

Was ihr jetzt in eure Gitkonfigurationen einbauen möchtet und wie ihr sie strukturiert, ist komplett euch überlassen – Git macht hierbei keine Vorschriften sondern arbeitet stur die vier eingangs erwähnten Dateien und alle optional einzubindenden Verzeichnisse und Dateien ab. Wichtig ist lediglich die Reihenfolge der Angaben, da sich diese gegebenenfalls überschreiben können.

Falls Du diesen Blogpost interessant fandest, aber bei Git noch Steigerungsbedarf siehst oder bei der Erwähnung von remote URLs ausgestiegen bist, kann ich Dir an dieser Stelle die NETWAYS Gitlab Schulung ans Herz legen, wo Du in Sachen Versionsverwaltung und DevOps voll durchstarten kannst.

Daniel Bodky
Daniel Bodky
Platform Advocate

Daniel kam nach Abschluss seines Studiums im Oktober 2021 zu NETWAYS und beriet zwei Jahre lang Kunden zu den Themen Icinga2 und Kubernetes, bevor es ihn weiter zu Managed Services zog. Seitdem redet und schreibt er viel über cloud-native Technologien und ihre spannenden Anwendungsfälle und gibt sein Bestes, um Neues und Interessantes rund um Kubernetes zu vermitteln. Nebenher schreibt er in seiner Freizeit kleinere Tools für verschiedenste Einsatzgebiete, nimmt öfters mal ein Buch in die Hand oder widmet sich seinem viel zu großen Berg Lego. In der wärmeren Jahreszeit findet man ihn außerdem oft auf dem Fahrrad oder beim Wandern.

HUGO: GitLab-CI/CD-Pipeline für eine statische Website

Vor etwa 4 Monaten habe ich hier einen Blogpost geschrieben, in dem ich Hugo vorgestellt habe – eine Software zum Generieren statischer Webseiten aus Markdown-Dateien.

Im Lauf meiner Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS habe ich vor kurzem an einer GitLab Fundamentals Schulung teilgenommen, um mehr über Git im allgemeinen und die Besonderheiten von GitLab im speziellen zu lernen. Auf Basis dieser Schulung und dem Projekt hinter oben genannten Blogpost habe ich nun eine CI/CD-Pipeline – CI/CD steht für Continous Integration and Continous Deployment – zum automatisierten Testen, Bauen und Ausrollen einer mit Hugo erzeugten Website gebaut.

Für dieses Projekt habe ich NETWAYS Web Services (NWS) eine GitLab CE App gestartet und außerdem in der Cloud von NWS zwei Webserver – einen als Testumgebung, einen als Produktivumgebung. Mithilfe meines Laptops als Client habe ich an der Website gearbeitet und die anfallenden Daten regelmäßig in ein eigenes GitLab Repository gepusht. Zum Testen, Bauen und Ausrollen auf die beiden Webserver laufen in der GitLab App zwei GitLab Runner. Das sind im Prinzip Agenten die für die GitLab App auf einem anderen System Befehle ausführen können.

Die CI/CD Pipeline

Die CI/CD Pipeline wird über die .gltiab-ci.yml gesteuert. Anfangs werden in der Pipeline die Quelldateien mithilfe zweier Markdown-Linter (vale.sh und markdownlint) getestet – in der .gitlab-ci.yml schaut das so aus:

lint:
   stage: lint
   tags: 
    - hugo
   allow_failure: true
   script:
    - cd tutorial
    - mdl ./content
    - vale ./content

Diese überprüfen die Inhalte der Website auf die Einhaltung eines Styleguides und auch auf die Sprachliche Korrektheit. Anschließend wird die Webseite mit Hugo gerendert, das heißt aus den Markdown-Dateien für den Websiteinhalt entsteht nun die wirkliche Website:

testBuild:
   stage: build
   tags:
    - test
   script:
    - cd tutorial
    - mkdir test
    - hugo -DEF --debug -d test
   artifacts:
   paths:
    - tutorial/test

Falls diese Operation auf der Testumgebung erfolgreich ist, wird sie auch auf der Produktivumgebung durchgeführt. Als Abschluss wird die gerenderte Webseite noch für den genutzten Webserver (z.B. Apache HTTPD oder nginx) bereitgestellt):

testDeploy:
   stage: deploy
   needs: [testBuild]
   tags:
    - hugotest
   script:
    - cp -r tutorial/test/* /var/www/html/
   only: 
    - main

Grafisch sieht diese Pipeline so aus:

Wenn auch Du solche interessanten Projekte in Deiner Ausbildung zum Fachinformatiker machen möchtest, kannst du Dich gerne für eine Ausbildung ab Herbst 2022 bewerben!

Björn Berg
Björn Berg
Junior Consultant

Björn hat nach seinem Abitur 2019 Datenschutz und IT-Sicherheit in Ansbach studiert. Nach einigen Semestern entschied er sich auf eine Ausbildung zum Fachinformatiker für Systemintegration umzusteigen und fing im September 2021 bei NETWAYS Professional Services an. Auch in seiner Freizeit sitzt er viel vor seinem PC und hat Spaß mit diversen Spielen, experimentiert auch mit verschiedenen Linux-Distributionen herum und geht im Sommer gerne mal campen.