🥇Autogjenerimi i sekreteve në Helm

Ekipa Kubernetes aaS nga Mail.ru përktheva një shënim të shkurtër rreth mënyrës si të gjeneroni automatikisht sekrete Helm gjatë azhurnimit. Më poshtë është teksti nga autori i artikullit — drejtori teknik i Intoware, një kompani zhvillimi zgjidhjesh SaaS.

Kontejnerët janë të mrekullueshëm. Në fillim isha kundër konteinerëve (është e turpshme të pranohet), por tani e mbështes plotësisht përdorimin e kësaj teknologjie. Nëse po e lexoni këtë, shpresoj të keni kaluar me sukses në detet e Docker, kuptuar përfitimet e Kubernetes dhe bërë jetën tuaj shumë më të lehtë me Helm.

Megjithatë, disa gjëra janë dukshëm më të komplikuara sesa duhet.

Si të gjeneroni automatikisht sekrete gjatë azhurnimit?

Sekreti i Kubernetes është një burim që përmban çifte çelësi/vlerë që dëshironi të përdorni në kodin tuaj. Këto mund të jenë lidhje të bazës së të dhënave, fjalëkalime të postës elektronike dhe kështu me radhë. Duke përdorur sekrete, krijoni një ndarje të qartë midis kodit dhe cilësimeve, duke përmirësuar lehtësinë e konfigurimit të azhurnimeve të ndryshme pa ndryshuar bazën e kodit.

Një situatë e zakonshme është kur dy module duhet të komunikojnë përmes një çelësi të përbashkët. Askush jashtë klasterit nuk duhet të dijë këtë çelës, pasi ai është i destinuar për lidhje "nga një në tjetër" brenda klasterit.

Krijimi i sekreteve

Zakonisht, për të krijuar një sekret në Helm, duhet:

të përshkruani sekretin në skedarin e vlerave;
ta tejkaloni atë gjatë procesit të deploy-it;
të referoheni në të brenda deploy-it/pod-it;
… fitim!

Zakonisht kjo duket pak a shumë si:

apiVersion: v1
kind: Secret
metadata:
  name: my-super-awesome-api-key
type: Opaque
stringData:
  apiKey: {{ .Values.MyApiKeySecret | quote }}

Një sekret i thjeshtë Kubernetes, duke përdorur vlerat nga values.yml

Por, le të themi se nuk dëshironi ta specifikoni sekretin tuaj në skedarin e vlerave.

Ka shumë opsione kur për deploy-in kërkohet një çelës i përbashkët, i cili duhet të gjenerohet gjatë instalimit.

Në shembullin e mësipërm me lidhjen mes moduleve, nuk është e dëshirueshme të shpërndahet sekreti jashtë deploy-it. Prandaj, është shumë e dëshirueshme që Helm të ketë mekanizma për të krijuar automatikisht sekretin pa pasur nevojë ta specifikoni atë drejtpërdrejt.

Hukut

Hooks lejojnë të ekzekutoni kod në disa pika gjatë procesit të instalimit. Ka ndoshta një detyrë konfigurimi që duhet të ekzekutohet pas instalimit të parë, ose ndoshta duhet të kryhet një pastrim para se të kryhen përditësime të çdo lloj.

Për të zgjidhur problemin tonë të shtimit të çelësit, i gjeneruar gjatë instalimit, hooks para-instaluese janë ideale. Por ka një kapak: nuk mund të gjeneroni automatikisht sekretin një herë gjatë përditësimit. Hooks do të funksionojnë me çdo përditësim.

Nëse ju keni gjeneruar sekretin tuaj, dhe instalimi juaj i parë ende nuk ka ndodhur, atëherë ndaloni së lexuari, hook para-instaluese do të jetë ideal për ju.

Por nëse sekreti është një pjesë e përditësimit (ndoshta një veçori e re që nuk ishte në instalim), atëherë është e pakëndshme që nuk është e mundur të krijoni një hook para-instaluese që do të funksiononte vetëm një herë.

Funksionet

Funksionet e Helm lejojnë shtimin e elementeve të ndryshme të skriptit në skenarët e shpërndarjes.

apiVersion: v1
kind: Secret
metadata:
  name: my-super-awesome-api-key
type: Opaque
stringData:
  apiKey: {{ uuidv4 | quote }} #Generoni një UUID të ri dhe citojeni atë

Në këtë shembull, vlera e sekretit apiKey do të jetë një UUID i ri, i gjeneruar gjatë instalimit.

Helm përfshin një bibliotekë të vërtetë të gjerë funksionesh, e cila përdor karakteristika mbresëlënëse të shabllonit GO dhe bibliotekën e funksioneve Sprig për të krijuar shpërndarje të personalizuara.

Funksioni Lookup

Në Helm 3.1 u shtua funksioni Lookup, i cili lejon të kërkoni një shpërndarje ekzistuese dhe:

të kontrolloni ekzistencën e burimeve;
të ktheni vlerën e një burimi ekzistues për përdorim të mëvonshëm.

Duke përdorur të dy këto mundësi, ne mund të krijojmë një sekret të gjeneruar dinamikisht për një herë!

# 1. Запросить существование секрета и вернуть в переменной $secret
{{- $secret := (lookup "v1" "Secret" .Release.Namespace "some-awesome-secret" -}}
apiVersion: v1
kind: Secret
metadata:
  name: some-awesome-secret
type: Opaque

# 2. Если секрет существует, взять его значение как apiKey (секрет использует кодирование Base64, так что используйте ключ "data")
{{ if $secret -}}
data:
  apiKey: {{ $secret.data.apiKey }}

# 3. Если секрет не существует — создать его (в этот раз используйте "stringData", так как будет обычное значение)!
{{ else -}}
stringData:
  apiKey: {{ uuidv4 | quote }}
{{ end }}

Sa herë që aplikohet një përditësim i ri në server, Helm do të gjenerojë një vlerë të re për sekretin (nëse sekreti nuk ekziston akoma), ose do të ripërdorë vlerën ekzistuese.

Suksese!

Çfarë tjetër të lexoni në këtë temë:

Burimi: habr.com