உங்கள் நெட்வொர்க் உள்கட்டமைப்பை எவ்வாறு கட்டுப்படுத்துவது. அத்தியாயம் நான்கு. ஆட்டோமேஷன். வார்ப்புருக்கள்

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

பல தலைப்புகளை விட்டுவிட்டு, ஒரு புதிய அத்தியாயத்தைத் தொடங்க முடிவு செய்தேன்.

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

நெட்வொர்க்கிற்கான DevOps

ஸ்கிரிப்ட் மூலம் உள்ளமைவை உருவாக்குதல், IT உள்கட்டமைப்பில் மாற்றங்களைக் கட்டுப்படுத்த GITஐப் பயன்படுத்துதல், தொலைநிலை “பதிவேற்றுதல்” - DevOps அணுகுமுறையின் தொழில்நுட்ப செயலாக்கத்தைப் பற்றி நீங்கள் சிந்திக்கும்போது இந்த யோசனைகள் முதலில் வருகின்றன. நன்மைகள் வெளிப்படையானவை. ஆனால், துரதிர்ஷ்டவசமாக, தீமைகளும் உள்ளன.

5 ஆண்டுகளுக்கு முன்பு, எங்கள் டெவலப்பர்கள், நெட்வொர்க்கர்கள், இந்த முன்மொழிவுகளுடன் எங்களிடம் வந்தபோது, ​​நாங்கள் மகிழ்ச்சியடையவில்லை.

சுமார் 10 வெவ்வேறு விற்பனையாளர்களிடமிருந்து உபகரணங்களைக் கொண்ட ஒரு மோட்லி நெட்வொர்க்கை நாங்கள் பெற்றோம் என்று நான் சொல்ல வேண்டும். சில விஷயங்களை நமக்குப் பிடித்த cli மூலம் கட்டமைக்க வசதியாக இருந்தது, ஆனால் மற்றவற்றில் GUI ஐப் பயன்படுத்த விரும்புகிறோம். கூடுதலாக, "நேரடி" உபகரணங்களில் நீண்ட வேலை நிகழ்நேரக் கட்டுப்பாட்டை எங்களுக்குக் கற்பித்துள்ளது. எடுத்துக்காட்டாக, மாற்றங்களைச் செய்யும்போது, ​​cli மூலம் நேரடியாக வேலை செய்வதை நான் மிகவும் வசதியாக உணர்கிறேன். இந்த வழியில், ஏதோ தவறு நடந்திருப்பதை என்னால் விரைவாகப் பார்க்க முடிகிறது மற்றும் மாற்றங்களைத் திரும்பப் பெற முடியும். இவையனைத்தும் அவர்களின் கருத்துக்களுக்கு முரணாக இருந்தது.

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

அல்லது, உள்ளமைவு கட்டளைகள் சரியாகப் பயன்படுத்தப்பட்டன என்பதை எவ்வாறு புரிந்துகொள்வது மற்றும் பிழை ஏற்பட்டால் என்ன செய்வது?

இந்த பிரச்சினைகள் அனைத்தும் தீர்க்க முடியாதவை என்று நான் கூற விரும்பவில்லை. "A" என்று சொன்னால், "B" என்று சொல்வதும் அர்த்தமுள்ளதாக இருக்கும், மேலும் வளர்ச்சியில் இருக்கும் அதே செயல்முறைகளை மாற்றக் கட்டுப்பாட்டிற்குப் பயன்படுத்த விரும்பினால், நீங்கள் உற்பத்திக்கு கூடுதலாக dev மற்றும் ஸ்டேஜிங் சூழல்களைக் கொண்டிருக்க வேண்டும். பின்னர் இந்த அணுகுமுறை முழுமையானதாகத் தெரிகிறது. ஆனால் அதற்கு எவ்வளவு செலவாகும்?

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

திட்டம்

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

தனிப்பட்ட முறையில் என்னைப் பொறுத்தவரை, இந்த திட்டத்தில் இரண்டு தனித்துவமான நிலைகள் உள்ளன.

முதல் கட்டம்

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

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

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

இப்போது நாம் கொஞ்சம் சுற்றிப் பார்க்கலாம்.
மேலும் இது இரண்டாம் கட்டத்தின் தொடக்கமாக இருந்தது.

நிலை இரண்டு

செயல்முறையை தானியக்கமாக்க முடிவு செய்தேன்.

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

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

எனவே, YAML மற்றும் Jinja2 ஐப் பயன்படுத்தும் போது, ​​IP முகவரிகள், BGP AS எண்கள், ... போன்ற கட்டமைப்பு அளவுருக்கள் கொண்ட YAML கோப்பு, NIP இன் பங்கை மிகச்சரியாக நிறைவேற்றுகிறது, அதே நேரத்தில் Jinja2 வார்ப்புருக்கள் வடிவமைப்பிற்கு ஒத்த தொடரியலை உள்ளடக்கியது, அதாவது, இது அடிப்படையில் ஒரு எல்எல்டியின் பிரதிபலிப்பு.

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

இப்போது மாற்றம் செயல்முறை இதுபோல் தெரிகிறது:

• YAML கோப்பை மாற்றியது
• ஒரு டெம்ப்ளேட்டைப் பயன்படுத்தி ஒரு கட்டமைப்பு கோப்பை உருவாக்கியது (ஜின்ஜா2)
• தொலை களஞ்சியத்தில் சேமிக்கப்பட்டது
• உருவாக்கப்பட்ட கட்டமைப்பை சாதனத்தில் பதிவேற்றியது
• நான் ஒரு பிழையைப் பார்த்தேன்
• YAML கோப்பு அல்லது ஜின்ஜா2 டெம்ப்ளேட்டை மாற்றியது
• ஒரு டெம்ப்ளேட்டைப் பயன்படுத்தி ஒரு கட்டமைப்பு கோப்பை உருவாக்கியது (ஜின்ஜா2)
• ...

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

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

தேவ் மற்றும் ஸ்டேஜிங்

ஸ்டேஜிங் உண்மையில் உற்பத்தியை முழுமையாக பிரதிபலிக்கிறது. தேவ் என்பது முக்கியமாக மெய்நிகர் வன்பொருளில் கட்டமைக்கப்பட்ட பெரிதும் அகற்றப்பட்ட நகலாகும். புதிய அணுகுமுறைக்கு ஏற்ற சூழ்நிலை. ஒட்டுமொத்த செயல்முறையிலிருந்து நான் செலவழித்த நேரத்தை தனிமைப்படுத்தினால், வேலை 2 வாரங்களுக்கு மேல் ஆகாது என்று நினைக்கிறேன். முக்கிய நேரம் மறுபுறம் காத்திருக்கிறது மற்றும் ஒன்றாக சிக்கல்களைத் தேடுகிறது. 3வது தரப்பைச் செயல்படுத்துவது கிட்டத்தட்ட மற்றவர்களால் கவனிக்கப்படாமல் போய்விட்டது. ஹப்ரே பற்றி ஏதாவது கற்றுக் கொள்ளவும், ஓரிரு கட்டுரைகளை எழுதவும் நேரம் கிடைத்தது :)

சுருக்கமாக சொல்கிறேன்

எனவே, அடிமட்டத்தில் என்னிடம் என்ன இருக்கிறது?

• உள்ளமைவை மாற்ற நான் செய்ய வேண்டியதெல்லாம், உள்ளமைவு அளவுருக்கள் கொண்ட எளிய, தெளிவாக கட்டமைக்கப்பட்ட YAML கோப்பை மாற்ற வேண்டும். நான் ஒருபோதும் பைதான் ஸ்கிரிப்டை மாற்றுவதில்லை மற்றும் மிக அரிதாக (பிழை இருந்தால் மட்டும்) ஜின்ஜா2 ஹீட்லேட்டை மாற்றுவேன்
• ஒரு ஆவணக் கண்ணோட்டத்தில், இது கிட்டத்தட்ட ஒரு சிறந்த சூழ்நிலை. நீங்கள் ஆவணங்களை மாற்றி (YAML கோப்புகள் NIP ஆக செயல்படுகின்றன) மற்றும் இந்த உள்ளமைவை சாதனத்தில் பதிவேற்றவும். இந்த வழியில் உங்கள் ஆவணங்கள் எப்போதும் புதுப்பித்த நிலையில் இருக்கும்

இவை அனைத்தும் உண்மைக்கு வழிவகுத்தது

• பிழை விகிதம் கிட்டத்தட்ட 0 ஆகக் குறைந்துள்ளது
• வழக்கத்தில் 90 சதவீதம் போய்விட்டது
• செயல்படுத்தும் வேகம் கணிசமாக அதிகரித்துள்ளது

பே, F5Y, ACY

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

கட்டுங்க = வரிசைப்படுத்தல் Pஆலோ Aஇருந்து Yaml = Yaml இலிருந்து பாலோ ஆல்டோ
F5Y = வரிசைப்படுத்தல் F5 இருந்து Yaml = F5 இருந்து Yaml (விரைவில்)
ACY = வரிசைப்படுத்தல் ACநான் இருந்து Yaml = F5 இருந்து Yஅடிக்கடி

ACY பற்றி சில வார்த்தைகளைச் சேர்ப்பேன் (ACI உடன் குழப்பிக் கொள்ள வேண்டாம்).

ACI உடன் பணிபுரிந்தவர்களுக்கு தெரியும், இந்த அதிசயம் (மற்றும் ஒரு நல்ல வழியில்) நிச்சயமாக நெட்வொர்க்கர்களால் உருவாக்கப்படவில்லை :). நெட்வொர்க்கைப் பற்றி உங்களுக்குத் தெரிந்த அனைத்தையும் மறந்து விடுங்கள் - அது உங்களுக்கு பயனுள்ளதாக இருக்காது!
இது கொஞ்சம் மிகைப்படுத்தப்பட்டதாக இருந்தாலும், கடந்த 3 ஆண்டுகளாக, ஏசிஐ உடன் பணிபுரிந்து வருவதை நான் தொடர்ந்து அனுபவித்து வருகிறேன் என்ற உணர்வை இது தோராயமாக வெளிப்படுத்துகிறது.

இந்த விஷயத்தில், ACY என்பது ஒரு மாற்றக் கட்டுப்பாட்டு செயல்முறையை உருவாக்குவதற்கான ஒரு வாய்ப்பாகும் (ஏசிஐ விஷயத்தில் இது மிகவும் முக்கியமானது, ஏனெனில் இது உங்கள் தரவு மையத்தின் மைய மற்றும் மிக முக்கியமான பகுதியாக இருக்க வேண்டும்), ஆனால் உங்களுக்கு வழங்குகிறது உள்ளமைவை உருவாக்குவதற்கான பயனர் நட்பு இடைமுகம்.

இந்த திட்டத்தில் உள்ள பொறியாளர்கள், அதே நோக்கங்களுக்காக YAML க்கு பதிலாக ACI ஐ உள்ளமைக்க Excel ஐப் பயன்படுத்துகின்றனர். எக்செல் பயன்படுத்துவதில் நிச்சயமாக நன்மைகள் உள்ளன:

• ஒரு கோப்பில் உங்கள் NIP
• வாடிக்கையாளர் பார்க்க இனிமையான அழகான அறிகுறிகள்
• நீங்கள் சில எக்செல் கருவிகளைப் பயன்படுத்தலாம்

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

ACY என்பது உண்மையில் ACI ஐ உள்ளமைக்க மூன்றாம் தரப்பினருக்கு நான் பயன்படுத்திய அதே அணுகுமுறைகளின் பயன்பாடாகும்.

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