9 Protokoll vor
Konfiguration und State sehen auf den ersten Blick wie zwei Beschreibungen derselben Infrastruktur aus. Dabei sagt die eine nur, wie etwas aussehen soll – die andere, was wirklich existiert.
Die Verwechslung liegt nahe, weil beide Dateien dieselben Ressourcen nennen. Wer nur die Konfiguration liest, glaubt deshalb, Terraform brauche nichts weiter.
Die Konfiguration ist der Bauplan. In HCL, der Sprache von Terraform, wird dort beschrieben, welche Ressourcen gewünscht sind und mit welchen Einstellungen. Steht darin eine VPC (das private Netz in der Cloud), legt der Code Name und IP-Adressbereich fest, etwa als Adressbereich mit Netzpräfix. Die Konfiguration sagt aber nicht, welches echte Netz die Cloud daraus gebaut hat.
Der State ist das Gedächtnis. Er ist im Kern eine kleine Datenbank, in der Terraform für jede Ressource die konkrete Kennung speichert, die die Cloud vergeben hat, samt den aktuellen Attributen. Für die Beispiel-VPC merkt er sich ihre ID, den Adressbereich und die zugehörigen Subnetze. Aus der Differenz zwischen Konfiguration und State berechnet terraform plan die Änderungen.
Ohne State hält Terraform die VPC für nicht vorhanden und würde bei apply alles neu anlegen, obwohl die echten Objekte längst laufen. Der State ist deshalb kein Anhängsel, sondern Voraussetzung für jeden sauberen Plan.
Faustregel: Den State zentral in einem Remote-Backend, also einer zentralen Ablage wie S3, ablegen, nie lokal in Git, und per State-Locking schützen, das zwei gleichzeitige Läufe am selben State verhindert. Drift durch manuelle Konsolenänderungen macht terraform plan sichtbar. Sensible Werte im State wie ein Geheimnis behandeln.
Der State heißt nicht Kopie der Konfiguration, sondern Zuordnung zwischen Wunsch und Wirklichkeit – fehlt sie, baut Terraform doppelt.
📌 Terraform State · Konfiguration vs. Realität · Remote-Backend
📚 Cloud von Grund auf · Tag 6 von 30
#Terraform #iac #devops
Die Verwechslung liegt nahe, weil beide Dateien dieselben Ressourcen nennen. Wer nur die Konfiguration liest, glaubt deshalb, Terraform brauche nichts weiter.
Die Konfiguration ist der Bauplan. In HCL, der Sprache von Terraform, wird dort beschrieben, welche Ressourcen gewünscht sind und mit welchen Einstellungen. Steht darin eine VPC (das private Netz in der Cloud), legt der Code Name und IP-Adressbereich fest, etwa als Adressbereich mit Netzpräfix. Die Konfiguration sagt aber nicht, welches echte Netz die Cloud daraus gebaut hat.
Der State ist das Gedächtnis. Er ist im Kern eine kleine Datenbank, in der Terraform für jede Ressource die konkrete Kennung speichert, die die Cloud vergeben hat, samt den aktuellen Attributen. Für die Beispiel-VPC merkt er sich ihre ID, den Adressbereich und die zugehörigen Subnetze. Aus der Differenz zwischen Konfiguration und State berechnet terraform plan die Änderungen.
Ohne State hält Terraform die VPC für nicht vorhanden und würde bei apply alles neu anlegen, obwohl die echten Objekte längst laufen. Der State ist deshalb kein Anhängsel, sondern Voraussetzung für jeden sauberen Plan.
Faustregel: Den State zentral in einem Remote-Backend, also einer zentralen Ablage wie S3, ablegen, nie lokal in Git, und per State-Locking schützen, das zwei gleichzeitige Läufe am selben State verhindert. Drift durch manuelle Konsolenänderungen macht terraform plan sichtbar. Sensible Werte im State wie ein Geheimnis behandeln.
Der State heißt nicht Kopie der Konfiguration, sondern Zuordnung zwischen Wunsch und Wirklichkeit – fehlt sie, baut Terraform doppelt.
📌 Terraform State · Konfiguration vs. Realität · Remote-Backend
📚 Cloud von Grund auf · Tag 6 von 30
#Terraform #iac #devops
3 Std vor
Eine Kanzlei mit zu viel Post öffnet keine größeren Briefkästen, sondern stellt einfach zwei Schalter nebeneinander. Genau so antwortet die Cloud auf wachsende Last.
Das Bild ausgemalt: Am einen Schalter staut sich die Schlange, also baut man den Schalter zu einem größeren Schalter um, an dem mehr Menschen gleichzeitig bedient werden. Der Umbau braucht Zeit, und währenddessen ist der Schalter zu. Schöner ist es, einen zweiten, gleichen Schalter zu öffnen, der sofort arbeiten kann. Und fällt ein Schalter aus, bleibt der andere besetzt.
Fachlich ist das vertikales Skalieren: Die bestehende Instanz, also eine virtuelle Maschine wie EC2, wird durch eine leistungsstärkere ersetzt. Horizontales Skalieren heißt stattdessen, zusätzliche Instanzen derselben Art daneben zu schalten und die Anfragen auf sie zu verteilen. Der Schalterausfall ist ein Single Point of Failure, eine Komponente, deren Ausfall alles stoppt.
In der Praxis: Mehr gleichzeitige Anfragen sprechen für horizontal, denn Lastverteilung wächst nach Bedarf, und die Abrechnung folgt der Nutzung. Größere einzelne Anfragen, etwa eine Datenbank mit hohem Speicherbedarf, sprechen für vertikal. Kubernetes hält dabei die gewünschte Anzahl laufender Container-Instanzen automatisch ein.
Das Bild hat eine Grenze: Ein Schalterteam braucht nur Menschen, Instanzen brauchen einen Lastverteiler, der die Anfragen auf die Instanzen verteilt, und geteilte Zustände wie Datenbanken. Und vertikal stößt man an die größte angebotene Instanzgröße, während horizontales Ergänzen nahezu unbegrenzt bleibt.
Horizontales Skalieren heißt nicht teurer, sondern redundanter: Mehr Instanzen schützen vor Ausfall, eine große Instanz bleibt ein einziger Schwachpunkt.
📌 Horizontale Skalierung · Vertikale Skalierung · Redundanz
📚 Cloud von Grund auf · Tag 6 von 30
#aws #devops #CloudHosting
Das Bild ausgemalt: Am einen Schalter staut sich die Schlange, also baut man den Schalter zu einem größeren Schalter um, an dem mehr Menschen gleichzeitig bedient werden. Der Umbau braucht Zeit, und währenddessen ist der Schalter zu. Schöner ist es, einen zweiten, gleichen Schalter zu öffnen, der sofort arbeiten kann. Und fällt ein Schalter aus, bleibt der andere besetzt.
Fachlich ist das vertikales Skalieren: Die bestehende Instanz, also eine virtuelle Maschine wie EC2, wird durch eine leistungsstärkere ersetzt. Horizontales Skalieren heißt stattdessen, zusätzliche Instanzen derselben Art daneben zu schalten und die Anfragen auf sie zu verteilen. Der Schalterausfall ist ein Single Point of Failure, eine Komponente, deren Ausfall alles stoppt.
In der Praxis: Mehr gleichzeitige Anfragen sprechen für horizontal, denn Lastverteilung wächst nach Bedarf, und die Abrechnung folgt der Nutzung. Größere einzelne Anfragen, etwa eine Datenbank mit hohem Speicherbedarf, sprechen für vertikal. Kubernetes hält dabei die gewünschte Anzahl laufender Container-Instanzen automatisch ein.
Das Bild hat eine Grenze: Ein Schalterteam braucht nur Menschen, Instanzen brauchen einen Lastverteiler, der die Anfragen auf die Instanzen verteilt, und geteilte Zustände wie Datenbanken. Und vertikal stößt man an die größte angebotene Instanzgröße, während horizontales Ergänzen nahezu unbegrenzt bleibt.
Horizontales Skalieren heißt nicht teurer, sondern redundanter: Mehr Instanzen schützen vor Ausfall, eine große Instanz bleibt ein einziger Schwachpunkt.
📌 Horizontale Skalierung · Vertikale Skalierung · Redundanz
📚 Cloud von Grund auf · Tag 6 von 30
#aws #devops #CloudHosting
6 Std vor
Terraform apply läuft, und plötzlich legt es eine zweite EC2-Instanz neben der bestehenden an. Das Symptom kennen viele bei ihren ersten Cloud-Projekten.
Trotz unveränderter Konfiguration entstehen doppelte Ressourcen in der Cloud. Die alten Instanzen laufen weiter und verursachen weiterhin Kosten.
Terraform hält in einer State-Datei fest, welche echten Cloud-Ressourcen zu welchem Konfigurationseintrag gehören. Dieser State ist Terraforms Gedächtnis: Er speichert den Zustand, den Terraform beim letzten apply beobachtet hat. Bei jedem Lauf vergleicht Terraform den Soll-Zustand aus den .tf-Dateien, den Ist-Zustand aus dem State und die reale Cloud.
In der Konfiguration steht eine EC2-Instanz namens web-server. Nach dem apply liegt die Instanz-ID der erzeugten Cloud-Instanz im State. Genau diese ID erlaubt Terraform bei einer späteren Änderung, dieselbe Instanz zu aktualisieren statt eine neue zu bauen. Ohne State entsteht beim nächsten apply eine doppelte Instanz.
So prüft man es: Nach terraform apply die Ausgabe darauf prüfen, ob sie nur beabsichtigte Änderungen zeigt. Erscheinen Ressourcen als komplett neu, fehlt vermutlich die Zuordnung im State.
Der State ist kein Protokoll, sondern ein Abbuchungsregister: Er entscheidet, welche echte Ressource beim Abbau entfernt wird. Deshalb gehört er geschützt in ein Remote-Backend, ein zentraler Ablageort für den State, etwa ein S3-Bucket; dort verhindert State-Locking, dass zwei Läufe gleichzeitig denselben State überschreiben. Weil der State Klartext wie Passwörter enthalten kann, hat er nichts in Git verloren.
Ein verlorener State lässt sich über Import-Werkzeuge teilweise zurückholen. Einfacher ist es, ihn nie zu verlieren.
State heißt nicht Nebenprodukt, sondern Gedächtnis ohne Rückversicherung.
📌 State-Datei · Remote-Backend · State-Locking
📚 Cloud von Grund auf · Tag 6 von 30
#Terraform #iac #devops
Trotz unveränderter Konfiguration entstehen doppelte Ressourcen in der Cloud. Die alten Instanzen laufen weiter und verursachen weiterhin Kosten.
Terraform hält in einer State-Datei fest, welche echten Cloud-Ressourcen zu welchem Konfigurationseintrag gehören. Dieser State ist Terraforms Gedächtnis: Er speichert den Zustand, den Terraform beim letzten apply beobachtet hat. Bei jedem Lauf vergleicht Terraform den Soll-Zustand aus den .tf-Dateien, den Ist-Zustand aus dem State und die reale Cloud.
In der Konfiguration steht eine EC2-Instanz namens web-server. Nach dem apply liegt die Instanz-ID der erzeugten Cloud-Instanz im State. Genau diese ID erlaubt Terraform bei einer späteren Änderung, dieselbe Instanz zu aktualisieren statt eine neue zu bauen. Ohne State entsteht beim nächsten apply eine doppelte Instanz.
So prüft man es: Nach terraform apply die Ausgabe darauf prüfen, ob sie nur beabsichtigte Änderungen zeigt. Erscheinen Ressourcen als komplett neu, fehlt vermutlich die Zuordnung im State.
Der State ist kein Protokoll, sondern ein Abbuchungsregister: Er entscheidet, welche echte Ressource beim Abbau entfernt wird. Deshalb gehört er geschützt in ein Remote-Backend, ein zentraler Ablageort für den State, etwa ein S3-Bucket; dort verhindert State-Locking, dass zwei Läufe gleichzeitig denselben State überschreiben. Weil der State Klartext wie Passwörter enthalten kann, hat er nichts in Git verloren.
Ein verlorener State lässt sich über Import-Werkzeuge teilweise zurückholen. Einfacher ist es, ihn nie zu verlieren.
State heißt nicht Nebenprodukt, sondern Gedächtnis ohne Rückversicherung.
📌 State-Datei · Remote-Backend · State-Locking
📚 Cloud von Grund auf · Tag 6 von 30
#Terraform #iac #devops
9 Std vor
Die meisten führen terraform apply direkt aus und schauen zu, was passiert. Dabei zeigt terraform plan vorher exakt, was passieren würde.
Ein apply ohne Blick auf den Plan ist ein Commit ohne Diff: Man weiß nicht, was gelöscht oder neu gebaut wird. Der Plan kostet Sekunden und verhindert teure Überraschungen.
📦 terraform plan zeigt jede Änderung mit einem Vorzeichen am Zeilenanfang. Plus bedeutet neu erstellen, Minus löschen, Tilde verändern. Etwa „+ aws_instance.web“ heißt: Diese Ressource wird neu gebaut, nicht nur geändert.
🔑 Drift wird erst im Plan sichtbar, also Abweichungen zwischen State und echter Infrastruktur. Der State ist Terraforms Datei, die Konfiguration und reale Ressourcen einander zuordnet. Wer eine Sicherheitsgruppe manuell in der Konsole ändert, sieht das im Plan als Tilde.
📈 Mit terraform plan -out=plan.tfplan wird der Plan als binäre Datei gespeichert. Sie enthält neben den Änderungen auch den damaligen Zustand. Anschließend setzt terraform apply plan.tfplan genau diesen Stand um, nichts anderes. Der Einsteigerirrtum: apply ohne Datei erneut ausführen und glauben, der zuvor gesehene Plan werde umgesetzt. Ohne Datei erzeugt apply einen neuen Plan. Hat sich die Realität inzwischen geändert, etwa durch einen Kollegen, wird etwas anderes ausgeführt als geprüft wurde. Deshalb gilt: prüfen, speichern, genau diese Datei anwenden. In Pipelines mit manueller Freigabe ist der gespeicherte Plan das Kontrollmittel: Geprüftes und Ausgeführtes sind identisch. Eine fest gepinnte Provider-Version hält Plan und Ausführung reproduzierbar.
Gespeichert heißt nicht bestätigt, sondern eingefroren: apply führt genau den geprüften Stand aus. Ohne Datei heißt apply „neu planen“, nie „wie gerade gesehen“.
📌 terraform plan · Plan-Datei · Drift
📚 Cloud von Grund auf · Tag 5 von 30
#Terraform #iac #devops
Ein apply ohne Blick auf den Plan ist ein Commit ohne Diff: Man weiß nicht, was gelöscht oder neu gebaut wird. Der Plan kostet Sekunden und verhindert teure Überraschungen.
📦 terraform plan zeigt jede Änderung mit einem Vorzeichen am Zeilenanfang. Plus bedeutet neu erstellen, Minus löschen, Tilde verändern. Etwa „+ aws_instance.web“ heißt: Diese Ressource wird neu gebaut, nicht nur geändert.
🔑 Drift wird erst im Plan sichtbar, also Abweichungen zwischen State und echter Infrastruktur. Der State ist Terraforms Datei, die Konfiguration und reale Ressourcen einander zuordnet. Wer eine Sicherheitsgruppe manuell in der Konsole ändert, sieht das im Plan als Tilde.
📈 Mit terraform plan -out=plan.tfplan wird der Plan als binäre Datei gespeichert. Sie enthält neben den Änderungen auch den damaligen Zustand. Anschließend setzt terraform apply plan.tfplan genau diesen Stand um, nichts anderes. Der Einsteigerirrtum: apply ohne Datei erneut ausführen und glauben, der zuvor gesehene Plan werde umgesetzt. Ohne Datei erzeugt apply einen neuen Plan. Hat sich die Realität inzwischen geändert, etwa durch einen Kollegen, wird etwas anderes ausgeführt als geprüft wurde. Deshalb gilt: prüfen, speichern, genau diese Datei anwenden. In Pipelines mit manueller Freigabe ist der gespeicherte Plan das Kontrollmittel: Geprüftes und Ausgeführtes sind identisch. Eine fest gepinnte Provider-Version hält Plan und Ausführung reproduzierbar.
Gespeichert heißt nicht bestätigt, sondern eingefroren: apply führt genau den geprüften Stand aus. Ohne Datei heißt apply „neu planen“, nie „wie gerade gesehen“.
📌 terraform plan · Plan-Datei · Drift
📚 Cloud von Grund auf · Tag 5 von 30
#Terraform #iac #devops
12 Std vor
Der erste Docker-Build dauert Minuten, der zweite nur Sekunden – solange niemand die Anweisungsreihenfolge ändert. Dabei entscheidet oft allein die Reihenfolge im Dockerfile, ob der Cache greift oder nicht.
Das kennt jeder, der einmal ein Dockerfile (das Baurezept für ein Container-Image) geschrieben hat. Wer die Reihenfolge nicht versteht, wartet bei jeder kleinen Änderung wieder so lange wie beim ersten Mal.
Der Build-Cache ist ein Speicher für fertige Schichten. Ein Docker-Image besteht aus Schichten: Jede Anweisung wie FROM, RUN oder COPY erzeugt genau eine, die auf der vorherigen aufbaut. Beim Neubau prüft Docker jede Anweisung von oben nach unten und übernimmt unveränderte Schichten unverändert. Sobald sich eine Anweisung ändert, sind alle folgenden Schichten ungültig und werden neu gebaut – auch wenn sie selbst gleich geblieben sind.
Ein typisches Dockerfile für eine Node-Anwendung kopiert zuerst nur package.json, führt npm install aus und kopiert danach erst den Quellcode. Der Cache-Schlüssel einer Anweisung umfasst den Anweisungstext und den Inhalt kopierter Dateien: Ein geändertes package.json macht die Installations-Schicht ungültig, ein geänderter Quelltext nur die Kopier-Schicht. Eine reine Codeänderung baut also nur die letzte Schicht neu.
Verwechselt wird der Cache gern mit einem bloßen Zeitmesser. Er prüft keine Ähnlichkeit, sondern exakte Schlüssel. Steht COPY ganz oben, macht jede kleine Codeänderung die teure Installations-Schicht ungültig – und der Build dauert jedes Mal wie beim ersten Mal. Deshalb gilt: selten Geändertes wie das Basis-Image (das Image, auf dem das eigene aufbaut, etwa in der FROM-Anweisung) an den Anfang, häufig Geändertes wie den Quellcode an das Ende.
Der Build-Cache belohnt keine schönen Dockerfiles, sondern stabile Anweisungsreihen.
📌 Schichten · Cache-Schlüssel · Reihenfolge
📚 Cloud von Grund auf · Tag 5 von 30
#docker #devops #CloudHosting
Das kennt jeder, der einmal ein Dockerfile (das Baurezept für ein Container-Image) geschrieben hat. Wer die Reihenfolge nicht versteht, wartet bei jeder kleinen Änderung wieder so lange wie beim ersten Mal.
Der Build-Cache ist ein Speicher für fertige Schichten. Ein Docker-Image besteht aus Schichten: Jede Anweisung wie FROM, RUN oder COPY erzeugt genau eine, die auf der vorherigen aufbaut. Beim Neubau prüft Docker jede Anweisung von oben nach unten und übernimmt unveränderte Schichten unverändert. Sobald sich eine Anweisung ändert, sind alle folgenden Schichten ungültig und werden neu gebaut – auch wenn sie selbst gleich geblieben sind.
Ein typisches Dockerfile für eine Node-Anwendung kopiert zuerst nur package.json, führt npm install aus und kopiert danach erst den Quellcode. Der Cache-Schlüssel einer Anweisung umfasst den Anweisungstext und den Inhalt kopierter Dateien: Ein geändertes package.json macht die Installations-Schicht ungültig, ein geänderter Quelltext nur die Kopier-Schicht. Eine reine Codeänderung baut also nur die letzte Schicht neu.
Verwechselt wird der Cache gern mit einem bloßen Zeitmesser. Er prüft keine Ähnlichkeit, sondern exakte Schlüssel. Steht COPY ganz oben, macht jede kleine Codeänderung die teure Installations-Schicht ungültig – und der Build dauert jedes Mal wie beim ersten Mal. Deshalb gilt: selten Geändertes wie das Basis-Image (das Image, auf dem das eigene aufbaut, etwa in der FROM-Anweisung) an den Anfang, häufig Geändertes wie den Quellcode an das Ende.
Der Build-Cache belohnt keine schönen Dockerfiles, sondern stabile Anweisungsreihen.
📌 Schichten · Cache-Schlüssel · Reihenfolge
📚 Cloud von Grund auf · Tag 5 von 30
#docker #devops #CloudHosting
15 Std vor
Die meisten Einsteiger halten die State-Datei für ein nebensächliches Nebenprodukt von Terraform. Wer sie löscht, verliert damit das Gedächtnis über die eigene Cloud.
Viele denken, Terraform finde die realen Ressourcen sowieso in der Cloud. Das klingt plausibel, denn Instanzen und Netzwerke sind sichtbar in der Konsole.
Tatsächlich vergleicht Terraform bei jedem Lauf drei Dinge: den Soll-Zustand aus den .tf-Dateien, den Ist-Zustand aus dem State und den realen Zustand in der Cloud. Der State ist Terraforms Gedächtnis; er speichert für jede Ressource, was beim letzten apply, dem Befehl, der Änderungen ausführt, existierte. Ohne ihn weiß Terraform nicht, welche echte Instanz zu welcher Konfigurationszeile gehört.
Der Irrtum entsteht, weil die Ressourcen nach dem Löschen der Datei weiterlaufen. Erst der nächste apply zeigt die Folge: Neue, doppelte Ressourcen entstehen.
In der Konfiguration steht eine EC2-Instanz namens web-server. Nach dem apply landet die Instanz-ID der erzeugten Cloud-Instanz im State. Genau diese ID erlaubt Terraform später, dieselbe Instanz zu aktualisieren, statt eine neue zu bauen.
Woran man es erkennt: terraform plan meldet plötzlich, dass Ressourcen neu erstellt werden sollen, obwohl die Konfiguration unverändert ist. Nach dem darauffolgenden apply zeigt die Konsole dann doppelte Instanzen.
In Teams gehört der State in ein Remote-Backend wie S3, also eine zentrale Ablage, auf die alle zugreifen; Locking über DynamoDB oder S3-Lock-Dateien verhindert gleichzeitige Änderungen. Der State kann Klartext-Passwörter enthalten und ist ein Geheimnis.
State heißt nicht nebensächliches Nebenprodukt, sondern das Gedächtnis, das Konfiguration und reale Ressourcen verbindet. Verlorener State bedeutet: Die Cloud bleibt bestehen, aber Terraform kann sie nicht mehr zuordnen.
📌 State-Datei · Remote-Backend · Locking
📚 Cloud von Grund auf · Tag 5 von 30
#Terraform #iac #aws
Viele denken, Terraform finde die realen Ressourcen sowieso in der Cloud. Das klingt plausibel, denn Instanzen und Netzwerke sind sichtbar in der Konsole.
Tatsächlich vergleicht Terraform bei jedem Lauf drei Dinge: den Soll-Zustand aus den .tf-Dateien, den Ist-Zustand aus dem State und den realen Zustand in der Cloud. Der State ist Terraforms Gedächtnis; er speichert für jede Ressource, was beim letzten apply, dem Befehl, der Änderungen ausführt, existierte. Ohne ihn weiß Terraform nicht, welche echte Instanz zu welcher Konfigurationszeile gehört.
Der Irrtum entsteht, weil die Ressourcen nach dem Löschen der Datei weiterlaufen. Erst der nächste apply zeigt die Folge: Neue, doppelte Ressourcen entstehen.
In der Konfiguration steht eine EC2-Instanz namens web-server. Nach dem apply landet die Instanz-ID der erzeugten Cloud-Instanz im State. Genau diese ID erlaubt Terraform später, dieselbe Instanz zu aktualisieren, statt eine neue zu bauen.
Woran man es erkennt: terraform plan meldet plötzlich, dass Ressourcen neu erstellt werden sollen, obwohl die Konfiguration unverändert ist. Nach dem darauffolgenden apply zeigt die Konsole dann doppelte Instanzen.
In Teams gehört der State in ein Remote-Backend wie S3, also eine zentrale Ablage, auf die alle zugreifen; Locking über DynamoDB oder S3-Lock-Dateien verhindert gleichzeitige Änderungen. Der State kann Klartext-Passwörter enthalten und ist ein Geheimnis.
State heißt nicht nebensächliches Nebenprodukt, sondern das Gedächtnis, das Konfiguration und reale Ressourcen verbindet. Verlorener State bedeutet: Die Cloud bleibt bestehen, aber Terraform kann sie nicht mehr zuordnen.
📌 State-Datei · Remote-Backend · Locking
📚 Cloud von Grund auf · Tag 5 von 30
#Terraform #iac #aws
18 Std vor
Zehn Sekunden Codeänderung, dann wartet man fünf Minuten auf denselben Build. Schuld ist meist eine einzige Zeile an der falschen Stelle im Dockerfile.
Gemeint ist der Aufbau eines Container-Images aus einer Beschreibungsdatei, dem Dockerfile. Das Image ist die unveränderliche Vorlage, aus der Container gestartet werden. Jede Anweisung darin – etwa COPY zum Kopieren von Dateien oder RUN zum Ausführen eines Befehls – erzeugt eine eigene Schicht, und der Build-Cache entscheidet, welche davon neu berechnet werden muss.
Zuerst liest das Build-Werkzeug das Dockerfile von oben nach unten und prüft jede Anweisung gegen den Cache. Sind Anweisungstext und Inhalt kopierter Dateien unverändert, wird die vorhandene Schicht wiederverwendet. Das Ergebnis ist sofort da, ohne Rechenarbeit.
Dann stößt das Werkzeug auf die erste geänderte Anweisung, etwa ein neues COPY mit anderem Quellcode. Diese Schicht wird neu gebaut. Der Cache-Schlüssel umfasst dabei beide Teile: Anweisungstext und Dateiinhalte.
Danach sind alle folgenden Schichten ungültig, auch wenn sie selbst gleich geblieben sind. Steht die teure Installation der Abhängigkeiten unterhalb des Quellcode-Kopierens, muss sie bei jeder Codeänderung erneut laufen – der Build dauert dann wieder so lange wie beim ersten Mal.
Zuletzt dreht man die Reihenfolge um: erst die Abhängigkeitsliste wie package.json kopieren und installieren, danach erst den Quellcode. Eine reine Codeänderung baut dann nur noch die letzte Schicht neu, aus Minuten werden Sekunden. Eine .dockerignore-Datei hält zudem unnötige Dateien aus dem Build-Kontext fern.
Der Cache ist kein Automatik-Glück, sondern folgt der Reihenfolge der Anweisungen. Seltenes nach oben, Häufiges nach unten: Diese eine Sortierung entscheidet über die Dauer jedes Neubaus.
📌 Schichten · Cache-Schlüssel · Reihenfolge
📚 Cloud von Grund auf · Tag 5 von 30
#docker #devops #CloudHosting
Gemeint ist der Aufbau eines Container-Images aus einer Beschreibungsdatei, dem Dockerfile. Das Image ist die unveränderliche Vorlage, aus der Container gestartet werden. Jede Anweisung darin – etwa COPY zum Kopieren von Dateien oder RUN zum Ausführen eines Befehls – erzeugt eine eigene Schicht, und der Build-Cache entscheidet, welche davon neu berechnet werden muss.
Zuerst liest das Build-Werkzeug das Dockerfile von oben nach unten und prüft jede Anweisung gegen den Cache. Sind Anweisungstext und Inhalt kopierter Dateien unverändert, wird die vorhandene Schicht wiederverwendet. Das Ergebnis ist sofort da, ohne Rechenarbeit.
Dann stößt das Werkzeug auf die erste geänderte Anweisung, etwa ein neues COPY mit anderem Quellcode. Diese Schicht wird neu gebaut. Der Cache-Schlüssel umfasst dabei beide Teile: Anweisungstext und Dateiinhalte.
Danach sind alle folgenden Schichten ungültig, auch wenn sie selbst gleich geblieben sind. Steht die teure Installation der Abhängigkeiten unterhalb des Quellcode-Kopierens, muss sie bei jeder Codeänderung erneut laufen – der Build dauert dann wieder so lange wie beim ersten Mal.
Zuletzt dreht man die Reihenfolge um: erst die Abhängigkeitsliste wie package.json kopieren und installieren, danach erst den Quellcode. Eine reine Codeänderung baut dann nur noch die letzte Schicht neu, aus Minuten werden Sekunden. Eine .dockerignore-Datei hält zudem unnötige Dateien aus dem Build-Kontext fern.
Der Cache ist kein Automatik-Glück, sondern folgt der Reihenfolge der Anweisungen. Seltenes nach oben, Häufiges nach unten: Diese eine Sortierung entscheidet über die Dauer jedes Neubaus.
📌 Schichten · Cache-Schlüssel · Reihenfolge
📚 Cloud von Grund auf · Tag 5 von 30
#docker #devops #CloudHosting
21 Std vor
Die Konfiguration beschreibt, was sein soll. Der State merkt sich, was bereits echt existiert.
Beide sind Dateien mit Ressourcen drin, deshalb hält man sie für dasselbe. Doch sie beantworten verschiedene Fragen: den Soll-Zustand und den Ist-Stand.
Die Konfiguration ist der Bauplan: In Terraform-Dateien steht in deklarativer Sprache, was entstehen soll, etwa eine Security-Group, also eine Firewall-Regelgruppe in AWS. Sie beschreibt Eigenschaften, aber keine konkreten Cloud-Objekte. Ein Beispiel: eine Regel, die einen Port für HTTPS freigibt. Terraform liest sie bei jedem Lauf neu ein.
Der State ist das Gedächtnis von Terraform: eine Datei, die für jede Ressource der Konfiguration festhält, welche echte Ressource in der Cloud dazugehört, etwa über deren konkrete ID. Steht dort eine Security-Group mit einer ID, kennt Terraform genau dieses Objekt. Fehlt der State, kann Terraform bestehende Ressourcen nicht mehr verwalten.
Die Konfiguration ist der Wunsch, der State die Zuordnung zur Wirklichkeit. Beim Plan vergleicht Terraform drei Dinge – Konfiguration, State und reale Ressourcen – und leitet daraus die Änderungen ab.
Faustregel: Wer Änderungen plant, braucht zuerst einen aktuellen State, sonst sind Plan und Wirklichkeit auseinander. Deshalb liegt der State zentral in einem Remote-Backend wie S3, einem Speicher, den alle Beteiligten gemeinsam nutzen.
Vorsicht: Der State kann Passwörter im Klartext enthalten und ist wie ein Geheimnis zu schützen. Löschen ist keine Aufräumlösung, sondern verwirft nur das Gedächtnis und erzeugt Duplikate.
Der State ist nicht die Konfiguration, sondern das Gedächtnis, das beide verbindet. Ohne ihn weiß Terraform nicht, was es selbst angelegt hat.
📌 Konfiguration · State · Remote-Backend
📚 Cloud von Grund auf · Tag 5 von 30
#Terraform #iac #devops #CloudSecurity
Beide sind Dateien mit Ressourcen drin, deshalb hält man sie für dasselbe. Doch sie beantworten verschiedene Fragen: den Soll-Zustand und den Ist-Stand.
Die Konfiguration ist der Bauplan: In Terraform-Dateien steht in deklarativer Sprache, was entstehen soll, etwa eine Security-Group, also eine Firewall-Regelgruppe in AWS. Sie beschreibt Eigenschaften, aber keine konkreten Cloud-Objekte. Ein Beispiel: eine Regel, die einen Port für HTTPS freigibt. Terraform liest sie bei jedem Lauf neu ein.
Der State ist das Gedächtnis von Terraform: eine Datei, die für jede Ressource der Konfiguration festhält, welche echte Ressource in der Cloud dazugehört, etwa über deren konkrete ID. Steht dort eine Security-Group mit einer ID, kennt Terraform genau dieses Objekt. Fehlt der State, kann Terraform bestehende Ressourcen nicht mehr verwalten.
Die Konfiguration ist der Wunsch, der State die Zuordnung zur Wirklichkeit. Beim Plan vergleicht Terraform drei Dinge – Konfiguration, State und reale Ressourcen – und leitet daraus die Änderungen ab.
Faustregel: Wer Änderungen plant, braucht zuerst einen aktuellen State, sonst sind Plan und Wirklichkeit auseinander. Deshalb liegt der State zentral in einem Remote-Backend wie S3, einem Speicher, den alle Beteiligten gemeinsam nutzen.
Vorsicht: Der State kann Passwörter im Klartext enthalten und ist wie ein Geheimnis zu schützen. Löschen ist keine Aufräumlösung, sondern verwirft nur das Gedächtnis und erzeugt Duplikate.
Der State ist nicht die Konfiguration, sondern das Gedächtnis, das beide verbindet. Ohne ihn weiß Terraform nicht, was es selbst angelegt hat.
📌 Konfiguration · State · Remote-Backend
📚 Cloud von Grund auf · Tag 5 von 30
#Terraform #iac #devops #CloudSecurity
1 Tag vor
Terraform funktioniert wie ein Stadtplaner mit einem Grundbuch. Ohne das Grundbuch wüsste er nicht, welche Grundstücke ihm überhaupt gehören.
Das Grundbuch verzeichnet jedes Grundstück mit Nummer, Besitzer und aktuellem Zustand. Will der Planer ein Haus umbauen, schlägt er erst nach: Ist das Grundstück bereits eingetragen? Ist der Zustand dort noch aktuell? Erst dann entscheidet er, ob gebaut, umgebaut oder abgerissen wird.
Bei Terraform heißt das Grundbuch State: eine Datei mit der Zuordnung zwischen dem Namen in der Konfiguration, also den Textdateien, die Infrastruktur beschreiben, und der realen Ressource in der Cloud. Bei jedem terraform plan oder terraform apply vergleicht Terraform drei Dinge: den gewünschten Zustand, den gespeicherten Ist-Zustand und die echte Cloud. Aus der Differenz ergibt sich, was erstellt, geändert oder gelöscht wird.
Konkret: In der Konfiguration steht eine EC2-Instanz (virtuelle Maschine bei AWS) mit dem Namen webserver. Im State liegt dazu die ID der realen Instanz, etwa i-abc123. Nur über diese Zuordnung findet Terraform die Instanz wieder, wenn sie verkleinert oder gelöscht werden soll. Löscht jemand die Instanz in der Konsole, meldet terraform plan die Abweichung und schlägt vor, sie neu zu erstellen.
Das Bild hat eine Grenze: Ein Grundbuch kann von Hand weitergeschrieben werden, der State nicht. Jede manuelle Änderung zerstört die Zuordnung. Deshalb gilt in der Praxis: State im verschlüsselten Backend (zentraler Ablageort) speichern, Zugriff strikt begrenzen.
Der State ist Terraforms Gedächtnis, kein Protokoll. Er wird geschützt, geteilt und nie von Hand editiert.
📌 State · Backend · Zuordnung
📚 Cloud von Grund auf · Tag 5 von 30
#Terraform #iac #CloudSecurity
Das Grundbuch verzeichnet jedes Grundstück mit Nummer, Besitzer und aktuellem Zustand. Will der Planer ein Haus umbauen, schlägt er erst nach: Ist das Grundstück bereits eingetragen? Ist der Zustand dort noch aktuell? Erst dann entscheidet er, ob gebaut, umgebaut oder abgerissen wird.
Bei Terraform heißt das Grundbuch State: eine Datei mit der Zuordnung zwischen dem Namen in der Konfiguration, also den Textdateien, die Infrastruktur beschreiben, und der realen Ressource in der Cloud. Bei jedem terraform plan oder terraform apply vergleicht Terraform drei Dinge: den gewünschten Zustand, den gespeicherten Ist-Zustand und die echte Cloud. Aus der Differenz ergibt sich, was erstellt, geändert oder gelöscht wird.
Konkret: In der Konfiguration steht eine EC2-Instanz (virtuelle Maschine bei AWS) mit dem Namen webserver. Im State liegt dazu die ID der realen Instanz, etwa i-abc123. Nur über diese Zuordnung findet Terraform die Instanz wieder, wenn sie verkleinert oder gelöscht werden soll. Löscht jemand die Instanz in der Konsole, meldet terraform plan die Abweichung und schlägt vor, sie neu zu erstellen.
Das Bild hat eine Grenze: Ein Grundbuch kann von Hand weitergeschrieben werden, der State nicht. Jede manuelle Änderung zerstört die Zuordnung. Deshalb gilt in der Praxis: State im verschlüsselten Backend (zentraler Ablageort) speichern, Zugriff strikt begrenzen.
Der State ist Terraforms Gedächtnis, kein Protokoll. Er wird geschützt, geteilt und nie von Hand editiert.
📌 State · Backend · Zuordnung
📚 Cloud von Grund auf · Tag 5 von 30
#Terraform #iac #CloudSecurity
1 Tag vor
Viele Einsteiger warten bei jeder kleinen Codeänderung erneut auf die komplette Paketinstallation. Dabei reicht eine andere Reihenfolge der Befehle, damit fast alles aus dem Cache kommt.
Nach dem Ändern einer einzigen Quellcodezeile läuft der komplette Build von vorn. Pakete werden wieder heruntergeladen, obwohl sie schon im vorherigen Build steckten.
Ein Dockerfile ist eine Schritt-für-Schritt-Anleitung, wie ein Image gebaut wird. Jeder Befehl erzeugt eine Schicht, also einen festen Layer im Image. Docker nutzt einen Build-Cache: Eine Schicht wird nur neu gebaut, wenn sich ihr Befehl oder die hineinkopierten Dateien geändert haben. Der Cache wird von oben nach unten geprüft – ab der ersten veränderten Schicht muss alles Folgende neu gebaut werden, auch wenn die Befehle gleich bleiben.
Ein typisches Dockerfile beginnt mit COPY des kompletten Quellcodes und installiert danach erst die Pakete mit RUN apt-get install. Jede noch so kleine Codeänderung trifft die erste Schicht und invalidiert alle folgenden. Die Paketinstallation läuft bei jedem Build erneut. Dreht man die Reihenfolge um – erst Pakete installieren, dann den Code kopieren – bleibt die teure Installation im Cache, wenn nur eine Codezeile geändert wird.
So prüft man es: Beim zweiten Build ohne Änderungen sollte Docker jeden Schritt aus dem Cache beantworten. Nach einer Codezeilen-Änderung dürfen nur die Schichten ab dem COPY neu laufen.
Erst das Seltene, dann das Häufige gehört ins Dockerfile. Häufig Geändertes gehört ans Ende des Dockerfiles, nicht an den Anfang.
📌 Build-Cache · Schichten · Befehlsreihenfolge
📚 Cloud von Grund auf · Tag 5 von 30
#docker #devops #CloudHosting
Nach dem Ändern einer einzigen Quellcodezeile läuft der komplette Build von vorn. Pakete werden wieder heruntergeladen, obwohl sie schon im vorherigen Build steckten.
Ein Dockerfile ist eine Schritt-für-Schritt-Anleitung, wie ein Image gebaut wird. Jeder Befehl erzeugt eine Schicht, also einen festen Layer im Image. Docker nutzt einen Build-Cache: Eine Schicht wird nur neu gebaut, wenn sich ihr Befehl oder die hineinkopierten Dateien geändert haben. Der Cache wird von oben nach unten geprüft – ab der ersten veränderten Schicht muss alles Folgende neu gebaut werden, auch wenn die Befehle gleich bleiben.
Ein typisches Dockerfile beginnt mit COPY des kompletten Quellcodes und installiert danach erst die Pakete mit RUN apt-get install. Jede noch so kleine Codeänderung trifft die erste Schicht und invalidiert alle folgenden. Die Paketinstallation läuft bei jedem Build erneut. Dreht man die Reihenfolge um – erst Pakete installieren, dann den Code kopieren – bleibt die teure Installation im Cache, wenn nur eine Codezeile geändert wird.
So prüft man es: Beim zweiten Build ohne Änderungen sollte Docker jeden Schritt aus dem Cache beantworten. Nach einer Codezeilen-Änderung dürfen nur die Schichten ab dem COPY neu laufen.
Erst das Seltene, dann das Häufige gehört ins Dockerfile. Häufig Geändertes gehört ans Ende des Dockerfiles, nicht an den Anfang.
📌 Build-Cache · Schichten · Befehlsreihenfolge
📚 Cloud von Grund auf · Tag 5 von 30
#docker #devops #CloudHosting
1 Tag vor
Ein Docker-Image ist die Vorlage, aus der Container gestartet werden; ein rasanter Neubau wirkt wie Magie. In Wahrheit ist es nur der Zwischenspeicher, der unveränderte Schichten wiederverwendet.
Wer sein erstes Dockerfile, die Schritt-für-Schritt-Bauanleitung für ein Image, schreibt, baut oft von Grund auf neu und staunt über die Wartezeit. Das kostet in jeder Continuous-Integration-Pipeline, die jede Codeänderung automatisch baut und testet, unnötig Zeit.
Ein Layer ist eine Schicht, ein Zwischenstand des Dateisystems, den Docker beim Bauen einzeln speichert. Jede Dockerfile-Anweisung wie RUN, COPY oder ADD erzeugt eine eigene Schicht; ein Dockerfile beschreibt Schritt für Schritt, wie das Image gebaut wird. Trifft der Zwischenspeicher auf eine bekannte Schicht, wird sie nicht neu gebaut, sondern direkt verwendet.
Weil jede Schicht auf dem Ergebnis der vorherigen aufbaut, gilt: Sobald eine Schicht geändert wurde, werden diese und alle folgenden Schichten neu gebaut. Beim COPY-Schritt entscheidet dabei allein der Inhalt der kopierten Dateien über den Treffer, nicht der Name des Schritts. Ein Dockerfile beginnt daher mit dem selten geänderten RUN-Schritt zum Installieren der Pakete, denn das ändert sich selten. Der eigene Quellcode mit COPY zu kopieren gehört ans Ende: Weil sich Code bei jedem Commit ändert, machen früh kopierte Dateien alle späteren Schichten ungültig. Der Zwischenspeicher nützt dann nichts.
Verwechselt wird der Layer mit dem fertigen Image, der unveränderlichen Vorlage für Container. Das Image besteht aus der gesamten Kette dieser Schichten; der Layer ist ein einzelner Baustein davon.
Der Bau ist nicht jedes Mal ein Neuanfang, sondern ein Abgleich von Schichten. Genau deshalb steht der Quellcode im Dockerfile ganz am Ende.
📌 Layer · COPY · Pipeline
📚 Cloud von Grund auf · Tag 5 von 30
#docker #iac #devops
Wer sein erstes Dockerfile, die Schritt-für-Schritt-Bauanleitung für ein Image, schreibt, baut oft von Grund auf neu und staunt über die Wartezeit. Das kostet in jeder Continuous-Integration-Pipeline, die jede Codeänderung automatisch baut und testet, unnötig Zeit.
Ein Layer ist eine Schicht, ein Zwischenstand des Dateisystems, den Docker beim Bauen einzeln speichert. Jede Dockerfile-Anweisung wie RUN, COPY oder ADD erzeugt eine eigene Schicht; ein Dockerfile beschreibt Schritt für Schritt, wie das Image gebaut wird. Trifft der Zwischenspeicher auf eine bekannte Schicht, wird sie nicht neu gebaut, sondern direkt verwendet.
Weil jede Schicht auf dem Ergebnis der vorherigen aufbaut, gilt: Sobald eine Schicht geändert wurde, werden diese und alle folgenden Schichten neu gebaut. Beim COPY-Schritt entscheidet dabei allein der Inhalt der kopierten Dateien über den Treffer, nicht der Name des Schritts. Ein Dockerfile beginnt daher mit dem selten geänderten RUN-Schritt zum Installieren der Pakete, denn das ändert sich selten. Der eigene Quellcode mit COPY zu kopieren gehört ans Ende: Weil sich Code bei jedem Commit ändert, machen früh kopierte Dateien alle späteren Schichten ungültig. Der Zwischenspeicher nützt dann nichts.
Verwechselt wird der Layer mit dem fertigen Image, der unveränderlichen Vorlage für Container. Das Image besteht aus der gesamten Kette dieser Schichten; der Layer ist ein einzelner Baustein davon.
Der Bau ist nicht jedes Mal ein Neuanfang, sondern ein Abgleich von Schichten. Genau deshalb steht der Quellcode im Dockerfile ganz am Ende.
📌 Layer · COPY · Pipeline
📚 Cloud von Grund auf · Tag 5 von 30
#docker #iac #devops
1 Tag vor
Viele geben beiden Sonden denselben Endpunkt und glauben, gut gerüstet zu sein. Dabei verursacht genau das die Neustartschleifen, die eine Anwendung in den Ausfall treiben.
Viele denken, Kubernetes brauche eine einzige Gesundheitsprüfung, denn gesund ist gesund. Plausibel klingt das, weil beide Sonden denselben HTTP-Aufruf machen, etwa GET /healthz mit Antwortcode 200 bis 399 als Erfolg.
Tatsächlich stellen die Sonden zwei verschiedene Fragen. Die Liveness-Probe (Lebenssonde) prüft, ob der Container überhaupt noch funktionsfähig ist oder durch einen Neustart repariert werden kann. Die Readiness-Probe (Bereitschaftsonde) prüft, ob er gerade Verkehr annehmen darf. Schlägt Readiness fehl, nimmt der Kubelet – der Agent auf jedem Knoten, der Container startet und überwacht – den Pod (die kleinste Einheit in Kubernetes) aus den Endpoints des Service; der Container läuft weiter, es kommt nur kein Verkehr mehr an.
Der Irrtum entsteht, weil beide Prüfungen technisch identisch aussehen. Was fehlt, ist die Frage nach der Folge: Neustart oder Pause.
Eine Anwendung lädt beim Start große Datenmengen und antwortet noch nicht. Wer hier Liveness mit Readiness gleichschaltet, startet den Container neu, obwohl er nur Zeit bräuchte. Noch schlimmer: Eine Liveness-Probe, die die externe Datenbank mitprüft, löst bei deren Ausfall eine Neustartschleife aus, die nichts behebt. Abhängigkeiten gehören deshalb in die Readiness-Probe.
Woran man es erkennt: Mit den Standardwerten gilt ein Container nach drei aufeinanderfolgenden Fehlversuchen im Abstand von zehn Sekunden als nicht gesund. Wer Container im Kreis drehen sieht, obwohl sie nur langsam starten, hat Liveness zu scharf gestellt.
Liveness heißt nicht „alles prüfen, was wichtig ist“, sondern „nur prüfen, was ein Neustart reparieren kann“.
📌 Liveness vs. Readiness · Kubelet · failureThreshold 3
📚 Cloud von Grund auf · Tag 4 von 30
#kubernetes #devops #sre
Viele denken, Kubernetes brauche eine einzige Gesundheitsprüfung, denn gesund ist gesund. Plausibel klingt das, weil beide Sonden denselben HTTP-Aufruf machen, etwa GET /healthz mit Antwortcode 200 bis 399 als Erfolg.
Tatsächlich stellen die Sonden zwei verschiedene Fragen. Die Liveness-Probe (Lebenssonde) prüft, ob der Container überhaupt noch funktionsfähig ist oder durch einen Neustart repariert werden kann. Die Readiness-Probe (Bereitschaftsonde) prüft, ob er gerade Verkehr annehmen darf. Schlägt Readiness fehl, nimmt der Kubelet – der Agent auf jedem Knoten, der Container startet und überwacht – den Pod (die kleinste Einheit in Kubernetes) aus den Endpoints des Service; der Container läuft weiter, es kommt nur kein Verkehr mehr an.
Der Irrtum entsteht, weil beide Prüfungen technisch identisch aussehen. Was fehlt, ist die Frage nach der Folge: Neustart oder Pause.
Eine Anwendung lädt beim Start große Datenmengen und antwortet noch nicht. Wer hier Liveness mit Readiness gleichschaltet, startet den Container neu, obwohl er nur Zeit bräuchte. Noch schlimmer: Eine Liveness-Probe, die die externe Datenbank mitprüft, löst bei deren Ausfall eine Neustartschleife aus, die nichts behebt. Abhängigkeiten gehören deshalb in die Readiness-Probe.
Woran man es erkennt: Mit den Standardwerten gilt ein Container nach drei aufeinanderfolgenden Fehlversuchen im Abstand von zehn Sekunden als nicht gesund. Wer Container im Kreis drehen sieht, obwohl sie nur langsam starten, hat Liveness zu scharf gestellt.
Liveness heißt nicht „alles prüfen, was wichtig ist“, sondern „nur prüfen, was ein Neustart reparieren kann“.
📌 Liveness vs. Readiness · Kubelet · failureThreshold 3
📚 Cloud von Grund auf · Tag 4 von 30
#kubernetes #devops #sre
2 Tage vor
Ein Container läuft nicht einfach irgendwie – er bekommt Ressourcen zugesichert und begrenzt. Wer beides verwechselt, wundert sich später über abrupte Neustarts.
In Kubernetes wird beim Start jedes Containers festgelegt, wie viel CPU und Speicher ihm garantiert und wie viel er höchstens verbrauchen darf. Das betrifft jede Web-Anwendung, jeden Job, jeden Dienst im Cluster – einem Cluster, einer Gruppe von Rechnern, die Container gemeinsam betreiben.
Zuerst definiert man die Requests: die Mengen an CPU und Speicher, die der Scheduler, die Komponente, die Container auf Knoten verteilt, fest einplant und garantiert. CPU misst man in Millicores: 1000m sind ein voller Kern, 500m die Hälfte. Speicher steht in Bytes, etwa mit dem Suffix Mi für Mebibyte.
Dann prüft der Scheduler anhand der Requests, ob ein Knoten noch Platz hat. Er kennt die Limits bei der Platzierung nicht. Fehlen Requests, bucht er Knoten über, weil er den Bedarf nicht kennt – Engpässe treten dann erst zur Laufzeit auf.
Danach läuft der Container und darf über seinen Request hinaus wachsen, solange Ressourcen frei sind. Ein Beispiel: Request 100m CPU und 128Mi Speicher, Limit 500m und 256Mi. Kurzzeitig darf er also auf das Fünffache der zugesicherten CPU wachsen.
Zuletzt greifen die Limits zur Laufzeit. Überschreitet der Container sein Speicher-Limit, beendet ihn der Kernel sofort per OOM-Kill und Kubernetes startet ihn neu. Am CPU-Limit wird er nicht beendet, sondern gedrosselt: Er läuft langsamer, arbeitet aber weiter. Pods ganz ohne Werte erhalten die Klasse BestEffort und werden bei Speicherknappheit zuerst verdrängt.
Requests sind das Versprechen an den Scheduler, Limits die Grenze im Betrieb. Wer Limits als Requests deutet, plant Knoten falsch voll; wer beides weglässt, überlässt die Verteilung dem Zufall.
📌 Request · Limit · OOM-Kill
📚 Cloud von Grund auf · Tag 4 von 30
#kubernetes #devops #CloudHosting
In Kubernetes wird beim Start jedes Containers festgelegt, wie viel CPU und Speicher ihm garantiert und wie viel er höchstens verbrauchen darf. Das betrifft jede Web-Anwendung, jeden Job, jeden Dienst im Cluster – einem Cluster, einer Gruppe von Rechnern, die Container gemeinsam betreiben.
Zuerst definiert man die Requests: die Mengen an CPU und Speicher, die der Scheduler, die Komponente, die Container auf Knoten verteilt, fest einplant und garantiert. CPU misst man in Millicores: 1000m sind ein voller Kern, 500m die Hälfte. Speicher steht in Bytes, etwa mit dem Suffix Mi für Mebibyte.
Dann prüft der Scheduler anhand der Requests, ob ein Knoten noch Platz hat. Er kennt die Limits bei der Platzierung nicht. Fehlen Requests, bucht er Knoten über, weil er den Bedarf nicht kennt – Engpässe treten dann erst zur Laufzeit auf.
Danach läuft der Container und darf über seinen Request hinaus wachsen, solange Ressourcen frei sind. Ein Beispiel: Request 100m CPU und 128Mi Speicher, Limit 500m und 256Mi. Kurzzeitig darf er also auf das Fünffache der zugesicherten CPU wachsen.
Zuletzt greifen die Limits zur Laufzeit. Überschreitet der Container sein Speicher-Limit, beendet ihn der Kernel sofort per OOM-Kill und Kubernetes startet ihn neu. Am CPU-Limit wird er nicht beendet, sondern gedrosselt: Er läuft langsamer, arbeitet aber weiter. Pods ganz ohne Werte erhalten die Klasse BestEffort und werden bei Speicherknappheit zuerst verdrängt.
Requests sind das Versprechen an den Scheduler, Limits die Grenze im Betrieb. Wer Limits als Requests deutet, plant Knoten falsch voll; wer beides weglässt, überlässt die Verteilung dem Zufall.
📌 Request · Limit · OOM-Kill
📚 Cloud von Grund auf · Tag 4 von 30
#kubernetes #devops #CloudHosting
2 Tage vor
Pods und Services klingen ähnlich, gehören aber zu verschiedenen Welten. Der eine ist ein Arbeiter, der kommt und geht – der andere ist das Schild am Gebäude.
Verwechselt werden beide, weil sie im Alltag zusammen auftreten. Immer wenn eine Anwendung Pods startet, steht ein Service davor.
Ein Pod ist die kleinste Einheit in Kubernetes und enthält einen oder mehrere Container, die sich Netzwerk und Speicher teilen. Ein Deployment hält eine gewünschte Anzahl gleicher Pods am Laufen. Pods sind bewusst kurzlebig: Bei jedem Update, bei Knotenausfall oder Neustart ersetzt Kubernetes alte Pods durch neue – und jeder neue Pod erhält eine neue Cluster-IP. Ein Webshop-Deployment verwaltet etwa drei Pods, von denen jeder Neustart mit einer frischen IP startet.
Ein Service ist dagegen eine feste Adresse für diese wechselnde Gruppe. Er besitzt eine eigene IP-Adresse und einen DNS-Namen (DNS übersetzt Namen in IP-Adressen) innerhalb des Clusters, die sich nicht ändern, solange der Service existiert. Der Service wählt seine Pods über ein Label-Selektor-Kriterium aus: Alle Pods mit einem bestimmten Label gehören zur Gruppe. Der Service „frontend“ verteilt alle Aufrufe von „frontend“ immer auf einen der gerade laufenden Pods – egal, wer gerade neu gestartet wurde.
Der Pod liefert die Arbeit, der Service liefert die Erreichbarkeit. Pod-IPs bleiben hinter dem Service verborgen; fällt ein Pod aus, wandern seine Anfragen automatisch zu den verbleibenden.
Faustregel: Pods nie direkt adressieren, sondern immer über den Service – eine Pod-IP in einer Konfiguration ist nach dem nächsten Neustart unbrauchbar.
Der Service heißt nicht Lastverteiler für Container, sondern feste Anlaufstelle vor kurzlebigen Pods.
📌 Pod · Service · Label-Selektor
📚 Cloud von Grund auf · Tag 4 von 30
#kubernetes #CloudHosting #devops
Verwechselt werden beide, weil sie im Alltag zusammen auftreten. Immer wenn eine Anwendung Pods startet, steht ein Service davor.
Ein Pod ist die kleinste Einheit in Kubernetes und enthält einen oder mehrere Container, die sich Netzwerk und Speicher teilen. Ein Deployment hält eine gewünschte Anzahl gleicher Pods am Laufen. Pods sind bewusst kurzlebig: Bei jedem Update, bei Knotenausfall oder Neustart ersetzt Kubernetes alte Pods durch neue – und jeder neue Pod erhält eine neue Cluster-IP. Ein Webshop-Deployment verwaltet etwa drei Pods, von denen jeder Neustart mit einer frischen IP startet.
Ein Service ist dagegen eine feste Adresse für diese wechselnde Gruppe. Er besitzt eine eigene IP-Adresse und einen DNS-Namen (DNS übersetzt Namen in IP-Adressen) innerhalb des Clusters, die sich nicht ändern, solange der Service existiert. Der Service wählt seine Pods über ein Label-Selektor-Kriterium aus: Alle Pods mit einem bestimmten Label gehören zur Gruppe. Der Service „frontend“ verteilt alle Aufrufe von „frontend“ immer auf einen der gerade laufenden Pods – egal, wer gerade neu gestartet wurde.
Der Pod liefert die Arbeit, der Service liefert die Erreichbarkeit. Pod-IPs bleiben hinter dem Service verborgen; fällt ein Pod aus, wandern seine Anfragen automatisch zu den verbleibenden.
Faustregel: Pods nie direkt adressieren, sondern immer über den Service – eine Pod-IP in einer Konfiguration ist nach dem nächsten Neustart unbrauchbar.
Der Service heißt nicht Lastverteiler für Container, sondern feste Anlaufstelle vor kurzlebigen Pods.
📌 Pod · Service · Label-Selektor
📚 Cloud von Grund auf · Tag 4 von 30
#kubernetes #CloudHosting #devops
2 Tage vor
Ein Deployment funktioniert wie ein Vorarbeiter, der eine Personalplanung im Kopf hat. Er weiß, wie viele Leute arbeiten sollen, und meldet sofort, wenn jemand fehlt.
Der Vorarbeiter hat einen Plan: Drei Arbeiter an einer Station. Kommt einer nicht, schickt er einen Ersatz. Der Ersatz übernimmt dieselbe Aufgabe, ohne dass jemand nachfragen muss. Der Vorarbeiter prüft dabei nicht die Stimmung oder die Leistung. Er zählt nur: Sind noch drei da? Solange die Zahl stimmt, greift er nicht ein.
In Kubernetes ist der Vorarbeiter das Deployment, eine Verwaltungseinheit für gleichartige Pods. Der Pod ist die kleinste betreibbare Einheit und umhüllt einen oder mehrere Container, also Anwendungen samt Abhängigkeiten. Der Plan steckt im Feld replicas: Dort steht die Soll-Stärke, etwa die Zahl drei. Fällt ein Pod aus, startet das Deployment automatisch einen neuen. Kubernetes verteilt die Pods dabei auf die Knoten, die Arbeitsrechner des Clusters.
Ein Deployment für eine Webanwendung mit replicas: 3 erzeugt drei gleiche Pods. Stürzt einer ab, läuft die Zahl ohne Eingriff auf drei zurück. Die Container eines Pods teilen sich eine IP-Adresse und reden über localhost miteinander.
Das Bild hat eine Grenze: Ein Arbeiter bleibt derselbe Mensch, ein ersetzter Pod ist eine neue Instanz mit neuer IP-Adresse. Der Vorarbeiter delegiert auch aktiv, das Deployment vergleicht nur Ist und Soll. Stabile Adressen für Anfragen liefert deshalb ein Kubernetes-Service.
Pods also nie von Hand starten: Wer replicas selbst überwacht, ersetzt keine ausgefallenen Pods. Deployment heißt nicht Pod, sondern Soll-Stärke, die Kubernetes von selbst hält.
📌 Pod · Deployment · replicas
📚 Cloud von Grund auf · Tag 4 von 30
#kubernetes #devops #docker
Der Vorarbeiter hat einen Plan: Drei Arbeiter an einer Station. Kommt einer nicht, schickt er einen Ersatz. Der Ersatz übernimmt dieselbe Aufgabe, ohne dass jemand nachfragen muss. Der Vorarbeiter prüft dabei nicht die Stimmung oder die Leistung. Er zählt nur: Sind noch drei da? Solange die Zahl stimmt, greift er nicht ein.
In Kubernetes ist der Vorarbeiter das Deployment, eine Verwaltungseinheit für gleichartige Pods. Der Pod ist die kleinste betreibbare Einheit und umhüllt einen oder mehrere Container, also Anwendungen samt Abhängigkeiten. Der Plan steckt im Feld replicas: Dort steht die Soll-Stärke, etwa die Zahl drei. Fällt ein Pod aus, startet das Deployment automatisch einen neuen. Kubernetes verteilt die Pods dabei auf die Knoten, die Arbeitsrechner des Clusters.
Ein Deployment für eine Webanwendung mit replicas: 3 erzeugt drei gleiche Pods. Stürzt einer ab, läuft die Zahl ohne Eingriff auf drei zurück. Die Container eines Pods teilen sich eine IP-Adresse und reden über localhost miteinander.
Das Bild hat eine Grenze: Ein Arbeiter bleibt derselbe Mensch, ein ersetzter Pod ist eine neue Instanz mit neuer IP-Adresse. Der Vorarbeiter delegiert auch aktiv, das Deployment vergleicht nur Ist und Soll. Stabile Adressen für Anfragen liefert deshalb ein Kubernetes-Service.
Pods also nie von Hand starten: Wer replicas selbst überwacht, ersetzt keine ausgefallenen Pods. Deployment heißt nicht Pod, sondern Soll-Stärke, die Kubernetes von selbst hält.
📌 Pod · Deployment · replicas
📚 Cloud von Grund auf · Tag 4 von 30
#kubernetes #devops #docker
2 Tage vor
Die meisten Neulinge wundern sich, warum ein kleiner Code-Fix den kompletten Docker-Build neu auslöst. Dabei entscheidet oft nur die Reihenfolge der Zeilen im Dockerfile über Sekunden oder Minuten Bauzeit.
Das Symptom: Nach jeder noch so kleinen Codeänderung läuft der Bau minutenlang durch. Pakete werden erneut installiert, obwohl sich daran nichts geändert hat. Der Build-Cache, also das Zwischenspeichern bereits gebauter Schritte, greift scheinbar nie.
Dahinter steckt das Schichtprinzip: Jede Zeile im Dockerfile (der Bauanleitung für ein Image) erzeugt eine eigene Schicht. Das fertige Image, also die unveränderliche Vorlage für Container, besteht aus diesen Schichten wie ein Stapel. Eine unveränderte Schicht wird aus dem Cache wiederverwendet. Ändert sich eine Zeile, wird sie neu gebaut, und alle folgenden ebenso, weil sie auf dem Ergebnis aufbauen. Steht COPY, das Kopieren eigener Dateien, früh im Dockerfile, macht jede Codeänderung den Rest ungültig.
Konkret: Ein Dockerfile beginnt mit FROM, dann RUN zum Installieren der Abhängigkeiten, dann erst COPY des Quellcodes. Wer umgekehrt erst den Code kopiert und danach RUN ausführt, baut die Abhängigkeiten bei jedem Fix neu. Die Regel lautet: Anweisungen mit selten ändernden Inhalten wie RUN an den Anfang, Anweisungen mit häufig ändernden Inhalten wie COPY ans Ende.
So prüft man es: Beim Bau die Ausgabe der Zeilen ansehen, die als wiederverwendet markiert sind. Zeigen die frühen Zeilen wie die Abhängigkeiten einen Treffer und startet der Neubau erst beim Kopieren des Quellcodes, stimmt die Anordnung.
Schichten sind keine Zufallsprodukte, sondern ein Stapel: Ein früher Treffer im Cache spart alles darunter. Ordnung im Dockerfile heißt Reihenfolge nach Änderungshäufigkeit.
📌 Dockerfile-Schichten · Build-Cache · Reihenfolge nach Änderungshäufigkeit
📚 Cloud von Grund auf · Tag 4 von 30
#docker #kubernetes #devops
Das Symptom: Nach jeder noch so kleinen Codeänderung läuft der Bau minutenlang durch. Pakete werden erneut installiert, obwohl sich daran nichts geändert hat. Der Build-Cache, also das Zwischenspeichern bereits gebauter Schritte, greift scheinbar nie.
Dahinter steckt das Schichtprinzip: Jede Zeile im Dockerfile (der Bauanleitung für ein Image) erzeugt eine eigene Schicht. Das fertige Image, also die unveränderliche Vorlage für Container, besteht aus diesen Schichten wie ein Stapel. Eine unveränderte Schicht wird aus dem Cache wiederverwendet. Ändert sich eine Zeile, wird sie neu gebaut, und alle folgenden ebenso, weil sie auf dem Ergebnis aufbauen. Steht COPY, das Kopieren eigener Dateien, früh im Dockerfile, macht jede Codeänderung den Rest ungültig.
Konkret: Ein Dockerfile beginnt mit FROM, dann RUN zum Installieren der Abhängigkeiten, dann erst COPY des Quellcodes. Wer umgekehrt erst den Code kopiert und danach RUN ausführt, baut die Abhängigkeiten bei jedem Fix neu. Die Regel lautet: Anweisungen mit selten ändernden Inhalten wie RUN an den Anfang, Anweisungen mit häufig ändernden Inhalten wie COPY ans Ende.
So prüft man es: Beim Bau die Ausgabe der Zeilen ansehen, die als wiederverwendet markiert sind. Zeigen die frühen Zeilen wie die Abhängigkeiten einen Treffer und startet der Neubau erst beim Kopieren des Quellcodes, stimmt die Anordnung.
Schichten sind keine Zufallsprodukte, sondern ein Stapel: Ein früher Treffer im Cache spart alles darunter. Ordnung im Dockerfile heißt Reihenfolge nach Änderungshäufigkeit.
📌 Dockerfile-Schichten · Build-Cache · Reihenfolge nach Änderungshäufigkeit
📚 Cloud von Grund auf · Tag 4 von 30
#docker #kubernetes #devops
2 Tage vor
Die meisten Docker-Neulinge wundern sich, warum jeder Build Minuten dauert. Dabei entscheidet oft weniger die Größe des Projekts über die Bauzeit, sondern die Reihenfolge der Zeilen im Dockerfile.
Ein Dockerfile ist eine Textdatei mit Anweisungen wie FROM, COPY und RUN, aus denen docker build ein Image erzeugt – eine portable, gepackte Umgebung für eine Anwendung. Wer die Schichten versteht, baut deutlich schneller.
📦 Jede Dockerfile-Anweisung erzeugt ihre eigene Schicht.
Eine Schicht (Layer) ist das Dateisystem-Änderungsprotokoll genau einer Anweisung; das fertige Image entsteht als Stapel dieser Schichten übereinander. Die Anweisungen werden von oben nach unten abgearbeitet. Beispiel: erst FROM, dann COPY der Paketliste, dann RUN zur Installation der Abhängigkeiten, erst danach COPY des Quellcodes.
🔑 Der Build-Cache prüft jede Anweisung von oben nach unten.
Der Build-Cache ist ein Zwischenspeicher früherer Schichten; Docker vergleicht Anweisung und Eingaben mit der gecachten Version. Ist eine Schicht unverändert, wird sie samt aller darunterliegenden wiederverwendet. Ab der ersten geänderten Anweisung wird alles Folgende neu gebaut.
📈 Häufig Geändertes gehört ans Ende des Dockerfiles.
Klassischer Einsteigerirrtum: Quellcode früh per COPY übernehmen. Dann läuft bei jeder Codeänderung auch die teure Abhängigkeitsinstallation erneut, obwohl sich nichts daran geändert hat. Steht die COPY-Zeile für den Code dagegen ganz unten, bleibt der Cache für die Installation intakt.
Die Reihenfolge heißt nicht Geschmackssache, sondern Cache-Strategie: selten Geändertes zuerst, häufig Geändertes zuletzt – Basis-Image und Abhängigkeiten vor dem eigenen Quellcode.
📌 Schichten · Build-Cache · Anweisungsreihenfolge
📚 Cloud von Grund auf · Tag 4 von 30
#docker #devops #CloudHosting
Ein Dockerfile ist eine Textdatei mit Anweisungen wie FROM, COPY und RUN, aus denen docker build ein Image erzeugt – eine portable, gepackte Umgebung für eine Anwendung. Wer die Schichten versteht, baut deutlich schneller.
📦 Jede Dockerfile-Anweisung erzeugt ihre eigene Schicht.
Eine Schicht (Layer) ist das Dateisystem-Änderungsprotokoll genau einer Anweisung; das fertige Image entsteht als Stapel dieser Schichten übereinander. Die Anweisungen werden von oben nach unten abgearbeitet. Beispiel: erst FROM, dann COPY der Paketliste, dann RUN zur Installation der Abhängigkeiten, erst danach COPY des Quellcodes.
🔑 Der Build-Cache prüft jede Anweisung von oben nach unten.
Der Build-Cache ist ein Zwischenspeicher früherer Schichten; Docker vergleicht Anweisung und Eingaben mit der gecachten Version. Ist eine Schicht unverändert, wird sie samt aller darunterliegenden wiederverwendet. Ab der ersten geänderten Anweisung wird alles Folgende neu gebaut.
📈 Häufig Geändertes gehört ans Ende des Dockerfiles.
Klassischer Einsteigerirrtum: Quellcode früh per COPY übernehmen. Dann läuft bei jeder Codeänderung auch die teure Abhängigkeitsinstallation erneut, obwohl sich nichts daran geändert hat. Steht die COPY-Zeile für den Code dagegen ganz unten, bleibt der Cache für die Installation intakt.
Die Reihenfolge heißt nicht Geschmackssache, sondern Cache-Strategie: selten Geändertes zuerst, häufig Geändertes zuletzt – Basis-Image und Abhängigkeiten vor dem eigenen Quellcode.
📌 Schichten · Build-Cache · Anweisungsreihenfolge
📚 Cloud von Grund auf · Tag 4 von 30
#docker #devops #CloudHosting
2 Tage vor
Viele Dockerfiles beginnen damit, das gesamte Projekt per COPY zu kopieren. Dabei zerstört jede Quellcode-Änderung den gesamten Build-Cache.
Wer ein Dockerfile schreibt, begegnet sofort dem Build-Cache. Wer ihn nicht kennt, wartet bei jedem Neubau Minuten statt Sekunden.
Ein Dockerfile ist eine Liste von Anweisungen, die mit docker build zu einem Image (einer startfertigen Vorlage für Container) verarbeitet wird. Jede Anweisung erzeugt eine Schicht, also das Änderungsprotokoll dieser einen Zeile im Dateisystem. Das Image ist ein Stapel dieser Schichten; docker run startet daraus den Container.
Der Cache prüft beim Neubau jede Anweisung von oben nach unten. Ist eine Zeile unverändert, wird ihre Schicht samt aller darunterliegenden wiederverwendet. Ab der ersten geänderten Zeile wird alles Folgende neu gebaut, auch wenn es sich gar nicht verändert hat.
Konkret: Zuerst FROM, also die Wahl des Basis-Images als Startpunkt, dann COPY der Paketliste, dann RUN zur Installation der Abhängigkeiten, erst danach COPY des Quellcodes und der Startbefehl. Ändert sich nur der Quellcode, bleibt die teure Installation im Cache. Steht die Quellcode-Zeile dagegen oben, läuft RUN bei jeder kleinen Änderung erneut.
Verwechselt wird der Cache gern mit dem Build-Kontext, also dem Verzeichnis, das dem Build als Quelle dient. Der Kontext bestimmt, welche Dateien überhaupt an COPY übergeben werden; der Cache bestimmt, welche Schichten wiederverwendet werden. Eine .dockerignore-Datei hält Unnötiges wie .git aus dem Kontext fern und beschleunigt den Build zusätzlich.
Der Build-Cache belohnt nicht die schönste Zeile, sondern die stabilste Reihenfolge: Selten Geändertes nach oben, Häufig Geändertes nach unten.
📌 Layer · Build-Cache · Reihenfolge im Dockerfile
📚 Cloud von Grund auf · Tag 4 von 30
#docker #devops #CloudHosting
Wer ein Dockerfile schreibt, begegnet sofort dem Build-Cache. Wer ihn nicht kennt, wartet bei jedem Neubau Minuten statt Sekunden.
Ein Dockerfile ist eine Liste von Anweisungen, die mit docker build zu einem Image (einer startfertigen Vorlage für Container) verarbeitet wird. Jede Anweisung erzeugt eine Schicht, also das Änderungsprotokoll dieser einen Zeile im Dateisystem. Das Image ist ein Stapel dieser Schichten; docker run startet daraus den Container.
Der Cache prüft beim Neubau jede Anweisung von oben nach unten. Ist eine Zeile unverändert, wird ihre Schicht samt aller darunterliegenden wiederverwendet. Ab der ersten geänderten Zeile wird alles Folgende neu gebaut, auch wenn es sich gar nicht verändert hat.
Konkret: Zuerst FROM, also die Wahl des Basis-Images als Startpunkt, dann COPY der Paketliste, dann RUN zur Installation der Abhängigkeiten, erst danach COPY des Quellcodes und der Startbefehl. Ändert sich nur der Quellcode, bleibt die teure Installation im Cache. Steht die Quellcode-Zeile dagegen oben, läuft RUN bei jeder kleinen Änderung erneut.
Verwechselt wird der Cache gern mit dem Build-Kontext, also dem Verzeichnis, das dem Build als Quelle dient. Der Kontext bestimmt, welche Dateien überhaupt an COPY übergeben werden; der Cache bestimmt, welche Schichten wiederverwendet werden. Eine .dockerignore-Datei hält Unnötiges wie .git aus dem Kontext fern und beschleunigt den Build zusätzlich.
Der Build-Cache belohnt nicht die schönste Zeile, sondern die stabilste Reihenfolge: Selten Geändertes nach oben, Häufig Geändertes nach unten.
📌 Layer · Build-Cache · Reihenfolge im Dockerfile
📚 Cloud von Grund auf · Tag 4 von 30
#docker #devops #CloudHosting
2 Tage vor
Viele halten einen festen Zugangsschlüssel in der Konfigurationsdatei für eine ganz normale Lösung. Dabei ist genau das der schwerwiegendste Fehler beim Cloud-Zugriff.
Viele denken, der Schlüssel gehöre in die Konfiguration wie einst ein Datenbankpasswort. Plausibel, weil der Access Key (ein dauerhaftes Schlüsselpaar für den Zugriff per Programm) bequem ist: einmal eintragen, die Anwendung läuft.
Tatsächlich gilt: Ein geleakter fester Schlüssel bleibt gültig, bis jemand ihn widerruft. IAM (Identity and Access Management) regelt zwar, wer welche Handlungen auf welchen Ressourcen ausführen darf – ein hinterlegter Schlüssel umgeht jede kurzlebige Kontrolle. Stattdessen vergeben IAM-Rollen temporäre Anmeldeinformationen über den Dienst STS (Security Token Service, der kurzlebige Zugangsdaten ausstellt). Anwendungen auf EC2, ECS oder Lambda erhalten ihre Rechte über zugewiesene Rollen, nicht über fest hinterlegte Schlüssel.
Der Irrtum entsteht, weil die Rollen-Lösung unsichtbar arbeitet: Temporäre Zugangsdaten kommen automatisch über die Instanzmetadaten-Adresse. Der feste Schlüssel steht sichtbar da und funktioniert – bis er in einem Repository landet.
Ein typischer Fall: Eine Anwendung auf einem EC2-Server braucht Lesezugriff auf einen S3-Datenspeicher. Statt einen Schlüssel zu hinterlegen, hängt man der Instanz eine Rolle mit genau dieser Leseberechtigung an. Langlebige Schlüssel, die unvermeidbar bleiben, werden rotiert und möglichst durch Rollen oder Identity Center ersetzt.
Woran man es erkennt: In Konfigurationsdateien oder Umgebungsvariablen stehen dauerhafte Schlüsselpaare, deren letzte Prüfung niemand kennt.
Feste Schlüssel sind nicht der praktische Standard, sondern ein stehendes Restrisiko. Rollen geben kurzlebige Zugangsdaten – und was kurzlebig ist, ist nach dem Ablauf wertlos.
📚 Cloud von Grund auf · Tag 4 von 30
#aws #CloudSecurity #devops
Viele denken, der Schlüssel gehöre in die Konfiguration wie einst ein Datenbankpasswort. Plausibel, weil der Access Key (ein dauerhaftes Schlüsselpaar für den Zugriff per Programm) bequem ist: einmal eintragen, die Anwendung läuft.
Tatsächlich gilt: Ein geleakter fester Schlüssel bleibt gültig, bis jemand ihn widerruft. IAM (Identity and Access Management) regelt zwar, wer welche Handlungen auf welchen Ressourcen ausführen darf – ein hinterlegter Schlüssel umgeht jede kurzlebige Kontrolle. Stattdessen vergeben IAM-Rollen temporäre Anmeldeinformationen über den Dienst STS (Security Token Service, der kurzlebige Zugangsdaten ausstellt). Anwendungen auf EC2, ECS oder Lambda erhalten ihre Rechte über zugewiesene Rollen, nicht über fest hinterlegte Schlüssel.
Der Irrtum entsteht, weil die Rollen-Lösung unsichtbar arbeitet: Temporäre Zugangsdaten kommen automatisch über die Instanzmetadaten-Adresse. Der feste Schlüssel steht sichtbar da und funktioniert – bis er in einem Repository landet.
Ein typischer Fall: Eine Anwendung auf einem EC2-Server braucht Lesezugriff auf einen S3-Datenspeicher. Statt einen Schlüssel zu hinterlegen, hängt man der Instanz eine Rolle mit genau dieser Leseberechtigung an. Langlebige Schlüssel, die unvermeidbar bleiben, werden rotiert und möglichst durch Rollen oder Identity Center ersetzt.
Woran man es erkennt: In Konfigurationsdateien oder Umgebungsvariablen stehen dauerhafte Schlüsselpaare, deren letzte Prüfung niemand kennt.
Feste Schlüssel sind nicht der praktische Standard, sondern ein stehendes Restrisiko. Rollen geben kurzlebige Zugangsdaten – und was kurzlebig ist, ist nach dem Ablauf wertlos.
📚 Cloud von Grund auf · Tag 4 von 30
#aws #CloudSecurity #devops
2 Tage vor
Die meisten Anfänger tippen los und wundern sich über langsame Builds. Dabei ist ein Dockerfile ein Rezept mit fester Anweisungsreihenfolge.
Ein Dockerfile beschreibt Schritt für Schritt, wie ein Container-Image entsteht. Das Image ist die unveränderliche Vorlage, aus der Container gestartet werden.
Zuerst steht die FROM-Anweisung: Sie legt ein Basis-Image fest, etwa eine schlanke Linux-Distribution mit Python. Jede Anweisung erzeugt dabei eine Schicht, und die Reihenfolge entscheidet über den Build-Cache. Selten geänderte Schritte wie Abhängigkeiten gehören deshalb vor häufig geänderten wie dem Quellcode.
Dann folgt COPY. Es kopiert Dateien aus dem Build-Kontext in das Image, also aus dem Verzeichnis, das dem Build mitgegeben wird. Ein häufiger Irrtum: Dateien außerhalb dieses Kontexts sind schlicht nicht verfügbar. Bewährt hat sich, zuerst nur die Datei mit den Abhängigkeiten zu kopieren und zu installieren, dann erst den Quellcode.
Danach kommen RUN für Installationsbefehle sowie USER. Ohne USER läuft der Prozess im Container als root, also mit vollen Rechten. Die Anweisung USER setzt einen unprivilegierten Benutzer und senkt das Risiko, falls der Container kompromittiert wird.
Zuletzt legen CMD den Startbefehl und EXPOSE den Port fest. EXPOSE dokumentiert nur, welchen Port die Anwendung im Container erreicht; geöffnet wird er erst beim Start mit docker run. Der Befehl docker build arbeitet das Dockerfile ab und erzeugt das Image, versehen mit einem Tag wie 1.2. Solche Tags sind beweglich; ein Digest wie sha256:… identifiziert dagegen genau einen Inhalt.
Ein Dockerfile ist also kein Skript, sondern ein Rezept: Jede Anweisung baut eine Schicht, und deren Reihenfolge bestimmt Tempo und Sicherheit des Images.
📌 Schichten und Build-Cache · COPY und Build-Kontext · USER statt root
📚 Cloud von Grund auf · Tag 3 von 30
#docker #devops #CloudSecurity
Ein Dockerfile beschreibt Schritt für Schritt, wie ein Container-Image entsteht. Das Image ist die unveränderliche Vorlage, aus der Container gestartet werden.
Zuerst steht die FROM-Anweisung: Sie legt ein Basis-Image fest, etwa eine schlanke Linux-Distribution mit Python. Jede Anweisung erzeugt dabei eine Schicht, und die Reihenfolge entscheidet über den Build-Cache. Selten geänderte Schritte wie Abhängigkeiten gehören deshalb vor häufig geänderten wie dem Quellcode.
Dann folgt COPY. Es kopiert Dateien aus dem Build-Kontext in das Image, also aus dem Verzeichnis, das dem Build mitgegeben wird. Ein häufiger Irrtum: Dateien außerhalb dieses Kontexts sind schlicht nicht verfügbar. Bewährt hat sich, zuerst nur die Datei mit den Abhängigkeiten zu kopieren und zu installieren, dann erst den Quellcode.
Danach kommen RUN für Installationsbefehle sowie USER. Ohne USER läuft der Prozess im Container als root, also mit vollen Rechten. Die Anweisung USER setzt einen unprivilegierten Benutzer und senkt das Risiko, falls der Container kompromittiert wird.
Zuletzt legen CMD den Startbefehl und EXPOSE den Port fest. EXPOSE dokumentiert nur, welchen Port die Anwendung im Container erreicht; geöffnet wird er erst beim Start mit docker run. Der Befehl docker build arbeitet das Dockerfile ab und erzeugt das Image, versehen mit einem Tag wie 1.2. Solche Tags sind beweglich; ein Digest wie sha256:… identifiziert dagegen genau einen Inhalt.
Ein Dockerfile ist also kein Skript, sondern ein Rezept: Jede Anweisung baut eine Schicht, und deren Reihenfolge bestimmt Tempo und Sicherheit des Images.
📌 Schichten und Build-Cache · COPY und Build-Kontext · USER statt root
📚 Cloud von Grund auf · Tag 3 von 30
#docker #devops #CloudSecurity
3 Tage vor
Viele reden von Containern, meinen aber das Image – und umgekehrt. Dabei ist der Unterschied so klar wie der zwischen Backrezept und Kuchen.
Die Verwechslung liegt an der Sprache: Docker nennt beides fast gleich, und die Begriffe treten immer paarweise auf. Ein Fehler im laufenden Container zeigt sich erst später als verlorene Arbeit.
Ein Image ist eine unveränderliche Vorlage: eine Datei-Sammlung, in der Anwendung, Laufzeit-Umgebung, Bibliotheken und Konfiguration fest eingefroren sind. Nach dem Bau wird es nicht mehr geändert, sondern nur durch ein neues ersetzt – das Prinzip heißt Immutable Infrastructure. Beschrieben wird der Bau in einem Dockerfile, einer Schritt-für-Schritt-Anleitung. Beispiel: Ein Image enthält Python in einer festen Version plus den eigenen Anwendungscode.
Ein Container ist die laufende Instanz, die aus genau diesem Image gestartet wird. Er verpackt die Anwendung mit ihren Abhängigkeiten und teilt sich den Kernel (den Kern) des Host-Betriebssystems, startet dadurch schneller als eine virtuelle Maschine. Aus ein und demselben Image lassen sich beliebig viele Container starten, die alle identisch beginnen. Beispiel: Drei Container aus demselben Python-Image laufen gleichzeitig auf drei Rechnern.
Das Image bleibt unverändert, der Container ist vergänglich. Jede Änderung am laufenden Container verliert mit dessen Löschung ihre Spur.
Faustregel: Änderungen gehören immer in ein neues Image, das man über das Dockerfile baut – niemals in den laufenden Container.
Ein Image ist die Vorlage, ein Container deren laufende Kopie. Wer am Container schraubt, arbeitet im Sandkasten; wer am Image baut, arbeitet für jeden künftigen Start.
📌 Image = Vorlage · Container = Instanz · Änderungen ins Dockerfile
📚 Cloud von Grund auf · Tag 3 von 30
#docker #devops #kubernetes
Die Verwechslung liegt an der Sprache: Docker nennt beides fast gleich, und die Begriffe treten immer paarweise auf. Ein Fehler im laufenden Container zeigt sich erst später als verlorene Arbeit.
Ein Image ist eine unveränderliche Vorlage: eine Datei-Sammlung, in der Anwendung, Laufzeit-Umgebung, Bibliotheken und Konfiguration fest eingefroren sind. Nach dem Bau wird es nicht mehr geändert, sondern nur durch ein neues ersetzt – das Prinzip heißt Immutable Infrastructure. Beschrieben wird der Bau in einem Dockerfile, einer Schritt-für-Schritt-Anleitung. Beispiel: Ein Image enthält Python in einer festen Version plus den eigenen Anwendungscode.
Ein Container ist die laufende Instanz, die aus genau diesem Image gestartet wird. Er verpackt die Anwendung mit ihren Abhängigkeiten und teilt sich den Kernel (den Kern) des Host-Betriebssystems, startet dadurch schneller als eine virtuelle Maschine. Aus ein und demselben Image lassen sich beliebig viele Container starten, die alle identisch beginnen. Beispiel: Drei Container aus demselben Python-Image laufen gleichzeitig auf drei Rechnern.
Das Image bleibt unverändert, der Container ist vergänglich. Jede Änderung am laufenden Container verliert mit dessen Löschung ihre Spur.
Faustregel: Änderungen gehören immer in ein neues Image, das man über das Dockerfile baut – niemals in den laufenden Container.
Ein Image ist die Vorlage, ein Container deren laufende Kopie. Wer am Container schraubt, arbeitet im Sandkasten; wer am Image baut, arbeitet für jeden künftigen Start.
📌 Image = Vorlage · Container = Instanz · Änderungen ins Dockerfile
📚 Cloud von Grund auf · Tag 3 von 30
#docker #devops #kubernetes
3 Tage vor
Ein Container ist ein Mieter im Mehrfamilienhaus: Das Fundament gehört allen, die Einrichtung ist privat. Eine virtuelle Maschine baut dagegen ein eigenes Haus mit eigenem Keller. Genauer: mit einem kompletten Betriebssystem.
Alle Mieter teilen sich dasselbe Gebäude, dieselbe Heizung und Wasserleitung. Jede Wohnung ist trotzdem abgeschlossen; der Nachbar sieht nichts hinein. Zieht ein Mieter aus, hinterlässt er nur seine Möbel, kein ganzes Haus.
Das gemeinsame Gebäude ist der Kernel, also der Kern des Betriebssystems, der Prozesse, Speicher und Hardwarezugriff verwaltet. Die abgeschlossene Wohnung ist der Prozessraum: Jeder Container sieht nur eigene Prozesse, eigenes Dateisystem und eigenes Netzwerk. Die privaten Möbel sind das Container-Image, die unveränderliche Vorlage mit Anwendung, Laufzeitbibliotheken und Konfigurationsdateien.
Ein Dockerfile beschreibt Schritt für Schritt, wie ein Image gebaut wird. Solch ein Image ist meist nur wenige Megabytes bis wenige hundert Megabytes groß, während ein VM-Abbild mit vollem Betriebssystem mehrere Gigabyte umfasst. Deshalb startet ein Container in Sekunden, während eine virtuelle Maschine erst ihr eigenes Betriebssystem bootet – bei AWS heißt dieser Dienst EC2.
Das Bild hat eine Grenze: Ein Mieter kann fast beliebig wirtschaften, ein Container braucht den passenden Kernel. Container setzen auf Linux auf und teilen sich dessen Kernel-Funktionen. Ein Linux-Container läuft deshalb nicht direkt auf einem Windows-Host ohne Linux-Kernel.
Container sind also keine „leichteren VMs“: Eine VM kapselt Hardware, ein Container kapselt nur die Anwendung.
📌 Kernel · Container-Image · Prozessraum
📚 Cloud von Grund auf · Tag 3 von 30
#docker #CloudHosting #Linux
Alle Mieter teilen sich dasselbe Gebäude, dieselbe Heizung und Wasserleitung. Jede Wohnung ist trotzdem abgeschlossen; der Nachbar sieht nichts hinein. Zieht ein Mieter aus, hinterlässt er nur seine Möbel, kein ganzes Haus.
Das gemeinsame Gebäude ist der Kernel, also der Kern des Betriebssystems, der Prozesse, Speicher und Hardwarezugriff verwaltet. Die abgeschlossene Wohnung ist der Prozessraum: Jeder Container sieht nur eigene Prozesse, eigenes Dateisystem und eigenes Netzwerk. Die privaten Möbel sind das Container-Image, die unveränderliche Vorlage mit Anwendung, Laufzeitbibliotheken und Konfigurationsdateien.
Ein Dockerfile beschreibt Schritt für Schritt, wie ein Image gebaut wird. Solch ein Image ist meist nur wenige Megabytes bis wenige hundert Megabytes groß, während ein VM-Abbild mit vollem Betriebssystem mehrere Gigabyte umfasst. Deshalb startet ein Container in Sekunden, während eine virtuelle Maschine erst ihr eigenes Betriebssystem bootet – bei AWS heißt dieser Dienst EC2.
Das Bild hat eine Grenze: Ein Mieter kann fast beliebig wirtschaften, ein Container braucht den passenden Kernel. Container setzen auf Linux auf und teilen sich dessen Kernel-Funktionen. Ein Linux-Container läuft deshalb nicht direkt auf einem Windows-Host ohne Linux-Kernel.
Container sind also keine „leichteren VMs“: Eine VM kapselt Hardware, ein Container kapselt nur die Anwendung.
📌 Kernel · Container-Image · Prozessraum
📚 Cloud von Grund auf · Tag 3 von 30
#docker #CloudHosting #Linux
3 Tage vor
Der Schlüssel in der Konfigurationsdatei funktioniert monatelang, ohne dass jemand ihn prüft. Genau das ist das Problem.
Das Symptom kennt jeder Erstkontakt mit der Cloud: Ein Skript braucht Zugriff, also kopiert man einen festen Zugangsschlüssel (Access Key, ein dauerhaftes Schlüsselpaar aus ID und geheimem Schlüssel) in eine Datei. Es läuft, man vergisst es. Der Schlüssel bleibt wirksam, bis jemand ihn manuell sperrt.
Dahinter steht der Unterschied zwischen dauerhaften und temporären Anmeldedaten. Eine IAM-Rolle ist keine Person, sondern eine Identität, die man vorübergehend annimmt. STS (Security Token Service), der Dienst für kurzlebige Anmeldedaten, stellt dabei einen Zugangsschlüssel, ein Sitzungstoken und einen geheimen Schlüssel aus. Diese gelten nur begrenzt, oft in Stunden bis maximal etwa zwölf Stunden, und laufen danach von selbst ab.
Ein Beispiel aus dem Betrieb: Eine Anwendung auf einem EC2-Server (Amazons virtuelle Maschinen) braucht Lesezugriff auf einen S3-Datenspeicher. Statt einen Schlüssel in die Konfiguration zu schreiben, hängt man der Instanz eine Rolle mit genau dieser Leseberechtigung an. Die Anwendung bezieht ihre temporären Daten automatisch über die Instanzmetadaten-Adresse, ganz ohne hinterlegtes Geheimnis.
So prüft man es: Grep im Projekt nach Access-Key-ID-Mustern, typischerweise zwanzigstellige Zeichenketten. Findet sich einer in einer Datei, ersetzt man ihn durch eine Rolle und sperrt den Schlüssel.
Der zentrale Sicherheitsgewinn liegt im Verfall: Ein geleakter fester Schlüssel bleibt unbegrenzt nutzbar, abgelaufene temporäre Daten sind wertlos. Eine Rolle heißt nicht dauerhaftes Passwort, sondern verliehenes Recht auf Zeit.
📌 IAM-Rolle · Temporäre Anmeldedaten · Schlüssel-Rotation
📚 Cloud von Grund auf · Tag 3 von 30
#aws #CloudSecurity #devops
Das Symptom kennt jeder Erstkontakt mit der Cloud: Ein Skript braucht Zugriff, also kopiert man einen festen Zugangsschlüssel (Access Key, ein dauerhaftes Schlüsselpaar aus ID und geheimem Schlüssel) in eine Datei. Es läuft, man vergisst es. Der Schlüssel bleibt wirksam, bis jemand ihn manuell sperrt.
Dahinter steht der Unterschied zwischen dauerhaften und temporären Anmeldedaten. Eine IAM-Rolle ist keine Person, sondern eine Identität, die man vorübergehend annimmt. STS (Security Token Service), der Dienst für kurzlebige Anmeldedaten, stellt dabei einen Zugangsschlüssel, ein Sitzungstoken und einen geheimen Schlüssel aus. Diese gelten nur begrenzt, oft in Stunden bis maximal etwa zwölf Stunden, und laufen danach von selbst ab.
Ein Beispiel aus dem Betrieb: Eine Anwendung auf einem EC2-Server (Amazons virtuelle Maschinen) braucht Lesezugriff auf einen S3-Datenspeicher. Statt einen Schlüssel in die Konfiguration zu schreiben, hängt man der Instanz eine Rolle mit genau dieser Leseberechtigung an. Die Anwendung bezieht ihre temporären Daten automatisch über die Instanzmetadaten-Adresse, ganz ohne hinterlegtes Geheimnis.
So prüft man es: Grep im Projekt nach Access-Key-ID-Mustern, typischerweise zwanzigstellige Zeichenketten. Findet sich einer in einer Datei, ersetzt man ihn durch eine Rolle und sperrt den Schlüssel.
Der zentrale Sicherheitsgewinn liegt im Verfall: Ein geleakter fester Schlüssel bleibt unbegrenzt nutzbar, abgelaufene temporäre Daten sind wertlos. Eine Rolle heißt nicht dauerhaftes Passwort, sondern verliehenes Recht auf Zeit.
📌 IAM-Rolle · Temporäre Anmeldedaten · Schlüssel-Rotation
📚 Cloud von Grund auf · Tag 3 von 30
#aws #CloudSecurity #devops
3 Tage vor
Die meisten denken bei Cloud-Sicherheit zuerst an Firewalls. Dabei entscheidet viel früher, wer im Konto überhaupt welche Aktion ausführen darf.
Wer hier falsch liegt, öffnet Fremden die Tür. Deshalb lohnt es sich, die drei Bausteine zu kennen.
📦 Ein Principal ist die Identität, die handelt. Das kann ein IAM-Benutzer sein, eine dauerhafte Anmeldung für eine Person, oder eine IAM-Rolle. Den Root-Benutzer, das Hauptkonto der Verwaltung, nur für Ausnahmen nutzen: AWS empfiehlt, ihn nicht für tägliche Aufgaben zu verwenden, MFA (Multi-Faktor-Authentifizierung) zu aktivieren und keine Zugangsschlüssel für ihn anzulegen.
🔑 Eine Richtlinie (Policy) ist ein Dokument mit Rechten. Sie beschreibt erlaubte oder verbotene Aktionen auf benannten Ressourcen, etwa Lesen eines bestimmten S3-Buckets, eines Speicherbehälters im AWS-Dienst S3. Nach Least Privilege erlaubt sie nur die Aktionen, die eine Aufgabe braucht. Eine Policy mit Action "*" und Resource "*" widerspricht diesem Grundsatz.
📈 Die Zuordnung verknüpft Identität und Rechte. Wird eine Richtlinie an einen Benutzer angehängt, erhält er deren Rechte. Beim Auswerten mehrerer Richtlinien gilt: Fehlt eine Erlaubnis, wird der Zugriff verweigert. Eine ausdrückliche Deny-Anweisung schlägt jede Allow-Anweisung. Rollen vergeben temporäre Anmeldeinformationen über den Security Token Service (STS), der kurzbewehrte Schlüssel ausgibt, und wechseln deshalb den Inhaber; Anwendungen auf EC2, ECS oder Lambda erhalten Rechte so statt über fest hinterlegte Schlüssel. Langlebige Schlüssel von IAM-Benutzern regelmäßig rotieren oder durch Rollen oder das Identity Center, die zentrale Benutzer- und Rechteverwaltung in AWS, ersetzen.
Eine Rolle heißt nicht die Person selbst, sondern eine Identität, die man nur für die Dauer einer Aufgabe übernimmt.
📌 Principal · Richtlinie · Zuordnung
📚 Cloud von Grund auf · Tag 3 von 30
#aws #CloudSecurity #devops
Wer hier falsch liegt, öffnet Fremden die Tür. Deshalb lohnt es sich, die drei Bausteine zu kennen.
📦 Ein Principal ist die Identität, die handelt. Das kann ein IAM-Benutzer sein, eine dauerhafte Anmeldung für eine Person, oder eine IAM-Rolle. Den Root-Benutzer, das Hauptkonto der Verwaltung, nur für Ausnahmen nutzen: AWS empfiehlt, ihn nicht für tägliche Aufgaben zu verwenden, MFA (Multi-Faktor-Authentifizierung) zu aktivieren und keine Zugangsschlüssel für ihn anzulegen.
🔑 Eine Richtlinie (Policy) ist ein Dokument mit Rechten. Sie beschreibt erlaubte oder verbotene Aktionen auf benannten Ressourcen, etwa Lesen eines bestimmten S3-Buckets, eines Speicherbehälters im AWS-Dienst S3. Nach Least Privilege erlaubt sie nur die Aktionen, die eine Aufgabe braucht. Eine Policy mit Action "*" und Resource "*" widerspricht diesem Grundsatz.
📈 Die Zuordnung verknüpft Identität und Rechte. Wird eine Richtlinie an einen Benutzer angehängt, erhält er deren Rechte. Beim Auswerten mehrerer Richtlinien gilt: Fehlt eine Erlaubnis, wird der Zugriff verweigert. Eine ausdrückliche Deny-Anweisung schlägt jede Allow-Anweisung. Rollen vergeben temporäre Anmeldeinformationen über den Security Token Service (STS), der kurzbewehrte Schlüssel ausgibt, und wechseln deshalb den Inhaber; Anwendungen auf EC2, ECS oder Lambda erhalten Rechte so statt über fest hinterlegte Schlüssel. Langlebige Schlüssel von IAM-Benutzern regelmäßig rotieren oder durch Rollen oder das Identity Center, die zentrale Benutzer- und Rechteverwaltung in AWS, ersetzen.
Eine Rolle heißt nicht die Person selbst, sondern eine Identität, die man nur für die Dauer einer Aufgabe übernimmt.
📌 Principal · Richtlinie · Zuordnung
📚 Cloud von Grund auf · Tag 3 von 30
#aws #CloudSecurity #devops
3 Tage vor
Eine Anwendung läuft dreifach ausfallsicher – und eine Stromversorgung legt sie komplett still. Solche Stellen heißen Single Points of Failure, und fast jede Architektur hat mindestens einen.
Wer nicht systematisch danach sucht, merkt den Ausfall erst, wenn Nutzer eine Fehlerseite sehen. Betroffen ist jede Cloud-Anwendung, die ohne Ausfallschutz betrieben wird.
Ein Single Point of Failure ist eine Komponente, deren Ausfall das ganze System stoppt. Hochverfügbarkeit entsteht, indem genau solche Komponenten mehrfach vorhanden sind. Erst wenn eine zweite Instanz die Arbeit übernehmen kann, ist der Ausfall abgefangen.
Man geht den Weg einer Anfrage von vorne nach hinten durch – DNS (übersetzt Domainnamen in IP-Adressen), Load Balancer (ein Verkehrsverteiler vor den Servern), Anwendungsserver, Datenbank, Speicher. Eine Anwendung, die nur in einer einzigen Availability Zone (einem Rechenzentrumverbund mit eigener Stromversorgung und Netzanbindung) läuft, hat daher einen Single Point of Failure: Fällt diese Zone aus, ist die Anwendung weg. Der Ausfallschutz entsteht erst durch das Betreiben in mindestens zwei Zonen. Auch vorne droht eine Falle: Ein Load Balancer, der alleinstehend vor der Anwendung sitzt, ist selbst ein Single Point of Failure. In Kubernetes fängt ein Deployment mit mehreren Pods (kleinste Einheit in Kubernetes mit einem oder mehreren Containern) den Ausfall einzelner Pods ab; ein Service gibt ihnen eine stabile Adresse und verteilt Anfragen, auch wenn Pods neu starten.
Verwechselt wird der Single Point of Failure oft mit Redundanz an nur einer Stelle. Die nützt nichts, wenn dahinter alles über genau eine Instanz läuft.
Ein Single Point of Failure ist also nicht „ein kaputtes Teil“, sondern die einzige Instanz, an der alles hängt.
📌 Anfrage-Weg abgehen · einzige Instanz prüfen · zweite Zone einplanen
📚 Cloud von Grund auf · Tag 3 von 30
#aws #sre
Wer nicht systematisch danach sucht, merkt den Ausfall erst, wenn Nutzer eine Fehlerseite sehen. Betroffen ist jede Cloud-Anwendung, die ohne Ausfallschutz betrieben wird.
Ein Single Point of Failure ist eine Komponente, deren Ausfall das ganze System stoppt. Hochverfügbarkeit entsteht, indem genau solche Komponenten mehrfach vorhanden sind. Erst wenn eine zweite Instanz die Arbeit übernehmen kann, ist der Ausfall abgefangen.
Man geht den Weg einer Anfrage von vorne nach hinten durch – DNS (übersetzt Domainnamen in IP-Adressen), Load Balancer (ein Verkehrsverteiler vor den Servern), Anwendungsserver, Datenbank, Speicher. Eine Anwendung, die nur in einer einzigen Availability Zone (einem Rechenzentrumverbund mit eigener Stromversorgung und Netzanbindung) läuft, hat daher einen Single Point of Failure: Fällt diese Zone aus, ist die Anwendung weg. Der Ausfallschutz entsteht erst durch das Betreiben in mindestens zwei Zonen. Auch vorne droht eine Falle: Ein Load Balancer, der alleinstehend vor der Anwendung sitzt, ist selbst ein Single Point of Failure. In Kubernetes fängt ein Deployment mit mehreren Pods (kleinste Einheit in Kubernetes mit einem oder mehreren Containern) den Ausfall einzelner Pods ab; ein Service gibt ihnen eine stabile Adresse und verteilt Anfragen, auch wenn Pods neu starten.
Verwechselt wird der Single Point of Failure oft mit Redundanz an nur einer Stelle. Die nützt nichts, wenn dahinter alles über genau eine Instanz läuft.
Ein Single Point of Failure ist also nicht „ein kaputtes Teil“, sondern die einzige Instanz, an der alles hängt.
📌 Anfrage-Weg abgehen · einzige Instanz prüfen · zweite Zone einplanen
📚 Cloud von Grund auf · Tag 3 von 30
#aws #sre
3 Tage vor
Ein Server fällt aus, und die Anwendung läuft einfach weiter. Viele Einsteiger halten das für Zufall oder Glück – dahinter steckt ein Baustein, der ständig mitprüft.
Viele denken, ein Load Balancer verteile Anfragen einfach stur reihum auf mehrere Server. Das klingt plausibel, weil Verteilen ja der Name des Bausteins ist. Wenn aber ein Server kaputt ist, landen weiter Anfragen bei ihm – und die Nutzer sehen Fehler.
Tatsächlich verteilt ein Load Balancer nur an Server, die gesund sind. Gesundheitsprüfungen (Health Checks) sind regelmäßige automatische Anfragen, etwa alle paar Sekunden an einen Prüfpfad wie /health. Erst nach mehreren erfolgreichen Prüfungen gilt ein Server als gesund. Ein Server, dessen Prüfungen fehlschlagen, wird automatisch aus der Verteilung genommen.
Der Irrtum entsteht, weil das Verteilen sichtbar ist, das Prüfen nicht. Von außen sieht man nur einen einzigen Ansprechpunkt, der Anfragen weiterreicht.
Ein Beispiel: Drei Server hinter einem Load Balancer, Verteilung per Round Robin – die Anfragen wandern reihum, jeder Server erhält etwa gleich viele. Ein Server antwortet auf /health nicht mehr; nach mehreren Fehlversuchen fliegt er aus der Verteilung. Die Nutzer merken nichts, solange mindestens ein gesunder Server bleibt.
Woran man es erkennt: Der Load Balancer leitet Verkehr nur an gesunde Instanzen weiter. Health-Check-Pfad und Schwellen müssen dabei zum Dienst passen, sonst gelten kaputte Server zu spät als krank.
Ein Load Balancer heißt nicht „Anfragenverteiler nach festem Schema“, sondern „Verteiler mit Gesundheitsprüfung“. Er entscheidet bei jeder Anfrage neu, wer sie bekommen darf.
📌 Load Balancer · Health Checks · Round Robin
📚 Cloud von Grund auf · Tag 3 von 30
#CloudHosting #devops #sre
Viele denken, ein Load Balancer verteile Anfragen einfach stur reihum auf mehrere Server. Das klingt plausibel, weil Verteilen ja der Name des Bausteins ist. Wenn aber ein Server kaputt ist, landen weiter Anfragen bei ihm – und die Nutzer sehen Fehler.
Tatsächlich verteilt ein Load Balancer nur an Server, die gesund sind. Gesundheitsprüfungen (Health Checks) sind regelmäßige automatische Anfragen, etwa alle paar Sekunden an einen Prüfpfad wie /health. Erst nach mehreren erfolgreichen Prüfungen gilt ein Server als gesund. Ein Server, dessen Prüfungen fehlschlagen, wird automatisch aus der Verteilung genommen.
Der Irrtum entsteht, weil das Verteilen sichtbar ist, das Prüfen nicht. Von außen sieht man nur einen einzigen Ansprechpunkt, der Anfragen weiterreicht.
Ein Beispiel: Drei Server hinter einem Load Balancer, Verteilung per Round Robin – die Anfragen wandern reihum, jeder Server erhält etwa gleich viele. Ein Server antwortet auf /health nicht mehr; nach mehreren Fehlversuchen fliegt er aus der Verteilung. Die Nutzer merken nichts, solange mindestens ein gesunder Server bleibt.
Woran man es erkennt: Der Load Balancer leitet Verkehr nur an gesunde Instanzen weiter. Health-Check-Pfad und Schwellen müssen dabei zum Dienst passen, sonst gelten kaputte Server zu spät als krank.
Ein Load Balancer heißt nicht „Anfragenverteiler nach festem Schema“, sondern „Verteiler mit Gesundheitsprüfung“. Er entscheidet bei jeder Anfrage neu, wer sie bekommen darf.
📌 Load Balancer · Health Checks · Round Robin
📚 Cloud von Grund auf · Tag 3 von 30
#CloudHosting #devops #sre
3 Tage vor
Eine neue Regel in der Security Group setzen, und trotzdem kommt kein Traffic durch. Meistens fehlt nicht die Regel, sondern sie zeigt auf die falsche Quelle.
Eine Security Group ist eine Firewall, die direkt an der Netzwerkschnittstelle einer Instanz hängt und jeden ein- und ausgehenden Datenverkehr prüft. Sie entscheidet in der Cloud, ob ein Server überhaupt erreichbar ist.
Zuerst denkt man an die Quelle einer Regel, also an die Frage, wer sich verbinden darf. Dort muss keine einzelne IP-Adresse stehen: Wenn die Anwendungsschicht eine eigene Security Group hat, kann genau diese Gruppe als Quelle eingetragen werden. So erhalten nur diese Instanzen Zugriff auf die Datenbank.
Dann wird die Richtung festgelegt. Regeln sind nur Erlaubnisse, nie Verbote. Wer HTTPS von überall erlaubt, lässt genau dieses herein; alles andere bleibt draußen. Die Gruppe gilt je Netzwerkschnittstelle, und Instanzen können mehrere Gruppen haben, deren Regeln sich addieren.
Danach folgt der Punkt, der Einsteiger verwirrt: Security Groups sind zustandsbehaftet. Ruft der Server eine Außenstelle auf, wird die Antwort automatisch eingelassen. Eine zusätzliche Regel für die Rückrichtung ist unnötig und ein häufiger Irrtum.
Zuletzt die Grenze: Öffentlich heißt nicht ungefiltert. Auch in einem öffentlichen Subnetz entscheidet die Security Group, was durchgeht. Eine Adresse gezielt blocken kann sie nicht; dafür braucht es die zustandslose Network ACL auf Subnetzebene.
Security Groups sperren niemanden aus, sondern lassen gewolltes herein. Die Antwort auf eine erlaubte Anfrage läuft immer mit.
📌 Zustandsbehaftet · Nur Erlaubnisregeln · Quelle kann Gruppe sein
📚 Cloud von Grund auf · Tag 3 von 30
#aws #CloudSecurity #devops
Eine Security Group ist eine Firewall, die direkt an der Netzwerkschnittstelle einer Instanz hängt und jeden ein- und ausgehenden Datenverkehr prüft. Sie entscheidet in der Cloud, ob ein Server überhaupt erreichbar ist.
Zuerst denkt man an die Quelle einer Regel, also an die Frage, wer sich verbinden darf. Dort muss keine einzelne IP-Adresse stehen: Wenn die Anwendungsschicht eine eigene Security Group hat, kann genau diese Gruppe als Quelle eingetragen werden. So erhalten nur diese Instanzen Zugriff auf die Datenbank.
Dann wird die Richtung festgelegt. Regeln sind nur Erlaubnisse, nie Verbote. Wer HTTPS von überall erlaubt, lässt genau dieses herein; alles andere bleibt draußen. Die Gruppe gilt je Netzwerkschnittstelle, und Instanzen können mehrere Gruppen haben, deren Regeln sich addieren.
Danach folgt der Punkt, der Einsteiger verwirrt: Security Groups sind zustandsbehaftet. Ruft der Server eine Außenstelle auf, wird die Antwort automatisch eingelassen. Eine zusätzliche Regel für die Rückrichtung ist unnötig und ein häufiger Irrtum.
Zuletzt die Grenze: Öffentlich heißt nicht ungefiltert. Auch in einem öffentlichen Subnetz entscheidet die Security Group, was durchgeht. Eine Adresse gezielt blocken kann sie nicht; dafür braucht es die zustandslose Network ACL auf Subnetzebene.
Security Groups sperren niemanden aus, sondern lassen gewolltes herein. Die Antwort auf eine erlaubte Anfrage läuft immer mit.
📌 Zustandsbehaftet · Nur Erlaubnisregeln · Quelle kann Gruppe sein
📚 Cloud von Grund auf · Tag 3 von 30
#aws #CloudSecurity #devops
3 Tage vor
Öffentliches und privates Subnetz klingen wie zwei verschiedene Bausteine. Dabei entscheidet nur eine Zeile in der Routing-Tabelle, welches Subnetz welches ist.
Die Verwechslung entsteht, weil der Name wie eine Sicherheitseigenschaft klingt. Tatsächlich ist „privat“ nur eine Aussage über Routen, nicht über einen Filter.
Ein Subnetz ist ein abgegrenzter IP-Adressbereich innerhalb einer VPC, des privaten Netzwerks in der Cloud. Jedes Subnetz hängt an einer Routing-Tabelle, die anhand des Ziel-IP-Bereichs entscheidet, wohin jedes Paket geleitet wird. Ein öffentliches Subnetz hat eine Route „Ziel 0.0.0.0/0, Ziel Internet Gateway“ – das Gateway ist die Verbindung zwischen VPC und Internet. Ein Webserver, der aus dem Internet erreichbar sein soll, gehört hierhin.
Ein privates Subnetz ist dasselbe Konstrukt, nur ohne Route zum Internet Gateway. Eine RDS-Datenbank (ein verwalteter Datenbankdienst) läuft typischerweise im privaten Subnetz. Der Zugriff wird über eine Security Group erlaubt, eine Firewall an der Netzwerkschnittstelle, die nur die Anwendungsschicht als Quelle nennt.
Der entscheidende Unterschied liegt nicht im Namen, sondern in der Route. Unerreichbarkeit von außen entsteht durch die fehlende Route, nicht durch eine Sperre. Für ausgehenden Internetzugang stellt ein NAT Gateway im öffentlichen Subnetz die Verbindung her, ohne dass jemand von außen hineinkann.
Faustregel: Alles, das direkt aus dem Internet erreichbar sein muss, gehört ins öffentliche Subnetz; alles andere, etwa Datenbanken, ins private.
Öffentlich heißt also nicht ungefiltert, und privat heißt nicht gesperrt. Beide Begriffe beschreiben nur, ob eine Route zum Internet Gateway existiert.
📌 Route entscheidet · 0.0.0.0/0 · Angriffsfläche trennen
📚 Cloud von Grund auf · Tag 2 von 30
#aws #CloudSecurity #devops
Die Verwechslung entsteht, weil der Name wie eine Sicherheitseigenschaft klingt. Tatsächlich ist „privat“ nur eine Aussage über Routen, nicht über einen Filter.
Ein Subnetz ist ein abgegrenzter IP-Adressbereich innerhalb einer VPC, des privaten Netzwerks in der Cloud. Jedes Subnetz hängt an einer Routing-Tabelle, die anhand des Ziel-IP-Bereichs entscheidet, wohin jedes Paket geleitet wird. Ein öffentliches Subnetz hat eine Route „Ziel 0.0.0.0/0, Ziel Internet Gateway“ – das Gateway ist die Verbindung zwischen VPC und Internet. Ein Webserver, der aus dem Internet erreichbar sein soll, gehört hierhin.
Ein privates Subnetz ist dasselbe Konstrukt, nur ohne Route zum Internet Gateway. Eine RDS-Datenbank (ein verwalteter Datenbankdienst) läuft typischerweise im privaten Subnetz. Der Zugriff wird über eine Security Group erlaubt, eine Firewall an der Netzwerkschnittstelle, die nur die Anwendungsschicht als Quelle nennt.
Der entscheidende Unterschied liegt nicht im Namen, sondern in der Route. Unerreichbarkeit von außen entsteht durch die fehlende Route, nicht durch eine Sperre. Für ausgehenden Internetzugang stellt ein NAT Gateway im öffentlichen Subnetz die Verbindung her, ohne dass jemand von außen hineinkann.
Faustregel: Alles, das direkt aus dem Internet erreichbar sein muss, gehört ins öffentliche Subnetz; alles andere, etwa Datenbanken, ins private.
Öffentlich heißt also nicht ungefiltert, und privat heißt nicht gesperrt. Beide Begriffe beschreiben nur, ob eine Route zum Internet Gateway existiert.
📌 Route entscheidet · 0.0.0.0/0 · Angriffsfläche trennen
📚 Cloud von Grund auf · Tag 2 von 30
#aws #CloudSecurity #devops
4 Tage vor
Eine VPC funktioniert wie ein Firmengelände mit Zaun, Wegen und einem einzigen Tor. Wer keinem Weg folgt, kommt nirgendwo hin – auch nicht ans Tor.
Das Gelände hat klare Grenzen, doch innen bestimmt der Eigentümer die Wege. Manche Wege führen zum Tor, andere enden an einem verschlossenen Gebäudeteil. Wer keine Zufahrt zum Tor hat, bleibt außen.
In der Cloud entspricht das Gelände der VPC (Virtual Private Cloud), also einem logisch abgegrenzten, privaten Netzwerkbereich, in dem man IP-Adressbereiche, Subnetze und Routing selbst festlegt. Die Wege sind die Routing-Tabellen: Sie leiten jedes Paket anhand des Ziel-IP-Bereichs, und ohne passende Route verlässt kein Paket das Subnetz. Das Tor ist das Internet Gateway, das öffentliche Subnetze per Route mit dem Internet verbindet; alle übrigen Subnetze sind privat.
Ein Beispiel: Eine VPC erhält beim Anlegen einen CIDR-Block (Classless Inter-Domain Routing), also einen Bereich zusammenhängender IP-Adressen mit Netzpräfix. Darin liegen zwei Subnetze – im öffentlichen läuft ein NAT-fähiger Dienst, im privaten eine Datenbank, die nur Anfragen aus dem öffentlichen Subnetz annimmt. Die Datenbank gehört dorthin und erlaubt über eine Security Group (eine Firewall-Regelliste) nur die Anwendungsschicht als Quelle.
Das Bild hat eine Grenze: „Privates Subnetz“ klingt nach einem Filter, ist aber nur eine fehlende Route. Sicherheit entsteht hier durchs Routing, nicht durch eine Mauer – Filter wie Security Groups kommen separat dazu.
Private Unerreichbarkeit ist also ein Wegproblem, kein Schloss. Wer das Routing plant, plant die Sicherheit gleich mit.
📌 VPC · Subnetze · Routing
📚 Cloud von Grund auf · Tag 2 von 30
#aws #CloudSecurity #devops
Das Gelände hat klare Grenzen, doch innen bestimmt der Eigentümer die Wege. Manche Wege führen zum Tor, andere enden an einem verschlossenen Gebäudeteil. Wer keine Zufahrt zum Tor hat, bleibt außen.
In der Cloud entspricht das Gelände der VPC (Virtual Private Cloud), also einem logisch abgegrenzten, privaten Netzwerkbereich, in dem man IP-Adressbereiche, Subnetze und Routing selbst festlegt. Die Wege sind die Routing-Tabellen: Sie leiten jedes Paket anhand des Ziel-IP-Bereichs, und ohne passende Route verlässt kein Paket das Subnetz. Das Tor ist das Internet Gateway, das öffentliche Subnetze per Route mit dem Internet verbindet; alle übrigen Subnetze sind privat.
Ein Beispiel: Eine VPC erhält beim Anlegen einen CIDR-Block (Classless Inter-Domain Routing), also einen Bereich zusammenhängender IP-Adressen mit Netzpräfix. Darin liegen zwei Subnetze – im öffentlichen läuft ein NAT-fähiger Dienst, im privaten eine Datenbank, die nur Anfragen aus dem öffentlichen Subnetz annimmt. Die Datenbank gehört dorthin und erlaubt über eine Security Group (eine Firewall-Regelliste) nur die Anwendungsschicht als Quelle.
Das Bild hat eine Grenze: „Privates Subnetz“ klingt nach einem Filter, ist aber nur eine fehlende Route. Sicherheit entsteht hier durchs Routing, nicht durch eine Mauer – Filter wie Security Groups kommen separat dazu.
Private Unerreichbarkeit ist also ein Wegproblem, kein Schloss. Wer das Routing plant, plant die Sicherheit gleich mit.
📌 VPC · Subnetze · Routing
📚 Cloud von Grund auf · Tag 2 von 30
#aws #CloudSecurity #devops
4 Tage vor
Die Seite ist plötzlich nicht mehr erreichbar, der Browser zeigt eine Warnseite statt der Anwendung. Dabei hat sich am Code nichts geändert – nur ein Zertifikat ist still abgelaufen.
Die Nutzer sehen eine Fehlermeldung, die wie ein Sicherheitsproblem aussieht. Auch API-Aufrufe scheitern, weil Clients die Verbindung verweigern. Abgelaufene Zertifikate gehören zu den häufigsten vermeidbaren Ausfallursachen.
Der Grundbegriff dahinter ist das TLS-Zertifikat: eine digitale Bescheinigung, die eine Domain einem öffentlichen Schlüssel des Servers zuordnet. Sie ist von einer Zertifizierungsstelle unterschrieben, also einer anerkannten Ausstellerin, der der Browser vertraut. Ohne gültiges Zertifikat kann der Browser nicht ausschließen, dass sich ein fremder Server für den echten ausgibt – ein sogenannter Man-in-the-Middle.
Ein konkretes Beispiel: Zertifikate von Lets Encrypt sind 90 Tage gültig; die Erneuerung wird nach 60 Tagen empfohlen. Wer von Hand erneuert, vergisst es irgendwann. Die Erneuerung soll deshalb automatisiert laufen, etwa mit dem ACME-Protokoll (RFC 8555) und einem Client wie certbot. Bei der HTTP-Challenge legt der Client eine vom Server gestellte Datei unter einer bekannten URL auf dem Webserver ab; wer sie liefern kann, beweist die Kontrolle über die Domain.
So prüft man es: Das Monitoring sollte die Restlaufzeit jedes öffentlichen Zertifikats überwachen und Alarm schlagen, bevor sie abläuft. Zusätzlich gehört die Erneuerung in einen Timer oder Cron-Dienst, der automatisch läuft.
Ein Zertifikat beweist dem Browser nicht die Echtheit einer Seite, sondern dass eine anerkannte Stelle die Kontrolle über die Domain geprüft hat. Deshalb gilt: Erneuerung automatisieren, Restlaufzeit überwachen – sonst wird der Ablauf zum Ausfall.
📌 TLS-Zertifikat · Zertifizierungsstelle · Automatische Erneuerung
📚 Cloud von Grund auf · Tag 2 von 30
#CloudSecurity #monitoring #devops
Die Nutzer sehen eine Fehlermeldung, die wie ein Sicherheitsproblem aussieht. Auch API-Aufrufe scheitern, weil Clients die Verbindung verweigern. Abgelaufene Zertifikate gehören zu den häufigsten vermeidbaren Ausfallursachen.
Der Grundbegriff dahinter ist das TLS-Zertifikat: eine digitale Bescheinigung, die eine Domain einem öffentlichen Schlüssel des Servers zuordnet. Sie ist von einer Zertifizierungsstelle unterschrieben, also einer anerkannten Ausstellerin, der der Browser vertraut. Ohne gültiges Zertifikat kann der Browser nicht ausschließen, dass sich ein fremder Server für den echten ausgibt – ein sogenannter Man-in-the-Middle.
Ein konkretes Beispiel: Zertifikate von Lets Encrypt sind 90 Tage gültig; die Erneuerung wird nach 60 Tagen empfohlen. Wer von Hand erneuert, vergisst es irgendwann. Die Erneuerung soll deshalb automatisiert laufen, etwa mit dem ACME-Protokoll (RFC 8555) und einem Client wie certbot. Bei der HTTP-Challenge legt der Client eine vom Server gestellte Datei unter einer bekannten URL auf dem Webserver ab; wer sie liefern kann, beweist die Kontrolle über die Domain.
So prüft man es: Das Monitoring sollte die Restlaufzeit jedes öffentlichen Zertifikats überwachen und Alarm schlagen, bevor sie abläuft. Zusätzlich gehört die Erneuerung in einen Timer oder Cron-Dienst, der automatisch läuft.
Ein Zertifikat beweist dem Browser nicht die Echtheit einer Seite, sondern dass eine anerkannte Stelle die Kontrolle über die Domain geprüft hat. Deshalb gilt: Erneuerung automatisieren, Restlaufzeit überwachen – sonst wird der Ablauf zum Ausfall.
📌 TLS-Zertifikat · Zertifizierungsstelle · Automatische Erneuerung
📚 Cloud von Grund auf · Tag 2 von 30
#CloudSecurity #monitoring #devops
