ഞാൻ മറ്റുള്ളവരുടെ അൻസിബിൾ കോഡിനെ കുറിച്ച് ധാരാളം അവലോകനങ്ങൾ നടത്തുകയും ഒരുപാട് എഴുതുകയും ചെയ്യുന്നു. തെറ്റുകൾ (മറ്റുള്ളവരുടെയും എന്റെയും), അതുപോലെ നിരവധി അഭിമുഖങ്ങൾ വിശകലനം ചെയ്യുന്നതിനിടയിൽ, അൻസിബിൾ ഉപയോക്താക്കൾ ചെയ്യുന്ന പ്രധാന തെറ്റ് ഞാൻ മനസ്സിലാക്കി - അടിസ്ഥാനപരമായ കാര്യങ്ങളിൽ വൈദഗ്ദ്ധ്യം നേടാതെ അവർ സങ്കീർണ്ണമായ കാര്യങ്ങളിൽ ഏർപ്പെടുന്നു.

ഈ സാർവത്രിക അനീതി തിരുത്താൻ, ഇതിനകം അറിയാവുന്നവർക്കായി അൻസിബിളിന് ഒരു ആമുഖം എഴുതാൻ ഞാൻ തീരുമാനിച്ചു. ഞാൻ നിങ്ങൾക്ക് മുന്നറിയിപ്പ് നൽകുന്നു, ഇത് മനുഷ്യരുടെ പുനരാഖ്യാനമല്ല, ഇത് ധാരാളം അക്ഷരങ്ങളും ചിത്രങ്ങളുമില്ലാത്ത ദീർഘമായ വായനയാണ്.

വായനക്കാരന്റെ പ്രതീക്ഷിത നിലവാരം, യാംലയുടെ ആയിരക്കണക്കിന് വരികൾ ഇതിനകം എഴുതിയിട്ടുണ്ട്, എന്തെങ്കിലും ഇതിനകം നിർമ്മാണത്തിലാണ്, പക്ഷേ "എങ്ങനെയെങ്കിലും എല്ലാം വളഞ്ഞതാണ്."

പേരുകൾ

ഒരു അൻസിബിൾ ഉപയോക്താവ് ചെയ്യുന്ന പ്രധാന തെറ്റ് എന്തെങ്കിലുമൊരു കാര്യം എന്താണെന്ന് അറിയാത്തതാണ്. നിങ്ങൾക്ക് പേരുകൾ അറിയില്ലെങ്കിൽ, ഡോക്യുമെന്റേഷൻ എന്താണ് പറയുന്നതെന്ന് നിങ്ങൾക്ക് മനസിലാക്കാൻ കഴിയില്ല. ജീവിച്ചിരിക്കുന്ന ഒരു ഉദാഹരണം: ഒരു അഭിമുഖത്തിനിടെ, താൻ അൻസിബിളിൽ ഒരുപാട് എഴുതിയിട്ടുണ്ടെന്ന് തോന്നിയ ഒരാൾക്ക് “ഒരു പ്ലേബുക്ക് എന്ത് ഘടകങ്ങൾ ഉൾക്കൊള്ളുന്നു?” എന്ന ചോദ്യത്തിന് ഉത്തരം നൽകാൻ കഴിഞ്ഞില്ല. "പ്ലേബുക്കിൽ കളി അടങ്ങിയിരിക്കുന്നു എന്ന ഉത്തരം പ്രതീക്ഷിച്ചിരുന്നു" എന്ന് ഞാൻ നിർദ്ദേശിച്ചപ്പോൾ, "ഞങ്ങൾ അത് ഉപയോഗിക്കുന്നില്ല" എന്ന അപകീർത്തികരമായ അഭിപ്രായം തുടർന്നു. ആളുകൾ പണത്തിന് വേണ്ടി അൻസിബിൾ എഴുതുന്നു, കളി ഉപയോഗിക്കരുത്. അവർ യഥാർത്ഥത്തിൽ അത് ഉപയോഗിക്കുന്നു, പക്ഷേ അത് എന്താണെന്ന് അറിയില്ല.

അതിനാൽ നമുക്ക് ലളിതമായ എന്തെങ്കിലും ഉപയോഗിച്ച് ആരംഭിക്കാം: അതിനെ എന്താണ് വിളിക്കുന്നത്? ഡോക്യുമെന്റേഷൻ വായിക്കുമ്പോൾ നിങ്ങൾ ശ്രദ്ധിച്ചില്ല എന്നതിനാൽ നിങ്ങൾക്ക് ഇത് അറിയാമോ അല്ലെങ്കിൽ നിങ്ങൾക്കറിയില്ല.

ansible-playbook പ്ലേബുക്ക് നിർവ്വഹിക്കുന്നു. yml/yaml വിപുലീകരണമുള്ള ഒരു ഫയലാണ് പ്ലേബുക്ക്, അതിനുള്ളിൽ ഇതുപോലൊന്ന് ഉണ്ട്:

---
- hosts: group1
  roles:
    - role1

- hosts: group2,group3
  tasks:
    - debug:

ഈ മുഴുവൻ ഫയലും ഒരു പ്ലേബുക്കാണെന്ന് ഞങ്ങൾ ഇതിനകം മനസ്സിലാക്കി. റോളുകൾ എവിടെയാണെന്നും ടാസ്‌ക്കുകൾ എവിടെയാണെന്നും നമുക്ക് കാണിക്കാം. എന്നാൽ കളി എവിടെ? പ്ലേയും റോളും അല്ലെങ്കിൽ പ്ലേബുക്കും തമ്മിലുള്ള വ്യത്യാസം എന്താണ്?

അതെല്ലാം ഡോക്യുമെന്റേഷനിലുണ്ട്. അവർ അത് നഷ്ടപ്പെടുത്തുകയും ചെയ്യുന്നു. തുടക്കക്കാർ - കാരണം വളരെയധികം ഉണ്ട്, നിങ്ങൾ എല്ലാം ഒറ്റയടിക്ക് ഓർക്കുകയില്ല. പരിചയസമ്പന്നർ - കാരണം "നിസ്സാര കാര്യങ്ങൾ". നിങ്ങൾക്ക് അനുഭവപരിചയമുണ്ടെങ്കിൽ, ഓരോ ആറുമാസത്തിലൊരിക്കലെങ്കിലും ഈ പേജുകൾ വീണ്ടും വായിക്കുക, നിങ്ങളുടെ കോഡ് ക്ലാസ് ലീഡിംഗ് ആയി മാറും.

അതിനാൽ, ഓർക്കുക: പ്ലേബുക്ക് എന്നത് കളിയും അടങ്ങുന്ന ഒരു ലിസ്റ്റാണ് import_playbook.
ഇത് ഒരു നാടകമാണ്:

- hosts: group1
  roles:
    - role1

ഇതും മറ്റൊരു നാടകമാണ്:

- hosts: group2,group3
  tasks:
    - debug:

എന്താണ് കളി? അവൾ എന്തിനാണ്?

ഒരു പ്ലേബുക്കിന്റെ പ്രധാന ഘടകമാണ് പ്ലേ, കാരണം പ്ലേയും പ്ലേയും റോളുകളുടെ ഒരു ലിസ്‌റ്റും/അല്ലെങ്കിൽ ടാസ്‌ക്കുകളും അവ എക്‌സിക്യൂട്ട് ചെയ്യേണ്ട ഹോസ്റ്റുകളുടെ ലിസ്റ്റുമായി ബന്ധപ്പെടുത്തുന്നു. ഡോക്യുമെന്റേഷന്റെ ആഴത്തിലുള്ള ആഴത്തിൽ നിങ്ങൾക്ക് പരാമർശം കണ്ടെത്താൻ കഴിയും delegate_to, ലോക്കൽ ലുക്ക്അപ്പ് പ്ലഗിനുകൾ, നെറ്റ്‌വർക്ക്-ക്ലി-നിർദ്ദിഷ്ട ക്രമീകരണങ്ങൾ, ജമ്പ് ഹോസ്റ്റുകൾ മുതലായവ. ജോലികൾ ചെയ്യുന്ന സ്ഥലം ചെറുതായി മാറ്റാൻ അവ നിങ്ങളെ അനുവദിക്കുന്നു. പക്ഷേ, അത് മറക്കുക. ഈ ബുദ്ധിമാനായ ഓരോ ഓപ്ഷനും വളരെ നിർദ്ദിഷ്ട ഉപയോഗങ്ങളുണ്ട്, അവ തീർച്ചയായും സാർവത്രികമല്ല. എല്ലാവരും അറിയേണ്ടതും ഉപയോഗിക്കേണ്ടതുമായ അടിസ്ഥാന കാര്യങ്ങളെക്കുറിച്ചാണ് ഞങ്ങൾ സംസാരിക്കുന്നത്.

നിങ്ങൾക്ക് "എന്തെങ്കിലും" "എവിടെയെങ്കിലും" അവതരിപ്പിക്കണമെങ്കിൽ, നിങ്ങൾ നാടകം എഴുതുക. ഒരു വേഷമല്ല. മൊഡ്യൂളുകളും ഡെലിഗേറ്റുകളും ഉള്ള റോളല്ല. നിങ്ങൾ അത് എടുത്ത് നാടകം എഴുതൂ. ഇതിൽ, ഹോസ്റ്റ്സ് ഫീൽഡിൽ നിങ്ങൾ എവിടെ എക്സിക്യൂട്ട് ചെയ്യണം, റോളുകൾ/ടാസ്ക്കുകൾ എന്നിവയിൽ - എന്താണ് എക്സിക്യൂട്ട് ചെയ്യേണ്ടതെന്ന് നിങ്ങൾ പട്ടികപ്പെടുത്തുന്നു.

ലളിതം, അല്ലേ? അല്ലാതെ എങ്ങനെയാവും?

കളിയിലൂടെയല്ല ഇത് ചെയ്യാൻ ആളുകൾക്ക് ആഗ്രഹം തോന്നുന്ന ഒരു സ്വഭാവ നിമിഷം "എല്ലാം സജ്ജമാക്കുന്ന പങ്ക്" ആണ്. ആദ്യ തരത്തിലുള്ള സെർവറുകളും രണ്ടാമത്തെ തരത്തിലുള്ള സെർവറുകളും കോൺഫിഗർ ചെയ്യുന്ന ഒരു റോൾ ലഭിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു.

ഒരു പുരാതന ഉദാഹരണം നിരീക്ഷണമാണ്. മോണിറ്ററിംഗ് കോൺഫിഗർ ചെയ്യുന്ന ഒരു മോണിറ്ററിംഗ് റോൾ ലഭിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. മോണിറ്ററിംഗ് ഹോസ്റ്റുകൾക്ക് മോണിറ്ററിംഗ് റോൾ നിയുക്തമാക്കിയിരിക്കുന്നു (പ്ലേ പ്രകാരം). എന്നാൽ നിരീക്ഷണത്തിനായി ഞങ്ങൾ നിരീക്ഷിക്കുന്ന ഹോസ്റ്റുകൾക്ക് പാക്കേജുകൾ നൽകേണ്ടതുണ്ടെന്ന് ഇത് മാറുന്നു. എന്തുകൊണ്ട് ഡെലിഗേറ്റ് ഉപയോഗിക്കരുത്? നിങ്ങൾ iptables കോൺഫിഗർ ചെയ്യേണ്ടതുണ്ട്. പ്രതിനിധി? മോണിറ്ററിംഗ് പ്രവർത്തനക്ഷമമാക്കുന്നതിന് നിങ്ങൾ DBMS-നായി ഒരു കോൺഫിഗറേഷൻ എഴുതുകയും/തിരുത്തുകയും ചെയ്യേണ്ടതുണ്ട്. പ്രതിനിധി! സർഗ്ഗാത്മകത കുറവാണെങ്കിൽ, നിങ്ങൾക്ക് ഒരു ഡെലിഗേഷൻ ഉണ്ടാക്കാം include_role ഗ്രൂപ്പുകളുടെ ലിസ്റ്റിലും അകത്തും ഒരു ട്രിക്കി ഫിൽട്ടർ ഉപയോഗിച്ച് ഒരു നെസ്റ്റഡ് ലൂപ്പിൽ include_role നിങ്ങൾക്ക് കൂടുതൽ ചെയ്യാൻ കഴിയും delegate_to വീണ്ടും. പിന്നെ ഞങ്ങൾ പോകുന്നു...

ഒരു നല്ല ആഗ്രഹം - ഒരൊറ്റ മോണിറ്ററിംഗ് റോൾ ഉണ്ടായിരിക്കണം, അത് "എല്ലാം ചെയ്യുന്നു" - നമ്മെ പൂർണ്ണമായ നരകത്തിലേക്ക് നയിക്കുന്നു, അതിൽ നിന്ന് പലപ്പോഴും ഒരു പോംവഴി മാത്രമേയുള്ളൂ: ആദ്യം മുതൽ എല്ലാം മാറ്റിയെഴുതുക.

ഇവിടെ എവിടെയാണ് തെറ്റ് സംഭവിച്ചത്? ഹോസ്റ്റ് X-ൽ "x" എന്ന ടാസ്ക് ചെയ്യാൻ നിങ്ങൾ ഹോസ്റ്റ് Y-ലേക്ക് പോയി അവിടെ "y" ചെയ്യണമെന്ന് നിങ്ങൾ കണ്ടെത്തിയ നിമിഷം, നിങ്ങൾ ഒരു ലളിതമായ വ്യായാമം ചെയ്യേണ്ടതുണ്ട്: പോയി പ്ലേ എഴുതുക, അത് ഹോസ്റ്റ് Y-ൽ y ചെയ്യുന്നു. "x" ലേക്ക് എന്തെങ്കിലും ചേർക്കരുത്, പക്ഷേ അത് ആദ്യം മുതൽ എഴുതുക. ഹാർഡ്‌കോഡുചെയ്‌ത വേരിയബിളുകൾക്കൊപ്പം പോലും.

മുകളിലെ ഖണ്ഡികകളിൽ എല്ലാം ശരിയായി പറഞ്ഞതായി തോന്നുന്നു. എന്നാൽ ഇത് നിങ്ങളുടെ കാര്യമല്ല! ഡ്രൈ ആയതും ലൈബ്രറി പോലെയുള്ളതുമായ പുനരുപയോഗിക്കാവുന്ന കോഡ് എഴുതാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നതിനാൽ, അത് എങ്ങനെ ചെയ്യണം എന്നതിനെക്കുറിച്ചുള്ള ഒരു രീതി നിങ്ങൾ അന്വേഷിക്കേണ്ടതുണ്ട്.

ഇവിടെയാണ് മറ്റൊരു ഗുരുതരമായ തെറ്റ് ഒളിഞ്ഞിരിക്കുന്നത്. സഹിഷ്ണുതയോടെ എഴുതിയതിൽ നിന്ന് (ഇത് മികച്ചതാകാം, പക്ഷേ എല്ലാം പ്രവർത്തിക്കുന്നു, പൂർത്തിയാക്കാൻ എളുപ്പമാണ്) എന്നതിൽ നിന്ന് പല പ്രോജക്റ്റുകളും രചയിതാവിന് പോലും മനസ്സിലാക്കാൻ കഴിയാത്ത ഒരു പൂർണ്ണമായ ഭയാനകമായി മാറ്റിയ ഒരു പിശക്. ഇത് പ്രവർത്തിക്കുന്നു, പക്ഷേ ഒന്നും മാറ്റാൻ ദൈവം നിങ്ങളെ വിലക്കുന്നു.

പിശക് ഇതാണ്: റോൾ ഒരു ലൈബ്രറി പ്രവർത്തനമാണ്. ഈ സാമ്യം നിരവധി നല്ല തുടക്കങ്ങളെ നശിപ്പിച്ചിട്ടുണ്ട്, അത് കാണാൻ സങ്കടകരമാണ്. പങ്ക് ഒരു ലൈബ്രറി പ്രവർത്തനമല്ല. അവൾക്ക് കണക്കുകൂട്ടലുകൾ നടത്താനും കളിയുടെ തലത്തിലുള്ള തീരുമാനങ്ങൾ എടുക്കാനും കഴിയില്ല. കളി എന്ത് തീരുമാനങ്ങളാണ് എടുക്കുന്നതെന്ന് എന്നെ ഓർമ്മിപ്പിക്കണോ?

നന്ദി, നിങ്ങൾ പറഞ്ഞത് ശരിയാണ്. ഏത് ഹോസ്റ്റുകളിൽ ഏതൊക്കെ ജോലികളും റോളുകളും നിർവഹിക്കണമെന്ന് പ്ലേ തീരുമാനിക്കുന്നു (കൂടുതൽ കൃത്യമായി, അതിൽ വിവരങ്ങൾ അടങ്ങിയിരിക്കുന്നു).

നിങ്ങൾ ഈ തീരുമാനം ഒരു റോളിലേക്ക് ഏൽപ്പിക്കുകയാണെങ്കിൽ, കൂടാതെ കണക്കുകൂട്ടലുകളോടെ പോലും, നിങ്ങൾ സ്വയം (നിങ്ങളുടെ കോഡ് പാഴ്‌സ് ചെയ്യാൻ ശ്രമിക്കുന്നയാളെ) ദയനീയമായ ഒരു അസ്തിത്വത്തിലേക്ക് നയിക്കും. എവിടെയാണ് അഭിനയിക്കേണ്ടതെന്ന് തീരുമാനിക്കുന്നത് വേഷമല്ല. കളിയിലൂടെയാണ് ഈ തീരുമാനം. പറയുന്നിടത്ത്, പറയുന്ന കാര്യങ്ങൾ ചെയ്യുന്നതാണ് വേഷം.

അൻസിബിളിൽ പ്രോഗ്രാം ചെയ്യുന്നത് എന്തുകൊണ്ട് അപകടകരമാണ്, എന്തുകൊണ്ട് അൻസിബിളിനേക്കാൾ COBOL മികച്ചതാണ്, വേരിയബിളുകളെയും ജിഞ്ചയെയും കുറിച്ച് ഞങ്ങൾ അധ്യായത്തിൽ സംസാരിക്കും. ഇപ്പോൾ, നമുക്ക് ഒരു കാര്യം പറയാം - നിങ്ങളുടെ ഓരോ കണക്കുകൂട്ടലും ആഗോള വേരിയബിളുകളിലെ മാറ്റങ്ങളുടെ മായാത്ത അടയാളം അവശേഷിപ്പിക്കുന്നു, നിങ്ങൾക്ക് അതിനെക്കുറിച്ച് ഒന്നും ചെയ്യാൻ കഴിയില്ല. രണ്ട് "ട്രേസുകൾ" കൂടിച്ചേർന്നയുടനെ എല്ലാം പോയി.

ഞെരുക്കമുള്ളവർക്കുള്ള കുറിപ്പ്: റോൾ തീർച്ചയായും നിയന്ത്രണ പ്രവാഹത്തെ സ്വാധീനിക്കും. കഴിക്കുക delegate_to അതിന് ന്യായമായ ഉപയോഗങ്ങളുമുണ്ട്. കഴിക്കുക meta: end host/play. പക്ഷേ! ഞങ്ങൾ അടിസ്ഥാനകാര്യങ്ങൾ പഠിപ്പിക്കുന്നത് ഓർക്കുന്നുണ്ടോ? മറന്നുപോയി delegate_to. ഞങ്ങൾ സംസാരിക്കുന്നത് ഏറ്റവും ലളിതവും മനോഹരവുമായ അൻസിബിൾ കോഡിനെക്കുറിച്ചാണ്. വായിക്കാൻ എളുപ്പമുള്ളതും എഴുതാൻ എളുപ്പമുള്ളതും ഡീബഗ് ചെയ്യാൻ എളുപ്പമുള്ളതും പരീക്ഷിക്കാൻ എളുപ്പമുള്ളതും പൂർത്തിയാക്കാൻ എളുപ്പവുമാണ്. അതിനാൽ, ഒരിക്കൽ കൂടി:

പ്ലേ ചെയ്യുക, ഏത് ഹോസ്റ്റ് ആണ് എക്സിക്യൂട്ട് ചെയ്യേണ്ടതെന്ന് തീരുമാനിക്കുന്നത് പ്ലേ മാത്രമാണ്.

ഈ വിഭാഗത്തിൽ, കളിയും വേഷവും തമ്മിലുള്ള എതിർപ്പാണ് ഞങ്ങൾ കൈകാര്യം ചെയ്തത്. ഇനി നമുക്ക് ടാസ്‌ക്കുകൾ vs റോൾ ബന്ധത്തെക്കുറിച്ച് സംസാരിക്കാം.

ചുമതലകളും റോളുകളും

കളിക്കുന്നത് പരിഗണിക്കുക:

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

നിങ്ങൾ ഫൂ ചെയ്യണമെന്ന് പറയാം. അത് പോലെ തോന്നുന്നു foo: name=foobar state=present. ഞാൻ ഇത് എവിടെ എഴുതണം? മുമ്പ്? പോസ്റ്റ്? ഒരു റോൾ സൃഷ്ടിക്കണോ?

... പിന്നെ ടാസ്ക്കുകൾ എവിടെ പോയി?

ഞങ്ങൾ വീണ്ടും അടിസ്ഥാനകാര്യങ്ങളിൽ നിന്ന് ആരംഭിക്കുകയാണ് - പ്ലേ ഉപകരണം. നിങ്ങൾ ഈ പ്രശ്‌നത്തിൽ പൊങ്ങിക്കിടക്കുകയാണെങ്കിൽ, മറ്റെല്ലാറ്റിനും അടിസ്ഥാനമായി നിങ്ങൾക്ക് പ്ലേ ഉപയോഗിക്കാൻ കഴിയില്ല, നിങ്ങളുടെ ഫലം "ചഞ്ചലമായിരിക്കും".

ഉപകരണം പ്ലേ ചെയ്യുക: ഹോസ്റ്റുകളുടെ നിർദ്ദേശം, കളിക്കാനുള്ള ക്രമീകരണങ്ങൾ, പ്രീ_ടാസ്‌ക്കുകൾ, ടാസ്‌ക്കുകൾ, റോളുകൾ, പോസ്റ്റ്_ടാസ്‌ക് വിഭാഗങ്ങൾ. കളിക്കാനുള്ള ശേഷിക്കുന്ന പാരാമീറ്ററുകൾ ഇപ്പോൾ ഞങ്ങൾക്ക് പ്രധാനമല്ല.

ചുമതലകളും റോളുകളും ഉള്ള അവരുടെ വിഭാഗങ്ങളുടെ ക്രമം: 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, എന്നാൽ പ്ലേയിലെ സെക്ഷനുകളുടെ നിർവ്വഹണ ക്രമത്തിൽ നമുക്ക് ആശ്രയിക്കാൻ കഴിയുമെങ്കിൽ എന്തുകൊണ്ട് ഫ്ലഷ്_ഹാൻഡ്ലറുകൾ ആവശ്യമാണ്? മാത്രമല്ല, meta-യുടെ ഉപയോഗം: flush_handlers ഡ്യൂപ്ലിക്കേറ്റ് ഹാൻഡ്‌ലറുകൾ ഉപയോഗിച്ച് നമുക്ക് അപ്രതീക്ഷിതമായ കാര്യങ്ങൾ നൽകുകയും ഉപയോഗിക്കുമ്പോൾ വിചിത്രമായ മുന്നറിയിപ്പുകൾ നൽകുകയും ചെയ്യും. when у block തുടങ്ങിയവ. നിങ്ങൾക്ക് അൻസിബിൾ നന്നായി അറിയാം, "തന്ത്രപരമായ" പരിഹാരത്തിനായി നിങ്ങൾക്ക് കൂടുതൽ സൂക്ഷ്മതകൾ നൽകാം. കൂടാതെ ഒരു ലളിതമായ പരിഹാരം - പ്രീ/റോളുകൾ/പോസ്റ്റ് എന്നിവയ്ക്കിടയിൽ ഒരു സ്വാഭാവിക വിഭജനം ഉപയോഗിക്കുന്നത് - സൂക്ഷ്മതകൾക്ക് കാരണമാകില്ല.

പിന്നെ, ഞങ്ങളുടെ 'ഫൂ'യിലേക്ക് മടങ്ങുക. ഞാൻ എവിടെ വയ്ക്കണം? പ്രീ, പോസ്റ്റ് അല്ലെങ്കിൽ റോളുകളിൽ? വ്യക്തമായും, ഇത് ഫൂയ്‌ക്ക് ഹാൻഡ്‌ലറിന്റെ ഫലങ്ങൾ ആവശ്യമാണോ എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു. അവ അവിടെ ഇല്ലെങ്കിൽ, ഫൂയെ പ്രീ അല്ലെങ്കിൽ പോസ്റ്റിൽ സ്ഥാപിക്കേണ്ടതില്ല - ഈ വിഭാഗങ്ങൾക്ക് ഒരു പ്രത്യേക അർത്ഥമുണ്ട് - കോഡിന്റെ പ്രധാന ബോഡിക്ക് മുമ്പും ശേഷവും ടാസ്‌ക്കുകൾ നടപ്പിലാക്കുന്നു.

ഇപ്പോൾ “റോൾ അല്ലെങ്കിൽ ടാസ്‌ക്” എന്ന ചോദ്യത്തിനുള്ള ഉത്തരം ഇതിനകം പ്ലേ ചെയ്യുന്നതിലേക്ക് വരുന്നു - അവിടെ ടാസ്‌ക്കുകൾ ഉണ്ടെങ്കിൽ, നിങ്ങൾ അവ ടാസ്‌ക്കുകളിലേക്ക് ചേർക്കേണ്ടതുണ്ട്. റോളുകൾ ഉണ്ടെങ്കിൽ, നിങ്ങൾ ഒരു റോൾ സൃഷ്ടിക്കേണ്ടതുണ്ട് (ഒരു ടാസ്ക്കിൽ നിന്ന് പോലും). ചുമതലകളും റോളുകളും ഒരേ സമയം ഉപയോഗിക്കില്ലെന്ന് ഞാൻ നിങ്ങളെ ഓർമ്മിപ്പിക്കട്ടെ.

അൻസിബിളിന്റെ അടിസ്ഥാനകാര്യങ്ങൾ മനസ്സിലാക്കുന്നത് അഭിരുചിയുമായി ബന്ധപ്പെട്ട ചോദ്യങ്ങൾക്ക് ന്യായമായ ഉത്തരം നൽകുന്നു.

ചുമതലകളും റോളുകളും (ഭാഗം രണ്ട്)

ഇപ്പോൾ നിങ്ങൾ ഒരു പ്ലേബുക്ക് എഴുതാൻ തുടങ്ങുമ്പോഴുള്ള സാഹചര്യം ചർച്ച ചെയ്യാം. നിങ്ങൾ ഫൂ, ബാർ, ബാസ് എന്നിവ ഉണ്ടാക്കണം. ഈ മൂന്ന് ജോലികൾ ഒരു റോളാണോ അതോ മൂന്ന് റോളുകളാണോ? ചോദ്യം സംഗ്രഹിക്കാൻ: ഏത് ഘട്ടത്തിലാണ് നിങ്ങൾ റോളുകൾ എഴുതാൻ തുടങ്ങേണ്ടത്? ടാസ്‌ക്കുകൾ എഴുതാൻ കഴിയുമ്പോൾ റോളുകൾ എഴുതുന്നതിൽ എന്ത് പ്രയോജനം?... എന്താണ് ഒരു റോൾ?

ഒരു പ്രോഗ്രാമിന്റെ ലൈബ്രറിയിലെ ഒരു ചടങ്ങ് പോലെയാണ് റോൾ എന്ന് കരുതുന്നതാണ് ഏറ്റവും വലിയ തെറ്റ് (ഞാൻ ഇതിനെക്കുറിച്ച് ഇതിനകം സംസാരിച്ചു). ഒരു പൊതു പ്രവർത്തന വിവരണം എങ്ങനെയിരിക്കും? ഇത് ഇൻപുട്ട് ആർഗ്യുമെന്റുകൾ സ്വീകരിക്കുന്നു, പാർശ്വ കാരണങ്ങളുമായി ഇടപഴകുന്നു, പാർശ്വഫലങ്ങൾ ഉണ്ടാക്കുന്നു, ഒരു മൂല്യം നൽകുന്നു.

ഇപ്പോൾ, ശ്രദ്ധ. റോളിൽ ഇതിൽ നിന്ന് എന്ത് ചെയ്യാൻ കഴിയും? സൈഡ് ഇഫക്റ്റുകൾ വിളിക്കാൻ നിങ്ങൾക്ക് എല്ലായ്പ്പോഴും സ്വാഗതം, ഇത് മുഴുവൻ അൻസിബിളിന്റെയും സാരാംശമാണ് - പാർശ്വഫലങ്ങൾ സൃഷ്ടിക്കാൻ. പാർശ്വ കാരണങ്ങളുണ്ടോ? പ്രാഥമിക. എന്നാൽ "ഒരു മൂല്യം കൈമാറുകയും അത് തിരികെ നൽകുകയും ചെയ്യുക" - അവിടെയാണ് ഇത് പ്രവർത്തിക്കാത്തത്. ആദ്യം, നിങ്ങൾക്ക് ഒരു റോളിലേക്ക് ഒരു മൂല്യം കൈമാറാൻ കഴിയില്ല. റോളിനായി vars വിഭാഗത്തിൽ നിങ്ങൾക്ക് ലൈഫ് ടൈം സൈസ് പ്ലേ ഉള്ള ഒരു ഗ്ലോബൽ വേരിയബിൾ സജ്ജീകരിക്കാം. റോളിനുള്ളിൽ ആജീവനാന്തം കളിക്കുന്ന ഒരു ആഗോള വേരിയബിൾ നിങ്ങൾക്ക് സജ്ജീകരിക്കാനാകും. അല്ലെങ്കിൽ പ്ലേബുക്കുകളുടെ ജീവിതകാലം പോലും (set_fact/register). എന്നാൽ നിങ്ങൾക്ക് "ലോക്കൽ വേരിയബിളുകൾ" ഉണ്ടാകില്ല. നിങ്ങൾക്ക് "ഒരു മൂല്യം എടുക്കാനും" "അത് തിരികെ നൽകാനും" കഴിയില്ല.

ഇതിൽ നിന്ന് പ്രധാന കാര്യം പിന്തുടരുന്നു: പാർശ്വഫലങ്ങൾ ഉണ്ടാക്കാതെ നിങ്ങൾക്ക് അൻസിബിളിൽ എന്തെങ്കിലും എഴുതാൻ കഴിയില്ല. ആഗോള വേരിയബിളുകൾ മാറ്റുന്നത് എല്ലായ്പ്പോഴും ഒരു ഫംഗ്ഷന്റെ ഒരു പാർശ്വഫലമാണ്. റസ്റ്റിൽ, ഉദാഹരണത്തിന്, ഒരു ആഗോള വേരിയബിൾ മാറ്റുന്നത് unsafe. അൻസിബിളിൽ ഒരു റോളിനുള്ള മൂല്യങ്ങളെ സ്വാധീനിക്കാനുള്ള ഒരേയൊരു മാർഗ്ഗമാണിത്. ഉപയോഗിച്ച വാക്കുകൾ ശ്രദ്ധിക്കുക: "റോളിന് ഒരു മൂല്യം കൈമാറുക" എന്നല്ല, "റോൾ ഉപയോഗിക്കുന്ന മൂല്യങ്ങൾ മാറ്റുക". വേഷങ്ങൾക്കിടയിൽ ഒറ്റപ്പെടലില്ല. ചുമതലകളും റോളുകളും തമ്മിൽ ഒറ്റപ്പെടലില്ല.

ആകെ: ഒരു പങ്ക് ഒരു പ്രവർത്തനമല്ല.

റോളിൽ എന്താണ് നല്ലത്? ആദ്യം, റോളിന് സ്ഥിരസ്ഥിതി മൂല്യങ്ങളുണ്ട് (/default/main.yaml), രണ്ടാമതായി, ഫയലുകൾ സംഭരിക്കുന്നതിന് റോളിന് അധിക ഡയറക്ടറികളുണ്ട്.

ഡിഫോൾട്ട് മൂല്യങ്ങളുടെ പ്രയോജനങ്ങൾ എന്തൊക്കെയാണ്? കാരണം മാസ്ലോയുടെ പിരമിഡിൽ, അൻസിബിളിന്റെ വേരിയബിൾ മുൻഗണനകളുടെ വികലമായ പട്ടികയിൽ, റോൾ ഡിഫോൾട്ടുകൾ ഏറ്റവും കുറഞ്ഞ മുൻഗണനയാണ് (മൈനസ് അൻസിബിൾ കമാൻഡ് ലൈൻ പാരാമീറ്ററുകൾ). ഇതിനർത്ഥം, നിങ്ങൾക്ക് സ്ഥിരസ്ഥിതി മൂല്യങ്ങൾ നൽകേണ്ടതുണ്ടെങ്കിൽ, ഇൻവെന്ററിയിൽ നിന്നോ ഗ്രൂപ്പ് വേരിയബിളുകളിൽ നിന്നോ ഉള്ള മൂല്യങ്ങളെ അവ മറികടക്കുന്നതിനെക്കുറിച്ച് വിഷമിക്കേണ്ടതില്ലെങ്കിൽ, റോൾ ഡിഫോൾട്ടുകളാണ് നിങ്ങൾക്ക് ശരിയായ സ്ഥലം. (ഞാൻ അൽപ്പം കള്ളം പറയുന്നു - കൂടുതൽ ഉണ്ട് |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:

റോളിന്റെ ഹാൻഡ്‌ലറുകൾ റോൾനെയിം/ഹാൻഡ്‌ലർമാർ/മെയിൻ.യാംൽ എന്നതിൽ സ്ഥിതിചെയ്യുന്നു. എല്ലാ കളിയിൽ പങ്കെടുക്കുന്നവർക്കും ഇടയിൽ ഹാൻഡ്‌ലർമാർ കുപ്രചരണം നടത്തുന്നു: പ്രീ/പോസ്റ്റ്_ടാസ്‌ക്കുകൾക്ക് റോൾ ഹാൻഡ്‌ലർമാരെ വലിച്ചിടാൻ കഴിയും, കൂടാതെ ഒരു റോളിന് ഹാൻഡ്‌ലർമാരെ പ്ലേയിൽ നിന്ന് പിൻവലിക്കാനും കഴിയും. എന്നിരുന്നാലും, ഹാൻഡ്‌ലറുകളിലേക്കുള്ള "ക്രോസ്-റോൾ" കോളുകൾ ഒരു നിസ്സാര ഹാൻഡ്‌ലർ ആവർത്തിക്കുന്നതിനേക്കാൾ കൂടുതൽ wtf ഉണ്ടാക്കുന്നു. (ഹാൻഡ്ലർ പേരുകൾ ആവർത്തിക്കാതിരിക്കാൻ ശ്രമിക്കുക എന്നതാണ് മികച്ച രീതികളുടെ മറ്റൊരു ഘടകം).

പ്രധാന വ്യത്യാസം, ടാസ്‌ക്ക് എപ്പോഴും എക്‌സിക്യൂട്ട് ചെയ്യപ്പെടുന്നു (അസാധാരണമായി) (പ്ലസ്/മൈനസ് ടാഗുകൾ കൂടാതെ when), കൂടാതെ ഹാൻഡ്‌ലർ - സംസ്ഥാന മാറ്റമനുസരിച്ച് (അത് മാറ്റിയിട്ടുണ്ടെങ്കിൽ മാത്രം തീയെ അറിയിക്കുക). എന്താണിതിനർത്ഥം? ഉദാഹരണത്തിന്, നിങ്ങൾ പുനരാരംഭിക്കുമ്പോൾ, മാറ്റമൊന്നും ഇല്ലെങ്കിൽ, പിന്നെ ഒരു ഹാൻഡ്‌ലറും ഉണ്ടാകില്ല. ജനറേറ്റിംഗ് ടാസ്‌ക്കിൽ ഒരു മാറ്റവുമില്ലാത്തപ്പോൾ നമ്മൾ ഹാൻഡ്‌ലർ എക്‌സിക്യൂട്ട് ചെയ്യേണ്ടത് എന്തുകൊണ്ട്? ഉദാഹരണത്തിന്, എന്തെങ്കിലും തകരുകയും മാറുകയും ചെയ്തതിനാൽ, എന്നാൽ നിർവ്വഹണം ഹാൻഡ്ലറിൽ എത്തിയില്ല. ഉദാഹരണത്തിന്, നെറ്റ്‌വർക്ക് താൽക്കാലികമായി പ്രവർത്തനരഹിതമായതിനാൽ. കോൺഫിഗറേഷൻ മാറി, സേവനം പുനരാരംഭിച്ചിട്ടില്ല. അടുത്ത തവണ നിങ്ങൾ ഇത് ആരംഭിക്കുമ്പോൾ, കോൺഫിഗേഷൻ ഇനി മാറില്ല, കൂടാതെ സേവനം കോൺഫിഗറിൻറെ പഴയ പതിപ്പിൽ തന്നെ തുടരും.

കോൺഫിഗറുമായുള്ള സാഹചര്യം പരിഹരിക്കാൻ കഴിയില്ല (കൂടുതൽ കൃത്യമായി പറഞ്ഞാൽ, ഫയൽ ഫ്ലാഗുകൾ മുതലായവ ഉപയോഗിച്ച് നിങ്ങൾക്ക് ഒരു പ്രത്യേക പുനരാരംഭിക്കൽ പ്രോട്ടോക്കോൾ സ്വയം കണ്ടുപിടിക്കാൻ കഴിയും, എന്നാൽ ഇത് ഇനി ഒരു രൂപത്തിലും 'അടിസ്ഥാന അൻസിബിൾ' അല്ല). എന്നാൽ മറ്റൊരു സാധാരണ കഥയുണ്ട്: ഞങ്ങൾ ആപ്ലിക്കേഷൻ ഇൻസ്റ്റാൾ ചെയ്തു, അത് റെക്കോർഡ് ചെയ്തു .service- ഫയൽ, ഇപ്പോൾ നമുക്കത് വേണം daemon_reload и state=started. ഇതിനുള്ള സ്വാഭാവിക സ്ഥലം കൈകാര്യം ചെയ്യുന്നയാളാണെന്ന് തോന്നുന്നു. എന്നാൽ നിങ്ങൾ ഇത് ഒരു ഹാൻഡ്‌ലറല്ല, ഒരു ടാസ്‌ക്‌ലിസ്റ്റിന്റെയോ റോളിന്റെയോ അവസാനം ഒരു ടാസ്‌ക് ആക്കുകയാണെങ്കിൽ, അത് ഓരോ തവണയും നിഷ്‌ക്രിയമായി നടപ്പിലാക്കും. പ്ലേബുക്ക് നടുവിൽ തകർന്നാലും. ഇത് പുനരാരംഭിച്ച പ്രശ്‌നം പരിഹരിക്കില്ല (പുനരാരംഭിച്ച ആട്രിബ്യൂട്ട് ഉപയോഗിച്ച് നിങ്ങൾക്ക് ഒരു ടാസ്‌ക് ചെയ്യാൻ കഴിയില്ല, കാരണം ഐഡമ്പറ്റൻസി നഷ്‌ടമായതിനാൽ), പക്ഷേ ഇത് തീർച്ചയായും സംസ്ഥാനം ചെയ്യുന്നത് മൂല്യവത്താണ്=ആരംഭിച്ചു, പ്ലേബുക്കുകളുടെ മൊത്തത്തിലുള്ള സ്ഥിരത വർദ്ധിക്കുന്നു, കാരണം കണക്ഷനുകളുടെ എണ്ണവും ചലനാത്മക നിലയും കുറയുന്നു.

ഹാൻഡ്‌ലറിന്റെ മറ്റൊരു പോസിറ്റീവ് പ്രോപ്പർട്ടി അത് ഔട്ട്‌പുട്ടിനെ തടസ്സപ്പെടുത്തുന്നില്ല എന്നതാണ്. മാറ്റങ്ങളൊന്നും ഉണ്ടായില്ല - ഔട്ട്‌പുട്ടിൽ അധിക ഒഴിവാക്കുകയോ ശരിയോ ഇല്ല - വായിക്കാൻ എളുപ്പമാണ്. ഇത് ഒരു നെഗറ്റീവ് പ്രോപ്പർട്ടി കൂടിയാണ് - ആദ്യ റണ്ണിൽ തന്നെ രേഖീയമായി നിർവ്വഹിച്ച ടാസ്‌ക്കിൽ അക്ഷരത്തെറ്റ് കണ്ടെത്തിയാൽ, മാറ്റുമ്പോൾ മാത്രമേ ഹാൻഡ്‌ലറുകൾ എക്‌സിക്യൂട്ട് ചെയ്യപ്പെടുകയുള്ളൂ, അതായത്. ചില വ്യവസ്ഥകളിൽ - വളരെ അപൂർവ്വമായി. ഉദാഹരണത്തിന്, അഞ്ച് വർഷത്തിന് ശേഷം എന്റെ ജീവിതത്തിൽ ആദ്യമായി. കൂടാതെ, തീർച്ചയായും, പേരിൽ ഒരു അക്ഷരത്തെറ്റ് ഉണ്ടാകും, എല്ലാം തകരും. നിങ്ങൾ അവ രണ്ടാം തവണ പ്രവർത്തിപ്പിച്ചില്ലെങ്കിൽ, ഒരു മാറ്റവുമില്ല.

വെവ്വേറെ, വേരിയബിളുകളുടെ ലഭ്യതയെക്കുറിച്ച് നമ്മൾ സംസാരിക്കേണ്ടതുണ്ട്. ഉദാഹരണത്തിന്, നിങ്ങൾ ഒരു ടാസ്ക്ക് ഒരു ലൂപ്പ് ഉപയോഗിച്ച് അറിയിക്കുകയാണെങ്കിൽ, വേരിയബിളുകളിൽ എന്തായിരിക്കും? നിങ്ങൾക്ക് വിശകലനപരമായി ഊഹിക്കാൻ കഴിയും, പക്ഷേ ഇത് എല്ലായ്പ്പോഴും നിസ്സാരമല്ല, പ്രത്യേകിച്ചും വേരിയബിളുകൾ വ്യത്യസ്ത സ്ഥലങ്ങളിൽ നിന്ന് വന്നാൽ.

... അതിനാൽ ഹാൻഡ്‌ലറുകൾ വളരെ കുറച്ച് ഉപയോഗപ്രദവും അവർ തോന്നുന്നതിനേക്കാൾ കൂടുതൽ പ്രശ്‌നകരവുമാണ്. ഹാൻഡ്‌ലറുകൾ ഇല്ലാതെ നിങ്ങൾക്ക് മനോഹരമായി (ഫ്രില്ലുകളില്ലാതെ) എന്തെങ്കിലും എഴുതാൻ കഴിയുമെങ്കിൽ, അവരെ കൂടാതെ അത് ചെയ്യുന്നതാണ് നല്ലത്. അത് മനോഹരമായി പ്രവർത്തിക്കുന്നില്ലെങ്കിൽ, അത് അവരോടൊപ്പം നല്ലതാണ്.

നമ്മൾ ചർച്ച ചെയ്തിട്ടില്ലെന്ന് കോറോസിവ് റീഡർ ശരിയായി ചൂണ്ടിക്കാണിക്കുന്നു listenഒരു ഹാൻഡ്‌ലറിന് മറ്റൊരു ഹാൻഡ്‌ലറെ അറിയിക്കാൻ വിളിക്കാൻ കഴിയും, ഒരു ഹാൻഡ്‌ലറിന് ഇറക്കുമതി_ടാസ്‌ക്കുകൾ ഉൾപ്പെടുത്താൻ കഴിയും (ഇതിൽ_ഇനങ്ങളോടൊപ്പം_ഇനങ്ങൾ ചെയ്യാൻ കഴിയും), അൻസിബിളിലെ ഹാൻഡ്‌ലർ സിസ്റ്റം ട്യൂറിംഗ്-കംപ്ലീറ്റ് ആണെന്നും, ഉൾപ്പെടുത്തിയ_റോളിൽ നിന്നുള്ള ഹാൻഡ്‌ലർമാർ കളിയിൽ നിന്നുള്ള ഹാൻഡ്‌ലറുകളുമായി കൗതുകകരമായ രീതിയിൽ വിഭജിക്കുന്നു, മുതലായവ .ഡി. - ഇതെല്ലാം വ്യക്തമായി "അടിസ്ഥാനങ്ങൾ" അല്ല).

ഒരു പ്രത്യേക WTF ഉണ്ടെങ്കിലും അത് യഥാർത്ഥത്തിൽ നിങ്ങൾ മനസ്സിൽ സൂക്ഷിക്കേണ്ട ഒരു സവിശേഷതയാണ്. നിങ്ങളുടെ ചുമതല നിർവ്വഹിച്ചാൽ delegate_to അത് അറിയിക്കുകയും, തുടർന്ന് അനുബന്ധ ഹാൻഡ്‌ലർ ഇല്ലാതെ എക്സിക്യൂട്ട് ചെയ്യുകയും ചെയ്യുന്നു delegate_to, അതായത്. പ്ലേ അസൈൻ ചെയ്‌തിരിക്കുന്ന ഹോസ്റ്റിൽ. (ഹാൻഡ്ലർക്ക് തീർച്ചയായും ഉണ്ടായിരിക്കാം delegate_to അതേ).

വെവ്വേറെ, വീണ്ടും ഉപയോഗിക്കാവുന്ന വേഷങ്ങളെക്കുറിച്ച് കുറച്ച് വാക്കുകൾ പറയാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. ശേഖരങ്ങൾ പ്രത്യക്ഷപ്പെടുന്നതിന് മുമ്പ്, നിങ്ങൾക്ക് സാർവത്രിക വേഷങ്ങൾ ചെയ്യാമെന്ന ആശയം ഉണ്ടായിരുന്നു ansible-galaxy install പോയി. എല്ലാ സാഹചര്യങ്ങളിലും എല്ലാ വേരിയന്റുകളുടെയും എല്ലാ OS-ലും പ്രവർത്തിക്കുന്നു. അതിനാൽ, എന്റെ അഭിപ്രായം: ഇത് പ്രവർത്തിക്കുന്നില്ല. മാസ്സ് ഉള്ള ഏത് വേഷവും include_vars, 100500 കേസുകൾ പിന്തുണയ്ക്കുന്നു, കോർണർ കേസ് ബഗുകളുടെ അഗാധതയിലേക്ക് വിധിക്കപ്പെട്ടിരിക്കുന്നു. അവ വൻതോതിലുള്ള പരിശോധനകളാൽ മൂടാം, എന്നാൽ ഏതൊരു ടെസ്റ്റിംഗിലെയും പോലെ, നിങ്ങൾക്ക് ഇൻപുട്ട് മൂല്യങ്ങളുടെ ഒരു കാർട്ടീഷ്യൻ ഉൽപ്പന്നവും മൊത്തത്തിലുള്ള പ്രവർത്തനവും ഉണ്ട്, അല്ലെങ്കിൽ നിങ്ങൾക്ക് "വ്യക്തിഗത സാഹചര്യങ്ങൾ ഉൾക്കൊള്ളുന്നു". റോൾ രേഖീയമാണെങ്കിൽ (സൈക്ലോമാറ്റിക് കോംപ്ലക്‌സിറ്റി 1) ആണ് കൂടുതൽ നല്ലത് എന്നാണ് എന്റെ അഭിപ്രായം.

കുറച്ച് ifs (വ്യക്തമോ പ്രഖ്യാപനമോ - രൂപത്തിൽ when അല്ലെങ്കിൽ രൂപം include_vars വേരിയബിളുകളുടെ സെറ്റ് പ്രകാരം), മികച്ച റോൾ. ചിലപ്പോൾ നിങ്ങൾ ശാഖകൾ ഉണ്ടാക്കണം, പക്ഷേ, ഞാൻ ആവർത്തിക്കുന്നു, കുറവ് ഉണ്ട്, നല്ലത്. അതിനാൽ ഇത് ഒരു കൂട്ടം ഗാലക്സിയിൽ (ഇത് പ്രവർത്തിക്കുന്നു!) ഒരു നല്ല വേഷമാണെന്ന് തോന്നുന്നു when അഞ്ച് ടാസ്ക്കുകളിൽ നിന്ന് "ഒരാളുടെ സ്വന്തം" റോളിനേക്കാൾ അഭികാമ്യമല്ല. നിങ്ങൾ എന്തെങ്കിലും എഴുതാൻ തുടങ്ങുമ്പോഴാണ് ഗാലക്സിയുമായുള്ള വേഷം മെച്ചമായ നിമിഷം. അത് വഷളാകുന്ന നിമിഷം, എന്തെങ്കിലും പൊട്ടിപ്പോകുമ്പോൾ, അത് "ഗാലക്സിയുമായുള്ള പങ്ക്" കാരണമാണോ എന്ന് നിങ്ങൾക്ക് സംശയമുണ്ട്. നിങ്ങൾ അത് തുറക്കുക, അഞ്ച് ഉൾപ്പെടുത്തലുകളും എട്ട് ടാസ്‌ക് ഷീറ്റുകളും ഒരു സ്റ്റാക്കും ഉണ്ട് when'ഓ... നമുക്ക് ഇത് കണ്ടുപിടിക്കണം. 5 ടാസ്ക്കുകൾക്ക് പകരം, തകർക്കാൻ ഒന്നുമില്ലാത്ത ഒരു ലീനിയർ ലിസ്റ്റ്.

ഇനിപ്പറയുന്ന ഭാഗങ്ങളിൽ

• ഇൻവെന്ററി, ഗ്രൂപ്പ് വേരിയബിളുകൾ, host_group_vars പ്ലഗിൻ, hostvars എന്നിവയെക്കുറിച്ച് അൽപ്പം. സ്പാഗെട്ടി ഉപയോഗിച്ച് ഒരു ഗോർഡിയൻ കെട്ട് എങ്ങനെ കെട്ടാം. സ്കോപ്പും മുൻഗണനാ വേരിയബിളുകളും, അൻസിബിൾ മെമ്മറി മോഡൽ. "അപ്പോൾ ഡാറ്റാബേസിനുള്ള ഉപയോക്തൃനാമം എവിടെ സംഭരിക്കും?"
• jinja: {{ jinja }} - nosql നോട്ട് നോസെൻസ് സോഫ്റ്റ് പ്ലാസ്റ്റിൻ. നിങ്ങൾ പ്രതീക്ഷിക്കാത്തിടത്ത് പോലും അത് എല്ലായിടത്തും ഉണ്ട്. കുറച്ച് കുറിച്ച് !!unsafe ഒപ്പം സ്വാദിഷ്ടമായ ചേനയും.

അവലംബം: www.habr.com