Git
Versionieren, Branches und saubere Änderungen kommen später.
Noch nicht geöffnetAZUBI-WIKI / START
Die Lernstrecke ist in kleine Aufgaben geteilt. Lies kurz, probiere selbst aus und öffne Hinweise erst dann, wenn du festhängst.
Versionieren, Branches und saubere Änderungen kommen später.
Noch nicht geöffnetHinweis: Es gibt keine Accounts und keinen Fortschrittszähler. Du arbeitest in deinem eigenen Tempo und hältst Ergebnisse selbst fest.
LINUX / LERNSTRECKE
Eine praktische Strecke für den Einstieg: erst verstehen, dann sicher in der VM ausprobieren und anschließend eigene kleine Werkzeuge bauen.
Öffne die Kapitel der Reihe nach. Die Grundlagen legen die Begriffe, die mittleren Aufgaben machen dich sicher auf der Kommandozeile und der fortgeschrittene Teil verbindet alles zu kleinen Skripten.
Vor dem Start
GRUNDLAGEN / AUFGABE 01
Bevor du Befehle lernst, kläre die wichtigsten Begriffe. Recherchiere selbst und formuliere die Antworten in deinen eigenen Worten.
Nutze die offiziellen Dokumentationen oder seriöse Fachartikel. Ergänze bei jeder Antwort ein Beispiel, das du verstanden hast.
Schreibe kurze Antworten mit deinen eigenen Beispielen.
Vergleiche mindestens Lizenzmodell, Bedienung, Dateisystem und typische Einsatzgebiete.
Denke nicht nur an die Oberfläche. Frage dich, wer den Quellcode kontrollieren kann und wie stark das System an einen Hersteller gebunden ist.
Finde mindestens drei Eigenschaften, die Linux im Alltag oder im Serverbetrieb auszeichnen.
Schau auf Anpassbarkeit, offene Entwicklung, Paketverwaltung, Stabilität und die vielen Distributionen. Begründe jede Eigenschaft kurz.
Ordne die drei Begriffe ein und notiere, worauf die Distributionen jeweils aufbauen oder wofür sie gedacht sind.
Vergleiche Zielgruppe, Paketbasis und typische Umgebung. Eine Distribution ist mehr als nur ein anderes Hintergrundbild.
Erkläre die Rolle des Kernels zwischen Hardware und Programmen mit einem kleinen Beispiel.
Suche nach den Begriffen Hardwarezugriff, Prozesse, Speicher und Treiber. Der Kernel ist nicht die komplette Benutzeroberfläche.
Finde praktische Gründe und nenne auch mindestens einen Nachteil oder eine Herausforderung.
Achte auf Betriebskosten, Automatisierung, Fernverwaltung, Stabilität und die Frage, wie viel Kontrolle ein Team braucht.
Eine Seite Notizen oder ein Markdown-Dokument mit deinen fünf Antworten und drei neuen Begriffen.
Kannst du einer anderen Person den Unterschied zwischen Kernel, Distribution und Desktop erklären?
GRUNDLAGEN / AUFGABE 02
Die Konsole ist der direkte Weg, mit Linux zu arbeiten. Lerne zuerst, wo du bist, wohin du gehst und was eine Datei wirklich enthält.
Arbeite mit einem Snapshot oder einem frischen Testsystem. Nutze für diese Aufgabe nicht deinen Produktivserver und starte nichts mit sudo, wenn es nicht nötig ist.
Die Linux-Verzeichnisstruktur — / ist das Wurzelverzeichnis. Alles hängt darunter.
pwdaktuellen Pfad anzeigenlsInhalte auflistencdVerzeichnis wechselncatDateiinhalt ausgebenmkdirOrdner anlegennanoTextdatei bearbeitencpDatei kopieren..eine Ebene nach obenFühre die Schritte nacheinander aus und beobachte nach jedem Befehl die Ausgabe.
Lege unter deinem Home-Verzeichnis den Ordner linux-lernordner/Test an.
Mit mkdir -p ~/linux-lernordner/Test legst du bei Bedarf beide Ordner in einem Schritt an.
Gehe mit cd in den Ordner Test und prüfe mit pwd, ob der Pfad stimmt.
Lege mit nano die Datei blabla.txt an. Schreibe eine Zeile hinein, speichere und schließe den Editor.
In nano speicherst du mit Ctrl + O, bestätigst den Dateinamen und beendest mit Ctrl + X.
Gib die Datei mit cat blabla.txt aus und erstelle anschließend mit cp blabla.txt blabla-kopie.txt eine Kopie.
Gehe mit cd .. zurück und liste mit ls den Inhalt von linux-lernordner auf.
azubi@linux:~$ mkdir -p ~/linux-lernordner/Test azubi@linux:~$ cd ~/linux-lernordner/Test azubi@linux:~/linux-lernordner/Test$ printf "Mein erster Linux-Test\n" > blabla.txt azubi@linux:~/linux-lernordner/Test$ cat blabla.txt Mein erster Linux-Test azubi@linux:~/linux-lernordner/Test$ cp blabla.txt blabla-kopie.txt
MITTLERER TEIL / AUFGABE 03
Linux entscheidet bei jeder Datei, wer lesen, schreiben oder ausführen darf. Lerne zuerst das Muster zu lesen und ändere nur Dateien in deinem Testordner.
Arbeite ausschließlich in ~/linux-lernordner/Test. Systemdateien und fremde Home-Verzeichnisse bleiben unangetastet.
Eine Rechtezeile lesen — bei -rw-r--r-- folgen auf den Dateityp drei Dreiergruppen: Besitzer, Gruppe, alle anderen.
whoamiaktuellen Benutzer zeigenidBenutzer- und Gruppen-IDsls -lRechte ausführlich lesenchmodRechte ändernchownEigentümer ändernsudomit erhöhten RechtenErstelle eine Testdatei und verändere nur deren Rechte.
Führe whoami und id aus. Notiere Benutzername und primäre Gruppe.
Erstelle rechte-test.txt und prüfe mit ls -l, welche Standardrechte gesetzt sind.
Entferne für den Besitzer testweise das Schreibrecht mit chmod u-w rechte-test.txt. Versuche danach zu speichern und erkläre das Ergebnis.
Gib dem Besitzer das Schreibrecht wieder und setze die Datei danach mit chmod u+rw,go-r rechte-test.txt auf einen privaten Testzustand.
u steht für user/Besitzer, g für group und o für others. Das Plus fügt hinzu, das Minus entfernt.
MITTLERER TEIL / AUFGABE 04
Programme laufen als Prozesse. In diesem Teil lernst du, Prozesse zu finden und grob einzuschätzen, wie stark CPU, Arbeitsspeicher und System ausgelastet sind.
ps auxalle Prozesse anzeigentoplaufende Last beobachtenhtopinteraktive Prozessansichtfree -hRAM und Swap prüfenuptimeLaufzeit und Load AveragekillProzess gezielt beendenBeende keine unbekannten Systemprozesse. Starte lieber ein eigenes Testprogramm oder beobachte einen Prozess, den du selbst geöffnet hast.
Erstelle eine kleine Momentaufnahme deines Testsystems.
Führe ps aux aus. Finde deinen Terminalprozess und notiere PID, CPU- und Speichernutzung.
Starte top und beobachte eine Minute lang die Werte. Beende die Ansicht mit q.
Die Load Average ist keine Prozentzahl. Sie beschreibt, wie viele Aufgaben im Durchschnitt auf CPU-Zeit oder I/O warten.
Vergleiche die Ausgabe von free -h mit der Speicheranzeige in top. Was fällt dir auf?
Starte sleep 120 im Hintergrund mit sleep 120 &. Finde die PID und beende nur diesen Prozess mit kill PID.
MITTLERER TEIL / AUFGABE 05
Linux bringt Werkzeuge mit, um Verbindung, IP-Adressen, Routen und offene Sockets zu prüfen. Wichtig: In Linux heißt der typische Ersatz für Windows-ipconfig heute ip.
In dieser Aufgabe liest du Informationen aus. Ändere keine Netzwerkgeräte oder Routen auf einem System, das du nicht selbst kontrollierst.
ping -c 4Erreichbarkeit testenip addrInterfaces und Adressenip routeRoutingtabelle zeigenss -tulpenListening-Sockets prüfencurl -IHTTP-Header testenhostname -Ilokale IP kurz anzeigenFühre die Befehle aus und beschreibe, was du siehst.
Teste mit ping -c 4 1.1.1.1 eine IP und mit ping -c 4 example.com einen Namen. Vergleiche die Ergebnisse.
Wenn die IP klappt, der Name aber nicht, kann die Namensauflösung/DNS-Konfiguration das Problem sein.
Führe ip addr aus. Finde das aktive Interface, die IPv4-Adresse und die Loopback-Adresse 127.0.0.1.
Welche Zeile in ip route zeigt das Standard-Gateway? Notiere Interface und Gateway.
Prüfe mit ss -tulpen, ob lokale Dienste auf Ports lauschen. Recherchiere einen gefundenen Port.
FORTGESCHRITTEN / AUFGABE 06
Du bekommst das Ziel, aber nicht die fertige Lösung. Recherchiere die nötigen Schritte selbst und dokumentiere, warum dein Script funktioniert.
Erstelle ein Bash-Script, das eine Begrüßung ausgibt.
Recherchiere, welche Dateiendung und welche erste Zeile ein Bash-Script braucht. Lege hello.sh an.
Finde selbst heraus, welche Rechte eine Script-Datei braucht und wie du ein Script aus dem aktuellen Ordner startest.
Ergänze den aktuell angemeldeten Benutzer und das heutige Datum. Suche die passenden Bash-Möglichkeiten selbst.
Erstelle ein zweites Script, das Dateien in einem Verzeichnis zählt und die Anzahl ausgibt.
Recherchiere, wie ein Bash-Script einen Pfad als erstes Argument annimmt. Teste das Script mit einem Pfad und ohne Argument.
Finde selbst heraus, wie du reguläre Dateien direkt in einem Ordner zählst. Entscheide, ob Unterordner und versteckte Dateien berücksichtigt werden, und dokumentiere dein Verhalten.
Formuliere eine klare Ausgabe und behandle auch einen nicht existierenden Pfad. Suche die dafür passenden Bash-Konzepte selbst.
Nutze Suchbegriffe wie Bash-Shebang, ausführbare Scripts, Positionsparameter, Dateitypen und Exit-Status. Die Suchbegriffe ersetzen keine eigene Lösung.
FORTGESCHRITTEN / AUFGABE 07
Gute Wartung beginnt mit einer Momentaufnahme. Recherchiere selbst, wie du Speicher, Protokolle und Dienste beobachtest, bevor du über Maßnahmen nachdenkst.
Arbeite in deiner Linux-VM. Im fortgeschrittenen Teil bekommst du bewusst keine fertigen Befehle. Recherchiere passende Werkzeuge für deine Distribution und notiere kurz, warum du sie verwendest.
Finde heraus, wie du Gesamtgröße, Belegung und freien Platz eines Dateisystems lesbar anzeigen lässt.
Recherchiere, wo deine Distribution Systemmeldungen ablegt und wie du die neuesten Einträge begrenzt ausgibst.
Untersuche, wie du fehlgeschlagene Dienste erkennst, ohne sofort etwas neu zu starten oder zu ändern.
Schreibe eine kurze Diagnose mit Datum, Distribution, Recherchequellen und deinen Beobachtungen.
Recherchiere eine passende Möglichkeit und notiere für das Wurzel-Dateisystem die Gesamtgröße, Belegung, freien Platz und Auslastung. Erkläre außerdem den Unterschied zwischen lesbarer und genauer Byte-Anzeige.
Untersuche deinen Testordner. Finde selbst heraus, wie du Größen von Dateien und Unterordnern vergleichst. Dokumentiere, ob versteckte Einträge und Unterordner in deiner Auswertung enthalten sind.
Recherchiere, wie du genau die neuesten 20 Systemmeldungen anzeigen lässt. Wenn deine VM kein Journal bereitstellt, halte die Fehlermeldung fest und finde den vorgesehenen Speicherort deiner Distribution.
Suche zuerst nach der Dokumentation deiner Distribution. Die Namen und Speicherorte der Protokolle können sich unterscheiden.
Finde heraus, wie du fehlerhafte oder beendete Dienste sichtbar machst. Notiere einen auffälligen Dienst und recherchiere seine Aufgabe, ohne ihn blind neu zu starten.
Fasse zusammen, was du gemessen hast, was dir auffällt und welche Änderung du ausdrücklich noch nicht vorgenommen hast.
FORTGESCHRITTEN / MINI-PROJEKT
Verbinde die bisherigen Bausteine zu einem kleinen, sicheren Werkzeug. Du bestimmst selbst, wie dein Bash-Script eine Momentaufnahme sammelt und als Textreport ablegt.
Das Script soll ausschließlich lesend arbeiten. Es darf Informationen sammeln, aber keine Konfiguration ändern und nichts außerhalb deines Arbeitsordners löschen oder überschreiben. Die passenden Lösungen recherchierst du selbst.
Baue einen Report mit Benutzer, Zeit, Pfad, Speicher, RAM, Netzwerk und Logs.
Lege in deiner VM einen eigenen Report-Ordner innerhalb deines Lernbereichs an und arbeite ausschließlich dort.
Recherchiere, wie du in Bash klare Überschriften und Abschnitte ausgibst. Plane zuerst die Reihenfolge deines Reports, bevor du das Script schreibst.
Finde selbst passende Möglichkeiten für aktuellen Benutzer, Datum und Uhrzeit, Arbeitsverzeichnis, Speicherplatz, RAM, Netzwerk und die letzten 20 Protokolleinträge. Prüfe, welche Informationen ohne erhöhte Rechte lesbar sind.
Arbeite mit Suchbegriffen wie Bash-Variablen, Standardausgabe, Systeminformationen, Systemprotokolle und Berechtigungen. Die Stichworte ersetzen keine eigene Lösung.
Recherchiere Ausgabeumleitung sowie den Unterschied zwischen Überschreiben und Anhängen. Erzeuge daraus einen gut lesbaren Textreport mit einem eindeutigen Dateinamen.
Teste einen nicht lesbaren Bereich und einen ungültigen Pfad. Formuliere eine verständliche Meldung und recherchiere, wie dein Script einen passenden Exit-Status zurückgibt.
Starte dein Script zu zwei unterschiedlichen Zeitpunkten. Erkläre, welche Werte sich ändern können und warum dein Report trotzdem nachvollziehbar bleibt.
Recherchiere, wie du einen Zeitstempel im Dateinamen unterbringst, ohne problematische Sonderzeichen in Pfaden zu erzeugen.
Eine fremde Person kann deinen Report lesen, ohne dein Script öffnen zu müssen, und erkennt Fehler klar.
ABSCHLUSS / EIGENE NOTIZ
Zum Abschluss erstellst du eine eigene, kurze Referenz an einem Ort deiner Wahl. Recherchiere fehlende Lösungen selbst und halte nur fest, was du wirklich verstanden hast.
Erstelle linux-cheat-sheet.md oder ein gleichwertiges Dokument dort, wo du dauerhaft arbeiten möchtest: zum Beispiel im Code-Editor, in einer Notiz-App oder in einem Textdokument auf deinem Rechner. Die VM bleibt für die Linux-Praxisaufgaben.
Baue das Cheat-Sheet außerhalb der VM auf und halte es mit deinen Erkenntnissen aktuell.
Lege deine Markdown-Datei oder Notiz an einem Ort an, den du selbst bestimmst. Erstelle diese Abschlussdatei ausdrücklich nicht in der Linux-VM.
Nutze mindestens die Kategorien Navigation, Dateien, Rechte, Prozesse, Netzwerk und Wartung.
Recherchiere für jede Kategorie die passenden Werkzeuge. Schreibe pro Eintrag Zweck, eine echte Beispielzeile aus deinen Aufgaben und eine Erklärung in deinen eigenen Worten.
Markiere Einträge, die Dateien löschen, Rechte ändern, Netzwerkzugriff auslösen oder erhöhte Rechte verlangen. Ergänze, worauf du vor dem Ausführen achten musst.
Schließe deine Recherche und löse drei kleine Aufgaben nur mit deinem Cheat-Sheet. Ergänze fehlende Informationen erst danach.
NavigationPfad anzeigen · Inhalt lesen · Ordner wechselnDateienDateien lesen · bearbeiten · kopieren · Ordner anlegenRechteBenutzer prüfen · Rechte lesen · Zugriffe anpassenProzesseProzesse anzeigen · Systemlast beobachten · gezielt beendenNetzwerkVerbindung testen · Adressen prüfen · Ports untersuchenWartungSpeicher prüfen · Logs lesen · Laufzeit dokumentierenNETZWERK / LERNSTRECKE
Verstehe den Weg von Daten, ordne Geräte und Dienste ein und lerne, Verbindungsprobleme unter Windows 11 und in deiner Linux-VM systematisch einzugrenzen.
Die ersten Kapitel bauen das Vokabular auf. Danach liest du echte Netzwerkinformationen auf deinem Windows-11-System und vergleichst sie mit deiner Linux-VM. Notiere immer Beobachtung, Bedeutung und nächste Frage.
Vor dem Start
GRUNDLAGEN / AUFGABE 01
Ein Netzwerk ist nicht nur das Internet. Es verbindet Geräte, Programme und Dienste, damit Daten nach gemeinsamen Regeln ausgetauscht werden können.
Für eine Verbindung müssen drei Dinge zusammenpassen: eine physische oder drahtlose Strecke, eine Adresse und ein gemeinsames Protokoll. Denke an Straße, Hausnummer und Sprache.
Ein typischer Datenweg — Nicht jede Anfrage läuft exakt so, aber die Rollen helfen beim Einordnen.
Beantworte die Fragen in eigenen Worten und zeichne einen kleinen Datenweg.
Ordne Browser, Drucker, Windows-PC, Webserver und Dateiserver ein. Erkläre, warum ein Gerät je nach Situation beide Rollen übernehmen kann.
Client beschreibt die Anfrage, Server das Angebot eines Dienstes. Die Rolle hängt vom gerade betrachteten Vorgang ab.
Finde je ein Beispiel aus deinem Alltag für LAN, WLAN und WAN. Erkläre, warum WLAN eine Zugangstechnik sein kann, aber nicht automatisch ein eigenes IP-Netz ist.
Zeichne den Weg von deinem Windows-PC zu einer Webseite. Markiere, an welcher Stelle Kabel oder Funk, lokales Netz, Router und Zielserver vorkommen.
Überlege, welche Dinge im lokalen Netz eventuell noch funktionieren könnten, etwa ein Drucker oder eine interne Freigabe. Begründe deine Antwort.
Recherchiere, ob Bluetooth ebenfalls als Netzwerk betrachtet werden kann und worin sich Reichweite und Technik unterscheiden.
GRUNDLAGEN / AUFGABE 02
Netzwerkgeräte haben unterschiedliche Aufgaben. Wer Switch, Router, Access Point und Firewall auseinanderhalten kann, versteht den Datenweg deutlich leichter.
Verbindet Geräte innerhalb eines LAN und lernt lokale MAC-Adressen. Er routet nicht automatisch ins Internet.
Verbindet verschiedene IP-Netze und wählt anhand einer Routingtabelle den nächsten Weg.
Bringt WLAN-Geräte in ein kabelgebundenes Netz. Er ist nicht automatisch Router oder Firewall.
Erlaubt oder blockiert Netzwerkverkehr nach Regeln für Quelle, Ziel, Port, Protokoll und Zustand.
Aktive Hardware braucht Strom und verarbeitet Daten. Kabel, Dosen, Patchpanel und Stecker bilden die passive Strecke.
Twisted-Pair-Kupfer ist typisch im Büro. PoE kann Geräte über das Netzwerkkabel versorgen. Glasfaser überträgt mit Licht und eignet sich für lange Strecken.
Nutze ein Blatt, eine Notiz-App oder dein Cheat-Sheet — du musst keine echte Netzwerkkonfiguration ändern.
Ordne Switch, Patchkabel, Router, Patchpanel, Firewall, Access Point und Netzwerkdose den beiden Kategorien zu. Begründe eine Zuordnung.
Erkläre an einem Beispiel, warum ein Switch Geräte im lokalen Netz verbindet und ein Router für ein anderes IP-Netz gebraucht wird.
Frage dich: Muss nur ein lokaler Ethernet-Frame an den richtigen Port oder muss ein Paket über eine Netzgrenze weitergeleitet werden?
Formuliere den Merksatz „MAC lokal, IP über Netze“ in deinen eigenen Worten. Ergänze, was sich an einem Router beim Ethernet-Frame ändert.
Recherchiere Cat 5e, Cat 6, Cat 6A, PoE, Singlemode und Multimode. Notiere Einsatz, typische Entfernung und einen möglichen Fehler.
Erkläre, wie Gast-WLAN, Büro-PCs und technische Geräte über dieselbe Switch-Infrastruktur logisch getrennt werden können.
GRUNDLAGEN / AUFGABE 03
Eine IP-Adresse beschreibt ein Gerät logisch. Die Subnetzmaske hilft dem Gerät zu entscheiden, ob ein Ziel lokal erreichbar ist oder über das Standard-Gateway muss.
Beispiel: 192.168.10.42 / 24 — Bei dieser vereinfachten Darstellung gehören die ersten drei Oktette zum Netz.
Geräte wie 192.168.10.42 und 192.168.10.88 liegen typischerweise im selben /24-Netz. 192.168.11.5 liegt in einem anderen Netz und braucht für den Weg dorthin einen Router.
32 Bit, meist als vier Zahlen zwischen 0 und 255 geschrieben. Beispiel: 192.168.10.42.
128 Bit, hexadezimale Blöcke und deutlich größerer Adressraum. IPv4 und IPv6 laufen oft parallel als Dual Stack.
Trennt Netz- und Geräteanteil. 255.255.255.0 entspricht der häufigen Kurzschreibweise /24.
Die Router-Adresse, an die ein Client Ziele außerhalb seines eigenen Subnetzes weitergibt.
Arbeite mit Beispielen und später mit deiner echten Windows- oder VM-Konfiguration.
Ordne diese Paare für ein /24-Netz ein: 192.168.10.42 und 192.168.10.88; 192.168.10.42 und 192.168.11.5. Begründe jeweils deine Entscheidung.
Beschreibe, was passiert, wenn dein PC einen Drucker im eigenen Netz und danach einen Webserver in einem anderen Netz erreichen möchte.
Für das lokale Ziel wird kein Router zwischen den Netzen benötigt. Für das fremde Ziel nutzt der Client das Standard-Gateway.
Finde die drei privaten IPv4-Bereiche und erkläre, warum solche Adressen nicht direkt im öffentlichen Internet geroutet werden. Recherchiere auch die Rolle von NAT.
Suche auf Windows 11 und in deiner Linux-VM nach einer IPv6-Adresse. Notiere nur den Adresstyp oder einen gekürzten, unkritischen Beispielwert und erkläre die Schreibweise.
GRUNDLAGEN / AUFGABE 04
Viele Dinge wirken automatisch: Der PC bekommt eine Adresse, Namen werden gefunden und die Uhr stimmt. Dahinter stehen konkrete Netzwerkdienste.
Vergibt meist IP-Adresse, Subnetzmaske, Gateway und DNS-Server als zeitlich begrenzte Lease.
Übersetzt Namen wie example.com in IP-Adressen. Ohne DNS kann eine IP-Verbindung funktionieren, während ein Name scheitert.
Synchronisiert Uhrzeit. Das ist wichtig für Logs, Zertifikate, Anmeldung und die zeitliche Einordnung von Fehlern.
SMB ist typisch für Windows-Freigaben. SFTP überträgt Dateien sicher über SSH.
SMTP transportiert E-Mails. IMAP synchronisiert Postfachinhalte zwischen Client und Server.
Active Directory und LDAP verwalten Identitäten, Gruppen und Geräte in einer Umgebung.
Windows: ipconfig /allDHCP, Gateway und DNS lesenLinux: ip addrInterfaces und Adressen lesenWindows: nslookupNamensauflösung prüfenLinux: getent hostsNamen über lokale Auflösung prüfenVerbinde die Dienste mit einer Beobachtung aus Windows 11 oder deiner VM.
Nutze unter Windows ipconfig /all und suche nach DHCP, DNS-Server, Standard-Gateway und Lease-Zeiten. Notiere, welcher Wert welche Aufgabe erfüllt.
Prüfe mit nslookup example.com, welcher Name zu welcher IP aufgelöst wird. Wiederhole die Abfrage für einen zweiten bekannten Namen und vergleiche die Antwort.
DNS liefert eine Namensauflösung. Es beweist noch nicht, dass der Webdienst erreichbar oder der richtige Port offen ist.
Lies in der VM die Adresse und Route aus. Recherchiere anschließend, wie deine Distribution den verwendeten DNS-Server anzeigt.
Erstelle eine kleine Tabelle mit DNS, DHCP, NTP, SMB, SFTP, SMTP, IMAP und Active Directory/LDAP: Aufgabe, typischer Einsatz und ein mögliches Fehlerbild.
MITTLERER TEIL / AUFGABE 05
Wenn jemand sagt „Ich habe kein Internet“, prüfst du nicht alles gleichzeitig. Du arbeitest von der eigenen Konfiguration bis zum eigentlichen Dienst.
Öffne PowerShell oder die Eingabeaufforderung. Die folgenden Leseabfragen brauchen normalerweise keine administrativen Rechte. Nutze für Ziele außerhalb deines Netzes nur erlaubte, unkritische Tests.
ipconfig /allIP, Maske, Gateway, DHCP, DNSping <ziel>Erreichbarkeit und Antwortzeitnslookup <name>Namensauflösungtracert <name>Router-Hops zum ZielFühre die Schritte nacheinander aus und schreibe zu jedem Ergebnis einen Satz.
Führe ipconfig /all aus. Notiere Interface, IPv4-Adresse, Subnetzmaske, Standard-Gateway, DHCP-Server und DNS-Server. Teile keine vollständigen öffentlichen oder firmeninternen Werte.
Ersetze <gateway> durch dein eigenes Standard-Gateway und nutze ping <gateway>. Was sagt eine Antwort, was sagt keine Antwort?
Keine Antwort beweist keinen Kabeldefekt: ICMP kann gefiltert werden. Zusammen mit der IP-Konfiguration wird das Ergebnis aussagekräftiger.
Teste eine erlaubte IP-Adresse und anschließend einen Namen. Wenn die IP antwortet, der Name aber nicht, ist DNS eine naheliegende nächste Spur.
Nutze nslookup example.com. Notiere Server, aufgelöste Adresse und ob eine Fehlermeldung erscheint.
Starte tracert example.com. Erkläre, warum einzelne Hops als Sternchen erscheinen können und warum das nicht automatisch ein Ausfall ist.
MITTLERER TEIL / AUFGABE 06
Die VM ist dein sicherer Übungsraum. Du liest Interfaces, Routen und Namensauflösung aus und vergleichst sie mit deinem Windows-11-Host.
Je nach Virtualisierung läuft die VM im NAT-, Bridged- oder Host-only-Modus. Lies zuerst die aktuelle Konfiguration. Stelle den Modus nur um, wenn du genau weißt, warum und es ausdrücklich erlaubt ist.
ip addrInterfaces und IP-Adressenip routeRouten und Standard-Gatewayhostname -Ilokale IP kurz anzeigenping -c 4 <ziel>vier Antworten testenss -tulpenlokale Listening-Sockets lesenArbeite ohne Konfigurationsänderung und halte Unterschiede fest.
Führe ip addr aus. Finde das aktive Interface, eine IPv4-Adresse und die Loopback-Adresse 127.0.0.1. Erkläre, warum Loopback kein Weg ins Internet ist.
Prüfe ip route. Welche Zeile beschreibt die Standardroute? Notiere nur, welches Interface und welcher Gateway-Typ verwendet wird.
Teste zuerst eine IP und danach einen Namen mit ping -c 4. Vergleiche die Ergebnisse und formuliere, ob Namensauflösung eine mögliche Ursache ist.
Ein Ping kann durch eine Firewall blockiert werden. Nutze deshalb mehrere Beobachtungen und formuliere keine absolute Aussage aus nur einem Test.
Nutze ss -tulpen, um lauschende Ports zu sehen. Recherchiere einen Eintrag, aber prüfe nur deine eigene VM und ändere nichts.
Vergleiche Windows-Host und Linux-Gast bei IP-Adresse, Gateway, DNS und Internetzugriff. Schreibe dazu, ob die VM eher NAT, Bridged oder Host-only entspricht.
MITTLERER TEIL / AUFGABE 07
Die IP-Adresse findet ein Gerät. Der Port findet den Dienst auf diesem Gerät. Erst zusammen ergibt sich ein brauchbarer Zielpunkt.
Stellt Reihenfolge und bestätigte Zustellung her. Geeignet, wenn Vollständigkeit wichtig ist.
Weniger Overhead und keine Zustellgarantie. Geeignet für bestimmte schnelle oder einfache Übertragungen.
Vereinfacht: IP-Adresse, Port und Transportprotokoll bilden einen Kommunikationsendpunkt.
DNS 53, HTTP 80, HTTPS 443, SSH/SFTP 22, SMB 445. Ein Port allein beweist noch keinen funktionierenden Dienst.
Ordne IP, Port und Protokoll und bleibe bei Tests im eigenen Bereich.
Erkläre den Unterschied zwischen 192.168.10.42, Port 443 und dem Protokoll HTTPS. Formuliere daraus einen vollständigen Satz.
Ordne HTTP/HTTPS, DNS, SSH/SFTP, SMB, SMTP und IMAP jeweils einer Aufgabe zu. Ergänze, ob Vertraulichkeit oder Authentizitätsprüfung dazugehört.
Nutze unter Linux ss -tulpen und unter Windows 11 eine passende Lesemöglichkeit für lokale Verbindungen. Recherchiere einen Eintrag ausschließlich auf deinem eigenen System.
Recherchiere, wie du von Windows 11 aus eine einzelne erlaubte TCP-Verbindung zu Port 443 prüfst. Dokumentiere Ziel, Ergebnis und warum ein offener Port nicht automatisch eine sichere Anwendung bedeutet.
Erkläre, warum Portscanner und Tests gegen fremde Systeme nur nach ausdrücklicher Freigabe verwendet werden dürfen.
MITTLERER TEIL / AUFGABE 08
Diese Begriffe gehören zusammen, sind aber nicht dasselbe. Sicherheit entsteht durch mehrere Schichten und eine passende Konfiguration.
Filtert Verbindungen nach Regeln, zum Beispiel Quelle, Ziel, Port, Protokoll und Verbindungszustand.
Steht als Stellvertreter zwischen Client und Ziel. Er kann Webzugriffe erlauben, blockieren, protokollieren oder zwischenspeichern.
Baut einen verschlüsselten Tunnel über ein fremdes Netz auf. Das Zielsystem ist dadurch nicht automatisch sicher.
Schützt die Verbindung zwischen Browser und Webdienst durch Verschlüsselung und Prüfung der Gegenstelle.
Beobachte und dokumentiere nur. Ändere keine Firewall-Regel, VPN-Einstellung, Proxy-Konfiguration oder Freigabe ohne klare Anweisung.
Erkläre die Rollen und finde Beispiele, ohne Systeme zu verändern.
Schreibe je zwei Sätze zu Firewall, Proxy, VPN und TLS. Nenne jeweils, was geschützt oder kontrolliert wird und was nicht.
Öffne die Windows-11-Sicherheitsoberfläche oder eine reine Statusansicht und notiere, welche Profile es gibt. Ändere keine Einstellung.
Typische Profile heißen Domäne, Privat und Öffentlich. Welches aktiv ist, hängt vom aktuellen Netzwerkprofil ab.
Öffne eine bekannte HTTPS-Seite und beschreibe, woran du eine verschlüsselte Verbindung erkennst. Recherchiere die Rolle des Zertifikats, ohne Zertifikatsdaten zu kopieren.
Erkläre, warum ein VPN die Transportstrecke schützen kann, aber starke Passwörter, MFA, Updates und ein Rechtekonzept nicht ersetzt.
Formuliere drei Fragen, die du vor dem Öffnen eines Ports oder dem Installieren eines Netzwerktools stellen würdest.
PRAXISPROJEKT / AUFGABE 09
Aus „geht nicht“ wird eine brauchbare Diagnose: Du prüfst von unten nach oben, hältst Ergebnisse fest und begründest den nächsten Schritt.
Nutze Windows 11 und die Linux-VM. Führe keine riskanten Änderungen durch.
Beschreibe, welche Beobachtung auf ein Problem beim Adapter, DHCP oder der lokalen Verbindung hindeuten würde. Nenne zwei Prüfungen, die du zuerst machen würdest.
Simuliere den Gedankengang mit einem erlaubten IP-Test und einem Namenstest. Erkläre, warum DNS jetzt eine naheliegende Spur ist.
Ein erfolgreicher IP-Test zeigt nur, dass dieser Weg antwortet. Der Name braucht zusätzlich funktionierende Namensauflösung.
Überlege, welche Ursachen nach erfolgreicher DNS-Auflösung noch möglich sind: falscher Port, Firewall, Dienststatus, Zertifikat oder Anwendung.
Führe die Windows-Diagnose aus Aufgabe 05 und die VM-Diagnose aus Aufgabe 06 durch. Schreibe jeweils Beobachtung, Bedeutung und offenen Punkt in eine Tabelle.
Formuliere für einen Testfall eine begründete nächste Maßnahme. Schreibe auch dazu, welche Änderung du ausdrücklich nicht vorgenommen hast.
ABSCHLUSS / EIGENE NOTIZ
Fasse die Begriffe und Werkzeuge dort zusammen, wo du dauerhaft arbeitest. Das Dokument entsteht außerhalb der VM; die VM und Windows liefern nur deine Beispiele.
Erstelle eine Markdown-Datei, Notiz oder ein Dokument an einem Ort deiner Wahl. Ergänze zu jedem Eintrag Zweck, Beispiel, erwartetes Ergebnis und eine Sicherheitsnotiz.
Wähle die Einträge selbst aus und formuliere die Erklärungen in eigenen Worten.
Erkläre Client, Server, LAN, WLAN, WAN, Switch, Router, Firewall, Access Point, MAC, IP, Gateway, Port und Protokoll.
Notiere mindestens drei Windows-11- und drei Linux-Werkzeuge aus den Aufgaben. Schreibe jeweils dazu, welche Frage sie beantworten.
Ergänze DNS, DHCP, NTP, HTTP/HTTPS, SSH/SFTP, SMB, SMTP und IMAP mit Zweck und typischem Port, soweit du ihn verstanden hast.
Beschreibe mindestens drei Muster: keine IP, IP erreichbar aber Name nicht, Name erreichbar aber Dienst/Port nicht. Ergänze deine Prüfreihenfolge.
Schließe deine Notizen und erkläre einer anderen Person den Weg von einem Windows-PC zu einer Webseite. Danach löst du einen kleinen Diagnosefall nur mit deinem Cheat-Sheet.
Weg & HardwareClient · Switch · Router · Firewall · Access Point · KabelAdressierungMAC · IPv4/IPv6 · Subnetz · Gateway · NATDiensteDHCP · DNS · NTP · Datei · Mail · VerzeichnisWindows 11Konfiguration · Erreichbarkeit · DNS · RouteLinux-VMInterface · Route · DNS · lokale SocketsSicherheitFirewall · Proxy · VPN · TLS · RechteDOCKER / LERNSTRECKE
Beginne mit Virtualisierung und Containerisierung. Erst wenn die Begriffe sitzen, testest du Docker Desktop unter Windows 11 und Docker Engine in deiner Linux-VM.
Der Weg durch diesen Teil
01–08 Theorie: VM, Hypervisor, Container, Engine, Images, Registry und Compose.
09–10 Praxis: Erst Docker Desktop auf Windows 11, danach die CLI in der Linux-VM.
11–14 Aufbau: Eigenes Image, Compose-Stack, Daten/Sicherheit und ein Abschlussprojekt.
Vor der Praxis
Eine VM ist kein Container. Ein Image ist kein laufender Container. Und ein Registry-Tag ist keine unveränderliche Versionsnummer. Die Unterschiede begleiten dich durch alle Aufgaben.
THEORIE / KAPITEL 01
Virtualisierung stellt einem Gastbetriebssystem virtuelle Hardware bereit. Dadurch kann eine VM wie ein eigener Rechner arbeiten, obwohl sie Ressourcen eines vorhandenen Hosts nutzt.
Der physische Rechner stellt die echte Hardware und einen Teil seiner Ressourcen bereit. Unter Windows 11 ist das normalerweise dein Laptop oder Desktop.
Die VM sieht virtuelle CPU, Arbeitsspeicher, Festplatte und Netzwerkkarte. Darin läuft ein eigenes Betriebssystem, zum Beispiel Linux.
Der Hypervisor vermittelt zwischen Host und Gast. Typ-1-Hypervisor laufen direkt auf Hardware, Typ-2-Hypervisor als Programm auf einem Host-Betriebssystem.
Ein Snapshot merkt sich einen Zustand für einen späteren Rücksprung. Er ersetzt kein Backup und darf nicht als einzige Sicherung wichtiger Daten gelten.
Eine VM trennt Gast und Host deutlich, aber nicht magisch. Gemeinsame Ordner, Zwischenablage, Netzwerkbrücken und Sicherheitslücken können Grenzen der Trennung bilden.
Recherchiere die Antworten und zeichne den Weg der Ressourcen auf.
Erkläre Host, Gast, Hypervisor, virtuelle Festplatte und virtuelle Netzwerkkarte jeweils in einem Satz.
Finde den Unterschied zwischen Typ-1- und Typ-2-Hypervisor und ordne deine eigene VM vorsichtig ein. Begründe, welche Informationen dir für die Einordnung noch fehlen.
Beschreibe, was passiert, wenn du der VM mehr RAM oder zwei virtuelle CPU-Kerne gibst. Welche Ressource bleibt trotzdem gemeinsam mit dem Host?
Denke an echte Hardware, die nur verteilt, aber nicht vervielfacht wird: Die VM bekommt einen virtuellen Blick auf gemeinsame Ressourcen.
Recherchiere drei Unterschiede und notiere, wann ein Snapshot beim Lernen hilft und warum er kein vollständiger Schutz vor einem Festplattenausfall ist.
Zeichne Host → Hypervisor → Linux-Gast und ergänze mindestens CPU, RAM, Storage und Netzwerk. Hebe gemeinsam genutzte Stellen farblich hervor.
THEORIE / KAPITEL 02
Auf deinem Windows-11-System können mehrere Linux-Schichten nebeneinander existieren. Für Docker ist wichtig, ob du mit Docker Desktop, WSL2 oder einer eigenen Linux-VM arbeitest.
Docker Desktop kann je nach Konfiguration WSL2 oder Hyper-V beziehungsweise eine andere Virtualisierungsumgebung verwenden. Für die Aufgabe zählt nicht das Auswendiglernen einer Oberfläche, sondern dass du herausfindest, wo der Docker-Daemon tatsächlich läuft und welcher Rechner den Container ausführt.
Die VM teilt typischerweise den Internetzugang des Hosts. Von außen ist sie nicht automatisch wie ein eigenes Gerät erreichbar.
Die VM hängt wie ein eigenes Gerät im lokalen Netz. Dadurch kann sie eine eigene Adresse erhalten und ist je nach Firewall aus dem LAN erreichbar.
Host und Gast können miteinander sprechen, aber der Gast hat normalerweise keinen direkten Weg in das normale LAN oder Internet.
Ist das Docker-CLI nur der Client, oder läuft die Engine wirklich in dieser Umgebung? Genau diese Trennung prüfst du später.
Erstelle eine Tabelle für Windows 11, Docker Desktop/WSL2 und deine Linux-VM.
Finde heraus, welche Virtualisierungssoftware deine Linux-VM verwendet und ob Docker Desktop bei dir aktiv ist. Notiere nur die bereits sichtbaren Informationen.
Recherchiere, wie WSL2 den Linux-Kernel bereitstellt und wie sich das von einer klassischen VM mit kompletter Distribution unterscheidet.
Untersuche die aktuelle VM-Konfiguration und ordne sie vorsichtig NAT, Bridged oder Host-only zu. Begründe die Zuordnung mit Beobachtungen, nicht mit Vermutungen.
Zeichne zwei Wege: Windows PowerShell → Docker Desktop → Container und Linux-VM-Terminal → Docker Engine → Container. Markiere, wo der Befehl verarbeitet wird.
THEORIE / KAPITEL 03
Ein Container ist ein isolierter Prozess mit seinem Dateisystem und seinen Abhängigkeiten. Er startet aus einem Image und teilt sich den Kernel der Umgebung, in der die Engine läuft.
Ein Image enthält die Vorlage für einen Container: Dateisystemschichten, Metadaten und den Startpunkt der Anwendung. Es läuft noch nicht.
Ein Container ist eine gestartete Instanz eines Images. Er hat einen eigenen Prozessraum und eine beschreibbare temporäre Schicht.
Namespaces begrenzen, was ein Prozess von anderen Prozessen sehen kann, zum Beispiel Prozesse, Netzwerk oder Mounts.
Control Groups begrenzen oder messen Ressourcen wie CPU und Arbeitsspeicher. Sie machen aus einem Container aber keine eigene Hardware.
Eine VM bringt normalerweise einen eigenen Gastkernel mit. Container teilen den Kernel der Engine-Umgebung. Deshalb sind Kernel, Rechte, Images und die Engine-Sicherheitsgrenzen im produktiven Betrieb wichtig.
Formuliere den Unterschied so, dass ihn eine andere Person nachvollziehen kann.
Schreibe je eine eigene Definition für Image, Container und virtuelle Maschine. Vermeide die Formulierung „alles ist ein Paket“ und nenne den Startpunkt jeder Einheit.
Recherchiere, warum Container unter Linux besonders direkt funktionieren und welche Rolle der Kernel bei der Isolation spielt.
Erkläre den Weg von „Image liegt lokal“ über „Container läuft“ bis „Container beendet“. Was bleibt erhalten und was verschwindet ohne Volume?
Trenne das Image, die beschreibbare Container-Schicht und dauerhaft gespeicherte Daten. Diese drei Dinge haben unterschiedliche Lebenszyklen.
Liste drei Grenzen oder Risiken auf: Kernel-Schwachstelle, zu weitreichende Rechte, offene Ports oder unkontrollierte Mounts sind mögliche Spuren.
THEORIE / KAPITEL 04
Container lösen ein konkretes Problem: Eine Anwendung soll mit ihren Abhängigkeiten reproduzierbar gebaut und in verschiedenen Umgebungen ähnlich gestartet werden können.
Ein beschriebenes Image lässt sich erneut bauen. Dadurch wird sichtbarer, welche Basis und welche Abhängigkeiten eine Anwendung braucht.
Das gleiche Artefakt kann auf dem Laptop, in der Linux-VM oder auf einem Server laufen, sofern die Engine und die Plattform passen.
Container teilen den Kernel und starten typischerweise leichter als komplette VMs. Das spart nicht automatisch alle Ressourcen.
Container ersetzen kein Monitoring, keine Backups, keine Rechteplanung und keine sichere Lieferkette. Sie können Probleme auch nur schneller verteilen.
„Läuft bei mir“ soll nicht von Hand installierten Paketen und zufälligen Einstellungen abhängen. Docker macht den Weg vom Quellcode zum startbaren Artefakt sichtbar und wiederholbar.
Bewerte Vorteile und Nachteile für ein kleines internes Webprojekt.
Beschreibe, welche Schritte bei einer manuellen Installation von Laufzeit, Bibliotheken und Konfiguration schiefgehen können. Vergleiche das mit einem Image-Build.
Erkläre, warum ein Image zwischen Windows 11, Linux-VM und Linux-Server portabel sein kann, aber trotzdem CPU-Architektur, Kernel, Speicher und Netzwerk berücksichtigt werden müssen.
Notiere mindestens drei Vorteile und drei neue Verantwortungen, die Container mitbringen. Dazu gehören beispielsweise Updates, Datenhaltung, Logs, Rechte und Image-Herkunft.
Recherchiere, warum „Container läuft“ noch keine Aussage über Verfügbarkeit, Sicherheit oder Datensicherung ist. Formuliere eine Checkliste mit fünf offenen Fragen.
THEORIE / KAPITEL 05
Wenn du einen Docker-Befehl eingibst, arbeitet meist ein Client mit einem Docker-Daemon zusammen. Docker Desktop verpackt diese Bausteine für den Desktop-Betrieb.
Die CLI ist nicht automatisch der Ort, an dem ein Container läuft. Sie kann einen lokalen oder bewusst eingerichteten entfernten Daemon ansprechen. Diese Trennung ist im Betrieb wichtig, weil Zugang zu einem Docker-Daemon weitreichende Kontrolle bedeuten kann.
Das Kommandozeilenprogramm nimmt deine Anweisung entgegen und spricht die Engine-API an.
Der lang laufende Dienst verwaltet Images, Container, Netzwerke und Volumes und führt die Aufträge aus.
Die Desktop-Anwendung bündelt UI, Engine, Integrationen und je nach Backend die Linux-Umgebung für Container.
Eine entfernte Engine ist kein Spielzeug: Socket, TLS, Benutzerrechte und Netzwerkzugriff müssen ausdrücklich abgesichert werden.
Zeichne den Weg eines Containerstarts und erkläre jede Station.
Ordne CLI, Docker Desktop, API, Daemon, Image, Container, Netzwerk und Volume in ein eigenes Schaubild ein.
Recherchiere, woran ein Docker-Client erkennt, welchen Daemon er anspricht. Notiere, warum ein falsch konfigurierter Zugriff sicherheitskritisch wäre.
Formuliere je einen Satz dazu, wofür Images, Container, Netzwerke und Volumes im Engine-Modell stehen.
Finde eine Aktion, die du in Docker Desktop und per CLI durchführen kannst. Vergleiche, welche Informationen die Oberfläche zeigt und welche die CLI dokumentierbarer macht.
THEORIE / KAPITEL 06
Ein Image wird nicht als ein einziger undurchsichtiger Block gebaut. Es besteht aus Schichten und Metadaten, die aus einer Build-Beschreibung entstehen können.
FROMLegt eine Basis fest. Prüfe Herkunft, Version und Pflegezustand, bevor du sie übernimmst.
WORKDIRDefiniert den Arbeitsort im Image und macht Pfade im Dockerfile nachvollziehbarer.
COPYÜbernimmt Dateien aus dem Build-Kontext. Geheimnisse gehören nicht unkontrolliert in den Kontext.
CMD / ENTRYPOINTBeschreiben, was beim Start ausgeführt werden soll. Recherche nötig: beide Direktiven haben unterschiedliche Rollen.
Wenn eine Anwendung zur Laufzeit Daten erzeugt, gehören diese in ein geeignetes Volume oder einen bewusst gewählten Mount. Ein erneuter Containerstart soll nicht versehentlich deine Daten vernichten.
Baue den Ablauf als Skizze und prüfe, welche Dateien wirklich im Kontext liegen.
Recherchiere, warum sich Dockerfile-Schritte auf den Build-Cache auswirken. Erkläre, warum häufig veränderte Dateien eher weiter unten im Dockerfile stehen.
Ordne FROM, WORKDIR, COPY, RUN und CMD in einen plausiblen Ablauf. Begründe die Reihenfolge, ohne eine fertige Datei abzuschreiben.
Liste Dateien auf, die niemals in ein Image gehören sollten. Recherchiere, wie eine Ignore-Datei den Kontext begrenzt.
Ordne Betriebssystempaket, Anwendungscode, Logdatei und Datenbankdaten entweder Image-Schicht, Container-Layer oder Volume zu und begründe jede Entscheidung.
THEORIE / KAPITEL 07
Eine Registry ist ein Speicher- und Verteilpunkt für Images. Sie kann öffentlich, privat oder selbst betrieben sein. Vor jedem Pull prüfst du Quelle, Version und Vertrauen.
[HOST[:PORT]/]NAMESPACE/REPOSITORY[:TAG]
Beispiel: registry.example/azubi/web:lernstandImages können von vielen Teams gefunden werden. Prüfe Organisation, Maintainer, Dokumentation, Aktualität und bekannte Herkunft.
Unternehmen speichern eigene Images geschützt. Zugriffe, Rollen, Aufbewahrung und Bereinigung gehören zum Betrieb.
Ein Tag wie latest oder v1 ist ein lesbarer Verweis, der später auf ein anderes Image zeigen kann.
Ein Digest identifiziert den Inhalt per Hash. Er hilft, exakt dasselbe Artefakt zu referenzieren, ersetzt aber keine Update- und Sicherheitsstrategie.
Ein Image kann Software, Konfiguration und Startskripte mitbringen. Nutze freigegebene Quellen, lies die Dokumentation, prüfe Updates und veröffentliche interne Daten niemals in einer öffentlichen Registry.
Beschreibe die Lieferkette ohne Zugangsdaten oder echte Push-Aktionen.
Markiere in drei Beispielnamen Host, Namespace, Repository und Tag. Recherchiere, wann ein Port in einer Registry-Adresse nötig ist.
Erkläre mit einem Beispiel, warum ein Tag bequem zu lesen ist, aber nicht dieselbe Unveränderlichkeit wie ein Digest bietet.
Erstelle eine Prüfliste mit fünf Fragen, bevor du ein Image aus Docker Hub oder einer internen Registry verwendest.
Skizziere den Weg Test → Freigabe → Registry → Linux-Server. Markiere, wo du einen unveränderlichen Verweis, Scan, Review und Rollback brauchst.
Denke an Software-Lieferketten: Das gebaute Artefakt sollte nicht stillschweigend zwischen Test und Produktion ausgetauscht werden.
THEORIE / KAPITEL 08
Compose beschreibt mehrere zusammengehörige Services in einer YAML-Datei. Dadurch wird aus einzelnen Startbefehlen eine nachvollziehbare Anwendung mit Netzwerken, Volumes und Abhängigkeiten.
Beschreibt eine laufende Komponente und meist das Image, Ports, Umgebungsvariablen, Volumes und Netzwerke.
Verbindet Services kontrolliert. Ein interner Service muss nicht automatisch auf dem Windows-Host veröffentlicht werden.
Lagert dauerhafte Daten aus dem vergänglichen Container-Layer aus. Backup und Besitz bleiben trotzdem deine Aufgabe.
Prüft, ob ein Dienst tatsächlich antwortet. „Container läuft“ und „Anwendung ist bereit“ sind nicht dasselbe.
Compose kann einen Stack reproduzierbar starten, aber es nimmt dir keine Entscheidung über Images, Secrets, Daten, Ports, Updates oder die Zielumgebung ab.
Nutze die Compose-Datei dieser lokalen Wiki-App als ungefährliches Architekturbeispiel.
Finde Service, Image oder Build, Portfreigabe, Netzwerk, Volume und Healthcheck. Schreibe neben jeden Eintrag seine Aufgabe.
Erkläre, warum ein Portmapping zwei Seiten hat und was es bedeutet, wenn ein Dienst nur intern im Compose-Netzwerk erreichbar ist.
Recherchiere den Unterschied zwischen „Service wurde gestartet“ und „Service ist bereit“. Überlege, wann ein Healthcheck oder eine Retry-Logik gebraucht wird.
Liste drei Unterschiede auf, die du bei einem Compose-Stack zwischen Laptop, Linux-VM und produktivem Server dokumentieren müsstest.
PRAXIS / WINDOWS 11
Arbeite zuerst auf deinem Windows-11-System. Docker Desktop soll bereits eingerichtet sein. Du nutzt Oberfläche und PowerShell, beobachtest Zustände und räumst nur deine eigenen Testobjekte auf.
Wenn Docker Desktop fehlt, nicht startet oder Adminrechte verlangt, halte an und kläre die Umgebung. Installiere oder ändere keine Systemkomponente im Rahmen dieser Aufgabe selbstständig.
docker versionClient und Engine vergleichendocker runContainer aus Image startendocker pslaufende Container lesendocker logsAusgaben eines Containers prüfendocker inspectMetadaten und Konfiguration lesendocker image lslokale Images inventarisierenRecherchiere die genaue Syntax und dokumentiere jede Beobachtung in deinen Notizen.
Öffne Docker Desktop und prüfe mit der Versionsansicht oder dem passenden CLI-Aufruf, ob Client und Engine antworten. Notiere, wo die Engine laut deiner Recherche läuft.
Starte das von Docker bereitgestellte Lern-/Test-Image nach Anleitung. Erkläre anschließend, warum ein Container nach seinem Prozessende nicht mehr als laufender Container erscheint.
Starte einen kleinen vertrauenswürdigen Webdienst nur lokal. Finde heraus, wie du einen Port am Host veröffentlichst, öffne die Seite und ordne Host-Port und Container-Port zu.
Nutze Desktop oder CLI, um Image, Containerstatus, Logs, Startzeit und Portmapping zu finden. Schreibe auf, welche Information woher kommt.
Stoppe und entferne ausschließlich deine eigenen Testcontainer und Images nach Anleitung. Verwende keine pauschalen Aufräumbefehle wie docker system prune -a.
PRAXIS / LINUX-VM
Jetzt wiederholst du den Ablauf in der Linux-VM. Produktiv wird Docker häufig ohne grafische Oberfläche per CLI betrieben; deshalb lernst du Zustände, Logs, Ports und Lebenszyklen bewusst zu lesen.
Die Docker Engine und CLI sollten bereits installiert und freigegeben sein. Prüfe erst die Umgebung. Installiere nichts auf deinem Windows-Host oder auf einem fremden Server.
Arbeite über das Terminal und recherchiere die Befehlsvarianten für deine Distribution.
Finde heraus, wie du Distribution, Benutzer, Docker-Client und Engine-Status nur lesend prüfst. Notiere, ob dein Benutzer für Docker besondere Rechte braucht.
Starte ein freigegebenes Test-Image in der VM. Notiere Image-Referenz, Containerstatus, Prozessende und die Ausgabe.
Starte einen kleinen Dienst im Hintergrund mit einer nur für dein Lernnetz geeigneten Portfreigabe. Prüfe Status, Logs und Erreichbarkeit aus der VM.
Zeige den Unterschied zwischen Stoppen, Starten, Entfernen und einem neuen Container aus demselben Image. Schreibe auf, welche Daten dabei nicht garantiert erhalten bleiben.
Vergleiche Engine-Ort, Terminal, Netzwerk, Dateipfade und Portzugriff mit Aufgabe 09. Erkläre, warum die Befehle ähnlich aussehen, aber die Umgebung nicht identisch ist.
BUILD / AUFGABE 11
Verpacke ein kleines, ungefährliches Lernprojekt. Das Ziel ist nicht eine große Anwendung, sondern ein nachvollziehbarer Weg von Dateien über Dockerfile und Build bis zum laufenden Container.
FROM <freigegebene-basis>
WORKDIR <arbeitsordner>
COPY <projektdateien> <ziel>
<optionale-schritte>
CMD [<startbefehl>]Fülle das Denkgerüst für eine kleine statische Seite oder ein Mini-Programm selbst. Recherchiere, welche Basis zu deiner Anwendung passt und warum ein nicht-root Benutzer sinnvoll sein kann.
Arbeite zuerst in einem neuen lokalen Ordner und halte jede Entscheidung fest.
Lege eine kleine Startdatei und ein Dockerfile an. Erstelle außerdem eine Ignore-Datei und begründe, welche Dateien nicht in den Build-Kontext gehören.
Finde die richtige Verwendung von FROM, WORKDIR, COPY, RUN, CMD und optional USER. Schreibe die Erklärung neben jede Zeile.
Recherchiere den Build-Aufruf und vergib einen eindeutigen lokalen Namen mit Tag. Prüfe danach Größe, Layer und Metadaten des Images.
Starte das Image, veröffentliche nur den nötigen lokalen Port und prüfe die Anwendung. Vergleiche den Port im Container mit dem Port auf Windows 11 oder in der Linux-VM.
Finde mindestens eine Verbesserung bei Build-Kontext, Layer-Reihenfolge, Basis-Version, Benutzerrechten oder Dokumentation und begründe sie.
COMPOSE / AUFGABE 12
Jetzt beschreibst du dein Lernprojekt als Compose-Stack. Verwende nur die Services, die du wirklich erklären kannst, und halte Ports, Daten und Startverhalten sichtbar.
docker compose configZusammengeführte Konfiguration prüfendocker compose upStack startendocker compose psServices und Status lesendocker compose logsAusgaben nach Service prüfendocker compose downeigenen Stack beendendocker compose pullfreigegebene Images aktualisierenLeite dich an der lokalen Wiki-App und danach an deinem eigenen kleinen Stack entlang.
Erstelle eine Compose-Datei für dein eigenes Image. Entscheide, welcher Host-Port gebraucht wird und welche Ports intern bleiben können.
Nutze die reine Prüfphase, bevor du startest. Recherchiere, wie Variablen ersetzt werden und wie du einen Tippfehler in YAML erkennst.
Starte den Stack, lies Service-Zustände und Logs und rufe die Anwendung auf. Dokumentiere, welcher Container welchen Zweck hat.
Füge nur dann ein Volume hinzu, wenn du erklären kannst, welche Daten darin liegen und wie du sie sichern oder löschen würdest.
Beende nur deinen Compose-Projektbereich. Prüfe anschließend, ob Images oder Volumes absichtlich bleiben und dokumentiere deinen Aufräumweg.
BETRIEB / AUFGABE 13
Ein Container ist schnell gestartet. Der Betrieb beginnt dort, wo du Daten, Zugriffe, Updates, Logs und Wiederherstellung bewusst planst.
Die Engine verwaltet den Speicherort. Das ist bequem, aber du musst trotzdem wissen, wie Backup und Restore funktionieren.
Ein Host-Pfad wird in den Container eingebunden. Das ist für Entwicklung praktisch, kann aber zu falschen Rechten oder zu viel Zugriff führen.
Ein veröffentlichter Port macht einen Dienst vom Host oder Netzwerk aus erreichbar. Veröffentliche nur, was wirklich gebraucht wird.
Umgebungsvariablen sind nicht automatisch ein sicherer Secret-Speicher. Nutze freigegebene Verfahren und möglichst geringe Rechte.
Basis-Images, Abhängigkeiten und Anwendung müssen gepflegt werden. Ein alter Tag kann bekannte Schwachstellen enthalten.
Logs, Metriken und Healthchecks helfen bei der Diagnose. Sie ersetzen kein Alarmierungs- und Wiederherstellungskonzept.
Verwende in gemeinsamer Umgebung niemals pauschale Lösch- oder Prune-Befehle. Prüfe zuerst Namen, Projekt und Abhängigkeiten und entferne nur deine eigenen Testobjekte.
Überprüfe deinen kleinen Compose-Stack wie ein verantwortlicher Betreiber.
Zeichne Client, veröffentlichte Ports, interne Services, Volumes und Registry. Markiere, wo Daten dauerhaft liegen.
Liste alle veröffentlichten Ports, Mounts und Benutzerrechte auf. Recherchiere, welche davon du reduzieren kannst.
Was passiert bei Container-Neustart, Image-Update, vollem Speicher oder nicht erreichbarer Registry? Notiere jeweils eine Beobachtung und eine erste Maßnahme.
Beschreibe einen sicheren Ablauf für Image-Update, Test, Freigabe und Rollback. Verwende dabei keine echten Zugangsdaten.
Recherchiere Container-Scanning, Rootless-Betrieb und minimale Basis-Images. Schreibe dazu, welche Aussage du verstanden hast und welche Frage offen bleibt.
ABSCHLUSS / EIGENE DOKUMENTATION
Zum Abschluss verbindest du Theorie, Windows-11-Praxis, Linux-VM und Compose. Das Cheat-Sheet erstellst du außerhalb der VM an dem Ort, an dem du später selbst danach suchen würdest.
Nutze eine Markdown-Datei, ein lokales Dokument, eine Notiz-App oder einen anderen von dir gewählten Ort. Die VM liefert nur Beobachtungen; sie ist nicht der vorgeschriebene Speicherort.
Baue kein großes Produkt. Liefere einen nachvollziehbaren Lernstand mit sauberer Dokumentation.
Wähle eine kleine Anwendung oder statische Seite. Schreibe Ziel, Eingaben, Ausgabe und benötigte Abhängigkeiten auf.
Baue ein eigenes Image mit Dockerfile, prüfe die Layer und dokumentiere Basis, Tag und Startverhalten.
Führe dein Image mit Compose aus. Notiere Service, Port, Netzwerk, Volume und Healthcheck oder begründe, warum du etwas nicht brauchst.
Starte und prüfe das Projekt in Docker Desktop und in der Linux-VM. Halte Unterschiede bei Pfaden, Ports, Netzwerk und Engine fest.
Entscheide, ob das Image überhaupt in eine Registry darf. Falls ja: Quelle, Namespace, Tag, Digest, Zugriff, Scan und Rollback dokumentieren. Noch nichts öffentlich pushen.
GrundbegriffeVM · Host · Gast · Hypervisor · Image · Container · EngineLebenszyklusBuild · Pull · Run · Logs · Inspect · Stop · RemoveComposeService · Network · Volume · Port · Healthcheck · ConfigRegistryHost · Namespace · Repository · Tag · Digest · Pull · PushBetriebLogs · Updates · Rechte · Daten · Backup · RollbackSicherheitQuelle prüfen · keine Secrets · minimale Ports · eigene TestobjekteSchreibe nicht nur Befehle ab. Zu jedem Eintrag gehören Zweck, Beispiel und Sicherheitsnotiz.
Lege Abschnitte für VM/Container, Images, Container-Lebenszyklus, Compose, Registry, Daten und Sicherheit an.
Ergänze nur Befehle und Ausgaben, die du selbst verstanden und in einer eigenen Lernumgebung getestet hast. Nutze Platzhalter statt echter Zugangsdaten.
Dokumentiere mindestens fünf Fälle: Engine nicht erreichbar, Image fehlt, Port belegt, Container beendet sich, Volume oder Registry-Zugriff funktioniert nicht.
Lass eine andere Person einen Eintrag lesen und den Zweck erklären. Überarbeite Stellen, die nur aus einer Befehlszeile ohne Kontext bestehen.