Blocco A · Fondamenta Docker — Modulo 2 di 16
Immagini e Dockerfile
Obiettivi di oggi
- Scrivere un Dockerfile da zero
- Capire layer e cache di build (e perché l'ordine conta)
- Costruire e taggare immagini
- Containerizzare l'API Pratiche — il cuore dell'app del corso
Il Dockerfile: la ricetta
FROM python:3.12 # da dove parto
WORKDIR /app # dove lavoro
COPY requirements.txt . # porto dentro i file
RUN pip install -r requirements.txt # eseguo in fase di BUILD
COPY app.py .
EXPOSE 5000 # documento la porta
CMD ["python", "app.py"] # cosa parte a RUNTIME
RUN = durante la build · CMD = all'avvio del container
Layer e cache
- Ogni istruzione crea un layer; i layer si riusano se gli input non cambiano
- Regola d'oro: prima ciò che cambia raramente (dipendenze), poi il codice
- Effetto: modifichi
app.py → rebuild in 2 secondi; modifichi i requirements → si reinstalla tutto
Build, tag, run
docker build -t pratiche/api:0.1.0 api/
docker image ls pratiche/api
docker history pratiche/api:0.1.0 # i layer, uno per istruzione
docker run -d --name api -p 5000:5000 pratiche/api:0.1.0
curl http://localhost:5000/api/pratiche
L'immagine è l'unità di rilascio
- Tutto ciò che serve al servizio sta DENTRO: dipendenze, runtime, codice
- Stessa immagine = stesso comportamento, su qualunque host
- È ciò che renderà sensato tutto il resto: versioni (M7), pipeline (M9), rollback (M12)
Laboratorio (2h)
- L'API Pratiche è fornita (Flask, archivio in memoria): leggila, avviala
- Scrivi il Dockerfile, builda
pratiche/api:0.1.0, prova GET e POST
- Esperimenti sulla cache: modifica codice vs modifica requirements
Riepilogo e prossimo passo
- Dockerfile = ricetta versionata; layer = build veloci se ordinati bene
- La nostra immagine funziona ma: ~1 GB, gira da root, server di sviluppo…
- Modulo 3: la portiamo allo standard dell'Ente
← portale · frecce/click per navigare · F = schermo intero · Ctrl+P = PDF