Docker - Modello Mentale

Cosa fa

#

Piattaforma di containerizzazione. Ogni container e' un processo isolato con il proprio filesystem, rete e permessi — come un mini Linux che non sa degli altri.

L'analogia del condominio

#

Prima di leggere le note tecniche, fissa questo modello:

docker build = compilazione docker run = new Classe()

#

Container = mini Linux isolato

#

graph TD
    subgraph Host["Host - il palazzo"]
        subgraph C1["Container rails - appartamento 1"]
            P1[processo ruby]
            FS1[filesystem isolato]
            N1[interfaccia di rete virtuale]
        end
        subgraph C2["Container postgres - appartamento 2"]
            P2[processo postgres]
            FS2[filesystem isolato]
            N2[interfaccia di rete virtuale]
        end
        subgraph C3["Container redis - appartamento 3"]
            P3[processo redis]
            FS3[filesystem isolato]
            N3[interfaccia di rete virtuale]
        end
        K[Kernel Linux condiviso]
        P1 & P2 & P3 --> K
    end

Ogni container ha il suo filesystem — ma condividono il kernel dell'host. Piu' leggero di una VM (che ha il suo kernel) ma meno isolato (un bug nel kernel colpisce tutti).

Container vs VM — non e' un'evoluzione, e' un livello diverso

#

Docker non e' la "naturale evoluzione" di una VM. Virtualizzano livelli diversi dello stack:

Coesistono: la configurazione tipica in cloud e' VM su hypervisor, con Docker che gira dentro quella VM.

Perche' nel Dockerfile c'e' Alpine o Ubuntu se il kernel e' condiviso?

#

Un sistema Linux ha due parti distinte:

┌─────────────────────────────┐
│  USERSPACE                  │  bash, apt/apk, libc, pip, la tua app
│  (varia per distro)         │  ← questo e' FROM alpine / FROM ubuntu
├─────────────────────────────┤
│  KERNEL SPACE               │  syscall, processi, rete, hardware
│  (condiviso in Docker)      │  ← questo e' sempre l'host
└─────────────────────────────┘

FROM alpine non sceglie il kernel — sceglie il filesystem userspace di Alpine: musl libc, ash shell, apk. Il kernel sotto e' sempre quello dell'host.

Per questo Alpine pesa ~5MB: porta solo il minimo indispensabile dell'userspace, zero kernel.

Conseguenza pratica: non puoi fare FROM windows su un host Linux. Il kernel Windows non e' quello dell'host. Docker Desktop su Mac/Windows aggira questo girando una mini VM Linux sotto, e i container girano dentro quella VM.

Implicazione di sicurezza (Security+)

#

Kernel condiviso = superficie di attacco condivisa. Una vulnerabilita' nel kernel Linux colpisce tutti i container su quell'host contemporaneamente. Le VM sono piu' isolate per questo motivo — ogni VM ha il suo kernel separato.

Il ciclo di vita

#

graph LR
    DF[Dockerfile] -->|docker build| IMG[Immagine]
    IMG -->|docker run| C[Container in esecuzione]
    C -->|docker stop| CS[Container fermo]
    CS -->|docker start| C
    CS -->|docker rm| Gone[eliminato]
    IMG -->|docker rmi| Gone2[immagine eliminata]
    V[Volume] -->|montato| C
    V -->|sopravvive a| Gone

L'immagine e' permanente — il container e' temporaneo. Il volume e' permanente — il filesystem del container e' temporaneo.

Come si collegano le note

#

docker-overview.md ← sei qui — modello mentale │ ├── docker-image.md → cos'e' un'immagine, layer, tag ├── dockerfile.md → come si costruisce un'immagine ├── docker-network.md → reti, DNS interno, isolamento ├── docker-compose.md → file YAML, esempio Chatwoot └── docker-security.md → docker.sock, root, porte, secrets

Collegato a

#

• docker-image — immagini e layer
• dockerfile — ENTRYPOINT, CMD, COPY, USER
• docker-network-defense — reti, DNS interno, bridge
• docker-compose — orchestrazione multi-container
• docker-security — superficie di attacco e contromisure
• system — categoria