Wanneer we Docker gebruiken, beginnen we met een basis image. We starten het op, maken wijzigingen en die wijzigingen worden opgeslagen in lagen die een ander image vormen.
Dus uiteindelijk heb ik een image voor mijn PostgreSQL instance en een image voor mijn webapplicatie, waarvan de wijzigingen steeds worden doorgevoerd.
Wat is een container?
Een instantie van een image wordt een container genoemd. Je hebt een image, wat een set van lagen is zoals je beschrijft. Als je dit image start, heb je een draaiende container van dit image. Je kunt veel draaiende containers van hetzelfde image hebben.
Je kunt al je images zien met docker images
terwijl je je lopende containers kunt zien met docker ps
(en je kunt alle containers zien met docker ps -a
).
Dus een draaiende instantie van een image is een container.
Uit mijn artikel over Automating Docker Deployments:
In Dockerland zijn er images en er zijn containers. De twee zijn nauw verwant, maar toch verschillend. Voor mij heeft het begrijpen van deze dichotomie Docker enorm verduidelijkt.
Een image is een inert, onveranderlijk, bestand dat's in wezen een momentopname van een container. Images worden gemaakt met het build commando, en ze'zullen een container produceren wanneer ze gestart worden met run. Images worden opgeslagen in een Docker-register zoals registry.hub.docker.com. Omdat ze vrij groot kunnen worden, zijn images ontworpen om te worden samengesteld uit lagen van andere images, waardoor een minimale hoeveelheid gegevens kan worden verzonden bij het overbrengen van images via het netwerk.
Lokale images kunnen worden opgesomd door docker images
uit te voeren:
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
Enkele dingen om op te merken:
-t
vlag van het docker build
commando, of van docker tag
-ing van een bestaande image. Het staat je vrij om images te taggen met een nomenclatuur die voor jou logisch is, maar weet dat docker de tag zal gebruiken als de registerlocatie in een docker push
of docker pull
.[REGISTRYHOST/][USERNAME/]NAAM[:TAG]
. Voor ubuntu
hierboven, wordt REGISTRYHOST afgeleid als registry.hub.docker.com
. Dus als je van plan bent om je image genaamd mijn-applicatie
op te slaan in een register op docker.example.com
, moet je die image docker.example.com/mijn-applicatie
taggen.latest
tag is niet magisch, het'is gewoon de standaard tag wanneer je'geen tag specificeert.<none>
TAG en REPOSITORY krijgen. Het's gemakkelijk om ze te vergeten.Meer informatie over images is beschikbaar in de Docker documentatie en glossarium.
Om een programmeermetafoor te gebruiken, als een image een klasse is, dan is een container een instantie van een klasse-een runtime object. Containers zijn hopelijk waarom je'Docker gebruikt; ze'zijn lichtgewicht en draagbare inkapselingen van een omgeving waarin toepassingen kunnen draaien.
Bekijk lokaal draaiende containers met 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
Hier draai ik een gedockeriseerde versie van het docker register, zodat ik een private plaats heb om mijn images op te slaan. Nogmaals, een paar dingen om op te merken:
docker ps
geeft alleen running containers weer. Je kunt alle containers (running or stopped) bekijken met docker ps -a
.--name
vlag.Een van mijn vroege frustraties met Docker was de schijnbaar constante opbouw van niet-gemerkte images en gestopte containers. In een handvol gevallen resulteerde deze opbouw in uitgeputte harde schijven die mijn laptop vertraagden of mijn geautomatiseerde bouwpijplijn stopzetten. Over "containers everywhere" gesproken!
We kunnen alle untagged images verwijderen door docker rmi
te combineren met de recente dangling=true
query:
docker images -q --filter "dangling=true" | xargs docker rmi
Docker zal niet in staat zijn om images te verwijderen die zich achter bestaande containers bevinden, dus het kan zijn dat je eerst gestopte containers moet verwijderen met docker rm
:
docker rm `docker ps --no-trunc -aq`
Dit zijn bekende pijnpunten met Docker en kunnen worden aangepakt in toekomstige releases. Echter, met een duidelijk begrip van images en containers, kunnen deze situaties worden vermeden met een paar praktijken:
docker rm [CONTAINER_ID]
.docker rmi [IMAGE_ID]
.Hoewel het het eenvoudigst is om aan een container te denken als een draaiende image, is dit niet helemaal juist.
Een image is eigenlijk een sjabloon dat in een container kan worden veranderd. Om van een image een container te maken, neemt de Docker engine de image, voegt er een read-write bestandssysteem aan toe en initialiseert verschillende instellingen, waaronder netwerkpoorten, containernaam, ID en limieten voor resources. Een draaiende container heeft een momenteel uitvoerend proces, maar een container kan ook worden gestopt (of exited in Docker's terminologie). Een verlaten container is niet hetzelfde als een image, omdat het opnieuw kan worden opgestart en zijn instellingen en eventuele bestandssysteemwijzigingen zal behouden.