ShĂ«n. pĂ«rkth.: Artikulli Ă«shtĂ« shkruar nga Scott Lowe â njĂ« inxhinier me shumĂ« pĂ«rvojĂ« nĂ« IT, autori/ko-autori i shtatĂ« librave tĂ« printuar (ndĂ«rsa kryesisht pĂ«r VMware vSphere). Ai aktualisht punon nĂ« nĂ«norganizatat e VMware â Heptio (e blerĂ« nĂ« vitin 2016), me specializim nĂ« llogaritĂ« nĂ« re dhe Kubernetes. Teksti shĂ«rben si njĂ« hyrje e shkurtĂ«r dhe e lehtĂ« pĂ«r t'u kuptuar nĂ« menaxhimin e konfigurimeve pĂ«r Kubernetes pĂ«rmes teknologjisĂ« , qĂ« sĂ« fundmi Ă«shtĂ« bĂ«rĂ« pjesĂ« e K8s.
Kustomize është një mjet që lejon përdoruesit "të konfigurojnë skedarët e thjeshtë dhe të lirë nga shabllonët YAML për qëllime të ndryshme, duke lënë origjinalin YAML të paprekur dhe të gatshëm për përdorim" (përshkrimi është marrë drejtpërdrejt nga ). Kustomize mund të ekzekutohet drejtpërdrejt ose, që nga Kubernetes 1.14, të përdoret kubectl -k për qasje në funksionet e tij (pavarësisht se që nga Kubernetes 1.15, një binar i veçantë është më i fundit se funksionalitetet e ndërtuara në kubectl). (Shën. përkth.: Me publikimin e fundit (për t'iu thënë, zhvillimi tani po bëhet në një repository të veçantë), pra për të përpunuar YAML-të shtesë nga direktori të veçanta kustomization (detajet për përdorimin e tyre shih në edhe në utilitarin kubeadm.) Në këtë publikim, dua t'i njoh lexuesit me bazat e kustomize.
Në formën e saj më të thjeshtë/a, kustomize është thjesht një grup burimesh (skedarë YAML që përcaktojnë objekte Kubernetes: Deployments, Services, etj.) plus një listë instrukcionesh për ndryshimet që duhen bërë në këto burime. Ashtu siç make përdor një grup instrukcionesh që ndodhen në Makefile, dhe Docker ndërtën një enë mbi bazën e instrukcioneve nga Dockerfile, kustomize përdor kustomization.yaml për të ruajtur rregullat se cilat ndryshime dëshiron përdoruesi 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ë përpiqem të flas për të gjitha fushat e mundshme në skedarin kustomization.yaml (për këtë është shkruar mjaft 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ë skedarëtdeployment.yamldheservice.yamlnë katalogun e tij (nëse është e nevojshme, mund të specifikohen rrugë të plota ose relative). - Fusha
namePrefixi jep kustomize-sĂ« urdhrin pĂ«r tĂ« shtuar njĂ« prefiks tĂ« caktuar (nĂ« kĂ«tĂ« rast âdev-) nĂ« atributinemrie tĂ« gjithĂ« burimeve qĂ« pĂ«rcaktohen nĂ« fushĂ«nresources. KĂ«shtu, nĂ«se nĂ« Deployment kaemrime vlerĂ«nnginx-deployment, kustomize do ta kthejĂ« atĂ« nĂ«dev-nginx-deployment. - Fusha
namespacepërcakton që kustomize të shtojë hapësirën e specifikuar të emrave në të gjitha burimet. Në këtë rast, Deployment dhe Service do të bien në hapësirën e emravezhvillim. - Në fund, fusha
commonLabelspërmban një grup etiketash që do të shtohen në të gjitha burimet. Në shembullin tonë, kustomize do të caktojë burimeve një etiketë me emrinmjedisdhe vlerënzhvillim.
Nëse përdoruesi ekzekuton kustomize build . në direktorinë me skedarin kustomization.yaml dhe burimet e nevojshme (pra, skedarët deployment.yaml dhe service.yaml), atëherë në dalje do të marrë tekstin me ndryshimet e përcaktuara në kustomization.yaml.
Shën. përkth.: Ilustrimi nga dokumentacioni i projektit për përdorimin "e thjeshtë" të kustomize
Dalja mund të ridrejtohet nëse është e nevojshme të ruhet ndryshimi:
kustomize build . > custom-config.yamlTë dhënat në dalje janë të përcaktuara (me të njëjtat të dhëna në hyrje do të marrin të njëjtat rezultate në dalje), prandaj nuk është e nevojshme ta ruani rezultatin në skedar. Në vend të kësaj, mund ta kaloni drejtpërdrejt në një komandë tjetër:
kustomize build . | kubectl apply -f - Qasje në funksionalitetet e kustomize gjithashtu mund të merret përmes kubectl -k (duke filluar nga versioni 1.14 i Kubernetes). Sidoqoftë, mbani në mend se paketi i veçantë kustomize përditësohet më shpejt se ai i integruar në kubectl (të paktën, kështu është situata me publikimin e Kubernetes 1.15).
Lexuesit mund të pyesin: "Pse janë të gjitha këto komplimente, nëse mund të redaktojmë skedarët direkt?". Pyetje e shkëlqyer. Në shembullin tonë, me të vërtetë mund të modifikimi i skedarëve deployment.yaml dhe service.yaml direkt, por çfarë nëse ata janë një fork i një projekti të dikujt? Modifikimi i drejtpërdrejtë i skedarëve e vështirëson (nëse nuk e bën të pamundur) rebase të forkut, kur bëhen ndryshime në burimin/faqen e origjinës. Përdorimi i kustomize lejon që këto ndryshime të centralizohen në një skedar kustomization.yaml, duke lënë skedarët origjinalë të paprekur dhe, kështu, duke lehtësuar ribashkimin e skedarëve origjinalë, nëse është e nevojshme.
Avantazhet e kustomize bëhen të dukshme në raste më të komplikuara përdorimi. Në shembullin e lartpërmendur kustomization.yaml dhe burimet ndodhen në të njëjtën direktori. Sidoqoftë, kustomize mbështet skenarë përdorimi ku ka një konfigurim bazë dhe shumë variacione të saj, të njohura gjithashtu si komanda e re. Për shembull, përdoruesi mund të dëshirojë të marrë Deployment dhe Service për nginx, të cilat unë i kam përdorur si shembull, dhe të krijojë versione (ose variacione) development-, staging-, dhe production- të atyre skedarëve. Për këtë, do t'i duhen overlays të përmendura më sipër dhe, përkatësisht, burimet bazë vetë.
Për të ilustruar idenë e overlays dhe resurseve bazë (resurset bazë), le të supozojmë se direktorët kanë strukturën e mëposhtme:
- 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ë duhet të përfshijë kustomize.
Në çdo skedë overlays/{dev,staging,prod}/kustomization.yaml përdoruesit referohen në konfigurimin bazë në fushën resources, dhe më pas specifikojnë ndryshimet e veçanta për këtë mjedis. Për shembull, skeda 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, skeda overlays/prod/kustomization.yaml mund të jetë krejtësisht e ndryshme:
resources:
- ../.. /base
namePrefix: prod-
namespace: production
commonLabels:
environment: production
sre-team: blue Kur përdoruesi të ekzekutojë kustomize build . në katalogun overlays/dev, kustomize do të gjenerojë variantin development. Nëse ekzekutohet kustomize build . në katalogun overlays/prod , do të marrësh variantin production. Dhe gjithë kjo, pa bërë asnjë ndryshim në skedat origjinale (bazë) , dhe gjithë kjo në një mënyrë deklarative dhe të përcaktuar. Mund të angazhoj konfigurimin bazë dhe direktorët overlay direkt në sistemin e menaxhimit të versioneve, duke ditur se mbi këto skeda, në çdo moment, mund të riprodhohet konfigurimi i nevojshëm.
Shën. përkth.: Ilustrimi nga dokumentacioni i projektit për përdorimin e overlays në kustomize
Kustomize di shumë më shumë se sa është përmendur në këtë artikull. Megjithatë, shpresoj se do të jetë një hyrje e mirë.
Burime të tjera
Ka shumë artikuj dhe publikime të mira mbi kustomize. Ja disa, që i kam konsideruar veçanërisht të dobishme:
- ;
- ;
- ;
- .
Shën. përkth.: Mund të rekomandohen gjithashtu blloket e lidhjeve, të publikuara si në faqen e veglës, dhe koleksioni që pason me video mbi prezantimet më të fundit rreth kustomize.
Nëse keni pyetje ose sugjerime për përmirësimin e këtij materiali, unë gjithmonë jam i hapur për reagime. Mund të më kontaktoni në ose në . Shijoni modifikimin e manifestacioneve tuaj me anë të kustomize!
P.S. nga përkthyesi
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «»;
- «».
Burimi: habr.com
