верф 1.1 издање: побољшања градитеља данас и планови за будућност

верф је наш опен соурце ГитОпс ЦЛИ услужни програм за прављење и испоруку апликација у Кубернетес. Као што је обећано, издање верзије в1.0 означио је почетак додавања нових карактеристика верфу и ревизије традиционалних приступа. Сада са задовољством представљамо издање в1.1, које је велики корак у развоју и основа за будућност колекционар верф. Верзија је тренутно доступна у канал 1.1 еа.

Основа издања је нова архитектура сценског складиштења и оптимизација рада оба колектора (за Стапел и Доцкерфиле). Нова архитектура складиштења отвара могућност имплементације дистрибуираних склопова са више хостова и паралелних склопова на истом хосту.

Оптимизација рада укључује ослобађање од непотребних прорачуна у фази израчунавања потписа фазе и промену механизама за израчунавање контролних сума датотека на ефикасније. Ова оптимизација смањује просечно време изградње пројекта помоћу верф-а. И неактивне градње, када све фазе постоје у кешу етапе-складиште, сада су веома брзи. У већини случајева, поновно покретање изградње ће трајати мање од 1 секунде! Ово се односи и на процедуре за проверу фаза у процесу рада тимова. werf deploy и werf run.

Такође у овом издању појавила се стратегија за означавање слика по садржају - означавање засновано на садржају, који је сада подразумевано омогућен и једини препоручен.

Хајде да детаљније погледамо кључне иновације у верф в1.1, а истовремено да вам кажемо о плановима за будућност.

Шта се променило у верф в1.1?

Нови формат именовања фаза и алгоритам за избор фаза из кеша

Ново правило генерисања уметничког имена. Сада свака верзија фазе генерише јединствено име фазе, које се састоји од 2 дела: потписа (као што је био у в1.0) плус јединствени привремени идентификатор.

На пример, цело име слике сцене може изгледати овако:

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

...или уопштено:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

Ево:

• SIGNATURE је потпис фазе, који представља идентификатор садржаја позорнице и зависи од историје измена у Гиту које су довеле до овог садржаја;
• TIMESTAMP_MILLISEC је гарантовани јединствени идентификатор слике који се генерише у време када се прави нова слика.

Алгоритам за избор фаза из кеша заснован је на провери односа Гит урезивања:

1. Верф израчунава потпис одређене фазе.
2. В етапе-складиште За дати потпис може бити неколико фаза. Верф бира све фазе које одговарају потпису.
3. Ако је тренутна фаза повезана са Гит-ом (гит-архива, прилагођена фаза са Гит закрпама: install, beforeSetup, setup; или гит-латест-патцх), тада верф бира само оне фазе које су повезане са урезивањем које је предак тренутног урезивања (за које се позива буилд).
4. Од преосталих одговарајућих фаза бира се једна - најстарија по датуму настанка.

Фаза за различите Гит гране може имати исти потпис. Али верф ће спречити да се кеш повезан са различитим гранама користи између ових грана, чак и ако се потписи поклапају.

→ Документација.

Нови алгоритам за креирање и чување фаза у складишту позорнице

Ако, приликом одабира фаза из кеша, верф не пронађе одговарајућу фазу, тада се покреће процес склапања нове фазе.

Имајте на уму да више процеса (на једном или више хостова) може почети да гради исту фазу приближно у исто време. Верф користи оптимистичан алгоритам за блокирање етапе-складиште у тренутку чувања свеже прикупљене слике у етапе-складиште. На овај начин, када је нова фаза изградње спремна, верф блокови етапе-складиште и тамо чува свеже прикупљену слику само ако одговарајућа слика тамо више не постоји (по потпису и другим параметрима - погледајте нови алгоритам за избор фаза из кеша).

Свеже састављена слика гарантовано има јединствени идентификатор TIMESTAMP_MILLISEC (погледајте нови формат именовања сцене). У случају да у етапе-складиште биће пронађена одговарајућа слика, верф ће одбацити свеже компајлирану слику и користити слику из кеша.

Другим речима: први процес који заврши изградњу слике (најбржи) ће добити право да је складишти у фазама-складиштем (а онда ће се ова појединачна слика користити за све градње). Спор процес изградње никада неће блокирати бржи процес да сачува резултате изградње у тренутној фази и пређе на следећу верзију.

→ Документација.

Побољшане перформансе Доцкерфиле буилдера

У овом тренутку, цевовод фаза за слику направљену од Доцкерфиле-а се састоји од једне фазе - dockerfile. Приликом израчунавања потписа израчунава се контролни збир датотека context, који ће се користити током монтаже. Пре овог побољшања, верф је рекурзивно прошао кроз све датотеке и добио контролни збир сумирањем контекста и режима сваке датотеке. Почевши од в1.1, верф може да користи израчунате контролне суме ускладиштене у Гит спремишту.

Алгоритам се заснива на гит лс-трее. Алгоритам узима у обзир записе у .dockerignore и пролази кроз стабло датотека рекурзивно само када је то потребно. Тако смо се одвојили од читања система датотека и зависности алгоритма од величине context није значајно.

Алгоритам такође проверава датотеке које се не прате и, ако је потребно, узима их у обзир у контролној суми.

Побољшане перформансе приликом увоза датотека

Верзије верф в1.1 користе рсинц сервер када увоз датотека из артефаката и слика. Раније је увоз рађен у два корака коришћењем монтирања директоријума са главног система.

Перформансе увоза на мацОС-у више нису ограничене Доцкер волуменима, а увоз се завршава за исто време као и за Линук и Виндовс.

Означавање засновано на садржају

Верф в1.1 подржава такозвано означавање по садржају слике - означавање засновано на садржају. Ознаке резултирајућих Доцкер слика зависе од садржаја ових слика.

Приликом покретања команде werf publish --tags-by-stages-signature или werf ci-env --tagging-strategy=stages-signature објављене слике тзв сценски потпис слика. Свака слика је означена сопственим потписом фаза ове слике, који се израчунава према истим правилима као и регуларни потпис сваке фазе посебно, али је општи идентификатор слике.

Потпис фаза слике зависи од:

1. садржај ове слике;
2. историје Гит промена које су довеле до овог садржаја.

Гит спремиште увек има лажне урезивања који не мењају садржај сликовних датотека. На пример, урезивања само са коментарима или спајањем урезивања, или урезивања која мењају те датотеке у Гиту које неће бити увезене у слику.

Када се користи означавање засновано на садржају, решавају се проблеми непотребног поновног покретања модула апликација у Кубернетес-у због промене назива слике, чак и ако се садржај слике није променио. Иначе, ово је један од разлога који спречава чување многих микросервиса једне апликације у једном Гит спремишту.

Такође, означавање засновано на садржају је поузданији метод означавања од означавања на гранама Гит-а, јер садржај резултујућих слика не зависи од редоследа којим се цевоводи извршавају у ЦИ систему за склапање вишеструких урезивања исте гране.

То је важно: почевши од сада етапе-потпис - Је једина препоручена стратегија означавања. Подразумевано ће се користити у команди werf ci-env (осим ако експлицитно не наведете другу шему означавања).

→ Документација. Овој особини биће посвећена и посебна публикација. АЖУРИРАН (3. април): Чланак са детаљима објављено.

Нивои евидентирања

Корисник сада има прилику да контролише излаз, подеси ниво евидентирања и ради са информацијама за отклањање грешака. Опције су додате --log-quiet, --log-verbose, --log-debug.

Подразумевано, излаз садржи минималне информације:

Када користите детаљан излаз (--log-verbose) можете видети како верф функционише:

Детаљан излаз (--log-debug), поред информација о отклањању грешака верф-а, садржи и евиденције коришћених библиотека. На пример, можете да видите како долази до интеракције са Доцкер регистром, као и да забележите места на којима се проводи значајан део времена:

Планови за будућност

Упозорење! Доле описане опције су означене вКСНУМКС ће постати доступни у овој верзији, многи од њих у блиској будућности. Ажурирања ће долазити путем аутоматских ажурирања када се користи мултиверф. Ове карактеристике не утичу на стабилан део функција в1.1; њихов изглед неће захтевати ручну интервенцију корисника у постојећим конфигурацијама.

Потпуна подршка за различите имплементације Доцкер Регистри (НОВО)

• Верзија: в1.1
• Датуми: март
• Питање

Циљ је да корисник користи прилагођену имплементацију без ограничења када користи верф.

Тренутно смо идентификовали следећи сет решења за које ћемо гарантовати пуну подршку:

• Подразумевано (библиотека/регистратор)*,
• АВС ЕЦР
• Азурно*,
• Доцкер Хуб
• ГЦР*,
• ГитХуб пакети
• ГитЛаб регистар*,
• лука*,
• Кеј.

Решења која тренутно у потпуности подржава верф означена су звездицом. За друге постоји подршка, али са ограничењима.

Могу се идентификовати два главна проблема:

• Нека решења не подржавају уклањање ознака коришћењем Доцкер Регистри АПИ-ја, спречавајући кориснике да користе верф-ово аутоматско чишћење. Ово важи за АВС ЕЦР, Доцкер Хуб и ГитХуб пакете.
• Нека решења не подржавају такозвана угнежђена спремишта (Доцкер Хуб, ГитХуб пакети и Куаи) или их подржавају, али корисник мора да их креира ручно користећи кориснички интерфејс или АПИ (АВС ЕЦР).

Решићемо ове и друге проблеме користећи изворне АПИ-је решења. Овај задатак такође укључује покривање целог циклуса верф операција са тестовима за сваки од њих.

Изградња дистрибуиране слике (↑)

• Верзија: в1.2 в1.1 (приоритет за имплементацију ове функције је повећан)
• Датуми: март-април март
• Питање

Тренутно, верф в1.0 и в1.1 могу да се користе само на једном наменском хосту за операције прављења и објављивања слика и примене апликације у Кубернетес.

Да би се отвориле могућности дистрибуираног рада верф-а, када се изградња и имплементација апликација у Кубернетес-у покрене на неколико произвољних хостова и ови хостови не чувају своје стање између буилд-ова (привремени покретачи), верф је потребан за имплементацију могућности коришћења Доцкер Регистри као продавница позорнице.

Раније, када се верф пројекат још звао дапп, имао је такву прилику. Међутим, наишли смо на низ проблема које треба узети у обзир приликом имплементације ове функционалности у верф-у.

Приметити. Ова функција не захтева да колектор ради унутар Кубернетес подова, јер Да бисте то урадили, морате да се ослободите зависности од локалног Доцкер сервера (у Кубернетес под-у нема приступа локалном Доцкер серверу, јер се сам процес покреће у контејнеру, а верф не подржава и неће подржавати рад са Доцкер сервером преко мреже). Подршка за покретање Кубернетеса биће имплементирана засебно.

Званична подршка за ГитХуб акције (НОВО)

• Верзија: в1.1
• Датуми: март
• Питање

Укључује верф документацију (одељке упућивање и води), као и званична ГитХуб акција за рад са верф-ом.

Поред тога, омогућиће верфу да ради на ефемерним тркачима.

Механика интеракције корисника са ЦИ системом ће се заснивати на постављању ознака на захтевима за повлачење да би се покренуле одређене радње за изградњу/извођење апликације.

Локални развој и примена апликација са верф-ом (↓)

• Верзија: в1.1
• Термини: јануар-фебруар април
• Питање

Главни циљ је да се постигне јединствена обједињена конфигурација за примену апликација како локално тако иу производњи, без сложених радњи, ван кутије.

верф такође мора да има режим рада у коме ће бити згодно да се уреди код апликације и одмах добије повратне информације од покренуте апликације за отклањање грешака.

Нови алгоритам чишћења (НОВО)

• Верзија: в1.1
• Датуми: април
• Питање

У тренутној верзији верф в1.1 у процедури cleanup Не постоји одредба за чишћење слика за шему означавања засновану на садржају – ове слике ће се акумулирати.

Такође, тренутна верзија верф-а (в1.0 и в1.1) користи различите политике чишћења за слике објављене под шемама означавања: Гит грана, Гит ознака или Гит урезивање.

Измишљен је нови алгоритам за чишћење слика заснован на историји урезивања у Гиту, уједињен за све шеме означавања:

• Не чувајте више од Н1 слика повезаних са Н2 најновијим урезивањем за сваку гит ХЕАД (гране и ознаке).
• Не чувајте више од Н1 сценских слика повезаних са Н2 најновијим урезивањем за сваку гит ХЕАД (гране и ознаке).
• Чувајте све слике које се користе у било ком ресурсу Кубернетес кластера (сви кубе контексти конфигурационе датотеке и простори имена се скенирају; ово понашање можете ограничити посебним опцијама).
• Чувајте све слике које се користе у манифестима конфигурације ресурса сачуваним у Хелм издањима.
• Слика се може избрисати ако није повезана ни са једном ГЛАВОМ из гит-а (на пример, зато што је сама одговарајућа ГЛАВА избрисана) и не користи се ни у једном манифесту у Кубернетес кластеру и у издањима Хелм-а.

Изградња паралелне слике (↓)

• Верзија: в1.1
• Датуми: јануар-фебруар април*

Тренутна верзија верфа прикупља слике и артефакте описане у werf.yaml, секвенцијално. Неопходно је упоредити процес састављања независних фаза слика и артефаката, као и обезбедити згодан и информативан излаз.

* Напомена: рок је померен због повећаног приоритета за имплементацију дистрибуираног склопа, што ће додати више могућности хоризонталног скалирања, као и коришћење верф-а са ГитХуб акцијама. Паралелно склапање је следећи корак оптимизације, који обезбеђује вертикалну скалабилност приликом склапања једног пројекта.

Прелазак на кормило 3 (↓)

• Верзија: в1.2
• Датуми: фебруар-март мај*

Укључује миграцију на нову кодну базу Кормило 3 и доказан, згодан начин за миграцију постојећих инсталација.

* Напомена: прелазак на Хелм 3 неће додати значајне карактеристике верф-у, јер су све кључне карактеристике Хелм-а 3 (3-смерно спајање и без тиллер-а) већ имплементиране у верф-у. Штавише, верф има додатне функције поред наведених. Међутим, ова транзиција остаје у нашим плановима и биће спроведена.

Јсоннет за описивање Кубернетес конфигурације (↓)

• Верзија: в1.2
• Термини: јануар-фебруар април-мај

Верф ће подржавати описе конфигурације за Кубернетес у Јсоннет формату. У исто време, верф ће остати компатибилан са Хелм-ом и постојаће избор формата описа.

Разлог је у томе што Го шаблони, према многим људима, имају високу улазну баријеру, а пати и разумљивост кода ових шаблона.

Разматра се и могућност увођења других система за опис конфигурације Кубернетес (на пример, Кустомизе).

Рад унутар Кубернетеса (↓)

• Верзија: в1.2
• Термини: април-мај-мај-јун

Циљ: Уверите се да су слике направљене и да се апликација испоручује помоћу покретача у Кубернетес-у. Оне. Нове слике могу да се праве, објављују, чисте и постављају директно из Кубернетес подова.

Да бисте имплементирали ову могућност, прво морате бити у могућности да направите дистрибуиране слике (види тачку изнад).

Такође захтева подршку за радни режим градитеља без Доцкер сервера (тј. изградња или уградња у корисничком простору налик Канику).

Верф ће подржати изградњу на Кубернетес-у не само са Доцкерфиле-ом, већ и са својим Стапел буилдером са инкременталним обнављањем и Ансибле-ом.

Корак ка отвореном развоју

Волимо нашу заједницу (ГитХуб, Telegram) и желимо да све више људи помогне да верф буде бољи, да разуме правац у ком се крећемо и учествује у развоју.

Недавно је одлучено да се пређе на ГитХуб пројектне плоче како бисмо открили радни процес нашег тима. Сада можете видети тренутне планове, као и тренутне радове у следећим областима:

• Документација и сајт;
• Тестирање;
• Грешке и лош кориснички доживљај;
• 1.1.

Доста посла је обављено са питањима:

• Уклоњене небитне.
• Постојећи су доведени у јединствен формат, са довољним бројем детаља и детаља.
• Додата су нова издања са идејама и предлозима.

Како омогућити верзију в1.1

Верзија је тренутно доступна у канал 1.1 еа (у каналима стабилан и чврст као стена Међутим, ослобађања ће се појавити када дође до стабилизације ea сама је већ довољно стабилна за употребу, јер прошао кроз канале алфа и бета). Активирано преко мултиверф на следећи начин:

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

Закључак

Нова архитектура за складиштење нивоа и оптимизације градитеља за Стапел и Доцкерфиле градитеље отварају могућност имплементације дистрибуираних и паралелних надградња у верф-у. Ове функције ће се ускоро појавити у истом издању в1.1 и постаће аутоматски доступне путем механизма аутоматског ажурирања (за кориснике мултиверф).

У овом издању додата је стратегија означавања заснована на садржају слике - означавање засновано на садржају, што је постало подразумевана стратегија. Главни дневник команди је такође прерађен: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

Следећи значајан корак је додавање дистрибуираних склопова. Дистрибуиране верзије постале су већи приоритет у односу на паралелне градње од в1.0 јер додају више вредности верф-у: вертикално скалирање програмера и подршка за ефемерне градитеље у различитим ЦИ/ЦД системима, као и могућност да се направи званична подршка за ГитХуб Ацтионс . Због тога су померени рокови имплементације за паралелне скупштине. Међутим, радимо на томе да што пре применимо обе могућности.

Пратите вести! И не заборавите да нас посетите на ГитХубда креирате проблем, пронађите постојећи и додајте плус, направите ПР или једноставно пратите развој пројекта.

ПС

Прочитајте и на нашем блогу:

• «Представљамо верф 1.0 стабилан: какве везе ГитОпс има са тим, статус и планови»
• «верф - наш алат за ЦИ / ЦД у Кубернетес-у (преглед и видео извештај)";
• Серија белешки о иновацијама у верф-у:
  • «3-смерно спајање са верф-ом: постављање на Кубернетес са Хелмом „на стероидима“";
  • «Коришћење верф-а за извођење сложених Хелм графикона";
  • «Подршка за монорепо и мултирепо у верф-у и какве везе Доцкер регистар има са тим";
  • «Сада можете да правите Доцкер слике у верф-у користећи обичан Доцкерфиле'.

Извор: ввв.хабр.цом