Best practice di Dockerfile: creazione di immagini Docker più snelle, veloci e sicure

Docker è diventato uno strumento indispensabile nello sviluppo software moderno, consentendo ai team di creare, distribuire ed eseguire applicazioni con una coerenza e una facilità senza precedenti. Al centro di questa magia della containerizzazione c'è il Dockerfile, uno script semplice ma potente che funge da modello per la creazione delle immagini Docker.

Creare un processo di build Dockerfile efficace è più di un semplice esercizio tecnico: è un percorso verso cicli di sviluppo più rapidi, footprint applicativi più ridotti e sicuri e distribuzioni più affidabili. Che siate alle prime armi con Docker o che vogliate affinare le vostre competenze, questa guida vi guiderà attraverso gli elementi essenziali per scrivere Dockerfile pratici, efficienti e sicuri.

Capire l'ecosistema Docker: un rapido ripasso

Prima di addentrarci nei Dockerfile, accenniamo brevemente ai concetti chiave di Docker:

• Immagini: un'immagine è un pacchetto eseguibile, autonomo e leggero che include tutto il necessario per eseguire il software, tra cui codice, runtime, librerie, variabili d'ambiente e file di configurazione. Le immagini sono modelli immutabili.
• Contenitori: un contenitore è un'istanza eseguibile di un'immagine. È possibile creare, avviare, arrestare, spostare o eliminare i contenitori. Forniscono ambienti isolati per le applicazioni.
• Dockerfile: questo è il nostro focus. Un Dockerfile è un documento di testo contenente una sequenza di comandi che Docker utilizza per assemblare automaticamente un'immagine.
• Docker Hub/Registri: si tratta di repository per l'archiviazione e la condivisione di immagini Docker, simili a GitHub per il codice.

Un Dockerfile ben scritto mira a produrre un'immagine che sia il più possibile snella, veloce da creare e sicura.

Spiegazione dei flag di compilazione Docker

• -t myapp:1.0 : questo flag assegna all'immagine un nome (myapp) e una versione (1.0). L'assegnazione di tag facilita il controllo della versione e semplifica il riferimento a build di immagini specifiche in un secondo momento, soprattutto durante la distribuzione o il push su un registro.

• . (punto) : si riferisce al contesto di compilazione, la directory in cui Docker dovrebbe cercare il Dockerfile e qualsiasi altro file necessario durante la compilazione (ad esempio, i file da COPIARE nell'immagine).
  Docker comprime e invia il contenuto di questa directory al demone Docker. È importante notare che durante il processo di compilazione è possibile accedere solo ai file all'interno del contesto di compilazione.

Istruzioni essenziali per Dockerfile: i blocchi costitutivi

Scopriamo insieme quali sono le istruzioni più comuni e come utilizzarle in modo efficace.

1. DA: Ogni Dockerfile deve iniziare con un'istruzione FROM. Questa specifica l'immagine di base su cui verrà creata l'immagine.
   • Scopo: selezionare un punto di partenza, spesso un sistema operativo (come Ubuntu:22.04) o un runtime di applicazione preconfigurato (come node:18-alpine).
   • Esempio : FROM python:3.9-slim
   • Best Practice: Scegli l'immagine base minima che soddisfi le esigenze della tua applicazione. Le versioni Alpine sono piccole ma utilizzano musl libc, che potrebbe presentare problemi di compatibilità con alcuni pacchetti dipendenti dal linguaggio di programmazione C. Le versioni Slim rappresentano un buon compromesso, offrendo una versione ridotta di una distribuzione standard (come Debian) con glibc.
2. WORKDIR: Questa impostazione imposta wdirectory di lavoro per eventuali istruzioni successive RUN, CMD, ENTRYPOINT, COPY e ADD.
   • Scopo: definire il contesto della directory corrente all'interno dell'immagine per le successive operazioni sui file e l'esecuzione dei comandi. Se la directory non esiste, Docker la crea.
   • Esempio: WORKDIR /usr/src/app
   • Best Practice: utilizzare percorsi assoluti per WORKDIR. Cambiare directory più volte utilizzando WORKDIR è generalmente più semplice che concatenare comandi cd all'interno di istruzioni RUN.
3. COPIA: Copia file o directory dal contesto di compilazione nel file system dell'immagine.
   • Scopo: aggiungere all'immagine il codice dell'applicazione, i file di configurazione e altre risorse necessarie.
   • Esempio:

Dockerfile

WORKDIR /usr/src/app
COPIA package.json ./
COPIA src/ ./src/

• Best Practice: per la semplice copia di file, preferire COPY ad ADD. COPY è più trasparente. ADD offre funzionalità aggiuntive come il download di URL e l'estrazione tar, che possono essere meno prevedibili. Per chiarezza e sicurezza, è spesso meglio usare RUN con curl, wget e tar se è necessario scaricare ed estrarre.

4. CORRERE: Esegue comandi in un nuovo livello sopra l'immagine corrente e ne conferma i risultati. Viene utilizzato per installare software, creare directory, compilare codice, ecc.
   • Scopo: modificare il file system dell'immagine installando pacchetti, eseguendo script di compilazione o impostando configurazioni.
   • Esempio:

Dockerfile

ESEGUI apt-get update && apt-get install -y –no-install-recommends \
nginx \
curl \
&& rm -rf /var/lib/apt/lists/*

• Best Practice: concatenare i comandi correlati usando && e pulire i file temporanei o le cache del gestore pacchetti (come rm -rf /var/lib/apt/lists/* per Debian/Ubuntu o yum clean all per CentOS/RHEL) nella stessa istruzione RUN. Questo riduce al minimo il numero di livelli e le dimensioni dell'immagine, poiché ogni istruzione RUN crea un nuovo livello.

5. AMBIENTE: Imposta le variabili di ambiente disponibili durante il processo di compilazione (dopo la loro definizione) e quando i contenitori vengono eseguiti dall'immagine.
   • Scopo: fornire valori di configurazione, percorsi o impostazioni necessari all'applicazione o agli script di compilazione.
   • Esempio:

Dockerfile

ENV NODE_ENV=produzione
ENV APP_PORT=3000

• Best Practice: utilizzare ENV per i dati di configurazione non sensibili. Si consiglia di utilizzare metodi di iniezione in fase di esecuzione anziché integrarli nell'immagine con ENV per i dati segreti.

6. ARG: Definisce una variabile di fase di compilazione che gli utenti possono passare utilizzando il flag -build-arg durante la compilazione di Docker.
   • Scopo: consentire la parametrizzazione del processo di build senza modificare il Dockerfile.
   • Esempio: Dockerfile

Dockerfile

ARG APP_VERSION=1.0.0
ENV APP_VERSION_ENV=${APP_VERSION}
RUN echo “Versione di compilazione ${APP_VERSION_ENV}”

• Costruisci con: colpire docker build– build-arg APP_VERSION=1.2.3 -t myapp.
• Nota: le variabili ARG non sono disponibili nel contenitore in esecuzione a meno che non siano impostate esplicitamente come variabile ENV, come mostrato sopra.

7. ESPORRE: Informa Docker che il contenitore è in ascolto sulle porte di rete specificate in fase di esecuzione.
   • Scopo: Questo documento serve principalmente come documentazione per il generatore di immagini e per l'utente. Non pubblica la porta.

Esempio:

Dockerfile

ESPONE 8080

• Nota: per rendere la porta accessibile dall'host, utilizzare il flag -p o -P con docker run (ad esempio, docker run -p 8080:8080 myimage).

8. Comando E PUNTO DI INGRESSO: Definisce quale comando viene eseguito all'avvio di un contenitore.
   • CMD ["eseguibile", "parametro1", "parametro2"] : fornisce i valori predefiniti per un contenitore in esecuzione. Questi valori predefiniti possono essere facilmente sovrascritti aggiungendo un comando a docker run. Se si hanno più CMD, solo l'ultimo avrà effetto.
   • ENTRYPOINT [“eseguibile”, “parametro1”, “parametro2”] : configura un contenitore per l'esecuzione come eseguibile. Gli argomenti passati a docker run vengono aggiunti al comando ENTRYPOINT.
   • Esempio (modello tipico):

Dockerfile

ENTRYPOINT [“python”, “app.py”] # Comando principale
CMD [“–help”] # Argomento predefinito se non ne viene fornito nessuno durante l'esecuzione di docker

• Best Practice: utilizzare CMD se si desidera un comando predefinito facilmente sovrascrivibile. Utilizzare ENTRYPOINT per creare un'immagine che si comporti come un eseguibile specifico, spesso utilizzando CMD per fornire argomenti predefiniti. Per le applicazioni web, CMD ["npm", "start"] o CMD ["python", "manage.py", "runserver"] sono standard.

Le migliori pratiche chiave per i Dockerfile ottimizzati

Scrivere un Dockerfile funzionale è solo l'inizio. Ottimizzarlo porta vantaggi significativi.

• Sfrutta efficacemente la cache di build: Docker crea le immagini a livelli e, se possibile, cerca di riutilizzare i livelli delle build precedenti (caching). Per massimizzare gli accessi alla cache:
  • Ordina le istruzioni da quelle che cambiano meno frequentemente a quelle che cambiano più frequentemente. Ad esempio, installa le dipendenze (che cambiano meno frequentemente) prima di copiare il codice sorgente dell'applicazione (che cambia frequentemente).

Dockerfile

# Buon esempio di caching per un'app Node.js
FROM node:18-alpine
WORKDIR /app
COPY package.json package-lock.json ./ # Le dipendenze cambiano meno spesso
RUN npm ci –omit=dev # Questo livello viene memorizzato nella cache se i file del pacchetto non cambiano
COPY . . # Il codice sorgente cambia spesso, quindi è l'ultimo
CMD ["node", "server.js"]

• Mantieni le tue immagini piccole: Le immagini più piccole sono più veloci da estrarre, spingere e distribuire e hanno una superficie di attacco ridotta.
  • Utilizzare immagini di base minime: le varianti Alpine, slim o distroless sono notevolmente più piccole delle immagini complete del sistema operativo.
  • Pulizia nello stesso livello RUN: Rimuovi le cache o i file temporanei non necessari utilizzando la stessa istruzione RUN dopo l'installazione dei pacchetti. Ad esempio:
    • Debian/Ubuntu: apt-get clean && rm -rf /var/lib/apt/lists/*
    • CentOS/RHEL: yum clean all o dnf clean all
    • Alpino: rm -rf /var/cache/apk/*
• Adottare build multi-fase: Questo è uno dei metodi più efficaci per ridurre le dimensioni delle immagini, soprattutto per i linguaggi compilati o le applicazioni con fasi di compilazione (come i frontend JavaScript).
  • Concetto: usa una fase (un blocco FROM) con tutti gli strumenti di build e le dipendenze di sviluppo per compilare/creare la tua applicazione. Quindi, avvia una nuova fase da un'immagine di base minima e usa COPY– from= … per copiare solo gli artefatti compilati necessari in questa fase finale e pulita.
  • Esempio (applicazione Go semplificata): Dockerfile

Dockerfile

# Fase 1: Compila
DA golang:1.20 COME builder
WORKDIR /app
COPY . .
RUN go build -o myapp

# Fase 2: Runtime DA
debian:bullseye-slim
WORKDIR /app
COPY –from=builder /app/myapp .
CMD [“./myapp”]

• La fase di sviluppo include il Go SDK, ma l'immagine finale contiene solo il binario compilato e il sistema operativo Alpine minimo.
• Dare priorità alla sicurezza:
  • Esecuzione come utente non root: per impostazione predefinita, i container vengono eseguiti come root. Questo rappresenta un rischio per la sicurezza. Crea un utente e un gruppo dedicati e senza privilegi nel tuo Dockerfile e usa l'istruzione USER per passare a tali utenti. Dockerfile

Dockerfile

RUN addgroup -S appgroup && adduser -S appuser -G appgroup
# … COPIA i file e assegna loro il nome appuser:appgroup …
UTENTE appuser

• Installa solo i pacchetti necessari: ogni pacchetto rappresenta una potenziale vulnerabilità. Evita di installare strumenti di debug o utility di sviluppo nelle immagini di produzione (a questo scopo, utilizza build multi-fase).
• Non codificare i segreti: evita di inserire password, chiavi API o altri segreti nel tuo Dockerfile (ad esempio, nelle variabili ENV). Utilizza metodi di iniezione in fase di esecuzione come segreti Docker, segreti Kubernetes o variabili di ambiente fornite in modo sicuro in fase di esecuzione.
• Utilizzare .dockerignore in modo efficace: creare un file .dockerignore nella radice del contesto di build (allo stesso livello del Dockerfile). Elencare i file e le directory da escludere dall'invio al demone Docker (ad esempio, .git, node_modules se installato nell'immagine, configurazioni IDE locali, *.log).
• Vantaggi: velocizza il processo di build di Docker riducendo le dimensioni del contesto di build ed evitando che file sensibili o non necessari vengano inclusi nell'immagine.

Oltre le basi: ulteriori miglioramenti

Una volta che hai acquisito familiarità con quanto sopra, prendi in considerazione questi per ottenere Dockerfile ancora migliori:

• BuildKit: il nuovo motore di build di Docker, spesso abilitato di default. Offre prestazioni migliori (build parallele), caching migliorato e funzionalità avanzate come i segreti di build (RUN– mount=type=secret,…) e i mount della cache (RUN– mount=type=cache,…) per i gestori di pacchetti. Assicurarsi che sia attivo o abilitarlo con DOCKER_BUILDKIT=1.
• Linting dei Dockerfile: utilizza strumenti come Hadolint (hadolint Dockerfile) per analizzare staticamente il tuo Dockerfile per individuare errori, violazioni di stile e aderenza alle best practice prima di procedere alla compilazione.

Suggerimenti rapidi per la risoluzione dei problemi comuni

• "File non trovato" durante COPIA o AGGIUNGI : ricontrolla il percorso di origine (è relativo alla radice del contesto di compilazione) e assicurati che il file non sia escluso da .dockerignore.
• Build lente: rivedere l'ordine delle istruzioni per l'ottimizzazione della cache. Combinare i comandi RUN ove possibile. Assicurarsi che il file .dockerignore sia completo.
• Immagini di grandi dimensioni: usa build multi-fase! Pulisci i livelli RUN. Scegli immagini di base minime.

Dockerfile nel flusso di lavoro DevOps

Un Dockerfile è un elemento chiave dell'"Infrastruttura come Codice"

• Controllo della versione: esegui sempre il commit del tuo Dockerfile nel repository Git insieme al codice dell'applicazione.
• Integrazione CI/CD: automatizza il processo di build e di push delle immagini Docker all'interno delle pipeline di integrazione continua/distribuzione continua (ad esempio, GitHub Actions, Jenkins, GitLab CI). Questo garantisce build e distribuzioni coerenti e ripetibili.

Conclusione: costruire le basi per il successo

Creare Dockerfile efficaci è un investimento che offre vantaggi significativi in ​​termini di velocità di sviluppo, affidabilità operativa e sicurezza delle applicazioni. Padroneggiando le istruzioni fondamentali, implementando best practice come build multi-fase e un'attenta gestione dei livelli di immagine, e dando priorità alla sicurezza, è possibile produrre immagini Docker snelle, efficienti e robuste.

Questa guida fornisce una solida base. Mentre prosegui il tuo viaggio con Docker, continua a esplorare, sperimentare e perfezionare i tuoi Dockerfile.

Pronti a migliorare le vostre pratiche Docker e DevOps?

In Seahawk Media , siamo specializzati nell'aiutare le aziende a sfruttare appieno il potenziale della containerizzazione, delle tecnologie cloud e delle pipeline CI/CD semplificate. Il nostro team di esperti è a vostra disposizione per aiutarvi a ottimizzare le distribuzioni delle vostre applicazioni, migliorare la sicurezza o accelerare il ciclo di vita dello sviluppo.