ni chanzo huria chetu cha matumizi ya GitOps CLI kwa ajili ya kujenga na kuwasilisha maombi kwa Kubernetes. Kama alivyoahidi, iliashiria mwanzo wa kuongeza vipengele vipya kwenye werf na kurekebisha mbinu za kitamaduni. Sasa tuna furaha kuwasilisha toleo la v1.1, ambalo ni hatua kubwa katika maendeleo na msingi wa siku zijazo mtoza werf. Toleo hilo linapatikana kwa sasa .
Msingi wa kutolewa ni usanifu mpya wa uhifadhi wa hatua na uboreshaji wa kazi ya watoza wote wawili (kwa Stapel na Dockerfile). Usanifu mpya wa hifadhi hufungua uwezekano wa kutekeleza makusanyiko yaliyosambazwa kutoka kwa majeshi mengi na makusanyiko ya sambamba kwenye mwenyeji mmoja.
Uboreshaji wa kazi ni pamoja na kuondoa mahesabu yasiyo ya lazima katika hatua ya kuhesabu saini za hatua na kubadilisha mifumo ya kuhesabu ukaguzi wa faili kuwa bora zaidi. Uboreshaji huu hupunguza muda wa wastani wa ujenzi wa mradi kwa kutumia werf. Na bila kazi hujenga, wakati hatua zote zipo kwenye kache hatua - kuhifadhi, sasa ziko haraka sana. Mara nyingi, kuanzisha upya ujenzi itachukua chini ya sekunde 1! Hii inatumika pia kwa taratibu za kuthibitisha hatua katika mchakato wa kazi ya timu. werf deploy ΠΈ werf run.
Pia katika toleo hili, mkakati wa kuweka tagi kwa yaliyomo ulionekana - uwekaji tagi kulingana na yaliyomo, ambayo sasa imewezeshwa kwa chaguo-msingi na pekee inayopendekezwa.
Hebu tuchunguze kwa undani zaidi uvumbuzi muhimu katika werf v1.1, na wakati huo huo kukuambia kuhusu mipango ya siku zijazo.
Ni nini kimebadilika katika werf v1.1?
Umbizo mpya la hatua ya kumtaja na algorithm ya kuchagua hatua kutoka kwa akiba
Sheria mpya ya kizazi cha jina la hatua. Sasa kila muundo wa hatua hutoa jina la kipekee la hatua, ambalo lina sehemu 2: saini (kama ilivyokuwa katika v1.0) pamoja na kitambulisho cha kipekee cha muda.
Kwa mfano, jina la picha ya hatua kamili linaweza kuonekana kama hii:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
... au kwa ujumla:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Hapa:
-
SIGNATUREni saini ya hatua, ambayo inawakilisha kitambulisho cha maudhui ya jukwaa na inategemea historia ya mabadiliko katika Git ambayo yalisababisha maudhui haya; -
TIMESTAMP_MILLISECni kitambulisho cha kipekee cha picha ambacho kinatolewa wakati picha mpya inapoundwa.
Algorithm ya kuchagua hatua kutoka kwa kache ni msingi wa kuangalia uhusiano wa ahadi za Git:
- Werf huhesabu saini ya hatua fulani.
- Π hatua - kuhifadhi Kunaweza kuwa na hatua kadhaa za saini fulani. Werf huchagua hatua zote zinazolingana na sahihi.
- Ikiwa hatua ya sasa imeunganishwa na Git (jalada la git, hatua maalum na viraka vya Git:
install,beforeSetup,setup; au git-latest-patch), basi werf huchagua tu hatua zile ambazo zinahusishwa na ahadi ambayo ni babu wa ahadi ya sasa (ambayo jengo hilo linaitwa). - Kutoka kwa hatua zilizobaki zinazofaa, moja huchaguliwa - ya zamani zaidi kwa tarehe ya uumbaji.
Hatua ya matawi tofauti ya Git inaweza kuwa na saini sawa. Lakini werf itazuia akiba inayohusishwa na matawi tofauti kutumiwa kati ya matawi haya, hata kama saini zinalingana.
.
Algorithm mpya ya kuunda na kuhifadhi hatua katika uhifadhi wa hatua
Ikiwa, wakati wa kuchagua hatua kutoka kwa cache, werf haipati hatua inayofaa, basi mchakato wa kukusanya hatua mpya umeanzishwa.
Kumbuka kuwa michakato mingi (kwenye seva pangishi moja au zaidi) inaweza kuanza kujenga hatua sawa kwa takriban wakati mmoja. Werf hutumia algorithm yenye matumaini ya kuzuia hatua - kuhifadhi wakati wa kuhifadhi picha mpya iliyokusanywa hatua - kuhifadhi. Kwa njia hii, wakati ujenzi wa hatua mpya uko tayari, werf blocks hatua - kuhifadhi na huhifadhi picha mpya iliyokusanywa pale tu ikiwa picha inayofaa haipo tena hapo (kwa saini na vigezo vingine - tazama algorithm mpya ya kuchagua hatua kutoka kwa kache).
Picha mpya iliyokusanywa imehakikishiwa kuwa na kitambulisho cha kipekee kwa TIMESTAMP_MILLISEC (tazama muundo mpya wa kumtaja hatua). Katika kesi katika hatua - kuhifadhi picha inayofaa itapatikana, werf itatupa picha mpya iliyokusanywa na itatumia picha kutoka kwa kache.
Kwa maneno mengine: mchakato wa kwanza wa kumaliza kujenga picha (ya haraka zaidi) utapata haki ya kuihifadhi katika hatua za uhifadhi (na kisha ni picha hii moja ambayo itatumika kwa miundo yote). Mchakato wa kujenga polepole hautawahi kuzuia mchakato wa haraka kutoka kwa kuhifadhi matokeo ya muundo wa hatua ya sasa na kuendelea hadi muundo unaofuata.
.
Utendaji ulioboreshwa wa mjenzi wa Dockerfile
Kwa sasa, bomba la hatua za picha iliyojengwa kutoka kwa Dockerfile lina hatua moja - dockerfile. Wakati wa kuhesabu saini, hundi ya faili imehesabiwa context, ambayo itatumika wakati wa kusanyiko. Kabla ya uboreshaji huu, werf ilipitia faili zote kwa kujirudia rudia na kupata hundi kwa kujumlisha muktadha na hali ya kila faili. Kuanzia na v1.1, werf inaweza kutumia hundi zilizokokotolewa zilizohifadhiwa kwenye hazina ya Git.
Algorithm inategemea . Algorithm inazingatia rekodi katika .dockerignore na hupitia mti wa faili kwa kujirudia tu inapobidi. Kwa hivyo, tumetengana kutoka kwa kusoma mfumo wa faili, na utegemezi wa algorithm kwenye saizi context sio muhimu.
Algorithm pia huangalia faili ambazo hazijafuatiliwa na, ikiwa ni lazima, inazizingatia katika hundi.
Utendaji ulioboreshwa wakati wa kuingiza faili
Matoleo ya werf v1.1 hutumia seva ya rsync wakati . Hapo awali, kuagiza kulifanyika kwa hatua mbili kwa kutumia mpangilio wa saraka kutoka kwa mfumo wa mwenyeji.
Utendaji wa kuingiza kwenye macOS hauzuiliwi tena na viwango vya Docker, na uagizaji hukamilika kwa muda sawa na Linux na Windows.
Uwekaji lebo kulingana na yaliyomo
Werf v1.1 inasaidia kinachojulikana kama tagging na yaliyomo kwenye picha - uwekaji tagi kulingana na yaliyomo. Lebo za picha zinazotokana za Docker hutegemea yaliyomo kwenye picha hizo.
Wakati wa kuendesha amri werf publish --tags-by-stages-signature au werf ci-env --tagging-strategy=stages-signature kuchapishwa picha za kinachojulikana saini ya hatua picha. Kila picha imetambulishwa na saini yake ya hatua za picha hii, ambayo imehesabiwa kulingana na sheria sawa na saini ya kawaida ya kila hatua tofauti, lakini ni kitambulisho cha jumla cha picha.
Saini ya hatua za picha inategemea:
- yaliyomo kwenye picha hii;
- historia za mabadiliko ya Git ambayo yalisababisha maudhui haya.
Jalada la Git kila wakati lina ahadi za dummy ambazo hazibadilishi yaliyomo kwenye faili za picha. Kwa mfano, ahadi na maoni pekee au ahadi za kuunganisha, au ahadi zinazobadilisha faili hizo kwenye Git ambazo hazitaingizwa kwenye picha.
Unapotumia tagi kulingana na yaliyomo, shida za kuanza tena bila lazima kwa ganda la programu katika Kubernetes kwa sababu ya mabadiliko ya jina la picha hutatuliwa, hata kama yaliyomo kwenye picha hayajabadilika. Kwa njia, hii ni moja ya sababu zinazozuia kuhifadhi microservices nyingi za programu moja kwenye hazina moja ya Git.
Pia, uwekaji tagi kulingana na yaliyomo ni njia inayoaminika zaidi ya kuweka lebo kuliko kuweka tagi kwenye matawi ya Git, kwa sababu maudhui ya picha zinazotokana hayategemei mpangilio ambao mabomba yanatekelezwa katika mfumo wa CI wa kukusanya kazi nyingi za tawi moja.
Ni muhimu: kuanzia sasa hatua - saini - Je, mkakati pekee uliopendekezwa wa kuweka alama. Itatumika kwa chaguo-msingi katika amri werf ci-env (isipokuwa utabainisha wazi mpango tofauti wa kuweka lebo).
. Chapisho tofauti pia litatolewa kwa kipengele hiki. IMESASISHA (Aprili 3): Makala yenye maelezo .
Viwango vya ukataji miti
Mtumiaji sasa ana nafasi ya kudhibiti pato, kuweka kiwango cha ukataji miti na kufanya kazi na habari ya utatuzi. Chaguo zimeongezwa --log-quiet, --log-verbose, --log-debug.
Kwa chaguo-msingi, pato lina habari ya chini zaidi:
Wakati wa kutumia pato la kitenzi (--log-verbose) unaweza kuona jinsi werf inavyofanya kazi:
Matokeo ya kina (--log-debug), pamoja na maelezo ya utatuzi wa werf, pia ina kumbukumbu za maktaba zilizotumika. Kwa mfano, unaweza kuona jinsi mwingiliano na Usajili wa Docker hutokea, na pia rekodi mahali ambapo kiasi kikubwa cha muda kinatumika:
Mipango ya baadaye
Attention! Chaguzi zilizoelezwa hapa chini zimewekwa alama v1.1 itapatikana katika toleo hili, nyingi kati yao katika siku za usoni. Masasisho yatakuja kupitia masasisho ya kiotomatiki . Vipengele hivi haviathiri sehemu thabiti ya chaguo za kukokotoa za v1.1; mwonekano wao hautahitaji uingiliaji wa kibinafsi wa mtumiaji katika usanidi uliopo.
Usaidizi kamili kwa utekelezaji mbalimbali wa Usajili wa Docker (MPYA)
- Toleo: v1.1
- Tarehe: Machi
Lengo ni kwa mtumiaji kutumia utekelezaji maalum bila vikwazo wakati wa kutumia werf.
Kwa sasa, tumetambua seti ifuatayo ya masuluhisho ambayo tutakuhakikishia usaidizi kamili:
- Chaguomsingi (maktaba/sajili)*,
- AWS ECR
- Azure*,
- Docker Hub
- GCR*,
- Vifurushi vya GitHub
- Usajili wa GitLab*,
- Bandari*,
- Quay.
Masuluhisho ambayo kwa sasa yanaauniwa kikamilifu na werf yana alama ya nyota. Kwa wengine kuna msaada, lakini kwa mapungufu.
Shida mbili kuu zinaweza kutambuliwa:
- Suluhu zingine haziauni uondoaji wa lebo kwa kutumia API ya Usajili wa Docker, kuzuia watumiaji kutumia usafishaji kiotomatiki wa werf. Hii ni kweli kwa AWS ECR, Docker Hub, na GitHub Packages.
- Suluhu zingine hazitumii zinazoitwa hazina zilizowekwa (Docker Hub, GitHub Packages na Quay) au hufanya hivyo, lakini ni lazima mtumiaji aziunde mwenyewe kwa kutumia UI au API (AWS ECR).
Tutasuluhisha shida hizi na zingine kwa kutumia API asili za suluhisho. Kazi hii pia inajumuisha kufunika mzunguko kamili wa operesheni ya werf na majaribio kwa kila moja yao.
Muundo wa picha uliosambazwa (β)
- Toleo: v1.2 v1.1 (kipaumbele cha kutekeleza kipengele hiki kimeongezwa)
- Tarehe: Machi-Aprili Machi
Kwa sasa, werf v1.0 na v1.1 inaweza kutumika tu kwa seva pangishi moja iliyojitolea kwa shughuli za kujenga na kuchapisha picha na kupeleka programu kwa Kubernetes.
Ili kufungua uwezekano wa kazi iliyosambazwa ya werf, wakati ujenzi na upelekaji wa programu katika Kubernetes zinapozinduliwa kwa majeshi kadhaa ya kiholela na majeshi haya hayahifadhi hali yao kati ya kujenga (wakimbiaji wa muda), werf inahitajika kutekeleza uwezo wa kutumia. Usajili wa Docker kama duka la hatua.
Hapo awali, wakati mradi wa werf ulikuwa bado unaitwa dapp, ulikuwa na fursa kama hiyo. Hata hivyo, tumekumbana na masuala kadhaa ambayo yanahitaji kuzingatiwa wakati wa kutekeleza utendakazi huu katika werf.
Kumbuka. Kipengele hiki hakihitaji mtoza kufanya kazi ndani ya maganda ya Kubernetes, kwa sababu Ili kufanya hivyo, unahitaji kuondokana na utegemezi wa seva ya Docker ya ndani (kwenye ganda la Kubernetes hakuna ufikiaji wa seva ya Docker ya ndani, kwa sababu mchakato yenyewe unaendesha kwenye chombo, na werf haifanyi na haitaunga mkono. kufanya kazi na seva ya Docker kwenye mtandao). Usaidizi wa kuendesha Kubernetes utatekelezwa tofauti.
Usaidizi rasmi wa Vitendo vya GitHub (MPYA)
- Toleo: v1.1
- Tarehe: Machi
Inajumuisha nyaraka za werf (sehemu kumbukumbu ΠΈ kuongoza), na vile vile Kitendo rasmi cha GitHub cha kufanya kazi na werf.
Kwa kuongeza, itaruhusu werf kufanya kazi kwa wakimbiaji wa ephemeral.
Mitindo ya mwingiliano wa watumiaji na mfumo wa CI itatokana na kuweka lebo kwenye maombi ya kuvuta ili kuanzisha vitendo fulani vya kuunda/kusambaza programu.
Ukuzaji wa ndani na usambazaji wa programu na werf (β)
- Toleo: v1.1
- Tarehe: Januari-Februari Aprili
Lengo kuu ni kufikia usanidi mmoja uliounganishwa wa kupeleka programu ndani ya nchi na katika uzalishaji, bila vitendo changamano, nje ya boksi.
werf pia inahitajika kuwa na hali ya kufanya kazi ambayo itakuwa rahisi kuhariri msimbo wa programu na kupokea maoni mara moja kutoka kwa programu inayoendesha ya utatuzi.
Kanuni mpya ya kusafisha (MPYA)
- Toleo: v1.1
- Tarehe: Aprili
Katika toleo la sasa la werf v1.1 katika utaratibu cleanup Hakuna kipengele cha kusafisha picha kwa mpango wa kuweka lebo kulingana na maudhui - picha hizi zitajilimbikiza.
Pia, toleo la sasa la werf (v1.0 na v1.1) hutumia sera tofauti za kusafisha kwa picha zilizochapishwa chini ya mipango ya kuweka lebo: Tawi la Git, Git tag au ahadi ya Git.
Algorithm mpya ya kusafisha picha kulingana na historia ya ahadi katika Git, iliyounganishwa kwa miradi yote ya kuweka lebo, imevumbuliwa:
- Usiweke zaidi ya picha za N1 zinazohusishwa na ahadi za hivi majuzi zaidi za N2 kwa kila git HEAD (matawi na vitambulisho).
- Hifadhi si zaidi ya picha za hatua ya N1 zinazohusiana na ahadi za hivi majuzi zaidi za N2 kwa kila git HEAD (matawi na lebo).
- Hifadhi picha zote zinazotumika katika nyenzo zozote za kundi la Kubernetes (miktadha yote ya kube ya faili ya usanidi na nafasi za majina huchanganuliwa; unaweza kudhibiti tabia hii kwa chaguo maalum).
- Hifadhi picha zote zinazotumika katika faili za usanidi wa rasilimali zilizohifadhiwa katika matoleo ya Helm.
- Picha inaweza kufutwa ikiwa haijahusishwa na HEAD yoyote kutoka kwa git (kwa mfano, kwa sababu HEAD inayolingana yenyewe ilifutwa) na haitumiki katika maonyesho yoyote katika kundi la Kubernetes na katika matoleo ya Helm.
Jengo la picha sambamba (β)
- Toleo: v1.1
- Tarehe: Januari-Februari Aprili*
Toleo la sasa la werf hukusanya picha na vizalia vya programu vilivyofafanuliwa ndani werf.yaml, mfululizo. Inahitajika kusawazisha mchakato wa kukusanya hatua za kujitegemea za picha na mabaki, na pia kutoa matokeo rahisi na ya habari.
* Kumbuka: tarehe ya mwisho imebadilishwa kwa sababu ya kuongezeka kwa kipaumbele kwa utekelezaji wa mkusanyiko uliosambazwa, ambayo itaongeza uwezo zaidi wa kuongeza usawa, pamoja na matumizi ya werf na Vitendo vya GitHub. Mkusanyiko sambamba ni hatua inayofuata ya uboreshaji, ikitoa uwekaji wima wakati wa kuunganisha mradi mmoja.
Mpito hadi kwenye Helm 3 (β)
- Toleo: v1.2
- Tarehe: Februari-Machi Mei*
Inajumuisha uhamishaji hadi msingi mpya wa msimbo na njia iliyothibitishwa na rahisi ya kuhamisha usakinishaji uliopo.
* Kumbuka: kubadili Helm 3 hakutaongeza vipengele muhimu kwenye werf, kwa sababu vipengele vyote muhimu vya Helm 3 (3-way-merge and no no tiller) tayari vinatekelezwa katika werf. Zaidi ya hayo, werf ina pamoja na zile zilizoonyeshwa. Hata hivyo, mpito huu unabaki katika mipango yetu na utatekelezwa.
Jsonnet kwa kuelezea usanidi wa Kubernetes (β)
- Toleo: v1.2
- Tarehe: Januari-Februari Aprili-Mei
Werf itasaidia maelezo ya usanidi wa Kubernetes katika umbizo la Jsonnet. Wakati huo huo, werf itasalia sambamba na Helm na kutakuwa na chaguo la umbizo la maelezo.
Sababu ni kwamba templates za Go, kulingana na watu wengi, zina kizuizi cha juu cha kuingia, na uelewa wa kanuni za templates hizi pia huteseka.
Uwezekano wa kuanzisha mifumo mingine ya maelezo ya usanidi wa Kubernetes (kwa mfano, Kustomize) pia inazingatiwa.
Hufanya kazi Kubernetes (β)
- Toleo: v1.2
- Tarehe: Aprili-Mei Mei-Juni
Lengo: Hakikisha kuwa picha zimeundwa na programu inawasilishwa kwa kutumia waendeshaji katika Kubernetes. Wale. Picha mpya zinaweza kutengenezwa, kuchapishwa, kusafishwa na kutumwa moja kwa moja kutoka kwa maganda ya Kubernetes.
Ili kutekeleza uwezo huu, kwanza unahitaji kuwa na uwezo wa kuunda picha zinazosambazwa (tazama nukta hapo juu).
Inahitaji pia usaidizi wa hali ya uendeshaji ya mjenzi bila seva ya Docker (yaani, kama Kaniko kujenga au kujenga katika nafasi ya mtumiaji).
Werf itasaidia ujenzi wa Kubernetes sio tu na Dockerfile, lakini pia na mjenzi wake wa Stapel na ujenzi wa nyongeza na Ansible.
Hatua kuelekea maendeleo ya wazi
Tunaipenda jamii yetu (, ) na tunataka watu zaidi na zaidi wasaidie kufanya werf kuwa bora zaidi, kuelewa mwelekeo tunakoelekea, na kushiriki katika maendeleo.
Hivi majuzi iliamuliwa kubadili ili kufichua mchakato wa kazi wa timu yetu. Sasa unaweza kuona mipango ya haraka, pamoja na kazi ya sasa katika maeneo yafuatayo:
- ;
- ;
- ;
- .
Kazi nyingi zimefanywa na masuala:
- Imeondolewa zisizo na maana.
- Vile vilivyopo vinaletwa kwa muundo mmoja, na idadi ya kutosha ya maelezo na maelezo.
- Masuala mapya yenye mawazo na mapendekezo yameongezwa.
Jinsi ya kuwezesha toleo la v1.1
Toleo hilo linapatikana kwa sasa (katika chaneli imara ΠΈ mwamba-imara matoleo yataonekana kadri uimarishaji unavyotokea, hata hivyo ea yenyewe tayari ni ya kutosha kwa matumizi, kwa sababu alipitia chaneli alpha ΠΈ beta) Imewashwa kwa njia ifuatayo:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Hitimisho
Usanifu mpya wa uhifadhi wa hatua na uboreshaji wa wajenzi kwa wajenzi wa Stapel na Dockerfile hufungua uwezekano wa kutekeleza ujenzi uliosambazwa na sambamba katika werf. Vipengele hivi vitaonekana katika toleo lile lile la v1.1 hivi karibuni na vitapatikana kiotomatiki kupitia utaratibu wa kusasisha kiotomatiki (kwa watumiaji. ).
Katika toleo hili, mkakati wa kuweka lebo kulingana na maudhui ya picha umeongezwa - uwekaji tagi kulingana na yaliyomo, ambayo imekuwa mkakati chaguo-msingi. Logi kuu ya amri pia imefanywa upya: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
Hatua inayofuata muhimu ni kuongeza makusanyiko yaliyosambazwa. Miundo iliyosambazwa imekuwa kipaumbele cha juu zaidi kuliko ujenzi sambamba tangu v1.0 kwa sababu zinaongeza thamani zaidi kwa werf: kuongeza wima kwa wajenzi na usaidizi wa wajenzi wa ephemeral katika mifumo mbalimbali ya CI/CD, na pia uwezo wa kutoa msaada rasmi kwa Vitendo vya GitHub. . Kwa hiyo, muda wa mwisho wa utekelezaji wa makusanyiko sambamba yalibadilishwa. Hata hivyo, tunajitahidi kutekeleza uwezekano wote wawili haraka iwezekanavyo.
Fuata habari! Na usisahau kututembelea ili kuunda suala, pata lililopo na uongeze nyongeza, unda PR, au tazama tu maendeleo ya mradi.
PS
Soma pia kwenye blogi yetu:
- «»
- Β«";
- Msururu wa maelezo kuhusu uvumbuzi katika werf:
- Β«";
- Β«";
- Β«";
- Β«'.
Chanzo: mapenzi.com