9 Protokoll vor
Konfiguration und State sehen auf den ersten Blick wie zwei Beschreibungen derselben Infrastruktur aus. Dabei sagt die eine nur, wie etwas aussehen soll – die andere, was wirklich existiert.
Die Verwechslung liegt nahe, weil beide Dateien dieselben Ressourcen nennen. Wer nur die Konfiguration liest, glaubt deshalb, Terraform brauche nichts weiter.
Die Konfiguration ist der Bauplan. In HCL, der Sprache von Terraform, wird dort beschrieben, welche Ressourcen gewünscht sind und mit welchen Einstellungen. Steht darin eine VPC (das private Netz in der Cloud), legt der Code Name und IP-Adressbereich fest, etwa als Adressbereich mit Netzpräfix. Die Konfiguration sagt aber nicht, welches echte Netz die Cloud daraus gebaut hat.
Der State ist das Gedächtnis. Er ist im Kern eine kleine Datenbank, in der Terraform für jede Ressource die konkrete Kennung speichert, die die Cloud vergeben hat, samt den aktuellen Attributen. Für die Beispiel-VPC merkt er sich ihre ID, den Adressbereich und die zugehörigen Subnetze. Aus der Differenz zwischen Konfiguration und State berechnet terraform plan die Änderungen.
Ohne State hält Terraform die VPC für nicht vorhanden und würde bei apply alles neu anlegen, obwohl die echten Objekte längst laufen. Der State ist deshalb kein Anhängsel, sondern Voraussetzung für jeden sauberen Plan.
Faustregel: Den State zentral in einem Remote-Backend, also einer zentralen Ablage wie S3, ablegen, nie lokal in Git, und per State-Locking schützen, das zwei gleichzeitige Läufe am selben State verhindert. Drift durch manuelle Konsolenänderungen macht terraform plan sichtbar. Sensible Werte im State wie ein Geheimnis behandeln.
Der State heißt nicht Kopie der Konfiguration, sondern Zuordnung zwischen Wunsch und Wirklichkeit – fehlt sie, baut Terraform doppelt.
📌 Terraform State · Konfiguration vs. Realität · Remote-Backend
📚 Cloud von Grund auf · Tag 6 von 30
#Terraform #iac #devops
Die Verwechslung liegt nahe, weil beide Dateien dieselben Ressourcen nennen. Wer nur die Konfiguration liest, glaubt deshalb, Terraform brauche nichts weiter.
Die Konfiguration ist der Bauplan. In HCL, der Sprache von Terraform, wird dort beschrieben, welche Ressourcen gewünscht sind und mit welchen Einstellungen. Steht darin eine VPC (das private Netz in der Cloud), legt der Code Name und IP-Adressbereich fest, etwa als Adressbereich mit Netzpräfix. Die Konfiguration sagt aber nicht, welches echte Netz die Cloud daraus gebaut hat.
Der State ist das Gedächtnis. Er ist im Kern eine kleine Datenbank, in der Terraform für jede Ressource die konkrete Kennung speichert, die die Cloud vergeben hat, samt den aktuellen Attributen. Für die Beispiel-VPC merkt er sich ihre ID, den Adressbereich und die zugehörigen Subnetze. Aus der Differenz zwischen Konfiguration und State berechnet terraform plan die Änderungen.
Ohne State hält Terraform die VPC für nicht vorhanden und würde bei apply alles neu anlegen, obwohl die echten Objekte längst laufen. Der State ist deshalb kein Anhängsel, sondern Voraussetzung für jeden sauberen Plan.
Faustregel: Den State zentral in einem Remote-Backend, also einer zentralen Ablage wie S3, ablegen, nie lokal in Git, und per State-Locking schützen, das zwei gleichzeitige Läufe am selben State verhindert. Drift durch manuelle Konsolenänderungen macht terraform plan sichtbar. Sensible Werte im State wie ein Geheimnis behandeln.
Der State heißt nicht Kopie der Konfiguration, sondern Zuordnung zwischen Wunsch und Wirklichkeit – fehlt sie, baut Terraform doppelt.
📌 Terraform State · Konfiguration vs. Realität · Remote-Backend
📚 Cloud von Grund auf · Tag 6 von 30
#Terraform #iac #devops
1 Stunde vor
Der Reflex heißt: Daten in die Cloud schicken, dort wird schon gerechnet. Genau dieser Reflex ist oft die falsche Entscheidung.
Viele Einsteiger glauben, eine zentrale Cloud sei der einzige Ort für Datenverarbeitung. Klingt plausibel, denn die Cloud gilt als der normale Ort für Verarbeitung. Also wandern erst einmal alle Daten dorthin.
Tatsächlich entscheidet der Anwendungsfall über den Ort der Verarbeitung. Edge Computing, das Rechnen direkt am Einsatzort, etwa auf einem kleinen Rechner an einer Maschine, verzichtet auf den weiten Weg ins Rechenzentrum. Das senkt die Latenz, also die Verzögerung zwischen Anfrage und Antwort. Es schont Bandbreite, die übertragbare Datenmenge je Zeiteinheit. Und es erhält Ausfallsicherheit, wenn die Netzanbindung wegfällt.
Der Irrtum entsteht, weil Clouds in Werbung und Schulung meist als Standardarchitektur gelehrt werden. Der Weg der Daten bleibt unsichtbar, solange alles funktioniert.
Eine Maschine mit Hochfrequenzsensoren erzeugt enorme Datenmengen. Das Edge-Gerät fasst sie vor Ort zusammen und sendet nur Auffälligkeiten weiter. Die Bandbreite sinkt stark, und die Steuerung bleibt bei Netzausfall lauffähig.
Woran man es erkennt: Muss die Anwendung selbsttätig und blitzschnell reagieren, gehört die Verarbeitung vor Ort. Geht es um übergreifende Analysen über viele Standorte, ist die zentrale Cloud die richtige Wahl.
Edge heißt nicht „Cloud abschaffen“, sondern Verarbeitung dorthin verlagern, wo Latenz, Bandbreite oder Ausfallsicherheit es verlangen.
📌 Latenz · Bandbreite · Ausfallsicherheit
📚 Zukunftstechnologien verstehen · Tag 6 von 30
#edgecomputing #architektur #DigitaleTransformation
Viele Einsteiger glauben, eine zentrale Cloud sei der einzige Ort für Datenverarbeitung. Klingt plausibel, denn die Cloud gilt als der normale Ort für Verarbeitung. Also wandern erst einmal alle Daten dorthin.
Tatsächlich entscheidet der Anwendungsfall über den Ort der Verarbeitung. Edge Computing, das Rechnen direkt am Einsatzort, etwa auf einem kleinen Rechner an einer Maschine, verzichtet auf den weiten Weg ins Rechenzentrum. Das senkt die Latenz, also die Verzögerung zwischen Anfrage und Antwort. Es schont Bandbreite, die übertragbare Datenmenge je Zeiteinheit. Und es erhält Ausfallsicherheit, wenn die Netzanbindung wegfällt.
Der Irrtum entsteht, weil Clouds in Werbung und Schulung meist als Standardarchitektur gelehrt werden. Der Weg der Daten bleibt unsichtbar, solange alles funktioniert.
Eine Maschine mit Hochfrequenzsensoren erzeugt enorme Datenmengen. Das Edge-Gerät fasst sie vor Ort zusammen und sendet nur Auffälligkeiten weiter. Die Bandbreite sinkt stark, und die Steuerung bleibt bei Netzausfall lauffähig.
Woran man es erkennt: Muss die Anwendung selbsttätig und blitzschnell reagieren, gehört die Verarbeitung vor Ort. Geht es um übergreifende Analysen über viele Standorte, ist die zentrale Cloud die richtige Wahl.
Edge heißt nicht „Cloud abschaffen“, sondern Verarbeitung dorthin verlagern, wo Latenz, Bandbreite oder Ausfallsicherheit es verlangen.
📌 Latenz · Bandbreite · Ausfallsicherheit
📚 Zukunftstechnologien verstehen · Tag 6 von 30
#edgecomputing #architektur #DigitaleTransformation
3 Std vor
Eine Kanzlei mit zu viel Post öffnet keine größeren Briefkästen, sondern stellt einfach zwei Schalter nebeneinander. Genau so antwortet die Cloud auf wachsende Last.
Das Bild ausgemalt: Am einen Schalter staut sich die Schlange, also baut man den Schalter zu einem größeren Schalter um, an dem mehr Menschen gleichzeitig bedient werden. Der Umbau braucht Zeit, und währenddessen ist der Schalter zu. Schöner ist es, einen zweiten, gleichen Schalter zu öffnen, der sofort arbeiten kann. Und fällt ein Schalter aus, bleibt der andere besetzt.
Fachlich ist das vertikales Skalieren: Die bestehende Instanz, also eine virtuelle Maschine wie EC2, wird durch eine leistungsstärkere ersetzt. Horizontales Skalieren heißt stattdessen, zusätzliche Instanzen derselben Art daneben zu schalten und die Anfragen auf sie zu verteilen. Der Schalterausfall ist ein Single Point of Failure, eine Komponente, deren Ausfall alles stoppt.
In der Praxis: Mehr gleichzeitige Anfragen sprechen für horizontal, denn Lastverteilung wächst nach Bedarf, und die Abrechnung folgt der Nutzung. Größere einzelne Anfragen, etwa eine Datenbank mit hohem Speicherbedarf, sprechen für vertikal. Kubernetes hält dabei die gewünschte Anzahl laufender Container-Instanzen automatisch ein.
Das Bild hat eine Grenze: Ein Schalterteam braucht nur Menschen, Instanzen brauchen einen Lastverteiler, der die Anfragen auf die Instanzen verteilt, und geteilte Zustände wie Datenbanken. Und vertikal stößt man an die größte angebotene Instanzgröße, während horizontales Ergänzen nahezu unbegrenzt bleibt.
Horizontales Skalieren heißt nicht teurer, sondern redundanter: Mehr Instanzen schützen vor Ausfall, eine große Instanz bleibt ein einziger Schwachpunkt.
📌 Horizontale Skalierung · Vertikale Skalierung · Redundanz
📚 Cloud von Grund auf · Tag 6 von 30
#aws #devops #CloudHosting
Das Bild ausgemalt: Am einen Schalter staut sich die Schlange, also baut man den Schalter zu einem größeren Schalter um, an dem mehr Menschen gleichzeitig bedient werden. Der Umbau braucht Zeit, und währenddessen ist der Schalter zu. Schöner ist es, einen zweiten, gleichen Schalter zu öffnen, der sofort arbeiten kann. Und fällt ein Schalter aus, bleibt der andere besetzt.
Fachlich ist das vertikales Skalieren: Die bestehende Instanz, also eine virtuelle Maschine wie EC2, wird durch eine leistungsstärkere ersetzt. Horizontales Skalieren heißt stattdessen, zusätzliche Instanzen derselben Art daneben zu schalten und die Anfragen auf sie zu verteilen. Der Schalterausfall ist ein Single Point of Failure, eine Komponente, deren Ausfall alles stoppt.
In der Praxis: Mehr gleichzeitige Anfragen sprechen für horizontal, denn Lastverteilung wächst nach Bedarf, und die Abrechnung folgt der Nutzung. Größere einzelne Anfragen, etwa eine Datenbank mit hohem Speicherbedarf, sprechen für vertikal. Kubernetes hält dabei die gewünschte Anzahl laufender Container-Instanzen automatisch ein.
Das Bild hat eine Grenze: Ein Schalterteam braucht nur Menschen, Instanzen brauchen einen Lastverteiler, der die Anfragen auf die Instanzen verteilt, und geteilte Zustände wie Datenbanken. Und vertikal stößt man an die größte angebotene Instanzgröße, während horizontales Ergänzen nahezu unbegrenzt bleibt.
Horizontales Skalieren heißt nicht teurer, sondern redundanter: Mehr Instanzen schützen vor Ausfall, eine große Instanz bleibt ein einziger Schwachpunkt.
📌 Horizontale Skalierung · Vertikale Skalierung · Redundanz
📚 Cloud von Grund auf · Tag 6 von 30
#aws #devops #CloudHosting
6 Std vor
Terraform apply läuft, und plötzlich legt es eine zweite EC2-Instanz neben der bestehenden an. Das Symptom kennen viele bei ihren ersten Cloud-Projekten.
Trotz unveränderter Konfiguration entstehen doppelte Ressourcen in der Cloud. Die alten Instanzen laufen weiter und verursachen weiterhin Kosten.
Terraform hält in einer State-Datei fest, welche echten Cloud-Ressourcen zu welchem Konfigurationseintrag gehören. Dieser State ist Terraforms Gedächtnis: Er speichert den Zustand, den Terraform beim letzten apply beobachtet hat. Bei jedem Lauf vergleicht Terraform den Soll-Zustand aus den .tf-Dateien, den Ist-Zustand aus dem State und die reale Cloud.
In der Konfiguration steht eine EC2-Instanz namens web-server. Nach dem apply liegt die Instanz-ID der erzeugten Cloud-Instanz im State. Genau diese ID erlaubt Terraform bei einer späteren Änderung, dieselbe Instanz zu aktualisieren statt eine neue zu bauen. Ohne State entsteht beim nächsten apply eine doppelte Instanz.
So prüft man es: Nach terraform apply die Ausgabe darauf prüfen, ob sie nur beabsichtigte Änderungen zeigt. Erscheinen Ressourcen als komplett neu, fehlt vermutlich die Zuordnung im State.
Der State ist kein Protokoll, sondern ein Abbuchungsregister: Er entscheidet, welche echte Ressource beim Abbau entfernt wird. Deshalb gehört er geschützt in ein Remote-Backend, ein zentraler Ablageort für den State, etwa ein S3-Bucket; dort verhindert State-Locking, dass zwei Läufe gleichzeitig denselben State überschreiben. Weil der State Klartext wie Passwörter enthalten kann, hat er nichts in Git verloren.
Ein verlorener State lässt sich über Import-Werkzeuge teilweise zurückholen. Einfacher ist es, ihn nie zu verlieren.
State heißt nicht Nebenprodukt, sondern Gedächtnis ohne Rückversicherung.
📌 State-Datei · Remote-Backend · State-Locking
📚 Cloud von Grund auf · Tag 6 von 30
#Terraform #iac #devops
Trotz unveränderter Konfiguration entstehen doppelte Ressourcen in der Cloud. Die alten Instanzen laufen weiter und verursachen weiterhin Kosten.
Terraform hält in einer State-Datei fest, welche echten Cloud-Ressourcen zu welchem Konfigurationseintrag gehören. Dieser State ist Terraforms Gedächtnis: Er speichert den Zustand, den Terraform beim letzten apply beobachtet hat. Bei jedem Lauf vergleicht Terraform den Soll-Zustand aus den .tf-Dateien, den Ist-Zustand aus dem State und die reale Cloud.
In der Konfiguration steht eine EC2-Instanz namens web-server. Nach dem apply liegt die Instanz-ID der erzeugten Cloud-Instanz im State. Genau diese ID erlaubt Terraform bei einer späteren Änderung, dieselbe Instanz zu aktualisieren statt eine neue zu bauen. Ohne State entsteht beim nächsten apply eine doppelte Instanz.
So prüft man es: Nach terraform apply die Ausgabe darauf prüfen, ob sie nur beabsichtigte Änderungen zeigt. Erscheinen Ressourcen als komplett neu, fehlt vermutlich die Zuordnung im State.
Der State ist kein Protokoll, sondern ein Abbuchungsregister: Er entscheidet, welche echte Ressource beim Abbau entfernt wird. Deshalb gehört er geschützt in ein Remote-Backend, ein zentraler Ablageort für den State, etwa ein S3-Bucket; dort verhindert State-Locking, dass zwei Läufe gleichzeitig denselben State überschreiben. Weil der State Klartext wie Passwörter enthalten kann, hat er nichts in Git verloren.
Ein verlorener State lässt sich über Import-Werkzeuge teilweise zurückholen. Einfacher ist es, ihn nie zu verlieren.
State heißt nicht Nebenprodukt, sondern Gedächtnis ohne Rückversicherung.
📌 State-Datei · Remote-Backend · State-Locking
📚 Cloud von Grund auf · Tag 6 von 30
#Terraform #iac #devops
7 Std vor
Die meisten Daten reisen heute erst in eine zentrale Wolke. Dabei entstehen sie direkt an der Maschine, am Sensor, am Nutzer.
Beide Begriffe – Cloud Computing und Edge Computing – klingen wie Konkurrenten. In Wirklichkeit sind sie zwei Orte für dieselbe Frage: Wo soll gerechnet werden?
Cloud-Rechnen bedeutet: Daten werden in ein zentrales Rechenzentrum geschickt, dort verarbeitet, und das Ergebnis kommt zurück. Der Rechner steht also weit weg von der Maschine, die die Daten liefert. Ein Beispiel ist die Qualitätsanalyse von Produktionsdaten, die über Nacht zentral ausgewertet wird. Das Signal muss hin- und zurücklaufen, und das kostet Zeit.
Edge Computing bedeutet: Die Verarbeitung läuft direkt dort, wo die Daten entstehen – etwa auf einem kleinen Rechner an der Maschine. Latenz, die Verzögerung zwischen Anfrage und Antwort, bleibt dadurch minimal. Eine Fertigungslinie mit Bilderkennung prüft so in Millisekunden, ob ein Teil korrekt geformt ist, und verwirft Ausschuss sofort.
Der entscheidende Unterschied ist der Ort der Verarbeitung und seine Folgen. Edge übernimmt zeitkritische und netzunabhängige Schritte, die Cloud datenreiche Analysen über lange Zeiträume.
Faustregel: Drei Fragen entscheiden – Muss die Antwort in Millisekunden kommen, sind die Rohdaten zu groß für die Leitung, und muss die Anlage bei Netzausfall weiterlaufen? Eine Schutzfunktion, die erst nach einer Sekunde reagiert, weil der Umweg übers Rechenzentrum dauert, ist wertlos.
Edge heißt nicht Cloud-Ersatz, sondern Arbeitsteilung: Millisekunden vor Ort, Auswertung zentral. Edge spart zudem keine Pflege, sondern verschiebt sie auf viele kleine, verteilte Rechner.
📌 Latenz · Bandbreite · Ausfallsicherheit
📚 Zukunftstechnologien verstehen · Tag 6 von 30
#edgecomputing #architektur #DigitaleTransformation
Beide Begriffe – Cloud Computing und Edge Computing – klingen wie Konkurrenten. In Wirklichkeit sind sie zwei Orte für dieselbe Frage: Wo soll gerechnet werden?
Cloud-Rechnen bedeutet: Daten werden in ein zentrales Rechenzentrum geschickt, dort verarbeitet, und das Ergebnis kommt zurück. Der Rechner steht also weit weg von der Maschine, die die Daten liefert. Ein Beispiel ist die Qualitätsanalyse von Produktionsdaten, die über Nacht zentral ausgewertet wird. Das Signal muss hin- und zurücklaufen, und das kostet Zeit.
Edge Computing bedeutet: Die Verarbeitung läuft direkt dort, wo die Daten entstehen – etwa auf einem kleinen Rechner an der Maschine. Latenz, die Verzögerung zwischen Anfrage und Antwort, bleibt dadurch minimal. Eine Fertigungslinie mit Bilderkennung prüft so in Millisekunden, ob ein Teil korrekt geformt ist, und verwirft Ausschuss sofort.
Der entscheidende Unterschied ist der Ort der Verarbeitung und seine Folgen. Edge übernimmt zeitkritische und netzunabhängige Schritte, die Cloud datenreiche Analysen über lange Zeiträume.
Faustregel: Drei Fragen entscheiden – Muss die Antwort in Millisekunden kommen, sind die Rohdaten zu groß für die Leitung, und muss die Anlage bei Netzausfall weiterlaufen? Eine Schutzfunktion, die erst nach einer Sekunde reagiert, weil der Umweg übers Rechenzentrum dauert, ist wertlos.
Edge heißt nicht Cloud-Ersatz, sondern Arbeitsteilung: Millisekunden vor Ort, Auswertung zentral. Edge spart zudem keine Pflege, sondern verschiebt sie auf viele kleine, verteilte Rechner.
📌 Latenz · Bandbreite · Ausfallsicherheit
📚 Zukunftstechnologien verstehen · Tag 6 von 30
#edgecomputing #architektur #DigitaleTransformation
9 Std vor
Die meisten führen terraform apply direkt aus und schauen zu, was passiert. Dabei zeigt terraform plan vorher exakt, was passieren würde.
Ein apply ohne Blick auf den Plan ist ein Commit ohne Diff: Man weiß nicht, was gelöscht oder neu gebaut wird. Der Plan kostet Sekunden und verhindert teure Überraschungen.
📦 terraform plan zeigt jede Änderung mit einem Vorzeichen am Zeilenanfang. Plus bedeutet neu erstellen, Minus löschen, Tilde verändern. Etwa „+ aws_instance.web“ heißt: Diese Ressource wird neu gebaut, nicht nur geändert.
🔑 Drift wird erst im Plan sichtbar, also Abweichungen zwischen State und echter Infrastruktur. Der State ist Terraforms Datei, die Konfiguration und reale Ressourcen einander zuordnet. Wer eine Sicherheitsgruppe manuell in der Konsole ändert, sieht das im Plan als Tilde.
📈 Mit terraform plan -out=plan.tfplan wird der Plan als binäre Datei gespeichert. Sie enthält neben den Änderungen auch den damaligen Zustand. Anschließend setzt terraform apply plan.tfplan genau diesen Stand um, nichts anderes. Der Einsteigerirrtum: apply ohne Datei erneut ausführen und glauben, der zuvor gesehene Plan werde umgesetzt. Ohne Datei erzeugt apply einen neuen Plan. Hat sich die Realität inzwischen geändert, etwa durch einen Kollegen, wird etwas anderes ausgeführt als geprüft wurde. Deshalb gilt: prüfen, speichern, genau diese Datei anwenden. In Pipelines mit manueller Freigabe ist der gespeicherte Plan das Kontrollmittel: Geprüftes und Ausgeführtes sind identisch. Eine fest gepinnte Provider-Version hält Plan und Ausführung reproduzierbar.
Gespeichert heißt nicht bestätigt, sondern eingefroren: apply führt genau den geprüften Stand aus. Ohne Datei heißt apply „neu planen“, nie „wie gerade gesehen“.
📌 terraform plan · Plan-Datei · Drift
📚 Cloud von Grund auf · Tag 5 von 30
#Terraform #iac #devops
Ein apply ohne Blick auf den Plan ist ein Commit ohne Diff: Man weiß nicht, was gelöscht oder neu gebaut wird. Der Plan kostet Sekunden und verhindert teure Überraschungen.
📦 terraform plan zeigt jede Änderung mit einem Vorzeichen am Zeilenanfang. Plus bedeutet neu erstellen, Minus löschen, Tilde verändern. Etwa „+ aws_instance.web“ heißt: Diese Ressource wird neu gebaut, nicht nur geändert.
🔑 Drift wird erst im Plan sichtbar, also Abweichungen zwischen State und echter Infrastruktur. Der State ist Terraforms Datei, die Konfiguration und reale Ressourcen einander zuordnet. Wer eine Sicherheitsgruppe manuell in der Konsole ändert, sieht das im Plan als Tilde.
📈 Mit terraform plan -out=plan.tfplan wird der Plan als binäre Datei gespeichert. Sie enthält neben den Änderungen auch den damaligen Zustand. Anschließend setzt terraform apply plan.tfplan genau diesen Stand um, nichts anderes. Der Einsteigerirrtum: apply ohne Datei erneut ausführen und glauben, der zuvor gesehene Plan werde umgesetzt. Ohne Datei erzeugt apply einen neuen Plan. Hat sich die Realität inzwischen geändert, etwa durch einen Kollegen, wird etwas anderes ausgeführt als geprüft wurde. Deshalb gilt: prüfen, speichern, genau diese Datei anwenden. In Pipelines mit manueller Freigabe ist der gespeicherte Plan das Kontrollmittel: Geprüftes und Ausgeführtes sind identisch. Eine fest gepinnte Provider-Version hält Plan und Ausführung reproduzierbar.
Gespeichert heißt nicht bestätigt, sondern eingefroren: apply führt genau den geprüften Stand aus. Ohne Datei heißt apply „neu planen“, nie „wie gerade gesehen“.
📌 terraform plan · Plan-Datei · Drift
📚 Cloud von Grund auf · Tag 5 von 30
#Terraform #iac #devops
10 Std vor
Edge Computing funktioniert wie eine Werkstatt im Dorf statt einer Fabrik am anderen Ende des Landes. Alle Teile wandern sonst erst stundenlang per LKW hin und her; dabei geht die meiste Zeit für den Weg drauf.
Im Dorf steht die Werkstatt direkt neben dem Ernteplatz: Der Defekt wird vor Ort behoben, das Ergebnis sofort geliefert. Ein LKW wäre für die fertige Lösung schneller beladen als für den gesamten Erntewagen samt Stroh und Erde. Und bricht die Fernstraße ab, arbeitet die Dorfwerkstatt trotzdem weiter.
Fachlich entspricht das Dorfwerkstatt dem Edge-Gerät, einem Rechner nahe an Sensoren und Maschinen. Die Ernte steht für Rohdaten, das fertige Ergebnis für die Antwort. Die Fahrzeit ins zentrale Rechenzentrum ist die Latenz, also die Verzögerung zwischen Anfrage und Antwort. Die LKW-Ladefläche ist die Bandbreite, also die Datenmenge je Zeiteinheit.
In der Praxis gilt: Eine industrielle Schutzfunktion, die erst nach einer Sekunde reagiert, weil der Umweg übers Rechenzentrum dauert, ist wertlos. Die Entscheidung fällt mit drei Fragen: Muss die Antwort in Millisekunden kommen, sind die Rohdatenmengen zu groß für die Leitung, und muss die Anlage bei Netzausfall weiterlaufen?
Das Bild hat eine Grenze: Die Dorfwerkstatt braucht nur einen Schraubenschlüssel, das Edge-Gerät braucht Updates, Konfiguration und Sicherheitspatches an vielen verteilten Standorten. Edge spart keine Arbeit, sondern verschiebt sie vom Rechenzentrum an oft schwer zugängliche Orte.
Edge heißt also nicht Cloud ersetzen, sondern Rechnen dorthin verlagern, wo Zeit, Leitung oder Ausfall es verlangt.
📌 Latenz · Bandbreite · Ausfallsicherheit
📚 Zukunftstechnologien verstehen · Tag 5 von 30
#edgecomputing #architektur #DigitaleTransformation
Im Dorf steht die Werkstatt direkt neben dem Ernteplatz: Der Defekt wird vor Ort behoben, das Ergebnis sofort geliefert. Ein LKW wäre für die fertige Lösung schneller beladen als für den gesamten Erntewagen samt Stroh und Erde. Und bricht die Fernstraße ab, arbeitet die Dorfwerkstatt trotzdem weiter.
Fachlich entspricht das Dorfwerkstatt dem Edge-Gerät, einem Rechner nahe an Sensoren und Maschinen. Die Ernte steht für Rohdaten, das fertige Ergebnis für die Antwort. Die Fahrzeit ins zentrale Rechenzentrum ist die Latenz, also die Verzögerung zwischen Anfrage und Antwort. Die LKW-Ladefläche ist die Bandbreite, also die Datenmenge je Zeiteinheit.
In der Praxis gilt: Eine industrielle Schutzfunktion, die erst nach einer Sekunde reagiert, weil der Umweg übers Rechenzentrum dauert, ist wertlos. Die Entscheidung fällt mit drei Fragen: Muss die Antwort in Millisekunden kommen, sind die Rohdatenmengen zu groß für die Leitung, und muss die Anlage bei Netzausfall weiterlaufen?
Das Bild hat eine Grenze: Die Dorfwerkstatt braucht nur einen Schraubenschlüssel, das Edge-Gerät braucht Updates, Konfiguration und Sicherheitspatches an vielen verteilten Standorten. Edge spart keine Arbeit, sondern verschiebt sie vom Rechenzentrum an oft schwer zugängliche Orte.
Edge heißt also nicht Cloud ersetzen, sondern Rechnen dorthin verlagern, wo Zeit, Leitung oder Ausfall es verlangt.
📌 Latenz · Bandbreite · Ausfallsicherheit
📚 Zukunftstechnologien verstehen · Tag 5 von 30
#edgecomputing #architektur #DigitaleTransformation
12 Std vor
Der erste Docker-Build dauert Minuten, der zweite nur Sekunden – solange niemand die Anweisungsreihenfolge ändert. Dabei entscheidet oft allein die Reihenfolge im Dockerfile, ob der Cache greift oder nicht.
Das kennt jeder, der einmal ein Dockerfile (das Baurezept für ein Container-Image) geschrieben hat. Wer die Reihenfolge nicht versteht, wartet bei jeder kleinen Änderung wieder so lange wie beim ersten Mal.
Der Build-Cache ist ein Speicher für fertige Schichten. Ein Docker-Image besteht aus Schichten: Jede Anweisung wie FROM, RUN oder COPY erzeugt genau eine, die auf der vorherigen aufbaut. Beim Neubau prüft Docker jede Anweisung von oben nach unten und übernimmt unveränderte Schichten unverändert. Sobald sich eine Anweisung ändert, sind alle folgenden Schichten ungültig und werden neu gebaut – auch wenn sie selbst gleich geblieben sind.
Ein typisches Dockerfile für eine Node-Anwendung kopiert zuerst nur package.json, führt npm install aus und kopiert danach erst den Quellcode. Der Cache-Schlüssel einer Anweisung umfasst den Anweisungstext und den Inhalt kopierter Dateien: Ein geändertes package.json macht die Installations-Schicht ungültig, ein geänderter Quelltext nur die Kopier-Schicht. Eine reine Codeänderung baut also nur die letzte Schicht neu.
Verwechselt wird der Cache gern mit einem bloßen Zeitmesser. Er prüft keine Ähnlichkeit, sondern exakte Schlüssel. Steht COPY ganz oben, macht jede kleine Codeänderung die teure Installations-Schicht ungültig – und der Build dauert jedes Mal wie beim ersten Mal. Deshalb gilt: selten Geändertes wie das Basis-Image (das Image, auf dem das eigene aufbaut, etwa in der FROM-Anweisung) an den Anfang, häufig Geändertes wie den Quellcode an das Ende.
Der Build-Cache belohnt keine schönen Dockerfiles, sondern stabile Anweisungsreihen.
📌 Schichten · Cache-Schlüssel · Reihenfolge
📚 Cloud von Grund auf · Tag 5 von 30
#docker #devops #CloudHosting
Das kennt jeder, der einmal ein Dockerfile (das Baurezept für ein Container-Image) geschrieben hat. Wer die Reihenfolge nicht versteht, wartet bei jeder kleinen Änderung wieder so lange wie beim ersten Mal.
Der Build-Cache ist ein Speicher für fertige Schichten. Ein Docker-Image besteht aus Schichten: Jede Anweisung wie FROM, RUN oder COPY erzeugt genau eine, die auf der vorherigen aufbaut. Beim Neubau prüft Docker jede Anweisung von oben nach unten und übernimmt unveränderte Schichten unverändert. Sobald sich eine Anweisung ändert, sind alle folgenden Schichten ungültig und werden neu gebaut – auch wenn sie selbst gleich geblieben sind.
Ein typisches Dockerfile für eine Node-Anwendung kopiert zuerst nur package.json, führt npm install aus und kopiert danach erst den Quellcode. Der Cache-Schlüssel einer Anweisung umfasst den Anweisungstext und den Inhalt kopierter Dateien: Ein geändertes package.json macht die Installations-Schicht ungültig, ein geänderter Quelltext nur die Kopier-Schicht. Eine reine Codeänderung baut also nur die letzte Schicht neu.
Verwechselt wird der Cache gern mit einem bloßen Zeitmesser. Er prüft keine Ähnlichkeit, sondern exakte Schlüssel. Steht COPY ganz oben, macht jede kleine Codeänderung die teure Installations-Schicht ungültig – und der Build dauert jedes Mal wie beim ersten Mal. Deshalb gilt: selten Geändertes wie das Basis-Image (das Image, auf dem das eigene aufbaut, etwa in der FROM-Anweisung) an den Anfang, häufig Geändertes wie den Quellcode an das Ende.
Der Build-Cache belohnt keine schönen Dockerfiles, sondern stabile Anweisungsreihen.
📌 Schichten · Cache-Schlüssel · Reihenfolge
📚 Cloud von Grund auf · Tag 5 von 30
#docker #devops #CloudHosting
15 Std vor
Die meisten Einsteiger halten die State-Datei für ein nebensächliches Nebenprodukt von Terraform. Wer sie löscht, verliert damit das Gedächtnis über die eigene Cloud.
Viele denken, Terraform finde die realen Ressourcen sowieso in der Cloud. Das klingt plausibel, denn Instanzen und Netzwerke sind sichtbar in der Konsole.
Tatsächlich vergleicht Terraform bei jedem Lauf drei Dinge: den Soll-Zustand aus den .tf-Dateien, den Ist-Zustand aus dem State und den realen Zustand in der Cloud. Der State ist Terraforms Gedächtnis; er speichert für jede Ressource, was beim letzten apply, dem Befehl, der Änderungen ausführt, existierte. Ohne ihn weiß Terraform nicht, welche echte Instanz zu welcher Konfigurationszeile gehört.
Der Irrtum entsteht, weil die Ressourcen nach dem Löschen der Datei weiterlaufen. Erst der nächste apply zeigt die Folge: Neue, doppelte Ressourcen entstehen.
In der Konfiguration steht eine EC2-Instanz namens web-server. Nach dem apply landet die Instanz-ID der erzeugten Cloud-Instanz im State. Genau diese ID erlaubt Terraform später, dieselbe Instanz zu aktualisieren, statt eine neue zu bauen.
Woran man es erkennt: terraform plan meldet plötzlich, dass Ressourcen neu erstellt werden sollen, obwohl die Konfiguration unverändert ist. Nach dem darauffolgenden apply zeigt die Konsole dann doppelte Instanzen.
In Teams gehört der State in ein Remote-Backend wie S3, also eine zentrale Ablage, auf die alle zugreifen; Locking über DynamoDB oder S3-Lock-Dateien verhindert gleichzeitige Änderungen. Der State kann Klartext-Passwörter enthalten und ist ein Geheimnis.
State heißt nicht nebensächliches Nebenprodukt, sondern das Gedächtnis, das Konfiguration und reale Ressourcen verbindet. Verlorener State bedeutet: Die Cloud bleibt bestehen, aber Terraform kann sie nicht mehr zuordnen.
📌 State-Datei · Remote-Backend · Locking
📚 Cloud von Grund auf · Tag 5 von 30
#Terraform #iac #aws
Viele denken, Terraform finde die realen Ressourcen sowieso in der Cloud. Das klingt plausibel, denn Instanzen und Netzwerke sind sichtbar in der Konsole.
Tatsächlich vergleicht Terraform bei jedem Lauf drei Dinge: den Soll-Zustand aus den .tf-Dateien, den Ist-Zustand aus dem State und den realen Zustand in der Cloud. Der State ist Terraforms Gedächtnis; er speichert für jede Ressource, was beim letzten apply, dem Befehl, der Änderungen ausführt, existierte. Ohne ihn weiß Terraform nicht, welche echte Instanz zu welcher Konfigurationszeile gehört.
Der Irrtum entsteht, weil die Ressourcen nach dem Löschen der Datei weiterlaufen. Erst der nächste apply zeigt die Folge: Neue, doppelte Ressourcen entstehen.
In der Konfiguration steht eine EC2-Instanz namens web-server. Nach dem apply landet die Instanz-ID der erzeugten Cloud-Instanz im State. Genau diese ID erlaubt Terraform später, dieselbe Instanz zu aktualisieren, statt eine neue zu bauen.
Woran man es erkennt: terraform plan meldet plötzlich, dass Ressourcen neu erstellt werden sollen, obwohl die Konfiguration unverändert ist. Nach dem darauffolgenden apply zeigt die Konsole dann doppelte Instanzen.
In Teams gehört der State in ein Remote-Backend wie S3, also eine zentrale Ablage, auf die alle zugreifen; Locking über DynamoDB oder S3-Lock-Dateien verhindert gleichzeitige Änderungen. Der State kann Klartext-Passwörter enthalten und ist ein Geheimnis.
State heißt nicht nebensächliches Nebenprodukt, sondern das Gedächtnis, das Konfiguration und reale Ressourcen verbindet. Verlorener State bedeutet: Die Cloud bleibt bestehen, aber Terraform kann sie nicht mehr zuordnen.
📌 State-Datei · Remote-Backend · Locking
📚 Cloud von Grund auf · Tag 5 von 30
#Terraform #iac #aws
18 Std vor
Zehn Sekunden Codeänderung, dann wartet man fünf Minuten auf denselben Build. Schuld ist meist eine einzige Zeile an der falschen Stelle im Dockerfile.
Gemeint ist der Aufbau eines Container-Images aus einer Beschreibungsdatei, dem Dockerfile. Das Image ist die unveränderliche Vorlage, aus der Container gestartet werden. Jede Anweisung darin – etwa COPY zum Kopieren von Dateien oder RUN zum Ausführen eines Befehls – erzeugt eine eigene Schicht, und der Build-Cache entscheidet, welche davon neu berechnet werden muss.
Zuerst liest das Build-Werkzeug das Dockerfile von oben nach unten und prüft jede Anweisung gegen den Cache. Sind Anweisungstext und Inhalt kopierter Dateien unverändert, wird die vorhandene Schicht wiederverwendet. Das Ergebnis ist sofort da, ohne Rechenarbeit.
Dann stößt das Werkzeug auf die erste geänderte Anweisung, etwa ein neues COPY mit anderem Quellcode. Diese Schicht wird neu gebaut. Der Cache-Schlüssel umfasst dabei beide Teile: Anweisungstext und Dateiinhalte.
Danach sind alle folgenden Schichten ungültig, auch wenn sie selbst gleich geblieben sind. Steht die teure Installation der Abhängigkeiten unterhalb des Quellcode-Kopierens, muss sie bei jeder Codeänderung erneut laufen – der Build dauert dann wieder so lange wie beim ersten Mal.
Zuletzt dreht man die Reihenfolge um: erst die Abhängigkeitsliste wie package.json kopieren und installieren, danach erst den Quellcode. Eine reine Codeänderung baut dann nur noch die letzte Schicht neu, aus Minuten werden Sekunden. Eine .dockerignore-Datei hält zudem unnötige Dateien aus dem Build-Kontext fern.
Der Cache ist kein Automatik-Glück, sondern folgt der Reihenfolge der Anweisungen. Seltenes nach oben, Häufiges nach unten: Diese eine Sortierung entscheidet über die Dauer jedes Neubaus.
📌 Schichten · Cache-Schlüssel · Reihenfolge
📚 Cloud von Grund auf · Tag 5 von 30
#docker #devops #CloudHosting
Gemeint ist der Aufbau eines Container-Images aus einer Beschreibungsdatei, dem Dockerfile. Das Image ist die unveränderliche Vorlage, aus der Container gestartet werden. Jede Anweisung darin – etwa COPY zum Kopieren von Dateien oder RUN zum Ausführen eines Befehls – erzeugt eine eigene Schicht, und der Build-Cache entscheidet, welche davon neu berechnet werden muss.
Zuerst liest das Build-Werkzeug das Dockerfile von oben nach unten und prüft jede Anweisung gegen den Cache. Sind Anweisungstext und Inhalt kopierter Dateien unverändert, wird die vorhandene Schicht wiederverwendet. Das Ergebnis ist sofort da, ohne Rechenarbeit.
Dann stößt das Werkzeug auf die erste geänderte Anweisung, etwa ein neues COPY mit anderem Quellcode. Diese Schicht wird neu gebaut. Der Cache-Schlüssel umfasst dabei beide Teile: Anweisungstext und Dateiinhalte.
Danach sind alle folgenden Schichten ungültig, auch wenn sie selbst gleich geblieben sind. Steht die teure Installation der Abhängigkeiten unterhalb des Quellcode-Kopierens, muss sie bei jeder Codeänderung erneut laufen – der Build dauert dann wieder so lange wie beim ersten Mal.
Zuletzt dreht man die Reihenfolge um: erst die Abhängigkeitsliste wie package.json kopieren und installieren, danach erst den Quellcode. Eine reine Codeänderung baut dann nur noch die letzte Schicht neu, aus Minuten werden Sekunden. Eine .dockerignore-Datei hält zudem unnötige Dateien aus dem Build-Kontext fern.
Der Cache ist kein Automatik-Glück, sondern folgt der Reihenfolge der Anweisungen. Seltenes nach oben, Häufiges nach unten: Diese eine Sortierung entscheidet über die Dauer jedes Neubaus.
📌 Schichten · Cache-Schlüssel · Reihenfolge
📚 Cloud von Grund auf · Tag 5 von 30
#docker #devops #CloudHosting
19 Std vor
Viele Unternehmen speichern ihre Daten in der EU – und sind trotzdem nicht Herr über sie. Der Grund: Kontrolle entsteht nicht durch den Standort, sondern durch die Architektur.
Der Begriff digitale Souveränität begegnet Einsteigern in Ausschreibungen und in der Regulierung. Wer ihn nicht kennt, verwechselt Standorte mit Selbstbestimmung – und merkt es erst beim Anbieterwechsel.
Digitale Souveränität ist die Fähigkeit, über eigene Daten, Systeme und digitale Abhängigkeiten selbstbestimmt zu entscheiden. Sie funktioniert wie ein Portfolio prüfbarer Kontrolle mit vier Fragen: Wer kann auf die Daten zugreifen? Wer kontrolliert die Systeme, welche Fähigkeiten sind nötig, und wie austauschbar ist die Lieferkette?
Ein Unternehmen speichert Kundendaten in einem EU-Rechenzentrum. Trotzdem kann es ohne die Hilfe des US-Muttersoftwarehauses weder Daten in einem gängigen Format exportieren noch den Betrieb fortführen. Der Standort ist souverän, die Architektur nicht. Artikel 20 DSGVO gibt den Menschen, von denen Daten stammen (DSGVO: betroffene Personen), das Recht auf ihre Daten in strukturiertem, maschinenlesbarem Format. Der Data Act (Verordnung (EU) 2023/2854) erleichtert den Wechsel zwischen Datenverarbeitungsdiensten, mit Vorgaben zu Wechselgebühren und Übergangsfristen.
Verwechselt wird Souveränität oft mit Abschottung. Gemeint ist selbstbestimmtes Entscheiden über Abhängigkeiten – nicht der Verzicht auf Cloud-Dienste oder ausländische Anbieter. Offene, dokumentierte Datenformate schaffen Portabilität. Eine Exit-Strategie je kritischem Dienst – Datenexport, Alternativanbieter, Übergangsbetrieb – wird vor dem Einstieg geplant.
Digitale Souveränität ist nicht die EU-Flagge über dem Rechenzentrum, sondern die beantwortbare Frage: Können wir morgen ohne diesen Anbieter weiterarbeiten?
📌 Vier Prüffragen · Portabilität · Exit-Strategie
📚 Zukunftstechnologien verstehen · Tag 5 von 30
#Souveraenitaet #strategie
Der Begriff digitale Souveränität begegnet Einsteigern in Ausschreibungen und in der Regulierung. Wer ihn nicht kennt, verwechselt Standorte mit Selbstbestimmung – und merkt es erst beim Anbieterwechsel.
Digitale Souveränität ist die Fähigkeit, über eigene Daten, Systeme und digitale Abhängigkeiten selbstbestimmt zu entscheiden. Sie funktioniert wie ein Portfolio prüfbarer Kontrolle mit vier Fragen: Wer kann auf die Daten zugreifen? Wer kontrolliert die Systeme, welche Fähigkeiten sind nötig, und wie austauschbar ist die Lieferkette?
Ein Unternehmen speichert Kundendaten in einem EU-Rechenzentrum. Trotzdem kann es ohne die Hilfe des US-Muttersoftwarehauses weder Daten in einem gängigen Format exportieren noch den Betrieb fortführen. Der Standort ist souverän, die Architektur nicht. Artikel 20 DSGVO gibt den Menschen, von denen Daten stammen (DSGVO: betroffene Personen), das Recht auf ihre Daten in strukturiertem, maschinenlesbarem Format. Der Data Act (Verordnung (EU) 2023/2854) erleichtert den Wechsel zwischen Datenverarbeitungsdiensten, mit Vorgaben zu Wechselgebühren und Übergangsfristen.
Verwechselt wird Souveränität oft mit Abschottung. Gemeint ist selbstbestimmtes Entscheiden über Abhängigkeiten – nicht der Verzicht auf Cloud-Dienste oder ausländische Anbieter. Offene, dokumentierte Datenformate schaffen Portabilität. Eine Exit-Strategie je kritischem Dienst – Datenexport, Alternativanbieter, Übergangsbetrieb – wird vor dem Einstieg geplant.
Digitale Souveränität ist nicht die EU-Flagge über dem Rechenzentrum, sondern die beantwortbare Frage: Können wir morgen ohne diesen Anbieter weiterarbeiten?
📌 Vier Prüffragen · Portabilität · Exit-Strategie
📚 Zukunftstechnologien verstehen · Tag 5 von 30
#Souveraenitaet #strategie
21 Std vor
Die Konfiguration beschreibt, was sein soll. Der State merkt sich, was bereits echt existiert.
Beide sind Dateien mit Ressourcen drin, deshalb hält man sie für dasselbe. Doch sie beantworten verschiedene Fragen: den Soll-Zustand und den Ist-Stand.
Die Konfiguration ist der Bauplan: In Terraform-Dateien steht in deklarativer Sprache, was entstehen soll, etwa eine Security-Group, also eine Firewall-Regelgruppe in AWS. Sie beschreibt Eigenschaften, aber keine konkreten Cloud-Objekte. Ein Beispiel: eine Regel, die einen Port für HTTPS freigibt. Terraform liest sie bei jedem Lauf neu ein.
Der State ist das Gedächtnis von Terraform: eine Datei, die für jede Ressource der Konfiguration festhält, welche echte Ressource in der Cloud dazugehört, etwa über deren konkrete ID. Steht dort eine Security-Group mit einer ID, kennt Terraform genau dieses Objekt. Fehlt der State, kann Terraform bestehende Ressourcen nicht mehr verwalten.
Die Konfiguration ist der Wunsch, der State die Zuordnung zur Wirklichkeit. Beim Plan vergleicht Terraform drei Dinge – Konfiguration, State und reale Ressourcen – und leitet daraus die Änderungen ab.
Faustregel: Wer Änderungen plant, braucht zuerst einen aktuellen State, sonst sind Plan und Wirklichkeit auseinander. Deshalb liegt der State zentral in einem Remote-Backend wie S3, einem Speicher, den alle Beteiligten gemeinsam nutzen.
Vorsicht: Der State kann Passwörter im Klartext enthalten und ist wie ein Geheimnis zu schützen. Löschen ist keine Aufräumlösung, sondern verwirft nur das Gedächtnis und erzeugt Duplikate.
Der State ist nicht die Konfiguration, sondern das Gedächtnis, das beide verbindet. Ohne ihn weiß Terraform nicht, was es selbst angelegt hat.
📌 Konfiguration · State · Remote-Backend
📚 Cloud von Grund auf · Tag 5 von 30
#Terraform #iac #devops #CloudSecurity
Beide sind Dateien mit Ressourcen drin, deshalb hält man sie für dasselbe. Doch sie beantworten verschiedene Fragen: den Soll-Zustand und den Ist-Stand.
Die Konfiguration ist der Bauplan: In Terraform-Dateien steht in deklarativer Sprache, was entstehen soll, etwa eine Security-Group, also eine Firewall-Regelgruppe in AWS. Sie beschreibt Eigenschaften, aber keine konkreten Cloud-Objekte. Ein Beispiel: eine Regel, die einen Port für HTTPS freigibt. Terraform liest sie bei jedem Lauf neu ein.
Der State ist das Gedächtnis von Terraform: eine Datei, die für jede Ressource der Konfiguration festhält, welche echte Ressource in der Cloud dazugehört, etwa über deren konkrete ID. Steht dort eine Security-Group mit einer ID, kennt Terraform genau dieses Objekt. Fehlt der State, kann Terraform bestehende Ressourcen nicht mehr verwalten.
Die Konfiguration ist der Wunsch, der State die Zuordnung zur Wirklichkeit. Beim Plan vergleicht Terraform drei Dinge – Konfiguration, State und reale Ressourcen – und leitet daraus die Änderungen ab.
Faustregel: Wer Änderungen plant, braucht zuerst einen aktuellen State, sonst sind Plan und Wirklichkeit auseinander. Deshalb liegt der State zentral in einem Remote-Backend wie S3, einem Speicher, den alle Beteiligten gemeinsam nutzen.
Vorsicht: Der State kann Passwörter im Klartext enthalten und ist wie ein Geheimnis zu schützen. Löschen ist keine Aufräumlösung, sondern verwirft nur das Gedächtnis und erzeugt Duplikate.
Der State ist nicht die Konfiguration, sondern das Gedächtnis, das beide verbindet. Ohne ihn weiß Terraform nicht, was es selbst angelegt hat.
📌 Konfiguration · State · Remote-Backend
📚 Cloud von Grund auf · Tag 5 von 30
#Terraform #iac #devops #CloudSecurity
1 Tag vor
Terraform funktioniert wie ein Stadtplaner mit einem Grundbuch. Ohne das Grundbuch wüsste er nicht, welche Grundstücke ihm überhaupt gehören.
Das Grundbuch verzeichnet jedes Grundstück mit Nummer, Besitzer und aktuellem Zustand. Will der Planer ein Haus umbauen, schlägt er erst nach: Ist das Grundstück bereits eingetragen? Ist der Zustand dort noch aktuell? Erst dann entscheidet er, ob gebaut, umgebaut oder abgerissen wird.
Bei Terraform heißt das Grundbuch State: eine Datei mit der Zuordnung zwischen dem Namen in der Konfiguration, also den Textdateien, die Infrastruktur beschreiben, und der realen Ressource in der Cloud. Bei jedem terraform plan oder terraform apply vergleicht Terraform drei Dinge: den gewünschten Zustand, den gespeicherten Ist-Zustand und die echte Cloud. Aus der Differenz ergibt sich, was erstellt, geändert oder gelöscht wird.
Konkret: In der Konfiguration steht eine EC2-Instanz (virtuelle Maschine bei AWS) mit dem Namen webserver. Im State liegt dazu die ID der realen Instanz, etwa i-abc123. Nur über diese Zuordnung findet Terraform die Instanz wieder, wenn sie verkleinert oder gelöscht werden soll. Löscht jemand die Instanz in der Konsole, meldet terraform plan die Abweichung und schlägt vor, sie neu zu erstellen.
Das Bild hat eine Grenze: Ein Grundbuch kann von Hand weitergeschrieben werden, der State nicht. Jede manuelle Änderung zerstört die Zuordnung. Deshalb gilt in der Praxis: State im verschlüsselten Backend (zentraler Ablageort) speichern, Zugriff strikt begrenzen.
Der State ist Terraforms Gedächtnis, kein Protokoll. Er wird geschützt, geteilt und nie von Hand editiert.
📌 State · Backend · Zuordnung
📚 Cloud von Grund auf · Tag 5 von 30
#Terraform #iac #CloudSecurity
Das Grundbuch verzeichnet jedes Grundstück mit Nummer, Besitzer und aktuellem Zustand. Will der Planer ein Haus umbauen, schlägt er erst nach: Ist das Grundstück bereits eingetragen? Ist der Zustand dort noch aktuell? Erst dann entscheidet er, ob gebaut, umgebaut oder abgerissen wird.
Bei Terraform heißt das Grundbuch State: eine Datei mit der Zuordnung zwischen dem Namen in der Konfiguration, also den Textdateien, die Infrastruktur beschreiben, und der realen Ressource in der Cloud. Bei jedem terraform plan oder terraform apply vergleicht Terraform drei Dinge: den gewünschten Zustand, den gespeicherten Ist-Zustand und die echte Cloud. Aus der Differenz ergibt sich, was erstellt, geändert oder gelöscht wird.
Konkret: In der Konfiguration steht eine EC2-Instanz (virtuelle Maschine bei AWS) mit dem Namen webserver. Im State liegt dazu die ID der realen Instanz, etwa i-abc123. Nur über diese Zuordnung findet Terraform die Instanz wieder, wenn sie verkleinert oder gelöscht werden soll. Löscht jemand die Instanz in der Konsole, meldet terraform plan die Abweichung und schlägt vor, sie neu zu erstellen.
Das Bild hat eine Grenze: Ein Grundbuch kann von Hand weitergeschrieben werden, der State nicht. Jede manuelle Änderung zerstört die Zuordnung. Deshalb gilt in der Praxis: State im verschlüsselten Backend (zentraler Ablageort) speichern, Zugriff strikt begrenzen.
Der State ist Terraforms Gedächtnis, kein Protokoll. Er wird geschützt, geteilt und nie von Hand editiert.
📌 State · Backend · Zuordnung
📚 Cloud von Grund auf · Tag 5 von 30
#Terraform #iac #CloudSecurity
1 Tag vor
Viele Einsteiger warten bei jeder kleinen Codeänderung erneut auf die komplette Paketinstallation. Dabei reicht eine andere Reihenfolge der Befehle, damit fast alles aus dem Cache kommt.
Nach dem Ändern einer einzigen Quellcodezeile läuft der komplette Build von vorn. Pakete werden wieder heruntergeladen, obwohl sie schon im vorherigen Build steckten.
Ein Dockerfile ist eine Schritt-für-Schritt-Anleitung, wie ein Image gebaut wird. Jeder Befehl erzeugt eine Schicht, also einen festen Layer im Image. Docker nutzt einen Build-Cache: Eine Schicht wird nur neu gebaut, wenn sich ihr Befehl oder die hineinkopierten Dateien geändert haben. Der Cache wird von oben nach unten geprüft – ab der ersten veränderten Schicht muss alles Folgende neu gebaut werden, auch wenn die Befehle gleich bleiben.
Ein typisches Dockerfile beginnt mit COPY des kompletten Quellcodes und installiert danach erst die Pakete mit RUN apt-get install. Jede noch so kleine Codeänderung trifft die erste Schicht und invalidiert alle folgenden. Die Paketinstallation läuft bei jedem Build erneut. Dreht man die Reihenfolge um – erst Pakete installieren, dann den Code kopieren – bleibt die teure Installation im Cache, wenn nur eine Codezeile geändert wird.
So prüft man es: Beim zweiten Build ohne Änderungen sollte Docker jeden Schritt aus dem Cache beantworten. Nach einer Codezeilen-Änderung dürfen nur die Schichten ab dem COPY neu laufen.
Erst das Seltene, dann das Häufige gehört ins Dockerfile. Häufig Geändertes gehört ans Ende des Dockerfiles, nicht an den Anfang.
📌 Build-Cache · Schichten · Befehlsreihenfolge
📚 Cloud von Grund auf · Tag 5 von 30
#docker #devops #CloudHosting
Nach dem Ändern einer einzigen Quellcodezeile läuft der komplette Build von vorn. Pakete werden wieder heruntergeladen, obwohl sie schon im vorherigen Build steckten.
Ein Dockerfile ist eine Schritt-für-Schritt-Anleitung, wie ein Image gebaut wird. Jeder Befehl erzeugt eine Schicht, also einen festen Layer im Image. Docker nutzt einen Build-Cache: Eine Schicht wird nur neu gebaut, wenn sich ihr Befehl oder die hineinkopierten Dateien geändert haben. Der Cache wird von oben nach unten geprüft – ab der ersten veränderten Schicht muss alles Folgende neu gebaut werden, auch wenn die Befehle gleich bleiben.
Ein typisches Dockerfile beginnt mit COPY des kompletten Quellcodes und installiert danach erst die Pakete mit RUN apt-get install. Jede noch so kleine Codeänderung trifft die erste Schicht und invalidiert alle folgenden. Die Paketinstallation läuft bei jedem Build erneut. Dreht man die Reihenfolge um – erst Pakete installieren, dann den Code kopieren – bleibt die teure Installation im Cache, wenn nur eine Codezeile geändert wird.
So prüft man es: Beim zweiten Build ohne Änderungen sollte Docker jeden Schritt aus dem Cache beantworten. Nach einer Codezeilen-Änderung dürfen nur die Schichten ab dem COPY neu laufen.
Erst das Seltene, dann das Häufige gehört ins Dockerfile. Häufig Geändertes gehört ans Ende des Dockerfiles, nicht an den Anfang.
📌 Build-Cache · Schichten · Befehlsreihenfolge
📚 Cloud von Grund auf · Tag 5 von 30
#docker #devops #CloudHosting
1 Tag vor
Ein Docker-Image ist die Vorlage, aus der Container gestartet werden; ein rasanter Neubau wirkt wie Magie. In Wahrheit ist es nur der Zwischenspeicher, der unveränderte Schichten wiederverwendet.
Wer sein erstes Dockerfile, die Schritt-für-Schritt-Bauanleitung für ein Image, schreibt, baut oft von Grund auf neu und staunt über die Wartezeit. Das kostet in jeder Continuous-Integration-Pipeline, die jede Codeänderung automatisch baut und testet, unnötig Zeit.
Ein Layer ist eine Schicht, ein Zwischenstand des Dateisystems, den Docker beim Bauen einzeln speichert. Jede Dockerfile-Anweisung wie RUN, COPY oder ADD erzeugt eine eigene Schicht; ein Dockerfile beschreibt Schritt für Schritt, wie das Image gebaut wird. Trifft der Zwischenspeicher auf eine bekannte Schicht, wird sie nicht neu gebaut, sondern direkt verwendet.
Weil jede Schicht auf dem Ergebnis der vorherigen aufbaut, gilt: Sobald eine Schicht geändert wurde, werden diese und alle folgenden Schichten neu gebaut. Beim COPY-Schritt entscheidet dabei allein der Inhalt der kopierten Dateien über den Treffer, nicht der Name des Schritts. Ein Dockerfile beginnt daher mit dem selten geänderten RUN-Schritt zum Installieren der Pakete, denn das ändert sich selten. Der eigene Quellcode mit COPY zu kopieren gehört ans Ende: Weil sich Code bei jedem Commit ändert, machen früh kopierte Dateien alle späteren Schichten ungültig. Der Zwischenspeicher nützt dann nichts.
Verwechselt wird der Layer mit dem fertigen Image, der unveränderlichen Vorlage für Container. Das Image besteht aus der gesamten Kette dieser Schichten; der Layer ist ein einzelner Baustein davon.
Der Bau ist nicht jedes Mal ein Neuanfang, sondern ein Abgleich von Schichten. Genau deshalb steht der Quellcode im Dockerfile ganz am Ende.
📌 Layer · COPY · Pipeline
📚 Cloud von Grund auf · Tag 5 von 30
#docker #iac #devops
Wer sein erstes Dockerfile, die Schritt-für-Schritt-Bauanleitung für ein Image, schreibt, baut oft von Grund auf neu und staunt über die Wartezeit. Das kostet in jeder Continuous-Integration-Pipeline, die jede Codeänderung automatisch baut und testet, unnötig Zeit.
Ein Layer ist eine Schicht, ein Zwischenstand des Dateisystems, den Docker beim Bauen einzeln speichert. Jede Dockerfile-Anweisung wie RUN, COPY oder ADD erzeugt eine eigene Schicht; ein Dockerfile beschreibt Schritt für Schritt, wie das Image gebaut wird. Trifft der Zwischenspeicher auf eine bekannte Schicht, wird sie nicht neu gebaut, sondern direkt verwendet.
Weil jede Schicht auf dem Ergebnis der vorherigen aufbaut, gilt: Sobald eine Schicht geändert wurde, werden diese und alle folgenden Schichten neu gebaut. Beim COPY-Schritt entscheidet dabei allein der Inhalt der kopierten Dateien über den Treffer, nicht der Name des Schritts. Ein Dockerfile beginnt daher mit dem selten geänderten RUN-Schritt zum Installieren der Pakete, denn das ändert sich selten. Der eigene Quellcode mit COPY zu kopieren gehört ans Ende: Weil sich Code bei jedem Commit ändert, machen früh kopierte Dateien alle späteren Schichten ungültig. Der Zwischenspeicher nützt dann nichts.
Verwechselt wird der Layer mit dem fertigen Image, der unveränderlichen Vorlage für Container. Das Image besteht aus der gesamten Kette dieser Schichten; der Layer ist ein einzelner Baustein davon.
Der Bau ist nicht jedes Mal ein Neuanfang, sondern ein Abgleich von Schichten. Genau deshalb steht der Quellcode im Dockerfile ganz am Ende.
📌 Layer · COPY · Pipeline
📚 Cloud von Grund auf · Tag 5 von 30
#docker #iac #devops
1 Tag vor
Viele geben beiden Sonden denselben Endpunkt und glauben, gut gerüstet zu sein. Dabei verursacht genau das die Neustartschleifen, die eine Anwendung in den Ausfall treiben.
Viele denken, Kubernetes brauche eine einzige Gesundheitsprüfung, denn gesund ist gesund. Plausibel klingt das, weil beide Sonden denselben HTTP-Aufruf machen, etwa GET /healthz mit Antwortcode 200 bis 399 als Erfolg.
Tatsächlich stellen die Sonden zwei verschiedene Fragen. Die Liveness-Probe (Lebenssonde) prüft, ob der Container überhaupt noch funktionsfähig ist oder durch einen Neustart repariert werden kann. Die Readiness-Probe (Bereitschaftsonde) prüft, ob er gerade Verkehr annehmen darf. Schlägt Readiness fehl, nimmt der Kubelet – der Agent auf jedem Knoten, der Container startet und überwacht – den Pod (die kleinste Einheit in Kubernetes) aus den Endpoints des Service; der Container läuft weiter, es kommt nur kein Verkehr mehr an.
Der Irrtum entsteht, weil beide Prüfungen technisch identisch aussehen. Was fehlt, ist die Frage nach der Folge: Neustart oder Pause.
Eine Anwendung lädt beim Start große Datenmengen und antwortet noch nicht. Wer hier Liveness mit Readiness gleichschaltet, startet den Container neu, obwohl er nur Zeit bräuchte. Noch schlimmer: Eine Liveness-Probe, die die externe Datenbank mitprüft, löst bei deren Ausfall eine Neustartschleife aus, die nichts behebt. Abhängigkeiten gehören deshalb in die Readiness-Probe.
Woran man es erkennt: Mit den Standardwerten gilt ein Container nach drei aufeinanderfolgenden Fehlversuchen im Abstand von zehn Sekunden als nicht gesund. Wer Container im Kreis drehen sieht, obwohl sie nur langsam starten, hat Liveness zu scharf gestellt.
Liveness heißt nicht „alles prüfen, was wichtig ist“, sondern „nur prüfen, was ein Neustart reparieren kann“.
📌 Liveness vs. Readiness · Kubelet · failureThreshold 3
📚 Cloud von Grund auf · Tag 4 von 30
#kubernetes #devops #sre
Viele denken, Kubernetes brauche eine einzige Gesundheitsprüfung, denn gesund ist gesund. Plausibel klingt das, weil beide Sonden denselben HTTP-Aufruf machen, etwa GET /healthz mit Antwortcode 200 bis 399 als Erfolg.
Tatsächlich stellen die Sonden zwei verschiedene Fragen. Die Liveness-Probe (Lebenssonde) prüft, ob der Container überhaupt noch funktionsfähig ist oder durch einen Neustart repariert werden kann. Die Readiness-Probe (Bereitschaftsonde) prüft, ob er gerade Verkehr annehmen darf. Schlägt Readiness fehl, nimmt der Kubelet – der Agent auf jedem Knoten, der Container startet und überwacht – den Pod (die kleinste Einheit in Kubernetes) aus den Endpoints des Service; der Container läuft weiter, es kommt nur kein Verkehr mehr an.
Der Irrtum entsteht, weil beide Prüfungen technisch identisch aussehen. Was fehlt, ist die Frage nach der Folge: Neustart oder Pause.
Eine Anwendung lädt beim Start große Datenmengen und antwortet noch nicht. Wer hier Liveness mit Readiness gleichschaltet, startet den Container neu, obwohl er nur Zeit bräuchte. Noch schlimmer: Eine Liveness-Probe, die die externe Datenbank mitprüft, löst bei deren Ausfall eine Neustartschleife aus, die nichts behebt. Abhängigkeiten gehören deshalb in die Readiness-Probe.
Woran man es erkennt: Mit den Standardwerten gilt ein Container nach drei aufeinanderfolgenden Fehlversuchen im Abstand von zehn Sekunden als nicht gesund. Wer Container im Kreis drehen sieht, obwohl sie nur langsam starten, hat Liveness zu scharf gestellt.
Liveness heißt nicht „alles prüfen, was wichtig ist“, sondern „nur prüfen, was ein Neustart reparieren kann“.
📌 Liveness vs. Readiness · Kubelet · failureThreshold 3
📚 Cloud von Grund auf · Tag 4 von 30
#kubernetes #devops #sre
2 Tage vor
Ein Container läuft nicht einfach irgendwie – er bekommt Ressourcen zugesichert und begrenzt. Wer beides verwechselt, wundert sich später über abrupte Neustarts.
In Kubernetes wird beim Start jedes Containers festgelegt, wie viel CPU und Speicher ihm garantiert und wie viel er höchstens verbrauchen darf. Das betrifft jede Web-Anwendung, jeden Job, jeden Dienst im Cluster – einem Cluster, einer Gruppe von Rechnern, die Container gemeinsam betreiben.
Zuerst definiert man die Requests: die Mengen an CPU und Speicher, die der Scheduler, die Komponente, die Container auf Knoten verteilt, fest einplant und garantiert. CPU misst man in Millicores: 1000m sind ein voller Kern, 500m die Hälfte. Speicher steht in Bytes, etwa mit dem Suffix Mi für Mebibyte.
Dann prüft der Scheduler anhand der Requests, ob ein Knoten noch Platz hat. Er kennt die Limits bei der Platzierung nicht. Fehlen Requests, bucht er Knoten über, weil er den Bedarf nicht kennt – Engpässe treten dann erst zur Laufzeit auf.
Danach läuft der Container und darf über seinen Request hinaus wachsen, solange Ressourcen frei sind. Ein Beispiel: Request 100m CPU und 128Mi Speicher, Limit 500m und 256Mi. Kurzzeitig darf er also auf das Fünffache der zugesicherten CPU wachsen.
Zuletzt greifen die Limits zur Laufzeit. Überschreitet der Container sein Speicher-Limit, beendet ihn der Kernel sofort per OOM-Kill und Kubernetes startet ihn neu. Am CPU-Limit wird er nicht beendet, sondern gedrosselt: Er läuft langsamer, arbeitet aber weiter. Pods ganz ohne Werte erhalten die Klasse BestEffort und werden bei Speicherknappheit zuerst verdrängt.
Requests sind das Versprechen an den Scheduler, Limits die Grenze im Betrieb. Wer Limits als Requests deutet, plant Knoten falsch voll; wer beides weglässt, überlässt die Verteilung dem Zufall.
📌 Request · Limit · OOM-Kill
📚 Cloud von Grund auf · Tag 4 von 30
#kubernetes #devops #CloudHosting
In Kubernetes wird beim Start jedes Containers festgelegt, wie viel CPU und Speicher ihm garantiert und wie viel er höchstens verbrauchen darf. Das betrifft jede Web-Anwendung, jeden Job, jeden Dienst im Cluster – einem Cluster, einer Gruppe von Rechnern, die Container gemeinsam betreiben.
Zuerst definiert man die Requests: die Mengen an CPU und Speicher, die der Scheduler, die Komponente, die Container auf Knoten verteilt, fest einplant und garantiert. CPU misst man in Millicores: 1000m sind ein voller Kern, 500m die Hälfte. Speicher steht in Bytes, etwa mit dem Suffix Mi für Mebibyte.
Dann prüft der Scheduler anhand der Requests, ob ein Knoten noch Platz hat. Er kennt die Limits bei der Platzierung nicht. Fehlen Requests, bucht er Knoten über, weil er den Bedarf nicht kennt – Engpässe treten dann erst zur Laufzeit auf.
Danach läuft der Container und darf über seinen Request hinaus wachsen, solange Ressourcen frei sind. Ein Beispiel: Request 100m CPU und 128Mi Speicher, Limit 500m und 256Mi. Kurzzeitig darf er also auf das Fünffache der zugesicherten CPU wachsen.
Zuletzt greifen die Limits zur Laufzeit. Überschreitet der Container sein Speicher-Limit, beendet ihn der Kernel sofort per OOM-Kill und Kubernetes startet ihn neu. Am CPU-Limit wird er nicht beendet, sondern gedrosselt: Er läuft langsamer, arbeitet aber weiter. Pods ganz ohne Werte erhalten die Klasse BestEffort und werden bei Speicherknappheit zuerst verdrängt.
Requests sind das Versprechen an den Scheduler, Limits die Grenze im Betrieb. Wer Limits als Requests deutet, plant Knoten falsch voll; wer beides weglässt, überlässt die Verteilung dem Zufall.
📌 Request · Limit · OOM-Kill
📚 Cloud von Grund auf · Tag 4 von 30
#kubernetes #devops #CloudHosting
2 Tage vor
Pods und Services klingen ähnlich, gehören aber zu verschiedenen Welten. Der eine ist ein Arbeiter, der kommt und geht – der andere ist das Schild am Gebäude.
Verwechselt werden beide, weil sie im Alltag zusammen auftreten. Immer wenn eine Anwendung Pods startet, steht ein Service davor.
Ein Pod ist die kleinste Einheit in Kubernetes und enthält einen oder mehrere Container, die sich Netzwerk und Speicher teilen. Ein Deployment hält eine gewünschte Anzahl gleicher Pods am Laufen. Pods sind bewusst kurzlebig: Bei jedem Update, bei Knotenausfall oder Neustart ersetzt Kubernetes alte Pods durch neue – und jeder neue Pod erhält eine neue Cluster-IP. Ein Webshop-Deployment verwaltet etwa drei Pods, von denen jeder Neustart mit einer frischen IP startet.
Ein Service ist dagegen eine feste Adresse für diese wechselnde Gruppe. Er besitzt eine eigene IP-Adresse und einen DNS-Namen (DNS übersetzt Namen in IP-Adressen) innerhalb des Clusters, die sich nicht ändern, solange der Service existiert. Der Service wählt seine Pods über ein Label-Selektor-Kriterium aus: Alle Pods mit einem bestimmten Label gehören zur Gruppe. Der Service „frontend“ verteilt alle Aufrufe von „frontend“ immer auf einen der gerade laufenden Pods – egal, wer gerade neu gestartet wurde.
Der Pod liefert die Arbeit, der Service liefert die Erreichbarkeit. Pod-IPs bleiben hinter dem Service verborgen; fällt ein Pod aus, wandern seine Anfragen automatisch zu den verbleibenden.
Faustregel: Pods nie direkt adressieren, sondern immer über den Service – eine Pod-IP in einer Konfiguration ist nach dem nächsten Neustart unbrauchbar.
Der Service heißt nicht Lastverteiler für Container, sondern feste Anlaufstelle vor kurzlebigen Pods.
📌 Pod · Service · Label-Selektor
📚 Cloud von Grund auf · Tag 4 von 30
#kubernetes #CloudHosting #devops
Verwechselt werden beide, weil sie im Alltag zusammen auftreten. Immer wenn eine Anwendung Pods startet, steht ein Service davor.
Ein Pod ist die kleinste Einheit in Kubernetes und enthält einen oder mehrere Container, die sich Netzwerk und Speicher teilen. Ein Deployment hält eine gewünschte Anzahl gleicher Pods am Laufen. Pods sind bewusst kurzlebig: Bei jedem Update, bei Knotenausfall oder Neustart ersetzt Kubernetes alte Pods durch neue – und jeder neue Pod erhält eine neue Cluster-IP. Ein Webshop-Deployment verwaltet etwa drei Pods, von denen jeder Neustart mit einer frischen IP startet.
Ein Service ist dagegen eine feste Adresse für diese wechselnde Gruppe. Er besitzt eine eigene IP-Adresse und einen DNS-Namen (DNS übersetzt Namen in IP-Adressen) innerhalb des Clusters, die sich nicht ändern, solange der Service existiert. Der Service wählt seine Pods über ein Label-Selektor-Kriterium aus: Alle Pods mit einem bestimmten Label gehören zur Gruppe. Der Service „frontend“ verteilt alle Aufrufe von „frontend“ immer auf einen der gerade laufenden Pods – egal, wer gerade neu gestartet wurde.
Der Pod liefert die Arbeit, der Service liefert die Erreichbarkeit. Pod-IPs bleiben hinter dem Service verborgen; fällt ein Pod aus, wandern seine Anfragen automatisch zu den verbleibenden.
Faustregel: Pods nie direkt adressieren, sondern immer über den Service – eine Pod-IP in einer Konfiguration ist nach dem nächsten Neustart unbrauchbar.
Der Service heißt nicht Lastverteiler für Container, sondern feste Anlaufstelle vor kurzlebigen Pods.
📌 Pod · Service · Label-Selektor
📚 Cloud von Grund auf · Tag 4 von 30
#kubernetes #CloudHosting #devops
2 Tage vor
Ein Deployment funktioniert wie ein Vorarbeiter, der eine Personalplanung im Kopf hat. Er weiß, wie viele Leute arbeiten sollen, und meldet sofort, wenn jemand fehlt.
Der Vorarbeiter hat einen Plan: Drei Arbeiter an einer Station. Kommt einer nicht, schickt er einen Ersatz. Der Ersatz übernimmt dieselbe Aufgabe, ohne dass jemand nachfragen muss. Der Vorarbeiter prüft dabei nicht die Stimmung oder die Leistung. Er zählt nur: Sind noch drei da? Solange die Zahl stimmt, greift er nicht ein.
In Kubernetes ist der Vorarbeiter das Deployment, eine Verwaltungseinheit für gleichartige Pods. Der Pod ist die kleinste betreibbare Einheit und umhüllt einen oder mehrere Container, also Anwendungen samt Abhängigkeiten. Der Plan steckt im Feld replicas: Dort steht die Soll-Stärke, etwa die Zahl drei. Fällt ein Pod aus, startet das Deployment automatisch einen neuen. Kubernetes verteilt die Pods dabei auf die Knoten, die Arbeitsrechner des Clusters.
Ein Deployment für eine Webanwendung mit replicas: 3 erzeugt drei gleiche Pods. Stürzt einer ab, läuft die Zahl ohne Eingriff auf drei zurück. Die Container eines Pods teilen sich eine IP-Adresse und reden über localhost miteinander.
Das Bild hat eine Grenze: Ein Arbeiter bleibt derselbe Mensch, ein ersetzter Pod ist eine neue Instanz mit neuer IP-Adresse. Der Vorarbeiter delegiert auch aktiv, das Deployment vergleicht nur Ist und Soll. Stabile Adressen für Anfragen liefert deshalb ein Kubernetes-Service.
Pods also nie von Hand starten: Wer replicas selbst überwacht, ersetzt keine ausgefallenen Pods. Deployment heißt nicht Pod, sondern Soll-Stärke, die Kubernetes von selbst hält.
📌 Pod · Deployment · replicas
📚 Cloud von Grund auf · Tag 4 von 30
#kubernetes #devops #docker
Der Vorarbeiter hat einen Plan: Drei Arbeiter an einer Station. Kommt einer nicht, schickt er einen Ersatz. Der Ersatz übernimmt dieselbe Aufgabe, ohne dass jemand nachfragen muss. Der Vorarbeiter prüft dabei nicht die Stimmung oder die Leistung. Er zählt nur: Sind noch drei da? Solange die Zahl stimmt, greift er nicht ein.
In Kubernetes ist der Vorarbeiter das Deployment, eine Verwaltungseinheit für gleichartige Pods. Der Pod ist die kleinste betreibbare Einheit und umhüllt einen oder mehrere Container, also Anwendungen samt Abhängigkeiten. Der Plan steckt im Feld replicas: Dort steht die Soll-Stärke, etwa die Zahl drei. Fällt ein Pod aus, startet das Deployment automatisch einen neuen. Kubernetes verteilt die Pods dabei auf die Knoten, die Arbeitsrechner des Clusters.
Ein Deployment für eine Webanwendung mit replicas: 3 erzeugt drei gleiche Pods. Stürzt einer ab, läuft die Zahl ohne Eingriff auf drei zurück. Die Container eines Pods teilen sich eine IP-Adresse und reden über localhost miteinander.
Das Bild hat eine Grenze: Ein Arbeiter bleibt derselbe Mensch, ein ersetzter Pod ist eine neue Instanz mit neuer IP-Adresse. Der Vorarbeiter delegiert auch aktiv, das Deployment vergleicht nur Ist und Soll. Stabile Adressen für Anfragen liefert deshalb ein Kubernetes-Service.
Pods also nie von Hand starten: Wer replicas selbst überwacht, ersetzt keine ausgefallenen Pods. Deployment heißt nicht Pod, sondern Soll-Stärke, die Kubernetes von selbst hält.
📌 Pod · Deployment · replicas
📚 Cloud von Grund auf · Tag 4 von 30
#kubernetes #devops #docker
2 Tage vor
Die meisten Daten enden im Rechenzentrum. Dabei haben Latenz und Bandbreite längst vorher das letzte Wort.
Latenz ist die Verzögerung zwischen einer Anfrage und ihrer Antwort. Bandbreite ist die Datenmenge, die je Zeiteinheit übertragen werden kann.
Zuerst trennt man die beiden Größen sauber. Eine Leitung kann hohe Bandbreite haben und trotzdem hohe Latenz, etwa wenn ein großer Datenblock erst nach langer Wartezeit fließt. Bandbreite ist also kein Heilmittel gegen Wartezeit.
Dann kommt die Entfernung ins Spiel. Signale brauchen physikalisch Laufzeit, jede Anfrage an ein fernes Rechenzentrum kostet mindestens eine Hin- und Rückreise. Je weiter die Cloud entfernt steht, desto später trifft jede Antwort ein.
Danach zeigt das Förderband-Beispiel die Grenze. Eine Kamera, die Ausschuss erkennen soll, erzeugt fortlaufend Bilddaten; wird jedes Bild in die Cloud geschickt, verbraucht das viel Bandbreite, und die Antwort kommt erst nach der Latenzstrecke zurück. Das Band ist inzwischen weitergelaufen.
Zuletzt verlagert man das Rechnen an den Rand. Edge Computing heißt, kleine Rechner nahe am Entstehungsort der Daten einzusetzen, etwa neben der Kamera. Der Rechner verarbeitet die Bilder selbst und meldet nur das Ergebnis: Teil fehlerhaft, Band stoppen. Das große Datenvolumen fällt weg, und die Reaktion erfolgt nahezu sofort.
Edge ersetzt die Cloud nicht, sondern ergänzt sie – Zeitkritisches und Voluminöses gehört an den Rand, Auswertung und Langzeitspeicherung ins Rechenzentrum. Je kürzer die erlaubte Reaktionszeit und je größer die Datenmenge im Verhältnis zur Leitung, desto stärker spricht die Architektur fürs Rechnen am Rand.
📌 Latenz · Bandbreite · Edge Computing
📚 Zukunftstechnologien verstehen · Tag 4 von 30
#edgecomputing #architektur #DigitaleTransformation
Latenz ist die Verzögerung zwischen einer Anfrage und ihrer Antwort. Bandbreite ist die Datenmenge, die je Zeiteinheit übertragen werden kann.
Zuerst trennt man die beiden Größen sauber. Eine Leitung kann hohe Bandbreite haben und trotzdem hohe Latenz, etwa wenn ein großer Datenblock erst nach langer Wartezeit fließt. Bandbreite ist also kein Heilmittel gegen Wartezeit.
Dann kommt die Entfernung ins Spiel. Signale brauchen physikalisch Laufzeit, jede Anfrage an ein fernes Rechenzentrum kostet mindestens eine Hin- und Rückreise. Je weiter die Cloud entfernt steht, desto später trifft jede Antwort ein.
Danach zeigt das Förderband-Beispiel die Grenze. Eine Kamera, die Ausschuss erkennen soll, erzeugt fortlaufend Bilddaten; wird jedes Bild in die Cloud geschickt, verbraucht das viel Bandbreite, und die Antwort kommt erst nach der Latenzstrecke zurück. Das Band ist inzwischen weitergelaufen.
Zuletzt verlagert man das Rechnen an den Rand. Edge Computing heißt, kleine Rechner nahe am Entstehungsort der Daten einzusetzen, etwa neben der Kamera. Der Rechner verarbeitet die Bilder selbst und meldet nur das Ergebnis: Teil fehlerhaft, Band stoppen. Das große Datenvolumen fällt weg, und die Reaktion erfolgt nahezu sofort.
Edge ersetzt die Cloud nicht, sondern ergänzt sie – Zeitkritisches und Voluminöses gehört an den Rand, Auswertung und Langzeitspeicherung ins Rechenzentrum. Je kürzer die erlaubte Reaktionszeit und je größer die Datenmenge im Verhältnis zur Leitung, desto stärker spricht die Architektur fürs Rechnen am Rand.
📌 Latenz · Bandbreite · Edge Computing
📚 Zukunftstechnologien verstehen · Tag 4 von 30
#edgecomputing #architektur #DigitaleTransformation
2 Tage vor
Die meisten Neulinge wundern sich, warum ein kleiner Code-Fix den kompletten Docker-Build neu auslöst. Dabei entscheidet oft nur die Reihenfolge der Zeilen im Dockerfile über Sekunden oder Minuten Bauzeit.
Das Symptom: Nach jeder noch so kleinen Codeänderung läuft der Bau minutenlang durch. Pakete werden erneut installiert, obwohl sich daran nichts geändert hat. Der Build-Cache, also das Zwischenspeichern bereits gebauter Schritte, greift scheinbar nie.
Dahinter steckt das Schichtprinzip: Jede Zeile im Dockerfile (der Bauanleitung für ein Image) erzeugt eine eigene Schicht. Das fertige Image, also die unveränderliche Vorlage für Container, besteht aus diesen Schichten wie ein Stapel. Eine unveränderte Schicht wird aus dem Cache wiederverwendet. Ändert sich eine Zeile, wird sie neu gebaut, und alle folgenden ebenso, weil sie auf dem Ergebnis aufbauen. Steht COPY, das Kopieren eigener Dateien, früh im Dockerfile, macht jede Codeänderung den Rest ungültig.
Konkret: Ein Dockerfile beginnt mit FROM, dann RUN zum Installieren der Abhängigkeiten, dann erst COPY des Quellcodes. Wer umgekehrt erst den Code kopiert und danach RUN ausführt, baut die Abhängigkeiten bei jedem Fix neu. Die Regel lautet: Anweisungen mit selten ändernden Inhalten wie RUN an den Anfang, Anweisungen mit häufig ändernden Inhalten wie COPY ans Ende.
So prüft man es: Beim Bau die Ausgabe der Zeilen ansehen, die als wiederverwendet markiert sind. Zeigen die frühen Zeilen wie die Abhängigkeiten einen Treffer und startet der Neubau erst beim Kopieren des Quellcodes, stimmt die Anordnung.
Schichten sind keine Zufallsprodukte, sondern ein Stapel: Ein früher Treffer im Cache spart alles darunter. Ordnung im Dockerfile heißt Reihenfolge nach Änderungshäufigkeit.
📌 Dockerfile-Schichten · Build-Cache · Reihenfolge nach Änderungshäufigkeit
📚 Cloud von Grund auf · Tag 4 von 30
#docker #kubernetes #devops
Das Symptom: Nach jeder noch so kleinen Codeänderung läuft der Bau minutenlang durch. Pakete werden erneut installiert, obwohl sich daran nichts geändert hat. Der Build-Cache, also das Zwischenspeichern bereits gebauter Schritte, greift scheinbar nie.
Dahinter steckt das Schichtprinzip: Jede Zeile im Dockerfile (der Bauanleitung für ein Image) erzeugt eine eigene Schicht. Das fertige Image, also die unveränderliche Vorlage für Container, besteht aus diesen Schichten wie ein Stapel. Eine unveränderte Schicht wird aus dem Cache wiederverwendet. Ändert sich eine Zeile, wird sie neu gebaut, und alle folgenden ebenso, weil sie auf dem Ergebnis aufbauen. Steht COPY, das Kopieren eigener Dateien, früh im Dockerfile, macht jede Codeänderung den Rest ungültig.
Konkret: Ein Dockerfile beginnt mit FROM, dann RUN zum Installieren der Abhängigkeiten, dann erst COPY des Quellcodes. Wer umgekehrt erst den Code kopiert und danach RUN ausführt, baut die Abhängigkeiten bei jedem Fix neu. Die Regel lautet: Anweisungen mit selten ändernden Inhalten wie RUN an den Anfang, Anweisungen mit häufig ändernden Inhalten wie COPY ans Ende.
So prüft man es: Beim Bau die Ausgabe der Zeilen ansehen, die als wiederverwendet markiert sind. Zeigen die frühen Zeilen wie die Abhängigkeiten einen Treffer und startet der Neubau erst beim Kopieren des Quellcodes, stimmt die Anordnung.
Schichten sind keine Zufallsprodukte, sondern ein Stapel: Ein früher Treffer im Cache spart alles darunter. Ordnung im Dockerfile heißt Reihenfolge nach Änderungshäufigkeit.
📌 Dockerfile-Schichten · Build-Cache · Reihenfolge nach Änderungshäufigkeit
📚 Cloud von Grund auf · Tag 4 von 30
#docker #kubernetes #devops
2 Tage vor
Die meisten Docker-Neulinge wundern sich, warum jeder Build Minuten dauert. Dabei entscheidet oft weniger die Größe des Projekts über die Bauzeit, sondern die Reihenfolge der Zeilen im Dockerfile.
Ein Dockerfile ist eine Textdatei mit Anweisungen wie FROM, COPY und RUN, aus denen docker build ein Image erzeugt – eine portable, gepackte Umgebung für eine Anwendung. Wer die Schichten versteht, baut deutlich schneller.
📦 Jede Dockerfile-Anweisung erzeugt ihre eigene Schicht.
Eine Schicht (Layer) ist das Dateisystem-Änderungsprotokoll genau einer Anweisung; das fertige Image entsteht als Stapel dieser Schichten übereinander. Die Anweisungen werden von oben nach unten abgearbeitet. Beispiel: erst FROM, dann COPY der Paketliste, dann RUN zur Installation der Abhängigkeiten, erst danach COPY des Quellcodes.
🔑 Der Build-Cache prüft jede Anweisung von oben nach unten.
Der Build-Cache ist ein Zwischenspeicher früherer Schichten; Docker vergleicht Anweisung und Eingaben mit der gecachten Version. Ist eine Schicht unverändert, wird sie samt aller darunterliegenden wiederverwendet. Ab der ersten geänderten Anweisung wird alles Folgende neu gebaut.
📈 Häufig Geändertes gehört ans Ende des Dockerfiles.
Klassischer Einsteigerirrtum: Quellcode früh per COPY übernehmen. Dann läuft bei jeder Codeänderung auch die teure Abhängigkeitsinstallation erneut, obwohl sich nichts daran geändert hat. Steht die COPY-Zeile für den Code dagegen ganz unten, bleibt der Cache für die Installation intakt.
Die Reihenfolge heißt nicht Geschmackssache, sondern Cache-Strategie: selten Geändertes zuerst, häufig Geändertes zuletzt – Basis-Image und Abhängigkeiten vor dem eigenen Quellcode.
📌 Schichten · Build-Cache · Anweisungsreihenfolge
📚 Cloud von Grund auf · Tag 4 von 30
#docker #devops #CloudHosting
Ein Dockerfile ist eine Textdatei mit Anweisungen wie FROM, COPY und RUN, aus denen docker build ein Image erzeugt – eine portable, gepackte Umgebung für eine Anwendung. Wer die Schichten versteht, baut deutlich schneller.
📦 Jede Dockerfile-Anweisung erzeugt ihre eigene Schicht.
Eine Schicht (Layer) ist das Dateisystem-Änderungsprotokoll genau einer Anweisung; das fertige Image entsteht als Stapel dieser Schichten übereinander. Die Anweisungen werden von oben nach unten abgearbeitet. Beispiel: erst FROM, dann COPY der Paketliste, dann RUN zur Installation der Abhängigkeiten, erst danach COPY des Quellcodes.
🔑 Der Build-Cache prüft jede Anweisung von oben nach unten.
Der Build-Cache ist ein Zwischenspeicher früherer Schichten; Docker vergleicht Anweisung und Eingaben mit der gecachten Version. Ist eine Schicht unverändert, wird sie samt aller darunterliegenden wiederverwendet. Ab der ersten geänderten Anweisung wird alles Folgende neu gebaut.
📈 Häufig Geändertes gehört ans Ende des Dockerfiles.
Klassischer Einsteigerirrtum: Quellcode früh per COPY übernehmen. Dann läuft bei jeder Codeänderung auch die teure Abhängigkeitsinstallation erneut, obwohl sich nichts daran geändert hat. Steht die COPY-Zeile für den Code dagegen ganz unten, bleibt der Cache für die Installation intakt.
Die Reihenfolge heißt nicht Geschmackssache, sondern Cache-Strategie: selten Geändertes zuerst, häufig Geändertes zuletzt – Basis-Image und Abhängigkeiten vor dem eigenen Quellcode.
📌 Schichten · Build-Cache · Anweisungsreihenfolge
📚 Cloud von Grund auf · Tag 4 von 30
#docker #devops #CloudHosting
2 Tage vor
Viele Dockerfiles beginnen damit, das gesamte Projekt per COPY zu kopieren. Dabei zerstört jede Quellcode-Änderung den gesamten Build-Cache.
Wer ein Dockerfile schreibt, begegnet sofort dem Build-Cache. Wer ihn nicht kennt, wartet bei jedem Neubau Minuten statt Sekunden.
Ein Dockerfile ist eine Liste von Anweisungen, die mit docker build zu einem Image (einer startfertigen Vorlage für Container) verarbeitet wird. Jede Anweisung erzeugt eine Schicht, also das Änderungsprotokoll dieser einen Zeile im Dateisystem. Das Image ist ein Stapel dieser Schichten; docker run startet daraus den Container.
Der Cache prüft beim Neubau jede Anweisung von oben nach unten. Ist eine Zeile unverändert, wird ihre Schicht samt aller darunterliegenden wiederverwendet. Ab der ersten geänderten Zeile wird alles Folgende neu gebaut, auch wenn es sich gar nicht verändert hat.
Konkret: Zuerst FROM, also die Wahl des Basis-Images als Startpunkt, dann COPY der Paketliste, dann RUN zur Installation der Abhängigkeiten, erst danach COPY des Quellcodes und der Startbefehl. Ändert sich nur der Quellcode, bleibt die teure Installation im Cache. Steht die Quellcode-Zeile dagegen oben, läuft RUN bei jeder kleinen Änderung erneut.
Verwechselt wird der Cache gern mit dem Build-Kontext, also dem Verzeichnis, das dem Build als Quelle dient. Der Kontext bestimmt, welche Dateien überhaupt an COPY übergeben werden; der Cache bestimmt, welche Schichten wiederverwendet werden. Eine .dockerignore-Datei hält Unnötiges wie .git aus dem Kontext fern und beschleunigt den Build zusätzlich.
Der Build-Cache belohnt nicht die schönste Zeile, sondern die stabilste Reihenfolge: Selten Geändertes nach oben, Häufig Geändertes nach unten.
📌 Layer · Build-Cache · Reihenfolge im Dockerfile
📚 Cloud von Grund auf · Tag 4 von 30
#docker #devops #CloudHosting
Wer ein Dockerfile schreibt, begegnet sofort dem Build-Cache. Wer ihn nicht kennt, wartet bei jedem Neubau Minuten statt Sekunden.
Ein Dockerfile ist eine Liste von Anweisungen, die mit docker build zu einem Image (einer startfertigen Vorlage für Container) verarbeitet wird. Jede Anweisung erzeugt eine Schicht, also das Änderungsprotokoll dieser einen Zeile im Dateisystem. Das Image ist ein Stapel dieser Schichten; docker run startet daraus den Container.
Der Cache prüft beim Neubau jede Anweisung von oben nach unten. Ist eine Zeile unverändert, wird ihre Schicht samt aller darunterliegenden wiederverwendet. Ab der ersten geänderten Zeile wird alles Folgende neu gebaut, auch wenn es sich gar nicht verändert hat.
Konkret: Zuerst FROM, also die Wahl des Basis-Images als Startpunkt, dann COPY der Paketliste, dann RUN zur Installation der Abhängigkeiten, erst danach COPY des Quellcodes und der Startbefehl. Ändert sich nur der Quellcode, bleibt die teure Installation im Cache. Steht die Quellcode-Zeile dagegen oben, läuft RUN bei jeder kleinen Änderung erneut.
Verwechselt wird der Cache gern mit dem Build-Kontext, also dem Verzeichnis, das dem Build als Quelle dient. Der Kontext bestimmt, welche Dateien überhaupt an COPY übergeben werden; der Cache bestimmt, welche Schichten wiederverwendet werden. Eine .dockerignore-Datei hält Unnötiges wie .git aus dem Kontext fern und beschleunigt den Build zusätzlich.
Der Build-Cache belohnt nicht die schönste Zeile, sondern die stabilste Reihenfolge: Selten Geändertes nach oben, Häufig Geändertes nach unten.
📌 Layer · Build-Cache · Reihenfolge im Dockerfile
📚 Cloud von Grund auf · Tag 4 von 30
#docker #devops #CloudHosting
2 Tage vor
Viele halten einen festen Zugangsschlüssel in der Konfigurationsdatei für eine ganz normale Lösung. Dabei ist genau das der schwerwiegendste Fehler beim Cloud-Zugriff.
Viele denken, der Schlüssel gehöre in die Konfiguration wie einst ein Datenbankpasswort. Plausibel, weil der Access Key (ein dauerhaftes Schlüsselpaar für den Zugriff per Programm) bequem ist: einmal eintragen, die Anwendung läuft.
Tatsächlich gilt: Ein geleakter fester Schlüssel bleibt gültig, bis jemand ihn widerruft. IAM (Identity and Access Management) regelt zwar, wer welche Handlungen auf welchen Ressourcen ausführen darf – ein hinterlegter Schlüssel umgeht jede kurzlebige Kontrolle. Stattdessen vergeben IAM-Rollen temporäre Anmeldeinformationen über den Dienst STS (Security Token Service, der kurzlebige Zugangsdaten ausstellt). Anwendungen auf EC2, ECS oder Lambda erhalten ihre Rechte über zugewiesene Rollen, nicht über fest hinterlegte Schlüssel.
Der Irrtum entsteht, weil die Rollen-Lösung unsichtbar arbeitet: Temporäre Zugangsdaten kommen automatisch über die Instanzmetadaten-Adresse. Der feste Schlüssel steht sichtbar da und funktioniert – bis er in einem Repository landet.
Ein typischer Fall: Eine Anwendung auf einem EC2-Server braucht Lesezugriff auf einen S3-Datenspeicher. Statt einen Schlüssel zu hinterlegen, hängt man der Instanz eine Rolle mit genau dieser Leseberechtigung an. Langlebige Schlüssel, die unvermeidbar bleiben, werden rotiert und möglichst durch Rollen oder Identity Center ersetzt.
Woran man es erkennt: In Konfigurationsdateien oder Umgebungsvariablen stehen dauerhafte Schlüsselpaare, deren letzte Prüfung niemand kennt.
Feste Schlüssel sind nicht der praktische Standard, sondern ein stehendes Restrisiko. Rollen geben kurzlebige Zugangsdaten – und was kurzlebig ist, ist nach dem Ablauf wertlos.
📚 Cloud von Grund auf · Tag 4 von 30
#aws #CloudSecurity #devops
Viele denken, der Schlüssel gehöre in die Konfiguration wie einst ein Datenbankpasswort. Plausibel, weil der Access Key (ein dauerhaftes Schlüsselpaar für den Zugriff per Programm) bequem ist: einmal eintragen, die Anwendung läuft.
Tatsächlich gilt: Ein geleakter fester Schlüssel bleibt gültig, bis jemand ihn widerruft. IAM (Identity and Access Management) regelt zwar, wer welche Handlungen auf welchen Ressourcen ausführen darf – ein hinterlegter Schlüssel umgeht jede kurzlebige Kontrolle. Stattdessen vergeben IAM-Rollen temporäre Anmeldeinformationen über den Dienst STS (Security Token Service, der kurzlebige Zugangsdaten ausstellt). Anwendungen auf EC2, ECS oder Lambda erhalten ihre Rechte über zugewiesene Rollen, nicht über fest hinterlegte Schlüssel.
Der Irrtum entsteht, weil die Rollen-Lösung unsichtbar arbeitet: Temporäre Zugangsdaten kommen automatisch über die Instanzmetadaten-Adresse. Der feste Schlüssel steht sichtbar da und funktioniert – bis er in einem Repository landet.
Ein typischer Fall: Eine Anwendung auf einem EC2-Server braucht Lesezugriff auf einen S3-Datenspeicher. Statt einen Schlüssel zu hinterlegen, hängt man der Instanz eine Rolle mit genau dieser Leseberechtigung an. Langlebige Schlüssel, die unvermeidbar bleiben, werden rotiert und möglichst durch Rollen oder Identity Center ersetzt.
Woran man es erkennt: In Konfigurationsdateien oder Umgebungsvariablen stehen dauerhafte Schlüsselpaare, deren letzte Prüfung niemand kennt.
Feste Schlüssel sind nicht der praktische Standard, sondern ein stehendes Restrisiko. Rollen geben kurzlebige Zugangsdaten – und was kurzlebig ist, ist nach dem Ablauf wertlos.
📚 Cloud von Grund auf · Tag 4 von 30
#aws #CloudSecurity #devops
2 Tage vor
Die meisten Anfänger tippen los und wundern sich über langsame Builds. Dabei ist ein Dockerfile ein Rezept mit fester Anweisungsreihenfolge.
Ein Dockerfile beschreibt Schritt für Schritt, wie ein Container-Image entsteht. Das Image ist die unveränderliche Vorlage, aus der Container gestartet werden.
Zuerst steht die FROM-Anweisung: Sie legt ein Basis-Image fest, etwa eine schlanke Linux-Distribution mit Python. Jede Anweisung erzeugt dabei eine Schicht, und die Reihenfolge entscheidet über den Build-Cache. Selten geänderte Schritte wie Abhängigkeiten gehören deshalb vor häufig geänderten wie dem Quellcode.
Dann folgt COPY. Es kopiert Dateien aus dem Build-Kontext in das Image, also aus dem Verzeichnis, das dem Build mitgegeben wird. Ein häufiger Irrtum: Dateien außerhalb dieses Kontexts sind schlicht nicht verfügbar. Bewährt hat sich, zuerst nur die Datei mit den Abhängigkeiten zu kopieren und zu installieren, dann erst den Quellcode.
Danach kommen RUN für Installationsbefehle sowie USER. Ohne USER läuft der Prozess im Container als root, also mit vollen Rechten. Die Anweisung USER setzt einen unprivilegierten Benutzer und senkt das Risiko, falls der Container kompromittiert wird.
Zuletzt legen CMD den Startbefehl und EXPOSE den Port fest. EXPOSE dokumentiert nur, welchen Port die Anwendung im Container erreicht; geöffnet wird er erst beim Start mit docker run. Der Befehl docker build arbeitet das Dockerfile ab und erzeugt das Image, versehen mit einem Tag wie 1.2. Solche Tags sind beweglich; ein Digest wie sha256:… identifiziert dagegen genau einen Inhalt.
Ein Dockerfile ist also kein Skript, sondern ein Rezept: Jede Anweisung baut eine Schicht, und deren Reihenfolge bestimmt Tempo und Sicherheit des Images.
📌 Schichten und Build-Cache · COPY und Build-Kontext · USER statt root
📚 Cloud von Grund auf · Tag 3 von 30
#docker #devops #CloudSecurity
Ein Dockerfile beschreibt Schritt für Schritt, wie ein Container-Image entsteht. Das Image ist die unveränderliche Vorlage, aus der Container gestartet werden.
Zuerst steht die FROM-Anweisung: Sie legt ein Basis-Image fest, etwa eine schlanke Linux-Distribution mit Python. Jede Anweisung erzeugt dabei eine Schicht, und die Reihenfolge entscheidet über den Build-Cache. Selten geänderte Schritte wie Abhängigkeiten gehören deshalb vor häufig geänderten wie dem Quellcode.
Dann folgt COPY. Es kopiert Dateien aus dem Build-Kontext in das Image, also aus dem Verzeichnis, das dem Build mitgegeben wird. Ein häufiger Irrtum: Dateien außerhalb dieses Kontexts sind schlicht nicht verfügbar. Bewährt hat sich, zuerst nur die Datei mit den Abhängigkeiten zu kopieren und zu installieren, dann erst den Quellcode.
Danach kommen RUN für Installationsbefehle sowie USER. Ohne USER läuft der Prozess im Container als root, also mit vollen Rechten. Die Anweisung USER setzt einen unprivilegierten Benutzer und senkt das Risiko, falls der Container kompromittiert wird.
Zuletzt legen CMD den Startbefehl und EXPOSE den Port fest. EXPOSE dokumentiert nur, welchen Port die Anwendung im Container erreicht; geöffnet wird er erst beim Start mit docker run. Der Befehl docker build arbeitet das Dockerfile ab und erzeugt das Image, versehen mit einem Tag wie 1.2. Solche Tags sind beweglich; ein Digest wie sha256:… identifiziert dagegen genau einen Inhalt.
Ein Dockerfile ist also kein Skript, sondern ein Rezept: Jede Anweisung baut eine Schicht, und deren Reihenfolge bestimmt Tempo und Sicherheit des Images.
📌 Schichten und Build-Cache · COPY und Build-Kontext · USER statt root
📚 Cloud von Grund auf · Tag 3 von 30
#docker #devops #CloudSecurity
3 Tage vor
Viele reden von Containern, meinen aber das Image – und umgekehrt. Dabei ist der Unterschied so klar wie der zwischen Backrezept und Kuchen.
Die Verwechslung liegt an der Sprache: Docker nennt beides fast gleich, und die Begriffe treten immer paarweise auf. Ein Fehler im laufenden Container zeigt sich erst später als verlorene Arbeit.
Ein Image ist eine unveränderliche Vorlage: eine Datei-Sammlung, in der Anwendung, Laufzeit-Umgebung, Bibliotheken und Konfiguration fest eingefroren sind. Nach dem Bau wird es nicht mehr geändert, sondern nur durch ein neues ersetzt – das Prinzip heißt Immutable Infrastructure. Beschrieben wird der Bau in einem Dockerfile, einer Schritt-für-Schritt-Anleitung. Beispiel: Ein Image enthält Python in einer festen Version plus den eigenen Anwendungscode.
Ein Container ist die laufende Instanz, die aus genau diesem Image gestartet wird. Er verpackt die Anwendung mit ihren Abhängigkeiten und teilt sich den Kernel (den Kern) des Host-Betriebssystems, startet dadurch schneller als eine virtuelle Maschine. Aus ein und demselben Image lassen sich beliebig viele Container starten, die alle identisch beginnen. Beispiel: Drei Container aus demselben Python-Image laufen gleichzeitig auf drei Rechnern.
Das Image bleibt unverändert, der Container ist vergänglich. Jede Änderung am laufenden Container verliert mit dessen Löschung ihre Spur.
Faustregel: Änderungen gehören immer in ein neues Image, das man über das Dockerfile baut – niemals in den laufenden Container.
Ein Image ist die Vorlage, ein Container deren laufende Kopie. Wer am Container schraubt, arbeitet im Sandkasten; wer am Image baut, arbeitet für jeden künftigen Start.
📌 Image = Vorlage · Container = Instanz · Änderungen ins Dockerfile
📚 Cloud von Grund auf · Tag 3 von 30
#docker #devops #kubernetes
Die Verwechslung liegt an der Sprache: Docker nennt beides fast gleich, und die Begriffe treten immer paarweise auf. Ein Fehler im laufenden Container zeigt sich erst später als verlorene Arbeit.
Ein Image ist eine unveränderliche Vorlage: eine Datei-Sammlung, in der Anwendung, Laufzeit-Umgebung, Bibliotheken und Konfiguration fest eingefroren sind. Nach dem Bau wird es nicht mehr geändert, sondern nur durch ein neues ersetzt – das Prinzip heißt Immutable Infrastructure. Beschrieben wird der Bau in einem Dockerfile, einer Schritt-für-Schritt-Anleitung. Beispiel: Ein Image enthält Python in einer festen Version plus den eigenen Anwendungscode.
Ein Container ist die laufende Instanz, die aus genau diesem Image gestartet wird. Er verpackt die Anwendung mit ihren Abhängigkeiten und teilt sich den Kernel (den Kern) des Host-Betriebssystems, startet dadurch schneller als eine virtuelle Maschine. Aus ein und demselben Image lassen sich beliebig viele Container starten, die alle identisch beginnen. Beispiel: Drei Container aus demselben Python-Image laufen gleichzeitig auf drei Rechnern.
Das Image bleibt unverändert, der Container ist vergänglich. Jede Änderung am laufenden Container verliert mit dessen Löschung ihre Spur.
Faustregel: Änderungen gehören immer in ein neues Image, das man über das Dockerfile baut – niemals in den laufenden Container.
Ein Image ist die Vorlage, ein Container deren laufende Kopie. Wer am Container schraubt, arbeitet im Sandkasten; wer am Image baut, arbeitet für jeden künftigen Start.
📌 Image = Vorlage · Container = Instanz · Änderungen ins Dockerfile
📚 Cloud von Grund auf · Tag 3 von 30
#docker #devops #kubernetes
3 Tage vor
Ein Container ist ein Mieter im Mehrfamilienhaus: Das Fundament gehört allen, die Einrichtung ist privat. Eine virtuelle Maschine baut dagegen ein eigenes Haus mit eigenem Keller. Genauer: mit einem kompletten Betriebssystem.
Alle Mieter teilen sich dasselbe Gebäude, dieselbe Heizung und Wasserleitung. Jede Wohnung ist trotzdem abgeschlossen; der Nachbar sieht nichts hinein. Zieht ein Mieter aus, hinterlässt er nur seine Möbel, kein ganzes Haus.
Das gemeinsame Gebäude ist der Kernel, also der Kern des Betriebssystems, der Prozesse, Speicher und Hardwarezugriff verwaltet. Die abgeschlossene Wohnung ist der Prozessraum: Jeder Container sieht nur eigene Prozesse, eigenes Dateisystem und eigenes Netzwerk. Die privaten Möbel sind das Container-Image, die unveränderliche Vorlage mit Anwendung, Laufzeitbibliotheken und Konfigurationsdateien.
Ein Dockerfile beschreibt Schritt für Schritt, wie ein Image gebaut wird. Solch ein Image ist meist nur wenige Megabytes bis wenige hundert Megabytes groß, während ein VM-Abbild mit vollem Betriebssystem mehrere Gigabyte umfasst. Deshalb startet ein Container in Sekunden, während eine virtuelle Maschine erst ihr eigenes Betriebssystem bootet – bei AWS heißt dieser Dienst EC2.
Das Bild hat eine Grenze: Ein Mieter kann fast beliebig wirtschaften, ein Container braucht den passenden Kernel. Container setzen auf Linux auf und teilen sich dessen Kernel-Funktionen. Ein Linux-Container läuft deshalb nicht direkt auf einem Windows-Host ohne Linux-Kernel.
Container sind also keine „leichteren VMs“: Eine VM kapselt Hardware, ein Container kapselt nur die Anwendung.
📌 Kernel · Container-Image · Prozessraum
📚 Cloud von Grund auf · Tag 3 von 30
#docker #CloudHosting #Linux
Alle Mieter teilen sich dasselbe Gebäude, dieselbe Heizung und Wasserleitung. Jede Wohnung ist trotzdem abgeschlossen; der Nachbar sieht nichts hinein. Zieht ein Mieter aus, hinterlässt er nur seine Möbel, kein ganzes Haus.
Das gemeinsame Gebäude ist der Kernel, also der Kern des Betriebssystems, der Prozesse, Speicher und Hardwarezugriff verwaltet. Die abgeschlossene Wohnung ist der Prozessraum: Jeder Container sieht nur eigene Prozesse, eigenes Dateisystem und eigenes Netzwerk. Die privaten Möbel sind das Container-Image, die unveränderliche Vorlage mit Anwendung, Laufzeitbibliotheken und Konfigurationsdateien.
Ein Dockerfile beschreibt Schritt für Schritt, wie ein Image gebaut wird. Solch ein Image ist meist nur wenige Megabytes bis wenige hundert Megabytes groß, während ein VM-Abbild mit vollem Betriebssystem mehrere Gigabyte umfasst. Deshalb startet ein Container in Sekunden, während eine virtuelle Maschine erst ihr eigenes Betriebssystem bootet – bei AWS heißt dieser Dienst EC2.
Das Bild hat eine Grenze: Ein Mieter kann fast beliebig wirtschaften, ein Container braucht den passenden Kernel. Container setzen auf Linux auf und teilen sich dessen Kernel-Funktionen. Ein Linux-Container läuft deshalb nicht direkt auf einem Windows-Host ohne Linux-Kernel.
Container sind also keine „leichteren VMs“: Eine VM kapselt Hardware, ein Container kapselt nur die Anwendung.
📌 Kernel · Container-Image · Prozessraum
📚 Cloud von Grund auf · Tag 3 von 30
#docker #CloudHosting #Linux
3 Tage vor
Der Schlüssel in der Konfigurationsdatei funktioniert monatelang, ohne dass jemand ihn prüft. Genau das ist das Problem.
Das Symptom kennt jeder Erstkontakt mit der Cloud: Ein Skript braucht Zugriff, also kopiert man einen festen Zugangsschlüssel (Access Key, ein dauerhaftes Schlüsselpaar aus ID und geheimem Schlüssel) in eine Datei. Es läuft, man vergisst es. Der Schlüssel bleibt wirksam, bis jemand ihn manuell sperrt.
Dahinter steht der Unterschied zwischen dauerhaften und temporären Anmeldedaten. Eine IAM-Rolle ist keine Person, sondern eine Identität, die man vorübergehend annimmt. STS (Security Token Service), der Dienst für kurzlebige Anmeldedaten, stellt dabei einen Zugangsschlüssel, ein Sitzungstoken und einen geheimen Schlüssel aus. Diese gelten nur begrenzt, oft in Stunden bis maximal etwa zwölf Stunden, und laufen danach von selbst ab.
Ein Beispiel aus dem Betrieb: Eine Anwendung auf einem EC2-Server (Amazons virtuelle Maschinen) braucht Lesezugriff auf einen S3-Datenspeicher. Statt einen Schlüssel in die Konfiguration zu schreiben, hängt man der Instanz eine Rolle mit genau dieser Leseberechtigung an. Die Anwendung bezieht ihre temporären Daten automatisch über die Instanzmetadaten-Adresse, ganz ohne hinterlegtes Geheimnis.
So prüft man es: Grep im Projekt nach Access-Key-ID-Mustern, typischerweise zwanzigstellige Zeichenketten. Findet sich einer in einer Datei, ersetzt man ihn durch eine Rolle und sperrt den Schlüssel.
Der zentrale Sicherheitsgewinn liegt im Verfall: Ein geleakter fester Schlüssel bleibt unbegrenzt nutzbar, abgelaufene temporäre Daten sind wertlos. Eine Rolle heißt nicht dauerhaftes Passwort, sondern verliehenes Recht auf Zeit.
📌 IAM-Rolle · Temporäre Anmeldedaten · Schlüssel-Rotation
📚 Cloud von Grund auf · Tag 3 von 30
#aws #CloudSecurity #devops
Das Symptom kennt jeder Erstkontakt mit der Cloud: Ein Skript braucht Zugriff, also kopiert man einen festen Zugangsschlüssel (Access Key, ein dauerhaftes Schlüsselpaar aus ID und geheimem Schlüssel) in eine Datei. Es läuft, man vergisst es. Der Schlüssel bleibt wirksam, bis jemand ihn manuell sperrt.
Dahinter steht der Unterschied zwischen dauerhaften und temporären Anmeldedaten. Eine IAM-Rolle ist keine Person, sondern eine Identität, die man vorübergehend annimmt. STS (Security Token Service), der Dienst für kurzlebige Anmeldedaten, stellt dabei einen Zugangsschlüssel, ein Sitzungstoken und einen geheimen Schlüssel aus. Diese gelten nur begrenzt, oft in Stunden bis maximal etwa zwölf Stunden, und laufen danach von selbst ab.
Ein Beispiel aus dem Betrieb: Eine Anwendung auf einem EC2-Server (Amazons virtuelle Maschinen) braucht Lesezugriff auf einen S3-Datenspeicher. Statt einen Schlüssel in die Konfiguration zu schreiben, hängt man der Instanz eine Rolle mit genau dieser Leseberechtigung an. Die Anwendung bezieht ihre temporären Daten automatisch über die Instanzmetadaten-Adresse, ganz ohne hinterlegtes Geheimnis.
So prüft man es: Grep im Projekt nach Access-Key-ID-Mustern, typischerweise zwanzigstellige Zeichenketten. Findet sich einer in einer Datei, ersetzt man ihn durch eine Rolle und sperrt den Schlüssel.
Der zentrale Sicherheitsgewinn liegt im Verfall: Ein geleakter fester Schlüssel bleibt unbegrenzt nutzbar, abgelaufene temporäre Daten sind wertlos. Eine Rolle heißt nicht dauerhaftes Passwort, sondern verliehenes Recht auf Zeit.
📌 IAM-Rolle · Temporäre Anmeldedaten · Schlüssel-Rotation
📚 Cloud von Grund auf · Tag 3 von 30
#aws #CloudSecurity #devops
3 Tage vor
Die meisten denken bei Cloud-Sicherheit zuerst an Firewalls. Dabei entscheidet viel früher, wer im Konto überhaupt welche Aktion ausführen darf.
Wer hier falsch liegt, öffnet Fremden die Tür. Deshalb lohnt es sich, die drei Bausteine zu kennen.
📦 Ein Principal ist die Identität, die handelt. Das kann ein IAM-Benutzer sein, eine dauerhafte Anmeldung für eine Person, oder eine IAM-Rolle. Den Root-Benutzer, das Hauptkonto der Verwaltung, nur für Ausnahmen nutzen: AWS empfiehlt, ihn nicht für tägliche Aufgaben zu verwenden, MFA (Multi-Faktor-Authentifizierung) zu aktivieren und keine Zugangsschlüssel für ihn anzulegen.
🔑 Eine Richtlinie (Policy) ist ein Dokument mit Rechten. Sie beschreibt erlaubte oder verbotene Aktionen auf benannten Ressourcen, etwa Lesen eines bestimmten S3-Buckets, eines Speicherbehälters im AWS-Dienst S3. Nach Least Privilege erlaubt sie nur die Aktionen, die eine Aufgabe braucht. Eine Policy mit Action "*" und Resource "*" widerspricht diesem Grundsatz.
📈 Die Zuordnung verknüpft Identität und Rechte. Wird eine Richtlinie an einen Benutzer angehängt, erhält er deren Rechte. Beim Auswerten mehrerer Richtlinien gilt: Fehlt eine Erlaubnis, wird der Zugriff verweigert. Eine ausdrückliche Deny-Anweisung schlägt jede Allow-Anweisung. Rollen vergeben temporäre Anmeldeinformationen über den Security Token Service (STS), der kurzbewehrte Schlüssel ausgibt, und wechseln deshalb den Inhaber; Anwendungen auf EC2, ECS oder Lambda erhalten Rechte so statt über fest hinterlegte Schlüssel. Langlebige Schlüssel von IAM-Benutzern regelmäßig rotieren oder durch Rollen oder das Identity Center, die zentrale Benutzer- und Rechteverwaltung in AWS, ersetzen.
Eine Rolle heißt nicht die Person selbst, sondern eine Identität, die man nur für die Dauer einer Aufgabe übernimmt.
📌 Principal · Richtlinie · Zuordnung
📚 Cloud von Grund auf · Tag 3 von 30
#aws #CloudSecurity #devops
Wer hier falsch liegt, öffnet Fremden die Tür. Deshalb lohnt es sich, die drei Bausteine zu kennen.
📦 Ein Principal ist die Identität, die handelt. Das kann ein IAM-Benutzer sein, eine dauerhafte Anmeldung für eine Person, oder eine IAM-Rolle. Den Root-Benutzer, das Hauptkonto der Verwaltung, nur für Ausnahmen nutzen: AWS empfiehlt, ihn nicht für tägliche Aufgaben zu verwenden, MFA (Multi-Faktor-Authentifizierung) zu aktivieren und keine Zugangsschlüssel für ihn anzulegen.
🔑 Eine Richtlinie (Policy) ist ein Dokument mit Rechten. Sie beschreibt erlaubte oder verbotene Aktionen auf benannten Ressourcen, etwa Lesen eines bestimmten S3-Buckets, eines Speicherbehälters im AWS-Dienst S3. Nach Least Privilege erlaubt sie nur die Aktionen, die eine Aufgabe braucht. Eine Policy mit Action "*" und Resource "*" widerspricht diesem Grundsatz.
📈 Die Zuordnung verknüpft Identität und Rechte. Wird eine Richtlinie an einen Benutzer angehängt, erhält er deren Rechte. Beim Auswerten mehrerer Richtlinien gilt: Fehlt eine Erlaubnis, wird der Zugriff verweigert. Eine ausdrückliche Deny-Anweisung schlägt jede Allow-Anweisung. Rollen vergeben temporäre Anmeldeinformationen über den Security Token Service (STS), der kurzbewehrte Schlüssel ausgibt, und wechseln deshalb den Inhaber; Anwendungen auf EC2, ECS oder Lambda erhalten Rechte so statt über fest hinterlegte Schlüssel. Langlebige Schlüssel von IAM-Benutzern regelmäßig rotieren oder durch Rollen oder das Identity Center, die zentrale Benutzer- und Rechteverwaltung in AWS, ersetzen.
Eine Rolle heißt nicht die Person selbst, sondern eine Identität, die man nur für die Dauer einer Aufgabe übernimmt.
📌 Principal · Richtlinie · Zuordnung
📚 Cloud von Grund auf · Tag 3 von 30
#aws #CloudSecurity #devops
3 Tage vor
Eine Anwendung läuft dreifach ausfallsicher – und eine Stromversorgung legt sie komplett still. Solche Stellen heißen Single Points of Failure, und fast jede Architektur hat mindestens einen.
Wer nicht systematisch danach sucht, merkt den Ausfall erst, wenn Nutzer eine Fehlerseite sehen. Betroffen ist jede Cloud-Anwendung, die ohne Ausfallschutz betrieben wird.
Ein Single Point of Failure ist eine Komponente, deren Ausfall das ganze System stoppt. Hochverfügbarkeit entsteht, indem genau solche Komponenten mehrfach vorhanden sind. Erst wenn eine zweite Instanz die Arbeit übernehmen kann, ist der Ausfall abgefangen.
Man geht den Weg einer Anfrage von vorne nach hinten durch – DNS (übersetzt Domainnamen in IP-Adressen), Load Balancer (ein Verkehrsverteiler vor den Servern), Anwendungsserver, Datenbank, Speicher. Eine Anwendung, die nur in einer einzigen Availability Zone (einem Rechenzentrumverbund mit eigener Stromversorgung und Netzanbindung) läuft, hat daher einen Single Point of Failure: Fällt diese Zone aus, ist die Anwendung weg. Der Ausfallschutz entsteht erst durch das Betreiben in mindestens zwei Zonen. Auch vorne droht eine Falle: Ein Load Balancer, der alleinstehend vor der Anwendung sitzt, ist selbst ein Single Point of Failure. In Kubernetes fängt ein Deployment mit mehreren Pods (kleinste Einheit in Kubernetes mit einem oder mehreren Containern) den Ausfall einzelner Pods ab; ein Service gibt ihnen eine stabile Adresse und verteilt Anfragen, auch wenn Pods neu starten.
Verwechselt wird der Single Point of Failure oft mit Redundanz an nur einer Stelle. Die nützt nichts, wenn dahinter alles über genau eine Instanz läuft.
Ein Single Point of Failure ist also nicht „ein kaputtes Teil“, sondern die einzige Instanz, an der alles hängt.
📌 Anfrage-Weg abgehen · einzige Instanz prüfen · zweite Zone einplanen
📚 Cloud von Grund auf · Tag 3 von 30
#aws #sre
Wer nicht systematisch danach sucht, merkt den Ausfall erst, wenn Nutzer eine Fehlerseite sehen. Betroffen ist jede Cloud-Anwendung, die ohne Ausfallschutz betrieben wird.
Ein Single Point of Failure ist eine Komponente, deren Ausfall das ganze System stoppt. Hochverfügbarkeit entsteht, indem genau solche Komponenten mehrfach vorhanden sind. Erst wenn eine zweite Instanz die Arbeit übernehmen kann, ist der Ausfall abgefangen.
Man geht den Weg einer Anfrage von vorne nach hinten durch – DNS (übersetzt Domainnamen in IP-Adressen), Load Balancer (ein Verkehrsverteiler vor den Servern), Anwendungsserver, Datenbank, Speicher. Eine Anwendung, die nur in einer einzigen Availability Zone (einem Rechenzentrumverbund mit eigener Stromversorgung und Netzanbindung) läuft, hat daher einen Single Point of Failure: Fällt diese Zone aus, ist die Anwendung weg. Der Ausfallschutz entsteht erst durch das Betreiben in mindestens zwei Zonen. Auch vorne droht eine Falle: Ein Load Balancer, der alleinstehend vor der Anwendung sitzt, ist selbst ein Single Point of Failure. In Kubernetes fängt ein Deployment mit mehreren Pods (kleinste Einheit in Kubernetes mit einem oder mehreren Containern) den Ausfall einzelner Pods ab; ein Service gibt ihnen eine stabile Adresse und verteilt Anfragen, auch wenn Pods neu starten.
Verwechselt wird der Single Point of Failure oft mit Redundanz an nur einer Stelle. Die nützt nichts, wenn dahinter alles über genau eine Instanz läuft.
Ein Single Point of Failure ist also nicht „ein kaputtes Teil“, sondern die einzige Instanz, an der alles hängt.
📌 Anfrage-Weg abgehen · einzige Instanz prüfen · zweite Zone einplanen
📚 Cloud von Grund auf · Tag 3 von 30
#aws #sre
