Når vi bruker Docker, starter vi med et basisbilde. Vi starter det opp, lager endringer, og disse endringene lagres i lag som danner et annet bilde.
Så til slutt har jeg et bilde for PostgreSQL-forekomsten min og et bilde for webapplikasjonen min, endringer som fortsetter å vedvare.
Hva er 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:
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.
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
<none> <none> 4ab0d9120985 3 months ago 486.5 MB
Noen ting å merke seg:
-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
.[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
.seneste
taggen er ikke magisk, det er ganske enkelt standardtaggen når du ikke spesifiserer en tagg.<none>
TAG og REPOSITORY. Det er lett å glemme dem.Mer informasjon om bilder finnes i Docker-dokumentasjonen og ordlisten.
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:
docker ps
gir bare ut running containere. Du kan se alle containere (running eller stopped) med docker ps -a
.--name
flagget.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:
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.