werf - Kubernetes లో CI / CD కోసం మా సాధనం (అవలోకనం మరియు వీడియో నివేదిక)

మే 27న పండుగలో భాగంగా జరిగిన DevOpsConf 2019 కాన్ఫరెన్స్ మెయిన్ హాల్‌లో RIT++ 2019, “నిరంతర డెలివరీ” విభాగంలో భాగంగా, “వెర్ఫ్ - కుబెర్నెట్స్‌లో CI/CD కోసం మా సాధనం” అనే నివేదిక అందించబడింది. వాటి గురించి మాట్లాడుతుంది కుబెర్నెటెస్‌కు పంపేటప్పుడు ప్రతి ఒక్కరూ ఎదుర్కొనే సమస్యలు మరియు సవాళ్లు, అలాగే వెంటనే గుర్తించబడని సూక్ష్మ నైపుణ్యాల గురించి. సాధ్యమయ్యే పరిష్కారాలను విశ్లేషిస్తూ, ఇది ఓపెన్ సోర్స్ సాధనంలో ఎలా అమలు చేయబడుతుందో మేము చూపుతాము వర్ఫ్.

ప్రెజెంటేషన్ నుండి, మా యుటిలిటీ (గతంలో డాప్ అని పిలుస్తారు) చారిత్రాత్మక మైలురాయిని చేరుకుంది GitHubలో 1000 నక్షత్రాలు — దాని పెరుగుతున్న వినియోగదారుల సంఘం చాలా మంది DevOps ఇంజనీర్‌లకు జీవితాన్ని సులభతరం చేస్తుందని మేము ఆశిస్తున్నాము.

కాబట్టి, పరిచయం చేద్దాం నివేదిక యొక్క వీడియో (~47 నిమిషాలు, వ్యాసం కంటే చాలా ఎక్కువ సమాచారం) మరియు దాని నుండి ప్రధాన సారం టెక్స్ట్ రూపంలో. వెళ్ళండి!

కుబెర్నెట్‌లకు కోడ్‌ని బట్వాడా చేస్తోంది

చర్చ ఇకపై వెర్ఫ్ గురించి కాదు, కుబెర్నెట్స్‌లోని CI/CD గురించి, మా సాఫ్ట్‌వేర్ డాకర్ కంటైనర్‌లలో ప్యాక్ చేయబడిందని సూచిస్తుంది. (నేను దీని గురించి మాట్లాడాను 2016 నివేదిక), మరియు ఉత్పత్తిలో దీన్ని అమలు చేయడానికి K8లు ఉపయోగించబడతాయి (దీని గురించి మరింత 2017 సంవత్సరం).

కుబెర్నెటెస్‌లో డెలివరీ ఎలా ఉంటుంది?

• కోడ్ మరియు దానిని నిర్మించడానికి సూచనలతో కూడిన Git రిపోజిటరీ ఉంది. అప్లికేషన్ డాకర్ ఇమేజ్‌లో నిర్మించబడింది మరియు డాకర్ రిజిస్ట్రీలో ప్రచురించబడింది.
• అదే రిపోజిటరీ అనువర్తనాన్ని ఎలా అమలు చేయాలి మరియు అమలు చేయాలి అనే దానిపై సూచనలను కూడా కలిగి ఉంటుంది. విస్తరణ దశలో, ఈ సూచనలు కుబెర్నెటెస్‌కు పంపబడతాయి, ఇది రిజిస్ట్రీ నుండి కావలసిన చిత్రాన్ని పొందుతుంది మరియు దానిని ప్రారంభించింది.
• అదనంగా, సాధారణంగా పరీక్షలు ఉన్నాయి. చిత్రాన్ని ప్రచురించేటప్పుడు వీటిలో కొన్నింటిని చేయవచ్చు. మీరు కూడా (అదే సూచనలను అనుసరించి) అప్లికేషన్ యొక్క కాపీని (ప్రత్యేక K8s నేమ్‌స్పేస్ లేదా ప్రత్యేక క్లస్టర్‌లో) అమర్చవచ్చు మరియు అక్కడ పరీక్షలను అమలు చేయవచ్చు.
• చివరగా, మీకు Git (లేదా బటన్ క్లిక్‌లు) నుండి ఈవెంట్‌లను స్వీకరించే CI సిస్టమ్ అవసరం మరియు అన్ని నియమించబడిన దశలను కాల్ చేస్తుంది: బిల్డ్, పబ్లిష్, డిప్లాయ్, టెస్ట్.

ఇక్కడ కొన్ని ముఖ్యమైన గమనికలు ఉన్నాయి:

1. ఎందుకంటే మనకు మార్పులేని మౌలిక సదుపాయాలు ఉన్నాయి (మార్పులేని మౌలిక సదుపాయాలు), అన్ని దశలలో ఉపయోగించే అప్లికేషన్ చిత్రం (స్టేజింగ్, ప్రొడక్షన్ మొదలైనవి), ఒకటి ఉండాలి. నేను దీని గురించి మరింత వివరంగా మరియు ఉదాహరణలతో మాట్లాడాను. ఇక్కడ.
2. ఎందుకంటే మేము మౌలిక సదుపాయాలను కోడ్ విధానంగా అనుసరిస్తాము (IaC), అప్లికేషన్ కోడ్, అసెంబ్లింగ్ మరియు లాంచ్ కోసం సూచనలు ఉండాలి సరిగ్గా ఒక రిపోజిటరీలో. దీని గురించి మరింత సమాచారం కోసం, చూడండి అదే నివేదిక.
3. డెలివరీ చైన్ (డెలివరీ) మేము సాధారణంగా దీన్ని ఇలా చూస్తాము: అప్లికేషన్ అసెంబుల్ చేయబడింది, పరీక్షించబడింది, విడుదల చేయబడింది (విడుదల దశ) మరియు అంతే - డెలివరీ జరిగింది. కానీ వాస్తవానికి, మీరు రూపొందించిన దాన్ని వినియోగదారు పొందుతారు, కాదు మీరు దానిని ఉత్పత్తికి అందించినప్పుడు మరియు అతను అక్కడికి వెళ్ళగలిగినప్పుడు మరియు ఈ ఉత్పత్తి పనిచేసినప్పుడు. కాబట్టి డెలివరీ చైన్ ముగుస్తుందని నేను నమ్ముతున్నాను కార్యాచరణ దశలో మాత్రమే (పరుగు), లేదా మరింత ఖచ్చితంగా, ఉత్పత్తి నుండి కోడ్ తీసివేయబడిన సమయంలో కూడా (దీనిని కొత్త దానితో భర్తీ చేయడం).

కుబెర్నెటెస్‌లోని పై డెలివరీ స్కీమ్‌కు తిరిగి వెళ్దాం: ఇది మా ద్వారా మాత్రమే కాకుండా, ఈ సమస్యను ఎదుర్కొన్న ప్రతి ఒక్కరిచే కనుగొనబడింది. నిజానికి, ఈ నమూనాను ఇప్పుడు GitOps అంటారు (మీరు పదం మరియు దాని వెనుక ఉన్న ఆలోచనల గురించి మరింత చదువుకోవచ్చు ఇక్కడ). పథకం యొక్క దశలను చూద్దాం.

వేదికను నిర్మించండి

2019లో డాకర్‌ఫైల్స్‌ని ఎలా రాయాలో మరియు రన్ చేయాలో అందరికీ తెలిసినప్పుడు మీరు డాకర్ చిత్రాలను రూపొందించడం గురించి మాట్లాడవచ్చు. docker build?.. నేను శ్రద్ధ వహించాలనుకుంటున్న సూక్ష్మ నైపుణ్యాలు ఇక్కడ ఉన్నాయి:

1. చిత్రం బరువు ముఖ్యమైనది, కాబట్టి ఉపయోగించండి బహుళ-దశఆపరేషన్‌కు నిజంగా అవసరమైన అప్లికేషన్‌ను మాత్రమే చిత్రంలో ఉంచడానికి.
2. పొరల సంఖ్య యొక్క గొలుసులను కలపడం ద్వారా తగ్గించాలి RUN-అర్థం ప్రకారం ఆదేశాలు.
3. అయితే, ఇది సమస్యలను జోడిస్తుంది డీబగ్గింగ్, ఎందుకంటే అసెంబ్లీ క్రాష్ అయినప్పుడు, మీరు సమస్యకు కారణమైన గొలుసు నుండి సరైన ఆదేశాన్ని కనుగొనవలసి ఉంటుంది.
4. అసెంబ్లీ వేగం ముఖ్యమైనది ఎందుకంటే మేము మార్పులను త్వరగా విడుదల చేసి ఫలితాలను చూడాలనుకుంటున్నాము. ఉదాహరణకు, మీరు అప్లికేషన్‌ను రూపొందించిన ప్రతిసారీ భాషా లైబ్రరీలలో డిపెండెన్సీలను పునర్నిర్మించకూడదు.
5. తరచుగా మీకు అవసరమైన ఒక Git రిపోజిటరీ నుండి అనేక చిత్రాలు, ఇది డాకర్‌ఫైల్‌ల సెట్ (లేదా ఒక ఫైల్‌లో పేరు పెట్టబడిన దశలు) మరియు వాటి సీక్వెన్షియల్ అసెంబ్లీతో బాష్ స్క్రిప్ట్ ద్వారా పరిష్కరించబడుతుంది.

ఇది ప్రతి ఒక్కరూ ఎదుర్కొనే మంచుకొండ యొక్క కొన మాత్రమే. కానీ ఇతర సమస్యలు ఉన్నాయి, ముఖ్యంగా:

1. తరచుగా అసెంబ్లీ దశలో మనకు ఏదో అవసరం మౌంట్ (ఉదాహరణకు, థర్డ్-పార్టీ డైరెక్టరీలో apt వంటి కమాండ్ ఫలితాన్ని కాష్ చేయండి).
2. మాకు కావాలి చేసాడు షెల్‌లో వ్రాయడానికి బదులుగా.
3. మాకు కావాలి డాకర్ లేకుండా నిర్మించండి (మేము ఇప్పటికే కుబెర్నెట్స్ క్లస్టర్‌ని కలిగి ఉన్నప్పుడు, దాని కోసం మనం ప్రతిదాన్ని కాన్ఫిగర్ చేయాల్సిన అదనపు వర్చువల్ మెషీన్ ఎందుకు అవసరం?).
4. సమాంతర అసెంబ్లీ, ఇది వివిధ మార్గాల్లో అర్థం చేసుకోవచ్చు: Dockerfile నుండి వేర్వేరు ఆదేశాలు (బహుళ-దశలను ఉపయోగించినట్లయితే), ఒకే రిపోజిటరీ యొక్క అనేక కమిట్‌లు, అనేక డాకర్ ఫైల్‌లు.
5. పంపిణీ చేసిన అసెంబ్లీ: మేము ఎందుకంటే "అశాశ్వతమైన" పాడ్‌లలో వస్తువులను సేకరించాలనుకుంటున్నాము వారి కాష్ అదృశ్యమవుతుంది, అంటే అది ఎక్కడో విడిగా నిల్వ చేయబడాలి.
6. చివరగా, నేను కోరికల పరాకాష్ట అని పేరు పెట్టాను ఆటోమేజిక్: రిపోజిటరీకి వెళ్లి, కొంత కమాండ్‌ని టైప్ చేసి, సరిగ్గా ఎలా మరియు ఏమి చేయాలో అవగాహనతో సమీకరించబడిన రెడీమేడ్ ఇమేజ్‌ని పొందడం ఆదర్శంగా ఉంటుంది. అయినప్పటికీ, అన్ని సూక్ష్మ నైపుణ్యాలను ఈ విధంగా ఊహించవచ్చని నాకు వ్యక్తిగతంగా ఖచ్చితంగా తెలియదు.

మరియు ఇక్కడ ప్రాజెక్ట్‌లు ఉన్నాయి:

• moby/buildkit — Docker Inc నుండి ఒక బిల్డర్ (ఇప్పటికే డాకర్ యొక్క ప్రస్తుత సంస్కరణల్లోకి విలీనం చేయబడింది), ఇది ఈ సమస్యలన్నింటినీ పరిష్కరించడానికి ప్రయత్నిస్తోంది;
• కానికో - డాకర్ లేకుండా నిర్మించడానికి మిమ్మల్ని అనుమతించే Google నుండి బిల్డర్;
• Buildpacks.io - ఆటోమేటిక్ మ్యాజిక్ చేయడానికి CNCF యొక్క ప్రయత్నం మరియు, ప్రత్యేకించి, లేయర్‌లకు రీబేస్‌తో ఆసక్తికరమైన పరిష్కారం;
• మరియు వంటి ఇతర యుటిలిటీల సమూహం బిల్డా, genuinetools/img...

...మరియు వారు GitHubలో ఎన్ని నక్షత్రాలను కలిగి ఉన్నారో చూడండి. అంటే ఒకవైపు.. docker build ఉనికిలో ఉంది మరియు ఏదైనా చేయగలదు, కానీ వాస్తవానికి సమస్య పూర్తిగా పరిష్కరించబడలేదు - దీనికి రుజువు ప్రత్యామ్నాయ కలెక్టర్ల సమాంతర అభివృద్ధి, వీటిలో ప్రతి ఒక్కటి కొన్ని సమస్యలను పరిష్కరిస్తుంది.

వెర్ఫ్‌లో అసెంబ్లీ

కాబట్టి మేము వచ్చింది వర్ఫ్ (గతంలో ప్రసిద్ధ డాప్ లాగా) - ఫ్లాంట్ కంపెనీ నుండి ఓపెన్ సోర్స్ యుటిలిటీ, మేము చాలా సంవత్సరాలుగా తయారు చేస్తున్నాము. ఇదంతా 5 సంవత్సరాల క్రితం డాకర్‌ఫైల్స్ అసెంబ్లీని ఆప్టిమైజ్ చేసిన బాష్ స్క్రిప్ట్‌లతో ప్రారంభమైంది మరియు గత 3 సంవత్సరాలుగా పూర్తి స్థాయి అభివృద్ధి దాని స్వంత Git రిపోజిటరీతో ఒక ప్రాజెక్ట్ యొక్క ఫ్రేమ్‌వర్క్‌లో నిర్వహించబడింది. (మొదట రూబీలో, ఆపై తిరిగి వ్రాయబడింది వెళ్ళడానికి, మరియు అదే సమయంలో పేరు మార్చబడింది). వెర్ఫ్‌లో ఏ అసెంబ్లీ సమస్యలు పరిష్కరించబడతాయి?

నీలం రంగులో ఉన్న సమస్యలు ఇప్పటికే అమలు చేయబడ్డాయి, అదే హోస్ట్‌లో సమాంతర నిర్మాణం జరిగింది మరియు పసుపు రంగులో హైలైట్ చేయబడిన సమస్యలను వేసవి చివరి నాటికి పూర్తి చేయడానికి ప్రణాళిక చేయబడింది.

రిజిస్ట్రీలో ప్రచురణ దశ (ప్రచురించండి)

మేము డయల్ చేసాము docker push... - రిజిస్ట్రీకి ఇమేజ్‌ని అప్‌లోడ్ చేయడంలో కష్టమేంటి? ఆపై ప్రశ్న తలెత్తుతుంది: "నేను చిత్రంలో ఏ ట్యాగ్ ఉంచాలి?" ఇది మనకు ఉన్న కారణం కోసం పుడుతుంది Gitflow (లేదా ఇతర Git వ్యూహం) మరియు కుబెర్నెట్స్, మరియు పరిశ్రమ కుబెర్నెట్స్‌లో ఏమి జరుగుతుందో Gitలో ఏమి జరుగుతుందో నిర్ధారించడానికి ప్రయత్నిస్తోంది. అన్నింటికంటే, Git మాత్రమే సత్యానికి మూలం.

ఇందులో అంత కష్టం ఏమిటి? పునరుత్పత్తిని నిర్ధారించుకోండి: Git లో నిబద్ధత నుండి, ఇది స్వభావంలో మార్పులేనిది (మార్పులేని), డాకర్ ఇమేజ్‌కి, అదే విధంగా ఉంచాలి.

అది కూడా మనకు ముఖ్యం మూలాన్ని నిర్ణయించండి, ఎందుకంటే కుబెర్నెట్స్‌లో నడుస్తున్న అప్లికేషన్ ఏ కమిట్‌తో నిర్మించబడిందో మనం అర్థం చేసుకోవాలనుకుంటున్నాము (అప్పుడు మనం తేడాలు మరియు ఇలాంటి పనులు చేయవచ్చు).

ట్యాగింగ్ వ్యూహాలు

మొదటిది సరళమైనది git ట్యాగ్. చిత్రంగా ట్యాగ్ చేయబడిన రిజిస్ట్రీని కలిగి ఉన్నాము 1.0. కుబెర్నెటీస్ వేదిక మరియు ఉత్పత్తిని కలిగి ఉంది, ఇక్కడ ఈ చిత్రం అప్‌లోడ్ చేయబడింది. Gitలో మనం కమిట్‌లు చేస్తాము మరియు ఏదో ఒక సమయంలో ట్యాగ్ చేస్తాము 2.0. మేము రిపోజిటరీ నుండి సూచనల ప్రకారం దానిని సేకరిస్తాము మరియు ట్యాగ్తో రిజిస్ట్రీలో ఉంచండి 2.0. మేము దానిని స్టేజ్‌కి మరియు అన్నీ బాగానే ఉంటే, ఉత్పత్తికి వెళ్లండి.

ఈ విధానంలో సమస్య ఏమిటంటే, మేము మొదట ట్యాగ్‌ని ఉంచాము, ఆపై మాత్రమే పరీక్షించి దాన్ని రూపొందించాము. ఎందుకు? ముందుగా, ఇది కేవలం అశాస్త్రీయమైనది: మేము ఇంకా పరీక్షించని సాఫ్ట్‌వేర్ వెర్షన్‌ను జారీ చేస్తున్నాము (మేము లేకపోతే చేయలేము, ఎందుకంటే తనిఖీ చేయడానికి, మేము ట్యాగ్‌ని ఉంచాలి). రెండవది, ఈ మార్గం Gitflowకి అనుకూలంగా లేదు.

రెండవ ఎంపిక git కమిట్ + ట్యాగ్. మాస్టర్ బ్రాంచ్‌కు ట్యాగ్ ఉంది 1.0; రిజిస్ట్రీలో దాని కోసం - ఉత్పత్తికి అమర్చబడిన చిత్రం. అదనంగా, కుబెర్నెటెస్ క్లస్టర్‌లో ప్రివ్యూ మరియు స్టేజింగ్ కాంటౌర్స్ ఉన్నాయి. తరువాత మేము Gitflowని అనుసరిస్తాము: అభివృద్ధి కోసం ప్రధాన శాఖలో (develop) మేము కొత్త ఫీచర్‌లను చేస్తాము, ఫలితంగా ఐడెంటిఫైయర్‌తో నిబద్ధత ఏర్పడుతుంది #c1. మేము దానిని సేకరించి, ఈ ఐడెంటిఫైయర్ ఉపయోగించి రిజిస్ట్రీలో ప్రచురిస్తాము (#c1) అదే ఐడెంటిఫైయర్‌తో మేము ప్రివ్యూకి వెళ్తాము. మేము కమిట్‌లతో కూడా అదే చేస్తాము #c2 и #c3.

తగినంత లక్షణాలు ఉన్నాయని మేము గ్రహించినప్పుడు, మేము ప్రతిదీ స్థిరీకరించడం ప్రారంభిస్తాము. Gitలో ఒక శాఖను సృష్టించండి release_1.1 (బేస్ మీద #c3 నుండి develop) ఈ విడుదలను సేకరించాల్సిన అవసరం లేదు, ఎందుకంటే... ఇది మునుపటి దశలో జరిగింది. అందువల్ల, మేము దానిని కేవలం స్టేజింగ్‌కు వెళ్లవచ్చు. మేము లోపాలను పరిష్కరిస్తాము #c4 మరియు అదేవిధంగా స్టేజింగ్‌కి వెళ్లండి. అదే సమయంలో, అభివృద్ధి జరుగుతోంది develop, ఇక్కడ మార్పులు క్రమానుగతంగా తీసుకోబడతాయి release_1.1. ఏదో ఒక సమయంలో, మేము కమిట్‌ను కంపైల్ చేసి స్టేజింగ్‌కి అప్‌లోడ్ చేస్తాము, దానితో మేము సంతోషిస్తాము (#c25).

అప్పుడు మేము విడుదల శాఖను (ఫాస్ట్-ఫార్వర్డ్‌తో) విలీనం చేస్తాము (release_1.1) మాస్టర్ లో. మేము ఈ కమిట్‌పై కొత్త వెర్షన్‌తో ట్యాగ్‌ని ఉంచాము (1.1) కానీ ఈ చిత్రం ఇప్పటికే రిజిస్ట్రీలో సేకరించబడింది, కాబట్టి దీన్ని మళ్లీ సేకరించకుండా ఉండటానికి, మేము ఇప్పటికే ఉన్న చిత్రానికి రెండవ ట్యాగ్‌ని జోడిస్తాము (ఇప్పుడు దీనికి రిజిస్ట్రీలో ట్యాగ్‌లు ఉన్నాయి. #c25 и 1.1) ఆ తరువాత, మేము దానిని ఉత్పత్తికి విడుదల చేస్తాము.

స్టేజింగ్‌కి ఒక చిత్రం మాత్రమే అప్‌లోడ్ చేయబడటంలో ఒక లోపం ఉంది (#c25), మరియు ఉత్పత్తిలో ఇది భిన్నంగా ఉంటుంది (1.1), కానీ "భౌతికంగా" ఇవి రిజిస్ట్రీ నుండి ఒకే చిత్రం అని మాకు తెలుసు.

నిజమైన ప్రతికూలత ఏమిటంటే, విలీన ఒప్పందాలకు మద్దతు లేదు, మీరు ఫాస్ట్-ఫార్వర్డ్ చేయాలి.

మనం మరింత ముందుకు వెళ్లి ఒక ఉపాయం చేయవచ్చు... ఒక సాధారణ డాకర్‌ఫైల్ ఉదాహరణను చూద్దాం:

FROM ruby:2.3 as assets
RUN mkdir -p /app
WORKDIR /app
COPY . ./
RUN gem install bundler && bundle install
RUN bundle exec rake assets:precompile
CMD bundle exec puma -C config/puma.rb

FROM nginx:alpine
COPY --from=assets /app/public /usr/share/nginx/www/public

కింది సూత్రం ప్రకారం దాని నుండి ఫైల్‌ను రూపొందిద్దాం:

• ఉపయోగించిన చిత్రాల ఐడెంటిఫైయర్‌ల నుండి SHA256 (ruby:2.3 и nginx:alpine), ఇవి వాటి కంటెంట్‌ల చెక్‌సమ్‌లు;
• అన్ని జట్లు (RUN, CMD మరియు మొదలైనవి);
• జోడించిన ఫైల్‌ల నుండి SHA256.

... మరియు అటువంటి ఫైల్ నుండి చెక్సమ్ (మళ్ళీ SHA256) తీసుకోండి. ఈ సంతకం డాకర్ చిత్రం యొక్క కంటెంట్‌లను నిర్వచించే ప్రతిదీ.

రేఖాచిత్రానికి తిరిగి వెళ్దాం మరియు కమిట్‌లకు బదులుగా మేము అలాంటి సంతకాలను ఉపయోగిస్తాము, అనగా సంతకాలతో చిత్రాలను ట్యాగ్ చేయండి.

ఇప్పుడు, అవసరమైనప్పుడు, ఉదాహరణకు, విడుదల నుండి మాస్టర్‌కు మార్పులను విలీనం చేయడానికి, మేము నిజమైన విలీన కమిట్‌ను చేయవచ్చు: దీనికి వేరే ఐడెంటిఫైయర్ ఉంటుంది, కానీ అదే సంతకం ఉంటుంది. అదే ఐడెంటిఫైయర్‌తో మేము చిత్రాన్ని ఉత్పత్తికి విడుదల చేస్తాము.

ప్రతికూలత ఏమిటంటే, ఉత్పత్తికి ఎలాంటి నిబద్ధత పురికొల్పబడిందో ఇప్పుడు గుర్తించడం సాధ్యం కాదు - చెక్‌సమ్‌లు ఒక దిశలో మాత్రమే పని చేస్తాయి. మెటాడేటాతో అదనపు లేయర్ ద్వారా ఈ సమస్య పరిష్కరించబడుతుంది - నేను మీకు తర్వాత చెబుతాను.

వెర్ఫ్‌లో ట్యాగ్ చేయడం

వెర్ఫ్‌లో మేము మరింత ముందుకు వెళ్లి, ఒక మెషీన్‌లో నిల్వ చేయని కాష్‌తో పంపిణీ చేయబడిన బిల్డ్ చేయడానికి సిద్ధం చేస్తున్నాము... కాబట్టి, మేము రెండు రకాల డాకర్ చిత్రాలను నిర్మిస్తున్నాము, మేము వాటిని పిలుస్తాము. రంగస్థల и చిత్రం.

werf Git రిపోజిటరీ బిల్డ్ యొక్క వివిధ దశలను వివరించే బిల్డ్-నిర్దిష్ట సూచనలను నిల్వ చేస్తుంది (ఇన్‌స్టాల్ చేయడానికి ముందు, ఇన్స్టాల్, సెటప్ ముందు, సెటప్) మొదటి దశల చెక్‌సమ్‌గా నిర్వచించబడిన సంతకంతో మేము మొదటి దశ చిత్రాన్ని సేకరిస్తాము. అప్పుడు మేము సోర్స్ కోడ్‌ను జోడిస్తాము, కొత్త దశ చిత్రం కోసం మేము దాని చెక్‌సమ్‌ను గణిస్తాము... ఈ కార్యకలాపాలు అన్ని దశలకు పునరావృతమవుతాయి, దీని ఫలితంగా మేము దశ చిత్రాల సమితిని పొందుతాము. అప్పుడు మేము తుది చిత్రాన్ని తయారు చేస్తాము, దాని మూలం గురించి మెటాడేటా కూడా ఉంటుంది. మరియు మేము ఈ చిత్రాన్ని వివిధ మార్గాల్లో ట్యాగ్ చేస్తాము (వివరాలు తరువాత).

దీని తర్వాత అప్లికేషన్ కోడ్ మాత్రమే మార్చబడిన కొత్త కమిట్ కనిపించిందని అనుకుందాం. ఏమి జరుగుతుంది? కోడ్ మార్పుల కోసం, ఒక ప్యాచ్ సృష్టించబడుతుంది మరియు కొత్త దశ చిత్రం సిద్ధం చేయబడుతుంది. దీని సంతకం పాత స్టేజ్ ఇమేజ్ మరియు కొత్త ప్యాచ్ యొక్క చెక్‌సమ్‌గా నిర్ణయించబడుతుంది. ఈ చిత్రం నుండి కొత్త తుది చిత్రం రూపొందించబడుతుంది. ఇతర దశల్లో మార్పులతో ఇలాంటి ప్రవర్తన జరుగుతుంది.

ఈ విధంగా, స్టేజ్ ఇమేజ్‌లు అనేది పంపిణీలో నిల్వ చేయగల కాష్ మరియు దాని నుండి ఇప్పటికే సృష్టించబడిన చిత్రాలు డాకర్ రిజిస్ట్రీకి అప్‌లోడ్ చేయబడతాయి.

రిజిస్ట్రీని శుభ్రపరచడం

తొలగించబడిన ట్యాగ్‌ల తర్వాత వేలాడుతున్న లేయర్‌లను తొలగించడం గురించి మేము మాట్లాడటం లేదు - ఇది డాకర్ రిజిస్ట్రీ యొక్క ప్రామాణిక లక్షణం. చాలా డాకర్ ట్యాగ్‌లు పేరుకుపోయినప్పుడు మేము ఒక పరిస్థితి గురించి మాట్లాడుతున్నాము మరియు వాటిలో కొన్ని ఇకపై మనకు అవసరం లేదని మేము అర్థం చేసుకున్నాము, కానీ అవి స్థలాన్ని తీసుకుంటాయి (మరియు/లేదా మేము దాని కోసం చెల్లిస్తాము).

శుభ్రపరిచే వ్యూహాలు ఏమిటి?

1. మీరు ఏమీ చేయలేరు శుభ్రం చేయవద్దు. కొన్నిసార్లు ట్యాగ్‌ల యొక్క భారీ చిక్కును విప్పడం కంటే అదనపు స్థలం కోసం కొంచెం చెల్లించడం చాలా సులభం. కానీ ఇది ఒక నిర్దిష్ట పాయింట్ వరకు మాత్రమే పని చేస్తుంది.
2. పూర్తి రీసెట్. మీరు అన్ని చిత్రాలను తొలగించి, CI సిస్టమ్‌లో ప్రస్తుత వాటిని మాత్రమే పునర్నిర్మిస్తే, సమస్య తలెత్తవచ్చు. ఉత్పత్తిలో కంటైనర్ పునఃప్రారంభించబడితే, దాని కోసం కొత్త చిత్రం లోడ్ చేయబడుతుంది - ఇది ఇంకా ఎవరిచేత పరీక్షించబడలేదు. ఇది మార్పులేని మౌలిక సదుపాయాల ఆలోచనను నాశనం చేస్తుంది.
3. నీలి ఆకుపచ్చ. ఒక రిజిస్ట్రీ ఓవర్‌ఫ్లో ప్రారంభమైంది - మేము చిత్రాలను మరొకదానికి అప్‌లోడ్ చేస్తాము. మునుపటి పద్ధతిలో అదే సమస్య: ఓవర్‌ఫ్లో ప్రారంభించిన రిజిస్ట్రీని మీరు ఏ సమయంలో క్లియర్ చేయవచ్చు?
4. సమయానికి. 1 నెల కంటే పాత అన్ని చిత్రాలను తొలగించాలా? అయితే నెల రోజులుగా అప్‌డేట్ చేయని సర్వీస్ ఖచ్చితంగా ఉంటుంది...
5. మానవీయంగా ఇప్పటికే ఏమి తొలగించబడవచ్చో నిర్ణయించండి.

రెండు నిజంగా ఆచరణీయ ఎంపికలు ఉన్నాయి: శుభ్రం చేయవద్దు లేదా నీలం-ఆకుపచ్చ + మానవీయంగా కలయిక. తరువాతి సందర్భంలో, మేము ఈ క్రింది వాటి గురించి మాట్లాడుతున్నాము: రిజిస్ట్రీని శుభ్రం చేయడానికి ఇది సమయం అని మీరు అర్థం చేసుకున్నప్పుడు, మీరు క్రొత్తదాన్ని సృష్టించి, దానికి ఒక నెలలో అన్ని కొత్త చిత్రాలను జోడించండి. మరియు ఒక నెల తర్వాత, కుబెర్నెట్స్‌లోని ఏ పాడ్‌లు ఇప్పటికీ పాత రిజిస్ట్రీని ఉపయోగిస్తున్నాయో చూడండి మరియు వాటిని కూడా కొత్త రిజిస్ట్రీకి బదిలీ చేయండి.

మనం దేనికి వచ్చాము వర్ఫ్? మేము సేకరిస్తాము:

1. Git head: అన్ని ట్యాగ్‌లు, అన్ని శాఖలు - చిత్రాలలో Gitలో ట్యాగ్ చేయబడిన ప్రతిదీ మనకు అవసరమని భావించి (మరియు లేకపోతే, మేము దానిని Gitలోనే తొలగించాలి);
2. ప్రస్తుతం కుబెర్నెట్స్‌కు పంప్ చేయబడిన అన్ని పాడ్‌లు;
3. పాత రెప్లికాసెట్స్ (ఇటీవల విడుదల చేయబడినవి), మరియు మేము హెల్మ్ విడుదలలను స్కాన్ చేయడానికి మరియు అక్కడ తాజా చిత్రాలను ఎంచుకోవాలని కూడా ప్లాన్ చేస్తున్నాము.

... మరియు ఈ సెట్ నుండి వైట్‌లిస్ట్ చేయండి - మేము తొలగించని చిత్రాల జాబితా. మేము మిగతావన్నీ శుభ్రం చేస్తాము, ఆ తర్వాత మేము అనాధ దశ చిత్రాలను కనుగొని వాటిని కూడా తొలగిస్తాము.

దశను విస్తరించండి

విశ్వసనీయ ప్రకటన

డిక్లరేటివ్‌గా ప్రకటించబడిన అప్‌డేట్ చేయబడిన రిసోర్స్ కాన్ఫిగరేషన్ యొక్క రోల్ అవుట్ గురించి నేను విస్తరణలో దృష్టిని ఆకర్షించాలనుకుంటున్నాను. Kubernetes వనరులను వివరించే అసలైన YAML పత్రం, వాస్తవానికి క్లస్టర్‌లో నడుస్తున్న ఫలితం నుండి ఎల్లప్పుడూ చాలా భిన్నంగా ఉంటుంది. ఎందుకంటే కుబెర్నెట్స్ కాన్ఫిగరేషన్‌కి జోడిస్తుంది:

1. ఐడెంటిఫైయర్లు;
2. సేవ సమాచారం;
3. అనేక డిఫాల్ట్ విలువలు;
4. ప్రస్తుత స్థితితో విభాగం;
5. ప్రవేశ వెబ్‌హుక్‌లో భాగంగా చేసిన మార్పులు;
6. వివిధ కంట్రోలర్లు (మరియు షెడ్యూలర్) యొక్క పని ఫలితం.

కాబట్టి, కొత్త రిసోర్స్ కాన్ఫిగరేషన్ కనిపించినప్పుడు (కొత్త), మేము దానితో ప్రస్తుత, “లైవ్” కాన్ఫిగరేషన్‌ని తీసుకోలేము మరియు ఓవర్‌రైట్ చేయలేము (ప్రత్యక్ష) దీన్ని చేయడానికి, మనం పోల్చాలి కొత్త చివరిగా దరఖాస్తు చేసిన కాన్ఫిగరేషన్‌తో (చివరిగా దరఖాస్తు) మరియు పైకి వెళ్లండి ప్రత్యక్ష పాచ్ అందుకుంది.

ఈ విధానాన్ని అంటారు 2-మార్గం విలీనం. ఇది హెల్మ్‌లో ఉపయోగించబడుతుంది.

కూడా ఉంది 3-మార్గం విలీనం, ఇది భిన్నంగా ఉంటుంది:

• పోల్చడం చివరిగా దరఖాస్తు и కొత్త, మేము తొలగించబడిన వాటిని పరిశీలిస్తాము;
• పోల్చడం కొత్త и ప్రత్యక్ష, మేము జోడించిన లేదా మార్చబడిన వాటిని చూస్తాము;
• సంక్షిప్త పాచ్ వర్తించబడుతుంది ప్రత్యక్ష.

మేము హెల్మ్‌తో 1000+ అప్లికేషన్‌లను అమలు చేస్తాము, కాబట్టి మేము వాస్తవానికి 2-మార్గం విలీనంతో జీవిస్తాము. అయినప్పటికీ, ఇది మా ప్యాచ్‌లతో మేము పరిష్కరించిన అనేక సమస్యలను కలిగి ఉంది, ఇది హెల్మ్ సాధారణంగా పని చేయడానికి సహాయపడుతుంది.

నిజమైన రోల్అవుట్ స్థితి

మా CI సిస్టమ్ తదుపరి ఈవెంట్ ఆధారంగా Kubernetes కోసం కొత్త కాన్ఫిగరేషన్‌ను రూపొందించిన తర్వాత, అది ఉపయోగం కోసం దాన్ని ప్రసారం చేస్తుంది (వర్తించు) ఒక క్లస్టర్‌కి - హెల్మ్ ఉపయోగించి లేదా kubectl apply. తర్వాత, ఇప్పటికే వివరించిన N-మార్గం విలీనం జరుగుతుంది, దీనికి Kubernetes API CI సిస్టమ్‌కు మరియు దాని వినియోగదారుకు ఆమోదం తెలుపుతూ ప్రతిస్పందిస్తుంది.

అయితే, ఒక పెద్ద సమస్య ఉంది: అన్ని తరువాత విజయవంతమైన అప్లికేషన్ అంటే విజయవంతమైన రోల్ అవుట్ అని కాదు. కుబెర్నెటెస్ ఏ మార్పులను వర్తింపజేయాలో అర్థం చేసుకుని, దానిని వర్తింపజేస్తే, ఫలితం ఎలా ఉంటుందో మాకు ఇంకా తెలియదు. ఉదాహరణకు, ఫ్రంటెండ్‌లో పాడ్‌లను నవీకరించడం మరియు పునఃప్రారంభించడం విజయవంతం కావచ్చు, కానీ బ్యాకెండ్‌లో కాదు, మరియు మేము రన్నింగ్ అప్లికేషన్ ఇమేజ్‌ల యొక్క విభిన్న వెర్షన్‌లను పొందుతాము.

ప్రతిదీ సరిగ్గా చేయడానికి, ఈ స్కీమ్‌కు అదనపు లింక్ అవసరం - ప్రత్యేక ట్రాకర్, ఇది Kubernetes API నుండి స్థితి సమాచారాన్ని అందుకుంటుంది మరియు వాస్తవ స్థితి యొక్క తదుపరి విశ్లేషణ కోసం దానిని ప్రసారం చేస్తుంది. మేము గోలో ఓపెన్ సోర్స్ లైబ్రరీని సృష్టించాము - క్యూబ్డాగ్ (దాని ప్రకటన చూడండి ఇక్కడ), ఇది ఈ సమస్యను పరిష్కరిస్తుంది మరియు వెర్ఫ్‌లో నిర్మించబడింది.

వెర్ఫ్ స్థాయిలో ఈ ట్రాకర్ యొక్క ప్రవర్తన విస్తరణలు లేదా స్టేట్‌ఫుల్‌సెట్‌లలో ఉంచబడిన ఉల్లేఖనాలను ఉపయోగించి కాన్ఫిగర్ చేయబడింది. ప్రధాన వ్యాఖ్యానం - fail-mode - కింది అర్థాలను అర్థం చేసుకుంటుంది:

• IgnoreAndContinueDeployProcess - మేము ఈ భాగాన్ని రోలింగ్ చేయడంలో సమస్యలను విస్మరిస్తాము మరియు విస్తరణను కొనసాగిస్తాము;
• FailWholeDeployProcessImmediately - ఈ భాగంలో లోపం విస్తరణ ప్రక్రియను నిలిపివేస్తుంది;
• HopeUntilEndOfDeployProcess — విస్తరణ ముగిసే సమయానికి ఈ భాగం పని చేస్తుందని మేము ఆశిస్తున్నాము.

ఉదాహరణకు, ఈ వనరులు మరియు ఉల్లేఖన విలువల కలయిక fail-mode:

మేము మొదటి సారి అమలు చేసినప్పుడు, డేటాబేస్ (MongoDB) ఇంకా సిద్ధంగా ఉండకపోవచ్చు - విస్తరణలు విఫలమవుతాయి. కానీ అది ప్రారంభించడానికి మీరు క్షణం వేచి ఉండవచ్చు మరియు విస్తరణ ఇప్పటికీ జరుగుతుంది.

వెర్ఫ్‌లో కుబెడాగ్ కోసం మరో రెండు ఉల్లేఖనాలు ఉన్నాయి:

• failures-allowed-per-replica - ప్రతి ప్రతిరూపానికి అనుమతించబడిన ఫాల్స్ సంఖ్య;
• show-logs-until - వెర్ఫ్ అన్ని రోల్ అవుట్ పాడ్‌ల నుండి లాగ్‌లను (stdoutలో) చూపే క్షణాన్ని నియంత్రిస్తుంది. డిఫాల్ట్ ఉంది PodIsReady (పాడ్‌కి ట్రాఫిక్ రావడం ప్రారంభించినప్పుడు మనం కోరుకోని సందేశాలను విస్మరించడానికి), కానీ విలువలు కూడా చెల్లుబాటులో ఉంటాయి: ControllerIsReady и EndOfDeploy.

విస్తరణ నుండి మనకు ఇంకా ఏమి కావాలి?

ఇప్పటికే వివరించిన రెండు పాయింట్లకు అదనంగా, మేము కోరుకుంటున్నాము:

• చూడండి చిట్టాలు - మరియు అవసరమైనవి మాత్రమే, మరియు వరుసగా ప్రతిదీ కాదు;
• ట్రాక్ పురోగతి, ఎందుకంటే ఉద్యోగం చాలా నిమిషాలు "నిశ్శబ్దంగా" వేలాడుతుంటే, అక్కడ ఏమి జరుగుతుందో అర్థం చేసుకోవడం ముఖ్యం;
• иметь ఆటోమేటిక్ రోల్‌బ్యాక్ ఏదైనా తప్పు జరిగితే (అందువలన విస్తరణ యొక్క వాస్తవ స్థితిని తెలుసుకోవడం చాలా కీలకం). రోల్అవుట్ తప్పనిసరిగా పరమాణువుగా ఉండాలి: అది చివరి వరకు వెళుతుంది లేదా ప్రతిదీ దాని మునుపటి స్థితికి తిరిగి వస్తుంది.

ఫలితాలు

ఒక కంపెనీగా మాకు, డెలివరీ యొక్క వివిధ దశలలో వివరించిన అన్ని సూక్ష్మ నైపుణ్యాలను అమలు చేయడానికి (బిల్డ్, పబ్లిష్, డిప్లాయ్), CI సిస్టమ్ మరియు యుటిలిటీ సరిపోతుంది. వర్ఫ్.

ముగింపుకు బదులుగా:

werf సహాయంతో, DevOps ఇంజనీర్‌ల కోసం పెద్ద సంఖ్యలో సమస్యలను పరిష్కరించడంలో మేము మంచి పురోగతిని సాధించాము మరియు విస్తృత కమ్యూనిటీ కనీసం ఈ ప్రయోజనాన్ని చర్యలో ప్రయత్నించినట్లయితే సంతోషిస్తాము. కలిసి మంచి ఫలితాన్ని సాధించడం సులభం అవుతుంది.

వీడియోలు మరియు స్లయిడ్‌లు

పనితీరు నుండి వీడియో (~47 నిమిషాలు):

నివేదిక ప్రదర్శన:

PS

మా బ్లాగులో Kubernetes గురించి ఇతర నివేదికలు:

• «కుబెర్నెట్స్‌లో ఆటోస్కేలింగ్ మరియు వనరుల నిర్వహణ» (డిమిత్రి స్టోలియారోవ్; ఏప్రిల్ 27, 2019 “స్ట్రైక్”పై);
• «కుబెర్నెట్‌లను విస్తరించడం మరియు పూర్తి చేయడం» (ఆండ్రీ పోలోవోవ్; ఏప్రిల్ 8, 2019 సెయింట్ హైలోడ్++లో);
• «డేటాబేస్‌లు మరియు కుబెర్నెట్స్» (డిమిత్రి స్టోలియారోవ్; నవంబర్ 8, 2018 హైలోడ్++లో);
• «పర్యవేక్షణ మరియు కుబెర్నెట్స్» (డిమిత్రి స్టోలియారోవ్; మే 28, 2018 రూట్‌కాన్ఫ్‌లో);
• «Kubernetes మరియు GitLabతో CI/CD ఉత్తమ అభ్యాసాలు» (డిమిత్రి స్టోలియారోవ్; నవంబర్ 7, 2017 హైలోడ్++లో);
• «చిన్న ప్రాజెక్ట్‌లలో కుబెర్నెట్స్‌తో మా అనుభవం» (డిమిత్రి స్టోలియారోవ్; జూన్ 6, 2017 రూట్‌కాన్ఫ్‌లో).

మూలం: www.habr.com