Bolje pozno kot nikoli. Ali kako smo skoraj naredili resno napako, ker nismo imeli podpore za običajne datoteke Dockerfiles za izdelavo slik aplikacij.
Pogovarjali se bomo o — Pripomoček GitOps, ki se integrira s katerim koli sistemom CI/CD in zagotavlja upravljanje celotnega življenjskega cikla aplikacije, kar omogoča:
- zbiranje in objavljanje slik,
- nameščanje aplikacij v Kubernetes,
- izbrišite neuporabljene slike s posebnimi pravilniki.
Filozofija projekta je zbrati nizkonivojska orodja v enoten enoten sistem, ki inženirjem DevOps omogoča nadzor nad aplikacijami. Če je mogoče, je treba uporabiti obstoječe pripomočke (kot sta Helm in Docker). Če rešitve problema ni, lahko ustvarimo in podpiramo vse, kar je za to potrebno.
Ozadje: vaš lastni zbiralnik slik
To se je zgodilo z zbiralnikom slik v werf: običajni Dockerfile nam ni bil dovolj. Če na hitro pogledate zgodovino projekta, se je ta težava pojavila že v prvih različicah werfa (takrat še ).
Med ustvarjanjem orodja za vgradnjo aplikacij v slike Docker smo hitro ugotovili, da Dockerfile za nas ni primeren za nekatera zelo specifična opravila:
- Potreba po izdelavi tipičnih majhnih spletnih aplikacij po naslednji standardni shemi:
- namestite sistemske odvisnosti aplikacij,
- namestite sveženj knjižnic odvisnosti od aplikacij,
- zbiranje sredstev,
- in kar je najpomembnejše, hitro in učinkovito posodobite kodo na sliki.
- Ko se datoteke projekta spremenijo, mora graditelj hitro ustvariti novo plast z uporabo popravka na spremenjenih datotekah.
- Če so se nekatere datoteke spremenile, je treba znova zgraditi ustrezno odvisno stopnjo.
Danes ima naš zbiratelj veliko drugih možnosti, a to so bile začetne želje in vzgibi.
Na splošno smo se brez dvakratnega razmišljanja oborožili s programskim jezikom, ki smo ga uporabili (glej spodaj) in se podajte na pot izvajanja lasten DSL! V skladu s cilji je bilo mišljeno opisati proces sestavljanja po stopnjah in določiti odvisnosti teh stopenj od datotek. In jo dopolnil lastnega zbiratelja, ki je DSL spremenil v končni cilj – sestavljeno sliko. Sprva je bil DSL v Rubyju, vendar kot — konfiguracija našega zbiralnika se je začela opisovati v datoteki YAML.
Stara konfiguracija za dapp v Rubyju
Trenutna konfiguracija za werf na YAML
Sčasoma se je spreminjal tudi mehanizem zbiralnika. Sprva smo preprosto sproti generirali začasno datoteko Dockerfile iz naše konfiguracije, nato pa smo začeli izvajati navodila za sestavljanje v začasnih vsebnikih in objavljati.
NB: Trenutno se je naš zbiralnik, ki deluje s svojo konfiguracijo (v YAML) in se imenuje Stapel collector, že razvil v dokaj zmogljivo orodje. Njegov podroben opis si zasluži ločene članke, osnovne podrobnosti pa najdete v .
Zavedanje problema
Vendar smo spoznali, in to ne takoj, da smo naredili eno napako: nismo dodali sposobnosti ustvarjanje slik prek standardne datoteke Dockerfile in jih integrirati v isto infrastrukturo za upravljanje aplikacij od konca do konca (tj. zbirati slike, jih namestiti in očistiti). Kako je mogoče narediti orodje za uvajanje v Kubernetesu in ne implementirati podpore za Dockerfile, tj. standardni način za opis slik za večino projektov?..
Namesto odgovora na to vprašanje ponujamo rešitev. Kaj pa, če že imate datoteko Dockerfile (ali nabor datotek Dockerfile) in želite uporabiti werf?
NB: Mimogrede, zakaj bi sploh želeli uporabiti werf? Glavne značilnosti so naslednje:
- celoten cikel upravljanja aplikacij, vključno s čiščenjem slike;
- zmožnost upravljanja sestavljanja več slik hkrati iz ene konfiguracije;
- Izboljšan postopek uvajanja za karte, združljive s Helmom.
Njihov popolnejši seznam je na voljo na .
Torej, če bi prej ponudili, da prepišemo Dockerfile v naši konfiguraciji, bomo zdaj z veseljem rekli: "Naj werf zgradi vaše Dockerfile!"
Kako uporabljati?
Popolna izvedba te funkcije se je pojavila v izdaji . Splošno načelo je preprosto: uporabnik določi pot do obstoječe datoteke Docker v konfiguraciji werf in nato zažene ukaz werf build... in to je to - werf bo sestavil sliko. Poglejmo si abstrakten primer.
Naj napovemo naslednjega Dockerfile v korenu projekta:
FROM ubuntu:18.04
RUN echo Building ...
In objavili bomo werf.yamlki to uporablja Dockerfile:
configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile
Vse! levo teči werf build:
Poleg tega lahko izjavite naslednje werf.yaml za izdelavo več slik iz različnih datotek Docker hkrati:
configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend
Končno podpira tudi posredovanje dodatnih gradbenih parametrov, kot je npr --build-arg и --add-host - prek konfiguracije werf. Celoten opis konfiguracije slike Dockerfile je na voljo na .
Kako deluje?
Med postopkom gradnje deluje standardni predpomnilnik lokalnih plasti v Dockerju. Vendar je pomembno, da tudi werf integrira konfiguracijo Dockerfile v svojo infrastrukturo. Kaj to pomeni?
- Vsaka slika, zgrajena iz datoteke Dockerfile, je sestavljena iz ene stopnje, imenovane
dockerfile(lahko preberete več o tem, katere stopnje so v werf ). - Za oder
dockerfilewerf izračuna podpis, ki je odvisen od vsebine konfiguracije Dockerfile. Ko se spremeni konfiguracija datoteke Dockerfile, se spremeni podpis stopnjedockerfilein werf sproži vnovično gradnjo te stopnje z novo konfiguracijo Dockerfile. Če se podpis ne spremeni, werf vzame sliko iz predpomnilnika (več podrobnosti o uporabi podpisov v werf je bilo opisanih v ). - Nato lahko zbrane slike objavite z ukazom
werf publish(Aliwerf build-and-publish) in ga uporabite za uvajanje v Kubernetes. Objavljene slike v registru Docker bodo očiščene s standardnimi orodji za čiščenje werf, tj. Stare slike (starejše od N dni), slike, povezane z neobstoječimi vejami Git, in drugi pravilniki bodo samodejno očiščeni.
Več podrobnosti o tukaj opisanih točkah najdete v dokumentaciji:
- ;
- ;
- .
Opombe in previdnostni ukrepi
1. Zunanji URL ni podprt v ADD
Trenutno uporaba zunanjega URL-ja v direktivi ni podprta ADD. Werf ne bo sprožil ponovne gradnje, ko se spremeni vir na podanem URL-ju. To funkcijo nameravamo dodati kmalu.
2. Sliki ne morete dodati .git
Na splošno dodajanje imenika .git na sliki – zlobna slaba praksa in tukaj je razlog:
- če
.gitostane v končni podobi, s tem so kršena načela : Ker mora biti končna slika povezana z eno samo potrditvijo, tega ne bi smelo biti mogočegit checkoutpoljubna zaveza. -
.gitpoveča velikost slike (repozitorij je lahko velik zaradi dejstva, da so bile velike datoteke enkrat dodane in nato izbrisane). Velikost delovnega drevesa, povezanega samo z določeno potrditvijo, ne bo odvisna od zgodovine operacij v Gitu. V tem primeru dodajanje in kasnejša odstranitev.gitiz končne slike ne bo delovalo: slika bo še vedno pridobila dodatno plast - tako deluje Docker. - Docker lahko sproži nepotrebno vnovično gradnjo, tudi če se gradi ista potrditev, vendar iz različnih delovnih dreves. Na primer, GitLab ustvari ločene klonirane imenike v
/home/gitlab-runner/builds/HASH/[0-N]/yourprojectko je omogočeno vzporedno sestavljanje. Dodatno ponovno sestavljanje bo posledica dejstva, da imenik.gitje drugačen v različnih kloniranih različicah istega repozitorija, tudi če je zgrajena ista potrditev.
Zadnja točka ima tudi posledice pri uporabi werf. Werf zahteva, da je pri izvajanju nekaterih ukazov prisoten vgrajen predpomnilnik (npr. werf deploy). Ko se ti ukazi zaženejo, werf izračuna podpise stopenj za slike, določene v werf.yaml, in morajo biti v predpomnilniku sklopov - sicer ukaz ne bo mogel nadaljevati z delom. Če je odrski podpis odvisen od vsebine .git, potem dobimo predpomnilnik, ki je nestabilen za spremembe v nepomembnih datotekah, in werf ne bo mogel odpustiti takšnega spregleda (za več podrobnosti glejte ).
Na splošno dodajanje samo določenih potrebnih datotek skozi navodila ADD v vsakem primeru poveča učinkovitost in zanesljivost zapisanega Dockerfile, in tudi izboljša stabilnost predpomnilnika, zbranega za to Dockerfile, do nepomembnih sprememb v Gitu.
Skupaj
Naša začetna pot do pisanja lastnega graditelja za posebne potrebe je bila težka, poštena in preprosta: namesto uporabe bergel poleg standardne datoteke Dockerfile smo svojo rešitev napisali s sintakso po meri. In to je imelo svoje prednosti: zbiralnik Stapel se odlično spopada s svojo nalogo.
Vendar pa smo v procesu pisanja lastnega graditelja izgubili izpred oči podporo za obstoječe datoteke Dockerfiles. Ta napaka je zdaj odpravljena in v prihodnosti nameravamo razviti podporo za Dockerfile skupaj z graditeljem Stapel po meri za porazdeljene gradnje in za gradnje, ki uporabljajo Kubernetes (tj. gradnje na tekačih znotraj Kubernetesa, kot se izvaja v kaniko).
Torej, če nenadoma imate naokoli nekaj datotek Dockerfile ... poskusi !
PS Seznam dokumentacije o temi
- ;
- ;
- ;
- ;
- ;
- ;
- .
Preberite tudi v našem blogu: “".
Vir: www.habr.com