🥇Teraz môžete vytvárať obrazy Dockeru vo werfe pomocou bežného súboru Dockerfile

Lepšie neskoro ako nikdy. Alebo ako sme takmer urobili vážnu chybu tým, že sme nemali podporu pre bežné Dockerfile súbory na vytváranie obrazov aplikácií.

Budeme hovoriť o werf — 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 vám umožňuje:

zbierať a publikovať obrázky,
nasadzovať aplikácie do Kubernetes,
odstráňte nepoužívané obrázky pomocou špeciálnych politík.

Filozofiou projektu je konsolidovať nízkoúrovňové nástroje do jedného, jednotného systému, ktorý dáva DevOps inžinierom kontrolu nad aplikáciami. Všade, kde je to možné, budú využité existujúce nástroje (ako napríklad Helm a Docker). Ak riešenie pre konkrétnu úlohu neexistuje, vieme vytvoriť a zabezpečiť všetku potrebnú podporu.

Pozadie: Váš vlastný zberateľ obrázkov

Presne to sa stalo s nástrojom na tvorbu obrazov werf: chýbal nám známy Dockerfile. Rýchly pohľad späť na históriu projektu odhaľuje tento problém, ktorý sa objavil v prvých verziách werf (vtedy, známy ako decentralizovaná aplikácia (DAPP)).

Pri vývoji nástroja na zostavovanie aplikácií do obrazov Dockeru sme si rýchlo uvedomili, že súbory Dockerfiles nie sú vhodné pre niektoré veľmi špecifické úlohy:

Potreba vytvoriť typické malé webové aplikácie pomocou nasledujúcej štandardnej schémy:
- nainštalovať závislosti aplikácie v celom systéme,
- nainštalovať balík knižníc závislostí aplikácie,
- zhromažďovať aktíva,
- a čo je najdôležitejšie, rýchlo a efektívne aktualizovať kód v obrázku.
Keď dôjde k zmenám v súboroch projektu, tvorca musí rýchlo vytvoriť novú vrstvu aplikovaním záplaty na zmenené súbory.
Ak sa určité súbory zmenili, je potrebné znovu zostaviť príslušnú závislú fázu.

Dnes má náš assembler mnoho ďalších funkcií, ale počiatočné túžby a nutkania boli nasledovné.

Skrátka, bez váhania sme sa vyzbrojili programovacím jazykom, ktorý sme používali. (Pozri nižšie) a vydajte sa na cestu k realizácii vlastné DSLV súlade so stanovenými cieľmi bolo zámerom opísať proces zostavovania v etapách a definovať závislosti týchto etap od súborov. A dopĺňalo ho to. vlastný assembler, čo transformovalo DSL na konečný cieľ – vytvorený obraz. Spočiatku bol DSL v jazyku Ruby a ako prechod do Golangu — konfigurácia nášho kolektora je teraz popísaná v súbore YAML.

Stará konfigurácia decentralizovanej aplikácie v Ruby

Aktuálna konfigurácia werf v YAML

Mechanizmus buildera sa tiež časom zmenil. Najprv sme jednoducho generovali dočasný Dockerfile za chodu z našej konfigurácie, ale potom sme začali spúšťať inštrukcie na zostavenie v dočasných kontajneroch a ich commitovať.

NBNáš nástroj na tvorbu Stapel, ktorý pracuje s vlastnou konfiguráciou YAML a nazýva sa Stapel builder, sa už vyvinul do pomerne výkonného nástroja. Jeho podrobný popis si zaslúži samostatné články, ale hlavné podrobnosti nájdete v... dokumentáciu.

Povedomie o probléme

Ale uvedomili sme si, a nie hneď, že sme urobili jednu chybu: nepridali sme schopnosť vytvárať obrazy pomocou štandardného Dockerfile a integrovať ich do rovnakej komplexnej infraštruktúry správy aplikácií (t. j. vytváranie obrazov, ich nasadzovanie a čistenie). Ako mohli vytvoriť nástroj na nasadenie Kubernetes bez podpory Dockerfiles, štandardného spôsobu popisu obrazov pre väčšinu projektov?

Namiesto odpovede na túto otázku ponúkame riešenie. Čo ak už máte Dockerfile (alebo sadu Dockerfile) a chcete použiť werf?

NBMimochodom, prečo by ste chceli používať werf? Hlavné vlastnosti sú nasledovné:

kompletný cyklus správy aplikácií vrátane čistenia obrazu;
schopnosť spravovať zostavovanie viacerých obrázkov naraz z jednej konfigurácie;
Vylepšený proces nasadenia grafov kompatibilných s Helmom.

Ich kompletnejší zoznam nájdete na stránka projektu.

Takže, ak by sme predtým navrhli prepísať Dockerfile do našej konfigurácie, teraz s radosťou povieme: „Nechajte werf zostaviť vaše Dockerfile!“

Ako používať?

Úplná implementácia tejto funkcie sa objavila vo vydaní werf v1.0.3-beta.1Všeobecný princíp je jednoduchý: používateľ zadá cestu k existujúcemu Dockerfile v konfigurácii werf a potom spustí príkaz werf build...a to je všetko – werf vytvorí obraz. Pozrime sa na abstraktný príklad.

Oznámme ďalší Dockerfile v jadre projektu:

FROM ubuntu:18.04
RUN echo Building ...

A my oznámime werf.yaml, ktorý toto používa Dockerfile:

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

To je všetko! Všetko, čo zostalo! bežať werf build:

Okrem toho môžete deklarovať nasledujúce werf.yaml Ak chcete naraz vytvoriť viacero obrázkov z rôznych súborov Dockerfile:

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

Nakoniec je podporované aj odovzdávanie ďalších parametrov zostavenia, ako napríklad --build-arg и --add-host — prostredníctvom konfigurácie werf. Úplný popis konfigurácie obrazu Dockerfile je k dispozícii na adrese stránka s dokumentáciou.

Ako to funguje?

Štandardná lokálna vyrovnávacia pamäť vrstiev Dockeru je povolená počas procesu zostavovania. Dôležité je však, že werf tiež integruje konfiguráciu Dockerfile do svojej infraštruktúryČo to znamená?

Každý obraz vytvorený z Dockerfile pozostáva z jednej fázy s názvom dockerfile (Viac o tom, aké fázy sú vo werfe, si môžete prečítať tu) tu).
Pre javisko dockerfile werf vypočíta podpis, ktorý závisí od obsahu konfigurácie Dockerfile. Zmenou konfigurácie Dockerfile sa zmení podpis etapy. dockerfile a werf spustí prestavbu tejto fázy s novou konfiguráciou Dockerfile. Ak sa podpis nezmení, werf vezme obraz z vyrovnávacej pamäte. (viac podrobností o používaní podpisov vo werfe bolo prediskutovaných v v tejto správe).
Zhromaždené obrázky je potom možné publikovať pomocou príkazu werf publish (Alebo werf build-and-publish) a použité na nasadenie do Kubernetes. Publikované obrazy v registri Docker budú vyčistené pomocou štandardných nástrojov na čistenie werf, čo znamená, že staré obrazy (staršie ako N dní), obrazy spojené s neexistujúcimi vetvami Gitu a ďalšie politiky budú automaticky vyčistené.

Viac podrobností o tu opísaných bodoch nájdete v dokumentácii:

Poznámky a bezpečnostné opatrenia

1. Externá URL adresa v ADD nie je podporovaná

Používanie externej URL adresy v direktíve momentálne nie je podporované. ADDWerf nespustí obnovu, keď sa zmení zdroj na zadanej URL adrese. Pridanie tejto funkcie sa plánuje čoskoro.

2. Do obrázka nie je možné pridať .git

Vo všeobecnosti, pridanie adresára .git na obrázku je zlý a nekalý zvyk a tu je dôvod:

Ak .git zostáva vo výslednom obraze, čo porušuje princípy Aplikácia 12 faktorov: keďže výsledný obrázok musí byť spojený s jedným commitom, nemalo by byť možné to urobiť git checkout svojvoľný commit.
.git zväčšuje veľkosť obrazu (repozitár môže byť veľký kvôli pridávaniu a následnému odstraňovaniu veľkých súborov). Veľkosť pracovného stromu spojeného iba s konkrétnym commitom nebude závisieť od histórie operácií Gitu. Navyše, pridávanie a následné odstraňovanie .git z finálneho obrázka nebude fungovať: obrázok stále získa ďalšiu vrstvu – takto funguje Docker.
Docker môže spúšťať zbytočné prestavby, aj keď sa zostavuje ten istý commit, ale z rôznych pracovných stromov. Napríklad GitLab vytvára samostatné klonované adresáre v /home/gitlab-runner/builds/HASH/[0-N]/yourproject s povoleným paralelným zostavovaním. Dodatočné zostavenie bude spôsobené tým, že adresár .git sa líši medzi klonovanými verziami toho istého repozitára, aj keď je zostavený rovnaký commit.

Posledný bod má dôsledky aj pri používaní werf. Werf vyžaduje, aby bola pri spúšťaní určitých príkazov (napríklad werf deploy). Pri spustení takýchto príkazov werf vypočítava podpisy scény pre obrázky zadané v werf.yamla musia byť vo vyrovnávacej pamäti zostavenia – inak tím nebude môcť pokračovať v práci. Ak podpis fázy závisí od obsahu .git, potom dostaneme vyrovnávaciu pamäť, ktorá je nestabilná voči zmenám v irelevantných súboroch a werf takéto prehliadnutie neodpustí (podrobnosti nájdete v dokumentáciu).

Všeobecne možno povedať, pridanie iba určitých potrebných súborov podľa pokynov ADD v každom prípade to zvyšuje efektivitu a spoľahlivosť toho, čo je napísané Dockerfilea tiež zlepšuje stabilitu vyrovnávacej pamäte zhromaždenej pre tento účel Dockerfile, k irelevantným zmenám v Gite.

Celkový

Naša počiatočná cesta k napísaniu vlastného builderu pre špecifické potreby bola náročná, úprimná a priamočiara: namiesto použitia hackov nad štandardným Dockerfile sme napísali vlastné riešenie s vlastnou syntaxou. A to malo svoje výhody: builder Stapel si svoju prácu robí perfektne.

Pri písaní nášho vlastného builderu sme však prehliadli podporu pre existujúce Dockerfile. Toto je teraz opravené a v budúcnosti plánujeme vyvinúť podporu pre Dockerfile spolu s naším vlastným Stapel builderom pre distribuované zostavenia a pre zostavenia založené na Kubernetes (t. j. zostavenia na runneroch v rámci Kubernetes, ako je to urobené v Kaniko).

Takže, ak náhodou máte po ruke pár Dockerfiles... vyskúšať werf!