🥇 ہیلم کے ساتھ متعدد Kubernetes کلسٹرز میں ایپلی کیشنز کی تعیناتی

ڈیلی موشن کبرنیٹس کو کس طرح استعمال کرتا ہے: ایپلیکیشن کی تعیناتی۔

ڈیلی موشن میں ہم نے 3 سال پہلے پروڈکشن میں کبرنیٹس کا استعمال شروع کیا۔ لیکن متعدد کلسٹرز میں ایپلیکیشنز کو تعینات کرنا مزہ آتا ہے، اس لیے پچھلے کچھ سالوں سے ہم اپنے ٹولز اور ورک فلو کو بہتر بنانے کی کوشش کر رہے ہیں۔

کہاں سے شروع ہوا۔

یہاں ہم اس بات کا احاطہ کریں گے کہ ہم اپنی ایپلی کیشنز کو دنیا بھر کے متعدد کبرنیٹس کلسٹرز میں کیسے تعینات کرتے ہیں۔

ایک ساتھ متعدد کبرنیٹس اشیاء کو تعینات کرنے کے لیے، ہم استعمال کرتے ہیں۔ پتوار، اور ہمارے تمام چارٹس ایک گٹ ریپوزٹری میں محفوظ ہیں۔ متعدد خدمات سے مکمل ایپلیکیشن اسٹیک لگانے کے لیے، ہم نام نہاد سمری چارٹ استعمال کرتے ہیں۔ بنیادی طور پر، یہ ایک چارٹ ہے جو انحصار کا اعلان کرتا ہے اور آپ کو API اور اس کی خدمات کو ایک کمانڈ کے ساتھ شروع کرنے کی اجازت دیتا ہے۔

ہم نے چیک کرنے، چارٹ بنانے، راز شامل کرنے، اور ایپلیکیشنز کو تعینات کرنے کے لیے ہیلم کے اوپر ایک چھوٹا ازگر کا اسکرپٹ بھی لکھا۔ یہ تمام کام مرکزی CI پلیٹ فارم پر ڈاکر امیج کا استعمال کرتے ہوئے انجام پاتے ہیں۔

آئیے بات کی طرف آتے ہیں۔

نوٹ. جیسا کہ آپ یہ پڑھ رہے ہیں، ہیلم 3 کے لیے پہلے ریلیز امیدوار کا اعلان ہو چکا ہے۔ مرکزی ورژن میں ماضی میں جن مسائل کا سامنا ہوا ہے ان میں سے کچھ کو حل کرنے کے لیے بہت ساری اصلاحات شامل ہیں۔

چارٹ ڈویلپمنٹ ورک فلو

ہم ایپلی کیشنز کے لیے برانچنگ کا استعمال کرتے ہیں، اور ہم نے چارٹس پر بھی اسی طریقہ کار کو لاگو کرنے کا فیصلہ کیا۔

شاخ دیو چارٹس بنانے کے لیے استعمال کیا جاتا ہے جن کی جانچ ترقیاتی کلسٹرز پر کی جائے گی۔
جب پل کی درخواست جمع کرائی جاتی ہے۔ ماسٹر، وہ اسٹیجنگ میں چیک کیے جاتے ہیں۔
آخر میں، ہم برانچ میں تبدیلیوں کا ارتکاب کرنے کے لیے ایک پل کی درخواست بناتے ہیں۔ پرو اور انہیں پیداوار میں لاگو کریں.

ہر ماحول کا اپنا ذاتی ذخیرہ ہوتا ہے جو ہمارے چارٹس کو ذخیرہ کرتا ہے، اور ہم استعمال کرتے ہیں۔ چارٹ میوزیم بہت مفید APIs کے ساتھ۔ اس طرح ہم ماحول اور چارٹس کو پیداوار میں استعمال کرنے سے پہلے ان کی حقیقی دنیا کی جانچ کے درمیان سخت تنہائی کو یقینی بناتے ہیں۔

مختلف ماحول میں چارٹ کے ذخیرے

یہ بات قابل غور ہے کہ جب ڈویلپرز ڈیو برانچ کو آگے بڑھاتے ہیں، تو ان کے چارٹ کا ایک ورژن خود بخود ڈیو چارٹ میوزیم میں بھیج دیا جاتا ہے۔ اس طرح، تمام ڈویلپرز ایک ہی ڈیو ریپوزٹری کا استعمال کرتے ہیں، اور آپ کو چارٹ کے اپنے ورژن کی احتیاط سے وضاحت کرنے کی ضرورت ہے تاکہ غلطی سے کسی اور کی تبدیلیوں کو استعمال نہ کریں۔

مزید برآں، ہماری چھوٹی Python اسکرپٹ Kubernetes اشیاء کو Kubernetes OpenAPI تصریحات کے خلاف توثیق کرتی ہے۔ کوبیوالچارٹ میوزیم پر شائع کرنے سے پہلے۔

چارٹ ڈویلپمنٹ ورک فلو کی عمومی وضاحت

تفصیلات کے مطابق پائپ لائن کے کاموں کو ترتیب دینا gazr.io کوالٹی کنٹرول کے لیے (لنٹ، یونٹ ٹیسٹ)۔
Python ٹولز کے ساتھ ایک ڈاکر امیج کو آگے بڑھانا جو ہماری ایپلیکیشنز کو تعینات کرتے ہیں۔
برانچ کے نام سے ماحول کو ترتیب دینا۔
Kubeval کا استعمال کرتے ہوئے Kubernetes yaml فائلوں کی توثیق کرنا۔
خودکار طور پر چارٹ اور اس کے پیرنٹ چارٹس کے ورژن میں اضافہ کریں (چارٹس جو تبدیل کیے جانے والے چارٹ پر منحصر ہیں)۔
چارٹ میوزیم میں چارٹ جمع کرنا جو اس کے ماحول سے میل کھاتا ہے۔

کلسٹرز میں فرق کا انتظام کرنا

فیڈریشن آف کلسٹرز

ایک وقت تھا جب ہم استعمال کرتے تھے۔ فیڈریشن آف کبرنیٹس کلسٹرز، جہاں کبرنیٹس آبجیکٹ کا اعلان ایک ہی API اینڈ پوائنٹ سے کیا جا سکتا ہے۔ لیکن مسائل پیدا ہوئے۔ مثال کے طور پر، فیڈریشن اینڈ پوائنٹ میں کچھ Kubernetes آبجیکٹس کو تخلیق نہیں کیا جا سکا، جس سے انفرادی کلسٹرز کے لیے فیڈریٹڈ آبجیکٹ اور دیگر اشیاء کو برقرار رکھنا مشکل ہو جاتا ہے۔

مسئلہ کو حل کرنے کے لیے، ہم نے آزادانہ طور پر کلسٹرز کو منظم کرنا شروع کیا، جس نے اس عمل کو بہت آسان بنا دیا (ہم نے فیڈریشن کا پہلا ورژن استعمال کیا؛ دوسرے میں کچھ تبدیل ہو سکتا ہے)۔

جیو سے تقسیم شدہ پلیٹ فارم

ہمارا پلیٹ فارم فی الحال 6 علاقوں میں تقسیم کیا گیا ہے - 3 مقامی طور پر اور 3 کلاؤڈ میں۔

تقسیم شدہ تعیناتی۔

عالمی ہیلم اقدار

4 عالمی ہیلم اقدار آپ کو کلسٹرز کے درمیان فرق کی شناخت کرنے کی اجازت دیتی ہیں۔ ہمارے تمام چارٹس کی ڈیفالٹ کم از کم اقدار ہیں۔

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

عالمی اقدار

یہ اقدار ہماری ایپلی کیشنز کے سیاق و سباق کی وضاحت میں مدد کرتی ہیں اور مختلف مقاصد کے لیے استعمال ہوتی ہیں: نگرانی، ٹریسنگ، لاگنگ، بیرونی کالز کرنا، اسکیلنگ وغیرہ۔

"Cloud": ہمارے پاس ایک ہائبرڈ Kubernetes پلیٹ فارم ہے۔ مثال کے طور پر، ہمارا API GCP زونز اور ہمارے ڈیٹا سینٹرز میں تعینات ہے۔
"env": کچھ قدریں غیر پیداواری ماحول کے لیے تبدیل ہو سکتی ہیں۔ مثال کے طور پر، وسائل کی تعریفیں اور آٹو اسکیلنگ کنفیگریشنز۔
"علاقہ": یہ معلومات کلسٹر کے مقام کا تعین کرنے میں مدد کرتی ہے اور بیرونی خدمات کے لیے قریبی اختتامی مقامات کا تعین کرنے کے لیے استعمال کی جا سکتی ہے۔
"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

سروس کی تعریف

یہ ان تمام اقدامات کا خاکہ ہے جو ہمارے تعیناتی ورک فلو کی وضاحت کرتے ہیں۔ آخری مرحلہ ایپلیکیشن کو بیک وقت متعدد ورکرز کلسٹرز میں تعینات کرتا ہے۔

جینکنز کی تعیناتی کے اقدامات

رازوں کے بارے میں کیا؟

سیکورٹی کے حوالے سے، ہم مختلف جگہوں سے تمام رازوں کو ٹریک کرتے ہیں اور انہیں ایک منفرد والٹ میں محفوظ کرتے ہیں۔ والٹ پیرس میں.

ہمارے تعیناتی ٹولز Vault سے خفیہ قدریں نکالتے ہیں اور جب تعیناتی کا وقت آتا ہے تو انہیں ہیلم میں داخل کر دیتے ہیں۔

ایسا کرنے کے لیے، ہم نے والٹ میں موجود رازوں اور ہماری ایپلی کیشنز کو درکار رازوں کے درمیان نقشہ سازی کی وضاحت کی:

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 گٹ ریپوزٹریز کا مطلب ہے 2 ورک فلوز، اور نوزائیدہ کے لیے الجھن میں پڑنا آسان ہے۔

عام چارٹس کا انتظام کرنا ایک پریشانی ہے۔

جیسا کہ ہم پہلے ہی کہہ چکے ہیں، عام چارٹ انحصار کی شناخت اور متعدد ایپلی کیشنز کو تیزی سے تعینات کرنے کے لیے بہت مفید ہیں۔ لیکن ہم استعمال کرتے ہیں۔ --reuse-valuesہر بار جب بھی ہم کوئی ایسی ایپلیکیشن لگاتے ہیں جو اس عمومی چارٹ کا حصہ ہو تمام اقدار کو پاس کرنے سے بچنے کے لیے۔

مسلسل ڈیلیوری ورک فلو میں، ہمارے پاس صرف دو اقدار ہیں جو باقاعدگی سے تبدیل ہوتی ہیں: نقل کی تعداد اور تصویری ٹیگ (ورژن)۔ دیگر، زیادہ مستحکم اقدار کو دستی طور پر تبدیل کیا جاتا ہے، اور یہ کافی مشکل ہے۔ مزید برآں، ایک عمومی چارٹ لگانے میں ایک غلطی سنگین ناکامیوں کا باعث بن سکتی ہے، جیسا کہ ہم نے اپنے تجربے سے دیکھا ہے۔

متعدد کنفیگریشن فائلوں کو اپ ڈیٹ کرنا

جب ایک ڈویلپر کوئی نئی ایپلیکیشن شامل کرتا ہے، تو اسے کئی فائلیں تبدیل کرنی پڑتی ہیں: ایپلیکیشن ڈیکلریشن، رازوں کی فہرست، ایپلیکیشن کو انحصار کے طور پر شامل کرنا اگر یہ عام چارٹ میں شامل ہو۔

والٹ میں جینکنز کی اجازتوں کو بہت بڑھا دیا گیا ہے۔

اب ہمارے پاس ایک ہے۔ ایپ رول، جو والٹ سے تمام راز پڑھتا ہے۔

رول بیک عمل خودکار نہیں ہے۔

رول بیک کرنے کے لیے، آپ کو کئی کلسٹرز پر کمانڈ چلانے کی ضرورت ہے، اور یہ غلطیوں سے بھرا ہوا ہے۔ ہم اس آپریشن کو دستی طور پر انجام دیتے ہیں تاکہ یہ یقینی بنایا جا سکے کہ درست ورژن ID کی وضاحت کی گئی ہے۔

ہم GitOps کی طرف بڑھ رہے ہیں۔

ہمارا مقصد

ہم چارٹ کو اس ایپلی کیشن کے ریپوزٹری میں واپس کرنا چاہتے ہیں جسے یہ تعینات کرتا ہے۔

ورک فلو وہی ہو گا جو ترقی کے لیے ہو گا۔ مثال کے طور پر، جب کسی شاخ کو ماسٹر کی طرف دھکیل دیا جاتا ہے، تو تعیناتی خود بخود شروع ہو جائے گی۔ اس نقطہ نظر اور موجودہ ورک فلو کے درمیان بنیادی فرق یہ ہوگا۔ سب کچھ گٹ میں منظم کیا جائے گا (خود ایپلیکیشن اور جس طرح سے اسے Kubernetes میں تعینات کیا گیا ہے)۔

کئی فائدے ہیں:

بہت واضح ڈویلپر کے لئے. مقامی چارٹ میں تبدیلیوں کو لاگو کرنے کا طریقہ سیکھنا آسان ہے۔
سروس کی تعیناتی کی تعریف بیان کی جا سکتی ہے۔ کوڈ کے طور پر ایک ہی جگہ سروس
عام چارٹس کو ہٹانے کا انتظام کرنا. سروس کا اپنا ہیلم ریلیز ہوگا۔ یہ آپ کو سب سے چھوٹی سطح پر ایپلیکیشن لائف سائیکل (رول بیک، اپ گریڈ) کا انتظام کرنے کی اجازت دے گا، تاکہ دوسری خدمات متاثر نہ ہوں۔
گٹ کے فوائد چارٹ کے انتظام کے لیے: تبدیلیوں کو کالعدم کریں، آڈٹ لاگ وغیرہ۔ اگر آپ کو کسی چارٹ میں تبدیلی کو کالعدم کرنے کی ضرورت ہے، تو آپ یہ گٹ کا استعمال کر سکتے ہیں۔ تعیناتی خود بخود شروع ہوتی ہے۔
آپ اپنے ترقیاتی کام کے فلو کو بہتر بنانے پر غور کر سکتے ہیں جیسے ٹولز سکافولڈ، جس کے ساتھ ڈویلپر پیداوار کے قریب سیاق و سباق میں تبدیلیوں کی جانچ کر سکتے ہیں۔

دو قدمی ہجرت

ہمارے ڈویلپرز اس ورک فلو کو اب 2 سالوں سے استعمال کر رہے ہیں، لہذا ہم چاہتے ہیں کہ منتقلی زیادہ سے زیادہ تکلیف دہ ہو۔ لہذا، ہم نے مقصد کے راستے پر ایک درمیانی قدم شامل کرنے کا فیصلہ کیا۔
پہلا مرحلہ آسان ہے:

ہم ایپلیکیشن کی تعیناتی کے لیے ایک جیسا ڈھانچہ رکھتے ہیں، لیکن ڈیلی موشن ریلیز نامی ایک شے میں۔

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

ہیلم کے ساتھ متعدد Kubernetes کلسٹرز میں ایپلی کیشنز کو تعینات کریں۔