2010 දී සමාගම සේවාදායකයන් 50 ක් සහ සරල ජාල ආකෘතියක් තිබුණි: පසුබිම, ඉදිරිපස සහ ෆයර්වෝල්. සේවාදායකයන් සංඛ්යාව වර්ධනය විය, ආකෘතිය වඩාත් සංකීර්ණ විය: වේදිකාගත කිරීම, ACL සහිත හුදකලා VLAN, පසුව VRF සහිත VPN, L2 මත ACL සහිත VLAN, L3 මත ACL සහිත VRF. ඔළුව කැරකෙනවාද? එය පසුව වඩාත් විනෝදජනක වනු ඇත.
සර්වර් 16ක් තියෙද්දි මෙච්චර විෂම කොටස් එක්ක කඳුළු නැතුව වැඩ කරන්න බැරි වුණා. ඉතින් අපි තවත් විසඳුමක් ගෙනාවා. අපි Netfilter තොගය ගෙන, දත්ත මූලාශ්‍රයක් ලෙස එයට කොන්සල් එකතු කළ අතර, අපට වේගයෙන් බෙදා හරින ලද ෆයර්වෝලයක් ලැබුණි. ඔවුන් රවුටරවල ACL වෙනුවට ඒවා බාහිර සහ අභ්යන්තර ෆයර්වෝලයක් ලෙස භාවිතා කළහ. මෙවලම ගතිකව කළමනාකරණය කිරීම සඳහා, අපි සෑම තැනකම භාවිතා කරන ලද BEFW පද්ධතිය සංවර්ධනය කළෙමු: නිෂ්පාදන ජාලයට පරිශීලක ප්රවේශය කළමනාකරණය කිරීමේ සිට ජාල කොටස් එකිනෙකින් හුදකලා කිරීම දක්වා.
ඒ සියල්ල ක්රියාත්මක වන ආකාරය සහ ඔබ මෙම පද්ධතිය දෙස සමීපව බැලිය යුත්තේ මන්දැයි ඔහු ඔබට කියනු ඇත. අයිවන් අගාර්කොව් () - සමාගමේ මින්ස්ක් සංවර්ධන මධ්‍යස්ථානයේ නඩත්තු අංශයේ යටිතල පහසුකම් ආරක්ෂක කණ්ඩායමේ ප්‍රධානියා. අයිවන් SELinux රසිකයෙක්, පර්ල්ට ආදරය කරයි, සහ කේතය ලියයි. තොරතුරු ආරක්ෂණ කණ්ඩායමේ ප්‍රධානියා ලෙස, ඔහු නිතිපතා ලොග්, උපස්ථ සහ R&D සමඟින් Wargaming හැකර්වරුන්ගෙන් ආරක්ෂා කිරීමට සහ සමාගමේ සියලුම ක්‍රීඩා සේවාදායකයන්ගේ ක්‍රියාකාරිත්වය සහතික කිරීමට ක්රියා කරයි.
ඓතිහාසික පසුබිම
අපි එය කළේ කෙසේදැයි මම ඔබට පැවසීමට පෙර, අපි මුලින්ම මෙයට පැමිණියේ කෙසේද සහ එය අවශ්ය වූයේ මන්දැයි මම ඔබට කියමි. මෙය සිදු කිරීම සඳහා, අපි වසර 9 ක් ආපසු යමු: 2010, වර්ල්ඩ් ඔෆ් ටැංකි දැන් දර්ශනය විය. Wargaming සතුව සේවාදායකයන් 50ක් පමණ තිබුණි.
සමාගම් සේවාදායක වර්ධන සටහන.
අපිට ජාල ආකෘතියක් තිබුණා. එම කාලය සඳහා එය ප්රශස්ත විය.
2010 දී ජාල ආකෘතිය.
ඉදිරි අන්තයේ අපිව කඩන්න ඕන නරක මිනිස්සු ඉන්නවා, නමුත් ඒකට ෆයර්වෝල් එකක් තියෙනවා. පසුබිමේ ෆයර්වෝල් නැත, නමුත් එහි සේවාදායකයන් 50 ක් ඇත, අපි ඒවා සියල්ලම දනිමු. සෑම දෙයක්ම හොඳින් ක්රියා කරයි.
වසර 4 ක් තුළ, සේවාදායක බලඇණිය 100 ගුණයකින් වර්ධනය විය, 5000. පළමු හුදකලා ජාල දර්ශනය විය - වේදිකාගත කිරීම: ඒවා නිෂ්පාදනයට යාමට නොහැකි වූ අතර, බොහෝ විට එහි ධාවනය වන දේවල් භයානක විය හැකිය.
2014 දී ජාල ආකෘතිය.
අවස්ථිති භාවයෙන්, අපි එකම දෘඪාංග කොටස් භාවිතා කළ අතර, සියලු වැඩ කටයුතු හුදකලා VLAN මත සිදු කරන ලදී: ACLs VLANs වෙත ලියා ඇත, එය යම් ආකාරයක සම්බන්ධතාවයකට ඉඩ ලබා දෙන හෝ ප්රතික්ෂේප කරයි.
2016 දී, සේවාදායක සංඛ්යාව 8000 දක්වා ළඟා විය. Wargaming වෙනත් චිත්රාගාර අවශෝෂණය කර, අතිරේක අනුබද්ධ ජාල දර්ශනය විය. ඒවා අපගේ බව පෙනේ, නමුත් එතරම් නොවේ: VLAN බොහෝ විට හවුල්කරුවන් සඳහා ක්රියා නොකරයි, ඔබ VRF සමඟ VPN භාවිතා කළ යුතුය, හුදකලාව වඩාත් සංකීර්ණ වේ. ACL පරිවාරක මිශ්රණය වර්ධනය විය.
2016 දී ජාල ආකෘතිය.
2018 ආරම්භය වන විට, යන්ත්‍ර සමූහය 16 දක්වා වර්ධනය වී ඇත. කොටස් 000 ක් තිබූ අතර, මූල්‍ය දත්ත ගබඩා කර ඇති සංවෘත ඒවා ඇතුළුව ඉතිරි ඒවා අපි ගණන් ගත්තේ නැත. බහාලුම් ජාල (Kubernetes), DevOps, VPN හරහා සම්බන්ධ වලාකුළු ජාල, උදාහරණයක් ලෙස, IVS වෙතින්, දර්ශනය වී ඇත. නීති ගොඩක් තිබුණා - එය වේදනාකාරී විය.
2018 දී ජාල ආකෘතිය සහ හුදකලා ක්රම.
හුදකලා කිරීම සඳහා අපි භාවිතා කළේ: L2 මත ACL සමඟ VLAN, L3 මත ACL සමඟ VRF, VPN සහ තවත් බොහෝ දේ. ඉතා වැඩියි.
ගැටළු
සෑම කෙනෙකුම ACL සහ VLAN සමඟ ජීවත් වේ. මොකක් ද වැරැද්ද? මෙම ප්රශ්නයට වේදනාව සඟවා හැරල්ඩ් විසින් පිළිතුරු දෙනු ඇත.
බොහෝ ගැටලු ඇති නමුත් දැවැන්ත ඒවා පහක් විය.
- නව නීති සඳහා ජ්යාමිතික මිල වැඩි කිරීම. සෑම නව රීතියක්ම පෙර එකට වඩා එකතු කිරීමට වැඩි කාලයක් ගත විය, මන්ද එවැනි රීතියක් දැනටමත් තිබේදැයි පළමුව බැලීමට අවශ්ය වූ බැවිනි.
- කොටස් ඇතුළත ෆයර්වෝල් නැත. කොටස් කෙසේ හෝ එකිනෙකින් වෙන් කර ඇති අතර, ඒ වන විටත් එහි ප්‍රමාණවත් සම්පත් නොතිබුණි.
- දිගු කලක් තිස්සේ නීති ක්රියාත්මක විය. ක්‍රියාකරුවන්ට පැයකින් එක් දේශීය රීතියක් අතින් ලිවිය හැකිය. ගෝලීය එකක් දින කිහිපයක් ගත විය.
- විගණන නීති සමඟ දුෂ්කරතා. වඩාත් නිවැරදිව, එය කළ නොහැකි විය. පළමු නීති 2010 දී නැවත ලියා ඇති අතර, ඔවුන්ගේ බොහෝ කතුවරුන් තවදුරටත් සමාගම සඳහා වැඩ කළේ නැත.
- පහළ මට්ටමේ යටිතල පහසුකම් පාලනය. මෙය ප්රධාන ගැටළුවයි - අපේ රටේ සිදුවෙමින් පවතින දේ අපි හොඳින් දැන සිටියේ නැත.
ජාල ඉංජිනේරුවෙකුට 2018 දී ඔහු ඇසූ විට පෙනුනේ මෙයයි: “තවත් ACL ටිකක් අවශ්‍යයි.”
විසඳුම්
2018 ආරම්භයේදී ඒ ගැන යමක් කිරීමට තීරණය විය.
ඒකාබද්ධතාවයේ මිල නිරන්තරයෙන් වර්ධනය වේ. ආරම්භක ලක්ෂ්‍යය වූයේ උපාංගවල මතකය අවසන් වූ නිසා විශාල දත්ත මධ්‍යස්ථාන හුදකලා VLAN සහ ACL සඳහා සහය දැක්වීම නැවැත්වීමයි.
විසඳුම: අපි මානව සාධකය ඉවත් කර උපරිම ප්රවේශය සැපයීම ස්වයංක්‍රීය කළෙමු.
නව නීති ක්රියාත්මක කිරීමට බොහෝ කාලයක් ගත වේ. විසඳුම: නීති ක්රියාත්මක කිරීම වේගවත් කිරීම, එය බෙදාහැරීම හා සමාන්තර කරන්න. පද්ධති දහසකට rsync හෝ SFTP නොමැතිව නීති රීති තමන් විසින්ම ලබා දීමට මෙය බෙදා හරින ලද පද්ධතියක් අවශ්ය වේ.
කොටස් ඇතුළත ෆයර්වෝල් නැත. එකම ජාලය තුළ විවිධ සේවාවන් දර්ශනය වූ විට කොටස් තුළ ෆයර්වෝලයක් අප වෙත පැමිණීමට පටන් ගත්තේය. විසඳුම: ධාරක මට්ටමේ ෆයර්වෝලයක් භාවිතා කරන්න - සත්කාරක-පාදක ෆයර්වෝල්. සෑම තැනකම පාහේ අපට ලිනක්ස් ඇත, සහ සෑම තැනකම අපට iptables ඇත, මෙය ගැටළුවක් නොවේ.
විගණන නීති සමඟ දුෂ්කරතා. විසඳුම: සමාලෝචනය සහ කළමනාකරණය සඳහා සියලුම නීති එකම ස්ථානයක තබා ගන්න, එවිට අපට සියල්ල විගණනය කළ හැක.
යටිතල පහසුකම් පාලනය කිරීමේ අඩු මට්ටම. විසඳුම: සියලුම සේවාවන් සහ ඒවා අතර ප්රවේශයන් පිළිබඳ ඉන්වෙන්ටරියක් ගන්න.
මෙය තාක්ෂණික ක්‍රියාවලියකට වඩා පරිපාලන ක්‍රියාවලියකි. සමහර විට අපි සතියකට නව නිකුතු 200-300 ක් ඇත, විශේෂයෙන් උසස්වීම් සහ නිවාඩු දිනවල. එපමණක් නොව, මෙය අපගේ DevOps කණ්ඩායමක් සඳහා පමණි. බොහෝ නිකුතු සමඟ, කුමන වරායන්, IPs සහ ඒකාබද්ධ කිරීම් අවශ්ය දැයි බැලීමට නොහැක. එමනිසා, අපට විශේෂයෙන් පුහුණු වූ සේවා කළමනාකරුවන් අවශ්ය වූ අතර ඔවුන් කණ්ඩායම් වලින් විමසා ඇත: "කෙසේ වෙතත් එහි ඇත්තේ කුමක්ද සහ ඔබ එය ගෙන ආවේ ඇයි?"
අප දියත් කළ සෑම දෙයකටම පසුව, 2019 දී ජාල ඉංජිනේරුවෙකු මේ ආකාරයෙන් පෙනෙන්නට පටන් ගත්තේය.
කොන්සල්
සේවා කළමනාකරුවන්ගේ සහාය ඇතිව අපට සොයාගත් සෑම දෙයක්ම අපි කොන්සල් වෙත දමා එතැනින් අපි iptables නීති ලිවීමට තීරණය කළෙමු.
අපි මෙය කිරීමට තීරණය කළේ කෙසේද?
- අපි සියලුම සේවාවන්, ජාල සහ පරිශීලකයින් එකතු කරන්නෙමු.
- ඒවා මත පදනම්ව iptables නීති නිර්මාණය කරමු.
- අපි පාලනය ස්වයංක්‍රීය කරන්නෙමු.
- ....
- ලාභයක්.
කොන්සල් යනු දුරස්ථ API එකක් නොවේ, එය සෑම node එකක් මතම ධාවනය කර iptables වෙත ලිවිය හැක. ඉතිරිව ඇත්තේ අනවශ්‍ය දේ පිරිසිදු කරන ස්වයංක්‍රීය පාලනයන් ඉදිරිපත් කිරීම පමණක් වන අතර බොහෝ ගැටලු විසඳනු ඇත! අපි ගියාම ඉතුරු ටික හදාගන්නම්.
ඇයි කොන්සල්?
හොඳින් ඔප්පු වී ඇත. 2014-15 දී, අපි එය මුරපද ගබඩා කරන Vault සඳහා පසුබිමක් ලෙස භාවිතා කළෙමු.
දත්ත නැති නොවේ. භාවිතා කරන කාලය තුළ, කොන්සල්ට එක් අනතුරකදී දත්ත අහිමි නොවීය. ෆයර්වෝල් කළමනාකරණ පද්ධතියක් සඳහා මෙය විශාල ප්ලස් වේ.
P2P සම්බන්ධතා වෙනස් වීමේ ව්‍යාප්තිය වේගවත් කරයි. P2P සමඟ, සියලු වෙනස්කම් ඉක්මනින් පැමිණේ, පැය ගණන් බලා සිටීමට අවශ්ය නොවේ.
පහසු REST API. අපි Apache ZooKeeper ද සලකා බැලුවෙමු, නමුත් එයට REST API නොමැත, එබැවින් ඔබට කිහිලිකරු ස්ථාපනය කිරීමට සිදුවේ.
යතුරු සුරක්ෂිතාගාරයක් (KV) සහ නාමාවලියක් (සේවා සොයාගැනීම) ලෙස ක්රියා කරයි. ඔබට එකවර සේවා, නාමාවලි සහ දත්ත මධ්‍යස්ථාන ගබඩා කළ හැක. මෙය අපට පමණක් නොව අසල්වැසි කණ්ඩායම් සඳහාද පහසු වේ, මන්ද ගෝලීය සේවාවක් ගොඩනඟන විට අපි විශාල ලෙස සිතමු.
Wargaming තොගයේ කොටසක් වන Go හි ලියා ඇත. අපි මෙම භාෂාවට ආදරෙයි, අපට බොහෝ Go සංවර්ධකයින් සිටී.
බලවත් ACL පද්ධතිය. කොන්සල්හිදී, ඔබට ACL භාවිතා කළ හැක්කේ කවුරුන් කුමක් ලියන්නේද යන්න පාලනය කිරීමටය. ෆයර්වෝල් රීති වෙනත් කිසිවක් සමඟ අතිච්ඡාදනය නොවන බවට අපි සහතික වන අතර අපට මේ සම්බන්ධයෙන් ගැටළු ඇති නොවේ.
නමුත් කොන්සල්ට ද එහි අඩුපාඩු තිබේ.
- ඔබට ව්‍යාපාරික අනුවාදයක් නොමැති නම් දත්ත මධ්‍යස්ථානයක් තුළ පරිමාණය නොකරයි. එය පරිමාණය කළ හැක්කේ සම්මේලනයට පමණි.
- ජාලයේ ගුණාත්මකභාවය සහ සේවාදායක භාරය මත බෙහෙවින් රඳා පවතී. ජාලයේ කිසියම් ප්‍රමාදයක් තිබේ නම්, උදාහරණයක් ලෙස, අසමාන වේගයක් තිබේ නම්, කාර්යබහුල සේවාදායකයක සේවාදායකයක් ලෙස කොන්සල් නිසි ලෙස ක්රියා නොකරනු ඇත. මෙය P2P සම්බන්ධතා සහ යාවත්කාලීන බෙදාහැරීමේ ආකෘති නිසාය.
- ලබා ගැනීමේ අපහසුතා නිරීක්ෂණය කිරීම. කොන්සල් තත්ත්වය තුළ ඔහු සියල්ල හොඳින් බව පැවසිය හැකිය, නමුත් ඔහු බොහෝ කලකට පෙර මිය ගියේය.
අපි කොන්සල් භාවිතා කරන අතරතුර මෙම ගැටළු බොහොමයක් විසඳා ගත්තෙමු, ඒ නිසා අපි එය තෝරා ගත්තෙමු. සමාගමට විකල්ප පසුබිමක් සඳහා සැලසුම් ඇත, නමුත් අපි ගැටළු සමඟ කටයුතු කිරීමට ඉගෙන ගෙන දැනට කොන්සල් සමඟ ජීවත් වෙමු.
කොන්සල් වැඩ කරන ආකාරය
අපි කොන්දේසි සහිත දත්ත මධ්‍යස්ථානයක සේවාදායක තුනක් හෝ පහක් ස්ථාපනය කරන්නෙමු. සේවාදායකයන් එකක් හෝ දෙකක් ක්රියා නොකරනු ඇත: ඔවුන්ට ගණපූරණයක් සංවිධානය කිරීමට සහ දත්ත නොගැලපෙන විට නිවැරදි කවුද සහ වැරදි කවුද යන්න තීරණය කිරීමට ඔවුන්ට නොහැකි වනු ඇත. පහකට වඩා තේරුමක් නැත, ඵලදායිතාව පහත වැටෙනු ඇත.
සේවාලාභීන් ඕනෑම අනුපිළිවෙලකට සේවාදායකයන් වෙත සම්බන්ධ වේ: එකම නියෝජිතයන්, ධජය සමඟ පමණි server = false.
මෙයින් පසු, සේවාදායකයින්ට P2P සම්බන්ධතා ලැයිස්තුවක් ලැබෙන අතර ඔවුන් අතර සම්බන්ධතා ගොඩනඟා ගනී.
ගෝලීය මට්ටමින් අපි දත්ත මධ්‍යස්ථාන කිහිපයක් සම්බන්ධ කරමු. ඔවුන් P2P සම්බන්ධ කර සන්නිවේදනය කරයි.
අපට වෙනත් දත්ත මධ්‍යස්ථානයකින් දත්ත ලබා ගැනීමට අවශ්ය වූ විට, ඉල්ලීම සේවාදායකයෙන් සේවාදායකයට යයි. මෙම යෝජනා ක්රමය ලෙස හැඳින්වේ සර්ෆ් ප්රොටෝකෝලය. කොන්සල් වැනි Serf ප්රොටෝකෝලය HashiCorp විසින් සංවර්ධනය කර ඇත.
කොන්සල් පිළිබඳ වැදගත් කරුණු කිහිපයක්
එය ක්රියාත්මක වන ආකාරය විස්තර කරන ලියකියවිලි කොන්සල් සතුව ඇත. දැනගත යුතු තෝරාගත් කරුණු පමණක් දෙන්නම්.
කොන්සල් සේවාදායකයන් ඡන්දදායකයින් අතරින් මාස්ටර් තෝරා ගනී. කොන්සල් විසින් එක් එක් දත්ත මධ්‍යස්ථානය සඳහා සේවාදායක ලැයිස්තුවෙන් මාස්ටර් තෝරා ගන්නා අතර, සේවාදායකයන් ගණන නොසලකා සියලු ඉල්ලීම් යන්නේ එයට පමණි. මාස්ටර් කැටි කිරීම නැවත තේරී පත්වීමට හේතු නොවේ. මාස්ටර් තෝරා නොගන්නේ නම්, ඉල්ලීම් කිසිවෙකු විසින් සේවා නොකෙරේ.
ඔබට තිරස් පරිමාණය අවශ්‍යද? කණගාටුයි, නැහැ.
වෙනත් දත්ත මධ්‍යස්ථානයකට ඉල්ලීමක් එය කුමන සේවාදායකයට පැමිණියත් එය මාස්ටර්ගෙන් ප්‍රධානියාට යයි. තෝරාගත් ස්වාමියාට ඉදිරි ඉල්ලීම් මත පැටවීම හැර, භාරයෙන් 100% ලැබේ. දත්ත මධ්‍යස්ථානයේ සියලුම සේවාදායකයන් සතුව දත්තවල යාවත්කාලීන පිටපතක් ඇත, නමුත් ප්‍රතිචාර දක්වන්නේ එකක් පමණි.
පරිමාණය කිරීමට ඇති එකම මාර්ගය වන්නේ සේවාලාභියා මත පරණ මාදිලිය සක්රිය කිරීමයි.
පරණ මාදිලියේදී, ඔබට ගණපූරණයක් නොමැතිව ප්‍රතිචාර දැක්විය හැක. මෙය අපි දත්ත අනුකූලතාව අත්හරින මාදිලියකි, නමුත් වෙනදාට වඩා ටිකක් වේගයෙන් කියවන අතර ඕනෑම සේවාදායකයක් ප්‍රතිචාර දක්වයි. ස්වාභාවිකවම, මාස්ටර් හරහා පමණක් පටිගත කිරීම.
කොන්සල් දත්ත මධ්‍යස්ථාන අතර දත්ත පිටපත් නොකරයි. ෆෙඩරේෂන් එකලස් කරන විට, සෑම සේවාදායකයකටම ඇත්තේ තමන්ගේම දත්ත පමණි. අන් අය සඳහා, ඔහු සෑම විටම වෙනත් කෙනෙකු වෙත හැරේ.
ගනුදෙනුවකින් පිටත මෙහෙයුම්වල පරමාණුකත්වය සහතික නොවේ. දේවල් වෙනස් කළ හැක්කේ ඔබට පමණක් නොවන බව මතක තබා ගන්න. ඔබට එය වෙනස් ආකාරයකින් අවශ්ය නම්, අගුලක් සමඟ ගනුදෙනුවක් සිදු කරන්න.
අවහිර කිරීමේ මෙහෙයුම් අගුලු දැමීම සහතික නොකරයි. ඉල්ලීම ස්වාමියාගෙන් ස්වාමියා වෙත යන අතර සෘජුවම නොවේ, එබැවින් ඔබ අවහිර කරන විට අවහිර කිරීම ක්රියා කරන බවට සහතිකයක් නොමැත, උදාහරණයක් ලෙස, වෙනත් දත්ත මධ්‍යස්ථානයක.
ACL ද ප්රවේශය සහතික නොකරයි (බොහෝ අවස්ථාවල). ACL එක ෆෙඩරේෂන් දත්ත මධ්‍යස්ථානයක - ACL දත්ත මධ්‍යස්ථානයේ (Primary DC) ගබඩා කර ඇති නිසා එය ක්රියා නොකරනු ඇත. DC ඔබට පිළිතුරු නොදෙන්නේ නම්, ACL ක්රියා නොකරනු ඇත.
එක් ශීත කළ මාස්ටර් මුළු සම්මේලනයම කැටි කිරීමට හේතු වනු ඇත. උදාහරණයක් ලෙස, ෆෙඩරේෂන් එකක දත්ත මධ්‍යස්ථාන 10 ක් ඇති අතර, එකක් නරක ජාලයක් ඇති අතර, එක් මාස්ටර් අසමත් වේ. ඔහු සමඟ සන්නිවේදනය කරන සෑම කෙනෙකුම රවුමක කැටි කරනු ඇත: ඉල්ලීමක් ඇත, එයට පිළිතුරක් නැත, නූල් කැටි වේ. මේක කවදා වෙයිද කියලා දැනගන්න විදිහක් නෑ තව පැයකින් දෙකකින් මුළු සම්මේලනයම වැටෙනවා. ඒ ගැන ඔබට කළ හැකි දෙයක් නැත.
තත්ත්වය, ගණපූරණය සහ මැතිවරණ වෙනම ත්‍රෙඩ් එකකින් හසුරුවනු ලැබේ. නැවත මැතිවරණයක් සිදු නොවනු ඇත, තත්වය කිසිවක් නොපෙන්වයි. ඔබට සජීවී කොන්සල්වරයෙකු සිටින බව ඔබ සිතන්නේ, ඔබ අසන්න, කිසිවක් සිදු නොවේ - පිළිතුරක් නැත. ඒ සමගම, තත්වය පෙන්නුම් කරන්නේ සෑම දෙයක්ම හොඳයි.
අපි මෙම ගැටලුවට මුහුණ දී ඇති අතර එය වළක්වා ගැනීම සඳහා දත්ත මධ්‍යස්ථානවල නිශ්චිත කොටස් නැවත ගොඩනැඟීමට සිදු විය.
කොන්සල් එන්ටර්ප්‍රයිස් හි ව්‍යාපාරික අනුවාදයේ ඉහත අවාසි කිහිපයක් නොමැත. එය බොහෝ ප්රයෝජනවත් කාර්යයන් ඇත: ඡන්දදායකයින් තෝරා ගැනීම, බෙදා හැරීම, පරිමාණය කිරීම. ඇත්තේ එක් “නමුත්” පමණි - බෙදා හරින ලද පද්ධතියක් සඳහා බලපත්‍ර පද්ධතිය ඉතා මිල අධිකය.
ජීවිතවලට අනවසරයෙන් සවන් rm -rf /var/lib/consul - නියෝජිතයාගේ සියලුම රෝග සඳහා පිළියමක්. යමක් ඔබ වෙනුවෙන් වැඩ නොකරන්නේ නම්, ඔබගේ දත්ත මකා දමා පිටපතකින් දත්ත බාගන්න. බොහෝ දුරට, කොන්සල් වැඩ කරනු ඇත.
BEFW
දැන් අපි කොන්සල්ට එකතු කළ දේ ගැන කතා කරමු.
යන්න කෙටි යෙදුමකි Bඅක්EndFමම යන්නම්Wසෑම. පළමු පරීක්ෂණ කැපවීම සඳහා මම ගබඩාව නිර්මාණය කරන විට නිෂ්පාදනයට කෙසේ හෝ නම් කිරීමට සිදු විය. මෙම නම ඉතිරිව ඇත.
රීති සැකිලි
රීති iptables සින්ටැක්ස් වලින් ලියා ඇත.
- -එන් බීඑෆ්ඩබ්ලිව්
- -P ආදාන පහත වැටීම
- -ආදානය -m රාජ්‍ය-ආශ්‍රිත, ස්ථාපිත -j පිළිගනිති
- -A INPUT -i lo -j පිළිගන්නවා
- -ආදානය -j BEFW
හැර සෑම දෙයක්ම BEFW දාමයට යයි ESTABLISHED, RELATED සහ localhost. අච්චුව ඕනෑම දෙයක් විය හැකිය, මෙය උදාහරණයක් පමණි.
BEFW ප්රයෝජනවත් වන්නේ කෙසේද?
සේවා
අපට සේවාවක් ඇත, එය සැමවිටම වරායක් ඇත, එය ක්රියාත්මක වන නෝඩයක් ඇත. අපගේ නෝඩයෙන්, අපට දේශීයව නියෝජිතයාගෙන් විමසා අපට යම් ආකාරයක සේවාවක් ඇති බව සොයා ගත හැකිය. ටැග් දාන්නත් පුළුවන්.
කොන්සල් සමඟ ක්රියාත්මක වන සහ ලියාපදිංචි වන ඕනෑම සේවාවක් iptables රීතියක් බවට පත්වේ. අපට SSH - open port 22 ඇත. Bash පිටපත සරලයි: curl සහ iptables, වෙන කිසිවක් අවශ්ය නොවේ.
සේවාලාභීන්
සෑම කෙනෙකුටම නොව තෝරා බේරා ප්රවේශය විවෘත කරන්නේ කෙසේද? සේවා නාමයෙන් KV ගබඩාවට IP ලැයිස්තු එක් කරන්න.
උදාහරණයක් ලෙස, දහවන ජාලයේ සිටින සියලු දෙනාටම SSH_TCP_22 සේවාව වෙත ප්‍රවේශ වීමට අපට අවශ්‍යය. එක් කුඩා TTL ක්ෂේත්‍රයක් එක් කරන්නද? දැන් අපට තාවකාලික බලපත්‍ර තිබේ, උදාහරණයක් ලෙස, දිනකට.
ප්රවේශයන්
අපි සේවා සහ සේවාදායකයින් සම්බන්ධ කරමු: අපට සේවාවක් ඇත, KV ගබඩාව එක් එක් සඳහා සූදානම්. දැන් අපි ප්රවේශය ලබා දෙන්නේ සෑම කෙනෙකුටම නොව තෝරා බේරාගෙනය.
කණ්ඩායම්
අපි හැම වෙලාවෙම ප්‍රවේශයට IP දහස් ගණනක් ලිව්වොත් අපි මහන්සි වෙනවා. අපි කණ්ඩායම් සමඟ පැමිණෙමු - KV හි වෙනම උප කුලකයක්. අපි එය අන්වර්ථ (හෝ කණ්ඩායම්) ලෙස හඳුන්වන අතර එකම මූලධර්මය අනුව කණ්ඩායම් එහි ගබඩා කරමු.
අපි සම්බන්ධ වෙමු: දැන් අපට SSH විවෘත කළ හැක්කේ P2P සඳහා නොව, සම්පූර්ණ කණ්ඩායමක් හෝ කණ්ඩායම් කිහිපයක් සඳහා ය. ඒ ආකාරයෙන්ම, TTL ඇත - ඔබට කණ්ඩායමකට එකතු කර කණ්ඩායමෙන් තාවකාලිකව ඉවත් කළ හැකිය.
අනුකලනය
අපගේ ගැටලුව මානව සාධකය සහ ස්වයංක්‍රීයකරණයයි. මෙතෙක් අපි එය මේ ආකාරයෙන් විසඳා ඇත.
අපි රූකඩ සමඟ වැඩ කරන අතර, පද්ධතියට (යෙදුම් කේතය) සම්බන්ධ වන සියල්ල ඔවුන්ට මාරු කරන්නෙමු. Puppetdb (සාමාන්‍ය PostgreSQL) එහි ක්රියාත්මක වන සේවා ලැයිස්තුවක් ගබඩා කරයි, ඒවා සම්පත් වර්ගය අනුව සොයාගත හැකිය. එහිදී ඔබට අයදුම් කරන්නේ කවුරුන්ද යන්න සොයාගත හැකිය. අපි මේ සඳහා පුල් ඉල්ලීම සහ ඒකාබද්ධ ඉල්ලීම් ක්‍රමයක් ද ඇත.
අපි befw-sync ලිව්වා, දත්ත මාරු කිරීමට උපකාරී වන සරල විසඳුමක්. පළමුව, සමමුහුර්ත කුකීස් puppetdb මගින් ප්‍රවේශ වේ. HTTP API එහි වින්‍යාස කර ඇත: අප සතුව ඇති සේවාවන් මොනවාද, කළ යුතු දේ අපි ඉල්ලා සිටිමු. එවිට ඔවුන් කොන්සල්ගෙන් ඉල්ලීමක් කරයි.
ඒකාබද්ධතාවයක් තිබේද? ඔව්: ඔවුන් නීති රීති ලියා ඇති අතර ඇදීමේ ඉල්ලීම් පිළිගැනීමට ඉඩ දුන්නේය. ඔබට නිශ්චිත වරායක් අවශ්‍යද නැතහොත් කිසියම් කණ්ඩායමකට සත්කාරකයක් එක් කරන්නද? අදින්න ඉල්ලීම, සමාලෝචනය - තවත් නැත "වෙනත් ACL 200ක් සොයාගෙන ඒ ගැන යමක් කිරීමට උත්සාහ කරන්න."
සුසර කිරීම
හිස් රීති දාමයක් සහිත දේශීය සත්කාරක පිං කිරීම 0,075 ms ගනී.
අපි මේ දාමයට iptables ලිපින 10ක් එකතු කරමු. ප්රතිඵලයක් වශයෙන්, ping 000 ගුණයකින් වැඩි වනු ඇත: iptables සම්පූර්ණයෙන්ම රේඛීය වේ, එක් එක් ලිපිනය සැකසීමට යම් කාලයක් ගතවේ.
අපි ACL දහස් ගණනක් සංක්‍රමණය කරන ෆයර්වෝලයක් සඳහා, අපට නීති රාශියක් ඇති අතර, මෙය ප්‍රමාදය හඳුන්වා දෙයි. මෙය ක්‍රීඩා ප්‍රොටෝකෝල සඳහා නරක ය.
හැබැයි අපි දැම්මොත් ipset හි ලිපින 10ක් පිං පවා අඩු වනු ඇත.
කාරණය වන්නේ ipset සඳහා "O" (ඇල්ගොරිතම සංකීර්ණත්වය) සෑම විටම 1 ට සමාන වන අතර, කොපමණ නීති රීති තිබුණත්. ඇත්ත, සීමාවක් තිබේ - නීති 65535 කට වඩා තිබිය නොහැක. දැනට අපි මෙය සමඟ ජීවත් වෙමු: ඔබට ඒවා ඒකාබද්ධ කළ හැකිය, ඒවා පුළුල් කළ හැකිය, එකකින් ipsets දෙකක් සෑදිය හැකිය.
ගබඩාව
පුනරාවර්තන ක්‍රියාවලියේ තාර්කික අඛණ්ඩ පැවැත්මක් වන්නේ සේවාව සඳහා සේවාලාභීන් පිළිබඳ තොරතුරු ipset තුළ ගබඩා කිරීමයි.
දැන් අපට එකම SSH ඇත, අපි එකවර IP 100 ක් ලියන්නේ නැත, නමුත් අපට සන්නිවේදනය කිරීමට අවශ්ය ipset නම සහ පහත රීතිය සකසන්න DROP. එය එක් රීතියක් බවට පරිවර්තනය කළ හැකිය "කවුද මෙහි නැත, DROP", නමුත් එය වඩාත් පැහැදිලිය.
දැන් අපට නීති සහ කට්ටල තිබේ. ප්රධාන කාර්යය වන්නේ රීතිය ලිවීමට පෙර කට්ටලයක් සෑදීමයි, එසේ නොමැතිනම් iptables රීතිය ලියන්නේ නැත.
පොදු යෝජනා ක්රමය
රූප සටහනක ආකාරයෙන්, මම පැවසූ සෑම දෙයක්ම මේ ආකාරයෙන් පෙනේ.
අපි Puppet සඳහා කැපවී සිටිමු, සියල්ල සත්කාරක වෙත යවනු ලැබේ, මෙහි සේවාවන්, එහි ipset, සහ එහි ලියාපදිංචි නොවූ ඕනෑම කෙනෙකුට අවසර නැත.
ඉඩ දෙන්න සහ ප්රතික්ෂේප කරන්න
ඉක්මනින් ලෝකය සුරැකීමට හෝ යමෙකු ඉක්මනින් අක්‍රිය කිරීමට, සියලු දාමයන් ආරම්භයේදී අපි ipset දෙකක් සෑදුවෙමු: rules_allow и rules_deny. එය ක්රියා කරන්නේ කෙසේද?
උදාහරණයක් ලෙස, යමෙකු බොට්ස් සමඟ අපගේ වෙබයේ බරක් නිර්මාණය කරයි. මීට පෙර, ඔබට ඔහුගේ IP ලොග් වලින් සොයා ගත යුතු අතර, එය ජාල ඉංජිනේරුවන් වෙත ගෙන යාමට සිදු විය, එවිට ඔවුන්ට ගමනාගමනයේ මූලාශ්රය සොයාගෙන ඔහුව තහනම් කළ හැකිය. දැන් එය වෙනස් ලෙස පෙනේ.
අපි එය කොන්සල් වෙත යවමු, තත්පර 2,5 ක් රැඳී සිටින්න, එය සිදු කර ඇත. කොන්සල් P2P හරහා ඉක්මනින් බෙදා හරින බැවින්, එය ලෝකයේ ඕනෑම තැනක සෑම තැනකම ක්රියා කරයි.
එක පාරක් ෆයර්වෝල් එකේ වැරදීමක් නිසා මම කොහොම හරි WOT එක සම්පුර්ණයෙන්ම නැවැත්තුවා. rules_allow - මෙය එවැනි අවස්ථාවන්ට එරෙහිව අපගේ රක්ෂණයයි. අපි ෆයර්වෝල් එකේ කොහේ හරි වැරැද්දක් කළා නම්, කොහේ හරි යමක් අවහිර වී ඇත්නම්, අපට සැමවිටම කොන්දේසියක් යැවිය හැකිය 0.0/0ඉක්මනින් සියල්ල ලබා ගැනීමට. පසුව අපි සියල්ල අතින් සවි කරමු.
වෙනත් කට්ටල
ඔබට අභ්‍යවකාශයේ වෙනත් ඕනෑම කට්ටලයක් එකතු කළ හැක $IPSETS$.
කුමක් සඳහා ද? සමහර විට යමෙකුට ipset අවශ්ය වේ, උදාහරණයක් ලෙස, පොකුරේ යම් කොටසක් වසා දැමීම අනුකරණය කිරීමට. ඕනෑම කෙනෙකුට ඕනෑම කට්ටලයක් ගෙන ඒමට හැකිය, ඒවා නම් කරන්න, ඔවුන් කොන්සල්ගෙන් ලබා ගනු ඇත. ඒ අතරම, කට්ටලවලට iptables නීතිවලට සහභාගී වීමට හෝ කණ්ඩායමක් ලෙස ක්රියා කිරීමට හැකිය NOOP: ඩීමන් විසින් අනුකූලතාව පවත්වා ගෙන යනු ඇත.
පරිශීලකයින්
මීට පෙර, එය මෙසේ විය: පරිශීලකයා ජාලයට සම්බන්ධ වූ අතර වසම හරහා පරාමිති ලබා ගත්තේය. නව පරම්පරාවේ ෆයර්වෝල් පැමිණීමට පෙර, සිස්කෝ පරිශීලකයා සිටින්නේ කොහේද සහ අයිපී කොහේද යන්න තේරුම් ගන්නේ කෙසේදැයි දැන සිටියේ නැත. එබැවින්, යන්ත්‍රයේ සත්කාරක නාමය හරහා පමණක් ප්රවේශය ලබා දෙන ලදී.
අපි මොනවද කළේ? ලිපිනය ලැබුණු මොහොතේම අපි හිරවුණා. සාමාන්යයෙන් මෙය dot1x, Wi-Fi හෝ VPN - සියල්ල RADIUS හරහා ගමන් කරයි. එක් එක් පරිශීලකයා සඳහා, අපි පරිශීලක නාමයෙන් කණ්ඩායමක් සාදා එහි dhcp.lease ට සමාන TTL සමඟ IP එකක් තබමු - එය කල් ඉකුත් වූ වහාම රීතිය අතුරුදහන් වනු ඇත.
දැන් අපට වෙනත් කණ්ඩායම් මෙන්, පරිශීලක නාමයෙන් සේවා සඳහා ප්රවේශය විවෘත කළ හැක. අපි සත්කාරක නම් වෙනස් වන විට වේදනාව ඉවත් කර ඇති අතර, ජාල ඉංජිනේරුවන්ට තවදුරටත් සිස්කෝ අවශ්ය නොවන නිසා අපි බර ඉවත් කළෙමු. දැන් ඉංජිනේරුවන් විසින්ම ඔවුන්ගේ සේවාදායකයන් වෙත ප්රවේශය ලියාපදිංචි කරයි.
පරිවරණය
ඒ අතරම, අපි පරිවරණය විසුරුවා හැරීමට පටන් ගත්තෙමු. සේවා කළමනාකරුවන් බඩු තොගයක් ගෙන ඇති අතර, අපි අපගේ සියලුම ජාල විශ්ලේෂණය කළෙමු. අපි ඒවා එකම කණ්ඩායම් වලට බෙදමු, සහ අවශ්ය සේවාදායකයන් මත කණ්ඩායම් එකතු කරන ලදී, උදාහරණයක් ලෙස, ප්රතික්ෂේප කිරීම සඳහා. දැන් එම වේදිකා හුදකලාව නිශ්පාදනයේ_ප්රතික්ෂේප කිරීම තුලින් අවසන් වේ, නමුත් නිෂ්පාදනය තුලම නොවේ.
යෝජනා ක්රමය ඉක්මනින් හා සරලව ක්රියා කරයි: අපි සර්වර් වලින් සියලුම ACL ඉවත් කරමු, දෘඪාංග බාගැනීම සහ හුදකලා VLAN සංඛ්යාව අඩු කරමු.
අඛණ්ඩතාව පාලනය කිරීම
මින් පෙර, යමෙකු ෆයර්වෝල් රීතියක් අතින් වෙනස් කළ විට වාර්තා කළ විශේෂ ප්‍රේරකයක් අප සතුව තිබුණි. මම ෆයර්වෝල් නීති පරීක්ෂා කිරීම සඳහා විශාල ලින්ටරයක් ලියමින් සිටියෙමි, එය දුෂ්කර විය. අඛණ්ඩතාව දැන් BEFW මගින් පාලනය වේ. ඔහු පනවන නීති වෙනස් නොවන බවට ඔහු ජ්වලිතව සහතික කරයි. කවුරුහරි ෆයර්වෝල් නීති වෙනස් කළහොත්, එය සියල්ල ආපසු වෙනස් කරයි. "මම ඉක්මනින්ම ප්‍රොක්සියක් පිහිටුවමි. එවිට මට නිවසේ සිට වැඩ කිරීමට හැකි විය"—එවැනි විකල්ප තවත් නැත.
BEFW දාමයේ සේවා රීති වන befw.conf හි සේවා සහ ලැයිස්තුවෙන් ipset පාලනය කරයි. නමුත් එය වෙනත් දාම සහ රීති සහ අනෙකුත් ipsets නිරීක්ෂණය නොකරයි.
බිඳවැටීම් ආරක්ෂාව
BEFW සෑම විටම අවසාන දන්නා හොඳ තත්වය කෙලින්ම state.bin ද්විමය ව්‍යුහය තුළ ගබඩා කරයි. යමක් වැරදුනහොත්, එය සෑම විටම මෙම state.bin වෙත ආපසු හැරේ.
මෙය අස්ථායී කොන්සල් මෙහෙයුමට එරෙහිව රක්ෂණයකි, එය දත්ත එවා නැති විට හෝ යමෙකු වැරැද්දක් කළ විට සහ යෙදිය නොහැකි නීති භාවිතා කරයි. අපි ෆයර්වෝලයක් නොමැතිව ඉතිරි නොවන බව සහතික කිරීම සඳහා, ඕනෑම අවස්ථාවක දෝෂයක් ඇති වුවහොත් BEFW නවතම තත්වයට පෙරළෙනු ඇත.
තීරණාත්මක අවස්ථාවන්හිදී, මෙය අපට වැඩ කරන ෆයර්වෝලයක් ඉතිරි වන බවට සහතිකයකි. අපි සියලුම අළු ජාල විවෘත කරන්නේ පරිපාලක පැමිණ එය නිවැරදි කරනු ඇතැයි යන බලාපොරොත්තුවෙන්. කවදාහරි මම මේක configs වලට දාන්නම්, නමුත් දැන් අපිට තියෙන්නේ අළු ජාල තුනක් විතරයි: 10/8, 172/12 සහ 192.168/16. අපගේ කොන්සල්වරයා තුළ, මෙය අපට තව දුරටත් වර්ධනය වීමට උපකාර වන වැදගත් අංගයකි.
Demo: වාර්තාව අතරතුර, Ivan BEFW හි ආදර්ශන මාදිලිය පෙන්වයි. ප්රදර්ශනය නැරඹීමට වඩා පහසුය . Demo source code ඇත .
උගුල්
අපට හමු වූ දෝෂ ගැන මම ඔබට කියන්නම්.
ipset add set 0.0.0.0/0. ඔබ ipset වෙත 0.0.0.0/0 එකතු කළහොත් කුමක් සිදුවේද? සියලුම IPs එකතු වේවිද? අන්තර්ජාල ප්රවේශය ලබා ගත හැකිද?
නැත, අපට පැය දෙකක අක්‍රිය කාලයක් වැය වන දෝෂයක් ලැබෙනු ඇත. එපමණක් නොව, දෝෂය 2016 සිට ක්රියා කර නැත, එය අංක 1297092 යටතේ RedHat Bugzilla හි පිහිටා ඇති අතර අපට එය අහම්බෙන් හමු විය - සංවර්ධකයාගේ වාර්තාවෙන්.
එය දැන් BEFW හි දැඩි නීතියකි 0.0.0.0/0 ලිපින දෙකක් බවට පරිවර්තනය වේ: 0.0.0.0/1 и 128.0.0.0/1.
ipset ප්‍රතිසාධන කට්ටලය < ගොනුව. ipset කිව්වම මොකද කරන්නේ restore? එය iptables හා සමානව ක්රියා කරයි යැයි ඔබ සිතනවාද? එය දත්ත යථා තත්වයට පත් කරයිද?
එවැනි කිසිවක් නැත - එය ඒකාබද්ධ කිරීමක් සිදු කරයි, සහ පැරණි ලිපින කොතැනකවත් නොයනු ඇත, ඔබ ප්රවේශය අවහිර නොකරයි.
හුදකලා කිරීම පරීක්ෂා කිරීමේදී අපට දෝෂයක් හමු විය. දැන් තරමක් සංකීර්ණ පද්ධතියක් ඇත - ඒ වෙනුවට restore පවත්වනු ලැබේ create tempඑතකොට restore flush temp и restore temp. swap අවසානයේ: පරමාණුකත්වය සඳහා, ඔබ එය මුලින්ම කරන්නේ නම් flush සහ මේ මොහොතේ පැකට්ටුවක් පැමිණේ, එය ඉවත දමනු ඇති අතර යමක් වැරදී යනු ඇත. ඉතින් එතන කළු මැජික් ටිකක් තියෙනවා.
කොන්සල් kv get -datacenter=වෙනත්. මම කිව්වා වගේ අපි හිතන්නේ අපි දත්ත ටිකක් ඉල්ලනවා, නමුත් අපට දත්ත හෝ දෝෂයක් ලැබෙනු ඇත. අපට දේශීයව කොන්සල් හරහා මෙය කළ හැකිය, නමුත් මෙම නඩුවේදී දෙකම කැටි වනු ඇත.
ප්‍රාදේශීය කොන්සල් සේවාලාභියා HTTP API හරහා එතුමකි. නමුත් එය හුදෙක් එල්ලෙන අතර Ctrl+C, හෝ Ctrl+Z, හෝ ඕනෑම දෙයකට පමණක් ප්‍රතිචාර නොදක්වයි. kill -9 ඊළඟ කොන්සෝලය තුළ. අපි විශාල පොකුරක් ඉදිකරන විට මෙය හමු විය. නමුත් අපට තවමත් විසඳුමක් නැත; අපි කොන්සල් හි මෙම දෝෂය නිවැරදි කිරීමට සූදානම් වෙමු.
කොන්සල් නායකයා ප්‍රතිචාර දක්වන්නේ නැත. දත්ත මධ්‍යස්ථානයේ සිටින අපගේ ස්වාමියා ප්‍රතිචාර නොදක්වයි, අපි සිතන්නේ: “සමහර විට නැවත තෝරා ගැනීමේ ඇල්ගොරිතම දැන් ක්රියා කරයිද?”
නැත, එය ක්රියා නොකරනු ඇත, සහ අධීක්ෂණය කිසිවක් නොපෙන්වයි: කැපවීමේ දර්ශකයක් ඇති බව කොන්සල් පවසනු ඇත, නායකයෙකු සොයාගෙන ඇත, සියල්ල හොඳයි.
අපි මේ සමඟ කටයුතු කරන්නේ කෙසේද? service consul restart සෑම පැයකටම ක්‍රෝන් හි. ඔබට සේවාදායකයන් 50 ක් තිබේ නම්, ලොකු දෙයක් නැත. 16ක් ඉන්නකොට තේරෙයි කොහොමද වැඩේ කියලා.
නිගමනය
එහි ප්රතිඵලයක් ලෙස පහත සඳහන් වාසි අපට ලැබිණි.
- සියලුම Linux යන්ත්‍ර සඳහා 100% ආවරණය.
- වේගය.
- ස්වයංක්රීයකරණය.
- අපි දෘඪාංග සහ ජාල ඉංජිනේරුවන් වහල්භාවයෙන් නිදහස් කළා.
- ඒකාබද්ධ කිරීමේ හැකියාවන් අසීමිත ලෙස පෙනේ: කුබර්නෙටස් සමඟ වුවද, ඇන්සිබල් සමඟ වුවද, පයිතන් සමඟ පවා.
මිනිසු: කොන්සල්, අපට දැන් ජීවත් වීමට සිදු වන අතර, දෝෂයේ ඉතා ඉහළ පිරිවැය. උදාහරණයක් ලෙස, වරක් සවස 6 ට (රුසියාවේ ප්‍රමුඛ වේලාව) මම ජාල ලැයිස්තුවේ යමක් සංස්කරණය කරමින් සිටියෙමි. අපි ඒ වන විට BEFW හි පරිවරණය ගොඩනඟමින් සිටියෙමු. මම කොහේ හරි වැරැද්දක් කළා, පෙනෙන විදිහට මම වැරදි වෙස් මුහුණක් ඇඟෙව්වා, නමුත් සියල්ල තත්පර දෙකකින් වැටුණා. අධීක්ෂණය දැල්වෙයි, රාජකාරියේ යෙදී සිටින සහායක පුද්ගලයා දුව පැමිණේ: "අපට සියල්ල තිබේ!" මෙය සිදු වූයේ මන්දැයි ව්‍යාපාරයට පැහැදිලි කරන විට දෙපාර්තමේන්තු ප්‍රධානියා අළු පැහැයක් ගත්තේය.
දෝෂයේ පිරිවැය ඉතා ඉහළ බැවින් අපි අපගේම සංකීර්ණ වැළැක්වීමේ ක්රියා පටිපාටියක් ඉදිරිපත් කර ඇත්තෙමු. ඔබ මෙය විශාල නිෂ්පාදන අඩවියක ක්රියාත්මක කරන්නේ නම්, ඔබ සැමට කොන්සල් වෙත ප්රධාන ටෝකනයක් ලබා දීමට අවශ්ය නොවේ. මෙය නරක ලෙස අවසන් වනු ඇත.
පිරිවැය. මම තනියම පැය 400ක් කේතය ලිව්වා. 4 දෙනෙකුගෙන් යුත් මගේ කණ්ඩායම සෑම කෙනෙකුටම සහයෝගය දැක්වීම සඳහා මසකට පැය 10ක් වැය කරයි. ඕනෑම නව පරම්පරාවේ ෆයර්වෝලයක මිල හා සසඳන විට එය නොමිලේ.
සැලසුම්. දිගුකාලීන සැලැස්ම වන්නේ කොන්සල් වෙනුවට හෝ සම්පූර්ණ කිරීම සඳහා විකල්ප ප්රවාහනය සොයා ගැනීමයි. සමහර විට එය කෆ්කා හෝ ඒ හා සමාන දෙයක් විය හැකිය. නමුත් ඉදිරි වසරවලදී අපි කොන්සල් මත ජීවත් වනු ඇත.
ක්ෂණික සැලසුම්: Fail2ban සමඟ ඒකාබද්ධ වීම, අධීක්ෂණය සමඟ, nftables සමඟ, සමහර විට වෙනත් බෙදාහැරීම් සමඟ, ප්‍රමිතික, උසස් අධීක්ෂණ, ප්‍රශස්තකරණය. Kubernetes සහය ද සැලසුම්වල කොතැනක හෝ ඇත, මන්ද දැන් අපට පොකුරු කිහිපයක් සහ ආශාවක් ඇත.
සැලසුම් වලින් තවත්:
- ගමනාගමනයේ විෂමතා සෙවීම;
- ජාල සිතියම් කළමනාකරණය;
- Kubernetes සහාය;
- සියලුම පද්ධති සඳහා පැකේජ එකලස් කිරීම;
- වෙබ්-UI.
අපි වින්‍යාසය පුළුල් කිරීම, ප්‍රමිතික වැඩි කිරීම සහ ප්‍රශස්තිකරණය කිරීම සඳහා නිරන්තරයෙන් කටයුතු කරමින් සිටිමු.
ව්යාපෘතියට සම්බන්ධ වන්න. ව්‍යාපෘතිය සිසිල් එකක් බවට පත් වූ නමුත්, අවාසනාවකට මෙන්, එය තවමත් තනි පුද්ගල ව්‍යාපෘතියකි. වෙත එන්න සහ යමක් කිරීමට උත්සාහ කරන්න: කැපවීම, පරීක්ෂා කිරීම, යමක් යෝජනා කිරීම, ඔබේ තක්සේරුව ලබා දීම.
මේ අතර, අපි සූදානම් වෙමින් සිටිමු , එය අප්රේල් 6 සහ 7 යන දිනවල ශාන්ත පීටර්ස්බර්ග්හිදී පැවැත්වෙන අතර, අපි අධි බර පද්ධති සංවර්ධකයින්ට ආරාධනා කරමු. . පළපුරුදු කථිකයන් දැනටමත් කුමක් කළ යුතු දැයි දනී, නමුත් කතා කිරීමට අලුත් අය සඳහා අපි අවම වශයෙන් නිර්දේශ කරමු . කථිකයෙකු ලෙස සමුළුවට සහභාගී වීමෙන් වාසි ගණනාවක් ඇත. කුමන ඒවාදැයි ඔබට කියවිය හැකිය, උදාහරණයක් ලෙස, අවසානයේ .
මූලාශ්රය: www.habr.com