🥇 بہترین طریقوں اور پالیسیوں کے خلاف Kubernetes YAML کی توثیق کرنا

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

TL؛ ڈاکٹر: یہ مضمون بہترین طریقوں اور تقاضوں کے خلاف Kubernetes YAML فائلوں کی توثیق اور جانچ کرنے کے لیے چھ جامد ٹولز کا موازنہ کرتا ہے۔

Kubernetes کام کے بوجھ کو عام طور پر YAML دستاویزات کی شکل میں بیان کیا جاتا ہے۔ YAML کے ساتھ ایک مسئلہ مینی فیسٹ فائلوں کے درمیان رکاوٹوں یا تعلقات کی وضاحت کرنے میں دشواری ہے۔

کیا ہوگا اگر ہمیں یہ یقینی بنانا ہو کہ کلسٹر میں لگائی گئی تمام تصاویر قابل اعتماد رجسٹری سے آئیں؟

میں ان تعیناتیوں کو کیسے روک سکتا ہوں جن میں PodDisruptionBudgets نہیں ہیں کلسٹر کو بھیجے جانے سے؟

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

Kubernetes جامد YAML فائل معائنہ ماحولیاتی نظام کو درج ذیل زمروں میں تقسیم کیا جا سکتا ہے:

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

اس مضمون میں ہم چھ مختلف ٹولز کی وضاحت اور موازنہ کریں گے:

کوبیوال
کیوب سکور؛
config-lint؛
تانبے
مقابلہ
پولاریس۔

ٹھیک ہے، چلو شروع کرتے ہیں!

تعیناتیوں کی جانچ ہو رہی ہے۔

اس سے پہلے کہ ہم ٹولز کا موازنہ شروع کریں، آئیے کچھ پس منظر بنائیں جس پر ان کی جانچ کی جائے۔

نیچے دیئے گئے منشور میں بہت سی غلطیاں اور بہترین طریقوں کی عدم تعمیل ہے: آپ ان میں سے کتنی تلاش کر سکتے ہیں؟

apiVersion: apps/v1
kind: Deployment
metadata:
  name: http-echo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: http-echo
  template:
    metadata:
      labels:
        app: http-echo
    spec:
      containers:
      - name: http-echo
        image: hashicorp/http-echo
        args: ["-text", "hello-world"]
        ports:
        - containerPort: 5678
---
apiVersion: v1
kind: Service
metadata:
  name: http-echo
spec:
  ports:
  - port: 5678
    protocol: TCP
    targetPort: 5678
  selector:
    app: http-echo

(base-valid.yaml)

ہم اس YAML کو مختلف ٹولز کا موازنہ کرنے کے لیے استعمال کریں گے۔

مذکورہ منشور base-valid.yaml اور اس مضمون کے دیگر منشورات میں پایا جا سکتا ہے۔ گٹ ریپوزٹریز.

مینی فیسٹ ایک ویب ایپلیکیشن کی وضاحت کرتا ہے جس کا بنیادی کام پورٹ 5678 پر "ہیلو ورلڈ" پیغام کے ساتھ جواب دینا ہے۔ اسے درج ذیل کمانڈ کے ساتھ تعینات کیا جا سکتا ہے:

kubectl apply -f hello-world.yaml

اور اس طرح - کام کو چیک کریں:

kubectl port-forward svc/http-echo 8080:5678

اب جائیں۔ http://localhost:8080 اور تصدیق کریں کہ ایپلیکیشن کام کر رہی ہے۔ لیکن کیا یہ بہترین طریقوں کی پیروی کرتا ہے؟ آؤ دیکھیں.

1. کوبیوال

کے دل میں کوبیوال خیال یہ ہے کہ Kubernetes کے ساتھ کوئی بھی تعامل اس کے REST API کے ذریعے ہوتا ہے۔ دوسرے لفظوں میں، آپ یہ چیک کرنے کے لیے ایک API اسکیما استعمال کر سکتے ہیں کہ آیا دیا گیا YAML اس کے مطابق ہے۔ آئیے ایک مثال دیکھتے ہیں۔

انسٹالیشن کی ہدایات kubeval پروجیکٹ کی ویب سائٹ پر دستیاب ہیں۔

اصل مضمون لکھنے کے وقت، ورژن 0.15.0 دستیاب تھا۔

انسٹال ہونے کے بعد، آئیے اسے اوپر والے مینی فیسٹ کو کھلائیں:

$ kubeval base-valid.yaml
PASS - base-valid.yaml contains a valid Deployment (http-echo)
PASS - base-valid.yaml contains a valid Service (http-echo)

کامیاب ہونے کی صورت میں کوبیوال ایگزٹ کوڈ 0 کے ساتھ باہر نکل جائے گا۔ آپ اسے اس طرح چیک کر سکتے ہیں:

$ echo $?
0

آئیے اب ایک مختلف مینی فیسٹ کے ساتھ کوبیوال کو آزماتے ہیں:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: http-echo
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: http-echo
    spec:
      containers:
      - name: http-echo
        image: hashicorp/http-echo
        args: ["-text", "hello-world"]
        ports:
        - containerPort: 5678
---
apiVersion: v1
kind: Service
metadata:
  name: http-echo
spec:
  ports:
  - port: 5678
    protocol: TCP
    targetPort: 5678
  selector:
    app: http-echo

(kubeval-invalid.yaml)

کیا آپ آنکھ سے مسئلہ دیکھ سکتے ہیں؟ آئیے لانچ کریں:

$ kubeval kubeval-invalid.yaml
WARN - kubeval-invalid.yaml contains an invalid Deployment (http-echo) - selector: selector is required
PASS - kubeval-invalid.yaml contains a valid Service (http-echo)

# проверим код возврата
$ echo $?
1

وسائل کی تصدیق نہیں ہو رہی ہے۔

API ورژن کا استعمال کرتے ہوئے تعیناتیاں apps/v1, میں ایک سلیکٹر شامل کرنا چاہیے جو پوڈ کے لیبل سے مماثل ہو۔ مندرجہ بالا مینی فیسٹ میں سلیکٹر شامل نہیں ہے، لہذا کوبیوال نے ایک غلطی کی اطلاع دی اور غیر صفر کوڈ کے ساتھ باہر نکلا۔

میں حیران ہوں کہ اگر میں کروں تو کیا ہوگا۔ kubectl apply -f اس منشور کے ساتھ؟

ٹھیک ہے، آئیے کوشش کریں:

$ kubectl apply -f kubeval-invalid.yaml
error: error validating "kubeval-invalid.yaml": error validating data: ValidationError(Deployment.spec):
missing required field "selector" in io.k8s.api.apps.v1.DeploymentSpec; if you choose to ignore these errors,
turn validation off with --validate=false

یہ بالکل وہی غلطی ہے جس کے بارے میں کوبیوال نے خبردار کیا تھا۔ آپ سلیکٹر کو شامل کر کے اسے ٹھیک کر سکتے ہیں:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: http-echo
spec:
  replicas: 2
  selector:          # !!!
    matchLabels:     # !!!
      app: http-echo # !!!
  template:
    metadata:
      labels:
        app: http-echo
    spec:
      containers:
      - name: http-echo
        image: hashicorp/http-echo
        args: ["-text", "hello-world"]
        ports:
        - containerPort: 5678
---
apiVersion: v1
kind: Service
metadata:
  name: http-echo
spec:
  ports:
  - port: 5678
    protocol: TCP
    targetPort: 5678
  selector:
    app: http-echo

(base-valid.yaml)

کوبیوال جیسے ٹولز کا فائدہ یہ ہے کہ اس طرح کی غلطیوں کو تعیناتی کے چکر میں جلد پکڑا جا سکتا ہے۔

اس کے علاوہ، ان چیکوں کو کلسٹر تک رسائی کی ضرورت نہیں ہے؛ یہ آف لائن انجام دیے جا سکتے ہیں۔

پہلے سے طے شدہ طور پر، kubeval تازہ ترین Kubernetes API اسکیما کے خلاف وسائل کو چیک کرتا ہے۔ تاہم، زیادہ تر معاملات میں آپ کو ایک مخصوص Kubernetes ریلیز کے خلاف چیک کرنے کی ضرورت پڑ سکتی ہے۔ یہ پرچم کا استعمال کرتے ہوئے کیا جا سکتا ہے --kubernetes-version:

$ kubeval --kubernetes-version 1.16.1 base-valid.yaml

براہ کرم نوٹ کریں کہ ورژن کی وضاحت فارمیٹ میں ہونی چاہیے۔ Major.Minor.Patch.

ان ورژنز کی فہرست کے لیے جن کے لیے توثیق کی حمایت کی جاتی ہے، براہ کرم ملاحظہ کریں۔ GitHub پر JSON اسکیما، جسے کوبیوال توثیق کے لیے استعمال کرتا ہے۔ اگر آپ کو کوبیوال آف لائن چلانے کی ضرورت ہے، تو اسکیموں کو ڈاؤن لوڈ کریں اور پرچم کا استعمال کرتے ہوئے ان کے مقامی مقام کی وضاحت کریں۔ --schema-location.

انفرادی YAML فائلوں کے علاوہ، kubeval ڈائریکٹریز اور stdin کے ساتھ بھی کام کر سکتا ہے۔

اس کے علاوہ، کوبیوال آسانی سے CI پائپ لائن میں ضم ہو جاتا ہے۔ جو لوگ کلسٹر میں مینی فیسٹ بھیجنے سے پہلے ٹیسٹ چلانا چاہتے ہیں انہیں یہ جان کر خوشی ہوگی کہ کیوبیل تین آؤٹ پٹ فارمیٹس کو سپورٹ کرتا ہے:

سادہ متن؛
JSON;
کسی بھی چیز کے پروٹوکول (ٹی اے پی) کی جانچ کریں۔

اور کسی بھی فارمیٹس کو مطلوبہ قسم کے نتائج کا خلاصہ تیار کرنے کے لیے آؤٹ پٹ کی مزید تجزیہ کے لیے استعمال کیا جا سکتا ہے۔

کوبیوال کی خامیوں میں سے ایک یہ ہے کہ یہ فی الحال کسٹم ریسورس ڈیفینیشنز (CRDs) کی تعمیل کی جانچ نہیں کر سکتا۔ تاہم، کوبیوال کو ترتیب دینا ممکن ہے۔ انہیں نظرانداز کرو.

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

مثال کے طور پر، ٹیگ کا استعمال کرتے ہوئے latest ایک کنٹینر میں بہترین طریقوں کی پیروی نہیں کرتا ہے۔ تاہم، کوبیوال اسے غلطی نہیں مانتا اور نہ ہی اس کی اطلاع دیتا ہے۔ یعنی ایسے YAML کی تصدیق بغیر وارننگ کے مکمل ہو جائے گی۔

لیکن اگر آپ YAML کی جانچ کرنا چاہتے ہیں اور ٹیگ جیسی خلاف ورزیوں کی نشاندہی کرنا چاہتے ہیں۔ latest? میں بہترین طریقوں کے خلاف YAML فائل کو کیسے چیک کروں؟

2. کیوب سکور

کیوب سکور YAML مینی فیسٹ کو پارس کرتا ہے اور بلٹ ان ٹیسٹوں کے خلاف ان کا جائزہ لیتا ہے۔ ان ٹیسٹوں کا انتخاب حفاظتی رہنما خطوط اور بہترین طریقوں کی بنیاد پر کیا جاتا ہے، جیسے:

کنٹینر کو روٹ کے طور پر نہیں چلانا۔
پوڈ ہیلتھ چیکس کی دستیابی.
وسائل کے لیے درخواستیں اور حدود طے کرنا۔

ٹیسٹ کے نتائج کی بنیاد پر، تین نتائج دیئے گئے ہیں: OK, انتباہ и CRITICAL.

آپ آن لائن کیوب سکور آزما سکتے ہیں یا اسے مقامی طور پر انسٹال کر سکتے ہیں۔

اصل مضمون لکھنے کے وقت، کیوب سکور کا تازہ ترین ورژن 1.7.0 تھا۔

آئیے اسے اپنے مینی فیسٹ پر آزماتے ہیں۔ base-valid.yaml:

$ kube-score score base-valid.yaml

apps/v1/Deployment http-echo
[CRITICAL] Container Image Tag
  · http-echo -> Image with latest tag
      Using a fixed tag is recommended to avoid accidental upgrades
[CRITICAL] Pod NetworkPolicy
  · The pod does not have a matching network policy
      Create a NetworkPolicy that targets this pod
[CRITICAL] Pod Probes
  · Container is missing a readinessProbe
      A readinessProbe should be used to indicate when the service is ready to receive traffic.
      Without it, the Pod is risking to receive traffic before it has booted. It is also used during
      rollouts, and can prevent downtime if a new version of the application is failing.
      More information: https://github.com/zegl/kube-score/blob/master/README_PROBES.md
[CRITICAL] Container Security Context
  · http-echo -> Container has no configured security context
      Set securityContext to run the container in a more secure context.
[CRITICAL] Container Resources
  · http-echo -> CPU limit is not set
      Resource limits are recommended to avoid resource DDOS. Set resources.limits.cpu
  · http-echo -> Memory limit is not set
      Resource limits are recommended to avoid resource DDOS. Set resources.limits.memory
  · http-echo -> CPU request is not set
      Resource requests are recommended to make sure that the application can start and run without
      crashing. Set resources.requests.cpu
  · http-echo -> Memory request is not set
      Resource requests are recommended to make sure that the application can start and run without crashing.
      Set resources.requests.memory
[CRITICAL] Deployment has PodDisruptionBudget
  · No matching PodDisruptionBudget was found
      It is recommended to define a PodDisruptionBudget to avoid unexpected downtime during Kubernetes
      maintenance operations, such as when draining a node.
[WARNING] Deployment has host PodAntiAffinity
  · Deployment does not have a host podAntiAffinity set
      It is recommended to set a podAntiAffinity that stops multiple pods from a deployment from
      being scheduled on the same node. This increases availability in case the node becomes unavailable.

YAML kubeval ٹیسٹ پاس کرتا ہے، جبکہ kube-score مندرجہ ذیل خامیوں کی طرف اشارہ کرتا ہے:

تیاری کے چیک کنفیگر نہیں ہیں۔
CPU وسائل اور میموری کے لیے کوئی درخواستیں یا حدود نہیں ہیں۔
پھلی میں خلل ڈالنے والے بجٹ کی وضاحت نہیں کی گئی ہے۔
علیحدگی کے کوئی اصول نہیں ہیں۔ (مخالف تعلق) دستیابی کو زیادہ سے زیادہ کرنے کے لیے۔
کنٹینر جڑ کے طور پر چلتا ہے.

یہ تمام خامیوں کے بارے میں درست نکات ہیں جنہیں تعیناتی کو مزید موثر اور قابل اعتماد بنانے کے لیے دور کرنے کی ضرورت ہے۔

ٹیم kube-score تمام قسم کی خلاف ورزیوں سمیت معلومات کو انسانی پڑھنے کے قابل شکل میں دکھاتا ہے۔ انتباہ и CRITICAL، جو ترقی کے دوران بہت مدد کرتا ہے۔

جو لوگ اس ٹول کو CI پائپ لائن کے اندر استعمال کرنا چاہتے ہیں وہ پرچم کا استعمال کرتے ہوئے زیادہ کمپریسڈ آؤٹ پٹ کو فعال کر سکتے ہیں۔ --output-format ci (اس صورت میں، نتیجہ کے ساتھ ٹیسٹ بھی دکھائے جاتے ہیں۔ OK):

$ kube-score score base-valid.yaml --output-format ci

[OK] http-echo apps/v1/Deployment
[OK] http-echo apps/v1/Deployment
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) CPU limit is not set
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) Memory limit is not set
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) CPU request is not set
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) Memory request is not set
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) Image with latest tag
[OK] http-echo apps/v1/Deployment
[CRITICAL] http-echo apps/v1/Deployment: The pod does not have a matching network policy
[CRITICAL] http-echo apps/v1/Deployment: Container is missing a readinessProbe
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) Container has no configured security context
[CRITICAL] http-echo apps/v1/Deployment: No matching PodDisruptionBudget was found
[WARNING] http-echo apps/v1/Deployment: Deployment does not have a host podAntiAffinity set
[OK] http-echo v1/Service
[OK] http-echo v1/Service
[OK] http-echo v1/Service
[OK] http-echo v1/Service

kubeval کی طرح، kube-score ایک غیر صفر ایگزٹ کوڈ واپس کرتا ہے جب کوئی ٹیسٹ ناکام ہو جاتا ہے CRITICAL. آپ اسی طرح کی پروسیسنگ کو بھی فعال کر سکتے ہیں۔ انتباہ.

اس کے علاوہ، مختلف API ورژن (جیسا کہ کوبیوال میں) کی تعمیل کے لیے وسائل کی جانچ کرنا ممکن ہے۔ تاہم، یہ معلومات خود کیوب سکور میں ہارڈ کوڈ کی گئی ہیں: آپ کوبرنیٹس کا کوئی مختلف ورژن منتخب نہیں کر سکتے۔ اگر آپ اپنے کلسٹر کو اپ گریڈ کرنا چاہتے ہیں یا آپ کے پاس K8s کے مختلف ورژن والے متعدد کلسٹرز ہیں تو یہ حد ایک بڑا مسئلہ ہو سکتی ہے۔

براہ کرم نوٹ کریں پہلے سے ہی ایک مسئلہ ہے اس موقع کو حاصل کرنے کی تجویز کے ساتھ۔

کیوب سکور کے بارے میں مزید معلومات پر مل سکتی ہے۔ سرکاری ویب سائٹ.

بہترین طریقوں کو لاگو کرنے کے لیے کیوب سکور ٹیسٹ ایک بہترین ٹول ہیں، لیکن اگر آپ کو ٹیسٹ میں تبدیلیاں کرنے یا اپنے قوانین شامل کرنے کی ضرورت ہو تو کیا ہوگا؟ افسوس، ایسا نہیں ہو سکتا۔

کیوب سکور قابل توسیع نہیں ہے: آپ اس میں پالیسیاں شامل یا ایڈجسٹ نہیں کر سکتے۔

اگر آپ کو کمپنی کی پالیسیوں کے ساتھ تعمیل کی تصدیق کے لیے حسب ضرورت ٹیسٹ لکھنے کی ضرورت ہے، تو آپ درج ذیل چار ٹولز میں سے ایک استعمال کر سکتے ہیں: config-lint، copper، confest، یا polaris۔

3.Config-lint

Config-lint YAML، JSON، Terraform، CSV کنفیگریشن فائلوں اور Kubernetes مینی فیسٹس کی توثیق کرنے کا ایک ٹول ہے۔

آپ اسے استعمال کرکے انسٹال کرسکتے ہیں۔ ہدایات منصوبے کی ویب سائٹ پر.

اصل مضمون لکھنے کے وقت کے مطابق موجودہ ریلیز 1.5.0 ہے۔

Config-lint میں Kubernetes مینی فیسٹس کی توثیق کرنے کے لیے پہلے سے موجود ٹیسٹ نہیں ہوتے ہیں۔

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

version: 1
description: Rules for Kubernetes spec files
type: Kubernetes
files:
  - "*.yaml"
rules:
   # список правил

(rule.yaml)

آئیے اس کا مزید قریب سے مطالعہ کریں:

فیلڈ type یہ بتاتا ہے کہ کس قسم کی کنفیگریشن config-lint استعمال کرے گی۔ K8s کے لیے یہ ظاہر ہوتا ہے۔ ہمیشہ Kubernetes.
کے خانے میں files خود فائلوں کے علاوہ، آپ ایک ڈائریکٹری کی وضاحت کر سکتے ہیں۔
فیلڈ rules صارف کے ٹیسٹ ترتیب دینے کا ارادہ ہے۔

ہم کہتے ہیں کہ آپ اس بات کو یقینی بنانا چاہتے ہیں کہ تعیناتی میں تصاویر کو ہمیشہ ایک قابل اعتماد ذخیرہ سے ڈاؤن لوڈ کیا جاتا ہے جیسے my-company.com/myapp:1.0. ایک config-lint اصول جو اس طرح کی جانچ کرتا ہے اس طرح نظر آئے گا:

- id: MY_DEPLOYMENT_IMAGE_TAG
  severity: FAILURE
  message: Deployment must use a valid image tag
  resource: Deployment
  assertions:
    - every:
        key: spec.template.spec.containers
        expressions:
          - key: image
            op: starts-with
            value: "my-company.com/"

(rule-trusted-repo.yaml)

ہر اصول میں درج ذیل صفات کا ہونا ضروری ہے:

id - اصول کا منفرد شناخت کنندہ؛
severity - شاید ناکامی, انتباہ и NON_COMPLIANT;
message - اگر کسی اصول کی خلاف ورزی کی جاتی ہے، تو اس لائن کے مندرجات ظاہر ہوتے ہیں۔
resource - وسائل کی قسم جس پر یہ اصول لاگو ہوتا ہے؛
assertions - شرائط کی ایک فہرست جس کا اس وسائل کے سلسلے میں جائزہ لیا جائے گا۔

اوپر کے اصول میں assertion کہا جاتا every چیک کرتا ہے کہ تمام کنٹینرز تعیناتی میں ہیں (key: spec.templates.spec.containers) بھروسہ مند تصاویر استعمال کریں (یعنی اس سے شروع کریں۔ my-company.com/).

مکمل اصول اس طرح لگتا ہے:

version: 1
description: Rules for Kubernetes spec files
type: Kubernetes
files:
  - "*.yaml"
rules:

 - id: DEPLOYMENT_IMAGE_REPOSITORY # !!!
    severity: FAILURE
    message: Deployment must use a valid image repository
    resource: Deployment
    assertions:
      - every:
          key: spec.template.spec.containers
          expressions:
            - key: image
              op: starts-with
              value: "my-company.com/"

(ruleset.yaml)

ٹیسٹ کو آزمانے کے لیے، آئیے اسے بطور محفوظ کریں۔ check_image_repo.yaml. آئیے فائل پر ایک چیک چلائیں۔ base-valid.yaml:

$ config-lint -rules check_image_repo.yaml base-valid.yaml

[
  {
  "AssertionMessage": "Every expression fails: And expression fails: image does not start with my-company.com/",
  "Category": "",
  "CreatedAt": "2020-06-04T01:29:25Z",
  "Filename": "test-data/base-valid.yaml",
  "LineNumber": 0,
  "ResourceID": "http-echo",
  "ResourceType": "Deployment",
  "RuleID": "DEPLOYMENT_IMAGE_REPOSITORY",
  "RuleMessage": "Deployment must use a valid image repository",
  "Status": "FAILURE"
  }
]

چیک ناکام ہو گیا۔ اب آئیے درج ذیل مینی فیسٹ کو درست امیج ریپوزٹری کے ساتھ دیکھیں۔

apiVersion: apps/v1
kind: Deployment
metadata:
  name: http-echo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: http-echo
  template:
    metadata:
      labels:
        app: http-echo
    spec:
      containers:
      - name: http-echo
         image: my-company.com/http-echo:1.0 # !!!
         args: ["-text", "hello-world"]
         ports:
         - containerPort: 5678

(image-valid-mycompany.yaml)

ہم اوپر والے مینی فیسٹ کے ساتھ وہی ٹیسٹ چلاتے ہیں۔ کوئی مسئلہ نہیں ملا:

$ config-lint -rules check_image_repo.yaml image-valid-mycompany.yaml
[]

Config-lint ایک امید افزا فریم ورک ہے جو آپ کو YAML DSL کا استعمال کرتے ہوئے Kubernetes YAML مینی فیسٹس کی توثیق کرنے کے لیے اپنے ٹیسٹ بنانے کی اجازت دیتا ہے۔

لیکن اگر آپ کو زیادہ پیچیدہ منطق اور ٹیسٹ کی ضرورت ہو تو کیا ہوگا؟ کیا YAML اس کے لیے بہت محدود نہیں ہے؟ کیا ہوگا اگر آپ مکمل پروگرامنگ زبان میں ٹیسٹ بناسکیں؟

4. کاپر

کاپر V2 اپنی مرضی کے ٹیسٹ (config-lint کی طرح) کا استعمال کرتے ہوئے مینی فیسٹس کی توثیق کرنے کا ایک فریم ورک ہے۔

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

کاپر کو انسٹال کرنے کے اقدامات اس میں مل سکتے ہیں۔ سرکاری دستاویزات.

2.0.1 اصل مضمون لکھنے کے وقت اس افادیت کی تازہ ترین ریلیز ہے۔

config-lint کی طرح، Copper میں بلٹ ان ٹیسٹ نہیں ہوتے ہیں۔ آئیے ایک لکھتے ہیں۔ اسے چیک کرنے دیں کہ تعیناتی کنٹینر کی تصاویر کو خصوصی طور پر قابل اعتماد ذخیرہ خانوں سے استعمال کرتی ہے۔ my-company.com.

ایک فائل بنائیں check_image_repo.js مندرجہ ذیل مواد کے ساتھ:

$$.forEach(function($){
    if ($.kind === 'Deployment') {
        $.spec.template.spec.containers.forEach(function(container) {
            var image = new DockerImage(container.image);
            if (image.registry.lastIndexOf('my-company.com/') != 0) {
                errors.add_error('no_company_repo',"Image " + $.metadata.name + " is not from my-company.com repo", 1)
            }
        });
    }
});

اب ہمارے منشور کو جانچنے کے لیے base-valid.yaml، کمانڈ استعمال کریں۔ copper validate:

$ copper validate --in=base-valid.yaml --validator=check_image_tag.js

Check no_company_repo failed with severity 1 due to Image http-echo is not from my-company.com repo
Validation failed

یہ واضح ہے کہ تانبے کی مدد سے آپ زیادہ پیچیدہ ٹیسٹ کر سکتے ہیں - مثال کے طور پر، Ingress مینی فیسٹ میں ڈومین کے ناموں کی جانچ کرنا یا مراعات یافتہ موڈ میں چلنے والے پوڈز کو مسترد کرنا۔

تانبے میں مختلف افادیت کے افعال شامل ہیں:

DockerImage مخصوص ان پٹ فائل کو پڑھتا ہے اور درج ذیل صفات کے ساتھ ایک آبجیکٹ بناتا ہے۔
- name - تصویر کا نام،
- tag - تصویری ٹیگ،
- registry - تصویری رجسٹری،
- registry_url - پروٹوکول (https://) اور امیج رجسٹری،
- fqin - تصویر کا مکمل مقام۔
فنکشن findByName دی گئی قسم کے ذریعہ وسائل تلاش کرنے میں مدد کرتا ہے (kind) اور نام (name) ان پٹ فائل سے۔
فنکشن findByLabels ایک مخصوص قسم کے ذریعہ وسائل تلاش کرنے میں مدد کرتا ہے (kind) اور لیبلز (labels).

آپ تمام دستیاب سروس فنکشن دیکھ سکتے ہیں۔ یہاں.

پہلے سے طے شدہ طور پر یہ پوری ان پٹ YAML فائل کو متغیر میں لوڈ کرتا ہے۔ $$ اور اسے اسکرپٹنگ کے لیے دستیاب کرتا ہے (jQuery کا تجربہ رکھنے والوں کے لیے ایک مانوس تکنیک)۔

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

یہ بھی واضح رہے کہ کاپر کا موجودہ ورژن جاوا اسکرپٹ انجن کے ES5 ورژن کے ساتھ کام کرتا ہے، ES6 کے ساتھ نہیں۔

تفصیلات پر دستیاب ہے۔ سرکاری منصوبے کی ویب سائٹ.

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

5۔مقابلہ

کنفٹیسٹ کنفیگریشن ڈیٹا کی جانچ کے لیے ایک فریم ورک ہے۔ Kubernetes مینی فیسٹ کی جانچ/تصدیق کے لیے بھی موزوں ہے۔ ٹیسٹ کی وضاحت ایک خصوصی استفسار کی زبان کا استعمال کرتے ہوئے کی جاتی ہے۔ Rego کی.

آپ confest استعمال کرکے انسٹال کرسکتے ہیں۔ ہدایاتپروجیکٹ کی ویب سائٹ پر درج ہے۔

اصل مضمون لکھنے کے وقت، دستیاب تازہ ترین ورژن 0.18.2 تھا۔

config-lint اور copper کی طرح، confest بغیر کسی بلٹ ان ٹیسٹ کے آتا ہے۔ آئیے اسے آزمائیں اور اپنی پالیسی لکھیں۔ پچھلی مثالوں کی طرح، ہم چیک کریں گے کہ آیا کنٹینر کی تصاویر کسی قابل اعتماد ذریعہ سے لی گئی ہیں۔

ایک ڈائریکٹری بنائیں conftest-checks، اور اس میں نام کی ایک فائل ہے۔ check_image_registry.rego مندرجہ ذیل مواد کے ساتھ:

package main

deny[msg] {

  input.kind == "Deployment"
  image := input.spec.template.spec.containers[_].image
  not startswith(image, "my-company.com/")
  msg := sprintf("image '%v' doesn't come from my-company.com repository", [image])
}

اب ٹیسٹ کرتے ہیں۔ base-valid.yaml کے ذریعے conftest:

$ conftest test --policy ./conftest-checks base-valid.yaml

FAIL - base-valid.yaml - image 'hashicorp/http-echo' doesn't come from my-company.com repository
1 tests, 1 passed, 0 warnings, 1 failure

ٹیسٹ ممکنہ طور پر ناکام ہو گیا کیونکہ تصاویر ایک ناقابل اعتماد ذریعہ سے آئی ہیں۔

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

ڈیفالٹ آؤٹ پٹ کے علاوہ، مقابلہ JSON، TAP اور ٹیبل فارمیٹ کو سپورٹ کرتا ہے - ایک انتہائی مفید خصوصیت اگر آپ کو موجودہ CI پائپ لائن میں رپورٹوں کو سرایت کرنے کی ضرورت ہے۔ آپ پرچم کا استعمال کرتے ہوئے مطلوبہ فارمیٹ سیٹ کر سکتے ہیں۔ --output.

پالیسیوں کو ڈیبگ کرنا آسان بنانے کے لیے، conftest کا ایک جھنڈا ہے۔ --trace. یہ اس بات کا سراغ لگاتا ہے کہ کس طرح confest مخصوص پالیسی فائلوں کو پارس کرتا ہے۔

مقابلے کی پالیسیاں OCI (اوپن کنٹینر انیشی ایٹو) رجسٹریوں میں بطور نمونے شائع اور شیئر کی جا سکتی ہیں۔

ٹیمیں push и pull آپ کو ریموٹ رجسٹری سے آرٹفیکٹ شائع کرنے یا موجودہ آرٹفیکٹ کو بازیافت کرنے کی اجازت دیتا ہے۔ آئیے اس پالیسی کو شائع کرنے کی کوشش کریں جو ہم نے مقامی ڈوکر رجسٹری میں استعمال کرتے ہوئے بنائی ہے۔ conftest push.

اپنی مقامی ڈاکر رجسٹری شروع کریں:

$ docker run -it --rm -p 5000:5000 registry

دوسرے ٹرمینل میں، اس ڈائرکٹری پر جائیں جو آپ نے پہلے بنائی تھی۔ conftest-checks اور درج ذیل کمانڈ کو چلائیں:

$ conftest push 127.0.0.1:5000/amitsaha/opa-bundle-example:latest

اگر کمانڈ کامیاب رہا، تو آپ کو اس طرح کا پیغام نظر آئے گا:

2020/06/10 14:25:43 pushed bundle with digest: sha256:e9765f201364c1a8a182ca637bc88201db3417bacc091e7ef8211f6c2fd2609c

اب ایک عارضی ڈائریکٹری بنائیں اور اس میں کمانڈ چلائیں۔ conftest pull. یہ پچھلی کمانڈ کے ذریعہ تیار کردہ پیکیج کو ڈاؤن لوڈ کرے گا:

$ cd $(mktemp -d)
$ conftest pull 127.0.0.1:5000/amitsaha/opa-bundle-example:latest

عارضی ڈائریکٹری میں ایک ذیلی ڈائرکٹری ظاہر ہوگی۔ policyہماری پالیسی فائل پر مشتمل:

$ tree
.
└── policy
  └── check_image_registry.rego

ٹیسٹ ریپوزٹری سے براہ راست چلائے جا سکتے ہیں:

$ conftest test --update 127.0.0.1:5000/amitsaha/opa-bundle-example:latest base-valid.yaml
..
FAIL - base-valid.yaml - image 'hashicorp/http-echo' doesn't come from my-company.com repository
2 tests, 1 passed, 0 warnings, 1 failure

بدقسمتی سے، DockerHub ابھی تک تعاون یافتہ نہیں ہے۔ لہذا اگر آپ استعمال کرتے ہیں تو اپنے آپ کو خوش قسمت سمجھیں۔ Azure کنٹینر رجسٹری (ACR) یا آپ کی اپنی رجسٹری۔

آرٹفیکٹ فارمیٹ جیسا ہی ہے۔ پالیسی ایجنٹ پیکجز کھولیں۔ (OPA)، جو آپ کو موجودہ OPA پیکجوں سے ٹیسٹ چلانے کے لیے confest استعمال کرنے کی اجازت دیتا ہے۔

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

6. پولارس

اس مضمون میں بحث کی جائے گی کہ آخری آلہ ہے Polaris. (ان کا گزشتہ سال کا اعلان ہم پہلے ہی ترجمہ کیا گیا ہے۔ - تقریبا. ترجمہ)

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

کمانڈ لائن موڈ میں چلتے وقت، بلٹ ان ٹیسٹ دستیاب ہوتے ہیں جن میں سیکیورٹی اور بہترین طریقہ کار (کیوب سکور کی طرح) شامل ہوتے ہیں۔ اس کے علاوہ، آپ اپنے ٹیسٹ بھی بنا سکتے ہیں (جیسا کہ config-lint، copper اور confest میں)۔

دوسرے الفاظ میں، پولارس ٹولز کی دونوں قسموں کے فوائد کو یکجا کرتا ہے: بلٹ ان اور حسب ضرورت ٹیسٹ کے ساتھ۔

پولارس کو کمانڈ لائن موڈ میں انسٹال کرنے کے لیے، استعمال کریں۔ منصوبے کی ویب سائٹ پر ہدایات.

اصل مضمون لکھنے کے وقت، ورژن 1.0.3 دستیاب ہے۔

انسٹالیشن مکمل ہونے کے بعد آپ مینی فیسٹ پر پولارس چلا سکتے ہیں۔ base-valid.yaml درج ذیل کمانڈ کے ساتھ:

$ polaris audit --audit-path base-valid.yaml

یہ JSON فارمیٹ میں کئے گئے ٹیسٹوں اور ان کے نتائج کی تفصیلی وضاحت کے ساتھ سٹرنگ آؤٹ پٹ کرے گا۔ آؤٹ پٹ میں مندرجہ ذیل ڈھانچہ ہوگا:

{
  "PolarisOutputVersion": "1.0",
  "AuditTime": "0001-01-01T00:00:00Z",
  "SourceType": "Path",
  "SourceName": "test-data/base-valid.yaml",
  "DisplayName": "test-data/base-valid.yaml",
  "ClusterInfo": {
    "Version": "unknown",
    "Nodes": 0,
    "Pods": 2,
    "Namespaces": 0,
    "Controllers": 2
  },
  "Results": [
    /* длинный список */
  ]
}

مکمل آؤٹ پٹ دستیاب ہے۔ یہاں.

کیوب سکور کی طرح، پولارس ان علاقوں میں مسائل کی نشاندہی کرتا ہے جہاں مینی فیسٹ بہترین طریقوں پر پورا نہیں اترتا:

پھلیوں کے لئے کوئی صحت کی جانچ نہیں ہے۔
کنٹینر کی تصاویر کے لیے ٹیگز متعین نہیں کیے گئے ہیں۔
کنٹینر جڑ کے طور پر چلتا ہے.
میموری اور CPU کے لیے درخواستیں اور حدود متعین نہیں ہیں۔

ہر ٹیسٹ، اس کے نتائج پر منحصر ہے، ایک درجہ تنقیدی تفویض کیا جاتا ہے: انتباہ یا خطرہ. دستیاب بلٹ ان ٹیسٹوں کے بارے میں مزید جاننے کے لیے، براہ کرم ملاحظہ کریں۔ دستاویزات.

اگر تفصیلات کی ضرورت نہیں ہے، تو آپ جھنڈے کی وضاحت کر سکتے ہیں۔ --format score. اس صورت میں، پولارس 1 سے 100 − تک کا نمبر نکالے گا۔ سکور (یعنی تشخیص):

$ polaris audit --audit-path test-data/base-valid.yaml --format score
68

سکور 100 کے جتنا قریب ہوگا، معاہدے کی ڈگری اتنی ہی زیادہ ہوگی۔ اگر آپ کمانڈ کا ایگزٹ کوڈ چیک کرتے ہیں۔ polaris audit، یہ پتہ چلتا ہے کہ یہ 0 کے برابر ہے۔

زبردستی polaris audit آپ دو جھنڈوں کا استعمال کرتے ہوئے غیر صفر کوڈ کے ساتھ کام ختم کر سکتے ہیں:

پرچم --set-exit-code-below-score رینج 1-100 میں ایک دلیل کے طور پر ایک حد کی قدر لیتا ہے۔ اس صورت میں، اگر سکور حد سے نیچے ہے تو کمانڈ ایگزٹ کوڈ 4 کے ساتھ نکل جائے گی۔ یہ اس وقت بہت مفید ہے جب آپ کے پاس ایک مخصوص حد کی قدر ہو (کہیں کہ 75) اور اگر اسکور نیچے جاتا ہے تو آپ کو الرٹ موصول کرنا ہوگا۔
پرچم --set-exit-code-on-danger اگر خطرے کے ٹیسٹوں میں سے ایک ناکام ہوجاتا ہے تو کمانڈ کو کوڈ 3 کے ساتھ ناکام کرنے کا سبب بنے گا۔

اب آئیے ایک حسب ضرورت ٹیسٹ بنانے کی کوشش کرتے ہیں جو یہ جانچتا ہے کہ آیا یہ تصویر کسی قابل اعتماد ذخیرہ سے لی گئی ہے۔ حسب ضرورت ٹیسٹ YAML فارمیٹ میں بیان کیے گئے ہیں، اور ٹیسٹ خود JSON اسکیما کا استعمال کرتے ہوئے بیان کیا گیا ہے۔

درج ذیل YAML کوڈ کا ٹکڑا ایک نئے ٹیسٹ کی وضاحت کرتا ہے جسے کہا جاتا ہے۔ checkImageRepo:

checkImageRepo:
  successMessage: Image registry is valid
  failureMessage: Image registry is not valid
  category: Images
  target: Container
  schema:
    '$schema': http://json-schema.org/draft-07/schema
    type: object
    properties:
      image:
        type: string
        pattern: ^my-company.com/.+$

آئیے اس پر گہری نظر ڈالتے ہیں:

successMessage اگر ٹیسٹ کامیابی سے مکمل ہو جاتا ہے تو یہ لائن پرنٹ کی جائے گی۔
failureMessage - یہ پیغام ناکامی کی صورت میں دکھایا جائے گا۔
category - زمروں میں سے ایک کی نشاندہی کرتا ہے: Images, Health Checks, Security, Networking и Resources;
target--- اس بات کا تعین کرتا ہے کہ کس قسم کی چیز (spec) ٹیسٹ کا اطلاق ہوتا ہے۔ ممکنہ قدریں: Container, Pod یا Controller;
ٹیسٹ خود آبجیکٹ میں بیان کیا گیا ہے۔ schema JSON اسکیما کا استعمال کرتے ہوئے اس ٹیسٹ میں کلیدی لفظ ہے۔ pattern مطلوبہ ماخذ سے تصویری ماخذ کا موازنہ کرنے کے لیے استعمال کیا جاتا ہے۔

مندرجہ بالا ٹیسٹ کو چلانے کے لیے، آپ کو درج ذیل پولارس کنفیگریشن بنانے کی ضرورت ہے:

checks:
  checkImageRepo: danger
customChecks:
  checkImageRepo:
    successMessage: Image registry is valid
    failureMessage: Image registry is not valid
    category: Images
    target: Container
    schema:
      '$schema': http://json-schema.org/draft-07/schema
      type: object
      properties:
        image:
          type: string
          pattern: ^my-company.com/.+$

(polaris-conf.yaml)

آئیے فائل کو پارس کرتے ہیں:

کے خانے میں checks ٹیسٹ اور ان کی تنقیدی سطح کا تعین کیا گیا ہے۔ چونکہ کسی غیر بھروسہ مند ذریعہ سے تصویر لی جانے پر انتباہ موصول ہونا ضروری ہے، اس لیے ہم یہاں لیول سیٹ کرتے ہیں۔ danger.
ٹیسٹ خود checkImageRepo پھر اعتراض میں رجسٹرڈ customChecks.

فائل کو بطور محفوظ کریں۔ custom_check.yaml. اب آپ دوڑ سکتے ہیں۔ polaris audit YAML مینی فیسٹ کے ساتھ جس کی تصدیق کی ضرورت ہے۔

آئیے اپنے منشور کو جانچتے ہیں۔ base-valid.yaml:

$ polaris audit --config custom_check.yaml --audit-path base-valid.yaml

ٹیم polaris audit صرف اوپر بیان کردہ صارف ٹیسٹ چلایا اور یہ ناکام ہوگیا۔

اگر آپ تصویر کو ٹھیک کرتے ہیں۔ my-company.com/http-echo:1.0، پولارس کامیابی سے مکمل ہو جائے گا۔ تبدیلیوں کے ساتھ منشور پہلے سے موجود ہے۔ ذخیرےلہذا آپ مینی فیسٹ پر پچھلی کمانڈ چیک کر سکتے ہیں۔ image-valid-mycompany.yaml.

اب سوال یہ پیدا ہوتا ہے کہ کسٹم ٹیسٹ کے ساتھ بلٹ ان ٹیسٹ کیسے چلائے جائیں؟ آسانی سے! آپ کو کنفیگریشن فائل میں بلٹ ان ٹیسٹ شناخت کنندگان کو شامل کرنے کی ضرورت ہے۔ نتیجے کے طور پر، یہ مندرجہ ذیل شکل لے گا:

checks:
  cpuRequestsMissing: warning
  cpuLimitsMissing: warning
  # Other inbuilt checks..
  # ..
  # custom checks
  checkImageRepo: danger # !!!
customChecks:
  checkImageRepo:        # !!!
    successMessage: Image registry is valid
    failureMessage: Image registry is not valid
    category: Images
    target: Container
    schema:
      '$schema': http://json-schema.org/draft-07/schema
      type: object
      properties:
        image:
          type: string
          pattern: ^my-company.com/.+$

(config_with_custom_check.yaml)

مکمل کنفیگریشن فائل کی مثال دستیاب ہے۔ یہاں.

مینی فیسٹ چیک کریں۔ base-valid.yamlبلٹ ان اور کسٹم ٹیسٹ کا استعمال کرتے ہوئے، آپ کمانڈ استعمال کر سکتے ہیں:

$ polaris audit --config config_with_custom_check.yaml --audit-path base-valid.yaml

پولارس اپنی مرضی کے مطابق ٹیسٹوں کو مکمل کرتا ہے، اس طرح دونوں جہانوں کے بہترین کو یکجا کرتا ہے۔

دوسری طرف، Rego یا JavaScript جیسی زیادہ طاقتور زبانیں استعمال کرنے میں ناکامی زیادہ نفیس ٹیسٹوں کی تخلیق کو روکنے کا ایک محدود عنصر ہو سکتا ہے۔

پولارس کے بارے میں مزید معلومات پر دستیاب ہے۔ منصوبے کی ویب سائٹ.

خلاصہ

جبکہ Kubernetes YAML فائلوں کا معائنہ اور جائزہ لینے کے لیے بہت سے ٹولز دستیاب ہیں، یہ واضح طور پر سمجھنا ضروری ہے کہ ٹیسٹوں کو کس طرح ڈیزائن اور انجام دیا جائے گا۔.

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

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

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

Conftest اور config-lint اپنی مرضی کے ٹیسٹ کی وضاحت کے لیے YAML کا استعمال کرتے ہیں، اور copper آپ کو ایک مکمل پروگرامنگ زبان تک رسائی فراہم کرتا ہے، جس سے یہ ایک پرکشش انتخاب ہے۔

دوسری طرف، کیا یہ ان ٹولز میں سے کسی ایک کو استعمال کرنے کے قابل ہے اور اس وجہ سے، تمام ٹیسٹ دستی طور پر بنانا، یا پولارس کو ترجیح دیں اور اس میں صرف وہی شامل کریں جس کی ضرورت ہے؟ اس سوال کا کوئی واضح جواب نہیں ہے۔.

نیچے دی گئی جدول ہر ٹول کی مختصر وضاحت فراہم کرتی ہے۔

آلہ۔
مقصد
حدود
صارف کے ٹیسٹ

کوبیوال
API اسکیما کے مخصوص ورژن کے خلاف YAML مینی فیسٹ کی توثیق کرتا ہے۔
CRD کے ساتھ کام نہیں کر سکتا
کوئی

کیوب سکور
بہترین طریقوں کے خلاف YAML کا تجزیہ کرتا ہے۔
وسائل کو چیک کرنے کے لیے آپ کا Kubernetes API ورژن منتخب نہیں کیا جا سکتا
کوئی

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

config-lint
YAML میں سرایت شدہ ڈومین کے لیے مخصوص زبان میں ٹیسٹ بنانے کے لیے ایک عمومی فریم ورک۔ مختلف کنفیگریشن فارمیٹس کو سپورٹ کرتا ہے (جیسے Terraform)
کوئی ریڈی میڈ ٹیسٹ نہیں ہیں۔ بلٹ ان دعوے اور افعال کافی نہیں ہوسکتے ہیں۔
جی ہاں

مقابلہ
ریگو (ایک خصوصی استفسار کی زبان) کا استعمال کرتے ہوئے اپنے ٹیسٹ بنانے کے لیے ایک فریم ورک۔ OCI بنڈلز کے ذریعے پالیسیوں کے اشتراک کی اجازت دیتا ہے۔
کوئی بلٹ ان ٹیسٹ نہیں۔ مجھے ریگو سیکھنا ہے۔ پالیسیاں شائع کرتے وقت Docker Hub تعاون یافتہ نہیں ہے۔
جی ہاں

Polaris
جائزے YAML معیاری بہترین طریقوں کے خلاف ظاہر ہوتا ہے۔ آپ کو JSON اسکیما کا استعمال کرتے ہوئے اپنے ٹیسٹ بنانے کی اجازت دیتا ہے۔
JSON اسکیما پر مبنی ٹیسٹ کی صلاحیتیں کافی نہیں ہوسکتی ہیں۔
جی ہاں

چونکہ یہ ٹولز Kubernetes کلسٹر تک رسائی پر انحصار نہیں کرتے ہیں، ان کو انسٹال کرنا آسان ہے۔ وہ آپ کو سورس فائلوں کو فلٹر کرنے اور پروجیکٹس میں پل کی درخواستوں کے مصنفین کو فوری فیڈ بیک فراہم کرنے کی اجازت دیتے ہیں۔

مترجم سے PS

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

ماخذ: www.habr.com

بہترین طریقوں اور پالیسیوں کے خلاف Kubernetes YAML کی توثیق کریں۔