Lepšie neskôr ako nikdy. Alebo ako sme takmer urobili vážnu chybu, keď sme nemali podporu pre bežné súbory Dockerfiles na vytváranie obrázkov aplikácií.
Porozprávame sa o — Nástroj GitOps, ktorý sa integruje s akýmkoľvek systémom CI/CD a poskytuje správu celého životného cyklu aplikácie, čo umožňuje:
- zbierať a publikovať obrázky,
- nasadzovať aplikácie v Kubernetes,
- odstrániť nepoužívané obrázky pomocou špeciálnych zásad.
Filozofiou projektu je zhromaždiť nízkoúrovňové nástroje do jedného jednotného systému, ktorý dáva inžinierom DevOps kontrolu nad aplikáciami. Ak je to možné, mali by sa použiť existujúce nástroje (ako Helm a Docker). Ak neexistuje riešenie problému, vieme vytvoriť a podporiť všetko potrebné na to.
Pozadie: váš vlastný zberateľ obrázkov
Toto sa stalo so zberateľom obrázkov vo werf: obvyklý súbor Dockerfile nám nestačil. Ak sa rýchlo pozriete do histórie projektu, tento problém sa objavil už v prvých verziách werf (vtedy ešte ).
Pri vytváraní nástroja na vytváranie aplikácií do obrazov Docker sme rýchlo zistili, že Dockerfile pre nás nie je vhodný na niektoré veľmi špecifické úlohy:
- Potreba vytvárať typické malé webové aplikácie podľa nasledujúcej štandardnej schémy:
- nainštalovať závislosti aplikácií v celom systéme,
- nainštalovať balík knižníc závislých aplikácií,
- zbierať majetok,
- a čo je najdôležitejšie, rýchlo a efektívne aktualizovať kód v obrázku.
- Keď sa vykonajú zmeny v súboroch projektu, tvorca musí rýchlo vytvoriť novú vrstvu aplikovaním opravy na zmenené súbory.
- Ak sa niektoré súbory zmenili, potom je potrebné znova vytvoriť zodpovedajúcu závislú fázu.
Dnes má náš zberateľ mnoho iných možností, ale toto boli prvotné túžby a nutkania.
Vo všeobecnosti sme sa bez rozmýšľania vyzbrojili programovacím jazykom, ktorý sme použili (Pozri nižšie) a vydať sa na cestu k realizácii vlastné DSL! V súlade s cieľmi bolo zámerom popísať proces montáže v etapách a určiť závislosti týchto fáz na súboroch. A dopĺňal to vlastný zberateľ, ktorý zmenil DSL na konečný cieľ - zostavený obraz. Najprv bolo DSL v Ruby, ale ako — konfigurácia nášho kolektora sa začala popisovať v súbore YAML.
Stará konfigurácia pre dapp v Ruby
Aktuálna konfigurácia pre werf na YAML
Mechanizmus zberača sa tiež časom menil. Najprv sme jednoducho vygenerovali dočasný súbor Dockerfile za chodu z našej konfigurácie a potom sme začali spúšťať montážne pokyny v dočasných kontajneroch a odovzdávať.
NB: Momentálne sa náš kolektor, ktorý pracuje s vlastnou konfiguráciou (v YAML) a volá sa Stapel kolektor, vyvinul v pomerne silný nástroj. Jeho podrobný popis si zaslúži samostatné články a základné podrobnosti nájdete v .
Uvedomenie si problému
Ale uvedomili sme si, a nie hneď, že sme urobili jednu chybu: nepridali sme schopnosť vytvárať obrázky prostredníctvom štandardného súboru Dockerfile a integrovať ich do rovnakej komplexnej infraštruktúry správy aplikácií (t. j. zbierať obrazy, nasadzovať ich a čistiť). Ako by bolo možné urobiť nástroj na nasadenie v Kubernetes a neimplementovať podporu Dockerfile, t.j. štandardný spôsob popisu obrázkov pre väčšinu projektov?...
Namiesto odpovede na túto otázku ponúkame riešenie. Čo ak už máte súbor Dockerfile (alebo sadu súborov Dockerfile) a chcete použiť werf?
NB: Mimochodom, prečo by ste vôbec chceli používať werf? Hlavné rysy sú nasledovné:
- úplný cyklus správy aplikácií vrátane čistenia obrazu;
- schopnosť riadiť zostavenie niekoľkých obrázkov naraz z jednej konfigurácie;
- Vylepšený proces nasadenia pre grafy kompatibilné s Helm.
Ich kompletnejší zoznam nájdete na .
Takže ak by sme predtým ponúkli prepísanie súboru Dockerfile v našej konfigurácii, teraz s radosťou povieme: „Nechajte werf zostaviť vaše súbory Docker!“
Ako používať?
Úplná implementácia tejto funkcie sa objavila vo vydaní . Všeobecný princíp je jednoduchý: používateľ zadá cestu k existujúcemu súboru Docker v konfigurácii werf a potom spustí príkaz werf build... a je to - werf zostaví obrázok. Pozrime sa na abstraktný príklad.
Oznámime ďalšiu Dockerfile v koreňovom adresári projektu:
FROM ubuntu:18.04
RUN echo Building ...
A oznámime werf.yamlktorý toto používa Dockerfile:
configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile
Všetky! Vľavo bežať werf build:
Okrem toho môžete deklarovať nasledovné werf.yaml vytvoriť niekoľko obrázkov z rôznych súborov Docker naraz:
configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend
Napokon podporuje aj odovzdávanie doplnkových parametrov zostavy, ako napr --build-arg и --add-host - cez konfiguráciu werf. Úplný popis konfigurácie obrazu Dockerfile je k dispozícii na adrese .
Ako to funguje?
Počas procesu zostavovania funguje štandardná vyrovnávacia pamäť lokálnych vrstiev v Dockeri. Čo je však dôležité, je aj to werf integruje konfiguráciu Dockerfile do svojej infraštruktúry. Čo to znamená?
- Každý obrázok vytvorený z Dockerfile pozostáva z jednej fázy tzv
dockerfile(môžete si prečítať viac o tom, aké sú fázy vo werf ). - Pre javisko
dockerfilewerf vypočíta podpis, ktorý závisí od obsahu konfigurácie Dockerfile. Keď sa zmení konfigurácia súboru Dockerfile, zmení sa podpis fázydockerfilea werf iniciuje prestavbu tejto fázy s novou konfiguráciou Dockerfile. Ak sa podpis nezmení, werf vezme obrázok z vyrovnávacej pamäte (viac podrobností o použití podpisov vo werf bolo popísaných v ). - Ďalej je možné zhromaždené obrázky publikovať pomocou príkazu
werf publish(Alebowerf build-and-publish) a použite ho na nasadenie do Kubernetes. Publikované obrázky do registra Docker budú vyčistené pomocou štandardných nástrojov na čistenie werf, t.j. Staré obrázky (staršie ako N dní), obrázky spojené s neexistujúcimi vetvami Git a ďalšie politiky budú automaticky vyčistené.
Viac podrobností o tu popísaných bodoch nájdete v dokumentácii:
- ;
- ;
- .
Poznámky a preventívne opatrenia
1. Externá adresa URL nie je podporovaná v ADD
V súčasnosti nie je podporované používanie externej adresy URL v smernici ADD. Werf nespustí opätovné zostavenie, keď sa zdroj na zadanej adrese URL zmení. Túto funkciu plánujeme pridať čoskoro.
2. K obrázku nemôžete pridať .git
Všeobecne povedané, pridanie adresára .git na obrázku - krutý zlý postup a tu je dôvod:
- Ak
.gitzostáva na konečnom obrázku, porušuje to zásady : Keďže konečný obrázok musí byť prepojený s jedným odovzdaním, nemalo by to byť možnégit checkoutsvojvoľný spáchanie. -
.gitzväčšuje veľkosť obrázka (úložisko môže byť veľké kvôli tomu, že doň boli kedysi pridané veľké súbory a potom vymazané). Veľkosť pracovného stromu spojeného len s konkrétnym odovzdaním nebude závisieť od histórie operácií v Git. V tomto prípade pridanie a následné odstránenie.gitz konečného obrázka nebude fungovať: obrázok stále získa ďalšiu vrstvu - takto funguje Docker. - Docker môže iniciovať zbytočné prebudovanie, aj keď sa vytvára rovnaké odovzdanie, ale z rôznych pracovných stromov. Napríklad GitLab vytvára samostatné klonované adresáre
/home/gitlab-runner/builds/HASH/[0-N]/yourprojectkeď je povolená paralelná montáž. Ďalšie opätovné zostavenie bude spôsobené tým, že adresár.gitsa líši v rôznych klonovaných verziách toho istého úložiska, aj keď je vytvorené rovnaké odovzdanie.
Posledný bod má dôsledky aj pri používaní werf. Werf vyžaduje, aby bola pri spúšťaní niektorých príkazov prítomná vstavaná vyrovnávacia pamäť (napr. werf deploy). Keď sa tieto príkazy spustia, werf vypočíta signatúry štádia pre obrázky špecifikované v werf.yamla musia byť v montážnej vyrovnávacej pamäti - inak príkaz nebude môcť pokračovať v práci. Ak podpis štádia závisí od obsahu .git, potom dostaneme vyrovnávaciu pamäť, ktorá je nestabilná voči zmenám v irelevantných súboroch a werf si takéto prehliadnutie nebude môcť odpustiť (podrobnejšie pozri ).
Všeobecne možno povedať, pridávanie len určitých potrebných súborov prostredníctvom pokynov ADD v každom prípade zvyšuje efektívnosť a spoľahlivosť napísaného Dockerfilea tiež zlepšuje stabilitu vyrovnávacej pamäte zhromaždenej na tento účel Dockerfile, k irelevantným zmenám v Git.
Celkový
Naša počiatočná cesta k napísaniu vlastného tvorcu pre špecifické potreby bola ťažká, čestná a priama: namiesto použitia bariel nad štandardným súborom Dockerfile sme napísali naše riešenie s vlastnou syntaxou. A to malo svoje výhody: zberateľ Stapel sa dokonale vyrovná so svojou úlohou.
V procese písania nášho vlastného buildera sme však stratili zo zreteľa podporu pre existujúce súbory Dockerfiles. Táto chyba je už opravená a v budúcnosti plánujeme vyvinúť podporu Dockerfile spolu s našim vlastným Stapel builderom pre distribuovanú montáž a pre montáž pomocou Kubernetes (t. j. montáž na bežcoch vo vnútri Kubernetes, ako sa to robí v kaniko).
Takže, ak sa vám zrazu povaľuje niekoľko súborov Dockerfile... vyskúšať !
PS Zoznam dokumentácie k téme
- ;
- ;
- ;
- ;
- ;
- ;
- .
Prečítajte si aj v našom blogu: “".
Zdroj: hab.com