Das DevOps Camp ist wieder einmal Geschichte und das natürlich viel zu schnell. Die Veranstaltung ist als BarCamp angelegt, genauere Informationen findet man hier.
Nachdem vorher nur grob ein Themenrahmen gesteckt wird, findet wie immer eine kurze Vorstellungsrunde, diesmal mit sensationellen 200 Teilnehmern, statt und dann die Sessionplanung. Es gibt sogar eine Aufzeichnung eines Teils der Planung vom Sonntag Morgen.
Das Ergebnis der Planung wird natürlich am Ende online veröffentlicht.
Folgende Sessions habe ich Sonnabend besucht.
Podman – wie funktioniert rootless
Podman is a daemonless container engine for developing, managing, and running OCI Containers on your Linux System. Containers can either be run as root or in rootless mode. Simply put:
alias docker=podman.
Soweit ich mich erinnere, wird auf Slirp, genauer gesagt auf slirp4netns zurück gegriffen, um das Problem mit unpriviligiertem network namespace zu umgehen. Leider wirft Podman neue Probleme auf. Allerdings scheinen auch laut dem Beitrag Experimenting with Rootless Docker Bestrebungen diesbezüglich bei Docker zu bestehen.
Culture Hacking
Es ging im Groben darum, wie man es mit kleinen Schritten schaffen kann, diesen Kulturwandel anzuregen. @udowiegaertner hat erst einleitend erzählt, was er (und seine konspirativen Kollegen) alles schon so "angestellt" hat. Dann haben wir in kleinen Gruppen überlegt, was man noch so alles tun kann. Bei den Vorschlägen war von hinterhältig bis saugeil alles dabei.
13 cloudy years, Cloud, Container & Confusion
Eine Session von @FrankPrechtel mit einem kurzen Abriss der technologischen Entwicklungen im Kontext "Cloud" der letzten Jahre. Eigentlich ist es vollkommen egal, worüber Frank spricht, es verspricht immer interessant und kurzweilig zu sein. Leider war der Raum schon frühzeitig so voll, dass ich mich gezwungen sah, Socializing zu betreiben. Dafür hat es auf Twitter glücklicherweise die Sketch-Notes durch meine Timeline gespült.
Kubernetes getting started
Ursprünglich als ASK-Session geplant, wurde dann ein Vortrag von einem Kollegen der Noris daraus, welcher sich um die theoretischen (Grundlagen-)Konzepte drehte und aus der Hüfte geschossen war. Ein sehr runder Vortrag in relativ kurzer Zeit. Sehr gut fand ich, dass es über das übliche Blahblah zu Pods, Master, Nodes etc. hinaus auch kurz anhand eines sehr aufschlussreichen Blogpostes Kubernetes Master Components: Etcd, API Server, Controller Manager, and Scheduler von Jorge Acetozi auf die Arbeitsweise im Zusammenhang des API Server eingegangen wurde.
Ask: Persistenz Docker/Kubernetes – Erfahrungsaustausch
Kleine Runde zu der Herausforderung "Persistentes Storage" in Containerumgebungen. Anscheinend immer noch ein riesiges Problem in Container-Umgebungen on premise. Richtig schwierig scheinen Storage-Provider zu sein, die "read-write by many nodes" unterstützen.
Wir haben hierzu folgende Matrix festgehalten:
| Driver | RWO | RWX |
|---|---|---|
| NFS | [x] | [x] |
| Ceph | [x] | |
| VMDK | [x] | |
| Cinder | [x] | |
| NetApp | [x] | |
| Trident | [x] | |
| Portworx | [x] |
NFS scheint wohl der gängige Workaround zu sein, soll wohl aber in Kubernetes deprecated zu sein/werden. Google selbst verwendet wohl auch NFS in der GKE für RWX.
Grundsätzlich möchte man anscheinend aber versuchen so viel wie möglich zu vereinheitlichen, idealerweise verwendet man einen Stogare-Provider der sich immer gleich anfühlt (und nicht in jedem Projekt was anderes). Ceph scheint auch ein heisser Kandidat zu sein.
Unabhängig davon scheinen gute Quellen die OpenShift Persistent Storage und Kubernetes Persistent Volumes Access Modes Dokumentation zu diesem Thema zu sein.
Overcooked – Führungsstile + Teams mit Spielkonsole ausprobieren
Wieder eine Session von @udowiegaertner! Nachdem ich von der ersten schon sehr angetan war, musste ich da natürlich unbedingt hin.
Grob ging es darum, dass man ein Teamverhalten auch wunderbar in einem Spiel erforschen und beobachten kann, in dem darum geht, Aufgaben zu erledigen. Dies wurde anhand von Overcooked! nach einer kurzen thematischen Einführung mit einer Versuchsgruppe von 4 Personen ausprobiert. Hierbei wurden neben den Spielanforderungen auch noch vom Spielleiter in den jeweiligen Spielrunden zusätzliche Randbedingungen definiert, wie beispielsweise, es darf keine Strafpunkte geben, es soll in Zweierteams gearbeitet werden oder mitten im Spiel scheidet ein Mitarbieter wegen "Elternzeit" aus und wird durch einen neuen Mitarbeiter ersetzt.
Hier konnte man recht gut sehen, dass sich durch bestimmte Massnahmen, Konstellationen oder unvorhergesehene Ereignisse das Ergebnis durchaus sehr stark verändert. Analogien zum Teamverhalten in Firmen waren offensichtlich und so konnte man sich aus Sicht des "Mitarbeiter" und aber auch aus Sicht des Managers bzw. Consultant, welches als ganzes Consultant-Team in Form der restlichen Session-Teilnehmer vorhanden war, ein recht gutes Bild machen, was es für Faktoren in Teams gibt, die das Ergebnis durchaus massgeblich beeinflussen.
Hier nochmal das Scoreboard mit den jeweiligen Team-Eigenschaften und den "Aha-Effekten".
Im Anschluss an die Sessions am Samstag war Networking und Socializing angesagt. Ich erspare Euch die #Foodporn Fotos, kommt das nächste Mal einfach vorbei.
Am etwas späteren Abend hat sich dann ganz spontan noch eine Lightning-Beer-Talk Session aufgetan. Wir waren leider schon auf dem Weg ins Hotel und noch kurz in einer andere Trinkhalle. Ich habe aber nur extrem gutes Feedback bekommen ... ich hoffe dies wird im nächsten Jahr offiziell in die Agenda aufgenommen!
Sonntag morgen ging es tatsächlich etwas zäher los, sowohl bei mir als auch auf dem Camp selbst. Nichtsdestotrotz begann alles mit einer Stärkung und wieder mit der üblichen Session-Planung.
Karriere in der IT
Eine Session von Ingo. Tja, was soll ich sagen ... auch bei Ingo ist jede Session aufschlussreich und mindestens interessant.
Im Grunde ging es darum, warum in der IT aus welchen Gründen Menschen in gewisse Positionen kommen. Welchen Sinn und Unsinn Titel haben und welche Mechanismen da eine Rolle spielen, war sehr inspirierend.
Von FTP bis AWS
@mattagohni hat uns von der schrittweisen Entwicklung div. Lösungen bei solutionDrive erzählt. Wie hat man früher Probleme erledigt (ja, FTP) und wohin hat man sich jetzt bewegt mit Terrorform, Packer, AWS vielen anderen Dingen rund um dieses "neumodische Hipster-Zeuch".
Wohin soll die Reise gehen, Entwicklungsmöglichkeiten, Generalisierung vs Spezifikation
Wieder @FrankPrechtel, diesmal habe ich die CCC-Strategie angewandt und mich schon mal in die Session davor gesetzt, um dann auch Platz in der Session zu haben, in die ich will. :)
Inhaltlich ging es darum, was man tun kann, um am (Arbeits-)Markt relevant zu bleiben. Z.B. T-Shape versuchen etc.
CI/CD Deployments with GitLab-CI
DrSlow und behu von Paessler haben uns an ihren Erfahrungen in Bezug auf Installation und Operations von Kubernetes teilhaben lassen.
Sehr bemerkenswert war, dass hier auch nach aussen offen mit einer Fehlerkultur umgegangen wurde und es bei bei Paessler auch möglich war, ein Projekt, welches sehr weit fortgeschritten ist, nochmals komplett über den Haufen zu werfen, weil man merkte, man ist in einer Sackgasse gelandet.
Ich zitiere hier kurz das Paessler Culture Deck:
Wenn wir nie versagen, haben wir uns nicht genug vorgenommen.
Bei Paessler wird anscheinend aktuell über das Kubernets-Setup hauptsächlich CI/CD workload gefahren, konkret über Gitlab-CI. Die Anforderung nach persistenten Storage scheint nur in geringem Maße vorhanden und aufgrund der hauptsächlichen Nutzung als CI/CD ist auch Tiller nicht notwendig, was ursprünglich einiges an Schwerzen verursacht hat.
Das aktuelle Setup wird wohl mit Rancher 2 als Kubernetes-Orchestrator verwendet und der Anspruch ist, Kubernets den Inhouse-Kunden weitestgehend als Self-Service anzubieten.
Eine sehr geile Session, wo auch nicht gespart wurde mit 'lessions learned' und 'please don't do'
Alles in allem war es wieder ein sehr schönes, entspanntes aber auch interessantes, kurzweiliges Barcamp. Ich freue mich schon auf das DevOps Camp compact im Herbst!