ProHoster > blog > Utawala > Sambaza programu kwenye vikundi vingi vya Kubernetes ukitumia Helm

Sambaza programu kwenye vikundi vingi vya Kubernetes ukitumia Helm

Jinsi Dailymotion hutumia Kubernetes: Usambazaji wa Maombi

Sisi katika Dailymotion tulianza kutumia Kubernetes katika uzalishaji miaka 3 iliyopita. Lakini kupeleka programu kwenye makundi mengi ni jambo la kufurahisha, kwa hivyo katika miaka michache iliyopita tumekuwa tukijaribu kuboresha zana na utendakazi wetu.

Imeanzia wapi

Hapa tutaangazia jinsi tunavyosambaza programu zetu kwenye makundi mengi ya Kubernetes kote ulimwenguni.

Ili kupeleka vitu vingi vya Kubernetes mara moja, tunatumia Helm, na chati zetu zote zimehifadhiwa kwenye hazina moja ya git. Ili kupeleka rundo kamili la programu kutoka kwa huduma kadhaa, tunatumia kinachojulikana chati ya muhtasari. Kimsingi, hii ni chati inayotangaza utegemezi na hukuruhusu kuanzisha API na huduma zake kwa amri moja.

Pia tuliandika hati ndogo ya Python juu ya Helm kufanya ukaguzi, kuunda chati, kuongeza siri, na kupeleka programu. Kazi hizi zote zinafanywa kwenye jukwaa kuu la CI kwa kutumia picha ya docker.

Hebu tufikie hoja.

Kumbuka. Unaposoma haya, mgombeaji wa kwanza wa kutolewa kwa Helm 3 tayari ametangazwa. Toleo kuu lina maboresho mengi ili kushughulikia baadhi ya masuala ambayo tumekumbana nayo hapo awali.

Mtiririko wa kazi wa ukuzaji wa chati

Tunatumia matawi kwa programu, na tuliamua kutumia mbinu sawa kwa chati.

  • Tawi dev kutumika kuunda chati ambazo zitajaribiwa kwenye vikundi vya ukuzaji.
  • Wakati ombi la kuvuta linawasilishwa kwa bwana, wao ni checked katika staging.
  • Mwishowe, tunaunda ombi la kuvuta kufanya mabadiliko kwenye tawi Prod na kuyatumia katika uzalishaji.

Kila mazingira yana hazina yake ya kibinafsi ambayo huhifadhi chati zetu, na sisi hutumia Chartmuseum na API muhimu sana. Kwa njia hii tunahakikisha kutengwa kabisa kati ya mazingira na majaribio ya ulimwengu halisi ya chati kabla ya kuzitumia katika toleo la umma.

Hifadhi za chati katika mazingira tofauti

Inafaa kukumbuka kuwa wakati wasanidi programu wanasukuma tawi la dev, toleo la chati yao husukumwa kiotomatiki hadi kwenye dev Chartmuseum. Kwa hivyo, watengenezaji wote hutumia hazina sawa ya dev, na unahitaji kubainisha kwa makini toleo lako la chati ili usitumie kimakosa mabadiliko ya mtu mwingine.

Kwa kuongezea, hati yetu ndogo ya Python inadhibitisha vitu vya Kubernetes dhidi ya maelezo ya Kubernetes OpenAPI kwa kutumia Kubeval, kabla ya kuzichapisha kwenye Chartmusem.

Maelezo ya jumla ya mtiririko wa kazi ya ukuzaji chati

  1. Kuweka kazi za bomba kulingana na vipimo gazr.io kwa udhibiti wa ubora (kitambaa, mtihani wa kitengo).
  2. Kusukuma picha ya docker na zana za Python ambazo hupeleka programu zetu.
  3. Kuweka mazingira kwa jina la tawi.
  4. Kuthibitisha faili za yaml za Kubernetes kwa kutumia Kubeval.
  5. Ongeza kiotomatiki toleo la chati na chati zake kuu (chati zinazotegemea chati kubadilishwa).
  6. Kuwasilisha chati kwa Chartmuseum inayolingana na mazingira yake

Kudhibiti tofauti katika makundi

Shirikisho la Vikundi

Kuna wakati tulitumia shirikisho la vikundi vya Kubernetes, ambapo vitu vya Kubernetes vinaweza kutangazwa kutoka kwa mwisho wa API. Lakini matatizo yalitokea. Kwa mfano, baadhi ya vitu vya Kubernetes havikuweza kuundwa katika mwisho wa shirikisho, na hivyo kufanya iwe vigumu kudumisha vitu vilivyoshirikishwa na vitu vingine kwa makundi binafsi.

Ili kutatua tatizo, tulianza kusimamia makundi kwa kujitegemea, ambayo imerahisisha sana mchakato (tulitumia toleo la kwanza la shirikisho; kitu kinaweza kubadilika kwa pili).

Jukwaa linalosambazwa kijiografia

Mfumo wetu kwa sasa unasambazwa katika mikoa 6 - 3 ndani ya nchi na 3 katika wingu.


Usambazaji Uliosambazwa

thamani ya Global Helm

Maadili 4 ya Helm ya kimataifa hukuruhusu kutambua tofauti kati ya nguzo. Chati zetu zote zina viwango vya chini kabisa chaguomsingi.

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

Maadili ya kimataifa

Maadili haya husaidia kufafanua muktadha wa programu zetu na hutumika kwa madhumuni mbalimbali: ufuatiliaji, ufuatiliaji, ukataji miti, kupiga simu za nje, kuongeza ukubwa, n.k.

  • "cloud": Tuna jukwaa la mseto la Kubernetes. Kwa mfano, API yetu inatumwa katika maeneo ya GCP na katika vituo vyetu vya data.
  • "env": Baadhi ya maadili yanaweza kubadilika kwa mazingira yasiyo ya uzalishaji. Kwa mfano, ufafanuzi wa rasilimali na usanidi wa kuongeza otomatiki.
  • "eneo": Maelezo haya husaidia kubainisha eneo la nguzo na inaweza kutumika kubainisha miisho ya karibu ya huduma za nje.
  • "clusterName": ikiwa na wakati tunataka kufafanua thamani ya nguzo mahususi.

Hapa kuna mfano maalum:

{{/* 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 -}}

Mfano wa template ya helm

Mantiki hii imefafanuliwa katika kiolezo cha usaidizi ili kuepuka msongamano wa Kubernetes YAML.

Tangazo la Maombi

Zana zetu za kusambaza zinatokana na faili nyingi za YAML. Ufuatao ni mfano wa jinsi tunavyotangaza huduma na topolojia yake ya kuongeza alama (idadi ya nakala) katika kundi.

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

Ufafanuzi wa Huduma

Huu ni muhtasari wa hatua zote zinazofafanua mtiririko wetu wa kazi ya upelekaji. Hatua ya mwisho inapeleka programu kwa vikundi vingi vya wafanyikazi kwa wakati mmoja.


Hatua za Usambazaji wa Jenkins

Vipi kuhusu siri?

Kuhusu usalama, tunafuatilia siri zote kutoka sehemu tofauti na kuzihifadhi kwenye chumba cha kipekee Vault mjini Paris.

Zana zetu za kusambaza hutoa thamani za siri kutoka kwa Vault na, wakati wa kupeleka ufikapo, ziweke kwenye Helm.

Ili kufanya hivyo, tulifafanua ramani kati ya siri katika Vault na siri ambazo programu zetu zinahitaji:

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"

  • Tumefafanua sheria za jumla za kufuata wakati wa kurekodi siri katika Vault.
  • Ikiwa siri inatumika kwa muktadha au nguzo maalum, unahitaji kuongeza ingizo maalum. (Hapa nguzo1 ya muktadha ina thamani yake ya siri ya stack-app1-password).
  • Vinginevyo, thamani hutumiwa kwa msingi.
  • Kwa kila kipengee kwenye orodha hii Kubernetes siri jozi ya thamani-msingi imeingizwa. Kwa hiyo, template ya siri katika chati zetu ni rahisi sana.

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

Matatizo na mapungufu

Kufanya kazi na hazina nyingi

Sasa tunatenganisha maendeleo ya chati na maombi. Hii ina maana kwamba watengenezaji wanapaswa kufanya kazi katika hazina mbili za git: moja kwa ajili ya programu, na moja kwa ajili ya kufafanua kupelekwa kwake kwa Kubernetes. Hazina 2 za git zinamaanisha mtiririko 2 wa kazi, na ni rahisi kwa mgeni kuchanganyikiwa.

Kusimamia chati za jumla ni shida

Kama tulivyokwisha sema, chati za jumla ni muhimu sana kwa kutambua utegemezi na kupeleka kwa haraka programu nyingi. Lakini tunatumia --reuse-valuesili kuepuka kupitisha thamani zote kila wakati tunapotuma programu ambayo ni sehemu ya chati hii ya jumla.

Katika mtiririko wa kazi unaoendelea wa uwasilishaji, tuna thamani mbili pekee zinazobadilika mara kwa mara: idadi ya nakala na lebo ya picha (toleo). Nyingine, maadili thabiti zaidi hubadilishwa kwa mikono, na hii ni ngumu sana. Zaidi ya hayo, kosa moja katika kupeleka chati ya jumla inaweza kusababisha kushindwa kubwa, kama tulivyoona kutokana na uzoefu wetu wenyewe.

Inasasisha faili nyingi za usanidi

Msanidi programu anapoongeza programu mpya, lazima abadilishe faili kadhaa: tamko la programu, orodha ya siri, na kuongeza programu kama tegemezi ikiwa imejumuishwa kwenye chati ya jumla.

Ruhusa za Jenkins zimepanuliwa sana katika Vault

Sasa tuna moja AppRole, ambayo inasoma siri zote kutoka kwa Vault.

Mchakato wa kurejesha sio otomatiki

Ili kurudi nyuma, unahitaji kuendesha amri kwenye makundi kadhaa, na hii imejaa makosa. Tunafanya operesheni hii kwa mikono ili kuhakikisha kuwa kitambulisho sahihi cha toleo kimebainishwa.

Tunasonga kuelekea GitOps

Lengo letu

Tunataka kurudisha chati kwenye hifadhi ya programu inayotumia.

Mtiririko wa kazi utakuwa sawa na wa maendeleo. Kwa mfano, tawi linaposukumwa kuwa bwana, uwekaji utaanzishwa kiotomatiki. Tofauti kuu kati ya mbinu hii na mtiririko wa kazi wa sasa itakuwa hiyo kila kitu kitasimamiwa katika git (programu yenyewe na jinsi inavyotumwa katika Kubernetes).

Kuna faida kadhaa:

  • Mengi wazi zaidi kwa msanidi programu. Ni rahisi kujifunza jinsi ya kutekeleza mabadiliko katika chati ya ndani.
  • Ufafanuzi wa kusambaza huduma unaweza kubainishwa mahali sawa na kanuni huduma.
  • Kusimamia uondoaji wa chati za jumla. Huduma itakuwa na toleo lake la Helm. Hii itakuruhusu kudhibiti mzunguko wa maisha ya programu (kurudisha nyuma, kusasisha) kwa kiwango kidogo, ili usiathiri huduma zingine.
  • Faida za git kwa usimamizi wa chati: tengua mabadiliko, logi ya ukaguzi, n.k. Ikiwa unahitaji kutendua mabadiliko kwenye chati, unaweza kufanya hivi kwa kutumia git. Usambazaji huanza moja kwa moja.
  • Unaweza kufikiria kuboresha utendakazi wako wa ukuzaji kwa kutumia zana kama vile Skafu, ambayo wasanidi programu wanaweza kujaribu mabadiliko katika muktadha ulio karibu na toleo la umma.

Uhamiaji wa hatua mbili

Wasanidi wetu wamekuwa wakitumia utendakazi huu kwa miaka 2 sasa, kwa hivyo tunataka uhamishaji usiwe na maumivu iwezekanavyo. Kwa hiyo, tuliamua kuongeza hatua ya kati kwenye njia ya kufikia lengo.
Hatua ya kwanza ni rahisi:

  • Tunaweka muundo sawa wa kusanidi utumaji programu, lakini katika kitu kimoja kinachoitwa 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"

  • Toleo 1 kwa kila programu (bila chati za jumla).
  • Chati kwenye hazina ya git ya programu.

Tumezungumza na wasanidi wote, kwa hivyo mchakato wa uhamiaji tayari umeanza. Hatua ya kwanza bado inadhibitiwa kwa kutumia jukwaa la CI. Nitaandika chapisho lingine hivi karibuni kuhusu awamu ya pili: jinsi tulivyohamia kwenye mtiririko wa kazi wa GitOps Flux. Nitakuambia jinsi tulivyoweka kila kitu na shida gani tulizokutana nazo (hifadhi nyingi, siri, nk). Fuatilia habari.

Hapa tumejaribu kuelezea maendeleo yetu katika utendakazi wa uwekaji maombi katika miaka iliyopita, ambayo ilisababisha mawazo kuhusu mbinu ya GitOps. Bado hatujafikia lengo na tutaripoti juu ya matokeo, lakini sasa tuna hakika kwamba tulifanya jambo sahihi wakati tuliamua kurahisisha kila kitu na kuleta karibu na tabia za watengenezaji.

Chanzo: mapenzi.com

Kuongeza maoni