Voit nyt rakentaa Docker-kuvia werfissä käyttämällä tavallista Docker-tiedostoa

Parempi myöhään kuin ei milloinkaan. Tai kuinka teimme melkein vakavan virheen, kun meillä ei ollut tukea tavallisille Docker-tiedostoille sovelluskuvien luomiseen.

Puhumme asiasta werf — GitOps-apuohjelma, joka integroituu mihin tahansa CI/CD-järjestelmään ja tarjoaa sovelluksen koko elinkaaren hallinnan mahdollistaen:

• kerätä ja julkaista kuvia,
• ota sovelluksia käyttöön Kubernetesissa,
• poista käyttämättömät kuvat erityiskäytäntöjen avulla.

Projektin filosofia on koota matalan tason työkalut yhdeksi yhtenäiseksi järjestelmäksi, jonka avulla DevOps-insinöörit voivat hallita sovelluksia. Jos mahdollista, olemassa olevia apuohjelmia (kuten Helm ja Docker) tulisi käyttää. Jos ongelmaan ei löydy ratkaisua, voimme luoda ja tukea kaiken tarvittavan.

Tausta: oma kuvankeräilijäsi

Näin kävi werfin kuvankerääjän kanssa: tavallinen Dockerfile ei riittänyt meille. Jos katsot nopeasti projektin historiaa, tämä ongelma ilmeni jo werf:n ensimmäisissä versioissa (silloin vielä tunnetaan nimellä dapp).

Kun loimme työkalua sovellusten rakentamiseen Docker-kuviin, huomasimme nopeasti, että Dockerfile ei sovellu meille joihinkin hyvin erityisiin tehtäviin:

1. Tarve rakentaa tyypillisiä pieniä verkkosovelluksia seuraavan vakiomallin mukaisesti:
   • asentaa järjestelmän laajuisia sovellusriippuvuuksia,
   • asentaa joukko sovellusriippuvuuskirjastoja,
   • kerätä omaisuutta,
   • ja mikä tärkeintä, päivitä kuvan koodi nopeasti ja tehokkaasti.
2. Kun projektitiedostoihin tehdään muutoksia, rakentajan on nopeasti luotava uusi taso asettamalla korjaustiedosto muutettuihin tiedostoihin.
3. Jos tietyt tiedostot ovat muuttuneet, on tarpeen rakentaa uudelleen vastaava riippuvainen vaihe.

Nykyään keräilijällämme on monia muita mahdollisuuksia, mutta nämä olivat ensimmäiset toiveet ja halut.

Yleensä, ajattelematta kahdesti, varusimme itsemme ohjelmointikielellämme (Katso alempaa) ja ryhtyä toteuttamaan oma DSL! Tavoitteiden mukaisesti oli tarkoitus kuvata kokoonpanoprosessi vaiheittain ja määrittää näiden vaiheiden riippuvuudet tiedostoista. Ja täydensi sitä oma keräilijä, joka muutti DSL:n lopulliseksi tavoitteeksi - kootuksi kuvaksi. Aluksi DSL oli Rubyssa, mutta kuten siirtyminen Golangiin - keräilijämme konfiguraatiota alettiin kuvata YAML-tiedostossa.

Vanha konfiguraatio dappille Rubyssa

Nykyinen werf-asetus YAML:ssä

Myös keräimen mekanismi muuttui ajan myötä. Aluksi loimme yksinkertaisesti väliaikaisen Docker-tiedoston lennossa kokoonpanostamme, ja sitten aloimme ajaa kokoonpanoohjeita väliaikaisissa säiliöissä ja sitoutua.

NB: Tällä hetkellä omalla konfiguraatiollaan (YAML:ssä) toimivasta Stapel-keräilijäksi kutsuttu keräilijämme on kehittynyt jo melko tehokkaaksi työkaluksi. Sen yksityiskohtainen kuvaus ansaitsee erilliset artikkelit, ja perustiedot löytyvät osoitteesta dokumentointi.

Tietoisuus ongelmasta

Mutta tajusimme, emmekä heti, että olimme tehneet yhden virheen: emme lisänneet kykyä rakentaa kuvia tavallisen Docker-tiedoston kautta ja integroi ne samaan päästä päähän -sovellusten hallintainfrastruktuuriin (eli kerää kuvia, ota käyttöön ja puhdista ne). Miten olisi mahdollista tehdä työkalu käyttöönottoon Kubernetesissa ja jättää toteuttamatta Dockerfile-tukea, ts. tavallinen tapa kuvata kuvia useimmissa projekteissa?

Sen sijaan, että vastaamme tähän kysymykseen, tarjoamme ratkaisun. Entä jos sinulla on jo Docker-tiedosto (tai joukko Docker-tiedostoja) ja haluat käyttää werfiä?

NB: Muuten, miksi edes haluat käyttää werfiä? Tärkeimmät ominaisuudet ovat seuraavat:

• täydellinen sovellusten hallintasykli, mukaan lukien kuvan puhdistus;
• kyky hallita useiden kuvien kokoamista kerralla yhdestä kokoonpanosta;
• Parannettu Helm-yhteensopivien kaavioiden käyttöönottoprosessi.

Täydellisempi luettelo niistä löytyy osoitteesta projektin sivu.

Joten jos aiemmin olisimme tarjonneet kirjoittaa Docker-tiedoston uudelleen konfiguraatiossamme, sanomme nyt iloisina: "Anna werf rakentaa Docker-tiedostosi!"

Kuinka käyttää?

Tämän ominaisuuden täydellinen toteutus ilmestyi julkaisussa werf v1.0.3-beta.1. Yleisperiaate on yksinkertainen: käyttäjä määrittää polun olemassa olevaan Docker-tiedostoon werf-kokoonpanossa ja suorittaa sitten komennon werf build... ja siinä kaikki - werf kokoaa kuvan. Katsotaanpa abstraktia esimerkkiä.

Julkistetaan seuraava Dockerfile projektin juuressa:

FROM ubuntu:18.04
RUN echo Building ...

Ja ilmoitamme werf.yamljoka käyttää tätä Dockerfile:

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

Kaikki! Vasen juosta werf build:

Lisäksi voit ilmoittaa seuraavat asiat werf.yaml luoda useita kuvia eri Docker-tiedostoista kerralla:

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

Lopuksi se tukee myös ylimääräisten koontiparametrien, kuten esim --build-arg и --add-host - werf configin kautta. Täydellinen kuvaus Dockerfile-kuvakokoonpanosta on saatavilla osoitteessa dokumentaatiosivu.

Miten se toimii?

Rakennusprosessin aikana Dockerin paikallisten kerrosten vakiovälimuisti toimii. Tärkeää on kuitenkin myös se werf integroi Dockerfile-kokoonpanon infrastruktuuriinsa. Mitä tämä tarkoittaa?

1. Jokainen Docker-tiedostosta rakennettu kuva koostuu yhdestä vaiheesta nimeltä dockerfile (voit lukea lisää siitä, mitkä vaiheet ovat werf täällä).
2. Lavaa varten dockerfile werf laskee allekirjoituksen, joka riippuu Dockerfile-kokoonpanon sisällöstä. Kun Dockerfile-kokoonpano muuttuu, vaiheen allekirjoitus muuttuu dockerfile ja werf aloittaa tämän vaiheen uudelleenrakentamisen uudella Dockerfile-kokoonpanolla. Jos allekirjoitus ei muutu, werf ottaa kuvan välimuistista (lisätietoja allekirjoitusten käytöstä werfissä kuvattiin julkaisussa tämä raportti).
3. Seuraavaksi kerätyt kuvat voidaan julkaista komennolla werf publish (tai werf build-and-publish) ja käytä sitä Kubernetesin käyttöönottoon. Docker-rekisteriin julkaistut kuvat puhdistetaan tavallisilla werf-siivoustyökaluilla, esim. Vanhat kuvat (vanhemmat kuin N päivää), olemattomiin Git-haaroihin liittyvät kuvat ja muut käytännöt puhdistetaan automaattisesti.

Lisätietoja tässä kuvatuista kohdista löytyy dokumentaatiosta:

• Julkaisuprosessi;
• Integrointi Kubernetesin käyttöönottoprosessiin;
• Puhdistusprosessi.

Huomautuksia ja varotoimet

1. ADD ei tue ulkoista URL-osoitetta

Tällä hetkellä ei tueta ulkoisen URL-osoitteen käyttöä käskyssä ADD. Werf ei aloita uudelleenrakennusta, kun määritetyn URL-osoitteen resurssi muuttuu. Aiomme lisätä tämän ominaisuuden pian.

2. Et voi lisätä kuvaan .git

Yleisesti ottaen hakemiston lisääminen .git kuvassa - ilkeä huono käytäntö ja tässä syy:

1. Jos .git jää lopulliseen kuvaan, tämä rikkoo periaatteita 12 tekijän sovellus: Koska lopullinen kuva on linkitettävä yhteen sitomiseen, sen ei pitäisi olla mahdollista git checkout mielivaltainen sitoutuminen.
2. .git lisää kuvan kokoa (arkisto voi olla suuri, koska siihen on kerran lisätty suuria tiedostoja ja sitten poistettu). Vain tiettyyn sitoumukseen liittyvän työpuun koko ei riipu Gitin toimintahistoriasta. Tässä tapauksessa lisääminen ja myöhempi poistaminen .git lopullisesta kuvasta ei toimi: kuva saa silti ylimääräisen kerroksen - näin Docker toimii.
3. Docker voi käynnistää tarpeettoman uudelleenrakentamisen, vaikka rakennettaisiinkin samaa toimitusta, mutta eri työpuista. Esimerkiksi GitLab luo erillisiä kloonattuja hakemistoja /home/gitlab-runner/builds/HASH/[0-N]/yourproject kun rinnakkaiskokoonpano on käytössä. Ylimääräinen uudelleenkokoonpano johtuu siitä, että hakemisto .git on erilainen saman arkiston eri kloonatuissa versioissa, vaikka sama toimitus olisi rakennettu.

Viimeisellä pisteellä on myös seurauksia käytettäessä werfiä. Werf vaatii sisäänrakennetun välimuistin olevan läsnä, kun suoritetaan joitain komentoja (esim. werf deploy). Kun nämä komennot suoritetaan, werf laskee vaiheiden allekirjoitukset määritetyille kuville werf.yaml, ja niiden on oltava kokoonpanovälimuistissa - muuten komento ei voi jatkaa toimintaansa. Jos vaiheen allekirjoitus riippuu sisällöstä .git, niin saamme välimuistin, joka on epävakaa epäolennaisten tiedostojen muutoksille, eikä werf voi antaa anteeksi tällaista virhettä (lisätietoja on kohdassa dokumentointi).

Yleensä vain tiettyjen tarpeellisten tiedostojen lisääminen ohjeiden kautta ADD joka tapauksessa lisää kirjoituksen tehokkuutta ja luotettavuutta Dockerfileja parantaa myös tätä varten kerätyn välimuistin vakautta Dockerfile, merkityksettömiin muutoksiin Gitissä.

Koko

Alkupolkumme oman rakentajan kirjoittamiseen erityistarpeita varten oli vaikea, rehellinen ja suoraviivainen: sen sijaan, että käyttäisimme kainalosauvoja tavallisen Dockerfile-tiedoston päälle, kirjoitimme ratkaisumme mukautetulla syntaksilla. Ja tässä oli etunsa: Stapel-keräin selviää tehtävästään täydellisesti.

Kuitenkin, kun kirjoitimme omaa rakentajaamme, menetimme näkyvistämme tuen olemassa oleville Dockerfilesille. Tämä virhe on nyt korjattu, ja tulevaisuudessa aiomme kehittää Dockerfile-tukea yhdessä mukautetun Stapel-rakennustyökalumme kanssa hajautettuun kokoonpanoon ja Kubernetesin avulla tapahtuvaan kokoonpanoon (eli kokoonpanoon Kubernetesin sisällä oleville juoksuille, kuten kanikossa tehdään).

Joten, jos sinulla on yhtäkkiä pari Docker-tiedostoa... kokeile sitä werf!

PS Luettelo aihetta koskevista asiakirjoista

• Ohjeita nopeaan alkuun;
• Dockerfile Builder -kokoonpanot;
• Stage-laite werfissä;
• Kuvien julkaisuprosessi;
• Integrointi Kubernetesin käyttöönottoprosessiin;
• Puhdistusprosessi;
• Stapel builder vaihtoehtona Dockerfilelle.

Lue myös blogistamme: "werf - työkalumme CI:lle / CD:lle Kubernetesissa (yleiskatsaus ja videoraportti)'.

Lähde: will.com