ආයුබෝවන් සියල්ලටම! මගේ නම Pavel Agaletsky. මම Lamoda බෙදාහැරීමේ පද්ධතිය සංවර්ධනය කරන කණ්ඩායමක කණ්ඩායම් නායකයෙකු ලෙස වැඩ කරමි. 2018 දී, මම HighLoad++ සමුළුවේදී කතා කළ අතර, අද මම මගේ වාර්තාවේ පිටපතක් ඉදිරිපත් කිරීමට කැමතියි.
මගේ මාතෘකාව විවිධ පරිසරයන් සඳහා පද්ධති සහ සේවාවන් යෙදවීමේ අපගේ සමාගමේ අත්දැකීම් සඳහා කැපවී ඇත. අපගේ ප්‍රාග් ඓතිහාසික යුගයේ සිට, අපි සියලුම පද්ධති සාමාන්‍ය අතථ්‍ය සේවාදායකයන් වෙත යෙදවූ විට, Nomad සිට Kubernetes හි යෙදවීම දක්වා ක්‍රමානුකූලව සංක්රමණය වීමත් සමඟ අවසන් විය. අපි එය කළේ ඇයි සහ ක්‍රියාවලියේදී අපට ඇති වූ ගැටළු මොනවාදැයි මම ඔබට කියමි.
VM වෙත යෙදුම් යෙදවීම
මීට වසර 3 කට පෙර සමාගමේ සියලුම පද්ධති සහ සේවාවන් සාමාන්‍ය අථත්‍ය සේවාදායකයන් වෙත යොදවා ඇති බව අපි ආරම්භ කරමු. තාක්‍ෂණිකව, එය සංවිධානය කර ඇත්තේ අපගේ පද්ධති සඳහා වන සියලුම කේතය ජෙන්කින්ස් භාවිතයෙන් ස්වයංක්‍රීය එකලස් කිරීමේ මෙවලම් භාවිතයෙන් ගබඩා කර එකලස් කර ඇති ආකාරයටය. Ansible භාවිතා කරමින්, එය අපගේ අනුවාද පාලන පද්ධතියෙන් අතථ්‍ය සේවාදායකයන් වෙත ගෙන යන ලදී. එපමණක් නොව, අපගේ සමාගම සතුව තිබූ සෑම පද්ධතියක්ම අවම වශයෙන් සේවාදායකයන් 2 කට යොදවා ඇත: ඒවායින් එකක් හිස මත, දෙවැන්න වලිගය මත. මෙම පද්ධති දෙක ඒවායේ සියලු සැකසුම්, බලය, වින්‍යාසය යනාදිය තුළ එකිනෙකට සම්පූර්ණයෙන්ම සමාන විය. ඔවුන් අතර ඇති එකම වෙනස නම් හිසට පරිශීලක ගමනාගමනය ලැබුණු අතර වලිගයට කිසි විටෙකත් පරිශීලක ගමනාගමනය නොලැබීමයි.
මෙය සිදු කළේ ඇයි?
අපි අපගේ යෙදුමේ නව නිකුතු යෙදූ විට, අපට අවශ්ය වූයේ බාධාවකින් තොරව, එනම්, පරිශීලකයින්ට සැලකිය යුතු ප්‍රතිවිපාකවලින් තොරව ප්‍රවාහයක් සහතික කිරීමට ය. මෙය සාක්ෂාත් කරගනු ලැබුවේ ඇන්සිබල් භාවිතයෙන් ඊළඟ සම්පාදනය කරන ලද නිකුතුව වලිගයට පෙරළීම හේතුවෙනි. එහිදී, යෙදවීමට සම්බන්ධ වූ පුද්ගලයින්ට පරීක්ෂා කර සියල්ල හොඳින් දැයි සහතික කර ගත හැකිය: සියලුම ප්‍රමිතික, අංශ සහ යෙදුම් ක්‍රියාත්මක විය; අවශ්ය ස්ක්‍රිප්ට් දියත් කෙරේ. ඔක්කොම හරි කියලා ඒත්තු ගත්තට පස්සේ තමයි ට් රැෆික් එක මාරු කළේ. එය කලින් වලිගය වූ සේවාදායකයට යාමට පටන් ගත්තේය. අපගේ යෙදුමේ පෙර අනුවාදය තවමත් ඇති අතර, පෙර ප්‍රධානියා පරිශීලක ගමනාගමනය නොමැතිව පැවතුනි.
එබැවින් එය පරිශීලකයින්ට බාධාවකින් තොරව සිදු විය. මක්නිසාද යත්, එය හුදෙක් සමතුලිතය මාරු කරන බැවින්, මාරුවීම ක්ෂණික වන බැවිනි. සමතුලිතය ආපසු මාරු කිරීමෙන් ඔබට ඉතා පහසුවෙන් පෙර අනුවාදයට ආපසු යා හැක. පරිශීලක ගමනාගමනය ලැබීමට පෙර පවා යෙදුම නිෂ්පාදනය කිරීමට හැකියාව ඇති බව අපට සත්‍යාපනය කළ හැකිය, එය තරමක් පහසු විය.
මේ සියල්ලෙන් අප දුටු වාසි මොනවාද?
- මුලින්ම, එය ප්රමාණවත්ය එය වැඩ කරයි. බොහෝ අය සාමාන්‍ය අතථ්‍ය සේවාදායකයන් වෙත යොදවා ඇති නිසා එවැනි යෙදවුම් යෝජනා ක්‍රමයක් ක්‍රියාත්මක වන ආකාරය සෑම දෙනාටම වැටහෙනවා.
- මෙය ප්රමාණවත්ය විශ්වසනීයව, යෙදවීමේ තාක්ෂණය සරල බැවින්, සමාගම් දහස් ගණනක් විසින් පරීක්ෂා කරනු ලැබේ. මිලියන ගණනක් සේවාදායකයන් මේ ආකාරයෙන් යොදවා ඇත. යමක් කඩන්න අමාරුයි.
- අවසානයේ අපට ලබා ගත හැකි විය පරමාණුක යෙදවුම්. පැරණි අනුවාදය සහ නව අනුවාදය අතර මාරුවීමේ කැපී පෙනෙන අදියරකින් තොරව, පරිශීලකයන් සඳහා එකවර සිදු වන යෙදවීම්.
නමුත් මේ සියල්ලේ අඩුපාඩු කිහිපයක් ද අපි දුටුවෙමු:
- නිෂ්පාදන පරිසරය, සංවර්ධන පරිසරයට අමතරව තවත් පරිසරයන් තිබේ. උදාහරණයක් ලෙස, qa සහ පූර්ව නිෂ්පාදනය. ඒ කාලේ අපිට සර්වර් ගොඩක් තිබුණා සේවා 60ක් විතර තිබුණා. මේ හේතුව නිසා එය අවශ්ය විය සෑම සේවාවක් සඳහාම, ඒ සඳහා නවතම අනුවාදය පවත්වා ගන්න අතථ්‍ය යන්ත්‍රය. එපමණක් නොව, ඔබට පුස්තකාල යාවත්කාලීන කිරීමට හෝ නව පරායත්තතා ස්ථාපනය කිරීමට අවශ්ය නම්, ඔබ මෙය සියලු පරිසරයන්හිදී කළ යුතුය. ඔබ ඔබේ යෙදුමේ මීළඟ නව අනුවාදය යෙදවීමට යන වේලාව devops අවශ්ය පරිසර සැකසුම් සිදු කරන වේලාව සමඟ සමමුහුර්ත කිරීමටද ඔබට අවශ්ය විය. මෙම අවස්ථාවේ දී, අපගේ පරිසරය එකවරම සියලු පරිසරයන් තුළ තරමක් වෙනස් වන තත්ත්වයකට පත්වීම පහසුය. උදාහරණයක් ලෙස, QA පරිසරයක පුස්තකාලවල සමහර අනුවාද ඇති අතර නිෂ්පාදන පරිසරයක විවිධ ඒවා ඇති අතර එය ගැටළු වලට තුඩු දෙනු ඇත.
- පරායත්තතා යාවත්කාලීන කිරීමේ දුෂ්කරතා ඔබගේ අයදුම්පත. එය ඔබ මත නොව, අනෙක් කණ්ඩායම මත රඳා පවතී. එනම්, සේවාදායකයන් නඩත්තු කරන devops කණ්ඩායමෙන්. ඔබ ඔවුන්ට සුදුසු කාර්යයක් සහ ඔබට කිරීමට අවශ්ය දේ පිළිබඳ විස්තරයක් ලබා දිය යුතුය.
- එකල අපටත් අවශ්ය වූයේ අප සතුව තිබූ විශාල විශාල ඒකලිත තව තවත් වැඩි වන බව අපට වැටහුණු නිසා වෙනම කුඩා සේවාවලට බෙදීමටය. ඒ වන විට අප සතුව ඒවායින් 100 කට වඩා තිබුණි. සෑම නව සේවාවක් සඳහාම වෙනම නව අථත්‍ය යන්ත්‍රයක් නිර්මාණය කිරීමට අවශ්ය විය, එය නඩත්තු කිරීමට සහ යෙදවීමටද අවශ්ය විය. ඊට අමතරව, ඔබට එක් මෝටර් රථයක් නොව, අවම වශයෙන් දෙකක් අවශ්ය වේ. මේ සියල්ලටම එකතු වන්නේ QA පරිසරයයි. මෙය ගැටළු ඇති කරන අතර ඔබට නව පද්ධති තැනීම සහ ධාවනය කිරීම වඩාත් අපහසු වේ. සංකීර්ණ, මිල අධික හා දිගු ක්රියාවලිය.
එමනිසා, සාමාන්‍ය අතථ්‍ය යන්ත්‍ර යෙදවීමේ සිට අපගේ යෙදුම් ඩොකර් කන්ටේනරයක යෙදවීම දක්වා ගමන් කිරීම වඩාත් පහසු වනු ඇතැයි අපි තීරණය කළෙමු. ඔබට ඩොකර් තිබේ නම්, ඔබට කන්ටේනරයක් එසවිය නොහැකි බැවින්, පොකුරක් තුළ යෙදුම ක්‍රියාත්මක කළ හැකි පද්ධතියක් ඔබට අවශ්ය වේ. සාමාන්‍යයෙන් ඔබට අවශ්ය වන්නේ ඒවා ස්වයංක්‍රීයව ඔසවන පරිදි කන්ටේනර් කීයක් ඔසවන්නේද යන්න නිරීක්ෂණය කිරීමයි. මෙම හේතුව නිසා, අපට පාලන පද්ධතියක් තෝරා ගැනීමට අවශ්ය විය.
අපි බොහෝ වේලාවක් කල්පනා කළේ කුමන එකක් ගත හැකිද යන්නයි. කාරණය නම්, ඒ වන විට සාමාන්‍ය අතථ්‍ය සේවාදායකයන්හි මෙම යෙදවුම් තොගය තරමක් යල්පැන ගොස් ඇති අතර, ඒවා සතුව මෙහෙයුම් පද්ධතිවල නවතම අනුවාදයන් නොතිබුණි. යම් අවස්ථාවක දී, FreeBSD පවා තිබුණි, එය සහය දැක්වීමට එතරම් පහසු නොවීය. හැකි ඉක්මනින් ඩොකර් වෙත සංක්රමණය වීමට අවශ්ය බව අපි තේරුම් ගත්තෙමු. අපගේ devops විවිධ විසඳුම් සමඟ ඔවුන්ගේ පවතින අත්දැකීම් දෙස බලා Nomad වැනි පද්ධතියක් තෝරා ගත්තේය.
Nomad වෙත මාරු වන්න
Nomad යනු HashiCorp හි නිෂ්පාදනයකි. ඒවා වෙනත් විසඳුම් සඳහා ද ප්‍රසිද්ධය:
"කොන්සල්" සේවා සොයාගැනීම සඳහා මෙවලමකි.
"ටෙරාෆෝම්" - ඊනියා යටිතල පහසුකම්-කේතය ලෙස හැඳින්වෙන වින්‍යාසය හරහා ඒවා වින්යාස කිරීමට ඔබට ඉඩ සලසන සේවාදායකයන් කළමනාකරණය කිරීමේ පද්ධතියකි.
"වැග්‍රන්ට්" විශේෂිත වින්යාස ගොනු හරහා අථත්‍ය යන්ත්‍ර දේශීයව හෝ වලාකුළෙහි යෙදවීමට ඔබට ඉඩ සලසයි.
එකල නෝමැඩ් සමස්ත යටිතල පහසුකම් වෙනස් නොකර ඉක්මනින් මාරු කළ හැකි තරමක් සරල විසඳුමක් ලෙස පෙනුණි. ඊට අමතරව, එය ඉගෙන ගැනීම තරමක් පහසුය. ඒකයි අපි අපේ කන්ටේනරය සඳහා පෙරීමේ පද්ධතිය ලෙස එය තෝරා ගත්තේ.
Nomad වෙත ඔබේ පද්ධතිය යෙදවීමට ඔබට අවශ්ය කුමක්ද?
- මුලින්ම ඔබට අවශ්යයි ඩොකර් රූපය ඔබගේ අයදුම්පත. ඔබ එය ගොඩනඟා එය ඩොකර් රූප ගබඩාවේ තැබිය යුතුය. අපගේ නඩුවේදී, මෙය කෘතිමවකි - විවිධ වර්ගවල විවිධ කෞතුක වස්තු එයට තල්ලු කිරීමට ඔබට ඉඩ සලසන පද්ධතියකි. එයට ලේඛනාගාර, ඩොකර් රූප, රචනා PHP පැකේජ, NPM පැකේජ ආදිය ගබඩා කළ හැක.
- එසේම අවශ්ය වේ වින්යාස ගොනුව, ඔබට යෙදවීමට අවශ්ය කුමක්ද, කොතැනද සහ කුමන ප්‍රමාණයකින් නෝමාඩ්ට කියනු ඇත.
අපි නෝමාඩ් ගැන කතා කරන විට, එය එහි තොරතුරු ගොනු ආකෘතිය ලෙස HCL භාෂාව භාවිතා කරයි HashiCorp වින්යාස භාෂාව. මෙය Yaml හි සුපිරි කට්ටලයක් වන අතර එය ඔබගේ සේවාව Nomad කොන්දේසි වලින් විස්තර කිරීමට ඔබට ඉඩ සලසයි.
ඔබට යෙදවීමට අවශ්ය බහාලුම් ප්‍රමාණය පැවසීමට එය ඔබට ඉඩ සලසයි, යෙදවීමේදී ඒවාට විවිධ පරාමිති ලබා දිය යුත්තේ කුමන පින්තූර වලින්ද යන්න. මේ අනුව, ඔබ මෙම ගොනුව Nomad වෙත පෝෂණය කරන අතර, එය අනුව නිෂ්පාදනයට බහාලුම් දියත් කරයි.
අපගේ නඩුවේදී, එක් එක් සේවාව සඳහා පරම සමාන HCL ගොනු ලිවීම එතරම් පහසු නොවන බව අපි තේරුම් ගත්තෙමු, මන්ද බොහෝ සේවා ඇති අතර සමහර විට ඔබට ඒවා යාවත්කාලීන කිරීමට අවශ්ය වේ. එය සිදු වන්නේ එක් සේවාවක් එක් අවස්ථාවකදී නොව, විවිධාකාරයේ විවිධාකාරයෙන් යොදවා ඇති බවයි. උදාහරණයක් ලෙස, නිෂ්පාදනයේ අප සතුව ඇති එක් පද්ධතියක් නිෂ්පාදනයේ අවස්ථා 100 කට වඩා තිබේ. ඒවා එකම පින්තූර වලින් ධාවනය වන නමුත් වින්යාස සැකසුම් සහ වින්යාස ගොනු වල වෙනස් වේ.
එබැවින්, එක් පොදු ගබඩාවක යෙදවීම සඳහා අපගේ සියලුම වින්යාස ගොනු ගබඩා කිරීම පහසු බව අපි තීරණය කළෙමු. මේ ආකාරයෙන් ඒවා දෘශ්‍යමාන විය: ඒවා නඩත්තු කිරීමට පහසු වූ අතර අප සතුව ඇති පද්ධති මොනවාදැයි අපට දැකගත හැකිය. අවශ්ය නම්, යමක් යාවත්කාලීන කිරීම හෝ වෙනස් කිරීම ද පහසුය. නව පද්ධතියක් එකතු කිරීම ද අපහසු නැත - ඔබට නව නාමාවලිය තුළ වින්යාස ගොනුවක් සෑදිය යුතුය. එහි ඇතුළත පහත ලිපිගොනු ඇත: service.hcl, අපගේ සේවාව පිළිබඳ විස්තරයක් අඩංගු වන අතර, නිෂ්පාදනයේ යෙදී සිටින මෙම සේවාවම වින්යාස කිරීමට ඉඩ සලසන සමහර env ගොනු.
කෙසේ වෙතත්, අපගේ සමහර පද්ධති නිෂ්පාදනයේ යොදවා ඇත්තේ එක් පිටපතක නොව, එකවර කිහිපයක ය. එබැවින්, වින්‍යාසයන් ඒවායේ පිරිසිදු ස්වරූපයෙන් නොව ඒවායේ සැකිලි ආකෘතියෙන් ගබඩා කිරීම අපට පහසු යැයි අපි තීරණය කළෙමු. ඒ වගේම අපි තෝරා ගත්තා ජිංජා 2. මෙම ආකෘතිය තුළ, අපි සේවාවේ වින්යාස සහ එයට අවශ්ය env ගොනු දෙකම ගබඩා කරමු.
ඊට අමතරව, අපි සියලු ව්‍යාපෘති සඳහා පොදු යෙදවුම් ස්ක්‍රිප්ට් එකක් ගබඩාවේ තබා ඇති අතර, එමඟින් ඔබේ සේවාව නිෂ්පාදනයට, අපේක්ෂිත පරිසරයට, අපේක්ෂිත ඉලක්කයට දියත් කිරීමට සහ යෙදවීමට ඔබට ඉඩ සලසයි. අපි අපේ HCL වින්‍යාසය අච්චුවක් බවට පත් කළ විට, කලින් සාමාන්‍ය Nomad වින්‍යාසයක් වූ HCL ගොනුව මේ අවස්ථාවේ දී ටිකක් වෙනස් ලෙස පෙනෙන්නට පටන් ගත්තේය.
එනම්, අපි සමහර වින්යාස ස්ථාන විචල්‍යයන් env ගොනු හෝ වෙනත් මූලාශ්‍රවලින් ලබාගත් ඇතුළු කළ විචල්‍ය සමඟ ප්‍රතිස්ථාපනය කළෙමු. මීට අමතරව, අපට HCL ගොනු ගතිකව එකතු කිරීමට අවස්ථාව ලැබුණි, එනම් අපට සාමාන්‍ය විචල්‍ය ඇතුළත් කිරීම් පමණක් භාවිතා කළ හැකිය. jinja ලූප සහ කොන්දේසි සඳහා සහය දක්වන බැවින්, ඔබට එහි වින්යාස ගොනු සෑදිය හැක, එය ඔබ හරියටම ඔබේ යෙදුම් යොදවන ස්ථානය අනුව වෙනස් වේ.
උදාහරණයක් ලෙස, ඔබට ඔබේ සේවාව පූර්ව නිෂ්පාදන සහ නිෂ්පාදනය සඳහා යෙදවීමට අවශ්ය වේ. පෙර-නිෂ්පාදනයේදී ඔබට ක්‍රෝන් ස්ක්‍රිප්ට් ධාවනය කිරීමට අවශ්ය නැත, නමුත් එය ක්‍රියාත්මක වන බව සහතික කර ගැනීම සඳහා සේවාව වෙනම වසමක දැකීමට අවශ්ය බව අපි කියමු. සේවාව යොදවන ඕනෑම කෙනෙකුට, ක්රියාවලිය ඉතා සරල හා විනිවිද පෙනෙන ලෙස පෙනේ. ඔබට අවශ්ය වන්නේ deploy.sh ගොනුව ක්‍රියාත්මක කිරීම පමණි, ඔබට යෙදවීමට අවශ්ය සේවාව සහ කුමන ඉලක්කයටද යන්න සඳහන් කරන්න. උදාහරණයක් ලෙස, ඔබට රුසියාව, බෙලරුස් හෝ කසකස්තානය වෙත යම් පද්ධතියක් යෙදවීමට අවශ්ය වේ. මෙය සිදු කිරීම සඳහා, එක් පරාමිතියක් වෙනස් කරන්න, එවිට ඔබට නිවැරදි මානකරන ගොනුව ලැබෙනු ඇත.
Nomad සේවාව දැනටමත් ඔබේ පොකුරට යොදවා ඇති විට, එය මේ ආකාරයෙන් පෙනේ.
පළමුව, ඔබට පිටත යම් ආකාරයක සමතුලිතයක් අවශ්ය වේ, එමඟින් සියලුම පරිශීලක ගමනාගමනය ලැබෙනු ඇත. එය කොන්සල් සමඟ එක්ව ක්රියා කරන අතර විශේෂිත වසම් නාමයකට අනුරූප වන විශේෂිත සේවාවක් පිහිටා ඇත්තේ කොතැනද, කුමන නෝඩයේ, කුමන IP ලිපිනයේද යන්න එයින් සොයා ගනු ඇත. කොන්සල් හි සේවාවන් නෝමාඩ් වෙතින්ම පැමිණේ. මේවා එකම සමාගමක නිෂ්පාදන බැවින් ඒවා එකිනෙකට බෙහෙවින් සම්බන්ධයි. Nomad out of the box එහි දියත් කරන ලද සියලුම සේවාවන් කොන්සල් තුළ ලියාපදිංචි කළ හැකි බව අපට පැවසිය හැකිය.
ඔබේ ඉදිරිපස පැටවුම් සමතුලිතය ගමනාගමනය යැවිය යුත්තේ කුමන සේවාවටදැයි දැනගත් පසු, එය ඔබේ යෙදුමට ගැලපෙන සුදුසු බහාලුම් හෝ බහු බහාලුම් වෙත එය යොමු කරයි. ස්වාභාවිකවම, ආරක්ෂාව ගැන සිතීම ද අවශ්ය වේ. සියලුම සේවාවන් බහාලුම්වල එකම අතථ්‍ය යන්ත්‍ර මත ක්‍රියාත්මක වුවද, මෙය සාමාන්‍යයෙන් ඕනෑම සේවාවකින් වෙනත් ඕනෑම සේවාවකට නොමිලේ ප්රවේශ වීම වැළැක්වීම අවශ්ය වේ. අපි මෙය සාක්ෂාත් කර ගත්තේ ඛණ්ඩනය කිරීමෙනි. සෑම සේවාවක්ම තමන්ගේම අතථ්‍ය ජාලයක් තුළ දියත් කරන ලද අතර, වෙනත් පද්ධති සහ සේවාවන් වෙත ප්රවේශ වීමට/ප්‍රතික්ෂේප කිරීම සඳහා මාර්ගගත කිරීමේ නීති සහ රීති නියම කර ඇත. ඒවා මෙම පොකුර ඇතුළත සහ ඉන් පිටත ස්ථානගත කළ හැකිය. උදාහරණයක් ලෙස, ඔබට විශේෂිත දත්ත සමුදායකට සම්බන්ධ වීමෙන් සේවාවක් වැලැක්වීමට අවශ්ය නම්, මෙය ජාල මට්ටමේ ඛණ්ඩනය හරහා සිදු කළ හැක. එනම්, වැරදීමකින් වුවද, ඔබට පරීක්ෂණ පරිසරයේ සිට ඔබේ නිෂ්පාදන දත්ත ගබඩාවට අහම්බෙන් සම්බන්ධ විය නොහැක.
මානව සම්පත සම්බන්ධයෙන් අපට සංක්‍රමණයට කොපමණ මුදලක් වැය වේද?
සමස්ත සමාගම Nomad වෙත මාරුවීමට ආසන්න වශයෙන් මාස 5-6 ක් ගත විය. අපි සේවයෙන් සේවා පදනමින්, නමුත් තරමක් වේගවත් වේගයකින් ගමන් කළෙමු. සෑම කණ්ඩායමකටම සේවා සඳහා තමන්ගේම බහාලුම් නිර්මාණය කිරීමට සිදු විය.
අපි එවැනි ප්‍රවේශයක් අනුගමනය කර ඇති අතර සෑම කණ්ඩායමක්ම ඔවුන්ගේ පද්ධතිවල ඩොකර් රූප සඳහා ස්වාධීනව වගකිව යුතුය. DevOps යෙදවීම සඳහා අවශ්ය සාමාන්‍ය යටිතල පහසුකම් සපයයි, එනම් පොකුරු සඳහාම සහය, CI පද්ධතිය සඳහා සහය යනාදිය. ඒ වන විට අපට පද්ධති 60 කට වඩා වැඩි ප්‍රමාණයක් නෝමාඩ් වෙත ගෙන ගිය අතර එය බහාලුම් දෙදහසක් පමණ විය.
යෙදවීම සහ සේවාදායක සම්බන්ධ සෑම දෙයකම සාමාන්‍ය යටිතල පහසුකම් සඳහා Devops වගකිව යුතුය. සෑම සංවර්ධන කණ්ඩායමක්ම, එහි නිශ්චිත පද්ධතිය සඳහා බහාලුම් ක්‍රියාත්මක කිරීම සඳහා වගකිව යුතුය, මන්ද එය විශේෂිත බහාලුමක සාමාන්‍යයෙන් අවශ්ය දේ දන්නා කණ්ඩායමයි.
Nomad අත්හැරීමට හේතු
Nomad සහ docker භාවිතා කරමින් යෙදවීම වෙත මාරු වීමෙන් අපට ලැබුණු වාසි මොනවාද?
- අපි සමාන කොන්දේසි සපයා ඇත සියලු පරිසරයන් සඳහා. සංවර්ධනයේදී, QA පරිසරය, පූර්ව නිෂ්පාදන, නිෂ්පාදනය, එකම බහාලුම් රූප භාවිතා කරනු ලැබේ, එකම පරායත්තතාවයන් සමඟ. ඒ අනුව, නිෂ්පාදනයෙන් අවසන් වන්නේ ඔබ කලින් දේශීයව හෝ ඔබේ පරීක්ෂණ පරිසරය තුළ පරීක්ෂා කළ දේ නොවන බවට ඔබට කිසිදු අවස්ථාවක් නැත.
- එය ප්‍රමාණවත් බව අපට ද පෙනී ගියේය නව සේවාවක් එකතු කිරීම පහසුය. යෙදවීමේ දෘෂ්ටි කෝණයෙන්, ඕනෑම නව පද්ධතියක් ඉතා සරලව දියත් කරනු ලැබේ. වින්යාස ගබඩා කරන ගබඩාව වෙත ගොස්, එහි ඔබේ පද්ධතිය සඳහා තවත් වින්‍යාසයක් එක් කරන්න, එවිට ඔබ සියල්ල සූදානම් කර ඇත. devops වෙතින් කිසිදු අමතර උත්සාහයකින් තොරව ඔබට ඔබේ පද්ධතිය නිෂ්පාදනය සඳහා යෙදවිය හැක.
- සියලු වින්යාස ගොනු එක් පොදු ගබඩාවක සමාලෝචනයට ලක්ව ඇති බව පෙනී ගියේය. අපි අතථ්‍ය සේවාදායකයන් භාවිතයෙන් අපගේ පද්ධති යෙදවූ අවස්ථාවේදී, අපි වින්‍යාසය එකම ගබඩාවේ තිබූ ඇන්සිබල් භාවිතා කළෙමු. කෙසේ වෙතත්, බොහෝ සංවර්ධකයින් සඳහා මෙය වැඩ කිරීමට ටිකක් අපහසු විය. මෙහිදී ඔබට සේවාව යෙදවීමට එක් කළ යුතු වින්යාස සහ කේත පරිමාව බෙහෙවින් කුඩා වී ඇත. ඊට අමතරව, එය නිවැරදි කිරීමට හෝ වෙනස් කිරීමට devops සඳහා ඉතා පහසු වේ. සංක්‍රාන්ති වලදී, උදාහරණයක් ලෙස, Nomad හි නව අනුවාදයකට, ඔවුන්ට එකම ස්ථානයේ පිහිටා ඇති සියලුම මෙහෙයුම් ගොනු ගෙන ගොස් තොග වශයෙන් යාවත්කාලීන කළ හැකිය.
නමුත් අපට අවාසි කිහිපයක් ද හමු විය:
අපි බව පෙනී ගියේය බාධාවකින් තොරව යෙදවීම් ලබා ගැනීමට නොහැකි විය Nomad නඩුවේ. විවිධ තත්වයන් යටතේ බහාලුම් පෙරළන විට, එය ක්‍රියාත්මක විය හැකි අතර, නෝමාඩ් එය ගමනාගමනය ලබා ගැනීමට සූදානම් බහාලුමක් ලෙස වටහා ගත්තේය. මෙය සිදු වූයේ එහි ඇතුළත යෙදුම දියත් කිරීමට පවා අවස්ථාවක් ලැබීමට පෙරය. මේ හේතුව නිසා, පද්ධතිය කෙටි කාලයක් සඳහා දෝෂ 500 ක් නිපදවීමට පටන් ගත්තේය, මන්ද එය තවමත් පිළිගැනීමට සූදානම් නැති කන්ටේනරයකට ගමනාගමනය ආරම්භ විය.
අපට සමහරක් හමු විය දෝෂ. වඩාත්ම වැදගත් දෝෂය නම්, ඔබට බොහෝ පද්ධති සහ බහාලුම් තිබේ නම්, නෝමාඩ් විශාල පොකුරක් ඉතා හොඳින් හසුරුවන්නේ නැත. නෝමැඩ් පොකුරේ ඇතුළත් කර ඇති සර්වර් එකක් නඩත්තුව සඳහා පිටතට ගැනීමට ඔබට අවශ්ය වූ විට, පොකුර ඉතා හොඳ යැයි හැඟෙන්නේ නැති අතර එය කඩා වැටීමට තරමක් ඉහළ සම්භාවිතාවක් ඇත. සමහර බහාලුම්, උදාහරණයක් ලෙස, වැටීමට හා නොනැසී පවතිනු ඇත - ඔබගේ සියලුම නිෂ්පාදන පද්ධති නෝමාඩ් විසින් කළමනාකරණය කරන ලද පොකුරක් තුළ පිහිටා තිබේ නම් මෙය ඔබට පසුව බොහෝ වියදම් වනු ඇත.
ඒ නිසා අපි ඊළඟට යා යුත්තේ කොතැනටදැයි සිතා බැලීමට තීරණය කළෙමු. එම අවස්ථාවේදී, අපට සාක්ෂාත් කර ගැනීමට අවශ්ය දේ පිළිබඳව අපි වඩාත් දැනුවත් විය. එනම්: අපට විශ්වාසනීයත්වය, Nomad සපයනවාට වඩා ටිකක් වැඩි කාර්යයන් සහ වඩාත් පරිණත, වඩා ස්ථාවර පද්ධතියක් අවශ්යයි.
මේ සම්බන්ධයෙන්, අපගේ තේරීම පොකුරු දියත් කිරීම සඳහා වඩාත් ජනප්‍රිය වේදිකාව ලෙස Kubernetes මත වැටුණි. විශේෂයෙන්ම අපගේ බහාලුම්වල ප්‍රමාණය සහ ප්‍රමාණය ප්‍රමාණවත් තරම් විශාල විය. එවැනි අරමුණු සඳහා, Kubernetes අපට බැලිය හැකි වඩාත්ම සුදුසු පද්ධතිය බව පෙනෙන්නට තිබුණි.
Kubernetes වෙත සංක්රමණය
Kubernetes හි මූලික සංකල්ප සහ ඒවා Nomad වෙතින් වෙනස් වන ආකාරය ගැන මම ඔබට ටිකක් කියන්නම්.
පළමුවෙන්ම, Kubernetes හි වඩාත් මූලික සංකල්පය වන්නේ පොඩ් සංකල්පයයි. පොඩ් සෑම විටම එකට ධාවනය වන බහාලුම් එකක හෝ කිහිපයක සමූහයකි. තවද ඔවුන් සෑම විටම එක අතථ්‍ය යන්ත්‍රයක දැඩි ලෙස ක්රියා කරයි. විවිධ වරායන් මත IP 127.0.0.1 හරහා ඒවා එකිනෙකට ප්රවේශ විය හැකිය.
ඔබ සතුව nginx සහ php-fpm - සම්භාව්‍ය යෝජනා ක්‍රමය අඩංගු PHP යෙදුමක් ඇතැයි උපකල්පනය කරමු. බොහෝ දුරට, ඔබට nginx සහ php-fpm බහාලුම් දෙකම සෑම විටම එකට තබා ගැනීමට අවශ්ය වනු ඇත. Kubernetes ඔබට එක් පොදු පොඩ් එකක් ලෙස විස්තර කිරීමෙන් මෙය සාක්ෂාත් කර ගැනීමට ඉඩ සලසයි. නෝමාඩ් සමඟ අපට ලබා ගත නොහැකි වූයේ මෙයයි.
දෙවන සංකල්පය වන්නේ යෙදවීම. කාරණය නම් කරල් යනු තාවකාලික දෙයක් වන අතර එය ආරම්භ වී නැති වී යයි. ඔබට අවශ්ය වන්නේ ඔබේ පෙර තිබූ සියලුම බහාලුම් ප්‍රථමයෙන් විනාශ කර, පසුව නව අනුවාද එකවර දියත් කිරීමටද, නැතහොත් ඔබට ඒවා ක්‍රමානුකූලව පෙරළීමට අවශ්‍යද?මෙය යෙදවීමේ සංකල්පය වගකිව යුතු ක්‍රියාවලියයි. එය ඔබ ඔබේ කරල් යොදවන ආකාරය, කුමන ප්‍රමාණයකින් සහ ඒවා යාවත්කාලීන කරන්නේ කෙසේද යන්න විස්තර කරයි.
තුන්වන සංකල්පය වන්නේ සේවාව. ඔබේ සේවාව ඇත්ත වශයෙන්ම ඔබේ පද්ධතිය වන අතර, එය යම් තදබදයක් ලබා ගන්නා අතර පසුව එය ඔබේ සේවාවට අනුරූප පොඩ් එකකට හෝ වැඩි ගණනකට යොමු කරයි. එනම්, එවැනි සහ එවැනි නමක් සහිත එවැනි සේවාවක් වෙත පැමිණෙන සියලුම රථවාහන මෙම විශේෂිත කරල් වෙත යැවිය යුතු බව පැවසීමට එය ඔබට ඉඩ සලසයි. ඒ සමඟම එය ඔබට රථවාහන තුලනය සපයයි. එනම්, ඔබට ඔබේ යෙදුමේ කරල් දෙකක් දියත් කළ හැකි අතර, පැමිණෙන සියලුම ගමනාගමනය මෙම සේවාවට අදාළ කරල් අතර ඒකාකාරව සමතුලිත වනු ඇත.
සහ හතරවන මූලික සංකල්පය වේ ආක්රමණය. මෙය Kubernetes පොකුරක් මත ක්‍රියාත්මක වන සේවාවකි. එය සියලුම ඉල්ලීම් භාර ගන්නා බාහිර පැටවුම් ශේෂයක් ලෙස ක්රියා කරයි. Kubernetes API භාවිතයෙන්, Ingress මෙම ඉල්ලීම් යැවිය යුත්තේ කොතැනටද යන්න තීරණය කළ හැක. එපමණක්ද නොව, ඔහු මෙය ඉතා නම්යශීලී ලෙස කරයි. මෙම ධාරකයට වන සියලුම ඉල්ලීම් සහ එවැනි සහ එවැනි URL මෙම සේවාව වෙත යවන බව ඔබට පැවසිය හැකිය. තවද මෙම සත්කාරකයට සහ වෙනත් URL වෙත පැමිණෙන මෙම ඉල්ලීම් වෙනත් සේවාවකට යවනු ලැබේ.
යෙදුමක් සංවර්ධනය කරන කෙනෙකුගේ දෘෂ්ටි කෝණයෙන් සිසිල්ම දෙය නම් ඔබට ඒ සියල්ල ඔබම කළමනාකරණය කළ හැකි වීමයි. Ingress වින්‍යාසය සැකසීමෙන්, ඔබට එවැනි සහ එවැනි API වෙත පැමිණෙන සියලුම මාර්ග තදබදය ලියා ඇති වෙනම බහාලුම් වෙත යැවිය හැකිය, උදාහරණයක් ලෙස, Go හි. නමුත් මෙම තදබදය, එම වසම වෙත පැමිණෙන නමුත් වෙනත් URL එකකට, PHP වලින් ලියා ඇති බහාලුම් වෙත යැවිය යුතුය, එහිදී තර්ක ගොඩක් ඇත, නමුත් ඒවා ඉතා වේගවත් නොවේ.
අපි මේ සියලු සංකල්ප Nomad සමඟ සංසන්දනය කළහොත්, පළමු සංකල්ප තුනම එකට සේවය කරන බව අපට පැවසිය හැකිය. අවසාන සංකල්පය Nomad තුළම නොමැත. අපි එය ලෙස බාහිර සමතුලිතයක් භාවිතා කළෙමු: එය haproxy, nginx, nginx+, සහ යනාදිය විය හැකිය. ඝනකයක් සම්බන්ධයෙන්, ඔබට මෙම අතිරේක සංකල්පය වෙන වෙනම හඳුන්වා දීමට අවශ්ය නොවේ. කෙසේ වෙතත්, ඔබ Ingress අභ්‍යන්තරව බැලුවහොත්, එය nginx, haproxy, හෝ traefik වේ, නමුත් Kubernetes තුළ ගොඩනගා ඇත.
මා විස්තර කළ සියලුම සංකල්ප, ඇත්ත වශයෙන්ම, Kubernetes පොකුරක් තුළ පවතින සම්පත් වේ. ඝනකයේ ඒවා විස්තර කිරීම සඳහා, yaml ආකෘතියක් භාවිතා කරනු ලැබේ, එය Nomad හි HCL ගොනු වලට වඩා කියවිය හැකි සහ හුරුපුරුදුය. නමුත් ව්‍යුහාත්මකව, උදාහරණයක් ලෙස, පොඩ් සම්බන්ධයෙන් ඔවුන් එකම දේ විස්තර කරයි. ඔවුන් පවසන්නේ - මට එවැනි සහ එවැනි කරල්, එවැනි සහ එවැනි රූප සහිත, එවැනි සහ එවැනි ප්‍රමාණවලින් එහි යෙදවීමට අවශ්යයි.
ඊට අමතරව, එක් එක් තනි සම්පත අතින් නිර්මාණය කිරීමට අපට අවශ්ය නැති බව අපි තේරුම් ගත්තෙමු: යෙදවීම, සේවා, ඇතුල්වීම, ආදිය. ඒ වෙනුවට, අපට අවශ්ය සියලු සම්පත් පරායත්තතා නිවැරදි අනුපිළිවෙලින් අතින් ප්‍රතිනිර්මාණය කිරීමට සිදු නොවන පරිදි, යෙදවීමේදී අපගේ එක් එක් පද්ධතිය Kubernetes අනුව විස්තර කිරීමට අවශ්ය විය. මෙය සිදු කිරීමට අපට ඉඩ සලසන පද්ධතිය ලෙස හෙල්ම් තෝරා ගන්නා ලදී.
හෙල්ම් හි මූලික සංකල්ප
හෙල්ම් ය පැකේජ කළමනාකරු Kubernetes සඳහා. ක්‍රමලේඛන භාෂා වල පැකේජ කළමනාකරුවන් ක්රියා කරන ආකාරය හා සමාන වේ. උදාහරණයක් ලෙස, deployment nginx, deployment php-fpm, Ingress සඳහා config, configmaps (මෙය ඔබේ පද්ධතිය සඳහා env සහ වෙනත් පරාමිති සැකසීමට ඔබට ඉඩ සලසන ආයතනයකි) වැනි ආකාරයේ සේවාවක් ගබඩා කිරීමට ඒවා ඔබට ඉඩ සලසයි. ප්‍රස්ථාර ලෙස හැඳින්වේ. ඒ සමගම හෙල්ම් Kubernetes මුදුනේ දිව යයි. එනම්, මෙය පසෙකට වී සිටින යම් ආකාරයක පද්ධතියක් නොව, කියුබ් තුළ දියත් කරන ලද තවත් සේවාවක් පමණි. ඔබ කොන්සෝල විධානයක් හරහා එහි API හරහා එය සමඟ අන්තර් ක්රියා කරයි. එහි පහසුව සහ අලංකාරය නම් හෙල්ම් එක කැඩී ගියත් හෝ ඔබ එය පොකුරෙන් ඉවත් කළත්, ඔබේ සේවාවන් අතුරුදහන් නොවනු ඇත, මන්ද හෙල්ම් අත්‍යවශ්‍යයෙන්ම පද්ධතිය ආරම්භ කිරීමට පමණක් සේවය කරයි. Kubernetes විසින්ම පසුව කාර්ය සාධනය සහ සේවා තත්ත්වය සඳහා වගකිව යුතුය.
ඒක අපිටත් තේරුණා සැකිලිකරණය, අපගේ වින්‍යාසය තුළට jinja හඳුන්වා දීමෙන් අපට පෙර අප විසින්ම කිරීමට බල කරන ලද, එය හෙල්ම් හි ප්‍රධාන ලක්ෂණ වලින් එකකි. ඔබ ඔබේ පද්ධති සඳහා නිර්මාණය කරන සියලුම වින්‍යාසයන් ජිංජා වලට ටිකක් සමාන සැකිලි ආකාරයෙන් සුක්කානම තුළ ගබඩා කර ඇත, නමුත් ඇත්ත වශයෙන්ම, කුබර්නෙටස් වැනි හෙල්ම් ලියා ඇති Go භාෂාවේ සැකිලි භාවිතා කරයි.
හෙල්ම් අප වෙනුවෙන් තවත් සංකල්ප කිහිපයක් එකතු කරයි.
සටහන - මෙය ඔබගේ සේවාව පිළිබඳ විස්තරයකි. වෙනත් පැකේජ කළමණාකරුවන් තුළ එය පැකේජයක්, බණ්ඩල් හෝ ඒ හා සමාන දෙයක් ලෙස හැඳින්වේ. මෙන්න එය ප්රස්ථාරය ලෙස හැඳින්වේ.
වටිනාකම් සැකිලි වලින් ඔබේ වින්‍යාසය ගොඩනැගීමට ඔබට භාවිතා කිරීමට අවශ්ය විචල්‍ය වේ.
නිකුතු. හෙල්ම් භාවිතයෙන් යොදවා ඇති සෑම අවස්ථාවකම නිකුත් කිරීමේ වර්ධක අනුවාදයක් ලැබේ. පෙර නිකුතුවේ සේවා වින්‍යාසය කුමක්ද, ඊට පෙර නිකුත් කිරීම සහ යනාදිය හෙල්ම්ට මතකයි. එබැවින්, ඔබට ආපසු හැරවීමට අවශ්ය නම්, එය පෙර නිකුතු අනුවාදයට යොමු කරමින් helm callback විධානය ක්‍රියාත්මක කරන්න. ඔබගේ ගබඩාවේ අනුරූප වින්‍යාසය ආපසු හැරවීමේ අවස්ථාවේදී නොතිබුණද, හෙල්ම් තවමත් එය කුමක්දැයි මතක තබා ගන්නා අතර ඔබේ පද්ධතිය පෙර නිකුතුවේ තිබූ තත්වයට ආපසු හරවයි.
අපි හෙල්ම් භාවිතා කරන විට, Kubernetes සඳහා වන සාමාන්‍ය වින්‍යාසයන් ද විචල්‍යයන්, ශ්‍රිතයන් භාවිතා කිරීමට සහ කොන්දේසි සහිත ප්‍රකාශ යෙදීමට හැකි සැකිලි බවට පත්වේ. මේ ආකාරයෙන් ඔබට පරිසරය අනුව ඔබේ සේවා වින්‍යාසය එකතු කර ගත හැකිය.
ප්‍රායෝගිකව, අපි Nomad සමඟ කළාට වඩා ටිකක් වෙනස් දේවල් කිරීමට තීරණය කළා. Nomad හි අපගේ සේවාව යෙදවීමට අවශ්ය deployment configs සහ n-variables දෙකම එක් ගබඩාවක ගබඩා කර තිබුනේ නම්, මෙහිදී අපි ඒවා වෙනම repositories දෙකකට බෙදීමට තීරණය කළෙමු. "deploy" repository ගබඩා කරන්නේ යෙදවීම සඳහා අවශ්ය n-විචල්‍ය පමණක් වන අතර "helm" ගබඩාව configs හෝ charts ගබඩා කරයි.
මෙය අපට ලබා දුන්නේ කුමක්ද?
අපි වින්යාස ගොනු තුළම සැබවින්ම සංවේදී දත්ත කිසිවක් ගබඩා නොකරමු. උදාහරණයක් ලෙස, දත්ත සමුදායන් සඳහා මුරපද. ඒවා Kubernetes හි රහස් ලෙස ගබඩා කර ඇත, නමුත් කෙසේ වෙතත්, සෑම කෙනෙකුටම ප්රවේශය ලබා දීමට අපට අවශ්ය නැති යම් යම් දේවල් තවමත් තිබේ. එබැවින්, "ඩිප්ලෝයි" නිධිය වෙත ප්රවේශය වඩාත් සීමිත වන අතර, "හෙල්ම්" නිධිය හුදෙක් සේවාව පිළිබඳ විස්තරයක් අඩංගු වේ. මෙම හේතුව නිසා, එය පුළුල් පරාසයක පුද්ගලයන් විසින් ආරක්ෂිතව ප්රවේශ විය හැක.
අපට නිෂ්පාදනය පමණක් නොව අනෙකුත් පරිසරයන් ද ඇති බැවින්, මෙම වෙන්වීමට ස්තූතිවන්ත වන්නට අපට අපගේ හෙල්ම් ප්‍රස්ථාර නිෂ්පාදනයට පමණක් නොව, උදාහරණයක් ලෙස QA පරිසරයකට සේවා යෙදවීමට නැවත භාවිතා කළ හැකිය. ඒවා දේශීයව භාවිතා කිරීමට පවා මිනිකුබ් - මෙය Kubernetes දේශීයව ධාවනය කිරීම සඳහා වූ දෙයකි.
එක් එක් ගබඩාව තුළ, අපි එක් එක් සේවාව සඳහා වෙනම නාමාවලි වලට බෙදීමක් තැබුවෙමු. එනම්, එක් එක් නාමාවලිය තුළ අදාළ ප්‍රස්ථාරයට අදාළ සැකිලි සහ අපගේ පද්ධතිය ක්‍රියාත්මක කිරීමට යෙදවිය යුතු සම්පත් විස්තර කරයි. අපි "deploy" ගබඩාවේ envs පමණක් ඉතිරි කර ඇත. මෙම අවස්ථාවෙහිදී, අපි jinja භාවිතයෙන් අච්චු ගැසීම භාවිතා නොකළෙමු, මන්ද helm විසින්ම පෙට්ටියෙන් පිටත අච්චු කිරීම සපයන බැවිනි - මෙය එහි ප්‍රධාන කාර්යයකි.
අපි යෙදවුම් ස්ක්‍රිප්ට් එකක් ඉතිරි කළෙමු - deploy.sh, එය හෙල්ම් භාවිතයෙන් යෙදවීම සඳහා දියත් කිරීම සරල කර ප්‍රමිතිකරණය කරයි. එබැවින්, යෙදවීමට අවශ්ය ඕනෑම කෙනෙකුට, යෙදවුම් අතුරුමුහුණත Nomad හරහා යෙදවීමේදී සිදු වූ ආකාරයටම පෙනේ. එම deploy.sh, ඔබේ සේවාවේ නම සහ ඔබට එය යෙදවීමට අවශ්ය ස්ථානය. මෙය හෙල්ම් අභ්‍යන්තරව ආරම්භ වීමට හේතු වේ. එය අනෙක් අතට, සැකිලි වලින් වින්යාස එකතු කරයි, අවශ්ය අගයන් ගොනු ඒවාට ඇතුළු කරයි, පසුව ඒවා යොදවා ඒවා කුබර්නෙටස් වෙත දියත් කරයි.
සොයා ගැනීම්
Kubernetes සේවාව Nomad වඩා සංකීර්ණ බව පෙනේ.
මෙන්න පිටතට යන ගමනාගමනය ඇතුල්වීම වෙත පැමිණේ. මෙය ඉදිරිපස පාලකය වන අතර, එය සියලු ඉල්ලීම් භාර ගන්නා අතර පසුව ඉල්ලීම් දත්ත වලට අනුරූප සේවාවන් වෙත ඒවා යවයි. එය ඔබගේ යෙදුමේ විස්තරයේ කොටසක් වන සහ සංවර්ධකයින් විසින්ම සකසා ඇති වින්යාස මත පදනම්ව ඒවා තීරණය කරයි. සේවාව එහි කරල් වෙත ඉල්ලීම් යවයි, එනම් විශේෂිත බහාලුම්, මෙම සේවාවට අයත් සියලුම බහාලුම් අතර එන ගමනාගමනය සමතුලිත කරයි. තවද, ඇත්ත වශයෙන්ම, අපි ජාල මට්ටමින් ආරක්ෂාවෙන් කොතැනකවත් නොයා යුතු බව අමතක නොකළ යුතුය. එබැවින්, ටැග් කිරීම මත පදනම් වූ කුබර්නෙටස් පොකුරක් තුළ ඛණ්ඩනය ක්රියා කරයි. පොකුර ඇතුළත හෝ ඉන් පිටත ඇතැම් බාහිර/අභ්‍යන්තර සම්පත් වෙත සේවාවන්හි ප්රවේශ අයිතිවාසිකම් සම්බන්ධ කර ඇති සියලුම සේවාවන්ට යම් ටැග් ඇත.
අපි සංක්රමණය කරන විට, අපි කලින් භාවිතා කළ Nomad හි සියලුම හැකියාවන් Kubernetes සතුව ඇති බව අපට දැකගත හැකි වූ අතර අලුත් දේවල් රාශියක්ද එකතු කරන ලදී. එය ප්ලගින හරහා සහ ඇත්ත වශයෙන්ම අභිරුචි සම්පත් වර්ග හරහා පුළුල් කළ හැක. එනම්, කුබර්නෙටස් සමඟ එන යමක් භාවිතා කිරීමට පමණක් නොව, ඔබේ සම්පත කියවන ඔබේම සම්පතක් සහ සේවාවක් නිර්මාණය කිරීමට ඔබට අවස්ථාව තිබේ. මෙය ඔබට Kubernetes නැවත ස්ථාපනය කිරීමකින් තොරව සහ වෙනස් කිරීම් අවශ්ය නොවී ඔබේ පද්ධතිය පුළුල් කිරීමට අමතර විකල්ප ලබා දෙයි.
එවැනි භාවිතයකට උදාහරණයක් වන්නේ අපගේ කුබර්නෙටස් පොකුර තුළ දිවෙන Prometheus ය. එය යම් සේවාවකින් ප්‍රමිතික එකතු කිරීම ආරම්භ කිරීම සඳහා, අපි සේවා විස්තරයට අමතර සම්පත් වර්ගයක්, ඊනියා සේවා මොනිටරය එකතු කළ යුතුය. Prometheus, Kubernetes හි දියත් කරන විට අභිරුචි සම්පත් වර්ගයක් කියවිය හැකි නිසා, ස්වයංක්‍රීයව නව පද්ධතියෙන් ප්‍රමිතික එකතු කිරීම ආරම්භ කරයි. එය තරමක් පහසු ය.
අපි Kubernetes වෙත පළමු යෙදවීම 2018 මාර්තු මාසයේදීය. ඒ වගේම මේ කාලය තුළ අපි කිසිවිටෙකත් එහි කිසිදු ගැටලුවකට මුහුණ දුන්නේ නැහැ. එය සැලකිය යුතු දෝෂ නොමැතිව තරමක් ස්ථාවර ලෙස ක්රියා කරයි. ඊට අමතරව, අපට එය තවදුරටත් පුළුල් කළ හැකිය. අද අපට එහි ඇති හැකියාවන් ප්‍රමාණවත් වන අතර, කුබර්නෙටේස් හි සංවර්ධනයේ වේගයට අපි ඇත්තෙන්ම කැමතියි. දැනට, කන්ටේනර් 3000කට වඩා වැඩි ප්‍රමාණයක් Kubernetes හි ඇත. පොකුර නෝඩ් කිහිපයක් අල්ලා ගනී. ඒ අතරම, එය සේවා කළ හැකි, ස්ථාවර සහ ඉතා පාලනය කළ හැකි ය.
මූලාශ්රය: www.habr.com