ShĂ«n. pĂ«rk.: Artikulli Ă«shtĂ« shkruar nga Scott Lowe â njĂ« inxhinier me pĂ«rvojĂ« tĂ« madhe nĂ« IT, autor ose bashkautor i shtatĂ« librave tĂ« botuar (shumica nga VMware vSphere). Aktualisht ai punon nĂ« filialin e VMware â Heptio (e blerĂ« nĂ« vitin 2016), i specializuar nĂ« computacionin nĂ« re dhe Kubernetes. Teksti shĂ«rben si njĂ« hyrje e pĂ«rmbledhur dhe e lehtĂ« pĂ«r t'u kuptuar pĂ«r menaxhimin e konfigurimeve pĂ«r Kubernetes duke pĂ«rdorur teknologjinĂ« , e cila sĂ« fundmi u bĂ« pjesĂ« e K8s.
Kustomize është një mjet që lejon përdoruesit "të personalizojnë skedarët YAML të thjeshtë dhe të lirë nga shabllonët për qëllime të ndryshme, duke lënë origjinalin YAML të paprekur dhe të përdorshëm" (përshkrimi i huazuar drejtpërdrejt nga ). Kustomize mund të ekzekutohet drejtpërdrejt ose, duke filluar nga Kubernetes 1.14, të përdoret kubectl -k për të aksesuar funksionet e tij (ndërsa në Kubernetes 1.15, binari i veçantë është më i ri se funksionalitetet e ndërtuara në kubectl). (Shën. përk.: Me lançimin e fundit kustomize përveç kësaj në utilitarin kubeadm.) Në këtë publikim, dua të prezantoj lexuesit me bazat e kustomize.
Në formën e saj më të thjeshtë/përdorim, kustomize është thjesht një grup burimesh (skedarësh YAML, që përcaktojnë objektet Kubernetes: Deployments, Services, etj.) plus një listë udhëzimesh për ndryshimet që duhet të bëhen në këto burime. Ashtu si make përdor një set udhëzimesh të përmbajtura në Makefile, ndërsa Docker ndryn një kontejner në bazë të udhëzimeve nga Dockerfile, kustomize përdor kustomization.yaml për të ruajtur udhëzimet për ndryshimet që përdoruesi dëshiron të bëjë në grupin e burimeve.
Ja një shembull i skedarit kustomization.yaml:
resources:
- deployment.yaml
- service.yaml
namePrefix: dev-
namespace: development
commonLabels:
environment: development Nuk do të mundohem të flas për të gjitha fushat e mundshme në skedarin kustomization.yaml (për këtë është shkruar mirë ), por do të jap një shpjegim të shkurtër të shembullit të veçantë:
- Fusha
resourcestregon se (cilat burime) do të ndryshojë kustomize. Në këtë rast, ai do të kërkojë burimet në skedaretdeployment.yamldheservice.yamlnë katalogun e tij (në rast nevoje, mund të specifikohen rrugë të plota ose relative). - Fusha
namePrefixi thotĂ« kustomize tĂ« shtojĂ« njĂ« prefiks tĂ« caktuar (nĂ« kĂ«tĂ« rast âdev-) nĂ« atributinemrie tĂ« gjitha burimeve tĂ« pĂ«rcaktuara nĂ« fushĂ«nresources. KĂ«shtu, nĂ«se nĂ« Deployment kaemrime vlerĂ«nginx-deployment, kustomize do ta bĂ«jĂ« atĂ«dev-nginx-deployment. - Fusha
namespacekustomize i thotë të shtojë hapësirën e caktuar në të gjitha burimet. Në këtë rast, Deployment dhe Shërbimi do të përfshihen në hapësirën e emritzhvillim. - Së fundi, fusha
commonLabelspërmban një grup etiketash që do të shtohet në të gjitha burimet. Në shembullin tonë, kustomize do t'i japë burimeve një etiketë me emrinenvironmentdhe vlerënzhvillim.
Nëse përdoruesi kryen kustomize build . në direktoriumin me skedarin kustomization.yaml dhe burimet e nevojshme (p.sh. skedarët deployment.yaml dhe service.yaml), atëherë rezultati do të jetë teksti me ndryshimet e shkruara në kustomization.yaml.
Shën. përk.: Ilustrimi nga dokumentacioni i projektit për përdorimin "e thjeshtë" të kustomize
Të dhënat mund të redirektohen, nëse është e nevojshme për të dokumentuar ndryshimet:
kustomize build . > custom-config.yamlTë dhënat e daljes janë të ndjeshme (me të njëjtat të dhëna në hyrje do të merren të njëjtat rezultate në dalje), prandaj nuk është e nevojshme ta ruani rezultatin në skedar. Në vend të kësaj, mund ta kaloni menjëherë në komandën tjetër:
kustomize build . | kubectl apply -f - Qasja në funksionet e kustomize gjithashtu mund të arrihet përmes kubectl -k (duke nga versioni 1.14 të Kubernetes). Megjithatë, mbani në mend se paketa e veçantë kustomize azhurnohet më shpejt sesa ajo e integruar në kubectl (të paktën, kështu ndodhi me lëshimin e Kubernetes 1.15).
Lexuesit mund të pyesin: "Përse na nevojiten të gjitha këto komplike, nëse mund të redaktojmë skedarët direkt?" Një pyetje e shkëlqyer. Në shembullin tonë, në të vërtetë mund të të modifikojmë skedarët deployment.yaml dhe service.yaml direkt, por çfarë ndodh nëse ato janë një fork i projektit të dikujt? Ndryshimi i drejtpërdrejtë i skedarëve e shtyn (nëse nuk e bën të pamundur) rebase fork-un kur bëhen ndryshime në burim. Përdorimi i kustomize lejon centralizimin e këtyre ndryshimeve në një skedar kustomization.yaml, duke lënë skedarët origjinalë të paprekur dhe, kështu, duke lehtësuar nëse është e nevojshme rebase-in e skedarëve origjinalë.
Përfitimet e kustomize bëhen evidente në raste më komplekse përdorimi. Në shembullin e mësipërm kustomization.yaml dhe burimet ndodhen në të njëjtën direktori. Megjithatë, kustomize mbështet skenarë përdorimi ku ka një konfiguracion bazë dhe shumë variacione të saj, të njohura gjithashtu si overlays. Për shembull, një përdorues dëshiroi të marrë Deployment dhe Service për nginx, të cilat unë i përdora si shembull, dhe të krijojë versione zhvillimi, testimi dhe prodhimi (ose variante) të atyre skedave. Për këtë, ata do të kenë nevojë për overlays përkatëse dhe, përkatësisht, për resurset bazë.
Për të ilustruar idenë e overlays dhe resurseve bazë (resurset bazë), le të supozojmë se drejtoritë kanë këtë strukturë:
- base
- deployment.yaml
- service.yaml
- kustomization.yaml
- overlays
- dev
- kustomization.yaml
- staging
- kustomization.yaml
- prod
- kustomization.yaml Në skedar base/kustomization.yaml përdoruesit me anë të fushës resources thjesht shpallin resurset që kustomize duhet të përfshijë.
Në secilin nga skedarët overlays/{dev,staging,prod}/kustomization.yaml përdoruesit i referohen konfigurimit bazë në fushën resources, dhe më pas tregojnë ndryshimet specifike për këto mjedise. 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ë të njëjtën kohë, skedari overlays/prod/kustomization.yaml mund të jetë krejt ndryshe:
resources:
- ../../base
namePrefix: prod-
namespace: production
commonLabels:
environment: production
sre-team: blue Kur pĂ«rdoruesi tĂ« ekzekutojĂ« kustomize build . nĂ« katalog overlays/dev, kustomize do tĂ« gjenerojĂ« variantin e zhvillimit. NĂ«se ekzekutohet kustomize build . nĂ« katalog overlays/prod â do tĂ« jetĂ« njĂ« variant production. Dhe gjithĂ« kjo â pa bĂ«rĂ« ndryshime nĂ« origjinalet (bazĂ«) dosjet, dhe gjithĂ« kjo â nĂ« mĂ«nyrĂ« deklarative dhe deterministe. Mund tĂ« angazhoj konfigurimin bazĂ« dhe drejtoritĂ« overlay drejtpĂ«rdrejt nĂ« sistemin e menaxhimit tĂ« versioneve, duke ditur se nĂ« bazĂ« tĂ« kĂ«tyre dosjeve, çdoherĂ« mund tĂ« rinovohet konfigurimi i nevojshĂ«m.
Shën. përk.: Ilustrimi nga dokumentacioni i projektit për përdorimin e overlays në kustomizim
Kustomize di shumë më shumë më tepër se sa është përshkruar në këtë artikull. Megjithatë, shpresoj se do të shërbejë si një hyrje e mirë.
Burime shtesë
Ka shumë artikuj të mirë dhe publikime në lidhje me kustomizimin. Ja disa që i kam konsideruar veçanërisht të dobishme:
- ;
- ;
- ;
- .
Shën. përk.: Gjithashtu mund të rekomandoj një bllok lidhjesh, të publikuara si në faqen e utilitarit, dhe koleksionin e mëpasshëm të videove me prezantimet e fundit mbi kustomizimin.
Nëse keni ndonjë pyetje ose propozim për përmirësimin e këtij materiali, unë gjithmonë jam i hapur për reagime. Mund të kontaktoni me mua në ose në . Shijoni dhe modifikoni manifestet tuaja me anë të kustomize!
P.S. nga përkthyesi
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «»;
- «».
Burimi: habr.com
