Rakenduste juurutamine mitmetes Kubernetes klastrites Helmiga

Kuidas Dailymotion kasutab Kubernetes't: rakenduste juurutamine

Me Dailymotion'is alustasime Kubernetes'e kasutamist tootmisest 3 aastat tagasi. Kuid rakenduste juurutamine mitmetes klastrites on tõeline väljakutse, mistõttu oleme viimastel aastatel püüdnud oma tööriistu ja töövooge parandada.

Kust see kõik algas

Siin räägime, kuidas me juurutame oma rakendusi mitmetes Kubernetes'i klastrites üle maailma.

Küsimisel, kuidas juurutada mitmeid Kubernetes'i objekte korraga, kasutame Helm, ja kõik meie chart'id on salvestatud ühes git-repos. Rakenduse täieliku stack'i juurutamiseks, mis koosneb mitmest teenusest, kasutame nn üldist chart'i. See on põhimõtteliselt chart, mis määratleb sõltuvused ja võimaldab algatada API ning selle teenused ühe käsuga.

Lisaks oleme kirjutanud väikese Python'i skripti Helm'i peale, et teha kontrollimisi, luua chart'e, lisada salajasi andmeid ja juurutada rakendusi. Kõiki neid ülesandeid täidetakse keskse CI platvormi abil docker'i pildi kaudu.

Läheme asja juurde.

Märkus. Kui te seda loete, on esimene Helm 3 versiooni kandidaat juba välja kuulutatud. Peamine versioon sisaldab hulga parandusi, mille eesmärgiks on lahendada mõned eelmisel ajal tekkinud probleemid.

Chart'ide arendamise töövoog

Rakenduste jaoks kasutame harude loomist ja otsustasime selle sama lähenemise rakendada ka chart'idele.

• Haru dev kasutatakse chart'ide loomiseks, mis testitakse arendusklastrites.
• Kui pull-ettepanek esitatakse master, kontrollitakse neid stseeni tasemel.
• Lõpuks loome pull-ettepaneku, et edastada muudatused haru prod ja rakendada need tootmises.

Igal keskkonnal on oma privaatne repos, mis hoiab meie chart'e, ja me kasutame Chartmuseum'i kõigi kasulike API-dega. Nii tagame ranget isoleeritust keskkondade vahel ja controlime chart'e reaalsetes tingimustes, enne kui kasutame neid tootmises.

Chart'ide reposid erinevates keskkondades

Tasub märkida, et kui arendajad saadavad haru dev, saadetakse nende chart'i versioon automaatselt dev Chartmuseum'i. Nii kasutavad kõik arendajad ühte dev reposi ja tuleb hoolikalt märkida oma chart'i versioon, et mitte kogemata kasutada kellegi teise muudatusi.

Veel meer, meie väike Python skript kontrollib Kubernetes objekte Kubernetes OpenAPI spetsifikatsioonide põhjal Kubeval, enne kui need avaldatakse Chartmusesse.

Chart’i arendamise töökäigu üldine ülevaade

1. Pipeliini ülesannete seadistamine spetsifikatsiooni järgi gazr.io kvaliteedikontrolliks (lint, üksuste testimine).
2. Docker'i pildi saatmine koos Python'i tööriistadega, mis juurutavad meie rakendused.
3. Keskkonna seadistamine harunime järgi.
4. Kubernetes yaml failide kontrollimine Kubeval’i abil.
5. Chart’i ja selle vanemate chart’ide (chart’id, mis sõltuvad muudetavast chart’ist) versiooni automaatne tõstmine.
6. Chart'i saatmine Chartmuseumisse, mis vastab oma keskkonnale

Erinevuste haldamine klastrites

Klastrite föderatsioon

Oli aeg, mil kasutasime Kubernetes klastrite föderatsiooni, kus Kubernetes objekte sai kuulutada ühe API lõpp-punkti kaudu. Kuid tekkisid probleemid. Näiteks teatud Kubernetes objekte ei saanud föderatsiooni lõpp-punktis luua, mistõttu oli keeruline hallata ühendatud objekte ja muid objekte eraldi klastrite jaoks.

Probleemi lahendamiseks hakkasime haldama klastreid sõltumatult, mis lihtsustas protsessi oluliselt (kasutades föderatsiooni esimest versiooni; teises võis midagi muutuda).

Geograafiliselt jaotatud platvorm

Praegu on meie platvorm jaotatud kuude regioonide vahel — kolm kohalikku ja kolm pilves.

Jaotatud juurutamine

Globaalne Helm'i väärtus

4 globaalset Helm'i väärtust aitavad määratleda erinevusi klastrite vahel. Kõikide meie chart'ide jaoks on minimaalsed vaikeväärtused.

global:
  cloud: True
  env: staging
  region: us-central1
  clusterName: staging-us-central1

Globaalne väärtus

Need väärtused aitavad määratleda konteksti meie rakendustele ja neid kasutatakse erinevatel ülesannetel: jälgimine, jälitamine, logimine, välistes kõnedes osalemine, skaleerimine jne.

• "cloud": meil on hübriidne Kubernetes platvorm. Näiteks meie API juurutatakse GCP tsoonides ja meie andmekeskustes.
• "env": mõned väärtused võivad erineda mitte-toimivates keskkondades. Näiteks ressursside määratlemised ja automaatse skaleerimise konfiguratsioon.
• "region": see teave aitab määrata klastri asukohta ja seda saab kasutada väliste teenuste lähima lõpp-punkti määramiseks.
• "clusterName": kui ja millal tahame määrata väärtuse eraldi klastri jaoks.

Siin on konkreetne näide:

{{
/* Tagastab GraphQL-i horisontaalse podi autoskaalija koopiate arvu */}}
{{- define "graphql.hpaReplicas" -}}
{{- if eq .Values.global.env "prod" }}
{{- if eq .Values.global.region "europe-west1" }}
minReplicas: 40
{{- else }}
minReplicas: 150
{{- end }}
maxReplicas: 1400
{{- else }}
minReplicas: 4
maxReplicas: 20
{{- end }}
{{- end -}}

Helmi mall näide

See loogika on määratletud abimallis, et mitte ummistada Kubernetes YAML-i.

Rakenduse väljakuulutamine

Meie juurutustööriistad põhinevad mitmel YAML-failil. Siin on näide, kuidas me kuulutame välja teenuse ja selle skaleerimis-topoloogia (koopiate arv) klastris.

releases:
  - foo.world

foo.world:                # Väljalaske nimi
  services:               # Dailymotioni rakenduste/projektide loetelu
    foobar:
      chart_name: foo-foobar
      repo: git@github.com:dailymotion/foobar
      contexts:
        prod-europe-west1:
          deployments:
            - name: foo-bar-baz
              replicas: 18
            - name: another-deployment
              replicas: 3

Teenuse määratlemine

See on skeem kõigist sammudest, mis määratlevad meie juurutusprotsessi. Viimane samm juurutab rakenduse samal ajal mitmes töökllastri.

Jenkinsis juurutamise sammud

Aga saladused?

Turvalisuse osas jälgime kõiki saladusi erinevatest kohtadest ja hoiame neid unikaalses salvestusruumis Vault Pariisis.

Meie juurutustööriistad tõmbavad saladuste väärtusi Vaultist ja kui on aeg juurutamiseks, sisestavad nad need Helmisse.

Selle jaoks oleme määratlenud vastavuse Vaultis olevate saladuste ja meie rakenduste vajalike saladuste vahel:

salad:                                                                                                                                                                                                        
     - secret_id: "stack1-app1-password"                                                                                                                                                                                  
       contexts:                                                                                                                                                                                                   
         - name: "default"                                                                                                                                                                                         
           vaultPath: "\/kv\/dev\/stack1\/app1\/test"                                                                                                                                                               
           vaultKey: "password"                                                                                                                                                                                    
         - name: "cluster1"                                                                                                                                                                           
           vaultPath: "\/kv\/dev\/stack1\/app1\/test"                                                                                                                                                               
           vaultKey: "password"

• Oleme määratlenud üldised põhimõtted, mida tuleb järgida saladuste registreerimisel Vaultis.
• Kui saladus kuulub kindlasse konteksti või klastrisse, tuleb lisada konkreetne kirje. (Siin on kontekstis cluster1 saladuse stack-app1-password jaoks oma väärtus).
• Muidu kasutatakse väärtust vaikimisi.
• Iga punkti jaoks selles loendis lisatakse Kubernetes'i saladusse võti-väärtus paar. Seetõttu on saladuse mall meie chartides väga lihtne.

apiVersion: v1
data:
{{- range $key,$value := .Values.secrets }}
  {{ $key }}: {{ $value | b64enc | quote }}
{{ end }}
kind: Secret
metadata:
  name: "{{ .Chart.Name }}"
  labels:
    chartVersion: "{{ .Chart.Version }}"
    tillerVersion: "{{ .Capabilities.TillerVersion.SemVer }}"
type: Opaque

Probleemid ja piirangud

Töötamine mitme repodega

Praegu jagame chartide ja rakenduste arendust. See tähendab, et arendajad peavad töötama kahes git-repos, üks rakenduse jaoks ja teine selle juurutamise määratlemiseks Kubernetesis. 2 git-repositooriumi tähendab 2 tööprotsessi ja algajal on lihtne segadusse minna.

Üldiste chartide haldamine on tülikas

Nagu me juba mainisime, on üldised chartid väga mugavad sõltuvuste määratlemiseks ja mitme rakenduse kiireks juurutamiseks. Kuid me kasutame --reuse-values, et vältida kõigi väärtuste edastamist iga kord, kui me rakendust, mis kuulub sellesse üldisesse charti, juurutame.

Tõhusa pideva tarnimise protsessis on meil vaid kaks väärtust, mis pidevalt muutuvad: koopiate arv ja pildi silt (versioon). Teised, stabiilsemad väärtused muudetakse käsitsi ja see on üsna keeruline. Veelgi enam, üks viga üldise chart'i juurutamisel võib viia tõsiste tõrgeteni, nagu oleme oma kogemustest kogenud.

Mitme konfiguratsioonifaili uuendamine

Kui arendaja lisab uue rakenduse, peab ta muutma mitmeid faile: rakenduse kuulutamise, saladuste nimekirja, rakenduse lisamise sõltuvustesse, kui see kuulub üldisesse chart'i.

Jenkins'i õigused on Vault'is liiga laiad

Praegu on meil üks AppRole, mis loeb kõiki saladusi Vault'ist.

Tagasivõtmise protsess ei ole automatiseeritud

Tagasivõtmiseks tuleb käivitada käsk mitmel klastril, mis on eksitav. Teeme seda toimingut käsitsi, et kindlalt näidata õiget versiooniidentifikaatorit.

Liigume GitOps'i suunas

Meie eesmärk

Soovime tuua chart'i tagasi rakenduse repository'sse, mida ta juurutab.

Töökäik on sama, nagu arenduses. Näiteks, kui haru saadetakse masterisse, siis juurutamine käivitatakse automaatselt. Peamine erinevus sellise lähenemise ja hetke töökäigu vahel on see, et kõike hallatakse git'is (ise rakendus ja kuidas seda Kubernetes'es juurutada).

Eeliseid on mitu:

• Oluliselt arendajale arusaadavam . Lihtsam on õppida, kuidas kohandada muudatusi kohalikus chart'is.
• Teenuse juurutamise määratlemine saab toimuda seal, kus on kood teenusest.
• Üldiste chart'ide eemaldamise haldamine. Teenusel on oma Helm'i väljaanne. See võimaldab hallata rakenduse elutsüklit (tagasivõtt, uuendus) kõige väiksemal tasemel, et mitte mõjutada teisi teenuseid.
• Git'i eelised chart'ide haldamiseks: muudatuste tühistamine, auditi ajalugu jne. Kui chart'i muudatus tuleb tühistada, saab seda teha git'i abil. Juurutamine käivitatakse automaatselt.
• Võib mõelda töövoo täiustamisele selliste tööriistade abil nagu Skaffold, millega arendajad saavad testida muudatusi kontekstis, mis sarnaneb tootmistingimustele.

Kaks sammu migreerimise

Meie arendajad on kasutanud seda töövoogu juba 2 aastat, nii et me vajame võimalikult sujuvat migratsiooni. Seetõttu otsustasime lisada vaheetapi teele eesmärgile.
Esimene etapp on lihtne:

• Säilitame sarnase struktuuri rakenduste käitamise seadistamiseks, kuid ühes objektis nimega DailymotionRelease.

apiVersion: "v1"
kind: "DailymotionRelease"
metadata:
  name: "app1.ns1"
  environment: "dev"
  branch: "mybranch"
spec:
  slack_channel: "#admin"
  chart_name: "app1"
  scaling:
    - context: "dev-us-central1-0"
      replicas:
        - name: "hermes"
          count: 2
    - context: "dev-europe-west1-0"
      replicas:
        - name: "app1-deploy"
          count: 2
  secrets:
    - secret_id: "app1"
      contexts:
        - name: "default"
          vaultPath: "\/kv\/dev\/ns1\/app1\/test"
          vaultKey: "password"
        - name: "dev-europe-west1-0"
          vaultPath: "\/kv\/dev\/ns1\/app1\/test"
          vaultKey: "password"

• 1 väljalaskmine rakendusele (ilma üldiselt chartideta).
• Chartid rakenduse git-repositooriumis.

Me oleme rääkinud kõikide arendajatega, nii et migratsiooniprotsess on juba alanud. Esimest etappi juhitakse endiselt CI platvormi abil. Varsti kirjutan veel ühe postituse teisest etapist: kuidas me läksime üle GitOps töövoole Flux. Räägin, kuidas me kõik seadistasime ja milliste raskustega silmitsi seisime (mitmed repositooriumid, saladused jne). Jälgige uudiseid.

Siin proovime kirjeldada meie edusamme rakenduste juurutamise töövoos viimastel aastatel, mis viis meid mõteteni GitOps lähenemise osas. Me ei ole veel eesmärgile jõudnud ja anname tulemuste kohta teada, kuid oleme praegu veendunud, et tegime õigesti, kui otsustasime kõik lihtsustada ja viia arendajate harjumustele lähemale.

Allikas: habr.com