ప్రోహోస్టర్ > బ్లాగ్ > పరిపాలన > ఉత్తమ పద్ధతులు మరియు విధానాలకు వ్యతిరేకంగా Kubernetes YAMLని ధృవీకరించండి
ఉత్తమ పద్ధతులు మరియు విధానాలకు వ్యతిరేకంగా Kubernetes YAMLని ధృవీకరించండి
గమనిక. అనువాదం.: K8s ఎన్విరాన్మెంట్ల కోసం YAML కాన్ఫిగరేషన్ల సంఖ్య పెరుగుతున్నందున, వాటి స్వయంచాలక ధృవీకరణ అవసరం మరింత అత్యవసరం అవుతుంది. ఈ సమీక్ష యొక్క రచయిత ఈ టాస్క్ కోసం ఇప్పటికే ఉన్న పరిష్కారాలను ఎంచుకోవడమే కాకుండా, అవి ఎలా పని చేస్తాయో చూడటానికి విస్తరణను ఉదాహరణగా ఉపయోగించారు. ఈ అంశంపై ఆసక్తి ఉన్నవారికి ఇది చాలా సమాచారంగా మారింది.
TL; DR: ఈ కథనం ఉత్తమ అభ్యాసాలు మరియు అవసరాలకు వ్యతిరేకంగా Kubernetes YAML ఫైల్లను ధృవీకరించడానికి మరియు మూల్యాంకనం చేయడానికి ఆరు స్టాటిక్ సాధనాలను పోల్చింది.
Kubernetes పనిభారం సాధారణంగా YAML పత్రాల రూపంలో నిర్వచించబడుతుంది. మానిఫెస్ట్ ఫైల్ల మధ్య పరిమితులు లేదా సంబంధాలను పేర్కొనడంలో ఇబ్బంది YAMLతో ఉన్న సమస్యల్లో ఒకటి.
క్లస్టర్కి అమర్చబడిన అన్ని చిత్రాలు విశ్వసనీయ రిజిస్ట్రీ నుండి వచ్చినట్లు మేము నిర్ధారించుకోవాల్సిన అవసరం ఉంటే?
PodDisruptionBdgets లేని డిప్లాయ్మెంట్లను క్లస్టర్కి పంపకుండా నేను ఎలా నిరోధించగలను?
స్టాటిక్ టెస్టింగ్ యొక్క ఏకీకరణ అభివృద్ధి దశలో లోపాలు మరియు విధాన ఉల్లంఘనలను గుర్తించడానికి మిమ్మల్ని అనుమతిస్తుంది. ఇది వనరుల నిర్వచనాలు సరైనవి మరియు సురక్షితమైనవి అనే హామీని పెంచుతుంది మరియు ఉత్పత్తి పనిభారం ఉత్తమ పద్ధతులను అనుసరించే అవకాశం ఎక్కువగా ఉంటుంది.
కుబెర్నెటెస్ స్టాటిక్ YAML ఫైల్ తనిఖీ పర్యావరణ వ్యవస్థను క్రింది వర్గాలుగా విభజించవచ్చు:
API వాలిడేటర్లు. ఈ వర్గంలోని సాధనాలు Kubernetes API సర్వర్ యొక్క అవసరాలకు వ్యతిరేకంగా YAML మానిఫెస్ట్ని తనిఖీ చేస్తాయి.
సిద్ధంగా పరీక్షకులు. ఈ కేటగిరీకి చెందిన సాధనాలు భద్రత, ఉత్తమ అభ్యాసాలకు అనుగుణంగా ఉండటం మొదలైన వాటి కోసం సిద్ధంగా ఉన్న పరీక్షలతో వస్తాయి.
కస్టమ్ వాలిడేటర్లు. ఈ వర్గం యొక్క ప్రతినిధులు వివిధ భాషలలో అనుకూల పరీక్షలను సృష్టించడానికి మిమ్మల్ని అనుమతిస్తారు, ఉదాహరణకు, రెగో మరియు జావాస్క్రిప్ట్.
ఈ వ్యాసంలో మేము ఆరు వేర్వేరు సాధనాలను వివరిస్తాము మరియు పోల్చాము:
కుబేవల్;
కుబే-స్కోరు;
config-lint;
రాగి;
ఘర్షణ;
పొలారిస్.
సరే, ప్రారంభిద్దాం!
విస్తరణలను తనిఖీ చేస్తోంది
మేము సాధనాలను పోల్చడం ప్రారంభించే ముందు, వాటిని పరీక్షించడానికి కొంత నేపథ్యాన్ని సృష్టించండి.
దిగువన ఉన్న మ్యానిఫెస్టోలో అనేక లోపాలు ఉన్నాయి మరియు ఉత్తమ అభ్యాసాలను పాటించకపోవడం: మీరు వాటిలో ఎన్ని కనుగొనగలరు?
విభిన్న సాధనాలను పోల్చడానికి మేము ఈ 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 ద్వారా జరుగుతుంది. మరో మాటలో చెప్పాలంటే, ఇచ్చిన YAML దానికి అనుగుణంగా ఉందో లేదో తనిఖీ చేయడానికి మీరు API స్కీమాను ఉపయోగించవచ్చు. ఒక ఉదాహరణ చూద్దాం.
సంస్థాపన సూచనలు 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తో kubeval నిష్క్రమిస్తుంది. మీరు దీన్ని ఈ క్రింది విధంగా తనిఖీ చేయవచ్చు:
$ echo $?
0
ఇప్పుడు వేరే మానిఫెస్ట్తో కుబేవల్ని ప్రయత్నిద్దాం:
మీరు కంటి ద్వారా సమస్యను గుర్తించగలరా? ప్రారంభిద్దాం:
$ 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, పాడ్ లేబుల్తో సరిపోలే సెలెక్టర్ని తప్పనిసరిగా చేర్చాలి. ఎగువ ఉన్న మానిఫెస్ట్లో సెలెక్టర్ లేదు, కాబట్టి kubeval లోపాన్ని నివేదించారు మరియు సున్నా కాని కోడ్తో నిష్క్రమించారు.
నేను చేస్తే ఏమి జరుగుతుందో అని నేను ఆశ్చర్యపోతున్నాను 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
కుబేవల్ హెచ్చరించిన తప్పు ఇదే. మీరు సెలెక్టర్ని జోడించడం ద్వారా దాన్ని పరిష్కరించవచ్చు:
కుబేవల్ వంటి సాధనాల యొక్క ప్రయోజనం ఏమిటంటే, విస్తరణ చక్రంలో ఇటువంటి లోపాలను ముందుగానే గుర్తించవచ్చు.
అదనంగా, ఈ తనిఖీలకు క్లస్టర్కు యాక్సెస్ అవసరం లేదు; అవి ఆఫ్లైన్లో నిర్వహించబడతాయి.
డిఫాల్ట్గా, kubeval తాజా Kubernetes API స్కీమాకు వ్యతిరేకంగా వనరులను తనిఖీ చేస్తుంది. అయినప్పటికీ, చాలా సందర్భాలలో మీరు నిర్దిష్ట Kubernetes విడుదలకు వ్యతిరేకంగా తనిఖీ చేయాల్సి రావచ్చు. ఇది జెండాను ఉపయోగించి చేయవచ్చు --kubernetes-version:
సంస్కరణ తప్పనిసరిగా ఫార్మాట్లో పేర్కొనబడాలని దయచేసి గమనించండి Major.Minor.Patch.
ధృవీకరణకు మద్దతు ఉన్న సంస్కరణల జాబితా కోసం, దయచేసి చూడండి GitHubలో JSON స్కీమా, ఏ kubeval ధృవీకరణ కోసం ఉపయోగిస్తుంది. మీరు kubeval ఆఫ్లైన్లో అమలు చేయాలనుకుంటే, స్కీమాలను డౌన్లోడ్ చేసి, ఫ్లాగ్ని ఉపయోగించి వాటి స్థానిక స్థానాన్ని పేర్కొనండి --schema-location.
వ్యక్తిగత YAML ఫైల్లతో పాటు, kubeval డైరెక్టరీలు మరియు stdinతో కూడా పని చేయవచ్చు.
అదనంగా, కుబెవల్ సులభంగా CI పైప్లైన్లో కలిసిపోతుంది. క్లస్టర్కు మానిఫెస్ట్లను పంపే ముందు పరీక్షలను అమలు చేయాలనుకునే వారు kubeval మూడు అవుట్పుట్ ఫార్మాట్లకు మద్దతు ఇస్తుందని తెలుసుకోవడం ఆనందంగా ఉంటుంది:
సాధారణ అక్షరాల;
JSON;
టెస్ట్ ఏదైనా ప్రోటోకాల్ (TAP).
మరియు కావలసిన రకం ఫలితాల సారాంశాన్ని రూపొందించడానికి అవుట్పుట్ని మరింత అన్వయించడానికి ఏదైనా ఫార్మాట్లను ఉపయోగించవచ్చు.
kubeval యొక్క లోపములలో ఒకటి ఇది ప్రస్తుతం కస్టమ్ రిసోర్స్ డెఫినిషన్స్ (CRDలు) సమ్మతిని తనిఖీ చేయలేము. అయితే, kubevalని కాన్ఫిగర్ చేయడం సాధ్యపడుతుంది వాటిని పట్టించుకోకండి.
కుబెవల్ అనేది వనరులను తనిఖీ చేయడానికి మరియు మూల్యాంకనం చేయడానికి ఒక గొప్ప సాధనం; ఏదేమైనప్పటికీ, పరీక్షలో ఉత్తీర్ణత సాధించడం వలన వనరు ఉత్తమ అభ్యాసాలకు అనుగుణంగా ఉందని హామీ ఇవ్వదని నొక్కి చెప్పాలి.
ఉదాహరణకు, ట్యాగ్ని ఉపయోగించడం latest ఒక కంటైనర్లో ఉత్తమ పద్ధతులను అనుసరించదు. అయితే, kubeval దీన్ని లోపంగా పరిగణించలేదు మరియు నివేదించలేదు. అంటే, అటువంటి YAML యొక్క ధృవీకరణ హెచ్చరికలు లేకుండా పూర్తవుతుంది.
మీరు YAMLని మూల్యాంకనం చేసి, ట్యాగ్ వంటి ఉల్లంఘనలను గుర్తించాలనుకుంటే ఏమి చేయాలి latest? ఉత్తమ అభ్యాసాలకు వ్యతిరేకంగా నేను YAML ఫైల్ని ఎలా తనిఖీ చేయాలి?
2. కుబే-స్కోర్
కుబే-స్కోరు YAML మానిఫెస్ట్లను అన్వయిస్తుంది మరియు అంతర్నిర్మిత పరీక్షలకు వ్యతిరేకంగా వాటిని మూల్యాంకనం చేస్తుంది. ఈ పరీక్షలు భద్రతా మార్గదర్శకాలు మరియు ఉత్తమ అభ్యాసాల ఆధారంగా ఎంపిక చేయబడతాయి, అవి:
కంటైనర్ను రూట్గా అమలు చేయడం లేదు.
పాడ్ ఆరోగ్య తనిఖీల లభ్యత.
వనరుల కోసం అభ్యర్థనలు మరియు పరిమితులను సెట్ చేయడం.
పరీక్ష ఫలితాల ఆధారంగా, మూడు ఫలితాలు ఇవ్వబడ్డాయి: OK, హెచ్చరిక и క్రిటికల్.
మీరు ఆన్లైన్లో Kube-స్కోర్ని ప్రయత్నించవచ్చు లేదా స్థానికంగా ఇన్స్టాల్ చేయవచ్చు.
అసలు కథనాన్ని వ్రాసే సమయంలో, kube-స్కోర్ యొక్క తాజా వెర్షన్ 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-స్కోర్ క్రింది లోపాలను సూచిస్తుంది:
సంసిద్ధత తనిఖీలు కాన్ఫిగర్ చేయబడలేదు.
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
kubeval మాదిరిగానే, kube-స్కోర్ పరీక్ష విఫలమైనప్పుడు సున్నా కాని నిష్క్రమణ కోడ్ను అందిస్తుంది క్రిటికల్. మీరు ఇలాంటి ప్రాసెసింగ్ని కూడా ప్రారంభించవచ్చు హెచ్చరిక.
అదనంగా, వివిధ API సంస్కరణలకు (కుబెవల్లో వలె) సమ్మతి కోసం వనరులను తనిఖీ చేయడం సాధ్యపడుతుంది. అయితే, ఈ సమాచారం kube-స్కోర్లోనే హార్డ్కోడ్ చేయబడింది: మీరు Kubernetes యొక్క వేరొక సంస్కరణను ఎంచుకోలేరు. మీరు మీ క్లస్టర్ని అప్గ్రేడ్ చేయాలనుకుంటే లేదా మీరు K8ల యొక్క విభిన్న వెర్షన్లతో బహుళ క్లస్టర్లను కలిగి ఉంటే ఈ పరిమితి పెద్ద సమస్యగా ఉంటుంది.
కుబే-స్కోర్ పరీక్షలు ఉత్తమ అభ్యాసాలను అమలు చేయడానికి ఒక గొప్ప సాధనం, అయితే మీరు పరీక్షలో మార్పులు చేయవలసి వస్తే లేదా మీ స్వంత నియమాలను జోడించాల్సి వస్తే ఏమి చేయాలి? అయ్యో, ఇది చేయలేము.
Kube-స్కోర్ పొడిగించబడదు: మీరు దీనికి విధానాలను జోడించలేరు లేదా వాటిని సర్దుబాటు చేయలేరు.
మీరు కంపెనీ విధానాలకు అనుగుణంగా ఉన్నట్లు ధృవీకరించడానికి అనుకూల పరీక్షలను వ్రాయవలసి వస్తే, మీరు క్రింది నాలుగు సాధనాలలో ఒకదాన్ని ఉపయోగించవచ్చు: config-lint, copper, conftest లేదా Polaris.
3.Config-lint
కాన్ఫిగ్-లింట్ అనేది YAML, JSON, Terraform, CSV కాన్ఫిగరేషన్ ఫైల్లు మరియు Kubernetes మానిఫెస్ట్లను ధృవీకరించడానికి ఒక సాధనం.
మీరు దీన్ని ఉపయోగించి ఇన్స్టాల్ చేయవచ్చు సూచనలు ప్రాజెక్ట్ వెబ్సైట్లో.
అసలు కథనాన్ని వ్రాసే సమయానికి ప్రస్తుత విడుదల 1.5.0.
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/).
కాన్ఫిగ్-లింట్ అనేది YAML DSLని ఉపయోగించి Kubernetes YAML మానిఫెస్ట్లను ధృవీకరించడానికి మీ స్వంత పరీక్షలను రూపొందించడానికి మిమ్మల్ని అనుమతించే మంచి ఫ్రేమ్వర్క్.
కానీ మీకు మరింత క్లిష్టమైన తర్కం మరియు పరీక్షలు అవసరమైతే? YAML దీనికి చాలా పరిమితం కాదా? మీరు పూర్తి ప్రోగ్రామింగ్ భాషలో పరీక్షలను సృష్టించగలిగితే?
4. రాగి
రాగి V2 కస్టమ్ పరీక్షలను ఉపయోగించి మానిఫెస్ట్లను ధృవీకరించడానికి ఒక ఫ్రేమ్వర్క్ (కాన్ఫిగర్-లింట్ మాదిరిగానే).
అయినప్పటికీ, ఇది పరీక్షలను వివరించడానికి YAMLని ఉపయోగించనందున ఇది రెండోదాని నుండి భిన్నంగా ఉంటుంది. బదులుగా జావాస్క్రిప్ట్లో పరీక్షలు రాయవచ్చు. రాగి అనేక ప్రాథమిక సాధనాలతో లైబ్రరీని అందిస్తుంది, ఇది కుబెర్నెట్స్ ఆబ్జెక్ట్ల గురించి సమాచారాన్ని చదవడానికి మరియు లోపాలను నివేదించడంలో మీకు సహాయపడుతుంది.
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 ఫైల్ను వేరియబుల్లోకి లోడ్ చేస్తుంది $$ మరియు స్క్రిప్టింగ్ కోసం దీన్ని అందుబాటులో ఉంచుతుంది (j క్వెరీ అనుభవం ఉన్నవారికి సుపరిచితమైన సాంకేతికత).
రాగి యొక్క ప్రధాన ప్రయోజనం స్పష్టంగా ఉంది: మీరు ప్రత్యేక భాషలో నైపుణ్యం అవసరం లేదు మరియు స్ట్రింగ్ ఇంటర్పోలేషన్, ఫంక్షన్లు మొదలైన మీ స్వంత పరీక్షలను రూపొందించడానికి మీరు వివిధ జావాస్క్రిప్ట్ లక్షణాలను ఉపయోగించవచ్చు.
కాపర్ యొక్క ప్రస్తుత వెర్షన్ ES5తో కాకుండా జావాస్క్రిప్ట్ ఇంజిన్ యొక్క ES6 వెర్షన్తో పనిచేస్తుందని కూడా గమనించాలి.
అయితే, మీరు నిజంగా జావాస్క్రిప్ట్ని ఇష్టపడకపోతే మరియు ప్రశ్నలను సృష్టించడం మరియు విధానాలను వివరించడం కోసం ప్రత్యేకంగా రూపొందించిన భాషని ఇష్టపడితే, మీరు కాన్ఫెస్ట్పై శ్రద్ధ వహించాలి.
5.పోటీ
Conftest అనేది కాన్ఫిగరేషన్ డేటాను పరీక్షించడానికి ఒక ఫ్రేమ్వర్క్. కుబెర్నెట్స్ మానిఫెస్ట్లను పరీక్షించడానికి/ధృవీకరించడానికి కూడా అనుకూలం. ప్రత్యేక ప్రశ్న భాషను ఉపయోగించి పరీక్షలు వివరించబడ్డాయి రెగో.
మీరు కాన్ఫెస్ట్ని ఉపయోగించి ఇన్స్టాల్ చేయవచ్చు సూచనలుప్రాజెక్ట్ వెబ్సైట్లో జాబితా చేయబడింది.
అసలు కథనాన్ని వ్రాసే సమయంలో, అందుబాటులో ఉన్న తాజా వెర్షన్ 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.
విధానాలను డీబగ్ చేయడాన్ని సులభతరం చేయడానికి, conftest ఒక ఫ్లాగ్ని కలిగి ఉంది --trace. ఇది పేర్కొన్న పాలసీ ఫైల్లను కాన్ఫెస్ట్ ఎలా అన్వయిస్తుంది అనే ట్రేస్ను అవుట్పుట్ చేస్తుంది.
పోటీ విధానాలు ఆర్టిఫాక్ట్లుగా OCI (ఓపెన్ కంటైనర్ ఇనిషియేటివ్) రిజిస్ట్రీలలో ప్రచురించబడతాయి మరియు భాగస్వామ్యం చేయబడతాయి.
Команды push и pull ఒక కళాఖండాన్ని ప్రచురించడానికి లేదా రిమోట్ రిజిస్ట్రీ నుండి ఇప్పటికే ఉన్న కళాఖండాన్ని తిరిగి పొందడానికి మిమ్మల్ని అనుమతిస్తుంది. ఉపయోగించి స్థానిక డాకర్ రిజిస్ట్రీకి మేము సృష్టించిన విధానాన్ని ప్రచురించడానికి ప్రయత్నిద్దాం conftest push.
మీ స్థానిక డాకర్ రిజిస్ట్రీని ప్రారంభించండి:
$ docker run -it --rm -p 5000:5000 registry
మరొక టెర్మినల్లో, మీరు ముందుగా సృష్టించిన డైరెక్టరీకి వెళ్లండి conftest-checks మరియు కింది ఆదేశాన్ని అమలు చేయండి:
కమాండ్ విజయవంతమైతే, మీరు ఇలాంటి సందేశాన్ని చూస్తారు:
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 ప్యాకేజీల నుండి పరీక్షలను అమలు చేయడానికి కాన్ఫెస్ట్ని ఉపయోగించడానికి మిమ్మల్ని అనుమతిస్తుంది.
పొలారిస్ను క్లస్టర్లో ఇన్స్టాల్ చేయవచ్చు లేదా కమాండ్ లైన్ మోడ్లో ఉపయోగించవచ్చు. మీరు ఊహించినట్లుగా, ఇది కుబెర్నెటెస్ మానిఫెస్ట్లను స్థిరంగా విశ్లేషించడానికి మిమ్మల్ని అనుమతిస్తుంది.
కమాండ్ లైన్ మోడ్లో నడుస్తున్నప్పుడు, అంతర్నిర్మిత పరీక్షలు భద్రత మరియు ఉత్తమ అభ్యాసాలు (కుబే-స్కోర్ మాదిరిగానే) వంటి ప్రాంతాలను కవర్ చేయడానికి అందుబాటులో ఉంటాయి. అదనంగా, మీరు మీ స్వంత పరీక్షలను సృష్టించవచ్చు (కాన్ఫిగర్-లింట్, కాపర్ మరియు కాన్ఫెస్ట్లో వలె).
మరో మాటలో చెప్పాలంటే, పొలారిస్ రెండు వర్గాల సాధనాల ప్రయోజనాలను మిళితం చేస్తుంది: అంతర్నిర్మిత మరియు అనుకూల పరీక్షలతో.
అసలు కథనాన్ని వ్రాసే సమయంలో, వెర్షన్ 1.0.3 అందుబాటులో ఉంది.
ఇన్స్టాలేషన్ పూర్తయిన తర్వాత మీరు మానిఫెస్ట్లో పోలారిస్ను రన్ చేయవచ్చు base-valid.yaml కింది ఆదేశంతో:
$ polaris audit --audit-path base-valid.yaml
ఇది నిర్వహించిన పరీక్షలు మరియు వాటి ఫలితాల వివరణాత్మక వివరణతో JSON ఆకృతిలో స్ట్రింగ్ను అవుట్పుట్ చేస్తుంది. అవుట్పుట్ కింది నిర్మాణాన్ని కలిగి ఉంటుంది:
కుబే-స్కోర్ లాగా, మానిఫెస్ట్ ఉత్తమ అభ్యాసాలకు అనుగుణంగా లేని ప్రాంతాల్లోని సమస్యలను పొలారిస్ గుర్తిస్తుంది:
పాడ్లకు ఎలాంటి ఆరోగ్య పరీక్షలు లేవు.
కంటైనర్ చిత్రాల కోసం ట్యాగ్లు పేర్కొనబడలేదు.
కంటైనర్ రూట్గా నడుస్తుంది.
మెమరీ మరియు CPU కోసం అభ్యర్థనలు మరియు పరిమితులు పేర్కొనబడలేదు.
ప్రతి పరీక్ష, దాని ఫలితాలను బట్టి, క్లిష్టమైన స్థాయిని కేటాయించబడుతుంది: హెచ్చరిక లేదా ప్రమాదం. అందుబాటులో ఉన్న అంతర్నిర్మిత పరీక్షల గురించి మరింత తెలుసుకోవడానికి, దయచేసి చూడండి డాక్యుమెంటేషన్.
వివరాలు అవసరం లేకపోతే, మీరు జెండాను పేర్కొనవచ్చు --format score. ఈ సందర్భంలో, పొలారిస్ 1 నుండి 100 − వరకు ఉన్న సంఖ్యను అవుట్పుట్ చేస్తుంది స్కోరు (అనగా అంచనా):
స్కోరు 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 పరీక్షలు మరియు వాటి క్లిష్టత స్థాయి సూచించబడ్డాయి. అవిశ్వసనీయ మూలం నుండి చిత్రం తీయబడినప్పుడు హెచ్చరికను స్వీకరించడం మంచిది కాబట్టి, మేము ఇక్కడ స్థాయిని సెట్ చేసాము danger.
పరీక్ష కూడా checkImageRepo అప్పుడు వస్తువులో నమోదు చేయబడింది customChecks.
ఫైల్ని ఇలా సేవ్ చేయండి custom_check.yaml. ఇప్పుడు మీరు అమలు చేయవచ్చు polaris audit ధృవీకరణ అవసరమయ్యే YAML మానిఫెస్ట్తో.
జట్టు polaris audit పైన పేర్కొన్న వినియోగదారు పరీక్షను మాత్రమే అమలు చేసారు మరియు అది విఫలమైంది.
మీరు చిత్రాన్ని సరిచేస్తే my-company.com/http-echo:1.0, పోలారిస్ విజయవంతంగా పూర్తి అవుతుంది. మార్పులతో కూడిన మేనిఫెస్టో ఇప్పటికే ఉంది రిపోజిటరీలుకాబట్టి మీరు మానిఫెస్ట్లో మునుపటి ఆదేశాన్ని తనిఖీ చేయవచ్చు image-valid-mycompany.yaml.
ఇప్పుడు ప్రశ్న తలెత్తుతుంది: కస్టమ్ వాటితో కలిసి అంతర్నిర్మిత పరీక్షలను ఎలా అమలు చేయాలి? సులభంగా! మీరు కాన్ఫిగరేషన్ ఫైల్కు అంతర్నిర్మిత పరీక్ష ఐడెంటిఫైయర్లను జోడించాలి. ఫలితంగా, ఇది క్రింది రూపాన్ని తీసుకుంటుంది:
Kubernetes YAML ఫైల్లను తనిఖీ చేయడానికి మరియు మూల్యాంకనం చేయడానికి అనేక సాధనాలు అందుబాటులో ఉన్నప్పటికీ, పరీక్షలు ఎలా రూపొందించబడతాయి మరియు అమలు చేయబడతాయి అనేదానిపై స్పష్టమైన అవగాహన కలిగి ఉండటం ముఖ్యం.
ఉదాహరణకు, మీరు పైప్లైన్ గుండా వెళుతున్న కుబెర్నెటెస్ మానిఫెస్ట్లను తీసుకుంటే, అటువంటి పైప్లైన్లో కుబేవల్ మొదటి అడుగు కావచ్చు.. ఆబ్జెక్ట్ నిర్వచనాలు కుబెర్నెట్స్ API స్కీమాకు అనుగుణంగా ఉన్నాయో లేదో ఇది పర్యవేక్షిస్తుంది.
అటువంటి సమీక్ష పూర్తయిన తర్వాత, ప్రామాణిక ఉత్తమ పద్ధతులు మరియు నిర్దిష్ట విధానాలకు అనుగుణంగా ఉండటం వంటి మరింత అధునాతన పరీక్షలకు వెళ్లవచ్చు. ఇక్కడే క్యూబ్-స్కోర్ మరియు పొలారిస్ ఉపయోగపడతాయి.
సంక్లిష్టమైన అవసరాలు మరియు పరీక్షలను వివరంగా అనుకూలీకరించాల్సిన వారికి, రాగి, కాన్ఫిగర్-లింట్ మరియు కాన్ఫెస్ట్ అనుకూలంగా ఉంటాయి.
కస్టమ్ పరీక్షలను నిర్వచించడానికి కాన్ఫెస్ట్ మరియు కాన్ఫిగర్-లింట్ YAMLని ఉపయోగిస్తాయి మరియు రాగి మీకు పూర్తి ప్రోగ్రామింగ్ లాంగ్వేజ్కి యాక్సెస్ ఇస్తుంది, ఇది చాలా ఆకర్షణీయమైన ఎంపికగా చేస్తుంది.
మరోవైపు, ఈ సాధనాల్లో ఒకదానిని ఉపయోగించడం విలువైనదేనా మరియు అందువల్ల, అన్ని పరీక్షలను మానవీయంగా సృష్టించడం లేదా పొలారిస్కు ప్రాధాన్యత ఇవ్వడం మరియు దానికి అవసరమైన వాటిని మాత్రమే జోడించడం విలువైనదేనా? ఈ ప్రశ్నకు స్పష్టమైన సమాధానం లేదు.
దిగువ పట్టిక ప్రతి సాధనం యొక్క సంక్షిప్త వివరణను అందిస్తుంది:
సాధనం
గమ్యం
లోపాలను
వినియోగదారు పరీక్షలు
కుబేవల్
API స్కీమా యొక్క నిర్దిష్ట సంస్కరణకు వ్యతిరేకంగా YAML మానిఫెస్ట్లను ధృవీకరిస్తుంది
CRDతో పని చేయడం సాధ్యపడదు
ఏ
kube-స్కోరు
ఉత్తమ అభ్యాసాలకు వ్యతిరేకంగా YAML మానిఫెస్ట్లను విశ్లేషిస్తుంది
వనరులను తనిఖీ చేయడానికి మీ Kubernetes API వెర్షన్ని ఎంచుకోలేదు
ఏ
రాగి
YAML మానిఫెస్ట్ల కోసం అనుకూల జావాస్క్రిప్ట్ పరీక్షలను రూపొందించడానికి సాధారణ ఫ్రేమ్వర్క్
అంతర్నిర్మిత పరీక్షలు లేవు. పేలవమైన డాక్యుమెంటేషన్
అవును
config-lint
YAMLలో పొందుపరిచిన డొమైన్-నిర్దిష్ట భాషలో పరీక్షలను రూపొందించడానికి ఒక సాధారణ ఫ్రేమ్వర్క్. వివిధ కాన్ఫిగరేషన్ ఫార్మాట్లకు మద్దతు ఇస్తుంది (ఉదా. టెర్రాఫార్మ్)
రెడీమేడ్ పరీక్షలు లేవు. అంతర్నిర్మిత ప్రకటనలు మరియు విధులు సరిపోకపోవచ్చు
అవును
ఘర్షణ
Rego (ప్రత్యేక ప్రశ్న భాష) ఉపయోగించి మీ స్వంత పరీక్షలను రూపొందించడానికి ఫ్రేమ్వర్క్. OCI బండిల్ల ద్వారా పాలసీలను షేర్ చేసుకోవడానికి అనుమతిస్తుంది
అంతర్నిర్మిత పరీక్షలు లేవు. నేను రెగో నేర్చుకోవాలి. విధానాలను ప్రచురించేటప్పుడు డాకర్ హబ్కి మద్దతు లేదు
అవును
పొలారిస్
సమీక్షలు YAML స్టాండర్డ్ బెస్ట్ ప్రాక్టీస్లకు వ్యతిరేకంగా మానిఫెస్ట్ చేస్తుంది. JSON స్కీమాను ఉపయోగించి మీ స్వంత పరీక్షలను సృష్టించడానికి మిమ్మల్ని అనుమతిస్తుంది
JSON స్కీమా ఆధారంగా పరీక్ష సామర్థ్యాలు సరిపోకపోవచ్చు
అవును
ఈ సాధనాలు కుబెర్నెట్స్ క్లస్టర్కు యాక్సెస్పై ఆధారపడనందున, వాటిని ఇన్స్టాల్ చేయడం సులభం. అవి సోర్స్ ఫైల్లను ఫిల్టర్ చేయడానికి మరియు ప్రాజెక్ట్లలోని పుల్ రిక్వెస్ట్ల రచయితలకు శీఘ్ర అభిప్రాయాన్ని అందించడానికి మిమ్మల్ని అనుమతిస్తాయి.