Docker Run

docker run -d -p 80:80 --name mein-web nginx

• -d (Detached): Lauf im Hintergrund (sonst blockiert dein Terminal).
• -p 80:80 (Port): Öffne Port 80 am Laptop und leite zu Port 80 im Container.
• --name: Gib ihm einen Namen (sonst heißt er modest_einstein).
• nginx: Das Image.

Wegwerf-Modus für Tests: docker run --rm -it ubuntu bash

• --rm: Lösche den Container sofort, wenn er fertig ist (kein Müll).
• -it: Interaktiv (ich will tippen).
• bash: Der Befehl, den ich starten will.

1. Entrypoint vs. CMD

Der ewige Klassiker.

• ENTRYPOINT: Die Haupt-Anwendung ("Das Binary"). Wird nicht überschrieben.
• CMD: Die Argumente ("Die Params"). Wird leicht überschrieben. Image: ENTRYPOINT ["echo"], CMD ["Hello"]. docker run img -> echo Hello. docker run img World -> echo World. Wenn du run benutzt, überschreibst du immer nur CMD, es sei denn du nutzt --entrypoint.

2. Runtime Constraints (--ulimit)

Manchmal crasht Java oder Elasticsearch im Container: "Too many open files". Das liegt daran, dass der Container die Limits vom Host erbt (oft 1024). Mit docker run --ulimit nofile=65535:65535 ... kannst du Kernel-Limits pro Container hochsetzen, ohne den Host global zu ändern.

3. PID 1 & Signal Forwarding

docker run startet deinen Prozess als PID 1. PID 1 ist speziell (in Linux ignorieren sie Standard-Kill-Signale). Wenn du docker run ... /bin/sh -c 'java app.jar' machst, ist die Shell PID 1. Wenn du docker stop machst, kriegt die Shell das Signal. Sie leitet es aber nicht an Java weiter. Java wird nach 10s gnadenlos gekillt. Nutze exec Form im Dockerfile oder --init im Run-Befehl.

1. Cgroups und Namespaces Initiierung

Was macht docker run tief im Linux-Kernel wirklich? Es ruft insgeheim Tools wie runc (Container Runtime) auf. Kommando: "Kernel! Erstelle mir einen isolierten Namespace (PID)". Das gaukelt dem laufenden Container-Prozess vor, er wäre PID 1, obwohl er auf dem echten Server in Wahrheit Prozess 54890 ist. Weiter: "Kernel! Sperre ihn in eine Cgroup". Docker run (-m 512m --cpus=1) konfiguriert den Linux-Sheduler rigoros so, dass dieser Container hart abstürzt (OOM Killed), bevor er jemals 513 MB Server-RAM berühren darf. docker run ist in Wahrheit nur ein glorifizierter Wrapper um sehr tiefgreifende Linux-Kernel-Kapselungen.

2. Das Seccomp Profile

Warum kann ein Hacker, der eine Lücke in deiner Node.js App ausnutzt und "in den Container" eindringt, den darunterliegenden Server nicht übernehmen? Weil docker run standardmäßig ein Seccomp (Secure Computing Mode) Profil mitlädt. Von über 300 verfügbaren Linux-Systemaufrufen (Syscalls), die ein C-Programm am Kernel machen kann (z.B. Hardware Mounten, Datum ändern, Kernel-Module nachladen), blockiert Docker hart die gefährlichsten 44 Syscalls. Selbst wenn der Container-Angreifer Code schreibt, der die System-Uhrzeit deines nackten Servers manipulieren will, verwirft der Linux Kernel den Command mit "Permission Denied", weil die Container-Laufzeitumgebung in einer syscall-verkrüppelten Sandbox festhängt.

3. TTY Allocation (-it Parameter)

Hängst du in Linux ein Binary an das Terminal, will es PTY (Pseudo Terminal) Features haben (bunte Farben, Strg+C Escape-Sequenzen verstehen). Betreibst du docker run ubuntu bash (ohne -it), startet Bash im Container, "merkt", dass gar keine Tastatur oder Monitor angeschlossen ist (Background), schaltet im Bruchteil einer Sekunde wieder ab und "exits". Der -t (Allocate pseudo-TTY) Flag zwingt Docker, einen unsichtbaren Rohrpost-Treiber (TTY) in den Container zu injizieren, und -i (Interactive) zwingt den Docker-Client auf dem Host, deinen Tastatur-Input fortlaufend ungepuffert als Stream durch dieses Rohr in den Container zu pumpen.