હું અન્ય લોકોના જવાબી કોડની ઘણી બધી સમીક્ષાઓ કરું છું અને પોતે ઘણું લખું છું. ભૂલોના વિશ્લેષણ દરમિયાન (અન્ય લોકોની અને મારી પોતાની), તેમજ સંખ્યાબંધ ઇન્ટરવ્યુ, મને સમજાયું કે જવાબદાર વપરાશકર્તાઓ જે મુખ્ય ભૂલ કરે છે - તેઓ મૂળભૂત બાબતોમાં નિપુણતા મેળવ્યા વિના જટિલ બાબતોમાં પ્રવેશ કરે છે.

આ સાર્વત્રિક અન્યાયને સુધારવા માટે, મેં જેઓ તેને પહેલેથી જ જાણતા હોય તેમના માટે જવાબ આપવાનું પરિચય લખવાનું નક્કી કર્યું. હું તમને ચેતવણી આપું છું કે, આ માણસોની રીટેલિંગ નથી, આ ઘણા બધા અક્ષરો અને કોઈ ચિત્રો સાથેની લાંબી વાંચન છે.

વાચકનું અપેક્ષિત સ્તર એ છે કે યમલાની હજારો પંક્તિઓ પહેલેથી જ લખાઈ ગઈ છે, કંઈક પહેલેથી જ નિર્માણમાં છે, પરંતુ "કોઈક રીતે બધું વાંકાચૂંકા છે."

નામો

જવાબ આપનાર વપરાશકર્તા જે મુખ્ય ભૂલ કરે છે તે એ નથી જાણવું કે કંઈક શું કહેવાય છે. જો તમે નામો જાણતા નથી, તો તમે સમજી શકતા નથી કે દસ્તાવેજ શું કહે છે. એક જીવંત ઉદાહરણ: એક ઇન્ટરવ્યુ દરમિયાન, એક વ્યક્તિ જે એવું કહેતી હોય કે તેણે જવાબમાં ઘણું લખ્યું છે તે પ્રશ્નનો જવાબ આપી શક્યો ન હતો "પ્લેબુકમાં કયા ઘટકોનો સમાવેશ થાય છે?" અને જ્યારે મેં સૂચવ્યું કે "જવાબ અપેક્ષિત હતો કે પ્લેબુકમાં નાટકનો સમાવેશ થાય છે," ત્યારે "અમે તેનો ઉપયોગ કરતા નથી" એવી નિંદાકારક ટિપ્પણી આવી. લોકો પૈસા માટે જવાબ લખે છે અને નાટકનો ઉપયોગ કરતા નથી. તેઓ ખરેખર તેનો ઉપયોગ કરે છે, પરંતુ તે શું છે તે જાણતા નથી.

તો ચાલો કંઈક સરળ સાથે શરૂ કરીએ: તેને શું કહેવાય છે. કદાચ તમે આ જાણો છો, અથવા કદાચ તમે નથી, કારણ કે જ્યારે તમે દસ્તાવેજો વાંચો ત્યારે તમે ધ્યાન આપ્યું ન હતું.

જવાબી-પ્લેબુક પ્લેબુક ચલાવે છે. પ્લેબુક એ 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" માં કંઈક ઉમેરશો નહીં, પરંતુ તેને શરૂઆતથી લખો. હાર્ડકોડેડ ચલો સાથે પણ.

એવું લાગે છે કે ઉપરના ફકરામાં બધું યોગ્ય રીતે કહેવામાં આવ્યું છે. પરંતુ આ તમારો કેસ નથી! કારણ કે તમે ફરીથી વાપરી શકાય તેવા કોડ લખવા માંગો છો જે DRY અને લાઇબ્રેરી-જેવો છે, અને તમારે તે કેવી રીતે કરવું તે માટેની પદ્ધતિ શોધવાની જરૂર છે.

આ તે છે જ્યાં બીજી ગંભીર ભૂલ છૂપાયેલી છે. એક ભૂલ જેણે ઘણા પ્રોજેક્ટ્સને સહનશીલ રીતે લખેલા (તે વધુ સારું હોઈ શકે છે, પરંતુ બધું કામ કરે છે અને સમાપ્ત કરવું સરળ છે) એક સંપૂર્ણ ભયાનકતામાં ફેરવ્યું છે જે લેખક પણ સમજી શકતા નથી. તે કામ કરે છે, પરંતુ ભગવાન તમને કંઈપણ બદલવાની મનાઈ કરે છે.

ભૂલ છે: ભૂમિકા એ લાઇબ્રેરી કાર્ય છે. આ સામ્યતાએ એટલી બધી સારી શરૂઆતને બરબાદ કરી દીધી છે કે તે જોઈને દુઃખ થાય છે. ભૂમિકા એ પુસ્તકાલયનું કાર્ય નથી. તે ગણતરીઓ કરી શકતી નથી અને તે પ્લે-લેવલના નિર્ણયો લઈ શકતી નથી. મને યાદ કરાવો કે નાટક કયા નિર્ણયો લે છે?

આભાર, તમે સાચા છો. પ્લે કયા હોસ્ટ પર કયા કાર્યો અને ભૂમિકાઓ કરવા તે વિશે નિર્ણય લે છે (વધુ સ્પષ્ટ રીતે, તેમાં માહિતી શામેલ છે).

જો તમે આ નિર્ણયને કોઈ ભૂમિકામાં સોંપો છો, અને ગણતરીઓ સાથે પણ, તો તમે તમારી જાતને (અને જે તમારા કોડને વિશ્લેષિત કરવાનો પ્રયાસ કરશે) એક કંગાળ અસ્તિત્વમાં આવશે. ભૂમિકા નક્કી કરતી નથી કે તે ક્યાં કરવામાં આવે છે. આ નિર્ણય નાટક દ્વારા લેવામાં આવે છે. ભૂમિકા તેને જે કહેવામાં આવે છે, જ્યાં તેને કહેવામાં આવે છે તે કરે છે.

શા માટે એન્સિબલમાં પ્રોગ્રામ કરવું જોખમી છે અને કોબોલ એન્સિબલ કરતાં શા માટે સારું છે અમે ચલ અને જિન્જા વિશે પ્રકરણમાં વાત કરીશું. હમણાં માટે, ચાલો એક વાત કહીએ - તમારી દરેક ગણતરીઓ વૈશ્વિક ચલોમાં ફેરફારોના અવિશ્વસનીય ટ્રેસ છોડી જાય છે, અને તમે તેના વિશે કંઈ કરી શકતા નથી. જલદી બે "ટ્રેસ" છેદે છે, બધું અદૃશ્ય થઈ ગયું.

સ્ક્વિમિશ માટે નોંધ: ભૂમિકા ચોક્કસપણે નિયંત્રણ પ્રવાહને પ્રભાવિત કરી શકે છે. ખાવું 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. મારે આ ક્યાં લખવું જોઈએ? પૂર્વમાં? પોસ્ટ? ભૂમિકા બનાવો?

...અને કાર્યો ક્યાં ગયા?

અમે ફરીથી બેઝિક્સ સાથે શરૂ કરી રહ્યા છીએ - પ્લે ડિવાઇસ. જો તમે આ મુદ્દા પર ફ્લોટ કરો છો, તો તમે બાકીની દરેક વસ્તુના આધાર તરીકે નાટકનો ઉપયોગ કરી શકતા નથી, અને તમારું પરિણામ "અસ્થિર" હશે.

પ્લે ડિવાઇસ: હોસ્ટ ડાયરેક્ટીવ, પ્લે માટે સેટિંગ્સ અને પ્રી_ટાસ્ક, કાર્યો, ભૂમિકાઓ, પોસ્ટ_ટાસ્ક વિભાગો. રમત માટેના બાકીના પરિમાણો હવે અમારા માટે મહત્વપૂર્ણ નથી.

કાર્યો અને ભૂમિકાઓ સાથેના તેમના વિભાગોનો ક્રમ: 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 વગેરે તમે જેટલી સારી રીતે જવાબો જાણો છો, તેટલી વધુ ઘોંઘાટ તમે "મુશ્કેલ" ઉકેલ માટે નામ આપી શકો છો. અને એક સરળ ઉકેલ - પૂર્વ/ભૂમિકા/પોસ્ટ વચ્ચે કુદરતી વિભાજનનો ઉપયોગ કરીને - ઘોંઘાટનું કારણ નથી.

અને, પાછા અમારા 'foo' પર. મારે તેને ક્યાં મૂકવું જોઈએ? પૂર્વ, પોસ્ટ અથવા ભૂમિકામાં? દેખીતી રીતે, આ તેના પર આધાર રાખે છે કે શું આપણને 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:

રોલના હેન્ડલર્સ rolename/handlers/main.yaml માં સ્થિત છે. હેન્ડલર્સ નાટકના બધા સહભાગીઓ વચ્ચે રમઝટ કરે છે: પ્રી/પોસ્ટ_ટાસ્ક રોલ હેન્ડલર્સને ખેંચી શકે છે, અને રોલ હેન્ડલર્સને નાટકમાંથી ખેંચી શકે છે. જો કે, હેન્ડલર્સને "ક્રોસ-રોલ" કૉલ્સ તુચ્છ હેન્ડલરને પુનરાવર્તિત કરવા કરતાં વધુ wtf નું કારણ બને છે. (શ્રેષ્ઠ પ્રેક્ટિસનું બીજું તત્વ એ છે કે હેન્ડલરના નામોનું પુનરાવર્તન ન કરવાનો પ્રયાસ કરવો).

મુખ્ય તફાવત એ છે કે કાર્ય હંમેશા (સમર્થનપૂર્વક) ચલાવવામાં આવે છે (પ્લસ/માઈનસ ટૅગ્સ અને when), અને હેન્ડલર - રાજ્યના ફેરફાર દ્વારા (જો તે બદલાયેલ હોય તો જ આગને સૂચિત કરો). આનો મતલબ શું થયો? ઉદાહરણ તરીકે, હકીકત એ છે કે જ્યારે તમે પુનઃપ્રારંભ કરો છો, જો ત્યાં કોઈ ફેરફાર થયો ન હતો, તો પછી કોઈ હેન્ડલર હશે નહીં. જ્યારે જનરેટીંગ કાર્યમાં કોઈ ફેરફાર થયો ન હતો ત્યારે આપણે હેન્ડલરને એક્ઝીક્યુટ કરવાની જરૂર કેમ પડી શકે? ઉદાહરણ તરીકે, કારણ કે કંઈક તૂટી ગયું અને બદલાયું, પરંતુ અમલ હેન્ડલર સુધી પહોંચ્યો નહીં. ઉદાહરણ તરીકે, કારણ કે નેટવર્ક અસ્થાયી રૂપે બંધ હતું. રૂપરેખા બદલાઈ ગઈ છે, સેવા પુનઃપ્રારંભ કરવામાં આવી નથી. આગલી વખતે જ્યારે તમે તેને શરૂ કરો છો, ત્યારે રૂપરેખા હવે બદલાતી નથી, અને સેવા રૂપરેખાના જૂના સંસ્કરણ સાથે રહે છે.

રૂપરેખા સાથેની પરિસ્થિતિને હલ કરી શકાતી નથી (વધુ સ્પષ્ટ રીતે, તમે ફાઇલ ફ્લેગ્સ વગેરે સાથે તમારા માટે વિશિષ્ટ પુનઃપ્રારંભ પ્રોટોકોલની શોધ કરી શકો છો, પરંતુ આ હવે કોઈપણ સ્વરૂપમાં 'મૂળભૂત જવાબ' નથી). પરંતુ બીજી સામાન્ય વાર્તા છે: અમે એપ્લિકેશન ઇન્સ્ટોલ કરી, તેને રેકોર્ડ કરી .service-ફાઈલ, અને હવે અમને તે જોઈએ છે daemon_reload и state=started. અને આ માટે કુદરતી સ્થળ હેન્ડલર લાગે છે. પરંતુ જો તમે તેને હેન્ડલર નહીં પરંતુ ટાસ્કલિસ્ટ અથવા રોલના અંતે એક ટાસ્ક બનાવો છો, તો તે દર વખતે યોગ્ય રીતે ચલાવવામાં આવશે. ભલે પ્લેબુક અધવચ્ચે જ તૂટી જાય. આ પુનઃપ્રારંભ થયેલ સમસ્યાને હલ કરતું નથી (તમે પુનઃપ્રારંભ કરેલ વિશેષતા સાથે કાર્ય કરી શકતા નથી, કારણ કે બુદ્ધિશક્તિ ખોવાઈ ગઈ છે), પરંતુ તે ચોક્કસપણે કરવા યોગ્ય છે રાજ્ય = શરુઆત, પ્લેબુકની એકંદર સ્થિરતા વધે છે, કારણ કે જોડાણોની સંખ્યા અને ગતિશીલ સ્થિતિ ઘટે છે.

હેન્ડલરની બીજી સકારાત્મક ગુણધર્મ એ છે કે તે આઉટપુટને બંધ કરતું નથી. ત્યાં કોઈ ફેરફારો ન હતા - આઉટપુટમાં કોઈ વધારાનું છોડવામાં આવ્યું નથી અથવા બરાબર નથી - વાંચવામાં સરળ છે. તે નકારાત્મક ગુણધર્મ પણ છે - જો તમને પહેલી જ વારમાં લીનિયરલી એક્ઝિક્યુટેડ ટાસ્કમાં ટાઈપો મળે, તો હેન્ડલર્સ જ્યારે બદલાશે ત્યારે જ એક્ઝિક્યુટ કરવામાં આવશે, એટલે કે. કેટલીક શરતો હેઠળ - ખૂબ જ ભાગ્યે જ. ઉદાહરણ તરીકે, પાંચ વર્ષ પછી મારા જીવનમાં પ્રથમ વખત. અને, અલબત્ત, નામમાં ટાઇપો હશે અને બધું તૂટી જશે. અને જો તમે તેમને બીજી વખત ચલાવતા નથી, તો તેમાં કોઈ ફેરફાર થતો નથી.

અલગથી, આપણે ચલોની ઉપલબ્ધતા વિશે વાત કરવાની જરૂર છે. ઉદાહરણ તરીકે, જો તમે લૂપ વડે કાર્યને સૂચિત કરો છો, તો ચલોમાં શું હશે? તમે વિશ્લેષણાત્મક રીતે અનુમાન લગાવી શકો છો, પરંતુ તે હંમેશા તુચ્છ નથી, ખાસ કરીને જો ચલો વિવિધ સ્થળોએથી આવે.

... તેથી હેન્ડલર્સ તેઓ લાગે છે તેના કરતાં ઘણા ઓછા ઉપયોગી અને વધુ સમસ્યારૂપ છે. જો તમે હેન્ડલર્સ વિના સુંદર રીતે (ફ્રીલ્સ વિના) કંઈક લખી શકો છો, તો તે તેમના વિના કરવું વધુ સારું છે. જો તે સુંદર રીતે કામ કરતું નથી, તો તે તેમની સાથે વધુ સારું છે.

કાટ લાગતા વાચક યોગ્ય રીતે નિર્દેશ કરે છે કે અમે ચર્ચા કરી નથી listenકે હેન્ડલર બીજા હેન્ડલર માટે સૂચિત કૉલ કરી શકે છે, કે હેન્ડલર import_tasks (જેમાં_items સાથે સમાવી શકે છે) નો સમાવેશ કરી શકે છે, કે Ansible માં હેન્ડલર સિસ્ટમ ટ્યુરિંગ-સંપૂર્ણ છે, કે સમાવેશ_રોલ ના હેન્ડલરો રમતના હેન્ડલરો સાથે વિચિત્ર રીતે છેદે છે, વગેરે. ડી. - આ બધું સ્પષ્ટપણે "મૂળભૂત" નથી).

જો કે ત્યાં એક વિશિષ્ટ 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