Hoe om klein Docker-beelde outomaties vir u behoeftes te skep
Ongewone obsessie
Die afgelope paar maande was ek obsessief oor hoe klein 'n Docker-beeld kan wees en steeds die toepassing laat loop?
Ek verstaan, die idee is vreemd.
Voordat ek in die besonderhede en tegniese aspekte ingaan, wil ek graag verduidelik hoekom hierdie probleem my so gepla het, en hoe dit jou raak.
Hoekom grootte saak maak
Deur die inhoud van die Docker-beeld te verminder, verminder ons daardeur die lys van kwesbaarhede. Boonop maak ons die beelde skoner, want dit bevat net wat nodig is om toepassings te laat loop.
Daar is nog 'n klein voordeel - beelde word 'n bietjie vinniger afgelaai, maar na my mening is dit nie so belangrik nie.
Neem asseblief kennis: As jy bekommerd is oor grootte, is die Alpynse voorkoms self klein en sal dit waarskynlik jou pas.
Distroless beelde
bied 'n keuse van basiese "distroless" beelde, hulle bevat nie pakketbestuurders, skulpe en ander nutsprogramme wat jy gewoond is om op die opdragreël te sien nie. As gevolg hiervan, gebruik pakketbestuurders soos pip и apt sal nie werk nie:
FROM gcr.io/distroless/python3
RUN pip3 install numpyDockerfile met Python 3 distroless beeld
Sending build context to Docker daemon 2.048kB
Step 1/2 : FROM gcr.io/distroless/python3
---> 556d570d5c53
Step 2/2 : RUN pip3 install numpy
---> Running in dbfe5623f125
/bin/sh: 1: pip3: not foundPip is nie in die beeld nie
Gewoonlik word hierdie probleem opgelos deur 'n multi-stadium bou:
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-stadium samestelling
Die resultaat is 'n beeld van 130MB groot. Nie te sleg nie! Ter vergelyking: die standaard Python-beeld weeg 929MB, en die "dunner" een (3,7-slim) - 179MB, alpiene beeld (3,7-alpine) is 98,6 MB, terwyl die basis distroless beeld wat in die voorbeeld gebruik word, 50,9 MB is.
Dit is regverdig om daarop te wys dat ons in die vorige voorbeeld 'n hele gids kopieer /usr/local/lib/python3.7/site-packages, wat afhanklikhede kan bevat wat ons nie nodig het nie. Alhoewel dit duidelik is dat die grootteverskil van alle bestaande Python-basisbeelde verskil.
Met die skryf hiervan ondersteun Google distroless nie baie beelde nie: Java en Python is nog in die eksperimentele stadium, en Python bestaan net vir 2,7 en 3,5.
Klein beelde
Terug na my obsessie met die skep van klein beelde.
Oor die algemeen wou ek sien hoe distroless beelde gekonstrueer word. Die distroless projek gebruik Google se bou-instrument bazel. Die installering van Bazel en die skryf van jou eie beelde het egter baie werk gekos (en om eerlik te wees, om die wiel weer uit te vind is pret en opvoedkundig). Ek wou die skepping van kleiner beelde vereenvoudig: die daad om 'n beeld te skep moet uiters eenvoudig wees, banaal. Sodat daar geen konfigurasielêers vir jou is nie, net een reël in die konsole: просто собрать образ для <приложение>.
Dus, as jy jou eie beelde wil skep, weet dan: daar is so 'n unieke docker-beeld, scratch. Scratch is 'n "leë" prent, daar is geen lêers daarin nie, alhoewel dit by verstek weeg - wow! - 77 grepe.
FROM scratchKrap beeld
Die idee van 'n krapbeeld is dat jy enige afhanklikhede van die gasheermasjien daarin kan kopieer en dit óf binne 'n Dockerfile kan gebruik (dit is soos om dit na apt en installeer van nuuts af), of later wanneer die Docker-beeld gerealiseer is. Dit laat jou toe om die inhoud van die Docker-houer heeltemal te beheer, en dus die grootte van die prent heeltemal te beheer.
Nou moet ons op een of ander manier hierdie afhanklikhede versamel. Bestaande gereedskap soos apt laat jou toe om pakkette af te laai, maar hulle is gekoppel aan die huidige masjien en ondersteun immers nie Windows of MacOS nie.
Ek het dus my eie instrument gebou wat outomaties 'n basisbeeld van die kleinste moontlike grootte sou bou en ook enige toepassing sou laat loop. Ek het Ubuntu/Debian-pakkette gebruik, 'n keuse gemaak (om pakkette direk vanaf die bewaarplekke te kry) en rekursief hul afhanklikhede gevind. Die program was veronderstel om outomaties die nuutste stabiele weergawe van die pakket af te laai, om sekuriteitsrisiko's so veel as moontlik te verminder.
Ek het die instrument genoem fetchy, want hy... vind en bring... wat nodig is [uit Engels "haal", "bring" - ongeveer. baan]. Die instrument werk deur 'n opdragreël-koppelvlak, maar bied terselfdertyd 'n API.
Om 'n beeld saam te stel met behulp van fetchy (kom ons neem hierdie keer 'n Python-prent), jy hoef net die CLI so te gebruik: fetchy dockerize python. Jy kan gevra word vir die teiken bedryfstelsel en kodenaam omdat fetchy gebruik tans slegs pakkette gebaseer op Debian en Ubuntu.
Nou kan jy kies watter afhanklikhede glad nie nodig is nie (in ons konteks) en dit uitsluit. Python is byvoorbeeld afhanklik van perl, hoewel dit goed werk sonder dat Perl geïnstalleer is.
Bevindinge
Python-beeld geskep met die opdrag fetchy dockerize python3.5 weeg net 35MB (ek is meer as seker dat dit in die toekoms nog ligter gemaak kan word). Dit blyk dat ons daarin geslaag het om nog 15 WW van die distroless beeld af te skeer.
Jy kan al die beelde wat tot dusver versamel is, sien .
Projek - .
As jy kenmerke ontbreek, skep net 'n versoek - ek sal graag help :) Selfs meer, ek werk tans daaraan om ander pakketbestuurders in fetchy te integreer, sodat daar geen behoefte aan multi-stadium bouwerk is nie.
Bron: will.com