#Ausführlicher Lernpfad: Windows 10 + WSL2 + VS Code + IntelliJ + Codex + OKD

Stand: 02.07.2026
Ziel: Du baust eine stabile Entwicklungsumgebung auf Windows 10, arbeitest mit Projekten in WSL2/Linux, nutzt VS Code und IntelliJ als IDEs, verwendest Codex sowohl in WSL als auch nativ unter Windows und installierst OKD lokal als Lerncluster über CRC. Diese Version enthält mehr Erklärungen, mentale Modelle, Fehlerdiagnosen und Übungsaufgaben.

Kernaussage: Installiere die IDE-Oberflächen in der Regel unter Windows. Die Projektdateien, Git, Compiler, Node/JDK/Python und Codex-CLI laufen je nach Workflow in WSL2. VS Code verbindet sich über die WSL-Extension; IntelliJ öffnet WSL-Projekte direkt oder über JetBrains Gateway.

#0. Wie du diesen Lernpfad liest

Dieser Lernpfad ist wie eine Landkarte aufgebaut. Du sollst nicht nur Befehle kopieren, sondern verstehen, welcher Teil deines Systems welche Aufgabe übernimmt. Das ist besonders wichtig, weil du hier mehrere Welten kombinierst:

Windows 10 = Desktop, Fenster, IDE-Oberflächen, Hypervisor, CRC-VM
WSL2       = Linux-Werkstatt für Code, Git, Shell, Toolchains, Codex CLI
VS Code    = Windows-App mit Remote-Verbindung in WSL
IntelliJ   = Windows-App, die WSL-Projekte und WSL-Runtimes nutzen kann
Codex      = KI-Agent, der entweder im Windows-Kontext oder im WSL-Kontext arbeitet
OKD        = Kubernetes/OpenShift-Lerncluster, lokal als VM über CRC

#Das wichtigste Prinzip

Trenne immer diese drei Fragen:

Wenn etwas nicht funktioniert, löst du das Problem meistens, indem du diese drei Fragen erneut beantwortest.

#Lernmethode: erst Bild, dann Befehl

Nutze bei jedem Abschnitt diese Reihenfolge:

1. Bild verstehen: Was spricht mit wem?
2. Befehl ausführen: Einen kleinen Schritt machen.
3. Ergebnis prüfen: Mit status, version, whoami, pwd, git status kontrollieren.
4. Notizen machen: Was hat funktioniert, was nicht?
5. Erst dann automatisieren: Codex erst einsetzen, wenn du den Ablauf grob verstehst.

#Mini-Legende

🧠 Erklärung       = Warum dieser Schritt wichtig ist
🧪 Prüfung         = So erkennst du, ob es funktioniert
🧯 Fehlerbild      = Typischer Fehler und Reparatur-Idee
🤖 Codex-Hinweis   = Wie du Codex sinnvoll einsetzt

#Sidebar-Verzeichnis

• 0. Wie du diesen Lernpfad liest
• 1. Zielbild
• 2. Architekturkarte
• 3. Was kommt wohin?
• 4. Woche 1: WSL2 stabil machen
• 5. Woche 2: VS Code auf WSL einrichten
• 6. Woche 3: IntelliJ mit WSL nutzen
• 7. Woche 4: Codex CLI, IDE-Extension und Alltag
• 8. Codex nativ auf Windows
• 9. Codex in WSL
• 10. Plugins und Extensions
• 11. Erster Testlauf
• 12. Fehlerbilder und Lösungen
• 13. Sicherheits- und Arbeitsregeln
• 14. OKD lokal installieren: CRC auf Windows + WSL anbinden
• 15. Befehls-Spickzettel
• 16. Gesamt-Checkliste
• 17. Nächste Lernstufen
• 18. Quellen

#1. Zielbild

#1.1 Was du am Ende wirklich können sollst

Das Ziel ist nicht, „alles irgendwie installiert“ zu haben. Das Ziel ist, dass du bewusst zwischen mehreren Arbeitsplätzen wechseln kannst:

Arbeitsplatz A: Linux-Projekt
  Windows öffnet IDE  →  WSL enthält Repo  →  Codex läuft in WSL  →  Tests laufen in Linux

Arbeitsplatz B: Windows-Projekt
  Windows enthält Repo  →  PowerShell führt Befehle aus  →  Codex läuft nativ auf Windows

Arbeitsplatz C: OKD-Lerncluster
  PowerShell startet CRC  →  OKD läuft als VM  →  WSL nutzt oc und YAML-Dateien

Der häufigste Anfängerfehler ist, diese Arbeitsplätze zu vermischen. Beispiel: Das Repo liegt unter C:\Users\..., aber die Tests laufen in WSL. Das kann funktionieren, ist aber oft langsam und erzeugt Rechte-, Pfad- oder Zeilenende-Probleme. Für Linux-Projekte ist daher die Grundregel:

Repo in WSL speichern. IDE von Windows aus verbinden. Befehle im WSL-Terminal ausführen.

#1.2 Was „installieren“ hier bedeutet

„Installieren“ heißt in diesem Setup nicht überall dasselbe:

#1.3 Lernkontrolle

Du hast diesen Abschnitt verstanden, wenn du erklären kannst:

• warum VS Code unter Windows installiert wird, aber trotzdem „in WSL“ arbeitet;
• warum ein Repo unter ~/code meist besser ist als unter /mnt/c/Users/...;
• warum Codex in Windows und Codex in WSL zwei getrennte Installationen sind;
• warum OKD/CRC auf dem Windows-Host läuft und WSL nur mit oc darauf zugreift.

Nach diesem Lernpfad kannst du:

• WSL2 auf Windows 10 prüfen, aktualisieren und sinnvoll strukturieren.
• Projekte unter ~/code/... in Linux speichern, statt langsam unter /mnt/c/... zu arbeiten.
• VS Code von WSL aus mit code . öffnen.
• IntelliJ mit WSL-Projekten, WSL-Git und WSL-Runtimes verwenden.
• Codex in zwei getrennten Umgebungen nutzen:
  • WSL-Codex: Linux-native Arbeit an WSL-Repositories.
  • Windows-Codex: native Windows-Projekte, PowerShell, Windows-Sandbox.
• Codex als CLI, VS-Code-Extension und JetBrains-Integration verwenden.
• OKD lokal mit CRC starten, per oc bedienen und aus WSL/IDE/Codex deployen.

#2. Architekturkarte

#2.1 Die Architektur in einfachen Worten

Stell dir dein System wie ein Haus mit Werkstatt vor:

Windows ist das Haus:
  Bildschirm, Fenster, Tastatur, Installer, Hyper-V/Virtualisierung.

WSL2 ist die Linux-Werkstatt im Haus:
  Dort liegen Werkzeuge wie git, node, java, python, bash und codex.

CRC/OKD ist eine zusätzliche Maschine in der Garage:
  Sie läuft als eigene VM und stellt Kubernetes/OpenShift-Funktionen bereit.

Die IDE ist dabei nicht der Ort, an dem alles installiert sein muss. Sie ist eher das Cockpit. Das Cockpit kann Befehle an WSL senden, Dateien in WSL anzeigen und Terminals in WSL öffnen.

#2.2 Kommunikationswege merken

VS Code → WSL Extension → VS Code Server in WSL → Projektdateien
IntelliJ → \\wsl.localhost\... → Projektdateien und WSL-Tools
PowerShell → crc.exe → OKD-VM
WSL → oc login → OKD API
Codex in WSL → liest/ändert Dateien im WSL-Repo
Codex in Windows → liest/ändert Dateien im Windows-Repo

Wenn eine Fehlermeldung kommt, frage zuerst: Auf welchem Kommunikationsweg bin ich gerade?
Ein DNS-Problem zu api.crc.testing ist ein anderes Problem als ein fehlender code-Befehl in WSL.

#Bildliche Merkhilfe

┌──────────────────────────── WINDOWS 10 ────────────────────────────┐
│  VS Code UI       IntelliJ UI       PowerShell       Codex Windows  │
│      │              │                │                  │           │
│      │ WSL Remote   │ WSL Pfad       │ wsl              │ native    │
└──────┼──────────────┼────────────────┼──────────────────┼───────────┘
       ▼              ▼                ▼                  ▼
┌──────────────────────────── WSL2 / Ubuntu ─────────────────────────┐
│  ~/code/projekt     git     node/jdk/python     codex     tests     │
└─────────────────────────────────────────────────────────────────────┘

#3. Was kommt wohin?

#3.1 Warum diese Trennung so wichtig ist

Windows und Linux benutzen unterschiedliche Annahmen:

WSL kann zwar auf Windows-Dateien zugreifen, aber das ist eine Übersetzungszone. Für einfache Dateien ist das okay. Für große Repos, viele node_modules, Symlinks, Tests oder Container-nahe Arbeit ist das oft langsam oder fehleranfällig.

#3.2 Gute Ordnerstruktur

Empfehlung:

Windows:
C:\Users\<du>\code\windows-projekte
C:\Tools\crc

WSL:
/home/<du>/code/linux-projekte
/home/<du>/code/okd-yaml
/home/<du>/bin

Nicht ideal für Linux-Projekte:

/mnt/c/Users/<du>/Desktop/mein-projekt
/mnt/c/Users/<du>/Downloads/test

Warum? Desktop und Downloads sind praktische Ablageorte, aber keine gute Entwicklungsbasis. Repos sollen reproduzierbar, versioniert und möglichst nah an der ausführenden Toolchain liegen.

#3.3 Entscheidungsregel

Baue ich ein Linux-/Cloud-/OKD-/Node-/Python-/Java-Projekt?
  → Repo nach WSL: ~/code/...

Baue ich ein reines Windows-/PowerShell-/.NET-Windows-Projekt?
  → Repo nach Windows: C:\Users\...\code\...

Steuere ich CRC selbst?
  → PowerShell auf Windows.

Deploye ich YAML/App-Code nach OKD?
  → WSL mit oc oder IDE-Terminal im WSL-Kontext.

#4. Woche 1: WSL2 stabil machen

#4.0 Was WSL2 eigentlich ist

WSL2 ist keine normale App und auch keine komplette Desktop-VM wie VirtualBox. WSL2 ist eine leichtgewichtige Linux-Umgebung, die mit einem echten Linux-Kernel läuft und eng in Windows integriert ist.

Windows Terminal
   │
   ▼
WSL2 Ubuntu
   │
   ├─ Linux-Dateisystem: /home/<user>/...
   ├─ Linux-Prozesse: bash, git, node, java, python
   └─ Zugriff auf Windows-Dateien: /mnt/c/...

Für Entwicklung ist wichtig: WSL2 fühlt sich wie Linux an, aber du bist weiterhin auf einem Windows-Host. Deshalb gibt es zwei Ebenen für Updates, Netzwerk, Speicher und Virtualisierung.

#4.0.1 WSL1 vs. WSL2

Prüfbefehl:

wsl -l -v

Wenn dort bei Ubuntu VERSION 2 steht, bist du auf dem richtigen Weg.

#4.0.2 Mentales Modell für WSL-Befehle

PowerShell-Befehl: wsl --status
  → fragt Windows: Welche WSL-Umgebungen kenne ich?

WSL-Befehl: uname -a
  → fragt Linux: Welcher Kernel läuft hier?

WSL-Befehl: pwd
  → fragt Linux: In welchem Linux-Ordner bin ich?

Verwechsle diese Ebenen nicht. wsl --shutdown gehört nach PowerShell. sudo apt update gehört nach Ubuntu/WSL.

#4.1 Prüfen, ob Windows 10 bereit ist

🧠 Erklärung:
winver zeigt dir deine Windows-Version. wsl --status zeigt den globalen Zustand von WSL. wsl -l -v zeigt installierte Distributionen und ob sie mit WSL1 oder WSL2 laufen.

🧪 Gutes Ergebnis:

NAME      STATE           VERSION
Ubuntu    Running         2

🧯 Wenn VERSION 1 erscheint:

wsl --set-version Ubuntu 2

Falls die Konvertierung scheitert, fehlen oft Windows-Features oder Virtualisierung ist im BIOS/UEFI deaktiviert.

Öffne PowerShell als Administrator:

winver
wsl --status
wsl -l -v

Für WSL2 braucht Windows 10 je nach Architektur mindestens geeignete Builds. Wenn wsl --install nicht verfügbar ist, nutze die manuellen Windows-Features.

#4.2 WSL installieren oder aktualisieren

🧠 Was passiert bei wsl --install -d Ubuntu?

Windows aktiviert die WSL-Komponenten, installiert die gewählte Distribution und richtet einen Linux-Benutzer ein. Dieser Linux-Benutzer ist nicht automatisch derselbe wie dein Windows-Benutzer, auch wenn du denselben Namen wählen kannst.

Windows-Benutzer: C:\Users\Aydin
WSL-Benutzer:     /home/aydin

🧠 Was macht wsl --shutdown?
Es beendet alle laufenden WSL-Distributionen. Das ist hilfreich nach Updates, Netzwerkproblemen oder wenn Prozesse hängen.

🧪 Nach dem Update prüfen:

wsl --version
wsl -l -v

Wenn wsl --version auf deinem Windows 10 nicht verfügbar ist, ist das nicht automatisch schlimm. Dann ist deine WSL-Verwaltung älter und du nutzt die manuellen Installations-/Updatewege.

wsl --install -d Ubuntu
wsl --set-default-version 2
wsl --update
wsl --shutdown
wsl -l -v

Wenn du eine alte Windows-10-Version hast und wsl --install nicht funktioniert:

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

Danach neu starten, Linux-Kernel-Update installieren und Ubuntu aus dem Microsoft Store oder per wsl --install -d Ubuntu einrichten.

#4.3 WSL-Grundpakete

🧠 Warum diese Pakete?

Diese Werkzeuge sind dein Linux-Werkzeugkasten. Auch Codex profitiert davon, weil es Tests, Suchen und Analysebefehle zuverlässiger ausführen kann.

🧪 Prüfen:

git --version
curl --version
rg --version || ripgrep --version

In Ubuntu/WSL:

sudo apt update && sudo apt upgrade -y
sudo apt install -y curl ca-certificates git build-essential unzip jq ripgrep fd-find
mkdir -p ~/code
cd ~/code

#4.4 Git-Grundkonfiguration

🧠 Warum core.autocrlf input?

Windows nutzt häufig CRLF-Zeilenenden, Linux meist LF. Wenn du Linux-Projekte in WSL bearbeitest, soll Git beim Commit eher Linux-freundliche LF-Zeilenenden behalten. input bedeutet vereinfacht: Beim Commit normalisieren, aber beim Checkout nicht automatisch Windows-Zeilenenden erzwingen.

🧪 Prüfen:

git config --global --list

🤖 Codex-Hinweis:
Bevor Codex größere Änderungen macht, sollte git status sauber sein. Dann kannst du nach Codex-Arbeit mit git diff genau sehen, was passiert ist.

git config --global user.name "Dein Name"
git config --global user.email "deine-email@example.com"
git config --global core.autocrlf input
git config --global init.defaultBranch main

#4.5 Tagesübung

#4.6 Zusatzübung: Windows- und Linux-Pfad vergleichen

Führe in WSL aus:

pwd
explorer.exe .

pwd zeigt den Linux-Pfad. explorer.exe . öffnet denselben Ort im Windows Explorer. Dadurch lernst du: Windows kann WSL-Dateien anzeigen, aber die Quelle bleibt das Linux-Dateisystem.

#4.7 Mini-Checkliste WSL

• [ ] wsl -l -v zeigt Ubuntu mit Version 2.

• [ ] ~/code existiert.

• [ ] git --version funktioniert in WSL.

• [ ] git config --global --list enthält Name und E-Mail.

• [ ] Du kannst erklären, warum /home/<user>/code besser ist als /mnt/c/....

• Öffne WSL.

• Erstelle ~/code/sandbox.

• Initialisiere ein Git-Repo.

• Schreibe eine _intern/sources/_intern\sources\README.md.

• Prüfe mit git status.

#5. Woche 2: VS Code auf WSL einrichten

#5.0 Was bei VS Code + WSL wirklich passiert

VS Code besteht in diesem Setup aus zwei Teilen:

Windows-Seite:
  VS Code Fenster, Menüs, Themes, Tastaturkürzel

WSL-Seite:
  VS Code Server, Terminal, Sprachserver, Linter, Debugger, Projektzugriff

Wenn du in WSL code . ausführst, öffnet sich zwar ein Windows-Fenster, aber der Arbeitskontext ist Linux. Das erkennst du unten links an WSL: Ubuntu.

#5.0.1 Warum nicht VS Code als Linux-GUI in WSL installieren?

Das wäre unnötig kompliziert. Der offizielle und stabile Weg ist:

VS Code App unter Windows
+ WSL Extension
+ Projekt in WSL öffnen

So bekommst du Windows-Performance für die Oberfläche und Linux-Nähe für Toolchains.

#5.1 Installationsbild

#5.2 VS Code richtig installieren

🧠 Warum „Add to PATH“ wichtig ist:
Der Befehl code . funktioniert in WSL nur zuverlässig, wenn Windows den VS-Code-Launcher kennt und VS Code die WSL-Integration korrekt bereitstellt.

🧪 Prüfen in PowerShell:

where code

🧪 Prüfen in WSL:

code --version

Wenn code in WSL nicht gefunden wird, öffne VS Code einmal unter Windows, installiere die WSL-Extension und starte Terminal/WSL neu.

1. VS Code unter Windows installieren, nicht als Linux-GUI in WSL.
2. Beim Installer Add to PATH aktivieren.
3. VS Code öffnen und Extension installieren:
   • WSL von Microsoft
   • Optional: Remote Development Pack
   • Codex IDE Extension von OpenAI

#5.3 Projekt aus WSL öffnen

🧠 Was code . bedeutet:

code = öffne VS Code
.    = aktueller Ordner

Wenn du also in /home/aydin/code/hello-wsl-codex stehst und code . ausführst, sagst du: „Öffne genau diesen Linux-Ordner in VS Code.“

🧪 Drei Kontrollpunkte in VS Code:

1. Unten links steht WSL: Ubuntu.
2. Das Terminal in VS Code zeigt einen Linux-Prompt.
3. pwd zeigt /home/..., nicht /mnt/c/....

pwd
uname -a
git status

cd ~/code
mkdir hello-wsl-codex && cd hello-wsl-codex
git init
printf '# Hello WSL Codex\n' > _intern/sources/_intern\sources\README.md
code .

Du bist richtig verbunden, wenn:

echo $WSL_DISTRO_NAME
pwd

eine Linux-Distribution und ein Pfad wie /home/<user>/code/... erscheinen.

#5.4 Extensions verstehen

🧠 Warum Extensions manchmal doppelt wirken:

Einige Extensions betreffen nur das Aussehen. Diese laufen lokal auf Windows. Andere Extensions müssen Code analysieren oder Tools ausführen. Diese sollten in WSL installiert sein.

Theme Extension       → Windows reicht
Python Extension      → in WSL installieren, wenn Python-Projekt in WSL liegt
ESLint/Prettier       → in WSL installieren, wenn node_modules in WSL liegt
Kubernetes/OpenShift  → oft lokal okay, Terminal/oc-Kontext aber prüfen
Codex Extension       → im IDE-Kontext verwenden, Repo-Kontext beachten

🧯 Fehlerbild: Extension sieht Projektdateien, aber findet Runtime nicht.
Meist läuft die Extension lokal, während Runtime in WSL liegt. Lösung: „Install in WSL“ wählen oder Projekt als WSL-Remote öffnen.

VS Code Extensions
├─ Lokal / Windows: Theme, Icons, UI, Keymap
└─ Remote / WSL: Sprache, Linter, Debugger, Tooling, Codex-Kontext

Wenn VS Code bei einer Extension Install in WSL anbietet, nutze das für Sprache/Runtime-nahe Erweiterungen.

#5.5 Tagesübung

#5.6 Zusatzübung: Extension-Ort erkennen

Öffne in VS Code die Extensions-Ansicht. Achte auf Hinweise wie:

Local - Installed
WSL: Ubuntu - Installed
Install in WSL: Ubuntu

Schreibe dir für deine wichtigsten Extensions auf, wo sie laufen. Das verhindert später Debugging-Frust.

#5.7 VS-Code-Fehlerdiagnose als Baum

code . öffnet kein richtiges WSL-Fenster?
├─ Unten links steht nicht WSL?
│  └─ Command Palette → WSL: Reopen Folder in WSL
├─ code-Befehl fehlt?
│  └─ VS Code unter Windows öffnen, PATH/WSL-Extension prüfen, Terminal neu starten
└─ Projekt ist langsam?
   └─ Prüfen: liegt es unter /mnt/c? Dann nach ~/code verschieben

• Öffne dein WSL-Projekt mit code ..
• Installiere die Codex-Extension.
• Öffne das Codex-Symbol in der Sidebar.
• Stelle eine kleine Aufgabe: „Erstelle eine README-Struktur für dieses Projekt.“

#6. Woche 3: IntelliJ mit WSL nutzen

#6.0 IntelliJ und WSL: zwei sinnvolle Betriebsarten

Bei IntelliJ gibt es zwei Hauptwege:

Einfacher Weg:
  IntelliJ läuft unter Windows und öffnet Dateien aus WSL.

Remote-/Gateway-Weg:
  Ein IDE-Backend läuft in WSL, die Oberfläche verbindet sich damit.

Für den Start ist der einfache Weg besser. Er ist leichter zu verstehen und reicht für viele Projekte. Gateway ist interessant, wenn du wirklich eine remote-artige Architektur willst oder große Projekte stärker im Linux-Kontext halten möchtest.

#6.0.1 Wichtiger Unterschied zu VS Code

VS Code hat eine sehr stark integrierte Remote-WSL-Erfahrung. IntelliJ kann WSL sehr gut nutzen, aber du musst häufiger bewusst auswählen:

• Welches Git?
• Welches JDK?
• Welches Node?
• Welcher Python Interpreter?
• Welches Terminal?

Das ist kein Fehler. IntelliJ ist sehr mächtig, aber du musst die Toolchain-Zuordnung sauber einstellen.

#6.1 Empfohlene Wege

#6.2 Weg A: IntelliJ lokal auf Windows, Projekt in WSL

🧠 Was ist \\wsl.localhost\Ubuntu\...?

Das ist ein Windows-Netzwerkpfad, über den Windows auf das WSL-Dateisystem zugreift. Der eigentliche Speicherort bleibt aber Linux.

Linux-Sicht:   /home/aydin/code/projekt
Windows-Sicht: \\wsl.localhost\Ubuntu\home\aydin\code\projekt

🧪 Gutes Zeichen:
Im IntelliJ-Terminal sollte pwd einen Linux-Pfad zeigen, wenn du ein WSL-Terminal verwendest.

🧯 Nicht ideal:
Ein Projekt über /mnt/c/... öffnen und dann Linux-Tools darauf loslassen. Das kann gehen, ist aber für viele Workflows schlechter.

1. IntelliJ IDEA unter Windows installieren.
2. Projekt in WSL unter ~/code/projekt ablegen.
3. In IntelliJ öffnen:

\\wsl.localhost\Ubuntu\home\<dein-user>\code\projekt

Alternativ im Explorer:

\\wsl$\Ubuntu\home\<dein-user>\code\projekt

#6.3 WSL-Git in IntelliJ

🧠 Warum WSL-Git?

Wenn dein Repo in WSL liegt, sollte Git möglichst auch aus WSL kommen. Dann stimmen Pfade, Dateirechte, Hooks und Zeilenenden besser zusammen.

Repo: /home/aydin/code/app
Git:  /usr/bin/git

🧪 Prüfen im IntelliJ-Terminal:

which git
git status

Wenn which git nichts findet, fehlt Git in WSL oder dein IntelliJ-Terminal ist nicht im WSL-Kontext.

Wenn IntelliJ das Projekt über einen WSL-Pfad öffnet, kann es Git aus WSL verwenden. Manuell findest du es hier:

Settings → Version Control → Git → Path to Git executable
\\wsl$\Ubuntu\usr\bin\git

#6.4 Node/JDK/Python aus WSL

🧠 Warum Runtime-Zuordnung wichtig ist:

Die IDE kann Code anzeigen, aber Build und Tests brauchen echte Laufzeitumgebungen. Wenn dein Projekt in WSL liegt, sollen diese Laufzeitumgebungen ebenfalls in WSL liegen.

Java-Projekt in WSL  → JDK aus WSL verwenden
Node-Projekt in WSL  → Node aus WSL verwenden
Python-Projekt WSL   → Python Interpreter aus WSL verwenden

🧪 Prüfbefehle in WSL:

which java && java -version
which node && node --version
which python3 && python3 --version

🤖 Codex-Hinweis:
Wenn Codex Tests vorschlägt, achte darauf, dass sie im richtigen Terminal laufen. Ein npm test in Windows ist nicht dasselbe wie npm test in WSL, wenn node_modules in WSL installiert wurden.

Für Node.js:

Settings → Languages & Frameworks → JavaScript Runtime
Node runtime → Add → Add WSL → Ubuntu → /usr/bin/node

Für Java/Kotlin:

sudo apt install -y openjdk-21-jdk
which java
java -version

Dann in IntelliJ den JDK/Run Target aus WSL wählen.

#6.5 Weg B: JetBrains Gateway mit WSL2

🧠 Wann Gateway sinnvoll ist:

Gateway ist sinnvoll, wenn die IDE-Backend-Prozesse vollständig im Linux-Kontext laufen sollen. Das ähnelt einem Remote-Server-Setup. Für Lernzwecke solltest du Gateway erst verwenden, wenn du den einfachen WSL-Pfad verstanden hast.

Einfacher Weg zuerst:
  Windows IntelliJ → WSL-Dateien/Runtimes

Gateway später:
  Windows Client → IDE Backend in WSL → Projekt

🧯 Typischer Fehler:
Gateway, WSL-Pfade, Windows-JDK und WSL-JDK gleichzeitig mischen. Lösung: erst einen Weg stabil einrichten, dann erweitern.

Dieser Weg ist schwerer, aber sauber für größere Remote-/WSL-Setups:

JetBrains Gateway → All Providers → WSL → New Connection → Ubuntu → IDE Version → Projekt → Start IDE and Connect

Nutze diesen Weg erst, wenn der einfache Weg läuft.

#6.6 Tagesübung

#6.7 IntelliJ-Checkliste

• [ ] Projekt liegt unter /home/<user>/code/....

• [ ] IntelliJ öffnet das Projekt über \\wsl.localhost\... oder Gateway.

• [ ] Git zeigt auf WSL-Git.

• [ ] JDK/Node/Python kommt aus WSL, wenn das Projekt in WSL liegt.

• [ ] Das integrierte Terminal zeigt den erwarteten Kontext.

• [ ] Codex wird nur auf das aktuelle Projekt losgelassen, nicht auf dein ganzes Home-Verzeichnis.

• Öffne ein WSL-Projekt in IntelliJ.

• Prüfe git status im IntelliJ-Terminal.

• Starte eine kleine Java/Node/Python-Datei aus IntelliJ.

• Öffne Codex im IntelliJ-Plugin oder starte codex im Terminal.

#7. Woche 4: Codex CLI, IDE-Extension und Alltag

#7.0 Codex als Mitarbeiter verstehen, nicht als Magie

Codex ist am nützlichsten, wenn du es wie einen sehr schnellen Junior-/Pair-Programmer behandelst:

Du gibst Ziel + Grenzen + Kontext.
Codex schlägt Plan + Änderungen vor.
Du prüfst Diff + Tests.
Du entscheidest, ob es in Git übernommen wird.

Schlechte Nutzung:

Mach alles fertig.

Bessere Nutzung:

Analysiere zuerst das Projekt. Zeige mir einen Plan. Ändere nur Dateien im Ordner src/ und tests/. Führe Tests aus. Erkläre mir danach den Diff.

#7.0.1 Codex-Kontext ist immer lokal

Codex sieht nicht automatisch „deinen Computer“. Es arbeitet in einem bestimmten Projektordner und mit bestimmten Berechtigungen.

codex gestartet in ~/code/app
  → guter Kontext: dieses Repo
  → schlechter Kontext: cd ~ und dann codex starten

Starte Codex deshalb immer aus dem Projektordner.

#7.1 Codex-Arbeitsmodell

🧠 Warum Plan → Änderung → Test so wichtig ist:

Ohne Plan weißt du nicht, was Codex vorhat. Ohne Tests weißt du nicht, ob die Änderung funktioniert. Ohne Diff weißt du nicht, was wirklich geändert wurde.

Plan lesen      = Absicht prüfen
Diff lesen      = tatsächliche Änderung prüfen
Tests ausführen = Verhalten prüfen
Commit machen   = sauberen Stand speichern

🧪 Standardablauf vor jeder größeren Codex-Aufgabe:

git status
codex
# Nach Arbeit:
git diff
git status

Prompt → Kontext prüfen → Plan → Änderung → Tests → Diff prüfen → Commit

#7.2 Codex-Modi im Kopf behalten

#7.3 Gute Prompts nach Situation

Erklären lassen, ohne Änderungen:

Erkläre mir die Projektstruktur. Ändere keine Dateien. Zeige mir, welche Ordner wichtig sind und welche Befehle vermutlich Tests starten.

Kleine Änderung:

Füge eine kleine Funktion hinzu. Arbeite nur in src/ und tests/. Zeige zuerst den Plan. Führe danach die Tests aus und erkläre den Diff.

OKD-YAML generieren:

Erstelle Kubernetes/OKD-YAML für diese App. Keine Secrets im Klartext. Lege alles unter k8s/ ab. Erkläre Deployment, Service und Route.

Fehlerdebugging:

Analysiere diese Fehlermeldung. Nenne drei mögliche Ursachen, sortiert nach Wahrscheinlichkeit. Ändere noch nichts.

#7.4 Sicherheitsgrenzen für Codex

Gib Codex klare Grenzen:

Nicht erlaubt:
- .env lesen
- SSH Keys lesen
- globale Pakete installieren
- oc delete project ausführen
- Dateien außerhalb dieses Repos ändern

Erlaubt:
- Dateien im Repo lesen
- Tests ausführen
- neue Dateien in src/, tests/, docs/, k8s/ anlegen

Das verhindert nicht jeden Fehler, aber es macht die Arbeit kontrollierbarer.

#8. Codex nativ auf Windows

#8.0 Wann Windows-Codex sinnvoll ist

Nutze Codex nativ auf Windows für Projekte, die auch wirklich Windows-nah sind:

PowerShell-Skripte
Windows-Automatisierung
.NET-/Desktop-Projekte
Dateien unter C:\Users\...\code

Nicht ideal ist Windows-Codex für ein Repo, dessen eigentliche Toolchain in WSL liegt. Dann kann Codex zwar Dateien sehen, aber Befehle, Pfade und Tests passen möglicherweise nicht.

#8.0.1 Windows-Codex und WSL-Codex nicht verwechseln

PowerShell:
  where codex
  codex --version

WSL:
  which codex
  codex --version

Beide können installiert sein. Das ist okay. Entscheidend ist, aus welchem Terminal du Codex startest.

Öffne PowerShell:

powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"
codex

Prüfen:

where codex
codex --version

Empfohlene Windows-Nutzung:

C:\Users\<du>\code\windows-projekt
PowerShell → codex
VS Code/IntelliJ Windows-Projekt → Codex Extension

Merke: Windows-Codex und WSL-Codex sind getrennte Installationen mit getrennten Home-Verzeichnissen und Konfigurationen.

#9. Codex in WSL

#9.0 Wann WSL-Codex sinnvoll ist

Nutze Codex in WSL für alles, was Linux-/Cloud-/Server-nah ist:

Node.js Backend
Python CLI/API
Java/Spring/Quarkus
Docker-nahe Projekte
Kubernetes/OKD YAML
Shell-Skripte

WSL-Codex hat denselben Blick auf das Projekt wie deine Linux-Tools. Das reduziert Pfadprobleme.

#9.0.1 Startordner ist entscheidend

Guter Start:

cd ~/code/mein-projekt
codex

Schlechter Start:

cd ~
codex

Warum? Im Home-Verzeichnis liegen viele private oder irrelevante Dateien. Codex soll nur den Projektkontext bekommen, den es wirklich braucht.

In Ubuntu/WSL:

curl -fsSL https://chatgpt.com/codex/install.sh | sh
codex

Prüfen:

which codex
codex --version

Empfohlene WSL-Nutzung:

mkdir -p ~/code
cd ~/code/dein-projekt
codex

Wichtig: Aktuelle Codex-Versionen sollten in WSL2 laufen. WSL1 ist für aktuelle Codex-Versionen nicht mehr die Zielumgebung.

#10. Plugins und Extensions

#10.0 CLI vs. IDE-Extension

Für den Anfang reicht oft:

VS Code/IntelliJ zum Lesen und Editieren
Codex CLI im Projektordner für Agent-Aufgaben
Codex Extension für kleine Fragen direkt im Editor

#10.1 VS Code

Installiere in VS Code:

• WSL Extension von Microsoft
• Codex IDE Extension von OpenAI
• Optional nach Projekttyp:
  • Python
  • ESLint
  • Prettier
  • Docker
  • Dev Containers

Codex erscheint nach Installation in der Sidebar. Wenn nicht, VS Code neu starten.

#10.2 IntelliJ

Installiere in IntelliJ:

Settings → Plugins → Marketplace → Codex / OpenAI Codex → Install

Dann anmelden mit:

• ChatGPT-Konto, oder
• API-Key, oder
• je nach Setup JetBrains-AI-Anbindung.

#10.3 CLI und IDE teilen Konfiguration pro Umgebung

🧠 Warum getrennte Konfigurationen gut sind:

Windows und WSL dürfen unterschiedliche Sandbox- und Approval-Regeln haben. Zum Beispiel kann Windows-Codex für Windows-Projekte anders arbeiten als WSL-Codex für Linux-Projekte.

Windows config: C:\Users\<du>\.codex\config.toml
WSL config:     /home/<du>/.codex/config.toml

Ändere Konfigurationen langsam. Wenn du nicht sicher bist, bleibe bei Approval/Workspace-Write statt Full Access.

Auf WSL:

nano ~/.codex/config.toml

Auf Windows:

notepad $env:USERPROFILE\.codex\config.toml

Beispiel:

model = "gpt-5.5"
approval_policy = "on-request"
sandbox_mode = "workspace-write"
model_reasoning_effort = "high"

[windows]
sandbox = "elevated"

#11. Erster Testlauf

#11.0 Warum ein Mini-Projekt wichtig ist

Installationen wirken oft erfolgreich, bis man den ersten echten Ablauf testet. Ein Mini-Projekt prüft mehrere Dinge gleichzeitig:

Git funktioniert
Codex startet im richtigen Ordner
Codex kann Dateien anlegen
Tests können laufen
Du kannst den Diff lesen

Mache den ersten Test bewusst in einem Wegwerf-Repo. So kannst du ohne Angst üben.

#11.1 Mini-Projekt bauen

mkdir -p ~/code/codex-test
cd ~/code/codex-test
git init
cat > _intern/sources/_intern\sources\README.md <<'TXT'
# Codex Test

Ziel: kleine CLI-App mit Tests.
TXT
codex

Prompt an Codex:

Erstelle eine kleine Python-CLI, die zwei Zahlen addiert. Lege Tests an, führe sie aus und erkläre mir danach den Diff.

#11.2 Nach Codex-Arbeit prüfen

🧠 Was du beim Diff lesen solltest:

Achte auf:

• Hat Codex nur erwartete Dateien geändert?
• Wurden Konfigurationsdateien verändert?
• Gibt es neue Abhängigkeiten?
• Wurden Tests wirklich hinzugefügt?
• Sind Befehle in README realistisch?

git diff --stat
git diff

git diff --stat gibt dir erst die Übersicht. git diff zeigt Details.

git status
git diff
pytest -q  # falls Python/pytest verwendet wurde

#11.3 Guter Prompt-Starter

Kontext: Dieses Repo liegt in WSL2 unter ~/code/projekt.
Ziel: Richte eine minimale Entwicklungsumgebung ein.
Arbeitsweise: Bitte zuerst Plan zeigen, dann kleine Änderungen, dann Tests ausführen.
Grenzen: Keine Secrets lesen, keine globalen Systemänderungen ohne Nachfrage.

#12. Fehlerbilder und Lösungen

#12.0 Fehler systematisch eingrenzen

Nutze diese Reihenfolge:

1. Wo bin ich?        pwd / echo $WSL_DISTRO_NAME / PowerShell erkennen
2. Was fehlt?         command not found / version prüfen
3. Welcher Pfad?      /home/... oder /mnt/c/... oder C:\...
4. Welche Rechte?     ls -la / Administrator / sudo
5. Welches Netzwerk?  DNS, Proxy, VPN, api.crc.testing
6. Welche Umgebung?   Windows-Codex oder WSL-Codex

#12.1 Diagnosebefehle

# PowerShell
wsl -l -v
where code
where codex
crc status

# WSL
pwd
uname -a
echo $WSL_DISTRO_NAME
which git
which codex
which oc
git status

#12.2 Merksatz

Erst Umgebung klären, dann Tool reparieren.

Viele Fehler entstehen nicht, weil ein Tool kaputt ist, sondern weil du es aus der falschen Umgebung startest.

#13. Sicherheits- und Arbeitsregeln

#13.0 Warum Sicherheit hier praktisch ist

Sicherheit bedeutet hier nicht nur „keine Hacker“. Es bedeutet auch:

• keine versehentlich gelöschten Projekte;
• keine geleakten API-Keys;
• keine kaputte globale Entwicklungsumgebung;
• keine unkontrollierten oc delete- oder PowerShell-Befehle;
• nachvollziehbare Änderungen durch Git.

Git ist dein Sicherheitsnetz.
Approval ist deine Bremse.
Tests sind deine Kontrolle.
Diff ist deine Wahrheit.

#13.1 Die goldenen Regeln

1. Arbeite in Git-Repos.
2. Vor großen Codex-Aufgaben: git status muss sauber sein.
3. Lass Codex zuerst planen.
4. Lies den Diff.
5. Führe Tests lokal aus.
6. Gib keine .env, Tokens oder Passwörter in Prompts.
7. Nutze Full Access nur in Wegwerf- oder stark kontrollierten Projekten.

#13.2 Visuelle Sicherheitsampel

🟢 Chat / Erklären       → sicher für Lernen und Verständnis
🟡 Agent + Approval      → gut für normale Entwicklung
🔴 Full Access / YOLO    → nur temporär und bewusst

#14. OKD lokal installieren: CRC auf Windows + WSL anbinden

#14.0 Was OKD ist, bevor du es installierst

OKD ist die Community-Variante der OpenShift-Plattform. OpenShift/OKD baut auf Kubernetes auf und ergänzt unter anderem Entwickler-Workflows, Web-Konsole, Routes, Builds, Projekte/Namespaces, Operatoren und Sicherheitskonzepte.

Sehr vereinfacht:

Kubernetes:
  Startet Container, verwaltet Pods, Services, Deployments.

OKD/OpenShift:
  Kubernetes + Entwicklerplattform + Web-Konsole + Routes + zusätzliche Policies/Tools.

Für deinen Lernpfad ist OKD wertvoll, weil du damit Cloud-native Entwicklung lokal üben kannst:

App schreiben → Image/Deployment definieren → Service bereitstellen → Route öffnen → Logs prüfen

#14.0.1 Wichtige OKD-Begriffe

#14.0.2 Warum CRC und nicht direkt OKD in WSL?

CRC startet eine eigene virtuelle Maschine. WSL2 ist selbst bereits eine virtualisierte Linux-Umgebung. Eine VM in einer VM ist verschachtelte Virtualisierung und in diesem Fall nicht der stabile Lernweg.

Darum:

Richtig für dich:
  Windows Host → CRC → OKD-VM
  WSL2 → oc CLI → OKD API

Nicht empfohlen:
  WSL2 → CRC → OKD-VM

WSL bleibt deine Werkstatt. CRC/OKD ist der Cluster, den du von dort bedienst.

Empfohlener Weg für deinen Rechner: OKD läuft lokal als Single-Node-Cluster über CRC / CodeReady Containers auf dem Windows-Host. WSL2 bleibt deine Linux-Werkstatt für oc, Git, Skripte, Codex und Projekte. Installiere CRC nicht „in WSL“, weil CRC selbst eine VM startet und verschachtelte Virtualisierung dafür nicht unterstützt wird.

#14.1 Zielbild OKD

🧠 So liest du das OKD-Bild:

• crc.exe ist das Steuerprogramm auf Windows.
• Die OKD-VM ist der eigentliche Cluster.
• Die Web-Konsole ist nur die Oberfläche.
• Die API ist das Herz des Clusters.
• oc spricht mit dieser API.
• Deine YAML-Dateien beschreiben den gewünschten Zustand.

Du schreibst YAML:
  „Ich will ein Deployment, einen Service und eine Route.“

oc sendet YAML an OKD:
  „Bitte bringe den Cluster in diesen Zustand.“

OKD arbeitet:
  erstellt Pods, Services, Routes und überwacht den Zustand.

┌──────────────────────── WINDOWS 10 ────────────────────────┐
│  crc.exe  ── startet ──►  OKD Single Node VM                │
│     ▲                         ▲                             │
│     │                         │ Web Console / API           │
│ PowerShell                    │ https://api.crc.testing:6443 │
└─────┼─────────────────────────┼─────────────────────────────┘
      │                         │
┌─────▼─────────────────────────▼─────────────────────────────┐
│ WSL2 Ubuntu: oc CLI + Codex + Git + Projektdateien           │
│ ~/code/app  ──► oc apply / oc new-app / oc logs              │
└──────────────────────────────────────────────────────────────┘

#14.2 Entscheidung: CRC, SNO oder vollständiger OKD-Cluster?

🧠 Warum CRC zuerst?

CRC nimmt dir viele Infrastrukturthemen ab. Du musst am Anfang nicht DNS, Load Balancer, Bootstrap Node, Control Plane und Worker planen. Dadurch kannst du dich zuerst auf Entwicklerwissen konzentrieren:

oc login
oc new-project
oc apply
oc get pods
oc logs
oc expose

Später kannst du SNO oder einen echten Cluster lernen. Dann verstehst du aber schon, was im Cluster passiert.

#14.2.1 Lernreihenfolge für OKD

Stufe 1: CRC lokal starten und Web-Konsole öffnen
Stufe 2: oc-Befehle verstehen
Stufe 3: Deployment, Service, Route manuell erzeugen
Stufe 4: YAML-Dateien versionieren
Stufe 5: App aus eigenem Repo deployen
Stufe 6: Logs, Events, Rollouts debuggen
Stufe 7: SNO/vollständige Installation verstehen

#14.3 Voraussetzungen prüfen

🧠 Warum OKD viel RAM braucht:

Ein OKD-Cluster besteht nicht nur aus deiner App. Schon im Leerlauf laufen viele Plattform-Komponenten:

API Server
Controller
Scheduler
etcd
Ingress/Router
Console
Monitoring-Komponenten
Operatoren
Registry/Build-Komponenten je nach Setup

Darum fühlt sich OKD schwerer an als ein einzelner Docker-Container.

#14.3.1 Ressourcen mental planen

Windows selbst braucht RAM
WSL2 braucht RAM
IDE braucht RAM
Browser/Web-Konsole braucht RAM
CRC/OKD braucht viel RAM

Wenn dein Rechner 16 GB RAM insgesamt hat, kann es knapp werden. Dann schließe Browser-Tabs, Docker Desktop, andere VMs und nicht benötigte IDEs.

#14.3.2 BIOS/UEFI-Virtualisierung

Wenn crc start früh scheitert, prüfe, ob Virtualisierung im BIOS/UEFI aktiv ist. Je nach Hersteller heißt die Option zum Beispiel:

Intel VT-x
Intel Virtualization Technology
AMD-V
SVM Mode

Unter Windows kannst du im Task-Manager unter „Leistung → CPU“ oft sehen, ob Virtualisierung aktiviert ist.

Windows-Seite:

winver
wsl -l -v
systeminfo | findstr /i "Virtualization Hyper-V"

Du brauchst:

• Voll aktualisiertes Windows 10 Pro/Enterprise/Education oder Windows 11.
• Hardware-Virtualisierung im BIOS/UEFI aktiviert.
• Genügend freie Ressourcen. Plane praktisch mindestens 6-8 CPU-Kerne, 16 GB RAM frei und 80+ GB freien Speicher, auch wenn einfache CRC-Minimumwerte niedriger sein können.
• CRC muss auf dem lokalen Laufwerk C:\ installiert werden, nicht auf einem Netzlaufwerk.

Nicht ideal: Windows 10 Home, sehr wenig RAM, Firmennetz mit strengem Proxy/VPN, oder der Versuch, CRC innerhalb von WSL2 zu starten.

#14.4 CRC installieren und OKD-Preset setzen

🧠 Was ist ein Preset?

CRC kann unterschiedliche Zielplattformen starten. Das Preset sagt CRC, welche Art lokaler Cluster erzeugt werden soll. Wenn du OKD lernen willst, setzt du vor dem Erzeugen der Instanz das OKD-Preset.

crc config set preset okd

Wichtig: Wenn bereits ein CRC-Cluster existiert, wirkt die Änderung nicht rückwirkend auf diese alte Instanz. Deshalb löscht man in solchen Fällen die Instanz und erstellt sie neu.

Alte Instanz       → preset war vielleicht anders
crc delete         → alte Instanz entfernen
preset okd setzen  → neue Zielplattform wählen
crc setup/start    → neue OKD-Instanz bauen/starten

🧯 Merke:
crc stop hält an. crc delete löscht die lokale Cluster-Instanz. Nutze delete bewusst.

1. Lade CRC / OpenShift Local für Windows herunter.
2. Installiere es auf C:\.
3. Öffne PowerShell als Administrator.
4. Prüfe die Installation:

crc version
crc config view

Setze danach OKD als Preset:

crc config set preset okd
crc config view

Falls du vorher schon einen OpenShift-CRC-Cluster gestartet hattest, musst du ihn löschen und neu erstellen, weil das Preset nur beim Erzeugen der Instanz wirkt:

crc stop
crc delete
crc config set preset okd
crc setup
crc start

Bei einer frischen Installation reicht meistens:

crc config set preset okd
crc setup
crc start

#14.5 Login, Web-Konsole und oc

🧠 Web-Konsole vs. CLI

Für echtes Lernen solltest du beides nutzen: erst in der Konsole anschauen, dann mit oc und YAML wiederholen.

#14.5.1 Was oc login macht

oc login speichert Zugangsdaten und Cluster-Kontext in deiner kubeconfig. Danach weiß oc, mit welchem Cluster und welchem Benutzer es sprechen soll.

oc login → schreibt/aktualisiert ~/.kube/config
oc whoami → zeigt aktuellen Benutzer
oc project → zeigt aktuelles Projekt/Namespace

In Windows und WSL gibt es getrennte Home-Verzeichnisse. Darum kann PowerShell bereits eingeloggt sein, während WSL noch nicht eingeloggt ist.

Nach dem Start:

crc status
crc console --credentials

Öffne die Konsole:

crc console

oc für PowerShell aktivieren:

crc oc-env | Invoke-Expression
oc version
oc whoami

Wenn du manuell einloggen willst, kopiere den Login-Befehl aus:

crc console --credentials

Typisches Muster:

oc login -u developer -p developer https://api.crc.testing:6443

#14.6 WSL2 an OKD anbinden

🧠 Warum PowerShell-Login nicht automatisch WSL-Login ist

PowerShell speichert Konfiguration unter deinem Windows-Benutzerprofil. WSL speichert sie unter /home/<user>. Deshalb brauchst du den Login in beiden Umgebungen, wenn du beide nutzen willst.

Windows kubeconfig:
C:\Users\<du>\.kube\config

WSL kubeconfig:
/home/<du>/.kube/config

#14.6.1 DNS-Problem einfach erklärt

CRC richtet lokale Namen wie api.crc.testing und *.apps-crc.testing ein. Windows kann diese Namen oft auflösen, WSL aber manchmal nicht.

WSL fragt: Wo ist api.crc.testing?
DNS antwortet nicht richtig.
oc login scheitert.

Temporäre Lösung: Die IP von crc ip in /etc/hosts eintragen. Das ist nicht schön, aber als Lernlösung praktisch.

🧪 Prüfen in WSL:

getent hosts api.crc.testing
curl -k https://api.crc.testing:6443/version

Wenn getent hosts nichts liefert, ist es ein Namensauflösungsproblem.

Der OKD-Cluster läuft auf Windows/CRC. In WSL arbeitest du mit Projekten und nutzt oc gegen denselben API-Endpunkt.

In WSL:

mkdir -p ~/bin ~/.kube ~/code/okd
cd ~/code/okd

Installiere oc entweder über den CRC-Output oder lade den passenden OpenShift/OKD-Client. Der einfachste Lernweg ist:

1. In PowerShell crc console --credentials ausführen.
2. Den oc login ... Befehl kopieren.
3. In WSL einfügen.
4. Prüfen:

oc whoami
oc get projects
oc get nodes

Wenn WSL api.crc.testing nicht auflösen kann, prüfe in PowerShell:

crc ip

und ergänze testweise in WSL /etc/hosts:

sudo nano /etc/hosts

Beispielzeilen, IP vorher mit crc ip ersetzen:

192.168.x.y api.crc.testing
192.168.x.y console-openshift-console.apps-crc.testing

#14.7 Erstes OKD-Projekt deployen

🧠 Was die Befehle erzeugen

oc new-project codex-demo

Erzeugt einen isolierten Arbeitsbereich.

oc create deployment hello-okd --image=...

Sagt OKD: Starte Pods aus diesem Container-Image.

oc expose deployment hello-okd --port=8080

Erzeugt einen Service, damit Pods intern stabil erreichbar sind.

oc expose service hello-okd

Erzeugt eine Route, damit du die App von außen über HTTP erreichst.

#14.7.1 Bild: Von Deployment zur URL

Deployment
   │ erzeugt/verwaltet
   ▼
Pod(s)
   │ werden intern erreicht über
   ▼
Service
   │ wird extern veröffentlicht über
   ▼
Route
   │ liefert URL
   ▼
Browser / curl

#14.7.2 Prüf-Befehle nach jedem Schritt

oc get projects
oc project
oc get deployments
oc get pods
oc get svc
oc get routes
oc describe pod <pod-name>
oc logs deployment/hello-okd

Du lernst schneller, wenn du nach jedem Befehl schaust, welche Ressource neu entstanden ist.

In WSL oder PowerShell, nachdem oc login funktioniert:

oc new-project codex-demo
oc create deployment hello-okd --image=quay.io/openshift/origin-hello-openshift:latest
oc expose deployment hello-okd --port=8080
oc expose service hello-okd
oc get pods
oc get routes

Route testen:

ROUTE=$(oc get route hello-okd -o jsonpath='{.spec.host}')
curl "http://$ROUTE"

Aufräumen:

oc delete project codex-demo

#14.8 VS Code, IntelliJ und Codex mit OKD verbinden

🧠 Rollenverteilung für OKD-Entwicklung

VS Code / IntelliJ:
  YAML und Code schreiben, Projektstruktur sehen, Terminal öffnen.

Codex:
  YAML vorschlagen, README schreiben, Fehler erklären, Tests ergänzen.

oc:
  Tatsächlich mit dem Cluster sprechen.

OKD:
  Gewünschten Zustand ausführen und überwachen.

🤖 Codex sinnvoll begrenzen:

Bitte erzeuge nur YAML-Dateien unter k8s/.
Keine Befehle ausführen.
Keine Secrets erstellen.
Erkläre mir nach jeder Datei, wofür sie da ist.

Wenn du später sicherer bist:

Führe oc apply -f k8s/ aus, aber frage vor jedem destruktiven Befehl nach.

VS Code:

• Projekt in WSL öffnen: code .
• Kubernetes/OpenShift YAML-Dateien im Repo bearbeiten.
• Optional Extensions: Kubernetes, YAML, Red Hat OpenShift Toolkit.
• Codex in VS Code bitten: „Erzeuge Deployment, Service und Route für OKD und erkläre mir die Ressourcen.“

IntelliJ:

• WSL-Projekt öffnen.
• Java/Quarkus/Spring-Projekt in WSL bauen.
• OpenShift/Kubernetes-Plugin oder Terminal nutzen.
• oc-Befehle im integrierten Terminal ausführen.

Codex:

cd ~/code/okd/meine-app
codex

Gute Prompts:

Analysiere dieses Projekt und erstelle eine OKD-Deployment-Variante mit Deployment, Service und Route.
Ändere nichts automatisch, sondern zeige mir zuerst den Plan.

Erzeuge ein k8s/ Verzeichnis mit YAML für OKD. Verwende keine Secrets im Klartext.
Füge README-Anweisungen für oc apply und oc rollout status hinzu.

#14.9 OKD-Lernwoche

#14.9.1 Was du jeden Tag notieren solltest

Lege eine Datei an:

mkdir -p ~/code/okd-notizen
nano ~/code/okd-notizen/tagebuch.md

Pro Tag notierst du:

Ziel:
Befehle:
Was hat funktioniert:
Fehler:
Was ich verstanden habe:
Nächster Schritt:

Das klingt simpel, ist aber extrem wirksam. OKD hat viele Begriffe. Ohne Notizen fühlt sich alles schnell gleich an.

#14.10 Fehlerbilder OKD

#14.10.1 OKD-Fehlerdiagnose als Entscheidungsbaum

oc-Befehl funktioniert nicht?
├─ oc nicht gefunden?
│  └─ oc in WSL installieren oder PATH prüfen
├─ nicht eingeloggt?
│  └─ oc login erneut ausführen
├─ api.crc.testing nicht erreichbar?
│  ├─ crc status in PowerShell prüfen
│  ├─ crc ip prüfen
│  └─ DNS/hosts in WSL prüfen
├─ Pod startet nicht?
│  ├─ oc describe pod <name>
│  ├─ oc logs <pod>
│  └─ Image/Port/Env prüfen
└─ Route geht nicht?
   ├─ oc get route
   ├─ Service-Port prüfen
   └─ Hostname/DNS prüfen

#14.10.2 Die drei wichtigsten Debug-Kommandos

oc describe <ressource> <name>
oc logs <pod-oder-deployment>
oc get events --sort-by=.lastTimestamp

describe zeigt den Zustand und Events zur Ressource. logs zeigt App-Ausgabe. events zeigt, was im Cluster zuletzt passiert ist.

#14.11 Spickzettel OKD

#14.12 OKD-Miniprojekt für Codex

Lege ein kleines Repo an:

mkdir -p ~/code/okd-miniapp
cd ~/code/okd-miniapp
git init
mkdir -p app k8s docs
cat > _intern/sources/_intern\sources\README.md <<'TXT'
# OKD Miniapp

Ziel: Eine kleine App nach OKD deployen und den Ablauf verstehen.
TXT

Dann Codex-Prompt:

Ich lerne OKD mit CRC. Erstelle für dieses Repo eine sehr kleine Beispiel-App und ein k8s/ Verzeichnis mit Deployment, Service und Route. Keine Secrets. Erkläre jede Ressource in docs/erklaerung.md. Zeige zuerst einen Plan.

Nach der Arbeit:

git diff --stat
git diff

Erst wenn du den Diff verstehst, wendest du YAML auf OKD an.

# PowerShell / Windows
crc version
crc config set preset okd
crc setup
crc start
crc status
crc console --credentials
crc console
crc oc-env | Invoke-Expression
oc get nodes
crc stop

# WSL / Ubuntu
oc login -u developer -p developer https://api.crc.testing:6443
oc new-project codex-demo
oc get all
oc get routes
oc logs deployment/hello-okd
oc rollout status deployment/hello-okd
oc delete project codex-demo

#15. Befehls-Spickzettel

#15.0 Spickzettel richtig verwenden

Ein Spickzettel ist kein Ersatz für Verständnis. Nutze ihn so:

1. Befehl ausführen
2. Ausgabe lesen
3. Notieren, was der Befehl beantwortet

Beispiele:

#Windows / PowerShell

wsl --status
wsl -l -v
wsl --install -d Ubuntu
wsl --set-default-version 2
wsl --update
wsl --shutdown
where codex
codex --version

#WSL / Ubuntu

sudo apt update && sudo apt upgrade -y
sudo apt install -y curl ca-certificates git build-essential unzip jq ripgrep fd-find
mkdir -p ~/code
cd ~/code
code .
which codex
codex --version

#Codex

codex
codex --version

#Git

git status
git diff
git add .
git commit -m "setup development environment"

#16. Gesamt-Checkliste

#16.1 WSL

• [ ] Ubuntu läuft mit WSL2.
• [ ] ~/code ist dein Hauptordner für Linux-Projekte.
• [ ] Git ist in WSL konfiguriert.
• [ ] Du kennst den Unterschied zwischen /home/... und /mnt/c/....

#16.2 VS Code

• [ ] VS Code ist unter Windows installiert.
• [ ] WSL-Extension ist installiert.
• [ ] code . funktioniert aus WSL.
• [ ] Unten links steht bei WSL-Projekten WSL: Ubuntu.

#16.3 IntelliJ

• [ ] IntelliJ ist unter Windows installiert.
• [ ] WSL-Projekt wird über \\wsl.localhost\... oder Gateway geöffnet.
• [ ] Git/JDK/Node/Python zeigen bei Linux-Projekten auf WSL.

#16.4 Codex

• [ ] Windows-Codex und WSL-Codex sind bewusst getrennt.
• [ ] Codex wird aus dem Projektordner gestartet.
• [ ] Vor Agent-Aufgaben ist git status sauber.
• [ ] Du liest nach jeder Änderung git diff.

#16.5 OKD

• [ ] CRC läuft auf Windows, nicht in WSL.
• [ ] OKD-Preset ist gesetzt.
• [ ] crc status funktioniert.
• [ ] oc login funktioniert in der Umgebung, in der du arbeitest.
• [ ] Du kannst Deployment, Service und Route erklären.

#17. Nächste Lernstufen

Wenn alles läuft, gehe nicht sofort zu komplexen Projekten. Baue in dieser Reihenfolge weiter:

1. Ein statisches Hello-World-Deployment
2. Eine kleine API mit Health-Endpoint
3. Eine App mit ConfigMap
4. Eine App mit Secret, aber Secret nie in Git committen
5. Build und Deployment aus README reproduzierbar machen
6. Codex nur für Review, YAML-Erklärung und Testergänzung nutzen
7. Später: SNO oder echter OKD-Cluster

#17.1 Gute Abschlussaufgabe

Erstelle ein Repo ~/code/fullstack-okd-lab mit:

_intern/sources/_intern\sources\README.md
app/
k8s/
docs/
scripts/

Ziel:

• App lokal in WSL starten.
• Tests lokal ausführen.
• YAML für OKD schreiben.
• Nach OKD deployen.
• Logs ansehen.
• Alles in README dokumentieren.
• Codex nur mit Plan + Diff + Tests arbeiten lassen.

#18. Quellen

• OpenAI Codex CLI: https://developers.openai.com/codex/cli

• OpenAI Codex Windows Guide: https://developers.openai.com/codex/windows

• OpenAI Codex IDE Extension: https://developers.openai.com/codex/ide

• OpenAI Codex Config Basics: https://developers.openai.com/codex/config-basic

• OpenAI Codex GitHub README: https://github.com/openai/codex

• Microsoft: Get started using VS Code with WSL: https://learn.microsoft.com/en-us/windows/wsl/tutorials/wsl-vscode

• VS Code: Developing in WSL: https://code.visualstudio.com/docs/remote/wsl

• Microsoft: Set up a WSL development environment: https://learn.microsoft.com/en-us/windows/wsl/setup/environment

• Microsoft: Manual WSL installation steps: https://learn.microsoft.com/en-us/windows/wsl/install-manual

• JetBrains: Use WSL in IntelliJ IDEA: https://www.jetbrains.com/help/idea/how-to-use-wsl-development-environment-in-product.html

• JetBrains: Gateway WSL: https://www.jetbrains.com/help/idea/remote-development-a.html

• JetBrains: WSL Git support: https://www.jetbrains.com/help/idea/settings-version-control-git.html

• JetBrains: Node.js runtimes with WSL: https://www.jetbrains.com/help/idea/node-js-interpreters.html

• OKD Documentation Home: https://docs.okd.io/

• OKD Installation Overview: https://docs.okd.io/4.21/installing/overview/index.html

• OKD CodeReady Containers: https://okd.io/docs/project/crc/

• CRC Installing: https://crc.dev/docs/installing/

• CRC Getting Started: https://crc.dev/docs/getting-started/

• CRC Networking: https://crc.dev/docs/networking/