Një hyrje e shkurtër në Kustomize

Shënim. përkth.: Artikulli u shkrua nga Scott Lowe, një inxhinier me përvojë të gjerë në IT, i cili është autor/bashkautor i shtatë librave të shtypur (kryesisht në VMware vSphere). Ai tani punon për degën e tij VMware, Heptio (të blerë në 2016), i specializuar në kompjuterin cloud dhe Kubernetes. Vetë teksti shërben si një hyrje koncize dhe e lehtë për t'u kuptuar në menaxhimin e konfigurimit për Kubernetes duke përdorur teknologjinë Personalizoje, e cila së fundmi u bë pjesë e K8s.

Kustomize është një mjet që i lejon përdoruesit të "përshtatin skedarët YAML të thjeshtë, pa shabllone për qëllime të ndryshme, duke e lënë YAML origjinal të paprekur dhe të përdorshëm" (përshkrimi i huazuar direkt nga kustomize depo në GitHub). Kustomize mund të ekzekutohet drejtpërdrejt ose, si nga Kubernetes 1.14, të përdoret kubectl -k për të hyrë në funksionalitetin e tij (edhe pse nga Kubernetes 1.15, binar i veçantë është më i ri se aftësitë e ndërtuara në kubectl). (Shënim. përkth.: Dhe me publikimin e fundit Kubernetes 1.16 personalizoj mbeshtetur nga gjithashtu në programin kubeadm.) Në këtë postim, unë dua t'i prezantoj lexuesit me bazat e kustomize.

Në formën/aplikacionin e tij më të thjeshtë, kustomize është thjesht një koleksion burimesh (skedarët YAML që përcaktojnë objektet e Kubernetes: Vendosjet, Shërbimet, etj.) plus një listë udhëzimesh për ndryshimet që duhen bërë në ato burime. Ashtu si make përdor grupin e udhëzimeve të përfshira në Makefile, dhe Docker ndërton kontejnerin bazuar në udhëzimet nga Dockerfile, personalizoni përdorimet kustomization.yaml për të ruajtur udhëzimet për ndryshimet që përdoruesi dëshiron të bëjë në një grup burimesh.

Këtu është një skedar shembull kustomization.yaml:

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

Nuk do të përpiqem të flas për të gjitha fushat e mundshme në skedar. kustomization.yaml (për këtë është shkruar mirë këtu), por unë do të jap një shpjegim të shkurtër të një shembulli specifik:

• Fushë resources tregon se çfarë (cilat burime) kustomize do të ndryshojë. Në këtë rast, ai do të kërkojë burime në skedarë deployment.yaml и service.yaml në drejtorinë tuaj (mund të specifikoni shtigje të plota ose relative nëse është e nevojshme).
• Fushë namePrefix udhëzon kustomize të shtojë një parashtesë të caktuar (në këtë rast - dev-) për të atribuar name të gjitha burimet e përcaktuara në terren resources. Kështu, nëse vendosja ka name me kuptim nginx-deployment, personalizimi do ta bëjë atë dev-nginx-deployment.
• Fushë namespace udhëzon kustomize të shtojë hapësirën e emrave të dhënë në të gjitha burimet. Në këtë rast, Deployment and Service do të bien në hapësirën e emrave development.
• Më në fund, fusha commonLabels përmban një grup etiketash që do t'u shtohen të gjitha burimeve. Në shembullin tonë, kustomize do t'i caktojë një etiketë burimeve me emrin environment dhe kuptimi development.

Nëse përdoruesi e bën kustomize build . në drejtorinë me skedarin kustomization.yaml dhe burimet e nevojshme (p.sh. skedarët deployment.yaml и service.yaml), më pas në dalje do të marrë një tekst me ndryshimet e specifikuara në kustomization.yaml.

Shënim. përkth.: Ilustrim nga dokumentacioni i projektit mbi përdorimin “e thjeshtë” të kustomize

Prodhimi mund të ridrejtohet nëse duhen kryer ndryshime:

kustomize build . > custom-config.yaml

Të dhënat e daljes janë përcaktuese (të njëjtat të dhëna hyrëse do të prodhojnë të njëjtat rezultate dalëse), kështu që nuk keni nevojë ta ruani rezultatin në një skedar. Në vend të kësaj, mund të kalohet drejtpërdrejt në një komandë tjetër:

kustomize build . | kubectl apply -f -

Veçoritë e personalizimit mund të aksesohen gjithashtu nëpërmjet kubectl -k (që nga versioni 1.14 i Kubernetes). Sidoqoftë, mbani në mend se paketa e pavarur kustomize përditësohet më shpejt se paketa e integruar kubectl (të paktën ky është rasti me lëshimin e Kubernetes 1.15).

Lexuesit mund të pyesin: "Pse gjithë ky kompleksitet nëse mund t'i modifikoni skedarët drejtpërdrejt?" Pyetje e madhe. Në shembullin tonë, me të vërtetë një mund të modifikoni skedarët deployment.yaml и service.yaml drejtpërsëdrejti, por çka nëse ato janë një degë e projektit të dikujt tjetër? Ndryshimi i skedarëve drejtpërdrejt e bën të vështirë (nëse jo të pamundur) ribazimin e një forku kur bëhen ndryshime në origjinën/burimin. Përdorimi i kustomize ju lejon të centralizoni këto ndryshime në një skedar kustomization.yaml, duke i lënë të paprekur skedarët origjinal dhe duke e bërë më të lehtë ribazimin e skedarëve origjinal nëse është e nevojshme.

Përfitimet e kustomize bëhen të dukshme në rastet më komplekse të përdorimit. Në shembullin e mësipërm kustomization.yaml dhe burimet janë në të njëjtën direktori. Sidoqoftë, kustomize mbështet rastet e përdorimit kur ka një konfigurim bazë dhe shumë variante të tij, të njohura edhe si overlays. Për shembull, një përdorues donte të merrte Deployment and Service për nginx, të cilat unë i përdora si shembull, dhe të krijonte versione (ose variante) të zhvillimit, vendosjes dhe prodhimit të atyre skedarëve. Për ta bërë këtë, ai do të ketë nevojë për mbivendosjet e lartpërmendura dhe, në fakt, vetë burimet bazë.

Për të ilustruar idenë e mbivendosjeve dhe burimeve themelore (burimet bazë), le të supozojmë se drejtoritë kanë strukturën e mëposhtme:

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

Në dosje base/kustomization.yaml përdoruesit që përdorin fushën resources thjesht deklaroni burimet që duhet të përfshijë kustomize.

Në secilin prej dosjeve overlays/{dev,staging,prod}/kustomization.yaml përdoruesit i referohen konfigurimit bazë në fushë resources, dhe më pas tregoni ndryshime specifike për mjedisin e dhënë. Për shembull, skedari overlays/dev/kustomization.yaml mund të duket si shembulli i dhënë më parë:

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

Në këtë rast dosja overlays/prod/kustomization.yaml mund të jetë krejtësisht ndryshe:

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

Kur përdoruesi kandidon kustomize build . në katalog overlays/dev, kustomize do të gjenerojë opsionin e zhvillimit. Nëse vraponi kustomize build . në katalog overlays/prod - ju merrni opsionin e prodhimit. Dhe e gjithë kjo - pa bërë asnjë ndryshim në origjinal (bazë) dosjet, të gjitha në mënyrë deklarative dhe përcaktuese. Ju mund t'i caktoni direktoritë e konfigurimit bazë dhe të mbivendosjes direkt në kontrollin e versionit, duke e ditur që në bazë të këtyre skedarëve mund të riprodhoni konfigurimin e dëshiruar në çdo kohë.

Shënim. përkth.: Ilustrim nga dokumentacioni i projektit mbi përdorimin e mbivendosjeve në kustomize

Personalizo mund shumë më shumë se sa përshkruhet në këtë artikull. Megjithatë, shpresoj që të shërbejë si një hyrje e mirë.

Burime Shtesë

Ka shumë artikuj dhe botime të mira rreth kustomize. Këtu janë disa që më duken veçanërisht të dobishme:

• Ndryshoni konfigurimin bazë të YAML për mjedise të ndryshme prod/test duke përdorur Kustomize;
• Kustomize - Mënyra e duhur për të bërë shabllon në Kubernetes;
• Menaxhimi deklarativ i objekteve Kubernetes duke përdorur Customize;
• Përshtatja e grafikëve të timonit në rrjedhën e sipërme me Customize.

Shënim. përkth.: Ju gjithashtu mund të rekomandoni një bllok lidhjesh të publikuara si burime në faqen e internetit të shërbimeve, e ndjekur nga një koleksion videosh me raportet më të fundit rreth kustomize.

Nëse keni pyetje ose sugjerime për përmirësimin e këtij materiali, unë jam gjithmonë i hapur për komente. Mund të më kontaktoni në Twitter ose Kanali Kubernetes Slack. Argëtohuni duke modifikuar manifestet tuaja me kustomize!

PS nga përkthyesi

Lexoni edhe në blogun tonë:

• «Mjete për zhvilluesit e aplikacioneve që funksionojnë në Kubernetes"?
• «Kubernetes 1.14: përmbledhje e inovacioneve kryesore"?
• «Pesë rezultatet kryesore të Samitit të Helm 2019 në Amsterdam"?
• «Hyrje praktike me menaxherin e paketave për Kubernetes - Helm'.

Burimi: www.habr.com