ProHoster > Blogs > Administrācija > werf 1.1 laidiens: bÅ«vētāja uzlabojumi Å”odien un nākotnes plāni

werf 1.1 laidiens: bÅ«vētāja uzlabojumi Å”odien un nākotnes plāni

werf 1.1 laidiens: bÅ«vētāja 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:

  1. Werf aprēķina noteikta posma parakstu.
  2. Š’ posmi-glabāŔana Vienam parakstam var bÅ«t vairāki posmi. Werf atlasa visus posmus, kas atbilst parakstam.
  3. 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).
  4. 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:

  1. Ŕī attēla saturs;
  2. 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:

werf 1.1 laidiens: bÅ«vētāja uzlabojumi Å”odien un nākotnes plāni

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

werf 1.1 laidiens: bÅ«vētāja uzlabojumi Å”odien un nākotnes plāni

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:

werf 1.1 laidiens: bÅ«vētāja uzlabojumi Å”odien un nākotnes plāni

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.

PS

Lasi arī mūsu emuārā:

Avots: www.habr.com

Pievieno komentāru