ਕੁਬਰਨੇਟਸ YAML ਨੂੰ ਵਧੀਆ ਅਭਿਆਸਾਂ ਅਤੇ ਨੀਤੀਆਂ ਦੇ ਵਿਰੁੱਧ ਪ੍ਰਮਾਣਿਤ ਕਰੋ

ਨੋਟ ਕਰੋ। ਅਨੁਵਾਦ: K8s ਵਾਤਾਵਰਣਾਂ ਲਈ YAML ਸੰਰਚਨਾਵਾਂ ਦੀ ਵੱਧ ਰਹੀ ਗਿਣਤੀ ਦੇ ਨਾਲ, ਉਹਨਾਂ ਦੀ ਸਵੈਚਲਿਤ ਤਸਦੀਕ ਦੀ ਲੋੜ ਵੱਧ ਤੋਂ ਵੱਧ ਜ਼ਰੂਰੀ ਹੋ ਜਾਂਦੀ ਹੈ। ਇਸ ਸਮੀਖਿਆ ਦੇ ਲੇਖਕ ਨੇ ਨਾ ਸਿਰਫ਼ ਇਸ ਕਾਰਜ ਲਈ ਮੌਜੂਦਾ ਹੱਲਾਂ ਦੀ ਚੋਣ ਕੀਤੀ, ਸਗੋਂ ਇਹ ਦੇਖਣ ਲਈ ਕਿ ਉਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ, ਇੱਕ ਉਦਾਹਰਣ ਵਜੋਂ ਤੈਨਾਤੀ ਦੀ ਵਰਤੋਂ ਵੀ ਕੀਤੀ। ਇਹ ਉਹਨਾਂ ਲਈ ਬਹੁਤ ਜਾਣਕਾਰੀ ਭਰਪੂਰ ਸਾਬਤ ਹੋਇਆ ਜੋ ਇਸ ਵਿਸ਼ੇ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹਨ.

TL; ਡਾ: ਇਹ ਲੇਖ ਵਧੀਆ ਅਭਿਆਸਾਂ ਅਤੇ ਲੋੜਾਂ ਦੇ ਵਿਰੁੱਧ ਕੁਬਰਨੇਟਸ YAML ਫਾਈਲਾਂ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਨ ਅਤੇ ਮੁਲਾਂਕਣ ਕਰਨ ਲਈ ਛੇ ਸਥਿਰ ਟੂਲਾਂ ਦੀ ਤੁਲਨਾ ਕਰਦਾ ਹੈ।

ਕੁਬਰਨੇਟਸ ਵਰਕਲੋਡਸ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ YAML ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। YAML ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ ਮੈਨੀਫੈਸਟ ਫਾਈਲਾਂ ਵਿਚਕਾਰ ਰੁਕਾਵਟਾਂ ਜਾਂ ਸਬੰਧਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨ ਵਿੱਚ ਮੁਸ਼ਕਲ।

ਉਦੋਂ ਕੀ ਜੇ ਸਾਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ ਕਿ ਕਲੱਸਟਰ ਵਿੱਚ ਤੈਨਾਤ ਸਾਰੀਆਂ ਤਸਵੀਰਾਂ ਇੱਕ ਭਰੋਸੇਯੋਗ ਰਜਿਸਟਰੀ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ?

ਮੈਂ ਉਹਨਾਂ ਤੈਨਾਤੀਆਂ ਨੂੰ ਕਿਵੇਂ ਰੋਕ ਸਕਦਾ ਹਾਂ ਜਿਹਨਾਂ ਕੋਲ ਪੋਡਡਿਸਰਪਸ਼ਨਬਜਟ ਨਹੀਂ ਹਨ ਕਲੱਸਟਰ ਨੂੰ ਭੇਜਣ ਤੋਂ?

ਸਥਿਰ ਟੈਸਟਿੰਗ ਦਾ ਏਕੀਕਰਣ ਤੁਹਾਨੂੰ ਵਿਕਾਸ ਦੇ ਪੜਾਅ 'ਤੇ ਗਲਤੀਆਂ ਅਤੇ ਨੀਤੀ ਦੀਆਂ ਉਲੰਘਣਾਵਾਂ ਦੀ ਪਛਾਣ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਇਹ ਗਾਰੰਟੀ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ ਕਿ ਸਰੋਤ ਪਰਿਭਾਸ਼ਾਵਾਂ ਸਹੀ ਅਤੇ ਸੁਰੱਖਿਅਤ ਹਨ, ਅਤੇ ਇਸਦੀ ਸੰਭਾਵਨਾ ਵੱਧ ਜਾਂਦੀ ਹੈ ਕਿ ਉਤਪਾਦਨ ਵਰਕਲੋਡ ਵਧੀਆ ਅਭਿਆਸਾਂ ਦੀ ਪਾਲਣਾ ਕਰੇਗਾ।

ਕੁਬਰਨੇਟਸ ਸਥਿਰ YAML ਫਾਈਲ ਨਿਰੀਖਣ ਈਕੋਸਿਸਟਮ ਨੂੰ ਹੇਠ ਲਿਖੀਆਂ ਸ਼੍ਰੇਣੀਆਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾ ਸਕਦਾ ਹੈ:

• API ਪ੍ਰਮਾਣਕ. ਇਸ ਸ਼੍ਰੇਣੀ ਵਿੱਚ ਟੂਲ ਕੁਬਰਨੇਟਸ API ਸਰਵਰ ਦੀਆਂ ਲੋੜਾਂ ਦੇ ਵਿਰੁੱਧ YAML ਮੈਨੀਫੈਸਟ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਨ।
• ਤਿਆਰ ਟੈਸਟਰ. ਇਸ ਸ਼੍ਰੇਣੀ ਦੇ ਟੂਲ ਸੁਰੱਖਿਆ, ਵਧੀਆ ਅਭਿਆਸਾਂ ਦੀ ਪਾਲਣਾ ਆਦਿ ਲਈ ਤਿਆਰ ਕੀਤੇ ਟੈਸਟਾਂ ਦੇ ਨਾਲ ਆਉਂਦੇ ਹਨ।
• ਕਸਟਮ ਵੈਲੀਡੇਟਰ. ਇਸ ਸ਼੍ਰੇਣੀ ਦੇ ਪ੍ਰਤੀਨਿਧ ਤੁਹਾਨੂੰ ਵੱਖ-ਵੱਖ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਕਸਟਮ ਟੈਸਟ ਬਣਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ, ਉਦਾਹਰਨ ਲਈ, ਰੇਗੋ ਅਤੇ ਜਾਵਾਸਕ੍ਰਿਪਟ।

ਇਸ ਲੇਖ ਵਿੱਚ ਅਸੀਂ ਛੇ ਵੱਖ-ਵੱਖ ਸਾਧਨਾਂ ਦਾ ਵਰਣਨ ਅਤੇ ਤੁਲਨਾ ਕਰਾਂਗੇ:

1. ਕੁਬੇਵਾਲ;
2. kube-ਸਕੋਰ;
3. config-lint;
4. ਤਾਂਬਾ;
5. ਮੁਕਾਬਲਾ;
6. ਪੋਲਾਰਿਸ.

ਖੈਰ, ਆਓ ਸ਼ੁਰੂ ਕਰੀਏ!

ਤੈਨਾਤੀਆਂ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ

ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਅਸੀਂ ਟੂਲਸ ਦੀ ਤੁਲਨਾ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰੀਏ, ਆਓ ਕੁਝ ਬੈਕਗਰਾਊਂਡ ਬਣਾਈਏ ਜਿਸ 'ਤੇ ਉਨ੍ਹਾਂ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾ ਸਕੇ।

ਹੇਠਾਂ ਦਿੱਤੇ ਮੈਨੀਫੈਸਟੋ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਤਰੁੱਟੀਆਂ ਹਨ ਅਤੇ ਵਧੀਆ ਅਭਿਆਸਾਂ ਦੀ ਗੈਰ-ਪਾਲਣਾ ਹੈ: ਤੁਸੀਂ ਉਹਨਾਂ ਵਿੱਚੋਂ ਕਿੰਨੀਆਂ ਲੱਭ ਸਕਦੇ ਹੋ?

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 ਅਤੇ ਇਸ ਲੇਖ ਦੇ ਹੋਰ ਮੈਨੀਫੈਸਟੋ ਵਿੱਚ ਲੱਭੇ ਜਾ ਸਕਦੇ ਹਨ Git ਰਿਪੋਜ਼ਟਰੀਆਂ.

ਮੈਨੀਫੈਸਟ ਇੱਕ ਵੈਬ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ ਜਿਸਦਾ ਮੁੱਖ ਕੰਮ ਪੋਰਟ 5678 'ਤੇ "ਹੈਲੋ ਵਰਲਡ" ਸੰਦੇਸ਼ ਨਾਲ ਜਵਾਬ ਦੇਣਾ ਹੈ। ਇਸਨੂੰ ਹੇਠ ਦਿੱਤੀ ਕਮਾਂਡ ਨਾਲ ਤੈਨਾਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ:

kubectl apply -f hello-world.yaml

ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ - ਕੰਮ ਦੀ ਜਾਂਚ ਕਰੋ:

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

ਹੁਣ ਜਾਓ http://localhost:8080 ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਕੰਮ ਕਰ ਰਹੀ ਹੈ। ਪਰ ਕੀ ਇਹ ਸਭ ਤੋਂ ਵਧੀਆ ਅਭਿਆਸਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ? ਦੀ ਜਾਂਚ ਕਰੀਏ।

1. ਕੁਬੇਵਾਲ

ਆਧਾਰ ਤੇ ਕੁਬੇਵਾਲ ਵਿਚਾਰ ਇਹ ਹੈ ਕਿ ਕੁਬਰਨੇਟਸ ਨਾਲ ਕੋਈ ਵੀ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਇਸਦੇ 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)

ਕੁਬੇਵਾਲ ਵਰਗੇ ਸਾਧਨਾਂ ਦਾ ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਇਸ ਤਰ੍ਹਾਂ ਦੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਤੈਨਾਤੀ ਚੱਕਰ ਵਿੱਚ ਜਲਦੀ ਫੜਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਹਨਾਂ ਜਾਂਚਾਂ ਲਈ ਕਲੱਸਟਰ ਤੱਕ ਪਹੁੰਚ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ; ਉਹਨਾਂ ਨੂੰ ਔਫਲਾਈਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਮੂਲ ਰੂਪ ਵਿੱਚ, ਕੁਬੇਵਲ ਨਵੀਨਤਮ ਕੁਬਰਨੇਟਸ API ਸਕੀਮਾ ਦੇ ਵਿਰੁੱਧ ਸਰੋਤਾਂ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ ਤੁਹਾਨੂੰ ਕਿਸੇ ਖਾਸ ਕੁਬਰਨੇਟਸ ਰੀਲੀਜ਼ ਦੇ ਵਿਰੁੱਧ ਜਾਂਚ ਕਰਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਇਹ ਫਲੈਗ ਵਰਤ ਕੇ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ --kubernetes-version:

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

ਕਿਰਪਾ ਕਰਕੇ ਨੋਟ ਕਰੋ ਕਿ ਸੰਸਕਰਣ ਫਾਰਮੈਟ ਵਿੱਚ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ Major.Minor.Patch.

ਸੰਸਕਰਣਾਂ ਦੀ ਸੂਚੀ ਲਈ ਜਿਨ੍ਹਾਂ ਲਈ ਪੁਸ਼ਟੀਕਰਨ ਸਮਰਥਿਤ ਹੈ, ਕਿਰਪਾ ਕਰਕੇ ਵੇਖੋ GitHub 'ਤੇ JSON ਸਕੀਮਾ, ਜਿਸ ਨੂੰ ਕੁਬੇਵਾਲ ਪ੍ਰਮਾਣਿਕਤਾ ਲਈ ਵਰਤਦਾ ਹੈ। ਜੇਕਰ ਤੁਹਾਨੂੰ ਕੁਬੇਵਲ ਔਫਲਾਈਨ ਚਲਾਉਣ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਸਕੀਮਾਂ ਨੂੰ ਡਾਊਨਲੋਡ ਕਰੋ ਅਤੇ ਫਲੈਗ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਉਹਨਾਂ ਦਾ ਸਥਾਨਕ ਸਥਾਨ ਨਿਰਧਾਰਿਤ ਕਰੋ --schema-location.

ਵਿਅਕਤੀਗਤ YAML ਫਾਈਲਾਂ ਤੋਂ ਇਲਾਵਾ, kubeval ਡਾਇਰੈਕਟਰੀਆਂ ਅਤੇ stdin ਨਾਲ ਵੀ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ।

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਕੁਬੇਵਾਲ ਆਸਾਨੀ ਨਾਲ ਸੀਆਈ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਏਕੀਕ੍ਰਿਤ ਹੋ ਜਾਂਦਾ ਹੈ। ਕਲੱਸਟਰ ਨੂੰ ਮੈਨੀਫੈਸਟ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਟੈਸਟ ਚਲਾਉਣ ਦੀ ਇੱਛਾ ਰੱਖਣ ਵਾਲਿਆਂ ਨੂੰ ਇਹ ਜਾਣ ਕੇ ਖੁਸ਼ੀ ਹੋਵੇਗੀ ਕਿ ਕੁਬੇਵਲ ਤਿੰਨ ਆਉਟਪੁੱਟ ਫਾਰਮੈਟਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ:

1. ਸਾਦਾ ਪਾਠ;
2. JSON;
3. ਟੈਸਟ ਐਨੀਥਿੰਗ ਪ੍ਰੋਟੋਕੋਲ (TAP)।

ਅਤੇ ਕਿਸੇ ਵੀ ਫਾਰਮੈਟ ਨੂੰ ਲੋੜੀਦੀ ਕਿਸਮ ਦੇ ਨਤੀਜਿਆਂ ਦਾ ਸੰਖੇਪ ਬਣਾਉਣ ਲਈ ਆਉਟਪੁੱਟ ਨੂੰ ਪਾਰਸ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਕੁਬੇਵਲ ਦੀਆਂ ਕਮੀਆਂ ਵਿੱਚੋਂ ਇੱਕ ਇਹ ਹੈ ਕਿ ਇਹ ਵਰਤਮਾਨ ਵਿੱਚ ਕਸਟਮ ਰਿਸੋਰਸ ਪਰਿਭਾਸ਼ਾਵਾਂ (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 ਕੁਬੇਵਲ ਟੈਸਟ ਪਾਸ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਕੁਬੇ-ਸਕੋਰ ਹੇਠ ਲਿਖੀਆਂ ਖਾਮੀਆਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ:

• ਤਿਆਰੀ ਜਾਂਚਾਂ ਨੂੰ ਕੌਂਫਿਗਰ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ।
• 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

ਕੁਬੇਵਾਲ ਦੀ ਤਰ੍ਹਾਂ, ਕੁਬੇ-ਸਕੋਰ ਇੱਕ ਗੈਰ-ਜ਼ੀਰੋ ਐਗਜ਼ਿਟ ਕੋਡ ਵਾਪਸ ਕਰਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ਟੈਸਟ ਅਸਫਲ ਹੁੰਦਾ ਹੈ CRITICAL. ਤੁਸੀਂ ਇਸ ਲਈ ਸਮਾਨ ਪ੍ਰੋਸੈਸਿੰਗ ਨੂੰ ਵੀ ਸਮਰੱਥ ਕਰ ਸਕਦੇ ਹੋ ਚੇਤਾਵਨੀ.

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਵੱਖ-ਵੱਖ API ਸੰਸਕਰਣਾਂ (ਜਿਵੇਂ ਕਿ ਕੁਬੇਵਲ ਵਿੱਚ) ਦੀ ਪਾਲਣਾ ਲਈ ਸਰੋਤਾਂ ਦੀ ਜਾਂਚ ਕਰਨਾ ਸੰਭਵ ਹੈ। ਹਾਲਾਂਕਿ, ਇਹ ਜਾਣਕਾਰੀ ਖੁਦ ਕੁਬੇ-ਸਕੋਰ ਵਿੱਚ ਹਾਰਡਕੋਡ ਕੀਤੀ ਗਈ ਹੈ: ਤੁਸੀਂ ਕੁਬਰਨੇਟਸ ਦਾ ਕੋਈ ਵੱਖਰਾ ਸੰਸਕਰਣ ਨਹੀਂ ਚੁਣ ਸਕਦੇ। ਇਹ ਸੀਮਾ ਇੱਕ ਵੱਡੀ ਸਮੱਸਿਆ ਹੋ ਸਕਦੀ ਹੈ ਜੇਕਰ ਤੁਸੀਂ ਆਪਣੇ ਕਲੱਸਟਰ ਨੂੰ ਅੱਪਗਰੇਡ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਜਾਂ ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ K8s ਦੇ ਵੱਖ-ਵੱਖ ਸੰਸਕਰਣਾਂ ਵਾਲੇ ਕਈ ਕਲੱਸਟਰ ਹਨ।

ਨੋਟ ਕਰੋ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਮੁੱਦਾ ਹੈ ਇਸ ਮੌਕੇ ਨੂੰ ਮਹਿਸੂਸ ਕਰਨ ਲਈ ਇੱਕ ਪ੍ਰਸਤਾਵ ਦੇ ਨਾਲ.

ਕੁਬੇ-ਸਕੋਰ ਬਾਰੇ ਹੋਰ ਜਾਣਕਾਰੀ ਇੱਥੇ ਲੱਭੀ ਜਾ ਸਕਦੀ ਹੈ ਸਰਕਾਰੀ ਵੈਬਸਾਈਟ.

ਕੁਬੇ-ਸਕੋਰ ਟੈਸਟ ਸਭ ਤੋਂ ਵਧੀਆ ਅਭਿਆਸਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਇੱਕ ਵਧੀਆ ਸਾਧਨ ਹਨ, ਪਰ ਜੇਕਰ ਤੁਹਾਨੂੰ ਟੈਸਟ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਕਰਨ ਜਾਂ ਆਪਣੇ ਖੁਦ ਦੇ ਨਿਯਮ ਜੋੜਨ ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਕੀ ਹੋਵੇਗਾ? ਹਾਏ, ਇਹ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ।

ਕੂਬੇ-ਸਕੋਰ ਵਿਸਤ੍ਰਿਤ ਨਹੀਂ ਹੈ: ਤੁਸੀਂ ਇਸ ਵਿੱਚ ਨੀਤੀਆਂ ਨਹੀਂ ਜੋੜ ਸਕਦੇ ਜਾਂ ਉਹਨਾਂ ਨੂੰ ਅਨੁਕੂਲ ਨਹੀਂ ਕਰ ਸਕਦੇ।

ਜੇ ਤੁਹਾਨੂੰ ਕੰਪਨੀ ਦੀਆਂ ਨੀਤੀਆਂ ਦੀ ਪਾਲਣਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਕਸਟਮ ਟੈਸਟ ਲਿਖਣ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਹੇਠਾਂ ਦਿੱਤੇ ਚਾਰ ਟੂਲਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ: config-lint, copper, confest, ਜਾਂ polaris.

3. ਕੌਨਫਿਗ-ਲਿੰਟ

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. ਇੱਕ ਸੰਰਚਨਾ-ਲਿੰਟ ਨਿਯਮ ਜੋ ਅਜਿਹੀ ਜਾਂਚ ਕਰਦਾ ਹੈ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇਵੇਗਾ:

- 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 ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦਾ ਹੈ। ਇਸਦੀ ਬਜਾਏ ਟੈਸਟਾਂ ਨੂੰ JavaScript ਵਿੱਚ ਲਿਖਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਕਾਪਰ ਕਈ ਬੁਨਿਆਦੀ ਸਾਧਨਾਂ ਨਾਲ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਜੋ ਤੁਹਾਨੂੰ ਕੁਬਰਨੇਟਸ ਵਸਤੂਆਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਪੜ੍ਹਨ ਅਤੇ ਗਲਤੀਆਂ ਦੀ ਰਿਪੋਰਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।

ਕਾਪਰ ਨੂੰ ਇੰਸਟਾਲ ਕਰਨ ਲਈ ਕਦਮ ਵਿੱਚ ਲੱਭਿਆ ਜਾ ਸਕਦਾ ਹੈ ਅਧਿਕਾਰਤ ਦਸਤਾਵੇਜ਼.

2.0.1 ਅਸਲੀ ਲੇਖ ਲਿਖਣ ਦੇ ਸਮੇਂ ਇਸ ਉਪਯੋਗਤਾ ਦਾ ਨਵੀਨਤਮ ਰੀਲੀਜ਼ ਹੈ।

config-lint ਵਾਂਗ, ਕਾਪਰ ਵਿੱਚ ਬਿਲਟ-ਇਨ ਟੈਸਟ ਨਹੀਂ ਹੁੰਦੇ ਹਨ। ਚਲੋ ਇੱਕ ਲਿਖਦੇ ਹਾਂ। ਇਸ ਨੂੰ ਜਾਂਚ ਕਰਨ ਦਿਓ ਕਿ ਤੈਨਾਤੀਆਂ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਭਰੋਸੇਯੋਗ ਰਿਪੋਜ਼ਟਰੀਆਂ ਜਿਵੇਂ ਕਿ ਕੰਟੇਨਰ ਚਿੱਤਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ 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

ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਤਾਂਬੇ ਦੀ ਮਦਦ ਨਾਲ ਤੁਸੀਂ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਟੈਸਟ ਕਰ ਸਕਦੇ ਹੋ - ਉਦਾਹਰਨ ਲਈ, ਇੰਗਰੈਸ ਮੈਨੀਫੈਸਟ ਵਿੱਚ ਡੋਮੇਨ ਨਾਮਾਂ ਦੀ ਜਾਂਚ ਕਰਨਾ ਜਾਂ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਵਾਲੇ ਮੋਡ ਵਿੱਚ ਚੱਲ ਰਹੇ ਪੌਡਾਂ ਨੂੰ ਰੱਦ ਕਰਨਾ।

ਕਾਪਰ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਉਪਯੋਗਤਾ ਫੰਕਸ਼ਨ ਹਨ:

• DockerImage ਨਿਰਧਾਰਤ ਇਨਪੁਟ ਫਾਈਲ ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਹੇਠ ਲਿਖੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨਾਲ ਇੱਕ ਵਸਤੂ ਬਣਾਉਂਦਾ ਹੈ:
  • name - ਚਿੱਤਰ ਦਾ ਨਾਮ,
  • tag - ਚਿੱਤਰ ਟੈਗ,
  • registry - ਚਿੱਤਰ ਰਜਿਸਟਰੀ,
  • registry_url - ਪ੍ਰੋਟੋਕੋਲ (https://) ਅਤੇ ਚਿੱਤਰ ਰਜਿਸਟਰੀ,
  • fqin - ਚਿੱਤਰ ਦੀ ਪੂਰੀ ਸਥਿਤੀ.
• ਫੰਕਸ਼ਨ findByName ਇੱਕ ਦਿੱਤੀ ਕਿਸਮ ਦੁਆਰਾ ਇੱਕ ਸਰੋਤ ਲੱਭਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ (kind) ਅਤੇ ਨਾਮ (name) ਇਨਪੁਟ ਫਾਈਲ ਤੋਂ.
• ਫੰਕਸ਼ਨ findByLabels ਇੱਕ ਖਾਸ ਕਿਸਮ ਦੁਆਰਾ ਇੱਕ ਸਰੋਤ ਲੱਭਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ (kind) ਅਤੇ ਲੇਬਲ (labels).

ਤੁਸੀਂ ਸਾਰੇ ਉਪਲਬਧ ਸੇਵਾ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਦੇਖ ਸਕਦੇ ਹੋ ਇੱਥੇ.

ਮੂਲ ਰੂਪ ਵਿੱਚ ਇਹ ਪੂਰੀ ਇਨਪੁਟ YAML ਫਾਈਲ ਨੂੰ ਇੱਕ ਵੇਰੀਏਬਲ ਵਿੱਚ ਲੋਡ ਕਰਦਾ ਹੈ $$ ਅਤੇ ਇਸਨੂੰ ਸਕ੍ਰਿਪਟਿੰਗ ਲਈ ਉਪਲਬਧ ਕਰਵਾਉਂਦਾ ਹੈ (jQuery ਅਨੁਭਵ ਵਾਲੇ ਲੋਕਾਂ ਲਈ ਇੱਕ ਜਾਣੀ-ਪਛਾਣੀ ਤਕਨੀਕ)।

ਕਾਪਰ ਦਾ ਮੁੱਖ ਫਾਇਦਾ ਸਪੱਸ਼ਟ ਹੈ: ਤੁਹਾਨੂੰ ਕਿਸੇ ਵਿਸ਼ੇਸ਼ ਭਾਸ਼ਾ ਵਿੱਚ ਮੁਹਾਰਤ ਹਾਸਲ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ ਅਤੇ ਤੁਸੀਂ ਆਪਣੇ ਖੁਦ ਦੇ ਟੈਸਟ ਬਣਾਉਣ ਲਈ ਕਈ JavaScript ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ, ਜਿਵੇਂ ਕਿ ਸਟ੍ਰਿੰਗ ਇੰਟਰਪੋਲੇਸ਼ਨ, ਫੰਕਸ਼ਨ, ਆਦਿ।

ਇਹ ਵੀ ਨੋਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕਾਪਰ ਦਾ ਮੌਜੂਦਾ ਸੰਸਕਰਣ JavaScript ਇੰਜਣ ਦੇ ES5 ਸੰਸਕਰਣ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ, ES6 ਨਾਲ ਨਹੀਂ।

'ਤੇ ਉਪਲਬਧ ਵੇਰਵੇ ਅਧਿਕਾਰਤ ਪ੍ਰੋਜੈਕਟ ਵੈਬਸਾਈਟ.

ਹਾਲਾਂਕਿ, ਜੇਕਰ ਤੁਸੀਂ ਸੱਚਮੁੱਚ JavaScript ਨੂੰ ਪਸੰਦ ਨਹੀਂ ਕਰਦੇ ਹੋ ਅਤੇ ਸਵਾਲ ਬਣਾਉਣ ਅਤੇ ਨੀਤੀਆਂ ਦਾ ਵਰਣਨ ਕਰਨ ਲਈ ਖਾਸ ਤੌਰ 'ਤੇ ਤਿਆਰ ਕੀਤੀ ਗਈ ਭਾਸ਼ਾ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਵਿਵਾਦ ਵੱਲ ਧਿਆਨ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ।

5. Conftest

Confest ਸੰਰਚਨਾ ਡੇਟਾ ਦੀ ਜਾਂਚ ਲਈ ਇੱਕ ਢਾਂਚਾ ਹੈ। ਕੁਬਰਨੇਟਸ ਮੈਨੀਫੈਸਟ ਦੀ ਜਾਂਚ/ਪੜਤਾਲ ਲਈ ਵੀ ਢੁਕਵਾਂ ਹੈ। ਟੈਸਟਾਂ ਦਾ ਵਰਣਨ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਪੁੱਛਗਿੱਛ ਭਾਸ਼ਾ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਰੈਗੋ.

ਤੁਸੀਂ ਵਰਤ ਕੇ ਕਨਫੈਸਟ ਇੰਸਟਾਲ ਕਰ ਸਕਦੇ ਹੋ ਨਿਰਦੇਸ਼ਪ੍ਰੋਜੈਕਟ ਦੀ ਵੈੱਬਸਾਈਟ 'ਤੇ ਸੂਚੀਬੱਧ.

ਅਸਲ ਲੇਖ ਲਿਖਣ ਦੇ ਸਮੇਂ, ਉਪਲਬਧ ਨਵੀਨਤਮ ਸੰਸਕਰਣ 0.18.2 ਸੀ।

ਕੌਂਫਿਗ-ਲਿੰਟ ਅਤੇ ਕਾਪਰ ਦੇ ਸਮਾਨ, ਕਨਫੈਸਟ ਬਿਨਾਂ ਕਿਸੇ ਬਿਲਟ-ਇਨ ਟੈਸਟਾਂ ਦੇ ਆਉਂਦਾ ਹੈ। ਚਲੋ ਇਸਨੂੰ ਅਜ਼ਮਾਈਏ ਅਤੇ ਆਪਣੀ ਨੀਤੀ ਲਿਖੀਏ। ਪਿਛਲੀਆਂ ਉਦਾਹਰਣਾਂ ਵਾਂਗ, ਅਸੀਂ ਜਾਂਚ ਕਰਾਂਗੇ ਕਿ ਕੀ ਕੰਟੇਨਰ ਦੀਆਂ ਤਸਵੀਰਾਂ ਭਰੋਸੇਯੋਗ ਸਰੋਤ ਤੋਂ ਲਈਆਂ ਗਈਆਂ ਹਨ।

ਇੱਕ ਡਾਇਰੈਕਟਰੀ ਬਣਾਓ 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.

ਨੀਤੀਆਂ ਨੂੰ ਡੀਬੱਗ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਣ ਲਈ, ਕਨਫੈਸਟ ਦਾ ਇੱਕ ਫਲੈਗ ਹੈ --trace. ਇਹ ਇੱਕ ਟਰੇਸ ਆਉਟਪੁੱਟ ਕਰਦਾ ਹੈ ਕਿ ਕਿਵੇਂ ਕਨਫੈਸਟ ਨਿਰਧਾਰਤ ਨੀਤੀ ਫਾਈਲਾਂ ਨੂੰ ਪਾਰਸ ਕਰਦਾ ਹੈ।

ਮੁਕਾਬਲੇ ਦੀਆਂ ਨੀਤੀਆਂ ਨੂੰ 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 ਅਜੇ ਸਮਰਥਿਤ ਨਹੀਂ ਹੈ। ਇਸ ਲਈ ਜੇਕਰ ਤੁਸੀਂ ਵਰਤਦੇ ਹੋ ਤਾਂ ਆਪਣੇ ਆਪ ਨੂੰ ਖੁਸ਼ਕਿਸਮਤ ਸਮਝੋ ਅਜ਼ੁਰ ਕੰਟੇਨਰ ਰਜਿਸਟਰੀ (ACR) ਜਾਂ ਤੁਹਾਡੀ ਆਪਣੀ ਰਜਿਸਟਰੀ।

ਆਰਟੀਫੈਕਟ ਫਾਰਮੈਟ ਦੇ ਸਮਾਨ ਹੈ ਪਾਲਿਸੀ ਏਜੰਟ ਪੈਕੇਜ ਖੋਲ੍ਹੋ (OPA), ਜੋ ਤੁਹਾਨੂੰ ਮੌਜੂਦਾ OPA ਪੈਕੇਜਾਂ ਤੋਂ ਟੈਸਟਾਂ ਨੂੰ ਚਲਾਉਣ ਲਈ ਕਨਫੈਸਟ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

ਤੁਸੀਂ ਨੀਤੀ ਸ਼ੇਅਰਿੰਗ ਅਤੇ ਕਾਂਟੈਸਟ ਦੀਆਂ ਹੋਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਬਾਰੇ ਇੱਥੇ ਹੋਰ ਜਾਣ ਸਕਦੇ ਹੋ ਅਧਿਕਾਰਤ ਪ੍ਰੋਜੈਕਟ ਵੈਬਸਾਈਟ.

6. ਪੋਲਾਰਿਸ

ਇਸ ਲੇਖ ਵਿਚ ਚਰਚਾ ਕੀਤੀ ਜਾਵੇਗੀ, ਜੋ ਕਿ ਆਖਰੀ ਸੰਦ ਹੈ ਪੋਲਰਿਸ. (ਉਸਦੀ ਪਿਛਲੇ ਸਾਲ ਦੀ ਘੋਸ਼ਣਾ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਅਨੁਵਾਦ ਕੀਤਾ ਗਿਆ ਹੈ - ਲਗਭਗ ਅਨੁਵਾਦ)

ਪੋਲਾਰਿਸ ਨੂੰ ਇੱਕ ਕਲੱਸਟਰ ਵਿੱਚ ਸਥਾਪਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜਾਂ ਕਮਾਂਡ ਲਾਈਨ ਮੋਡ ਵਿੱਚ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਅਨੁਮਾਨ ਲਗਾਇਆ ਹੋਵੇਗਾ, ਇਹ ਤੁਹਾਨੂੰ ਕੁਬਰਨੇਟਸ ਮੈਨੀਫੈਸਟਸ ਦਾ ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ।

ਕਮਾਂਡ ਲਾਈਨ ਮੋਡ ਵਿੱਚ ਚੱਲਣ ਵੇਲੇ, ਬਿਲਟ-ਇਨ ਟੈਸਟ ਸੁਰੱਖਿਆ ਅਤੇ ਵਧੀਆ ਅਭਿਆਸਾਂ (ਕਿਊਬ-ਸਕੋਰ ਦੇ ਸਮਾਨ) ਵਰਗੇ ਖੇਤਰਾਂ ਨੂੰ ਕਵਰ ਕਰਨ ਲਈ ਉਪਲਬਧ ਹੁੰਦੇ ਹਨ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਤੁਸੀਂ ਆਪਣੇ ਖੁਦ ਦੇ ਟੈਸਟ ਬਣਾ ਸਕਦੇ ਹੋ (ਜਿਵੇਂ ਕਿ 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

ਪੋਲਾਰਿਸ ਕਸਟਮ ਟੈਸਟਾਂ ਦੇ ਨਾਲ ਬਿਲਟ-ਇਨ ਟੈਸਟਾਂ ਦੀ ਪੂਰਤੀ ਕਰਦਾ ਹੈ, ਇਸ ਤਰ੍ਹਾਂ ਦੋਵਾਂ ਸੰਸਾਰਾਂ ਦੇ ਸਭ ਤੋਂ ਵਧੀਆ ਨੂੰ ਜੋੜਦਾ ਹੈ।

ਦੂਜੇ ਪਾਸੇ, ਰੇਗੋ ਜਾਂ ਜਾਵਾ ਸਕ੍ਰਿਪਟ ਵਰਗੀਆਂ ਵਧੇਰੇ ਸ਼ਕਤੀਸ਼ਾਲੀ ਭਾਸ਼ਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਅਸਮਰੱਥਾ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਟੈਸਟਾਂ ਦੀ ਸਿਰਜਣਾ ਨੂੰ ਰੋਕਣ ਲਈ ਇੱਕ ਸੀਮਤ ਕਾਰਕ ਹੋ ਸਕਦੀ ਹੈ।

ਪੋਲਾਰਿਸ ਬਾਰੇ ਹੋਰ ਜਾਣਕਾਰੀ ਇੱਥੇ ਉਪਲਬਧ ਹੈ ਪ੍ਰੋਜੈਕਟ ਦੀ ਵੈੱਬਸਾਈਟ.

ਸੰਖੇਪ

ਜਦੋਂ ਕਿ ਕੁਬਰਨੇਟਸ YAML ਫਾਈਲਾਂ ਦਾ ਮੁਆਇਨਾ ਅਤੇ ਮੁਲਾਂਕਣ ਕਰਨ ਲਈ ਬਹੁਤ ਸਾਰੇ ਸਾਧਨ ਉਪਲਬਧ ਹਨ, ਟੈਸਟਾਂ ਨੂੰ ਕਿਵੇਂ ਡਿਜ਼ਾਇਨ ਅਤੇ ਲਾਗੂ ਕੀਤਾ ਜਾਵੇਗਾ ਇਸ ਬਾਰੇ ਸਪਸ਼ਟ ਸਮਝ ਹੋਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ.

ਮਿਸਾਲ ਲਈ, ਜੇਕਰ ਤੁਸੀਂ ਪਾਈਪਲਾਈਨ ਵਿੱਚੋਂ ਲੰਘ ਰਹੇ ਕੁਬਰਨੇਟਸ ਮੈਨੀਫੈਸਟਸ ਨੂੰ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਕੁਬੇਵਾਲ ਅਜਿਹੀ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਪਹਿਲਾ ਕਦਮ ਹੋ ਸਕਦਾ ਹੈ।. ਇਹ ਨਿਗਰਾਨੀ ਕਰੇਗਾ ਕਿ ਕੀ ਆਬਜੈਕਟ ਪਰਿਭਾਸ਼ਾ Kubernetes API ਸਕੀਮਾ ਦੇ ਅਨੁਕੂਲ ਹੈ ਜਾਂ ਨਹੀਂ।

ਇੱਕ ਵਾਰ ਜਦੋਂ ਅਜਿਹੀ ਸਮੀਖਿਆ ਪੂਰੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਕੋਈ ਹੋਰ ਵਧੀਆ ਟੈਸਟਾਂ ਵੱਲ ਵਧ ਸਕਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਮਿਆਰੀ ਵਧੀਆ ਅਭਿਆਸਾਂ ਅਤੇ ਖਾਸ ਨੀਤੀਆਂ ਦੀ ਪਾਲਣਾ। ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਕਿਊਬ-ਸਕੋਰ ਅਤੇ ਪੋਲਾਰਿਸ ਕੰਮ ਆਉਣਗੇ।

ਉਹਨਾਂ ਲਈ ਜਿਹਨਾਂ ਦੀਆਂ ਗੁੰਝਲਦਾਰ ਲੋੜਾਂ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਵਿਸਥਾਰ ਵਿੱਚ ਟੈਸਟਾਂ ਨੂੰ ਅਨੁਕੂਲਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂਬਾ, ਕੌਂਫਿਗ-ਲਿੰਟ ਅਤੇ ਕਨਫੈਸਟ ਢੁਕਵੇਂ ਹੋਣਗੇ।.

Confest ਅਤੇ config-lint ਕਸਟਮ ਟੈਸਟਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਲਈ YAML ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਅਤੇ ਕਾਪਰ ਤੁਹਾਨੂੰ ਇੱਕ ਪੂਰੀ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਭਾਸ਼ਾ ਤੱਕ ਪਹੁੰਚ ਦਿੰਦਾ ਹੈ, ਇਸ ਨੂੰ ਇੱਕ ਬਹੁਤ ਹੀ ਆਕਰਸ਼ਕ ਵਿਕਲਪ ਬਣਾਉਂਦਾ ਹੈ।

ਦੂਜੇ ਪਾਸੇ, ਕੀ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਇੱਕ ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਅਤੇ ਇਸਲਈ, ਸਾਰੇ ਟੈਸਟਾਂ ਨੂੰ ਹੱਥੀਂ ਬਣਾਉਣਾ, ਜਾਂ ਪੋਲਾਰਿਸ ਨੂੰ ਤਰਜੀਹ ਦੇਣਾ ਅਤੇ ਸਿਰਫ਼ ਉਹੀ ਜੋੜਨਾ ਹੈ ਜੋ ਇਸ ਵਿੱਚ ਲੋੜੀਂਦਾ ਹੈ? ਇਸ ਸਵਾਲ ਦਾ ਕੋਈ ਸਪੱਸ਼ਟ ਜਵਾਬ ਨਹੀਂ ਹੈ.

ਹੇਠਾਂ ਦਿੱਤੀ ਸਾਰਣੀ ਹਰੇਕ ਟੂਲ ਦਾ ਸੰਖੇਪ ਵਰਣਨ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ:

ਟੂਲ
ਉਦੇਸ਼
shortcomings
ਉਪਭੋਗਤਾ ਟੈਸਟ

ਕੁਬੇਵਾਲ
API ਸਕੀਮਾ ਦੇ ਇੱਕ ਖਾਸ ਸੰਸਕਰਣ ਦੇ ਵਿਰੁੱਧ YAML ਪ੍ਰਗਟਾਵੇ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ
CRD ਨਾਲ ਕੰਮ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ
ਕੋਈ

kube-ਸਕੋਰ
ਸਭ ਤੋਂ ਵਧੀਆ ਅਭਿਆਸਾਂ ਦੇ ਵਿਰੁੱਧ YAML ਪ੍ਰਗਟਾਵੇ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦਾ ਹੈ
ਸਰੋਤਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਤੁਹਾਡੇ Kubernetes API ਸੰਸਕਰਣ ਦੀ ਚੋਣ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ
ਕੋਈ

ਤਾਂਬਾ
YAML ਮੈਨੀਫੈਸਟ ਲਈ ਕਸਟਮ JavaScript ਟੈਸਟ ਬਣਾਉਣ ਲਈ ਇੱਕ ਆਮ ਫਰੇਮਵਰਕ
ਕੋਈ ਬਿਲਟ-ਇਨ ਟੈਸਟ ਨਹੀਂ ਹਨ। ਖਰਾਬ ਦਸਤਾਵੇਜ਼
ਜੀ

config-lint
YAML ਵਿੱਚ ਏਮਬੇਡ ਕੀਤੀ ਇੱਕ ਡੋਮੇਨ-ਵਿਸ਼ੇਸ਼ ਭਾਸ਼ਾ ਵਿੱਚ ਟੈਸਟ ਬਣਾਉਣ ਲਈ ਇੱਕ ਆਮ ਫਰੇਮਵਰਕ। ਵੱਖ-ਵੱਖ ਸੰਰਚਨਾ ਫਾਰਮੈਟਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ (ਜਿਵੇਂ ਕਿ ਟੈਰਾਫਾਰਮ)
ਕੋਈ ਰੈਡੀਮੇਡ ਟੈਸਟ ਨਹੀਂ ਹਨ। ਬਿਲਟ-ਇਨ ਦਾਅਵੇ ਅਤੇ ਫੰਕਸ਼ਨ ਕਾਫ਼ੀ ਨਹੀਂ ਹੋ ਸਕਦੇ ਹਨ
ਜੀ

ਮੁਕਾਬਲਾ
ਰੇਗੋ (ਇੱਕ ਵਿਸ਼ੇਸ਼ ਪੁੱਛਗਿੱਛ ਭਾਸ਼ਾ) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਤੁਹਾਡੇ ਆਪਣੇ ਟੈਸਟ ਬਣਾਉਣ ਲਈ ਇੱਕ ਢਾਂਚਾ। OCI ਬੰਡਲਾਂ ਰਾਹੀਂ ਨੀਤੀਆਂ ਨੂੰ ਸਾਂਝਾ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ
ਕੋਈ ਬਿਲਟ-ਇਨ ਟੈਸਟ ਨਹੀਂ ਹਨ। ਮੈਨੂੰ ਰੈਗੋ ਸਿੱਖਣਾ ਹੈ। ਨੀਤੀਆਂ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਵੇਲੇ ਡੌਕਰ ਹੱਬ ਸਮਰਥਿਤ ਨਹੀਂ ਹੈ
ਜੀ

ਪੋਲਰਿਸ
ਸਮੀਖਿਆਵਾਂ YAML ਮਿਆਰੀ ਵਧੀਆ ਅਭਿਆਸਾਂ ਦੇ ਵਿਰੁੱਧ ਪ੍ਰਗਟ ਹੁੰਦਾ ਹੈ। ਤੁਹਾਨੂੰ JSON ਸਕੀਮਾ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਆਪਣੇ ਖੁਦ ਦੇ ਟੈਸਟ ਬਣਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ
JSON ਸਕੀਮਾ 'ਤੇ ਆਧਾਰਿਤ ਟੈਸਟ ਸਮਰੱਥਾਵਾਂ ਕਾਫ਼ੀ ਨਹੀਂ ਹੋ ਸਕਦੀਆਂ
ਜੀ

ਕਿਉਂਕਿ ਇਹ ਟੂਲ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਤੱਕ ਪਹੁੰਚ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਕਰਦੇ ਹਨ, ਇਹ ਇੰਸਟਾਲ ਕਰਨ ਲਈ ਆਸਾਨ ਹਨ। ਉਹ ਤੁਹਾਨੂੰ ਸਰੋਤ ਫਾਈਲਾਂ ਨੂੰ ਫਿਲਟਰ ਕਰਨ ਅਤੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਪੁੱਲ ਬੇਨਤੀਆਂ ਦੇ ਲੇਖਕਾਂ ਨੂੰ ਤੁਰੰਤ ਫੀਡਬੈਕ ਪ੍ਰਦਾਨ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹਨ.

ਅਨੁਵਾਦਕ ਤੋਂ ਪੀ.ਐਸ

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਵੀ ਪੜ੍ਹੋ:

• «ਪੋਲਾਰਿਸ ਨੂੰ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰਾਂ ਨੂੰ ਸਿਹਤਮੰਦ ਰੱਖਣ ਲਈ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ";
• «ਕੁਬਰਨੇਟਸ ਲਈ YAML ਸਮਰਥਨ ਨਾਲ ਵਿਮ";
• «ਗੂਗਲ ਦੇ ਅਨੁਸਾਰ ਕੰਟੇਨਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ 7 ਸਭ ਤੋਂ ਵਧੀਆ ਅਭਿਆਸ".

ਸਰੋਤ: www.habr.com