શ્રેષ્ઠ પ્રથાઓ અને નીતિઓ સામે કુબરનેટ્સ YAML ને માન્ય કરો

નૉૅધ. અનુવાદ: K8s પર્યાવરણો માટે YAML રૂપરેખાંકનોની વધતી જતી સંખ્યા સાથે, તેમની સ્વચાલિત ચકાસણીની જરૂરિયાત વધુને વધુ તાકીદની બની રહી છે. આ સમીક્ષાના લેખકે આ કાર્ય માટે માત્ર હાલના સોલ્યુશન્સ જ પસંદ કર્યા નથી, પરંતુ ઉદાહરણ તરીકે ડિપ્લોયમેન્ટનો ઉપયોગ કરીને તેઓ કેવી રીતે કાર્ય કરે છે તે પણ જોયું છે. આ વિષયમાં રસ ધરાવતા લોકો માટે તે ખૂબ જ માહિતીપ્રદ હોવાનું બહાર આવ્યું છે.

TL; DR: આ લેખ શ્રેષ્ઠ પ્રયાસો અને આવશ્યકતાઓ સામે કુબરનેટ્સ YAML ફાઇલોને માન્ય અને મૂલ્યાંકન કરવા માટે છ સ્થિર સાધનોની તુલના કરે છે.

કુબરનેટ્સ વર્કલોડ સામાન્ય રીતે YAML દસ્તાવેજોના સ્વરૂપમાં વ્યાખ્યાયિત કરવામાં આવે છે. YAML ની ​​સમસ્યાઓમાંની એક મેનિફેસ્ટ ફાઇલો વચ્ચેના અવરોધો અથવા સંબંધોને સ્પષ્ટ કરવામાં મુશ્કેલી છે.

જો આપણે ખાતરી કરવાની જરૂર હોય કે ક્લસ્ટરમાં જમાવવામાં આવેલી બધી છબીઓ વિશ્વસનીય રજિસ્ટ્રીમાંથી આવે છે?

PodDisruptionBudgets ન હોય તેવા ડિપ્લોયમેન્ટને હું ક્લસ્ટરમાં મોકલતા કેવી રીતે રોકી શકું?

સ્ટેટિક ટેસ્ટિંગનું એકીકરણ તમને વિકાસના તબક્કે ભૂલો અને નીતિના ઉલ્લંઘનોને ઓળખવા દે છે. આ બાંયધરી વધારે છે કે સંસાધન વ્યાખ્યાઓ સાચી અને સુરક્ષિત છે, અને ઉત્પાદન વર્કલોડ શ્રેષ્ઠ પ્રથાઓનું પાલન કરશે તેવી શક્યતા વધારે છે.

કુબરનેટ્સ સ્ટેટિક YAML ફાઇલ નિરીક્ષણ ઇકોસિસ્ટમને નીચેની શ્રેણીઓમાં વિભાજિત કરી શકાય છે:

• API માન્યકર્તાઓ. આ કેટેગરીના સાધનો કુબરનેટ્સ API સર્વરની જરૂરિયાતો સામે YAML મેનિફેસ્ટ તપાસે છે.
• તૈયાર પરીક્ષકો. આ કેટેગરીના સાધનો સુરક્ષા, શ્રેષ્ઠ પ્રથાઓનું પાલન વગેરે માટે તૈયાર પરીક્ષણો સાથે આવે છે.
• કસ્ટમ માન્યકર્તાઓ. આ કેટેગરીના પ્રતિનિધિઓ તમને વિવિધ ભાષાઓમાં કસ્ટમ પરીક્ષણો બનાવવાની મંજૂરી આપે છે, ઉદાહરણ તરીકે, રેગો અને જાવાસ્ક્રિપ્ટ.

આ લેખમાં આપણે છ જુદા જુદા સાધનોનું વર્ણન અને તુલના કરીશું:

1. કુબેવલ;
2. ક્યુબ-સ્કોર;
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 અને આ લેખમાંથી અન્ય મેનિફેસ્ટોમાં મળી શકે છે ગિટ રીપોઝીટરીઝ.

મેનિફેસ્ટ એક વેબ એપ્લિકેશનનું વર્ણન કરે છે જેનું મુખ્ય કાર્ય પોર્ટ 5678 પર "હેલો વર્લ્ડ" સંદેશ સાથે પ્રતિસાદ આપવાનું છે. તેને નીચેના આદેશ સાથે ગોઠવી શકાય છે:

kubectl apply -f hello-world.yaml

અને તેથી - કાર્ય તપાસો:

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

હવે પર જાઓ http://localhost:8080 અને ખાતરી કરો કે એપ્લિકેશન કામ કરી રહી છે. પરંતુ શું તે શ્રેષ્ઠ પ્રયાસોનું પાલન કરે છે? ચાલો તપાસીએ.

1. કુબેવલ

ના હૃદય પર કુબેવલ વિચાર એ છે કે કુબરનેટ્સ સાથેની કોઈપણ ક્રિયાપ્રતિક્રિયા તેના REST API દ્વારા થાય છે. બીજા શબ્દોમાં કહીએ તો, આપેલ YAML તેનું અનુરૂપ છે કે કેમ તે તપાસવા માટે તમે API સ્કીમાનો ઉપયોગ કરી શકો છો. ચાલો એક ઉદાહરણ જોઈએ.

સ્થાપન સૂચનો કુબેવલ પ્રોજેક્ટ વેબસાઇટ પર ઉપલબ્ધ છે.

મૂળ લેખ લખતી વખતે, સંસ્કરણ 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)

કુબેવલ જેવા સાધનોનો ફાયદો એ છે કે આના જેવી ભૂલોને જમાવટ ચક્રમાં વહેલી પકડી શકાય છે.

વધુમાં, આ તપાસોને ક્લસ્ટરની ઍક્સેસની જરૂર નથી; તેઓ ઑફલાઇન કરી શકાય છે.

મૂળભૂત રીતે, કુબેવલ નવીનતમ Kubernetes API સ્કીમા સામે સંસાધનોની તપાસ કરે છે. જો કે, મોટા ભાગના કિસ્સાઓમાં તમારે ચોક્કસ કુબરનેટ્સ રિલીઝ સામે તપાસ કરવાની જરૂર પડી શકે છે. આ ધ્વજનો ઉપયોગ કરીને કરી શકાય છે --kubernetes-version:

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

કૃપા કરીને નોંધો કે સંસ્કરણ ફોર્મેટમાં ઉલ્લેખિત હોવું આવશ્યક છે Major.Minor.Patch.

સંસ્કરણોની સૂચિ માટે કે જેના માટે ચકાસણી સમર્થિત છે, કૃપા કરીને સંદર્ભ લો GitHub પર JSON સ્કીમા, જેનો કુબેવલ માન્યતા માટે ઉપયોગ કરે છે. જો તમારે કુબેવલ ઑફલાઇન ચલાવવાની જરૂર હોય, તો સ્કીમા ડાઉનલોડ કરો અને ફ્લેગનો ઉપયોગ કરીને તેમનું સ્થાનિક સ્થાન સ્પષ્ટ કરો --schema-location.

વ્યક્તિગત YAML ફાઇલો ઉપરાંત, kubeval ડિરેક્ટરીઓ અને stdin સાથે પણ કામ કરી શકે છે.

વધુમાં, કુબેવલ સરળતાથી CI પાઇપલાઇનમાં એકીકૃત થાય છે. ક્લસ્ટરમાં મેનિફેસ્ટ મોકલતા પહેલા પરીક્ષણો ચલાવવા ઈચ્છતા લોકોને એ જાણીને આનંદ થશે કે કુબેવલ ત્રણ આઉટપુટ ફોર્મેટને સપોર્ટ કરે છે:

1. સાદો લખાણ;
2. JSON;
3. કંઈપણ પ્રોટોકોલનું પરીક્ષણ કરો (TAP).

અને ઇચ્છિત પ્રકારના પરિણામોનો સારાંશ જનરેટ કરવા માટે આઉટપુટના વધુ પદચ્છેદન માટે કોઈપણ ફોર્મેટનો ઉપયોગ કરી શકાય છે.

કુબેવલની ખામીઓમાંની એક એ છે કે તે હાલમાં કસ્ટમ રિસોર્સ ડેફિનેશન (CRDs) સાથે અનુપાલન માટે તપાસ કરી શકતું નથી. જો કે, કુબેવલને રૂપરેખાંકિત કરવું શક્ય છે તેમને અવગણો.

કુબેવલ એ સંસાધનોની ચકાસણી અને મૂલ્યાંકન માટેનું એક ઉત્તમ સાધન છે; જો કે, એ વાત પર ભાર મૂકવો જોઈએ કે પરીક્ષણ પાસ કરવું એ બાંહેધરી આપતું નથી કે સંસાધન શ્રેષ્ઠ પ્રથાઓનું પાલન કરે છે.

ઉદાહરણ તરીકે, ટેગનો ઉપયોગ કરીને latest કન્ટેનરમાં શ્રેષ્ઠ પ્રયાસોનું પાલન કરતું નથી. જો કે, કુબેવાલ આને ભૂલ માનતા નથી અને તેની જાણ કરતા નથી. એટલે કે, આવા YAML ની ​​ચકાસણી ચેતવણી વિના પૂર્ણ થશે.

પરંતુ જો તમે YAML નું મૂલ્યાંકન કરવા અને ટેગ જેવા ઉલ્લંઘનોને ઓળખવા માંગતા હોવ તો શું કરવું latest? શ્રેષ્ઠ પ્રથાઓ સામે હું YAML ફાઇલ કેવી રીતે તપાસું?

2. કુબે-સ્કોર

કુબે-સ્કોર YAML મેનિફેસ્ટને પાર્સ કરે છે અને બિલ્ટ-ઇન પરીક્ષણો સામે તેનું મૂલ્યાંકન કરે છે. આ પરીક્ષણો સુરક્ષા દિશાનિર્દેશો અને શ્રેષ્ઠ પ્રયાસોના આધારે પસંદ કરવામાં આવે છે, જેમ કે:

• બિન-રુટ વપરાશકર્તા તરીકે કન્ટેનર ચલાવવું.
• પોડ આરોગ્ય તપાસની ઉપલબ્ધતા.
• સંસાધનો માટેની વિનંતીઓ અને મર્યાદાઓ સુયોજિત કરવી.

પરીક્ષણ પરિણામોના આધારે, ત્રણ પરિણામો આપવામાં આવે છે: OK, ચેતવણી и ક્રિટિકલ.

તમે કુબે-સ્કોરને ઑનલાઇન અજમાવી શકો છો અથવા તેને સ્થાનિક રીતે ઇન્સ્ટોલ કરી શકો છો.

મૂળ લેખ લખતી વખતે, કુબે-સ્કોરનું નવીનતમ સંસ્કરણ 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 તમામ પ્રકારના ઉલ્લંઘનો સહિત માનવ વાંચી શકાય તેવા સ્વરૂપમાં માહિતી પ્રદર્શિત કરે છે ચેતવણી и ક્રિટિકલ, જે વિકાસ દરમિયાન ઘણી મદદ કરે છે.

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

કુબેવલની જેમ જ, કુબે-સ્કોર બિન-શૂન્ય એક્ઝિટ કોડ આપે છે જ્યારે કોઈ પરીક્ષણ નિષ્ફળ જાય છે ક્રિટિકલ. તમે માટે સમાન પ્રક્રિયાને સક્ષમ પણ કરી શકો છો ચેતવણી.

વધુમાં, વિવિધ 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 - કદાચ નિષ્ફળતા, ચેતવણી и બિન સુસંગત;
• 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 વૈવિધ્યપૂર્ણ પરીક્ષણોનો ઉપયોગ કરીને મેનિફેસ્ટને માન્ય કરવા માટેનું માળખું છે (કોન્ફિગ-લિન્ટ જેવું જ).

જો કે, તે પછીના કરતા અલગ છે કે તે પરીક્ષણોનું વર્ણન કરવા માટે YAML નો ઉપયોગ કરતું નથી. તેના બદલે જાવાસ્ક્રિપ્ટમાં ટેસ્ટ લખી શકાય છે. કોપર ઘણા મૂળભૂત સાધનો સાથે પુસ્તકાલય પૂરું પાડે છે, જે તમને કુબરનેટ્સ ઑબ્જેક્ટ્સ વિશેની માહિતી વાંચવામાં અને ભૂલોની જાણ કરવામાં મદદ કરે છે.

કોપર ઇન્સ્ટોલ કરવાનાં પગલાંઓ આમાં મળી શકે છે સત્તાવાર દસ્તાવેજીકરણ.

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

તે સ્પષ્ટ છે કે કોપરની મદદથી તમે વધુ જટિલ પરીક્ષણો કરી શકો છો - ઉદાહરણ તરીકે, ઇન્ગ્રેસ મેનિફેસ્ટમાં ડોમેન નામો તપાસવા અથવા વિશેષાધિકૃત મોડમાં ચાલતા પોડ્સને નકારવા.

કોપરમાં વિવિધ ઉપયોગિતા કાર્યો છે જે તેમાં બનેલ છે:

• DockerImage ઉલ્લેખિત ઇનપુટ ફાઇલ વાંચે છે અને નીચેના લક્ષણો સાથે એક ઑબ્જેક્ટ બનાવે છે:
  • name - છબીનું નામ,
  • tag - છબી ટેગ,
  • registry - છબી રજિસ્ટ્રી,
  • registry_url - પ્રોટોકોલ (https://) અને ઇમેજ રજિસ્ટ્રી,
  • fqin - છબીનું સંપૂર્ણ સ્થાન.
• કાર્ય findByName આપેલ પ્રકાર દ્વારા સંસાધન શોધવામાં મદદ કરે છે (kind) અને નામ (name) ઇનપુટ ફાઇલમાંથી.
• કાર્ય findByLabels ઉલ્લેખિત પ્રકાર દ્વારા સંસાધન શોધવામાં મદદ કરે છે (kind) અને લેબલ્સ (labels).

તમે બધા ઉપલબ્ધ સેવા કાર્યો જોઈ શકો છો અહીં.

મૂળભૂત રીતે તે સમગ્ર ઇનપુટ YAML ફાઇલને ચલમાં લોડ કરે છે $$ અને તેને સ્ક્રિપ્ટીંગ માટે ઉપલબ્ધ બનાવે છે (jQuery અનુભવ ધરાવતા લોકો માટે એક પરિચિત ટેકનિક).

કોપરનો મુખ્ય ફાયદો સ્પષ્ટ છે: તમારે વિશિષ્ટ ભાષામાં નિપુણતા મેળવવાની જરૂર નથી અને તમે તમારા પોતાના પરીક્ષણો બનાવવા માટે વિવિધ JavaScript સુવિધાઓનો ઉપયોગ કરી શકો છો, જેમ કે સ્ટ્રિંગ ઇન્ટરપોલેશન, ફંક્શન્સ વગેરે.

એ પણ નોંધવું જોઈએ કે કોપરનું વર્તમાન સંસ્કરણ JavaScript એન્જિનના ES5 સંસ્કરણ સાથે કામ કરે છે, ES6 સાથે નહીં.

પર ઉપલબ્ધ વિગતો સત્તાવાર પ્રોજેક્ટ વેબસાઇટ.

જો કે, જો તમને ખરેખર JavaScript પસંદ ન હોય અને ક્વેરી બનાવવા અને નીતિઓનું વર્ણન કરવા માટે ખાસ રચાયેલ ભાષા પસંદ કરો, તો તમારે કોન્ટેસ્ટ પર ધ્યાન આપવું જોઈએ.

5. કોન્ફેસ્ટ

કોન્ફટેસ્ટ એ રૂપરેખાંકન ડેટાના પરીક્ષણ માટેનું માળખું છે. Kubernetes મેનિફેસ્ટની ચકાસણી/ચકાસણી માટે પણ યોગ્ય. પરીક્ષણોનું વર્ણન વિશિષ્ટ ક્વેરી ભાષાનો ઉપયોગ કરીને કરવામાં આવે છે રેગો.

તમે confest નો ઉપયોગ કરીને ઇન્સ્ટોલ કરી શકો છો સૂચનાઓપ્રોજેક્ટ વેબસાઇટ પર સૂચિબદ્ધ.

મૂળ લેખ લખતી વખતે, ઉપલબ્ધ નવીનતમ સંસ્કરણ 0.18.2 હતું.

config-lint અને copper ની જેમ જ, કોન્ટેસ્ટ કોઈપણ બિલ્ટ-ઇન ટેસ્ટ વિના આવે છે. ચાલો તેને અજમાવીએ અને આપણી પોતાની નીતિ લખીએ. અગાઉના ઉદાહરણોની જેમ, અમે તપાસ કરીશું કે કન્ટેનરની છબીઓ વિશ્વસનીય સ્ત્રોતમાંથી લેવામાં આવી છે કે કેમ.

ડિરેક્ટરી બનાવો 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. પોલારિસ

આ લેખમાં ચર્ચા કરવામાં આવશે તે છેલ્લું સાધન છે પોલારિસ. (તેમની ગયા વર્ષની જાહેરાત અમે પહેલેથી જ અનુવાદિત - આશરે અનુવાદ)

પોલારિસને ક્લસ્ટરમાં ઇન્સ્ટોલ કરી શકાય છે અથવા કમાન્ડ લાઇન મોડમાં ઉપયોગ કરી શકાય છે. જેમ તમે અનુમાન લગાવ્યું હશે, તે તમને કુબરનેટ્સ મેનિફેસ્ટનું સ્ટેટિકલી વિશ્લેષણ કરવાની મંજૂરી આપે છે.

જ્યારે કમાન્ડ લાઇન મોડમાં ચાલી રહ્યું હોય, ત્યારે બિલ્ટ-ઇન ટેસ્ટ ઉપલબ્ધ હોય છે જેમાં સુરક્ષા અને શ્રેષ્ઠ પ્રેક્ટિસ (કુબે-સ્કોરની જેમ) જેવા ક્ષેત્રોને આવરી લેવામાં આવે છે. વધુમાં, તમે તમારા પોતાના પરીક્ષણો બનાવી શકો છો (જેમ કે રૂપરેખા-લિંટ, કોપર અને કોન્ફેસ્ટમાં).

બીજા શબ્દોમાં કહીએ તો, પોલારિસ ટૂલ્સની બંને શ્રેણીઓના ફાયદાઓને જોડે છે: બિલ્ટ-ઇન અને કસ્ટમ પરીક્ષણો સાથે.

કમાન્ડ લાઇન મોડમાં પોલારિસ ઇન્સ્ટોલ કરવા માટે, ઉપયોગ કરો પ્રોજેક્ટ વેબસાઇટ પર સૂચનાઓ.

મૂળ લેખ લખતી વખતે, સંસ્કરણ 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 ફાઇલોનું નિરીક્ષણ અને મૂલ્યાંકન કરવા માટે ઘણા સાધનો ઉપલબ્ધ છે, પરીક્ષણોની રચના અને અમલ કેવી રીતે કરવામાં આવશે તેની સ્પષ્ટ સમજ હોવી મહત્વપૂર્ણ છે.

ઉદાહરણ તરીકે, જો તમે પાઇપલાઇનમાંથી પસાર થતા કુબરનેટ્સ મેનિફેસ્ટ લો છો, તો કુબેવલ આવી પાઇપલાઇનમાં પ્રથમ પગલું હોઈ શકે છે. તે ઑબ્જેક્ટ વ્યાખ્યાઓ કુબરનેટ્સ API સ્કીમાને અનુરૂપ છે કે કેમ તેનું નિરીક્ષણ કરશે.

એકવાર આવી સમીક્ષા પૂર્ણ થઈ જાય પછી, વ્યક્તિ વધુ અત્યાધુનિક પરીક્ષણો તરફ આગળ વધી શકે છે, જેમ કે પ્રમાણભૂત શ્રેષ્ઠ પ્રથાઓ અને ચોક્કસ નીતિઓનું પાલન. આ તે છે જ્યાં કુબે-સ્કોર અને પોલારિસ કામમાં આવશે.

જેઓ જટિલ આવશ્યકતાઓ ધરાવે છે અને વિગતવાર પરીક્ષણોને કસ્ટમાઇઝ કરવાની જરૂર છે તેમના માટે, કોપર, કોન્ફિગ-લિન્ટ અને કોન્ફેસ્ટ યોગ્ય રહેશે..

કન્ફટેસ્ટ અને રૂપરેખા-લિન્ટ કસ્ટમ પરીક્ષણોને વ્યાખ્યાયિત કરવા માટે YAML નો ઉપયોગ કરે છે, અને કોપર તમને સંપૂર્ણ પ્રોગ્રામિંગ ભાષાની ઍક્સેસ આપે છે, જે તેને એક સુંદર આકર્ષક પસંદગી બનાવે છે.

બીજી બાજુ, શું આમાંથી કોઈ એક ટૂલનો ઉપયોગ કરવા યોગ્ય છે અને તેથી, જાતે જ તમામ પરીક્ષણો બનાવવી, અથવા પોલારિસને પ્રાધાન્ય આપવું અને તેમાં જે જરૂરી છે તે જ ઉમેરો? આ પ્રશ્નનો કોઈ સ્પષ્ટ જવાબ નથી.

નીચેનું કોષ્ટક દરેક સાધનનું સંક્ષિપ્ત વર્ણન પ્રદાન કરે છે:

ટૂલ
લક્ષ્યસ્થાન
ખામીઓ
વપરાશકર્તા પરીક્ષણો

કુબેવલ
API સ્કીમાના ચોક્કસ સંસ્કરણ સામે YAML મેનિફેસ્ટને માન્ય કરે છે
CRD સાથે કામ કરી શકાતું નથી
કોઈ

કુબે-સ્કોર
શ્રેષ્ઠ પ્રથાઓ સામે YAML મેનીફેસ્ટનું વિશ્લેષણ કરે છે
સંસાધનો તપાસવા માટે તમારું Kubernetes API સંસ્કરણ પસંદ કરી શકતાં નથી
કોઈ

તાંબુ
YAML મેનિફેસ્ટ માટે કસ્ટમ JavaScript પરીક્ષણો બનાવવા માટેનું સામાન્ય માળખું
કોઈ બિલ્ટ-ઇન પરીક્ષણો નથી. નબળા દસ્તાવેજીકરણ
હા

config-lint
YAML માં એમ્બેડ કરેલી ડોમેન-વિશિષ્ટ ભાષામાં પરીક્ષણો બનાવવા માટેનું સામાન્ય માળખું. વિવિધ રૂપરેખાંકન ફોર્મેટને સપોર્ટ કરે છે (દા.ત. ટેરાફોર્મ)
ત્યાં કોઈ તૈયાર પરીક્ષણો નથી. બિલ્ટ-ઇન નિવેદનો અને કાર્યો પૂરતા ન હોઈ શકે
હા

હરીફાઈ
રેગો (એક વિશિષ્ટ ક્વેરી ભાષા) નો ઉપયોગ કરીને તમારા પોતાના પરીક્ષણો બનાવવા માટેનું માળખું. OCI બંડલ્સ દ્વારા પોલિસી શેર કરવાની મંજૂરી આપે છે
કોઈ બિલ્ટ-ઇન પરીક્ષણો નથી. મારે રેગો શીખવો છે. નીતિઓ પ્રકાશિત કરતી વખતે ડોકર હબ સમર્થિત નથી
હા

પોલારિસ
સમીક્ષાઓ YAML પ્રમાણભૂત શ્રેષ્ઠ પ્રથાઓ સામે મેનીફેસ્ટ કરે છે. તમને JSON સ્કીમાનો ઉપયોગ કરીને તમારા પોતાના પરીક્ષણો બનાવવાની મંજૂરી આપે છે
JSON સ્કીમા પર આધારિત પરીક્ષણ ક્ષમતાઓ પર્યાપ્ત ન હોઈ શકે
હા

કારણ કે આ સાધનો કુબરનેટ્સ ક્લસ્ટરની ઍક્સેસ પર આધાર રાખતા નથી, તેઓ ઇન્સ્ટોલ કરવા માટે સરળ છે. તેઓ તમને સ્રોત ફાઇલોને ફિલ્ટર કરવાની અને પ્રોજેક્ટ્સમાં પુલ વિનંતીઓના લેખકોને ઝડપી પ્રતિસાદ પ્રદાન કરવાની મંજૂરી આપે છે.

અનુવાદક તરફથી પીએસ

અમારા બ્લોગ પર પણ વાંચો:

• «પોલારિસે કુબરનેટ્સ ક્લસ્ટરોને સ્વસ્થ રાખવા માટે રજૂ કર્યું»;
• «Kubernetes માટે YAML સપોર્ટ સાથે Vim»;
• «Google અનુસાર કન્ટેનરનો ઉપયોગ કરવા માટેની 7 શ્રેષ્ઠ પદ્ધતિઓ».

સોર્સ: www.habr.com