Wat is Containerimage?

Een alleen-lezen sjabloon waaruit containers worden gemaakt. Het stapelt de bestanden van een applicatie, zoals uitvoerbare bestanden, bibliotheken en instellingen, in lagen en voegt configuratie toe zoals de opdracht die bij het starten wordt uitgevoerd; het bevat geen kernel van een besturingssysteem. Images worden gebouwd uit een Dockerfile of iets vergelijkbaars en via registries opgeslagen en verspreid. Een image wordt aangeduid met de naam van de repository en een tag (bijvoorbeeld web:1.4), of eenduidig met een digest die uit de inhoud wordt berekend (sha256:…). Identieke lagen worden tussen images gedeeld.

Japanse benaming: コンテナイメージ

“Containerimage” komt voor in 3 oefenvragen uit 1 onderwerpen, bijv. Basis van cloud en containers.

Vakgebied: Basis van cloud en containers

Hoe lagen werken

Elke instructie in een Dockerfile die bestanden wijzigt (RUN, COPY enz.), wordt één laag. Lagen worden geïdentificeerd door een digest die uit hun inhoud wordt berekend; images die op hetzelfde basisimage zijn gebouwd, delen die laag dus en downloaden en bewaren haar maar één keer. Het verwijderen van een bestand in een latere laag laat de inhoud van de eerdere laag in het image staan; grote tijdelijke bestanden worden daarom binnen dezelfde instructie verwijderd of met een multi-stage build buiten het uiteindelijke image gehouden.

Tags en digests

Een tag, zoals latest of web:1.4, is een naam die mensen geven en kan later naar een ander image worden verplaatst. Een digest wordt uit de inhoud van het image berekend en verandert als ook maar één bit anders is. In productie, of overal waar precies moet worden gebruikt wat getest is, worden images met hun digest aangeduid.

Kleine en veilige images maken

Compilers en pakketbeheerders die tijdens de uitvoering niet nodig zijn, weglaten maakt images kleiner, sneller te halen en minder blootgesteld aan kwetsbaarheden. Een gangbare methode is een multi-stage build die een buildstage scheidt van een stage voor de uitvoering. Geheimen worden niet in images gezet, maar bij het starten doorgegeven.

Nu oefenen: vragen over Containerimage

Welke beschrijving van de relatie tussen een containerimage en een container is juist?

AAls een container wordt gestopt, worden de wijzigingen in de container automatisch naar het image teruggeschreven en wordt het oorspronkelijke image overschreven
BEen image is een alleen-lezen sjabloon, en uit één image kunnen meerdere containers worden gestart die elk een eigen beschrijfbare laag hebben
CUit een image kan tegelijk maar één container worden gestart; voor een tweede container moet het image eerst onder een andere naam worden gekopieerd

Antwoord en toelichting tonen

Antwoord: B. Een image is een alleen-lezen sjabloon, en uit één image kunnen meerdere containers worden gestart die elk een eigen beschrijfbare laag hebben

Een image is een alleen-lezen sjabloon waarin de bestanden en instellingen voor het uitvoeren van een applicatie zijn gebundeld, en een container is een uitvoeringseenheid die uit een image wordt gemaakt. Bij het maken van een container wordt een eigen beschrijfbare laag (layer) boven op de lagen van het image gestapeld. Uit één image kunnen dus veel containers worden gestart, en wijzigingen in de ene container hebben geen invloed op de andere containers of op het image. Om een wijziging als deel van een image te bewaren, past men gewoonlijk het Dockerfile aan en bouwt men het image opnieuw.

In een Kubernetes-Deployment wordt het containerimage in de Pod-template veranderd in een nieuwe versie. Welke beschrijving van wat er gebeurt met de standaardupdatestrategie (RollingUpdate) is juist?

AEr wordt een nieuwe ReplicaSet gemaakt, en Pods van de nieuwe versie worden toegevoegd terwijl Pods van de oude versie worden verwijderd. De oude ReplicaSet blijft met 0 Pods bestaan voor een rollback
BHet containerimage in de draaiende Pods wordt ter plaatse door de nieuwe versie vervangen zonder de Pods opnieuw te maken; de IP-adressen en de namen van de Pods veranderen dus niet
CAlle Pods van de oude versie worden in één keer verwijderd en daarna worden de Pods van de nieuwe versie samen gemaakt; de dienst staat dus tijdens de update tijdelijk stil

Antwoord en toelichting tonen

Antwoord: A. Er wordt een nieuwe ReplicaSet gemaakt, en Pods van de nieuwe versie worden toegevoegd terwijl Pods van de oude versie worden verwijderd. De oude ReplicaSet blijft met 0 Pods bestaan voor een rollback

Als de Pod-template verandert, maakt een Deployment een ReplicaSet voor de nieuwe template en vermindert het, terwijl het nagaat dat nieuwe Pods gereed zijn, geleidelijk de Pods van de oude ReplicaSet. Een bepaald aantal Pods blijft dus tijdens de update aanvragen verwerken. De oude ReplicaSet wordt met 0 Pods bewaard, zodat kubectl rollout undo naar de vorige versie kan terugkeren. De strategie die eerst alle Pods verwijdert en ze dan opnieuw maakt, is Recreate; die wordt alleen gebruikt als ze expliciet wordt opgegeven.

Veelgestelde vragen

Wat is het verschil tussen een image en een container?

Een image is een alleen-lezen sjabloon, en een container is een draaiende (of gestopte) instantie die daaruit is gemaakt. Uit één image kunnen veel containers worden gemaakt, die elk een eigen beschrijfbare laag krijgen. Het lijkt op de relatie tussen een programmabestand en een proces.

Levert de tag latest altijd de nieuwste versie?

latest is een gewone tag zonder bijzondere betekenis. Het is alleen de standaardnaam die wordt gebruikt als er geen tag wordt opgegeven, en hij wijst niet naar een nieuwe versie tenzij iemand hem verplaatst. Om een versie vast te leggen, geeft men een concrete tag of een digest op.

Vragen met “Containerimage” (3)

Verwante termen

Container Kubernetes Pod CI/CD (continuous integration en continuous delivery) Omgevingsvariabele (environment variable) Autoscaling Beschikbaarheidszone (availability zone) Blue-green deployment Canary release Docker

Naar de woordenlijst