Представљамо Хелм 3

Представљамо Хелм 3

Белешка. трансл.: 16. мај ове године означава значајну прекретницу у развоју пакет менаџера за Кубернетес - Хелм. На данашњи дан представљено је прво алфа издање будуће главне верзије пројекта - 3.0. Његово објављивање ће донети значајне и дуго очекиване промене у Хелму, у које многи у Кубернетес заједници полажу велике наде. Ми смо једни од њих, пошто активно користимо Хелм за имплементацију апликација: интегрисали смо га у наш алат за имплементацију ЦИ/ЦД верф и с времена на време дајемо свој допринос развоју узводног. Овај превод комбинује 7 белешки са званичног Хелм блога, које су посвећене првом алфа издању Хелм 3 и говоре о историји пројекта и главним карактеристикама Хелм 3. Њихов аутор је Матт „бацонгобблер“ Фисхер, запослени у Мицрософту и један од кључних одржаватеља Хелма.

15. октобра 2015. рођен је пројекат сада познат као Хелм. Само годину дана након оснивања, Хелм заједница се придружила Кубернетесу, док је активно радила на Хелм 2. У јуну 2018. Хелм придружио се ЦНЦФ-у као развојни (инкубацијски) пројекат. Премотајте унапред у садашњост и прво алфа издање новог Хелм 3 је на путу. (ово издање се већ одиграла средином маја - цца. превод).

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

Резиме:

  • историја настанка Хелма;
  • нежни опроштај од Тилера;
  • складишта графикона;
  • управљање ослобађањем;
  • промене у зависности од графикона;
  • библиотечке карте;
  • шта је следеће?

Историја Хелма

Рођење

Хелм 1 је започео као пројекат отвореног кода који је креирао Деис. Били смо мали стартап апсорбован Мицрософт у пролеће 2017. Наш други пројекат отвореног кода, такође назван Деис, имао је алат deisctl, који је коришћен (између осталог) за инсталирање и рад Деис платформе у Кластер флоте. У то време, Флеет је била једна од првих платформи за оркестрацију контејнера.

Средином 2015. одлучили смо да променимо курс и преместили смо Деис (у то време преименован у Деис Воркфлов) из Флеет-а у Кубернетес. Један од првих који је редизајниран био је алат за инсталацију. deisctl. Користили смо га за инсталирање и управљање Деис Воркфлов-ом у Флеет кластеру.

Хелм 1 је креиран по угледу на познате менаџере пакета као што су Хомебрев, апт и иум. Његов главни циљ је био да поједностави задатке као што су паковање и инсталирање апликација на Кубернетес. Хелм је званично представљен 2015. године на конференцији КубеЦон у Сан Франциску.

Наш први покушај са Хелмом је успео, али није био без озбиљних ограничења. Узео је сет Кубернетес манифеста, ароматизованих генераторима као уводним ИАМЛ блоковима (предња ствар)* и учитао резултате у Кубернетес.

* Белешка. трансл.: Од прве верзије Хелма, ИАМЛ синтакса је изабрана да опише Кубернетес ресурсе, а Јиња шаблони и Питхон скрипте су подржани приликом писања конфигурација. Више о овоме и структури прве верзије Хелма уопште писали смо у поглављу „Кратка историја Хелма“ овај материјал.

На пример, да бисте заменили поље у ИАМЛ датотеци, морали сте да додате следећу конструкцију у манифест:

#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml

Сјајно је што данас постоје шаблони, зар не?

Из много разлога, овај рани инсталатер Кубернетеса захтевао је тврдо кодирану листу манифестних датотека и извршавао је само мали, фиксни низ догађаја. Било је толико тешко користити да је тиму за истраживање и развој Деис Воркфлов-а било тешко када су покушали да пренесу свој производ на ову платформу - међутим, семе идеје је већ било посејано. Наш први покушај био је одлична прилика за учење: схватили смо да смо заиста страствени у стварању прагматичних алата који решавају свакодневне проблеме за наше кориснике.

На основу искуства из прошлих грешака, почели смо да развијамо Хелм 2.

Прављење кормила 2

Крајем 2015. контактирао нас је Гоогле тим. Радили су на сличном алату за Кубернетес. Деплоимент Манагер за Кубернетес је био порт постојећег алата који је коришћен за Гоогле Цлоуд Платформ. „Да ли бисмо желели“, упитали су, „да проведемо неколико дана разговарајући о сличностима и разликама?“

У јануару 2016. тимови за управљање и развојни менаџер састали су се у Сијетлу како би разменили идеје. Преговори су завршени амбициозним планом: комбиновати оба пројекта за стварање Хелм 2. Уз Деис и Гугл, момци из СкиппБок (сада део Битнамија - прибл. прев.), и почели смо да радимо на Хелм 2.

Желели смо да задржимо Хелмову лакоћу коришћења, али додамо следеће:

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

Да би се постигли ови циљеви, други елемент је додат екосистему Хелм. Ова компонента унутар кластера звала се Тиллер и била је одговорна за инсталирање и управљање Хелм графиконима.

Од издавања Хелм 2 2016. године, Кубернетес је додао неколико великих иновација. Додата контрола приступа заснована на улогама (РБАЦ), који је на крају заменио контролу приступа засновану на атрибутима (АБАЦ). Уведени су нови типови ресурса (у то време Деплоиментс је још увек био у бета верзији). Измишљене су прилагођене дефиниције ресурса (првобитно назване ресурси трећих страна или ТПР). И што је најважније, појавио се скуп најбољих пракси.

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

Нежни опроштај од Тилера

Током развоја Хелм 2, представили смо Тиллер као део наше интеграције са Гоогле-овим менаџером за имплементацију. Тилер је играо важну улогу за тимове који раде у оквиру заједничког кластера: омогућио је различитим стручњацима који управљају инфраструктуром да комуницирају са истим скупом издања.

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

Након што смо сазнали како је заједница користила Хелм у одређеним ситуацијама, схватили смо да Тиллеров систем за управљање издањима не мора да се ослања на компоненту унутар кластера да би одржао стање или функционисао као централно чвориште за информације о издању. Уместо тога, могли бисмо једноставно да примимо информације са Кубернетес АПИ сервера, генеришемо графикон на страни клијента и сачувамо запис о инсталацији у Кубернетес.

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

Пошто је Тилер отишао, Хелмов безбедносни модел је радикално поједностављен. Хелм 3 сада подржава све модерне методе безбедности, идентитета и ауторизације актуелних Кубернетес-а. Дозволе за управљање се одређују помоћу кубецонфиг фајл. Администратори кластера могу ограничити корисничка права на било који ниво грануларности. Издања се и даље чувају унутар кластера, а остатак Хелмове функционалности остаје нетакнут.

Складишта графикона

На високом нивоу, спремиште графикона је место где се графикони могу чувати и делити. Хелм клијент пакује и шаље графиконе у спремиште. Једноставно речено, складиште графикона је примитивни ХТТП сервер са индек.иамл датотеком и неким упакованим графиконима.

Иако постоје неке предности АПИ-ја Цхартс Репоситори који испуњава већину основних захтева за складиштење, постоји и неколико недостатака:

  • Спремишта графикона нису компатибилна са већином безбедносних имплементација потребних у производном окружењу. Имати стандардни АПИ за аутентификацију и ауторизацију је изузетно важно у сценаријима производње.
  • Хелмови алати за порекло графикона, који се користе за потписивање, проверу интегритета и порекла графикона, су опциони део процеса објављивања графикона.
  • У сценаријима са више корисника, исти графикон може да отпреми други корисник, удвостручујући количину простора потребног за складиштење истог садржаја. За решавање овог проблема развијена су паметнија спремишта, али она нису део формалне спецификације.
  • Коришћење једне индексне датотеке за претрагу, чување метаподатака и преузимање графикона отежава развој безбедних имплементација за више корисника.

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

Али да ли сте знали да је пројекат дистрибуције дизајниран да дистрибуира било који облик садржаја, а не само слике контејнера?

Захваљујући напорима Иницијатива за отворени контејнер (или ОЦИ), Хелм карте се могу поставити на било коју инстанцу дистрибуције. За сада је овај процес експерименталан. Подршка за пријављивање и друге функције потребне за комплетан Хелм 3 су у току, али ми смо узбуђени што учимо из открића до којих су ОЦИ и дистрибутивни тимови дошли током година. А кроз њихово менторство и смернице, сазнајемо како је то радити са високо доступном услугом у великом обиму.

Доступан је детаљнији опис неких предстојећих промена у складиштима Хелм графикона по ссылке.

Управљање издањима

У Хелм-у 3, стање апликације се прати унутар кластера помоћу пара објеката:

  • објекат издања - представља инстанцу апликације;
  • тајна издања верзије - представља жељено стање апликације у одређеном тренутку (на пример, издавање нове верзије).

Изазов helm install креира објекат издања и тајну верзије издања. Цалл helm upgrade захтева објекат издања (који може да промени) и креира нову тајну верзије издања која садржи нове вредности и припремљен манифест.

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

Тајна верзије издања повезује издање са низом ревизија (инсталација, ажурирања, враћање, брисање).

У Хелм 2, ревизије су биле изузетно доследне. Цалл helm install креиран в1, накнадно ажурирање (надоградња) - в2, и тако даље. Тајна издања и издања верзије су скупљене у један објекат познат као ревизија. Ревизије су биле ускладиштене у истом именском простору као Тиллер, што је значило да је свако издање било "глобално" у смислу простора имена; као резултат, само једна инстанца имена се могла користити.

У Хелм-у 3, свако издање је повезано са једном или више тајни верзије издања. Објекат издања увек описује тренутно издање примењено на Кубернетес. Свака тајна верзија издања описује само једну верзију тог издања. Надоградња ће, на пример, креирати нову тајну верзије издања, а затим променити објекат издања да указује на ту нову верзију. У случају враћања, можете користити тајне претходне верзије издања да бисте вратили издање на претходно стање.

Након што је Тиллер напуштен, Хелм 3 чува податке о издању у истом именском простору као и издање. Ова промена вам омогућава да инсталирате графикон са истим именом издања у другом именском простору, а подаци се чувају између ажурирања/поновног покретања кластера у етцд-у. На пример, можете да инсталирате ВордПресс у именски простор „фоо“, а затим у именски простор „бар“, а оба издања се могу назвати „вордпресс“.

Промене у зависности од графикона

Карте су упаковане (користећи helm package) за коришћење са Хелмом 2 може се инсталирати са Хелмом 3, међутим ток рада развоја графикона је у потпуности ревидиран, тако да се морају направити неке измене да би се наставио развој графикона са Хелмом 3. Конкретно, систем управљања зависношћу графикона се променио.

Систем управљања зависношћу графикона је прешао са requirements.yaml и requirements.lock на Chart.yaml и Chart.lock. То значи да су графикони који су користили команду helm dependency, захтевају нека подешавања за рад у Хелм 3.

Погледајмо пример. Хајде да додамо зависност графикону у Хелм 2 и видимо шта се мења када пређемо на Хелм 3.

У кормилу 2 requirements.yaml изгледао овако:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

У Хелм-у 3, иста зависност ће се одразити на ваш Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

Карте се и даље преузимају и стављају у директоријум charts/, па подграфикони (подграфикони), лежи у каталогу charts/, наставиће са радом без измена.

Представљамо библиотечке графиконе

Хелм 3 подржава класу графикона која се назива библиотечки графикони (табела библиотеке). Овај графикон користе други графикони, али не ствара никакве артефакте издања сам по себи. Шаблони дијаграма библиотеке могу само да декларишу елементе define. Други садржај се једноставно игнорише. Ово омогућава корисницима да поново користе и деле исечке кода који се могу користити на више графикона, чиме се избегава дуплирање и придржавање принципа СУВ.

Библиотечки графикони су декларисани у секцији dependencies у фајлу Chart.yaml. Инсталирање и управљање њима се не разликује од других графикона.

dependencies:
  - name: mylib
    version: 1.x.x
    repository: quay.io

Узбуђени смо због случајева коришћења које ће ова компонента отворити за програмере графикона, као и због најбољих пракси које се могу појавити из библиотечких графикона.

Шта је следеће?

Хелм 3.0.0-алпха.1 је основа на којој почињемо да градимо нову верзију Хелм-а. У чланку сам описао неке занимљиве карактеристике Хелм 3. Многе од њих су још увек у раним фазама развоја и то је нормално; Смисао алфа издања је да тестира идеју, прикупи повратне информације од раних корисника и потврди наше претпоставке.

Чим алфа верзија буде објављена (запамтите да је ово већ се догодило — прибл. превод), почећемо да прихватамо закрпе за Хелм 3 од заједнице. Морате да створите јаку основу која омогућава развој и усвајање нових функционалности, као и да се корисници осећају укљученим у процес отварањем тикета и исправкама.

Покушао сам да истакнем нека од главних побољшања која долазе у Хелм 3, али ова листа ни у ком случају није исцрпна. Потпуна мапа пута за Хелм 3 укључује функције као што су побољшане стратегије ажурирања, дубља интеграција са ОЦИ регистрима и коришћење ЈСОН шема за валидацију вредности графикона. Такође планирамо да очистимо кодну базу и ажурирамо њене делове који су били занемарени последње три године.

Ако се осећате као да смо нешто пропустили, волели бисмо да чујемо ваше мишљење!

Придружите се дискусији на нашој Слаки канали:

  • #helm-users за питања и једноставну комуникацију са заједницом;
  • #helm-dev да разговарамо о захтевима за повлачење, коду и грешкама.

Такође можете да разговарате у нашим недељним јавним позивима за програмере четвртком у 19:30 МСК. Састанци су посвећени дискусији о питањима на којима раде кључни програмери и заједница, као и темама за дискусију током недеље. Свако се може придружити и учествовати на састанку. Линк је доступан на Слацк каналу #helm-dev.

ПС од преводиоца

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

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

Додај коментар