Hva er forskjellen mellom et Docker-bilde og en container?

En forekomst av et bilde kalles en beholder. Du har et bilde, som er et sett med lag som du beskriver. Hvis du starter dette bildet, har du en løpende beholder av dette bildet. Du kan ha mange kjørende containere av det samme bildet.

Du kan se alle bildene dine med docker images mens du kan se dine løpende containere med docker ps (og du kan se alle containere med docker ps -a).

Så en kjørende forekomst av et bilde er en container.

Fra min artikkel om Automatisering av Docker-distribusjoner:

Docker Images vs. Containere

I Dockerland er det images og det er containere. De to er nært beslektet, men forskjellige. For meg har det å forstå denne dikotomien avklart Docker enormt.

Hva er et bilde?

Et image er en inert, uforanderlig fil som egentlig er et øyeblikksbilde av en container. Images opprettes med kommandoen build, og de vil produsere en container når de startes med run. Bilder lagres i et Docker-register som registry.hub.docker.com. Fordi de kan bli ganske store, er bilder designet for å være sammensatt av lag med andre bilder, slik at en minimal mengde data kan sendes når bilder overføres over nettverket.

Lokale bilder kan oppføres ved å kjøre docker images:

REPOSITORY                TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
ubuntu                    13.10               5e019ab7bf6d        2 months ago        180 MB
ubuntu                    14.04               99ec81b80c55        2 months ago        266 MB
ubuntu                    latest              99ec81b80c55        2 months ago        266 MB
ubuntu                    trusty              99ec81b80c55        2 months ago        266 MB
                                  4ab0d9120985        3 months ago        486.5 MB

Noen ting å merke seg:

1. IMAGE ID er de første 12 tegnene i den sanne identifikatoren for et bilde. Du kan opprette mange tagger for et gitt bilde, men alle ID-ene vil være de samme (som ovenfor).
2. VIRTUELL STØRRELSE er virtuell fordi den legger sammen størrelsene til alle de forskjellige underliggende lagene. Dette betyr at summen av alle verdiene i denne kolonnen sannsynligvis er mye større enn diskplassen som brukes av alle disse bildene.
3. Verdien i REPOSITORY-kolonnen kommer fra -t-flagget i docker build-kommandoen, eller fra docker tag-ing av et eksisterende bilde. Du står fritt til å tagge bilder ved hjelp av en nomenklatur som gir mening for deg, men vet at docker vil bruke taggen som registerplassering i en docker push eller docker pull.
4. Den fullstendige formen for en tag er [REGISTRYHOST/][USERNAME/]NAME[:TAG]. For ubuntu ovenfor er REGISTRYHOST utledet til å være registry.hub.docker.com. Så hvis du planlegger å lagre bildet ditt kalt my-application i et register på docker.example.com, bør du merke det bildet docker.example.com/my-application.
5. TAG-kolonnen er bare [:TAG]-delen av full-taggen. Dette er uheldig terminologi.
6. Den seneste taggen er ikke magisk, det er ganske enkelt standardtaggen når du ikke spesifiserer en tagg.
7. Du kan ha umerkede bilder som bare kan identifiseres ved hjelp av bilde-ID-ene. Disse vil få `` TAG og REPOSITORY. Det er lett å glemme dem.

Mer informasjon om bilder finnes i Docker-dokumentasjonen og ordlisten.

Hva er en container?

For å bruke en programmeringsmetafor, hvis et bilde er en klasse, er en container en forekomst av en klasse - et kjøretidsobjekt. Beholdere er forhåpentligvis grunnen til at du bruker Docker; de er lette og bærbare innkapslinger av et miljø der du kan kjøre applikasjoner.

Se lokale containere som kjører med docker ps:

CONTAINER ID        IMAGE                               COMMAND                CREATED             STATUS              PORTS                    NAMES
f2ff1af05450        samalba/docker-registry:latest      /bin/sh -c 'exec doc   4 months ago        Up 12 weeks         0.0.0.0:5000->5000/tcp   docker-registry

Her kjører jeg en dockerisert versjon av dokkeregisteret, slik at jeg har et privat sted å lagre bildene mine. Igjen, noen ting å merke seg:

1. I likhet med IMAGE ID er CONTAINER ID den sanne identifikatoren for containeren. Den har samme form, men den identifiserer en annen type objekt.
2. docker ps gir bare ut running containere. Du kan se alle containere (running eller stopped) med docker ps -a.
3. NAMES kan brukes til å identifisere en startet container via --name flagget.

Slik unngår du opphopning av bilder og containere

En av mine tidlige frustrasjoner med Docker var den tilsynelatende konstante opphopningen av umerkede bilder og stoppede containere. Ved en håndfull anledninger resulterte denne opphopningen i fullstappede harddisker som bremset den bærbare datamaskinen min eller stoppet den automatiserte byggepipelinen min. Snakk om "containere overalt"!

Vi kan fjerne alle umerkede bilder ved å kombinere docker rmi med den siste dangling=true-spørringen:

docker images -q --filter "dangling=true" | xargs docker rmi

Docker vil ikke kunne fjerne bilder som ligger bak eksisterende containere, så det kan hende du må fjerne stoppede containere med docker rm først:

docker rm `docker ps --no-trunc -aq`

Dette er kjente smertepunkter med Docker og kan bli adressert i fremtidige utgivelser. Imidlertid, med en klar forståelse av bilder og containere, kan disse situasjonene unngås med et par fremgangsmåter:

1. Fjern alltid en ubrukelig, stoppet container med `docker rm [CONTAINER_ID].
2. Fjern alltid bildet bak en ubrukelig, stoppet container med docker rmi [IMAGE_ID].

Selv om det er enklest å tenke på en container som et løpende bilde, er dette ikke helt nøyaktig.

Et bilde er egentlig en mal som kan gjøres om til en container. For å gjøre et bilde om til en container, tar Docker-motoren bildet, legger til et lese- og skrivefilsystem på toppen og initialiserer forskjellige innstillinger, inkludert nettverksporter, containernavn, ID og ressursgrenser. En container som kjører har en prosess som kjører, men en container kan også stoppes (eller exited i Dockers terminologi). En avsluttet container er ikke det samme som et image, ettersom den kan startes på nytt og vil beholde innstillingene og eventuelle filsystemendringer.