ProHoster > Blogi > antaminen > Ota sovelluksia käyttöön useissa Kubernetes-klustereissa Helmin avulla

Ota sovelluksia käyttöön useissa Kubernetes-klustereissa Helmin avulla

Kuinka Dailymotion käyttää Kubernetesia: Sovelluksen käyttöönotto

Me Dailymotionilla aloitimme Kubernetesin käytön tuotannossa 3 vuotta sitten. Mutta sovellusten käyttöönotto useissa klusteissa on hauskaa, joten viime vuosina olemme yrittäneet parantaa työkalujamme ja työnkulkujamme.

Mistä se alkoi

Tässä kerromme, kuinka otamme käyttöön sovelluksiamme useissa Kubernetes-klustereissa ympäri maailmaa.

Useiden Kubernetes-objektien käyttöönottamiseksi kerralla käytämme Ruori, ja kaikki kaaviomme on tallennettu yhteen git-tietovarastoon. Täyden sovelluspinon käyttöönottamiseksi useista palveluista käytämme ns. yhteenvetokaaviota. Pohjimmiltaan tämä on kaavio, joka ilmoittaa riippuvuudet ja antaa sinun alustaa API ja sen palvelut yhdellä komennolla.

Kirjoitimme myös pienen Python-skriptin Helmin päälle, jotta voimme tehdä tarkistuksia, luoda kaavioita, lisätä salaisuuksia ja ottaa sovelluksia käyttöön. Kaikki nämä tehtävät suoritetaan keskitetyllä CI-alustalla käyttämällä telakointikuvaa.

Mennään asiaan.

Huomautus. Kun luet tätä, Helm 3:n ensimmäinen julkaisuehdokas on jo julkistettu. Pääversio sisältää joukon parannuksia joidenkin aiemmin kohtaamiemme ongelmien ratkaisemiseksi.

Kaavion kehittämistyönkulku

Käytämme haaroitusta sovelluksissa, ja päätimme soveltaa samaa lähestymistapaa kaavioihin.

  • Haara dev käytetään luomaan kaavioita, joita testataan kehitysklustereissa.
  • Kun vetopyyntö lähetetään mestari, ne tarkistetaan vaiheittain.
  • Lopuksi luomme vetopyynnön muutosten sitomiseksi haaraan tuot ja soveltaa niitä tuotannossa.

Jokaisella ympäristöllä on oma yksityinen arkisto, joka tallentaa kaaviomme ja jota käytämme Karttamuseo erittäin hyödyllisillä API:illa. Näin varmistamme tiukan eristyksen ympäristöjen välillä ja kaavioiden todellisen testauksen ennen niiden käyttöä tuotannossa.

Karttavarastot eri ympäristöissä

On syytä huomata, että kun kehittäjät työntävät kehityshaaran, heidän kaavionsa versio työnnetään automaattisesti dev Chartmuseumiin. Näin ollen kaikki kehittäjät käyttävät samaa kehittäjävarastoa, ja sinun on määritettävä huolellisesti kaavioversiosi, jotta et käytä vahingossa jonkun muun tekemiä muutoksia.

Lisäksi pieni Python-skriptimme vahvistaa Kubernetes-objektit Kubernetes OpenAPI-määrityksiä vastaan ​​käyttämällä Kubeval, ennen kuin ne julkaistaan ​​Chartmusemissa.

Yleinen kuvaus kaavion kehittämistyönkulusta

  1. Liukuputkitehtävien asettaminen spesifikaatioiden mukaan gazr.io laadunvalvontaa varten (nukka, yksikkötesti).
  2. Docker-kuvan työntäminen Python-työkaluilla, jotka ottavat käyttöön sovelluksiamme.
  3. Ympäristön asettaminen haaran nimen mukaan.
  4. Kubernetes yaml -tiedostojen validointi Kubevalilla.
  5. Lisää automaattisesti kaavion ja sen ylätason kaavioiden versiota (kaavioita, jotka riippuvat muutettavasta kaaviosta).
  6. Kartan lähettäminen ympäristöönsä sopivaan Chartmuseumiin

Klusterien välisten erojen hallinta

Klusterien liitto

Oli aika, jolloin käytimme Kubernetes-klusterien liitto, jossa Kubernetes-objektit voidaan ilmoittaa yhdestä API-päätepisteestä. Mutta ongelmia ilmaantui. Esimerkiksi joitain Kubernetes-objekteja ei voitu luoda yhdistämisen päätepisteessä, mikä vaikeuttaa hajautettujen objektien ja muiden objektien ylläpitoa yksittäisille klusteille.

Ongelman ratkaisemiseksi aloimme hallita klustereita itsenäisesti, mikä yksinkertaisti prosessia huomattavasti (käytimme liittoutuman ensimmäistä versiota; toisessa saattoi jotain muuttua).

Maantieteellisesti hajautettu alusta

Alustamme on tällä hetkellä jaettu kuudelle alueelle – 6 paikallisesti ja 3 pilvessä.


Hajautettu käyttöönotto

Globaalit Helmin arvot

Neljän globaalin Helm-arvon avulla voit tunnistaa klusterien väliset erot. Kaikilla kaavioillamme on oletusminimiarvot.

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

Globaalit arvot

Nämä arvot auttavat määrittelemään kontekstin sovelluksillemme, ja niitä käytetään eri tarkoituksiin: valvontaan, jäljitykseen, lokiin, ulkopuheluihin, skaalaukseen jne.

  • "pilvi": Meillä on hybridi Kubernetes-alusta. Esimerkiksi APImme on käytössä GCP-vyöhykkeillä ja palvelinkeskuksissamme.
  • "env": Jotkut arvot voivat muuttua muissa kuin tuotantoympäristöissä. Esimerkiksi resurssien määritykset ja automaattisen skaalauksen määritykset.
  • "alue": Nämä tiedot auttavat määrittämään klusterin sijainnin, ja niitä voidaan käyttää ulkoisten palveluiden lähellä olevien päätepisteiden määrittämiseen.
  • "clusterName": jos ja milloin haluamme määrittää arvon yksittäiselle klusterille.

Tässä on konkreettinen esimerkki:

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

Esimerkki ruorin mallista

Tämä logiikka on määritelty apumallissa Kubernetes YAML:n sotkeutumisen välttämiseksi.

Hakemusilmoitus

Käyttöönottotyökalumme perustuvat useisiin YAML-tiedostoihin. Alla on esimerkki siitä, kuinka ilmoitamme palvelun ja sen skaalaustopologian (kopioiden lukumäärän) klusterissa.

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

Palvelun määritelmä

Tämä on yleiskatsaus kaikista vaiheista, jotka määrittävät käyttöönoton työnkulkumme. Viimeinen vaihe ottaa sovelluksen käyttöön useissa työntekijäklustereissa samanaikaisesti.


Jenkinsin käyttöönottovaiheet

Entä salaisuudet?

Turvallisuuden osalta seuraamme kaikkia salaisuuksia eri paikoista ja tallennamme ne ainutlaatuiseen holviin Holvi Pariisissa.

Käyttöönottotyökalumme poimivat salaiset arvot Holvista ja lisäävät ne Helmiin, kun käyttöönotto aika koittaa.

Tätä varten määritimme kartoituksen Holvin salaisuuksien ja sovelluksiemme tarvitsemien salaisuuksien välille:

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"

  • Olemme määrittäneet yleiset säännöt, joita on noudatettava tallentaessasi salaisuuksia Holviin.
  • Jos salaisuus pätee tiettyyn kontekstiin tai klusteriin, sinun on lisättävä tietty merkintä. (Tässä kontekstiklusterilla1 on oma arvonsa salaiselle pino-sovellus1-salasanalle).
  • Muussa tapauksessa arvoa käytetään oletuksena.
  • Jokaiselle tämän luettelon tuotteelle Kubernetes salaisuus avain-arvo-pari lisätään. Siksi kaavioidemme salainen malli on hyvin yksinkertainen.

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

Ongelmia ja rajoituksia

Työskentely useiden tietovarastojen kanssa

Nyt erotamme kaavioiden ja sovellusten kehittämisen. Tämä tarkoittaa, että kehittäjien on työskenneltävä kahdessa git-varastossa: yksi sovellusta varten ja toinen määrittääkseen sen käyttöönoton Kubernetesissa. 2 git-tietovarastoa tarkoittaa kahta työnkulkua, ja aloittelijan on helppo hämmentää.

Yleisten kaavioiden hallinta on vaivalloista

Kuten jo sanoimme, yleiset kaaviot ovat erittäin hyödyllisiä riippuvuuksien tunnistamisessa ja useiden sovellusten nopeassa käyttöönotossa. Mutta käytämme --reuse-valuesvälttääksemme kaikkien arvojen välittämisen joka kerta, kun otamme käyttöön sovelluksen, joka on osa tätä yleistettyä kaaviota.

Jatkuvassa toimitustyönkulussa meillä on vain kaksi arvoa, jotka muuttuvat säännöllisesti: replikoiden määrä ja kuvatunniste (versio). Muut, vakaammat arvot muutetaan manuaalisesti, ja tämä on melko vaikeaa. Lisäksi yksi virhe yleisen kaavion käyttöönotossa voi johtaa vakaviin epäonnistumisiin, kuten olemme nähneet omasta kokemuksestamme.

Useiden asetustiedostojen päivittäminen

Kun kehittäjä lisää uuden sovelluksen, hänen on muutettava useita tiedostoja: sovellusilmoitus, salaisuusluettelo, sovelluksen lisääminen riippuvuudeksi, jos se sisältyy yleiseen kaavioon.

Jenkinsin käyttöoikeudet on liian laajennettu Holvissa

Nyt meillä on yksi AppRole, joka lukee kaikki holvin salaisuudet.

Palautusprosessi ei ole automatisoitu

Palauttaaksesi sinun on suoritettava komento useissa klusteissa, ja tämä on täynnä virheitä. Suoritamme tämän toiminnon manuaalisesti varmistaaksemme, että oikea versiotunnus on määritetty.

Siirrymme kohti GitOpsia

Meidän maalimme

Haluamme palauttaa kaavion sen käyttöönotetun sovelluksen arkistoon.

Työnkulku on sama kuin kehitystyössä. Esimerkiksi kun haara työnnetään isäntälle, käyttöönotto käynnistyy automaattisesti. Suurin ero tämän lähestymistavan ja nykyisen työnkulun välillä on se kaikkea hallitaan gitissä (itse sovellus ja tapa, jolla se otetaan käyttöön Kubernetesissa).

On olemassa useita etuja:

  • Paljon selkeämpi kehittäjälle. On helpompi oppia ottamaan muutoksia käyttöön paikallisessa kaaviossa.
  • Palvelun käyttöönoton määritelmä voidaan määrittää sama paikka kuin koodi palvelua.
  • Yleisten kaavioiden poistamisen hallinta. Palvelulla on oma Helm -julkaisu. Näin voit hallita sovelluksen elinkaarta (palautus, päivitys) pienimmällä tasolla, jotta se ei vaikuta muihin palveluihin.
  • Gitin edut kaavion hallintaan: kumoa muutokset, tarkastusloki jne. Jos sinun on kumottava kaavioon tehty muutos, voit tehdä tämän gitillä. Käyttöönotto alkaa automaattisesti.
  • Voit harkita kehittämistyönkulun parantamista työkaluilla, kuten Scaffold, jolla kehittäjät voivat testata muutoksia tuotantoa lähellä olevassa kontekstissa.

Kaksivaiheinen siirto

Kehittäjämme ovat käyttäneet tätä työnkulkua nyt 2 vuotta, joten haluamme siirtymisen olevan mahdollisimman kivutonta. Siksi päätimme lisätä väliaskeleen matkalla maaliin.
Ensimmäinen vaihe on yksinkertainen:

  • Säilytämme samanlaisen rakenteen sovellusten käyttöönoton määrittämiseksi, mutta yhdessä objektissa nimeltä 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 julkaisu per sovellus (ilman yleisiä kaavioita).
  • Kaaviot sovelluksen git-arkistossa.

Olemme keskustelleet kaikkien kehittäjien kanssa, joten siirtoprosessi on jo alkanut. Ensimmäistä vaihetta ohjataan edelleen CI-alustalla. Kirjoitan pian toisen postauksen toisesta vaiheesta: kuinka siirryimme GitOps-työnkulkuun Vuo. Kerron sinulle, kuinka asensimme kaiken ja mitä vaikeuksia kohtasimme (useita tietovarastoja, salaisuuksia jne.). Seuraa uutisia.

Tässä olemme yrittäneet kuvata edistymistämme sovellusten käyttöönoton työnkulussa viime vuosien aikana, mikä johti ajatuksiin GitOps-lähestymistavasta. Emme ole vielä saavuttaneet tavoitetta ja raportoimme tuloksista, mutta nyt olemme vakuuttuneita, että teimme oikein, kun päätimme yksinkertaistaa kaikkea ja tuoda sen lähemmäksi kehittäjien tottumuksia.

Lähde: will.com

Lisää kommentti