புத்தாண்டு நெருங்கிக் கொண்டிருந்தது. நாடு முழுவதும் உள்ள குழந்தைகள் ஏற்கனவே சாண்டா கிளாஸுக்கு கடிதங்களை அனுப்பியுள்ளனர் அல்லது தங்களுக்கு பரிசுகளை வழங்கினர், மேலும் அவர்களின் முக்கிய நிர்வாகி, முக்கிய சில்லறை விற்பனையாளர்களில் ஒருவரான, விற்பனையின் மன்னிப்புக்கு தயாராகி வந்தார். டிசம்பரில், அதன் தரவு மையத்தின் சுமை பல மடங்கு அதிகரிக்கிறது. எனவே, நிறுவனம் தரவு மையத்தை நவீனமயமாக்க முடிவுசெய்து, அதன் சேவை வாழ்க்கையின் முடிவை அடையும் உபகரணங்களுக்கு பதிலாக பல டஜன் புதிய சேவையகங்களை இயக்க முடிவு செய்தது. இது சுழலும் ஸ்னோஃப்ளேக்குகளின் பின்னணியில் கதையை முடிக்கிறது, மேலும் த்ரில்லர் தொடங்குகிறது.

உபகரணங்கள் விற்பனையின் உச்சத்திற்கு பல மாதங்களுக்கு முன்பே தளத்திற்கு வந்தன. உற்பத்திச் சூழலுக்கு அவற்றைக் கொண்டு வருவதற்காக, சர்வர்களை எப்படி, என்ன கட்டமைக்க வேண்டும் என்பது செயல்பாட்டுச் சேவைக்குத் தெரியும். ஆனால் நாம் இதை தானியக்கமாக்க வேண்டும் மற்றும் மனித காரணியை அகற்ற வேண்டும். கூடுதலாக, நிறுவனத்திற்கு முக்கியமான ஒரு SAP அமைப்புகளின் இடமாற்றத்திற்கு முன் சேவையகங்கள் மாற்றப்பட்டன.

புதிய சேவையகங்களை இயக்குவது கண்டிப்பாக காலக்கெடுவுடன் இணைக்கப்பட்டுள்ளது. அதை நகர்த்துவது ஒரு பில்லியன் பரிசுகளின் ஏற்றுமதி மற்றும் அமைப்புகளின் இடம்பெயர்வு ஆகிய இரண்டையும் பாதிக்கும். ஃபாதர் ஃப்ரோஸ்ட் மற்றும் சாண்டா கிளாஸ் ஆகியோரைக் கொண்ட குழுவால் கூட தேதியை மாற்ற முடியவில்லை - நீங்கள் வருடத்திற்கு ஒரு முறை மட்டுமே கிடங்கு நிர்வாகத்திற்கான SAP அமைப்பை மாற்ற முடியும். டிசம்பர் 31 முதல் ஜனவரி 1 வரை, சில்லறை விற்பனையாளரின் பெரிய கிடங்குகள், மொத்தம் 20 கால்பந்து மைதானங்கள், 15 மணி நேரம் தங்கள் வேலையை நிறுத்துகின்றன. கணினியை நகர்த்துவதற்கான ஒரே காலப்பகுதி இதுவாகும். சேவையகங்களை அறிமுகப்படுத்தும் போது எங்களிடம் பிழை இல்லை.

நான் தெளிவாகச் சொல்கிறேன்: எங்கள் குழு பயன்படுத்தும் கருவிகள் மற்றும் உள்ளமைவு மேலாண்மை செயல்முறையை எனது கதை பிரதிபலிக்கிறது.

கட்டமைப்பு மேலாண்மை வளாகம் பல நிலைகளைக் கொண்டுள்ளது. முக்கிய கூறு CMS அமைப்பு ஆகும். தொழில்துறை செயல்பாட்டில், நிலைகளில் ஒன்று இல்லாதது தவிர்க்க முடியாமல் விரும்பத்தகாத அற்புதங்களுக்கு வழிவகுக்கும்.

OS நிறுவல் மேலாண்மை

முதல் நிலை என்பது இயற்பியல் மற்றும் மெய்நிகர் சேவையகங்களில் இயக்க முறைமைகளின் நிறுவலை நிர்வகிப்பதற்கான ஒரு அமைப்பாகும். இது அடிப்படை OS கட்டமைப்புகளை உருவாக்குகிறது, மனித காரணியை நீக்குகிறது.

இந்த அமைப்பைப் பயன்படுத்தி, மேலும் ஆட்டோமேஷனுக்கு ஏற்ற OS உடன் நிலையான சர்வர் நிகழ்வுகளைப் பெற்றோம். "கொட்டுதல்" போது அவர்கள் குறைந்தபட்ச உள்ளூர் பயனர்கள் மற்றும் பொது SSH விசைகள் மற்றும் நிலையான OS உள்ளமைவைப் பெற்றனர். CMS மூலம் சேவையகங்களை நிர்வகிப்பதற்கு நாங்கள் உத்தரவாதம் அளிக்க முடியும் மற்றும் OS மட்டத்தில் "கீழே" ஆச்சரியங்கள் எதுவும் இல்லை என்பதில் உறுதியாக இருக்கிறோம்.

நிறுவல் மேலாண்மை அமைப்புக்கான "அதிகபட்ச" பணியானது, BIOS/Firmware நிலையிலிருந்து OS க்கு தானாக சர்வர்களை உள்ளமைப்பதாகும். இங்கே அதிகம் உபகரணங்கள் மற்றும் அமைவு பணிகளைப் பொறுத்தது. பன்முக உபகரணங்களுக்கு, நீங்கள் கருத்தில் கொள்ளலாம் ரெட்ஃபிஷ் ஏபிஐ. அனைத்து வன்பொருளும் ஒரு விற்பனையாளரிடமிருந்து இருந்தால், ஆயத்த மேலாண்மை கருவிகளைப் பயன்படுத்துவது மிகவும் வசதியானது (எடுத்துக்காட்டாக, HP ILO பெருக்கி, DELL OpenManage, முதலியன).

இயற்பியல் சேவையகங்களில் OS ஐ நிறுவ, நாங்கள் நன்கு அறியப்பட்ட Cobbler ஐப் பயன்படுத்தினோம், இது செயல்பாட்டு சேவையுடன் ஒப்புக் கொள்ளப்பட்ட நிறுவல் சுயவிவரங்களின் தொகுப்பை வரையறுக்கிறது. உள்கட்டமைப்பில் ஒரு புதிய சேவையகத்தைச் சேர்க்கும்போது, ​​பொறியாளர் சர்வரின் MAC முகவரியை Cobbler இல் தேவையான சுயவிவரத்துடன் இணைத்தார். முதல் முறையாக நெட்வொர்க்கில் துவக்கும்போது, ​​சேவையகம் ஒரு தற்காலிக முகவரி மற்றும் புதிய OS ஐப் பெற்றது. பின்னர் அது இலக்கு VLAN/IP முகவரிக்கு மாற்றப்பட்டு அங்கு தொடர்ந்து பணிபுரிந்தது. ஆம், VLAN ஐ மாற்றுவதற்கு நேரம் எடுக்கும் மற்றும் ஒருங்கிணைப்பு தேவைப்படுகிறது, ஆனால் இது உற்பத்தி சூழலில் சர்வரை தற்செயலாக நிறுவுவதற்கு எதிராக கூடுதல் பாதுகாப்பை வழங்குகிறது.

ஹாஷிகோர்ப் பேக்கரைப் பயன்படுத்தி தயாரிக்கப்பட்ட டெம்ப்ளேட்களின் அடிப்படையில் மெய்நிகர் சேவையகங்களை உருவாக்கினோம். காரணம் ஒன்றுதான்: OS ஐ நிறுவும் போது சாத்தியமான மனித பிழைகளைத் தடுக்க. ஆனால், இயற்பியல் சேவையகங்களைப் போலல்லாமல், PXE, நெட்வொர்க் பூட்டிங் மற்றும் VLAN மாற்றங்கள் ஆகியவற்றின் தேவையை பேக்கர் நீக்குகிறது. இது மெய்நிகர் சேவையகங்களை உருவாக்குவதை எளிதாகவும் எளிதாகவும் செய்துள்ளது.

அரிசி. 1. இயக்க முறைமைகளின் நிறுவலை நிர்வகித்தல்.

இரகசியங்களை நிர்வகித்தல்

எந்தவொரு உள்ளமைவு மேலாண்மை அமைப்பும் சாதாரண பயனர்களிடமிருந்து மறைக்கப்பட வேண்டிய தரவைக் கொண்டுள்ளது, ஆனால் அமைப்புகளைத் தயாரிக்கத் தேவைப்படுகிறது. இவை உள்ளூர் பயனர்களுக்கான கடவுச்சொற்கள் மற்றும் சேவை கணக்குகள், சான்றிதழ் விசைகள், பல்வேறு API டோக்கன்கள் போன்றவை. அவை பொதுவாக "ரகசியங்கள்" என்று அழைக்கப்படுகின்றன.

இந்த ரகசியங்களை எங்கு, எப்படி சேமிப்பது என்பதை ஆரம்பத்திலிருந்தே நீங்கள் தீர்மானிக்கவில்லை என்றால், தகவல் பாதுகாப்புத் தேவைகளின் தீவிரத்தைப் பொறுத்து, பின்வரும் சேமிப்பக முறைகள் சாத்தியமாகும்:

• நேரடியாக உள்ளமைவுக் கட்டுப்பாட்டுக் குறியீட்டில் அல்லது களஞ்சியத்தில் உள்ள கோப்புகளில்;
• சிறப்பு கட்டமைப்பு மேலாண்மை கருவிகளில் (உதாரணமாக, அன்சிபிள் வால்ட்);
• CI/CD அமைப்புகளில் (Jenkins/TeamCity/GitLab/etc.) அல்லது கட்டமைப்பு மேலாண்மை அமைப்புகளில் (Ansible Tower/Ansible AWX);
• இரகசியங்களை "கைமுறையாக" மாற்றலாம். எடுத்துக்காட்டாக, அவை ஒரு குறிப்பிட்ட இடத்தில் அமைக்கப்பட்டுள்ளன, பின்னர் அவை கட்டமைப்பு மேலாண்மை அமைப்புகளால் பயன்படுத்தப்படுகின்றன;
• மேலே உள்ள பல்வேறு சேர்க்கைகள்.

ஒவ்வொரு முறைக்கும் அதன் சொந்த தீமைகள் உள்ளன. முக்கியமானது இரகசியங்களை அணுகுவதற்கான கொள்கைகள் இல்லாதது: சில இரகசியங்களை யார் பயன்படுத்தலாம் என்பதை தீர்மானிக்க இயலாது அல்லது கடினமானது. அணுகல் தணிக்கை மற்றும் முழு வாழ்க்கை சுழற்சி இல்லாதது மற்றொரு குறைபாடு ஆகும். எடுத்துக்காட்டாக, குறியீட்டிலும் பல தொடர்புடைய அமைப்புகளிலும் எழுதப்பட்ட பொது விசையை எவ்வாறு விரைவாக மாற்றுவது?

மையப்படுத்தப்பட்ட ரகசிய சேமிப்பக HashiCorp Vault ஐப் பயன்படுத்தினோம். இது எங்களுக்கு அனுமதித்தது:

• இரகசியங்களை பாதுகாப்பாக வைத்திருங்கள். அவை குறியாக்கம் செய்யப்பட்டுள்ளன, மேலும் யாரேனும் வால்ட் தரவுத்தளத்திற்கான அணுகலைப் பெற்றாலும் (உதாரணமாக, காப்புப்பிரதியிலிருந்து அதை மீட்டெடுப்பதன் மூலம்), அவர்களால் அங்கு சேமிக்கப்பட்ட இரகசியங்களைப் படிக்க முடியாது;
• இரகசியங்களை அணுகுவதற்கான கொள்கைகளை ஒழுங்கமைத்தல். அவர்களுக்கு "ஒதுக்கப்பட்ட" ரகசியங்கள் மட்டுமே பயனர்களுக்கும் பயன்பாடுகளுக்கும் கிடைக்கும்;
• ரகசியங்களுக்கான தணிக்கை அணுகல். வால்ட் தணிக்கைப் பதிவில் இரகசியங்களைக் கொண்ட எந்தச் செயல்களும் பதிவு செய்யப்படுகின்றன;
• இரகசியங்களுடன் பணிபுரியும் முழு அளவிலான "வாழ்க்கை சுழற்சியை" ஒழுங்கமைக்கவும். அவற்றை உருவாக்கலாம், ரத்து செய்யலாம், காலாவதி தேதியை அமைக்கலாம்.
• இரகசியங்களை அணுக வேண்டிய பிற அமைப்புகளுடன் ஒருங்கிணைக்க எளிதானது;
• மேலும் எண்ட்-டு-எண்ட் என்க்ரிப்ஷன், OS மற்றும் தரவுத்தளத்திற்கான ஒரு முறை கடவுச்சொற்கள், அங்கீகரிக்கப்பட்ட மையங்களின் சான்றிதழ்கள் போன்றவற்றைப் பயன்படுத்தவும்.

இப்போது மத்திய அங்கீகாரம் மற்றும் அங்கீகார முறைக்கு செல்லலாம். இது இல்லாமல் செய்ய முடியும், ஆனால் பல தொடர்புடைய அமைப்புகளில் பயனர்களை நிர்வகிப்பது மிகவும் அற்பமானது அல்ல. LDAP சேவை மூலம் அங்கீகாரம் மற்றும் அங்கீகாரத்தை உள்ளமைத்துள்ளோம். இல்லையெனில், பயனர்களுக்கான அங்கீகார டோக்கன்களை வால்ட் தொடர்ந்து வெளியிட வேண்டும் மற்றும் கண்காணிக்க வேண்டும். மேலும் பயனர்களை நீக்குவதும் சேர்ப்பதும் “இந்தப் பயனர் கணக்கை எல்லா இடங்களிலும் நான் உருவாக்கியுள்ளேனா/நீக்கியிருக்கிறேனா?” என்ற தேடலாக மாறும்.

எங்கள் அமைப்பில் மற்றொரு நிலை சேர்க்கிறோம்: இரகசிய மேலாண்மை மற்றும் மைய அங்கீகாரம்/அங்கீகாரம்:

அரிசி. 2. இரகசிய மேலாண்மை.

கட்டமைப்பு மேலாண்மை

நாங்கள் மையத்திற்கு வந்தோம் - CMS அமைப்பு. எங்கள் விஷயத்தில், இது Ansible மற்றும் Red Hat Ansible AWX ஆகியவற்றின் கலவையாகும்.

அன்சிபிள்க்கு பதிலாக, செஃப், பப்பட், சால்ட்ஸ்டாக் ஆகியவற்றைப் பயன்படுத்தலாம். பல அளவுகோல்களின் அடிப்படையில் அன்சிபிளைத் தேர்ந்தெடுத்தோம்.

• முதலாவதாக, இது பல்துறை. கட்டுப்பாட்டுக்கான ஆயத்த தொகுதிகளின் தொகுப்பு அது ஈர்க்கக்கூடியது. உங்களிடம் போதுமான அளவு இல்லை என்றால், நீங்கள் GitHub மற்றும் Galaxy இல் தேடலாம்.
• இரண்டாவதாக, நிர்வகிக்கப்பட்ட உபகரணங்களில் முகவர்களை நிறுவி ஆதரிக்க வேண்டிய அவசியமில்லை, அவை சுமைகளில் தலையிடாது என்பதை நிரூபிக்கவும், "புக்மார்க்குகள்" இல்லாததை உறுதிப்படுத்தவும்.
• மூன்றாவதாக, அன்சிபிள் நுழைவதற்கு குறைந்த தடையைக் கொண்டுள்ளது. ஒரு திறமையான பொறியாளர், தயாரிப்புடன் பணிபுரியும் முதல் நாளில் ஒரு வேலை புத்தகத்தை எழுதுவார்.

ஆனால் உற்பத்தி சூழலில் அன்சிபிள் மட்டும் எங்களுக்கு போதுமானதாக இல்லை. இல்லையெனில், அணுகலைக் கட்டுப்படுத்துவதிலும், நிர்வாகிகளின் செயல்களைத் தணிக்கை செய்வதிலும் பல சிக்கல்கள் எழும். அணுகலை எவ்வாறு கட்டுப்படுத்துவது? எல்லாவற்றிற்கும் மேலாக, ஒவ்வொரு துறையும் நிர்வகிக்க வேண்டியது அவசியம் (படிக்க: அன்சிபிள் பிளேபுக்கை இயக்கவும்) "அதன் சொந்த" சேவையகங்கள். குறிப்பிட்ட அன்சிபிள் பிளேபுக்குகளை இயக்க குறிப்பிட்ட ஊழியர்களை மட்டும் எப்படி அனுமதிப்பது? அல்லது அன்சிபில் இயங்கும் சர்வர்கள் மற்றும் உபகரணங்களில் நிறைய உள்ளூர் அறிவை அமைக்காமல் பிளேபுக்கை யார் தொடங்கினார்கள் என்பதைக் கண்காணிப்பது எப்படி?

இத்தகைய சிக்கல்களில் சிங்கத்தின் பங்கு Red Hat மூலம் தீர்க்கப்படுகிறது அன்சிபிள் டவர், அல்லது அவரது திறந்த மூல அப்ஸ்ட்ரீம் திட்டம் அன்சிபிள் AWX. அதனால்தான் நாங்கள் வாடிக்கையாளருக்கு முன்னுரிமை கொடுத்தோம்.

எங்கள் CMS அமைப்பின் உருவப்படத்திற்கு மேலும் ஒரு தொடுதல். அன்சிபிள் பிளேபுக் குறியீடு களஞ்சிய மேலாண்மை அமைப்புகளில் சேமிக்கப்பட வேண்டும். எங்களிடம் உள்ளது GitLab CE.

எனவே, உள்ளமைவுகள் அன்சிபிள்/அன்சிபிள் AWX/GitLab ஆகியவற்றின் கலவையால் நிர்வகிக்கப்படுகின்றன (படம் 3 ஐப் பார்க்கவும்). நிச்சயமாக, AWX/GitLab ஒற்றை அங்கீகார அமைப்புடன் ஒருங்கிணைக்கப்பட்டுள்ளது, மேலும் அன்சிபிள் பிளேபுக் ஹாஷிகார்ப் வால்ட் உடன் ஒருங்கிணைக்கப்பட்டுள்ளது. உள்ளமைவுகள் அன்சிபிள் ஏடபிள்யூஎக்ஸ் மூலம் மட்டுமே உற்பத்திச் சூழலுக்குள் நுழைகின்றன, இதில் அனைத்து “விளையாட்டின் விதிகளும்” குறிப்பிடப்பட்டுள்ளன: யார் எதை உள்ளமைக்க முடியும், சிஎம்எஸ்க்கான உள்ளமைவு மேலாண்மை குறியீட்டை எங்கு பெறுவது போன்றவை.

அரிசி. 3. கட்டமைப்பு மேலாண்மை.

சோதனை மேலாண்மை

எங்கள் கட்டமைப்பு குறியீடு வடிவத்தில் வழங்கப்படுகிறது. எனவே, மென்பொருள் உருவாக்குநர்களின் அதே விதிகளின்படி விளையாட வேண்டிய கட்டாயத்தில் இருக்கிறோம். உருவாக்கம், தொடர்ச்சியான சோதனை, விநியோகம் மற்றும் உற்பத்தி சேவையகங்களுக்கு உள்ளமைவு குறியீட்டைப் பயன்படுத்துதல் ஆகியவற்றின் செயல்முறைகளை நாங்கள் ஒழுங்கமைக்க வேண்டும்.

இது உடனடியாக செய்யப்படாவிட்டால், உள்ளமைவுக்காக எழுதப்பட்ட பாத்திரங்கள் ஆதரிக்கப்படுவதையும் மாற்றியமைப்பதையும் நிறுத்திவிடும் அல்லது தயாரிப்பில் தொடங்கப்படுவதை நிறுத்திவிடும். இந்த வலிக்கான சிகிச்சை அறியப்படுகிறது, மேலும் இது இந்த திட்டத்தில் தன்னை நிரூபித்துள்ளது:

• ஒவ்வொரு பாத்திரமும் அலகு சோதனைகளால் மூடப்பட்டிருக்கும்;
• உள்ளமைவுகளை நிர்வகிக்கும் குறியீட்டில் ஏதேனும் மாற்றம் ஏற்பட்டால் சோதனைகள் தானாகவே இயங்கும்;
• அனைத்து சோதனைகள் மற்றும் குறியீட்டு மதிப்பாய்வை வெற்றிகரமாக நிறைவேற்றிய பின்னரே கட்டமைப்பு மேலாண்மை குறியீட்டில் மாற்றங்கள் உற்பத்தி சூழலில் வெளியிடப்படுகின்றன.

குறியீடு மேம்பாடு மற்றும் உள்ளமைவு மேலாண்மை ஆகியவை அமைதியாகவும் மேலும் கணிக்கக்கூடியதாகவும் மாறியுள்ளது. தொடர்ச்சியான சோதனையை ஒழுங்கமைக்க, நாங்கள் GitLab CI/CD கருவித்தொகுப்பைப் பயன்படுத்தினோம், மேலும் எடுத்தோம் அன்சிபிள் மூலக்கூறு.

உள்ளமைவு மேலாண்மைக் குறியீட்டில் மாற்றம் ஏற்படும் போதெல்லாம், GitLab CI/CD மூலக்கூறுகளை அழைக்கிறது:

• இது குறியீடு தொடரியல் சரிபார்க்கிறது,
• டோக்கர் கொள்கலனை உயர்த்துகிறது,
• உருவாக்கப்பட்ட கொள்கலனுக்கு மாற்றியமைக்கப்பட்ட குறியீட்டைப் பயன்படுத்துகிறது,
• இயலாமைக்கான பங்கைச் சரிபார்த்து, இந்தக் குறியீட்டிற்கான சோதனைகளை இயக்குகிறது (இங்குள்ள கிரானுலாரிட்டி அன்சிபிள் ரோல் அளவில் உள்ளது, படம் 4 ஐப் பார்க்கவும்).

அன்சிபிள் AWX ஐப் பயன்படுத்தி உற்பத்தி சூழலுக்கு உள்ளமைவுகளை வழங்கினோம். செயல்பாட்டு பொறியாளர்கள் முன் வரையறுக்கப்பட்ட வார்ப்புருக்கள் மூலம் உள்ளமைவு மாற்றங்களைப் பயன்படுத்துகின்றனர். AWX ஆனது GitLab மாஸ்டர் கிளையிலிருந்து குறியீட்டின் சமீபத்திய பதிப்பை ஒவ்வொரு முறை பயன்படுத்தப்படும்போதும் சுயாதீனமாக "கோரிக்கப்பட்டது". இந்த வழியில் உற்பத்திச் சூழலில் சோதிக்கப்படாத அல்லது காலாவதியான குறியீட்டைப் பயன்படுத்துவதை நாங்கள் விலக்கினோம். இயற்கையாகவே, சோதனை, மதிப்பாய்வு மற்றும் ஒப்புதலுக்குப் பிறகுதான் குறியீடு முதன்மைக் கிளைக்குள் நுழைந்தது.

அரிசி. 4. GitLab CI/CD இல் பாத்திரங்களின் தானியங்கி சோதனை.

உற்பத்தி அமைப்புகளின் செயல்பாட்டுடன் தொடர்புடைய ஒரு பிரச்சனையும் உள்ளது. நிஜ வாழ்க்கையில், CMS குறியீடு மூலம் மட்டும் உள்ளமைவு மாற்றங்களைச் செய்வது மிகவும் கடினம். குறியீட்டு எடிட்டிங், சோதனை, ஒப்புதல் போன்றவற்றிற்காக காத்திருக்காமல், ஒரு பொறியாளர் "இங்கே மற்றும் இப்போது" உள்ளமைவை மாற்ற வேண்டிய அவசர சூழ்நிலைகள் எழுகின்றன.

இதன் விளைவாக, கைமுறை மாற்றங்கள் காரணமாக, ஒரே வகை உபகரணங்களில் உள்ளமைவில் முரண்பாடுகள் தோன்றும் (உதாரணமாக, sysctl அமைப்புகள் HA கிளஸ்டர் முனைகளில் வித்தியாசமாக கட்டமைக்கப்படுகின்றன). அல்லது உபகரணங்களில் உள்ள உண்மையான உள்ளமைவு CMS குறியீட்டில் குறிப்பிடப்பட்டதிலிருந்து வேறுபடுகிறது.

எனவே, தொடர்ச்சியான சோதனைக்கு கூடுதலாக, உள்ளமைவு முரண்பாடுகளுக்கான உற்பத்தி சூழல்களை நாங்கள் சரிபார்க்கிறோம். நாங்கள் எளிமையான விருப்பத்தைத் தேர்ந்தெடுத்தோம்: CMS உள்ளமைவுக் குறியீட்டை "டிரை ரன்" பயன்முறையில் இயக்கவும், அதாவது மாற்றங்களைப் பயன்படுத்தாமல், ஆனால் திட்டமிட்ட மற்றும் உண்மையான உள்ளமைவுக்கு இடையே உள்ள அனைத்து முரண்பாடுகளின் அறிவிப்புடன். தயாரிப்பு சேவையகங்களில் “—செக்” விருப்பத்துடன் அனைத்து அன்சிபிள் பிளேபுக்குகளையும் அவ்வப்போது இயக்குவதன் மூலம் இதைச் செயல்படுத்தினோம். எப்போதும் போல, பிளேபுக்கைத் தொடங்குவதற்கும் புதுப்பித்த நிலையில் வைத்திருப்பதற்கும் Ansible AWX பொறுப்பாகும் (படம் 5 ஐப் பார்க்கவும்):

அரிசி. 5. Ansible AWX இல் உள்ளமைவு முரண்பாடுகளை சரிபார்க்கிறது.

சரிபார்ப்புகளுக்குப் பிறகு, AWX நிர்வாகிகளுக்கு ஒரு முரண்பாடு அறிக்கையை அனுப்புகிறது. அவர்கள் சிக்கலான உள்ளமைவைப் படித்து பின்னர் சரிசெய்யப்பட்ட பிளேபுக்குகள் மூலம் அதைச் சரிசெய்கிறார்கள். உற்பத்திச் சூழலில் உள்ளமைவை இப்படித்தான் நாங்கள் பராமரிக்கிறோம் மற்றும் CMS எப்போதும் புதுப்பித்த நிலையில் மற்றும் ஒத்திசைக்கப்படுகிறது. இது "உற்பத்தி" சேவையகங்களில் CMS குறியீடு பயன்படுத்தப்படும் போது விரும்பத்தகாத "அற்புதங்களை" நீக்குகிறது.

எங்களிடம் இப்போது அன்சிபிள் AWX/GitLab/Molecule (படம் 6) அடங்கிய முக்கியமான சோதனை அடுக்கு உள்ளது.

அரிசி. 6. சோதனை மேலாண்மை.

கஷ்டமா? நான் வாதிடுவதில்லை. ஆனால் கட்டமைப்பு நிர்வாகத்தின் இத்தகைய சிக்கலானது சர்வர் உள்ளமைவின் ஆட்டோமேஷன் தொடர்பான பல கேள்விகளுக்கு ஒரு விரிவான பதிலாக மாறியுள்ளது. இப்போது சில்லறை விற்பனையாளரின் நிலையான சேவையகங்கள் எப்போதும் கண்டிப்பாக வரையறுக்கப்பட்ட உள்ளமைவைக் கொண்டுள்ளன. CMS, ஒரு பொறியாளரைப் போலல்லாமல், தேவையான அமைப்புகளைச் சேர்க்க, பயனர்களை உருவாக்க மற்றும் டஜன் கணக்கான அல்லது நூற்றுக்கணக்கான தேவையான அமைப்புகளைச் செய்ய மறக்காது.

இன்று சேவையகங்கள் மற்றும் சூழல்களின் அமைப்புகளில் "ரகசிய அறிவு" இல்லை. தேவையான அனைத்து அம்சங்களும் பிளேபுக்கில் பிரதிபலிக்கின்றன. மேலும் படைப்பாற்றல் மற்றும் தெளிவற்ற வழிமுறைகள் இல்லை: "வழக்கமான Oracle போன்று இதை நிறுவவும், ஆனால் நீங்கள் இரண்டு sysctl அமைப்புகளைக் குறிப்பிட வேண்டும் மற்றும் தேவையான UID உள்ள பயனர்களைச் சேர்க்க வேண்டும். செயல்பாட்டில் உள்ளவர்களிடம் கேளுங்கள், அவர்களுக்குத் தெரியும்".

உள்ளமைவு முரண்பாடுகளைக் கண்டறிந்து அவற்றை முன்கூட்டியே சரிசெய்யும் திறன் மன அமைதியை வழங்குகிறது. உள்ளமைவு மேலாண்மை அமைப்பு இல்லாமல், இது பொதுவாக வித்தியாசமாகத் தெரிகிறது. ஒரு நாள் அவர்கள் உற்பத்தியில் "சுட" வரை சிக்கல்கள் குவிந்து கிடக்கின்றன. பின்னர் ஒரு விவாதம் மேற்கொள்ளப்படுகிறது, உள்ளமைவுகள் சரிபார்க்கப்பட்டு சரி செய்யப்படுகின்றன. மேலும் சுழற்சி மீண்டும் நிகழ்கிறது

நிச்சயமாக, நாங்கள் பல நாட்கள் முதல் மணிநேரம் வரை சேவையகங்களை இயக்குவதை துரிதப்படுத்தினோம்.

புத்தாண்டு தினத்தன்று, குழந்தைகள் மகிழ்ச்சியுடன் பரிசுகளை அவிழ்த்துக்கொண்டிருந்தபோதும், பெரியவர்கள் சத்தம் அடித்தபோதும், எங்கள் பொறியாளர்கள் SAP அமைப்பை புதிய சேவையகங்களுக்கு மாற்றினர். சாண்டா கிளாஸ் கூட சிறந்த அற்புதங்கள் என்று கூறுவார்கள்.

PS வாடிக்கையாளர்கள் உள்ளமைவு மேலாண்மை சிக்கல்களை முடிந்தவரை எளிமையாக தீர்க்க விரும்புகிறார்கள் என்ற உண்மையை எங்கள் குழு அடிக்கடி எதிர்கொள்கிறது. வெறுமனே, மந்திரம் போல - ஒரு கருவி மூலம். ஆனால் வாழ்க்கையில் எல்லாம் மிகவும் சிக்கலானது (ஆம், வெள்ளி தோட்டாக்கள் மீண்டும் வழங்கப்படவில்லை): வாடிக்கையாளரின் குழுவிற்கு வசதியான கருவிகளைப் பயன்படுத்தி நீங்கள் முழு செயல்முறையையும் உருவாக்க வேண்டும்.

ஆசிரியர்: செர்ஜி ஆர்டெமோவ், துறை கட்டிடக் கலைஞர் DevOps தீர்வுகள் "ஜெட் இன்ஃபோசிஸ்டம்ஸ்"

ஆதாரம்: www.habr.com