De tanende ster van Docker

Dit artikel verscheen oorspronkelijk in het Engels in december 2020 op rlvs.eu.

Het Kleenex-effect

In januari 2014 werd ik uitgenodigd in Finland om een lezing en workshop over softwarecontainers te geven.
Het concept van softwarecontainers was toen nog vrij nieuw, dus de aandacht van het publiek trekken was niet zo moeilijk. Het was in elk geval makkelijker dan wakker worden de dag erna: Team België had zijn dorst misschien wat overschat.

Docker was nog niet erg volwassen en zat nog in de 0.x-releasereeks, maar had al de verdienste dat het het containerconcept naar het grote publiek bracht.
Goede documentatie, een degelijke CLI, sterke partnerschappen en slimme marketing waren de ingrediënten van het succesverhaal.

Mijn taak om dingen uit te leggen was eenvoudig: er was Docker, Docker en Docker, en alleen als je echt dieper wilde graven, moest je ook vertellen dat het gebouwd was op LXC.
Dat laatste was maar tijdelijk: een jaar later ruilde Docker LXC in voor een eigen onderliggende runtime (libcontainer) (v0.9).

Sindsdien veroverde Docker de wereld van de softwarecontainers. Concurrenten (Mesos, rkt, ..) bleven met hun eigen implementaties achter met enkel wat kruimels, en ze stonden altijd een beetje in de schaduw van Moby, de dikke blauwe walvis.
In die jaren begon Docker het ‘Kleenex’-effect te vertonen: het merk werd het product.

Een van de grote verwezenlijkingen van de Docker-ploeg was dat ze mee een standaard pakketformaat en runtime voor containers opzetten binnen het Open Container Initiative. Ze schonken in feite hun low-level runtime libcontainer (hernoemd tot runc) en hun imageformaat (hernoemd tot OCI image).

Hoewel het belang van die zet niet te overschatten is, was het ook het begin van het einde van de suprematie van Docker.

De koning is dood, leve de koning!

Houston, we hebben een standaard

Met die standaarden op hun plaats hadden concurrerende producten een probleem minder in hun strijd om relevant te blijven. Het resultaat is een bruisend ecosysteem waarin bijna wekelijks nieuwe spelers en initiatieven aangekondigd worden. Kijk maar eens naar het cloud native landscape om te begrijpen wat ik bedoel..

Red Hat doet bijvoorbeeld hard zijn best om zijn eigen high-level runtime overal ingang te doen vinden. Podman is nu de standaardmanier om een container uit te rollen in RHEL8 en Openshift 4. Het gebruikt hetzelfde gestandaardiseerde OCI-imageformaat en dezelfde OCI low-level runtime (runc), maar probeert ons sysadmins met nieuwe high-level runtime-implementaties te verlossen van enkele serieuze beperkingen van Docker:

Met Podman (en Buildah):

kunnen dezelfde ‘Docker’-images gebruikt worden, omdat het imageformaat en de low-level runtime ongewijzigd en OCI-conform zijn
is er geen centrale daemon: containerd is niet langer een single point of failure op de containerhost
zijn rootless containers mogelijk, wat het aanvalsoppervlak verkleint

De nieuwe realiteit

Docker werd ook bekend omdat het de welbekende container registry host: https://hub.docker.com.

Maar de reputatie van die publieke repository en de facto plek om officiële containers te zoeken, taant. De beslissing om vorige maand rate limiting in te voeren zal sommige gebruikers zeker frustreren.
Uiteindelijk wordt de limiet voor gratis accounts 100 pulls per zes uur. Dat meten ze aan de hand van je publieke IP-adres. Hoewel dat op het eerste gezicht redelijk lijkt: als je NAT gebruikt, kunnen je collega’s per ongeluk CI/CD-pipelines achter hetzelfde publieke IP-adres doen falen, gewoon omdat hun docker pull-opdrachten meetellen voor dezelfde teller. Amper een dag na die aankondiging kondigden verschillende grote spelers al hun alternatief aan.

Is dit de volgende stap naar het eindspel van Docker Inc? Nu ze hun containerbeheerplatform (Swarm) opgegeven hebben, hun enterprise-afdeling verkocht hebben, overbodig geworden zijn als runtime (zoals in dit artikel uitgelegd) en het gratis gebruik van hun registry beperkt hebben, zullen concurrenten de gaten maar al te graag opvullen.

Een paar weken geleden kwam ook het nieuws dat Kubernetes vanaf versie 1.20 Docker niet langer als standaard high-level container runtime gebruikt. Omdat dat geen wissel van de low-level runtime inhoudt, hoef je je daar waarschijnlijk geen zorgen over te maken.
Maar dat wist je al, want je hebt net deze post gelezen. ;-)

Bronnen: