నేను ఇతరుల Ansible కోడ్‌కి సంబంధించి చాలా సమీక్షలు చేస్తాను మరియు స్వయంగా చాలా వ్రాస్తాను. పొరపాట్లను (ఇతరుల మరియు నా స్వంతం రెండూ), అలాగే అనేక ఇంటర్వ్యూలను విశ్లేషించే క్రమంలో, అన్సిబుల్ వినియోగదారులు చేసే ప్రధాన తప్పును నేను గ్రహించాను - వారు ప్రాథమిక వాటిని ప్రావీణ్యం చేయకుండా సంక్లిష్టమైన విషయాలలోకి ప్రవేశిస్తారు.

ఈ సార్వత్రిక అన్యాయాన్ని సరిదిద్దడానికి, ఇది ఇప్పటికే తెలిసిన వారి కోసం అన్సిబుల్‌కు పరిచయం రాయాలని నిర్ణయించుకున్నాను. నేను మిమ్మల్ని హెచ్చరిస్తున్నాను, ఇది మనుష్యుల రీటెల్లింగ్ కాదు, ఇది చాలా అక్షరాలు మరియు చిత్రాలు లేని లాంగ్ రీడ్.

పాఠకుల అంచనా స్థాయి ఏమిటంటే, ఇప్పటికే అనేక వేల పంక్తులు యమ్లా వ్రాయబడ్డాయి, ఇప్పటికే ఏదో ఉత్పత్తిలో ఉంది, కానీ "ఏదో ఒకవిధంగా ప్రతిదీ వంకరగా ఉంది."

పేర్లు

Ansible వినియోగదారు చేసే ప్రధాన తప్పు ఏమిటంటే, దాన్ని ఏమని పిలుస్తారో తెలియకపోవడం. మీకు పేర్లు తెలియకపోతే, డాక్యుమెంటేషన్ ఏమి చెబుతుందో మీరు అర్థం చేసుకోలేరు. ఒక సజీవ ఉదాహరణ: ఒక ఇంటర్వ్యూలో, అతను అన్సిబుల్‌లో చాలా రాశాడని చెప్పినట్లు అనిపించిన వ్యక్తి “ప్లేబుక్ ఏ అంశాలను కలిగి ఉంటుంది?” అనే ప్రశ్నకు సమాధానం ఇవ్వలేకపోయాడు. మరియు "ప్లేబుక్‌లో ప్లే ఉందని సమాధానం ఊహించబడింది" అని నేను సూచించినప్పుడు, "మేము దానిని ఉపయోగించము" అనే హేయమైన వ్యాఖ్య అనుసరించింది. ప్రజలు డబ్బు కోసం 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"కి ఏదైనా జోడించవద్దు, కానీ దానిని మొదటి నుండి వ్రాయండి. హార్డ్‌కోడెడ్ వేరియబుల్స్‌తో కూడా.

పై పేరాగ్రాఫ్‌లలో అన్నీ సరిగ్గా చెప్పినట్లు అనిపిస్తుంది. కానీ ఇది మీ కేసు కాదు! ఎందుకంటే మీరు పొడిగా మరియు లైబ్రరీ లాంటి పునర్వినియోగ కోడ్‌ని వ్రాయాలనుకుంటున్నారు మరియు దీన్ని ఎలా చేయాలో మీరు ఒక పద్ధతి కోసం వెతకాలి.

ఇక్కడే మరో తీవ్రమైన తప్పు దాగి ఉంది. తట్టుకోలేని విధంగా వ్రాయబడిన అనేక ప్రాజెక్ట్‌లను (ఇది మెరుగ్గా ఉండవచ్చు, కానీ ప్రతిదీ పని చేస్తుంది మరియు పూర్తి చేయడం సులభం) నుండి రచయిత కూడా గుర్తించలేని పూర్తి భయానకంగా మార్చిన లోపం. ఇది పనిచేస్తుంది, కానీ మీరు దేనినీ మార్చకూడదని దేవుడు నిషేధించాడు.

లోపం ఏమిటంటే: పాత్ర అనేది లైబ్రరీ ఫంక్షన్. ఈ సారూప్యత చాలా మంచి ప్రారంభాలను నాశనం చేసింది, ఇది చూడటానికి విచారంగా ఉంది. పాత్ర లైబ్రరీ ఫంక్షన్ కాదు. ఆమె గణనలు చేయలేరు మరియు ఆట స్థాయి నిర్ణయాలు తీసుకోలేరు. నాటకం ఎలాంటి నిర్ణయాలు తీసుకుంటుందో నాకు గుర్తు చేస్తున్నారా?

ధన్యవాదాలు, మీరు చెప్పింది నిజమే. ప్లే ఏ హోస్ట్‌లలో ఏ విధులు మరియు పాత్రలను నిర్వహించాలనే దాని గురించి (మరింత ఖచ్చితంగా, ఇది సమాచారాన్ని కలిగి ఉంటుంది) నిర్ణయం తీసుకుంటుంది.

మీరు ఈ నిర్ణయాన్ని ఒక పాత్రకు అప్పగిస్తే మరియు గణనలతో కూడా, మీరు మీరే (మరియు మీ కోడ్‌ని అన్వయించడానికి ప్రయత్నించే వ్యక్తి) దుర్భరమైన ఉనికికి గురవుతారు. పాత్ర ఎక్కడ ప్రదర్శించబడుతుందో నిర్ణయించదు. ఈ నిర్ణయం ఆట ద్వారా తీసుకోబడుతుంది. పాత్ర చెప్పిన చోట, చెప్పినట్లు చేస్తుంది.

Ansibleలో ప్రోగ్రామ్ చేయడం ఎందుకు ప్రమాదకరం మరియు Ansible కంటే 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, అయితే ప్లేలో సెక్షన్‌ల అమలు క్రమం మీద మనం ఆధారపడగలిగితే మనకు ఫ్లష్_హ్యాండ్లర్‌లు ఎందుకు అవసరం? అంతేకాకుండా, మెటా ఉపయోగం: ఫ్లష్_హ్యాండ్లర్‌లు డూప్లికేట్ హ్యాండ్లర్‌లతో మనకు ఊహించని విషయాలను అందించగలవు, ఉపయోగించినప్పుడు మనకు వింత హెచ్చరికలను అందిస్తాయి. when у block మొదలైనవి మీకు అన్సిబుల్ బాగా తెలుసు, మీరు "గమ్మత్తైన" పరిష్కారం కోసం మరిన్ని సూక్ష్మ నైపుణ్యాలను పేర్కొనవచ్చు. మరియు ఒక సాధారణ పరిష్కారం - ముందు/పాత్రలు/పోస్ట్ మధ్య సహజ విభజనను ఉపయోగించడం - సూక్ష్మభేదాలకు కారణం కాదు.

మరియు, తిరిగి మా 'ఫూ'కి. నేను ఎక్కడ ఉంచాలి? ముందు, పోస్ట్ లేదా పాత్రలలో? సహజంగానే, ఇది ఫూ కోసం హ్యాండ్లర్ ఫలితాలు మనకు అవసరమా అనే దానిపై ఆధారపడి ఉంటుంది. అవి లేనట్లయితే, fooని ముందుగా లేదా పోస్ట్‌లో ఉంచాల్సిన అవసరం లేదు - ఈ విభాగాలకు ప్రత్యేక అర్ధం ఉంది - కోడ్ యొక్క ప్రధాన విభాగానికి ముందు మరియు తర్వాత విధులను అమలు చేయడం.

ఇప్పుడు “పాత్ర లేదా పని” అనే ప్రశ్నకు సమాధానం ఇప్పటికే ప్లేలో ఉన్నదానికి వస్తుంది - అక్కడ టాస్క్‌లు ఉంటే, మీరు వాటిని టాస్క్‌లకు జోడించాలి. పాత్రలు ఉంటే, మీరు ఒక పాత్రను సృష్టించాలి (ఒక పని నుండి కూడా). విధులు మరియు పాత్రలు ఒకే సమయంలో ఉపయోగించబడవని నేను మీకు గుర్తు చేస్తాను.

అన్సిబుల్ యొక్క ప్రాథమికాలను అర్థం చేసుకోవడం రుచికి సంబంధించిన ప్రశ్నలకు సహేతుకమైన సమాధానాలను అందిస్తుంది.

విధులు మరియు పాత్రలు (పార్ట్ టూ)

ఇప్పుడు మీరు ప్లేబుక్ రాయడం ప్రారంభించినప్పుడు పరిస్థితిని చర్చిద్దాం. మీరు ఫూ, బార్ మరియు బాజ్ తయారు చేయాలి. ఈ మూడు పనులు, ఒక పాత్రనా లేదా మూడు పాత్రలా? ప్రశ్నను సంగ్రహంగా చెప్పాలంటే: మీరు ఏ సమయంలో పాత్రలు రాయడం ప్రారంభించాలి? టాస్క్‌లు రాయగలిగినప్పుడు పాత్రలు రాయడం వల్ల ప్రయోజనం ఏమిటి?... పాత్ర అంటే ఏమిటి?

ప్రోగ్రామ్ యొక్క లైబ్రరీలో పాత్ర ఒక ఫంక్షన్ లాంటిదని భావించడం (నేను ఇప్పటికే దీని గురించి మాట్లాడాను) అతిపెద్ద తప్పులలో ఒకటి. సాధారణ ఫంక్షన్ వివరణ ఎలా ఉంటుంది? ఇది ఇన్‌పుట్ ఆర్గ్యుమెంట్‌లను అంగీకరిస్తుంది, దుష్ప్రభావాలతో పరస్పర చర్య చేస్తుంది, దుష్ప్రభావాలు చేస్తుంది మరియు విలువను అందిస్తుంది.

ఇప్పుడు, శ్రద్ధ. పాత్రలో దీని నుండి ఏమి చేయవచ్చు? దుష్ప్రభావాలకు కాల్ చేయడానికి మీరు ఎల్లప్పుడూ స్వాగతం పలుకుతారు, ఇది మొత్తం అన్సిబుల్ యొక్క సారాంశం - దుష్ప్రభావాలను సృష్టించడానికి. పక్క కారణాలు ఉన్నాయా? ప్రాథమిక. కానీ “విలువను పాస్ చేసి దాన్ని తిరిగి ఇవ్వండి”తో - అది ఎక్కడ పని చేయదు. ముందుగా, మీరు ఒక పాత్రకు విలువను పాస్ చేయలేరు. మీరు పాత్ర కోసం vars విభాగంలో జీవితకాల పరిమాణంతో గ్లోబల్ వేరియబుల్‌ని సెట్ చేయవచ్చు. మీరు రోల్‌లో జీవితకాలం పాటు గ్లోబల్ వేరియబుల్‌ని సెట్ చేయవచ్చు. లేదా ప్లేబుక్స్ జీవితకాలంతో కూడా (set_fact/register) కానీ మీరు "స్థానిక వేరియబుల్స్" కలిగి ఉండకూడదు. మీరు "విలువ తీసుకోలేరు" మరియు "దానిని తిరిగి ఇవ్వలేరు".

దీని నుండి ప్రధాన విషయం అనుసరిస్తుంది: మీరు దుష్ప్రభావాలను కలిగించకుండా Ansible లో ఏదైనా వ్రాయలేరు. గ్లోబల్ వేరియబుల్స్‌ని మార్చడం అనేది ఫంక్షన్‌కి ఎల్లప్పుడూ సైడ్ ఎఫెక్ట్. రస్ట్‌లో, ఉదాహరణకు, గ్లోబల్ వేరియబుల్‌ని మార్చడం unsafe. మరియు అన్సిబుల్‌లో పాత్ర కోసం విలువలను ప్రభావితం చేసే ఏకైక పద్ధతి ఇది. ఉపయోగించిన పదాలను గమనించండి: "పాత్రకు విలువను పాస్ చేయవద్దు", కానీ "పాత్ర ఉపయోగించే విలువలను మార్చండి". పాత్రల మధ్య ఒంటరితనం ఉండదు. విధులు మరియు పాత్రల మధ్య ఒంటరితనం లేదు.

మొత్తం: పాత్ర ఒక విధి కాదు.

పాత్రలో ఏది మంచిది? మొదట, పాత్ర డిఫాల్ట్ విలువలను కలిగి ఉంటుంది (/default/main.yaml), రెండవది, ఫైల్‌లను నిల్వ చేయడానికి పాత్రకు అదనపు డైరెక్టరీలు ఉన్నాయి.

డిఫాల్ట్ విలువల ప్రయోజనాలు ఏమిటి? ఎందుకంటే మాస్లో యొక్క పిరమిడ్‌లో, అన్సిబుల్ యొక్క కాకుండా వక్రీకరించిన వేరియబుల్ ప్రాధాన్యతల పట్టికలో, రోల్ డిఫాల్ట్‌లు అత్యంత తక్కువ-ప్రాధాన్యత (మైనస్ అన్సిబుల్ కమాండ్ లైన్ పారామితులు). దీనర్థం మీరు డిఫాల్ట్ విలువలను అందించాల్సిన అవసరం ఉంటే మరియు ఇన్వెంటరీ లేదా గ్రూప్ వేరియబుల్స్ నుండి వాటి విలువలను భర్తీ చేయడం గురించి చింతించకండి, అప్పుడు రోల్ డిఫాల్ట్‌లు మీకు సరైన స్థలం మాత్రమే. (నేను కొంచెం అబద్ధం చెబుతున్నాను - ఇంకా ఉన్నాయి |d(your_default_here), కానీ మేము స్థిర స్థలాల గురించి మాట్లాడినట్లయితే, అప్పుడు మాత్రమే పాత్ర డిఫాల్ట్‌లు).

పాత్రలలో ఇంకా గొప్పదనం ఏమిటి? ఎందుకంటే వారికి వారి స్వంత కేటలాగ్‌లు ఉన్నాయి. ఇవి వేరియబుల్స్ కోసం డైరెక్టరీలు, స్థిరమైన (అనగా పాత్ర కోసం లెక్కించినవి) మరియు డైనమిక్ (ఒక నమూనా లేదా వ్యతిరేక నమూనా ఉంది - include_vars కలిసి {{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml.) ఇవి డైరెక్టరీలు files/, templates/. అలాగే, ఇది మీ స్వంత మాడ్యూల్స్ మరియు ప్లగిన్‌లను కలిగి ఉండటానికి మిమ్మల్ని అనుమతిస్తుంది (library/) కానీ, ప్లేబుక్‌లోని టాస్క్‌లతో పోల్చితే (ఇవన్నీ కూడా కలిగి ఉండవచ్చు), ఇక్కడ ఉన్న ఏకైక ప్రయోజనం ఏమిటంటే, ఫైల్‌లు ఒక పైల్‌లోకి డంప్ చేయబడవు, కానీ అనేక వేర్వేరు పైల్స్.

మరో వివరాలు: మీరు పునర్వినియోగం కోసం అందుబాటులో ఉండే పాత్రలను సృష్టించడానికి ప్రయత్నించవచ్చు (గెలాక్సీ ద్వారా). కలెక్షన్ల రాకతో, పాత్ర పంపిణీ దాదాపు మర్చిపోయినట్లు పరిగణించవచ్చు.

అందువల్ల, పాత్రలు రెండు ముఖ్యమైన లక్షణాలను కలిగి ఉంటాయి: అవి డిఫాల్ట్‌లను కలిగి ఉంటాయి (ఒక ప్రత్యేక లక్షణం) మరియు అవి మీ కోడ్‌ను రూపొందించడానికి మిమ్మల్ని అనుమతిస్తాయి.

అసలు ప్రశ్నకు తిరిగి వస్తున్నాము: పనులు ఎప్పుడు చేయాలి మరియు పాత్రలు ఎప్పుడు చేయాలి? ప్లేబుక్‌లోని టాస్క్‌లు చాలా తరచుగా పాత్రలకు ముందు/తర్వాత "జిగురు"గా లేదా స్వతంత్ర నిర్మాణ అంశంగా ఉపయోగించబడతాయి (అప్పుడు కోడ్‌లో పాత్రలు ఉండకూడదు). పాత్రలతో కలిపిన సాధారణ పనుల కుప్ప నిస్సందేహమైన అలసత్వం. మీరు ఒక నిర్దిష్ట శైలికి కట్టుబడి ఉండాలి - ఒక పని లేదా పాత్ర. పాత్రలు ఎంటిటీలు మరియు డిఫాల్ట్‌ల విభజనను అందిస్తాయి, టాస్క్‌లు కోడ్‌ని వేగంగా చదవడానికి మిమ్మల్ని అనుమతిస్తాయి. సాధారణంగా, మరింత "స్టేషనరీ" (ముఖ్యమైన మరియు సంక్లిష్టమైన) కోడ్ పాత్రలలో ఉంచబడుతుంది మరియు సహాయక స్క్రిప్ట్‌లు టాస్క్ స్టైల్‌లో వ్రాయబడతాయి.

ఇంపోర్ట్_రోల్‌ని ఒక పనిగా చేయడం సాధ్యమే, కానీ మీరు దీన్ని వ్రాస్తే, మీరు దీన్ని ఎందుకు చేయాలనుకుంటున్నారో మీ స్వంత సౌందర్య భావానికి వివరించడానికి సిద్ధంగా ఉండండి.

పాత్రలు పాత్రలను దిగుమతి చేసుకోవచ్చని, పాత్రలు 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 టాస్క్‌లకు బదులుగా, విచ్ఛిన్నం చేయడానికి ఏమీ లేని సరళ జాబితా.

క్రింది భాగాలలో

• ఇన్వెంటరీ, గ్రూప్ వేరియబుల్స్, హోస్ట్_గ్రూప్_వార్స్ ప్లగ్ఇన్, హోస్ట్‌వార్‌ల గురించి కొంచెం. స్పఘెట్టితో గోర్డియన్ ముడిని ఎలా కట్టాలి. స్కోప్ మరియు ప్రిసిడెన్స్ వేరియబుల్స్, అన్సిబుల్ మెమరీ మోడల్. "కాబట్టి మేము డేటాబేస్ కోసం వినియోగదారు పేరును ఎక్కడ నిల్వ చేస్తాము?"
• jinja: {{ jinja }} - nosql notype nosense సాఫ్ట్ ప్లాస్టిసిన్. మీరు ఊహించని చోట కూడా ఇది ప్రతిచోటా ఉంటుంది. గురించి కొంచెం !!unsafe మరియు రుచికరమైన యమల్.

మూలం: www.habr.com