මෙම කතාව අපි නිෂ්පාදන පරිසරයක, විශේෂයෙන් Kubernetes තුළ බහාලුම් භාවිතා කරන ආකාරය ගැන ය. මෙම ලිපිය බහාලුම් වලින් මිනුම් සහ ලඝු-සටහන් එකතු කිරීම මෙන්ම රූප ගොඩනැගීම සඳහා කැප කර ඇත.

අපි B2B සහ B2C සඳහා අන්තර්ජාල වෙළඳාම සහ fintech නිෂ්පාදන සඳහා සේවා සංවර්ධනය කරන fintech සමාගම Exness වෙතින්. අපගේ R&D හි විවිධ කණ්ඩායම් ඇත, සංවර්ධන දෙපාර්තමේන්තුවට සේවකයින් 100+ ඇත.

අපි අපගේ සංවර්ධකයින්ට කේතය එකතු කර ධාවනය කිරීමට වේදිකාවට වගකිව යුතු කණ්ඩායම නියෝජනය කරන්නෙමු. විශේෂයෙන්, යෙදුම් වලින් ප්‍රමිතික, ලඝු-සටහන් සහ සිදුවීම් එකතු කිරීම, ගබඩා කිරීම සහ වාර්තා කිරීම සඳහා අප වගකිව යුතුය. අපි දැනට නිෂ්පාදන පරිසරයක ආසන්න වශයෙන් ඩොකර් බහාලුම් තුන්දහසක් ක්‍රියාත්මක කරන අතර, අපගේ TB 50 විශාල දත්ත ගබඩාව පවත්වා ගෙන යන අතර අපගේ යටිතල පහසුකම් වටා ගොඩනගා ඇති වාස්තු විද්‍යාත්මක විසඳුම් සපයන්නෙමු: Kubernetes, Rancher සහ විවිධ පොදු වලාකුළු සපයන්නන්. 

අපගේ අභිප්රේරණය

මොකක්ද පිච්චෙන්නේ? කිසිවෙකුට පිළිතුරු දිය නොහැක. උදුන කොහෙද? තේරුම් ගන්න අමාරුයි. එය ගිනි ගත්තේ කවදාද? ඔබට එය සොයාගත හැකිය, නමුත් වහාම නොවේ. 

සමහර කන්ටේනර් නැවතී ඇති අතර අනෙක් ඒවා වැටී ඇත්තේ ඇයි? කුමන කන්ටේනරයට දොස් පැවරිය යුතුද? සියල්ලට පසු, බහාලුම්වල පිටත සමාන වේ, නමුත් එක් එක් ඇතුළත තමන්ගේම නියෝ ඇත.

අපගේ සංවර්ධකයින් දක්ෂ පුද්ගලයින් ය. ඔවුන් සමාගමට ලාභයක් ගෙන දෙන හොඳ සේවාවන් සපයයි. නමුත් යෙදුම් සහිත බහාලුම් අයාලේ යන විට අසාර්ථක වීම් තිබේ. එක් බහාලුමක් අධික CPU පරිභෝජනය කරයි, තවත් එකක් ජාලය පරිභෝජනය කරයි, තුන්වැන්න I/O මෙහෙයුම් පරිභෝජනය කරයි, සහ සිව්වැන්න එය සොකට් වලින් කරන්නේ කුමක්ද යන්න සම්පූර්ණයෙන්ම අපැහැදිලි ය. ඒ සියල්ල වැටී නැව ගිලී යයි. 

නියෝජිතයන්

ඇතුළත සිදුවන්නේ කුමක්ද යන්න තේරුම් ගැනීමට, අපි නියෝජිතයන් සෘජුවම බහාලුම්වල තැබීමට තීරණය කළෙමු.

මෙම නියෝජිතයන් කන්ටේනර් එකිනෙක නොකැඩෙන තත්ත්වයක තබා ගන්නා වැඩසටහන් වළක්වයි. නියෝජිතයන් ප්‍රමිතිගත කර ඇති අතර, මෙමගින් බහාලුම් සේවා සැපයීම සඳහා ප්‍රමිතිගත ප්‍රවේශයකට ඉඩ සලසයි. 

අපගේ නඩුවේදී, නියෝජිතයින් විසින් ලොගයන් සම්මත ආකෘතියකින්, ටැග් කර සහ තෙරපුම් කළ යුතුය. ඔවුන් අපට ව්‍යාපාරික යෙදුම් ඉදිරිදර්ශනයකින් විස්තීරණය කළ හැකි ප්‍රමිතිගත මිනුම් ද ලබා දිය යුතුය.

නියෝජිතයන් යනු විවිධ රූපවලට (ඩේබියන්, ඇල්පයින්, සෙන්ටෝස්, ආදිය) සහාය දක්වන විවිධ වාද්‍ය වෘන්ද පද්ධතිවල ක්‍රියා කළ හැකි මෙහෙයුම් සහ නඩත්තු සඳහා උපයෝගීතා ද අදහස් කරයි.

අවසාන වශයෙන්, නියෝජිතයන් ඩොකර් ගොනු ඇතුළත් සරල CI/CD සඳහා සහාය විය යුතුය. එසේ නොවුවහොත්, නැව කඩා වැටෙනු ඇත, මන්ද “වංක” රේල් පීලි ඔස්සේ බහාලුම් බෙදා හැරීමට පටන් ගනී.

ගොඩනැගීමේ ක්‍රියාවලිය සහ ඉලක්ක රූප උපාංගය

සෑම දෙයක්ම ප්‍රමිතිගතව සහ කළමනාකරණය කළ හැකි ලෙස තබා ගැනීමට, යම් ආකාරයක සම්මත ගොඩනැගීමේ ක්‍රියාවලියක් අනුගමනය කළ යුතුය. එමනිසා, අපි බහාලුම් මගින් බහාලුම් එකතු කිරීමට තීරණය කළෙමු - මෙය පුනරාවර්තනයකි.

මෙහි කන්ටේනර් ඝන දළ සටහන් මගින් නිරූපණය කෙරේ. ඒ අතරම, "ජීවිතය රාස්ප්බෙරි මෙන් නොපෙනෙන පරිදි" බෙදා හැරීමේ කට්ටල තැබීමට ඔවුහු තීරණය කළහ. මෙය සිදු කළේ ඇයි, අපි පහත විස්තර කරන්නෙමු.
 
එහි ප්‍රතිඵලය වන්නේ ගොඩනැගීමේ මෙවලමකි—විශේෂිත බෙදාහැරීමේ අනුවාද සහ නිශ්චිත ස්ක්‍රිප්ට් අනුවාද ගැන සඳහන් කරන අනුවාද-විශේෂිත බහාලුමකි.

අපි එය භාවිතා කරන්නේ කෙසේද? අපට කන්ටේනරයක් අඩංගු Docker Hub එකක් ඇත. බාහිර පරායත්තතා ඉවත් කිරීම සඳහා අපි එය අපගේ පද්ධතිය තුළ පිළිබිඹු කරමු. ප්රතිඵලය වන්නේ කහ පැහැයෙන් සලකුණු කර ඇති කන්ටේනරයයි. අපට අවශ්‍ය සියලුම බෙදාහැරීම් සහ ස්ක්‍රිප්ට් කන්ටේනරය තුළට ස්ථාපනය කිරීමට අපි අච්චුවක් සාදන්නෙමු. ඊට පසු, අපි භාවිතයට සූදානම් රූපයක් එක්රැස් කරමු: සංවර්ධකයින් කේත සහ ඔවුන්ගේම විශේෂ පරායත්තතා කිහිපයක් එයට දමමු. 

මෙම ප්රවේශයේ හොඳ කුමක්ද? 

• පළමුව, ගොඩනැගීමේ මෙවලම්වල සම්පූර්ණ අනුවාද පාලනය - බහාලුම්, ස්ක්‍රිප්ට් සහ බෙදාහැරීමේ අනුවාද ගොඩනැගීම. 
• දෙවනුව, අපි ප්‍රමිතිකරණය අත්කර ගෙන ඇත: අපි සැකිලි, අතරමැදි සහ භාවිතයට සූදානම් රූපය එකම ආකාරයකින් නිර්මාණය කරමු. 
• තෙවනුව, බහාලුම් අපට අතේ ගෙන යා හැකි හැකියාව ලබා දෙයි. අද අපි Gitlab භාවිතා කරන අතර හෙට අපි TeamCity හෝ Jenkins වෙත මාරු වන අතර අපගේ බහාලුම් එලෙසම ධාවනය කිරීමට අපට හැකි වනු ඇත. 
• හතරවනුව, පරායත්තතා අවම කිරීම. අපි බෙදාහැරීමේ කට්ටල කන්ටේනරය තුළ තැබීම අහම්බයක් නොවේ, මන්ද මෙය සෑම විටම අන්තර්ජාලයෙන් බාගත කිරීම වළක්වා ගැනීමට අපට ඉඩ සලසයි. 
• පස්වනුව, ගොඩනැගීමේ වේගය වැඩි වී ඇත - පින්තූරවල දේශීය පිටපත් තිබීම දේශීය රූපයක් ඇති බැවින් බාගත කිරීමේදී කාලය නාස්ති නොකිරීමට ඔබට ඉඩ සලසයි. 

වෙනත් වචන වලින් කිවහොත්, අපි පාලිත සහ නම්‍යශීලී එකලස් කිරීමේ ක්‍රියාවලියක් සාක්ෂාත් කර ගෙන ඇත. ඕනෑම සම්පූර්ණ අනුවාදයක් සහිත බහාලුමක් තැනීමට අපි එකම මෙවලම් භාවිතා කරමු. 

අපගේ ගොඩනැගීමේ ක්‍රියා පටිපාටිය ක්‍රියාත්මක වන ආකාරය

එකලස් කිරීම එක් විධානයකින් දියත් කරනු ලැබේ, ක්රියාවලිය රූපයේ ක්රියාත්මක වේ (රතු පැහැයෙන් උද්දීපනය කර ඇත). සංවර්ධකයා සතුව ඩොකර් ගොනුවක් ඇත (කහ පැහැයෙන් උද්දීපනය කර ඇත), අපි එය විදැහුම් කරන්නෙමු, විචල්‍යයන් අගයන් සමඟ ප්‍රතිස්ථාපනය කරන්නෙමු. ඒ වගේම අපි ශීර්ෂයන් සහ පාදක එකතු කරනවා - මේ අපේ නියෝජිතයන්. 

ශීර්ෂකය අනුරූප රූප වලින් බෙදාහැරීම් එක් කරයි. පාදකය අපගේ සේවාවන් ඇතුළත ස්ථාපනය කරයි, වැඩ බර දියත් කිරීම, ලොග් වීම සහ වෙනත් නියෝජිතයන් වින්‍යාස කරයි, ඇතුල්වීමේ ස්ථානය ප්‍රතිස්ථාපනය කරයි. 

අපි ගොඩක් වෙලා කල්පනා කළා සුපවයිසර් කෙනෙක් දාන්නද කියලා. අවසානයේ අපි තීරණය කළා ඔහුව අවශ්‍ය බව. අපි S6 තෝරා ගත්තා. සුපරීක්ෂකවරයා බහාලුම් කළමනාකරණය සපයයි: ප්‍රධාන ක්‍රියාවලිය බිඳ වැටුණහොත් එයට සම්බන්ධ වීමට ඔබට ඉඩ සලසයි සහ එය ප්‍රතිනිර්මාණය නොකර කන්ටේනරය අතින් කළමනාකරණය සපයයි. ලඝු-සටහන් සහ ප්‍රමිතික යනු කන්ටේනරය තුළ ක්‍රියාත්මක වන ක්‍රියාවලි වේ. ඒවත් කොහොම හරි පාලනය කරන්න ඕනේ, අපි මේක කරන්නේ සුපවයිසර් කෙනෙක්ගේ උදව්වෙන්. අවසාන වශයෙන්, S6 ගෘහ පාලනය, සංඥා සැකසීම සහ අනෙකුත් කාර්යයන් ගැන සැලකිලිමත් වේ.

අපි විවිධ වාද්‍ය වෘන්ද පද්ධති භාවිතා කරන බැවින්, ගොඩනඟා ධාවනය කිරීමෙන් පසු, කන්ටේනරය එය කුමන පරිසරයක දැයි තේරුම් ගෙන තත්වයට අනුව ක්‍රියා කළ යුතුය. උදාහරණ වශයෙන්:
මෙය අපට එක් රූපයක් ගොඩනඟා විවිධ වාද්‍ය වෘන්ද පද්ධතිවල ධාවනය කිරීමට ඉඩ සලසයි, මෙම වාද්‍ය වෘන්දයේ විශේෂතා සැලකිල්ලට ගනිමින් එය දියත් කෙරේ.

 

එකම කන්ටේනරය සඳහා අපට ඩොකර් සහ කුබර්නෙටස් හි විවිධ ක්‍රියාවලි ගස් ලැබේ:

S6 හි අධීක්ෂණය යටතේ ගෙවීම සිදු කෙරේ. එකතු කරන්නා සහ සිදුවීම් වෙත අවධානය යොමු කරන්න - මොවුන් ලඝු-සටහන් සහ ප්‍රමිතික සඳහා වගකිව යුතු අපගේ නියෝජිතයන් වේ. Kubernetes ළඟ ඒවා නැහැ, නමුත් Docker ළඟ තියෙනවා. ඇයි? 

අපි "පොඩ්" හි පිරිවිතර දෙස බැලුවහොත් (මින් ඉදිරියට - කුබර්නෙටස් පොඩ්), ප්‍රමිතික සහ ලඝු-සටහන් එකතු කිරීමේ කාර්යය ඉටු කරන වෙනම එකතු කරන්නා කන්ටේනරයක් ඇති පොඩ් එකක සිදුවීම් කන්ටේනරය ක්‍රියාත්මක කර ඇති බව අපට පෙනෙනු ඇත. අපට Kubernetes හි හැකියාවන් භාවිතා කළ හැකිය: එක් පොඩ් එකක, තනි ක්‍රියාවලියක සහ/හෝ ජාල අවකාශයක බහාලුම් ධාවනය කිරීම. ඇත්ත වශයෙන්ම ඔබේ නියෝජිතයන් හඳුන්වා දී සමහර කාර්යයන් ඉටු කරන්න. තවද එම කන්ටේනරයම Docker හි දියත් කළහොත්, එයට ප්‍රතිදානය ලෙස සියලුම හැකියාවන් ලැබෙනු ඇත, එනම් නියෝජිතයන් අභ්‍යන්තරව දියත් කරනු ලබන බැවින් එයට ලඝු-සටහන් සහ ප්‍රමිතික ලබා දීමට හැකි වේ. 

මිනුම් සහ ලඝු-සටහන්

මිනුම් සහ ලඝු-සටහන් ලබා දීම සංකීර්ණ කාර්යයකි. ඇයගේ තීරණයේ පැති කිහිපයක් තිබේ.
යටිතල ව්‍යුහය නිර්මාණය කර ඇත්තේ බර පැටවීම ක්‍රියාත්මක කිරීම සඳහා මිස ලොග් විශාල වශයෙන් බෙදා හැරීම සඳහා නොවේ. එනම්, මෙම ක්රියාවලිය අවම බහාලුම් සම්පත් අවශ්යතා සහිතව සිදු කළ යුතුය. අපි අපගේ සංවර්ධකයින්ට උදවු කිරීමට උත්සාහ කරමු: "Docker Hub කන්ටේනරයක් ලබා ගන්න, එය ක්‍රියාත්මක කරන්න, එවිට අපට ලඝු-සටහන් ලබා දිය හැක." 

දෙවන අංගය වන්නේ ලොග් පරිමාව සීමා කිරීමයි. බහාලුම් කිහිපයක ලොග් පරිමාවේ වැඩිවීමක් සිදුවුවහොත් (යෙදුම මඟින් ලූපයක් තුළ ස්ටැක්-ට්‍රේස් එකක් ප්‍රතිදානය කරයි), CPU, සන්නිවේදන නාලිකා සහ ලොග් සැකසුම් පද්ධතිය මත පැටවීම වැඩි වන අතර මෙය ධාරකයේ ක්‍රියාකාරිත්වයට බලපායි. ධාරකයේ සම්පූර්ණ සහ අනෙකුත් බහාලුම්, එවිට සමහර විට මෙය ධාරකයේ "වැටීමට" හේතු වේ. 

තුන්වන අංගය නම්, කොටුවෙන් පිටත හැකි තරම් ප්‍රමිතික එකතු කිරීමේ ක්‍රමවලට සහාය වීම අවශ්‍ය වීමයි. ලිපිගොනු කියවීම සහ Prometheus-endpoint ඡන්ද විමසීමේ සිට යෙදුම් විශේෂිත ප්‍රොටෝකෝල භාවිතා කිරීම දක්වා.

අවසාන අංගය වන්නේ සම්පත් පරිභෝජනය අවම කිරීමයි.

අපි Telegraf නමින් විවෘත මූලාශ්‍ර Go විසඳුමක් තෝරා ගත්තෙමු. මෙය ආදාන නාලිකා වර්ග 140 කට වඩා (ආදාන ප්ලගීන) සහ ප්‍රතිදාන නාලිකා වර්ග 30 කට (ප්‍රතිදාන ප්ලගීන) සහය දක්වන විශ්වීය සම්බන්ධකයකි. අපි එය අවසන් කර ඇති අතර දැන් අපි එය උදාහරණයක් ලෙස Kubernetes භාවිතා කරන ආකාරය ඔබට කියන්නෙමු. 

අපි හිතමු සංවර්ධකයෙක් වැඩ ප්‍රමාණයක් යොදවන අතර Kubernetes හට පොඩ් එකක් සෑදීමට ඉල්ලීමක් ලැබේ. මෙම අවස්ථාවේදී, එක් එක් පොඩ් සඳහා කලෙක්ටර් නම් කන්ටේනරයක් ස්වයංක්‍රීයව නිර්මාණය වේ (අපි විකෘති වෙබ්හූක් භාවිතා කරමු). එකතුකරන්නා අපගේ නියෝජිතයාය. ආරම්භයේදී, මෙම කන්ටේනරය Prometheus සහ ලොග් එකතු කිරීමේ පද්ධතිය සමඟ වැඩ කිරීමට මානකරයි.

• මෙය සිදු කිරීම සඳහා, එය පොඩ් අනුසටහන් භාවිතා කරන අතර, එහි අන්තර්ගතය මත පදනම්ව, Prometheus අවසාන ලක්ෂ්‍යයක් නිර්මාණය කරයි; 
• පොඩ් පිරිවිතර සහ විශේෂිත බහාලුම් සැකසුම් මත පදනම්ව, එය ලඝු-සටහන් බෙදා හරින ආකාරය තීරණය කරයි.

අපි Docker API හරහා ලඝු එකතු කරන්නෙමු: සංවර්ධකයින්ට ඒවා stdout හෝ stderr තුළ තැබීමට අවශ්‍ය වන අතර, එකතුකරන්නා එය නිරාකරණය කරනු ඇත. විය හැකි ධාරක අධි බර වැලැක්වීම සඳහා යම් ප්‍රමාදයක් සහිතව ලඝු-සටහන් කොටස් වශයෙන් එකතු කරනු ලැබේ. 

බහාලුම්වල වැඩ බර අවස්ථා (ක්‍රියාවලි) හරහා ප්‍රමිතික එකතු කරනු ලැබේ. සෑම දෙයක්ම ටැග් කර ඇත: නාම අවකාශය, යටතේ, සහ යනාදිය, පසුව Prometheus ආකෘතියට පරිවර්තනය කර ඇත - සහ එකතු කිරීම සඳහා ලබා ගත හැකිය (ලඝු-සටහන් හැර). අපි කෆ්කා වෙත ලඝු-සටහන්, ප්‍රමිතික සහ සිදුවීම් යවමු සහ තවත්:

• ලඝු-සටහන් ග්‍රේලොග්හි ඇත (දෘෂ්‍ය විශ්ලේෂණය සඳහා);
• ලඝු-සටහන්, ප්‍රමිතික, සිදුවීම් දිගු කාලීන ගබඩා කිරීම සඳහා Clickhouse වෙත යවනු ලැබේ.

AWS හි සෑම දෙයක්ම හරියටම ක්‍රියා කරයි, අපි පමණක් අපි ග්‍රේලොග් වෙනුවට කෆ්කා සමඟ ක්ලවුඩ් වොච් ප්‍රතිස්ථාපනය කරමු. අපි එහි ලොග් යවන අතර සෑම දෙයක්ම ඉතා පහසු වේ: ඒවා අයත් වන්නේ කුමන පොකුර සහ බහාලුම්ද යන්න වහාම පැහැදිලිය. Google Stackdriver සඳහාද එයම වේ. එනම්, අපගේ යෝජනා ක්‍රමය කෆ්කා සමඟ පරිශ්‍රයේ සහ වලාකුළෙහි ක්‍රියා කරයි. 

අපි කරල් සමග Kubernetes නොමැති නම්, යෝජනා ක්රමය ටිකක් සංකීර්ණ වේ, නමුත් එය එකම මූලධර්ම මත ක්රියා කරයි.

කන්ටේනරය තුළ එකම ක්‍රියාවලීන් ක්‍රියාත්මක වේ, ඒවා S6 භාවිතයෙන් සංවිධානය කරනු ලැබේ. එකම කන්ටේනරය තුළ එකම ක්‍රියාවලීන් ක්‍රියාත්මක වේ.

එහි ප්රතිඵලයක් ලෙස,

ලඝු-සටහන් සහ ප්‍රමිතික එකතු කිරීම සහ බෙදා හැරීම සඳහා විකල්ප සමඟ අපි රූප තැනීම සහ දියත් කිරීම සඳහා සම්පූර්ණ විසඳුමක් නිර්මාණය කර ඇත:

• අපි රූප එකලස් කිරීම සඳහා ප්‍රමිතිගත ප්‍රවේශයක් සකස් කළ අතර, එය මත පදනම්ව අපි CI සැකිලි සකස් කළෙමු;
• දත්ත එකතු කිරීමේ නියෝජිතයන් අපගේ Telegraf දිගු වේ. නිෂ්පාදනයේදී අපි ඒවා හොඳින් පරීක්ෂා කළා;
• කරල් වල නියෝජිතයන් සහිත බහාලුම් ක්‍රියාත්මක කිරීමට අපි විකෘති වෙබ්හූක් භාවිතා කරමු; 
• Kubernetes/Rancher පරිසර පද්ධතියට ඒකාබද්ධ;
• අපට විවිධ වාද්‍ය වෘන්ද පද්ධතිවල එකම බහාලුම් ක්‍රියාත්මක කර අප අපේක්ෂා කරන ප්‍රතිඵලය ලබා ගත හැක;
• සම්පූර්ණයෙන්ම ගතික බහාලුම් කළමනාකරණ වින්‍යාසයක් නිර්මාණය කරන ලදී. 

සම කර්තෘ: Ilya Prudnikov

මූලාශ්රය: www.habr.com