We build it, we run it!
Beschleunigen Sie zusammen mit procceed Ihre time-to-market mit unserer DevOps-Expertise.
DevOps
Als Container und Kubernetes-Experten nutzen und optimieren wir tagtäglich die Denkweisen, Praktiken und Tools, mit denen Unternehmen schneller und einfacher Anwendungen bereitstellen können. Stichwort: devops
Eines unserer wichtigsten Ziele dabei ist die Entwicklungs- und Deploymentprozesse so effizient wie möglich zu gestalten, so dass neue Features schnellstmöglich in den Produktivbetrieb gebracht werden können. Bei dieser Optimierung haben wir stets die Wartbarkeit und Konfigurierbarkeit des Systems im Blick.
Ein weiteres wichtiges Ziel ist es, die laufende Software sowohl auf mögliche Fehler oder Kennzahlen zu beobachten. Außerdem ist es wichtig Informationen für die Analyse der laufenden Anwendung selbst als auch für die Analyse der Interaktion zwischen verschiedenen Anwendungen zu sammeln und grafisch aufzubereiten.
Die Basis unseres DevOps-Verständnisses beruht auf den Prinzipien der 12-Factor-App in Verbindung mit cloud-native basierten Ansätzen wie z.B. GitOps, Tekton-basierten Pipelines etc.
CI/CD
Ob Jenkins, multi-stage builds oder Tekton, ohne CI/CD-Pipeline wäre eine agile Anwendungsentwicklung mit häufigen Produktions-Deployments nicht denkbar. Wir sehen hier für die Zukunft Tekton als den Standard im Kubernetes-Umfeld. Der Einzug von Tekton in JenkinsX und in die RedHat OpenShift-Platform hat dies bereits bestätigt.
Den großen Vorteil von Tekton sehen wir in dem zugrundeliegenden cloud-native Ansatz: die Pipeline wird komplett als eine Menge von Ressourcen (CRDs) deployed, welche von einem Operator der einmalig auf der Plattform installiert ist, angewandt. Die Pipeline selbst besteht aus mehreren Tasks/Steps die jeweils in dem Dockerimage der eigenen Wahl gescriptet werden. Über sogenannte Cluster-Tasks können für die gesamte Plattform allgemeine Tasks wie z.B. ein Git-clone oder mvn-build zur Verfügung gestellt werden. Eine erste Anlaufstelle zur Orientierung ist der Tekton Hub, auf dem durch die Community gepflegte Tasks und Pipelines angeboten werden.
In unseren Kundenprojekten setzen wir historisch bedingt noch an vielen Stellen Jenkins ein. Gleichzeitig sehen wir im Kubernetes-Umfeld die verständliche Tendenz auf Tekton zu migrieren. Hierbei unterstützen wir Sie sehr gerne.
GitOps
GitOps ist nicht nur hip, sondern vor allem eins: ganz im Sinne von devops!
Bei GitOps geht es im Kern darum die Infrastruktur (inklusive der Konfiguration) einer Anwendung vom Applikationscode zu trennen und in getrennten Repositories zu verwalten. Ein sogenannter GitOps-Operator passt regelmäßig den Istzustand des Deployments an den Sollzustand des Infra-Repositorys an. Dies führt in der Regel zu einem Rolling-Update mit dem Ergebnis, dass die in Git vorgenommene Anpassung der Infrastruktur sofort angewandt wird.
Die beiden bekannten GitOps-Operatoren sind Flux und ArgoCD. Mit letzteren haben wir sehr gute Erfahrung in unseren Kundenprojekten gemacht.
Um den GitOps-Ansatz mit dem übergeordnetem Ziel der Etablierung von devops zu verheiraten, ist es sehr wichtig sich über das Thema Konfigurationsmanagement und damit einhergehend des Releasemanagements Gedanken zu machen. Angenommen man möchte aufgrund eines entdeckten Bugs in der Produktion auf den Codestand des letzten Deployments zurückrollen, so muss dazu gleichzeitig der dazu passende Infrarepo-Stand angewandt werden. Diese Kombination entspricht einem Release das gemangt werden muss um alles im Blick zu behalten.
Observability
Monitoring ist ein guter Anfang um die erwarteten oder bereits bekannte Fehler eines Systems zur Laufzeit zu identifizieren. Das ist ein guter Anfang, führt allerdings dazu, dass bei neuen, bisher nicht bekannten Fehlern deren Symptome in die Monitoring-Suite hinzufügt bzw. anschließend ebenso überwacht werden müssen.
Observability geht hier weiter und hat zum Ziel durch entsprechenden Einsatz geeigneter Tools das System zur Laufzeit zu verstehen indem es Ereignisse und das Systemverhalten in Korrelation setzt. Dadurch können auch Fehlerfälle zur Laufzeit identifiziert und analysiert werden die im Gegensatz zum Monitoring, bisher nicht bekannt waren. Observability ist daher eine Systemeigenschaft die auf drei konkreten Mechanismen aufsetzt: Tracing, Metriken und Logging.
Während jede dieser drei Methoden bereits für sich einen Mehrwert hinsichtlich dem Einblick in das Systemverhalten bringt, konnten wir in einigen Kundenprojekten durch deren Verknüpfung die Observability stark verbessern. So können beispielsweise durch geeignete Metriken eine Teilmenge von fehlerhaften Traces gefunden werden, die wiederum durch Korrelations-Informationen zu Log-Einträgen führen, mit denen die Fehlerursache analysiert werden kann.