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

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

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

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

కాన్ఫిగరేషన్ మేనేజ్‌మెంట్ కాంప్లెక్స్ అనేక స్థాయిలను కలిగి ఉంటుంది. ముఖ్య భాగం CMS వ్యవస్థ. పారిశ్రామిక ఆపరేషన్లో, స్థాయిలలో ఒకటి లేకపోవడం అనివార్యంగా అసహ్యకరమైన అద్భుతాలకు దారి తీస్తుంది.

OS సంస్థాపన నిర్వహణ

మొదటి స్థాయి భౌతిక మరియు వర్చువల్ సర్వర్‌లపై ఆపరేటింగ్ సిస్టమ్‌ల ఇన్‌స్టాలేషన్‌ను నిర్వహించడానికి ఒక వ్యవస్థ. ఇది ప్రాథమిక OS కాన్ఫిగరేషన్‌లను సృష్టిస్తుంది, మానవ కారకాన్ని తొలగిస్తుంది.

ఈ సిస్టమ్‌ని ఉపయోగించి, మేము తదుపరి ఆటోమేషన్‌కు అనువైన OSతో ప్రామాణిక సర్వర్ ఉదాహరణలను అందుకున్నాము. "పోయడం" సమయంలో వారు కనీస స్థానిక వినియోగదారులు మరియు పబ్లిక్ SSH కీలను, అలాగే స్థిరమైన OS కాన్ఫిగరేషన్‌ను అందుకున్నారు. CMS ద్వారా సర్వర్‌లను నిర్వహించగలమని మేము హామీ ఇవ్వగలము మరియు OS స్థాయిలో "క్రిందికి" ఎటువంటి ఆశ్చర్యకరమైనవి లేవని నిశ్చయించుకున్నాము.

BIOS/ఫర్మ్‌వేర్ స్థాయి నుండి OSకి సర్వర్‌లను స్వయంచాలకంగా కాన్ఫిగర్ చేయడం ఇన్‌స్టాలేషన్ మేనేజ్‌మెంట్ సిస్టమ్ కోసం "గరిష్ట" పని. ఇక్కడ చాలా పరికరాలు మరియు సెటప్ పనులపై ఆధారపడి ఉంటుంది. వైవిధ్య పరికరాల కోసం, మీరు పరిగణించవచ్చు రెడ్‌ఫిష్ API. అన్ని హార్డ్‌వేర్‌లు ఒక విక్రేత నుండి వచ్చినట్లయితే, రెడీమేడ్ మేనేజ్‌మెంట్ సాధనాలను ఉపయోగించడం చాలా సౌకర్యవంతంగా ఉంటుంది (ఉదాహరణకు, HP ILO యాంప్లిఫైయర్, DELL OpenManage, మొదలైనవి).

ఫిజికల్ సర్వర్‌లలో OSని ఇన్‌స్టాల్ చేయడానికి, మేము బాగా తెలిసిన కోబ్లర్‌ను ఉపయోగించాము, ఇది ఆపరేషన్ సేవతో అంగీకరించిన ఇన్‌స్టాలేషన్ ప్రొఫైల్‌ల సమితిని నిర్వచిస్తుంది. ఇన్‌ఫ్రాస్ట్రక్చర్‌కు కొత్త సర్వర్‌ని జోడించినప్పుడు, ఇంజనీర్ కాబ్లర్‌లో అవసరమైన ప్రొఫైల్‌కు సర్వర్ యొక్క MAC చిరునామాను టైడ్ చేశాడు. మొదటిసారిగా నెట్‌వర్క్‌లో బూట్ చేస్తున్నప్పుడు, సర్వర్ తాత్కాలిక చిరునామా మరియు తాజా OSని పొందింది. అప్పుడు అది లక్ష్య VLAN/IP చిరునామాకు బదిలీ చేయబడింది మరియు అక్కడ పనిని కొనసాగించింది. అవును, VLANని మార్చడానికి సమయం పడుతుంది మరియు సమన్వయం అవసరం, అయితే ఇది ఉత్పత్తి వాతావరణంలో సర్వర్ యొక్క ప్రమాదవశాత్తూ ఇన్‌స్టాలేషన్ నుండి అదనపు రక్షణను అందిస్తుంది.

మేము HashiСorp Packerని ఉపయోగించి తయారు చేసిన టెంప్లేట్‌ల ఆధారంగా వర్చువల్ సర్వర్‌లను సృష్టించాము. కారణం అదే: OS ని ఇన్‌స్టాల్ చేసేటప్పుడు సాధ్యమయ్యే మానవ లోపాలను నివారించడానికి. కానీ, భౌతిక సర్వర్‌ల వలె కాకుండా, PXE, నెట్‌వర్క్ బూటింగ్ మరియు VLAN మార్పుల అవసరాన్ని ప్యాకర్ తొలగిస్తుంది. ఇది వర్చువల్ సర్వర్‌లను సృష్టించడం సులభం మరియు సులభతరం చేసింది.

అన్నం. 1. ఆపరేటింగ్ సిస్టమ్స్ యొక్క సంస్థాపనను నిర్వహించడం.

రహస్యాలను నిర్వహించడం

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

ఈ రహస్యాలను ఎక్కడ మరియు ఎలా నిల్వ చేయాలో మీరు మొదటి నుండి నిర్ణయించకపోతే, సమాచార భద్రతా అవసరాల తీవ్రతను బట్టి, కింది నిల్వ పద్ధతులు ఉండవచ్చు:

• నేరుగా కాన్ఫిగరేషన్ నియంత్రణ కోడ్‌లో లేదా రిపోజిటరీలోని ఫైల్‌లలో;
• ప్రత్యేక కాన్ఫిగరేషన్ నిర్వహణ సాధనాల్లో (ఉదాహరణకు, అన్సిబుల్ వాల్ట్);
• CI/CD సిస్టమ్స్‌లో (జెంకిన్స్/టీమ్‌సిటీ/GitLab/మొదలైనవి) లేదా కాన్ఫిగరేషన్ మేనేజ్‌మెంట్ సిస్టమ్‌లలో (Ansible Tower/Ansible AWX);
• రహస్యాలను "మాన్యువల్‌గా" కూడా బదిలీ చేయవచ్చు. ఉదాహరణకు, అవి పేర్కొన్న ప్రదేశంలో వేయబడ్డాయి, ఆపై అవి కాన్ఫిగరేషన్ మేనేజ్‌మెంట్ సిస్టమ్స్ ద్వారా ఉపయోగించబడతాయి;
• పైన పేర్కొన్న వివిధ కలయికలు.

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

మేము కేంద్రీకృత రహస్య నిల్వ HashiCorp వాల్ట్‌ని ఉపయోగించాము. ఇది మాకు అనుమతించింది:

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

ఇప్పుడు కేంద్ర ప్రమాణీకరణ మరియు అధికార వ్యవస్థకు వెళ్దాం. ఇది లేకుండా చేయడం సాధ్యమే, కానీ అనేక సంబంధిత సిస్టమ్‌లలో వినియోగదారులను నిర్వహించడం చాలా చిన్నవిషయం కాదు. మేము LDAP సేవ ద్వారా ప్రమాణీకరణ మరియు అధికారాన్ని కాన్ఫిగర్ చేసాము. లేకపోతే, వాల్ట్ వినియోగదారుల కోసం ప్రామాణీకరణ టోకెన్‌లను నిరంతరం జారీ చేయాలి మరియు ట్రాక్ చేయాలి. మరియు వినియోగదారులను తొలగించడం మరియు జోడించడం అనేది “నేను ఈ వినియోగదారు ఖాతాను ప్రతిచోటా సృష్టించానా/తొలగించానా?” అనే అన్వేషణగా మారుతుంది.

మేము మా సిస్టమ్‌కు మరొక స్థాయిని జోడిస్తాము: రహస్యాల నిర్వహణ మరియు కేంద్ర ప్రమాణీకరణ/ప్రామాణీకరణ:

అన్నం. 2. రహస్య నిర్వహణ.

ఆకృతీకరణ నిర్వహణ

మేము కోర్కి చేరుకున్నాము - CMS సిస్టమ్. మా విషయంలో, ఇది Ansible మరియు Red Hat Ansible AWX కలయిక.

Ansible బదులుగా, Chef, Puppet, SaltStack ఉపయోగించవచ్చు. మేము అనేక ప్రమాణాల ఆధారంగా అన్సిబుల్‌ని ఎంచుకున్నాము.

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

కానీ ఉత్పత్తి వాతావరణంలో అన్సిబుల్ మాత్రమే మాకు సరిపోదు. లేకపోతే, యాక్సెస్‌ని పరిమితం చేయడం మరియు నిర్వాహకుల చర్యలను ఆడిట్ చేయడంతో అనేక సమస్యలు తలెత్తుతాయి. యాక్సెస్‌ని ఎలా పరిమితం చేయాలి? అన్నింటికంటే, ప్రతి విభాగానికి "దాని స్వంత" సర్వర్‌ల సెట్‌ను నిర్వహించడం (చదవండి: అన్సిబుల్ ప్లేబుక్‌ని అమలు చేయడం) అవసరం. నిర్దిష్ట Ansible ప్లేబుక్‌లను అమలు చేయడానికి నిర్దిష్ట ఉద్యోగులను మాత్రమే ఎలా అనుమతించాలి? లేదా Ansible నడుస్తున్న సర్వర్‌లు మరియు పరికరాలపై స్థానిక పరిజ్ఞానాన్ని ఏర్పాటు చేయకుండా ప్లేబుక్‌ను ఎవరు ప్రారంభించారో ట్రాక్ చేయడం ఎలా?

ఇటువంటి సమస్యలలో సింహభాగం Red Hat ద్వారా పరిష్కరించబడుతుంది అన్సిబుల్ టవర్, లేదా అతని ఓపెన్ సోర్స్ అప్‌స్ట్రీమ్ ప్రాజెక్ట్ అన్సిబుల్ AWX. అందుకే కస్టమర్‌కు ప్రాధాన్యత ఇచ్చాం.

మరియు మా CMS సిస్టమ్ పోర్ట్రెయిట్‌కు మరో టచ్. అన్సిబుల్ ప్లేబుక్ కోడ్ రిపోజిటరీ మేనేజ్‌మెంట్ సిస్టమ్‌లలో నిల్వ చేయబడాలి. మా దగ్గర ఉంది GitLab CE.

కాబట్టి, కాన్ఫిగరేషన్‌లు అన్సిబుల్/అన్సిబుల్ AWX/GitLab కలయికతో నిర్వహించబడతాయి (Fig. 3 చూడండి). వాస్తవానికి, AWX/GitLab ఒకే ప్రమాణీకరణ వ్యవస్థతో అనుసంధానించబడింది మరియు Ansible ప్లేబుక్ HashiCorp వాల్ట్‌తో అనుసంధానించబడింది. కాన్ఫిగరేషన్‌లు ఉత్పత్తి వాతావరణంలోకి Ansible AWX ద్వారా మాత్రమే ప్రవేశిస్తాయి, దీనిలో అన్ని “గేమ్ యొక్క నియమాలు” పేర్కొనబడ్డాయి: ఎవరు ఏమి కాన్ఫిగర్ చేయవచ్చు, CMS కోసం కాన్ఫిగరేషన్ మేనేజ్‌మెంట్ కోడ్‌ను ఎక్కడ పొందాలి మొదలైనవి.

అన్నం. 3. కాన్ఫిగరేషన్ నిర్వహణ.

పరీక్ష నిర్వహణ

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

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

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

కోడ్ అభివృద్ధి మరియు కాన్ఫిగరేషన్ నిర్వహణ ప్రశాంతంగా మరియు మరింత ఊహాజనితంగా మారింది. నిరంతర పరీక్షను నిర్వహించడానికి, మేము GitLab CI/CD టూల్‌కిట్‌ని ఉపయోగించాము మరియు తీసుకున్నాము అన్సిబుల్ మాలిక్యూల్.

కాన్ఫిగరేషన్ మేనేజ్‌మెంట్ కోడ్‌లో మార్పు వచ్చినప్పుడల్లా, GitLab CI/CD మాలిక్యూల్‌కి కాల్ చేస్తుంది:

• ఇది కోడ్ సింటాక్స్‌ని తనిఖీ చేస్తుంది,
• డాకర్ కంటైనర్‌ను పెంచుతుంది,
• సృష్టించిన కంటైనర్‌కు సవరించిన కోడ్‌ని వర్తింపజేస్తుంది,
• ఐడెంపోటెన్సీ కోసం పాత్రను తనిఖీ చేస్తుంది మరియు ఈ కోడ్ కోసం పరీక్షలను అమలు చేస్తుంది (ఇక్కడ గ్రాన్యులారిటీ అనేది పాత్ర స్థాయిలో ఉంది, అంజీర్ 4 చూడండి).

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

అన్నం. 4. GitLab CI/CDలో పాత్రల స్వయంచాలక పరీక్ష.

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

ఫలితంగా, మాన్యువల్ మార్పుల కారణంగా, ఒకే రకమైన పరికరాలపై కాన్ఫిగరేషన్‌లో వ్యత్యాసాలు కనిపిస్తాయి (ఉదాహరణకు, HA క్లస్టర్ నోడ్‌లలో sysctl సెట్టింగ్‌లు విభిన్నంగా కాన్ఫిగర్ చేయబడతాయి). లేదా పరికరాలపై వాస్తవ కాన్ఫిగరేషన్ CMS కోడ్‌లో పేర్కొన్న దానికి భిన్నంగా ఉంటుంది.

అందువల్ల, నిరంతర పరీక్షతో పాటు, కాన్ఫిగరేషన్ వ్యత్యాసాల కోసం మేము ఉత్పత్తి వాతావరణాలను తనిఖీ చేస్తాము. మేము సరళమైన ఎంపికను ఎంచుకున్నాము: CMS కాన్ఫిగరేషన్ కోడ్‌ను “డ్రై రన్” మోడ్‌లో అమలు చేయడం, అంటే మార్పులను వర్తింపజేయకుండా, కానీ ప్రణాళికాబద్ధమైన మరియు వాస్తవ కాన్ఫిగరేషన్ మధ్య ఉన్న అన్ని వ్యత్యాసాల నోటిఫికేషన్‌తో. మేము ప్రొడక్షన్ సర్వర్‌లలో “—చెక్” ఎంపికతో అన్ని Ansible ప్లేబుక్‌లను క్రమానుగతంగా అమలు చేయడం ద్వారా దీన్ని అమలు చేసాము. ఎప్పటిలాగే, ప్లేబుక్‌ను తాజాగా ప్రారంభించడం మరియు ఉంచడం కోసం Ansible AWX బాధ్యత వహిస్తుంది (Fig. 5 చూడండి):

అన్నం. 5. Ansible AWXలో కాన్ఫిగరేషన్ వ్యత్యాసాల కోసం తనిఖీలు.

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

మేము ఇప్పుడు Ansible AWX/GitLab/Molecule (Figure 6)తో కూడిన ముఖ్యమైన టెస్టింగ్ లేయర్‌ని కలిగి ఉన్నాము.

అన్నం. 6. పరీక్ష నిర్వహణ.

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

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

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

మరియు వాస్తవానికి, మేము చాలా రోజుల నుండి గంటల వరకు సర్వర్‌ల ప్రారంభాన్ని వేగవంతం చేసాము.

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

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

రచయిత: సెర్గీ ఆర్టెమోవ్, డిపార్ట్మెంట్ ఆర్కిటెక్ట్ DevOps పరిష్కారాలు "జెట్ ఇన్ఫోసిస్టమ్స్"

మూలం: www.habr.com