🥇Rakenduste juurutamine mitmes Kubernetes klastris Helm

Kuidas Dailymotion kasutab Kubernetes't: rakenduste juurutamine

Me Dailymotionis oleme hakanud Kubernetes't tootmises kasutama kolm aastat tagasi. Ent rakenduste juurutamine mitmel klastril on olnud paras väljakutse, seetõttu oleme viimastel aastatel püüdnud oma tööriistu ja töövooge täiustada.

Kust kõik algas

Siin räägime, kuidas me juurutame oma rakendusi mitmel Kubernetes klastril üle kogu maailma.

Küsimuseks, kuidas korraga mitut Kubernetes objekti juurutada, me kasutame Helm, ja kõik meie chart'id on hoitud ühes git-repos. Täieliku rakenduste virna juurutamiseks mitmest teenusest kasutame nii nimetatud koondchart'i. Essentsiaalselt on see chart, mis kuulutab välja sõltuvused ja võimaldab initsialiseerida API-d ja selle teenuseid ühe käsuga.

Oleme ka kirjutanud väikese Python skripti Helm'i kohale, et teostada kontrollid, luua chart'e, lisada salajaid ja juurutada rakendusi. Kõik need ülesanded täidetakse keskses CI platvormis docker'i abil.

Liigume oluliste asjade juurde.

Märge. Kui te seda loete, on Helm 3 esimene versioonkandidaat juba välja kuulutatud. Peamine versioon sisaldab mitmeid täiustusi, mis on suunatud varasemate probleemide lahendamisele.

Chartide arendamise töövoog

Rakenduste jaoks kasutame haru loomist ja otsustasime selle lähenemise rakendada ka chartide puhul.

Haru dev kasutatakse chartide loomiseks, mida testitakse arendusklastrites.
Kui pull-ettepanek esitatakse master, kontrollitakse neid stendis.
Lõpuks loome pull-ettepaneku, et edastada muudatused harusse prod ja rakendada neid tootmises.

Igal keskkonnal on oma privaatne hoidla, mis salvestab meie chartid, ja kasutame Chartmuseum kuna see pakub väga kasulikke API-sid. Nii garantii, et keskkondade vahel on range isoleeritus ja chartide testimine reaalses olukorras enne nende tootmisesse rakendamist.

Chartide hoidlad erinevates keskkondades

Oluline on märkida, et kui arendajad saadavad dev haru, saadetakse nende charti versioon automaatselt dev Chartmuseumisse. Seeläbi kasutavad kõik arendajad ühte dev hoidlat ja on oluline täpselt näidata oma charti versioon, et mitte kasutada kellegi teise muudatusi.

Lisaks kontrollib meie väike Python skript Kubernetes objekti nende Kubernetes OpenAPI spetsifikatsioonide järgi. Kubeval, enne nende avaldamist Chartmuseumis.

Charti arendusprotsessi üldine kirjeldus

Töövooprotsessi ülesannete seadmine spetsifikatsiooni järgi gazr.io kvaliteedikontrolli (lint, unit-test) jaoks.
Docker pildi saatmine koos Python tööriistadega, mis käivitavad meie rakendusi.
Keskkonna seadistamine haru nime järgi.
Kubernetes yaml failide kontrollimine Kubeval abil.
Charti ja selle vanemate chartide (chartide, mis sõltuvad muudetavast chartist) automaatne versiooni tõstmine.
Charti saatmine Chartmuseumisse, mis vastab tema keskkonnale.

Klastrite erinevuste haldamine

Klastrite föderatsioon

Oli aeg, mil me kasutasime Kubernetesi klastrite föderatsiooni., kus Kubernetes objektide väljakuulutamiseks oli üks API lõpp-punkt. Kuid tekkisid probleemid. Näiteks ei olnud mõningaid Kubernetes objekte võimalik liidusõlmes luua, seetõttu oli keeruline hallata ühendatud objekte ja teisi objekte eraldi klastrite jaoks.

Probleemi lahendamiseks hakkasime haldama klasse iseseisvalt, mis lihtsustas protsessi oluliselt (kasutasime föderatsiooni esimest versiooni; teises võis midagi muutuda).

Geograafiliselt jaotatud platvorm

Praegu on meie platvorm jaotatud 6 regiooni — 3 kohalikku ja 3 pilve.

Jaotatud kasutuselevõtt

Globaalne Helm väärtused

4 globaalse väärtuse Helm abil on võimalik määratleda erinevusi klastrite vahel. Kõikide meie graafikute jaoks on minimaalsed vaikimisi väärtused.

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

Globaalsed väärtused

Need väärtused aitavad määratleda meie rakenduste konteksti ja neid kasutatakse erinevate ülesannete jaoks: jälgimine, jälitus, logimine, väliste kutsungite tegemine, skaleerimine jne.

«cloud»: meil on hübri Kubernetes platvorm. Näiteks meie API paigaldatakse GCP piirkondadesse ja meie andmekeskustesse.
«env»: mõned väärtused võivad muutuda mitte-toimivates keskkondades. Näiteks ressursi määratlused ja automaatse skaleerimise konfiguratsioon.
«region»: see teave aitab määrata klastrite asukohta ja võib olla kasulik lähimate lõpp-punktide määramisel välistest teenustest.
«clusterName»: kui ja millal me soovime määrata väärtuse konkreetse klastrile.

Siin on konkreetne näide:

{{/* Tagastab horisontaalse podi automaat skaalastamise replikad GraphQL jaoks */}}
{{- 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 segada Kubernetes YAML faili.

Rakenduse kuulutamine

Meie paigaldustööriistad põhinevad mitmetel YAML failidel. Allpool on näide, kuidas me kuulutame teenuse ja selle skaleerimise topoloogia (replikate arv) klastris.

väljalaset:
  - foo.world

foo.world:                # Väljalase nimi
  teenused:               # Dailymotioni rakenduste/projektide nimekiri
    foobar:
      chart_name: foo-foobar
      repo: git@github.com:dailymotion/foobar
      kontekstid:
        prod-europe-west1:
          juurutamised:
            - nimi: foo-bar-baz
              koopiad: 18
            - nimi: another-deployment
              koopiad: 3

Teenuse määratlemine

See on skeem kõigist sammudest, mis määratlevad meie juurutamisprotsessi. Viimane samm juurutab rakenduse korraga mitmes tööklastris.

Jenkins'i juurutamise sammud

Aga saladused?

Mis puudutab turvalisust, siis jälgime kõiki saladusi erinevates kohtades ja hoiame neid unikaalses salvestuses Vault Pariis.

Meie juurutamisriistad võtavad saladuste väärtused Vaultist ja kui on juurutamise aeg, sisestavad need Helm'i.

Selle jaoks oleme määratlenud vastenduse Vaultis olevate saladuste ja meie rakendustes vajalike saladuste vahel:

saladused:                                                                                                                                                                                                        
     - secret_id: "stack1-app1-password"                                                                                                                                                                                  
       kontekstid:                                                                                                                                                                                                   
         - nimi: "vaikimisi"                                                                                                                                                                                         
           vaultPath: "/kv/dev/stack1/app1/test"                                                                                                                                                               
           vaultKey: "salasõna"                                                                                                                                                                                    
         - nimi: "cluster1"                                                                                                                                                                           
           vaultPath: "/kv/dev/stack1/app1/test"                                                                                                                                                               
           vaultKey: "salasõna"

Oleme määratlenud üldised reeglid, mida tuleb järgida saladuste salvestamisel Vaulti.
Kui saladus kuulub teatud konteksti või klastri juurde, tuleb lisada konkreetne kirje. (Siin kontekstis cluster1 on stack-app1-password-i saladusel oma tähendus).
Muudel juhtudel kasutatakse väärtust vaikimisi.
Iga punkti jaoks selles loendis Kubernetes'i saladuses sisestatakse võtme-väärtuse paar. Seetõttu on meie chartide saladuse mall 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 hoidla jaoks

Praegu eristame chartide ja rakenduste arendamist. See tähendab, et arendajad peavad töötama kahes git-hoidlas: üks rakenduse jaoks ja teine selle Kubernetes'i juurutamise määratlemiseks. 2 git-hoidlat tähendab 2 tööprotsessi ja uue inimese on lihtne segadusse ajada.

Üldiste chartide haldamine on tülikas

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

Jätkuva tarneprotsessis on meil vaid kaks väärtust, mis pidevalt muutuvad: koopiate arv ja pildimärgis (versioon). Teised, stabiilsemad väärtused, muutuvad käsitsi, mis on üsna keeruline. Veelgi enam, üks viga üldise chart'i juurutamises võib põhjustada tõsiseid tõrkeid, nagu oleme oma kogemustest õppinud.

Mitme konfiguratsioonifaili värskendamine

Kui arendaja lisab uue rakenduse, peab ta muutma mitmeid faile: rakenduse kuulutamine, saladuste loetelu, rakenduse lisamine sõltuvustesse, kui see kuulub üldisse chart'i.

Jenkinsi load on Vaultis liiga laiad

Praegu on meil üks AppRole, mis loeb kõiki saladusi Vaultist.

Tagasipöördumise protsess ei ole automatiseeritud

Tagasipöördumiseks tuleb käivitada käsk mitmes klastris, mis on vigadele avatud. Sooritatav toiming on käsitsi, et tagada õige versioonitunnuse määramine.

Liigume GitOps'i suunas

Meie eesmärk

Soovime tuua chart'i rakenduse reposse, mida see juurutab.

Tööpõhimõte jääb samaks kui arenduses. Näiteks, kui haru saadetakse masteri, käivitub juurutamine automaatselt. Peamine erinevus sellise lähenemise ja praeguse tööprotsessi vahel on see, et kõike hallatakse git'is (rakendus ise ja selle juurutamise viis Kuberneteses).

Eeliseid on mitu:

Palju selgem arendajale. Lihtsam on õppida rakendama muudatusi kohalikus chartis.
Teenuse juurutamise määratlemine saab toimuda seal, kus on kood teenusest.
Üldiste chartide eemaldamise haldamine. Teenusel on oma Helm'i väljaanne. See võimaldab hallata rakenduse elutsüklit (tagasipööramine, uuendamine) kõige väiksemal tasandil, et mitte häirida teisi teenuseid.
Git'i eelised chartide haldamisel: muudatuste tühistamine, auditilogid jne. Kui charti muudatust on vaja tühistada, saab seda teha git'i abiga. Juurutamine käivitub automaatselt.
Saab mõelda arendusprotsessi täiustamisele selliste tööriistadega nagu Skaffold, millega arendajad saavad teste teha muutustes, mis on lähedased tootmisprotsessile.

Kahe-etapiline migratsioon

Meie arendajad on seda töövoogu kasutanud juba 2 aastat, seega vajame maksimaalselt sujuvat migratsiooni. Seetõttu otsustasime lisada vaheetapi teele.
Esimene etapp on lihtne:

Hoidame sarnast struktuuri rakenduste välja tõstmise 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äljalase rakenduse kohta (ilma üldistatud chartideta).
Chartid rakenduse git-repositooriumis.

Rääkisime kõigi arendajatega, seega on migratsiooniprotsess juba alanud. Esimene etapp on endiselt kontrolli all CI platvormi kaudu. Peagi kirjutan veel ühe postituse teise etapi kohta: kuidas me läksime üle GitOps töövoole. Flux. Räägin, kuidas me kõik seadistasime ja milliste raskustega silmitsi seisisime (mitmed ladustamised, saladused jne). Jälgige meie uudiseid.

Siin üritasime kirjeldada meie edusamme rakenduste juurutamise tööprotsessis viimase paari aasta jooksul, mis viis meid mõtetele GitOps lähenemisviisi kohta. Me pole veel eesmärgini jõudnud ja anname tulemuste kohta teada, kuid oleme nüüd veendunud, et tegime õigesti, kui otsustasime kõik lihtsustada ja viia arendajate harjumustele lähemale.

Allikas: habr.com