மற்றவர்களின் அன்சிபிள் குறியீட்டை நான் நிறைய மதிப்பாய்வு செய்கிறேன் மற்றும் நானே நிறைய எழுதுகிறேன். தவறுகளை பகுப்பாய்வு செய்யும் போது (மற்றவர்கள் மற்றும் எனது சொந்தம்), அத்துடன் பல நேர்காணல்களில், அன்சிபிள் பயனர்கள் செய்யும் முக்கிய தவறை நான் உணர்ந்தேன் - அவர்கள் அடிப்படை விஷயங்களை மாஸ்டர் செய்யாமல் சிக்கலான விஷயங்களில் ஈடுபடுகிறார்கள்.

இந்த உலகளாவிய அநீதியை சரிசெய்ய, ஏற்கனவே தெரிந்தவர்களுக்கு அன்சிபில் ஒரு அறிமுகத்தை எழுத முடிவு செய்தேன். நான் உங்களை எச்சரிக்கிறேன், இது மனிதர்களின் மறுபரிசீலனை அல்ல, இது நிறைய கடிதங்கள் மற்றும் படங்கள் இல்லாத நீண்ட வாசிப்பு.

வாசகரின் எதிர்பார்ப்பு நிலை என்னவென்றால், யம்லாவின் பல ஆயிரம் வரிகள் ஏற்கனவே எழுதப்பட்டுள்ளன, ஏற்கனவே ஏதோ தயாரிப்பில் உள்ளது, ஆனால் "எப்படியோ எல்லாம் வளைந்துவிட்டது."

பெயர்கள்

ஒரு அன்சிபிள் பயனர் செய்யும் முக்கிய தவறு, எதையாவது அழைக்கப்படுகிறது என்பதை அறியாதது. உங்களுக்கு பெயர்கள் தெரியாவிட்டால், ஆவணம் என்ன சொல்கிறது என்பதை நீங்கள் புரிந்து கொள்ள முடியாது. ஒரு வாழ்க்கை உதாரணம்: ஒரு நேர்காணலின் போது, ​​​​அன்சிபில் நிறைய எழுதியதாகக் கூறத் தோன்றிய ஒருவரால் "ஒரு பிளேபுக் என்ன கூறுகளைக் கொண்டுள்ளது?" என்ற கேள்விக்கு பதிலளிக்க முடியவில்லை. "ப்ளேபுக் விளையாட்டைக் கொண்டுள்ளது என்று பதில் எதிர்பார்க்கப்பட்டது" என்று நான் பரிந்துரைத்தபோது, ​​"நாங்கள் அதைப் பயன்படுத்துவதில்லை" என்ற மோசமான கருத்து தொடர்ந்து வந்தது. மக்கள் பணத்திற்காக Ansible என்று எழுதுகிறார்கள், விளையாட்டைப் பயன்படுத்துவதில்லை. அவர்கள் உண்மையில் அதைப் பயன்படுத்துகிறார்கள், ஆனால் அது என்னவென்று தெரியவில்லை.

எனவே எளிமையான ஒன்றைத் தொடங்குவோம்: அது என்ன அழைக்கப்படுகிறது. ஆவணத்தைப் படிக்கும்போது நீங்கள் கவனம் செலுத்தாததால் இது உங்களுக்குத் தெரிந்திருக்கலாம் அல்லது தெரியாமலிருக்கலாம்.

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" இல் எதையாவது சேர்க்க வேண்டாம், ஆனால் புதிதாக எழுதவும். ஹார்ட்கோடட் மாறிகள் கூட.

மேலே உள்ள பத்திகளில் எல்லாம் சரியாகச் சொல்லப்பட்டிருப்பதாகத் தெரிகிறது. ஆனால் இது உங்கள் வழக்கு அல்ல! ஏனெனில் நீங்கள் உலர்ந்த மற்றும் நூலகம் போன்ற மறுபயன்பாட்டு குறியீட்டை எழுத விரும்புகிறீர்கள், மேலும் அதை எப்படி செய்வது என்பது குறித்த ஒரு முறையை நீங்கள் தேட வேண்டும்.

இங்குதான் இன்னொரு பெரிய தவறு ஒளிந்திருக்கிறது. சகிப்புத்தன்மையுடன் எழுதப்பட்ட பல திட்டங்களை (அது சிறப்பாக இருக்கலாம், ஆனால் எல்லாம் வேலை செய்கிறது மற்றும் முடிக்க எளிதானது) ஒரு முழுமையான திகிலாக மாற்றிய பிழை, ஆசிரியரால் கூட கண்டுபிடிக்க முடியாத ஒரு முழுமையான திகில் ஆகும். இது வேலை செய்கிறது, ஆனால் நீங்கள் எதையும் மாற்றுவதை கடவுள் தடுக்கிறார்.

பிழை: பாத்திரம் ஒரு நூலக செயல்பாடு. இந்த ஒப்புமை பல நல்ல தொடக்கங்களை அழித்துவிட்டது, பார்ப்பதற்கு வருத்தமாக இருக்கிறது. பங்கு ஒரு நூலக செயல்பாடு அல்ல. அவளால் கணக்கீடுகளைச் செய்ய முடியாது மற்றும் அவளால் விளையாட்டு நிலை முடிவுகளை எடுக்க முடியாது. விளையாட்டு என்ன முடிவுகளை எடுக்கிறது என்பதை எனக்கு நினைவூட்டுங்கள்?

நன்றி, நீங்கள் சொல்வது சரிதான். எந்தெந்த ஹோஸ்ட்களில் எந்தப் பணிகள் மற்றும் பாத்திரங்களைச் செய்வது என்பது பற்றிய முடிவை Play எடுக்கிறது (இன்னும் துல்லியமாக, அதில் தகவல் உள்ளது).

இந்த முடிவை நீங்கள் ஒரு பங்கிற்கு ஒப்படைத்தால், மற்றும் கணக்கீடுகளுடன் கூட, உங்களை நீங்களே (உங்கள் குறியீட்டைப் பாகுபடுத்த முயற்சிப்பவரை) ஒரு பரிதாபகரமான இருப்புக்கு ஆளாக்குவீர்கள். பாத்திரம் எங்கு நடிக்க வேண்டும் என்பதை முடிவு செய்வதில்லை. இந்த முடிவு விளையாட்டின் மூலம் எடுக்கப்படுகிறது. பாத்திரம் சொன்னதை, சொன்ன இடத்தில் செய்கிறது.

Ansible இல் நிரல் செய்வது ஏன் ஆபத்தானது மற்றும் ஏன் COBOL ஏன் Ansible ஐ விட சிறந்தது என்று மாறிகள் மற்றும் ஜின்ஜா பற்றி அத்தியாயத்தில் பேசுவோம். இப்போதைக்கு, ஒரு விஷயத்தைச் சொல்லலாம் - உங்கள் கணக்கீடுகள் ஒவ்வொன்றும் உலகளாவிய மாறிகளில் ஏற்படும் மாற்றங்களின் அழியாத தடயத்தை விட்டுச்செல்கின்றன, மேலும் இதைப் பற்றி நீங்கள் எதுவும் செய்ய முடியாது. இரண்டு "தடங்கள்" வெட்டப்பட்டவுடன், எல்லாம் போய்விட்டது.

கசப்பானவர்களுக்கான குறிப்பு: பங்கு நிச்சயமாக கட்டுப்பாட்டு ஓட்டத்தை பாதிக்கலாம். சாப்பிடு delegate_to மேலும் இது நியாயமான பயன்பாடுகளைக் கொண்டுள்ளது. சாப்பிடு meta: end host/play. ஆனாலும்! நாங்கள் அடிப்படைகளை கற்பிக்கிறோம் என்பதை நினைவில் கொள்கிறீர்களா? மறந்துவிட்டது delegate_to. நாங்கள் எளிமையான மற்றும் அழகான அன்சிபிள் குறியீட்டைப் பற்றி பேசுகிறோம். படிக்க எளிதானது, எழுத எளிதானது, பிழைத்திருத்தம் செய்வது எளிது, சோதிக்க எளிதானது மற்றும் முடிக்க எளிதானது. எனவே, மீண்டும் ஒருமுறை:

விளையாடுவது மற்றும் விளையாடுவது எந்த ஹோஸ்ட்களை செயல்படுத்துகிறது என்பதை மட்டுமே தீர்மானிக்கிறது.

இந்த பிரிவில், நாடகத்திற்கும் பாத்திரத்திற்கும் இடையிலான எதிர்ப்பைக் கையாண்டோம். இப்போது பணிகள் மற்றும் பங்கு உறவு பற்றி பேசலாம்.

பணிகள் மற்றும் பாத்திரங்கள்

விளையாடுவதைக் கவனியுங்கள்:

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

நீங்கள் foo செய்ய வேண்டும் என்று சொல்லலாம். மற்றும் அது போல் தெரிகிறது foo: name=foobar state=present. இதை நான் எங்கே எழுத வேண்டும்? முன்? அஞ்சல்? ஒரு பாத்திரத்தை உருவாக்கவா?

... மற்றும் பணிகள் எங்கு சென்றன?

நாங்கள் மீண்டும் அடிப்படைகளுடன் தொடங்குகிறோம் - விளையாட்டு சாதனம். இந்த சிக்கலில் நீங்கள் மிதந்தால், மற்ற அனைத்திற்கும் நீங்கள் விளையாட்டை ஒரு அடிப்படையாகப் பயன்படுத்த முடியாது, மேலும் உங்கள் முடிவு "அதிர்ச்சியாக" இருக்கும்.

சாதனத்தை இயக்கு: ஹோஸ்ட்கள் உத்தரவு, விளையாடுவதற்கான அமைப்புகள் மற்றும் முன்_பணிகள், பணிகள், பாத்திரங்கள், 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, bar மற்றும் baz செய்ய வேண்டும். இந்த மூன்று பணிகளும், ஒரு பாத்திரமா அல்லது மூன்று பாத்திரங்களா? கேள்வியை சுருக்கமாக: எந்த கட்டத்தில் நீங்கள் பாத்திரங்களை எழுத ஆரம்பிக்க வேண்டும்? டாஸ்க்குகளை எழுதும் போது பாத்திரங்களை எழுதி என்ன பயன்?... ரோல் என்றால் என்ன?

மிகப் பெரிய தவறுகளில் ஒன்று (நான் ஏற்கனவே இதைப் பற்றி பேசினேன்) ஒரு நிரலின் நூலகத்தில் ஒரு செயல்பாடு போன்றது என்று நினைப்பது. பொதுவான செயல்பாடு விளக்கம் எப்படி இருக்கும்? இது உள்ளீட்டு வாதங்களை ஏற்றுக்கொள்கிறது, பக்க காரணங்களுடன் தொடர்பு கொள்கிறது, பக்க விளைவுகளைச் செய்கிறது மற்றும் மதிப்பை வழங்குகிறது.

இப்போது, ​​கவனம். இந்த பாத்திரத்தில் இருந்து என்ன செய்ய முடியும்? பக்க விளைவுகளை அழைக்க நீங்கள் எப்போதும் வரவேற்கப்படுகிறீர்கள், இது முழு அன்சிபிலின் சாராம்சம் - பக்க விளைவுகளை உருவாக்க. பக்க காரணங்கள் உள்ளதா? தொடக்கநிலை. ஆனால் "ஒரு மதிப்பைக் கடந்து அதைத் திருப்பித் தரவும்" - அது வேலை செய்யாது. முதலில், நீங்கள் ஒரு பாத்திரத்திற்கு மதிப்பை அனுப்ப முடியாது. பாத்திரத்திற்கான 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:

பாத்திரத்தின் கையாளுபவர்கள் பாத்திரப்பெயர்/கையாளுபவர்கள்/main.yaml இல் உள்ளனர். நாடகத்தில் பங்கேற்பாளர்கள் அனைவருக்கும் இடையே ஹேண்ட்லர்கள் சலசலப்பு: முன்/பின்_பணிகள் ரோல் ஹேண்ட்லர்களை இழுக்க முடியும், மேலும் ஒரு பாத்திரம் நாடகத்திலிருந்து ஹேண்ட்லர்களை இழுக்க முடியும். இருப்பினும், ஹேண்ட்லர்களுக்கான "கிராஸ்-ரோல்" அழைப்புகள், அற்பமான ஹேண்ட்லரை மீண்டும் செய்வதை விட அதிக wtf ஐ ஏற்படுத்துகிறது. (சிறந்த நடைமுறைகளின் மற்றொரு அம்சம், கையாளுபவரின் பெயர்களை மீண்டும் செய்யாமல் இருப்பது).

முக்கிய வேறுபாடு என்னவென்றால், பணி எப்போதும் செயல்படுத்தப்படும் (சுத்தமில்லாமல்) (பிளஸ்/மைனஸ் குறிச்சொற்கள் மற்றும் when), மற்றும் கையாளுபவர் - மாநில மாற்றம் (அது மாற்றப்பட்டிருந்தால் மட்டுமே தீயை அறிவிக்கவும்). இதன் பொருள் என்ன? எடுத்துக்காட்டாக, நீங்கள் மறுதொடக்கம் செய்யும் போது, ​​எந்த மாற்றமும் இல்லை என்றால், எந்த ஹேண்ட்லரும் இருக்காது. உருவாக்கும் பணியில் எந்த மாற்றமும் இல்லாதபோது நாம் ஏன் ஹேண்ட்லரை இயக்க வேண்டும்? உதாரணமாக, ஏதோ உடைந்து மாறியதால், ஆனால் செயல்படுத்தல் கையாளுபவரை அடையவில்லை. எடுத்துக்காட்டாக, நெட்வொர்க் தற்காலிகமாக செயலிழந்ததால். கட்டமைப்பு மாற்றப்பட்டது, சேவை மறுதொடக்கம் செய்யப்படவில்லை. அடுத்த முறை நீங்கள் அதைத் தொடங்கும்போது, ​​​​கட்டமைப்பு இனி மாறாது, மேலும் சேவை கட்டமைப்பின் பழைய பதிப்பில் இருக்கும்.

கட்டமைப்பின் நிலைமையை தீர்க்க முடியாது (இன்னும் துல்லியமாக, கோப்பு கொடிகள் போன்றவற்றுடன் உங்களுக்காக ஒரு சிறப்பு மறுதொடக்கம் நெறிமுறையை நீங்கள் கண்டுபிடிக்கலாம், ஆனால் இது இனி எந்த வடிவத்திலும் 'அடிப்படை ஆன்சிபிள்' அல்ல). ஆனால் மற்றொரு பொதுவான கதை உள்ளது: நாங்கள் பயன்பாட்டை நிறுவி, பதிவு செய்தோம் .service-கோப்பு, இப்போது நாம் அதை விரும்புகிறோம் daemon_reload и state=started. மேலும் இதற்கான இயற்கையான இடம் கையாளுபவராகத் தெரிகிறது. ஆனால் நீங்கள் அதை ஒரு கையாளுபவராக இல்லாமல், பணிப்பட்டியல் அல்லது பாத்திரத்தின் முடிவில் ஒரு பணியாக மாற்றினால், அது ஒவ்வொரு முறையும் திறமையற்ற முறையில் செயல்படுத்தப்படும். நடுவில் ப்ளேபுக் உடைந்தாலும். இது மறுதொடக்கம் செய்யப்பட்ட சிக்கலைத் தீர்க்காது (மறுதொடக்கம் செய்யப்பட்ட பண்புக்கூறுடன் நீங்கள் ஒரு பணியைச் செய்ய முடியாது, ஏனெனில் ஐடிம்போடென்சி இழக்கப்படுகிறது), ஆனால் இது நிச்சயமாக மதிப்புக்குரியது நிலை = தொடங்கப்பட்டது, பிளேபுக்குகளின் ஒட்டுமொத்த நிலைத்தன்மை அதிகரிக்கிறது, ஏனெனில் இணைப்புகளின் எண்ணிக்கை மற்றும் மாறும் நிலை குறைகிறது.

கையாளுபவரின் மற்றொரு நேர்மறையான பண்பு என்னவென்றால், அது வெளியீட்டை அடைக்காது. எந்த மாற்றமும் இல்லை - கூடுதல் தவிர்க்கப்பட்டது அல்லது வெளியீட்டில் சரி இல்லை - படிக்க எளிதானது. இது ஒரு எதிர்மறையான சொத்து - முதல் ஓட்டத்திலேயே நேரியல் முறையில் செயல்படுத்தப்பட்ட பணியில் எழுத்துப்பிழையை நீங்கள் கண்டால், ஹேண்ட்லர்கள் மாற்றப்படும் போது மட்டுமே செயல்படுத்தப்படும், அதாவது. சில நிபந்தனைகளின் கீழ் - மிகவும் அரிதாக. உதாரணமாக, ஐந்து ஆண்டுகளுக்குப் பிறகு என் வாழ்க்கையில் முதல் முறையாக. மற்றும், நிச்சயமாக, பெயரில் ஒரு எழுத்துப்பிழை இருக்கும் மற்றும் எல்லாம் உடைந்துவிடும். நீங்கள் அவற்றை இரண்டாவது முறையாக இயக்கவில்லை என்றால், எந்த மாற்றமும் இல்லை.

தனித்தனியாக, மாறிகளின் கிடைக்கும் தன்மை பற்றி நாம் பேச வேண்டும். எடுத்துக்காட்டாக, ஒரு பணியை லூப் மூலம் அறிவித்தால், மாறிகளில் என்ன இருக்கும்? நீங்கள் பகுப்பாய்வு ரீதியாக யூகிக்க முடியும், ஆனால் இது எப்போதும் அற்பமானது அல்ல, குறிப்பாக மாறிகள் வெவ்வேறு இடங்களிலிருந்து வந்தால்.

... எனவே கையாளுபவர்கள் மிகவும் குறைவான பயனுள்ளவர்கள் மற்றும் அவர்கள் தோன்றுவதை விட மிகவும் சிக்கலானவர்கள். கையாளுபவர்கள் இல்லாமலேயே (சுறுசுறுப்பு இல்லாமல்) எதையாவது அழகாக எழுத முடிந்தால், அவர்கள் இல்லாமல் அதைச் செய்வது நல்லது. அது அழகாக வேலை செய்யவில்லை என்றால், அது அவர்களுடன் சிறந்தது.

நாங்கள் விவாதிக்கவில்லை என்பதை அரிக்கும் வாசகர் சரியாக சுட்டிக்காட்டுகிறார் listenஒரு ஹேண்ட்லர் மற்றொரு ஹேண்ட்லருக்கு அறிவிப்பை அழைக்கலாம், ஒரு ஹேண்ட்லர் இறக்குமதி_பணிகளைச் சேர்க்கலாம் (இதில்_உருப்படிகளுடன்_சேர்க்க முடியும்), அன்சிபில் உள்ள ஹேண்ட்லர் சிஸ்டம் டூரிங்-கம்ப்ளீட், ஆன்சிபில் ஹேண்ட்லர் சிஸ்டம் டூரிங்-கம்ப்ளீட், விளையாடும் ஹேண்ட்லர்களுடன் ஆர்வமாக குறுக்கிடுகிறது, முதலியன .d. - இவை அனைத்தும் தெளிவாக "அடிப்படைகள்" அல்ல).

ஒரு குறிப்பிட்ட WTF இருந்தாலும் அது உண்மையில் நீங்கள் மனதில் கொள்ள வேண்டிய அம்சமாகும். உங்கள் பணி நிறைவேற்றப்பட்டால் delegate_to மற்றும் அது தெரிவிக்கிறது, பின்னர் தொடர்புடைய கையாளுபவர் இல்லாமல் செயல்படுத்தப்படும் delegate_to, அதாவது நாடகம் ஒதுக்கப்படும் ஹோஸ்டில். (நிச்சயமாக, கையாளுபவர் இருக்கலாம் delegate_to அதே).

தனித்தனியாக, மீண்டும் பயன்படுத்தக்கூடிய பாத்திரங்களைப் பற்றி சில வார்த்தைகளைச் சொல்ல விரும்புகிறேன். சேகரிப்புகள் தோன்றுவதற்கு முன்பு, நீங்கள் உலகளாவிய பாத்திரங்களை உருவாக்கலாம் என்ற எண்ணம் இருந்தது ansible-galaxy install மற்றும் சென்றார். எல்லா சூழ்நிலைகளிலும் அனைத்து வகைகளின் அனைத்து OS இல் வேலை செய்கிறது. எனவே, என் கருத்து: அது வேலை செய்யாது. நிறை கொண்ட எந்த வேடமும் include_vars. அவை பாரிய சோதனைகளால் மூடப்பட்டிருக்கும், ஆனால் எந்தவொரு சோதனையையும் போலவே, உங்களிடம் உள்ளீட்டு மதிப்புகளின் கார்ட்டீசியன் தயாரிப்பு மற்றும் மொத்த செயல்பாடு உள்ளது, அல்லது உங்களிடம் "தனிப்பட்ட காட்சிகள்" உள்ளன. என் கருத்து என்னவென்றால், பாத்திரம் நேரியல் (சைக்ளோமாடிக் சிக்கலானது 100500) இருந்தால் மிகவும் நல்லது.

குறைவான ifs (வெளிப்படையான அல்லது அறிவிப்பு - வடிவத்தில் when அல்லது வடிவம் include_vars மாறிகளின் தொகுப்பின் மூலம்), சிறந்த பாத்திரம். சில நேரங்களில் நீங்கள் கிளைகளை உருவாக்க வேண்டும், ஆனால், நான் மீண்டும் சொல்கிறேன், குறைவாக உள்ளன, சிறந்தது. எனவே இது கேலக்ஸியுடன் (அது வேலை செய்கிறது!) ஒரு நல்ல பாத்திரமாக தெரிகிறது when ஐந்து பணிகளில் இருந்து "ஒருவரின் சொந்த" பாத்திரத்தை விட குறைவாக விரும்பத்தக்கதாக இருக்கலாம். நீங்கள் எதையாவது எழுதத் தொடங்கும் போது கேலக்ஸியுடன் பாத்திரம் சிறப்பாக இருக்கும் தருணம். அது மோசமடையும் தருணம் என்னவென்றால், ஏதாவது உடைந்தால், அது “கேலக்ஸியுடன் பங்கு” காரணமாக இருக்குமோ என்று உங்களுக்கு சந்தேகம். நீங்கள் அதைத் திறந்து, ஐந்து சேர்த்தல்கள், எட்டு பணித் தாள்கள் மற்றும் ஒரு ஸ்டாக் உள்ளன when'ஓ... இதை நாம் கண்டுபிடிக்க வேண்டும். 5 பணிகளுக்குப் பதிலாக, உடைக்க எதுவும் இல்லாத நேரியல் பட்டியல்.

பின்வரும் பகுதிகளில்

• சரக்கு, குழு மாறிகள், host_group_vars செருகுநிரல், ஹோஸ்ட்வார்கள் பற்றி கொஞ்சம். ஸ்பாகெட்டியுடன் கோர்டியன் முடிச்சை எப்படி கட்டுவது. நோக்கம் மற்றும் முன்னுரிமை மாறிகள், அன்சிபிள் நினைவக மாதிரி. "அப்படியானால் தரவுத்தளத்திற்கான பயனர்பெயரை எங்கே சேமிப்பது?"
• jinja: {{ jinja }} - nosql notype nosense மென்மையான பிளாஸ்டைன். நீங்கள் எதிர்பார்க்காத இடத்தில் கூட இது எல்லா இடங்களிலும் உள்ளது. பற்றி கொஞ்சம் !!unsafe மற்றும் சுவையான யாழ்.

ஆதாரம்: www.habr.com