🥇Ansible ಪರೀಕ್ಷೆಯನ್ನು ಪ್ರಾರಂಭಿಸುವುದು ಹೇಗೆ, ಒಂದು ವರ್ಷದಲ್ಲಿ ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು ರಿಫ್ಯಾಕ್ಟರ್ ಮಾಡಿ ಮತ್ತು ಹುಚ್ಚರಾಗಬೇಡಿ

ಇದು ಪ್ರತಿಲಿಪಿಯಾಗಿದೆ ಪ್ರದರ್ಶನಗಳು ಮೇಲೆ DevOps-40 2020-03-18:

ಎರಡನೇ ಬದ್ಧತೆಯಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಯಾವುದೇ ಕೋಡ್ ಪರಂಪರೆಯಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಆರಂಭಿಕ ಆಲೋಚನೆಗಳು ಕಠೋರ ವಾಸ್ತವದಿಂದ ಬೇರೆಯಾಗಲು ಪ್ರಾರಂಭಿಸುತ್ತವೆ. ಇದು ಒಳ್ಳೆಯದು ಅಥವಾ ಕೆಟ್ಟದ್ದಲ್ಲ, ಇದು ವಾದಿಸಲು ಕಷ್ಟ ಮತ್ತು ಅದರೊಂದಿಗೆ ಬದುಕಬೇಕು. ಈ ಪ್ರಕ್ರಿಯೆಯ ಭಾಗವು ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಆಗಿದೆ. ಮೂಲಸೌಕರ್ಯವನ್ನು ಕೋಡ್ ಆಗಿ ಮರುಫಲಕಗೊಳಿಸುವುದು. ಒಂದು ವರ್ಷದಲ್ಲಿ ಅನ್ಸಿಬಲ್ ಅನ್ನು ಹೇಗೆ ಮರುಪಾವತಿ ಮಾಡುವುದು ಮತ್ತು ಹುಚ್ಚರಾಗಬಾರದು ಎಂಬುದಕ್ಕೆ ಕಥೆಯನ್ನು ಪ್ರಾರಂಭಿಸೋಣ.

ದಿ ಬರ್ತ್ ಆಫ್ ಲೆಗಸಿ

ದಿನ #1: ರೋಗಿಯ ಶೂನ್ಯ

ಒಂದಾನೊಂದು ಕಾಲದಲ್ಲಿ ಷರತ್ತುಬದ್ಧ ಯೋಜನೆ ಇತ್ತು. ಇದು ದೇವ್ ಡೆವಲಪ್‌ಮೆಂಟ್ ತಂಡ ಮತ್ತು ಆಪ್ಸ್ ಇಂಜಿನಿಯರ್‌ಗಳನ್ನು ಹೊಂದಿತ್ತು. ಅವರು ಅದೇ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತಿದ್ದರು: ಸರ್ವರ್‌ಗಳನ್ನು ನಿಯೋಜಿಸುವುದು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಹೇಗೆ ಚಲಾಯಿಸುವುದು. ಸಮಸ್ಯೆಯೆಂದರೆ ಪ್ರತಿ ತಂಡವು ಈ ಸಮಸ್ಯೆಯನ್ನು ತನ್ನದೇ ಆದ ರೀತಿಯಲ್ಲಿ ಪರಿಹರಿಸಿದೆ. ಯೋಜನೆಯಲ್ಲಿ, ದೇವ್ ಮತ್ತು ಓಪ್ಸ್ ತಂಡಗಳ ನಡುವೆ ಜ್ಞಾನವನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲು ಅನ್ಸಿಬಲ್ ಅನ್ನು ಬಳಸಲು ನಿರ್ಧರಿಸಲಾಯಿತು.

ದಿನ #89: ದಿ ಬರ್ತ್ ಆಫ್ ಲೆಗಸಿ

ಅದನ್ನು ಸ್ವತಃ ಗಮನಿಸದೆ, ಅವರು ಅದನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಉತ್ತಮವಾಗಿ ಮಾಡಲು ಬಯಸಿದ್ದರು, ಆದರೆ ಅದು ಪರಂಪರೆಯಾಗಿ ಹೊರಹೊಮ್ಮಿತು. ಇದು ಹೇಗೆ ಸಂಭವಿಸುತ್ತದೆ?

ನಮಗೆ ಇಲ್ಲಿ ತುರ್ತು ಕೆಲಸವಿದೆ, ನಾವು ಕೊಳಕು ಹ್ಯಾಕ್ ಮಾಡೋಣ ಮತ್ತು ಅದನ್ನು ಸರಿಪಡಿಸೋಣ.
ನೀವು ದಸ್ತಾವೇಜನ್ನು ಬರೆಯಬೇಕಾಗಿಲ್ಲ ಮತ್ತು ಇಲ್ಲಿ ಏನು ನಡೆಯುತ್ತಿದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ.
ನನಗೆ Ansible/Python/Bash/Terraform ಗೊತ್ತು! ನಾನು ಹೇಗೆ ತಪ್ಪಿಸಿಕೊಳ್ಳಬಲ್ಲೆ ಎಂದು ನೋಡಿ!
ನಾನು ಫುಲ್ ಸ್ಟಾಕ್ ಓವರ್‌ಫ್ಲೋ ಡೆವಲಪರ್ ಆಗಿದ್ದೇನೆ ಮತ್ತು ಇದನ್ನು ಸ್ಟಾಕ್‌ಓವರ್‌ಫ್ಲೋನಿಂದ ನಕಲಿಸಿದ್ದೇನೆ, ಇದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ನನಗೆ ತಿಳಿದಿಲ್ಲ, ಆದರೆ ಇದು ತಂಪಾಗಿ ಕಾಣುತ್ತದೆ ಮತ್ತು ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ.

ಪರಿಣಾಮವಾಗಿ, ನೀವು ಗ್ರಹಿಸಲಾಗದ ರೀತಿಯ ಕೋಡ್ ಅನ್ನು ಪಡೆಯಬಹುದು, ಇದಕ್ಕಾಗಿ ಯಾವುದೇ ದಾಖಲಾತಿಗಳಿಲ್ಲ, ಅದು ಏನು ಮಾಡುತ್ತದೆ, ಅದು ಅಗತ್ಯವಿದೆಯೇ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ, ಆದರೆ ಸಮಸ್ಯೆಯೆಂದರೆ ನೀವು ಅದನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಬೇಕು, ಮಾರ್ಪಡಿಸಬೇಕು, ಊರುಗೋಲು ಮತ್ತು ಬೆಂಬಲವನ್ನು ಸೇರಿಸಬೇಕು , ಪರಿಸ್ಥಿತಿಯನ್ನು ಇನ್ನಷ್ಟು ಹದಗೆಡಿಸುತ್ತದೆ.

- hosts: localhost
  tasks:
    - shell: echo -n Z >> a.txt && cat a.txt
      register: output
      delay: 1
      retries: 5
      until: not output.stdout.find("ZZZ")

ದಿನ #109: ಸಮಸ್ಯೆಯ ಅರಿವು

ಆರಂಭದಲ್ಲಿ ಕಲ್ಪಿಸಲಾದ ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸಿದ IaC ಮಾದರಿಯು ಇನ್ನು ಮುಂದೆ ಬಳಕೆದಾರರು / ವ್ಯಾಪಾರ / ಇತರ ತಂಡಗಳ ಅವಶ್ಯಕತೆಗಳನ್ನು ಪೂರೈಸುವುದಿಲ್ಲ ಮತ್ತು ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡುವ ಸಮಯವು ಸ್ವೀಕಾರಾರ್ಹವಾಗುವುದಿಲ್ಲ. ಈ ಕ್ಷಣದಲ್ಲಿ, ಇದು ಕ್ರಮ ತೆಗೆದುಕೊಳ್ಳುವ ಸಮಯ ಎಂದು ತಿಳುವಳಿಕೆ ಬರುತ್ತದೆ.

IaC ರಿಫ್ಯಾಕ್ಟರಿಂಗ್

ದಿನ #139: ನಿಮಗೆ ನಿಜವಾಗಿಯೂ ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಅಗತ್ಯವಿದೆಯೇ?

ನೀವು ರಿಫ್ಯಾಕ್ಟರ್ ಮಾಡಲು ಹೊರದಬ್ಬುವ ಮೊದಲು, ನೀವು ಹಲವಾರು ಪ್ರಮುಖ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸಬೇಕು:

ನಿಮಗೆ ಇದೆಲ್ಲ ಏಕೆ ಬೇಕು?
ನಿಮಗೆ ಸಮಯವಿದೆಯೇ?
ಜ್ಞಾನ ಸಾಕೇ?

ಪ್ರಶ್ನೆಗಳಿಗೆ ಹೇಗೆ ಉತ್ತರಿಸಬೇಕೆಂದು ನಿಮಗೆ ತಿಳಿದಿಲ್ಲದಿದ್ದರೆ, ಮರುಫಲಕವು ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲು ಕೊನೆಗೊಳ್ಳುತ್ತದೆ, ಅಥವಾ ಅದು ಕೆಟ್ಟದಾಗಬಹುದು. ಏಕೆಂದರೆ ಅನುಭವವಿತ್ತು ( 200 ಲೈನ್‌ಗಳ ಇನ್‌ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್ ಕೋಡ್ ಪರೀಕ್ಷೆಯಿಂದ ನಾನು ಕಲಿತದ್ದು), ನಂತರ ಯೋಜನೆಯು ಪಾತ್ರಗಳನ್ನು ಸರಿಪಡಿಸಲು ಮತ್ತು ಅವುಗಳನ್ನು ಪರೀಕ್ಷೆಗಳೊಂದಿಗೆ ಒಳಗೊಳ್ಳಲು ಸಹಾಯಕ್ಕಾಗಿ ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸಿದೆ.

ದಿನ #149: ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಅನ್ನು ಸಿದ್ಧಪಡಿಸುವುದು

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

ಮೂಲಸೌಕರ್ಯ ಪರೀಕ್ಷೆಯು ಮೂಲಾಧಾರವಾಗುತ್ತದೆ ಮತ್ತು ಇಲ್ಲಿ ಮೂಲಸೌಕರ್ಯ ಪರೀಕ್ಷೆಯ ಪಿರಮಿಡ್ ಅನ್ನು ನಮೂದಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ. ಅಭಿವೃದ್ಧಿಯಲ್ಲಿರುವ ಅದೇ ಕಲ್ಪನೆ, ಆದರೆ ಮೂಲಸೌಕರ್ಯಕ್ಕಾಗಿ: ನಾವು ಇಂಡೆಂಟೇಶನ್‌ನಂತಹ ಸರಳ ವಿಷಯಗಳನ್ನು ಪರಿಶೀಲಿಸುವ ಅಗ್ಗದ ತ್ವರಿತ ಪರೀಕ್ಷೆಗಳಿಂದ ಸಂಪೂರ್ಣ ಮೂಲಸೌಕರ್ಯವನ್ನು ನಿಯೋಜಿಸುವ ದುಬಾರಿ ಪೂರ್ಣ ಪ್ರಮಾಣದ ಪರೀಕ್ಷೆಗಳಿಗೆ ಹೋಗುತ್ತಿದ್ದೇವೆ.

ಆನ್ಸಿಬಲ್ ಪರೀಕ್ಷಾ ಪ್ರಯತ್ನಗಳು

ಪ್ರಾಜೆಕ್ಟ್‌ನಲ್ಲಿ ನಾವು ಅನ್ಸಿಬಲ್ ಪರೀಕ್ಷೆಗಳನ್ನು ಹೇಗೆ ಆವರಿಸಿದ್ದೇವೆ ಎಂಬುದನ್ನು ವಿವರಿಸಲು ಹೋಗುವ ಮೊದಲು, ಮಾಡಿದ ನಿರ್ಧಾರಗಳ ಸಂದರ್ಭವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ನಾನು ಮೊದಲು ಬಳಸಲು ಅವಕಾಶವನ್ನು ಹೊಂದಿದ್ದ ಪ್ರಯತ್ನಗಳು ಮತ್ತು ವಿಧಾನಗಳನ್ನು ನಾನು ವಿವರಿಸುತ್ತೇನೆ.

ದಿನ ಸಂಖ್ಯೆ -997: SDS ನಿಬಂಧನೆ

SDS (ಸಾಫ್ಟ್‌ವೇರ್ ಡಿಫೈನ್ಡ್ ಸ್ಟೋರೇಜ್) ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ಯೋಜನೆಯಲ್ಲಿ ನಾನು ಅನ್ಸಿಬಲ್ ಅನ್ನು ಮೊದಲ ಬಾರಿಗೆ ಪರೀಕ್ಷಿಸಿದೆ. ಈ ವಿಷಯದ ಬಗ್ಗೆ ಪ್ರತ್ಯೇಕ ಲೇಖನವಿದೆ
ನಿಮ್ಮ ವಿತರಣೆಯನ್ನು ಪರೀಕ್ಷಿಸುವಾಗ ಊರುಗೋಲುಗಳ ಮೇಲೆ ಬೈಸಿಕಲ್ಗಳನ್ನು ಮುರಿಯುವುದು ಹೇಗೆ, ಆದರೆ ಸಂಕ್ಷಿಪ್ತವಾಗಿ, ನಾವು ತಲೆಕೆಳಗಾದ ಪರೀಕ್ಷಾ ಪಿರಮಿಡ್‌ನೊಂದಿಗೆ ಕೊನೆಗೊಂಡಿದ್ದೇವೆ ಮತ್ತು ಪರೀಕ್ಷೆಯನ್ನು ನಾವು ಒಂದು ಪಾತ್ರಕ್ಕಾಗಿ 60-90 ನಿಮಿಷಗಳನ್ನು ಕಳೆದಿದ್ದೇವೆ, ಅದು ಬಹಳ ಸಮಯ. ಆಧಾರವು e2e ಪರೀಕ್ಷೆಗಳು, ಅಂದರೆ. ನಾವು ಪೂರ್ಣ ಪ್ರಮಾಣದ ಅನುಸ್ಥಾಪನೆಯನ್ನು ನಿಯೋಜಿಸಿದ್ದೇವೆ ಮತ್ತು ನಂತರ ಅದನ್ನು ಪರೀಕ್ಷಿಸಿದ್ದೇವೆ. ಅವರ ಸ್ವಂತ ಸೈಕಲ್‌ನ ಆವಿಷ್ಕಾರವು ಇನ್ನಷ್ಟು ಉಲ್ಬಣಗೊಂಡಿತು. ಆದರೆ ನಾನು ಒಪ್ಪಿಕೊಳ್ಳಬೇಕು, ಈ ಪರಿಹಾರವು ಕೆಲಸ ಮಾಡಿದೆ ಮತ್ತು ಸ್ಥಿರ ಬಿಡುಗಡೆಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು.

ದಿನ # -701: ಅನ್ಸಿಬಲ್ ಮತ್ತು ಟೆಸ್ಟ್ ಅಡಿಗೆ

ಅನ್ಸಿಬಲ್ ಪರೀಕ್ಷಾ ಕಲ್ಪನೆಯ ಅಭಿವೃದ್ಧಿಯು ಸಿದ್ಧ-ತಯಾರಿಸಿದ ಸಾಧನಗಳ ಬಳಕೆಯಾಗಿದೆ, ಅವುಗಳೆಂದರೆ ಪರೀಕ್ಷಾ ಅಡಿಗೆ / ಅಡಿಗೆ-ci ಮತ್ತು ಇನ್ಸ್ಪೆಕ್. ರೂಬಿಯ ಜ್ಞಾನದಿಂದ ಆಯ್ಕೆಯನ್ನು ನಿರ್ಧರಿಸಲಾಗಿದೆ (ಹೆಚ್ಚಿನ ವಿವರಗಳಿಗಾಗಿ, ಹಬ್ರೆ ಲೇಖನವನ್ನು ನೋಡಿ: YML ಪ್ರೋಗ್ರಾಮರ್‌ಗಳು ಅನ್ಸಿಬಲ್ ಅನ್ನು ಪರೀಕ್ಷಿಸುವ ಕನಸು ಕಾಣುತ್ತಾರೆಯೇ?) 40 ಪಾತ್ರಗಳಿಗೆ ಸುಮಾರು 10 ನಿಮಿಷಗಳಷ್ಟು ವೇಗವಾಗಿ ಕೆಲಸ ಮಾಡಿದೆ. ನಾವು ವರ್ಚುವಲ್ ಯಂತ್ರಗಳ ಪ್ಯಾಕ್ ಅನ್ನು ರಚಿಸಿದ್ದೇವೆ ಮತ್ತು ಒಳಗೆ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಿದ್ದೇವೆ.

ಸಾಮಾನ್ಯವಾಗಿ, ಪರಿಹಾರವು ಕೆಲಸ ಮಾಡಿದೆ, ಆದರೆ ವೈವಿಧ್ಯತೆಯಿಂದಾಗಿ ಕೆಲವು ಕೆಸರು ಇತ್ತು. ಪರೀಕ್ಷಿಸಿದ ಜನರ ಸಂಖ್ಯೆಯನ್ನು 13 ಮೂಲ ಪಾತ್ರಗಳಿಗೆ ಮತ್ತು 2 ಮೆಟಾ ಪಾತ್ರಗಳಿಗೆ ಸಣ್ಣ ಪಾತ್ರಗಳನ್ನು ಸಂಯೋಜಿಸಿದಾಗ, ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಪರೀಕ್ಷೆಗಳು 70 ನಿಮಿಷಗಳ ಕಾಲ ನಡೆಯಲು ಪ್ರಾರಂಭಿಸಿದವು, ಇದು ಸುಮಾರು 2 ಪಟ್ಟು ಹೆಚ್ಚು. XP (ತೀವ್ರ ಪ್ರೋಗ್ರಾಮಿಂಗ್) ಅಭ್ಯಾಸಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುವುದು ಕಷ್ಟಕರವಾಗಿತ್ತು ಏಕೆಂದರೆ... ಯಾರೂ 70 ನಿಮಿಷ ಕಾಯಲು ಬಯಸುವುದಿಲ್ಲ. ಇದು ವಿಧಾನ ಬದಲಿಸಲು ಕಾರಣವಾಗಿತ್ತು

ದಿನ # -601: ಅನ್ಸಿಬಲ್ ಮತ್ತು ಅಣು

ಕಲ್ಪನಾತ್ಮಕವಾಗಿ, ಇದು ಟೆಸ್ಟ್‌ಕಿಚನ್‌ನಂತೆಯೇ ಇರುತ್ತದೆ, ನಾವು ಮಾತ್ರ ಪಾತ್ರ ಪರೀಕ್ಷೆಯನ್ನು ಡಾಕರ್‌ಗೆ ವರ್ಗಾಯಿಸಿದ್ದೇವೆ ಮತ್ತು ಸ್ಟಾಕ್ ಅನ್ನು ಬದಲಾಯಿಸಿದ್ದೇವೆ. ಪರಿಣಾಮವಾಗಿ, ಸಮಯವನ್ನು 20 ಪಾತ್ರಗಳಿಗೆ ಸ್ಥಿರವಾದ 25-7 ನಿಮಿಷಗಳವರೆಗೆ ಕಡಿಮೆಗೊಳಿಸಲಾಯಿತು.

ಪರೀಕ್ಷಿತ ಪಾತ್ರಗಳ ಸಂಖ್ಯೆಯನ್ನು 17 ಕ್ಕೆ ಹೆಚ್ಚಿಸುವ ಮೂಲಕ ಮತ್ತು 45 ಪಾತ್ರಗಳನ್ನು ಲಿಂಟಿಂಗ್ ಮಾಡುವ ಮೂಲಕ, ನಾವು ಇದನ್ನು 28 ಜೆಂಕಿನ್ಸ್ ಸ್ಲೇವ್‌ಗಳಲ್ಲಿ 2 ನಿಮಿಷಗಳಲ್ಲಿ ನಡೆಸಿದ್ದೇವೆ.

ದಿನ #167: ಯೋಜನೆಗೆ ಅನ್ಸಿಬಲ್ ಪರೀಕ್ಷೆಗಳನ್ನು ಸೇರಿಸುವುದು

ಹೆಚ್ಚಾಗಿ, ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಕಾರ್ಯವನ್ನು ತರಾತುರಿಯಲ್ಲಿ ಮಾಡಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಕಾರ್ಯವು ಅಳೆಯಬಹುದಾದಂತಿರಬೇಕು ಆದ್ದರಿಂದ ನೀವು ಅದನ್ನು ಸಣ್ಣ ತುಂಡುಗಳಾಗಿ ಒಡೆಯಬಹುದು ಮತ್ತು ಟೀಚಮಚದೊಂದಿಗೆ ಆನೆಯ ತುಂಡನ್ನು ತುಂಡು ತಿನ್ನಬಹುದು. ನೀವು ಸರಿಯಾದ ದಿಕ್ಕಿನಲ್ಲಿ ಸಾಗುತ್ತಿದ್ದೀರಾ, ಎಷ್ಟು ಸಮಯ ಹೋಗಬೇಕು ಎಂಬ ತಿಳುವಳಿಕೆ ಇರಬೇಕು.

ಸಾಮಾನ್ಯವಾಗಿ, ಇದನ್ನು ಹೇಗೆ ಮಾಡಲಾಗುತ್ತದೆ ಎಂಬುದು ಮುಖ್ಯವಲ್ಲ, ನೀವು ಕಾಗದದ ತುಂಡು ಮೇಲೆ ಬರೆಯಬಹುದು, ನೀವು ಕ್ಲೋಸೆಟ್ ಮೇಲೆ ಸ್ಟಿಕ್ಕರ್ಗಳನ್ನು ಹಾಕಬಹುದು, ನೀವು ಜಿರಾದಲ್ಲಿ ಕಾರ್ಯಗಳನ್ನು ರಚಿಸಬಹುದು ಅಥವಾ ನೀವು Google ಡಾಕ್ಸ್ ಅನ್ನು ತೆರೆಯಬಹುದು ಮತ್ತು ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಯನ್ನು ಬರೆಯಬಹುದು ಅಲ್ಲಿ. ಪ್ರಕ್ರಿಯೆಯು ತಕ್ಷಣವೇ ಅಲ್ಲ ಎಂಬ ಅಂಶದಿಂದ ಕಾಲುಗಳು ಬೆಳೆಯುತ್ತವೆ, ಅದು ದೀರ್ಘ ಮತ್ತು ಬೇಸರದಾಗಿರುತ್ತದೆ. ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಸಮಯದಲ್ಲಿ ನೀವು ಆಲೋಚನೆಗಳಿಂದ ಸುಟ್ಟುಹೋಗಲು, ಸುಸ್ತಾಗಲು ಮತ್ತು ಮುಳುಗಲು ಯಾರಾದರೂ ಬಯಸುತ್ತಾರೆ ಎಂಬುದು ಅಸಂಭವವಾಗಿದೆ.

ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಸರಳವಾಗಿದೆ:

ತಿನ್ನಿರಿ.
ಸ್ಲೀಪ್.
ಕೋಡ್.
IaC ಪರೀಕ್ಷೆ.
ಪುನರಾವರ್ತಿಸಿ

ಮತ್ತು ನಾವು ಉದ್ದೇಶಿತ ಗುರಿಯನ್ನು ತಲುಪುವವರೆಗೆ ನಾವು ಇದನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತೇವೆ.

ಈಗಿನಿಂದಲೇ ಎಲ್ಲವನ್ನೂ ಪರೀಕ್ಷಿಸಲು ಪ್ರಾರಂಭಿಸಲು ಸಾಧ್ಯವಾಗದಿರಬಹುದು, ಆದ್ದರಿಂದ ನಮ್ಮ ಮೊದಲ ಕೆಲಸವೆಂದರೆ ಲಿಂಟಿಂಗ್ ಮತ್ತು ಸಿಂಟ್ಯಾಕ್ಸ್ ಅನ್ನು ಪರಿಶೀಲಿಸುವುದು.

ದಿನ #181: ಗ್ರೀನ್ ಬಿಲ್ಡ್ ಮಾಸ್ಟರ್

ಗ್ರೀನ್ ಬಿಲ್ಡ್ ಮಾಸ್ಟರ್ ಕಡೆಗೆ ಲಿಂಟಿಂಗ್ ಒಂದು ಸಣ್ಣ ಮೊದಲ ಹೆಜ್ಜೆಯಾಗಿದೆ. ಇದು ಬಹುತೇಕ ಯಾವುದನ್ನೂ ಮುರಿಯುವುದಿಲ್ಲ, ಆದರೆ ಇದು ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಡೀಬಗ್ ಮಾಡಲು ಮತ್ತು ಜೆಂಕಿನ್ಸ್‌ನಲ್ಲಿ ಹಸಿರು ನಿರ್ಮಾಣಗಳನ್ನು ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ತಂಡದ ನಡುವೆ ಅಭ್ಯಾಸವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವುದು ಇದರ ಉದ್ದೇಶವಾಗಿದೆ:

ಕೆಂಪು ಪರೀಕ್ಷೆಗಳು ಕೆಟ್ಟದು.
ನಾನು ಏನನ್ನಾದರೂ ಸರಿಪಡಿಸಲು ಬಂದಿದ್ದೇನೆ ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ಕೋಡ್ ಅನ್ನು ನಿಮ್ಮ ಮೊದಲಿಗಿಂತ ಸ್ವಲ್ಪ ಉತ್ತಮಗೊಳಿಸುತ್ತೇನೆ.

ದಿನ #193: ಲಿಂಟಿಂಗ್‌ನಿಂದ ಯುನಿಟ್ ಪರೀಕ್ಷೆಗಳವರೆಗೆ

ಕೋಡ್ ಅನ್ನು ಮಾಸ್ಟರ್‌ಗೆ ಪಡೆಯುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿರ್ಮಿಸಿದ ನಂತರ, ನೀವು ಹಂತ-ಹಂತದ ಸುಧಾರಣೆಯ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸಬಹುದು - ಉಡಾವಣಾ ಪಾತ್ರಗಳೊಂದಿಗೆ ಲಿಂಟಿಂಗ್ ಅನ್ನು ಬದಲಿಸಿ, ನೀವು ಅದನ್ನು ದುರ್ಬಲತೆ ಇಲ್ಲದೆ ಸಹ ಮಾಡಬಹುದು. ಪಾತ್ರಗಳನ್ನು ಹೇಗೆ ಅನ್ವಯಿಸಬೇಕು ಮತ್ತು ಅವು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು.

ದಿನ #211: ಘಟಕದಿಂದ ಏಕೀಕರಣ ಪರೀಕ್ಷೆಗಳಿಗೆ

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

ಜೆಂಕಿನ್ಸ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು, ನಾವು ಅನೇಕ ಹಂತಗಳನ್ನು ರಚಿಸಿದ್ದೇವೆ ಅದು ಸಮಾನಾಂತರವಾಗಿ ಪಾತ್ರಗಳು/ಪ್ಲೇಬುಕ್‌ಗಳನ್ನು ಲಿಂಟೆಡ್, ನಂತರ ಕಂಟೈನರ್‌ಗಳಲ್ಲಿ ಘಟಕ ಪರೀಕ್ಷೆಗಳು ಮತ್ತು ಅಂತಿಮವಾಗಿ ಏಕೀಕರಣ ಪರೀಕ್ಷೆಗಳು.

ಜೆಂಕಿನ್ಸ್ + ಡಾಕರ್ + ಅನ್ಸಿಬಲ್ = ಪರೀಕ್ಷೆಗಳು

ಚೆಕ್ಔಟ್ ರೆಪೋ ಮತ್ತು ನಿರ್ಮಾಣ ಹಂತಗಳನ್ನು ರಚಿಸಿ.
ಲಿಂಟ್ ಪ್ಲೇಬುಕ್ ಹಂತಗಳನ್ನು ಸಮಾನಾಂತರವಾಗಿ ರನ್ ಮಾಡಿ.
ಲಿಂಟ್ ರೋಲ್ ಹಂತಗಳನ್ನು ಸಮಾನಾಂತರವಾಗಿ ರನ್ ಮಾಡಿ.
ಸಿಂಟ್ಯಾಕ್ಸ್ ಚೆಕ್ ರೋಲ್ ಹಂತಗಳನ್ನು ಸಮಾನಾಂತರವಾಗಿ ರನ್ ಮಾಡಿ.
ಪರೀಕ್ಷಾ ಪಾತ್ರದ ಹಂತಗಳನ್ನು ಸಮಾನಾಂತರವಾಗಿ ರನ್ ಮಾಡಿ.
1. ಲಿಂಟ್ ಪಾತ್ರ.
2. ಇತರ ಪಾತ್ರಗಳ ಮೇಲೆ ಅವಲಂಬನೆಯನ್ನು ಪರಿಶೀಲಿಸಿ.
3. ಸಿಂಟ್ಯಾಕ್ಸ್ ಪರಿಶೀಲಿಸಿ.
4. ಡಾಕರ್ ನಿದರ್ಶನವನ್ನು ರಚಿಸಿ
5. Molecule/default/playbook.yml ಅನ್ನು ರನ್ ಮಾಡಿ.
6. ದುರ್ಬಲತೆಯನ್ನು ಪರಿಶೀಲಿಸಿ.
ಏಕೀಕರಣ ಪರೀಕ್ಷೆಗಳನ್ನು ರನ್ ಮಾಡಿ
ಮುಕ್ತಾಯ

ದಿನ #271: ಬಸ್ ಫ್ಯಾಕ್ಟರ್

ಮೊದಲಿಗೆ, ಎರಡು ಅಥವಾ ಮೂರು ಜನರ ಸಣ್ಣ ಗುಂಪಿನಿಂದ ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಅನ್ನು ನಡೆಸಲಾಯಿತು. ಅವರು ಮಾಸ್ಟರ್‌ನಲ್ಲಿ ಕೋಡ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿದರು. ಕಾಲಾನಂತರದಲ್ಲಿ, ತಂಡವು ಕೋಡ್ ಅನ್ನು ಹೇಗೆ ಬರೆಯುವುದು ಎಂಬುದರ ಕುರಿತು ಜ್ಞಾನವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿತು ಮತ್ತು ಕೋಡ್ ವಿಮರ್ಶೆಯು ಮೂಲಸೌಕರ್ಯ ಮತ್ತು ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಜ್ಞಾನದ ಪ್ರಸಾರಕ್ಕೆ ಕೊಡುಗೆ ನೀಡಿತು. ಇಲ್ಲಿ ಮುಖ್ಯಾಂಶವೆಂದರೆ ವಿಮರ್ಶಕರನ್ನು ಒಂದು ವೇಳಾಪಟ್ಟಿಯ ಪ್ರಕಾರ ಒಬ್ಬೊಬ್ಬರಾಗಿ ಆಯ್ಕೆ ಮಾಡಲಾಯಿತು, ಅಂದರೆ. ಕೆಲವು ಹಂತದ ಸಂಭವನೀಯತೆಯೊಂದಿಗೆ ನೀವು ಹೊಸ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಏರುವಿರಿ.

ಮತ್ತು ಇಲ್ಲಿ ಆರಾಮದಾಯಕವಾಗಿರಬೇಕು. ವಿಮರ್ಶೆಯನ್ನು ಮಾಡಲು ಇದು ಅನುಕೂಲಕರವಾಗಿದೆ, ಅದು ಯಾವ ಕಾರ್ಯವನ್ನು ಮಾಡಿದೆ ಮತ್ತು ಚರ್ಚೆಗಳ ಇತಿಹಾಸದ ಚೌಕಟ್ಟಿನೊಳಗೆ ನೋಡಿ. ನಾವು ಜೆಂಕಿನ್ಸ್ + ಬಿಟ್‌ಬಕೆಟ್ + ಜಿರಾವನ್ನು ಸಂಯೋಜಿಸಿದ್ದೇವೆ.

ಆದರೆ, ವಿಮರ್ಶೆಯು ರಾಮಬಾಣವಲ್ಲ; ಹೇಗಾದರೂ, ನಾವು ಮಾಸ್ಟರ್ ಕೋಡ್‌ಗೆ ಪ್ರವೇಶಿಸಿದ್ದೇವೆ, ಅದು ನಮ್ಮನ್ನು ಫ್ಲಾಪ್ ಪರೀಕ್ಷೆಗಳನ್ನು ಮಾಡಿತು:

- get_url:
    url: "{{ actk_certs }}/{{ item.1 }}"
    dest: "{{ actk_src_tmp }}/"
    username: "{{ actk_mvn_user }}"
    password: "{{ actk_mvn_pass }}"
  with_subelements:
    - "{{ actk_cert_list }}"
    - "{{ actk_certs }}"
  delegate_to: localhost

- copy:
    src: "{{ actk_src_tmp }}/{{ item.1 }}"
    dest: "{{ actk_dst_tmp }}"
  with_subelements:
    - "{{ actk_cert_list }}"
    - "{{ actk_certs }}"

ನಂತರ ಅವರು ಅದನ್ನು ಸರಿಪಡಿಸಿದರು, ಆದರೆ ಕೆಸರು ಉಳಿಯಿತು.

get_url:
    url: "{{ actk_certs }}/{{ actk_item }}"
    dest: "{{ actk_src_tmp }}/{{ actk_item }}"
    username: "{{ actk_mvn_user }}"
    password: "{{ actk_mvn_pass }}"
  loop_control:
    loop_var: actk_item
  with_items: "{{ actk_cert_list }}"
  delegate_to: localhost

- copy:
    src: "{{ actk_src_tmp }}/{{ actk_item }}"
    dest: "{{ actk_dst_tmp }}"
  loop_control:
    loop_var: actk_item
  with_items: "{{ actk_cert_list }}"

ದಿನ #311: ಪರೀಕ್ಷೆಗಳನ್ನು ವೇಗಗೊಳಿಸುವುದು

ಕಾಲಾನಂತರದಲ್ಲಿ, ಹೆಚ್ಚಿನ ಪರೀಕ್ಷೆಗಳು ಇದ್ದವು, ನಿರ್ಮಾಣಗಳು ನಿಧಾನವಾಗಿ ಓಡಿದವು, ಕೆಟ್ಟ ಸಂದರ್ಭದಲ್ಲಿ ಒಂದು ಗಂಟೆಯವರೆಗೆ. ರೆಟ್ರೋಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ "ಪರೀಕ್ಷೆಗಳು ಇರುವುದು ಒಳ್ಳೆಯದು, ಆದರೆ ಅವು ನಿಧಾನವಾಗಿವೆ" ಎಂಬ ನುಡಿಗಟ್ಟು ಇತ್ತು. ಪರಿಣಾಮವಾಗಿ, ನಾವು ವರ್ಚುವಲ್ ಗಣಕಗಳಲ್ಲಿ ಏಕೀಕರಣ ಪರೀಕ್ಷೆಗಳನ್ನು ಕೈಬಿಟ್ಟಿದ್ದೇವೆ ಮತ್ತು ಅದನ್ನು ವೇಗವಾಗಿ ಮಾಡಲು ಡಾಕರ್‌ಗೆ ಅಳವಡಿಸಿಕೊಂಡಿದ್ದೇವೆ. ಬಳಸಿದ ಪರಿಕರಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು ನಾವು testinfra ಅನ್ನು ಆನ್ಸಿಬಲ್ ವೆರಿಫೈಯರ್‌ನೊಂದಿಗೆ ಬದಲಾಯಿಸಿದ್ದೇವೆ.

ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಹೇಳುವುದಾದರೆ, ಕ್ರಮಗಳ ಒಂದು ಸೆಟ್ ಇತ್ತು:

ಡಾಕರ್‌ಗೆ ಬದಲಿಸಿ.
ಅವಲಂಬನೆಗಳ ಕಾರಣದಿಂದಾಗಿ ನಕಲು ಮಾಡಲಾದ ಪಾತ್ರ ಪರೀಕ್ಷೆಯನ್ನು ತೆಗೆದುಹಾಕಿ.
ಗುಲಾಮರ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸಿ.
ಟೆಸ್ಟ್ ರನ್ ಆದೇಶ.
ಲಿಂಟ್ ಮಾಡುವ ಸಾಮರ್ಥ್ಯ ಎಲ್ಲಾ ಸ್ಥಳೀಯವಾಗಿ ಒಂದು ಆಜ್ಞೆಯೊಂದಿಗೆ.

ಪರಿಣಾಮವಾಗಿ, ಜೆಂಕಿನ್ಸ್ ಮೇಲಿನ ಪೈಪ್ಲೈನ್ ಕೂಡ ಏಕೀಕೃತಗೊಂಡಿತು

ನಿರ್ಮಾಣ ಹಂತಗಳನ್ನು ರಚಿಸಿ.
ಎಲ್ಲವನ್ನೂ ಸಮಾನಾಂತರವಾಗಿ ಲಿಂಟ್ ಮಾಡಿ.
ಪರೀಕ್ಷಾ ಪಾತ್ರದ ಹಂತಗಳನ್ನು ಸಮಾನಾಂತರವಾಗಿ ರನ್ ಮಾಡಿ.
ಮುಕ್ತಾಯ.

ಲೆಸನ್ಸ್ ಕಲಿತ

ಜಾಗತಿಕ ಅಸ್ಥಿರಗಳನ್ನು ತಪ್ಪಿಸಿ

ಅನ್ಸಿಬಲ್ ಜಾಗತಿಕ ಅಸ್ಥಿರಗಳನ್ನು ಬಳಸುತ್ತದೆ, ರೂಪದಲ್ಲಿ ಭಾಗಶಃ ಪರಿಹಾರವಿದೆ ಖಾಸಗಿ_ಪಾತ್ರ_ವರ್ಸ್, ಆದರೆ ಇದು ರಾಮಬಾಣವಲ್ಲ.

ಒಂದು ಉದಾಹರಣೆ ಕೊಡುತ್ತೇನೆ. ನಾವು ಹೊಂದೋಣ role_a и role_b

# cat role_a/defaults/main.yml
---
msg: a

# cat role_a/tasks/main.yml
---
- debug:
    msg: role_a={{ msg }}

# cat role_b/defaults/main.yml
---
msg: b

# cat role_b/tasks/main.yml
---
- set_fact:
    msg: b
- debug:
    msg: role_b={{ msg }}

- hosts: localhost
  vars:
    msg: hello
  roles:
    - role: role_a
    - role: role_b
  tasks:
    - debug:
        msg: play={{msg}}

ತಮಾಷೆಯ ವಿಷಯವೆಂದರೆ ಪ್ಲೇಬುಕ್‌ಗಳ ಫಲಿತಾಂಶವು ಯಾವಾಗಲೂ ಸ್ಪಷ್ಟವಾಗಿಲ್ಲದ ವಿಷಯಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ, ಉದಾಹರಣೆಗೆ ಪಾತ್ರಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಲಾದ ಕ್ರಮ. ದುರದೃಷ್ಟವಶಾತ್, ಇದು ಅನ್ಸಿಬಲ್‌ನ ಸ್ವಭಾವವಾಗಿದೆ ಮತ್ತು ಮಾಡಬಹುದಾದ ಉತ್ತಮ ಕೆಲಸವೆಂದರೆ ಕೆಲವು ರೀತಿಯ ಒಪ್ಪಂದವನ್ನು ಬಳಸುವುದು, ಉದಾಹರಣೆಗೆ, ಪಾತ್ರದೊಳಗೆ, ಈ ಪಾತ್ರದಲ್ಲಿ ವಿವರಿಸಿದ ವೇರಿಯಬಲ್ ಅನ್ನು ಮಾತ್ರ ಬಳಸಿ.

ಕೆಟ್ಟದ್ದಾಗಿದೆ: ಜಾಗತಿಕ ವೇರಿಯಬಲ್ ಬಳಸಿ.

# cat roles/some_role/tasks/main.yml
---
debug:
  var: java_home

ಉತ್ತಮ: ವಿ defaults ಅಗತ್ಯ ಅಸ್ಥಿರಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿ ಮತ್ತು ನಂತರ ಅವುಗಳನ್ನು ಮಾತ್ರ ಬಳಸಿ.

# cat roles/some_role/defaults/main.yml
---
r__java_home:
 "{{ java_home | default('/path') }}"

# cat roles/some_role/tasks/main.yml
---
debug:
  var: r__java_home

ಪೂರ್ವಪ್ರತ್ಯಯ ಪಾತ್ರ ವೇರಿಯೇಬಲ್‌ಗಳು

ಕೆಟ್ಟದ್ದಾಗಿದೆ: ಜಾಗತಿಕ ವೇರಿಯಬಲ್ ಬಳಸಿ.

# cat roles/some_role/defaults/main.yml
---
db_port: 5432

ಉತ್ತಮ: ಅಸ್ಥಿರ ಪಾತ್ರಗಳಲ್ಲಿ, ಪಾತ್ರದ ಹೆಸರಿನೊಂದಿಗೆ ಪೂರ್ವಪ್ರತ್ಯಯವಿರುವ ವೇರಿಯೇಬಲ್‌ಗಳನ್ನು ಬಳಸಿ; ಇದು, ದಾಸ್ತಾನು ನೋಡುವ ಮೂಲಕ, ಏನಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸುಲಭವಾಗುತ್ತದೆ.

# cat roles/some_role/defaults/main.yml
---
some_role__db_port: 5432

ಲೂಪ್ ಕಂಟ್ರೋಲ್ ವೇರಿಯೇಬಲ್ ಬಳಸಿ

ಕೆಟ್ಟದ್ದಾಗಿದೆ: ಲೂಪ್‌ಗಳಲ್ಲಿ ಪ್ರಮಾಣಿತ ವೇರಿಯಬಲ್ ಅನ್ನು ಬಳಸಿ item, ಈ ಕಾರ್ಯ/ಪ್ಲೇಬುಕ್ ಎಲ್ಲೋ ಸೇರಿಸಿದ್ದರೆ, ಇದು ಅನಿರೀಕ್ಷಿತ ವರ್ತನೆಗೆ ಕಾರಣವಾಗಬಹುದು

---
- hosts: localhost
  tasks:
    - debug:
        msg: "{{ item }}"
      loop:
        - item1
        - item2

ಉತ್ತಮ: ಮೂಲಕ ಲೂಪ್‌ನಲ್ಲಿ ವೇರಿಯೇಬಲ್ ಅನ್ನು ಮರು ವ್ಯಾಖ್ಯಾನಿಸಿ loop_var.

---
- hosts: localhost
  tasks:
    - debug:
        msg: "{{ item_name }}"
      loop:
        - item1
        - item2
      loop_control:
        loop_var: item_name

ಇನ್‌ಪುಟ್ ವೇರಿಯೇಬಲ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ

ವೇರಿಯಬಲ್ ಪೂರ್ವಪ್ರತ್ಯಯಗಳನ್ನು ಬಳಸಲು ನಾವು ಒಪ್ಪಿಕೊಂಡಿದ್ದೇವೆ; ನಾವು ನಿರೀಕ್ಷಿಸಿದಂತೆ ಅವುಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುವುದು ಅತಿಯಾಗಿರುವುದಿಲ್ಲ ಮತ್ತು ಉದಾಹರಣೆಗೆ, ಖಾಲಿ ಮೌಲ್ಯದಿಂದ ಅತಿಕ್ರಮಿಸಲಾಗಿಲ್ಲ

ಉತ್ತಮ: ಅಸ್ಥಿರಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.

- name: "Verify that required string variables are defined"
  assert:
    that: ahs_var is defined and ahs_var | length > 0 and ahs_var != None
    fail_msg: "{{ ahs_var }} needs to be set for the role to work "
    success_msg: "Required variables {{ ahs_var }} is defined"
  loop_control:
    loop_var: ahs_var
  with_items:
    - ahs_item1
    - ahs_item2
    - ahs_item3

ಹ್ಯಾಶ್ ನಿಘಂಟುಗಳನ್ನು ತಪ್ಪಿಸಿ, ಫ್ಲಾಟ್ ರಚನೆಯನ್ನು ಬಳಸಿ

ಪಾತ್ರವು ಅದರ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ ಹ್ಯಾಶ್/ನಿಘಂಟನ್ನು ನಿರೀಕ್ಷಿಸಿದರೆ, ನಾವು ಚೈಲ್ಡ್ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳಲ್ಲಿ ಒಂದನ್ನು ಬದಲಾಯಿಸಲು ಬಯಸಿದರೆ, ನಾವು ಸಂಪೂರ್ಣ ಹ್ಯಾಶ್/ನಿಘಂಟನ್ನು ಅತಿಕ್ರಮಿಸಬೇಕಾಗುತ್ತದೆ, ಅದು ಕಾನ್ಫಿಗರೇಶನ್ ಸಂಕೀರ್ಣತೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ.

ಕೆಟ್ಟದ್ದಾಗಿದೆ: ಹ್ಯಾಶ್/ನಿಘಂಟನ್ನು ಬಳಸಿ.

---
user:
  name: admin
  group: admin

ಉತ್ತಮ: ಫ್ಲಾಟ್ ವೇರಿಯಬಲ್ ರಚನೆಯನ್ನು ಬಳಸಿ.

---
user_name: admin
user_group: "{{ user_name }}"

ಅಸಮರ್ಥ ಪ್ಲೇಬುಕ್‌ಗಳು ಮತ್ತು ಪಾತ್ರಗಳನ್ನು ರಚಿಸಿ

ಪಾತ್ರಗಳು ಮತ್ತು ಪ್ಲೇಬುಕ್‌ಗಳು ವಿವೇಕಯುತವಾಗಿರಬೇಕು, ಏಕೆಂದರೆ ಕಾನ್ಫಿಗರೇಶನ್ ಡ್ರಿಫ್ಟ್ ಮತ್ತು ಏನನ್ನಾದರೂ ಮುರಿಯುವ ಭಯವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಆದರೆ ನೀವು ಅಣುವನ್ನು ಬಳಸಿದರೆ, ಇದು ಡೀಫಾಲ್ಟ್ ನಡವಳಿಕೆಯಾಗಿದೆ.

ಕಮಾಂಡ್ ಶೆಲ್ ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಬಳಸುವುದನ್ನು ತಪ್ಪಿಸಿ

ಶೆಲ್ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಬಳಸುವುದರಿಂದ ಅನ್ಸಿಬಲ್‌ನ ಮುಖ್ಯವಾದ ಡಿಕ್ಲೇರೇಟಿವ್‌ನ ಬದಲಿಗೆ ಕಡ್ಡಾಯವಾದ ವಿವರಣೆಯ ಮಾದರಿ ಉಂಟಾಗುತ್ತದೆ.

ಅಣುವಿನ ಮೂಲಕ ನಿಮ್ಮ ಪಾತ್ರಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ

ಅಣುವು ತುಂಬಾ ಹೊಂದಿಕೊಳ್ಳುವ ವಿಷಯವಾಗಿದೆ, ಕೆಲವು ಸನ್ನಿವೇಶಗಳನ್ನು ನೋಡೋಣ.

ಅಣು ಬಹು ನಿದರ್ಶನಗಳು

В molecule.yml ವಿಭಾಗದಲ್ಲಿ platforms ನೀವು ನಿಯೋಜಿಸಬಹುದಾದ ಅನೇಕ ಹೋಸ್ಟ್‌ಗಳನ್ನು ನೀವು ವಿವರಿಸಬಹುದು.

---
    driver:
      name: docker
    platforms:
      - name: postgresql-instance
        hostname: postgresql-instance
        image: registry.example.com/postgres10:latest
        pre_build_image: true
        override_command: false
        network_mode: host
      - name: app-instance
        hostname: app-instance
        pre_build_image: true
        image: registry.example.com/docker_centos_ansible_tests
        network_mode: host

ಅಂತೆಯೇ, ಈ ಆತಿಥೇಯರು ಆಗಿರಬಹುದು converge.yml ಬಳಕೆ:

---
- name: Converge all
  hosts: all
  vars:
    ansible_user: root
  roles:
    - role: some_role

- name: Converge db
  hosts: db-instance
  roles:
    - role: some_db_role

- name: Converge app
  hosts: app-instance
  roles:
    - role: some_app_role

ಅನ್ಸಿಬಲ್ ಪರಿಶೀಲಕ

ಅಣುವಿನಲ್ಲಿ ನಿದರ್ಶನವನ್ನು ಸರಿಯಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಲು ಅನ್ಸಿಬಲ್ ಅನ್ನು ಬಳಸಲು ಸಾಧ್ಯವಿದೆ, ಮೇಲಾಗಿ, ಬಿಡುಗಡೆ 3 ರಿಂದ ಇದು ಡೀಫಾಲ್ಟ್ ಆಗಿದೆ. ಇದು testinfra/inspec ನಂತೆ ಹೊಂದಿಕೊಳ್ಳುವುದಿಲ್ಲ, ಆದರೆ ಫೈಲ್‌ನ ವಿಷಯಗಳು ನಮ್ಮ ನಿರೀಕ್ಷೆಗಳಿಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತವೆಯೇ ಎಂದು ನಾವು ಪರಿಶೀಲಿಸಬಹುದು:

---
- name: Verify
  hosts: all
  tasks:
    - name: copy config
      copy:
        src: expected_standalone.conf
        dest: /root/wildfly/bin/standalone.conf
        mode: "0644"
        owner: root
        group: root
      register: config_copy_result

    - name: Certify that standalone.conf changed
      assert:
        that: not config_copy_result.changed

ಅಥವಾ ಸೇವೆಯನ್ನು ನಿಯೋಜಿಸಿ, ಅದು ಲಭ್ಯವಾಗುವವರೆಗೆ ಕಾಯಿರಿ ಮತ್ತು ಹೊಗೆ ಪರೀಕ್ಷೆಯನ್ನು ಮಾಡಿ:

---
  - name: Verify
    hosts: solr
    tasks:
      - command: /blah/solr/bin/solr start -s /solr_home -p 8983 -force
      - uri:
          url: http://127.0.0.1:8983/solr
          method: GET
          status_code: 200
        register: uri_result
        until: uri_result is not failed
        retries: 12
        delay: 10
      - name: Post documents to solr
        command: /blah/solr/bin/post -c master /exampledocs/books.csv

ಸಂಕೀರ್ಣ ತರ್ಕವನ್ನು ಮಾಡ್ಯೂಲ್‌ಗಳು ಮತ್ತು ಪ್ಲಗಿನ್‌ಗಳಿಗೆ ಹಾಕಿ

ಅನ್ಸಿಬಲ್ ಘೋಷಣಾ ವಿಧಾನವನ್ನು ಪ್ರತಿಪಾದಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನೀವು ಕೋಡ್ ಶಾಖೆ, ಡೇಟಾ ರೂಪಾಂತರ, ಶೆಲ್ ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಮಾಡಿದಾಗ, ಕೋಡ್ ಅನ್ನು ಓದಲು ಕಷ್ಟವಾಗುತ್ತದೆ. ಇದನ್ನು ಎದುರಿಸಲು ಮತ್ತು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸರಳವಾಗಿರಲು, ನಿಮ್ಮ ಸ್ವಂತ ಮಾಡ್ಯೂಲ್ಗಳನ್ನು ರಚಿಸುವ ಮೂಲಕ ಈ ಸಂಕೀರ್ಣತೆಯನ್ನು ಎದುರಿಸಲು ಇದು ಅತಿಯಾಗಿರುವುದಿಲ್ಲ.

ಸಲಹೆಗಳು ಮತ್ತು ತಂತ್ರಗಳನ್ನು ಸಾರಾಂಶಗೊಳಿಸಿ

ಜಾಗತಿಕ ಅಸ್ಥಿರಗಳನ್ನು ತಪ್ಪಿಸಿ.
ಪೂರ್ವಪ್ರತ್ಯಯ ಪಾತ್ರ ವೇರಿಯೇಬಲ್‌ಗಳು.
ಲೂಪ್ ಕಂಟ್ರೋಲ್ ವೇರಿಯೇಬಲ್ ಬಳಸಿ.
ಇನ್‌ಪುಟ್ ವೇರಿಯೇಬಲ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.
ಹ್ಯಾಶ್ ನಿಘಂಟುಗಳನ್ನು ತಪ್ಪಿಸಿ, ಫ್ಲಾಟ್ ರಚನೆಯನ್ನು ಬಳಸಿ.
ಅಸಮರ್ಥ ಪ್ಲೇಬುಕ್‌ಗಳು ಮತ್ತು ಪಾತ್ರಗಳನ್ನು ರಚಿಸಿ.
ಕಮಾಂಡ್ ಶೆಲ್ ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಬಳಸುವುದನ್ನು ತಪ್ಪಿಸಿ.
ಅಣುವಿನ ಮೂಲಕ ನಿಮ್ಮ ಪಾತ್ರಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ.
ಸಂಕೀರ್ಣ ತರ್ಕವನ್ನು ಮಾಡ್ಯೂಲ್‌ಗಳು ಮತ್ತು ಪ್ಲಗಿನ್‌ಗಳಿಗೆ ಹಾಕಿ.

ತೀರ್ಮಾನಕ್ಕೆ

ನೀವು IaC ಹೊಂದಿದ್ದರೂ ಸಹ, ಪ್ರಾಜೆಕ್ಟ್‌ನಲ್ಲಿ ಮೂಲಸೌಕರ್ಯವನ್ನು ಮರುಪರಿಶೀಲಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಇದು ದೀರ್ಘ ಪ್ರಕ್ರಿಯೆಯಾಗಿದ್ದು, ತಾಳ್ಮೆ, ಸಮಯ ಮತ್ತು ಜ್ಞಾನದ ಅಗತ್ಯವಿರುತ್ತದೆ.

ಲಿಂಕ್ಸ್

UPD1 2020.05.01 20:30 - ಪ್ಲೇಬುಕ್‌ಗಳ ಪ್ರಾಥಮಿಕ ಪ್ರೊಫೈಲಿಂಗ್‌ಗಾಗಿ ನೀವು ಬಳಸಬಹುದು callback_whitelist = profile_tasks ದೀರ್ಘಕಾಲದವರೆಗೆ ನಿಖರವಾಗಿ ಏನು ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು. ನಂತರ ನಾವು ಹಾದು ಹೋಗುತ್ತೇವೆ ಆನ್ಸಿಬಲ್ ವೇಗವರ್ಧಕ ಕ್ಲಾಸಿಕ್ಸ್. ನೀವೂ ಪ್ರಯತ್ನಿಸಬಹುದು ಮೈಟೊಜೆನ್
UPD2 2020.05.03 16:34 - ಇಂಗ್ಲೀಷ್ ಆವೃತ್ತಿ

ಮೂಲ: www.habr.com

ಅನ್ಸಿಬಲ್ ಪರೀಕ್ಷೆಯನ್ನು ಹೇಗೆ ಪ್ರಾರಂಭಿಸುವುದು, ಒಂದು ವರ್ಷದಲ್ಲಿ ಯೋಜನೆಯನ್ನು ಮರುಪರಿಶೀಲಿಸಿ ಮತ್ತು ಹುಚ್ಚರಾಗಬೇಡಿ