کتاب "Kubernetes for DevOps"

ہیلو، خبر کے رہنے والوں! Kubernetes جدید کلاؤڈ ماحولیاتی نظام کے اہم عناصر میں سے ایک ہے۔ یہ ٹکنالوجی کنٹینر ورچوئلائزیشن کو قابل اعتماد، توسیع پذیری اور لچک فراہم کرتی ہے۔ John Arundel اور Justin Domingus Kubernetes ایکو سسٹم کے بارے میں بات کرتے ہیں اور روزمرہ کے مسائل کے ثابت شدہ حل پیش کرتے ہیں۔ قدم بہ قدم، آپ اپنی کلاؤڈ-آبائی ایپلی کیشن بنائیں گے اور اسے سپورٹ کرنے کے لیے انفراسٹرکچر بنائیں گے، ایک ترقیاتی ماحول اور ایک مسلسل تعیناتی پائپ لائن ترتیب دیں گے جو آپ کی اگلی ایپلیکیشنز پر کام کرتے وقت آپ کی مدد کرے گی۔

• بنیادی باتوں سے کنٹینرز اور Kubernetes کے ساتھ شروع کریں: موضوع کو سیکھنے کے لیے کسی خاص تجربے کی ضرورت نہیں ہے۔ • اپنے کلسٹرز چلائیں یا Amazon، Google، وغیرہ سے ایک منظم Kubernetes سروس کا انتخاب کریں۔ • کنٹینر لائف سائیکل اور وسائل کی کھپت کا انتظام کرنے کے لیے Kubernetes کا استعمال کریں۔ • لاگت، کارکردگی، لچک، طاقت اور توسیع پذیری کی بنیاد پر کلسٹرز کو بہتر بنائیں۔ • اپنی ایپلیکیشنز کو تیار کرنے، جانچنے اور ان کی تعیناتی کے لیے بہترین ٹولز سیکھیں۔ • سیکورٹی اور کنٹرول کو یقینی بنانے کے لیے صنعت کے موجودہ طریقوں سے فائدہ اٹھائیں۔ • اپنی پوری کمپنی میں DevOps اصولوں کو لاگو کریں تاکہ ترقیاتی ٹیمیں زیادہ لچکدار، جلدی اور مؤثر طریقے سے کام کر سکیں۔

کتاب کس کے لیے ہے؟

یہ کتاب سرورز، ایپلیکیشنز اور خدمات کے ذمہ دار انتظامیہ کے محکموں کے ملازمین کے ساتھ ساتھ نئی کلاؤڈ سروسز بنانے یا موجودہ ایپلی کیشنز کو Kubernetes اور کلاؤڈ میں منتقل کرنے میں ملوث ڈویلپرز کے لیے سب سے زیادہ متعلقہ ہے۔ پریشان نہ ہوں، آپ کو یہ جاننے کی ضرورت نہیں ہے کہ Kubernetes یا کنٹینرز کے ساتھ کیسے کام کرنا ہے - ہم آپ کو سب کچھ سکھائیں گے۔

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

کتاب کن سوالوں کے جواب دیتی ہے؟

کتاب کی منصوبہ بندی اور تحریر کے دوران، ہم نے سینکڑوں لوگوں کے ساتھ کلاؤڈ ٹکنالوجی اور Kubernetes پر تبادلہ خیال کیا، صنعت کے رہنماؤں اور ماہرین کے ساتھ ساتھ مکمل نووائسز سے بات کی۔ ذیل میں منتخب سوالات ہیں جن کے جواب وہ اس اشاعت میں دیکھنا چاہیں گے۔

• "مجھے اس بات میں دلچسپی ہے کہ آپ کو اس ٹیکنالوجی پر وقت کیوں گزارنا چاہیے۔ اس سے مجھے اور میری ٹیم کو کن مسائل کو حل کرنے میں مدد ملے گی؟"
• "Kubernetes دلچسپ لگتا ہے، لیکن داخلے میں کافی حد تک رکاوٹ ہے۔ ایک سادہ مثال تیار کرنا مشکل نہیں ہے، لیکن مزید انتظامیہ اور ڈیبگنگ مشکل ہے۔ ہم اس بارے میں قابل اعتماد مشورہ حاصل کرنا چاہیں گے کہ لوگ حقیقی دنیا میں کبرنیٹس کلسٹرز کو کس طرح منظم کرتے ہیں اور ہمیں کن مسائل کا سامنا کرنا پڑ سکتا ہے۔"
• "مضموناتی مشورہ مددگار ثابت ہوگا۔ Kubernetes ماحولیاتی نظام نئی ٹیموں کو انتخاب کرنے کے لیے بہت زیادہ اختیارات دیتا ہے۔ جب ایک ہی کام کرنے کے کئی طریقے ہیں، تو آپ کیسے جانتے ہیں کہ کون سا بہترین ہے؟ انتخاب کیسے کریں؟

اور شاید تمام سوالات میں سب سے اہم:

• "میں اپنی کمپنی میں خلل ڈالے بغیر کبرنیٹس کا استعمال کیسے کر سکتا ہوں؟"

اقتباس۔ کنفیگریشن اور خفیہ اشیاء

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

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

Kubernetes ترتیب کو منظم کرنے کے کئی مختلف طریقے فراہم کرتا ہے۔ سب سے پہلے، آپ پوڈ ریپر تصریح میں بیان کردہ ماحولیاتی متغیرات کے ذریعے ایپلی کیشن کو اقدار منتقل کر سکتے ہیں (صفحہ 192 پر "ماحولیاتی متغیرات" دیکھیں)۔ دوسرا، کنفیگریشن ڈیٹا کو کنفیگ میپ اور سیکرٹ آبجیکٹ کا استعمال کرتے ہوئے براہ راست Kubernetes میں محفوظ کیا جا سکتا ہے۔

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

جب ترتیب میں تبدیلی آتی ہے تو پوڈ شیل کو اپ ڈیٹ کرنا

تصور کریں کہ آپ کے کلسٹر میں ایک تعیناتی ہے اور آپ اس کے ConfigMap میں کچھ اقدار کو تبدیل کرنا چاہتے ہیں۔ اگر آپ ہیلم چارٹ استعمال کرتے ہیں (صفحہ 102 پر "Helm: Package Manager for Kubernetes" دیکھیں)، آپ خود بخود کنفیگریشن کی تبدیلی کا پتہ لگا سکتے ہیں اور ایک صاف چال میں اپنے پوڈ شیل کو دوبارہ لوڈ کر سکتے ہیں۔ اپنی تعیناتی کی تفصیلات میں درج ذیل تشریح شامل کریں:

checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") .
       | sha256sum }}

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

Kubernetes میں حساس ڈیٹا

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

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

شروع کرنے کے لیے، خفیہ آبجیکٹ کے لیے Kubernetes مینی فیسٹ پر ایک نظر ڈالیں (دیکھیں hello-secret-env/k8s/secret.yaml):

apiVersion: v1
kind: Secret
metadata:
    name: demo-secret
stringData:
    magicWord: xyzzy

اس مثال میں، magicWord کی نجی کلید xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)) ہے۔ لفظ xyzzy عام طور پر کمپیوٹر کی دنیا میں بہت مفید ہے۔ ConfigMap کی طرح، آپ ایک سیکرٹ آبجیکٹ میں ایک سے زیادہ کلیدیں اور اقدار محفوظ کر سکتے ہیں۔ یہاں، سادگی کے لیے، ہم صرف ایک کلیدی قدر کا جوڑا استعمال کرتے ہیں۔

خفیہ اشیاء کو ماحولیاتی متغیر کے طور پر استعمال کرنا

ConfigMap کی طرح، خفیہ آبجیکٹ کو کنٹینر میں ماحولیاتی متغیرات یا اس کی ڈسک پر فائل کے طور پر دستیاب کیا جا سکتا ہے۔ درج ذیل مثال میں، ہم سیکرٹ سے ویلیو کے لیے ایک ماحولیاتی متغیر تفویض کریں گے:

spec:
   containers:
       - name: demo
          image: cloudnatived/demo:hello-secret-env
          ports:
             - containerPort: 8888
          env:
             - name: GREETING
               valueFrom:
               secretKeyRef:
                  name: demo-secret
                  key: magicWord

مینی فیسٹ کو لاگو کرنے کے لیے ڈیمو ریپوزٹری میں درج ذیل کمانڈ کو چلائیں:

kubectl apply -f hello-secret-env/k8s/
deployment.extensions "demo" configured
secret "demo-secret" created

پہلے کی طرح، اپنے براؤزر میں نتیجہ دیکھنے کے لیے مقامی پورٹ کو تعیناتی پر بھیجیں:

kubectl port-forward deploy/demo 9999:8888
Forwarding from 127.0.0.1:9999 -> 8888
Forwarding from [::1]:9999 -> 8888

ایڈریس کھولتے وقت localhost:9999/ آپ کو درج ذیل دیکھنا چاہئے:

The magic word is "xyzzy"

فائلوں میں خفیہ آبجیکٹ لکھنا

اس مثال میں، ہم خفیہ آبجیکٹ کو کنٹینر سے بطور فائل منسلک کریں گے۔ کوڈ ڈیمو ریپوزٹری کے ہیلو سیکریٹ فائل فولڈر میں واقع ہے۔

سیکرٹ کو بطور فائل جوڑنے کے لیے، ہم درج ذیل تعیناتی کا استعمال کریں گے۔

spec:
   containers:
       - name: demo
          image: cloudnatived/demo:hello-secret-file
          ports:
              - containerPort: 8888
          volumeMounts:
              - name: demo-secret-volume
                mountPath: "/secrets/"
                readOnly: true
   volumes:
      - name: demo-secret-volume
        secret:
           secretName: demo-secret

جیسا کہ ذیلی سیکشن "ConfigMap آبجیکٹ سے کنفیگریشن فائلیں بنانا" p. 240، ہم ایک والیوم بناتے ہیں (اس معاملے میں ڈیمو سیکریٹ والیوم) اور اسے تصریح کے والیوم ماؤنٹس سیکشن میں کنٹینر پر لگا دیتے ہیں۔ mountPath فیلڈ /secrets ہے، لہذا Kubernetes اس فولڈر میں ہر ایک کلید/قدر کے جوڑے کے لیے ایک فائل بنائے گا جو خفیہ آبجیکٹ میں بیان کی گئی ہے۔

ہماری مثال میں، ہم نے صرف ایک کلیدی قدر کے جوڑے کی وضاحت کی ہے جسے magicWord کہتے ہیں، لہذا مینی فیسٹ کنٹینر میں موجود حساس ڈیٹا کے ساتھ ایک واحد پڑھنے والی فائل /secrets/magicWord بنائے گا۔

اگر آپ اس مینی فیسٹ کو پچھلی مثال کی طرح لاگو کرتے ہیں، تو آپ کو وہی نتیجہ ملنا چاہیے:

The magic word is "xyzzy"

خفیہ اشیاء پڑھنا

پچھلے حصے میں، ہم نے کنفیگ میپ کے مواد کو ظاہر کرنے کے لیے kubectl describe کمانڈ کا استعمال کیا۔ کیا سیکرٹ کے ساتھ بھی ایسا ہی کیا جا سکتا ہے؟

kubectl describe secret/demo-secret
Name:          demo-secret

Namespace:      default
Labels:             <none>
Annotations:
Type:               Opaque

Data
====
magicWord: 5   bytes

براہ کرم نوٹ کریں کہ ڈیٹا خود ظاہر نہیں ہوتا ہے۔ Kubernetes میں خفیہ اشیاء Opaque قسم کی ہوتی ہیں، جس کا مطلب ہے کہ ان کے مواد کو kubectl describe output، log entries، یا ٹرمینل میں نہیں دکھایا جاتا ہے، جس سے حساس معلومات کو حادثاتی طور پر ظاہر کرنا ناممکن ہو جاتا ہے۔

حساس ڈیٹا کا انکوڈ شدہ YAML ورژن دیکھنے کے لیے، kubectl get کمانڈ استعمال کریں:

kubectl get secret/demo-secret -o yaml
apiVersion: v1
data:
   magicWord: eHl6enk=
kind: Secret
metadata:
...
type: Opaque

بیس 64

eHl6enk= کیا ہے، ہماری اصل قدر سے بالکل مختلف؟ یہ دراصل ایک خفیہ آبجیکٹ ہے، جس کی نمائندگی بیس 64 انکوڈنگ میں کی گئی ہے۔ Base64 حروف کی ایک تار کے طور پر صوابدیدی بائنری ڈیٹا کو انکوڈنگ کرنے کی اسکیم ہے۔

کیونکہ حساس معلومات بائنری ہو سکتی ہیں نہ کہ آؤٹ پٹ (جیسا کہ TLS انکرپشن کلید کا معاملہ ہے)، خفیہ اشیاء کو ہمیشہ base64 فارمیٹ میں محفوظ کیا جاتا ہے۔

متن beHl6enk= ہمارے خفیہ لفظ xyzzy کا base64 انکوڈ شدہ ورژن ہے۔ آپ ٹرمینل میں base64 —decode کمانڈ چلا کر اس کی تصدیق کر سکتے ہیں۔

echo "eHl6enk=" | base64 --decode
xyzzy

لہذا، جب کہ Kubernetes آپ کو ٹرمینل یا لاگ فائلوں میں حساس ڈیٹا کو حادثاتی طور پر آؤٹ پٹ کرنے سے بچاتا ہے، اگر آپ نے کسی مخصوص نام کی جگہ میں خفیہ آبجیکٹ پر پڑھنے کی اجازتیں حاصل کی ہیں، تو اس ڈیٹا کو بیس 64 کیا جا سکتا ہے اور بعد میں ڈی کوڈ کیا جا سکتا ہے۔

اگر آپ کو بیس 64 کو کچھ متن کو انکوڈ کرنے کی ضرورت ہے (مثال کے طور پر، اسے خفیہ میں ڈالنے کے لیے)، بغیر دلائل کے base64 کمانڈ استعمال کریں:

echo xyzzy | base64
eHl6enkK

خفیہ اشیاء تک رسائی

کون خفیہ اشیاء کو پڑھ اور ترمیم کر سکتا ہے؟ اس کا تعین RBAC کے ذریعے کیا جاتا ہے، ایک رسائی کنٹرول میکانزم (ہم اس پر صفحہ 258 پر ذیلی سیکشن "رول بیسڈ ایکسیس کنٹرول کا تعارف" میں تفصیل سے بات کریں گے)۔ اگر آپ ایک ایسا کلسٹر چلا رہے ہیں جس میں RBAC نہیں ہے یا فعال نہیں ہے، تو آپ کی تمام خفیہ اشیاء کسی بھی صارف اور کنٹینرز کے لیے دستیاب ہیں (ہم بعد میں وضاحت کریں گے کہ آپ کے پاس RBAC کے بغیر کوئی پروڈکشن کلسٹر نہیں ہونا چاہیے)۔

غیر فعال ڈیٹا انکرپشن

ان لوگوں کے بارے میں کیا جو etcd ڈیٹا بیس تک رسائی رکھتے ہیں جہاں Kubernetes اپنی تمام معلومات محفوظ کرتا ہے؟ کیا وہ API کے ذریعے خفیہ اشیاء کو پڑھنے کی اجازت کے بغیر حساس ڈیٹا کو پڑھ سکتے ہیں؟

ورژن 1.7 کے بعد سے، Kubernetes غیر فعال ڈیٹا انکرپشن کو سپورٹ کرتا ہے۔ اس کا مطلب یہ ہے کہ etcd کے اندر حساس معلومات کو ڈسک پر خفیہ طور پر محفوظ کیا جاتا ہے اور ڈیٹا بیس تک براہ راست رسائی رکھنے والے بھی اسے نہیں پڑھ سکتے۔ اسے ڈکرپٹ کرنے کے لیے، آپ کو ایک کلید کی ضرورت ہے جو صرف Kubernetes API سرور کے پاس ہے۔ مناسب طریقے سے تشکیل شدہ کلسٹر میں، غیر فعال خفیہ کاری کو فعال کیا جانا چاہیے۔

آپ چیک کر سکتے ہیں کہ آیا غیر فعال خفیہ کاری آپ کے کلسٹر میں اس طرح کام کرتی ہے:

kubectl describe pod -n kube-system -l component=kube-apiserver |grep encryption
        --experimental-encryption-provider-config=...

اگر آپ کو تجرباتی-انکرپشن-provider-config پرچم نظر نہیں آتا ہے، تو غیر فعال خفیہ کاری فعال نہیں ہے۔ Google Kubernetes Engine یا دیگر Kubernetes مینجمنٹ سروسز کا استعمال کرتے وقت، آپ کا ڈیٹا ایک مختلف طریقہ کار کا استعمال کرتے ہوئے انکرپٹ کیا جاتا ہے، اس لیے پرچم موجود نہیں ہوگا۔ اپنے Kubernetes وینڈر سے یہ دیکھنے کے لیے چیک کریں کہ آیا etcd مواد کو انکرپٹ کیا گیا ہے۔

خفیہ ڈیٹا کو محفوظ کرنا

کچھ Kubernetes وسائل ہیں جنہیں کبھی بھی کلسٹر سے نہیں ہٹایا جانا چاہیے، جیسے کہ انتہائی حساس خفیہ اشیاء۔ آپ ہیلم مینیجر کی طرف سے فراہم کردہ تشریح کا استعمال کرتے ہوئے کسی وسائل کو حذف ہونے سے بچا سکتے ہیں:

kind: Secret
metadata:
    annotations:
        "helm.sh/resource-policy": keep

خفیہ آبجیکٹ مینجمنٹ کی حکمت عملی

پچھلے حصے کی مثال میں، حساس ڈیٹا کو کلسٹر میں محفوظ کرنے کے فوراً بعد غیر مجاز رسائی سے محفوظ کیا گیا تھا۔ لیکن مینی فیسٹ فائلوں میں وہ سادہ متن کے طور پر محفوظ تھے۔

آپ کو کبھی بھی ان فائلوں میں خفیہ معلومات نہیں رکھنی چاہئیں جو ورژن کنٹرول میں ہوں۔ آپ اپنے Kubernetes کلسٹر پر لاگو کرنے سے پہلے اس معلومات کو محفوظ طریقے سے کیسے منظم اور ذخیرہ کر سکتے ہیں؟

آپ اپنی ایپلی کیشنز میں حساس ڈیٹا کو ہینڈل کرنے کے لیے کسی بھی ٹولز یا حکمت عملی کا انتخاب کر سکتے ہیں، لیکن پھر بھی آپ کو کم از کم درج ذیل سوالات کے جوابات دینے کی ضرورت ہوگی۔

• حساس ڈیٹا کو کہاں ذخیرہ کیا جانا چاہئے تاکہ یہ انتہائی قابل رسائی ہو؟
• حساس ڈیٹا کو اپنی فعال ایپلی کیشنز تک کیسے قابل رسائی بنایا جائے؟
• جب آپ حساس ڈیٹا کو تبدیل یا ترمیم کرتے ہیں تو آپ کی ایپلیکیشنز کا کیا ہونا چاہیے؟

مصنفین کے بارے میں

جان ارنڈیل کمپیوٹر انڈسٹری میں 30 سال کا تجربہ رکھنے والا ایک مشیر ہے۔ اس نے متعدد کتابیں لکھی ہیں اور مختلف ممالک کی بہت سی کمپنیوں کے ساتھ کام کیا ہے، انہیں کلاؤڈ-نیٹیو انفراسٹرکچر اور کوبرنیٹس پر مشورہ دیا ہے۔ اپنے فارغ وقت میں، وہ سرفنگ سے لطف اندوز ہوتا ہے، ایک اچھا پستول شوٹر ہے، اور ایک شوقیہ کے طور پر پیانو بجاتا ہے۔ کارن وال، انگلینڈ میں ایک پریوں کی کہانی کاٹیج میں رہتا ہے۔

جسٹن ڈومینگس - سسٹم ایڈمنسٹریشن انجینئر کوبرنیٹس اور کلاؤڈ ٹیکنالوجیز کے ساتھ DevOps ماحول میں کام کر رہا ہے۔ وہ باہر وقت گزارنے، کافی پینے، کیکڑے کھانے اور کمپیوٹر پر بیٹھنے سے لطف اندوز ہوتا ہے۔ سیئٹل، واشنگٹن میں ایک شاندار بلی اور اس سے بھی زیادہ شاندار بیوی اور بہترین دوست ایڈرین کے ساتھ رہتی ہے۔

»کتاب کے بارے میں مزید تفصیلات یہاں پر دیکھی جا سکتی ہیں۔ پبلشر کی ویب سائٹ
» مواد کی میز
» اقتباس

Khabrozhiteley کے لیے کوپن کا استعمال کرتے ہوئے 25% ڈسکاؤنٹ - Kubernetes

کتاب کے کاغذی ورژن کی ادائیگی پر، ایک الیکٹرانک کتاب بذریعہ ای میل بھیجی جائے گی۔

ماخذ: www.habr.com