کسٹمائز کا مختصر تعارف

نوٹ. ترجمہ: یہ مضمون IT میں وسیع تجربہ رکھنے والے انجینئر سکاٹ لو نے لکھا تھا، جو سات چھپی ہوئی کتابوں کے مصنف/شریک مصنف ہیں (بنیادی طور پر VMware vSphere پر)۔ اب وہ اس کے VMware کے ذیلی ادارے Heptio (2016 میں حاصل کیا گیا) کے لیے کام کرتا ہے، جو کلاؤڈ کمپیوٹنگ اور Kubernetes میں مہارت رکھتا ہے۔ متن بذات خود ٹیکنالوجی کا استعمال کرتے ہوئے Kubernetes کے کنفیگریشن مینجمنٹ کے لیے ایک مختصر اور سمجھنے میں آسان تعارف کے طور پر کام کرتا ہے۔ حسب ضرورت بنائیں، جو حال ہی میں K8s کا حصہ بن گیا ہے۔

کسٹمائز ایک ایسا ٹول ہے جو صارفین کو "مختلف مقاصد کے لیے سادہ، ٹیمپلیٹ سے پاک YAML فائلوں کو اپنی مرضی کے مطابق بنانے کی اجازت دیتا ہے، اصل YAML کو برقرار اور قابل استعمال چھوڑ کر" (تفصیل براہ راست اس سے مستعار لی گئی ہے۔ GitHub پر ذخیرہ کو کسٹمائز کریں۔)۔ کسٹمائز کو براہ راست چلایا جا سکتا ہے یا، Kubernetes 1.14 کے مطابق، استعمال کیا جا سکتا ہے۔ kubectl -k اس کی فعالیت تک رسائی حاصل کرنے کے لیے (اگرچہ Kubernetes 1.15 کے مطابق، علیحدہ بائنری kubectl میں بنائی گئی صلاحیتوں سے نئی ہے)۔ (نوٹ. ترجمہ: اور حالیہ ریلیز کے ساتھ کبرنیٹس 1.16 اپنی مرضی کے مطابق بنائیں کی طرف سے حمایت kubeadm افادیت میں بھی۔) اس پوسٹ میں، میں قارئین کو کسٹمائز کی بنیادی باتوں سے متعارف کرانا چاہتا ہوں۔

اپنی آسان ترین شکل/ایپلی کیشن میں، kustomize محض وسائل کا مجموعہ ہے (YAML فائلیں جو Kubernetes آبجیکٹ کی وضاحت کرتی ہیں: تعیناتیاں، خدمات وغیرہ) اور ان تبدیلیوں کے لیے ہدایات کی فہرست جو ان وسائل میں کرنے کی ضرورت ہے۔ بالکل اسی طرح جیسے میک میں موجود انسٹرکشن سیٹ کا استعمال ہوتا ہے۔ Makefile، اور Docker کی ہدایات کی بنیاد پر کنٹینر بناتا ہے۔ Dockerfile، استعمال کو اپنی مرضی کے مطابق بنائیں kustomization.yaml اس بارے میں ہدایات کو ذخیرہ کرنے کے لیے کہ صارف وسائل کے سیٹ میں کیا تبدیلیاں لانا چاہتا ہے۔

یہاں ایک مثال فائل ہے۔ kustomization.yaml:

resources:
- deployment.yaml
- service.yaml
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

میں فائل میں موجود تمام ممکنہ فیلڈز کے بارے میں بات کرنے کی کوشش نہیں کروں گا۔ kustomization.yaml (اس کے بارے میں اچھی طرح سے لکھا گیا ہے۔ یہاں)، لیکن میں ایک مخصوص مثال کی مختصر وضاحت کروں گا:

• فیلڈ resources اس بات کی نشاندہی کرتا ہے کہ کیا (کون سے وسائل) کسٹمائز تبدیل ہوگا۔ اس صورت میں، یہ فائلوں میں وسائل تلاش کرے گا۔ deployment.yaml и service.yaml آپ کی ڈائرکٹری میں (اگر ضروری ہو تو آپ مکمل یا متعلقہ راستے بتا سکتے ہیں)۔
• فیلڈ namePrefix کسٹمائز کو ایک مخصوص سابقہ ​​شامل کرنے کی ہدایت کرتا ہے (اس معاملے میں - dev-) منسوب کرنا name میدان میں بیان کردہ تمام وسائل resources. اس طرح، اگر تعیناتی ہے name معنی کے ساتھ nginx-deployment، اپنی مرضی کے مطابق بنائیں گے۔ dev-nginx-deployment.
• فیلڈ namespace کسٹمائز کو تمام وسائل میں دی گئی نام کی جگہ شامل کرنے کی ہدایت کرتا ہے۔ اس صورت میں، تعیناتی اور سروس نام کی جگہ میں آجائے گی۔ development.
• آخر میں، میدان commonLabels لیبلز کا ایک سیٹ ہے جو تمام وسائل میں شامل کیا جائے گا۔ ہماری مثال میں، کسٹمائز نام کے ساتھ وسائل کو ایک لیبل تفویض کرے گا۔ environment اور معنی development.

اگر صارف کرتا ہے۔ kustomize build . فائل کے ساتھ ڈائریکٹری میں kustomization.yaml اور ضروری وسائل (یعنی فائلیں deployment.yaml и service.yaml)، پھر آؤٹ پٹ پر اس میں بیان کردہ تبدیلیوں کے ساتھ ایک متن موصول ہوگا۔ kustomization.yaml.

نوٹ. ترجمہ: کسٹمائز کے "سادہ" استعمال پر پروجیکٹ دستاویزات سے مثال

اگر تبدیلیاں کرنے کی ضرورت ہو تو آؤٹ پٹ کو ری ڈائریکٹ کیا جا سکتا ہے:

kustomize build . > custom-config.yaml

آؤٹ پٹ ڈیٹا تعییناتی ہے (ایک ہی ان پٹ ڈیٹا ایک ہی آؤٹ پٹ کے نتائج پیدا کرے گا)، لہذا آپ کو نتیجہ کو فائل میں محفوظ کرنے کی ضرورت نہیں ہے۔ اس کے بجائے، اسے براہ راست کسی اور کمانڈ پر منتقل کیا جا سکتا ہے:

kustomize build . | kubectl apply -f -

کسٹمائز فیچرز کے ذریعے بھی رسائی حاصل کی جاسکتی ہے۔ kubectl -k (کوبرنیٹس ورژن 1.14 کے بعد سے)۔ تاہم، اس بات کو ذہن میں رکھیں کہ اسٹینڈ الون kustomize پیکیج کو مربوط kubectl پیکیج سے زیادہ تیزی سے اپ ڈیٹ کیا جاتا ہے (کم از کم یہی معاملہ Kubernetes 1.15 ریلیز کا ہے)۔

قارئین پوچھ سکتے ہیں: "اگر آپ فائلوں میں براہ راست ترمیم کر سکتے ہیں تو یہ ساری پیچیدگی کیوں؟" زبردست سوال۔ ہماری مثال میں، واقعی ایک کر سکتے ہیں فائلوں میں ترمیم کریں deployment.yaml и service.yaml براہ راست، لیکن اگر وہ کسی اور کے پروجیکٹ کا کانٹا ہیں تو کیا ہوگا؟ فائلوں کو براہ راست تبدیل کرنا جب اصل/ذریعہ میں تبدیلیاں کی جاتی ہیں تو کانٹے کو بحال کرنا مشکل (اگر ناممکن نہیں تو) بنا دیتا ہے۔ کسٹمائز کا استعمال آپ کو فائل میں ان تبدیلیوں کو سنٹرلائز کرنے کی اجازت دیتا ہے۔ kustomization.yaml، اصل فائلوں کو برقرار رکھنا اور اس طرح اگر ضروری ہو تو اصل فائلوں کو دوبارہ ترتیب دینا آسان بناتا ہے۔

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

اوورلیز اور بنیادی وسائل کے خیال کو واضح کرنے کے لیے (بنیادی وسائل)، آئیے فرض کریں کہ ڈائریکٹریوں میں درج ذیل ڈھانچہ ہے:

- base
  - deployment.yaml
  - service.yaml
  - kustomization.yaml
- overlays
  - dev
    - kustomization.yaml
  - staging
    - kustomization.yaml
  - prod
    - kustomization.yaml

فائل میں base/kustomization.yaml فیلڈ استعمال کرنے والے صارفین resources صرف ان وسائل کا اعلان کریں جن میں کسٹمائز کو شامل ہونا چاہیے۔

فائلوں میں سے ہر ایک میں overlays/{dev,staging,prod}/kustomization.yaml صارفین فیلڈ میں بیس کنفیگریشن کا حوالہ دیتے ہیں۔ resources، اور پھر کے لیے مخصوص تبدیلیوں کی نشاندہی کریں۔ دیا ہوا ماحول. مثال کے طور پر، فائل overlays/dev/kustomization.yaml پہلے دی گئی مثال کی طرح نظر آسکتا ہے:

resources:
- ../../base
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

اس معاملے میں فائل overlays/prod/kustomization.yaml بالکل مختلف ہو سکتا ہے:

resources:
- ../../base
namePrefix: prod-
namespace: production
commonLabels:
  environment: production
  sre-team: blue

جب صارف چلتا ہے۔ kustomize build . کیٹلاگ میں overlays/dev، کسٹمائز ڈویلپمنٹ آپشن تیار کرے گا۔ اگر آپ بھاگتے ہیں۔ kustomize build . کیٹلاگ میں overlays/prod - آپ کو پروڈکشن کا آپشن ملتا ہے۔ اور یہ سب - اصل میں کوئی تبدیلی کیے بغیر (بنیاد) فائلیں، سب ایک اعلانیہ اور عزمی انداز میں۔ آپ بیس کنفیگریشن اور اوورلے ڈائرکٹریز کو براہ راست ورژن کنٹرول میں بھیج سکتے ہیں، یہ جانتے ہوئے کہ ان فائلوں کی بنیاد پر آپ کسی بھی وقت مطلوبہ کنفیگریشن دوبارہ تیار کر سکتے ہیں۔

نوٹ. ترجمہ: کسٹمائز میں اوورلیز کے استعمال پر پراجیکٹ دستاویزات سے مثال

اپنی مرضی کے مطابق کر سکتے ہیں زیادہ اس مضمون میں جو کچھ بتایا گیا ہے اس سے زیادہ۔ تاہم، مجھے امید ہے کہ یہ ایک اچھا تعارف کے طور پر کام کرتا ہے.

ые ы

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

• کسٹمائز کا استعمال کرتے ہوئے مختلف ماحول کے پروڈ/ٹیسٹ کے لیے بیس YAML کنفیگریشن کو تبدیل کریں۔;
• کسٹمائز — کوبرنیٹس میں ٹیمپلیٹنگ کرنے کا صحیح طریقہ;
• اپنی مرضی کے مطابق استعمال کرتے ہوئے Kubernetes آبجیکٹ کا اعلانیہ انتظام;
• اپنی مرضی کے مطابق اپ اسٹریم ہیلم چارٹس کو حسب ضرورت بنانا.

نوٹ. ترجمہ: آپ بطور شائع شدہ لنکس کے بلاک کی بھی سفارش کر سکتے ہیں۔ وسائل یوٹیلیٹی کی ویب سائٹ پر، اس کے بعد kustomize کے بارے میں تازہ ترین رپورٹس کے ساتھ ویڈیوز کا مجموعہ۔

اگر آپ کے پاس اس مواد کو بہتر بنانے کے لیے سوالات یا مشورے ہیں، تو میں فیڈ بیک کے لیے ہمیشہ کھلا ہوں۔ آپ مجھ سے اس پر رابطہ کر سکتے ہیں۔ ٹویٹر یا کبرنیٹس سلیک چینل. کسٹمائز کے ساتھ اپنے مینی فیسٹس میں ترمیم کرنے کا لطف اٹھائیں!

مترجم سے PS

ہمارے بلاگ پر بھی پڑھیں:

• «Kubernetes پر چلنے والی ایپلیکیشنز کے ڈویلپرز کے لیے ٹولز؛ "
• «Kubernetes 1.14: اہم اختراعات کا جائزہ؛ "
• «ایمسٹرڈیم میں ہیلم سمٹ 2019 کے پانچ اہم نتائج؛ "
• «Kubernetes - Helm کے لیے پیکیج مینیجر کا عملی تعارف'.

ماخذ: www.habr.com