estas nia malfermfonta GitOps CLI-ilaĵo por konstrui kaj liveri aplikojn al Kubernetes. Kiel promesite, markis la komencon de aldonado de novaj funkcioj al werf kaj reviziado de tradiciaj aliroj. Nun ni ĝojas prezenti eldonon v1.1, kiu estas granda paŝo en evoluo kaj fundamento por la estonteco kolektanto werf. La versio estas nuntempe havebla en .
La bazo de la eldono estas la nova arkitekturo de stokado kaj optimumigo de la laboro de ambaŭ kolektantoj (por Stapel kaj Dockerfile). La nova stokado-arkitekturo malfermas la eblecon efektivigi distribuitajn asembleojn de pluraj gastigantoj kaj paralelaj asembleoj sur la sama gastiganto.
Optimumigo de laboro inkluzivas forigi nenecesajn kalkulojn en la stadio de kalkulado de etapaj subskriboj kaj ŝanĝi la mekanismojn por kalkuli dosierkontrolajn sumojn al pli efikaj. Ĉi tiu optimumigo reduktas la averaĝan tempon de projektokonstruoj uzante werf. Kaj neaktivaj konstruoj, kiam ĉiuj etapoj ekzistas en la kaŝmemoro etapoj-stokado, estas nun vere rapidaj. Plejofte, rekomenci la konstruon daŭros malpli ol 1 sekundon! Ĉi tio validas ankaŭ por proceduroj por kontroli etapojn en la procezo de laboro de teamoj. werf deploy и werf run.
Ankaŭ en ĉi tiu eldono aperis strategio por etikedi bildojn laŭ enhavo - enhav-bazita etikedado, kiu nun estas ebligita defaŭlte kaj la nura rekomendita.
Ni rigardu pli detale la ĉefajn novigojn en werf v1.1, kaj samtempe rakontu al vi pri planoj por la estonteco.
Kio ŝanĝiĝis en werf v1.1?
Nova faza nomformato kaj algoritmo por elekti stadiojn el kaŝmemoro
Nova regulo pri generacia artista nomo. Nun ĉiu faza konstruo generas unikan artistan nomon, kiu konsistas el 2 partoj: subskribo (kiel ĝi estis en v1.0) plus unika provizora identigilo.
Ekzemple, la plena scenbildnomo povus aspekti jene:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
... aŭ ĝenerale:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Jen:
-
SIGNATUREestas sceneja subskribo, kiu reprezentas la identigilon de la sceneja enhavo kaj dependas de la historio de redaktoj en Git, kiuj kondukis al ĉi tiu enhavo; -
TIMESTAMP_MILLISECestas garantiita unika bildidentigilo kiu estas generita kiam nova bildo estas konstruita.
La algoritmo por elekti stadiojn el la kaŝmemoro baziĝas sur kontrolado de la rilato de Git-komisioj:
- Werf kalkulas la subskribon de certa stadio.
- В etapoj-stokado Povas ekzisti pluraj stadioj por donita subskribo. Werf elektas ĉiujn stadiojn, kiuj kongruas kun la subskribo.
- Se la nuna stadio estas ligita al Git (git-arkivo, kutima stadio kun Git-flakoj:
install,beforeSetup,setup; aŭ git-latest-patch), tiam werf elektas nur tiujn stadiojn, kiuj estas asociitaj kun commit, kiu estas prapatro de la nuna commit (por kiu la konstruo estas vokita). - El la ceteraj taŭgaj stadioj, unu estas elektita - la plej malnova laŭ krea dato.
Etapo por malsamaj Git-branĉoj povas havi la saman subskribon. Sed werf malhelpos la kaŝmemoron asociitan kun malsamaj branĉoj esti uzata inter ĉi tiuj branĉoj, eĉ se la subskriboj kongruas.
.
Nova algoritmo por krei kaj konservi etapoj en la sceneja stokado
Se, elektante stadiojn el la kaŝmemoro, werf ne trovas taŭgan stadion, tiam la procezo de kunigo de nova etapo komenciĝas.
Notu, ke pluraj procezoj (sur unu aŭ pluraj gastigantoj) povas komenci konstrui la saman stadion proksimume samtempe. Werf uzas optimisman blokan algoritmon etapoj-stokado en la momento de konservado de la ĵus kolektita bildo en etapoj-stokado. Tiel, kiam la nova sceneja konstruo estas preta, werf blokas etapoj-stokado kaj konservas tie freŝe kolektitan bildon nur se tie ne plu ekzistas taŭga bildo (per subskribo kaj aliaj parametroj - vidu la novan algoritmon por elekti etapojn el la kaŝmemoro).
Freŝe kunmetita bildo estas garantiita havi unikan identigilon per TIMESTAMP_MILLISEC (vidu novan fazan nomformaton). En kazo en etapoj-stokado taŭga bildo estos trovita, werf forĵetos la ĵus kompilitan bildon kaj uzos la bildon el la kaŝmemoro.
Alivorte: la unua procezo por finkonstrui la bildon (la plej rapida) ricevos la rajton konservi ĝin en etapoj-stokado (kaj tiam ĝi estas ĉi tiu ununura bildo kiu estos uzata por ĉiuj konstruoj). Malrapida konstruprocezo neniam blokos pli rapidan procezon konservi la konstrurezultojn de la nuna etapo kaj pluiri al la sekva konstruo.
.
Plibonigita agado de Dockerfile-konstruanto
Nuntempe, la dukto de etapoj por bildo konstruita el Dockerfile konsistas el unu etapo - dockerfile. Kiam oni kalkulas la subskribon, la kontrolsumo de la dosieroj estas kalkulita context, kiu estos uzata dum kunigo. Antaŭ ĉi tiu plibonigo, werf rekursie trairis ĉiujn dosierojn kaj akiris ĉeksumon suminte la kuntekston kaj reĝimon de ĉiu dosiero. Komencante kun v1.1, werf povas uzi kalkulitajn ĉeksumojn konservitajn en Git-deponejo.
La algoritmo baziĝas sur . La algoritmo enkalkulas rekordojn en .dockerignore kaj trairas la dosierarbon rekursie nur kiam necese. Tiel, ni malkunligis de legado de la dosiersistemo, kaj la dependeco de la algoritmo de la grandeco. context ne estas signifa.
La algoritmo ankaŭ kontrolas nespuritajn dosierojn kaj, se necese, enkalkulas ilin en la ĉeksumo.
Plibonigita rendimento dum importado de dosieroj
Versioj de werf v1.1 uzas rsync-servilon kiam . Antaŭe, importado estis farita en du paŝoj uzante dosierujon de la gastiga sistemo.
Importa rendimento en macOS ne plu estas limigita de Docker-volumoj, kaj importado finiĝas en la sama tempo kiel Linukso kaj Vindozo.
Enhavo-bazita etikedado
Werf v1.1 subtenas tiel nomatan etikedon per bilda enhavo - enhav-bazita etikedado. La etikedoj de la rezultaj Docker-bildoj dependas de la enhavo de ĉi tiuj bildoj.
Kiam vi ruliĝas la komandon werf publish --tags-by-stages-signature aŭ werf ci-env --tagging-strategy=stages-signature publikigitaj bildoj de la tn sceneja subskribo bildo. Ĉiu bildo estas etikedita kun sia propra subskribo de la stadioj de ĉi tiu bildo, kiu estas kalkulita laŭ la samaj reguloj kiel la regula subskribo de ĉiu etapo aparte, sed estas ĝenerala identigilo de la bildo.
La subskribo de la bildaj stadioj dependas de:
- la enhavo de ĉi tiu bildo;
- historioj de la Git-ŝanĝoj kiuj kondukis al ĉi tiu enhavo.
Git-deponejo ĉiam havas imitajn kommittojn, kiuj ne ŝanĝas la enhavon de la bilddosieroj. Ekzemple, kommits kun nur komentoj aŭ kunfandas kommits, aŭ kommits kiuj ŝanĝas tiujn dosierojn en Git kiuj ne estos importitaj en la bildon.
Kiam oni uzas enhav-bazitan etikedon, la problemoj de nenecesaj rekomencoj de aplikaĵpodoj en Kubernetes pro ŝanĝoj en la bildonomo estas solvitaj, eĉ se la enhavo de la bildo ne ŝanĝiĝis. Cetere, ĉi tio estas unu el la kialoj, kiuj malhelpas stoki multajn mikroservojn de unu aplikaĵo en ununura Git-deponejo.
Ankaŭ, enhav-bazita etikedado estas pli fidinda etikedmetodo ol etikedado sur Git-branĉoj, ĉar la enhavo de la rezultaj bildoj ne dependas de la ordo en kiu duktoj estas ekzekutitaj en la CI-sistemo por kunvenado de multoblaj komits de la sama branĉo.
gravaj: ekde nun etapoj-signaturo Estas la sola rekomendita etikedstrategio. Ĝi estos uzata defaŭlte en la komando werf ci-env (krom se vi eksplicite specifas alian etikedskemon).
. Aparta publikaĵo ankaŭ estos dediĉita al ĉi tiu funkcio. Ĝisdatigita (3a de aprilo): Artikolo kun detaloj .
Registroniveloj
La uzanto nun havas la ŝancon kontroli la eligon, agordi la registran nivelon kaj labori kun sencimigaj informoj. Opcioj aldonitaj --log-quiet, --log-verbose, --log-debug.
Defaŭlte, la eligo enhavas la minimumajn informojn:
Kiam vi uzas multvortan eligon (--log-verbose) vi povas vidi kiel funkcias werf:
Detala eligo (--log-debug), krom werf-sencimigaj informoj, ankaŭ enhavas protokolojn de uzitaj bibliotekoj. Ekzemple, vi povas vidi kiel okazas interago kun la Docker-Registro, kaj ankaŭ registri la lokojn, kie signifa kvanto da tempo estas pasigita:
Estontaj planoj
Singardemo La ebloj priskribitaj malsupre estas markitaj v1.1 estos disponeblaj en ĉi tiu versio, multaj el ili baldaŭ. Ĝisdatigoj venos per aŭtomataj ĝisdatigoj . Ĉi tiuj funkcioj ne influas la stabilan parton de v1.1-funkcioj; ilia aspekto ne postulos manan uzantan intervenon en ekzistantaj agordoj.
Plena subteno por diversaj realigoj de Docker Registry (NOVA)
- Versio: v1.1
- Datoj: marto
La celo estas, ke la uzanto uzu laŭmendan efektivigon sen limigoj kiam vi uzas werf.
Nuntempe, ni identigis la sekvan aron da solvoj, por kiuj ni garantios plenan subtenon:
- Defaŭlte (biblioteko/registro)*,
- AWS ECR
- Lazuro*,
- Docker Hub
- GCR*,
- GitHub-Pakoj
- GitLab Registry*,
- Haveno*,
- Kajo.
Solvoj kiuj estas nuntempe plene subtenataj de werf estas markitaj per asterisko. Por aliaj ekzistas subteno, sed kun limigoj.
Du ĉefaj problemoj povas esti identigitaj:
- Iuj solvoj ne subtenas forigon de etikedoj per la Docker Registry API, malhelpante uzantojn uzi la aŭtomatan purigadon de werf. Ĉi tio validas por AWS ECR, Docker Hub kaj GitHub-Pakoj.
- Iuj solvoj ne subtenas tiel nomatajn nestitajn deponejojn (Docker Hub, GitHub Packages kaj Quay) aŭ faras, sed la uzanto devas krei ilin permane uzante la UI aŭ API (AWS ECR).
Ni solvos ĉi tiujn kaj aliajn problemojn uzante denaskajn API-ojn de la solvoj. Ĉi tiu tasko ankaŭ inkluzivas kovri la plenan ciklon de werf-operacio per testoj por ĉiu el ili.
Distribuita bilda konstruo (↑)
- Versio: v1.2 v1.1 (la prioritato por efektivigi ĉi tiun funkcion estis pliigita)
- Datoj: marto-aprilo marto
Nuntempe, werf v1.0 kaj v1.1 povas esti uzataj nur sur unu dediĉita gastiganto por operacioj de konstruado kaj publikigado de bildoj kaj deplojado de la aplikaĵo al Kubernetes.
Por malfermi la eblecojn de distribuita laboro de werf, kiam la konstruo kaj deplojo de aplikoj en Kubernetes estas lanĉitaj sur pluraj arbitraj gastigantoj kaj ĉi tiuj gastigantoj ne konservas sian staton inter konstruoj (provizoraj kurantoj), werf estas postulata por efektivigi la kapablon uzi la Docker Registry kiel sceneja vendejo.
Antaŭe, kiam la werf-projekto ankoraŭ nomiĝis dapp, ĝi havis tian ŝancon. Tamen, ni renkontis kelkajn problemojn, kiujn oni devas konsideri dum efektivigo de ĉi tiu funkcio en werf.
Примечание. Ĉi tiu funkcio ne postulas, ke la kolektanto laboru ene de Kubernetes-podoj, ĉar Por fari tion, vi devas forigi la dependecon de la loka Docker-servilo (en la Kubernetes-podo ne estas aliro al la loka Docker-servilo, ĉar la procezo mem funkcias en ujo, kaj werf ne subtenas kaj ne subtenos. laborante kun la Docker-servilo tra la reto). Subteno por funkcii Kubernetes estos efektivigita aparte.
Oficiala subteno por GitHub-Agoj (NOVA)
- Versio: v1.1
- Datoj: marto
Inkludas werf-dokumentadon (sekcioj referenco и gvidi), same kiel la oficiala GitHub Action por labori kun werf.
Krome, ĝi permesos al werf labori pri efemeraj kurantoj.
La mekaniko de uzantinterago kun la CI-sistemo estos bazita sur metado de etikedoj sur tiraj petoj por komenci certajn agojn por konstrui/elvolvi la aplikaĵon.
Loka evoluo kaj deplojo de aplikoj kun werf (↓)
- Versio: v1.1
- Datoj: januaro-februaro aprilo
La ĉefa celo estas atingi ununuran unuigitan agordon por disfaldi aplikaĵojn kaj loke kaj en produktado, sen kompleksaj agoj, el la skatolo.
werf ankaŭ estas postulata por havi operacian reĝimon, en kiu estos oportune redakti la aplikaĵokodon kaj tuj ricevi retrosciigon de la funkcianta aplikaĵo por senararigado.
Nova puriga algoritmo (NOVA)
- Versio: v1.1
- Datoj: aprilo
En la nuna versio de werf v1.1 en la proceduro cleanup Ne estas kondiĉo por purigado de bildoj por la enhav-bazita etikedskemo - ĉi tiuj bildoj amasiĝos.
Ankaŭ, la nuna versio de werf (v1.0 kaj v1.1) uzas malsamajn purigajn politikojn por bildoj publikigitaj sub etikedskemoj: Git-branĉo, Git-etikedo aŭ Git-kommit.
Nova algoritmo por purigado de bildoj bazitaj sur la historio de komitaĵoj en Git, unuigita por ĉiuj etikedskemoj, estis inventita:
- Konservu ne pli ol N1-bildojn asociitajn kun la plej lastatempaj komitaĵoj de N2 por ĉiu git HEAD (branĉoj kaj etikedoj).
- Stoku ne pli ol N1-scenbildojn asociitajn kun la plej lastatempaj komitaĵoj de N2 por ĉiu git HEAD (branĉoj kaj etikedoj).
- Konservu ĉiujn bildojn, kiuj estas uzataj en iuj kubernetaj amasrimedoj (ĉiuj kube-kuntekstoj de la agorda dosiero kaj nomspacoj estas skanitaj; vi povas limigi ĉi tiun konduton per specialaj opcioj).
- Konservu ĉiujn bildojn, kiuj estas uzataj en rimeda agorda manifestoj konservitaj en Helm-eldonoj.
- Bildo povas esti forigita se ĝi ne estas asociita kun iu HEAD de git (ekzemple ĉar la responda HEAD mem estis forigita) kaj ne estas uzata en iuj manifestoj en la Kubernetes-areo kaj en Helm-eldonoj.
Paralela bildkonstruaĵo (↓)
- Versio: v1.1
- Datoj: januaro-februaro aprilo*
La nuna versio de werf kolektas la bildojn kaj artefaktojn priskribitajn en werf.yaml, sinsekve. Necesas paraleligi la procezon de kunigo de sendependaj etapoj de bildoj kaj artefaktoj, kaj ankaŭ provizi oportunan kaj informan eliron.
* Noto: la limdato estis ŝanĝita pro pliigita prioritato por efektivigo de distribuita asembleo, kiu aldonos pli da horizontalaj skalaj kapabloj, kaj ankaŭ la uzon de werf kun GitHub-Agoj. Paralela asembleo estas la sekva optimumiga paŝo, provizante vertikalan skaleblon dum kunvenado de unu projekto.
Transiro al Helmo 3 (↓)
- Versio: v1.2
- Datoj: februaro-marto majo*
Inkluzivas migradon al nova kodbazo kaj pruvita, oportuna maniero migri ekzistantajn instalaĵojn.
* Noto: ŝanĝi al Helm 3 ne aldonos signifajn funkciojn al werf, ĉar ĉiuj ĉefaj funkcioj de Helm 3 (tridirekta kunfandiĝo kaj sen tiller) jam estas efektivigitaj en werf. Plie, werf havas krom tiuj indikitaj. Tamen, ĉi tiu transiro restas en niaj planoj kaj estos efektivigita.
Jsonnet por priskribi Kubernetes-agordon (↓)
- Versio: v1.2
- Datoj: januaro-februaro aprilo-majo
Werf subtenos agordajn priskribojn por Kubernetes en formato Jsonnet. Samtempe, werf restos kongrua kun Helm kaj estos elekto de priskriba formato.
La kialo estas, ke Go-ŝablonoj, laŭ multaj homoj, havas altan enirbarieron, kaj ankaŭ la komprenebleco de la kodo de ĉi tiuj ŝablonoj suferas.
La ebleco enkonduki aliajn Kubernetes-agordajn priskribsistemojn (ekzemple Kustomize) ankaŭ estas pripensita.
Laborante ene de Kubernetes (↓)
- Versio: v1.2
- Datoj: aprilo-majo majo-junio
Celo: Certigu, ke bildoj estas konstruitaj kaj la aplikaĵo estas liverita per kuriloj en Kubernetes. Tiuj. Novaj bildoj povas esti konstruitaj, publikigitaj, purigitaj kaj deplojitaj rekte de Kubernetes-podoj.
Por efektivigi ĉi tiun kapablon, vi unue devas povi konstrui distribuitajn bildojn (vidu la punkton supre).
Ĝi ankaŭ postulas subtenon por la operaciumo de la konstruanto sen Docker-servilo (t.e. Kaniko-simila konstruo aŭ konstruo en uzantspaco).
Werf subtenos konstrui Kubernetes ne nur per Dockerfile, sed ankaŭ kun ĝia Stapel-konstruanto kun pliigaj rekonstruoj kaj Ansible.
Paŝo al malferma disvolviĝo
Ni amas nian komunumon (, ) kaj ni volas ke pli kaj pli da homoj helpu plibonigi werf, kompreni la direkton en kiu ni moviĝas kaj partopreni en la evoluo.
Sufiĉe lastatempe oni decidis ŝanĝi al por malkaŝi la laborprocezon de nia teamo. Nun vi povas vidi la tujajn planojn, same kiel nunan laboron en la sekvaj areoj:
- ;
- ;
- ;
- .
Multe da laboro estis farita kun problemoj:
- Forigitaj senrilataj.
- La ekzistantaj estas alportitaj al ununura formato, kun sufiĉa nombro da detaloj kaj detaloj.
- Novaj temoj kun ideoj kaj sugestoj estis aldonitaj.
Kiel ebligi version v1.1
La versio estas nuntempe havebla en (en kanaloj Stabila и rok-solida eldonoj aperos dum stabiligo okazas, tamen ea mem estas jam sufiĉe stabila por uzo, ĉar iris tra la kanaloj alfa и beta). Aktivigita en la sekva maniero:
source $(multiwerf use 1.1 ea)
werf COMMAND ...konkludo
La nova arkitekturo de konservado de scenejo kaj optimumigo de konstruiloj por Stapel kaj Dockerfile-konstruistoj malfermas la eblecon efektivigi distribuitajn kaj paralelajn konstruojn en werf. Ĉi tiuj funkcioj baldaŭ aperos en la sama versio v1.1 kaj fariĝos aŭtomate disponeblaj per la aŭtomata ĝisdatiga mekanismo (por uzantoj ).
En ĉi tiu eldono, etikedstrategio bazita sur bilda enhavo estis aldonita - enhav-bazita etikedado, kiu fariĝis la defaŭlta strategio. La ĉefa komandprotokolo ankaŭ estis reverkita: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
La sekva grava paŝo estas aldoni distribuitajn asembleojn. Distribuitaj konstruoj fariĝis pli alta prioritato ol paralelaj konstruoj ekde v1.0 ĉar ili aldonas pli da valoro al werf: vertikala skalo de konstruantoj kaj subteno por efemeraj konstruantoj en diversaj CI/KD-sistemoj, same kiel la kapablo fari oficialan subtenon por GitHub-Agoj. . Tial, la efektivigdatoj por paralelaj asembleoj estis ŝanĝitaj. Tamen ni laboras por efektivigi ambaŭ eblecojn kiel eble plej baldaŭ.
Sekvu la novaĵojn! Kaj ne forgesu viziti nin ĉe krei aferon, trovi ekzistantan kaj aldoni pluson, krei PR aŭ simple rigardi la evoluon de la projekto.
PS
Legu ankaŭ en nia blogo:
- «»
- «»;
- Serio de notoj pri novigoj en werf:
- «»;
- «»;
- «»;
- «".
fonto: www.habr.com