aiMOOC

Server Cloud und zuverlässiger IT-Betrieb – Container als Betriebsform verstehen

QR-Code

Einleitung

Server Cloud und zuverlässiger IT-Betrieb – Container als Betriebsform verstehen

Zielgruppe: IT-Ausbildung, insbesondere Fachinformatikerinnen und Fachinformatiker für Systemintegration und Anwendungsentwicklung.

Dauer: Fünf Lerneinheiten mit jeweils etwa 10 Minuten, zusätzlich 30–45 Minuten für das Praxislabor.

Leitfrage: Wie helfen Container beim zuverlässigen Betrieb von Anwendungen, und wo liegen ihre Grenzen?

Du lernst: Cloud, virtuelle Maschinen, Images, Namespaces, Ressourcenlimits und sicheren IT-Betrieb zu unterscheiden.

Kurzbeschreibung: Container verpacken Anwendungen und ihre Abhängigkeiten. Sie isolieren Prozesse, sind aber keine vollständige Sicherheitsgrenze. Du untersuchst dies anhand eines fiktiven Betriebsauftrags.

Sicherheitsregel: Führe alle technischen Versuche ausschließlich in einer eigenen lokalen oder ausdrücklich freigegebenen Schulungsumgebung aus. Verwende nur fiktive Daten. Keine fremden Netze, Produktivsysteme, Zugangsdaten oder Kundendaten. Keine automatischen Downloads, externen Uploads oder ungefragten Datenübertragungen.

Medienhinweis: YouTube und LearningApps sind externe Angebote. Verwende sie nur nach Freigabe und unter Beachtung des Datenschutzes. Die lokalen Programmierübungen benötigen diese Angebote nicht.

Der Ausbildungsfall: Eine Statusanzeige betreiben

Betriebsauftrag – fiktive Musterwerkstatt

Eine Ausbildungswerkstatt benötigt eine interne Statusanzeige. Der Beispieldienst soll lediglich die Meldung STATUS: GRUEN anzeigen.

Dein Auftrag lautet: Wähle eine geeignete Betriebsform, prüfe die Isolation und dokumentiere einen sicheren Teststart.

Anforderung	Entscheidung im Schulungslabor
Statusanzeige	Statische fiktive Meldung
Netz	Kein externes Containernetz
Arbeitsspeicher	128 MiB als Übungslimit
Prozessor	Höchstens 0,5 CPU
Dateisystem	Schreibgeschütztes Wurzeldateisystem
Berechtigungen	Nicht privilegierter Benutzer
Daten	Ausschließlich künstliche Testdaten

Dein Lernprodukt: Eine kurze Betriebsentscheidung mit Testprotokoll, Risikobewertung und Verbesserungsvorschlag.

Lerneinheit 1: Server, Cloud und virtuelle Maschinen

Zeit: 10 Minuten

Ein Server stellt Dienste bereit. Cloud Computing beschreibt die bedarfsgerechte Bereitstellung von IT-Ressourcen. Ein Container kann auf einem lokalen Server oder in einer Cloud-Umgebung laufen.

Cloud-Betriebsformen. Sam Johnston, CC BY-SA 3.0. Quelle und Lizenz

Merke: Cloud bezeichnet eine Art der Bereitstellung. Container bezeichnen eine Betriebs- und Paketierungsform. Beides ist nicht dasselbe.

Virtuelle Maschine oder Container?

Vergleich klassischer Bereitstellung, virtueller Maschinen und Container. MoreInput, CC BY-SA 4.0. Quelle und Lizenz

Eigenschaft	Virtuelle Maschine	Container
Betriebssystem	Eigenes Gastbetriebssystem	Teilt den Kernel der Laufzeitumgebung
Isolation	Über Hypervisor und Gastbetriebssystem	Über Betriebssystemmechanismen
Start	Oft aufwendiger	Häufig schneller
Ressourcenbedarf	Zusätzlicher Gastbetriebssystemaufwand	Häufig geringer
Typischer Einsatz	Getrennte Betriebssystemumgebungen	Paketierte Anwendungen

Auf Windows und macOS können Linux-Container innerhalb einer Linux-VM laufen.

Videoimpuls: Erkläre nach dem Video in zwei Sätzen, weshalb Container und virtuelle Maschinen auch gemeinsam eingesetzt werden können.

IBM Technology: Containers vs VMs: What's the difference? YouTube-Video vom 10.09.2020. Kein pauschaler OER-Lizenznachweis für das Video.

Mini-Aufgabe – Basis: Warum ist ein Container nicht einfach ein kleiner vollständiger Computer?

Feedback: Eine gute Antwort nennt den gemeinsam genutzten Kernel. Nur die Größe zu vergleichen erklärt den technischen Unterschied nicht.

Lerneinheit 2: Isolation verstehen

Zeit: 10 Minuten

Unter Linux arbeiten Container insbesondere mit zwei Mechanismen:

Namespaces: Begrenzen die Sicht eines Prozesses auf bestimmte Systemressourcen.
Cgroups: Steuern beziehungsweise begrenzen die Nutzung von Ressourcen wie CPU und Arbeitsspeicher.

Traditionelle und containerisierte Anwendungen. Joseph554, CC BY-SA 4.0. Quelle und Lizenz

Historische Darstellung von Docker-Schnittstellen zum Linux-Kernel. Maklaan, auf Commons als gemeinfrei gekennzeichnet. Die gezeigten Schnittstellen sind nicht alle Bestandteil heutiger Standardkonfigurationen. Quelle und Rechte

Merksatz: Namespaces bestimmen, was ein Prozess sehen kann. Cgroups beeinflussen, wie viele Ressourcen er nutzen darf.

Wichtige Grenze: Die Isolation ist konfigurations- und kernelabhängig. Sicherheitslücken, weitreichende Berechtigungen und gefährliche Einbindungen können die Schutzwirkung beeinträchtigen.

Mini-Aufgabe – Anwendung: Zwei Container teilen sich einen Host. Einer verbraucht sehr viel RAM. Welcher Mechanismus kann den Speicherverbrauch begrenzen?

Feedback: Cgroups sind hier relevant. Eine andere Prozesssicht allein verhindert keine Ressourcenüberlastung.

Lerneinheit 3: Images und Container unterscheiden

Zeit: 10 Minuten

Ein Image ist eine Vorlage mit Programmdateien, Abhängigkeiten und Konfiguration. Ein Container ist eine daraus erzeugte Laufzeitinstanz.

Traditionelle und containerisierte Anwendungsbereitstellung. MoreInput, unter anderem CC BY-SA 4.0. Quelle und Lizenz

IMAGE
  Basisdateien
      +
  Anwendung
      +
  Konfiguration
      |
      v
  Container A
  Container B
  Container C

Images bestehen üblicherweise aus unveränderlichen Schichten. Ein Container erhält für veränderliche Daten normalerweise zusätzlich eine beschreibbare Ebene, sofern diese nicht eingeschränkt wird.

Begriff	Bedeutung
Dockerfile	Bauanleitung für ein Image
Image	Unveränderliche Vorlage
Container	Erzeugte Laufzeitinstanz
Registry	Speicher- und Verteildienst für Images
Tag	Veränderbare Versionsbezeichnung
Digest	Inhaltsbezogene Image-Kennung

Videoimpuls: Benenne beim Vergleich von VM und Container jeweils den Speicherort des Betriebssystemkerns.

IBM Technology: Virtual Machine (VM) vs Docker. YouTube-Video vom 18.04.2023.

Mini-Aufgabe – Basis: Erkläre den Unterschied zwischen einem Image und einem Container mithilfe des Vergleichs „Vorlage und gestartetes Programm“.

Feedback: Ein Image wird nicht bereits dadurch zum laufenden Dienst, dass es lokal gespeichert ist. Erst die erzeugte und gestartete Instanz führt Prozesse aus.

Lerneinheit 4: Grenzen und zuverlässigen Betrieb erkennen

Zeit: 10 Minuten

Container vereinfachen die Paketierung und Bereitstellung. Zuverlässigkeit entsteht jedoch erst durch geeignete Betriebsmaßnahmen.

Risiko	Mögliche Betriebsmaßnahme
Überhöhter RAM-Verbrauch	Speicherlimit und Beobachtung
Hohe Prozessorlast	CPU-Begrenzung
Fehlerhaftes Image	Geprüfte Herkunft und kontrollierte Updates
Ungewollter Dateizugriff	Minimale Berechtigungen und Read-only
Fehlerhafte Konfiguration	Dokumentation und Freigabe
Datenverlust	Geeignete Datensicherung
Dienststörung	Monitoring, Fehleranalyse und Wiederherstellung

Wichtig: Ein Speicherlimit verhindert nicht automatisch jeden Ausfall. Ein Container kann bei Speichermangel beendet werden. Neustarts ersetzen keine Fehlerbehebung.

Architektur des Linux-Kernels. Kuzux, CC BY-SA 2.5. Quelle und Lizenz

Betriebsentscheidung: Für besonders hohe Isolationsanforderungen kann zusätzliche Trennung, beispielsweise durch virtuelle Maschinen, angemessen sein.

Mini-Aufgabe – Transfer: Ein Container startet nach einem Fehler automatisch neu, fällt aber jede Minute erneut aus. Ist der Betrieb zuverlässig?

Feedback: Nein. Der Neustart stellt keine dauerhafte Funktionsfähigkeit sicher. Ursachenanalyse, geeignete Überwachung und gegebenenfalls ein Rollback sind notwendig.

Lerneinheit 5: Betriebsdaten auswerten

Zeit: 10 Minuten

Die folgenden Werte sind vollständig fiktive Schulungsdaten. Es handelt sich nicht um Messungen an einem echten Server.

RAM-Limit im Beispiel: 128 MiB

RAM-Verbrauch verschiedener Testfälle

48 MiB   [######..........]  38 %
96 MiB   [############....]  75 %
116 MiB  [###############.] 91 %
148 MiB  [################] 116 %  !

Skala: 16 Zeichen entsprechen 128 MiB.
! = simulierte Last oberhalb des Limits

Testfall	RAM	Fachliche Bewertung
Normalbetrieb	48 MiB	Deutliche Reserve
Erweiterte Last	96 MiB	Beobachten
Lastspitze	116 MiB	Geringe Reserve
Überlast	148 MiB	Oberhalb des gesetzten Limits

Die Grafik visualisiert den Vergleich mit einem Grenzwert. Das tatsächliche Laufzeitverhalten eines realen Containers hängt zusätzlich von Speicherverwaltung, Swap-Einstellungen und Hostkonfiguration ab.

Mini-Aufgabe – Anwendung: Begründe, weshalb 116 MiB bei einem Limit von 128 MiB bereits eine Warnung rechtfertigen können.

Feedback: Es bleiben rechnerisch nur 12 MiB bis zum Limit. Kurzfristige zusätzliche Speicheranforderungen können deshalb problematisch werden.

Praxislabor: Zwei lokale Testumgebungen

Die Übungen werden nicht auf Produktionsanlagen ausgeführt.

Labor	Voraussetzungen	Isolation
Labor A	Python 3, offline	Lokale Simulation ohne Netzwerkfunktionen
Labor B	Freigegebene lokale Docker-Schulungs-VM	Tatsächlicher Container mit eingeschränktem Netzwerk und Ressourcen

Achtung: Labor A simuliert Containerregeln, erzeugt aber keine echte Betriebssystemisolation. Auch Pythons Option -I ist keine vollständige Sandbox. Labor B benötigt einen ausschließlich für die Schulung freigegebenen lokalen Container-Host. Der Zugriff auf den Docker-Daemon ist sicherheitsrelevant.

Labor A: Interaktive Offline-Simulation mit Python

Aufgabe: Entscheide für fünf fiktive Betriebssituationen, ob sie die Laborregeln erfüllen.

Speichere den folgenden Code unter dem Dateinamen container_lab.py in einem neuen Schulungsverzeichnis.

from dataclasses import dataclass

LIMIT = 128  # MiB, nur ein fiktiver Schulungswert

@dataclass(frozen=True)
class Probe:
    name: str
    ram: int
    netz: str
    readonly: bool

faelle = [
    Probe("Normalbetrieb", 48, "none", True),
    Probe("Lastspitze", 116, "none", True),
    Probe("Ueberlast", 148, "none", True),
    Probe("Falsches Netz", 72, "bridge", True),
    Probe("Schreibzugriff", 64, "none", False),
]

def pruefe(fall):
    hinweise = []
    if fall.ram > LIMIT:
        hinweise.append("RAM-Spitze ueber dem Limit: OOM-Risiko")
    if fall.netz != "none":
        hinweise.append("Netzmodus verstoesst gegen die Laborregel")
    if not fall.readonly:
        hinweise.append("Wurzeldateisystem ist beschreibbar")
    return hinweise

for nr, fall in enumerate(faelle, 1):
    anzahl = min(20, round(fall.ram / LIMIT * 20))
    print(f"{nr} {fall.name:16} [{('#' * anzahl):<20}] "
          f"{fall.ram:3} MiB")

while True:
    antwort = input("Fall 1-5 oder q: ").strip().lower()
    if antwort == "q":
        break
    if antwort not in ("1", "2", "3", "4", "5"):
        print("Bitte 1 bis 5 oder q eingeben.")
        continue
    fall = faelle[int(antwort) - 1]
    tipp = input("Nach Laborregel freigeben? j/n: ").strip().lower()
    hinweise = pruefe(fall)
    korrekt = not hinweise
    print("Feedback:", "richtig" if (tipp == "j") == korrekt
          else "noch einmal pruefen")
    print("Begruendung:", "; ".join(hinweise) if hinweise
          else "Die drei Laborregeln sind erfuellt.")

Lokal starten:

python3 -I -B container_lab.py

Dein Test: Wähle Fall 3 und antworte mit n. Anschließend probiere die Fälle 1, 4 und 5 aus.

Erwartetes Feedback zu Fall 3: Die simulierte RAM-Spitze von 148 MiB überschreitet das Laborlimit von 128 MiB. Das begründet ein OOM-Risiko.

Hinweis: Die dargestellten Zahlen sind Testdaten. Das Programm fragt keine Netzwerke ab, liest keine fremden Dateien und verändert keine produktiven Dienste.

Labor B: Ein Image ausschließlich lokal bauen und starten

Voraussetzung: Die Lehrkraft hat eine isolierte Schulungs-VM mit lokalem Docker-Daemon und dem vorab geprüften Image busybox:1.36 vorbereitet.

Die Image-Herkunft und der Digest sind von der Lehrkraft zu dokumentieren. Ein Tag allein ist keine unveränderliche Identifikation. Es erfolgt im Kurs kein Image-Download.

Prüfe zunächst, ob Du tatsächlich den freigegebenen lokalen Docker-Daemon verwendest. Eine Remote-Verbindung über einen Docker-Kontext oder DOCKER_HOST ist nicht zulässig.

Schritt 1: Lokales Image prüfen

docker image inspect busybox:1.36

Fehlt das Image, brich das Labor ab und informiere die Lehrkraft. Verwende keinen Pull-Befehl.

Schritt 2: Ein leeres Verzeichnis mit fiktiven Daten erstellen

mkdir aimooc-labor-neu
cd aimooc-labor-neu
printf 'STATUS: GRUEN (fiktiv)\n' > meldung.txt

Führe dies nur aus, wenn das Verzeichnis noch nicht existiert. Kopiere keine persönlichen oder betrieblichen Dateien in das Verzeichnis.

Schritt 3: Dockerfile erstellen

Lege im selben Verzeichnis eine Datei namens Dockerfile mit folgendem Inhalt an:

FROM busybox:1.36
COPY meldung.txt /meldung.txt
USER 65534:65534
CMD ["cat", "/meldung.txt"]

Schritt 4: Ohne Build-Netzwerk und ohne Pull bauen

docker build --pull=false --network none \
  -t aimooc-status:1 .

Falls der lokal konfigurierte Builder zusätzliche externe Ressourcen verlangt, darf der Build nicht fortgesetzt werden.

Schritt 5: Den Container eingeschränkt ausführen

docker run --rm --pull never \
  --network none \
  --read-only \
  --user 65534:65534 \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --pids-limit 64 \
  --memory 128m \
  --cpus 0.5 \
  aimooc-status:1

Erwartete Ausgabe:

STATUS: GRUEN (fiktiv)

Die Optionen bedeuten:

Option	Begründung
--pull never	Kein automatischer Image-Download beim Start
--network none	Keine externe Netzschnittstelle im Container; Loopback bleibt
--read-only	Schreibgeschütztes Wurzeldateisystem
--user	Keine Ausführung mit Container-Root als Standardbenutzer
--cap-drop ALL	Entfernt Linux-Capabilities
--security-opt no-new-privileges	Verhindert zusätzliche Privilegien durch Exec-Mechanismen
--pids-limit	Begrenzt die Zahl der Prozesse beziehungsweise Tasks
--memory	Legt die Speicherobergrenze fest
--cpus	Begrenzt die verfügbare CPU-Zeit
--rm	Entfernt den gestoppten Testcontainer automatisch

Interaktive Variante: Starte eine Shell innerhalb desselben isolierten Containers.

docker run --rm -it --pull never \
  --network none --read-only \
  --user 65534:65534 \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --pids-limit 64 --memory 128m --cpus 0.5 \
  aimooc-status:1 sh

Gib ausschließlich diese harmlosen lokalen Befehle ein:

id
cat /meldung.txt
ls /
exit

Beobachtungsauftrag: Welche Benutzerkennung wird angezeigt? Welche Datei wurde durch COPY in das Image aufgenommen?

Feedback: Die Meldung stammt aus dem selbst erstellten Image. Die Benutzerkennung ist nicht Root. Die Einschränkungen verringern Risiken, garantieren aber keine vollständige Isolation gegenüber einem kompromittierten Host oder Kernel.

Technischer Hinweis: Die Unterstützung einzelner Ressourcenlimits hängt von der Linux- und Docker-Konfiguration ab. Fällt ein Limit wegen fehlender Hostunterstützung aus, gilt der Test nicht als erfolgreich abgesichert.

Gestufte Hilfen

Hilfe 1 – Den passenden Begriff finden
Frage Dich: Geht es um die Sichtbarkeit von Ressourcen, ihre Menge oder die Herkunft einer Anwendung? Sichtbarkeit führt zu Namespaces, Ressourcenmenge zu Cgroups, Herkunft zu Images.

Hilfe 2 – Den Ausbildungsfall prüfen
Vergleiche jede Betriebsentscheidung mit drei Vorgaben: kein externes Containernetz, kein veränderbares Root-Dateisystem und festgelegter Speicherverbrauch. Die Python-Simulation prüft genau diese drei Regeln.

Hilfe 3 – Eine Entscheidung begründen
Musterargument: Ich wähle einen eingeschränkten Container, weil sich die statische Anwendung einfach paketieren lässt. Die Grenzen sind der gemeinsame Kernel, die weiterhin notwendigen Updates und die Verantwortung für Monitoring und Wiederherstellung.

Interaktive Aufgaben

Quiz: Teste Dein Wissen

Was teilen sich Linux-Container auf demselben Host normalerweise? (Den Betriebssystemkernel) (!Ein vollständiges Gastbetriebssystem) (!Eine eigene physische CPU) (!Eine eigene Festplatte)

Welcher Mechanismus begrenzt den Speicherverbrauch eines Containers? (Cgroups) (!DNS) (!HTML) (!Registry)

Was beschreibt ein Container-Image? (Eine Vorlage mit Dateien und Konfiguration) (!Einen automatisch erreichbaren Cloudserver) (!Eine vollständige physische Maschine) (!Eine garantierte Datensicherung)

Welcher Begriff bezeichnet eine laufende Instanz eines Images? (Container) (!Registry) (!Hypervisor) (!Digest)

Was bewirkt die Docker-Option --network none? (Sie isoliert den Containernetzwerkstack bis auf Loopback) (!Sie aktiviert den Internetzugang) (!Sie löscht alle Netzwerkdateien des Hosts) (!Sie startet einen Cloudrouter)

Warum sind Speicherlimits im zuverlässigen IT-Betrieb wichtig? (Sie begrenzen die Speichernutzung einer Anwendung) (!Sie verhindern sämtliche Softwarefehler) (!Sie ersetzen Backups) (!Sie garantieren jede Antwortzeit)

Welche Aussage zu Container-Images ist richtig? (Ein Image kann aus mehreren unveränderlichen Schichten bestehen) (!Jeder Container benötigt einen eigenen Linux-Kernel) (!Images sind immer automatisch sicher) (!Images können nur mit Internetverbindung laufen)

Was ist eine wesentliche Grenze der Containerisolation? (Der gemeinsam genutzte Kernel bleibt sicherheitsrelevant) (!Container können nie beendet werden) (!Container unterstützen keine CPU-Limits) (!Container haben grundsätzlich keine Prozesse)

Welche Maßnahme passt zu minimalen Berechtigungen? (Ausführung mit einem nicht privilegierten Benutzer) (!Start als privilegierter Administrator ohne Einschränkungen) (!Freigabe aller Hostverzeichnisse) (!Deaktivieren sämtlicher Sicherheitsprofile)

Ein Container startet ständig neu. Was ist die beste erste betriebliche Reaktion? (Fehlerursache anhand freigegebener lokaler Diagnosedaten untersuchen) (!Den Fehler ohne Dokumentation ignorieren) (!Sämtliche Sicherheitslimits entfernen) (!Den Container ungeprüft im Internet veröffentlichen)

Memory

Ordne den Fachbegriffen die passenden Erklärungen zu.

Image	Unveränderliche Anwendungsvorlage
Container	Erzeugte Laufzeitinstanz
Namespace	Abgegrenzte Systemsicht
Cgroup	Steuerung von Ressourcen
Registry	Ablage für Images
Digest	Inhaltsbezogene Kennung
Hypervisor	Virtualisierung virtueller Maschinen

Drag and Drop

Ordne die richtigen Begriffe zu.	Aufgabe oder Eigenschaft
Namespace	Prozesssicht eingrenzen
Cgroup	Arbeitsspeicher begrenzen
Image	Anwendungsvorlage bereitstellen
Monitoring	Betriebszustand beobachten
Rollback	Zu einem vorherigen freigegebenen Stand zurückkehren

Kreuzworträtsel

Kernel	Welchen Betriebssystemkern teilen sich Linux-Container auf demselben Host?
Namespace	Welcher Mechanismus grenzt die Sicht auf Systemressourcen ab?
Cgroups	Welche Linux-Funktion verwaltet Ressourcengrenzen?
Image	Wie heißt die Vorlage zum Erstellen eines Containers?
Registry	Wo werden Container-Images zur Verteilung abgelegt?
Rollback	Wie heißt die Rückkehr zu einem vorherigen freigegebenen Softwarestand?

LearningApps

Optionales externes Übungsangebot: Die Suche enthält nicht zwingend geprüfte Aufgaben. Nutze sie nur nach Freigabe der Lehrkraft. Für eine vollständig offline durchgeführte Schulung verwende stattdessen die Übungen dieses Kurses.

Lückentext

Ein Linux-Container teilt sich den

mit anderen Containern auf demselben Host.

Die abgegrenzte Sicht auf Systemressourcen entsteht mithilfe von

.

Ressourcen wie Arbeitsspeicher lassen sich durch

kontrollieren.

Eine gespeicherte Anwendungsvorlage heißt

.

Ein gestartetes Image erzeugt eine Containerinstanz, die als

bezeichnet wird.

Zum Bereitstellen von Images kann eine

verwendet werden.

Eine Inhaltskennung für ein Image heißt

.

Die Option --read-only macht das Wurzeldateisystem

.

Zum Beobachten des Betriebszustands dient das

.

Die Rückkehr zu einer zuvor freigegebenen Version wird als

bezeichnet.

Begründetes Feedback zur Selbstkontrolle

Typische Annahme	Rückmeldung
Ein Container ist vollständig vom Host getrennt.	Nicht richtig: Der Kernel und die Laufzeitumgebung bleiben sicherheitsrelevant.
Ein Image ist schon ein gestartetes Programm.	Nicht richtig: Ein Image dient als Vorlage für Containerinstanzen.
Ein RAM-Limit garantiert Stabilität.	Nicht richtig: Überschreitungen können Fehler und Prozessbeendigungen verursachen.
Ein funktionierender Neustart reicht als Betriebskonzept.	Nicht richtig: Monitoring, Ursachenanalyse und Wiederherstellbarkeit fehlen.
Ohne Netzwerk kann der Container keinen Schaden verursachen.	Nicht richtig: Dateizugriffe, Berechtigungen und Kernelrisiken bleiben relevant.

Offene Aufgaben

Leicht – Basisaufgaben

Begriffskarte: Erstelle eine Karte mit den Begriffen Image, Container, Kernel und Registry und verbinde diese sinnvoll.
Vergleichsbild: Zeichne eine eigene Grafik, die virtuelle Maschinen und Container gegenüberstellt.
Betriebsregeln: Formuliere fünf Regeln für den sicheren Testbetrieb einer fiktiven Statusanzeige.
Datenvisualisierung: Stelle die vier fiktiven RAM-Werte des Kurses als selbst erstelltes Balkendiagramm dar.

Standard – Anwendungsaufgaben

Offline-Labor: Führe Labor A lokal durch, dokumentiere die Entscheidungen für alle fünf Fälle und begründe jede Bewertung.
Containerstart: Starte den selbst erstellten Testcontainer auf der freigegebenen lokalen Schulungs-VM und dokumentiere verwendete Schutzoptionen.
Fehlerprotokoll: Erstelle ein fiktives Störungsticket über einen Container, der seine Speichergrenze erreicht, und schlage angemessene Diagnosemaßnahmen vor.
Betriebskonzept: Entwirf für eine fiktive Statusanwendung einen Plan für Monitoring, Updates, Backups und Wiederherstellung.

Schwer – Transferaufgaben

Risikobewertung: Entscheide begründet, ob für eine besonders schutzbedürftige fiktive Anwendung ein Container allein oder zusätzlich eine VM eingesetzt werden sollte.
Freigabeprozess: Entwirf einen lokalen Prozess zur Image-Prüfung mit Herkunftsnachweis, Digest, Versionswechsel und Rollback.
Lehrvideo: Produziere ein zweiminütiges Erklärvideo mit selbst erstellten Grafiken zu den Vorteilen und Grenzen der Containerisolierung.
Betriebsentscheidung: Vergleiche anhand fiktiver Anforderungen den Betrieb einer Anwendung auf einem klassischen Server, in einer VM und in einem Container und präsentiere Deine Empfehlung.

Feedback und Bewertungsraster

Für alle offenen Aufgaben gelten folgende Kriterien:

Kriterium	Basis erfüllt	Gute Transferleistung
Fachlichkeit	Begriffe richtig verwendet	Technische Zusammenhänge begründet
Sicherheit	Nur freigegebene lokale Tests	Zusätzliche Risiken erkannt und bewertet
Nachvollziehbarkeit	Ergebnisse dokumentiert	Entscheidungen mit Belegen begründet
Betrieb	Funktion einer Anwendung beschrieben	Überwachung und Wiederherstellung berücksichtigt

Beispiel für begründetes Feedback:

Basis: „Du hast Image und Container richtig unterschieden. Ergänze, weshalb sich Container einen Kernel teilen.“

Anwendung: „Deine Ressourcenbegrenzung passt zum Ausbildungsfall. Beschreibe zusätzlich das Verhalten bei einer möglichen Überschreitung.“

Transfer: „Deine Entscheidung für eine VM bei erhöhten Isolationsanforderungen ist plausibel. Bewerte zusätzlich den Betriebsaufwand und die Sicherheitskonfiguration.“

Selbstreflexion: Was würdest Du an Deiner Betriebsentscheidung verändern, wenn die Statusanzeige statt statischer Meldungen vertrauliche Daten verarbeiten müsste? Entwickle nur ein Konzept; führe keinen solchen Versuch mit echten Daten durch.

Lernkontrolle

Bearbeite mindestens fünf der folgenden Aufgaben schriftlich oder mit eigenen Diagrammen. Nutze ausschließlich fiktive Situationen.

Architekturentscheidung: Begründe, wann Du Container innerhalb einer VM einsetzen würdest, und berücksichtige dabei Isolation und Betriebsaufwand.
Sicherheitsanalyse: Eine Anwendung soll auf alle Hostverzeichnisse zugreifen können. Analysiere die Risiken und schlage eine sicherere Architektur vor.
Ressourcenplanung: Drei fiktive Anwendungen benötigen unterschiedlich viel RAM. Entwirf einen Plan zur Begrenzung und Überwachung der Ressourcennutzung.
Updateplanung: Nach einem Image-Update startet eine Anwendung nicht mehr. Entwickle einen nachvollziehbaren Freigabe-, Diagnose- und Rollbackprozess.
Cloudtransfer: Erkläre, weshalb ein Container nicht allein dadurch zuverlässiger oder sicherer wird, dass er in einer Cloud ausgeführt wird.
Wiederherstellung: Ein zustandsbehafteter Dienst verliert nach Neuerstellung des Containers seine lokalen Daten. Analysiere Ursache und geeignete Maßnahmen für persistente Speicherung und Backup.

Bewertungsmaßstab: Nicht nur die vorgeschlagene Lösung zählt. Bewertet werden die technische Begründung, erkannte Grenzen, Sicherheitsaspekte und die Übertragbarkeit auf neue Aufgaben.

Lernnachweis

Ein vollständiger Lernnachweis zum Ausbildungsfall enthält:

Begriffswissen: Korrekte Erklärung von Container, Image, Namespace, Cgroup und Kernel.
Architektur: Eigene Zeichnung zum Unterschied zwischen VM und Container.
Praxis: Protokoll des offline ausgeführten Python-Labors und bei Freigabe des Docker-Labors.
Datenkompetenz: Selbst erstellte Visualisierung der fiktiven RAM-Werte mit Interpretation.
Betrieb: Begründete Entscheidungen zu Ressourcenlimits, Rechten, Monitoring und Wiederherstellung.
Sicherheit: Dokumentation der verwendeten isolierten Schulungsumgebung ohne echte Kundendaten.
Transfer: Begründete Empfehlung für die geeignete Betriebsform eines neuen fiktiven Anwendungsfalls.
Reflexion: Benennung von mindestens drei Grenzen der Containertechnik.

Nachweisform: Lernportfolio, kurzer technischer Bericht oder Präsentation mit eigener Grafik, lokaler Testdokumentation und begründeten Entscheidungen.

Datenschutz: Verwende in Screenshots und Protokollen ausschließlich künstliche Angaben. Entferne personenbezogene Informationen und Zugangsdaten.

OERs zum Thema

Wikipedia – Grundlagenartikel

Technische Fachquellen:

Docker Docs: What is a container? – Container und virtuelle Maschinen.
Docker Docs: What is an image? – Images und Schichten.
Docker Engine security – Namespaces, Cgroups und Sicherheitsaspekte.
Docker: Resource constraints – CPU- und Speicherlimits.
Docker: None network driver – Netzwerkisolation.
Docker: Building best practices – Sichere Images, Digests und Updates.
NIST SP 800-190: Application Container Security Guide – Sicherheitsrisiken und Gegenmaßnahmen.
Docker: Rootless mode – Nicht privilegierter Docker-Betrieb.

Geprüfte Medien und Rechte:

Medium	Urheber / Quelle	Rechte laut Quellseite
Cloud computing types.svg	Sam Johnston	CC BY-SA 3.0
Containerization2.svg	MoreInput	CC BY-SA 4.0
Containers.svg	Joseph554	CC BY-SA 4.0
Docker-linux-interfaces.svg	Maklaan	Gemeinfrei laut Commons
Containerization.svg	MoreInput	Unter anderem CC BY-SA 4.0
Linux kernel diagram.svg	Kuzux	CC BY-SA 2.5

Die Commons-Dateibeschreibungen enthalten die jeweiligen Lizenzbedingungen und Urheberangaben. Die YouTube-Videos werden nur als externe Lernmedien eingebunden und nicht als frei nachnutzbare OER-Dateien ausgegeben.

Quellenprüfung: Technische Aussagen orientieren sich an der Docker-Dokumentation und an NIST SP 800-190. Die angegebenen Grafiken und Videoadressen wurden anhand ihrer veröffentlichten Quellseiten geprüft. Externe Medien und technische Dokumentationen können später verändert oder entfernt werden.