DevOps und Cloud Engineer mit Entwicklerbackground

#Ansible, #AWS, #Azure, #Docker, #GCP, #GitLab, #JavaScript, #Jest, #Kubernetes, #NodeJS,
#TypeScript

Zwischen den Aufträgen bilde ich mich aktiv fort und schreibe Software für meine eigene Verwaltung von Rechnungen und Projektangeboten, vorzugsweise mit AWS.

Auf AWS nutze ich bspw. Lambda für Serverless Apps als Grundlade für die Rechnungsverwaltung.

Diese Apps, welche auf einer Node.js Runtime mit mit JavaScript und TypeScript laufen, dienen zur Automatisierung von wiederkehrende Arbeitsschritten, wie eingehende Rechnungen an den Steuerberater zu versenden und PDF-Rechnungen nach einem vorgegeben Schema zu benennen.

Zum Einsatz kommen u. A. die AWS-Dienste SNS (Notificatons) und SQS (Queues), SES (Mail-Empfang und Versand), S3 (Object Storage), API Gateway (REST APIs) und PostgreSQL in einer Serverless-Konfiguration (Datenbank).

Das Deployment dieser Apps basiert auf CloudFormation Templates mit SAM (Serverless Application Model), CDK und Ansible. Tests werden über Jest ausgeführt. Das Logging und Monitoring erfolgt mit CloudWatch, bei dem die Apps strukturierte Logs erzeugen.

Außerdem nutze ich in anderen Projekten u. A. Docker, Kubernetes (auch mit AWS EKS, ECS und Fargate), GitLab CI/CD und TerraForm. Grundkenntnisse in Azure und GCP sind ebenfalls durch kleinere Projekte vorhanden.

#Ansible, #CoreMedia, #DependencyTrack, #Docker, #kaniko, #Kubernetes, #Maven, #MSDefender, #Podman, #Tekton

Bei der IHK GfI habe ich als DevOps Experte Aufgaben bei der Migration von CoreMedia 9 auf 10 mit Aufbau einer Tekton Build Pipeline und Kubernetes übernommen.

Während der ersten Phase war die Anforderung kurzfristig ein Uptime Monitoring zu etablieren, um Fehler im Docker Swarm Setup zeitnah zu erkennen. Dies habe ich durch eine statping-ng Installation bereitgestellt, welche in der ersten Version als ad-hoc Deployment ausgerollt wurde. Im Nachgang habe ich Ansible Playbooks geschrieben, welche diese Installation reproduzierbar machen.

Das bestehende Maven OWASP Plugin zum Finden von Vulnerabilities habe ich durch eine Dependency Track Installation ersetzt, welche aktiv täglich neue sicherheitskritische Findings über MS Teams berichtet. Damit entfällt die Notwendigkeit des manuellen Ausführens eines Vulnerability Scanners zum Prüfen auf neue Schwachstellen.

Weitere Ansible Playbooks wurden von mir geschrieben, welche MS Defender ausrollen, die iptables Firewall für Docker konfigurieren, und Ansible Semaphore installieren. Diese wurden modifiziert, um auf Podman, d. h. ohne Root Rechte, lauffähig zu sein.

In der zweiten Phase habe ich nach Vorgabe der IHK GfI eine Build Pipeline in Tekton und Kubernetes aufgebaut, welche das CoreMedia 10 Projekt per Maven und Docker Images per kaniko baut. Die Build Pipeline wird über Argo CD ausgerollt und baut das CoreMedia Projekt mit zahlreichen von mir eingebauten Modifikationen, welche die Dauer des Builds signifikant verkürzen.

Für alle Aufgaben habe ich eine Dokumentation in Markdown angefertigt und zum Projektende die Übergabe vor Ort durchgeführt.

#Ansible, #Artifactory, #Automation, #Bamboo, #Bash, #Bitbucket, #Confluence, #DevOps, #Git, #GitHubEnterprise, #Gradle, #Jira, #PolarionALM, #PowerShell, #RHEL, #Subversion

Im Operations Team habe ich als DevOps Engineer Builds mit Gradle für Polarion ALM eingerichtet, welche über Bamboo und Ansible ausgerollt wurden.

Polarion wurde als internes Tool in zahlreichen Projekten weltweit mit mehreren tausend Benutzern eingesetzt und nutzt SVN (Subversion) als Backend. Als Teil des Operations Teams habe ich die bereits vorhandenen Ansible Playbooks erweitert, um den Grad der Automatisierung zu erhöhen. Weiterhin war das Ziel, die Playbooks auf die Anforderungen für aktuelle Versionen von RHEL (Red Hat Enterprise Linux) und Polarion zu aktualisieren.

Für eines der Polarion Projekte, welches bisher manuell in Eclipse gebaut wurde, sollte es ermöglicht werden, diesen Build lokal sowie auf dem Bamboo Server zu bauen. Dafür habe ich einen Gradle Build auf der zu dem Zeitpunkt aktuellen Version 7.4 eingerichtet.

Da Polarions Dependency Management auf OSGi mit lokalen Dateien basiert, wurden mittels eines selbstgeschriebenen PowerShell Skripts die Dependencies der Polarion Distribution analysiert und auf Maven Artefakte abgebildet. Diese können somit von Gradle aus einem internen Artifactory Repository geladen werden.

Durch das programmatische Auslesen der Dependencies war es mir möglich, nur die Dependencies zu laden, welche tatsächlich im Java Code genutzt werden. Als Ergebnis kann Polarion lokal und auf Bamboo gebaut werden, ohne dass dabei die gesamte Polarion Distribution mit allen Dateien vorgehalten werden muss; dies resultiert in schlanken und schnellen Builds.

Für dieses Projekt war es ebenfalls notwendig, Code von GitHub Enterprise auf Bitbucket zu migrieren. Dafür habe ich ebenfalls programmatisch mittels eines Bash Skripts ein Multi-Module Repository zu einem einzelnen Git Repository zusammengeführt, ohne dass dabei die Historie verloren geht.

Im Laufe des Auftrags habe ich weiterhin zahlreiche Server von RHEL 7 auf 8 aktualisiert.
Die Arbeit wurde auf Englisch in Confluence oder mittels Markdown dokumentiert.