🥇Kubernetes 1.16: a fő újdonságok áttekintése | ProHoster

[utalás az amerikai gyermekmese «Kicsi gőzös, aki hitt magában» («The Little Engine That Could») — a fordító megj.]

Hogyan készítsünk automatikusan apró docker-képeket a saját igényeinkhez

Szokatlan megszállottság

Az elmúlt néhány hónapban megszállottan foglalkoztam a gondolattal: milyen mértékben lehet csökkenteni egy Docker-képet, miközben a alkalmazás működik?

Megértem, hogy a gondolat furcsa.

Mielőtt belemerülnék a részletekbe és a technikai nehézségekbe, szeretném megmagyarázni, miért ragadott meg engem ez a probléma, és hogyan érinthet titeket.

Miért fontos a méret

A Docker-kép tartalmának csökkentésével egyben a sebezhetőségek listáját is csökkentjük. Ezen kívül tisztábbá tesszük a képeket, hiszen csak az szükséges elemeket tartalmazzák az alkalmazások futtatásához.

Van egy apró előnye is — a képek egy kicsit gyorsabban tölthetők le, de szerintem ez nem annyira fontos.

Figyelem: Ha aggódsz a méret miatt, az Alpine képek önállóan kicsik, és biztosan megfelelnek neked.

Distroless képek

A Distroless projekt ajánl egy gyűjteményt az alap «distroless» képekből, amelyek nem tartalmaznak csomagkezelőket, shell-eket és egyéb segédprogramokat, amelyeket a parancssorban megszoktál látni. Ennek következtében nem használhatsz csomagkezelőket, mint például pip és apt nem lesz lehetséges:

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

Dockerfile, amely distroless Python 3 képet használ

A build kontextusának küldése a Docker démonnak  2.048kB
1. lépés/2: FROM gcr.io/distroless/python3
 ---> 556d570d5c53
2. lépés/2: RUN  pip3 install numpy
 ---> Futtatás dbfe5623f125-ön
/bin/sh: 1: pip3: nem található

A pip nincs a képen

Általában ezt a problémát többlépcsős builddel oldják meg:

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/

Többlépcsős build

Így egy 130MB-os képet kapunk. Nem is rossz! Összehasonlításképpen: az alapértelmezett Python kép 929MB, míg a «lesoványított» (3.7-slim) — 179MB, az Alpine (3.7-alpine) — 98,6MB, míg az általunk használt alap distroless kép 50,9MB.

Jogos felvetni, hogy az előző példában egy egész könyvtárat másolunk le /usr/local/lib/python3.7/site-packages, ahol felesleges függőségek is lehetnek. Bár világos, hogy a Python összes létező alap képének méretei változóak.

E sorok írásakor a Google distroless nem támogat túl sok képet: a Java és a Python még kísérleti szakaszban van, a Python pedig csak a 2.7 és 3.5 számára létezik.

Apró képek

Visszatérve a kis képek létrehozására vonatkozó megszállottságomra.

Valójában azt akartam megnézni, hogyan is épülnek a distroless képek. A distroless projekt a Google építőeszközét használja bazel. Azonban, hogy telepíthessem a Bazelt és megírhassam a saját képeimet, meg kellett izzadnom (ha teljesen őszinte akarok lenni, akkor a kereket újra feltalálni — ez szórakoztató és tanulságos). Szerettem volna egyszerűsíteni a csökkentett képek létrehozását: a kép létrehozásának aktusának a lehető legegyszerűbbnek kell lennie, banálisnak. Nincs szükség konfigurációs fájlokra, csak egy sor a konzolon: egyszerűen építse meg a képet a <alkalmazás> számára.

Tehát, ha saját képeket szeretne létrehozni, tudja: létezik egy ilyen egyedi docker kép, scratch. A Scratch egy "üres" kép, nincs benne fájl, bár alapértelmezetten — wow! — 77 bájt.

FROM scratch

A scratch kép

A scratch kép lényege, hogy bármilyen függőséget átmásolhatunk a gazdagépről, és vagy használhatjuk őket a Dockerfile-ban (ez olyan, mint átmásolni őket apt és nulláról telepíteni), vagy később, amikor a Docker kép konkrétá válik. Ez lehetővé teszi a Docker konténer tartalmának teljes ellenőrzését, ezáltal pedig a kép méretének teljes ellenőrzését is.

Most pedig valahogyan össze kellene állítanunk ezeket a függőségeket. A meglévő eszközök, mint például apt lehetővé teszik a csomagok letöltését, de ezek az aktuális géphez vannak kötve, és végül nem támogatják a Windows-t vagy a MacOS-t.

Így hát belevágtam egy saját eszköz fejlesztésébe, amely automatikusan építene egy alap képet a lehető legkisebb méretben, és még bármilyen alkalmazást is futtatna. Ubuntu/Debian csomagokat használtam, lekértem a csomagokat közvetlenül a repozitóriumokból, és rekurzívan kerestem a függőségeiket. A programnak automatikusan le kellett töltenie a legújabb stabil verziót a csomagból, minimalizálva a biztonsági kockázatokat.

Az eszközt fetchy-nak, mert… megtalálja és hozza… amire szükség van [az angol 'fetch', 'hozni' szóból — a fordító megjegyzése.]. Az eszköz parancssori felületen keresztül működik, de API-t is kínál.

Ahhoz, hogy képet építhessen a fetchy-nak (most vegyük a Python képet), csak ezt a CLI-t használja így: fetchy dockerize python. Kérheti, hogy adja meg a céleszköz operációs rendszerét és kódnevét, mivel fetchy-nak jelenleg csak Debian és Ubuntu alapú csomagokat használ.

Most már lehet választani, hogy mely függőségek teljesen szükségtelenek (a mi kontextusunkban), és kizárni őket. Például a Python a perl-től függ, bár tökéletesen működik Perl telepítése nélkül.

Eredmények

A Python image, amelyet a parancs segítségével hoztak létre fetchy dockerize python3.5 mindössze 35MB (több mint biztos vagyok benne, hogy a jövőben még tovább csökkenthető). Így a distroless image-ből sikerült 15MB-ot "lefaragni".

Minden eddig összegyűjtött image-t meg lehet nézni itt.

Projekt — itt.

Ha hiányzik valami funkció, egyszerűen küldje el a kérését — örömmel segítek 🙂 Sőt, jelenleg dolgozom más csomagkezelők integrálásán a fetchy-be, hogy elkerülhetőek legyenek a több lépéses build-ek.

Forrás: habr.com