Nyní můžete vytvářet obrazy Docker ve werf pomocí běžného souboru Docker

Lépe později než nikdy. Nebo jak jsme málem udělali vážnou chybu, když jsme neměli podporu pro běžné soubory Dockerfiles pro vytváření obrazů aplikací.

Bude to o werf - Nástroj GitOps, který se integruje s jakýmkoli systémem CI / CD a poskytuje správu celého životního cyklu aplikace, což vám umožňuje:

• sbírat a publikovat obrázky,
• nasazení aplikací do Kubernetes,
• odstranit nepoužívané obrázky pomocí speciálních zásad.

Filozofií projektu je shromáždit nízkoúrovňové nástroje do jediného jednotného systému, který inženýrům DevOps poskytuje kontrolu nad aplikacemi. Pokud je to možné, měly by být použity stávající nástroje (jako Helm a Docker). Pokud neexistuje řešení nějakého problému, můžeme vytvořit a udržovat vše potřebné k tomu.

Pozadí: váš vlastní sběratel obrázků

To se stalo s tvůrcem obrázků ve werf: chyběl nám obvyklý Dockerfile. Pokud se krátce ponoříte do historie projektu, pak se tento problém projevil již v prvních verzích werf (tehdy známý jako dapp).

Při vytváření nástroje pro vytváření aplikací do obrazů Dockeru jsme rychle zjistili, že Dockerfile pro nás není vhodný pro některé velmi specifické úkoly:

1. Potřeba sestavit typické malé webové aplikace podle následujícího standardního schématu:
   • nainstalovat systémové závislosti aplikace,
   • nainstalovat balíček knihoven závislostí aplikací,
   • sbírat majetek,
   • a co je nejdůležitější, rychle a efektivně aktualizovat kód v obrázku.
2. Když jsou provedeny změny v souborech projektu, musí tvůrce rychle vytvořit novou vrstvu opravou změněných souborů.
3. Pokud se některé soubory změnily, musí být znovu vytvořena odpovídající závislá fáze.

Dnes je v našem faucetu mnoho dalších možností, ale prvotní touhy a nutkání byly následující.

Obecně platí, že bez přemýšlení jsme se vyzbrojili použitým programovacím jazykem (viz. níže) a vyrazit na cestu - realizovat vlastní DSL! V souladu se zadanými úkoly bylo zamýšleno popsat proces sestavení ve fázích a určit závislosti těchto fází na souborech. A doplnil to vlastní faucet, který proměnil DSL ve finální cíl – sestavený obraz. Zpočátku bylo DSL v Ruby, ale jako přechod na Golang - konfigurace našeho kolektoru se začala popisovat v souboru YAML.

Stará konfigurace pro dapp v Ruby

Aktuální konfigurace pro werf na YAML

Mechanismus sběrače se také časem měnil. Nejprve jsme jednoduše vygenerovali nějaký dočasný Dockerfile z naší konfigurace za chodu a pak jsme začali spouštět instrukce pro sestavení v dočasných kontejnerech a provádět odevzdání.

NB: V tuto chvíli se náš builder, který pracuje s vlastní konfigurací (v YAML) a jmenuje se Stapel builder, již vyvinul v poměrně silný nástroj. Jeho podrobný popis si zaslouží samostatné články a hlavní podrobnosti najdete v dokumentace.

Uvědomění si problému

Ale uvědomili jsme si, a ne hned, že jsme udělali jednu chybu: nepřidali jsme schopnost vytvářet obrázky prostřednictvím standardního souboru Dockerfile a integrovat je do stejné infrastruktury pro správu aplikací typu end-to-end (tj. shromažďovat obrazy, nasazovat je a čistit). Jak byste mohli udělat nástroj pro nasazení v Kubernetes a neimplementovat podporu Dockerfile, tzn. standardní způsob popisu obrázků pro většinu projektů?...

Místo odpovědi na takovou otázku nabízíme její řešení. Co když již máte soubor Dockerfile (nebo sadu souborů Dockerfile) a chcete použít werf?

NB: Mimochodem, proč byste vůbec chtěli používat werf? Hlavní rysy se scvrkají na následující:

• úplný cyklus správy aplikací včetně obrázků čištění;
• schopnost spravovat sestavení několika obrazů najednou z jedné konfigurace;
• vylepšený proces nasazení pro grafy kompatibilní s Helm.

Úplnější seznam lze nalézt na stránka projektu.

Pokud bychom tedy dříve navrhli přepsat Dockerfile do naší konfigurace, nyní s radostí můžeme říci: „Nechte werf vytvořit vaše Dockerfile!“

Jak používat?

Plná implementace této funkce se objevila ve vydání werf v1.0.3-beta.1. Obecný princip je jednoduchý: uživatel zadá cestu k existujícímu Dockerfile v konfiguraci werf a poté spustí příkaz werf build... a je to - werf vytvoří image. Vezměme si abstraktní příklad.

Pojďme oznámit další Dockerfile v kořenu projektu:

FROM ubuntu:18.04
RUN echo Building ...

A oznámíme werf.yamlkterý toto používá Dockerfile:

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

Všechno! Vlevo, odjet běžet werf build:

Kromě toho můžete deklarovat následující werf.yaml vytvořit několik obrázků najednou z různých souborů Dockerfiles:

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

Konečně je podporováno i předávání dalších parametrů sestavení – jako např --build-arg и --add-host - přes konfiguraci werf. Úplný popis konfigurace obrazu Dockerfile je k dispozici na adrese stránka dokumentace.

Jak to funguje?

Během procesu sestavení funguje standardní mezipaměť místních vrstev v Dockeru. Nicméně, co je důležité, werf také integruje konfiguraci Dockerfile do své infrastruktury. Co to znamená?

1. Každý obraz vytvořený z Dockerfile se skládá z jedné fáze nazvané dockerfile (více o tom, jaké fáze jsou ve werf, si můžete přečíst zde).
2. Na jeviště dockerfile werf vypočítá podpis, který závisí na obsahu konfigurace Dockerfile. Změna konfigurace Dockerfile změní podpis fáze dockerfile a werf zahájí přestavbu této fáze s novou konfigurací Dockerfile. Pokud se podpis nezmění, werf vezme obrázek z mezipaměti (více o použití podpisů ve werf bylo popsáno v tato zpráva).
3. Dále lze shromážděné obrázky publikovat pomocí příkazu werf publish (nebo werf build-and-publish) a použijte jej k nasazení do Kubernetes. Publikované obrázky v registru Docker budou vyčištěny standardními nástroji pro čištění werf, tzn. dojde k automatickému vyčištění starých obrázků (starších než N dní), obrázků spojených s neexistujícími větvemi Git a dalších zásad.

Více podrobností o zde popsaných bodech naleznete v dokumentaci:

• Publikační proces;
• Integrace s procesem nasazení v Kubernetes;
• Proces čištění.

Poznámky a bezpečnostní opatření

1. Externí adresa URL v ADD není podporována

Použití externí adresy URL v direktivě není aktuálně podporováno. ADD. Werf nespustí opětovné sestavení, když se zdroj na zadané adrese URL změní. Tato funkce má být brzy přidána.

2. K obrázku nemůžete přidat .git

Obecně řečeno, přidání adresáře .git do obrázku je zlomyslná špatná praxe a zde je důvod:

1. Jestliže .git zůstává na konečném obrázku, porušuje to zásady 12faktorová aplikace: protože výsledný obrázek musí být spojen s jedním potvrzením, nemělo by to být možné git checkout svévolný spáchání.
2. .git zvětšuje velikost obrázku (úložiště může být velké kvůli tomu, že do něj byly kdysi přidány velké soubory a poté smazány). Velikost pracovního stromu spojeného pouze s konkrétním potvrzením nebude záviset na historii operací v Gitu. V tomto případě přidání a následné odebrání .git z výsledného obrázku nebude fungovat: obrázek bude stále získávat další vrstvu - takto funguje Docker.
3. Docker může spustit zbytečnou obnovu, i když je stejné potvrzení sestavováno z různých pracovních stromů. Například GitLab vytváří samostatné klonované adresáře /home/gitlab-runner/builds/HASH/[0-N]/yourproject s povolenou paralelní montáží. Další přestavba bude způsobena tím, že adresář .git liší se v různých klonovaných verzích stejného úložiště, i když je sestaveno stejné potvrzení.

Poslední bod má důsledky i při použití werf. Werf vyžaduje, aby byla při spouštění některých příkazů (např. werf deploy). Během provádění takových příkazů werf vypočítá signatury fáze pro obrázky specifikované v werf.yamla musí být v mezipaměti sestavení, jinak příkaz nebude moci pokračovat. Pokud podpis etap závisí na obsahu .git, pak získáme mezipaměť, která je nestabilní vůči změnám v irelevantních souborech a werf nebude schopen takové nedopatření odpustit (podrobněji viz dokumentace).

Obecně lze říci, přidání pouze určitých požadovaných souborů prostřednictvím instrukcí ADD v každém případě zvyšuje efektivitu a spolehlivost psaného textu Dockerfile, a také zlepšuje stabilitu mezipaměti shromážděné tímto Dockerfile, na irelevantní změny v Gitu.

Celkový

Naše počáteční cesta s psaním našeho vlastního builderu pro konkrétní potřeby byla tvrdá, upřímná a přímočará: namísto použití berliček nad standardním Dockerfile jsme napsali vlastní řešení s vlastní syntaxí. A to přineslo své výhody: Stapel-kolektor dělá svou práci dokonale.

V procesu psaní našeho vlastního builderu jsme však ztratili ze zřetele podporu již existujících souborů Dockerfiles. Nyní je tento nedostatek opraven a v budoucnu plánujeme vyvinout podporu Dockerfile spolu s naším vlastním Stapel builderem pro distribuovaná sestavení a pro sestavování pomocí Kubernetes (tj. stavění na běžcích uvnitř Kubernetes, jak se to dělá v kaniko).

Takže, pokud se vám najednou povaluje několik Dockerfile ... zkuste to werf!

PS Seznam dokumentace k tématu

• Příručky pro rychlý start;
• konfigurace dockerfile builderu;
• fáze zařízení ve werf;
• Proces publikování obrázků;
• Integrace s procesem nasazení v Kubernetes;
• Proces čištění;
• Stapel builder jako alternativa k Dockerfile.

Přečtěte si také na našem blogu:werf - náš nástroj pro CI / CD v Kubernetes (přehled a videoreportáž)".

Zdroj: www.habr.com