د هیلم سره د ډیری کبرنیټ کلسترونو کې غوښتنلیکونه ځای په ځای کړئ

ډیلی موشن څنګه کوبرنیټس کاروي: د غوښتنلیک ځای پرځای کول

موږ په ډیلی موشن کې 3 کاله دمخه په تولید کې د کبرنیټ کارول پیل کړل. مګر په ډیری کلسترونو کې د غوښتنلیکونو ځای په ځای کول ساتیري ده، نو په تیرو څو کلونو کې موږ هڅه کوو چې خپل وسایل او کاري جریان ښه کړو.

له کومه ځایه پیل شو

دلته به موږ پوښښ وکړو چې څنګه موږ خپل غوښتنلیکونه د نړۍ په ګوټ ګوټ کې د کبرنیټس کلسترونو کې ځای په ځای کوو.

په یوځل کې د ډیری کبرنیټس شیانو ځای په ځای کولو لپاره ، موږ کاروو خولۍ، او زموږ ټول چارټونه په یوه ګیټ ذخیره کې زیرمه شوي. د ډیری خدماتو څخه د بشپړ غوښتنلیک سټیک ځای په ځای کولو لپاره، موږ د تش په نامه لنډیز چارټ کاروو. په لازمي ډول ، دا یو چارټ دی چې انحصار اعالن کوي ​​او تاسو ته اجازه درکوي چې API او د هغې خدمات د یوې کمانډ سره پیل کړئ.

موږ د هیلم په سر کې یو کوچنی پایتون سکریپټ هم لیکلی ترڅو چکونه ترسره کړي، چارټونه جوړ کړي، رازونه اضافه کړي، او غوښتنلیکونه ځای پرځای کړي. دا ټولې دندې د ډاکر عکس په کارولو سره په مرکزي CI پلیټ فارم کې ترسره کیږي.

راځئ چې ټکي ته ورسیږو.

نوټ. لکه څنګه چې تاسو دا لوستل، د هیلم 3 لپاره د لومړي خوشې کیدو کاندید لا دمخه اعلان شوی. اصلي نسخه د پرمختګونو بشپړ کوربه لري ترڅو ځینې مسلې حل کړي چې موږ په تیرو وختونو کې ورسره مخ شوي یو.

د چارټ پراختیا کاري جریان

موږ د غوښتنلیکونو لپاره برانچینګ کاروو، او موږ پریکړه وکړه چې په چارټونو کې ورته طریقه پلي کړو.

• څانګه dev د چارټونو جوړولو لپاره کارول کیږي چې د پراختیا کلسترونو کې به ازمول کیږي.
• کله چې د پلولو غوښتنه وسپارل شي د بادار، دوی په مرحله کې چک شوي.
• په نهایت کې ، موږ په څانګه کې د بدلونونو ژمن کولو لپاره د پلټ غوښتنه رامینځته کوو پروډ او په تولید کې یې پلي کړئ.

هر چاپیریال خپل شخصي ذخیره لري چې زموږ چارټونه ذخیره کوي، او موږ یې کاروو چارټ میوزیم د خورا ګټور APIs سره. پدې توګه موږ په تولید کې د کارولو دمخه د چاپیریال او ریښتیني نړۍ د چارټونو ازموینې ترمینځ سخت انزوا ډاډمن کوو.

په مختلف چاپیریال کې د چارټ ذخیره

دا د یادونې وړ ده چې کله پراختیا کونکي د دیو برانچ فشار راوړي ، د دوی د چارټ یوه نسخه په اوتومات ډول د ډیو چارټ میوزیم ته اړول کیږي. پدې توګه ، ټول پراختیا کونکي ورته dev ذخیره کاروي ، او تاسو اړتیا لرئ په دقت سره د چارټ خپل نسخه مشخص کړئ ترڅو په ناڅاپي ډول د بل چا بدلونونه ونه کاروئ.

سربیره پردې، زموږ کوچنی Python سکریپټ د Kubernetes توکي د Kubernetes OpenAPI مشخصاتو په کارولو سره تاییدوي کوبیوال, مخکې له دې چې دوی په چارټموسیم کې خپاره کړي.

د چارټ د پراختیا کاري فلو عمومي توضیحات

1. د مشخصاتو سره سم د پایپ لاین دندې تنظیم کول gazr.io د کیفیت کنټرول لپاره (لینټ، یونټ-ټیسټ).
2. د Python وسیلو سره د ډاکر عکس فشار کول چې زموږ غوښتنلیکونه ځای په ځای کوي.
3. د څانګې په نوم د چاپیریال تنظیم کول.
4. د Kubeval په کارولو سره د Kubernetes yaml فایلونو اعتبار کول.
5. په اوتومات ډول د چارټ نسخه او د هغې اصلي چارټونه زیات کړئ (چارتونه چې په چارټ کې بدلون پورې اړه لري).
6. د چارټ میوزیم ته د چارټ سپارل چې د دې چاپیریال سره سمون لري

په کلسترونو کې د توپیرونو اداره کول

د کلسترونو فدراسیون

یو وخت و چې موږ یې کاروو د Kubernetes کلسترونو فدراسیون، چیرې چې د کوبرنیټس توکي د یو واحد API پای نقطې څخه اعلان کیدی شي. خو ستونزې را ولاړې شوې. د مثال په توګه، د فدراسیون په پای کې ځینې Kubernetes څیزونه نشي رامینځته کیدی، د انفرادي کلسترونو لپاره د فدرالي شیانو او نورو شیانو ساتل ستونزمن کوي.

د ستونزې د حل لپاره، موږ په خپلواکه توګه د کلسترونو اداره کول پیل کړل، کوم چې پروسه خورا ساده کړې (موږ د فدراسیون لومړۍ نسخه کارولې؛ یو څه ممکن په دویمه کې بدل شوي وي).

جیو ویشل شوی پلیټ فارم

زموږ پلیټ فارم اوس مهال په 6 سیمو کې توزیع شوی - 3 په محلي توګه او 3 په بادل کې.

ویشل شوی ځای پرځای کول

د نړیوال هیلم ارزښتونه

4 نړیوال هیلم ارزښتونه تاسو ته اجازه درکوي چې د کلسترونو ترمنځ توپیرونه وپیژني. زموږ ټول چارټونه د ډیفالټ لږترلږه ارزښتونه لري.

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

نړیوال ارزښتونه

دا ارزښتونه زموږ د غوښتنلیکونو لپاره شرایط تعریف کولو کې مرسته کوي او د مختلف اهدافو لپاره کارول کیږي: نظارت کول ، تعقیب کول ، ننوتل ، بهرني تلیفونونه کول ، اندازه کول او داسې نور.

• "بادل": موږ یو هایبرډ کبرنیټ پلیټ فارم لرو. د مثال په توګه، زموږ API په GCP زونونو او زموږ د معلوماتو مرکزونو کې ځای پرځای شوي.
• "env": ځینې ارزښتونه ممکن د غیر تولید چاپیریال لپاره بدل شي. د مثال په توګه، د سرچینو تعریفونه او د اتوماتیک کولو ترتیب.
• "region": دا معلومات د کلستر د موقعیت په ټاکلو کې مرسته کوي او د بهرنیو خدماتو لپاره د نږدې پای ټکی ټاکلو لپاره کارول کیدی شي.
• "clusterName": که او کله موږ غواړو د یو انفرادي کلستر لپاره ارزښت تعریف کړو.

دلته یو ځانګړی مثال دی:

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

د هیلم ټیمپلیټ بیلګه

دا منطق په مرستندویه ټیمپلیټ کې تعریف شوی ترڅو د Kubernetes YAML ګډوډۍ مخه ونیسي.

د غوښتنلیک اعلان

زموږ د ګمارنې وسیلې د ډیری YAML فایلونو پراساس دي. لاندې یو مثال دی چې څنګه موږ په کلستر کې یو خدمت او د هغې اندازه کولو ټوپولوژي (د نقلونو شمیر) اعلان کوو.

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

د خدمت تعریف

دا د ټولو ګامونو یوه خاکه ده چې زموږ د ګمارنې کاري فلو تعریفوي. وروستی ګام په ورته وخت کې ډیری کارګر کلسترونو ته غوښتنلیک ځای په ځای کوي.

د جینکنز ګمارنې مرحلې

د رازونو په اړه څه؟

د امنیت په اړه، موږ ټول رازونه د مختلفو ځایونو څخه تعقیب کوو او په یو ځانګړي والټ کې یې ذخیره کوو هدېرې په پاریس کې.

زموږ د ګمارنې وسیلې له والټ څخه پټ ارزښتونه استخراجوي او کله چې د ځای پرځای کولو وخت راشي نو هیلم ته یې داخل کړئ.

د دې کولو لپاره ، موږ په والټ کې د رازونو او هغه رازونو ترمینځ نقشه تعریف کړه چې زموږ غوښتنلیکونه ورته اړتیا لري:

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"

• موږ په والټ کې د رازونو ثبتولو پرمهال د تعقیب لپاره عمومي مقررات تعریف کړي دي.
• که پټه پلي شي یو ځانګړي شرایطو یا کلستر ته، تاسو اړتیا لرئ یو ځانګړی ننوتل اضافه کړئ. (دلته د شرایطو کلستر 1 د پټ سټیک-ایپ 1- پاسورډ لپاره خپل ارزښت لري).
• که نه نو ارزښت کارول کیږي په تلواله.
• په دې لیست کې د هر توکي لپاره د Kubernetes راز د کلیدي ارزښت جوړه داخلیږي. له همدې امله، زموږ په چارټونو کې پټه نمونه خورا ساده ده.

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

ستونزې او محدودیتونه

د ډیری ذخیره کولو سره کار کول

اوس موږ د چارټونو او غوښتنلیکونو پراختیا جلا کوو. د دې معنی دا ده چې پراختیا کونکي باید په دوه ګیټ ذخیره کې کار وکړي: یو د غوښتنلیک لپاره ، او بل یې کوبرنیټس ته د دې ګمارلو تعریف کولو لپاره. 2 git ذخیره د 2 کاري جریان معنی لري ، او د نوي زده کونکي لپاره مغشوش کیدل اسانه دي.

د عمومي چارټونو اداره کول یوه ستونزه ده

لکه څنګه چې موږ دمخه وویل، عمومي چارټونه د انحصار پیژندلو او په چټکۍ سره د ډیری غوښتنلیکونو ځای پرځای کولو لپاره خورا ګټور دي. مګر موږ کاروو --reuse-valuesد دې لپاره چې هرکله چې موږ یو غوښتنلیک ځای په ځای کړو چې د دې عمومي چارټ برخه ده د ټولو ارزښتونو له تیریدو څخه مخنیوی وکړئ.

په دوامداره تحویلي کاري فلو کې ، موږ یوازې دوه ارزښتونه لرو چې په منظم ډول بدلیږي: د عکسونو شمیر او د عکس ټاګ (نسخه). نور، ډیر باثباته ارزښتونه په لاسي ډول بدل شوي، او دا خورا ستونزمن دی. سربیره پردې، د عمومي چارټ په ځای کولو کې یوه تېروتنه کولی شي د جدي ناکامیو لامل شي، لکه څنګه چې موږ د خپلې تجربې څخه لیدلي.

د ډیری تشکیلاتو فایلونو تازه کول

کله چې یو پرمخ وړونکی نوی غوښتنلیک اضافه کړي، هغه باید ډیری فایلونه بدل کړي: د غوښتنلیک اعلامیه، د رازونو لیست، غوښتنلیک د انحصار په توګه اضافه کول که چیرې دا په عمومي چارټ کې شامل وي.

په والټ کې د جینکنز اجازه خورا پراخه شوې

اوس موږ یو AppRole، کوم چې د والټ ټول رازونه لوستل.

د رول بیک پروسه اتومات نه ده

د رول بیک کولو لپاره ، تاسو اړتیا لرئ په څو کلسترونو کې کمانډ چل کړئ ، او دا له غلطیو ډک دی. موږ دا عملیات په لاسي ډول ترسره کوو ترڅو ډاډ ترلاسه کړو چې صحیح نسخه ID مشخص شوی.

موږ د GitOps په لور روان یو

زموږ هدف

موږ غواړو چارټ د غوښتنلیک ذخیره کولو ته راستون کړو چې دا ځای په ځای کوي.

د کار جریان به د پراختیا لپاره ورته وي. د مثال په توګه، کله چې یوه څانګه ماسټر ته وهل کیږي، ګمارل به په اوتومات ډول پیل شي. د دې طریقې او اوسني کاري فلو ترمنځ اصلي توپیر به دا وي هرڅه به په git کې اداره شي (اپلیکیشن پخپله او هغه طریقه چې دا په کوبرنیټس کې ځای په ځای شوی).

څو ګټې لري:

• ډیر روښانه د پراختیا کونکي لپاره. دا اسانه ده چې زده کړئ چې څنګه په محلي چارټ کې بدلونونه پلي کړئ.
• د خدماتو ګمارلو تعریف مشخص کیدی شي د کوډ په څیر ورته ځای خدمت
• د عمومي شوي چارټونو د لرې کولو اداره کول. خدمت به خپل هیلم خوشې کړي. دا به تاسو ته اجازه درکړي چې په کوچنۍ کچه د غوښتنلیک د ژوند دورې (رول بیک، اپ گریڈ) اداره کړئ، ترڅو په نورو خدماتو اغیزه ونکړي.
• د ګیټ ګټې د چارټ مدیریت لپاره: بدلونونه بیرته راګرځول، د پلټنې لاګ، او نور. که تاسو اړتیا لرئ چې په چارټ کې بدلون بیرته راولي، تاسو کولی شئ دا د git په کارولو سره ترسره کړئ. ګمارنه په اوتومات ډول پیل کیږي.
• تاسو ممکن د وسیلو سره ستاسو د پراختیا کاري فلو ښه کولو په اړه فکر وکړئ سکافولډ، د کوم سره چې پراختیا کونکي کولی شي تولید ته نږدې شرایطو کې بدلونونه معاینه کړي.

دوه ګامه مهاجرت

زموږ پراختیا کونکي اوس د 2 کلونو لپاره دا کاري فلو کاروي، نو موږ غواړو مهاجرت د امکان تر حده بې درده وي. له همدې امله، موږ پریکړه وکړه چې هدف ته په لاره کې یو منځنی ګام اضافه کړو.
لومړی پړاو ساده دی:

• موږ د غوښتنلیک پلي کولو تنظیم کولو لپاره ورته جوړښت ساتو ، مګر په یو واحد څیز کې چې د 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 خوشې کول (پرته له عمومي چارټونو).
• د غوښتنلیک په ګیټ ذخیره کې چارټونه.

موږ د ټولو پراختیا کونکو سره خبرې کړې، نو د مهاجرت پروسه لا دمخه پیل شوې ده. لومړی مرحله لاهم د CI پلیټ فارم په کارولو سره کنټرول کیږي. زه به ډیر ژر د دوهم مرحلې په اړه بل پوسټ ولیکم: څنګه موږ د GitOps کاري فلو ته لاړ بهيږي. زه به تاسو ته ووایم چې موږ هر څه څنګه تنظیم کړل او له کومو ستونزو سره مخ شو (ډیری ذخیره، رازونه، او نور). خبرونه تعقیب کړئ.

دلته موږ هڅه کړې چې په تیرو کلونو کې د غوښتنلیک ګمارنې کاري فلو کې زموږ پرمختګ تشریح کړو ، کوم چې د GitOps چلند په اړه فکرونو لامل شوی. موږ تراوسه هدف ته نه یو رسیدلي او د پایلو په اړه به راپور ورکوو، مګر اوس موږ ډاډه یو چې موږ سم کار کړی کله چې موږ پریکړه وکړه چې هرڅه ساده کړو او د پراختیا کونکو عادتونو ته نږدې کړو.

سرچینه: www.habr.com