Hogyan használja a Dailymotion a Kubernetes alkalmazást: Alkalmazástelepítés
Mi a Dailymotionnál 3 évvel ezelőtt kezdtük el a Kubernetes termelési használatát. Az alkalmazások több fürtben történő üzembe helyezése azonban szórakoztató, ezért az elmúlt néhány évben igyekeztünk javítani eszközeinket és munkafolyamatainkat.
Hol kezdődött
Itt bemutatjuk, hogyan telepítjük alkalmazásainkat több Kubernetes-fürtre szerte a világon.
Több Kubernetes objektum egyidejű üzembe helyezéséhez használjuk , és az összes diagramunkat egyetlen git tárolóban tároljuk. A teljes alkalmazáscsomag több szolgáltatásból történő telepítéséhez az úgynevezett összefoglaló diagramot használjuk. Lényegében ez egy diagram, amely deklarálja a függőségeket, és lehetővé teszi az API és szolgáltatásainak inicializálását egyetlen paranccsal.
A Helm tetejére egy kis Python-szkriptet is írtunk, amellyel ellenőrzéseket végezhet, diagramokat hozhat létre, titkokat adhat hozzá és alkalmazásokat telepíthet. Mindezeket a feladatokat egy központi CI platformon hajtják végre egy docker image segítségével.
Térjünk a lényegre.
Jegyzet. Ahogy ezt olvasod, már bejelentették a Helm 3 első megjelenési jelöltjét. A fő verzió egy sor fejlesztést tartalmaz a múltban tapasztalt problémák megoldására.
Diagram fejlesztési munkafolyamat
Az alkalmazásokhoz elágazást használunk, és úgy döntöttünk, hogy ugyanezt a megközelítést alkalmazzuk a diagramoknál is.
- Ág dev diagramok létrehozására szolgál, amelyeket a fejlesztési fürtökön tesztelnek.
- Amikor lehívási kérelmet nyújtanak be mester, stádiumban ellenőrzik.
- Végül létrehozunk egy lehívási kérelmet a módosítások végrehajtásához az ágon döf és alkalmazza őket a termelésben.
Minden környezetnek megvan a saját privát tárolója, amely a diagramjainkat tárolja, és mi használjuk nagyon hasznos API-kkal. Így biztosítjuk a környezetek szigorú elkülönítését és a diagramok valós tesztelését az éles felhasználás előtt.
Diagramtárak különböző környezetekben
Érdemes megjegyezni, hogy amikor a fejlesztők lenyomnak egy fejlesztői ágat, a diagramjuk egy verziója automatikusan a dev Chartmuseumba kerül. Így minden fejlesztő ugyanazt a fejlesztői adattárat használja, és gondosan meg kell adnia a diagram verzióját, hogy véletlenül ne használja valaki más módosításait.
Ezenkívül a mi kis Python-szkriptünk a Kubernetes-objektumokat a Kubernetes OpenAPI specifikációinak megfelelően érvényesíti , mielőtt közzéteszi őket a Chartmusemen.
A diagramfejlesztési munkafolyamat általános leírása
- Csővezetéki feladatok specifikáció szerinti beállítása minőségellenőrzésre (szösz, egységpróba).
- Docker kép leküldése Python-eszközökkel, amelyek telepítik alkalmazásainkat.
- A környezet beállítása ágnév szerint.
- Kubernetes yaml fájlok ellenőrzése a Kubeval segítségével.
- Automatikusan növeli a diagram és a szülődiagramjainak verziószámát (a diagramok, amelyek a módosítandó diagramtól függenek).
- Diagram beküldése a környezetének megfelelő Chartmuseumba
A klaszterek közötti különbségek kezelése
Klaszterek Szövetsége
Volt idő, amikor használtuk , ahol a Kubernetes objektumok egyetlen API-végpontról deklarálhatók. De problémák merültek fel. Például egyes Kubernetes-objektumok nem hozhatók létre az összevonási végpontban, ami megnehezíti az egyesített objektumok és egyéb objektumok karbantartását az egyes fürtökhöz.
A probléma megoldása érdekében elkezdtük a klaszterek önálló kezelését, ami nagymértékben leegyszerűsítette a folyamatot (az összevonás első verzióját használtuk, a másodiknál lehet, hogy valami megváltozott).
Földrajzilag elosztott platform
Platformunk jelenleg 6 régióban van elosztva – 3 helyileg és 3 a felhőben.
Elosztott telepítés
Globális Helm értékek
A 4 globális Helm érték lehetővé teszi a klaszterek közötti különbségek azonosítását. Minden diagramunk alapértelmezett minimális értékkel rendelkezik.
global:
cloud: True
env: staging
region: us-central1
clusterName: staging-us-central1Globális értékek
Ezek az értékek segítenek meghatározni alkalmazásaink kontextusát, és különféle célokra használhatók: figyelés, nyomkövetés, naplózás, külső hívások kezdeményezése, méretezés stb.
- "felhő": Van egy hibrid Kubernetes platformunk. Például API-nkat a GCP-zónákban és adatközpontjainkban telepítjük.
- "env": Egyes értékek nem éles környezetben változhatnak. Például erőforrás-definíciók és automatikus skálázási konfigurációk.
- "régió": Ez az információ segít meghatározni a fürt helyét, és felhasználható a külső szolgáltatások közeli végpontjainak meghatározására.
- "clusterName": ha és mikor akarunk értéket definiálni egy egyedi fürt számára.
Íme egy konkrét példa:
{{/* 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 sablon példa
Ez a logika egy segédsablonban van meghatározva, hogy elkerülje a Kubernetes YAML zsúfoltságát.
Pályázati hirdetmény
Üzembe helyezési eszközeink több YAML-fájlon alapulnak. Az alábbiakban egy példa látható arra, hogyan deklarálunk egy szolgáltatást és annak skálázási topológiáját (replikák számát) egy fürtben.
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: 3Szolgáltatás meghatározása
Ez a telepítési munkafolyamatunkat meghatározó összes lépés vázlata. Az utolsó lépés egyidejűleg több dolgozói fürtre telepíti az alkalmazást.
Jenkins telepítési lépései
Mi a helyzet a titkokkal?
Ami a biztonságot illeti, az összes titkot különböző helyekről nyomon követjük, és egyedi trezorban tároljuk Párizsban.
Üzembe helyezési eszközeink titkos értékeket nyernek ki a Vaultból, és amikor eljön a telepítés ideje, beillesztik őket a Helmbe.
Ehhez leképezést hoztunk létre a Vault titkai és az alkalmazásainknak szükséges titkok között:
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"- Meghatároztuk az általános szabályokat, amelyeket követni kell a titkok Vaultban történő rögzítésekor.
- Ha a titok érvényes egy adott kontextushoz vagy klaszterhez, hozzá kell adni egy konkrét bejegyzést. (Itt a kontextusfürt1-nek saját értéke van a titkos verem-app1-jelszóhoz).
- Ellenkező esetben az érték kerül felhasználásra alapértelmezés szerint.
- A listában szereplő minden egyes elemhez Kubernetes titok kulcs-érték pár kerül beillesztésre. Ezért a diagramjaink titkos sablonja nagyon egyszerű.
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: OpaqueProblémák és korlátok
Több adattárral való munkavégzés
Most különválasztjuk a diagramok és az alkalmazások fejlesztését. Ez azt jelenti, hogy a fejlesztőknek két git-tárolóban kell dolgozniuk: az egyikben az alkalmazáshoz, a másikban pedig a Kubernetes-be való telepítésének meghatározásához. A 2 git adattár 2 munkafolyamatot jelent, és az újoncok könnyen összezavarodhatnak.
Az általánosított diagramok kezelése gondot okoz
Ahogy már említettük, az általános diagramok nagyon hasznosak a függőségek azonosításához és több alkalmazás gyors üzembe helyezéséhez. De használjuk --reuse-valueshogy elkerüljük az összes érték átadását minden alkalommal, amikor olyan alkalmazást telepítünk, amely ennek az általánosított diagramnak a részét képezi.
A folyamatos kézbesítési munkafolyamatban csak két értékünk van, amelyek rendszeresen változnak: a replikák száma és a képcímke (verzió). Más, stabilabb értékek manuálisan módosíthatók, és ez meglehetősen nehéz. Sőt, amint azt saját tapasztalatainkból is láthattuk, egy általánosított diagram telepítésének egyetlen hibája súlyos hibákhoz vezethet.
Több konfigurációs fájl frissítése
Amikor egy fejlesztő új alkalmazást ad hozzá, több fájlt is módosítania kell: az alkalmazás deklarációját, a titkok listáját, és az alkalmazást függőségként fel kell vennie, ha az általánosított diagramon szerepel.
A Jenkins engedélyei túlságosan kiterjesztettek a Vaultban
Most van egy , amely minden titkot kiolvas a Vaultból.
A visszaállítási folyamat nem automatizált
A visszaállításhoz a parancsot több fürtön kell futtatni, és ez tele van hibákkal. Ezt a műveletet manuálisan hajtjuk végre, hogy biztosítsuk a helyes verzióazonosító megadását.
A GitOps felé haladunk
A mi célunk
Szeretnénk visszaküldeni a diagramot az általa telepített alkalmazás tárházába.
A munkafolyamat ugyanaz lesz, mint a fejlesztésnél. Például, amikor egy ágat a rendszer irányítani, a központi telepítés automatikusan elindul. A fő különbség e megközelítés és a jelenlegi munkafolyamat között az lenne minden gitben lesz kezelve (maga az alkalmazás és a telepítés módja a Kubernetesben).
Számos előnye van:
- Sokkal világosabb a fejlesztő számára. Könnyebb megtanulni, hogyan alkalmazza a változtatásokat egy helyi diagramon.
- A szolgáltatás telepítési definíciója megadható ugyanaz a hely, mint a kód szolgáltatás.
- Általánosított diagramok eltávolításának kezelése. A szolgáltatásnak saját Helm kiadása lesz. Ez lehetővé teszi az alkalmazás életciklusának kezelését (visszaállítás, frissítés) a legalacsonyabb szinten, hogy ne érintsen más szolgáltatásokat.
- A git előnyei diagramkezeléshez: módosítások visszavonása, auditnapló stb. Ha vissza kell vonnia egy diagram módosítását, ezt a git segítségével teheti meg. A telepítés automatikusan elindul.
- Fontolja meg a fejlesztési munkafolyamat javítását olyan eszközökkel, mint pl Skaffold, amellyel a fejlesztők a termeléshez közeli környezetben tesztelhetik a változásokat.
Kétlépcsős migráció
Fejlesztőink már 2 éve használják ezt a munkafolyamatot, ezért szeretnénk, ha a migráció a lehető legfájdalommentesebb lenne. Ezért úgy döntöttünk, hogy egy köztes lépést teszünk a cél felé vezető úton.
Az első szakasz egyszerű:
- Hasonló struktúrát tartunk fenn az alkalmazástelepítés beállításához, de egyetlen DailymotionRelease nevű objektumban.
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"- Alkalmazásonként 1 kiadás (általánosított diagramok nélkül).
- Diagramok az alkalmazás git-tárában.
Az összes fejlesztővel beszéltünk, így a migrációs folyamat már elkezdődött. Az első szakaszt továbbra is a CI platform vezérli. Hamarosan írok egy újabb bejegyzést a második fázisról: hogyan tértünk át a GitOps munkafolyamathoz . Elmondom, hogyan állítottunk be mindent, és milyen nehézségekbe ütköztünk (több adattár, titkok stb.). Kövesd a híreket.
Itt megpróbáltuk leírni az alkalmazástelepítési munkafolyamatban az elmúlt évek során elért fejlődésünket, ami a GitOps megközelítéssel kapcsolatos gondolatokhoz vezetett. Még nem értük el a célt, és beszámolunk az eredményekről, de most meg vagyunk győződve arról, hogy helyesen cselekedtünk, amikor úgy döntöttünk, hogy mindent leegyszerűsítünk, és közelebb hozzuk a fejlesztők szokásaihoz.
Forrás: will.com