Nyebarkeun aplikasi dina sababaraha klaster Kubernetes sareng Helm

Kumaha Dailymotion ngagunakeun Kubernetes: Deployment Aplikasi

Kami di Dailymotion mimitian nganggo Kubernetes dina produksi 3 sababaraha taun ka pengker. Tapi deploying aplikasi sakuliah sababaraha klaster téh senang, jadi dina sababaraha taun ka tukang urang geus nyobian pikeun ngaronjatkeun alat jeung workflows urang.

Dimana mimitina

Di dieu urang bakal nutupan kumaha urang nyebarkeun aplikasi di sababaraha klaster Kubernetes di sakuliah dunya.

Pikeun nyebarkeun sababaraha objék Kubernetes sakaligus, kami nganggo helem, sareng sadaya bagan kami disimpen dina hiji gudang git. Pikeun nyebarkeun tumpukan aplikasi lengkep tina sababaraha jasa, kami nganggo anu disebut bagan kasimpulan. Intina, ieu mangrupikeun bagan anu nyatakeun katergantungan sareng ngamungkinkeun anjeun pikeun ngamimitian API sareng jasana ku hiji paréntah.

Urang ogé nulis Aksara Python leutik di luhur Helm pikeun ngalakukeun cék, nyieun grafik, nambahkeun rusiah, sarta nyebarkeun aplikasi. Sadaya pancén ieu dilaksanakeun dina platform CI sentral nganggo gambar docker.

Hayu urang ka titik.

Catetan. Nalika anjeun maca ieu, calon pelepasan munggaran pikeun Helm 3 parantos diumumkeun. Versi utama ngandung sajumlah ageung perbaikan pikeun ngarengsekeun sababaraha masalah anu urang tepang dina jaman baheula.

Workflow ngembangkeun bagan

Kami nganggo branching pikeun aplikasi, sareng kami mutuskeun pikeun nerapkeun pendekatan anu sami kana bagan.

  • Cabang dev dipaké pikeun nyieun grafik anu bakal diuji dina klaster pangwangunan.
  • Nalika pamundut tarikan dikintunkeun ka ngawasaan, aranjeunna dipariksa dina pementasan.
  • Tungtungna, urang nyieun pamundut tarikan pikeun bunuh parobahan cabang produksi sareng nerapkeunana dina produksi.

Unggal lingkungan boga gudang swasta sorangan nu nyimpen grafik urang, sarta kami nganggo Chartmuseum kalawan API pisan mangpaat. Ku cara ieu kami mastikeun isolasi ketat antara lingkungan sareng uji dunya nyata tina bagan sateuacan dianggo dina produksi.

Repositories bagan dina lingkungan anu béda

Perlu dicatet yén nalika pamekar nyorong cabang dev, versi baganna otomatis kadorong ka dev Chartmuseum. Janten, sadaya pamekar nganggo gudang dev anu sami, sareng anjeun kedah ati-ati nangtukeun versi bagan anjeun supados henteu ngahaja nganggo parobihan batur.

Leuwih ti éta, Aksara Python saeutik urang validates objék Kubernetes ngalawan spésifikasi Kubernetes OpenAPI ngagunakeun Kubeval, sateuacan nyebarkeun aranjeunna dina Chartmusem.

Katerangan umum ngeunaan alur kerja pangwangunan bagan

  1. Nyetel tugas pipa nurutkeun spésifikasi gazr.io pikeun kadali kualitas (lint, unit-test).
  2. Ngadorong gambar docker nganggo alat Python anu nyebarkeun aplikasi kami.
  3. Nyetél lingkungan ku ngaran cabang.
  4. Validasi file yaml Kubernetes ngagunakeun Kubeval.
  5. Otomatis ningkatkeun versi bagan sareng bagan indungna (bagan anu gumantung kana bagan anu dirobih).
  6. Ngirimkeun bagan ka Chartmuseum anu cocog sareng lingkunganana

Ngatur bédana sakuliah klaster

Féderasi Kluster

Aya hiji waktu nalika urang dipaké federasi klaster Kubernetes, dimana objék Kubernetes bisa dinyatakeun tina hiji titik API tunggal. Tapi masalah timbul. Contona, sababaraha objék Kubernetes teu bisa dijieun dina titik tungtung federasi, sahingga hésé ngajaga objék federasi jeung objék séjén pikeun klaster individu.

Pikeun ngabéréskeun masalah, urang mimiti ngatur klaster sacara mandiri, anu nyederhanakeun prosésna (kami nganggo versi federasi munggaran; aya anu tiasa robih dina kadua).

platform Geo-disebarkeun

Platform kami ayeuna disebarkeun ka 6 daérah - 3 lokal sareng 3 dina méga.


Panyebaran disebarkeun

nilai Helm Global

4 nilai Helm global ngamungkinkeun anjeun pikeun ngaidentipikasi bédana antara klaster. Sadaya bagan urang gaduh nilai minimum standar.

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

nilai global

Nilai-nilai ieu ngabantosan netepkeun kontéks pikeun aplikasi kami sareng dianggo pikeun sababaraha tujuan: ngawaskeun, ngalacak, logging, nelepon éksternal, skala, jsb.

  • "awan": Kami gaduh platform Kubernetes hibrid. Contona, API urang disebarkeun di zona GCP sareng di pusat data urang.
  • "env": Sababaraha nilai tiasa robih pikeun lingkungan non-produksi. Contona, definisi sumberdaya jeung konfigurasi autoscaling.
  • "wilayah": Inpo ieu mantuan nangtukeun lokasi klaster sarta bisa dipaké pikeun nangtukeun titik tungtung caket dieu pikeun layanan éksternal.
  • "clusterName": lamun jeung iraha urang rék nangtukeun nilai pikeun klaster individu.

Ieu conto husus:

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

conto template Helm

Logika ieu didefinisikeun dina template helper pikeun ngahindarkeun cluttering Kubernetes YAML.

Pengumuman Lamaran

Alat panyebaran kami dumasar kana sababaraha file YAML. Di handap ieu conto kumaha urang nyatakeun jasa sareng topologi skala na (jumlah réplika) dina klaster.

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

Harti jasa

Ieu mangrupikeun garis tina sadaya léngkah anu netepkeun alur kerja panyebaran urang. Léngkah terakhir nyebarkeun aplikasi ka sababaraha klaster pagawé sakaligus.


Jenkins deployment Léngkah

Kumaha upami rusiah?

Ngeunaan kaamanan, urang ngalacak sagala rusiah ti tempat anu béda sareng nyimpenna dina kolong anu unik lomari wesi di Paris.

Alat panyebaran kami nimba nilai rusiah tina Vault sareng, nalika waktos panyebaran sumping, selapkeun kana Helm.

Jang ngalampahkeun ieu, kami netepkeun pemetaan antara rusiah dina Vault sareng rusiah anu diperyogikeun ku aplikasi kami:

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"

  • Kami parantos netepkeun aturan umum anu kedah diturutan nalika ngarékam rusiah di Vault.
  • Lamun rusiah lumaku kana konteks atawa klaster husus, Anjeun kudu nambahkeun entri husus. (Di dieu cluster1 konteks boga nilai sorangan pikeun rusiah stack-app1-sandi).
  • Upami teu kitu, nilai dipaké sacara standar.
  • Pikeun unggal item dina daptar ieu dina Rahasia Kubernetes pasangan konci-nilai diselapkeun. Ku alatan éta, template rusiah dina grafik urang basajan pisan.

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 jeung watesan

Gawe sareng sababaraha repositories

Ayeuna urang misahkeun pamekaran grafik sareng aplikasi. Ieu ngandung harti yén pamekar kedah damel di dua repositori git: hiji pikeun aplikasi, sareng hiji pikeun netepkeun panyebaranna ka Kubernetes. 2 git repositories hartosna 2 workflows, sarta gampang pikeun newbie bingung.

Ngatur bagan umum nyaéta repot

Sakumaha urang parantos nyarios, bagan generik mangpaat pisan pikeun ngaidentipikasi katergantungan sareng gancang nyebarkeun sababaraha aplikasi. Tapi urang ngagunakeun --reuse-valuespikeun ngahindarkeun ngalangkungan sadaya nilai unggal waktos urang nyebarkeun aplikasi anu mangrupikeun bagian tina bagan umum ieu.

Dina alur kerja pangiriman kontinyu, urang ngan ukur gaduh dua nilai anu rutin robih: jumlah réplika sareng tag gambar (versi). Lain, nilai anu langkung stabil dirobih sacara manual, sareng ieu sesah. Sumawona, hiji kasalahan dina nyebarkeun bagan umum tiasa nyababkeun kagagalan anu serius, sakumaha anu urang tingali tina pangalaman urang sorangan.

Ngamutahirkeun sababaraha file konfigurasi

Nalika pamekar nambihan aplikasi anyar, anjeunna kedah ngarobih sababaraha file: deklarasi aplikasi, daptar rahasia, nambihan aplikasi salaku kagumantungan upami kalebet dina bagan umum.

Idin Jenkins diperpanjang teuing di Vault

Ayeuna urang gaduh hiji AppRole, nu maca sagala Rahasia ti Kolong.

Prosés rollback henteu otomatis

Pikeun rollback, anjeun kudu ngajalankeun paréntah dina sababaraha klaster, sarta ieu fraught kalawan kasalahan. Urang ngalakukeun operasi ieu sacara manual pikeun mastikeun yén ID vérsi anu bener dieusian.

Kami nuju ka GitOps

Tujuan urang

Kami hoyong uih deui bagan ka gudang aplikasi anu disebarkeun.

Alur kerja bakal sami sareng pikeun pangwangunan. Contona, nalika cabang kadorong ka master, deployment bakal dipicu otomatis. Beda utama antara pendekatan ieu sareng alur kerja ayeuna nyaéta éta sagalana bakal diatur dina git (aplikasi sorangan jeung cara eta deployed di Kubernetes).

Aya sababaraha kaunggulan:

  • loba leuwih jelas pikeun pamekar. Leuwih gampang pikeun neuleuman kumaha carana nerapkeun parobahan dina bagan lokal.
  • Definisi deployment jasa bisa dieusian tempat anu sarua sakumaha kode palayanan.
  • Ngatur panyabutan grafik umum. Ladenan éta bakal gaduh sékrési Helm sorangan. Ieu bakal ngidinan Anjeun pikeun ngatur lifecycle aplikasi (rollback, ningkatkeun) dina tingkat pangleutikna, ku kituna teu mangaruhan jasa lianna.
  • Keunggulan git pikeun manajemén bagan: bolaykeun parobahan, log Inok, jsb Lamun perlu bolaykeun parobahan grafik a, Anjeun tiasa ngalakukeun ieu ngagunakeun git. deployment dimimitian otomatis.
  • Anjeun tiasa mertimbangkeun ningkatkeun alur kerja pangembangan anjeun nganggo alat sapertos Skaffold, nu pamekar bisa nguji parobahan dina konteks deukeut produksi.

Migrasi dua léngkah

Pamekar kami parantos nganggo alur kerja ieu salami 2 taun ayeuna, janten kami hoyong migrasi janten henteu aya rasa nyeri-gancang. Ku alatan éta, urang mutuskeun pikeun nambahkeun hiji hambalan panengah dina jalan ka gawang.
Tahap kahiji basajan:

  • Urang nyimpen struktur sarupa pikeun nyetel deployment aplikasi, tapi dina hiji objek disebut 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 per aplikasi (tanpa grafik umum).
  • Bagan dina gudang git aplikasi.

Kami parantos ngobrol sareng sadaya pamekar, janten prosés migrasi parantos dimimitian. Tahap kahiji masih dikawasa ngagunakeun platform CI. Kuring gé nulis pos sejen pas ngeunaan fase dua: kumaha urang dipindahkeun ka workflow GitOps kalawan ngocor. Kuring bakal nyarioskeun ka anjeun kumaha urang nyetél sadayana sareng kasusah naon anu kami hadapi (sababaraha repositori, rusiah, jsb.). Tuturkeun warta.

Di dieu kami parantos nyobian ngajelaskeun kamajuan urang dina alur kerja panyebaran aplikasi salami sababaraha taun ka pengker, anu nyababkeun pamikiran ngeunaan pendekatan GitOps. Kami henteu acan ngahontal tujuan sareng bakal ngalaporkeun hasil, tapi ayeuna urang yakin yén urang ngalakukeun hal anu leres nalika urang mutuskeun pikeun nyederhanakeun sadayana sareng ngadeukeutkeun kana kabiasaan pamekar.

sumber: www.habr.com

Tambahkeun komentar