allesnurgecloud.com ist ein kuratierter Newsletter mit Inhalten aus der Open-Source, Cloud und IT-Welt.
Für weiteren Content folge mir gerne auf Twitter, Mastodon oder LinkedIn.
Möchtest du den Newsletter wöchentlich per E-Mail erhalten?
Einfach hier abonnieren:
Die Hintergründe der 5 Stunden Facebook Downtime
Facebook, Instagram und WhatsApp waren am 4. Oktober 2021 für mehr als 5 Stunden down – Was war aber passiert?
Facebook hatte um ca. 15:40 Uhr UTC (Das ist aktuell 17:40 Uhr in Europe/Berlin) diverse BGP Updates gesendet und sich somit unerreichbar gemacht. Alle IP Adressen hinter Facebooks ASN 32934 waren nicht mehr erreichbar, hier stehen auch die DNS Server von Facebook. Somit konnte niemand mehr die Dienste von Facebook, Instagram und WhatsApp nutzen.
Eine ASN ist die Zugangsnummer eines „Autonomen Systems“, dies beschreibt ein eigenes Netzwerk, in dem man selbst alle Ziele kennt. Beispielsweise wenn eine Poststation einer Stadt die einzige Entität wäre, die weiß, wo sich beispielsweise die Oststraße 42 befindet. Cloudflare hat hier eine gute Erklärung zu AS und BGP auf deutsch.
Julia Evens hat auf Twitter versucht, die BGP Änderungen zeitlich nachzuvollziehen und zu Visualisieren. Man kann in diesem Bild schön den vorher/nachher zustand der BGP Routen sehen – links ist das Netz sehr gut mit diversen anderen Netzen verbunden, Rechts ist das Netz alleine und sendet ein erstes Lebenszeichen (Quelle: twitter )
Cloudflare hat die zeitliche Reihenfolge und die Auswirkungen in einem Blog Eintrag sehr gut erklärt. Die massive Störung bei Facebook führte über diverse Kaskadeneffekte zu Störungen auf anderen Website – beispielsweise durch eingebundene Facebook Login Plugins, oder auch einfach nur langsam ladende Werbe-Tracker.
Teilweise wurden auch andere Dienste gestört, wie beispielsweise der DNS Service des AdBlockers AdGuard.
Facebook hatte in einem ersten Blog Post seine Sicht der Dinge erklärt, als die Systeme wieder erreichbar waren. Ein ausführliches Posting vom 5.10.2021 erlaubt einen Einblick mit viel mehr Details. Teilweise werden Gerüchte bestätigt, dass die Facebook Engineers Schwierigkeiten beim physischen Zugriff auf die Datacenter hatten – der Remote Zugriff hatte nicht mehr funktioniert, da man ein DNS System für interne und externe Dienste verwendet.
Facebook hatte in der Vergangenheit seinen BGP Release Cycle öffentlich vorgestellt – auch an dieser Stelle verwendet man automatisierte Tests in einem CI/CD Prozess. Auf der „USENIX Symposium on Networked Systems Design and Implementation“ im April 2021 stellte Facebook in einer Präsentation „Running BGP in Data Centers at Scale“ (Video ca. 12 Minuten). Der Blog Eintrag „Running Border Gateway Protocol in large-scale data centers“ aus dem Mai 2021 gibt noch weitere Details hierzu.
Twitch.tv mit massivem Data-Leak
Twitch, das Streaming Portal welches 2014 von Amazon übernommen wurde, hatte in dieser Woche einen massiven 125GB Data-Leak. Der Leak ist ziemlich umfangreich und enthält den Source Code diverser Applikationen, Secrets für diverse 3rd Party Dienste, Infrastructure as Code (IaC) Anweisungen für die Twitch AWS Infrastruktur und Daten aller Streamer und User.
Zuerst war der Vorfall auf Twitter zu lesen, unter anderem mit Screenshots der Streamer-Einnahmen bei @Sinoc229.
Twitch selbst gab am 7. Oktober bekannt, dass keine Login-Daten entwendet wurden, Sicherheitsforscher hingegen sind der Meinung, dass Passwörter, E-Mails und zugehörige Paypal Konten ebenfalls entwendet wurden (Quelle: golem.de).
Manche Dinge sind unverständlich, beispielsweise dass man Unmengen an Secrets (API Zugänge zu SaaS Diensten, Datenbanken, Analyse Tools,..) im Source Code mit ablegt. Sowas sollte man im Jahr 2021 auf keinen Fall mehr machen, und doch passiert es immer wieder.
In dem Zusammenhang auch interessant ist das Reverse Engineering eines AWS Security Consultants der Twitch Infrastruktur bei AWS. Man nutzt über 1442 AWS Account ID, 60 S3 Buckets, Terraform, CloudFormation, Chef, Packer, Jenkins, Slack, Pagerduty und so weiter. Die Teams arbeiten dem Eindruck nach in ihren eigenes Silos, mit jeweils eigenen Prozessen für DevOps, Security und Systeme – andere würden dies positiv als „loosely coupled“ verkaufen.
Aktuell ist noch unklar, woher der Leak genau stammt – laut @zoph wurden sie über das letzte Wochenende erstellt.
golem.de: Twitch-Leak: Einnahmen der Streamer, Quellcode und mehr im Netz
Sponsored
Senior Consultant Cloud Data Engineering (m/w/d)
superluminar ist ein 12-köpfiges, auf AWS spezialisiertes Team, das Kunden wie Fielmann, Immowelt, MOIA sowie Startups auf dem Weg in und durch die Cloud partnerschaftlich begleitet. Neben der strategischen Beratung krempelt superluminar auch selbst die Ärmel hoch und steigt in den Maschinenraum, um mit Unternehmen gemeinsam innovative Produkte und Technologien zu entwickeln: Bei Projektende gehören das Wissen, die Fähigkeiten und die Lösung so dem Kunden.
Als Senior Consultant Cloud Data Engineering (m/w/d) treibst du gemeinsam mit deinen neuen Kolleg:innen die Data-Projekte unserer Kunden voran. Der Fokus liegt dabei auf der Entwicklung von ETL Pipelines und Data Pipelines, Engineering-Beratung, Coaching und Trainings. Auch wird Machine Learning eine Rolle spielen.
Gerne darfst du in Teilzeit arbeiten, dir ein Firmenfahrrad aussuchen und von nachhaltiger Betrieblicher Altersvorsorge sowie Kita-Zuschüssen profitieren.
Serverless kann Infrastructure und Operations komplexer und teurer machen
Tom McLaughlin beschreibt im verlinkten Twitter Thread, dass die Verwendung von „Serverless“ in manchen Organisationen eine Herausforderung werden kann.
Die meisten Unternehmen starten nicht auf der grünen Wiese, sondern haben vorhandene Strukturen und Infrastrukturen, und müssen nun zusätzlich „Serverless“ Techniken lernen und in die Organisation treiben.
Im Status Quo betreibt ein Plattform, DevOps oder Infrastruktur Team Themen wie Netzwerke, VPCs, Loadbalancer, Monitoring und Security. Setzt man nun voll auf „Serverless“ oder andere als SaaS/PaaS bereitgestellte Dienste, so sourced man diese Komplexität an den Cloud Betreiber aus.
Der Entwickler muss trotzdem verstehen, was hier passiert, somit erhöhe sich für ihn die Komplexität. Ein Entwickler übernimmt somit mehr Verantwortung des ganzen Stacks als im vorherigen Modell.
Tom beschreibt, dass es in vielen Teams funktionieren kann. Man müsse sich allerdings darüber klar sein, dass man die Mitarbeiter/Entwickler dafür ausbilden muss, man diese Skills nicht von heute auf morgen lernt und das eben nicht alle Entwickler eine solche Verantwortung haben wollen.
Tom beschreibt dies folgendermaßen:
Devs went from putting code into a container and it Just Working(TM) to being slowed down by owning more work in a layer of the stack they’re not familiar with.
If you don’t actively address the new complexity devs just assumed responsibility for you’re going to have a new and unexpected opposition front.
It’s devs who “just want to code and not worry about infrastructure”.And dev leadership who are questioning losses in productivity
Aus meinen persönlichen Erfahrungen kann ich da nur zustimmen. Die meisten Probleme beim Shift entstehen nicht auf der technischen Seite, sondern beim Menschen und Prozessen.
VMWare Tanzu – Kubernetes Community Edition released
VMWare hat Anfang Oktober die Community Version seiner Kubernetes Distribution Tanzu veröffentlicht.
Tanzu könnt ihr einfach lokal in eurer Docker Desktop Installation ausprobieren, oder in eurer VMWare vSphere Cluster deployen.
Die Community Version ist dazu gedacht, sich Tanzu mal anzusehen oder in kleinen oder pre-production Environments zu betreiben.
Tanzu bundled diverse CNCF Projekte zu einer kompletten Kubernetes Platform und verwendet unter anderem Grafana, Prometheis und Fluent für Observability, Knative, Harbor, KubeApps und kpack für Build & Deploy und Velero, Pinniped, Sonobuoy und Open Policy Agent im Service Layer. Viele der Services hat VMWare selbst open-source veröffentlicht.
Die offizielle Dokumentation gibt einen guten Einstieg in das Thema VMWare Tanzu.
Announcing Tanzu Community Edition from VMware
Raspberry Pi Kubernetes Cluster mit Netboot betreiben
Alex Ellis hatte im Dezember 2017 seinen 30 Node Raspberry Pi Cluster vorgestellt. Aufgrund eines timing Bugs konnte er damals kein Netboot verwenden und musste auf SD Karten ausweichen. Diese Karten zeigten sich aufgrund permanenter Schreiboperationen im Kubernetes Cluster aber als sehr unzuverlässig.
Im verlinkten Artikel erklärt Alex Historie und sein heutiges Setup, bestehend aus einem 8 Node Raspberry Cluster in einem BitScope Cluster Blade mit insgesamt 40GB RAM und 32 CPU Cores. Der Netboot Server ist ein Intel NUC, welcher diesmal ohne Probleme PXE boot die Ubuntu 20.04 Raspberries bereitstellen konnte.
Alex hat sein gesammeltes Wissen als kostenpflichtigen „Netbooting Workshop for Raspberry PI“ auf Gumroad bereitgestellt.
State of netbooting Raspberry Pi in 2021
Helpdesk Software Zammad erscheint in Version 5.0
Die populäre Helpdesk Software Zammad wurde in der Version 5.0 veröffentlicht.
Mit dem lang ersehnten Feature „Core Workflows“ können Zammad Administratoren Screens und Masken dynamisch auf Gruppen anpassen und eben bestimmte Felder anzeigen, ausblenden oder customizen.
Zusätzlich gibt es in der 5.0 von Zammad eine Integration des SMS Dienstes Messagebird und Zammad wird auf eine inklusive Sprache umgestellt. Außerdem wurde die Integration mit Jira weiter verbessert und diverse kleinere Verbesserungen vorgenommen.
Zammad kann man noch immer in der Community Variante selbst betreiben oder einfach als SaaS Dienst konsumieren.
O’reilly Infrastructure and Ops Bundle
Bei Humble Bundle gibt es aktuell ein interessantes O’reilly Bundle zum Thema „Infrastructure and Ops“, welches unter anderem folgende eBooks enthält:
- Terraform Up & Running
- Distributed Tracing in Practice
- Kubernetes Operators
- Kubernetes Best Practices
- Learning Helm
- Prometheus Up & Running
Für die insgesamt 15 Bücher müsst ihr mindestens 15,38€ bezahlen – dafür erhaltet ihr die Bücher als PDF, ePUB und im MOBI Format und könnt diese DRM frei auf sämtlichen Geräten lesen (Danke Tim für den Tipp).
Schmunzelecke
„A Day in the Life of an engineer working from home“ – na, bei wem passt es? – zum Video auf YouTube.
„I have summarized the Apache path normalization clusterfuck for you“ – auf Twitter bei Florian Roth.
💡 Link Tipps aus der Open Source Welt
PostgreSQL 14 Released!
PostgreSQL wurde Ende September in der Version 14 veröffentlicht. Mit Version 14 soll die Verarbeitung und Manipulation von JSON Daten weiter vereinfacht werden. Performanceintensive Workloads mit vielen parallelen Connections sollen nun teilweise doppelt so schnell bearbeitet werden können. In verteilten Systemen mit Replica Datenbanken wurde zudem die Performance für replizierte Systeme verbessert. Des weiteren gibt Verbesserungen in der Stabilität, Administration und im Monitoring eurer PostgreSQL Instanzen.
Below: Time Traveling Resource Monitor für Linux
Below ist ein von Facebook open-source veröffentlichter System Monitor mit History. Stellt es euch als „atop“ vor, mit dem ihr in die Vergangenheit des Systemzustands springen könnt. „Was war gestern um 13:37 auf System X“ passiert, welcher Prozess hatte wieviel Speicher genutzt, und so weiter.
https://github.com/facebookincubator/below
Peirates – Kubernetes Penetration Testing
Peirates ist ein Kubernetes Penetration Testing Tool, welches als Container in einem Kubernetes Cluster gestartet wird. Es versucht dann automatisch diverse „Privilege Escalation“ Methoden und versucht Service Accounts zu stehlen und am Ende euren Kubernetes Cluster zu übernehmen. Peirates wird von den Sicherheitsforschern inGuardians auf GitHub Open-Source veröffentlicht.
https://github.com/inguardians/peirates
❓ Feedback & Newsletter Abo
Vielen Dank, dass du es bis hierhin geschafft hast!
Kommentiere gerne oder schicke mir Inhalte, die du passend findest.
Falls dir die Inhalte gefallen haben, kannst du mir gerne auf Twitter folgen.
Gerne kannst du mir ein Bier ausgeben oder mal auf meiner Wunschliste vorbeischauen – Danke!
Möchtest du den Newsletter wöchentlich per E-Mail erhalten?
Einfach hier abonnieren: