Кратак увод у прилагођавање

Белешка. трансл.: Чланак је написао Скот Лоу, инжењер са великим искуством у ИТ, који је аутор/коаутор седам штампаних књига (углавном о ВМваре вСпхере). Сада ради за ВМваре подружницу Хептио (купљену 2016.), специјализовану за рачунарство у облаку и Кубернетес. Сам текст служи као сажет и лако разумљив увод у управљање конфигурацијом за Кубернетес користећи технологију Прилагоди, који је недавно постао део К8с.

Кустомизе је алатка која омогућава корисницима да „прилагоде једноставне ИАМЛ датотеке без шаблона за различите сврхе, остављајући оригинални ИАМЛ нетакнутим и употребљивим“ (опис је позајмљен директно од прилагодите спремиште на ГитХуб-у). Кустомизе се може покренути директно или, од Кубернетес 1.14, користити kubectl -k да бисте приступили његовој функционалности (иако је од Кубернетеса 1.15, одвојени бинарни фајл новији од могућности уграђених у кубецтл). (Белешка. трансл.: И са недавним издањем Кубернетес 1.16 прилагоди подржан од такође у услужном програму кубеадм.) У овом посту желим да упознам читаоце са основама кустомизе.

У свом најједноставнијем облику/апликацији, кустомизе је једноставно колекција ресурса (ИАМЛ датотеке које дефинишу Кубернетес објекте: имплементације, услуге, итд.) плус листа упутстава за промене које је потребно извршити на тим ресурсима. Баш као што маке користи скуп инструкција садржан у Makefile, а Доцкер прави контејнер на основу упутстава из Dockerfile, прилагодите употребу kustomization.yaml да чува упутства о томе које промене корисник жели да изврши у скупу ресурса.

Ево примера датотеке kustomization.yaml:

resources:
- deployment.yaml
- service.yaml
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

Нећу покушавати да говорим о свим могућим пољима у датотеци. kustomization.yaml (о овоме је добро написано овде), али ћу дати кратко објашњење конкретног примера:

• Поље resources означава шта (који ресурси) ће се променити. У овом случају, тражиће ресурсе у датотекама deployment.yaml и service.yaml у вашем директоријуму (можете навести пуне или релативне путање ако је потребно).
• Поље namePrefix налаже кустомизе да дода одређени префикс (у овом случају - dev-) приписати name сви ресурси дефинисани на терену resources. Дакле, ако Деплоимент има name са значењем nginx-deployment, прилагодите ће успети dev-nginx-deployment.
• Поље namespace налаже кустомизе да дода дати простор имена свим ресурсима. У овом случају, Деплоимент анд Сервице ће пасти у именски простор development.
• Коначно, поље commonLabels садржи скуп ознака које ће бити додате свим ресурсима. У нашем примеру, кустомизе ће доделити ознаку ресурсима са именом environment и значење development.

Ако корисник то уради kustomize build . у директоријуму са датотеком kustomization.yaml и потребне ресурсе (тј. датотеке deployment.yaml и service.yaml), онда ће на излазу добити текст са изменама наведеним у kustomization.yaml.

Белешка. трансл.: Илустрација из пројектне документације о „једноставној” употреби кустомизе

Излаз се може преусмерити ако промене треба да буду урезане:

kustomize build . > custom-config.yaml

Излазни подаци су детерминистички (исти улазни подаци ће дати исте излазне резултате), тако да не морате да сачувате резултат у датотеци. Уместо тога, може се пренети директно другој команди:

kustomize build . | kubectl apply -f -

Функцијама прилагођавања се такође може приступити преко kubectl -k (од Кубернетес верзије 1.14). Међутим, имајте на уму да се самостални кустомизе пакет ажурира брже од интегрисаног кубецтл пакета (бар је то случај са издањем Кубернетес 1.15).

Читаоци се могу питати: „Чему сва та сложеност ако можете директно да уређујете датотеке?“ Сјајно питање. У нашем примеру, заиста може се модификовати датотеке deployment.yaml и service.yaml директно, али шта ако су виљушка туђег пројекта? Директна промена датотека отежава (ако не и немогуће) поновно базирање виљушке када се промене извор/извор. Коришћење кустомизе вам омогућава да централизујете ове промене у датотеци kustomization.yaml, остављајући оригиналне датотеке нетакнуте и на тај начин олакшавајући поновно базирање оригиналних датотека ако је потребно.

Предности кустомизе-а постају очигледне у сложенијим случајевима употребе. У горњем примеру kustomization.yaml а ресурси су у истом директоријуму. Међутим, кустомизе подржава случајеве коришћења где постоји основна конфигурација и многе њене варијанте, такође познате као прекривања. На пример, корисник је желео да узме Деплоимент анд Сервице за нгинк, које сам користио као пример, и да креира развојне, сценске и производне верзије (или варијанте) тих датотека. Да би то урадио, биће му потребни горе наведени слојеви и, у ствари, сами основни ресурси.

Да илуструје идеју о преклопима и основним ресурсима (основни ресурси), претпоставимо да директоријуми имају следећу структуру:

- base
  - deployment.yaml
  - service.yaml
  - kustomization.yaml
- overlays
  - dev
    - kustomization.yaml
  - staging
    - kustomization.yaml
  - prod
    - kustomization.yaml

У фајлу base/kustomization.yaml корисника који користе терен resources једноставно наведите ресурсе које кустомизе треба да обухвати.

У сваком од фајлова overlays/{dev,staging,prod}/kustomization.yaml корисници се позивају на основну конфигурацију на терену resources, а затим наведите конкретне промене за дато окружење. На пример, фајл overlays/dev/kustomization.yaml може изгледати као пример дат раније:

resources:
- ../../base
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

У овом случају фајл overlays/prod/kustomization.yaml може бити потпуно другачије:

resources:
- ../../base
namePrefix: prod-
namespace: production
commonLabels:
  environment: production
  sre-team: blue

Када корисник покрене kustomize build . у каталогу overlays/dev, кустомизе ће генерисати опцију развоја. Ако трчиш kustomize build . у каталогу overlays/prod - добијате опцију производње. И све ово - без икаквих промена у оригиналу (база) датотеке, све на декларативни и детерминистички начин. Можете да укључите основну конфигурацију и директоријуме преклапања директно у контролу верзија, знајући да на основу ових датотека можете репродуковати жељену конфигурацију у било ком тренутку.

Белешка. трансл.: Илустрација из пројектне документације о коришћењу прекривача у кустомизеу

Прилагодите лименку много више од онога што је покривено у овом чланку. Ипак, надам се да ће послужити као добар увод.

Додатна средства

Постоји много добрих чланака и публикација о кустомизеу. Ево неколико које сам сматрао посебно корисним:

• Промените основну ИАМЛ конфигурацију за различита окружења прод/тест користећи Кустомизе;
• Прилагођавање — прави начин израде шаблона у Кубернетесу;
• Декларативно управљање Кубернетес објектима помоћу Цустомизе;
• Прилагођавање Упстреам Хелм Цхартс помоћу Цустомизе.

Белешка. трансл.: Такође можете препоручити блок веза објављених као средства на веб локацији услужног програма, након чега следи колекција видео снимака са најновијим извештајима о кустомизе-у.

Ако имате питања или сугестије за побољшање овог материјала, увек сам отворен за повратне информације. Можете ме контактирати на Twitter или Кубернетес Слацк канал. Забавите се мењајући своје манифесте помоћу кустомизе!

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

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

• «Алати за програмере апликација које раде на Кубернетесу";
• «Кубернетес 1.14: преглед главних иновација";
• «Пет главних резултата Хелм самита 2019. у Амстердаму";
• «Практично упознавање са менаџером пакета за Кубернетес - Хелм'.

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