అందరికి వందనాలు! నా పేరు పావెల్ అగాలెట్స్కీ. నేను లామోడా డెలివరీ సిస్టమ్‌ను అభివృద్ధి చేసే బృందంలో టీమ్ లీడ్‌గా పని చేస్తున్నాను. 2018లో, నేను HighLoad++ కాన్ఫరెన్స్‌లో మాట్లాడాను మరియు ఈ రోజు నేను నా నివేదిక యొక్క ట్రాన్‌స్క్రిప్ట్‌ను సమర్పించాలనుకుంటున్నాను.

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

VMకి దరఖాస్తులను అమలు చేస్తోంది

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

ఇది ఎందుకు జరిగింది?

మేము మా అప్లికేషన్ యొక్క కొత్త విడుదలలను అమలు చేసినప్పుడు, వినియోగదారులకు గుర్తించదగిన పరిణామాలు లేకుండా, అతుకులు లేని రోల్‌అవుట్‌ని మేము నిర్ధారించాలనుకుంటున్నాము. అన్సిబుల్‌ని ఉపయోగించి తదుపరి సంకలనం చేయబడిన విడుదల టెయిల్‌కి రోల్‌అవుట్ చేయబడినందున ఇది సాధించబడింది. అక్కడ, విస్తరణలో పాల్గొన్న వ్యక్తులు తనిఖీ చేసి, అంతా బాగానే ఉందని నిర్ధారించుకోవచ్చు: అన్ని మెట్రిక్‌లు, విభాగాలు మరియు అప్లికేషన్‌లు పని చేస్తున్నాయి; అవసరమైన స్క్రిప్ట్‌లు ప్రారంభించబడ్డాయి. అంతా సవ్యంగా ఉందని నిర్ధారించుకున్న తర్వాతే ట్రాఫిక్‌ను మార్చారు. ఇది గతంలో తోకలో ఉన్న సర్వర్‌కు వెళ్లడం ప్రారంభించింది. మరియు మా అప్లికేషన్ యొక్క మునుపటి సంస్కరణను కలిగి ఉన్నప్పటికీ, ఇంతకు ముందు హెడ్‌గా ఉన్న వ్యక్తి వినియోగదారు ట్రాఫిక్ లేకుండానే ఉన్నారు.

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

వీటన్నింటిలో మనం ఏ ప్రయోజనాలను చూశాము?

1. అన్నింటిలో మొదటిది, ఇది సరిపోతుంది ఇది కేవలం పనిచేస్తుంది. అటువంటి విస్తరణ పథకం ఎలా పనిచేస్తుందో అందరూ అర్థం చేసుకుంటారు, ఎందుకంటే చాలా మంది వ్యక్తులు సాధారణ వర్చువల్ సర్వర్‌లకు అమలు చేశారు.
2. ఇది చాలు విశ్వసనీయంగా, విస్తరణ సాంకేతికత చాలా సులభం కనుక, వేలకొద్దీ కంపెనీలు పరీక్షించాయి. లక్షలాది సర్వర్లు ఈ విధంగా అమర్చబడ్డాయి. ఏదైనా విచ్ఛిన్నం చేయడం కష్టం.
3. చివరకు మేము పొందగలిగాము అణు విస్తరణలు. పాత వెర్షన్ మరియు కొత్తదానికి మధ్య మారే గుర్తించదగిన దశ లేకుండా, వినియోగదారుల కోసం ఏకకాలంలో జరిగే విస్తరణలు.

కానీ వీటన్నింటిలో మేము అనేక లోపాలను కూడా చూశాము:

1. ఉత్పత్తి వాతావరణంతో పాటు, అభివృద్ధి వాతావరణం, ఇతర వాతావరణాలు ఉన్నాయి. ఉదాహరణకు, qa మరియు ప్రీప్రొడక్షన్. ఆ సమయంలో మాకు చాలా సర్వర్లు మరియు దాదాపు 60 సేవలు ఉన్నాయి. ఈ కారణంగా ఇది అవసరం ప్రతి సేవ కోసం, దాని కోసం తాజా సంస్కరణను నిర్వహించండి వర్చువల్ యంత్రం. అంతేకాకుండా, మీరు లైబ్రరీలను నవీకరించాలనుకుంటే లేదా కొత్త డిపెండెన్సీలను ఇన్‌స్టాల్ చేయాలనుకుంటే, మీరు దీన్ని అన్ని పరిసరాలలో చేయాలి. డెవొప్స్ అవసరమైన ఎన్విరాన్మెంట్ సెట్టింగ్‌లను అమలు చేసే సమయంతో మీరు మీ అప్లికేషన్ యొక్క తదుపరి కొత్త వెర్షన్‌ని అమలు చేయబోతున్న సమయాన్ని కూడా సమకాలీకరించాలి. ఈ సందర్భంలో, మన పర్యావరణం ఒకేసారి అన్ని వాతావరణాలలో కొంత భిన్నంగా ఉండే పరిస్థితిలోకి రావడం సులభం. ఉదాహరణకు, QA వాతావరణంలో లైబ్రరీల యొక్క కొన్ని సంస్కరణలు ఉంటాయి మరియు ఉత్పత్తి వాతావరణంలో విభిన్నమైనవి ఉంటాయి, ఇది సమస్యలకు దారి తీస్తుంది.
2. డిపెండెన్సీలను నవీకరించడంలో ఇబ్బంది మీ అప్లికేషన్. ఇది మీపై కాదు, ఇతర జట్టుపై ఆధారపడి ఉంటుంది. అవి, సర్వర్‌లను నిర్వహించే devops బృందం నుండి. మీరు వారికి తగిన విధిని మరియు మీరు ఏమి చేయాలనుకుంటున్నారో వివరణ ఇవ్వాలి.
3. ఆ సమయంలో, మేము పెద్ద పెద్ద మోనోలిత్‌లను విడివిడిగా చిన్న చిన్న సేవలుగా విభజించాలనుకుంటున్నాము, ఎందుకంటే అవి మరింత ఎక్కువగా ఉంటాయని మేము అర్థం చేసుకున్నాము. ఆ సమయంలో, మేము ఇప్పటికే వాటిలో 100 కంటే ఎక్కువ కలిగి ఉన్నాము. ప్రతి కొత్త సేవ కోసం, ప్రత్యేక కొత్త వర్చువల్ మెషీన్‌ను సృష్టించడం అవసరం, దానిని కూడా నిర్వహించడం మరియు అమలు చేయడం అవసరం. అదనంగా, మీకు ఒక కారు అవసరం లేదు, కానీ కనీసం రెండు. వీటన్నింటికి QA పర్యావరణం జోడించబడింది. ఇది సమస్యలను కలిగిస్తుంది మరియు మీరు కొత్త సిస్టమ్‌లను నిర్మించడం మరియు అమలు చేయడం మరింత కష్టతరం చేస్తుంది. క్లిష్టమైన, ఖరీదైన మరియు సుదీర్ఘమైన ప్రక్రియ.

అందువల్ల, సాధారణ వర్చువల్ మిషన్‌లను అమలు చేయడం నుండి మా అప్లికేషన్‌లను డాకర్ కంటైనర్‌లో అమర్చడం వరకు మరింత సౌకర్యవంతంగా ఉంటుందని మేము నిర్ణయించుకున్నాము. మీకు డాకర్ ఉన్నట్లయితే, మీరు కేవలం కంటైనర్‌ను పెంచలేరు కాబట్టి, అప్లికేషన్‌ను క్లస్టర్‌లో అమలు చేయగల సిస్టమ్ మీకు అవసరం. సాధారణంగా మీరు ఎన్ని కంటైనర్‌లను ఎత్తివేసారు అనేదానిని ట్రాక్ చేయాలనుకుంటున్నారు, తద్వారా అవి స్వయంచాలకంగా ఎత్తబడతాయి. ఈ కారణంగా, మేము నియంత్రణ వ్యవస్థను ఎంచుకోవాలి.

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

నోమాడ్‌కి మారండి

నోమాడ్ HashiCorp యొక్క ఉత్పత్తి. వారు వారి ఇతర పరిష్కారాలకు కూడా ప్రసిద్ధి చెందారు:

"కాన్సుల్" సేవ ఆవిష్కరణ కోసం ఒక సాధనం.

"టెర్రాఫాం" - ఇన్‌ఫ్రాస్ట్రక్చర్-ఏ-కోడ్ అని పిలవబడే కాన్ఫిగరేషన్ ద్వారా వాటిని కాన్ఫిగర్ చేయడానికి మిమ్మల్ని అనుమతించే సర్వర్‌లను నిర్వహించడానికి సిస్టమ్.

"వాగ్రాంట్" నిర్దిష్ట కాన్ఫిగరేషన్ ఫైల్‌ల ద్వారా స్థానికంగా లేదా క్లౌడ్‌లో వర్చువల్ మిషన్‌లను అమలు చేయడానికి మిమ్మల్ని అనుమతిస్తుంది.

ఆ సమయంలో నోమాడ్ చాలా సరళమైన పరిష్కారంగా అనిపించింది, ఇది మొత్తం మౌలిక సదుపాయాలను మార్చకుండా త్వరగా మార్చబడుతుంది. అదనంగా, నేర్చుకోవడం చాలా సులభం. అందుకే మేము దానిని మా కంటైనర్‌కు వడపోత వ్యవస్థగా ఎంచుకున్నాము.

మీ సిస్టమ్‌ను నోమాడ్‌కి అమర్చడానికి మీరు ఏమి చేయాలి?

1. మీకు కావలసిందల్లా డాకర్ చిత్రం మీ అప్లికేషన్. మీరు దీన్ని నిర్మించి డాకర్ ఇమేజ్ రిపోజిటరీలో ఉంచాలి. మా విషయంలో, ఇది ఒక ఆర్టిఫ్యాక్టరీ - వివిధ రకాలైన వివిధ కళాఖండాలను దానిలోకి నెట్టడానికి మిమ్మల్ని అనుమతించే వ్యవస్థ. ఇది ఆర్కైవ్‌లు, డాకర్ చిత్రాలు, కంపోజర్ PHP ప్యాకేజీలు, NPM ప్యాకేజీలు మొదలైనవాటిని నిల్వ చేయగలదు.
2. కూడా అవసరం కాన్ఫిగరేషన్ ఫైల్, ఇది నోమాడ్‌కి మీరు ఏమి, ఎక్కడ మరియు ఏ పరిమాణంలో అమర్చాలనుకుంటున్నారో తెలియజేస్తుంది.

మేము నోమాడ్ గురించి మాట్లాడేటప్పుడు, ఇది HCL భాషను దాని సమాచార ఫైల్ ఫార్మాట్‌గా ఉపయోగిస్తుంది, దీని అర్థం HashiCorp కాన్ఫిగరేషన్ లాంగ్వేజ్. ఇది Yaml యొక్క సూపర్‌సెట్, ఇది మీ సేవను నోమాడ్ నిబంధనలలో వివరించడానికి మిమ్మల్ని అనుమతిస్తుంది.

మీరు ఎన్ని కంటైనర్‌లను అమర్చాలనుకుంటున్నారో చెప్పడానికి ఇది మిమ్మల్ని అనుమతిస్తుంది, విస్తరణ సమయంలో ఏ చిత్రాల నుండి వివిధ పారామితులను వాటికి పంపాలి. అందువల్ల, మీరు ఈ ఫైల్‌ను నోమాడ్‌కు ఫీడ్ చేస్తారు మరియు దాని ప్రకారం ఉత్పత్తికి కంటైనర్‌లను ప్రారంభిస్తుంది.

మా విషయంలో, ప్రతి సేవ కోసం ఖచ్చితంగా ఒకేలాంటి HCL ఫైల్‌లను వ్రాయడం చాలా సౌకర్యవంతంగా ఉండదని మేము గ్రహించాము, ఎందుకంటే చాలా సేవలు ఉన్నాయి మరియు కొన్నిసార్లు మీరు వాటిని నవీకరించాలనుకుంటున్నారు. ఒక సేవ ఒక సందర్భంలో కాదు, వివిధ రకాలైన వాటిలో అమలు చేయబడుతుంది. ఉదాహరణకు, మేము ఉత్పత్తిలో ఉన్న సిస్టమ్‌లలో ఒకటి ఉత్పత్తిలో 100 కంటే ఎక్కువ సందర్భాలను కలిగి ఉంది. అవి ఒకే చిత్రాల నుండి నడుస్తాయి, కానీ కాన్ఫిగరేషన్ సెట్టింగ్‌లు మరియు కాన్ఫిగరేషన్ ఫైల్‌లలో విభిన్నంగా ఉంటాయి.

అందువల్ల, మా కాన్ఫిగరేషన్ ఫైల్‌లన్నింటినీ ఒక సాధారణ రిపోజిటరీలో డిప్లాయ్‌మెంట్ కోసం నిల్వ చేయడం మాకు సౌకర్యంగా ఉంటుందని మేము నిర్ణయించుకున్నాము. ఈ విధంగా అవి కనిపించేవి: అవి నిర్వహించడం సులభం మరియు మనకు ఏ వ్యవస్థలు ఉన్నాయో చూడగలం. అవసరమైతే, ఏదైనా నవీకరించడం లేదా మార్చడం కూడా సులభం. కొత్త సిస్టమ్‌ను జోడించడం కూడా కష్టం కాదు - మీరు కొత్త డైరెక్టరీలో కాన్ఫిగరేషన్ ఫైల్‌ను సృష్టించాలి. దాని లోపల కింది ఫైల్‌లు ఉన్నాయి: service.hcl, మా సేవ యొక్క వివరణను కలిగి ఉంటుంది మరియు ఈ సేవను కాన్ఫిగర్ చేయడానికి అనుమతించే కొన్ని env ఫైల్‌లు.

అయినప్పటికీ, మా సిస్టమ్‌లలో కొన్ని ఒకే కాపీలో కాకుండా ఒకేసారి అనేక వాటిలో ఉత్పత్తిలో ఉన్నాయి. అందువల్ల, కాన్ఫిగర్‌లను వాటి స్వచ్ఛమైన రూపంలో కాకుండా వాటి టెంప్లేట్ రూపంలో నిల్వ చేయడం మాకు సౌకర్యంగా ఉంటుందని మేము నిర్ణయించుకున్నాము. మరియు మేము ఎంచుకున్నాము జింజా 2. ఈ ఫార్మాట్‌లో, మేము సేవ యొక్క కాన్ఫిగర్‌లు మరియు దానికి అవసరమైన env ఫైల్‌లు రెండింటినీ నిల్వ చేస్తాము.

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

అంటే, మేము కొన్ని కాన్ఫిగర్ లొకేషన్ వేరియబుల్‌లను env ఫైల్‌లు లేదా ఇతర మూలాధారాల నుండి తీసుకున్న చొప్పించిన వేరియబుల్స్‌తో భర్తీ చేసాము. అదనంగా, మేము HCL ఫైల్‌లను డైనమిక్‌గా సేకరించే అవకాశాన్ని పొందాము, అంటే, మేము సాధారణ వేరియబుల్ ఇన్‌సర్షన్‌లను మాత్రమే ఉపయోగించగలము. జింజా లూప్‌లు మరియు షరతులను సపోర్ట్ చేస్తుంది కాబట్టి, మీరు అక్కడ కాన్ఫిగరేషన్ ఫైల్‌లను కూడా సృష్టించవచ్చు, ఇది మీరు మీ అప్లికేషన్‌లను సరిగ్గా ఎక్కడ అమలు చేస్తారనే దానిపై ఆధారపడి మారుతుంది.

ఉదాహరణకు, మీరు మీ సేవను ప్రీ-ప్రొడక్షన్ మరియు ప్రొడక్షన్‌కి ఉపయోగించాలనుకుంటున్నారు. ప్రీ-ప్రొడక్షన్‌లో మీరు క్రాన్ స్క్రిప్ట్‌లను అమలు చేయకూడదనుకుంటున్నారని చెప్పండి, కానీ అది పని చేస్తుందని నిర్ధారించుకోవడానికి ప్రత్యేక డొమైన్‌లో సేవను చూడాలనుకుంటున్నాము. సేవను అమలు చేసే ఎవరికైనా, ప్రక్రియ చాలా సరళంగా మరియు పారదర్శకంగా కనిపిస్తుంది. మీరు చేయవలసిందల్లా deploy.sh ఫైల్‌ని అమలు చేయడం, మీరు ఏ సేవను అమలు చేయాలనుకుంటున్నారో మరియు ఏ లక్ష్యానికి చేరుకోవాలో పేర్కొనండి. ఉదాహరణకు, మీరు రష్యా, బెలారస్ లేదా కజాఖ్స్తాన్‌కు నిర్దిష్ట వ్యవస్థను అమలు చేయాలనుకుంటున్నారు. దీన్ని చేయడానికి, పారామితులలో ఒకదాన్ని మార్చండి మరియు మీకు సరైన కాన్ఫిగరేషన్ ఫైల్ ఉంటుంది.

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

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

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

మానవ వనరుల పరంగా పరివర్తన మాకు ఎంత ఖర్చు చేసింది?

మొత్తం కంపెనీ నోమాడ్‌కి మారడానికి సుమారు 5-6 నెలలు పట్టింది. మేము సర్వీస్ వారీగా, కానీ చాలా వేగవంతమైన వేగంతో తరలించాము. ప్రతి బృందం సేవల కోసం వారి స్వంత కంటైనర్‌లను సృష్టించాలి.

ప్రతి బృందం స్వతంత్రంగా వారి సిస్టమ్‌ల డాకర్ చిత్రాలకు బాధ్యత వహించే విధానాన్ని మేము అనుసరించాము. DevOps విస్తరణకు అవసరమైన సాధారణ అవస్థాపనను అందిస్తాయి, అనగా క్లస్టర్‌కు మద్దతు, CI సిస్టమ్‌కు మద్దతు మొదలైనవి. మరియు ఆ సమయంలో, మేము 60 కంటే ఎక్కువ వ్యవస్థలను నోమాడ్‌కు తరలించాము, ఇది సుమారు 2 వేల కంటైనర్లు.

డిప్లాయ్‌మెంట్ మరియు సర్వర్‌లకు సంబంధించిన అన్నింటికీ సాధారణ మౌలిక సదుపాయాలకు Devops బాధ్యత వహిస్తుంది. మరియు ప్రతి డెవలప్‌మెంట్ టీమ్, దాని నిర్దిష్ట సిస్టమ్ కోసం కంటైనర్‌లను అమలు చేయడానికి బాధ్యత వహిస్తుంది, ఎందుకంటే ఇది ఒక నిర్దిష్ట కంటైనర్‌లో సాధారణంగా ఏమి అవసరమో తెలిసిన బృందం.

సంచారాన్ని విడిచిపెట్టడానికి కారణాలు

నోమాడ్ మరియు డాకర్‌ని ఉపయోగించి విస్తరణకు మారడం ద్వారా మేము ఏ ప్రయోజనాలను పొందాము?

1. మేము సమాన పరిస్థితులను అందించింది అన్ని పర్యావరణాల కోసం. అభివృద్ధిలో, QA పర్యావరణం, ప్రీ-ప్రొడక్షన్, ప్రొడక్షన్, అదే డిపెండెన్సీలతో ఒకే కంటైనర్ చిత్రాలు ఉపయోగించబడతాయి. తదనుగుణంగా, ఉత్పత్తిలో ముగిసేది మీరు స్థానికంగా లేదా మీ పరీక్షా వాతావరణంలో గతంలో పరీక్షించినది కాదని వాస్తవంగా మీకు అవకాశం లేదు.
2. ఇది సరిపోతుందని మేము కూడా కనుగొన్నాము కొత్త సేవను జోడించడం సులభం. విస్తరణ దృక్కోణం నుండి, ఏదైనా కొత్త వ్యవస్థలు చాలా సరళంగా ప్రారంభించబడతాయి. కాన్ఫిగర్‌లను నిల్వ చేసే రిపోజిటరీకి వెళ్లి, అక్కడ మీ సిస్టమ్ కోసం మరొక కాన్ఫిగరేషన్‌ను జోడించండి మరియు మీరు అంతా సిద్ధంగా ఉన్నారు. మీరు devops నుండి ఎటువంటి అదనపు ప్రయత్నం లేకుండానే మీ సిస్టమ్‌ని ఉత్పత్తికి అమర్చవచ్చు.
3. అన్ని కాన్ఫిగరేషన్ ఫైళ్లు ఒక సాధారణ రిపోజిటరీలో సమీక్షలో ఉన్నట్లు తేలింది. మేము వర్చువల్ సర్వర్‌లను ఉపయోగించి మా సిస్టమ్‌లను అమలు చేసిన సమయంలో, మేము Ansibleని ఉపయోగించాము, దీనిలో configs అదే రిపోజిటరీలో ఉన్నాయి. అయినప్పటికీ, చాలా మంది డెవలపర్‌లకు ఇది పని చేయడం కొంచెం కష్టం. సేవను అమలు చేయడానికి మీరు జోడించాల్సిన కాన్ఫిగర్‌లు మరియు కోడ్ పరిమాణం ఇక్కడ చాలా చిన్నదిగా మారింది. అదనంగా, దీన్ని పరిష్కరించడం లేదా మార్చడం devopsకు చాలా సులభం. పరివర్తనాల విషయంలో, ఉదాహరణకు, నోమాడ్ యొక్క కొత్త వెర్షన్‌కు, వారు ఒకే స్థలంలో ఉన్న అన్ని ఆపరేటింగ్ ఫైల్‌లను తీసుకొని బల్క్ అప్‌డేట్ చేయవచ్చు.

కానీ మేము అనేక ప్రతికూలతలను కూడా ఎదుర్కొన్నాము:

మేము అని తేలింది అతుకులు లేని విస్తరణలను సాధించలేకపోయింది సంచార విషయంలో. వేర్వేరు పరిస్థితులలో కంటైనర్‌లను రోల్ చేస్తున్నప్పుడు, అది నడుస్తున్నట్లు మారుతుంది మరియు ట్రాఫిక్‌ను స్వీకరించడానికి సిద్ధంగా ఉన్న కంటైనర్‌గా నోమాడ్ దానిని గ్రహించాడు. దానిలోని అప్లికేషన్‌ను ప్రారంభించే అవకాశం కూడా రాకముందే ఇది జరిగింది. ఈ కారణంగా, సిస్టమ్ తక్కువ వ్యవధిలో 500 లోపాలను ఉత్పత్తి చేయడం ప్రారంభించింది, ఎందుకంటే ట్రాఫిక్ దానిని అంగీకరించడానికి ఇంకా సిద్ధంగా లేని కంటైనర్‌కు వెళ్లడం ప్రారంభించింది.

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

కాబట్టి మేము తదుపరి ఎక్కడికి వెళ్లాలో ఆలోచించాలని నిర్ణయించుకున్నాము. ఆ సమయంలో, మేము ఏమి సాధించాలనుకుంటున్నాము అనే దాని గురించి మాకు మరింత అవగాహన ఏర్పడింది. అవి: మాకు విశ్వసనీయత, నోమాడ్ అందించే దానికంటే కొంచెం ఎక్కువ విధులు మరియు మరింత పరిణతి చెందిన, మరింత స్థిరమైన వ్యవస్థ కావాలి.

ఈ విషయంలో, క్లస్టర్‌లను ప్రారంభించడానికి అత్యంత ప్రజాదరణ పొందిన ప్లాట్‌ఫారమ్‌గా మా ఎంపిక కుబెర్నెట్స్‌పై పడింది. ముఖ్యంగా మా కంటైనర్ల పరిమాణం మరియు సంఖ్య తగినంత పెద్దది. అటువంటి ప్రయోజనాల కోసం, కుబెర్నెట్స్ మనం చూడగలిగే అత్యంత అనుకూలమైన వ్యవస్థగా అనిపించింది.

కుబెర్నెటీస్‌కు పరివర్తన

కుబెర్నెట్స్ యొక్క ప్రాథమిక భావనల గురించి మరియు అవి నోమాడ్ నుండి ఎలా విభిన్నంగా ఉన్నాయో నేను మీకు కొంచెం చెబుతాను.

అన్నింటిలో మొదటిది, కుబెర్నెట్స్‌లో అత్యంత ప్రాథమిక భావన పాడ్ భావన. పోడియమ్ ఎల్లప్పుడూ కలిసి నడిచే ఒకటి లేదా అంతకంటే ఎక్కువ కంటైనర్ల సమూహం. మరియు అవి ఎల్లప్పుడూ ఒక వర్చువల్ మెషీన్‌లో ఖచ్చితంగా పని చేస్తాయి. అవి వేర్వేరు పోర్ట్‌లలో IP 127.0.0.1 ద్వారా ఒకదానికొకటి అందుబాటులో ఉంటాయి.

మీరు nginx మరియు php-fpm - క్లాసిక్ స్కీమ్‌లను కలిగి ఉన్న PHP అప్లికేషన్‌ని కలిగి ఉన్నారని అనుకుందాం. చాలా మటుకు, మీరు nginx మరియు php-fpm కంటైనర్‌లను అన్ని సమయాలలో కలిపి ఉంచాలని కోరుకుంటారు. Kubernetes వాటిని ఒక సాధారణ పాడ్‌గా వివరించడం ద్వారా దీన్ని సాధించడానికి మిమ్మల్ని అనుమతిస్తుంది. నోమాడ్‌తో మేము పొందలేకపోయినది ఇదే.

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

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

మరియు నాల్గవ ప్రాథమిక భావన లోపల ప్రవేశించుట. ఇది కుబెర్నెటెస్ క్లస్టర్‌లో నడిచే సేవ. ఇది అన్ని అభ్యర్థనలను తీసుకునే బాహ్య లోడ్ బ్యాలెన్సర్‌గా పనిచేస్తుంది. Kubernetes APIని ఉపయోగించి, ఈ అభ్యర్థనలను ఎక్కడ పంపాలో ఇన్‌గ్రెస్ నిర్ణయించగలదు. అంతేకాకుండా, అతను దీన్ని చాలా సరళంగా చేస్తాడు. మీరు ఈ హోస్ట్‌కి చేసిన అన్ని అభ్యర్థనలు మరియు అలాంటి URL ఈ సేవకు పంపబడతాయని చెప్పవచ్చు. మరియు ఈ హోస్ట్‌కి మరియు మరొక URLకి వచ్చే ఈ అభ్యర్థనలు మరొక సేవకు పంపబడతాయి.

అనువర్తనాన్ని అభివృద్ధి చేసే వారి దృక్కోణం నుండి చక్కని విషయం ఏమిటంటే, మీరు అన్నింటినీ మీరే నిర్వహించగలుగుతారు. ఇన్‌గ్రెస్ కాన్ఫిగరేషన్‌ను సెట్ చేయడం ద్వారా, మీరు అటువంటి మరియు అటువంటి APIకి వచ్చే అన్ని ట్రాఫిక్‌లను ప్రత్యేక కంటైనర్‌లకు పంపవచ్చు, ఉదాహరణకు, గోలో. కానీ ఈ ట్రాఫిక్, అదే డొమైన్‌కు కానీ, వేరే URLకి కానీ, PHPలో వ్రాసిన కంటైనర్‌లకు పంపబడాలి, అక్కడ చాలా లాజిక్ ఉంది, కానీ అవి చాలా వేగంగా లేవు.

ఈ కాన్సెప్ట్‌లన్నింటినీ నోమాడ్‌తో పోల్చి చూస్తే, మొదటి మూడు కాన్సెప్ట్‌లు అన్నీ కలిసి సర్వీస్ అని చెప్పవచ్చు. మరియు చివరి భావన నోమాడ్‌లోనే లేదు. మేము బాహ్య బ్యాలెన్సర్‌ని ఉపయోగించాము: ఇది హాప్రాక్సీ, nginx, nginx+ మరియు మొదలైనవి కావచ్చు. క్యూబ్ విషయంలో, మీరు ఈ అదనపు భావనను విడిగా పరిచయం చేయవలసిన అవసరం లేదు. అయితే, మీరు అంతర్గతంగా ప్రవేశాన్ని చూస్తే, అది nginx, haproxy లేదా traefik, కానీ కుబెర్నెట్స్‌లో అంతర్నిర్మితంగా ఉంటుంది.

నేను వివరించిన అన్ని భావనలు, వాస్తవానికి, కుబెర్నెట్స్ క్లస్టర్‌లో ఉన్న వనరులు. వాటిని క్యూబ్‌లో వివరించడానికి, ఒక yaml ఫార్మాట్ ఉపయోగించబడుతుంది, ఇది నోమాడ్ విషయంలో HCL ఫైల్‌ల కంటే ఎక్కువ చదవగలిగేది మరియు సుపరిచితమైనది. కానీ నిర్మాణాత్మకంగా వారు అదే విషయాన్ని వివరిస్తారు, ఉదాహరణకు, పాడ్. వారు అంటున్నారు - నేను అలాంటి మరియు అలాంటి పాడ్‌లను, అలాంటి మరియు అలాంటి చిత్రాలతో, అలాంటి మరియు అలాంటి పరిమాణంలో అక్కడ అమర్చాలనుకుంటున్నాను.

అదనంగా, మేము ప్రతి వ్యక్తి వనరును చేతితో సృష్టించకూడదని మేము గ్రహించాము: విస్తరణ, సేవలు, ప్రవేశం మొదలైనవి. బదులుగా, మేము మా ప్రతి సిస్టమ్‌ను విస్తరణ సమయంలో కుబెర్నెట్‌ల పరంగా వివరించాలనుకుంటున్నాము, తద్వారా మేము సరైన క్రమంలో అవసరమైన అన్ని వనరుల డిపెండెన్సీలను మాన్యువల్‌గా పునఃసృష్టించాల్సిన అవసరం లేదు. దీన్ని చేయడానికి మాకు అనుమతించే వ్యవస్థగా హెల్మ్ ఎంపిక చేయబడింది.

హెల్మ్‌లోని ప్రాథమిక అంశాలు

హెల్మ్ ఉంది ప్యాకేజీ మేనేజర్ కుబెర్నెట్స్ కోసం. ప్రోగ్రామింగ్ లాంగ్వేజ్‌లలో ప్యాకేజీ మేనేజర్లు ఎలా పని చేస్తారో దానికి చాలా పోలి ఉంటుంది. ఉదాహరణకు, విస్తరణ nginx, విస్తరణ php-fpm, ఇన్‌గ్రెస్ కోసం config, configmaps (ఇది మీ సిస్టమ్ కోసం env మరియు ఇతర పారామితులను సెట్ చేయడానికి మిమ్మల్ని అనుమతించే ఎంటిటీ) వంటి వాటితో కూడిన సేవను నిల్వ చేయడానికి అవి మిమ్మల్ని అనుమతిస్తాయి. చార్టులు అని పిలుస్తారు. అదే సమయంలో హెల్మ్ కుబెర్నెటీస్ పైన నడుస్తుంది. అంటే, ఇది ఒకరకమైన సిస్టమ్ పక్కన నిలబడటం కాదు, క్యూబ్ లోపల ప్రారంభించబడిన మరొక సేవ. మీరు కన్సోల్ కమాండ్ ద్వారా దాని API ద్వారా దానితో పరస్పర చర్య చేస్తారు. దీని సౌలభ్యం మరియు అందం ఏమిటంటే, హెల్మ్ విరిగిపోయినా లేదా మీరు దానిని క్లస్టర్ నుండి తీసివేసినా, మీ సేవలు అదృశ్యం కావు, ఎందుకంటే హెల్మ్ తప్పనిసరిగా సిస్టమ్‌ను ప్రారంభించడానికి మాత్రమే ఉపయోగపడుతుంది. కుబెర్నెటెస్ స్వయంగా సేవల పనితీరు మరియు స్థితికి బాధ్యత వహిస్తాడు.

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

హెల్మ్ మా కోసం మరికొన్ని భావనలను జోడిస్తుంది.

<span style="font-family: Mandali; "> పట్టిక (చార్ట్)</span> - ఇది మీ సేవ యొక్క వివరణ. ఇతర ప్యాకేజీ నిర్వాహకులలో దీనిని ప్యాకేజీ, బండిల్ లేదా అలాంటిదే అంటారు. ఇక్కడ దీనిని చార్ట్ అంటారు.

విలువలు టెంప్లేట్‌ల నుండి మీ కాన్ఫిగరేషన్‌లను రూపొందించడానికి మీరు ఉపయోగించాలనుకుంటున్న వేరియబుల్స్.

విడుదల. ప్రతిసారీ హెల్మ్ ఉపయోగించి అమలు చేయబడిన సేవ విడుదల యొక్క పెరుగుతున్న సంస్కరణను పొందుతుంది. హెల్మ్ మునుపటి విడుదలలో సర్వీస్ కాన్ఫిగరేషన్ ఏమిటో గుర్తుంచుకుంటుంది, దానికి ముందు విడుదల, మరియు మొదలైనవి. అందువల్ల, మీరు రోల్‌బ్యాక్ చేయవలసి వస్తే, హెల్మ్ కాల్‌బ్యాక్ ఆదేశాన్ని అమలు చేయండి, దానిని మునుపటి విడుదల సంస్కరణకు చూపుతుంది. రోల్‌బ్యాక్ సమయంలో మీ రిపోజిటరీలో సంబంధిత కాన్ఫిగరేషన్ అందుబాటులో లేనప్పటికీ, హెల్మ్ అది ఏమిటో గుర్తుంచుకుంటుంది మరియు మీ సిస్టమ్‌ని మునుపటి విడుదలలో ఉన్న స్థితికి రోల్‌బ్యాక్ చేస్తుంది.

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

ఆచరణలో, మేము నోమాడ్‌తో చేసినదానికంటే కొంచెం భిన్నంగా చేయాలని నిర్ణయించుకున్నాము. నోమాడ్‌లో మా సేవను అమలు చేయడానికి అవసరమైన డిప్లాయ్‌మెంట్ కాన్ఫిగర్‌లు మరియు n-వేరియబుల్‌లు రెండూ ఒక రిపోజిటరీలో నిల్వ చేయబడితే, ఇక్కడ మేము వాటిని రెండు వేర్వేరు రిపోజిటరీలుగా విభజించాలని నిర్ణయించుకున్నాము. "డిప్లాయ్" రిపోజిటరీ డిప్లాయ్‌మెంట్ కోసం అవసరమైన n-వేరియబుల్స్‌ను మాత్రమే స్టోర్ చేస్తుంది మరియు "హెల్మ్" రిపోజిటరీ కాన్ఫిగర్‌లు లేదా చార్ట్‌లను స్టోర్ చేస్తుంది.

ఇది మాకు ఏమి ఇచ్చింది?

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

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

ప్రతి రిపోజిటరీ లోపల, మేము ప్రతి సేవ కోసం ప్రత్యేక డైరెక్టరీలుగా విభజించాము. అంటే, ప్రతి డైరెక్టరీ లోపల సంబంధిత చార్ట్‌కు సంబంధించిన టెంప్లేట్‌లు ఉన్నాయి మరియు మా సిస్టమ్‌ను ప్రారంభించేందుకు ఉపయోగించాల్సిన వనరులను వివరిస్తాయి. మేము "డిప్లాయ్" రిపోజిటరీలో కేవలం envsని మాత్రమే ఉంచాము. ఈ సందర్భంలో, మేము జింజాను ఉపయోగించి టెంప్లేటింగ్‌ని ఉపయోగించలేదు, ఎందుకంటే హెల్మ్ కూడా బాక్స్ వెలుపల టెంప్లేటింగ్‌ను అందిస్తుంది - ఇది దాని ప్రధాన విధుల్లో ఒకటి.

మేము విస్తరణ స్క్రిప్ట్‌ను వదిలివేసాము - deploy.sh, ఇది హెల్మ్‌ని ఉపయోగించి విస్తరణ కోసం లాంచ్‌ను సులభతరం చేస్తుంది మరియు ప్రామాణికం చేస్తుంది. కాబట్టి, డిప్లాయ్ చేయాలనుకునే ఎవరికైనా, నోమాడ్ ద్వారా డిప్లాయ్ చేస్తున్నప్పుడు డిప్లాయ్‌మెంట్ ఇంటర్‌ఫేస్ సరిగ్గా అదే విధంగా కనిపిస్తుంది. అదే deploy.sh, మీ సేవ పేరు మరియు మీరు దీన్ని ఎక్కడ అమలు చేయాలనుకుంటున్నారు. ఇది హెల్మ్ అంతర్గతంగా ప్రారంభమయ్యేలా చేస్తుంది. ఇది క్రమంగా, టెంప్లేట్‌ల నుండి కాన్ఫిగరేషన్‌లను సేకరిస్తుంది, వాటిలో అవసరమైన విలువల ఫైల్‌లను ఇన్‌సర్ట్ చేస్తుంది, ఆపై వాటిని అమలు చేస్తుంది, వాటిని కుబెర్నెట్స్‌లోకి లాంచ్ చేస్తుంది.

కనుగొన్న

కుబెర్నెట్స్ సేవ నోమాడ్ కంటే చాలా క్లిష్టంగా కనిపిస్తుంది.

ఇక్కడ అవుట్‌గోయింగ్ ట్రాఫిక్ ఇంగ్రెస్‌కి వస్తుంది. ఇది కేవలం ఫ్రంట్ కంట్రోలర్, ఇది అన్ని అభ్యర్థనలను తీసుకుంటుంది మరియు తదనంతరం అభ్యర్థన డేటాకు సంబంధించిన సేవలకు వాటిని పంపుతుంది. ఇది హెల్మ్‌లో మీ అప్లికేషన్ యొక్క వివరణలో భాగమైన మరియు డెవలపర్‌లు వారి స్వంతంగా సెట్ చేసిన కాన్ఫిగర్‌ల ఆధారంగా వాటిని నిర్ణయిస్తుంది. సేవ దాని పాడ్‌లకు అభ్యర్థనలను పంపుతుంది, అంటే నిర్దిష్ట కంటైనర్‌లు, ఈ సేవకు చెందిన అన్ని కంటైనర్‌ల మధ్య ఇన్‌కమింగ్ ట్రాఫిక్‌ను బ్యాలెన్స్ చేస్తుంది. మరియు, వాస్తవానికి, మేము నెట్వర్క్ స్థాయిలో భద్రత నుండి ఎక్కడికీ వెళ్లకూడదని మనం మర్చిపోకూడదు. కాబట్టి, ట్యాగింగ్‌పై ఆధారపడిన కుబెర్నెట్స్ క్లస్టర్‌లో సెగ్మెంటేషన్ పనిచేస్తుంది. క్లస్టర్ లోపల లేదా వెలుపల కొన్ని బాహ్య/అంతర్గత వనరులకు సేవల యాక్సెస్ హక్కులు అనుబంధించబడిన నిర్దిష్ట ట్యాగ్‌లు అన్ని సేవలకు ఉన్నాయి.

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

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

మేము కుబెర్నెట్స్‌కి మొదటి విస్తరణ మార్చి 2018లో చేసాము. మరియు ఈ సమయంలో మేము దానితో ఎటువంటి సమస్యలను ఎదుర్కోలేదు. ఇది ముఖ్యమైన దోషాలు లేకుండా చాలా స్థిరంగా పనిచేస్తుంది. అదనంగా, మేము దానిని మరింత విస్తరించవచ్చు. ఈ రోజు మనకు తగినంత సామర్థ్యాలు ఉన్నాయి మరియు కుబెర్నెట్స్ అభివృద్ధి వేగాన్ని మేము నిజంగా ఇష్టపడతాము. ప్రస్తుతం, 3000 కంటే ఎక్కువ కంటైనర్లు కుబెర్నెట్స్‌లో ఉన్నాయి. క్లస్టర్ అనేక నోడ్‌లను ఆక్రమించింది. అదే సమయంలో, ఇది సేవ చేయదగినది, స్థిరమైనది మరియు చాలా నియంత్రించదగినది.

మూలం: www.habr.com