Piccole immagini Docker che credevano in se stesse*

[riferimento alla favola americana per bambini «Il piccolo locomotore che poteva» («The Little Engine That Could») — nota del traduttore.]*

Come creare automaticamente piccole immagini Docker per le proprie esigenze

Un'ossessione insolita

Negli ultimi due mesi sono stato ossessionato dall'idea di quanto si possa ridurre un'immagine Docker pur mantenendo l'applicazione funzionante.

Capisco, l'idea è strana.

Prima di addentrarmi nei dettagli e nelle complessità tecniche, vorrei spiegare perché questo problema mi ha colpito e come riguarda anche te.

Perché la dimensione conta

Riducendo il contenuto dell'immagine Docker, riduciamo anche l'elenco delle vulnerabilità. Inoltre, rendiamo le immagini più pulite, poiché contengono solo ciò che è necessario per eseguire le applicazioni.

C'è anche un piccolo vantaggio: le immagini vengono scaricate un po' più velocemente, ma a mio avviso non è così importante.

Nota: Se la dimensione è un problema per te, le immagini Alpine sono già piccole e probabilmente si adatteranno alle tue esigenze.

Immagini Distroless

Il progetto Distroless offre una selezione di immagini base «distroless», che non contengono gestori di pacchetti, shell e altre utility che sei abituato a vedere nella riga di comando. Di conseguenza, non puoi utilizzare gestori di pacchetti come pip e apt :

FROM gcr.io/distroless/python3
RUN  pip3 install numpy

Dockerfile che utilizza l'immagine distroless di Python 3

Invio del contesto di build al demone Docker  2.048kB
Passo 1/2 : FROM gcr.io/distroless/python3
 ---> 556d570d5c53
Passo 2/2 : RUN  pip3 install numpy
 ---> In esecuzione in dbfe5623f125
/bin/sh: 1: pip3: non trovato

Pip non è presente nell'immagine

Di solito, questo problema viene risolto con un build multi-stage:

FROM python:3 as builder
RUN  pip3 install numpy

FROM gcr.io/distroless/python3
COPY --from=builder /usr/local/lib/python3.7/site-packages /usr/local/lib/python3.5/

Build multi-stage

Di conseguenza, si ottiene un'immagine di dimensione 130 MB. Non è poi così male! A titolo di confronto: l'immagine di Python predefinita pesa 929 MB, mentre la versione 'snellita' (3.7-slim) — 179 MB, l'immagine alpine (3.7-alpine) — 98,6 MB, mentre l'immagine base distroless utilizzata nell'esempio pesa 50,9 MB.

Si può giustamente osservare che nell'esempio precedente stiamo copiando un'intera cartella /usr/local/lib/python3.7/site-packages, che potrebbe contenere dipendenze non necessarie. Anche se è chiaro che c'è una variazione nelle dimensioni di tutte le immagini di base di Python esistenti.

Al momento della scrittura di queste righe, Google distroless non supporta molte immagini: Java e Python sono ancora in fase di sperimentazione, e Python esiste solo per 2,7 e 3,5.

Piccole immagini

Torniamo alla mia ossessione per la creazione di immagini ridotte.

In realtà volevo vedere come sono fatti le immagini distroless. Il progetto distroless utilizza lo strumento di build di Google bazel. Tuttavia, per installare Bazel e creare immagini proprie, è stato necessario sudare (e per essere completamente onesti, reinventare la ruota è divertente e istruttivo). Volevo semplificare la creazione di immagini ridotte: il processo di creazione di un'immagine deve essere estremamente semplice, banale. Nessun file di configurazione, solo una riga nel terminale: creare semplicemente un'immagine per.

Quindi, se vuoi creare immagini proprie, sappi che esiste un'immagine docker unica, scratch. Scratch è un'immagine "vuota", non contiene file, anche se di default pesa — wow! — 77 byte.

FROM scratch

L'immagine scratch

L'idea dell'immagine scratch è che puoi copiarvi dentro qualsiasi dipendenza dalla macchina host e usarl in Dockerfile (come copiare e apt installare da zero), oppure successivamente, quando l'immagine Docker si materializza. Questo permette un controllo completo sul contenuto del contenitore Docker e, quindi, sul suo dimensionamento.

Ora dobbiamo in qualche modo raccogliere queste dipendenze. Gli strumenti esistenti come apt consentono di scaricare pacchetti, ma sono legati alla macchina attuale e, alla fine, non supportano Windows o MacOS.

E così ho deciso di creare uno strumento che assemblasse automaticamente un'immagine di base della dimensione minima possibile e che potesse eseguire qualsiasi applicazione. Ho utilizzato pacchetti Ubuntu/Debian, estraendo (ottenendo pacchetti direttamente dai repository) e trovando ricorsivamente le loro dipendenze. Il programma avrebbe dovuto scaricare automaticamente l'ultima versione stabile del pacchetto, minimizzando i rischi per la sicurezza.

Ho chiamato lo strumento fetchy, perché... trova e porta... ciò di cui hai bisogno [dal inglese "fetch", "portare" — ndt.]. Lo strumento funziona tramite un'interfaccia a riga di comando, ma offre anche un'API.

Per assemblare un'immagine usando fetchy (questa volta prendiamo l'immagine Python), devi solo usare il CLI in questo modo: fetchy dockerize python. Potrebbe esserti chiesto di fornire il sistema operativo di destinazione e il nome in codice, poiché fetchy attualmente utilizza solo pacchetti basati su Debian e Ubuntu.

Ora è possibile scegliere quali dipendenze non siano affatto necessarie (nel nostro contesto) ed escluderle. Ad esempio, Python dipende da perl, anche se funziona benissimo senza perl installato.

Risultati

Immagine di Python creata con il comando fetchy dockerize python3.5 pesando solo 35 MB (sono più che sicuro che in futuro si potrà alleggerire ancora di più). Quindi, dal buon uso dell'immagine distroless sono riuscito a "tagliare" altri 15 MB.

Tutte le immagini raccolte fino a questo momento possono essere visualizzate qui.

Progetto — qui.

Se ti mancano delle funzionalità, crea semplicemente una richiesta — sarò felice di aiutarti 🙂 In effetti, in questo momento sto lavorando all'integrazione di altri gestori di pacchetti in fetchy, in modo che non ci sia più bisogno di build multi-fase.

Fonte: habr.com