Pertsonalizatzeko sarrera laburra

Ohar. itzul.: artikulua Scott Lowe-k idatzi zuen, ITn esperientzia handia duen ingeniariak, inprimatutako zazpi libururen (batez ere VMware vSphere-n) egilea/egilekidea dena. Orain Heptio VMware filialean lan egiten du (2016an erosia), hodeiko informatikan eta Kubernetesen espezializatuta. Testuak berak teknologia erabiliz Kubernetes-en konfigurazio kudeaketarako sarrera zehatz eta ulerterraza gisa balio du. Pertsonalizatu, duela gutxi K8s-en parte bihurtu zena.

Kustomize tresna bat da, erabiltzaileek "txantiloirik gabeko YAML fitxategi sinpleak pertsonalizatzeko aukera desberdinetarako, jatorrizko YAML osorik eta erabilgarri utziz" (deskribapena zuzenean mailegatuta). kustomize biltegia GitHub-en). Kustomize zuzenean exekutatu daiteke edo, Kubernetes 1.14tik aurrera, erabil daiteke kubectl -k bere funtzionaltasuna atzitzeko (nahiz eta Kubernetes 1.15etik aurrera, bereizitako bitarra kubectl-en eraikitako gaitasunak baino berriagoa den). (Ohar. itzul.: Eta berriki argitaratutakoarekin Kubernetes 1.16 pertsonalizatu euskarria kubeadm erabilgarritasunean ere.) Post honetan, irakurleei kustomize-ren oinarriak aurkeztu nahi dizkiet.

Bere forma/aplikaziorik errazenean, kustomize baliabideen bilduma bat besterik ez da (Kubernetes-eko objektuak definitzen dituzten YAML fitxategiak: inplementazioak, zerbitzuak, etab.) gehi baliabide horietan egin behar diren aldaketen argibideen zerrenda. Make-k barruan dagoen instrukzio-multzoa erabiltzen duen bezala Makefile, eta Docker-ek edukiontziaren argibideetan oinarrituta eraikitzen du Dockerfile, erabilerak pertsonalizatu kustomization.yaml erabiltzaileak baliabide multzo batean egin nahi dituen aldaketei buruzko argibideak gordetzeko.

Hona hemen adibide fitxategi bat kustomization.yaml:

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

Ez naiz saiatuko fitxategiko eremu posible guztiei buruz hitz egiten. kustomization.yaml (Hori buruz ondo idatzita dago Hemen), baina adibide zehatz baten azalpen labur bat emango dut:

• Field resources kustomize zer (zein baliabide) aldatuko den adierazten du. Kasu honetan, fitxategietan baliabideak bilatuko ditu deployment.yaml и service.yaml zure direktorioan (bide osoa edo erlatiboa zehaztu dezakezu behar izanez gero).
• Field namePrefix kustomize-ri aurrizki jakin bat gehitzeko agintzen dio (kasu honetan - dev-) egotzi name eremuan definitutako baliabide guztiak resources. Horrela, Inplementak badu name esanahiarekin nginx-deployment, pertsonalizatzeak egingo du dev-nginx-deployment.
• Field namespace Kustomize-ri agintzen dio emandako izen-espazioa baliabide guztietan gehitzeko. Kasu honetan, Hedapena eta Zerbitzua izen-eremuan sartuko dira development.
• Azkenik, zelaia commonLabels baliabide guztiei gehituko zaizkien etiketa multzo bat dauka. Gure adibidean, kustomize-k etiketa bat esleituko die izena duten baliabideei environment eta esanahia development.

Erabiltzaileak egiten badu kustomize build . fitxategia duen direktorioan kustomization.yaml eta beharrezko baliabideak (hau da, fitxategiak deployment.yaml и service.yaml), orduan irteeran testu bat jasoko du bertan zehaztutako aldaketekin kustomization.yaml.

Ohar. itzul.: Kustomize-ren erabilera “sinpleari” buruzko proiektuaren dokumentazioko ilustrazioa

Irteera birbideratu daiteke aldaketak egin behar badira:

kustomize build . > custom-config.yaml

Irteerako datuak deterministikoak dira (sarrerako datu berdinek irteerako emaitza berdinak sortuko dituzte), beraz, ez duzu emaitza fitxategi batean gorde beharrik. Horren ordez, zuzenean beste komando batera pasa daiteke:

kustomize build . | kubectl apply -f -

Kustomize funtzioak bidez ere atzi daitezke kubectl -k (Kubernetes 1.14 bertsiotik). Hala ere, kontuan izan kustomize pakete autonomoa kubectl pakete integratua baino azkarrago eguneratzen dela (kubernetes 1.15 bertsioarekin hori gertatzen da behintzat).

Irakurleek galdetu dezakete: "Zergatik konplexutasun hori guztia fitxategiak zuzenean edita ditzakezun?" Galdera bikaina. Gure adibidean, hain zuzen ko ahal fitxategiak aldatu deployment.yaml и service.yaml zuzenean, baina beste baten proiektuaren sardexka bat badira? Fitxategiak zuzenean aldatzeak zaildu egiten du (ez bada ezinezkoa) bidegurutze bat aldatzea jatorrian/iturburuan aldaketak egiten direnean. Kustomize erabiltzeak aldaketa hauek fitxategi batean zentralizatzeko aukera ematen du kustomization.yaml, jatorrizko fitxategiak osorik utziz eta, horrela, beharrezkoa izanez gero jatorrizko fitxategiak berriro oinarritzea erraztuz.

Kustomize-ren onurak erabilera-kasu konplexuagoetan nabaritzen dira. Goiko adibidean kustomization.yaml eta baliabideak direktorio berean daude. Hala ere, kustomize-k oinarrizko konfigurazio bat eta haren aldaera asko dauden erabilera kasuak onartzen ditu, izenez ere ezagutzen direnak geruza. Adibidez, erabiltzaile batek Deployment and Service hartu nahi zuen nginx-erako, nik adibide gisa erabili nuena, eta fitxategi horien garapen, eszenatze eta ekoizpen bertsioak (edo aldaerak) sortu. Horretarako, aipatutako gainjartzeak eta, hain zuzen ere, oinarrizko baliabideak berak beharko ditu.

Gainjartzeen eta azpiko baliabideen ideia ilustratzeko (oinarrizko baliabideak), demagun direktorioek egitura hau dutela:

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

Fitxategian base/kustomization.yaml eremua erabiltzen duten erabiltzaileak resources besterik gabe, kustomize-k barne hartu behar dituen baliabideak deklaratu.

Fitxategi bakoitzean overlays/{dev,staging,prod}/kustomization.yaml erabiltzaileek oinarrizko konfigurazioa aipatzen dute eremuan resources, eta ondoren adierazi aldaketa zehatzak emandako ingurunea. Adibidez, fitxategia overlays/dev/kustomization.yaml lehenago emandako adibidearen itxura izan liteke:

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

Kasu honetan fitxategia overlays/prod/kustomization.yaml guztiz ezberdina izan daiteke:

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

Erabiltzaileak korrika egiten duenean kustomize build . katalogoan overlays/dev, kustomize-k garapen aukera sortuko du. Korrika egiten baduzu kustomize build . katalogoan overlays/prod - Ekoizpen aukera lortzen duzu. Eta hori guztia - jatorrizkoan inolako aldaketarik egin gabe (oinarria) fitxategiak, guztiak modu deklaratiboan eta deterministikoan. Oinarrizko konfigurazioa eta gainjarritako direktorioak zuzenean bertsio-kontrolera konprometi ditzakezu, jakinik fitxategi horietan oinarrituta nahi duzun konfigurazioa edozein unetan erreproduzi dezakezula.

Ohar. itzul.: Kustomize-n gainjartzeak erabiltzeari buruzko proiektuaren dokumentazioko ilustrazioa

Pertsonalizatu ahal asko artikulu honetan jasotzen dena baino gehiago. Hala ere, espero dut sarrera on gisa balio izatea.

Baliabide osagarriak

Kustomize-ri buruzko artikulu eta argitalpen on asko daude. Hona hemen bereziki erabilgarriak iruditu zaizkidan batzuk:

• Aldatu oinarrizko YAML konfigurazioa ingurune desberdinetarako prod/proba Kustomize erabiliz;
• Kustomize — Kubernetesen txantiloiak egiteko modu egokia;
• Kubernetes Objektuen Adierazpen Kudeaketa Customize erabiliz;
• Pertsonalizatzea Upstream Helm diagramak Customize-rekin.

Ohar. itzul.: gisa argitaratutako esteken bloke bat ere gomenda dezakezu Baliabideak utilitatearen webgunean, eta ondoren kustomize-ri buruzko azken txostenak dituzten bideo bilduma.

Material hau hobetzeko galdera edo iradokizunik baduzu, beti nago iritziak jasotzeko. Nirekin harremanetan jar zaitezke Twitter edo Kubernetes Slack kanala. Ondo pasa zure manifestuak kustomize-rekin aldatzen!

PS itzultzailetik

Irakurri ere gure blogean:

• «Kubernetesen exekutatzen diren aplikazioen garatzaileentzako tresnak»;
• «Kubernetes 1.14: berritasunaren aipagarrienak»;
• «Amsterdameko Helm Summit 2019ko bost emaitza nagusi»;
• «Kubernetes - Helm paketeen kudeatzaileari buruzko sarrera praktikoa'.

Iturria: www.habr.com