గమనిక. అనువాదం.: Kubernetes సంఘంలో, GitOps అనే ట్రెండ్ స్పష్టమైన ప్రజాదరణ పొందుతోంది, మనం వ్యక్తిగతంగా చూసినట్లుగా, KubeCon Europe 2019. ఈ పదం సాపేక్షంగా ఇటీవలిది వీవ్‌వర్క్స్ హెడ్ - అలెక్సిస్ రిచర్డ్‌సన్ ద్వారా - మరియు డెవలపర్‌లకు (ప్రధానంగా Git, అందుకే పేరు వచ్చింది) కార్యాచరణ సమస్యలను పరిష్కరించడానికి తెలిసిన సాధనాలను ఉపయోగించడం అని అర్థం. ప్రత్యేకించి, మేము దాని కాన్ఫిగరేషన్‌లను Gitలో నిల్వ చేయడం ద్వారా మరియు స్వయంచాలకంగా క్లస్టర్‌కు మార్పులను రోల్ చేయడం ద్వారా కుబెర్నెట్స్ యొక్క ఆపరేషన్ గురించి మాట్లాడుతున్నాము. Matthias Jg ఈ కథనంలో ఈ రోల్‌అవుట్‌కి సంబంధించిన రెండు విధానాల గురించి మాట్లాడుతున్నారు.
గత సంవత్సరం (వాస్తవానికి, అధికారికంగా ఇది ఆగస్టు 2017లో జరిగింది - సుమారుగా. అనువాదం.) కుబెర్నెట్స్‌లో అప్లికేషన్‌లను అమలు చేయడానికి కొత్త విధానం ఉంది. దీనిని GitOps అని పిలుస్తారు మరియు ఇది Git రిపోజిటరీ యొక్క సురక్షిత వాతావరణంలో విస్తరణ సంస్కరణలు ట్రాక్ చేయబడుతుందనే ప్రాథమిక ఆలోచనపై ఆధారపడి ఉంటుంది.
ఈ విధానం యొక్క ప్రధాన ప్రయోజనాలు క్రింది విధంగా ఉన్నాయి::
- విస్తరణ సంస్కరణ మరియు మార్పు చరిత్ర. మొత్తం క్లస్టర్ యొక్క స్థితి Git రిపోజిటరీలో నిల్వ చేయబడుతుంది మరియు విస్తరణలు కమిట్‌ల ద్వారా మాత్రమే నవీకరించబడతాయి. అదనంగా, కమిట్ హిస్టరీని ఉపయోగించి అన్ని మార్పులను ట్రాక్ చేయవచ్చు.
- తెలిసిన Git ఆదేశాలను ఉపయోగించి రోల్‌బ్యాక్‌లు. సరళమైనది
git resetవిస్తరణలలో మార్పులను రీసెట్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది; గత రాష్ట్రాలు ఎల్లప్పుడూ అందుబాటులో ఉంటాయి. - సిద్ధంగా యాక్సెస్ నియంత్రణ. సాధారణంగా, Git సిస్టమ్ చాలా సున్నితమైన డేటాను కలిగి ఉంటుంది, కాబట్టి చాలా కంపెనీలు దానిని రక్షించడంలో ప్రత్యేక శ్రద్ధ చూపుతాయి. దీని ప్రకారం, ఈ రక్షణ విస్తరణలతో కార్యకలాపాలకు కూడా వర్తిస్తుంది.
- విస్తరణల కోసం విధానాలు. చాలా Git సిస్టమ్‌లు బ్రాంచ్ వారీగా విధానాలకు స్థానికంగా మద్దతు ఇస్తాయి-ఉదాహరణకు, పుల్ రిక్వెస్ట్‌లు మాత్రమే మాస్టర్‌ను అప్‌డేట్ చేయగలవు మరియు మార్పులను మరొక బృంద సభ్యుడు సమీక్షించి, ఆమోదించాలి. యాక్సెస్ నియంత్రణ వలె, అదే విధానాలు విస్తరణ నవీకరణలకు వర్తిస్తాయి.
మీరు గమనిస్తే, GitOps పద్ధతికి చాలా ప్రయోజనాలు ఉన్నాయి. గత సంవత్సరంలో, రెండు విధానాలు ప్రత్యేక ప్రజాదరణ పొందాయి. ఒకటి పుష్ బేస్డ్, మరొకటి పుల్ బేస్డ్. మేము వాటిని చూసే ముందు, సాధారణంగా కుబెర్నెట్స్ విస్తరణలు ఎలా ఉంటాయో చూద్దాం.
విస్తరణ పద్ధతులు
ఇటీవలి సంవత్సరాలలో, కుబెర్నెట్స్‌లో విస్తరణ కోసం వివిధ పద్ధతులు మరియు సాధనాలు స్థాపించబడ్డాయి:
- స్థానిక Kubernetes/Kustomize టెంప్లేట్‌ల ఆధారంగా. ఇది Kubernetesలో అప్లికేషన్‌లను అమలు చేయడానికి సులభమైన మార్గం. డెవలపర్ ప్రాథమిక YAML ఫైల్‌లను సృష్టించి, వాటిని వర్తింపజేస్తారు. అదే టెంప్లేట్‌లను నిరంతరం తిరిగి వ్రాయడాన్ని వదిలించుకోవడానికి, కస్టమైజ్ అభివృద్ధి చేయబడింది (ఇది కుబెర్నెట్స్ టెంప్లేట్‌లను మాడ్యూల్స్‌గా మారుస్తుంది). గమనిక. అనువాదం.: Kustomize దీనితో kubectlలో విలీనం చేయబడింది .
- హెల్మ్ చార్ట్‌లు. హెల్మ్ చార్ట్‌లు టెంప్లేట్‌ల సెట్‌లు, init కంటైనర్‌లు, సైడ్‌కార్‌లు మొదలైనవాటిని సృష్టించడానికి మిమ్మల్ని అనుమతిస్తాయి, ఇవి టెంప్లేట్-ఆధారిత విధానం కంటే మరింత సౌకర్యవంతమైన అనుకూలీకరణ ఎంపికలతో అప్లికేషన్‌లను అమలు చేయడానికి ఉపయోగించబడతాయి. ఈ పద్ధతి టెంప్లేట్ చేయబడిన YAML ఫైల్‌లపై ఆధారపడి ఉంటుంది. హెల్మ్ వాటిని వివిధ పారామీటర్‌లతో నింపి, ఆపై వాటిని క్లస్టర్‌కి పంపే క్లస్టర్ కాంపోనెంట్ అయిన టిల్లర్‌కి పంపుతుంది మరియు అప్‌డేట్‌లు మరియు రోల్‌బ్యాక్‌లను అనుమతిస్తుంది. ముఖ్యమైన విషయం ఏమిటంటే, హెల్మ్ తప్పనిసరిగా కావలసిన విలువలను టెంప్లేట్‌లలోకి చొప్పించి, సాంప్రదాయ పద్ధతిలో చేసిన విధంగానే వాటిని వర్తింపజేస్తుంది. (ఇవన్నీ ఎలా పని చేస్తాయి మరియు మీరు మాలో ఎలా ఉపయోగించవచ్చనే దాని గురించి మరింత చదవండి - సుమారు అనువాదం.). విస్తృత శ్రేణి పనులను కవర్ చేసే అనేక రకాల రెడీమేడ్ హెల్మ్ చార్ట్‌లు ఉన్నాయి.
- ప్రత్యామ్నాయ సాధనాలు. అనేక ప్రత్యామ్నాయ సాధనాలు ఉన్నాయి. వారందరికీ ఉమ్మడిగా ఉన్న విషయం ఏమిటంటే, వారు కొన్ని టెంప్లేట్ ఫైల్‌లను కుబెర్నెట్స్-రీడబుల్ YAML ఫైల్‌లుగా మార్చారు మరియు వాటిని ఉపయోగించడం.
మా పనిలో, మేము ముఖ్యమైన సాధనాల కోసం హెల్మ్ చార్ట్‌లను నిరంతరం ఉపయోగిస్తాము (అవి ఇప్పటికే చాలా విషయాలు సిద్ధంగా ఉన్నాయి, ఇది జీవితాన్ని మరింత సులభతరం చేస్తుంది) మరియు మా స్వంత అప్లికేషన్‌లను అమలు చేయడానికి "స్వచ్ఛమైన" కుబెర్నెటెస్ YAML ఫైల్‌లను ఉపయోగిస్తాము.
లాగు నెట్టు
నా ఇటీవలి బ్లాగ్ పోస్ట్‌లలో ఒకదానిలో, నేను సాధనాన్ని పరిచయం చేసాను , ఇది మీరు Git రిపోజిటరీకి టెంప్లేట్‌లను కమిట్ చేయడానికి మరియు కంటైనర్ యొక్క ప్రతి కమిట్ లేదా పుష్ తర్వాత విస్తరణను నవీకరించడానికి అనుమతిస్తుంది. పుల్ విధానాన్ని ప్రోత్సహించడంలో ఈ సాధనం ప్రధానమైన వాటిలో ఒకటి అని నా అనుభవం చూపిస్తుంది, కాబట్టి నేను దీన్ని తరచుగా సూచిస్తాను. మీరు దీన్ని ఎలా ఉపయోగించాలో గురించి మరింత తెలుసుకోవాలనుకుంటే, ఇక్కడ .
NB! GitOpsను ఉపయోగించడం వల్ల కలిగే అన్ని ప్రయోజనాలు రెండు విధానాలకు ఒకే విధంగా ఉంటాయి.
పుల్ బేస్డ్ విధానం
పుల్ విధానం అన్ని మార్పులు క్లస్టర్‌లోనే వర్తింపజేయడంపై ఆధారపడి ఉంటుంది. అనుబంధిత Git మరియు డాకర్ రిజిస్ట్రీ రిపోజిటరీలను క్రమం తప్పకుండా తనిఖీ చేసే క్లస్టర్ లోపల ఒక ఆపరేటర్ ఉన్నారు. వాటికి ఏవైనా మార్పులు సంభవించినట్లయితే, క్లస్టర్ యొక్క స్థితి అంతర్గతంగా నవీకరించబడుతుంది. క్లస్టర్ అడ్మినిస్ట్రేటర్ హక్కులకు ఏ బాహ్య క్లయింట్‌కు యాక్సెస్ లేనందున ఈ ప్రక్రియ సాధారణంగా చాలా సురక్షితమైనదిగా పరిగణించబడుతుంది.
ప్రోస్:
- క్లస్టర్‌లో మార్పులు చేయడానికి ఏ బాహ్య క్లయింట్‌కు హక్కులు లేవు; అన్ని అప్‌డేట్‌లు లోపల నుండి రూపొందించబడ్డాయి.
- కొన్ని సాధనాలు హెల్మ్ చార్ట్ అప్‌డేట్‌లను సమకాలీకరించడానికి మరియు వాటిని క్లస్టర్‌కి లింక్ చేయడానికి కూడా మిమ్మల్ని అనుమతిస్తాయి.
- కొత్త వెర్షన్‌ల కోసం డాకర్ రిజిస్ట్రీని స్కాన్ చేయవచ్చు. కొత్త చిత్రం అందుబాటులో ఉంటే, Git రిపోజిటరీ మరియు విస్తరణ కొత్త సంస్కరణకు నవీకరించబడతాయి.
- వివిధ Git రిపోజిటరీలు మరియు అనుమతులతో వివిధ నేమ్‌స్పేస్‌లలో పుల్ టూల్స్ పంపిణీ చేయబడతాయి. దీనికి ధన్యవాదాలు, మల్టీటెనెంట్ మోడల్‌ను ఉపయోగించవచ్చు. ఉదాహరణకు, టీమ్ A నేమ్‌స్పేస్ Aని ఉపయోగించవచ్చు, టీమ్ B నేమ్‌స్పేస్ Bని ఉపయోగించవచ్చు మరియు ఇన్‌ఫ్రాస్ట్రక్చర్ టీమ్ గ్లోబల్ స్పేస్‌ని ఉపయోగించవచ్చు.
- నియమం ప్రకారం, ఉపకరణాలు చాలా తేలికైనవి.
- ఆపరేటర్ వంటి సాధనాలతో కలిపి , రహస్యాలను Git రిపోజిటరీలో గుప్తీకరించి నిల్వ చేయవచ్చు మరియు క్లస్టర్‌లో తిరిగి పొందవచ్చు.
- క్లస్టర్‌లో విస్తరణలు జరుగుతున్నందున CD పైప్‌లైన్‌లకు కనెక్షన్ లేదు.
Минусы:
- హెల్మ్ చార్ట్‌ల నుండి విస్తరణ రహస్యాలను నిర్వహించడం సాధారణ వాటి కంటే చాలా కష్టం, ఎందుకంటే అవి మొదట సీల్డ్ సీక్రెట్స్ రూపంలో ఉత్పత్తి చేయబడాలి, ఆపై అంతర్గత ఆపరేటర్ ద్వారా డీక్రిప్ట్ చేయబడతాయి మరియు ఆ తర్వాత మాత్రమే అవి పుల్ టూల్‌కు అందుబాటులో ఉంటాయి. అప్పుడు మీరు ఇప్పటికే అమలు చేయబడిన రహస్యాలలోని విలువలతో హెల్మ్‌లో విడుదలను అమలు చేయవచ్చు. విస్తరణ కోసం ఉపయోగించే అన్ని హెల్మ్ విలువలతో రహస్యాన్ని సృష్టించడం, దానిని డీక్రిప్ట్ చేయడం మరియు దానిని Gitకి అప్పగించడం సులభమయిన మార్గం.
- మీరు పుల్ అప్రోచ్ తీసుకున్నప్పుడు, మీరు పుల్ టూల్స్‌తో ముడిపడి ఉంటారు. ఇది క్లస్టర్‌లో విస్తరణ ప్రక్రియను అనుకూలీకరించే సామర్థ్యాన్ని పరిమితం చేస్తుంది. ఉదాహరణకు, చివరి టెంప్లేట్‌లు Gitకి కట్టుబడి ఉండకముందే అది తప్పనిసరిగా అమలు చేయబడాలి అనే వాస్తవంతో కస్టమైజ్ సంక్లిష్టంగా ఉంటుంది. మీరు స్వతంత్ర సాధనాలను ఉపయోగించలేరని నేను చెప్పడం లేదు, కానీ అవి మీ విస్తరణ ప్రక్రియలో ఏకీకృతం చేయడం చాలా కష్టం.
పుష్ ఆధారిత విధానం
పుష్ విధానంలో, Git రిపోజిటరీకి కట్టుబడిన తర్వాత లేదా మునుపటి CI పైప్‌లైన్ విజయవంతమైతే, బాహ్య వ్యవస్థ (ప్రధానంగా CD పైప్‌లైన్‌లు) క్లస్టర్‌కు విస్తరణలను ప్రారంభిస్తుంది. ఈ విధానంలో, సిస్టమ్ క్లస్టర్‌కు ప్రాప్యతను కలిగి ఉంటుంది.
Плюсы:
- భద్రత Git రిపోజిటరీ మరియు బిల్డ్ పైప్‌లైన్ ద్వారా నిర్ణయించబడుతుంది.
- హెల్మ్ చార్ట్‌లను అమలు చేయడం సులభం మరియు హెల్మ్ ప్లగిన్‌లకు మద్దతు ఇస్తుంది.
- సీక్రెట్‌లను నిర్వహించడం సులభం ఎందుకంటే సీక్రెట్‌లను పైప్‌లైన్‌లలో ఉపయోగించవచ్చు మరియు Git (యూజర్ యొక్క ప్రాధాన్యతలను బట్టి) గుప్తీకరించి కూడా నిల్వ చేయవచ్చు.
- నిర్దిష్ట సాధనానికి కనెక్షన్ లేదు, ఎందుకంటే ఏ రకాన్ని అయినా ఉపయోగించవచ్చు.
- బిల్డ్ పైప్‌లైన్ ద్వారా కంటైనర్ వెర్షన్ అప్‌డేట్‌లను ప్రారంభించవచ్చు.
Минусы:
- క్లస్టర్ యాక్సెస్ డేటా బిల్డ్ సిస్టమ్ లోపల ఉంది.
- పుల్ ప్రాసెస్‌తో విస్తరణ కంటైనర్‌లను నవీకరించడం ఇంకా సులభం.
- CD సిస్టమ్‌పై ఎక్కువగా ఆధారపడటం, మనకు అవసరమైన పైప్‌లైన్‌లు వాస్తవానికి Gitlab రన్నర్స్ కోసం వ్రాయబడి ఉండవచ్చు, ఆపై బృందం Azure DevOps లేదా Jenkinsకి వెళ్లాలని నిర్ణయించుకుంటుంది... మరియు పెద్ద సంఖ్యలో బిల్డ్ పైప్‌లైన్‌లను తరలించాల్సి ఉంటుంది.
ఫలితాలు: పుష్ లేదా లాగండి?
సాధారణంగా, ప్రతి విధానం దాని లాభాలు మరియు నష్టాలను కలిగి ఉంటుంది. కొన్ని పనులు ఒకదానితో సులభంగా మరియు మరొకదానితో మరింత కష్టంగా ఉంటాయి. మొదట నేను మాన్యువల్‌గా విస్తరణలు చేస్తున్నాను, కానీ నేను వీవ్ ఫ్లక్స్ గురించి కొన్ని కథనాలను చూసిన తర్వాత, అన్ని ప్రాజెక్ట్‌లకు GitOps ప్రక్రియలను అమలు చేయాలని నిర్ణయించుకున్నాను. ప్రాథమిక టెంప్లేట్‌ల కోసం ఇది చాలా సులభం, కానీ నేను హెల్మ్ చార్ట్‌లతో ఇబ్బందుల్లో పడటం ప్రారంభించాను. ఆ సమయంలో, వీవ్ ఫ్లక్స్ హెల్మ్ చార్ట్ ఆపరేటర్ యొక్క మూలాధార సంస్కరణను మాత్రమే అందించింది, అయితే ఇప్పుడు కూడా కొన్ని పనులు మాన్యువల్‌గా రహస్యాలను సృష్టించడం మరియు వాటిని వర్తింపజేయడం వల్ల చాలా కష్టంగా ఉన్నాయి. క్లస్టర్ యొక్క ఆధారాలు క్లస్టర్ వెలుపల అందుబాటులో లేనందున, పుల్ అప్రోచ్ చాలా సురక్షితమైనదని మీరు వాదించవచ్చు, ఇది మరింత సురక్షితమైనదిగా చేస్తుంది, ఇది అదనపు కృషికి విలువైనది.
కొంచెం ఆలోచించిన తరువాత, ఇది అలా కాదు అని నేను ఊహించని నిర్ణయానికి వచ్చాను. మేము గరిష్ట రక్షణ అవసరమయ్యే భాగాల గురించి మాట్లాడినట్లయితే, ఈ జాబితాలో రహస్య నిల్వ, CI/CD సిస్టమ్‌లు మరియు Git రిపోజిటరీలు ఉంటాయి. వాటిలోని సమాచారం చాలా హాని కలిగిస్తుంది మరియు గరిష్ట రక్షణ అవసరం. అదనంగా, ఎవరైనా మీ Git రిపోజిటరీలోకి ప్రవేశించి, అక్కడ కోడ్‌ను పుష్ చేయగలిగితే, వారు తమకు కావలసినదాన్ని (అది లాగినా లేదా పుష్ చేసినా) అమలు చేయవచ్చు మరియు క్లస్టర్ సిస్టమ్‌లలోకి చొరబడవచ్చు. అందువల్ల, రక్షించాల్సిన ముఖ్యమైన భాగాలు Git రిపోజిటరీ మరియు CI/CD సిస్టమ్‌లు, క్లస్టర్ ఆధారాలు కాదు. మీరు ఈ రకమైన సిస్టమ్‌ల కోసం బాగా కాన్ఫిగర్ చేసిన విధానాలు మరియు భద్రతా నియంత్రణలను కలిగి ఉంటే మరియు క్లస్టర్ ఆధారాలను రహస్యాలుగా పైప్‌లైన్‌లలోకి సంగ్రహిస్తే, పుల్ అప్రోచ్ యొక్క అదనపు భద్రత మొదట అనుకున్నంత విలువైనది కాకపోవచ్చు.
కాబట్టి, పుల్ విధానం ఎక్కువ శ్రమతో కూడుకున్నది మరియు భద్రతా ప్రయోజనాన్ని అందించకపోతే, పుష్ విధానాన్ని మాత్రమే ఉపయోగించడం లాజికల్ కాదా? కానీ పుష్ విధానంలో మీరు CD సిస్టమ్‌తో చాలా ముడిపడి ఉన్నారని ఎవరైనా వాదించవచ్చు మరియు బహుశా దీన్ని చేయకపోవడమే మంచిది, తద్వారా భవిష్యత్తులో వలసలు చేయడం సులభం అవుతుంది.
నా అభిప్రాయం ప్రకారం (ఎప్పటిలాగే), మీరు ఒక నిర్దిష్ట సందర్భంలో లేదా కలపడానికి చాలా సరిఅయినదాన్ని ఉపయోగించాలి. వ్యక్తిగతంగా, నేను రెండు విధానాలను ఉపయోగిస్తాను: పుల్-ఆధారిత విస్తరణల కోసం వీవ్ ఫ్లక్స్ ఎక్కువగా మా స్వంత సేవలను కలిగి ఉంటుంది మరియు హెల్మ్ మరియు ప్లగిన్‌లతో కూడిన పుష్ విధానం, ఇది క్లస్టర్‌కు హెల్మ్ చార్ట్‌లను వర్తింపజేయడాన్ని సులభతరం చేస్తుంది మరియు రహస్యాలను సజావుగా సృష్టించడానికి మిమ్మల్ని అనుమతిస్తుంది. అన్ని కేసులకు అనువైన ఒకే పరిష్కారం ఎప్పటికీ ఉండదని నేను భావిస్తున్నాను, ఎందుకంటే ఎల్లప్పుడూ చాలా సూక్ష్మ నైపుణ్యాలు ఉన్నాయి మరియు అవి నిర్దిష్ట అప్లికేషన్‌పై ఆధారపడి ఉంటాయి. ఇలా చెప్పుకుంటూ పోతే, నేను GitOpsని బాగా సిఫార్సు చేస్తున్నాను - ఇది జీవితాన్ని చాలా సులభతరం చేస్తుంది మరియు భద్రతను మెరుగుపరుస్తుంది.
ఈ అంశంపై నా అనుభవం మీ విస్తరణకు ఏ పద్ధతి మరింత అనుకూలంగా ఉంటుందో నిర్ణయించడంలో మీకు సహాయపడుతుందని నేను ఆశిస్తున్నాను మరియు మీ అభిప్రాయాన్ని వినడానికి నేను సంతోషిస్తాను.
అనువాదకుడు నుండి PS గమనిక
పుల్ మోడల్ యొక్క ప్రతికూలత ఏమిటంటే, రెండర్ చేయబడిన మానిఫెస్ట్‌లను Gitలో ఉంచడం కష్టం, కానీ పుల్ మోడల్‌లోని CD పైప్‌లైన్ రోల్ అవుట్ నుండి విడిగా నివసిస్తుంది మరియు ముఖ్యంగా ఒక కేటగిరీ పైప్‌లైన్ అవుతుంది. నిరంతర దరఖాస్తు. అందువల్ల, అన్ని విస్తరణల నుండి వారి స్థితిని సేకరించడానికి మరియు లాగ్‌లు/స్టేటస్‌కి యాక్సెస్‌ను అందించడానికి ఇంకా ఎక్కువ కృషి అవసరం అవుతుంది.
ఈ కోణంలో, పుష్ మోడల్ రోల్‌అవుట్‌కు కనీసం కొన్ని హామీలను అందించడానికి అనుమతిస్తుంది, ఎందుకంటే పైప్‌లైన్ జీవితకాలం రోల్‌అవుట్ యొక్క జీవితకాలానికి సమానంగా చేయవచ్చు.
మేము రెండు నమూనాలను ప్రయత్నించాము మరియు వ్యాసం యొక్క రచయిత వలె అదే నిర్ణయాలకు వచ్చాము:
- పెద్ద సంఖ్యలో క్లస్టర్‌లలో సిస్టమ్ భాగాల నవీకరణలను నిర్వహించడానికి పుల్ మోడల్ మాకు అనుకూలంగా ఉంటుంది (చూడండి. ).
- GitLab CI ఆధారంగా పుష్ మోడల్ హెల్మ్ చార్ట్‌లను ఉపయోగించి అప్లికేషన్‌లను రోల్ అవుట్ చేయడానికి బాగా సరిపోతుంది. అదే సమయంలో, పైప్‌లైన్‌లలో విస్తరణల రోల్‌అవుట్ సాధనాన్ని ఉపయోగించి పర్యవేక్షించబడుతుంది . మార్గం ద్వారా, మా ప్రాజెక్ట్ యొక్క ఈ సందర్భంలో, KubeCon Europe'19 వద్ద మా స్టాండ్‌లో DevOps ఇంజనీర్ల యొక్క ముఖ్యమైన సమస్యలను చర్చించినప్పుడు మేము స్థిరమైన “GitOps”ని విన్నాము.
అనువాదకుని నుండి PPS
మా బ్లాగులో కూడా చదవండి:
- «";
- «";
- «";
- «".
నమోదు చేసుకున్న వినియోగదారులు మాత్రమే సర్వేలో పాల్గొనగలరు. దయచేసి.
మీరు GitOps ఉపయోగిస్తున్నారా?
-
అవును, పుల్ అప్రోచ్
-
అవును, పుష్
-
అవును, లాగండి + పుష్
-
అవును, ఇంకేదో
-
ఏ
30 మంది వినియోగదారులు ఓటు వేశారు. 10 మంది వినియోగదారులు దూరంగా ఉన్నారు.
మూలం: www.habr.com