ප්රවේශයක් අයි.ඒ.සී. (කේතය ලෙස යටිතල පහසුකම්) ගබඩාවේ ගබඩා කර ඇති කේතය පමණක් නොව, මෙම කේතය වටා ඇති පුද්ගලයින් සහ ක්‍රියාවලීන් ද සමන්විත වේ. මෘදුකාංග සංවර්ධනයේ සිට යටිතල පහසුකම් කළමනාකරණය සහ විස්තරය දක්වා ප්රවේශයන් නැවත භාවිතා කළ හැකිද? ඔබ ලිපිය කියවන අතරතුර මෙම අදහස මතකයේ තබා ගැනීම හොඳ අදහසකි.
මේක මගේ පිටපතක් මත .
විනිවිදක සහ වීඩියෝ
- වියළි ධාවනය 2019-04-24
බැෂ් ඉතිහාසය ලෙස යටිතල පහසුකම්
ඔබ නව ව්‍යාපෘතියකට පැමිණ, ඔවුන් ඔබට මෙසේ කියයි: “අපට තිබේ කේතය ලෙස යටිතල පහසුකම්". යථාර්ථයේ දී එය හැරෙනවා බැෂ් ඉතිහාසය ලෙස යටිතල පහසුකම් හෝ උදාහරණයක් ලෙස බැෂ් ඉතිහාසය ලෙස ලේඛනගත කිරීම. මෙය ඉතා සැබෑ තත්වයකි, නිදසුනක් වශයෙන්, ඒ හා සමාන නඩුවක් ඩෙනිස් ලයිසෙන්කෝ විසින් කථාවකදී විස්තර කරන ලදී , bash ඉතිහාසයෙන් ඔවුන් ව්යාපෘතිය සඳහා සුසංයෝගී යටිතල පහසුකම් ලබා ගත් ආකාරය ඔහු කීවේය.
යම් ආශාවක් ඇතිව, අපට එය පැවසිය හැකිය බැෂ් ඉතිහාසය ලෙස යටිතල පහසුකම් මෙය කේතය වැනි ය:
- ප්රතිනිෂ්පාදනය: ඔබට bash ඉතිහාසය ගත හැකි අතර, එහි ඇති විධානයන් ක්රියාත්මක කළ හැකි අතර, ඔබට වැඩ කරන වින්‍යාසය ප්‍රතිදානයක් ලෙස ලබා ගත හැක.
- අනුවාදනය: ඔබ දන්නේ කවුද සහ ඔවුන් කළ දේ, නැවතත්, මෙය ඔබව පිටවීමේදී වැඩ කරන වින්‍යාසයකට ගෙන යනු ඇති බව සත්‍යයක් නොවේ.
- ඉතිහාසයක් ඇත: කවුද කළේ කියන කතාව. ඔබට සේවාදායකය නැති වුවහොත් පමණක් ඔබට එය භාවිතා කිරීමට නොහැකි වනු ඇත.
මම කළ යුත්තේ කුමක්ද?
කේතය ලෙස යටිතල පහසුකම්
වැනි අමුතු නඩුවක් පවා බැෂ් ඉතිහාසය ලෙස යටිතල පහසුකම් ඔබට එය කන් වලින් ඇද ගත හැකිය කේතය ලෙස යටිතල පහසුකම්, නමුත් අපට හොඳ පැරණි LAMP සේවාදායකයට වඩා සංකීර්ණ දෙයක් කිරීමට අවශ්ය වූ විට, මෙම කේතය කෙසේ හෝ වෙනස් කිරීම, වෙනස් කිරීම, වැඩිදියුණු කිරීම අවශ්ය බව අපි නිගමනය කරමු. ඊළඟට අපි අතර ඇති සමානකම් සලකා බැලීමට කැමැත්තෙමු කේතය ලෙස යටිතල පහසුකම් සහ මෘදුකාංග සංවර්ධනය.
ඩී.ආර්.වයි.
ගබඩා පද්ධති සංවර්ධන ව්‍යාපෘතියක, උප කාර්යයක් විය : අපි නව නිකුතුවක් නිකුත් කරන්නෙමු - එය වැඩිදුර පරීක්ෂා කිරීම සඳහා පෙරළීමට අවශ්‍යයි. කාර්යය අතිශයින්ම සරල ය:
- ssh හරහා මෙහි ලොග් වී විධානය ක්රියාත්මක කරන්න.
- ගොනුව එහි පිටපත් කරන්න.
- මෙහි වින්‍යාසය නිවැරදි කරන්න.
- එහි සේවාව ආරම්භ කරන්න
- ...
- ලාභය
විස්තර කරන ලද තර්කනය සඳහා, bash ප්රමාණවත් තරම් වැඩි ය, විශේෂයෙන්ම ව්යාපෘතියේ මුල් අදියරේදී, එය ආරම්භ වන විට. මෙය , නමුත් කාලයත් සමඟ සමාන, නමුත් තරමක් වෙනස් දෙයක් යෙදවීමට ඉල්ලීම් තිබේ. මතකයට එන පළමු දෙය කොපි පේස්ට් ය. දැන් අපට දැනටමත් එකම දේ කරන ඉතා සමාන ස්ක්‍රිප්ට් දෙකක් තිබේ. කාලයාගේ ඇවෑමෙන්, ස්ක්‍රිප්ට් ගණන වැඩි වූ අතර, විවිධ ස්ක්‍රිප්ට් අතර සමමුහුර්ත කළ යුතු ස්ථාපනයක් යෙදවීම සඳහා යම් ව්‍යාපාරික තර්කයක් ඇති බවට අපට මුහුණ දීමට සිදු විය, මෙය තරමක් සංකීර්ණ ය.
D.R.Y වැනි භාවිතයක් ඇති බව පෙනී යයි. (නැවත නැවත කියන්න එපා). අදහස වන්නේ පවතින කේතය නැවත භාවිතා කිරීමයි. එය සරල බව පෙනේ, නමුත් අපි වහාම මේ වෙත පැමිණියේ නැත. අපගේ නඩුවේදී, එය අශෝභන අදහසක් විය: ස්ක්‍රිප්ට් වලින් වින්‍යාසයන් වෙන් කිරීම. එම. ස්ථාපනය වෙන වෙනම යොදවා ඇති ආකාරය පිළිබඳ ව්‍යාපාරික තර්කනය, වෙන වෙනම වින්‍යාස කිරීම.
ඝණ. CFM සඳහා
කාලයත් සමඟ ව්යාපෘතිය වර්ධනය විය ඇන්සිබල්ගේ මතුවීම විය. එහි පෙනුම සඳහා ප්රධාන හේතුව වන්නේ කණ්ඩායමේ විශේෂඥ දැනුමක් තිබීම සහ bash සංකීර්ණ තර්කනය සඳහා නිර්මාණය කර නොමැති බවයි. Ansible ද සංකීර්ණ තර්කයක් අඩංගු වීමට පටන් ගත්තේය. සංකීර්ණ තර්කනය අවුල් සහගත බවට හැරවීම වැළැක්වීම සඳහා, මෘදුකාංග සංවර්ධනයේදී කේතය සංවිධානය කිරීම සඳහා මූලධර්ම තිබේ ඝණ. එසේම, උදාහරණයක් ලෙස, Grigory Petrov වාර්තාවේ "තොරතුරු තාක්ෂණ විශේෂඥයෙකුට පුද්ගලික සන්නාමයක් අවශ්ය වන්නේ ඇයි" යන ප්රශ්නය මතු කළේ, මෘදුකාංග සංවර්ධනයේ දී, යම් පුද්ගලයෙකු යම් සමාජ ආයතන සමඟ ක්රියා කිරීමට පහසු වන පරිදි නිර්මාණය කර තිබේද යන්නයි. වස්තූන් වේ. අපි මෙම අදහස් දෙක ඒකාබද්ධ කර ඒවා දිගටම වර්ධනය කරන්නේ නම්, අපට ද භාවිතා කළ හැකි බව අපට පෙනෙනු ඇත ඝණ. අනාගතයේදී මෙම තර්කනය පවත්වාගෙන යාම සහ වෙනස් කිරීම පහසු කිරීම සඳහා.
තනි වගකීම් මූලධර්මය
සෑම පන්තියක්ම එක් කාර්යයක් පමණක් ඉටු කරයි.
කේතය මිශ්‍ර කර මොනොලිතික් දිව්‍ය ස්පැගටි රාක්ෂයන් සෑදීමට අවශ්ය නැත. යටිතල පහසුකම් සරල ගඩොල්වලින් සමන්විත විය යුතුය. ඔබ Ansible playbook කුඩා කැබලිවලට බෙදුවහොත්, Ansible භූමිකාවන් කියවන්නේ නම්, ඒවා නඩත්තු කිරීමට පහසු බව පෙනේ.
විවෘත සංවෘත මූලධර්මය
විවෘත / සංවෘත මූලධර්මය.
- දිගුව සඳහා විවෘත: නව ආයතන වර්ග නිර්මාණය කිරීමෙන් ආයතනයක හැසිරීම දිගු කළ හැකි බව අදහස් වේ.
- වෙනස් කිරීමට වසා ඇත: ආයතනයක හැසිරීම දිගු කිරීමේ ප්රතිඵලයක් ලෙස, එම ආයතන භාවිතා කරන කේතයට කිසිදු වෙනසක් සිදු නොකළ යුතුය.
මුලදී, අපි අතථ්‍ය යන්ත්‍ර මත පරීක්ෂණ යටිතල පහසුකම් යෙදුවෙමු, නමුත් යෙදවීමේ ව්‍යාපාරික තර්කය ක්රියාත්මක කිරීමෙන් වෙන් වූ නිසා, අපි කිසිදු ගැටළුවක් නොමැතිව baremetall වෙත පෙරළීම එකතු කළෙමු.
ලිස්කොව් ආදේශන මූලධර්මය
බාබරා ලිස්කොව්ගේ ආදේශන මූලධර්මය. වැඩසටහනක ඇති වස්තූන් වැඩසටහන නිවැරදිව ක්රියාත්මක කිරීම වෙනස් නොකර ඒවායේ උප වර්ගවල අවස්ථා සමඟ ප්‍රතිස්ථාපනය කළ යුතුය.
ඔබ එය වඩාත් පුළුල් ලෙස බැලුවහොත්, එය එහි යෙදිය හැකි විශේෂිත ව්‍යාපෘතියක ලක්ෂණයක් නොවේ ඝණ., එය සාමාන්යයෙන් CFM ගැන වේ, උදාහරණයක් ලෙස, වෙනත් ව්‍යාපෘතියක විවිධ ජාවා, යෙදුම් සේවාදායක, දත්ත සමුදායන්, OS යනාදිය මත කොටු ජාවා යෙදුමක් යෙදවීම අවශ්ය වේ. මෙම උදාහරණය භාවිතා කරමින්, මම තවත් මූලධර්ම සලකා බලමි ඝණ.
අපගේ නඩුවේදී, අපි imbjava හෝ oraclejava භූමිකාව ස්ථාපනය කර ඇත්නම්, අපට java binary executable එකක් ඇති බවට යටිතල පහසුකම් කණ්ඩායම තුළ එකඟතාවයක් ඇත. මෙය අවශ්ය නිසා Upstream භූමිකා මෙම හැසිරීම මත රඳා පවතී; ඔවුන් java අපේක්ෂා කරයි. ඒ අතරම, යෙදුම් යෙදවීමේ තර්කය වෙනස් නොකර එක් java ක්රියාත්මක කිරීමක්/අනුවාදයක් තවත් එකක් සමඟ ප්‍රතිස්ථාපනය කිරීමට මෙය අපට ඉඩ සලසයි.
මෙහි ප්රශ්නය පවතින්නේ කණ්ඩායම තුළ යම් එකඟතා මතුවන ප්රතිඵලයක් ලෙස මෙය Ansible තුළ ක්රියාත්මක කළ නොහැකි වීමයි.
අතුරු මුහුණත වෙන් කිරීමේ මූලධර්මය
අතුරුමුහුණත් වෙන් කිරීමේ මූලධර්මය: “බොහෝ සේවාදායක විශේෂිත අතුරුමුහුණත් එක් පොදු කාර්ය අතුරු මුහුණතකට වඩා හොඳය.
මුලදී, අපි යෙදුම් යෙදවීමේ සියලුම විචල්‍යයන් එක් ඇන්සිබල් ක්‍රීඩා පොතකට දැමීමට උත්සාහ කළෙමු, නමුත් එයට සහාය වීම දුෂ්කර වූ අතර, අපට බාහිර අතුරු මුහුණතක් නිශ්චිතව ඇති විට ප්රවේශය (සේවාදායකයා වරාය 443 අපේක්ෂා කරයි), එවිට යටිතල පහසුකම් තනි තනිව එකලස් කළ හැකිය. නිශ්චිත ක්රියාත්මක කිරීම සඳහා ගඩොල්.
යැපුම් ප්‍රතිලෝම මූලධර්මය
පරායත්තතා ප්‍රතිලෝමයේ මූලධර්මය. ඉහළ මට්ටම්වල ඇති මොඩියුල පහළ මට්ටමේ මොඩියුල මත රඳා නොපවතී. මොඩියුල වර්ග දෙකම වියුක්තයන් මත රඳා පැවතිය යුතුය. වියුක්ත කිරීම් විස්තර මත රඳා නොපවතී. විස්තර වියුක්තයන් මත රඳා පැවතිය යුතුය.
මෙහි උදාහරණය ප්‍රති රටාවක් මත පදනම් වේ.
- එක් පාරිභෝගිකයෙකුට පුද්ගලික වලාකුළක් තිබුණි.
- අපි වලාකුළ තුළ අතථ්‍ය යන්ත්‍ර ඇණවුම් කළෙමු.
- නමුත් වලාකුළේ ස්වභාවය නිසා, යෙදුම් යෙදවීම VM එක ක්රියාත්මක වූ හයිපර්වයිසරයට සම්බන්ධ විය.
එම. අධි-මට්ටමේ යෙදවුම් තාර්කික පරායත්තතාවයන් සමඟ අධි වයිසරයේ පහළ මට්ටම් වෙත ගලා ගිය අතර, මෙම තර්කය නැවත භාවිතා කිරීමේදී ගැටළු ඇති විය. මේ විදියට කරන්න එපා.
අන්තර් ක්රියාකාරිත්වය
කේතය ලෙස යටිතල පහසුකම් යනු කේතය පමණක් නොව, කේතය සහ පුද්ගලයින් අතර සම්බන්ධය, යටිතල පහසුකම් සංවර්ධකයින් අතර අන්තර්ක්රියා පිළිබඳව ද වේ.
බස් සාධකය
අපි හිතමු ඔබේ ව්යාපෘතියේ ඔබට Vasya ඉන්නවා කියලා. Vasya ඔබේ යටිතල පහසුකම් ගැන සියල්ල දන්නවා, Vasya හදිසියේම අතුරුදහන් වුවහොත් කුමක් සිදුවේද? මෙය ඉතා සැබෑ තත්වයකි, මන්ද ඔහු බස් රථයක හැප්පිය හැකිය. සමහර විට එය සිදු වේ. මෙය සිදුවන්නේ නම් සහ කේතය, එහි ව්‍යුහය, එය ක්රියා කරන ආකාරය, පෙනුම සහ මුරපද පිළිබඳ දැනුම කණ්ඩායම අතර බෙදා නොගන්නේ නම්, ඔබට අප්‍රසන්න අවස්ථා ගණනාවකට මුහුණ දිය හැකිය. මෙම අවදානම් අවම කිරීම සහ කණ්ඩායම තුළ දැනුම බෙදා හැරීම සඳහා, ඔබට විවිධ ප්රවේශයන් භාවිතා කළ හැකිය
යුගල Devopsing
ඒක වගේ නෙවෙයි , පරිපාලකයින් බියර් පානය කිරීම, මුරපද වෙනස් කිරීම සහ යුගල ක්‍රමලේඛනයේ ප්‍රතිසමයක් බව. එම. ඉංජිනේරුවන් දෙදෙනෙකු එක් පරිගණකයක, එක් යතුරු පුවරුවක වාඩි වී ඔබේ යටිතල පහසුකම් එකට සැකසීම ආරම්භ කරන්න: සේවාදායකයක් සැකසීම, ඇන්සිබල් භූමිකාවක් ලිවීම යනාදිය. එය ලස්සනයි, නමුත් එය අපට වැඩ කළේ නැත. නමුත් මෙම භාවිතයේ විශේෂ අවස්ථා සාර්ථක විය. නව සේවකයෙකු පැමිණේ, ඔහුගේ උපදේශකයා ඔහු සමඟ එක්ව සැබෑ කාර්යයක් භාර ගනී, වැඩ කර දැනුම මාරු කරයි.
තවත් විශේෂ අවස්ථාවක් වන්නේ සිදුවීම් ඇමතුමකි. ගැටලුවක් අතරතුර, රාජකාරියේ යෙදී සිටින සහ සම්බන්ධ වූවන්ගේ කණ්ඩායමක් එක්රැස් වන අතර, එක් නායකයෙකු පත් කරනු ලැබේ, ඔහු ඔහුගේ තිරය බෙදාගෙන සිතුවිලි දුම්රියට හඬ නඟයි. අනෙකුත් සහභාගිවන්නන් නායකයාගේ සිතුවිලි අනුගමනය කරයි, කොන්සෝලයෙන් උපක්‍රම පිළිබඳ ඔත්තු බලන්න, ඔවුන් ලොගයේ රේඛාවක් අතපසු කර නැති බව පරීක්ෂා කරන්න, සහ පද්ධතිය පිළිබඳ අලුත් දේවල් ඉගෙන ගන්න. මෙම ප්රවේශය බොහෝ විට වැඩ කළේ නැත.
කේත සමාලෝචනය
විෂයානුබද්ධව, යටිතල පහසුකම් සහ එය කේත සමාලෝචනය භාවිතයෙන් ක්රියා කරන ආකාරය පිළිබඳ දැනුම බෙදා හැරීම වඩාත් ඵලදායී විය:
- යටිතල පහසුකම් ගබඩාවේ කේතය මගින් විස්තර කෙරේ.
- වෙනස්කම් වෙනම ශාඛාවක සිදු වේ.
- ඒකාබද්ධ කිරීමේ ඉල්ලීමක් අතරතුර, යටිතල ව්‍යුහයේ වෙනස්කම් වල ඩෙල්ටාව ඔබට දැක ගත හැක.
මෙහි විශේෂත්වය වූයේ කාලසටහනකට අනුව විචාරකයින් එකින් එක තෝරා ගැනීමයි, i.e. යම් තරමක සම්භාවිතාවක් සමඟ ඔබ නව යටිතල පහසුකම් කොටසකට නැඟී යනු ඇත.
කේත විලාසය
කාලයාගේ ඇවෑමෙන්, සමාලෝචන අතරතුර රණ්ඩු දබර ඇති විය, මන්ද ... සමාලෝචකයින්ට ඔවුන්ගේම ශෛලියක් තිබූ අතර සමාලෝචකයන්ගේ භ්‍රමණය විවිධ මෝස්තරවලින් ඒවා ගොඩගැසී ඇත: හිස්තැන් 2ක් හෝ 4ක්, කැමල්කේස් හෝ සර්ප_කේස්. මෙය වහාම ක්රියාත්මක කිරීමට නොහැකි විය.
- පළමු අදහස වූයේ ලින්ටර් භාවිතා කිරීම නිර්දේශ කිරීමයි, සියල්ලට පසු, සෑම කෙනෙකුම ඉංජිනේරුවන් ය, සෑම කෙනෙකුම බුද්ධිමත් ය. නමුත් විවිධ සංස්කාරකවරුන්, OS, පහසු නොවේ
- මෙය එක් එක් ගැටළුකාරී කැපවීම සඳහා ස්ලැක් කිරීමට ලියූ සහ ලින්ටර් ප්‍රතිදානය අමුණා ඇති බොට් එකක් බවට පරිණාමය විය. නමුත් බොහෝ අවස්ථාවලදී සිදු කිරීමට වඩා වැදගත් දේවල් තිබූ අතර කේතය ස්ථාවර නොවී පැවතුනි.
හරිත ගොඩනැගීමේ මාස්ටර්
කාලය ගෙවී යන අතර, ඇතැම් පරීක්ෂණ සමත් නොවන කැපවීම්වලට ස්වාමියා තුළට ඉඩ දිය නොහැකි බව අපි නිගමනය කර ඇත්තෙමු. Voila! අපි ග්‍රීන් බිල්ඩ් මාස්ටර් සොයා ගත්තෙමු, එය දිගු කලක් තිස්සේ මෘදුකාංග සංවර්ධනයේ යෙදී ඇත:
- වෙනම ශාඛාවක සංවර්ධනය සිදුවෙමින් පවතී.
- මෙම ත්‍රෙඩ් එකේ පරීක්ෂණ ක්රියාත්මක වේ.
- පරීක්ෂණ අසමත් වුවහොත්, කේතය එය මාස්ටර් බවට පත් නොකරයි.
මෙම තීරණය ගැනීම ඉතා වේදනාකාරී විය, මන්ද ... මතභේදයට තුඩු දුන් නමුත් එය වටිනවා, මන්ද ... සමාලෝචන ශෛලියේ වෙනස්කම් නොමැතිව ඒකාබද්ධ කිරීම් සඳහා ඉල්ලීම් ලැබීමට පටන් ගත් අතර කාලයත් සමඟ ගැටළු සහිත ප්රදේශ ගණන අඩු වීමට පටන් ගත්තේය.
IaC පරීක්ෂණය
විලාස පරීක්ෂාවට අමතරව, ඔබට වෙනත් දේවල් භාවිතා කළ හැකිය, උදාහරණයක් ලෙස, ඔබේ යටිතල පහසුකම් ඇත්ත වශයෙන්ම යෙදවිය හැකිදැයි පරීක්ෂා කිරීමට. නැතහොත් යටිතල පහසුකම්වල වෙනස්කම් මුදල් අහිමි වීමට හේතු නොවන බව පරීක්ෂා කරන්න. මෙය අවශ්ය විය හැක්කේ ඇයි? ප්රශ්නය සංකීර්ණ සහ දාර්ශනික ය, කෙසේ හෝ මායිම් කොන්දේසි පරීක්ෂා නොකළ ස්වයංක්‍රීය පරිමාණයක් පවර්ෂෙල් හි තිබූ බවට කතාවකින් පිළිතුරු දීම වඩා හොඳය => අවශ්ය ප්‍රමාණයට වඩා VM නිර්මාණය කර ඇත => සේවාදායකයා සැලසුම් කළ ප්‍රමාණයට වඩා වැඩි මුදලක් වියදම් කළේය. මෙය ඉතා ප්රසන්න නොවේ, නමුත් මුල් අදියරේදී මෙම දෝෂය අල්ලා ගැනීමට බෙහෙවින් හැකි වනු ඇත.
සංකීර්ණ යටිතල ව්‍යුහය වඩාත් සංකීර්ණ කරන්නේ ඇයි දැයි කෙනෙකුට ඇසිය හැකිය. යටිතල පහසුකම් සඳහා වන පරීක්ෂණ, කේතය සඳහා මෙන්ම, සරල කිරීම ගැන නොව, ඔබේ යටිතල ව්‍යුහය ක්රියා කළ යුතු ආකාරය දැන ගැනීමයි.
IaC පරීක්ෂණ පිරමීඩය
IaC පරීක්ෂාව: ස්ථිතික විශ්ලේෂණය
ඔබ සම්පූර්ණ යටිතල ව්‍යුහයම එකවර යොදවා එය ක්රියාත්මක වන්නේ දැයි පරීක්ෂා කරන්නේ නම්, එය බොහෝ කාලයක් ගත වන අතර බොහෝ කාලයක් අවශ්ය බව ඔබට පෙනී යා හැක. එමනිසා, පදනම ඉක්මනින් ක්රියා කරන දෙයක් විය යුතුය, එය ගොඩක් තිබේ, එය ප්රාථමික ස්ථාන ගොඩක් ආවරණය කරයි.
බාෂ් කපටියි
අපි සුළු උදාහරණයක් බලමු. වත්මන් නාමාවලියෙහි ඇති සියලුම ගොනු තෝරා වෙනත් ස්ථානයකට පිටපත් කරන්න. මතකයට එන පළමු දෙය:
for i in * ; do
cp $i /some/path/$i.bak
doneගොනු නාමයේ ඉඩක් තිබේ නම් කුමක් කළ යුතුද? හොඳයි, හරි, අපි දක්ෂයි, අපි උද්ධෘත භාවිතා කරන්නේ කෙසේදැයි දනිමු:
for i in * ; do cp "$i" "/some/path/$i.bak" ; doneහොඳින් කළා? නැත! නාමාවලියෙහි කිසිවක් නොමැති නම්, i.e. globbing වැඩ කරන්නේ නැහැ.
find . -type f -exec mv -v {} dst/{}.bak ;දැන් හොදද? නැහැ... ගොනු නාමයේ විය හැකි දේ අමතක විය n.
touch x
mv x "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dirස්ථිතික විශ්ලේෂණ මෙවලම්
පෙර පියවරේ ඇති ගැටළුව අපට උපුටා දැක්වීම් අමතක වූ විට අල්ලා ගත හැකිය, මේ සඳහා සොබාදහමේ බොහෝ පිළියම් තිබේ , සාමාන්යයෙන් ඒවායින් බොහොමයක් ඇති අතර, බොහෝ විට ඔබට ඔබේ IDE යටතේ ඔබේ තොගය සඳහා ලින්ටරයක් සොයාගත හැකිය.
භාෂා
මෙවලම
බෂ්
රූබි
පිඹුරා
පිළිතුරු
IaC පරීක්ෂණ: ඒකක පරීක්ෂණ
පෙර උදාහරණයෙන් අප දුටු පරිදි, ලින්ටර් සර්වබලධාරී නොවන අතර ගැටළු ඇති සියලුම ප්රදේශ පෙන්වා දිය නොහැක. තවද, මෘදුකාංග සංවර්ධනයේ පරීක්ෂණ හා සමානව, අපට ඒකක පරීක්ෂණ සිහිපත් කළ හැකිය. එකපාරටම මතක් වෙන දේ තමයි , , , . නමුත් ansible, chef, saltstack සහ ඔවුන් වැනි වෙනත් අය සමඟ කුමක් කළ යුතුද?
ආරම්භයේදීම අපි කතා කළා ඝණ. සහ අපගේ යටිතල පහසුකම් කුඩා ගඩොල්වලින් සමන්විත විය යුතුය. ඔවුන්ගේ කාලය පැමිණ ඇත.
- යටිතල පහසුකම් කුඩා ගඩොල්වලට බෙදී ඇත, උදාහරණයක් ලෙස, Ansible භූමිකාවන්.
- යම් ආකාරයක පරිසරයක් යොදවා ඇත, එය docker හෝ VM වේ.
- අපි අපගේ Ansible භූමිකාව මෙම පරීක්ෂණ පරිසරයට යොදන්නෙමු.
- අපි බලාපොරොත්තු වූ පරිදි සෑම දෙයක්ම ක්රියාත්මක වූ බව අපි පරීක්ෂා කරමු (අපි පරීක්ෂණ පවත්වමු).
- හරිද නැද්ද කියලා අපි තීරණය කරනවා.
IaC පරීක්ෂණ: ඒකක පරීක්ෂණ මෙවලම්
ප්රශ්නය, CFM සඳහා වන පරීක්ෂණ මොනවාද? ඔබට සරලව ස්ක්‍රිප්ට් ධාවනය කළ හැකිය, නැතහොත් ඔබට මේ සඳහා සූදානම් කළ විසඳුම් භාවිතා කළ හැකිය:
සීඑෆ්එම්
මෙවලම
පිළිතුරු
හිස
හිස
ලුණු මිටි
testinfra සඳහා උදාහරණය, පරිශීලකයන් පරීක්ෂා කිරීම test1, test2 පවතින අතර සමූහයක සිටිති sshusers:
def test_default_users(host):
users = ['test1', 'test2' ]
for login in users:
assert host.user(login).exists
assert 'sshusers' in host.user(login).groupsතෝරා ගත යුත්තේ කුමක්ද? ප්රශ්නය සංකීර්ණ සහ අපැහැදිලි ය, 2018-2019 සඳහා github හි ව්‍යාපෘතිවල වෙනස්කම් පිළිබඳ උදාහරණයක් මෙන්න:
IaC පරීක්ෂණ රාමු
ප්රශ්නය පැනනගින්නේ: සියල්ල එකට එකතු කර එය දියත් කරන්නේ කෙසේද? පුළුවන් ප්රමාණවත් ඉංජිනේරුවන් සංඛ්‍යාවක් සිටී නම්. නැතහොත් ඒවායින් බොහොමයක් නොමැති වුවද ඔබට සූදානම් කළ විසඳුම් ගත හැකිය:
සීඑෆ්එම්
මෙවලම
පිළිතුරු
හිස
භූමිෂ් .ය
2018-2019 සඳහා github හි ව්‍යාපෘතිවල වෙනස්කම් සඳහා උදාහරණය:
අණු එදිරිව. ටෙස්ට් කුස්සිය
මුලදී අපි :
- සමාන්තරව VM එකක් සාදන්න.
- Ansible භූමිකාවන් යොදන්න.
- පරීක්ෂාව ධාවනය කරන්න.
25-35 භූමිකාවන් සඳහා එය විනාඩි 40-70 ක් වැඩ කළ අතර එය දිගු විය.
ඊළඟ පියවර වූයේ jenkins/docker/ansible/molecule වෙත සංක්‍රමණය වීමයි. දෘෂ්ටිවාදාත්මකව සෑම දෙයක්ම සමාන වේ
- ලින්ට් සෙල්ලම් පොත්.
- භූමිකාවන් පෙළගස්වන්න.
- කන්ටේනරය දියත් කරන්න
- Ansible භූමිකාවන් යොදන්න.
- testinfra ධාවනය කරන්න.
- දුර්වලතාවය පරීක්ෂා කරන්න.
භූමිකාවන් 40 ක් සඳහා ලින්ටින් කිරීම සහ දුසිමක් සඳහා පරීක්ෂණ විනාඩි 15 ක් පමණ ගත විය.
තෝරා ගත යුතු දේ බොහෝ සාධක මත රඳා පවතී, එනම් භාවිතා කරන ලද තොගය, කණ්ඩායමේ විශේෂඥතාව යනාදිය. මෙහිදී සෑම කෙනෙකුම තමන් විසින්ම තීරණය කරනුයේ ඒකක පරීක්ෂණ ප්රශ්නය වසා දමන්නේ කෙසේද යන්නයි
IaC පරීක්ෂණ: ඒකාබද්ධතා පරීක්ෂණ
යටිතල පහසුකම් පරීක්ෂණ පිරමීඩයේ ඊළඟ පියවර වනුයේ ඒකාබද්ධතා පරීක්ෂණ වේ. ඒවා ඒකක පරීක්ෂණ වලට සමාන වේ:
- යටිතල පහසුකම් කුඩා ගඩොල් වලට බෙදී ඇත, උදාහරණයක් ලෙස Ansible භූමිකාවන්.
- යම් ආකාරයක පරිසරයක් යොදවා ඇත, එය docker හෝ VM වේ.
- මෙම පරීක්ෂණ පරිසරය සඳහා අයදුම් කරන්න බොහෝ වගකිවයුතු භූමිකාවන්.
- අපි බලාපොරොත්තු වූ පරිදි සෑම දෙයක්ම ක්රියාත්මක වූ බව අපි පරීක්ෂා කරමු (අපි පරීක්ෂණ පවත්වමු).
- හරිද නැද්ද කියලා අපි තීරණය කරනවා.
දළ වශයෙන් කිවහොත්, අපි ඒකක පරීක්ෂණ වලදී මෙන් පද්ධතියේ තනි මූලද්‍රව්‍යයක ක්රියාකාරිත්වය පරීක්ෂා නොකරමු, සමස්තයක් ලෙස සේවාදායකය වින්‍යාස කර ඇති ආකාරය අපි පරීක්ෂා කරමු.
IaC පරීක්ෂාව: අවසානය සිට අවසානය දක්වා පරීක්ෂණ
පිරමීඩයේ මුදුනේ අපව පිළිගන්නේ අන්තයේ සිට අවසානය දක්වා පරීක්ෂණ. එම. අපි වෙනම සේවාදායකයක, වෙනම ස්ක්‍රිප්ට් එකක හෝ අපගේ යටිතල ව්‍යුහයේ වෙනම ගඩොල්වල ක්රියාකාරිත්වය පරීක්ෂා නොකරමු. බොහෝ සේවාදායකයන් එකට සම්බන්ධ වී ඇති බව අපි පරීක්ෂා කරමු, අපගේ යටිතල පහසුකම් අප බලාපොරොත්තු වන පරිදි ක්රියා කරයි. අවාසනාවකට, මම කවදාවත් සූදානම් පෙට්ටි විසඳුම් දැකලා නැහැ, බොහෝ විට ... යටිතල ව්‍යුහය බොහෝ විට අද්විතීය වන අතර සැකිලි කිරීමට සහ පරීක්ෂණ සඳහා රාමුවක් නිර්මාණය කිරීමට අපහසු වේ. එහි ප්රතිඵලයක් වශයෙන්, සෑම කෙනෙකුම තමන්ගේම විසඳුම් නිර්මාණය කරයි. ඉල්ලුමක් ඇත, නමුත් පිළිතුරක් නැත. එමනිසා, සෑම දෙයක්ම අපට පෙර බොහෝ කලකට පෙර සොයා ගන්නා ලද නිසා අන් අයව හොඳ සිතුවිලි වලට තල්ලු කිරීමට හෝ මගේ නාසය අතුල්ලන්නට ඇති දේ මම ඔබට කියමි.
පොහොසත් ඉතිහාසයක් ඇති ව්යාපෘතියක්. එය විශාල සංවිධානවල භාවිතා වන අතර බොහෝ විට ඔබ සෑම කෙනෙකුම එය සමඟ වක්‍රව හරස් වී ඇත. යෙදුම බොහෝ දත්ත සමුදායන්, ඒකාබද්ධ කිරීම් ආදිය සඳහා සහය දක්වයි. යටිතල ව්‍යුහය කෙබඳු විය හැකිද යන්න දැන ගැනීම ඩොකර්-රචනය කරන ගොනු රාශියක් වන අතර කුමන පරිසරයක ක්රියාත්මක විය යුතුදැයි දැන ගැනීම ජෙන්කින්ස් වේ.
මෙම යෝජනා ක්‍රමය රාමුව තුළ තෙක් සෑහෙන කාලයක් ක්රියාත්මක විය අපි මෙය Openshift වෙත මාරු කිරීමට උත්සාහ කර නැත. බහාලුම් එලෙසම පවතී, නමුත් දියත් කිරීමේ පරිසරය වෙනස් වී ඇත (ආයෙත් ආයුබෝවන් D.R.Y.).
පර්යේෂණ අදහස තවත් ඉදිරියට ගිය අතර, openshift වලදී ඔවුන් APB (Ansible Playbook Bundle) වැනි දෙයක් සොයා ගන්නා ලදී, එමඟින් ඔබට යටිතල පහසුකම් කන්ටේනරයක් තුළට යෙදවිය යුතු ආකාරය පිළිබඳ දැනුම ඇසුරුම් කිරීමට ඉඩ සලසයි. එම. යටිතල ව්‍යූහය යෙදවිය යුතු ආකාරය පිළිබඳව නැවත නැවතත් පරීක්ෂා කළ හැකි දැනුමක් ඇත.
අපි විෂමජාතීය යටිතල ව්‍යූහයකට දිව යන තෙක් මේ සියල්ල හොඳින් ඇසුණි: අපට පරීක්ෂණ සඳහා වින්ඩෝස් අවශ්ය විය. එහි ප්රතිඵලයක් වශයෙන්, කුමක්, කොතැනද, යෙදවිය යුතු ආකාරය සහ පරීක්ෂා කිරීම පිළිබඳ දැනුම ජෙන්කින්ස් තුළ පවතී.
නිගමනය
කේතය ලෙස යටිතල පහසුකම්
- ගබඩාවේ කේතය.
- මානව අන්තර්ක්රියා.
- යටිතල පහසුකම් පරීක්ෂා කිරීම.
සබැඳි
- වියළි ධාවනය 2019-04-24
- &
මූලාශ්රය: www.habr.com