ನಾನು ಇತರ ಜನರ ಅನ್ಸಿಬಲ್ ಕೋಡ್‌ನ ಸಾಕಷ್ಟು ವಿಮರ್ಶೆಗಳನ್ನು ಮಾಡುತ್ತೇನೆ ಮತ್ತು ಬಹಳಷ್ಟು ಬರೆಯುತ್ತೇನೆ. ತಪ್ಪುಗಳನ್ನು (ಇತರ ಜನರ ಮತ್ತು ನನ್ನ ಸ್ವಂತ) ಮತ್ತು ಹಲವಾರು ಸಂದರ್ಶನಗಳನ್ನು ವಿಶ್ಲೇಷಿಸುವ ಸಂದರ್ಭದಲ್ಲಿ, ಅನ್ಸಿಬಲ್ ಬಳಕೆದಾರರು ಮಾಡುವ ಮುಖ್ಯ ತಪ್ಪನ್ನು ನಾನು ಅರಿತುಕೊಂಡೆ - ಅವರು ಮೂಲಭೂತ ವಿಷಯಗಳನ್ನು ಕರಗತ ಮಾಡಿಕೊಳ್ಳದೆ ಸಂಕೀರ್ಣ ವಿಷಯಗಳಿಗೆ ಹೋಗುತ್ತಾರೆ.

ಈ ಸಾರ್ವತ್ರಿಕ ಅನ್ಯಾಯವನ್ನು ಸರಿಪಡಿಸಲು, ನಾನು ಈಗಾಗಲೇ ತಿಳಿದಿರುವವರಿಗೆ ಅನ್ಸಿಬಲ್ಗೆ ಪರಿಚಯವನ್ನು ಬರೆಯಲು ನಿರ್ಧರಿಸಿದೆ. ನಾನು ನಿಮಗೆ ಎಚ್ಚರಿಕೆ ನೀಡುತ್ತೇನೆ, ಇದು ಮನುಷ್ಯರ ಪುನರಾವರ್ತನೆಯಲ್ಲ, ಇದು ಬಹಳಷ್ಟು ಅಕ್ಷರಗಳು ಮತ್ತು ಚಿತ್ರಗಳಿಲ್ಲದ ದೀರ್ಘ ಓದುವಿಕೆಯಾಗಿದೆ.

ಓದುಗರ ನಿರೀಕ್ಷಿತ ಮಟ್ಟವೆಂದರೆ ಯಮಲದ ಹಲವಾರು ಸಾವಿರ ಸಾಲುಗಳನ್ನು ಈಗಾಗಲೇ ಬರೆಯಲಾಗಿದೆ, ಏನಾದರೂ ಈಗಾಗಲೇ ಉತ್ಪಾದನೆಯಲ್ಲಿದೆ, ಆದರೆ "ಹೇಗಾದರೂ ಎಲ್ಲವೂ ವಕ್ರವಾಗಿದೆ."

ಹೆಸರುಗಳು

ಅನ್ಸಿಬಲ್ ಬಳಕೆದಾರರು ಮಾಡುವ ಮುಖ್ಯ ತಪ್ಪು ಏನೆಂದರೆ ಏನನ್ನು ಕರೆಯುತ್ತಾರೆ ಎಂದು ತಿಳಿಯದೇ ಇರುವುದು. ನಿಮಗೆ ಹೆಸರುಗಳು ತಿಳಿದಿಲ್ಲದಿದ್ದರೆ, ದಸ್ತಾವೇಜನ್ನು ಏನು ಹೇಳುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ. ಜೀವಂತ ಉದಾಹರಣೆ: ಸಂದರ್ಶನವೊಂದರಲ್ಲಿ, ಅವರು ಅನ್ಸಿಬಲ್‌ನಲ್ಲಿ ಬಹಳಷ್ಟು ಬರೆದಿದ್ದಾರೆ ಎಂದು ತೋರುವ ವ್ಯಕ್ತಿಯು “ಪ್ಲೇಬುಕ್ ಯಾವ ಅಂಶಗಳನ್ನು ಒಳಗೊಂಡಿದೆ?” ಎಂಬ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಮತ್ತು "ಪ್ಲೇಬುಕ್ ನಾಟಕವನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ ಎಂಬ ಉತ್ತರವನ್ನು ನಿರೀಕ್ಷಿಸಲಾಗಿದೆ" ಎಂದು ನಾನು ಸೂಚಿಸಿದಾಗ, "ನಾವು ಅದನ್ನು ಬಳಸುವುದಿಲ್ಲ" ಎಂಬ ಖಂಡನೀಯ ಕಾಮೆಂಟ್ ಅನುಸರಿಸಿತು. ಜನರು ಅನ್ಸಿಬಲ್ ಅನ್ನು ಹಣಕ್ಕಾಗಿ ಬರೆಯುತ್ತಾರೆ ಮತ್ತು ಆಟವನ್ನು ಬಳಸಬೇಡಿ. ಅವರು ಅದನ್ನು ಬಳಸುತ್ತಾರೆ, ಆದರೆ ಅದು ಏನು ಎಂದು ತಿಳಿದಿಲ್ಲ.

ಆದ್ದರಿಂದ ಸರಳವಾದ ಯಾವುದನ್ನಾದರೂ ಪ್ರಾರಂಭಿಸೋಣ: ಅದನ್ನು ಏನು ಕರೆಯಲಾಗುತ್ತದೆ. ಬಹುಶಃ ನೀವು ಇದನ್ನು ತಿಳಿದಿರಬಹುದು, ಅಥವಾ ಬಹುಶಃ ನೀವು ತಿಳಿದಿರುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ನೀವು ದಸ್ತಾವೇಜನ್ನು ಓದಿದಾಗ ನೀವು ಗಮನ ಹರಿಸಲಿಲ್ಲ.

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 ನಲ್ಲಿ ಪ್ರೋಗ್ರಾಮ್ ಮಾಡುವುದು ಏಕೆ ಅಪಾಯಕಾರಿ ಮತ್ತು 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: 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 ಇತ್ಯಾದಿ ನೀವು ಅನ್ಸಿಬಲ್ ಅನ್ನು ಚೆನ್ನಾಗಿ ತಿಳಿದಿದ್ದೀರಿ, "ಟ್ರಿಕಿ" ಪರಿಹಾರಕ್ಕಾಗಿ ನೀವು ಹೆಚ್ಚು ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಹೆಸರಿಸಬಹುದು. ಮತ್ತು ಸರಳ ಪರಿಹಾರ - ಪೂರ್ವ/ಪಾತ್ರಗಳು/ಪೋಸ್ಟ್ ನಡುವೆ ನೈಸರ್ಗಿಕ ವಿಭಜನೆಯನ್ನು ಬಳಸುವುದು - ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳಿಗೆ ಕಾರಣವಾಗುವುದಿಲ್ಲ.

ಮತ್ತು, ನಮ್ಮ 'ಫೂ' ಗೆ ಹಿಂತಿರುಗಿ. ನಾನು ಎಲ್ಲಿ ಹಾಕಬೇಕು? ಪೂರ್ವ, ಪೋಸ್ಟ್ ಅಥವಾ ಪಾತ್ರಗಳಲ್ಲಿ? ನಿಸ್ಸಂಶಯವಾಗಿ, ಇದು ಫೂಗಾಗಿ ಹ್ಯಾಂಡ್ಲರ್ನ ಫಲಿತಾಂಶಗಳ ಅಗತ್ಯವಿದೆಯೇ ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ. ಅವುಗಳು ಇಲ್ಲದಿದ್ದರೆ, ನಂತರ ಫೂ ಅನ್ನು ಪೂರ್ವ ಅಥವಾ ನಂತರದಲ್ಲಿ ಇರಿಸುವ ಅಗತ್ಯವಿಲ್ಲ - ಈ ವಿಭಾಗಗಳು ವಿಶೇಷ ಅರ್ಥವನ್ನು ಹೊಂದಿವೆ - ಕೋಡ್‌ನ ಮುಖ್ಯ ಭಾಗದ ಮೊದಲು ಮತ್ತು ನಂತರ ಕಾರ್ಯಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದು.

ಈಗ “ಪಾತ್ರ ಅಥವಾ ಕಾರ್ಯ” ಎಂಬ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರವು ಈಗಾಗಲೇ ಆಟದಲ್ಲಿರುವುದಕ್ಕೆ ಬರುತ್ತದೆ - ಅಲ್ಲಿ ಕಾರ್ಯಗಳಿದ್ದರೆ, ನೀವು ಅವುಗಳನ್ನು ಕಾರ್ಯಗಳಿಗೆ ಸೇರಿಸಬೇಕಾಗುತ್ತದೆ. ಪಾತ್ರಗಳಿದ್ದರೆ, ನೀವು ಪಾತ್ರವನ್ನು ರಚಿಸಬೇಕಾಗಿದೆ (ಒಂದು ಕಾರ್ಯದಿಂದ ಕೂಡ). ಕಾರ್ಯಗಳು ಮತ್ತು ಪಾತ್ರಗಳನ್ನು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಬಳಸಲಾಗುವುದಿಲ್ಲ ಎಂದು ನಾನು ನಿಮಗೆ ನೆನಪಿಸುತ್ತೇನೆ.

ಅನ್ಸಿಬಲ್‌ನ ಮೂಲಭೂತ ಅಂಶಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಅಭಿರುಚಿಯ ತೋರಿಕೆಯ ಪ್ರಶ್ನೆಗಳಿಗೆ ಸಮಂಜಸವಾದ ಉತ್ತರಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ.

ಕಾರ್ಯಗಳು ಮತ್ತು ಪಾತ್ರಗಳು (ಭಾಗ ಎರಡು)

ಈಗ ನೀವು ಪ್ಲೇಬುಕ್ ಬರೆಯಲು ಪ್ರಾರಂಭಿಸುತ್ತಿರುವಾಗ ಪರಿಸ್ಥಿತಿಯನ್ನು ಚರ್ಚಿಸೋಣ. ನೀವು ಫೂ, ಬಾರ್ ಮತ್ತು ಬಾಜ್ ಮಾಡಬೇಕಾಗಿದೆ. ಈ ಮೂರು ಕಾರ್ಯಗಳು, ಒಂದು ಪಾತ್ರ ಅಥವಾ ಮೂರು ಪಾತ್ರಗಳು? ಪ್ರಶ್ನೆಯನ್ನು ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಹೇಳಲು: ಯಾವ ಹಂತದಲ್ಲಿ ನೀವು ಪಾತ್ರಗಳನ್ನು ಬರೆಯಲು ಪ್ರಾರಂಭಿಸಬೇಕು? ನೀವು ಕಾರ್ಯಗಳನ್ನು ಬರೆಯಬಹುದಾದಾಗ ಪಾತ್ರಗಳನ್ನು ಬರೆಯುವುದರಲ್ಲಿ ಏನು ಪ್ರಯೋಜನ?... ಪಾತ್ರವೇನು?

ಒಂದು ದೊಡ್ಡ ತಪ್ಪು (ನಾನು ಈಗಾಗಲೇ ಇದರ ಬಗ್ಗೆ ಮಾತನಾಡಿದ್ದೇನೆ) ಕಾರ್ಯಕ್ರಮದ ಲೈಬ್ರರಿಯಲ್ಲಿನ ಒಂದು ಕಾರ್ಯದಂತೆ ಒಂದು ಪಾತ್ರವನ್ನು ಯೋಚಿಸುವುದು. ಜೆನೆರಿಕ್ ಫಂಕ್ಷನ್ ವಿವರಣೆ ಹೇಗಿರುತ್ತದೆ? ಇದು ಇನ್‌ಪುಟ್ ಆರ್ಗ್ಯುಮೆಂಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಅಡ್ಡ ಕಾರಣಗಳೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ, ಅಡ್ಡ ಪರಿಣಾಮಗಳನ್ನು ಮಾಡುತ್ತದೆ ಮತ್ತು ಮೌಲ್ಯವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ.

ಈಗ, ಗಮನ. ಪಾತ್ರದಲ್ಲಿ ಇದರಿಂದ ಏನು ಮಾಡಬಹುದು? ಅಡ್ಡ ಪರಿಣಾಮಗಳನ್ನು ಕರೆಯಲು ನಿಮಗೆ ಯಾವಾಗಲೂ ಸ್ವಾಗತವಿದೆ, ಇದು ಸಂಪೂರ್ಣ ಅನ್ಸಿಬಲ್‌ನ ಸಾರವಾಗಿದೆ - ಅಡ್ಡಪರಿಣಾಮಗಳನ್ನು ರಚಿಸಲು. ಅಡ್ಡ ಕಾರಣಗಳಿವೆಯೇ? ಪ್ರಾಥಮಿಕ. ಆದರೆ "ಮೌಲ್ಯವನ್ನು ರವಾನಿಸಿ ಮತ್ತು ಅದನ್ನು ಹಿಂತಿರುಗಿಸಿ" - ಅಲ್ಲಿ ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ಮೊದಲಿಗೆ, ನೀವು ಪಾತ್ರಕ್ಕೆ ಮೌಲ್ಯವನ್ನು ರವಾನಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ನೀವು ಪಾತ್ರಕ್ಕಾಗಿ ವರ್ಸ್ ವಿಭಾಗದಲ್ಲಿ ಜೀವಮಾನದ ಆಟದ ಗಾತ್ರದೊಂದಿಗೆ ಜಾಗತಿಕ ವೇರಿಯಬಲ್ ಅನ್ನು ಹೊಂದಿಸಬಹುದು. ಪಾತ್ರದ ಒಳಗೆ ಜೀವಿತಾವಧಿಯಲ್ಲಿ ನೀವು ಜಾಗತಿಕ ವೇರಿಯಬಲ್ ಅನ್ನು ಹೊಂದಿಸಬಹುದು. ಅಥವಾ ಪ್ಲೇಬುಕ್‌ಗಳ ಜೀವಿತಾವಧಿಯೊಂದಿಗೆ (set_fact/register) ಆದರೆ ನೀವು "ಸ್ಥಳೀಯ ಅಸ್ಥಿರಗಳನ್ನು" ಹೊಂದಲು ಸಾಧ್ಯವಿಲ್ಲ. ನೀವು "ಮೌಲ್ಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು" ಮತ್ತು "ಅದನ್ನು ಹಿಂತಿರುಗಿಸಲು" ಸಾಧ್ಯವಿಲ್ಲ.

ಮುಖ್ಯ ವಿಷಯವು ಇದರಿಂದ ಅನುಸರಿಸುತ್ತದೆ: ಅಡ್ಡ ಪರಿಣಾಮಗಳನ್ನು ಉಂಟುಮಾಡದೆ ನೀವು ಅನ್ಸಿಬಲ್ನಲ್ಲಿ ಏನನ್ನಾದರೂ ಬರೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ. ಜಾಗತಿಕ ಅಸ್ಥಿರಗಳನ್ನು ಬದಲಾಯಿಸುವುದು ಯಾವಾಗಲೂ ಒಂದು ಕಾರ್ಯಕ್ಕೆ ಅಡ್ಡ ಪರಿಣಾಮವಾಗಿದೆ. ರಸ್ಟ್‌ನಲ್ಲಿ, ಉದಾಹರಣೆಗೆ, ಜಾಗತಿಕ ವೇರಿಯಬಲ್ ಅನ್ನು ಬದಲಾಯಿಸುವುದು 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:

ಪಾತ್ರದ ನಿರ್ವಾಹಕರು rolename/handlers/main.yaml ನಲ್ಲಿ ನೆಲೆಗೊಂಡಿದ್ದಾರೆ. ಎಲ್ಲಾ ಪ್ಲೇ ಭಾಗವಹಿಸುವವರ ನಡುವೆ ಹ್ಯಾಂಡ್ಲರ್‌ಗಳು ಗುಜರಿ ಹಾಕುತ್ತಾರೆ: ಪೂರ್ವ/ಪೋಸ್ಟ್_ಟಾಸ್ಕ್‌ಗಳು ರೋಲ್ ಹ್ಯಾಂಡ್ಲರ್‌ಗಳನ್ನು ಎಳೆಯಬಹುದು ಮತ್ತು ಪಾತ್ರವು ಹ್ಯಾಂಡ್ಲರ್‌ಗಳನ್ನು ನಾಟಕದಿಂದ ಎಳೆಯಬಹುದು. ಆದಾಗ್ಯೂ, ಹ್ಯಾಂಡ್ಲರ್‌ಗಳಿಗೆ "ಕ್ರಾಸ್-ರೋಲ್" ಕರೆಗಳು ಕ್ಷುಲ್ಲಕ ಹ್ಯಾಂಡ್ಲರ್ ಅನ್ನು ಪುನರಾವರ್ತಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನ 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 notype nosense ಸಾಫ್ಟ್ ಪ್ಲಾಸ್ಟಿಸಿನ್. ಇದು ಎಲ್ಲೆಡೆ ಇರುತ್ತದೆ, ನೀವು ನಿರೀಕ್ಷಿಸದಿದ್ದರೂ ಸಹ. ಬಗ್ಗೆ ಸ್ವಲ್ಪ !!unsafe ಮತ್ತು ರುಚಿಕರವಾದ ಯಾಮ್ಲ್.

ಮೂಲ: www.habr.com