Dailymotion Kubernetes-dən necə istifadə edir: Tətbiq Yerləşdirmə
Dailymotion-da biz Kubernetes-dən 3 il əvvəl istehsalda istifadə etməyə başladıq. Lakin proqramların çoxsaylı klasterlərdə yerləşdirilməsi əyləncəlidir, ona görə də son bir neçə il ərzində biz alətlərimizi və iş axınlarımızı təkmilləşdirməyə çalışırıq.
Harada başladı
Burada tətbiqlərimizi dünya üzrə çoxsaylı Kubernetes klasterlərində necə yerləşdirdiyimizi əhatə edəcəyik.
Birdən çox Kubernetes obyektini yerləşdirmək üçün istifadə edirik , və bütün diaqramlarımız bir git deposunda saxlanılır. Bir neçə xidmətdən tam proqram yığınını yerləşdirmək üçün biz sözdə xülasə diaqramından istifadə edirik. Əslində, bu, asılılıqları elan edən və bir əmrlə API və onun xidmətlərini işə salmağa imkan verən bir qrafikdir.
Biz həmçinin yoxlamalar aparmaq, diaqramlar yaratmaq, sirlər əlavə etmək və tətbiqləri yerləşdirmək üçün Helm-in üstünə kiçik bir Python skripti yazdıq. Bütün bu vəzifələr docker görüntüsündən istifadə edərək mərkəzi CI platformasında yerinə yetirilir.
Gəlin mətləbə.
Qeyd. Bunu oxuduğunuz kimi, Helm 3 üçün ilk buraxılış namizədi artıq elan edilmişdir. Əsas versiyada keçmişdə qarşılaşdığımız bəzi problemləri həll etmək üçün bir çox təkmilləşdirmələr var.
Diaqramın işlənməsi prosesi
Tətbiqlər üçün şaxələnmədən istifadə edirik və eyni yanaşmanı qrafiklərə tətbiq etmək qərarına gəldik.
- Filial dev inkişaf klasterlərində sınaqdan keçiriləcək diaqramlar yaratmaq üçün istifadə olunur.
- Çəkmə sorğusu göndərildikdə ustad, onlar səhnələşdirmədə yoxlanılır.
- Nəhayət, filiala dəyişikliklər etmək üçün çəkmə sorğusu yaradırıq prod və onları istehsalda tətbiq etmək.
Hər bir mühitin qrafiklərimizi saxlayan öz şəxsi deposu var və biz istifadə edirik çox faydalı API ilə. Bu yolla, istehsalda istifadə etməzdən əvvəl, mühitlər arasında ciddi təcrid və qrafiklərin real dünyada sınaqdan keçirilməsini təmin edirik.
Fərqli mühitlərdə diaqram depoları
Qeyd etmək lazımdır ki, tərtibatçılar bir dev filialını itələdikdə, onların qrafikinin bir versiyası avtomatik olaraq dev Chartmuseum-a köçürülür. Beləliklə, bütün tərtibatçılar eyni inkişaf deposundan istifadə edirlər və başqasının dəyişikliklərindən təsadüfən istifadə etməmək üçün qrafikin versiyasını diqqətlə göstərməlisiniz.
Üstəlik, kiçik Python skriptimiz Kubernetes obyektlərini Kubernetes OpenAPI spesifikasiyalarına qarşı təsdiqləyir. , onları Chartmusem-də dərc etməzdən əvvəl.
Diaqramın işlənməsi prosesinin ümumi təsviri
- Spesifikasiyaya uyğun olaraq boru kəməri tapşırıqlarının qurulması keyfiyyətə nəzarət üçün (lint, vahid test).
- Tətbiqlərimizi yerləşdirən Python alətləri ilə docker şəklini itələmək.
- Filial adı ilə mühitin qurulması.
- Kubeval istifadə edərək Kubernetes yaml fayllarının təsdiqlənməsi.
- Diaqramın versiyasını və onun əsas diaqramlarını (dəyişdirilən diaqramdan asılı olan qrafiklər) avtomatik artırın.
- Diaqramın onun mühitinə uyğun olan Chartmuseum-a təqdim edilməsi
Klasterlər arasında fərqlərin idarə edilməsi
Klasterlər Federasiyası
Bizim istifadə etdiyimiz vaxt olub , burada Kubernetes obyektləri tək API son nöqtəsindən elan edilə bilər. Ancaq problemlər yarandı. Məsələn, bəzi Kubernetes obyektləri federasiyanın son nöqtəsində yaradıla bilmədi, bu da fərdi klasterlər üçün federasiya edilmiş obyektlərin və digər obyektlərin saxlanmasını çətinləşdirir.
Problemi həll etmək üçün biz klasterləri müstəqil şəkildə idarə etməyə başladıq, bu da prosesi xeyli sadələşdirdi (biz federasiyanın birinci versiyasından istifadə etdik; ikincisində nəsə dəyişə bilərdi).
Geo-paylanmış platforma
Platformamız hazırda 6 regionda paylanır - 3-ü yerli, 3-ü isə buludda.
Paylanmış Yerləşdirmə
Qlobal Helm dəyərləri
4 qlobal Helm dəyəri klasterlər arasındakı fərqləri müəyyən etməyə imkan verir. Bütün diaqramlarımız standart minimum dəyərlərə malikdir.
global:
cloud: True
env: staging
region: us-central1
clusterName: staging-us-central1Qlobal dəyərlər
Bu dəyərlər tətbiqlərimiz üçün konteksti müəyyənləşdirməyə kömək edir və müxtəlif məqsədlər üçün istifadə olunur: monitorinq, izləmə, qeydlər, xarici zənglər, miqyaslama və s.
- "bulud": Bizim hibrid Kubernetes platformamız var. Məsələn, API-miz GCP zonalarında və məlumat mərkəzlərimizdə yerləşdirilib.
- "env": Bəzi dəyərlər qeyri-istehsal mühitləri üçün dəyişə bilər. Məsələn, resurs tərifləri və avtomatik ölçmə konfiqurasiyaları.
- "region": Bu məlumat klasterin yerini müəyyən etməyə kömək edir və xarici xidmətlər üçün yaxınlıqdakı son nöqtələri müəyyən etmək üçün istifadə edilə bilər.
- "clusterName": fərdi klaster üçün dəyər təyin etmək istəsək və nə vaxt.
Budur konkret bir nümunə:
{{/* 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 -}}Helm şablon nümunəsi
Bu məntiq Kubernetes YAML-ni qarışdırmamaq üçün köməkçi şablonda müəyyən edilmişdir.
Ərizə elanı
Yerləşdirmə alətlərimiz çoxsaylı YAML fayllarına əsaslanır. Aşağıda bir klasterdə bir xidməti və onun miqyaslı topologiyasını (replikaların sayı) necə elan etdiyimizə dair bir nümunə verilmişdir.
releases:
- foo.world
foo.world: # Release name
services: # List of dailymotion's apps/projects
foobar:
chart_name: foo-foobar
repo: git@github.com:dailymotion/foobar
contexts:
prod-europe-west1:
deployments:
- name: foo-bar-baz
replicas: 18
- name: another-deployment
replicas: 3Xidmət Tərifi
Bu, yerləşdirmə iş axınımızı müəyyən edən bütün addımların konturudur. Son addım tətbiqi eyni vaxtda birdən çox işçi qruplarına yerləşdirir.
Jenkins Yerləşdirmə Addımları
Bəs sirlər?
Təhlükəsizliyə gəlincə, biz bütün sirləri müxtəlif yerlərdən izləyirik və onları unikal bir anbarda saxlayırıq Parisdə.
Yerləşdirmə alətlərimiz Vault-dan gizli dəyərlər çıxarır və yerləşdirmə vaxtı gələndə onları Helm-ə daxil edin.
Bunu etmək üçün biz Vault-dakı sirrlərlə tətbiqlərimizin ehtiyac duyduğu sirrlər arasında xəritəni təyin etdik:
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"- Vault-da sirrləri qeyd edərkən riayət etməli olduğumuz ümumi qaydaları müəyyən etdik.
- Əgər sirr tətbiq olunarsa xüsusi kontekst və ya klaster üçün, xüsusi bir giriş əlavə etməlisiniz. (Burada kontekst klaster1 gizli yığın-app1-parol üçün öz dəyərinə malikdir).
- Əks halda dəyər istifadə olunur default olaraq.
- Bu siyahıdakı hər bir element üçün Kubernetes sirri açar-dəyər cütü daxil edilir. Buna görə də qrafiklərimizdəki gizli şablon çox sadədir.
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: OpaqueProblemlər və məhdudiyyətlər
Çoxsaylı depolarla işləmək
İndi biz diaqramların və tətbiqlərin işlənməsini ayırırıq. Bu o deməkdir ki, tərtibatçılar iki git deposunda işləməlidirlər: biri tətbiq üçün, digəri isə onun Kubernetes-də yerləşdirilməsini müəyyən etmək üçün. 2 git repozitoriyası 2 iş axını deməkdir və yeni başlayan üçün çaşqın olmaq asandır.
Ümumiləşdirilmiş diaqramları idarə etmək əngəldir
Artıq dediyimiz kimi, ümumi diaqramlar asılılıqları müəyyən etmək və birdən çox tətbiqi tez yerləşdirmək üçün çox faydalıdır. Amma istifadə edirik --reuse-valuesbu ümumiləşdirilmiş diaqramın bir hissəsi olan tətbiqi hər dəfə yerləşdirdiyimiz zaman bütün dəyərləri ötürməmək üçün.
Davamlı çatdırılma işində biz müntəzəm olaraq dəyişən yalnız iki dəyərə sahibik: replikaların sayı və şəkil etiketi (versiya). Digər, daha sabit dəyərlər əl ilə dəyişdirilir və bu olduqca çətindir. Üstəlik, ümumiləşdirilmiş diaqramın tətbiqində bir səhv, öz təcrübəmizdən gördüyümüz kimi, ciddi uğursuzluqlara səbəb ola bilər.
Çoxlu konfiqurasiya fayllarının yenilənməsi
Tərtibatçı yeni proqram əlavə etdikdə, o, bir neçə faylı dəyişməli olur: tətbiq bəyannaməsi, sirlərin siyahısı, proqram ümumiləşdirilmiş diaqrama daxil edilibsə, onu asılılıq kimi əlavə edir.
Jenkins icazələri Vault-da çox uzadılıb
İndi bizdə biri var , Vaultdan bütün sirləri oxuyan.
Geri qaytarma prosesi avtomatlaşdırılmayıb
Geri qaytarmaq üçün əmri bir neçə klasterdə işlətməlisiniz və bu, səhvlərlə doludur. Düzgün versiya identifikatorunun göstərilməsini təmin etmək üçün bu əməliyyatı əl ilə həyata keçiririk.
GitOps-a doğru irəliləyirik
Bizim məqsədimiz
Biz qrafiki yerləşdirdiyi tətbiqin repozitoriyasına qaytarmaq istəyirik.
İş prosesi inkişafla eyni olacaq. Məsələn, filial mastera itələndikdə, yerləşdirmə avtomatik olaraq işə salınacaq. Bu yanaşma ilə cari iş axını arasındakı əsas fərq ondan ibarətdir ki hər şey git-də idarə olunacaq (tətbiqin özü və onun Kubernetes-də yerləşdirilmə üsulu).
Bir sıra üstünlüklər var:
- Çox daha aydın developer üçün. Yerli diaqramda dəyişiklikləri necə tətbiq etməyi öyrənmək daha asandır.
- Xidmətin yerləşdirilməsi tərifi müəyyən edilə bilər kodla eyni yer xidmət.
- Ümumiləşdirilmiş diaqramların silinməsini idarə etmək. Xidmətin öz Helm buraxılışı olacaq. Bu, digər xidmətlərə təsir etməmək üçün tətbiqin həyat dövrünü (geri qaytarma, təkmilləşdirmə) ən kiçik səviyyədə idarə etməyə imkan verəcək.
- Git-in faydaları diaqramın idarə edilməsi üçün: dəyişiklikləri geri al, audit jurnalı və s. Əgər diaqramdakı dəyişikliyi ləğv etmək lazımdırsa, bunu git istifadə edərək edə bilərsiniz. Yerləşdirmə avtomatik olaraq başlayır.
- kimi alətlərlə inkişaf iş prosesinizi təkmilləşdirməyi düşünə bilərsiniz Skaffold, onun köməyi ilə tərtibatçılar istehsala yaxın kontekstdə dəyişiklikləri sınaqdan keçirə bilərlər.
İki addımlı miqrasiya
Tərtibatçılarımız artıq 2 ildir ki, bu iş prosesindən istifadə edirlər, ona görə də köçün mümkün qədər ağrısız olmasını istəyirik. Buna görə də, məqsədə gedən yolda ara addım əlavə etmək qərarına gəldik.
Birinci mərhələ sadədir:
- Tətbiqlərin yerləşdirilməsinin qurulması üçün oxşar strukturu saxlayırıq, lakin DailymotionRelease adlı bir obyektdə.
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"- Tətbiq üçün 1 buraxılış (ümumiləşdirilmiş qrafiklər olmadan).
- Proqramın git deposundakı qrafiklər.
Biz bütün tərtibatçılarla danışdıq, ona görə də miqrasiya prosesi artıq başlayıb. Birinci mərhələ hələ də CI platformasından istifadə etməklə idarə olunur. Tezliklə ikinci mərhələ haqqında başqa bir yazı yazacağam: GitOps iş prosesinə necə keçdik . Mən sizə hər şeyi necə qurduğumuzu və hansı çətinliklərlə qarşılaşdığımızı (çox depolar, sirlər və s.) Deyəcəyəm. Xəbərləri izləyin.
Burada biz GitOps yanaşması haqqında düşüncələrə səbəb olan son illər ərzində tətbiqlərin yerləşdirilməsi iş prosesində irəliləyişimizi təsvir etməyə çalışdıq. Biz hələ məqsədə çatmamışıq və nəticələr barədə məlumat verəcəyik, lakin indi hər şeyi sadələşdirmək və onu tərtibatçıların vərdişlərinə yaxınlaşdırmaq qərarına gələndə düzgün hərəkət etdiyimizə əminik.
Mənbə: www.habr.com
