Kubernetes වෙත යෙදවීමේ පළමු පියවර වන්නේ ඔබේ අයදුම්පත බහාලුමක තැබීමයි. මෙම ලිපි මාලාවේදී, අපි ඔබට කුඩා, ආරක්ෂිත බහාලුම් රූපයක් නිර්මාණය කරන්නේ කෙසේදැයි බලමු.
ඩොකර්ට ස්තූතියි, බහාලුම් රූප නිර්මාණය කිරීම කිසි විටෙක පහසු නොවීය. මූලික රූපයක් සඳහන් කරන්න, ඔබේ වෙනස්කම් එකතු කරන්න, සහ බහාලුමක් සාදන්න.
මෙම තාක්ෂණය ආරම්භ කිරීම සඳහා විශිෂ්ට වන අතර, පෙරනිමි පාදක රූප භාවිතා කිරීම අවදානම් සහිත විශාල පින්තූර සමඟ අනාරක්ෂිත වැඩ කිරීමට හේතු විය හැක.
මීට අමතරව, Docker හි බොහෝ පින්තූර මූලික රූපය සඳහා Debian හෝ Ubuntu භාවිතා කරන අතර, මෙය විශිෂ්ට ගැළපීමක් සහ පහසු අභිරුචිකරණයක් සපයන අතර (Docker ගොනුවකට කේත පේළි දෙකක් පමණක් ගත වේ), මූලික රූප මඟින් ඔබේ බහාලුමට මෙගාබයිට් සිය ගණනක් අමතර බරක් එක් කළ හැක. උදාහරණයක් ලෙස, Go "hello-world" යෙදුමක් සඳහා සරල node.js ගොනුවක් මෙගාබයිට් 700ක් පමණ වන අතර ඔබේ සැබෑ යෙදුම ප්‍රමාණයෙන් මෙගාබයිට් කිහිපයක් පමණි.
එබැවින් මෙම අමතර වැඩ ප්රමාණය ඩිජිටල් අවකාශය නාස්තියක් වන අතර ආරක්ෂක දුර්වලතා සහ දෝෂ සඳහා විශාල සැඟවුණු ස්ථානයකි. ඉතින් අපි බලමු කන්ටේනර් රූපයක ප්රමාණය අඩු කරන ක්‍රම දෙකක්.
පළමුවැන්න කුඩා පාදක රූප භාවිතය, දෙවැන්න Builder Pattern භාවිතයයි. කුඩා මූලික රූප භාවිතා කිරීම ඔබේ බහාලුම් ප්රමාණය අඩු කිරීමට ඇති පහසුම ක්‍රමය විය හැකිය. බොහෝ දුරට, ඔබ භාවිතා කරන භාෂාව හෝ තොගය පෙරනිමි රූපයට වඩා බෙහෙවින් කුඩා මුල් යෙදුම් රූපයක් සපයයි. අපි අපේ node.js කන්ටේනරය දෙස බලමු.
Docker හි පෙරනිමියෙන්, node:8 මූලික රූපයේ ප්රමාණය 670 MB වන අතර node: 8-alpine image size 65 MB පමණි, එනම් 10 ගුණයකින් කුඩා වේ. කුඩා ඇල්පයින් පාදක රූපය භාවිතා කිරීමෙන්, ඔබ ඔබේ බහාලුම් ප්රමාණය සැලකිය යුතු ලෙස අඩු කරනු ඇත. Alpine යනු කුඩා හා සැහැල්ලු Linux බෙදාහැරීමක් වන අතර එය Docker භාවිතා කරන්නන් අතර ඉතා ජනප්‍රිය වන්නේ එය බහාලුම් කුඩාව තබා ගනිමින් බොහෝ යෙදුම් සමඟ අනුකූල වන බැවිනි. සම්මත Docker "node" රූපය මෙන් නොව, "node:alpine" සේවා ගොනු සහ වැඩසටහන් බොහොමයක් ඉවත් කරයි, ඔබගේ යෙදුම ක්රියාත්මක කිරීමට ප්‍රමාණවත් ඒවා පමණක් ඉතිරි කරයි.
කුඩා මූලික රූපයකට යාමට, නව මූලික රූපය සමඟ වැඩ කිරීම ආරම්භ කිරීමට Dockerfile යාවත්කාලීන කරන්න:
දැන්, පැරණි onbuild රූපය මෙන් නොව, ඔබ ඔබේ කේතය බහාලුමට පිටපත් කර ඕනෑම පරායත්තයක් ස්ථාපනය කළ යුතුය. නව Dockerfile එකක, බහාලුම node:alpine image එකකින් ආරම්භ වේ, පසුව කේතය සඳහා නාමාවලියක් නිර්මාණය කරයි, NPM පැකේජ කළමනාකරු භාවිතයෙන් පරායත්තතා ස්ථාපනය කරයි, සහ අවසානයේ server.js ධාවනය කරයි.
මෙම උත්ශ්‍රේණිගත කිරීම ප්‍රමාණයෙන් 10 ගුණයකින් කුඩා බහාලුමක් ඇති කරයි. ඔබගේ ක්‍රමලේඛන භාෂාවට හෝ තොගයට මූලික රූප අඩු කිරීමේ ක්‍රියාකාරීත්වයක් නොමැති නම්, Alpine Linux භාවිතා කරන්න. එය කන්ටේනරයේ අන්තර්ගතය සම්පූර්ණයෙන්ම කළමනාකරණය කිරීමේ හැකියාව ද ලබා දෙනු ඇත. කුඩා පාදක රූප භාවිතා කිරීම කුඩා බහාලුම් ඉක්මනින් නිර්මාණය කිරීමට විශිෂ්ට ක්රමයකි. නමුත් ඊටත් වඩා විශාල අඩුවීමක් Builder Pattern භාවිතයෙන් ලබා ගත හැක.
පරිවර්ථනය කරන ලද භාෂා වලදී, මූල කේතය මුලින්ම පරිවර්තකයා වෙත ලබා දී පසුව සෘජුවම ක්රියාත්මක වේ. සම්පාදනය කරන ලද භාෂා වලදී, මූල කේතය මුලින්ම සම්පාදනය කරන ලද කේතය බවට පරිවර්තනය වේ. කෙසේ වෙතත්, සම්පාදනය බොහෝ විට කේතය ධාවනය කිරීමට අවශ්ය නොවන මෙවලම් භාවිතා කරයි. මෙයින් අදහස් කරන්නේ ඔබට මෙම මෙවලම් අවසන් කන්ටේනරයෙන් සම්පූර්ණයෙන්ම ඉවත් කළ හැකි බවයි. මේ සඳහා ඔබට Builder Pattern භාවිතා කළ හැකිය.
කේතය පළමු කන්ටේනරය තුළ නිර්මාණය කර සම්පාදනය කර ඇත. සම්පාදනය කරන ලද කේතය පසුව එම කේතය සම්පාදනය කිරීමට අවශ්ය සම්පාදක සහ මෙවලම් නොමැතිව අවසන් භාජනයකට ඇසුරුම් කරනු ලැබේ. අපි මෙම ක්‍රියාවලිය හරහා Go යෙදුමක් ධාවනය කරමු. පළමුව, අපි onbuild රූපයේ සිට Alpine Linux වෙත මාරු කරමු.
නව Dockerfile තුළ, කන්ටේනරය golang:alpine රූපයකින් ආරම්භ වේ. ඉන්පසු එය කේතය සඳහා නාමාවලියක් නිර්මාණය කරයි, එය මූලාශ්‍ර කේතයට පිටපත් කරයි, එම ප්‍රභව කේතය ගොඩනඟා යෙදුම ක්රියාත්මක කරයි. මෙම කන්ටේනරය onbuild කන්ටේනරයට වඩා ඉතා කුඩා නමුත් එහි තවමත් අපට අවශ්ය නොවන compiler සහ අනෙකුත් Go මෙවලම් අඩංගු වේ. ඒ නිසා අපි compile කරපු program එක extract කරලා තමන්ගේම භාජනයකට දාමු.
ඔබට මෙම Docker ගොනුවේ අමුතු දෙයක් දැකිය හැක: එහි FROM රේඛා දෙකක් අඩංගු වේ. මෙම අදියර නම් කිරීමට AS මූල පදය භාවිතා කිරීම හැර පළමු පේළි 4 කොටස පෙර Dockerfile හා සමාන වේ. ඊළඟ කොටසේ නව රූපයක් ආරම්භ කිරීම සඳහා නව FROM රේඛාවක් ඇත, එහිදී golang:alpine රූපය වෙනුවට අපි මූලික රූපය ලෙස Raw alpine භාවිතා කරමු.
Raw Alpine Linux හි SSL සහතික ස්ථාපනය කර නැත, එය HTTPS හරහා බොහෝ API ඇමතුම් අසාර්ථක වීමට හේතු වනු ඇත, එබැවින් අපි root CA සහතික කිහිපයක් ස්ථාපනය කරමු.
දැන් විනෝදජනක කොටස පැමිණේ: සම්පාදනය කරන ලද කේතය පළමු කන්ටේනරයේ සිට දෙවැන්නට පිටපත් කිරීමට, ඔබට දෙවන කොටසේ 5 වන පේළියේ පිහිටා ඇති COPY විධානය භාවිතා කළ හැකිය. එය එක් යෙදුම් ගොනුවක් පමණක් පිටපත් කරන අතර Go උපයෝගිතා මෙවලම්වලට බලපාන්නේ නැත. නව බහු-අදියර ඩොකර් ගොනුවේ මෙගාබයිට් 12 ක් වූ මුල් බහාලුම් රූපයට සාපේක්ෂව මෙගාබයිට් 700 ක් පමණක් වන බහාලුම් රූපයක් අඩංගු වේ, එය විශාල වෙනසක්!
එබැවින් කුඩා පාදක රූප සහ Builder Pattern භාවිතා කිරීම වැඩ ගොඩක් නොමැතිව කුඩා බහාලුම් නිර්මාණය කිරීමට විශිෂ්ට ක්‍රම වේ.
යෙදුම් තොගය මත පදනම්ව, රූපය සහ බහාලුම් ප්රමාණය අඩු කිරීමට අමතර ක්‍රම තිබිය හැකි නමුත් කුඩා බහාලුම්වලට මැනිය හැකි ප්‍රතිලාභයක් තිබේද? කුඩා බහාලුම් අතිශයින්ම ඵලදායී වන අංශ දෙකක් දෙස බලමු - කාර්ය සාධනය සහ ආරක්ෂාව.
කාර්ය සාධනය වැඩිවීම තක්සේරු කිරීම සඳහා, බහාලුමක් නිර්මාණය කිරීමේ ක්රියාවලියේ කාලසීමාව සලකා බලන්න, එය රෙජිස්ට්රි (තල්ලු කිරීම) තුළට ඇතුල් කිරීම, ඉන්පසු එය එතැන් සිට නැවත ලබා ගැනීම (අදින්න). විශාල භාජනයකට වඩා කුඩා බහාලුමක් විශේෂ වාසියක් ඇති බව ඔබට පෙනේ.
ඩොකර් විසින් ස්ථර හැඹිලිගත කරන බැවින් පසුකාලීන ගොඩනැගීම් ඉතා වේගවත් වනු ඇත. කෙසේ වෙතත්, බහාලුම් තැනීමට සහ පරීක්ෂා කිරීමට භාවිතා කරන බොහෝ CI පද්ධති ස්ථර හැඹිලි නොකරන බැවින් සැලකිය යුතු කාල ඉතිරියක් ඇත. ඔබට පෙනෙන පරිදි, ඔබේ යන්ත්‍රයේ බලය මත පදනම්ව විශාල බහාලුමක් තැනීමේ කාලය තත්පර 34 සිට 54 දක්වා වන අතර, කන්ටේනරයක් භාවිතා කරන විට Builder Pattern භාවිතයෙන් අඩු වේ - තත්පර 23 සිට 28 දක්වා. මේ ආකාරයේ මෙහෙයුම් සඳහා, ඵලදායිතාව වැඩිවීම 40-50% වනු ඇත. ඒ නිසා ඔබ ඔබේ කේතය කොපමණ වාර ගණනක් ගොඩනඟා පරීක්ෂා කර ඇත්දැයි සිතා බලන්න.
කන්ටේනරය තැනීමෙන් පසු, ඔබ එහි රූපය (තල්ලු බහාලුම් රූපය) බහාලුම් රෙජිස්ට්‍රියට තල්ලු කළ යුතු අතර එවිට ඔබට එය ඔබේ කුබර්නෙටස් පොකුරේ භාවිතා කළ හැකිය. මම Google Container Registry භාවිතා කිරීමට නිර්දේශ කරමි.
Google Container Registry (GCR) සමඟින්, ඔබ ගෙවන්නේ අමු ගබඩාව සහ ජාලකරණය සඳහා පමණක් වන අතර අමතර බහාලුම් කළමනාකරණ ගාස්තු නොමැත. එය පුද්ගලික, ආරක්ෂිත සහ ඉතා වේගවත් වේ. GCR අදින්න ක්‍රියාව වේගවත් කිරීම සඳහා බොහෝ උපක්‍රම භාවිතා කරයි. ඔබට පෙනෙන පරිදි, go:onbuild භාවිතයෙන් Docker Container Image කන්ටේනරයක් ඇතුළු කිරීමට පරිගණකයේ ක්‍රියාකාරිත්වය අනුව තත්පර 15 සිට 48 දක්වා ගත වන අතර කුඩා බහාලුමක් සමඟ එම මෙහෙයුම තත්පර 14 සිට 16 දක්වා ගත වන අතර අඩු ඵලදායි යන්ත්‍ර සඳහා මෙහෙයුම් වේගයේ වාසිය 3 ගුණයකින් වැඩි වේ. විශාල යන්ත්‍ර සඳහා, කාලය සමාන වේ, GCR විසින් පින්තූරවල බෙදාගත් දත්ත ගබඩාවක් සඳහා ගෝලීය හැඹිලියක් භාවිතා කරයි, එනම් ඔබට ඒවා කිසිසේත් පූරණය කිරීමට අවශ්ය නැත. අඩු බලැති පරිගණකයක, CPU යනු බාධාවකි, එබැවින් කුඩා බහාලුම් භාවිතා කිරීමේ වාසිය මෙහි බෙහෙවින් වැඩි ය.
ඔබ GCR භාවිතා කරන්නේ නම්, ඔබගේ ගොඩනැගීමේ පද්ධතියේ කොටසක් ලෙස Google Container Builder (GCB) භාවිතා කිරීම මම තරයේ නිර්දේශ කරමි.
ඔබට පෙනෙන පරිදි, එහි භාවිතය නිෂ්පාදන යන්ත්‍රයකට වඩා Build+Push මෙහෙයුමේ කාලසීමාව අඩු කිරීමේදී වඩා හොඳ ප්‍රතිඵල ලබා ගැනීමට ඔබට ඉඩ සලසයි - මෙම අවස්ථාවේ දී, ධාරකයට බහාලුම් තැනීමේ සහ යැවීමේ ක්‍රියාවලිය 2 ගුණයකින් පමණ වේගවත් වේ. . ඊට අමතරව, ඔබට සෑම දිනකම නොමිලේ ගොඩනැගීමේ මිනිත්තු 120ක් ලැබේ, එය බොහෝ අවස්ථාවලදී ඔබේ බහාලුම් ගොඩනැගිලි අවශ්‍යතා ආවරණය කරයි.
මීළඟට වඩාත්ම වැදගත් කාර්ය සාධන මෙට්‍රික් එක පැමිණේ - බහාලුම් නැවත ලබා ගැනීමේ හෝ බාගැනීමේ වේගය. තවද ඔබ තල්ලු කිරීමේ මෙහෙයුමක් සඳහා ගත කරන කාලය ගැන වැඩි සැලකිල්ලක් නොදක්වන්නේ නම්, ඇදීමේ ක්රියාවලියේ දිග සමස්ත පද්ධතියේ ක්‍රියාකාරිත්වයට බරපතල බලපෑමක් ඇති කරයි. ඔබට නෝඩ් තුනක පොකුරක් ඇති බවත් ඉන් එකක් අසාර්ථක වූ බවත් සිතමු. ඔබ Google Kubernetes Engine වැනි කළමනාකරණ පද්ධතියක් භාවිතා කරන්නේ නම්, එය ස්වයංක්‍රීයව මිය ගිය නෝඩය නව එකක් සමඟ ප්‍රතිස්ථාපනය කරයි. කෙසේ වෙතත්, මෙම නව නෝඩය සම්පූර්ණයෙන්ම හිස් වනු ඇති අතර එය ක්‍රියා කිරීම ආරම්භ කිරීම සඳහා ඔබේ සියලුම බහාලුම් එයට ඇදගෙන යා යුතුය. ඇදීමේ මෙහෙයුමට ප්‍රමාණවත් කාලයක් ගතවේ නම්, ඔබේ පොකුර මුළු කාලයම අඩු කාර්ය සාධනයකින් ක්රියාත්මක වේ.
මෙය සිදුවිය හැකි බොහෝ අවස්ථා තිබේ: පොකුරකට නව නෝඩයක් එකතු කිරීම, නෝඩ් උත්ශ්‍රේණි කිරීම හෝ යෙදවීම සඳහා නව බහාලුමක් වෙත මාරු වීම. මේ අනුව, ඇද ගැනීමේ කාලය අවම කිරීම ප්‍රධාන සාධකයක් බවට පත්වේ. කුඩා බහාලුමක් විශාල එකකට වඩා වේගයෙන් බාගත වන බව අවිවාදිතය. ඔබ Kubernetes පොකුරක් තුළ බහාලුම් කිහිපයක් ධාවනය කරන්නේ නම්, කාලය ඉතිරි කිරීම සැලකිය යුතු විය හැකිය.
මෙම සංසන්දනය දෙස බලන්න: කුඩා බහාලුම් මත ඇදීමේ මෙහෙයුමක් යන්ත්‍රයේ බලය මත පදනම්ව, go:onbuild භාවිතා කරන එකම මෙහෙයුමට වඩා 4-9 ගුණයකින් අඩු කාලයක් ගතවේ. බෙදාගත්, කුඩා බහාලුම් පාදක රූප භාවිතයෙන් නව Kubernetes නෝඩ් යෙදවිය හැකි සහ අන්තර්ජාලයට පැමිණිය හැකි කාලය සහ වේගය සැලකිය යුතු ලෙස වේගවත් කරයි.
ආරක්ෂාව පිළිබඳ ගැටළුව දෙස බලමු. කුඩා බහාලුම් කුඩා ප්‍රහාරක මතුපිටක් ඇති බැවින් විශාල ඒවාට වඩා ආරක්ෂිත යැයි සැලකේ. එය ඇත්තටමද? Google Container Registry හි වඩාත් ප්‍රයෝජනවත් විශේෂාංගවලින් එකක් වන්නේ අවදානම් සඳහා ඔබේ බහාලුම් ස්වයංක්‍රීයව පරිලෝකනය කිරීමේ හැකියාවයි. මාස කීපයකට පෙර මම ගොඩනඟන සහ බහු අදියර බහාලුම් දෙකම නිර්මාණය කළෙමි, එබැවින් එහි යම් දුර්වලතා තිබේදැයි බලමු.
ප්‍රති result ලය විශ්මයජනක ය: කුඩා භාජනයක මධ්‍යම අවදානම් 3 ක් පමණක් අනාවරණය වී ඇති අතර විශාල බහාලුමක් තුළ විවේචනාත්මක 16 ක් සහ වෙනත් දුර්වලතා 376 ක් සොයා ගන්නා ලදී. අපි විශාල කන්ටේනරයක අන්තර්ගතය දෙස බැලුවහොත්, බොහෝ ආරක්ෂක ගැටළු අපගේ යෙදුම සමඟ කිසිදු සම්බන්ධයක් නැති නමුත් අප භාවිතා නොකරන වැඩසටහන් වලට සම්බන්ධ බව අපට පෙනේ. එබැවින් මිනිසුන් විශාල ප්‍රහාරක මතුපිටක් ගැන කතා කරන විට, ඔවුන් අදහස් කරන්නේ එයයි.
රැගෙන යාම පැහැදිලිය: කුඩා බහාලුම් ඔබේ පද්ධතියට සැබෑ කාර්ය සාධනය සහ ආරක්ෂක ප්‍රතිලාභ ලබා දෙන නිසා ඒවා සාදන්න.
සමහර දැන්වීම් 🙂
අප සමඟ රැඳී සිටීම ගැන ඔබට ස්තුතියි. ඔබ අපේ ලිපි වලට කැමතිද? වඩාත් රසවත් අන්තර්ගතය බැලීමට අවශ්‍යද? ඇණවුමක් කිරීමෙන් හෝ මිතුරන්ට නිර්දේශ කිරීමෙන් අපට සහාය වන්න, , ඔබ වෙනුවෙන් අප විසින් නිර්මාණය කරන ලද ප්‍රවේශ මට්ටමේ සේවාදායකයන්ගේ අද්විතීය ප්‍රතිසමයක්: (RAID1 සහ RAID10, cores 24 දක්වා සහ 40GB DDR4 දක්වා ඇත).
Dell R730xd ඇම්ස්ටර්ඩෑම් හි Equinix Tier IV දත්ත මධ්‍යස්ථානයේ 2 ගුණයක් ලාභදායීද? මෙතන විතරයි නෙදර්ලන්තයේ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 සිට! ගැන කියවන්න
මූලාශ්රය: www.habr.com