ProHoster > Blog > administratë > Vendosni aplikacione nëpër grupe të shumta Kubernetes me Helm

Vendosni aplikacione nëpër grupe të shumta Kubernetes me Helm

Si përdor Dailymotion Kubernetes: Vendosja e aplikacionit

Ne në Dailymotion filluam të përdorim Kubernetes në prodhim 3 vjet më parë. Por vendosja e aplikacioneve nëpër grupe të shumta është argëtuese, kështu që gjatë viteve të fundit ne jemi përpjekur të përmirësojmë mjetet dhe rrjedhat tona të punës.

Ku filloi

Këtu do të mbulojmë se si i vendosim aplikacionet tona nëpër grupe të shumta Kubernetes në mbarë botën.

Për të vendosur objekte të shumta Kubernetes në të njëjtën kohë, ne përdorim kaskë, dhe të gjitha grafikët tanë ruhen në një depo git. Për të vendosur një grumbull të plotë aplikacionesh nga disa shërbime, ne përdorim të ashtuquajturin grafikun përmbledhës. Në thelb, ky është një grafik që deklaron varësi dhe ju lejon të inicializoni API-në dhe shërbimet e tij me një komandë.

Ne gjithashtu shkruam një skript të vogël Python në krye të Helm për të bërë kontrolle, për të krijuar grafikët, për të shtuar sekrete dhe për të vendosur aplikacione. Të gjitha këto detyra kryhen në një platformë qendrore CI duke përdorur një imazh docker.

Le të shkojmë te pika.

Shënim. Ndërsa e lexoni këtë, kandidati i parë i lëshimit për Helm 3 tashmë është shpallur. Versioni kryesor përmban një mori përmirësimesh për të adresuar disa nga problemet që kemi hasur në të kaluarën.

Rrjedha e punës për zhvillimin e grafikut

Ne përdorim degëzimin për aplikacione dhe vendosëm të aplikojmë të njëjtën qasje për grafikët.

  • Dega dev përdoret për të krijuar grafikët që do të testohen në grupimet e zhvillimit.
  • Kur një kërkesë për tërheqje paraqitet në mjeshtër, kontrollohen në skenë.
  • Së fundi, ne krijojmë një kërkesë tërheqëse për të kryer ndryshimet në degë stimuloj dhe t'i zbatojnë ato në prodhim.

Çdo mjedis ka depon e tij private që ruan grafikët tanë dhe ne i përdorim Chartmuseum me API shumë të dobishme. Në këtë mënyrë ne sigurojmë izolim të rreptë midis mjediseve dhe testim në botën reale të grafikëve përpara përdorimit të tyre në prodhim.

Depot e grafikëve në mjedise të ndryshme

Vlen të përmendet se kur zhvilluesit shtyjnë një degë të devijimit, një version i grafikut të tyre shtyhet automatikisht në Devi Chartmuseum. Kështu, të gjithë zhvilluesit përdorin të njëjtën depo të devijimit, dhe ju duhet të specifikoni me kujdes versionin tuaj të grafikut në mënyrë që të mos përdorni aksidentalisht ndryshimet e dikujt tjetër.

Për më tepër, skripti ynë i vogël Python vërteton objektet Kubernetes kundrejt specifikimeve Kubernetes OpenAPI duke përdorur Kubeval, përpara se t'i publikonte në Chartmusem.

Përshkrimi i përgjithshëm i rrjedhës së punës për zhvillimin e grafikut

  1. Vendosja e detyrave të tubacionit sipas specifikimeve gazr.io për kontrollin e cilësisë (lint, unit-test).
  2. Shtyrja e një imazhi doker me mjetet e Python që vendosin aplikacionet tona.
  3. Vendosja e mjedisit sipas emrit të degës.
  4. Verifikimi i skedarëve Kubernetes yaml duke përdorur Kubeval.
  5. Rrit automatikisht versionin e një grafiku dhe grafikët e tij mëmë (grafikë që varen nga ndryshimi i grafikut).
  6. Dorëzimi i një grafiku në një Chartmuseum që përputhet me mjedisin e tij

Menaxhimi i dallimeve në grupe

Federata e Klasterave

Kishte një kohë kur përdornim federata e grupimeve të Kubernetes, ku objektet Kubernetes mund të deklarohen nga një pikë fundore e vetme API. Por u shfaqën probleme. Për shembull, disa objekte Kubernetes nuk mund të krijoheshin në pikën përfundimtare të federatës, duke e bërë të vështirë ruajtjen e objekteve të federuara dhe objekteve të tjera për grupime individuale.

Për të zgjidhur problemin, filluam të menaxhonim grupet në mënyrë të pavarur, gjë që e thjeshtoi shumë procesin (përdorëm versionin e parë të federatës; diçka mund të kishte ndryshuar në të dytin).

Platforma gjeo-shpërndarë

Platforma jonë aktualisht shpërndahet në 6 rajone - 3 në nivel lokal dhe 3 në re.


Vendosja e shpërndarë

Vlerat Global Helm

4 vlerat globale të Helm-it ju lejojnë të identifikoni ndryshimet midis grupimeve. Të gjitha grafikët tanë kanë vlera minimale të paracaktuara.

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

Vlerat globale

Këto vlera ndihmojnë në përcaktimin e kontekstit për aplikacionet tona dhe përdoren për qëllime të ndryshme: monitorim, gjurmim, regjistrim, kryerje thirrjesh të jashtme, shkallëzim, etj.

  • "cloud": Ne kemi një platformë hibride Kubernetes. Për shembull, API-ja jonë është vendosur në zonat GCP dhe në qendrat tona të të dhënave.
  • "env": Disa vlera mund të ndryshojnë për mjediset joprodhuese. Për shembull, përkufizimet e burimeve dhe konfigurimet e shkallëzimit automatik.
  • "rajon": Ky informacion ndihmon në përcaktimin e vendndodhjes së grupit dhe mund të përdoret për të përcaktuar pikat fundore të afërta për shërbimet e jashtme.
  • "ClusterName": nëse dhe kur duam të përcaktojmë një vlerë për një grup individual.

Këtu është një shembull specifik:

{{/* Returns Horizontal Pod Autoscaler replicas for GraphQL*/}}
{{- 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 -}}

Shembull i shabllonit të timonit

Kjo logjikë përcaktohet në një shabllon ndihmës për të shmangur rrëmujën e Kubernetes YAML.

Njoftimi i Aplikimit

Mjetet tona të vendosjes bazohen në skedarë të shumtë YAML. Më poshtë është një shembull se si ne deklarojmë një shërbim dhe topologjinë e tij të shkallëzimit (numri i kopjeve) në një grup.

releases:
  - foo.world

foo.world:                # Release name
  services:               # List of dailymotion's apps/projects
    foobar:
      chart_name: foo-foobar
      repo: [email protected]:dailymotion/foobar
      contexts:
        prod-europe-west1:
          deployments:
            - name: foo-bar-baz
              replicas: 18
            - name: another-deployment
              replicas: 3

Përkufizimi i shërbimit

Ky është një përmbledhje e të gjithë hapave që përcaktojnë rrjedhën tonë të punës së vendosjes. Hapi i fundit vendos aplikacionin në grupe të shumta punëtorësh njëkohësisht.


Hapat e vendosjes së Jenkins

Po sekretet?

Për sa i përket sigurisë, ne gjurmojmë të gjitha sekretet nga vende të ndryshme dhe i ruajmë në një kasafortë unike Kasafortë Në Paris.

Mjetet tona të vendosjes nxjerrin vlera sekrete nga Vault dhe, kur të vijë koha e vendosjes, futini ato në Helm.

Për ta bërë këtë, ne përcaktuam një hartë midis sekreteve në Vault dhe sekreteve që u duhen aplikacioneve tona:

secrets:                                                                                                                                                                                                        
     - 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"

  • Ne kemi përcaktuar rregulla të përgjithshme që duhen ndjekur gjatë regjistrimit të sekreteve në Vault.
  • Nëse sekreti zbatohet në një kontekst ose grup specifik, duhet të shtoni një hyrje specifike. (Këtu grupi i kontekstit1 ka vlerën e vet për fjalëkalimin sekret stack-app1).
  • Përndryshe, vlera përdoret nga parazgjedhja.
  • Për çdo artikull në këtë listë në Sekreti i Kubernetes futet një çift çelës-vlerë. Prandaj, shablloni sekret në grafikët tanë është shumë i thjeshtë.

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

Problemet dhe kufizimet

Puna me depo të shumta

Tani ne veçojmë zhvillimin e grafikëve dhe aplikacioneve. Kjo do të thotë që zhvilluesit duhet të punojnë në dy depo git: një për aplikacionin dhe një për përcaktimin e vendosjes së tij në Kubernetes. 2 depo git nënkuptojnë 2 rrjedha pune dhe është e lehtë për një fillestar të ngatërrohet.

Menaxhimi i grafikëve të përgjithësuar është një sherr

Siç kemi thënë tashmë, grafikët gjenerikë janë shumë të dobishëm për identifikimin e varësive dhe vendosjen e shpejtë të aplikacioneve të shumta. Por ne përdorim --reuse-valuespër të shmangur kalimin e të gjitha vlerave sa herë që vendosim një aplikacion që është pjesë e këtij grafiku të përgjithësuar.

Në një rrjedhë pune të shpërndarjes së vazhdueshme, ne kemi vetëm dy vlera që ndryshojnë rregullisht: numrin e kopjeve dhe etiketën e imazhit (versionin). Vlerat e tjera, më të qëndrueshme ndryshohen me dorë, dhe kjo është mjaft e vështirë. Për më tepër, një gabim në vendosjen e një grafiku të përgjithësuar mund të çojë në dështime serioze, siç e kemi parë nga përvoja jonë.

Përditësimi i skedarëve të shumtë të konfigurimit

Kur një zhvillues shton një aplikacion të ri, ai duhet të ndryshojë disa skedarë: deklaratën e aplikacionit, listën e sekreteve, duke shtuar aplikacionin si varësi nëse përfshihet në grafikun e përgjithësuar.

Lejet e Jenkins janë shumë të zgjeruara në Vault

Tani kemi një AppRole, e cila lexon të gjitha sekretet nga Vault.

Procesi i rikthimit nuk është i automatizuar

Për t'u rikthyer, duhet të ekzekutoni komandën në disa grupe, dhe kjo është e mbushur me gabime. Ne e kryejmë këtë operacion manualisht për të siguruar që është specifikuar ID-ja e saktë e versionit.

Po shkojmë drejt GitOps

Qellimi jone

Ne duam ta kthejmë grafikun në depon e aplikacionit që ai vendos.

Rrjedha e punës do të jetë e njëjtë si për zhvillimin. Për shembull, kur një degë shtyhet për të zotëruar, vendosja do të aktivizohet automatikisht. Dallimi kryesor midis kësaj qasjeje dhe rrjedhës aktuale të punës do të ishte ai gjithçka do të menaxhohet në git (vetë aplikacioni dhe mënyra se si vendoset në Kubernetes).

Ka disa avantazhe:

  • Shumë më të qartë për zhvilluesin. Është më e lehtë të mësosh se si të zbatosh ndryshimet në një grafik lokal.
  • Përkufizimi i vendosjes së shërbimit mund të specifikohet të njëjtin vend me kodin shërbimi.
  • Menaxhimi i heqjes së grafikëve të përgjithësuar. Shërbimi do të ketë lëshimin e vet të Helm-it. Kjo do t'ju lejojë të menaxhoni ciklin e jetës së aplikacionit (rikthyer, azhurnim) në nivelin më të vogël, në mënyrë që të mos prekni shërbimet e tjera.
  • Përfitimet e git për menaxhimin e grafikut: anuloni ndryshimet, regjistrin e auditimit, etj. Nëse keni nevojë të zhbëni një ndryshim në një grafik, mund ta bëni këtë duke përdorur git. Vendosja fillon automatikisht.
  • Ju mund të konsideroni përmirësimin e rrjedhës së punës tuaj të zhvillimit me mjete si Skeli, me të cilin zhvilluesit mund të testojnë ndryshimet në një kontekst afër prodhimit.

Migrimi me dy hapa

Zhvilluesit tanë e përdorin këtë rrjedhë pune për 2 vjet tani, kështu që ne duam që migrimi të jetë sa më pa dhimbje. Prandaj, vendosëm të shtojmë një hap të ndërmjetëm në rrugën drejt qëllimit.
Faza e parë është e thjeshtë:

  • Ne mbajmë një strukturë të ngjashme për vendosjen e vendosjes së aplikacionit, por në një objekt të vetëm të quajtur 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 version për aplikim (pa grafikët e përgjithësuar).
  • Grafikët në depon e git të aplikacionit.

Ne kemi biseduar me të gjithë zhvilluesit, kështu që procesi i migrimit ka filluar tashmë. Faza e parë ende kontrollohet duke përdorur platformën CI. Së shpejti do të shkruaj një postim tjetër rreth fazës së dytë: si kaluam në një rrjedhë pune me GitOps Gradient. Unë do t'ju tregoj se si kemi vendosur gjithçka dhe çfarë vështirësish kemi hasur (depo të shumta, sekrete, etj.). Ndiqni lajmet.

Këtu jemi përpjekur të përshkruajmë përparimin tonë në rrjedhën e punës së vendosjes së aplikacioneve gjatë viteve të fundit, gjë që çoi në mendime rreth qasjes GitOps. Ne ende nuk e kemi arritur qëllimin dhe do të raportojmë për rezultatet, por tani jemi të bindur se bëmë gjënë e duhur kur vendosëm të thjeshtojmë gjithçka dhe ta afrojmë atë me zakonet e zhvilluesve.

Burimi: www.habr.com

Shto një koment