Små Docker-images som trodde på sig själva*

[referens till den amerikanska barnhistorien 'Den lilla lokomotiv som kunde' ('The Little Engine That Could') — övers.]*

Hur man automatiskt skapar små Docker-images för sina behov

En ovanlig besatthet

De senaste månaderna har jag varit besatt av en idé: hur mycket kan man minska en Docker-image så att applikationen fortfarande fungerar?

Jag förstår, idén är konstig.

Innan jag går in på detaljer och tekniska avvikelser vill jag förklara varför detta problem fascinerar mig så mycket och hur det berör dig.

Varför storlek spelar roll

Genom att minska innehållet i Docker-imagen minskar vi listan över sårbarheter. Dessutom gör vi bilderna renare, eftersom de endast innehåller det som behövs för att köra applikationerna.

Det finns ytterligare en liten fördel — bilderna laddas ner lite snabbare, men personligen tycker jag att det inte är så viktigt.

Observera: Om du är bekymrad över storleken är Alpine-images små i sig själva och passar säkerligen för dig.

Distroless-images

Distroless-projektet erbjuder en uppsättning grundläggande 'distroless'-bilder, de innehåller inga paketchefer, skal eller andra verktyg som du är van vid att se i kommandoraden. Som ett resultat går det inte att använda paketchefer såsom pip och apt inte möjligt:

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

Dockerfile som använder distroless-image Python 3

Skickar byggkontext till Docker-daemon 2.048kB
Steg 1/2: FROM gcr.io/distroless/python3
 ---> 556d570d5c53
Steg 2/2: RUN pip3 install numpy
 ---> Kör i dbfe5623f125
/bin/sh: 1: pip3: hittades inte

Pip finns inte i imagen

Vanligtvis löses detta problem genom flertränad byggnad:

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/

Flertränad byggnad

Resultatet är en bild som väger 130MB. Inte så illa! Jämfört med: standard Python-image väger 929MB, och 'slimmade' (3.7-slim) — 179MB, Alpine-image (3.7-alpine) — 98.6MB, medan den grundläggande distroless-imagen som används i exemplet väger 50.9MB.

Man kan med rätta påpeka att i det föregående exemplet kopierar vi en hel katalog /usr/local/lib/python3.7/site-packages, där onödiga beroenden kan finnas. Även om det är uppenbart att storleksskillnaden mellan alla existerande grundläggande Python-images varierar.

Vid tidpunkten för dessa rader stödjer Google distroless inte så många images: Java och Python är fortfarande i experimentfas och Python finns endast för 2.7 och 3.5.

Små bilder

Låt oss återgå till min besatthet av att skapa små bilder.

Jag ville egentligen se hur distroless-bilder fungerar. Distroless-projektet använder Googles byggverktyg bazel. Men för att installera Bazel och skriva egna bilder fick jag kämpa (och om jag ska vara helt ärlig, så var det som att återuppfinna hjulet — vilket var både roligt och lärorikt). Jag ville förenkla skapandet av nedskurna bilder: skapandet av en bild borde vara så enkelt som möjligt, banalt. Så inga konfigurationsfiler, bara en rad i konsolen: bara skapa en bild för.

Så om du vill skapa egna bilder, så vet att det finns en unik docker-bild, scratch. Scratch är en "tom" bild, den innehåller inga filer, även om den väger — oho! — 77 byte som standard.

FROM scratch

Scratch-bilden

Idén med scratch-bilden är att du kan kopiera in alla beroenden från värdmaskinen och antingen använda dem i Dockerfile (det är som att kopiera dem in i apt och installera dem från grunden), eller senare, när Docker-bilden har skapats. Detta gör att du har fullständig kontroll över innehållet i Docker-behållaren och sålunda också över bildens storlek.

Nu behöver vi på något sätt samla dessa beroenden. Befintliga verktyg som apt tillåter nedladdning av paket, men de är bundna till den aktuella maskinen och stöder inte Windows eller MacOS.

Och så började jag skapa mitt eget verktyg som automatiskt skulle samla in en grundläggande bild av minsta möjliga storlek som fortfarande skulle kunna köra valfritt program. Jag använde Ubuntu/Debian-paket, gjorde urval (genom att hämta paket direkt från arkiven) och hittade deras beroenden rekursivt. Programmet skulle automatiskt ladda ner den senaste stabila versionen av paketet, vilket minimerade säkerhetsriskerna.

Jag kallade verktyget fetchy, eftersom det... hittar och hämtar... vad som behövs [från engelska "fetch", "hämta" — anm. övers.]. Verktyget fungerar via kommandoradsgränssnitt, men erbjuder också ett API.

För att skapa en bild med hjälp av fetchy (denna gång tar vi Python-bilden), behöver du bara använda CLI så här: fetchy dockerize python. Du kan bli ombedd att ange målsystem och kodnamn, eftersom fetchy just nu använder bara paket baserade på Debian och Ubuntu.

Nu kan du välja vilka beroenden som inte alls behövs (i vårt sammanhang) och utesluta dem. Till exempel, Python är beroende av Perl, men fungerar utmärkt utan installerad Perl.

Resultat

Python-avbildningen som skapades med kommandot fetchy dockerize python3.5 väger endast 35 MB (jag är mer än säker på att den i framtiden kan göras ännu lättare). Således lyckades vi "skära av" ytterligare 15 MB från distroless-avbildningen.

Du kan se alla avbildningar som har samlats in hittills här.

Projektet — ). Ett typiskt exempel på användning:.

Om du saknar funktioner, skapa bara en begäran — jag hjälper gärna till 🙂 Dessutom arbetar jag för närvarande med att integrera andra paketförvaltare i fetchy, så att behovet av flertrinsbyggen försvinner.

Källa: habr.com