🥇Mostantól Docker-képeket készíthet werf-ben egy szokásos Dockerfile

Jobb később, mint soha. Vagy hogy majdnem súlyos hibát követtünk el azzal, hogy nem támogattuk a rendszeres Docker-fájlokat az alkalmazásképek készítéséhez.

Majd megbeszéljük werf — GitOps segédprogram, amely bármely CI/CD rendszerrel integrálható, és biztosítja az alkalmazás teljes életciklusának kezelését, lehetővé téve:

képeket gyűjteni és közzétenni,
alkalmazások telepítése Kubernetesben,
törölje a nem használt képeket speciális házirendekkel.

A projekt filozófiája az, hogy az alacsony szintű eszközöket egyetlen egységes rendszerbe gyűjtsék össze, amely lehetővé teszi a DevOps mérnökeinek az alkalmazások irányítását. Ha lehetséges, a meglévő segédprogramokat (például a Helm és a Docker) kell használni. Ha egy problémára nincs megoldás, akkor ehhez mindent meg tudunk alkotni és támogatni.

Háttér: saját képgyűjtő

Ez történt a werf képgyűjtőjével: a szokásos Dockerfile nem volt elég nekünk. Ha egy gyors pillantást vetünk a projekt történetére, ez a probléma már a werf első verzióiban megjelent (akkor még dapp néven ismert).

Miközben létrehoztunk egy alkalmazást Docker-képekbe építő eszközt, hamar rájöttünk, hogy a Dockerfile nem alkalmas számunkra néhány nagyon specifikus feladatra:

Tipikus kis webalkalmazások létrehozásának szükségessége a következő szabványos séma szerint:
- rendszerszintű alkalmazásfüggőségek telepítése,
- telepítsen egy csomó alkalmazásfüggőségi könyvtárat,
- eszközöket gyűjteni,
- és ami a legfontosabb: gyorsan és hatékonyan frissítse a képen található kódot.
A projektfájlok módosításakor az építőnek gyorsan létre kell hoznia egy új fóliát a módosított fájlok javításával.
Ha bizonyos fájlok megváltoztak, akkor újra kell építeni a megfelelő függő szakaszt.

Ma gyűjtőnknek sok más lehetősége is van, de ezek voltak a kezdeti vágyak és késztetések.

Általánosságban elmondható, hogy kétszeri gondolkodás nélkül felvérteztük magunkat az általunk használt programozási nyelvvel (lásd lejjebb) és nekivág a megvalósításnak saját DSL! A céloknak megfelelően az összeállítási folyamat szakaszos leírása és ezeknek a szakaszoknak a fájloktól való függése volt a cél. És kiegészítette saját gyűjtő, amely a DSL-t a végső céllá - összerakott képpé - változtatta. Eleinte a DSL Rubyban volt, de mint átmenet Golangba - a gyűjtőnk konfigurációját elkezdték leírni egy YAML fájlban.

Régi konfig a dapp-hoz Rubyban

A werf jelenlegi konfigurációja a YAML-on

A kollektor mechanizmusa is változott az idők során. Először egyszerűen létrehoztunk egy ideiglenes Dockerfile-t a konfigurációnkból, majd elkezdtük az összeszerelési utasításokat ideiglenes tárolókban futtatni, és véglegesíteni.

NB: Jelen pillanatban a saját konfiggal működő (YAML-ben) gyűjtőnk, amelyet Stapel gyűjtőnek hívnak, már elég erős eszközzé fejlődött. Részletes leírása külön cikkeket érdemel, az alapvető részleteket pedig a dokumentáció.

A probléma tudatosítása

De rájöttünk, és nem azonnal, hogy elkövettünk egy hibát: nem adtuk hozzá a képességet képeket készíthet a szabványos Dockerfile segítségével és integrálja őket ugyanabba a végpontok közötti alkalmazáskezelési infrastruktúrába (azaz képek összegyűjtése, üzembe helyezése és tisztítása). Hogyan lehetne megvalósítani egy eszközt a Kubernetesben való telepítéshez és nem implementálni a Dockerfile támogatást, pl. szabványos módja a képek leírásának a legtöbb projekthez?

A kérdés megválaszolása helyett megoldást kínálunk. Mi a teendő, ha már van egy Dockerfile-ja (vagy egy Docker-fájlkészlete), és szeretné használni a werf-et?

NB: Egyébként miért akarod egyáltalán használni a werf-et? A főbb jellemzők a következők:

teljes alkalmazáskezelési ciklus, beleértve a képtisztítást;
több kép összeállításának egyszerre történő kezelése egyetlen konfigurációból;
Továbbfejlesztett telepítési folyamat a Helm-kompatibilis diagramokhoz.

Ezek teljesebb listája a címen található projekt oldala.

Tehát, ha korábban felajánlottuk volna, hogy átírjuk a Dockerfile-t a konfigurációnkban, most boldogan mondjuk majd: „Hagyja, hogy a werf megépítse a Docker-fájljait!”

Hogyan kell használni?

Ennek a funkciónak a teljes megvalósítása megjelent a kiadásban werf v1.0.3-beta.1. Az általános elv egyszerű: a felhasználó megadja egy létező Dockerfile elérési útját a werf konfigurációban, majd lefuttatja a parancsot. werf build... és ennyi – a werf összeállítja a képet. Nézzünk egy absztrakt példát.

Meghirdetjük a következőt Dockerfile a projekt gyökérben:

FROM ubuntu:18.04
RUN echo Building ...

És bejelentjük werf.yamlamely ezt használja Dockerfile:

configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile

Minden! Bal fuss werf build:

Ezen kívül kijelentheti a következőket werf.yaml több kép létrehozása különböző Docker-fájlokból egyszerre:

configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend

Végül támogatja további összeállítási paraméterek átadását is, mint pl --build-arg и --add-host - werf konfiguráción keresztül. A Dockerfile képkonfiguráció teljes leírása a következő címen érhető el dokumentációs oldal.

Hogyan működik?

Az összeállítási folyamat során a Docker helyi rétegeinek szabványos gyorsítótára működik. Azonban ami fontos, az a werf is integrálja a Dockerfile konfigurációt az infrastruktúrájába. Mit is jelent ez?

Minden Dockerfile-ból épített kép egy szakaszból áll, az úgynevezett dockerfile (További információkat olvashat arról, hogy milyen szakaszok vannak a werf-ben itt).
Színpadra dockerfile A werf egy aláírást számít ki, amely a Dockerfile konfiguráció tartalmától függ. Amikor a Dockerfile konfiguráció megváltozik, a szakasz aláírása megváltozik dockerfile és a werf elindítja ennek a szakasznak az újraépítését egy új Dockerfile konfigurációval. Ha az aláírás nem változik, akkor a werf kiveszi a képet a gyorsítótárból (Az aláírások werf-ben történő használatáról további részleteket a következő helyen írtunk le ez a jelentés).
Ezután az összegyűjtött képeket a paranccsal közzé lehet tenni werf publish (vagy werf build-and-publish), és használja a Kubernetes rendszerbe történő telepítéshez. A Docker Registry-ben közzétett képek megtisztítása szabványos werf tisztítóeszközökkel történik, pl. A rendszer automatikusan megtisztítja a régi képeket (N napnál régebbi), a nem létező Git-ágakhoz társított képeket és egyéb házirendeket.

Az itt leírt pontokról további részletek a dokumentációban találhatók:

Megjegyzések és óvintézkedések

1. A külső URL nem támogatott az ADD-ben

Jelenleg nem támogatott a külső URL használata egy direktívában ADD. A Werf nem kezdeményez újraépítést, ha a megadott URL-címen található erőforrás megváltozik. Terveink szerint hamarosan hozzáadjuk ezt a funkciót.

2. Nem adhat hozzá .git a képhez

Általában véve egy könyvtár hozzáadása .git a képen – egy rosszindulatú, rossz gyakorlat, és miért:

Ha .git a végső képen marad, ez sérti az elveket 12 faktoros kb: Mivel a végső képet egyetlen véglegesítéshez kell kapcsolni, ezt nem lehet megtenni git checkout önkényes elkövetés.
.git növeli a kép méretét (a tárhely nagy lehet, mivel egyszer nagy fájlokat adtak hozzá, majd törölték). A csak egy adott véglegesítéshez társított munkafa mérete nem függ a Gitben végzett műveletek előzményeitől. Ebben az esetben a hozzáadás és az azt követő eltávolítás .git a végső képből nem fog működni: a kép továbbra is kap egy extra réteget - a Docker így működik.
A Docker szükségtelen újraépítést kezdeményezhet, még akkor is, ha ugyanaz a commit készül, de különböző munkafákból. Például a GitLab külön klónozott könyvtárakat hoz létre /home/gitlab-runner/builds/HASH/[0-N]/yourproject ha a párhuzamos összeszerelés engedélyezve van. Az extra összeszerelés annak köszönhető, hogy a könyvtár .git különbözik ugyanannak a tárolónak a különböző klónozott verzióiban, még akkor is, ha ugyanaz a véglegesítés épül.

Az utolsó pont a werf használatakor is következményekkel jár. A Werf megköveteli, hogy a beépített gyorsítótár jelen legyen bizonyos parancsok futtatásakor (pl. werf deploy). Amikor ezek a parancsok futnak, a werf kiszámítja a szakasz aláírásait a következőben megadott képekhez werf.yaml, és az összeállítás gyorsítótárában kell lenniük - különben a parancs nem tud tovább működni. Ha a színpadi aláírás a tartalomtól függ .git, akkor olyan gyorsítótárat kapunk, amely instabil az irreleváns fájlok változásaihoz, és a werf nem fogja tudni megbocsátani egy ilyen mulasztást (további részletekért lásd dokumentáció).

Általában véve, csak bizonyos szükséges fájlokat ad hozzá az utasításokon keresztül ADD mindenesetre növeli az írás hatékonyságát és megbízhatóságát Dockerfile, és javítja az ehhez gyűjtött gyorsítótár stabilitását is Dockerfile, a Git irreleváns változásaihoz.

Teljes

A kezdeti utunk ahhoz, hogy konkrét igényekhez saját készítőt írjunk, nehéz, őszinte és egyértelmű volt: ahelyett, hogy a szabványos Dockerfile-on felül mankókat használtunk volna, egyedi szintaxissal írtuk meg a megoldásunkat. Ennek pedig megvoltak az előnyei: a Stapel kollektor tökéletesen megbirkózik a feladatával.

A saját builder megírása során azonban szem elől tévesztettük a meglévő Dockerfiles támogatását. Ezt a hibát kijavítottuk, és a jövőben tervezzük a Dockerfile-támogatás fejlesztését az egyedi Stapel builderünkkel együtt az elosztott összeszereléshez és a Kubernetes használatával történő összeszereléshez (vagyis a Kubernetesen belüli futókra való összeszereléshez, ahogyan a kaniko esetében is történik).

Szóval, ha hirtelen néhány Docker-fájl hever... megpróbál werf!

PS A témával kapcsolatos dokumentációk listája

Olvassa el blogunkban is: "werf - eszközünk CI / CD-hez Kubernetesben (áttekintés és videóriport)".

Forrás: will.com

Mostantól Docker-képeket készíthet a werf-ben egy normál Dockerfile használatával