ਮੈਂ ਹੋਰ ਲੋਕਾਂ ਦੇ ਜਵਾਬੀ ਕੋਡ ਦੀਆਂ ਬਹੁਤ ਸਾਰੀਆਂ ਸਮੀਖਿਆਵਾਂ ਕਰਦਾ ਹਾਂ ਅਤੇ ਖੁਦ ਬਹੁਤ ਕੁਝ ਲਿਖਦਾ ਹਾਂ। ਗਲਤੀਆਂ (ਦੂਜੇ ਲੋਕਾਂ ਦੀਆਂ ਅਤੇ ਮੇਰੀਆਂ ਦੋਵੇਂ) ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਦੇ ਨਾਲ-ਨਾਲ ਕਈ ਇੰਟਰਵਿਊਆਂ ਦੇ ਦੌਰਾਨ, ਮੈਨੂੰ ਮੁੱਖ ਗਲਤੀ ਦਾ ਅਹਿਸਾਸ ਹੋਇਆ ਜੋ ਜਵਾਬਦੇਹ ਉਪਭੋਗਤਾ ਕਰਦੇ ਹਨ - ਉਹ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਵਿੱਚ ਮੁਹਾਰਤ ਹਾਸਲ ਕੀਤੇ ਬਿਨਾਂ ਗੁੰਝਲਦਾਰ ਚੀਜ਼ਾਂ ਵਿੱਚ ਪੈ ਜਾਂਦੇ ਹਨ।

ਇਸ ਸਰਬਵਿਆਪੀ ਬੇਇਨਸਾਫ਼ੀ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ, ਮੈਂ ਉਹਨਾਂ ਲਈ ਜਵਾਬਦੇਹ ਲਈ ਇੱਕ ਜਾਣ-ਪਛਾਣ ਲਿਖਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਜੋ ਪਹਿਲਾਂ ਹੀ ਇਸ ਨੂੰ ਜਾਣਦੇ ਹਨ। ਮੈਂ ਤੁਹਾਨੂੰ ਚੇਤਾਵਨੀ ਦਿੰਦਾ ਹਾਂ, ਇਹ ਮਨੁੱਖਾਂ ਦੀ ਦੁਬਾਰਾ ਦੱਸਣਾ ਨਹੀਂ ਹੈ, ਇਹ ਬਹੁਤ ਸਾਰੇ ਅੱਖਰਾਂ ਅਤੇ ਕੋਈ ਤਸਵੀਰਾਂ ਵਾਲੀ ਲੰਮੀ ਰੀਡ ਹੈ।

ਪਾਠਕ ਦਾ ਅਨੁਮਾਨਿਤ ਪੱਧਰ ਇਹ ਹੈ ਕਿ ਯਮਲਾ ਦੀਆਂ ਕਈ ਹਜ਼ਾਰ ਲਾਈਨਾਂ ਪਹਿਲਾਂ ਹੀ ਲਿਖੀਆਂ ਜਾ ਚੁੱਕੀਆਂ ਹਨ, ਕੁਝ ਪਹਿਲਾਂ ਹੀ ਉਤਪਾਦਨ ਵਿੱਚ ਹੈ, ਪਰ "ਕਿਸੇ ਤਰ੍ਹਾਂ ਹਰ ਚੀਜ਼ ਟੇਢੀ ਹੈ।"

ਸਿਰਲੇਖ

ਇੱਕ ਜਵਾਬਦੇਹ ਉਪਭੋਗਤਾ ਜੋ ਮੁੱਖ ਗਲਤੀ ਕਰਦਾ ਹੈ ਉਹ ਇਹ ਨਹੀਂ ਜਾਣਦਾ ਹੈ ਕਿ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਕੀ ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਨਾਮ ਨਹੀਂ ਜਾਣਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇਹ ਨਹੀਂ ਸਮਝ ਸਕਦੇ ਕਿ ਦਸਤਾਵੇਜ਼ ਕੀ ਕਹਿੰਦਾ ਹੈ। ਇੱਕ ਜਿਉਂਦੀ ਜਾਗਦੀ ਉਦਾਹਰਣ: ਇੱਕ ਇੰਟਰਵਿਊ ਦੌਰਾਨ, ਇੱਕ ਵਿਅਕਤੀ ਜੋ ਇਹ ਕਹਿੰਦਾ ਜਾਪਦਾ ਸੀ ਕਿ ਉਸਨੇ ਜਵਾਬ ਵਿੱਚ ਬਹੁਤ ਕੁਝ ਲਿਖਿਆ ਹੈ, ਇਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਿਆ ਕਿ "ਇੱਕ ਪਲੇਬੁੱਕ ਵਿੱਚ ਕਿਹੜੇ ਤੱਤ ਹੁੰਦੇ ਹਨ?" ਅਤੇ ਜਦੋਂ ਮੈਂ ਸੁਝਾਅ ਦਿੱਤਾ ਕਿ "ਜਵਾਬ ਦੀ ਉਮੀਦ ਕੀਤੀ ਗਈ ਸੀ ਕਿ ਪਲੇਬੁੱਕ ਵਿੱਚ ਖੇਡ ਸ਼ਾਮਲ ਹੈ," ਤਾਂ ਘਿਨਾਉਣੀ ਟਿੱਪਣੀ "ਅਸੀਂ ਇਸਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ" ਦਾ ਅਨੁਸਰਣ ਕੀਤਾ। ਲੋਕ ਪੈਸੇ ਲਈ ਜਵਾਬਦੇਹ ਲਿਖਦੇ ਹਨ ਅਤੇ ਖੇਡ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ। ਉਹ ਅਸਲ ਵਿੱਚ ਇਸਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਪਰ ਇਹ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਇਹ ਕੀ ਹੈ.

ਤਾਂ ਆਓ ਕੁਝ ਸਧਾਰਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੀਏ: ਇਸਨੂੰ ਕੀ ਕਿਹਾ ਜਾਂਦਾ ਹੈ? ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਇਹ ਜਾਣਦੇ ਹੋ, ਜਾਂ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਨਹੀਂ ਜਾਣਦੇ, ਕਿਉਂਕਿ ਜਦੋਂ ਤੁਸੀਂ ਦਸਤਾਵੇਜ਼ ਪੜ੍ਹਦੇ ਹੋ ਤਾਂ ਤੁਸੀਂ ਧਿਆਨ ਨਹੀਂ ਦਿੱਤਾ ਸੀ।

ਜਵਾਬਦੇਹ-ਪਲੇਬੁੱਕ ਪਲੇਬੁੱਕ ਨੂੰ ਚਲਾਉਂਦੀ ਹੈ। ਇੱਕ ਪਲੇਬੁੱਕ 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 ਕਰਦਾ ਹੈ। "x" ਵਿੱਚ ਕੁਝ ਨਾ ਜੋੜੋ, ਪਰ ਇਸਨੂੰ ਸਕ੍ਰੈਚ ਤੋਂ ਲਿਖੋ। ਹਾਰਡਕੋਡ ਵੇਰੀਏਬਲ ਦੇ ਨਾਲ ਵੀ.

ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਉਪਰੋਕਤ ਪੈਰਿਆਂ ਵਿੱਚ ਸਭ ਕੁਝ ਸਹੀ ਕਿਹਾ ਗਿਆ ਹੈ. ਪਰ ਇਹ ਤੁਹਾਡਾ ਕੇਸ ਨਹੀਂ ਹੈ! ਕਿਉਂਕਿ ਤੁਸੀਂ ਦੁਬਾਰਾ ਵਰਤੋਂ ਯੋਗ ਕੋਡ ਲਿਖਣਾ ਚਾਹੁੰਦੇ ਹੋ ਜੋ ਕਿ DRY ਅਤੇ ਲਾਇਬ੍ਰੇਰੀ-ਵਰਗੇ ਹੈ, ਅਤੇ ਤੁਹਾਨੂੰ ਇਸ ਨੂੰ ਕਿਵੇਂ ਕਰਨਾ ਹੈ ਇਸ ਬਾਰੇ ਇੱਕ ਢੰਗ ਲੱਭਣ ਦੀ ਲੋੜ ਹੈ।

ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਇੱਕ ਹੋਰ ਗੰਭੀਰ ਗਲਤੀ ਲੁਕੀ ਹੋਈ ਹੈ। ਇੱਕ ਗਲਤੀ ਜਿਸਨੇ ਬਹੁਤ ਸਾਰੇ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਸਹਿਣਸ਼ੀਲਤਾ ਨਾਲ ਲਿਖੇ ਤੋਂ ਬਦਲ ਦਿੱਤਾ (ਇਹ ਬਿਹਤਰ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਸਭ ਕੁਝ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਪੂਰਾ ਕਰਨਾ ਆਸਾਨ ਹੈ) ਇੱਕ ਪੂਰੀ ਦਹਿਸ਼ਤ ਵਿੱਚ ਬਦਲ ਗਿਆ ਜਿਸਦਾ ਲੇਖਕ ਵੀ ਪਤਾ ਨਹੀਂ ਲਗਾ ਸਕਦਾ। ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਰੱਬ ਤੁਹਾਨੂੰ ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਮਨ੍ਹਾ ਕਰੇ।

ਗਲਤੀ ਇਹ ਹੈ: ਰੋਲ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਫੰਕਸ਼ਨ ਹੈ। ਇਸ ਸਮਾਨਤਾ ਨੇ ਬਹੁਤ ਸਾਰੀਆਂ ਚੰਗੀਆਂ ਸ਼ੁਰੂਆਤਾਂ ਨੂੰ ਬਰਬਾਦ ਕਰ ਦਿੱਤਾ ਹੈ ਕਿ ਇਹ ਦੇਖਣਾ ਸਿਰਫ਼ ਉਦਾਸ ਹੈ. ਭੂਮਿਕਾ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਫੰਕਸ਼ਨ ਨਹੀਂ ਹੈ। ਉਹ ਗਣਨਾ ਨਹੀਂ ਕਰ ਸਕਦੀ ਅਤੇ ਉਹ ਖੇਡ-ਪੱਧਰ ਦੇ ਫੈਸਲੇ ਨਹੀਂ ਲੈ ਸਕਦੀ। ਮੈਨੂੰ ਯਾਦ ਦਿਵਾਓ ਕਿ ਖੇਡਣ ਨਾਲ ਕਿਹੜੇ ਫੈਸਲੇ ਹੁੰਦੇ ਹਨ?

ਧੰਨਵਾਦ, ਤੁਸੀਂ ਸਹੀ ਹੋ। ਪਲੇ ਇੱਕ ਫੈਸਲਾ ਲੈਂਦਾ ਹੈ (ਵਧੇਰੇ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ, ਇਸ ਵਿੱਚ ਜਾਣਕਾਰੀ ਹੁੰਦੀ ਹੈ) ਇਸ ਬਾਰੇ ਕਿ ਕਿਹੜੇ ਮੇਜ਼ਬਾਨਾਂ 'ਤੇ ਕਿਹੜੇ ਕਾਰਜ ਅਤੇ ਭੂਮਿਕਾਵਾਂ ਨਿਭਾਉਣੀਆਂ ਹਨ।

ਜੇ ਤੁਸੀਂ ਇਸ ਫੈਸਲੇ ਨੂੰ ਕਿਸੇ ਭੂਮਿਕਾ ਲਈ ਸੌਂਪਦੇ ਹੋ, ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ ਗਣਨਾਵਾਂ ਦੇ ਨਾਲ, ਤੁਸੀਂ ਆਪਣੇ ਆਪ ਨੂੰ (ਅਤੇ ਉਹ ਵਿਅਕਤੀ ਜੋ ਤੁਹਾਡੇ ਕੋਡ ਨੂੰ ਪਾਰਸ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੇਗਾ) ਨੂੰ ਇੱਕ ਤਰਸਯੋਗ ਹੋਂਦ ਲਈ ਤਬਾਹ ਕਰ ਦਿੰਦੇ ਹੋ। ਭੂਮਿਕਾ ਇਹ ਤੈਅ ਨਹੀਂ ਕਰਦੀ ਕਿ ਇਹ ਕਿੱਥੇ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇਹ ਫੈਸਲਾ ਨਾਟਕ ਦੁਆਰਾ ਕੀਤਾ ਗਿਆ ਹੈ. ਰੋਲ ਉਹੀ ਕਰਦਾ ਹੈ ਜੋ ਇਸਨੂੰ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਜਿੱਥੇ ਇਸਨੂੰ ਦੱਸਿਆ ਗਿਆ ਹੈ।

Ansible ਵਿੱਚ ਪ੍ਰੋਗਰਾਮ ਕਰਨਾ ਖ਼ਤਰਨਾਕ ਕਿਉਂ ਹੈ ਅਤੇ COBOL Ansible ਨਾਲੋਂ ਬਿਹਤਰ ਕਿਉਂ ਹੈ ਅਸੀਂ ਵੇਰੀਏਬਲ ਅਤੇ ਜਿੰਜਾ ਬਾਰੇ ਚੈਪਟਰ ਵਿੱਚ ਗੱਲ ਕਰਾਂਗੇ। ਹੁਣ ਲਈ, ਆਓ ਇੱਕ ਗੱਲ ਕਹੀਏ - ਤੁਹਾਡੀ ਹਰ ਗਣਨਾ ਗਲੋਬਲ ਵੇਰੀਏਬਲ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਦਾ ਇੱਕ ਅਮਿੱਟ ਨਿਸ਼ਾਨ ਛੱਡਦੀ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਜਿਵੇਂ ਹੀ ਦੋ "ਟਰੇਸ" ਇਕ ਦੂਜੇ ਨੂੰ ਕੱਟਦੇ ਹਨ, ਸਭ ਕੁਝ ਖਤਮ ਹੋ ਗਿਆ ਸੀ.

squeamish ਲਈ ਨੋਟ: ਭੂਮਿਕਾ ਨਿਸ਼ਚਤ ਤੌਰ 'ਤੇ ਨਿਯੰਤਰਣ ਪ੍ਰਵਾਹ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰ ਸਕਦੀ ਹੈ. ਖਾਓ 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, ਪਰ ਸਾਨੂੰ flush_handlers ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ ਜੇਕਰ ਅਸੀਂ ਖੇਡ ਵਿੱਚ ਭਾਗਾਂ ਨੂੰ ਚਲਾਉਣ ਦੇ ਕ੍ਰਮ 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹਾਂ? ਇਸ ਤੋਂ ਇਲਾਵਾ, meta: flush_handlers ਦੀ ਵਰਤੋਂ ਸਾਨੂੰ ਡੁਪਲੀਕੇਟ ਹੈਂਡਲਰਾਂ ਨਾਲ ਅਚਾਨਕ ਚੀਜ਼ਾਂ ਦੇ ਸਕਦੀ ਹੈ, ਜਦੋਂ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਤਾਂ ਸਾਨੂੰ ਅਜੀਬ ਚੇਤਾਵਨੀਆਂ ਦੇ ਸਕਦੇ ਹਨ। when у block ਆਦਿ ਜਿੰਨਾ ਬਿਹਤਰ ਤੁਸੀਂ ਜਵਾਬਦੇਹ ਨੂੰ ਜਾਣਦੇ ਹੋ, ਓਨੀ ਹੀ ਜ਼ਿਆਦਾ ਸੂਖਮਤਾਵਾਂ ਨੂੰ ਤੁਸੀਂ "ਛਲ" ਹੱਲ ਲਈ ਨਾਮ ਦੇ ਸਕਦੇ ਹੋ। ਅਤੇ ਇੱਕ ਸਧਾਰਨ ਹੱਲ - ਪੂਰਵ/ਰੋਲ/ਪੋਸਟ ਵਿਚਕਾਰ ਇੱਕ ਕੁਦਰਤੀ ਵੰਡ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ - ਸੂਖਮਤਾ ਦਾ ਕਾਰਨ ਨਹੀਂ ਬਣਦਾ।

ਅਤੇ, ਸਾਡੇ 'foo' ਵੱਲ ਵਾਪਸ। ਮੈਨੂੰ ਇਹ ਕਿੱਥੇ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ? ਪੂਰਵ, ਪੋਸਟ ਜਾਂ ਭੂਮਿਕਾਵਾਂ ਵਿੱਚ? ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਇਹ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਸਾਨੂੰ foo ਲਈ ਹੈਂਡਲਰ ਦੇ ਨਤੀਜਿਆਂ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਜੇਕਰ ਉਹ ਉੱਥੇ ਨਹੀਂ ਹਨ, ਤਾਂ foo ਨੂੰ ਪਹਿਲਾਂ ਜਾਂ ਪੋਸਟ ਵਿੱਚ ਰੱਖਣ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਹੈ - ਇਹਨਾਂ ਭਾਗਾਂ ਦਾ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਅਰਥ ਹੈ - ਕੋਡ ਦੇ ਮੁੱਖ ਭਾਗ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਕਾਰਜਾਂ ਨੂੰ ਚਲਾਉਣਾ।

ਹੁਣ "ਰੋਲ ਜਾਂ ਟਾਸਕ" ਸਵਾਲ ਦਾ ਜਵਾਬ ਉਸ ਚੀਜ਼ 'ਤੇ ਆਉਂਦਾ ਹੈ ਜੋ ਪਹਿਲਾਂ ਹੀ ਖੇਡ ਵਿੱਚ ਹੈ - ਜੇਕਰ ਉੱਥੇ ਕੰਮ ਹਨ, ਤਾਂ ਤੁਹਾਨੂੰ ਉਹਨਾਂ ਨੂੰ ਕਾਰਜਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਜੇ ਰੋਲ ਹਨ, ਤਾਂ ਤੁਹਾਨੂੰ ਇੱਕ ਰੋਲ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ (ਇੱਕ ਕੰਮ ਤੋਂ ਵੀ)। ਮੈਨੂੰ ਤੁਹਾਨੂੰ ਯਾਦ ਦਿਵਾਉਣ ਦਿਓ ਕਿ ਕੰਮ ਅਤੇ ਭੂਮਿਕਾਵਾਂ ਇੱਕੋ ਸਮੇਂ ਨਹੀਂ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।

ਜਵਾਬਦੇਹੀ ਦੀਆਂ ਮੂਲ ਗੱਲਾਂ ਨੂੰ ਸਮਝਣਾ ਸੁਆਦ ਦੇ ਪ੍ਰਤੀਤ ਹੋਣ ਵਾਲੇ ਸਵਾਲਾਂ ਦੇ ਉਚਿਤ ਜਵਾਬ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

ਕਾਰਜ ਅਤੇ ਭੂਮਿਕਾਵਾਂ (ਭਾਗ ਦੋ)

ਹੁਣ ਆਉ ਉਸ ਸਥਿਤੀ ਬਾਰੇ ਚਰਚਾ ਕਰੀਏ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਪਲੇਬੁੱਕ ਲਿਖਣਾ ਸ਼ੁਰੂ ਕਰ ਰਹੇ ਹੋ। ਤੁਹਾਨੂੰ ਫੂ, ਬਾਰ ਅਤੇ ਬਾਜ਼ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ। ਕੀ ਇਹ ਤਿੰਨ ਕੰਮ ਹਨ, ਇੱਕ ਭੂਮਿਕਾ ਜਾਂ ਤਿੰਨ ਭੂਮਿਕਾਵਾਂ? ਸਵਾਲ ਦਾ ਸਾਰ ਦੇਣ ਲਈ: ਤੁਹਾਨੂੰ ਕਿਸ ਬਿੰਦੂ 'ਤੇ ਰੋਲ ਲਿਖਣਾ ਸ਼ੁਰੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ? ਰੋਲ ਲਿਖਣ ਦਾ ਕੀ ਮਤਲਬ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਕੰਮ ਲਿਖ ਸਕਦੇ ਹੋ?... ਰੋਲ ਕੀ ਹੈ?

ਸਭ ਤੋਂ ਵੱਡੀ ਗਲਤੀਆਂ ਵਿੱਚੋਂ ਇੱਕ (ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਇਸ ਬਾਰੇ ਗੱਲ ਕੀਤੀ ਹੈ) ਇਹ ਸੋਚਣਾ ਹੈ ਕਿ ਇੱਕ ਰੋਲ ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਦੀ ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ ਇੱਕ ਫੰਕਸ਼ਨ ਵਰਗਾ ਹੈ. ਇੱਕ ਆਮ ਫੰਕਸ਼ਨ ਵੇਰਵਾ ਕਿਹੋ ਜਿਹਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ? ਇਹ ਇਨਪੁਟ ਆਰਗੂਮੈਂਟਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਸਾਈਡ ਕਾਰਨਾਂ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਦਾ ਹੈ, ਸਾਈਡ ਇਫੈਕਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਮੁੱਲ ਵਾਪਸ ਕਰਦਾ ਹੈ।

ਹੁਣ, ਧਿਆਨ. ਇਸ ਤੋਂ ਭੂਮਿਕਾ ਵਿਚ ਕੀ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ? ਸਾਈਡ ਇਫੈਕਟਸ ਨੂੰ ਕਾਲ ਕਰਨ ਲਈ ਤੁਹਾਡਾ ਹਮੇਸ਼ਾ ਸੁਆਗਤ ਹੈ, ਇਹ ਪੂਰੇ ਜਵਾਬ ਦਾ ਸਾਰ ਹੈ - ਮਾੜੇ ਪ੍ਰਭਾਵਾਂ ਨੂੰ ਬਣਾਉਣ ਲਈ. ਸਾਈਡ ਕਾਰਨ ਹਨ? ਐਲੀਮੈਂਟਰੀ। ਪਰ "ਇੱਕ ਮੁੱਲ ਪਾਸ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਵਾਪਸ ਕਰੋ" ਦੇ ਨਾਲ - ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਇਹ ਕੰਮ ਨਹੀਂ ਕਰਦਾ। ਪਹਿਲਾਂ, ਤੁਸੀਂ ਕਿਸੇ ਭੂਮਿਕਾ ਨੂੰ ਮੁੱਲ ਨਹੀਂ ਦੇ ਸਕਦੇ। ਤੁਸੀਂ ਭੂਮਿਕਾ ਲਈ 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-file, ਅਤੇ ਹੁਣ ਅਸੀਂ ਇਹ ਚਾਹੁੰਦੇ ਹਾਂ daemon_reload и state=started. ਅਤੇ ਇਸਦੇ ਲਈ ਕੁਦਰਤੀ ਸਥਾਨ ਹੈਂਡਲਰ ਜਾਪਦਾ ਹੈ. ਪਰ ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਨੂੰ ਹੈਂਡਲਰ ਨਹੀਂ ਬਲਕਿ ਇੱਕ ਟਾਸਕਲਿਸਟ ਜਾਂ ਰੋਲ ਦੇ ਅੰਤ ਵਿੱਚ ਇੱਕ ਕੰਮ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਸਨੂੰ ਹਰ ਵਾਰ ਸਮਝਦਾਰੀ ਨਾਲ ਚਲਾਇਆ ਜਾਵੇਗਾ। ਭਾਵੇਂ ਪਲੇਬੁੱਕ ਵਿਚਕਾਰੋਂ ਟੁੱਟ ਗਈ। ਇਹ ਰੀਸਟਾਰਟ ਕੀਤੀ ਸਮੱਸਿਆ ਨੂੰ ਬਿਲਕੁਲ ਵੀ ਹੱਲ ਨਹੀਂ ਕਰਦਾ ਹੈ (ਤੁਸੀਂ ਰੀਸਟਾਰਟ ਕੀਤੀ ਵਿਸ਼ੇਸ਼ਤਾ ਦੇ ਨਾਲ ਕੋਈ ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਕਿਉਂਕਿ ਇਮਪੋਟੈਂਸੀ ਖਤਮ ਹੋ ਗਈ ਹੈ), ਪਰ ਇਹ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਸਟੇਟ=ਸਟਾਰਟ ਕਰਨ ਦੇ ਯੋਗ ਹੈ, ਪਲੇਬੁੱਕ ਦੀ ਸਮੁੱਚੀ ਸਥਿਰਤਾ ਵਧਦੀ ਹੈ, ਕਿਉਂਕਿ ਕੁਨੈਕਸ਼ਨਾਂ ਦੀ ਗਿਣਤੀ ਅਤੇ ਗਤੀਸ਼ੀਲ ਅਵਸਥਾ ਘਟਦੀ ਹੈ।

ਹੈਂਡਲਰ ਦੀ ਇੱਕ ਹੋਰ ਸਕਾਰਾਤਮਕ ਵਿਸ਼ੇਸ਼ਤਾ ਇਹ ਹੈ ਕਿ ਇਹ ਆਉਟਪੁੱਟ ਨੂੰ ਬੰਦ ਨਹੀਂ ਕਰਦਾ ਹੈ। ਕੋਈ ਬਦਲਾਅ ਨਹੀਂ ਸਨ - ਆਉਟਪੁੱਟ ਵਿੱਚ ਕੋਈ ਵਾਧੂ ਛੱਡਿਆ ਜਾਂ ਠੀਕ ਨਹੀਂ - ਪੜ੍ਹਨਾ ਆਸਾਨ ਹੈ। ਇਹ ਇੱਕ ਨਕਾਰਾਤਮਕ ਸੰਪੱਤੀ ਵੀ ਹੈ - ਜੇਕਰ ਤੁਹਾਨੂੰ ਪਹਿਲੀ ਵਾਰ ਇੱਕ ਲੀਨੀਅਰਲੀ ਐਗਜ਼ੀਕਿਊਟਿਡ ਟਾਸਕ ਵਿੱਚ ਕੋਈ ਗਲਤੀ ਮਿਲਦੀ ਹੈ, ਤਾਂ ਹੈਂਡਲਰ ਉਦੋਂ ਹੀ ਲਾਗੂ ਕੀਤੇ ਜਾਣਗੇ ਜਦੋਂ ਬਦਲਿਆ ਜਾਵੇਗਾ, ਯਾਨੀ. ਕੁਝ ਹਾਲਤਾਂ ਵਿੱਚ - ਬਹੁਤ ਘੱਟ ਹੀ। ਉਦਾਹਰਨ ਲਈ, ਪੰਜ ਸਾਲ ਬਾਅਦ ਮੇਰੀ ਜ਼ਿੰਦਗੀ ਵਿੱਚ ਪਹਿਲੀ ਵਾਰ. ਅਤੇ, ਬੇਸ਼ਕ, ਨਾਮ ਵਿੱਚ ਇੱਕ ਟਾਈਪੋ ਹੋਵੇਗੀ ਅਤੇ ਸਭ ਕੁਝ ਟੁੱਟ ਜਾਵੇਗਾ. ਅਤੇ ਜੇਕਰ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਦੂਜੀ ਵਾਰ ਨਹੀਂ ਚਲਾਉਂਦੇ ਹੋ, ਤਾਂ ਕੋਈ ਬਦਲਾਵ ਨਹੀਂ ਹੈ।

ਵੱਖਰੇ ਤੌਰ 'ਤੇ, ਸਾਨੂੰ ਵੇਰੀਏਬਲਾਂ ਦੀ ਉਪਲਬਧਤਾ ਬਾਰੇ ਗੱਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਤੁਸੀਂ ਲੂਪ ਦੇ ਨਾਲ ਇੱਕ ਕੰਮ ਨੂੰ ਸੂਚਿਤ ਕਰਦੇ ਹੋ, ਤਾਂ ਵੇਰੀਏਬਲ ਵਿੱਚ ਕੀ ਹੋਵੇਗਾ? ਤੁਸੀਂ ਵਿਸ਼ਲੇਸ਼ਣਾਤਮਕ ਤੌਰ 'ਤੇ ਅੰਦਾਜ਼ਾ ਲਗਾ ਸਕਦੇ ਹੋ, ਪਰ ਇਹ ਹਮੇਸ਼ਾ ਮਾਮੂਲੀ ਨਹੀਂ ਹੁੰਦਾ, ਖਾਸ ਕਰਕੇ ਜੇ ਵੇਰੀਏਬਲ ਵੱਖ-ਵੱਖ ਥਾਵਾਂ ਤੋਂ ਆਉਂਦੇ ਹਨ।

... ਇਸ ਲਈ ਹੈਂਡਲਰ ਬਹੁਤ ਘੱਟ ਉਪਯੋਗੀ ਹੁੰਦੇ ਹਨ ਅਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਮੱਸਿਆ ਵਾਲੇ ਹੁੰਦੇ ਹਨ ਜਿੰਨਾ ਉਹ ਜਾਪਦੇ ਹਨ. ਜੇ ਤੁਸੀਂ ਹੈਂਡਲਰ ਤੋਂ ਬਿਨਾਂ ਕੁਝ ਸੋਹਣੇ ਢੰਗ ਨਾਲ (ਬਿਨਾਂ ਫਰਿੱਲਾਂ ਤੋਂ) ਲਿਖ ਸਕਦੇ ਹੋ, ਤਾਂ ਉਹਨਾਂ ਤੋਂ ਬਿਨਾਂ ਅਜਿਹਾ ਕਰਨਾ ਬਿਹਤਰ ਹੈ। ਜੇ ਇਹ ਸੁੰਦਰਤਾ ਨਾਲ ਕੰਮ ਨਹੀਂ ਕਰਦਾ, ਤਾਂ ਇਹ ਉਹਨਾਂ ਨਾਲ ਬਿਹਤਰ ਹੈ.

ਖਰਾਬ ਪਾਠਕ ਠੀਕ ਹੀ ਦੱਸਦਾ ਹੈ ਕਿ ਅਸੀਂ ਚਰਚਾ ਨਹੀਂ ਕੀਤੀ ਹੈ listenਕਿ ਇੱਕ ਹੈਂਡਲਰ ਕਿਸੇ ਹੋਰ ਹੈਂਡਲਰ ਲਈ ਸੂਚਿਤ ਕਰ ਸਕਦਾ ਹੈ, ਕਿ ਇੱਕ ਹੈਂਡਲਰ import_tasks (ਜੋ ਕਿ with_items ਦੇ ਨਾਲ include_role ਕਰ ਸਕਦਾ ਹੈ) ਨੂੰ ਸ਼ਾਮਲ ਕਰ ਸਕਦਾ ਹੈ, ਕਿ Ansible ਵਿੱਚ ਹੈਂਡਲਰ ਸਿਸਟਮ ਟਿਊਰਿੰਗ-ਪੂਰਾ ਹੈ, ਜੋ ਕਿ include_role ਤੋਂ ਹੈਂਡਲਰ ਇੱਕ ਉਤਸੁਕ ਤਰੀਕੇ ਨਾਲ ਪਲੇ ਤੋਂ ਹੈਂਡਲਰਾਂ ਦੇ ਨਾਲ ਇੱਕ ਦੂਜੇ ਨੂੰ ਕੱਟਦੇ ਹਨ, ਆਦਿ .d - ਇਹ ਸਭ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ "ਬੁਨਿਆਦੀ" ਨਹੀਂ ਹੈ)।

ਹਾਲਾਂਕਿ ਇੱਥੇ ਇੱਕ ਖਾਸ WTF ਹੈ ਜੋ ਅਸਲ ਵਿੱਚ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣ ਦੀ ਲੋੜ ਹੈ। ਜੇਕਰ ਤੁਹਾਡਾ ਕੰਮ ਇਸ ਨਾਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ delegate_to ਅਤੇ ਇਸ ਨੇ ਸੂਚਿਤ ਕੀਤਾ ਹੈ, ਫਿਰ ਸੰਬੰਧਿਤ ਹੈਂਡਲਰ ਨੂੰ ਬਿਨਾਂ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ delegate_to, i.e. ਮੇਜ਼ਬਾਨ 'ਤੇ ਜਿੱਥੇ ਖੇਡ ਨਿਰਧਾਰਤ ਕੀਤੀ ਗਈ ਹੈ। (ਹਾਲਾਂਕਿ ਹੈਂਡਲਰ, ਬੇਸ਼ੱਕ, ਹੋ ਸਕਦਾ ਹੈ 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