මම අනුන්ගෙ Ansible code එක ගොඩක් Review කරනවා වගේම ගොඩක් ලියන්නෙත් මමමයි. වැරදි විශ්ලේෂණය කිරීමේදී (අනෙක් අයගේ සහ මගේම) මෙන්ම සම්මුඛ සාකච්ඡා ගණනාවකදී, ඇන්සිබල් පරිශීලකයින් කරන ප්‍රධාන වැරැද්ද මට වැටහුණි - ඔවුන් මූලික ඒවා ප්‍රගුණ නොකර සංකීර්ණ දේවලට වැටේ.

මෙම විශ්වීය අසාධාරණය නිවැරදි කිරීම සඳහා, එය දැනටමත් දන්නා අය සඳහා Ansible වෙත හැඳින්වීමක් ලිවීමට මම තීරණය කළෙමි. මම ඔබට අනතුරු අඟවමි, මෙය මිනිසුන්ගේ නැවත කියවීමක් නොවේ, මෙය අකුරු ගොඩක් සහ පින්තූර නොමැති දිගු කියවීමකි.

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

නම්

Ansible පරිශීලකයෙකු කරන ප්‍රධාන වැරැද්ද නම් යමක් හඳුන්වන්නේ කුමක්දැයි නොදැන සිටීමයි. ඔබ නම් නොදන්නේ නම්, ලේඛනයේ සඳහන් දේ ඔබට තේරුම් ගත නොහැක. ජීවමාන උදාහරණයක්: සම්මුඛ සාකච්ඡාවකදී, ඔහු Ansible හි බොහෝ දේ ලියා ඇති බව පවසන පුද්ගලයෙකුට “ක්‍රීඩා පොතක් සමන්විත වන්නේ කුමන අංගයන්ගෙන්ද?” යන ප්‍රශ්නයට පිළිතුරු දිය නොහැකි විය. “ප්‍රතිචාරය බලාපොරොත්තු වූයේ ක්‍රීඩා පොත ක්‍රීඩාවෙන් සමන්විත වන බව” මා යෝජනා කළ විට, “අපි එය භාවිතා නොකරමු” යන භයානක ප්‍රකාශය අනුගමනය කළේය. මිනිස්සු Ansible ලියන්නේ සල්ලි වලට මිසක් play කරන්න එපා. ඔවුන් එය සැබවින්ම භාවිතා කරයි, නමුත් එය කුමක්දැයි නොදනී.

එබැවින් අපි සරල දෙයකින් පටන් ගනිමු: එය හඳුන්වන්නේ කුමක්ද? ඔබ ලේඛන කියවීමේදී ඔබ අවධානය යොමු නොකළ නිසා සමහර විට ඔබ මෙය දන්නවා හෝ සමහර විට ඔබ නොදන්නවා විය හැකිය.

ansible-playbook playbook ක්‍රියාත්මක කරයි. Playbook යනු yml/yaml දිගුව සහිත ගොනුවකි, එහි ඇතුළත මෙවැනි දෙයක් ඇත:

---
- hosts: group1
  roles:
    - role1

- hosts: group2,group3
  tasks:
    - debug:

මෙම සම්පූර්ණ ගොනුව ක්‍රීඩා පොතක් බව අපි දැනටමත් අවබෝධ කරගෙන සිටිමු. භූමිකාවන් කොතැනද සහ කාර්යයන් කොතැනද යන්න අපට පෙන්විය හැකිය. නමුත් සෙල්ලම් කොහෙද? සහ රංගනය සහ භූමිකාව හෝ නාට්‍ය පොත අතර වෙනස කුමක්ද?

ඒ ඔක්කොම ලියකියවිලි වල තියෙනවා. ඒ වගේම ඔවුන්ට එය මග හැරෙනවා. ආරම්භකයින් - ඕනෑවට වඩා ඇති නිසා සහ ඔබට එකවර සියල්ල මතක නැති නිසා. පළපුරුදු - "සුළු දේවල්" නිසා. ඔබ පළපුරුදු නම්, අවම වශයෙන් සෑම මාස හයකට වරක්වත් මෙම පිටු නැවත කියවන්න, එවිට ඔබේ කේතය පන්තියේ ප්‍රමුඛයා වනු ඇත.

එබැවින්, මතක තබා ගන්න: Playbook යනු ක්‍රීඩා වලින් සමන්විත ලැයිස්තුවකි import_playbook.
මෙය එක් නාට්යයකි:

- hosts: group1
  roles:
    - role1

මෙයද තවත් නාට්‍යයකි:

- hosts: group2,group3
  tasks:
    - debug:

රංගනය යනු කුමක්ද? ඇයි ඇය?

Play යනු ක්‍රීඩා පොතක් සඳහා ප්‍රධාන අංගයකි, මන්ද Play and play පමණක් භූමිකාවන් සහ/හෝ කාර්යයන් ක්‍රියාත්මක කළ යුතු සත්කාරක ලැයිස්තුවක් සමඟ සම්බන්ධ කරයි. ලේඛනවල ගැඹුරු ගැඹුරින් ඔබට සඳහනක් සොයාගත හැකිය delegate_to, දේශීය සෙවීම් ප්ලගින, ජාල-ක්ලි-විශේෂිත සැකසුම්, පැනීමේ සත්කාරක, ආදිය. කාර්යයන් සිදු කරන ස්ථානය තරමක් වෙනස් කිරීමට ඒවා ඔබට ඉඩ සලසයි. නමුත්, එය අමතක කරන්න. මෙම සෑම දක්ෂ විකල්පයකටම නිශ්චිත භාවිතයන් ඇති අතර, ඒවා නියත වශයෙන්ම විශ්වීය නොවේ. ඒ වගේම අපි හැමෝම දැනගෙන භාවිතා කළ යුතු මූලික දේවල් ගැන කතා කරනවා.

ඔබට "යමක්" "කොහේ හරි" ඉටු කිරීමට අවශ්ය නම්, ඔබ නාට්යය ලියන්න. භූමිකාවක් නොවේ. මොඩියුල සහ නියෝජිතයන් සමඟ භූමිකාවක් නොවේ. ඔයා ඒක අරන් නාට්‍ය ලියන්න. එහිදී, ධාරක ක්ෂේත්‍රයේ ඔබ ක්‍රියාත්මක කළ යුතු ස්ථානය ලැයිස්තුගත කරයි, සහ භූමිකාවන්/කාර්යයන් - ක්‍රියාත්මක කළ යුතු දේ.

සරලයි නේද? එය එසේ නොවන්නේ කෙසේද?

මිනිසුන්ට මෙය ක්‍රීඩාවෙන් නොව කිරීමට ආශාවක් ඇති විට එක් ලාක්ෂණික අවස්ථාවක් වන්නේ “සියල්ල සකස් කරන භූමිකාවයි”. පළමු වර්ගයේ සේවාදායකයන් සහ දෙවන වර්ගයේ සේවාදායකයන් යන දෙකම වින්‍යාස කරන භූමිකාවක් ලබා ගැනීමට මම කැමතියි.

පුරාවිද්‍යාත්මක උදාහරණයක් වන්නේ නිරීක්ෂණයයි. මම අධීක්ෂණය වින්‍යාස කරන අධීක්ෂණ භූමිකාවක් ලබා ගැනීමට කැමතියි. අධීක්ෂණ භූමිකාව අධීක්ෂණ සත්කාරක වෙත පවරා ඇත (සෙල්ලම් කිරීමට අනුව). නමුත් අධීක්‍ෂණය සඳහා අප අධීක්‍ෂණය කරන ධාරක වෙත පැකේජ ලබාදිය යුතු බව පෙනී යයි. නියෝජිතයා භාවිතා නොකරන්නේ ඇයි? ඔබට iptables වින්‍යාස කිරීමටද අවශ්‍ය වේ. නියෝජිතයා? අධීක්‍ෂණය සක්‍රීය කිරීම සඳහා ඔබ DBMS සඳහා වින්‍යාසයක් ලිවීමට/නිවැරදි කිරීමට ද අවශ්‍ය වේ. නියෝජිතයා! නිර්මාණශීලීත්වය අඩු නම්, ඔබට නියෝජිත කණ්ඩායමක් සෑදිය හැකිය include_role කණ්ඩායම් ලැයිස්තුවක් මත උපක්‍රමශීලී පෙරහනක් භාවිතා කරමින් කැදලි ලූපයක් තුළ සහ ඇතුළත include_role ඔබට තවත් කළ හැකිය delegate_to නැවතත්. හා අපි යනවා...

හොඳ පැතුමක් - "සියල්ල කරන" තනි අධීක්ෂණ භූමිකාවක් තිබීම - අපව සම්පූර්ණ නිරයට ගෙන යන අතර එයින් බොහෝ විට ඇත්තේ එක් මාර්ගයක් පමණි: මුල සිටම සියල්ල නැවත ලිවීමට.

මෙතන වැරැද්ද වුනේ කොතනද? සත්කාරක X හි "x" කාර්යය කිරීමට ඔබට සත්කාරක Y වෙත ගොස් එහි "y" කළ යුතු බව ඔබ සොයාගත් මොහොතේ, ඔබට සරල අභ්‍යාසයක් කිරීමට සිදු විය: ගොස් වාදනය කරන්න, එය සත්කාරක Y මත y කරයි. "x" වෙත යමක් එකතු නොකරන්න, නමුත් එය මුල සිට ලියන්න. දෘඪ කේත සහිත විචල්යයන් සමඟ පවා.

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

තවත් බරපතළ වරදක් සැඟවී ඇත්තේ මෙතැනදීය. බොහෝ ව්‍යාපෘති ඉවසිය හැකි ලෙස ලිඛිතව (එය වඩා හොඳ විය හැකි නමුත් සියල්ල ක්‍රියාත්මක වන අතර නිම කිරීමට පහසුය) කතුවරයාට පවා හඳුනාගත නොහැකි සම්පූර්ණ භීෂණයක් බවට පත් කළ දෝෂයකි. එය ක්රියා කරයි, නමුත් දෙවියන් වහන්සේ ඔබට කිසිවක් වෙනස් කිරීම තහනම් කරයි.

දෝෂය නම්: භූමිකාව පුස්තකාල කාර්යයකි. මෙම ප්‍රතිසමය බොහෝ හොඳ ආරම්භයන් විනාශ කර ඇති අතර එය නැරඹීමට කණගාටුදායක ය. භූමිකාව පුස්තකාල කාර්යයක් නොවේ. ඇයට ගණනය කිරීම් කළ නොහැකි අතර ඇයට ක්‍රීඩා මට්ටමේ තීරණ ගත නොහැක. ක්‍රීඩාව ගන්නා තීරණ මොනවාදැයි මට මතක් කරන්න?

ස්තුතියි, ඔබ හරි. Play විසින් තීරණයක් ගනී (වඩාත් නිවැරදිව, එහි තොරතුරු අඩංගු වේ) කුමන කාර්යයන් සහ භූමිකාවන් ඉටු කළ යුතුද යන්න පිළිබඳව.

ඔබ මෙම තීරණය භූමිකාවකට පවරන්නේ නම් සහ ගණනය කිරීම් සමඟ පවා, ඔබ (සහ ඔබේ කේතය විග්‍රහ කිරීමට උත්සාහ කරන තැනැත්තා) දුක්ඛිත පැවැත්මකට විනාශ වේ. එය ඉටු කරන ස්ථානය තීරණය කරන්නේ භූමිකාව නොවේ. මෙම තීරණය ගනු ලබන්නේ සෙල්ලම් කිරීමෙනි. භූමිකාව කියන දේ, කියන තැන කරනවා.

Ansible වලින් program කිරීම අනතුරුදායක වන්නේ ඇයි සහ Ansible වලට වඩා COBOL හොඳ ඇයි අපි variables සහ jinja ගැන පරිච්ඡේදයෙන් කතා කරමු. දැනට, අපි එක දෙයක් කියමු - ඔබගේ එක් එක් ගණනය කිරීම් ගෝලීය විචල්‍යවල නොමැකෙන වෙනස්කම් ඉතිරි කරයි, ඔබට ඒ ගැන කිසිවක් කළ නොහැක. "හෝඩුවාවන්" දෙක ඡේදනය වූ වහාම සියල්ල පහව ගියේය.

කුපිත කරන්නන් සඳහා සටහන: භූමිකාව නිසැකවම පාලන ප්‍රවාහයට බලපෑම් කළ හැකිය. කන්න delegate_to සහ එය සාධාරණ භාවිතයන් ඇත. කන්න meta: end host/play. එහෙත්! මතකද අපි මූලික දේවල් උගන්නනවා? ගැන අමතක වුනා delegate_to. අපි කතා කරන්නේ සරලම හා ලස්සනම Ansible කේතය ගැන ය. කියවීමට පහසු, ලිවීමට පහසු, නිදොස් කිරීමට පහසු, පරීක්ෂා කිරීමට පහසු සහ සම්පූර්ණ කිරීමට පහසු වේ. ඉතින්, නැවත වරක්:

ක්‍රීඩා කරන්න සහ ක්‍රියාත්මක කරන්නේ කුමන සත්කාරක ද යන්න තීරණය කරන්නේ ක්‍රීඩාව පමණි.

මෙම කොටසේදී, අපි සෙල්ලම් කිරීම සහ භූමිකාව අතර ඇති විරුද්ධත්වය සමඟ කටයුතු කළෙමු. දැන් අපි කතා කරමු කර්තව්‍ය vs භූමිකාව සම්බන්ධය ගැන.

කාර්යයන් සහ භූමිකාවන්

සෙල්ලම් කිරීම සලකා බලන්න:

- hosts: somegroup
  pre_tasks:
    - some_tasks1:
  roles:
     - role1
     - role2
  post_tasks:
     - some_task2:
     - some_task3:

අපි හිතමු ඔයාට foo කරන්න ඕන කියලා. සහ එය පෙනේ foo: name=foobar state=present. මම මෙය ලිවිය යුත්තේ කොතැනින්ද? කලින්? තැපැල්? භූමිකාවක් නිර්මාණය කරන්න?

... සහ කාර්යයන් ගියේ කොහේද?

අපි නැවතත් මූලික කරුණු වලින් පටන් ගනිමු - Play උපාංගය. ඔබ මෙම ගැටලුව මත පාවී යන්නේ නම්, ඔබට අනෙක් සියල්ල සඳහා පදනම ලෙස ක්‍රීඩාව භාවිතා කළ නොහැකි අතර ඔබේ ප්‍රතිඵලය "සෙලවෙන" වනු ඇත.

Play උපාංගය: ධාරක විධානය, ක්‍රීඩා සඳහාම සැකසීම් සහ පෙර_කාර්යයන්, කාර්යයන්, භූමිකාවන්, post_tasks කොටස්. ක්‍රීඩාව සඳහා ඉතිරිව ඇති පරාමිතීන් දැන් අපට වැදගත් නොවේ.

කාර්යයන් සහ භූමිකාවන් සමඟ ඔවුන්ගේ අංශවල අනුපිළිවෙල: pre_tasks, roles, tasks, post_tasks. ක්‍රියාත්මක කිරීමේ අනුපිළිවෙල අර්ථකථනය වන බැවින් tasks и roles යන්න පැහැදිලි නැත, එවිට හොඳම භාවිතයන් පවසන්නේ අපි කොටසක් එකතු කරන බවයි tasks, එසේ නොවේ නම් පමණි roles... තියෙනවා නම් roles, පසුව සියලුම අමුණා ඇති කාර්යයන් කොටස්වල තබා ඇත pre_tasks/post_tasks.

ඉතිරිව ඇත්තේ සෑම දෙයක්ම අර්ථාන්විතව පැහැදිලි වීමයි: පළමුව pre_tasksඑතකොට rolesඑතකොට post_tasks.

නමුත් අපි තවමත් ප්රශ්නයට පිළිතුරු දී නැත: මොඩියුල ඇමතුම කොහෙද? foo ලියන්නද? අපි එක් එක් මොඩියුලය සඳහා සම්පූර්ණ භූමිකාවක් ලිවිය යුතුද? එසේත් නැතිනම් සෑම දෙයකටම ඝන භූමිකාවක් තිබීම වඩා හොඳද? සහ භූමිකාවක් නොවේ නම්, මා ලිවිය යුත්තේ කොතැනින්ද - පෙර හෝ පසු?

මෙම ප්‍රශ්නවලට තර්කානුකූල පිළිතුරක් නොමැති නම්, මෙය බුද්ධිය නොමැතිකමේ ලකුණකි, එනම් එම “සෙලවෙන පදනම්” ය. අපි එය තේරුම් ගනිමු. පළමුව, ආරක්ෂක ප්රශ්නයක්: ක්රීඩාව තිබේ නම් pre_tasks и post_tasks (සහ කිසිදු කාර්යයක් හෝ භූමිකාවක් නොමැත), එවිට මම පළමු කාර්යය ඉටු කළහොත් යමක් කැඩී යා හැක post_tasks මම එය අවසානය දක්වා ගෙන යන්නෙමි pre_tasks?

ඇත්ත වශයෙන්ම, ප්රශ්නයේ වචනවලින් එය බිඳ වැටෙන බව ඉඟි කරයි. නමුත් හරියටම කුමක්ද?

... හසුරුවන්නන්. මූලික කරුණු කියවීම වැදගත් කරුණක් හෙළි කරයි: එක් එක් කොටසෙන් පසු සියලුම හසුරුවන්නන් ස්වයංක්‍රීයව සෝදා හරිනු ලැබේ. එම. සිට සියලු කාර්යයන් pre_tasks, පසුව දැනුම් දුන් සියලුම හසුරුවන්න. එවිට භූමිකාවන්හි දැනුම් දී ඇති සියලුම භූමිකාවන් සහ සියලුම හසුරුවන්නන් ක්‍රියාත්මක වේ. අනතුරුව post_tasks සහ ඔවුන්ගේ හසුරුවන්නන්.

මේ අනුව, ඔබ කාර්යයක් ඇදගෙන ගියහොත් post_tasks в pre_tasks, එවිට ඔබ හසුරුවන්නා ක්‍රියාත්මක කිරීමට පෙර එය ක්‍රියාත්මක කරනු ඇත. උදාහරණයක් ලෙස, ඇතුලේ නම් pre_tasks වෙබ් සේවාදායකය ස්ථාපනය කර වින්‍යාස කර ඇත, සහ post_tasks යමක් එයට යවනු ලැබේ, පසුව මෙම කාර්යය කොටස වෙත මාරු කරන්න pre_tasks "යවන" අවස්ථාවේදී සේවාදායකය තවමත් ක්රියාත්මක නොවන අතර සෑම දෙයක්ම බිඳී යනු ඇත.

දැන් අපි නැවත සිතමු, අපට අවශ්ය වන්නේ ඇයි? pre_tasks и post_tasks? උදාහරණයක් ලෙස, කාර්යභාරය ඉටු කිරීමට පෙර අවශ්ය සියල්ල (හැසිරවන්නන් ඇතුළුව) සම්පූර්ණ කිරීම සඳහා. ඒ post_tasks භූමිකාවන් (හැසිරවන්නන් ඇතුළුව) ක්රියාත්මක කිරීමේ ප්රතිඵල සමඟ වැඩ කිරීමට අපට ඉඩ සලසයි.

බුද්ධිමත් ඇන්සිබල් විශේෂඥයෙක් එය කුමක්දැයි අපට කියනු ඇත. meta: flush_handlers, නමුත් අපට ක්‍රීඩාවේ කොටස් ක්‍රියාත්මක කිරීමේ අනුපිළිවෙල මත විශ්වාසය තැබිය හැකි නම් අපට flush_handlers අවශ්‍ය වන්නේ ඇයි? එපමනක් නොව, meta භාවිතය: flush_handlers අපට අනුපිටපත් හසුරුවන්න සමඟ අනපේක්ෂිත දේවල් ලබා දිය හැක, භාවිතා කරන විට අපට අමුතු අනතුරු ඇඟවීම් ලබා දෙයි. when у block ආදිය ඔබ ඇසිබල් වඩාත් හොඳින් දන්නා තරමට, ඔබට "උපක්‍රම" විසඳුමක් සඳහා නම් කළ හැකි සූක්ෂ්මතා වැඩි වේ. සහ සරල විසඳුමක් - පෙර/භූමිකාවන්/පශ්චාත් අතර ස්වභාවික බෙදීමක් භාවිතා කිරීම - සූක්ෂ්මතා ඇති නොකරයි.

සහ, අපගේ 'foo' වෙත ආපසු. මම එය තැබිය යුත්තේ කොහේද? පෙර, තනතුර හෝ භූමිකාව තුළ? නිසැකවම, මෙය foo සඳහා හසුරුවන්නාගේ ප්රතිඵල අවශ්යද යන්න මත රඳා පවතී. ඒවා නොමැති නම්, foo පෙර හෝ පසු තැබීමට අවශ්‍ය නොවේ - මෙම කොටස් වලට විශේෂ අර්ථයක් ඇත - ප්‍රධාන කේතයට පෙර සහ පසුව කාර්යයන් ක්‍රියාත්මක කිරීම.

දැන් “භූමිකාව හෝ කාර්යය” යන ප්‍රශ්නයට පිළිතුර දැනටමත් ක්‍රියාත්මක වන දෙයට පැමිණේ - එහි කාර්යයන් තිබේ නම්, ඔබ ඒවා කාර්යයන් සඳහා එක් කළ යුතුය. භූමිකාවන් තිබේ නම්, ඔබ භූමිකාවක් නිර්මාණය කළ යුතුය (එක් කාර්යයකින් පවා). කාර්යයන් සහ භූමිකාවන් එකවර භාවිතා නොකරන බව මම ඔබට මතක් කරමි.

Ansible හි මූලික කරුණු අවබෝධ කර ගැනීමෙන් රසය පිළිබඳ පෙනෙන ප්‍රශ්නවලට සාධාරණ පිළිතුරු සපයයි.

කාර්යයන් සහ භූමිකාවන් (දෙවන කොටස)

දැන් ඔබ සෙල්ලම් පොතක් ලිවීමට පටන් ගන්නා විට තත්වය සාකච්ඡා කරමු. ඔබ foo, bar සහ baz සෑදිය යුතුය. මෙම කාර්යයන් තුන, එක් භූමිකාවක් හෝ භූමිකාවන් තුනක් ද? ප්‍රශ්නය සාරාංශ කිරීමට: ඔබ භූමිකාවන් ලිවීම ආරම්භ කළ යුත්තේ කුමන අවස්ථාවේදීද? ඔබට කාර්යයන් ලිවීමට හැකි වූ විට භූමිකාවන් ලිවීමේ තේරුම කුමක්ද?... භූමිකාවක් යනු කුමක්ද?

විශාලම වැරැද්දක් (මම දැනටමත් මේ ගැන කතා කර ඇත) භූමිකාවක් යනු වැඩසටහනක පුස්තකාලයේ කාර්යයක් වැනි යැයි සිතීමයි. සාමාන්‍ය ශ්‍රිත විස්තරයක් පෙනෙන්නේ කෙසේද? එය ආදාන තර්ක පිළිගනී, අතුරු හේතූන් සමඟ අන්තර් ක්‍රියා කරයි, අතුරු ආබාධ කරයි, සහ අගයක් ලබා දෙයි.

දැන්, අවධානය. භූමිකාව තුළ මෙයින් කළ හැක්කේ කුමක්ද? අතුරු ආබාධ ඇමතීමට ඔබ සැමවිටම සාදරයෙන් පිළිගනිමු, මෙය සමස්ත Ansible හි සාරය - අතුරු ආබාධ ඇති කිරීම. අතුරු හේතු තිබේද? මූලික. නමුත් “අගය සම්මත කර එය ආපසු දෙන්න” සමඟ - එය ක්‍රියා නොකරන තැනයි. පළමුව, ඔබට භූමිකාවකට වටිනාකමක් ලබා දිය නොහැක. ඔබට භූමිකාව සඳහා vars කොටසෙහි ජීවිත කාලය පුරාවට ක්‍රීඩා කරන ගෝලීය විචල්‍යයක් සැකසිය හැක. ඔබට භූමිකාව තුළ ජීවිත කාලය සමඟ ගෝලීය විචල්‍යයක් සැකසිය හැක. නැතහොත් ක්‍රීඩා පොත්වල ජීවිත කාලය සමඟ පවා (set_fact/register) නමුත් ඔබට "දේශීය විචල්යයන්" තිබිය නොහැක. ඔබට "අගය ගන්න" සහ "එය ආපසු" ලබා දිය නොහැක.

මෙයින් ප්‍රධාන දෙය පහත දැක්වේ: ඔබට අතුරු ආබාධ ඇති නොකර Ansible හි යමක් ලිවිය නොහැක. ගෝලීය විචල්‍යයන් වෙනස් කිරීම සැමවිටම ශ්‍රිතයක් සඳහා අතුරු ආබාධයකි. උදාහරණයක් ලෙස, රස්ට් හි ගෝලීය විචල්‍යයක් වෙනස් කිරීම වේ unsafe. සහ Ansible හි භූමිකාවක් සඳහා අගයන්ට බලපෑම් කළ හැකි එකම ක්‍රමය එයයි. භාවිතා කරන වචන සටහන් කරන්න: "භූමිකාවට අගයක් ලබා දීම" නොව "භූමිකාව භාවිතා කරන අගයන් වෙනස් කරන්න". භූමිකාවන් අතර හුදකලා වීමක් නොමැත. කාර්යයන් සහ භූමිකාවන් අතර හුදකලා වීමක් නොමැත.

එකතුව: භූමිකාවක් යනු කාර්යයක් නොවේ.

භූමිකාවේ හොඳ කුමක්ද? පළමුව, භූමිකාවට පෙරනිමි අගයන් ඇත (/default/main.yaml), දෙවනුව, භූමිකාවට ගොනු ගබඩා කිරීම සඳහා අමතර නාමාවලි ඇත.

පෙරනිමි අගයන්හි ප්‍රතිලාභ මොනවාද? Maslow ගේ පිරමීඩයේ, Ansible හි තරමක් විකෘති වූ විචල්‍ය ප්‍රමුඛතා වගුවේ, භූමිකා පෙරනිමිය වඩාත්ම අඩු ප්‍රමුඛතාවය (ඇන්සිබල් විධාන රේඛා පරාමිතීන් අඩු කිරීම) වන බැවිනි. මෙයින් අදහස් කරන්නේ ඔබට පෙරනිමි අගයන් සැපයීමට අවශ්‍ය නම් සහ ඉන්වෙන්ටරි හෝ කණ්ඩායම් විචල්‍ය වලින් අගයන් අභිබවා යාම ගැන කරදර නොවන්න නම්, භූමිකාව පෙරනිමිය ඔබට එකම නිවැරදි ස්ථානයයි. (මම ටිකක් බොරු කියනවා - තව තියෙනවා |d(your_default_here), නමුත් අපි ස්ථාවර ස්ථාන ගැන කතා කරන්නේ නම්, භූමිකාව පෙරනිමිය පමණි).

භූමිකාවන්හි තවත් විශිෂ්ට වන්නේ කුමක්ද? මන්ද ඔවුන්ට ඔවුන්ගේම නාමාවලි තිබේ. මේවා විචල්‍ය සඳහා නාමාවලි වේ, නියත (එනම් භූමිකාව සඳහා ගණනය කෙරේ) සහ ගතික (එක්කෝ රටාවක් හෝ ප්‍රති-රටාවක් ඇත - include_vars සමඟ {{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml.) මේ සඳහා නාමාවලි වේ files/, templates/. එසේම, එය ඔබට ඔබේම මොඩියුල සහ ප්ලගීන (library/) නමුත්, ක්‍රීඩා පොතක ඇති කාර්යයන් හා සසඳන විට (මේ සියල්ල ද තිබිය හැක), මෙහි ඇති එකම ප්‍රයෝජනය වන්නේ ගොනු එක් ගොඩකට නොව වෙනම ගොඩවල් කිහිපයකට දැමීමයි.

තවත් එක් විස්තරයක්: ඔබට නැවත භාවිතය සඳහා ලබා ගත හැකි භූමිකාවන් නිර්මාණය කිරීමට උත්සාහ කළ හැකිය ( මන්දාකිණිය හරහා ). එකතු කිරීම් පැමිණීමත් සමඟ භූමිකාව බෙදා හැරීම පාහේ අමතක වී ඇති බව සැලකිය හැකිය.

මේ අනුව, භූමිකාවන්ට වැදගත් විශේෂාංග දෙකක් ඇත: ඒවාට පෙරනිමි (අද්විතීය අංගයක්) ඇති අතර ඒවා ඔබේ කේතය ව්‍යුහගත කිරීමට ඔබට ඉඩ සලසයි.

මුල් ප්‍රශ්නයට නැවත පැමිණීම: කාර්යයන් කළ යුත්තේ කවදාද සහ භූමිකාවන් කරන්නේ කවදාද? ක්‍රීඩා පොතක ඇති කාර්යයන් බොහෝ විට භාවිතා වන්නේ භූමිකාවන්ට පෙර/පසු “මැලියම්” ලෙස හෝ ස්වාධීන ගොඩනැඟිලි අංගයක් ලෙසය (එවිට කේතයේ භූමිකාවක් නොතිබිය යුතුය). භූමිකාවන් සමඟ මිශ්‍ර වූ සාමාන්‍ය කාර්යයන් රාශියක් යනු නොපැහැදිලි අලසකමයි. ඔබ නිශ්චිත ශෛලියකට අනුගත විය යුතුය - කාර්යයක් හෝ භූමිකාවක්. භූමිකාවන් ආයතන සහ පෙරනිමි වෙන් කිරීම් සපයයි, කාර්යයන් මඟින් ඔබට කේතය වේගයෙන් කියවීමට ඉඩ සලසයි. සාමාන්‍යයෙන්, වඩාත් “ස්ථාවර” (වැදගත් සහ සංකීර්ණ) කේතය භූමිකාවන් තුළට දමා ඇති අතර, සහායක ස්ක්‍රිප්ට් කාර්ය විලාසයෙන් ලියා ඇත.

කර්තව්‍යයක් ලෙස import_role කිරීමට හැකියාව ඇත, නමුත් ඔබ මෙය ලියන්නේ නම්, ඔබට මෙය කිරීමට අවශ්‍ය වන්නේ මන්දැයි ඔබේම සුන්දරත්වයේ හැඟීමට පැහැදිලි කිරීමට සූදානම් වන්න.

විචක්ෂණශීලී පාඨකයෙකු පැවසිය හැක්කේ භූමිකාවන්ට භූමිකාවන් ආයාත කළ හැකි බවත්, භූමිකාවන්ට galaxy.yml හරහා පරායත්තතා තිබිය හැකි බවත්, භයානක හා බිහිසුණු බවක් ද ඇති බවත්ය. include_role - මම ඔබට මතක් කර දෙන්නේ අපි මූලික ඇන්සිබල්වල කුසලතා වැඩි දියුණු කරන අතර රූප ජිම්නාස්ටික් වල නොවන බවයි.

හසුරුවන්නන් සහ කාර්යයන්

අපි තවත් පැහැදිලි දෙයක් සාකච්ඡා කරමු: හසුරුවන්න. ඒවා නිවැරදිව භාවිතා කරන්නේ කෙසේදැයි දැන ගැනීම පාහේ කලාවකි. හසුරුවන්නෙකු සහ ඇදගෙන යාමක් අතර වෙනස කුමක්ද?

අපි මූලික කරුණු මතක තබා ගන්නා බැවින්, මෙන්න උදාහරණයක්:

- hosts: group1
  tasks:
    - foo:
      notify: handler1
  handlers:
     - name: handler1
       bar:

භූමිකාවේ හසුරුවන්න භූමිකාවේ නම/හසුරුවන්/main.yaml හි පිහිටා ඇත. සියලුම ක්‍රීඩා සහභාගිවන්නන් අතර හසුරුවන්නන් කටමැත දොඩවයි: පෙර/පසු_වැඩවලට භූමිකාව හසුරුවන්නන් ඇද ගත හැකි අතර භූමිකාවකට හසුරුවන්නන් නාට්‍යයෙන් ඇද ගත හැක. කෙසේ වෙතත්, හසුරුවන්නන් වෙත "හරස් භූමිකාව" ඇමතුම් සුළු හසුරුවන්නෙකු නැවත කිරීමට වඩා බොහෝ wtf ඇති කරයි. (හොඳම භාවිතයන්හි තවත් අංගයක් වන්නේ හසුරුවන්නන්ගේ නම් නැවත නොකිරීමට උත්සාහ කිරීමයි).

ප්‍රධාන වෙනස නම් කාර්යය සෑම විටම ක්‍රියාත්මක වීමයි (නිරපේක්ෂ ලෙස) (plus/minus tags සහ when), සහ හසුරුවන්නා - රාජ්ය වෙනස් කිරීම (එය වෙනස් කර ඇත්නම් පමණක් ගිනි දැනුම් දෙන්න). මෙමගින් කුමක් වෙයිද? උදාහරණයක් ලෙස, ඔබ නැවත ආරම්භ කරන විට, කිසිදු වෙනසක් සිදු නොකළේ නම්, එවිට හසුරුවන්නෙකු නොමැති බව. උත්පාදන කාර්යයේ කිසිදු වෙනසක් සිදු නොවූ විට අපට හසුරුවන්නා ක්‍රියාත්මක කිරීමට අවශ්‍ය වන්නේ ඇයි? උදාහරණයක් ලෙස, යමක් කැඩී වෙනස් වී ඇති නිසා, නමුත් ක්රියාත්මක කිරීම හසුරුවන්නා වෙත ළඟා නොවීය. උදාහරණයක් ලෙස, ජාලය තාවකාලිකව අක්රිය වූ නිසා. වින්‍යාසය වෙනස් වී ඇත, සේවාව නැවත ආරම්භ කර නොමැත. ඊළඟ වතාවේ ඔබ එය ආරම්භ කරන විට, වින්‍යාසය තවදුරටත් වෙනස් නොවන අතර, සේවාව වින්‍යාසයේ පැරණි අනුවාදය සමඟ පවතී.

වින්‍යාසය සමඟ ඇති තත්වය විසඳිය නොහැක (වඩාත් නිවැරදිව, ඔබට ගොනු ධජ යනාදිය සමඟ ඔබ වෙනුවෙන් විශේෂ නැවත ආරම්භ කිරීමේ ප්‍රොටෝකෝලයක් නිර්මාණය කළ හැකිය, නමුත් මෙය තවදුරටත් කිසිදු ආකාරයකින් 'මූලික ඇසිබල්' නොවේ). නමුත් තවත් පොදු කතාවක් තිබේ: අපි යෙදුම ස්ථාපනය කර එය පටිගත කළෙමු .serviceගොනුව, දැන් අපට එය අවශ්‍යයි daemon_reload и state=started. තවද මේ සඳහා ස්වභාවික ස්ථානය හසුරුවන්නා බව පෙනේ. නමුත් ඔබ එය හසුරුවන්නෙකු නොව කාර්ය ලැයිස්තුවක් හෝ භූමිකාවක් අවසානයේ කාර්යයක් බවට පත් කරන්නේ නම්, එය සෑම අවස්ථාවකම දුර්වල ලෙස ක්‍රියාත්මක වේ. සෙල්ලම් පොත මැදින් කැඩුනත්. මෙය නැවත ආරම්භ කරන ලද ගැටළුව කිසිසේත් විසඳන්නේ නැත (ඔබට නැවත ආරම්භ කළ ගුණාංගය සමඟ කාර්යයක් කළ නොහැක, මන්ද idempotency නැති වී ඇත), නමුත් එය අනිවාර්යයෙන්ම state=start කිරීම වටී, playbooks වල සමස්ත ස්ථාවරත්වය වැඩි වේ, මන්ද සම්බන්ධතා සංඛ්යාව සහ ගතික තත්ත්වය අඩු වේ.

හසුරුවන්නාගේ තවත් ධනාත්මක ගුණාංගයක් වන්නේ එය ප්රතිදානය අවහිර නොකරන බවයි. ප්‍රතිදානයේ කිසිදු වෙනස්කමක් නැත - අමතර මඟ හැරීමක් හෝ හරි නැත - කියවීමට පහසුය. එය ද සෘණාත්මක ගුණයකි - ඔබ පළමු ධාවනයේදී රේඛීයව ක්‍රියාත්මක කරන ලද කාර්යයක යතුරු ලියන දෝෂයක් සොයා ගන්නේ නම්, හසුරුවන්නන් ක්‍රියාත්මක වන්නේ වෙනස් වූ විට පමණි, i.e. සමහර කොන්දේසි යටතේ - ඉතා කලාතුරකින්. නිදසුනක් වශයෙන්, වසර පහකට පසු මගේ ජීවිතයේ පළමු වතාවට. තවද, ඇත්ත වශයෙන්ම, නමේ ටයිප් එකක් ඇති අතර සෑම දෙයක්ම කැඩී යනු ඇත. ඔබ ඒවා දෙවන වරට ක්‍රියාත්මක නොකරන්නේ නම්, වෙනසක් නොමැත.

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

... එබැවින් හසුරුවන්නන් පෙනෙන ආකාරයට වඩා බෙහෙවින් අඩු ප්රයෝජනවත් සහ බොහෝ ගැටලුකාරී වේ. හසුරුවන්නෙකු නොමැතිව ඔබට අලංකාර ලෙස (අලංකාරයෙන් තොරව) යමක් ලිවිය හැකි නම්, ඔවුන් නොමැතිව එය කිරීම වඩා හොඳය. එය අලංකාර ලෙස ක්රියා නොකරන්නේ නම්, එය ඔවුන් සමඟ වඩා හොඳය.

අප සාකච්ඡා නොකළ බව විඛාදන පාඨකයා නිවැරදිව පෙන්වා දෙයි listenහසුරුවන්නෙකුට වෙනත් හසුරුවන්නෙකු සඳහා දැනුම් දීමට ඇමතිය හැකි බව, හසුරුවන්නෙකුට ආනයන_කර්තව්‍ය ඇතුළත් කළ හැකි බව (අන්ත‍්‍ර_භාණ්ඩ සමග_අන්ත‍්‍ර_භාණ්ඩ සමග කළ හැක), ඇන්සිබල් හි හසුරුවන්නන්ගේ පද්ධතිය Turing-සම්පූර්ණ බව, ඇතුලත්_රෝල් හි හසුරුවන්නන් ක්‍රීඩාවෙන් හසුරුවන්නන් සමඟ කුතුහලයෙන් ඡේදනය වන බව, ආදිය .d. - මේ සියල්ල පැහැදිලිවම "මූලික" නොවේ).

එක් විශේෂිත WTF එකක් තිබුණද එය ඇත්ත වශයෙන්ම ඔබ මතක තබා ගත යුතු අංගයකි. ඔබගේ කාර්යය සමඟ ක්රියාත්මක වන්නේ නම් delegate_to සහ එය දැනුම් දී ඇත, පසුව අදාල හසුරුවන්නා නොමැතිව ක්රියාත්මක වේ delegate_to, i.e. ක්රීඩාව පවරා ඇති සත්කාරක මත. (හැසිරුම්කරුට ඇත්ත වශයෙන්ම තිබිය හැකි වුවද delegate_to එකම).

වෙනමම, නැවත භාවිතා කළ හැකි භූමිකාවන් ගැන වචන කිහිපයක් පැවසීමට මට අවශ්යය. එකතු කිරීම් දර්ශනය වීමට පෙර, ඔබට විශ්වීය භූමිකාවන් කළ හැකි බවට අදහසක් තිබුණි ansible-galaxy install යන්න ගියා. සියලුම අවස්ථා වල සියලුම ප්‍රභේදවල සියලුම OS මත ක්‍රියා කරයි. ඉතින්, මගේ මතය: එය ක්රියා නොකරයි. ස්කන්ධය සහිත ඕනෑම භූමිකාවක් include_vars, අවස්ථා 100500කට සහය දක්වමින්, කෙළවරේ කේස් දෝෂ වල අගාධයට පත් වේ. ඒවා දැවැන්ත පරීක්‍ෂාවකින් ආවරණය කළ හැක, නමුත් ඕනෑම පරීක්‍ෂණයකදී මෙන්, එක්කෝ ඔබට ආදාන අගයන්හි කාටිසියානු නිෂ්පාදනයක් සහ සම්පූර්ණ ශ්‍රිතයක් ඇත, නැතහොත් ඔබට “තනි පුද්ගල අවස්ථා ආවරණය කර ඇත.” මගේ අදහස නම් භූමිකාව රේඛීය නම් (චක්‍රීය සංකීර්ණත්වය 1) වඩා හොඳ බවයි.

අඩු නම් (පැහැදිලි හෝ ප්‍රකාශන - පෝරමයේ when හෝ ආකෘතිය include_vars විචල්‍ය සමූහයක් මගින්), භූමිකාව වඩා හොඳය. සමහර විට ඔබ ශාඛා සෑදිය යුතුය, නමුත්, මම නැවත නැවතත්, අඩු ඒවා, වඩා හොඳය. එබැවින් එය පොකුරක් සමඟ මන්දාකිනි (එය ක්‍රියා කරයි!) සමඟ හොඳ භූමිකාවක් සේ පෙනේ when කාර්යයන් පහකින් "තමාගේම" භූමිකාවට වඩා අඩු මනාප විය හැකිය. මන්දාකිණි සමඟ භූමිකාව වඩා හොඳ වන මොහොත වන්නේ ඔබ යමක් ලිවීමට පටන් ගන්නා විටය. එය නරක අතට හැරෙන මොහොත වන්නේ යමක් කැඩී ඇති අතර එය "මන්දකාසි සමඟ භූමිකාව" නිසාදැයි ඔබට සැකයක් ඇති වේ. ඔබ එය විවෘත කරන්න, ඇතුළත් කිරීම් පහක්, කාර්ය පත්රිකා අටක් සහ තොගයක් ඇත when'ඕව්... අපි මේක හොයාගන්න ඕනේ. කැඩීමට කිසිවක් නොමැති රේඛීය ලැයිස්තුවක් සහිත කාර්යයන් 5 ක් වෙනුවට.

පහත කොටස් වල

• ඉන්වෙන්ටරි, කණ්ඩායම් විචල්යයන්, host_group_vars ප්ලගිනය, hostvars ගැන ටිකක්. ස්පැගටි සමඟ ගෝර්ඩියන් ගැටයක් බැඳ ගන්නේ කෙසේද? විෂය පථය සහ ප්‍රමුඛතා විචල්‍යයන්, Ansible මතක ආකෘතිය. "ඉතින් අපි දත්ත සමුදාය සඳහා පරිශීලක නාමය ගබඩා කරන්නේ කොහේද?"
• jinja: {{ jinja }} - nosql notype nosense soft plasticine. ඔබ බලාපොරොත්තු නොවන තැන පවා එය සෑම තැනකම තිබේ. ගැන ටිකක් !!unsafe සහ රසවත් යමහල්.

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