VM, Nomad மற்றும் Kubernetes ஆகியவற்றிற்கு விண்ணப்பங்களை வரிசைப்படுத்துகிறது

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

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

VM க்கு விண்ணப்பங்களை வரிசைப்படுத்துகிறது

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

இது ஏன் செய்யப்பட்டது?

எங்கள் பயன்பாட்டின் புதிய வெளியீடுகளை நாங்கள் பயன்படுத்தியபோது, ​​பயனர்களுக்கு குறிப்பிடத்தக்க விளைவுகள் இல்லாமல், தடையற்ற வெளியீட்டை உறுதிசெய்ய விரும்பினோம். Ansible ஐப் பயன்படுத்தி அடுத்த தொகுக்கப்பட்ட வெளியீடு வால் வரை உருட்டப்பட்டதன் காரணமாக இது அடையப்பட்டது. அங்கு, வரிசைப்படுத்தலில் ஈடுபட்டிருந்தவர்கள் சரிபார்த்து, எல்லாம் சரியாக இருக்கிறதா என்பதை உறுதிப்படுத்திக் கொள்ளலாம்: அனைத்து அளவீடுகள், பிரிவுகள் மற்றும் பயன்பாடுகள் வேலை செய்கின்றன; தேவையான ஸ்கிரிப்டுகள் தொடங்கப்பட்டுள்ளன. எல்லாம் சரியாகிவிட்டது என்று உறுதியான பிறகுதான் போக்குவரத்து மாற்றப்பட்டது. முன்பு வால் இருந்த சர்வருக்குப் போக ஆரம்பித்தது. எங்கள் பயன்பாட்டின் முந்தைய பதிப்பை வைத்திருக்கும் அதே வேளையில், முன்பு தலைவராக இருந்தவர் பயனர் போக்குவரத்து இல்லாமல் இருந்தார்.

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

இவை அனைத்திலும் நாம் என்ன நன்மைகளைக் கண்டோம்?

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

ஆனால் இவை அனைத்திலும் பல குறைபாடுகளையும் நாங்கள் கண்டோம்:

  1. உற்பத்தி சூழல், வளர்ச்சி சூழல் தவிர, பிற சூழல்களும் உள்ளன. எடுத்துக்காட்டாக, qa மற்றும் முன் தயாரிப்பு. அந்த நேரத்தில் எங்களிடம் பல சேவையகங்கள் மற்றும் சுமார் 60 சேவைகள் இருந்தன. இந்த காரணத்திற்காக இது அவசியமாக இருந்தது ஒவ்வொரு சேவைக்கும், அதற்கான சமீபத்திய பதிப்பைப் பராமரிக்கவும் மெய்நிகர் இயந்திரம். மேலும், நீங்கள் நூலகங்களைப் புதுப்பிக்க விரும்பினால் அல்லது புதிய சார்புகளை நிறுவ விரும்பினால், எல்லா சூழல்களிலும் இதைச் செய்ய வேண்டும். டெவொப்ஸ் தேவையான சூழல் அமைப்புகளைச் செய்யும் நேரத்துடன் உங்கள் பயன்பாட்டின் அடுத்த புதிய பதிப்பைப் பயன்படுத்தப் போகும் நேரத்தையும் நீங்கள் ஒத்திசைக்க வேண்டும். இந்த விஷயத்தில், ஒரே நேரத்தில் அனைத்து சூழல்களிலும் நமது சூழல் சற்று வித்தியாசமாக இருக்கும் சூழ்நிலைக்கு வருவது எளிது. எடுத்துக்காட்டாக, QA சூழலில் நூலகங்களின் சில பதிப்புகள் இருக்கும், மேலும் உற்பத்திச் சூழலில் வேறுபட்டவை இருக்கும், இது சிக்கல்களுக்கு வழிவகுக்கும்.
  2. சார்புகளைப் புதுப்பிப்பதில் சிரமம் உங்கள் விண்ணப்பம். இது உங்களைப் பொறுத்தது அல்ல, ஆனால் மற்ற அணியைப் பொறுத்தது. அதாவது, சர்வர்களை பராமரிக்கும் டெவொப்ஸ் குழுவிலிருந்து. நீங்கள் அவர்களுக்கு பொருத்தமான பணியையும் நீங்கள் என்ன செய்ய விரும்புகிறீர்கள் என்பதற்கான விளக்கத்தையும் கொடுக்க வேண்டும்.
  3. அந்த நேரத்தில், எங்களிடம் இருந்த பெரிய பெரிய மோனோலித்களை தனித்தனி சிறிய சேவைகளாகப் பிரிக்க விரும்பினோம், ஏனெனில் அவை மேலும் மேலும் இருக்கும் என்பதை நாங்கள் புரிந்துகொண்டோம். அந்த நேரத்தில், அவற்றில் 100 க்கும் மேற்பட்டவை ஏற்கனவே எங்களிடம் இருந்தன. ஒவ்வொரு புதிய சேவைக்கும், ஒரு தனி புதிய மெய்நிகர் இயந்திரத்தை உருவாக்குவது அவசியம், அதுவும் பராமரிக்கப்பட்டு பயன்படுத்தப்பட வேண்டும். கூடுதலாக, உங்களுக்கு ஒரு கார் தேவையில்லை, ஆனால் குறைந்தது இரண்டு. இதற்கெல்லாம் சேர்க்கப்பட்டது QA சூழல். இது சிக்கல்களை ஏற்படுத்துகிறது மற்றும் புதிய அமைப்புகளை உருவாக்கி இயக்குவதை மிகவும் கடினமாக்குகிறது. சிக்கலான, விலையுயர்ந்த மற்றும் நீண்ட செயல்முறை.

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

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

நாடோடிக்கு மாறவும்

நோமட் என்பது ஹாஷிகார்ப் நிறுவனத்தின் தயாரிப்பு. அவை மற்ற தீர்வுகளுக்கும் பெயர் பெற்றவை:

VM, Nomad மற்றும் Kubernetes ஆகியவற்றிற்கு விண்ணப்பங்களை வரிசைப்படுத்துகிறது

"கன்சல்" சேவையை கண்டுபிடிப்பதற்கான ஒரு கருவியாகும்.

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

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

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

உங்கள் கணினியை நாடோடிக்கு பயன்படுத்த என்ன தேவை?

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

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

VM, Nomad மற்றும் Kubernetes ஆகியவற்றிற்கு விண்ணப்பங்களை வரிசைப்படுத்துகிறது

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

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

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

VM, Nomad மற்றும் Kubernetes ஆகியவற்றிற்கு விண்ணப்பங்களை வரிசைப்படுத்துகிறது

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

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

VM, Nomad மற்றும் Kubernetes ஆகியவற்றிற்கு விண்ணப்பங்களை வரிசைப்படுத்துகிறது

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

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

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

VM, Nomad மற்றும் Kubernetes ஆகியவற்றிற்கு விண்ணப்பங்களை வரிசைப்படுத்துகிறது

முதலில், உங்களுக்கு வெளியில் சில வகையான பேலன்சர் தேவை, இது அனைத்து பயனர் போக்குவரத்தையும் பெறும். இது தூதரகத்துடன் இணைந்து செயல்படும் மற்றும் ஒரு குறிப்பிட்ட டொமைன் பெயருடன் தொடர்புடைய ஒரு குறிப்பிட்ட சேவை எங்கு, எந்த முனையில், எந்த ஐபி முகவரியில் அமைந்துள்ளது என்பதைக் கண்டறியும். தூதரக சேவைகள் நோமடிலிருந்தே வருகின்றன. இவை ஒரே நிறுவனத்தின் தயாரிப்புகள் என்பதால், அவை ஒன்றோடொன்று தொடர்புடையவை. Nomad out of the box அதில் தொடங்கப்பட்ட அனைத்து சேவைகளையும் தூதரகத்திற்குள் பதிவு செய்ய முடியும் என்று நாம் கூறலாம்.

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

மனித வளத்தைப் பொறுத்தவரை மாற்றம் எவ்வளவு செலவாகும்?

முழு நிறுவனமும் நாடோடிக்கு மாறுவதற்கு சுமார் 5-6 மாதங்கள் ஆனது. நாங்கள் சேவை வாரியாகச் சென்றோம், ஆனால் மிக விரைவான வேகத்தில். ஒவ்வொரு குழுவும் சேவைகளுக்காக தங்கள் சொந்த கொள்கலன்களை உருவாக்க வேண்டும்.

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

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

நாடோடியை கைவிடுவதற்கான காரணங்கள்

Nomad மற்றும் docker போன்றவற்றைப் பயன்படுத்தி வரிசைப்படுத்துதலுக்கு மாறுவதன் மூலம் என்ன நன்மைகளைப் பெற்றோம்?

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

ஆனால் நாங்கள் பல குறைபாடுகளையும் சந்தித்தோம்:

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

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

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

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

குபெர்னெட்டஸுக்கு மாற்றம்

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

VM, Nomad மற்றும் Kubernetes ஆகியவற்றிற்கு விண்ணப்பங்களை வரிசைப்படுத்துகிறது

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

உன்னதமான திட்டமான nginx மற்றும் php-fpm ஆகியவற்றைக் கொண்ட PHP பயன்பாடு உங்களிடம் உள்ளது என்று வைத்துக்கொள்வோம். பெரும்பாலும், நீங்கள் எல்லா நேரங்களிலும் nginx மற்றும் php-fpm கொள்கலன்களை ஒன்றாக வைத்திருக்க விரும்புவீர்கள். குபெர்னெட்டஸ் ஒரு பொதுவான பாட் என்று விவரிப்பதன் மூலம் இதை அடைய உங்களை அனுமதிக்கிறது. இதைத்தான் நாடோடியுடன் எங்களால் பெற முடியவில்லை.

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

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

மற்றும் நான்காவது அடிப்படை கருத்து உட்செல்வதை. இது குபெர்னெட்ஸ் கிளஸ்டரில் இயங்கும் சேவையாகும். இது அனைத்து கோரிக்கைகளையும் எடுக்கும் வெளிப்புற சுமை சமநிலையாக செயல்படுகிறது. Kubernetes API ஐப் பயன்படுத்தி, இந்த கோரிக்கைகள் எங்கு அனுப்பப்பட வேண்டும் என்பதை Ingress தீர்மானிக்க முடியும். மேலும், அவர் இதை மிகவும் நெகிழ்வாக செய்கிறார். இந்த ஹோஸ்டுக்கான அனைத்து கோரிக்கைகளும் மற்றும் அத்தகைய URLகளும் இந்த சேவைக்கு அனுப்பப்படும் என்று நீங்கள் கூறலாம். இந்த ஹோஸ்டுக்கும் மற்றொரு URL க்கும் வரும் இந்தக் கோரிக்கைகள் மற்றொரு சேவைக்கு அனுப்பப்படும்.

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

இந்த எல்லா கருத்துகளையும் நாடோடியுடன் ஒப்பிட்டுப் பார்த்தால், முதல் மூன்று கருத்துக்கள் அனைத்தும் ஒன்றாக சேவை என்று சொல்லலாம். கடைசி கருத்து நாடோடியிலேயே இல்லை. வெளிப்புற பேலன்சரைப் பயன்படுத்தினோம்: அது ஹாப்ராக்ஸி, என்ஜிஎன்எக்ஸ், என்ஜிஎன்எக்ஸ்+ மற்றும் பலவாக இருக்கலாம். கனசதுரத்தைப் பொறுத்தவரை, இந்த கூடுதல் கருத்தை நீங்கள் தனித்தனியாக அறிமுகப்படுத்த வேண்டியதில்லை. இருப்பினும், நீங்கள் உள்நாட்டில் உள்ளிழுப்பைப் பார்த்தால், அது nginx, haproxy அல்லது traefik, ஆனால் Kubernetes இல் கட்டமைக்கப்பட்டுள்ளது.

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

VM, Nomad மற்றும் Kubernetes ஆகியவற்றிற்கு விண்ணப்பங்களை வரிசைப்படுத்துகிறது

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

ஹெல்மில் அடிப்படை கருத்துக்கள்

ஹெல்ம் உள்ளது தொகுப்பு மேலாளர் குபர்னெட்டஸுக்கு. நிரலாக்க மொழிகளில் தொகுப்பு மேலாளர்கள் எவ்வாறு செயல்படுகிறார்கள் என்பதைப் போலவே இது மிகவும் ஒத்திருக்கிறது. எடுத்துக்காட்டாக, deployment nginx, deployment php-fpm, config for Ingress, configmaps (இது உங்கள் கணினிக்கான env மற்றும் பிற அளவுருக்களை அமைக்க உங்களை அனுமதிக்கும் ஒரு நிறுவனம்) போன்றவற்றை உள்ளடக்கிய ஒரு சேவையைச் சேமிக்க அவை உங்களை அனுமதிக்கின்றன. விளக்கப்படங்கள் என்று அழைக்கப்படுகின்றன. அதே நேரத்தில் ஹெல்ம் குபெர்னெட்டஸின் மேல் ஓடுகிறது. அதாவது, இது ஒருவித அமைப்பு ஒதுங்கி நிற்கவில்லை, ஆனால் கனசதுரத்திற்குள் தொடங்கப்பட்ட மற்றொரு சேவை. கன்சோல் கட்டளை மூலம் அதன் API வழியாக நீங்கள் அதனுடன் தொடர்பு கொள்கிறீர்கள். அதன் வசதி மற்றும் அழகு என்னவென்றால், ஹெல்ம் உடைந்தாலும் அல்லது கிளஸ்டரிலிருந்து அகற்றினாலும், உங்கள் சேவைகள் மறைந்துவிடாது, ஏனெனில் ஹெல்ம் அடிப்படையில் கணினியைத் தொடங்க மட்டுமே உதவுகிறது. சேவைகளின் செயல்திறன் மற்றும் நிலைக்கு குபெர்னெட்டஸ் தானே பொறுப்பு.

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

ஹெல்ம் எங்களுக்காக இன்னும் சில கருத்துக்களைச் சேர்க்கிறார்.

விளக்கப்படம் - இது உங்கள் சேவையின் விளக்கம். மற்ற பேக்கேஜ் மேனேஜர்களில் இது ஒரு தொகுப்பு, மூட்டை அல்லது அதுபோன்ற ஒன்று என்று அழைக்கப்படும். இங்கே அது விளக்கப்படம் என்று அழைக்கப்படுகிறது.

மதிப்புகள் வார்ப்புருக்களிலிருந்து உங்கள் கட்டமைப்புகளை உருவாக்க நீங்கள் பயன்படுத்த விரும்பும் மாறிகள்.

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

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

VM, Nomad மற்றும் Kubernetes ஆகியவற்றிற்கு விண்ணப்பங்களை வரிசைப்படுத்துகிறது

நடைமுறையில், நாடோடியுடன் செய்ததை விட சற்று வித்தியாசமாக விஷயங்களைச் செய்ய முடிவு செய்தோம். Nomad இல் எங்கள் சேவையை வரிசைப்படுத்த தேவையான deployment configs மற்றும் n-variables ஆகிய இரண்டும் ஒரு களஞ்சியத்தில் சேமிக்கப்பட்டிருந்தால், அவற்றை இரண்டு தனித்தனி களஞ்சியங்களாகப் பிரிக்க முடிவு செய்தோம். "வரிசைப்படுத்து" களஞ்சியமானது வரிசைப்படுத்தலுக்குத் தேவையான n-மாறிகளை மட்டுமே சேமிக்கிறது, மேலும் "ஹெல்ம்" களஞ்சியமானது கட்டமைப்புகள் அல்லது விளக்கப்படங்களைச் சேமிக்கிறது.

VM, Nomad மற்றும் Kubernetes ஆகியவற்றிற்கு விண்ணப்பங்களை வரிசைப்படுத்துகிறது

இது நமக்கு என்ன கொடுத்தது?

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

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

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

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

கண்டுபிடிப்புகள்

குபெர்னெட்ஸ் சேவை நாடோடியை விட சிக்கலானதாக தோன்றுகிறது.

VM, Nomad மற்றும் Kubernetes ஆகியவற்றிற்கு விண்ணப்பங்களை வரிசைப்படுத்துகிறது

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

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

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

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

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

கருத்தைச் சேர்