ProHoster > Π‘Π»ΠΎΠ³ > Administrasi > Nyebarake aplikasi ing pirang-pirang kluster Kubernetes nganggo Helm

Nyebarake aplikasi ing pirang-pirang kluster Kubernetes nganggo Helm

Kepiye Dailymotion nggunakake Kubernetes: Penyebaran Aplikasi

Kita ing Dailymotion wiwit nggunakake Kubernetes ing produksi 3 taun kepungkur. Nanging nyebarake aplikasi ing pirang-pirang kluster pancen nyenengake, mula sajrone sawetara taun kepungkur, kita wis nyoba nambah alat lan alur kerja.

Ngendi iku diwiwiti

Ing kene kita bakal ngrembug babagan cara nyebarake aplikasi ing pirang-pirang kluster Kubernetes ing saindenging jagad.

Kanggo masang sawetara obyek Kubernetes bebarengan, kita nggunakake Helm, lan kabeh grafik kita disimpen ing siji gudang git. Kanggo nyebarake tumpukan aplikasi lengkap saka sawetara layanan, kita nggunakake bagan ringkesan sing diarani. Ateges, iki minangka grafik sing nyatakake dependensi lan ngidini sampeyan miwiti API lan layanan kanthi siji printah.

Kita uga nulis skrip Python cilik ing ndhuwur Helm kanggo mriksa, nggawe grafik, nambah rahasia, lan nyebarake aplikasi. Kabeh tugas iki ditindakake ing platform CI tengah nggunakake gambar docker.

Ayo menyang titik.

Cathetan. Nalika maca iki, calon rilis pisanan kanggo Helm 3 wis diumumake. Versi utama ngemot macem-macem dandan kanggo ngatasi sawetara masalah sing kita alami ing jaman kepungkur.

Alur kerja pangembangan grafik

Kita nggunakake cabang kanggo aplikasi, lan kita mutusake kanggo ngetrapake pendekatan sing padha ing grafik.

  • Cabang dev digunakake kanggo nggawe grafik sing bakal diuji ing klompok pangembangan.
  • Nalika panjalukan narik diajukake kanggo Master, lagi dicenthang ing pementasan.
  • Pungkasan, kita nggawe panjalukan narik kanggo nindakake owah-owahan ing cabang kasebut produk lan aplikasi ing produksi.

Saben lingkungan duwe gudang pribadi dhewe sing nyimpen grafik kita, lan kita gunakake Chartmuseum karo API banget migunani. Kanthi cara iki, kita mesthekake pamisahan sing ketat ing antarane lingkungan lan tes grafik nyata sadurunge digunakake ing produksi.

Repositori grafik ing macem-macem lingkungan

Wigati dicathet yen nalika pangembang nyurung cabang dev, versi grafik kasebut kanthi otomatis didorong menyang Chartmuseum dev. Dadi, kabeh pangembang nggunakake repositori dev sing padha, lan sampeyan kudu kanthi ati-ati nemtokake versi grafik supaya ora sengaja nggunakake owah-owahan wong liya.

Kajaba iku, skrip Python cilik kita validasi obyek Kubernetes nglawan spesifikasi OpenAPI Kubernetes nggunakake Kubeval, sadurunge nerbitake ing Chartmusem.

Gambaran umum alur kerja pangembangan grafik

  1. Nyetel tugas pipa miturut spesifikasi gazr.io kanggo kontrol kualitas (lint, unit-test).
  2. Nyorong gambar docker nganggo alat Python sing nyebarake aplikasi kita.
  3. Nyetel lingkungan kanthi jeneng cabang.
  4. Validasi file yaml Kubernetes nggunakake Kubeval.
  5. Tambah versi grafik lan grafik induk kanthi otomatis (grafik sing gumantung saka grafik sing diganti).
  6. Ngirim grafik menyang Chartmuseum sing cocog karo lingkungane

Ngatur beda antarane klompok

Federasi Kluster

Ana wektu nalika kita digunakake federasi kluster Kubernetes, ing ngendi obyek Kubernetes bisa diumumake saka titik pungkasan API siji. Nanging ana masalah. Contone, sawetara obyek Kubernetes ora bisa digawe ing titik pungkasan federasi, dadi angel kanggo njaga obyek gabungan lan obyek liyane kanggo klompok individu.

Kanggo ngatasi masalah kasebut, kita wiwit ngatur klompok kasebut kanthi mandiri, sing nyederhanakake proses kasebut (kita nggunakake versi pertama federasi; ana sing bisa diganti ing kaloro).

Platform sing disebarake geo

Platform kita saiki disebar ing 6 wilayah - 3 sacara lokal lan 3 ing awan.


Penyebaran sing disebarake

Nilai Helm Global

4 nilai Helm global ngidini sampeyan ngenali beda antarane klompok. Kabeh denah kita duwe nilai minimal standar.

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

Nilai global

Nilai kasebut mbantu nemtokake konteks kanggo aplikasi kita lan digunakake kanggo macem-macem tujuan: ngawasi, nelusuri, logging, nelpon eksternal, skala, lsp.

  • "cloud": Kita duwe platform Kubernetes hibrida. Contone, API kita disebarake ing zona GCP lan ing pusat data kita.
  • "env": Sawetara nilai bisa diganti kanggo lingkungan non-produksi. Contone, definisi sumber daya lan konfigurasi autoscaling.
  • "wilayah": Informasi iki mbantu nemtokake lokasi kluster lan bisa digunakake kanggo nemtokake endpoint sing cedhak kanggo layanan eksternal.
  • "clusterName": yen lan nalika kita arep kanggo nemtokake nilai kanggo klompok individu.

Punika conto tartamtu:

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

Contoh template helm

Logika iki ditetepake ing template helper kanggo ngindhari cluttering Kubernetes YAML.

Pengumuman Lamaran

Piranti panyebaran kita adhedhasar macem-macem file YAML. Ing ngisor iki conto carane kita ngumumake layanan lan topologi skala (jumlah replika) ing kluster.

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

Definisi Layanan

Iki minangka garis garis kabeh langkah sing nemtokake alur kerja penyebaran kita. Langkah pungkasan deploys aplikasi kanggo macem-macem klompok buruh bebarengan.


Langkah-langkah Penyebaran Jenkins

Apa babagan rahasia?

Babagan keamanan, kita nglacak kabeh rahasia saka macem-macem papan lan nyimpen ing lemari sing unik Wikipedia ing Paris.

Piranti panyebaran kita ngekstrak nilai rahasia saka Vault lan, nalika wektu panyebaran teka, lebokake menyang Helm.

Kanggo nindakake iki, kita nemtokake pemetaan antarane rahasia ing Vault lan rahasia sing dibutuhake aplikasi kita:

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"

  • Kita wis nemtokake aturan umum sing kudu ditindakake nalika ngrekam rahasia ing Vault.
  • Yen rahasia ditrapake menyang konteks utawa kluster tartamtu, sampeyan kudu nambah entri tartamtu. (Ing kene konteks cluster1 duwe nilai dhewe kanggo rahasia stack-app1-sandi).
  • Yen ora, nilai digunakake kanthi gawan.
  • Kanggo saben item ing dhaftar iki ing Rahasia Kubernetes pasangan kunci-nilai dilebokake. Mulane, cithakan rahasia ing grafik kita gampang banget.

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

Masalah lan watesan

Nggarap macem-macem repositori

Saiki kita misahake pangembangan grafik lan aplikasi. Iki tegese pangembang kudu kerja ing rong repositori git: siji kanggo aplikasi, lan siji kanggo nemtokake penyebarane menyang Kubernetes. 2 repositori git tegese 2 alur kerja, lan gampang bingung kanggo wong anyar.

Ngatur denah umum minangka repot

Kaya sing wis dakkandhakake, grafik umum migunani banget kanggo ngenali dependensi lan nggunakake macem-macem aplikasi kanthi cepet. Nanging kita nggunakake --reuse-valuessupaya ora ngliwati kabeh nilai saben-saben kita nyebarake aplikasi sing dadi bagean saka grafik umum iki.

Ing alur kerja pangiriman sing terus-terusan, kita mung duwe rong nilai sing diganti kanthi rutin: jumlah replika lan tag gambar (versi). Nilai liyane sing luwih stabil diganti kanthi manual, lan iki cukup angel. Menapa malih, salah satunggaling kesalahan ing deploying grafik umum bisa mimpin kanggo Gagal serius, kita wis katon saka pengalaman kita dhewe.

Nganyari sawetara file konfigurasi

Nalika pangembang nambah aplikasi anyar, dheweke kudu ngganti sawetara file: deklarasi aplikasi, dhaptar rahasia, nambahake aplikasi minangka dependensi yen kalebu ing grafik umum.

Ijin Jenkins ditambahi banget ing Vault

Saiki kita duwe siji AppRole, sing maca kabeh rahasia saka Vault.

Proses rollback ora otomatis

Kanggo rollback, sampeyan kudu mbukak printah ing sawetara klompok, lan iki fraught karo kasalahan. Kita nindakake operasi iki kanthi manual kanggo mesthekake yen ID versi sing bener ditemtokake.

Kita pindhah menyang GitOps

Tujuan kita

Kita pengin mbalekake grafik menyang repositori aplikasi sing disebarake.

Alur kerja bakal padha karo pembangunan. Contone, nalika cabang di-push kanggo master, penyebaran prajurit bakal micu kanthi otomatis. Bentenane utama antarane pendekatan iki lan alur kerja saiki yaiku kabeh bakal diatur ing git (aplikasi dhewe lan cara disebarake ing Kubernetes).

Ana sawetara kaluwihan:

  • akeh luwih cetha kanggo pangembang. Luwih gampang sinau carane ngetrapake owah-owahan ing grafik lokal.
  • DΓ©finisi panyebaran layanan bisa ditemtokake panggonan sing padha karo kode layanan.
  • Ngatur mbusak grafik umum. Layanan bakal duwe release Helm dhewe. Iki bakal ngidini sampeyan ngatur siklus urip aplikasi (rollback, upgrade) ing tingkat paling cilik, supaya ora mengaruhi layanan liyane.
  • Keuntungan saka git kanggo manajemen grafik: mbatalake owah-owahan, log audit, etc.. Yen sampeyan kudu mbatalake owah-owahan ing grafik, sampeyan bisa nindakake iki nggunakake git. Penyebaran diwiwiti kanthi otomatis.
  • Sampeyan bisa uga nimbang nambah alur kerja pangembangan kanthi alat kaya Skaffold, sing pangembang bisa nguji owah-owahan ing konteks sing cedhak karo produksi.

Migrasi rong langkah

Pangembang kita wis nggunakake alur kerja iki sajrone 2 taun saiki, mula kita pengin migrasi dadi ora krasa lara. Mulane, kita mutusake kanggo nambah langkah penengah ing dalan menyang gol.
Tahap pisanan prasaja:

  • Kita tetep struktur sing padha kanggo nyetel panyebaran aplikasi, nanging ing obyek siji sing diarani 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 release saben aplikasi (tanpa grafik umum).
  • Bagan ing repositori git aplikasi.

Kita wis ngobrol karo kabeh pangembang, mula proses migrasi wis diwiwiti. Tahap pisanan isih dikontrol nggunakake platform CI. Aku bakal nulis kirim liyane rauh babagan phase loro: carane kita pindhah menyang alur kerja GitOps karo mili. Aku bakal pitutur marang kowe carane kita nyetel kabeh lan apa kangelan kita nemokke (multiple repositori, Rahasia, etc.). Tindakake kabar.

Ing kene kita wis nyoba njlèntrèhaké kemajuan kita ing alur kerja panyebaran aplikasi ing taun-taun kepungkur, sing ndadékaké pamikiran babagan pendekatan GitOps. Kita durung tekan target lan bakal nglaporake asil kasebut, nanging saiki kita yakin manawa nindakake perkara sing bener nalika mutusake kanggo nyederhanakake kabeh lan nyedhaki kabiasaan para pangembang.

Source: www.habr.com

Add a comment