🥇1.1. versijas izlaidums: kolekcionāra uzlabojumi šodien un nākotnes plāni

werf ir mūsu atvērtā pirmkoda GitOps CLI utilīta lietojumprogrammu izveidei un piegādei Kubernetes. Kā solīts, versijas v1.0 izlaišana iezīmēja sākumu jaunu funkciju pievienošanai werf un tradicionālo pieeju pārskatīšanai. Tagad mēs esam priecīgi iepazīstināt ar versiju v1.1, kas ir liels solis attīstībā un pamats nākotnei kolekcionārs werf. Versija pašlaik ir pieejama valodā kanāls 1.1 ea.

Izlaiduma pamatā ir jaunā skatuves krātuves arhitektūra un abu kolekcionāru darba optimizācija (Stapel un Dockerfile). Jaunā krātuves arhitektūra paver iespēju vienā un tajā pašā resursdatorā ieviest sadalītus komplektus no vairākiem saimniekdatoriem un paralēlus komplektus.

Darba optimizācija ietver atbrīvošanos no nevajadzīgiem aprēķiniem stadijas parakstu aprēķināšanas stadijā un failu kontrolsummu aprēķināšanas mehānismu nomaiņu uz efektīvākiem. Šī optimizācija samazina vidējo projekta izveides laiku, izmantojot werf. Un dīkstāves būvējumi, kad kešatmiņā ir visi posmi posmi-glabāšana, tagad ir ļoti ātri. Vairumā gadījumu būvēšanas restartēšana prasīs mazāk nekā 1 sekundi! Tas attiecas arī uz procedūrām komandu darba procesa posmu pārbaudei. werf deploy и werf run.

Arī šajā laidienā parādījās stratēģija attēlu marķēšanai pēc satura - uz saturu balstīta marķēšana, kas tagad ir iespējots pēc noklusējuma un vienīgais ieteicamais.

Sīkāk apskatīsim galvenos werf v1.1 jauninājumus un tajā pašā laikā pastāstīsim par nākotnes plāniem.

Kas ir mainījies werf v1.1 versijā?

Jauns posmu nosaukšanas formāts un algoritms posmu atlasei no kešatmiņas

Jauns skatuves vārdu ģenerēšanas noteikums. Tagad katra posma versija ģenerē unikālu skatuves nosaukumu, kas sastāv no 2 daļām: paraksta (kā tas bija v1.0 versijā) un unikāla pagaidu identifikatora.

Piemēram, pilnais skatuves attēla nosaukums varētu izskatīties šādi:

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

...vai vispār:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

Здесь:

SIGNATURE ir skatuves paraksts, kas apzīmē skatuves satura identifikatoru un ir atkarīgs no Git rediģēšanas vēstures, kas noveda pie šī satura;
TIMESTAMP_MILLISEC ir garantēts unikāls attēla identifikators, kas tiek ģenerēts jauna attēla izveides laikā.

Algoritms posmu atlasei no kešatmiņas ir balstīts uz Git saistību pārbaudi:

Werf aprēķina noteikta posma parakstu.
В posmi-glabāšana Vienam parakstam var būt vairāki posmi. Werf atlasa visus posmus, kas atbilst parakstam.
Ja pašreizējais posms ir saistīts ar Git (git-arhīvs, pielāgots posms ar Git ielāpiem: install, beforeSetup, setup; vai git-latest-patch), tad werf atlasa tikai tos posmus, kas ir saistīti ar commit, kas ir pašreizējās commit priekštecis (kurai tiek izsaukta būvēšana).
No atlikušajiem piemērotajiem posmiem tiek atlasīts viens - vecākais pēc izveides datuma.

Dažādu Git filiāļu posmam var būt vienāds paraksts. Bet werf neļaus ar dažādām filiālēm saistītās kešatmiņas izmantot starp šīm filiālēm, pat ja paraksti sakrīt.

→ Dokumentācija.

Jauns algoritms posmu izveidei un saglabāšanai skatuves krātuvē

Ja, izvēloties posmus no kešatmiņas, werf neatrod piemērotu posmu, tad tiek uzsākts jauna posma salikšanas process.

Ņemiet vērā, ka vairāki procesi (vienā vai vairākos saimniekdatoros) var sākt veidot vienu un to pašu posmu aptuveni vienā un tajā pašā laikā. Werf izmanto optimistisku bloķēšanas algoritmu posmi-glabāšana svaigi savāktā attēla saglabāšanas brīdī posmi-glabāšana. Tādā veidā, kad jaunā posma būve ir gatava, werf bloki posmi-glabāšana un tur saglabā tikko savākto attēlu tikai tad, ja tur vairs nav piemērota attēla (pēc paraksta un citiem parametriem - skatiet jauno algoritmu posmu atlasei no kešatmiņas).

Svaigi samontētam attēlam tiek garantēts unikāls identifikators TIMESTAMP_MILLISEC (skatiet jauno posmu nosaukumu formātu). Gadījumā, ja iekšā posmi-glabāšana tiks atrasts piemērots attēls, werf atmetīs tikko sastādīto attēlu un izmantos attēlu no kešatmiņas.

Citiem vārdiem sakot: pirmais process, lai pabeigtu attēla veidošanu (ātrākais), iegūs tiesības to uzglabāt pakāpeniski — glabāšana (un pēc tam tas ir viens attēls, kas tiks izmantots visās būvniecībās). Lēns izveides process nekad netraucēs ātrākam procesam saglabāt pašreizējā posma būvēšanas rezultātus un pāriet uz nākamo būvējumu.

→ Dokumentācija.

Uzlabota Dockerfile veidotāja veiktspēja

Pašlaik no Dockerfile veidota attēla posmu cauruļvads sastāv no viena posma - dockerfile. Aprēķinot parakstu, tiek aprēķināta failu kontrolsumma context, kas tiks izmantots montāžas laikā. Pirms šī uzlabojuma werf rekursīvi izstaigāja visus failus un ieguva kontrolsummu, summējot katra faila kontekstu un režīmu. Sākot ar versiju 1.1, werf var izmantot aprēķinātās kontrolsummas, kas tiek glabātas Git repozitorijā.

Algoritms ir balstīts uz git ls-tree. Algoritms ņem vērā ierakstus .dockerignore un rekursīvi šķērso failu koku tikai nepieciešamības gadījumā. Tādējādi mēs esam atsaistīti no failu sistēmas lasīšanas un algoritma atkarības no lieluma context nav nozīmīgs.

Algoritms pārbauda arī neizsekotos failus un, ja nepieciešams, ņem tos vērā kontrolsummā.

Uzlabota veiktspēja, importējot failus

Versijas werf v1.1 izmanto rsync serveri, kad failu importēšana no artefaktiem un attēliem. Iepriekš importēšana tika veikta divos posmos, izmantojot direktorija stiprinājumu no resursdatora sistēmas.

Importēšanas veiktspēju operētājsistēmā MacOS vairs neierobežo Docker apjomi, un importēšana tiek pabeigta tādā pašā laikā kā Linux un Windows.

Satura marķēšana

Werf v1.1 atbalsta tā saukto atzīmēšanu pēc attēla satura — uz saturu balstīta marķēšana. Iegūto Docker attēlu atzīmes ir atkarīgas no šo attēlu satura.

Palaižot komandu werf publish --tags-by-stages-signature vai werf ci-env --tagging-strategy=stages-signature publicēti attēli t.s skatuves paraksts attēlu. Katrs attēls ir atzīmēts ar savu šī attēla posmu parakstu, kas tiek aprēķināts saskaņā ar tiem pašiem noteikumiem kā katra posma parastais paraksts atsevišķi, bet ir attēla vispārējs identifikators.

Attēla posmu paraksts ir atkarīgs no:

šī attēla saturs;
Git izmaiņu vēsture, kas noveda pie šī satura.

Git repozitorijā vienmēr ir fiktīvas saistības, kas nemaina attēlu failu saturu. Piemēram, izpilda tikai ar komentāriem vai sapludināšanas darbības, vai izpildes, kas maina tos Git failus, kas netiks importēti attēlā.

Lietojot uz saturu balstītu tagu pievienošanu, tiek atrisinātas problēmas, kas saistītas ar Kubernetes lietojumprogrammu aplikāciju nevajadzīgu restartēšanu attēla nosaukuma izmaiņu dēļ, pat ja attēla saturs nav mainījies. Starp citu, tas ir viens no iemesliem, kas neļauj vienā Git repozitorijā uzglabāt daudzus vienas lietojumprogrammas mikropakalpojumus.

Tāpat uz saturu balstīta marķēšana ir uzticamāka tagu pievienošanas metode nekā tagu pievienošana Git zaros, jo iegūto attēlu saturs nav atkarīgs no secības, kādā CI sistēmā tiek izpildīti konveijeri vairāku vienas un tās pašas filiāles commit montāžai.

Tas ir svarīgi: sākot no šī brīža posmi-paraksts -Šo vienīgā ieteicamā marķēšanas stratēģija. Komandā tas tiks izmantots pēc noklusējuma werf ci-env (ja vien jūs nepārprotami norādāt citu marķēšanas shēmu).

→ Dokumentācija. Šai funkcijai tiks veltīta arī atsevišķa publikācija. ATJAUNINĀTS (3. aprīlis): raksts ar detaļām publicēts.

Mežizstrādes līmeņi

Lietotājam tagad ir iespēja kontrolēt izvadi, iestatīt reģistrēšanas līmeni un strādāt ar atkļūdošanas informāciju. Opcijas ir pievienotas --log-quiet, --log-verbose, --log-debug.

Pēc noklusējuma izvade satur minimālo informāciju:

Lietojot detalizētu izvadi (--log-verbose) varat redzēt, kā darbojas werf:

Detalizēta izvade (--log-debug), papildus werf atkļūdošanas informācijai satur arī izmantoto bibliotēku žurnālus. Piemēram, varat redzēt, kā notiek mijiedarbība ar Docker reģistru, kā arī reģistrēt vietas, kur tiek pavadīts ievērojams laiks:

Nākotnes plāni

Uzmanību! Tālāk aprakstītās opcijas ir atzīmētas v1.1 būs pieejams šajā versijā, daudzas no tām tuvākajā nākotnē. Atjauninājumi tiks nodrošināti, izmantojot automātiskos atjauninājumus izmantojot multiwerf. Šīs funkcijas neietekmē v1.1 funkciju stabilo daļu; to parādīšanai nav nepieciešama manuāla lietotāja iejaukšanās esošajās konfigurācijās.

Pilns atbalsts dažādām Docker Registry implementācijām (JAUNS)

Versija: v1.1
Datumi: marts
Izdot

Mērķis ir, lai lietotājs bez ierobežojumiem izmantotu pielāgotu ieviešanu, izmantojot werf.

Pašlaik mēs esam identificējuši šādu risinājumu kopumu, kuriem mēs garantējam pilnīgu atbalstu:

Noklusējums (bibliotēka/reģistrs)*,
AWS ECR
debeszils*,
Docker Hub
GCR*,
GitHub pakotnes
GitLab reģistrs*,
Osta*,
Piestātne.

Risinājumi, kurus pašlaik pilnībā atbalsta werf, ir atzīmēti ar zvaigznīti. Citiem ir atbalsts, bet ar ierobežojumiem.

Var identificēt divas galvenās problēmas:

Daži risinājumi neatbalsta tagu noņemšanu, izmantojot Docker reģistra API, neļaujot lietotājiem izmantot werf automātisko tīrīšanu. Tas attiecas uz AWS ECR, Docker Hub un GitHub pakotnēm.
Daži risinājumi neatbalsta tā sauktos ligzdotos repozitorijus (Docker Hub, GitHub Packages un Quay) vai atbalsta, taču lietotājam tie ir jāizveido manuāli, izmantojot lietotāja saskarni vai API (AWS ECR).

Mēs atrisināsim šīs un citas problēmas, izmantojot risinājumu vietējās API. Šis uzdevums ietver arī pilna werf darbības cikla aptveršanu ar testiem katram no tiem.

Izplatītā attēla izveide (↑)

Versija: v1.2 v1.1 (šīs funkcijas ieviešanas prioritāte ir palielināta)
Datumi: marts-aprīlis marts
Izdot

Pašlaik werf v1.0 un v1.1 var izmantot tikai vienā īpašā resursdatorā attēlu veidošanai un publicēšanai un lietojumprogrammas izvietošanai Kubernetes.

Lai atvērtu werf izkliedētā darba iespējas, kad Kubernetes lietojumprogrammu būvēšana un izvietošana tiek palaista uz vairākiem patvaļīgiem resursdatoriem un šie resursdatori nesaglabā savu stāvokli starp būvēm (pagaidu skrējēji), werf ir jāievieš iespēja izmantot Docker Registry kā skatuves veikals.

Iepriekš, kad werf projekts vēl saucās dapp, tam bija tāda iespēja. Tomēr mēs esam saskārušies ar vairākām problēmām, kas jāņem vērā, ieviešot šo funkcionalitāti werf.

Piezīme. Šī funkcija neprasa, lai kolektors darbotos Kubernetes podiņos, jo Lai to izdarītu, jums ir jāatbrīvojas no atkarības no vietējā Docker servera (Kubernetes podā nav piekļuves vietējam Docker serverim, jo pats process darbojas konteinerā, un werf neatbalsta un neatbalstīs darbs ar Docker serveri tīklā). Atbalsts Kubernetes darbībai tiks īstenots atsevišķi.

Oficiālais atbalsts GitHub darbībām (JAUNS)

Versija: v1.1
Datumi: marts
Izdot

Ietver werf dokumentāciju (sadaļas atsauce и vadīt), kā arī oficiālā GitHub darbība darbam ar werf.

Turklāt tas ļaus werf strādāt ar īslaicīgiem skrējējiem.

Lietotāju mijiedarbības mehānika ar CI sistēmu būs balstīta uz iezīmju izvietošanu uz izvilkšanas pieprasījumiem, lai uzsāktu noteiktas darbības lietojumprogrammas izveidei/izvēršanai.

Vietējā lietojumprogrammu izstrāde un izvietošana ar werf (↓)

Versija: v1.1
Datumi: janvāris-februāris aprīlis
Izdot

Galvenais mērķis ir panākt vienotu unificētu konfigurāciju lietojumprogrammu izvietošanai gan lokāli, gan ražošanā, bez sarežģītām darbībām.

werf ir nepieciešams arī darbības režīms, kurā būs ērti rediģēt lietojumprogrammas kodu un uzreiz saņemt atgriezenisko saiti no darbojošās lietojumprogrammas atkļūdošanai.

Jauns tīrīšanas algoritms (JAUNS)

Versija: v1.1
Datumi: aprīlis
Izdot

Pašreizējā versijā werf v1.1 procedūrā cleanup Satura iezīmēšanas shēmā attēlu tīrīšana nav paredzēta — šie attēli tiks uzkrāti.

Arī pašreizējā werf versijā (v1.0 un v1.1) tiek izmantotas dažādas tīrīšanas politikas attēliem, kas publicēti saskaņā ar tagu piešķiršanas shēmām: Git branch, Git tag vai Git commit.

Ir izgudrots jauns algoritms attēlu tīrīšanai, pamatojoties uz Git saistību vēsturi, kas ir vienots visām marķēšanas shēmām:

Saglabājiet ne vairāk kā N1 attēlus, kas saistīti ar N2 jaunākajām saistībām katram git HEAD (zariem un tagiem).
Saglabājiet ne vairāk kā N1 posma attēlus, kas saistīti ar N2 jaunākajām saistībām katram git HEAD (zariem un tagiem).
Saglabājiet visus attēlus, kas tiek izmantoti jebkurā Kubernetes klastera resursos (tiek skenēti visi konfigurācijas faila kube konteksti un nosaukumvietas; varat ierobežot šo darbību ar īpašām opcijām).
Saglabājiet visus attēlus, kas tiek izmantoti resursu konfigurācijas manifestos, kas saglabāti Helm laidienos.
Attēlu var dzēst, ja tas nav saistīts ar nevienu HEAD no git (piemēram, tāpēc, ka tika dzēsta pati atbilstošā HEAD) un netiek izmantota nevienā Kubernetes klastera un Helm izlaidumos.

Paralēlā attēla veidošana (↓)

Versija: v1.1
Datumi: janvāris-februāris aprīlis*

Pašreizējā werf versija apkopo attēlus un artefaktus, kas aprakstīti werf.yaml, secīgi. Nepieciešams paralēli veidot neatkarīgu attēlu un artefaktu posmu salikšanas procesu, kā arī nodrošināt ērtu un informatīvu izvadi.

* Piezīme: termiņš ir pārcelts, jo ir palielināta prioritāte izplatītās montāžas ieviešanai, kas papildinās horizontālās mērogošanas iespējas, kā arī werf izmantošana ar GitHub Actions. Paralēlā montāža ir nākamais optimizācijas solis, kas nodrošina vertikālu mērogojamību, montējot vienu projektu.

Pāreja uz Helm 3 (↓)

Versija: v1.2
Datumi: februāris - marts maijs*

Ietver migrāciju uz jaunu kodu bāzi Stūre 3 un pārbaudīts, ērts veids, kā migrēt esošās iekārtas.

* Piezīme: pārejot uz Helm 3, werf netiks pievienotas nozīmīgas funkcijas, jo visas Helm 3 galvenās funkcijas (trīsvirzienu sapludināšana un bez stūres) jau ir ieviestas werf. Turklāt werf ir papildus iespējas papildus norādītajiem. Taču šī pāreja joprojām ir mūsu plānos un tiks īstenota.

Jsonnet, lai aprakstītu Kubernetes konfigurāciju (↓)

Versija: v1.2
Datumi: janvāris-februāris aprīlis-maijs

Werf atbalstīs Kubernetes konfigurācijas aprakstus Jsonnet formātā. Tajā pašā laikā werf joprojām būs saderīgs ar Helm un būs iespēja izvēlēties apraksta formātu.

Iemesls ir tāds, ka Go veidnēm, pēc daudzu cilvēku domām, ir augsta ienākšanas barjera, un cieš arī šo veidņu koda saprotamība.

Tiek apsvērta arī iespēja ieviest citas Kubernetes konfigurācijas aprakstu sistēmas (piemēram, Kustomize).

Darbs Kubernetes (↓)

Versija: v1.2
Datumi: aprīlis-maijs maijs-jūnijs

Mērķis: nodrošināt, lai attēli tiktu veidoti un lietojumprogramma tiktu piegādāta, izmantojot Kubernetes skrējējus. Tie. Jaunus attēlus var izveidot, publicēt, notīrīt un izvietot tieši no Kubernetes podiem.

Lai īstenotu šo iespēju, vispirms ir jāspēj izveidot izplatītus attēlus (skat. punktu augstāk).

Tam ir nepieciešams arī atbalsts veidotāja darbības režīmam bez Docker servera (t.i., Kaniko līdzīga konstrukcija vai uzbūve lietotāja telpā).

Werf atbalstīs Kubernetes būvniecību ne tikai ar Dockerfile, bet arī ar savu Stapel veidotāju, veicot pakāpenisku pārbūvi un Ansible.

Solis pretī atvērtai attīstībai

Mēs mīlam savu kopienu (GitHub, Telegram), un mēs vēlamies, lai arvien vairāk cilvēku palīdzētu uzlabot werf, izprastu virzienu, kurā mēs virzāmies, un piedalās attīstībā.

Pavisam nesen tika nolemts pāriet uz GitHub projektu dēļi lai atklātu mūsu komandas darba procesu. Tagad jūs varat redzēt tuvākos plānus, kā arī pašreizējos darbus šādās jomās:

Ir daudz strādāts ar problēmām:

Noņemti neatbilstošie.
Esošie ir sakārtoti vienotā formātā, ar pietiekamu skaitu detaļu un detaļu.
Ir pievienoti jauni jautājumi ar idejām un ieteikumiem.

Kā iespējot versiju v1.1

Versija pašlaik ir pieejama valodā kanāls 1.1 ea (kanālos stabils и ciets kā akmens izlaidumi parādīsies, kad notiks stabilizācija ea pati jau ir pietiekami stabila lietošanai, jo gāja pa kanāliem alfa и beta). Aktivizēts caur multiwerf šādā veidā:

source $(multiwerf use 1.1 ea)
werf COMMAND ...

Secinājums

Jaunā stadijas krātuves arhitektūra un veidotāju optimizācija Stapel un Dockerfile veidotājiem paver iespēju werf ieviest izplatītas un paralēlas versijas. Šīs funkcijas drīzumā parādīsies tajā pašā v1.1 laidienā un kļūs automātiski pieejamas, izmantojot automātiskās atjaunināšanas mehānismu (lietotājiem multiwerf).

Šajā laidienā ir pievienota marķēšanas stratēģija, kuras pamatā ir attēla saturs. uz saturu balstīta marķēšana, kas ir kļuvusi par noklusējuma stratēģiju. Galvenais komandu žurnāls ir arī pārstrādāts: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

Nākamais nozīmīgais solis ir sadalīto mezglu pievienošana. Kopš versijas 1.0 izplatītās versijas ir kļuvušas par augstāku prioritāti nekā paralēlās versijas, jo tās werf piešķir lielāku vērtību: veidotāju vertikālā mērogošana un atbalsts īslaicīgiem veidotājiem dažādās CI/CD sistēmās, kā arī iespēja sniegt oficiālu atbalstu GitHub darbībām. . Tāpēc paralēlo montāžu ieviešanas termiņi tika pārcelti. Tomēr mēs strādājam, lai pēc iespējas ātrāk īstenotu abas iespējas.

Sekojiet jaunumiem! Un neaizmirstiet mūs apmeklēt plkst GitHublai izveidotu problēmu, atrodiet esošu un pievienojiet plusu, izveidojiet PR vai vienkārši vērojiet projekta attīstību.