2 hours ago
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
5 hours ago
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
8 hours ago
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
11 hours ago
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
17 hours ago
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
20 hours ago
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 day ago
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 day ago
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 day ago
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
1 day ago
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 days ago
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 days ago
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 days ago
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 days ago
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 days ago
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 days ago
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 days ago
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
2 days ago
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 days ago
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 days ago
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 days ago
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 days ago
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 days ago
Ö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
3 days ago
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 days ago
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
4 days ago
Die meisten denken bei Cloud-Kosten an die Monatsmiete für Server. Dabei zahlt man in der Cloud nur für das, was tatsächlich läuft.
Cloud-Provider rechnen Nutzung automatisch ab und weisen sie transparent aus – Kunden sehen also, wofür sie zahlen. Das betrifft jede Entscheidung: Wer eine Ressource startet, eine Datei speichert oder Daten verschickt, löst jeweils eine andere Kostenart aus.
Zuerst startet jemand eine Instanz – eine gemietete virtuelle Maschine im Rechenzentrum des Providers. Ab der ersten Minute zahlt sie, pro Zeiteinheit. Wer um drei Uhr nachts mit wenigen Klicks eine Maschine startet und sie nach einer Stunde wieder löscht, zahlt nur diese Stunde. Bei gemieteter Festhardware würde der Vertrag monatlich abgerechnet, ob sie läuft oder nicht.
Dann wachsen die Speicherkosten, sobald Daten abgelegt werden. Gespeicherte Datenmenge wird berechnet, und zwar auch dann, wenn keine Anwendung läuft. Alte Backups, vergessene Snapshots – gespeicherte Abbilder von Festplatten – und nicht gelöschte Testdaten stehen monatlich auf der Rechnung, solange sie existieren.
Danach kommt der Datenverkehr dazu: Eingehender Verkehr aus dem Internet ist bei AWS in der Regel kostenfrei. Ausgehender Verkehr ins Internet und zwischen Regionen wird dagegen berechnet. Auch Verkehr zwischen Availability Zones – getrennte Rechenzentren innerhalb derselben Region – kostet und sollte deshalb eingeplant werden.
Zuletzt entscheidet die Freigabe: Nicht mehr benötigte Ressourcen werden gelöscht und verursachen keine Kosten mehr. Wer vergisst abzubauen, zahlt unbemerkt weiter.
Gemessen wird also nicht der Bedarf, sondern die Laufzeit. Cloud-Kosten heißen nicht Miete, sondern Meter.
📌 Laufzeit · Speicher · Datenverkehr
📚 Cloud von Grund auf · Tag 2 von 30
#CloudHosting #devops #aws
Cloud-Provider rechnen Nutzung automatisch ab und weisen sie transparent aus – Kunden sehen also, wofür sie zahlen. Das betrifft jede Entscheidung: Wer eine Ressource startet, eine Datei speichert oder Daten verschickt, löst jeweils eine andere Kostenart aus.
Zuerst startet jemand eine Instanz – eine gemietete virtuelle Maschine im Rechenzentrum des Providers. Ab der ersten Minute zahlt sie, pro Zeiteinheit. Wer um drei Uhr nachts mit wenigen Klicks eine Maschine startet und sie nach einer Stunde wieder löscht, zahlt nur diese Stunde. Bei gemieteter Festhardware würde der Vertrag monatlich abgerechnet, ob sie läuft oder nicht.
Dann wachsen die Speicherkosten, sobald Daten abgelegt werden. Gespeicherte Datenmenge wird berechnet, und zwar auch dann, wenn keine Anwendung läuft. Alte Backups, vergessene Snapshots – gespeicherte Abbilder von Festplatten – und nicht gelöschte Testdaten stehen monatlich auf der Rechnung, solange sie existieren.
Danach kommt der Datenverkehr dazu: Eingehender Verkehr aus dem Internet ist bei AWS in der Regel kostenfrei. Ausgehender Verkehr ins Internet und zwischen Regionen wird dagegen berechnet. Auch Verkehr zwischen Availability Zones – getrennte Rechenzentren innerhalb derselben Region – kostet und sollte deshalb eingeplant werden.
Zuletzt entscheidet die Freigabe: Nicht mehr benötigte Ressourcen werden gelöscht und verursachen keine Kosten mehr. Wer vergisst abzubauen, zahlt unbemerkt weiter.
Gemessen wird also nicht der Bedarf, sondern die Laufzeit. Cloud-Kosten heißen nicht Miete, sondern Meter.
📌 Laufzeit · Speicher · Datenverkehr
📚 Cloud von Grund auf · Tag 2 von 30
#CloudHosting #devops #aws
4 days ago
Die meisten denken, die Cloud stehe „irgendwo im Internet“. Dabei läuft sie in echten Gebäuden mit Stromanschluss, Kühlung und Netzleitung.
Die Verwechslung liegt nahe, weil man Region und Availability Zone nie zu sehen bekommt. Beide klingen nach Geografie, meinen aber unterschiedliche Ebenen der Ausfallsicherheit.
Eine Region ist ein geografisches Gebiet, etwa ein Landesteil oder ein Ballungsraum, in dem ein Anbieter mehrere Rechenzentren betreibt. Sie ist die oberste Einheit, die man bei der Anmeldung wählt. Wer Ressourcen in Frankfurt anlegt, entscheidet damit über den physischen Standort: Daten bleiben im gewählten Land, und Nutzer in der Nähe profitieren von kurzer Latenz, also geringer Verzögerung bei der Datenübertragung.
Eine Availability Zone, kurz AZ, ist der Baustein innerhalb der Region: eines oder mehrere Rechenzentren mit eigener Stromversorgung und eigener Netzanbindung. Die Zonen einer Region sind so platziert, dass sie unabhängig versorgt sind, aber nah genug beieinander liegen, um schnell miteinander zu kommunizieren. Ein Beispiel: Ein Subnetz, also ein Adressbereich im Netz der Cloud, liegt immer in genau einer AZ.
Die Region beantwortet „Wo auf der Welt?“, die AZ beantwortet „Wie unabhängig ist mein Ausfallschutz?“. Eine Anwendung, die nur in einer AZ läuft, hat einen Single Point of Failure – fällt diese Zone aus, ist alles weg.
Faustregel: Region nach Vorgaben wählen (Compliance, Nähe der Nutzer), Ressourcen dann auf mindestens zwei Availability Zones verteilen.
Der Ausfallschutz liegt also nicht in der Region, sondern in der Zahl genutzter Zonen.
📌 Region · Availability Zone · Single Point of Failure
📚 Cloud von Grund auf · Tag 2 von 30
#aws #CloudHosting #devops
Die Verwechslung liegt nahe, weil man Region und Availability Zone nie zu sehen bekommt. Beide klingen nach Geografie, meinen aber unterschiedliche Ebenen der Ausfallsicherheit.
Eine Region ist ein geografisches Gebiet, etwa ein Landesteil oder ein Ballungsraum, in dem ein Anbieter mehrere Rechenzentren betreibt. Sie ist die oberste Einheit, die man bei der Anmeldung wählt. Wer Ressourcen in Frankfurt anlegt, entscheidet damit über den physischen Standort: Daten bleiben im gewählten Land, und Nutzer in der Nähe profitieren von kurzer Latenz, also geringer Verzögerung bei der Datenübertragung.
Eine Availability Zone, kurz AZ, ist der Baustein innerhalb der Region: eines oder mehrere Rechenzentren mit eigener Stromversorgung und eigener Netzanbindung. Die Zonen einer Region sind so platziert, dass sie unabhängig versorgt sind, aber nah genug beieinander liegen, um schnell miteinander zu kommunizieren. Ein Beispiel: Ein Subnetz, also ein Adressbereich im Netz der Cloud, liegt immer in genau einer AZ.
Die Region beantwortet „Wo auf der Welt?“, die AZ beantwortet „Wie unabhängig ist mein Ausfallschutz?“. Eine Anwendung, die nur in einer AZ läuft, hat einen Single Point of Failure – fällt diese Zone aus, ist alles weg.
Faustregel: Region nach Vorgaben wählen (Compliance, Nähe der Nutzer), Ressourcen dann auf mindestens zwei Availability Zones verteilen.
Der Ausfallschutz liegt also nicht in der Region, sondern in der Zahl genutzter Zonen.
📌 Region · Availability Zone · Single Point of Failure
📚 Cloud von Grund auf · Tag 2 von 30
#aws #CloudHosting #devops
4 days ago
Eine vermietete Wohnung funktioniert wie Cloud Computing: Der Vermieter liefert das Haus, der Mieter sichert die Tür. Bei Cloud-Sicherheit ist es genauso geteilt – und die meisten Mieter vergessen den Türschlosskauf.
Der Vermieter sichert das Grundstück: Zäune, Alarmanlage, Strom, Wasser, Heizung. Er sorgt dafür, dass kein Fremder in den Keller kommt. Die Wände trennen die Wohnungen voneinander, ohne dass jeder Mieter sein eigenes Haus baut. Was in der Wohnung passiert, sieht der Vermieter nicht.
Der Anbieter übernimmt die Sicherheit der Cloud: Rechenzentren mit Zutrittskontrolle, Hardware, Strom, Kühlung, Netz und die Virtualisierungsschicht, die Kunden voneinander trennt. Der Kunde verantwortet die Sicherheit in der Cloud: Daten verschlüsseln, Zugriffsrechte per IAM (Identity and Access Management, das Rechtesystem von AWS) vergeben, Netzregeln wie Security Groups setzen, Patches auf eigenen Servern einspielen. Jede Konfiguration gehört ihm.
Konkret: In einer AWS-Region laufen mehrere Rechenzentren als Availability Zones, jede mit eigener Stromversorgung. Die trennende Virtualisierung pflegt AWS; ein offener S3-Speicher durch falsche Rechte ist dagegen Kundensache. In der Praxis gilt: Offene Konfiguration ist Kundensache, der Ausfall einer Zone ist Sache des Anbieters.
Das Bild hat eine Grenze: Der Vermieter kann meist noch vorbeikommen, der Anbieter sieht Kundendaten nicht. Und der Mietvertrag deckt Möbel ab, in der Cloud bleiben Daten und Rechte immer beim Kunden.
Als Prüffrage gilt: Kann ich die Schicht selbst konfigurieren? Dann ist sie meine Verantwortung. Geteilte Verantwortung heißt nicht geteilte Haftung für jedes Detail, sondern klare Zuständigkeit je Schicht.
📌 Shared Responsibility Model · Sicherheit der Cloud vs. in der Cloud · Fehlkonfiguration
📚 Cloud von Grund auf · Tag 1 von 30
#CloudSecurity #aws #devops
Der Vermieter sichert das Grundstück: Zäune, Alarmanlage, Strom, Wasser, Heizung. Er sorgt dafür, dass kein Fremder in den Keller kommt. Die Wände trennen die Wohnungen voneinander, ohne dass jeder Mieter sein eigenes Haus baut. Was in der Wohnung passiert, sieht der Vermieter nicht.
Der Anbieter übernimmt die Sicherheit der Cloud: Rechenzentren mit Zutrittskontrolle, Hardware, Strom, Kühlung, Netz und die Virtualisierungsschicht, die Kunden voneinander trennt. Der Kunde verantwortet die Sicherheit in der Cloud: Daten verschlüsseln, Zugriffsrechte per IAM (Identity and Access Management, das Rechtesystem von AWS) vergeben, Netzregeln wie Security Groups setzen, Patches auf eigenen Servern einspielen. Jede Konfiguration gehört ihm.
Konkret: In einer AWS-Region laufen mehrere Rechenzentren als Availability Zones, jede mit eigener Stromversorgung. Die trennende Virtualisierung pflegt AWS; ein offener S3-Speicher durch falsche Rechte ist dagegen Kundensache. In der Praxis gilt: Offene Konfiguration ist Kundensache, der Ausfall einer Zone ist Sache des Anbieters.
Das Bild hat eine Grenze: Der Vermieter kann meist noch vorbeikommen, der Anbieter sieht Kundendaten nicht. Und der Mietvertrag deckt Möbel ab, in der Cloud bleiben Daten und Rechte immer beim Kunden.
Als Prüffrage gilt: Kann ich die Schicht selbst konfigurieren? Dann ist sie meine Verantwortung. Geteilte Verantwortung heißt nicht geteilte Haftung für jedes Detail, sondern klare Zuständigkeit je Schicht.
📌 Shared Responsibility Model · Sicherheit der Cloud vs. in der Cloud · Fehlkonfiguration
📚 Cloud von Grund auf · Tag 1 von 30
#CloudSecurity #aws #devops
4 days ago
„Ein Server im Internet“ – für viele reicht das als Cloud. Genau dieser Irrtum führt zu Rechnungen für Maschinen, die niemand nutzt.
Wer eine Anwendung erstmals ins Internet stellt, mietet oft einen dedizierten Server, also einen fest zugewiesenen physischen Rechner. Der Vertrag läuft monatlich, ob die Maschine arbeitet oder leer läuft.
Hinter dem Symptom stehen die fünf Merkmale der Cloud, wie sie das US-Institut NIST in SP 800-145 definiert. Cloud Computing ist demnach bedarfsgerechter Netzzugriff auf einen gemeinsamen Pool konfigurierbarer Rechenressourcen, schnell bereitgestellt und wieder freigegeben. Fehlt eines der Merkmale, liegt Servermiete oder Hosting vor, keine echte Cloud.
Selbstbedienung heißt: Ressourcen über eine Weboberfläche oder Programmierschnittstelle (API) bestellen, ohne Vertrieb. Breiter Netzzugriff: erreichbar über Standardprotokolle wie HTTPS, nicht nur von einer festen Leitung. Pooling: viele Kunden teilen sich dieselben physischen Rechner und Speicher, getrennt nur durch Virtualisierung, also durch Software statt eigener Hardware. Elastizität: bei Lastanstieg starten zusätzliche Maschinen, bei Ruhe verschwinden sie. Gemessener Dienst: Nutzung wird automatisch erfasst und ausgewiesen.
Um drei Uhr nachts wird in der Konsole mit wenigen Klicks eine virtuelle Maschine gestartet und nach einer Stunde wieder gelöscht. Bezahlt wird genau diese eine Stunde Laufzeit. Der dedizierte Server wird stattdessen monatlich abgerechnet, ob er läuft oder nicht.
So prüft man es: Ein Angebot an den fünf Merkmalen messen und nachfragen, was bei einer nicht mehr gebrauchten Ressource passiert. Echt ist die Cloud erst, wenn Freigeben sofort und ohne Restkosten möglich ist.
Cloud ist nicht Server im Internet, sondern ein Pool, aus dem man sich bedient und zurückgibt.
📌 NIST SP 800-145 · fünf Merkmale · nutzungsbasierte Abrechnung
📚 Cloud von Grund auf · Tag 1 von 30
#CloudHosting #devops
Wer eine Anwendung erstmals ins Internet stellt, mietet oft einen dedizierten Server, also einen fest zugewiesenen physischen Rechner. Der Vertrag läuft monatlich, ob die Maschine arbeitet oder leer läuft.
Hinter dem Symptom stehen die fünf Merkmale der Cloud, wie sie das US-Institut NIST in SP 800-145 definiert. Cloud Computing ist demnach bedarfsgerechter Netzzugriff auf einen gemeinsamen Pool konfigurierbarer Rechenressourcen, schnell bereitgestellt und wieder freigegeben. Fehlt eines der Merkmale, liegt Servermiete oder Hosting vor, keine echte Cloud.
Selbstbedienung heißt: Ressourcen über eine Weboberfläche oder Programmierschnittstelle (API) bestellen, ohne Vertrieb. Breiter Netzzugriff: erreichbar über Standardprotokolle wie HTTPS, nicht nur von einer festen Leitung. Pooling: viele Kunden teilen sich dieselben physischen Rechner und Speicher, getrennt nur durch Virtualisierung, also durch Software statt eigener Hardware. Elastizität: bei Lastanstieg starten zusätzliche Maschinen, bei Ruhe verschwinden sie. Gemessener Dienst: Nutzung wird automatisch erfasst und ausgewiesen.
Um drei Uhr nachts wird in der Konsole mit wenigen Klicks eine virtuelle Maschine gestartet und nach einer Stunde wieder gelöscht. Bezahlt wird genau diese eine Stunde Laufzeit. Der dedizierte Server wird stattdessen monatlich abgerechnet, ob er läuft oder nicht.
So prüft man es: Ein Angebot an den fünf Merkmalen messen und nachfragen, was bei einer nicht mehr gebrauchten Ressource passiert. Echt ist die Cloud erst, wenn Freigeben sofort und ohne Restkosten möglich ist.
Cloud ist nicht Server im Internet, sondern ein Pool, aus dem man sich bedient und zurückgibt.
📌 NIST SP 800-145 · fünf Merkmale · nutzungsbasierte Abrechnung
📚 Cloud von Grund auf · Tag 1 von 30
#CloudHosting #devops
5 days ago
Die meisten denken bei Cloud an einen gemieteten Server irgendwo im Internet. Dabei ist der Kern ein gemeinsamer Vorrat an Rechenleistung, aus dem viele Kunden gleichzeitig bedient werden.
Nur wer den Pool und die Selbstbedienung versteht, erkennt, warum Cloud kein Server-Mieten ist. Denn genau diese zwei Merkmale machen Bereitstellung in Minuten und nutzungsbasierte Abrechnung erst möglich.
📦 Cloud bedeutet, Ressourcen aus einem geteilten Vorrat anzufordern, nicht einen festen Rechner zu mieten. NIST SP 800-145 beschreibt das als bedarfsgerechten Netzzugriff auf einen Pool konfigurierbarer Rechenressourcen. Rechenleistung, Speicher und Netzwerk liegen also nicht als einzelne Geräte bereit, sondern als gemeinsamer Bestand. Die Trennung der Kunden geschieht durch Virtualisierung, also Software, die jedem Kunden einen abgegrenzten Anteil an der Hardware zuteilt.
🔑 Selbstbedienung heißt: Ressourcen per Weboberfläche oder Programmierschnittstelle (API, eine Schnittstelle, über die Software automatisch Befehle sendet) bestellen, ohne Vertrieb oder Menschen. Ein Skript oder ein Klick genügt, um einen virtuellen Rechner zu starten oder zu löschen. Deshalb dauert die Bereitstellung Minuten statt Tage, und es entsteht keine langfristige Bindung an feste Hardware.
📈 Abgerechnet wird nach Nutzung, etwa nach der Laufzeit einer Instanz, also eines gestarteten virtuellen Rechners, der gespeicherten Datenmenge oder den übertragenen Daten. Was nicht mehr gebraucht wird, wird freigegeben und kostet nichts mehr. Gemietete Festhardware wird dagegen abgerechnet, ob sie läuft oder nicht.
Cloud Computing heißt nicht „ein Server im Internet“, sondern Rechenleistung, Speicher und Netzwerk aus einem Pool per Schnittstelle anfordern und nach Nutzung zurückgeben.
📌 Ressourcen-Pool · Selbstbedienung · nutzungsbasierte Abrechnung
📚 Cloud von Grund auf · Tag 1 von 30
#CloudHosting #devops
Nur wer den Pool und die Selbstbedienung versteht, erkennt, warum Cloud kein Server-Mieten ist. Denn genau diese zwei Merkmale machen Bereitstellung in Minuten und nutzungsbasierte Abrechnung erst möglich.
📦 Cloud bedeutet, Ressourcen aus einem geteilten Vorrat anzufordern, nicht einen festen Rechner zu mieten. NIST SP 800-145 beschreibt das als bedarfsgerechten Netzzugriff auf einen Pool konfigurierbarer Rechenressourcen. Rechenleistung, Speicher und Netzwerk liegen also nicht als einzelne Geräte bereit, sondern als gemeinsamer Bestand. Die Trennung der Kunden geschieht durch Virtualisierung, also Software, die jedem Kunden einen abgegrenzten Anteil an der Hardware zuteilt.
🔑 Selbstbedienung heißt: Ressourcen per Weboberfläche oder Programmierschnittstelle (API, eine Schnittstelle, über die Software automatisch Befehle sendet) bestellen, ohne Vertrieb oder Menschen. Ein Skript oder ein Klick genügt, um einen virtuellen Rechner zu starten oder zu löschen. Deshalb dauert die Bereitstellung Minuten statt Tage, und es entsteht keine langfristige Bindung an feste Hardware.
📈 Abgerechnet wird nach Nutzung, etwa nach der Laufzeit einer Instanz, also eines gestarteten virtuellen Rechners, der gespeicherten Datenmenge oder den übertragenen Daten. Was nicht mehr gebraucht wird, wird freigegeben und kostet nichts mehr. Gemietete Festhardware wird dagegen abgerechnet, ob sie läuft oder nicht.
Cloud Computing heißt nicht „ein Server im Internet“, sondern Rechenleistung, Speicher und Netzwerk aus einem Pool per Schnittstelle anfordern und nach Nutzung zurückgeben.
📌 Ressourcen-Pool · Selbstbedienung · nutzungsbasierte Abrechnung
📚 Cloud von Grund auf · Tag 1 von 30
#CloudHosting #devops
