Perché le immagini del contenitore Docker sono così grandi?

Ho creato un'immagine semplice tramite Dockerfile di Fedora (inizialmente 320 MB).

Aggiunto Nano (questo piccolo editor di dimensioni di 1 MB) e la dimensione dell'immagine è salita a 530 MB. Ho aggiunto Git sopra a quello (30-ish MB), quindi le dimensioni della mia immagine sono salite a 830 MB.

Non è folle?

Ho provato a esportare e importare container per rimuovere la cronologia / le immagini intermedie. Questo sforzo ha permesso di risparmiare fino a 25 MB, ora la mia dimensione dell'immagine è 804 MB. Ho anche provato a eseguire molti comandi su uno RUN, ma sto ancora ricevendo gli stessi 830 MB iniziali.

Sto avendo dei dubbi se vale la pena usare Docker. Voglio dire, ho appena installato nulla e sto colpendo 1 GB. Se dovessi aggiungere alcune cose serie come un database e così via, potrei esaurire lo spazio su disco.

Qualcuno soffre di ridicole dimensioni delle immagini? Come lo gestisci?

A meno che il mio Dockerfile non sia terribilmente errato?

FROM fedora:latest
MAINTAINER Me NotYou <email@dot.com>
RUN yum -y install nano
RUN yum -y install git

ma è difficile immaginare cosa potrebbe andare storto qui.

Come diceva @rexposadas, le immagini includono tutti i livelli e ogni livello include tutte le dipendenze per ciò che hai installato. È anche importante notare che le immagini di base (come quelle fedora:latesttendenzialmente sono molto spoglie. Potresti essere sorpreso dal numero di dipendenze che il tuo software installato ha.

Sono stato in grado di ridurre notevolmente la tua installazione aggiungendo yum -y clean alla ciascuna riga:

FROM fedora:latest
RUN yum -y install nano && yum -y clean all
RUN yum -y install git && yum -y clean all

È importante farlo per ogni RUN, prima che il layer venga impegnato, altrimenti le eliminazioni non rimuovono effettivamente i dati. Cioè, in un file system union / copy-on-write, la pulizia alla fine non riduce realmente l'utilizzo del file system perché i dati reali sono già impegnati nei livelli inferiori. Per ovviare a questo è necessario pulire ad ogni livello.

$ docker history bf5260c6651d
IMAGE               CREATED             CREATED BY                                      SIZE
bf5260c6651d        4 days ago          /bin/sh -c yum -y install git; yum -y clean a   260.7 MB
172743bd5d60        4 days ago          /bin/sh -c yum -y install nano; yum -y clean    12.39 MB
3f2fed40e4b0        2 weeks ago         /bin/sh -c #(nop) ADD file:cee1a4fcfcd00d18da   372.7 MB
fd241224e9cf        2 weeks ago         /bin/sh -c #(nop) MAINTAINER Lokesh Mandvekar   0 B
511136ea3c5a        12 months ago                                                       0 B

Le immagini docker non sono grandi, stai solo costruendo immagini di grandi dimensioni.

L' scratchimmagine è 0B e puoi usarla per impacchettare il tuo codice se puoi compilare il tuo codice in un binario statico. Ad esempio, puoi compilare il tuo programma Go e impacchettarlo soprascratch per creare un'immagine completamente utilizzabile che sia inferiore a 5 MB.

La chiave è non usare le immagini Docker ufficiali, sono troppo grandi. Scratch non è neanche così pratico, quindi consiglierei di utilizzare Alpine Linux come immagine di base. È ~ 5 MB, quindi aggiungi solo ciò che è necessario per la tua app. Questo post su Microcontainer mostra come costruire immagini di dimensioni molto ridotte su Alpine.

AGGIORNAMENTO: le immagini Docker ufficiali sono basate su alpine ora, quindi sono buone da usare ora.

Ecco alcune altre cose che puoi fare :

• Evita più RUNcomandi dove puoi. Metti tutto il possibile in un RUNcomando (usando &&)
• ripulisci gli strumenti non necessari come wget o git (di cui hai solo bisogno per scaricare o creare cose, ma non per eseguire il tuo processo)

Con entrambi i consigli AND di @Andy e @michau sono stato in grado di ridimensionare la mia immagine nodejs da 1.062 GB a 542 MB.

Modifica: Un'altra cosa importante: "Mi ci è voluto un po 'di tempo per capire davvero che ogni comando Dockerfile crea un nuovo contenitore con i delta. [...] Non importa se rm -rf i file in un comando successivo; continuano a esistere in alcuni container di livello intermedio ". Così ora sono riuscito a mettere apt-get install, wget, npm install(con le dipendenze Git) e apt-get removein un unico RUNcomando, così ora la mia immagine ha solo 438 MB.

Modifica 29/06/17

Con Docker v17.06 sono disponibili nuove funzionalità per i file Docker: è possibile avere più FROMistruzioni all'interno di un file Docker e solo i contenuti dell'ultimo FROMsaranno nell'immagine Docker finale. Ciò è utile per ridurre le dimensioni dell'immagine, ad esempio:

FROM nodejs as builder
WORKDIR /var/my-project
RUN apt-get install ruby python git openssh gcc && \
    git clone my-project . && \
    npm install

FROM nodejs
COPY --from=builder /var/my-project /var/my-project

Si tradurrà in un'immagine che ha solo l'immagine di base nodejs più il contenuto di / var / my-project sin dai primi passi - ma senza ruby, python, git, openssh e gcc!

Sì, quelle dimensioni sono ridicole e non ho davvero idea del perché così poche persone lo notino.

Ho creato un'immagine di Ubuntu che è in realtà minima (a differenza di altre cosiddette immagini "minimal"). Si chiama textlab/ubuntu-essentiale ha 60 MB.

FROM textlab/ubuntu-essential
RUN apt-get update && apt-get -y install nano

L'immagine sopra è di 82 MB dopo l'installazione di nano.

FROM textlab/ubuntu-essential
RUN apt-get update && apt-get -y install nano git

Git ha molti più prerequisiti, quindi l'immagine diventa più grande, circa 192 MB. Questo è ancora inferiore alla dimensione iniziale della maggior parte delle immagini.

Puoi anche dare un'occhiata allo script che ho scritto per creare l'immagine minima di Ubuntu per Docker . Puoi forse adattarlo a Fedora, ma non sono sicuro di quanto sarai in grado di disinstallare.

Quanto segue mi ha aiutato molto:

Dopo aver rimosso i pacchetti non utilizzati (ad es. Redis 1200 mb liberati) all'interno del mio contenitore, ho fatto quanto segue:

1. docker export [containerID] -o containerername.tar
2. docker import -m "commit del messaggio qui" contiene username.tar imagename: tag

Gli strati si appiattiscono. Le dimensioni della nuova immagine saranno inferiori perché ho rimosso i pacchetti dal contenitore come indicato sopra.

Ci è voluto molto tempo per capirlo ed è per questo che ho aggiunto il mio commento.

Per la migliore pratica, è necessario eseguire un singolo comando RUN, poiché ogni istruzione RUN nel Dockerfile scrive un nuovo livello nell'immagine e ogni livello richiede spazio aggiuntivo sul disco. Al fine di ridurre al minimo i livelli numerici, qualsiasi manipolazione di file come installazione, spostamento, estrazione, rimozione, ecc. Dovrebbe idealmente essere effettuata con una singola istruzione RUN

FROM fedora:latest
RUN yum -y install nano git && yum -y clean all

Docker Squash è davvero una bella soluzione. è possibile $packagemanager cleannell'ultimo passaggio anziché in ogni riga e quindi eseguire una finestra mobile per sbarazzarsi di tutti i livelli.

https://github.com/jwilder/docker-squash

Sì, il sistema a strati è abbastanza sorprendente. Se si dispone di un'immagine di base e la si incrementa nel modo seguente:

# Test
#
# VERSION       1

# use the centos base image provided by dotCloud
FROM centos7/wildfly
MAINTAINER JohnDo 

# Build it with: docker build -t "centos7/test" test/

# Change user into root
USER root

# Extract weblogic
RUN rm -rf /tmp/* \
    && rm -rf /wildfly/* 

L'immagine ha esattamente le stesse dimensioni. Ciò significa essenzialmente che devi riuscire a mettere nelle tue fasi RUN un sacco di estrazione, installazione e pulizia magica per rendere le immagini piccole quanto il software installato.

Questo rende la vita molto più difficile ...

Nel dockerBuild mancano i passaggi RUN senza commit.