Små Docker-billeder, der troede på sig selv*

[henvisning til den amerikanske børnefortælling "Den lille lokomotiv, der kunne" — overs.]*

Hvordan man automatisk skaber små docker-billeder til sine behov

Usædvanlig besættelse

De sidste par måneder har jeg været besat af en tankegang: hvor meget kan man reducere et Docker-billede, så applikationen stadig fungerer?

Jeg forstår, at ideen er underlig.

Før vi dykker ind i detaljerne og tekniske områder, vil jeg gerne forklare, hvorfor dette problem fangede mig så meget, og hvordan det vedrører dig.

Hvorfor størrelse betyder noget

Ved at reducere indholdet af Docker-billedet reducerer vi samtidig listen over sårbarheder. Derudover gør vi billederne renere, da de kun indeholder det, der er nødvendigt for at køre applikationer.

Der er også en lille fordel — billederne downloades lidt hurtigere, men for mig er det ikke så vigtigt.

Bemærk: Hvis du er bekymret for størrelsen, er Alpine-billederne selv små og sikkert vil være velegnede til dig.

Distroless-billeder

Distroless-projektet tilbyder en samling af grundlæggende "distroless"-billeder, som ikke indeholder pakkestyringssystemer, skaller og andre værktøjer, som du er vant til at se i kommandolinjen. Derfor kan man ikke bruge pakkestyringssystemer som pip og apt ikke kan anvendes:

FROM gcr.io/distroless/python3
RUN  pip3 install numpy

Dockerfile, der bruger distroless-billede Python 3

Sender byggekontext til Docker-daemon  2.048kB
Trin 1/2 : FROM gcr.io/distroless/python3
 ---> 556d570d5c53
Trin 2/2 : RUN  pip3 install numpy
 ---> Kører i dbfe5623f125
/bin/sh: 1: pip3: ikke fundet

Pip er ikke til stede i billedet

Normalt løses et sådant problem ved hjælp af multi-trin byggeri:

FROM python:3 as builder
RUN  pip3 install numpy

FROM gcr.io/distroless/python3
COPY --from=builder /usr/local/lib/python3.7/site-packages /usr/local/lib/python3.5/

Multi-trins byggeri

Resultatet er et billede på 130MB. Ikke så dårligt! Til sammenligning vejer standard Python-billedet 929MB, og det "slankede" (3,7-slim) — 179MB, Alpine-billedet (3,7-alpine) — 98,6MB, mens det basis distroless-billede, der blev brugt i eksemplet, er 50,9MB.

Man kan med rette påpege, at i det tidligere eksempel kopierer vi et helt katalog /usr/local/lib/python3.7/site-packages, som kan indeholde unødvendige afhængigheder for os. Selvom det er klart, at størrelsesforskellene mellem alle eksisterende basisbilleder for Python varierer.

På tidspunktet for skrivningen understøtter Google distroless ikke så mange billeder: Java og Python — stadig i eksperimentelle stadier, og Python eksisterer kun for 2,7 og 3,5.

Små billeder

Lad os vende tilbage til min besættelse af at lave små billeder.

Generelt ville jeg se, hvordan distroless-billeder er opbygget. Distroless-projektet bruger Googles build-værktøj bazel. Men for at installere Bazel og skrive mine egne billeder måtte jeg arbejde hårdt (og for at være helt ærlig, opfinde hjulet igen — det er sjovt og lærerigt). Jeg ønskede at forenkle oprettelsen af reducerede billeder: handlingen ved at oprette et billede skal være så simpel som muligt, banal. Så der skal ikke være nogen konfigurationsfiler, kun én linje i konsollen: bare byg et billede for <applikation>.

Så, hvis du ønsker at oprette dine egne billeder, så ved: der findes et unikt docker-billede, scratch. Scratch er et "tomt" billede, der ikke indeholder filer, selvom det vejer som standard — wow! — 77 byte.

FROM scratch

Scratch-billedet

Idéen med scratch-billedet er, at man kan kopiere enhver afhængighed fra værtsmaskinen ind i det og enten bruge dem i Dockerfile (det er ligesom at kopiere dem ind i apt og installere fra bunden), eller senere, når Docker-billedet er materialiseret. Dette giver fuld kontrol over indholdet af Docker-containeren, og dermed også over billedets størrelse.

Og nu skal vi finde en måde at samle disse afhængigheder på. Eksisterende værktøjer som apt giver mulighed for at downloade pakker, men de er bundet til den nuværende maskine og understøtter i sidste ende ikke Windows eller MacOS.

Så jeg satte mig for at opbygge mit eget værktøj, som automatisk ville samle et grundlæggende billede af den mindst mulige størrelse og stadig kunne køre enhver applikation. Jeg brugte pakker fra Ubuntu/Debian, udarbejdede en liste (hentede pakker lige fra repositorier) og fandt deres afhængigheder rekursivt. Programmet skulle automatisk downloade den nyeste stabile version af pakken for at minimere sikkerhedsrisici.

Jeg kaldte værktøjet fetchy, fordi det… finder og bringer… hvad der er nødvendigt [fra engelsk "fetch", "at bringe" — overs. anm.]. Værktøjet fungerer gennem kommandolinjeinterfacet, men tilbyder samtidig også en API.

For at kunne samle et billede ved hjælp af fetchy (denne gang tager vi Python-billedet), skal du blot bruge CLI som dette: fetchy dockerize python. Du kan blive bedt om at angive det målrettede operativsystem og kodenavn, da fetchy indtil videre kun bruger Debian- og Ubuntu-baserede pakker.

Nu kan du vælge, hvilke afhængigheder der slet ikke er nødvendige (i vores kontekst), og udelukke dem. For eksempel afhænger Python af Perl, selvom det fungerer fint uden installeret Perl.

Resultater

Python-billedet, der er oprettet med kommandoen fetchy dockerize python3.5 vejer kun 35MB (jeg er mere end sikker på, at det i fremtiden kan gøres endnu lettere). Det viser sig, at vi har "skåret" yderligere 15MB fra distroless-billedet.

Du kan se alle de indsamlede billeder indtil videre her.

Projektet — her.

Hvis du mangler funktioner, så lav en anmodning — jeg vil gerne hjælpe 🙂 Endda mere, jeg arbejder i øjeblikket på at integrere andre pakkemanagere i fetchy, så behovet for trinvise opbygninger forsvinder.

Kilde: habr.com