ನಿಮ್ಮ ನೆಟ್‌ವರ್ಕ್ ಮೂಲಸೌಕರ್ಯವನ್ನು ಹೇಗೆ ನಿಯಂತ್ರಿಸುವುದು. ಅಧ್ಯಾಯ ನಾಲ್ಕು. ಆಟೋಮೇಷನ್. ಟೆಂಪ್ಲೇಟ್‌ಗಳು

ಈ ಲೇಖನವು "ನಿಮ್ಮ ನೆಟ್‌ವರ್ಕ್ ಮೂಲಸೌಕರ್ಯವನ್ನು ಹೇಗೆ ನಿಯಂತ್ರಿಸುವುದು" ಎಂಬ ಸರಣಿಯಲ್ಲಿ ಆರನೆಯದಾಗಿದೆ. ಸರಣಿಯಲ್ಲಿನ ಎಲ್ಲಾ ಲೇಖನಗಳ ವಿಷಯಗಳನ್ನು ಮತ್ತು ಲಿಂಕ್‌ಗಳನ್ನು ಕಾಣಬಹುದು ಇಲ್ಲಿ.

ಹಲವಾರು ವಿಷಯಗಳನ್ನು ಹಿಂದೆ ಬಿಟ್ಟು, ನಾನು ಹೊಸ ಅಧ್ಯಾಯವನ್ನು ಪ್ರಾರಂಭಿಸಲು ನಿರ್ಧರಿಸಿದೆ.

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

ನೆಟ್ವರ್ಕ್ಗಾಗಿ DevOps

ಸ್ಕ್ರಿಪ್ಟ್‌ನೊಂದಿಗೆ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ರಚಿಸುವುದು, IT ಮೂಲಸೌಕರ್ಯದಲ್ಲಿನ ಬದಲಾವಣೆಗಳನ್ನು ನಿಯಂತ್ರಿಸಲು GIT ಅನ್ನು ಬಳಸುವುದು, ರಿಮೋಟ್ “ಅಪ್‌ಲೋಡ್” - ನೀವು DevOps ವಿಧಾನದ ತಾಂತ್ರಿಕ ಅನುಷ್ಠಾನದ ಬಗ್ಗೆ ಯೋಚಿಸಿದಾಗ ಈ ಆಲೋಚನೆಗಳು ಮೊದಲು ಬರುತ್ತವೆ. ಅನುಕೂಲಗಳು ಸ್ಪಷ್ಟವಾಗಿವೆ. ಆದರೆ, ದುರದೃಷ್ಟವಶಾತ್, ಅನಾನುಕೂಲಗಳೂ ಇವೆ.

5 ವರ್ಷಗಳ ಹಿಂದೆ, ನಮ್ಮ ಡೆವಲಪರ್‌ಗಳು ನಮ್ಮ ಬಳಿಗೆ ಬಂದಾಗ, ನೆಟ್‌ವರ್ಕರ್‌ಗಳು, ಈ ಪ್ರಸ್ತಾಪಗಳೊಂದಿಗೆ, ನಾವು ಸಂತೋಷಪಡಲಿಲ್ಲ.

ನಾವು ಸುಮಾರು 10 ವಿಭಿನ್ನ ಮಾರಾಟಗಾರರಿಂದ ಉಪಕರಣಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಮಾಟ್ಲಿ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಆನುವಂಶಿಕವಾಗಿ ಪಡೆದಿದ್ದೇವೆ ಎಂದು ನಾನು ಹೇಳಲೇಬೇಕು. ನಮ್ಮ ನೆಚ್ಚಿನ cli ಮೂಲಕ ಕೆಲವು ವಿಷಯಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಅನುಕೂಲಕರವಾಗಿದೆ, ಆದರೆ ಇತರರಲ್ಲಿ ನಾವು GUI ಅನ್ನು ಬಳಸಲು ಆದ್ಯತೆ ನೀಡಿದ್ದೇವೆ. ಇದರ ಜೊತೆಗೆ, "ಲೈವ್" ಸಲಕರಣೆಗಳ ಮೇಲೆ ಸುದೀರ್ಘ ಕೆಲಸವು ನೈಜ-ಸಮಯದ ನಿಯಂತ್ರಣವನ್ನು ನಮಗೆ ಕಲಿಸಿದೆ. ಉದಾಹರಣೆಗೆ, ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡುವಾಗ, ಕ್ಲೈ ಮೂಲಕ ನೇರವಾಗಿ ಕೆಲಸ ಮಾಡಲು ನನಗೆ ಹೆಚ್ಚು ಆರಾಮದಾಯಕವಾಗಿದೆ. ಈ ರೀತಿಯಾಗಿ ಏನೋ ತಪ್ಪಾಗಿದೆ ಎಂದು ನಾನು ತ್ವರಿತವಾಗಿ ನೋಡಬಹುದು ಮತ್ತು ಬದಲಾವಣೆಗಳನ್ನು ಹಿಂತಿರುಗಿಸಬಹುದು. ಇದೆಲ್ಲವೂ ಅವರ ಆಲೋಚನೆಗಳೊಂದಿಗೆ ಸ್ವಲ್ಪ ವಿರೋಧಾಭಾಸವಾಗಿತ್ತು.

ಇತರ ಪ್ರಶ್ನೆಗಳು ಸಹ ಉದ್ಭವಿಸುತ್ತವೆ, ಉದಾಹರಣೆಗೆ, ಇಂಟರ್ಫೇಸ್ ಆವೃತ್ತಿಯಿಂದ ಸಾಫ್ಟ್‌ವೇರ್ ಆವೃತ್ತಿಗೆ ಸ್ವಲ್ಪ ಬದಲಾಗಬಹುದು. ಇದು ಅಂತಿಮವಾಗಿ ನಿಮ್ಮ ಸ್ಕ್ರಿಪ್ಟ್ ತಪ್ಪಾದ "ಸಂರಚನೆಯನ್ನು" ರಚಿಸಲು ಕಾರಣವಾಗುತ್ತದೆ. "ರನ್ನಿಂಗ್ ಇನ್" ಗಾಗಿ ಉತ್ಪಾದನೆಯನ್ನು ಬಳಸಲು ನಾನು ಬಯಸುವುದಿಲ್ಲ.

ಅಥವಾ, ಕಾನ್ಫಿಗರೇಶನ್ ಆಜ್ಞೆಗಳನ್ನು ಸರಿಯಾಗಿ ಅನ್ವಯಿಸಲಾಗಿದೆ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಹೇಗೆ ಮತ್ತು ದೋಷದ ಸಂದರ್ಭದಲ್ಲಿ ಏನು ಮಾಡಬೇಕು?

ಈ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳು ಪರಿಹರಿಸಲಾಗದವು ಎಂದು ನಾನು ಹೇಳಲು ಬಯಸುವುದಿಲ್ಲ. "A" ಎಂದು ಹೇಳುವುದು ಬಹುಶಃ "B" ಎಂದು ಹೇಳಲು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ ಮತ್ತು ಅಭಿವೃದ್ಧಿಯಲ್ಲಿನ ಬದಲಾವಣೆಯ ನಿಯಂತ್ರಣಕ್ಕಾಗಿ ನೀವು ಅದೇ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಬಳಸಲು ಬಯಸಿದರೆ, ನಂತರ ನೀವು ಉತ್ಪಾದನೆಯ ಜೊತೆಗೆ dev ಮತ್ತು ಸ್ಟೇಜಿಂಗ್ ಪರಿಸರವನ್ನು ಹೊಂದಿರಬೇಕು. ನಂತರ ಈ ವಿಧಾನವು ಸಂಪೂರ್ಣ ಕಾಣುತ್ತದೆ. ಆದರೆ ಎಷ್ಟು ವೆಚ್ಚವಾಗುತ್ತದೆ?

ಆದರೆ ಅನಾನುಕೂಲಗಳನ್ನು ಪ್ರಾಯೋಗಿಕವಾಗಿ ನೆಲಸಮಗೊಳಿಸಿದಾಗ ಒಂದು ಪರಿಸ್ಥಿತಿ ಇದೆ, ಮತ್ತು ಅನುಕೂಲಗಳು ಮಾತ್ರ ಉಳಿದಿವೆ. ನಾನು ವಿನ್ಯಾಸ ಕೆಲಸದ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇನೆ.

ಯೋಜನೆಯು

ಕಳೆದ ಎರಡು ವರ್ಷಗಳಿಂದ ನಾನು ದೊಡ್ಡ ಪೂರೈಕೆದಾರರಿಗೆ ಡೇಟಾ ಕೇಂದ್ರವನ್ನು ನಿರ್ಮಿಸುವ ಯೋಜನೆಯಲ್ಲಿ ಭಾಗವಹಿಸುತ್ತಿದ್ದೇನೆ. ಈ ಯೋಜನೆಯಲ್ಲಿ F5 ಮತ್ತು ಪಾಲೊ ಆಲ್ಟೊಗೆ ನಾನು ಜವಾಬ್ದಾರನಾಗಿರುತ್ತೇನೆ. ಸಿಸ್ಕೋದ ದೃಷ್ಟಿಕೋನದಿಂದ, ಇದು "3ನೇ ವ್ಯಕ್ತಿಯ ಉಪಕರಣ".

ನನಗೆ ವೈಯಕ್ತಿಕವಾಗಿ, ಈ ಯೋಜನೆಯಲ್ಲಿ ಎರಡು ವಿಭಿನ್ನ ಹಂತಗಳಿವೆ.

ಒಂದು ಹಂತ

ಮೊದಲ ವರ್ಷ ನಾನು ಕೊನೆಯಿಲ್ಲದೆ ಕಾರ್ಯನಿರತನಾಗಿದ್ದೆ, ನಾನು ರಾತ್ರಿಗಳು ಮತ್ತು ವಾರಾಂತ್ಯಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದ್ದೇನೆ. ನನಗೆ ತಲೆ ಎತ್ತಲಾಗಲಿಲ್ಲ. ನಿರ್ವಹಣೆ ಮತ್ತು ಗ್ರಾಹಕರ ಒತ್ತಡವು ಬಲವಾದ ಮತ್ತು ನಿರಂತರವಾಗಿತ್ತು. ನಿರಂತರ ದಿನಚರಿಯಲ್ಲಿ, ಪ್ರಕ್ರಿಯೆಯನ್ನು ಉತ್ತಮಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸಲು ನನಗೆ ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಇದು ವಿನ್ಯಾಸ ದಸ್ತಾವೇಜನ್ನು ಸಿದ್ಧಪಡಿಸುವಂತೆ ಉಪಕರಣಗಳ ಸಂರಚನೆ ಮಾತ್ರವಲ್ಲ.

ಮೊದಲ ಪರೀಕ್ಷೆಗಳು ಪ್ರಾರಂಭವಾಗಿವೆ, ಮತ್ತು ಎಷ್ಟು ಸಣ್ಣ ದೋಷಗಳು ಮತ್ತು ತಪ್ಪುಗಳನ್ನು ಮಾಡಲಾಗಿದೆ ಎಂದು ನಾನು ಆಶ್ಚರ್ಯ ಪಡುತ್ತೇನೆ. ಸಹಜವಾಗಿ, ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡಿದೆ, ಆದರೆ ಹೆಸರಿನಲ್ಲಿ ಕಾಣೆಯಾದ ಪತ್ರವಿತ್ತು, ಆಜ್ಞೆಯಲ್ಲಿ ಕಾಣೆಯಾದ ಸಾಲು ಇತ್ತು ... ಪರೀಕ್ಷೆಗಳು ಮುಂದುವರೆದವು ಮತ್ತು ನಾನು ಈಗಾಗಲೇ ದೋಷಗಳು, ಪರೀಕ್ಷೆಗಳು ಮತ್ತು ದಾಖಲಾತಿಗಳೊಂದಿಗೆ ನಿರಂತರ, ದೈನಂದಿನ ಹೋರಾಟದಲ್ಲಿದ್ದೆ .

ಇದು ಒಂದು ವರ್ಷದವರೆಗೆ ನಡೆಯಿತು. ಯೋಜನೆ, ನಾನು ಅರ್ಥಮಾಡಿಕೊಂಡಂತೆ, ಎಲ್ಲರಿಗೂ ಸುಲಭವಲ್ಲ, ಆದರೆ ಕ್ರಮೇಣ ಕ್ಲೈಂಟ್ ಹೆಚ್ಚು ಹೆಚ್ಚು ತೃಪ್ತರಾದರು, ಮತ್ತು ಇದು ದಿನಚರಿಯ ಭಾಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಸಮರ್ಥರಾದ ಹೆಚ್ಚುವರಿ ಎಂಜಿನಿಯರ್‌ಗಳನ್ನು ನೇಮಿಸಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗಿಸಿತು.

ಈಗ ನಾವು ಸ್ವಲ್ಪ ಸುತ್ತಲೂ ನೋಡಬಹುದು.
ಮತ್ತು ಇದು ಎರಡನೇ ಹಂತದ ಆರಂಭವಾಗಿತ್ತು.

ಎರಡನೇ ಹಂತ

ನಾನು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ನಿರ್ಧರಿಸಿದೆ.

ಆ ಸಮಯದಲ್ಲಿ ಡೆವಲಪರ್‌ಗಳೊಂದಿಗಿನ ನನ್ನ ಸಂವಹನದಿಂದ ನಾನು ಅರ್ಥಮಾಡಿಕೊಂಡದ್ದು (ಮತ್ತು ನಾವು ಗೌರವ ಸಲ್ಲಿಸಬೇಕು, ನಾವು ಬಲವಾದ ತಂಡವನ್ನು ಹೊಂದಿದ್ದೇವೆ) ಪಠ್ಯ ಸ್ವರೂಪವು ಮೊದಲ ನೋಟದಲ್ಲಿ DOS ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ನ ಪ್ರಪಂಚದಿಂದ ಏನಾದರೂ ತೋರುತ್ತದೆಯಾದರೂ, ಒಂದು ಸಂಖ್ಯೆಯನ್ನು ಹೊಂದಿದೆ. ಬೆಲೆಬಾಳುವ ಆಸ್ತಿಗಳು.
ಆದ್ದರಿಂದ, ಉದಾಹರಣೆಗೆ, ನೀವು GIT ಮತ್ತು ಅದರ ಎಲ್ಲಾ ಉತ್ಪನ್ನಗಳ ಸಂಪೂರ್ಣ ಪ್ರಯೋಜನವನ್ನು ಪಡೆಯಲು ಬಯಸಿದರೆ ಪಠ್ಯ ಸ್ವರೂಪವು ಉಪಯುಕ್ತವಾಗಿರುತ್ತದೆ. ಮತ್ತು ನಾನು ಬಯಸಿದ್ದೆ.

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

ಆದ್ದರಿಂದ, YAML ಮತ್ತು Jinja2 ಅನ್ನು ಬಳಸುವಾಗ, IP ವಿಳಾಸಗಳು, BGP AS ಸಂಖ್ಯೆಗಳು, ... ಮುಂತಾದ ಸಂರಚನಾ ನಿಯತಾಂಕಗಳನ್ನು ಹೊಂದಿರುವ YAML ಫೈಲ್ NIP ನ ಪಾತ್ರವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪೂರೈಸುತ್ತದೆ, ಆದರೆ Jinja2 ಟೆಂಪ್ಲೇಟ್‌ಗಳು ವಿನ್ಯಾಸಕ್ಕೆ ಅನುಗುಣವಾದ ಸಿಂಟ್ಯಾಕ್ಸ್ ಅನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಅಂದರೆ, ಇದು ಮೂಲಭೂತವಾಗಿ ಒಂದು LLD ಯ ಪ್ರತಿಬಿಂಬ.

YAML ಮತ್ತು Jinja2 ಕಲಿಯಲು ಇದು ಎರಡು ದಿನಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು. ಇದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಕೆಲವು ಉತ್ತಮ ಉದಾಹರಣೆಗಳು ಸಾಕು. ನಂತರ ನಮ್ಮ ವಿನ್ಯಾಸಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುವ ಎಲ್ಲಾ ಟೆಂಪ್ಲೇಟ್‌ಗಳನ್ನು ರಚಿಸಲು ಸುಮಾರು ಎರಡು ವಾರಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು: ಪಾಲೊ ಆಲ್ಟೊಗೆ ಒಂದು ವಾರ ಮತ್ತು F5 ಗೆ ಇನ್ನೊಂದು ವಾರ. ಇದೆಲ್ಲವನ್ನೂ ಕಾರ್ಪೊರೇಟ್ ಗಿಥಾಬ್‌ನಲ್ಲಿ ಪೋಸ್ಟ್ ಮಾಡಲಾಗಿದೆ.

ಈಗ ಬದಲಾವಣೆ ಪ್ರಕ್ರಿಯೆಯು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

• YAML ಫೈಲ್ ಅನ್ನು ಬದಲಾಯಿಸಲಾಗಿದೆ
• ಟೆಂಪ್ಲೇಟ್ (Jinja2) ಬಳಸಿಕೊಂಡು ಸಂರಚನಾ ಕಡತವನ್ನು ರಚಿಸಲಾಗಿದೆ
• ರಿಮೋಟ್ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಉಳಿಸಲಾಗಿದೆ
• ರಚಿಸಿದ ಸಂರಚನೆಯನ್ನು ಉಪಕರಣಕ್ಕೆ ಅಪ್‌ಲೋಡ್ ಮಾಡಲಾಗಿದೆ
• ನಾನು ದೋಷವನ್ನು ನೋಡಿದೆ
• YAML ಫೈಲ್ ಅಥವಾ Jinja2 ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು ಬದಲಾಯಿಸಲಾಗಿದೆ
• ಟೆಂಪ್ಲೇಟ್ (Jinja2) ಬಳಸಿಕೊಂಡು ಸಂರಚನಾ ಕಡತವನ್ನು ರಚಿಸಲಾಗಿದೆ
• ...

ಮೊದಲಿಗೆ ಸಂಪಾದನೆಗಳಿಗಾಗಿ ಸಾಕಷ್ಟು ಸಮಯವನ್ನು ವ್ಯಯಿಸಲಾಯಿತು ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ, ಆದರೆ ಒಂದು ವಾರ ಅಥವಾ ಎರಡು ನಂತರ ಇದು ಅಪರೂಪವಾಯಿತು.

ಎಲ್ಲವನ್ನೂ ಡೀಬಗ್ ಮಾಡಲು ಉತ್ತಮ ಪರೀಕ್ಷೆ ಮತ್ತು ಅವಕಾಶವೆಂದರೆ ಹೆಸರಿಸುವ ಸಂಪ್ರದಾಯವನ್ನು ಬದಲಾಯಿಸುವ ಗ್ರಾಹಕನ ಬಯಕೆ. ಎಫ್ 5 ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿದವರು ಪರಿಸ್ಥಿತಿಯ ತೀವ್ರತೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ. ಆದರೆ ನನಗೆ ಎಲ್ಲವೂ ತುಂಬಾ ಸರಳವಾಗಿತ್ತು. ನಾನು YAML ಫೈಲ್‌ನಲ್ಲಿ ಹೆಸರುಗಳನ್ನು ಬದಲಾಯಿಸಿದೆ, ಉಪಕರಣದಿಂದ ಸಂಪೂರ್ಣ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಅಳಿಸಿದೆ, ಹೊಸದನ್ನು ರಚಿಸಿದೆ ಮತ್ತು ಅದನ್ನು ಅಪ್‌ಲೋಡ್ ಮಾಡಿದೆ. ದೋಷ ಪರಿಹಾರಗಳನ್ನು ಒಳಗೊಂಡಂತೆ ಎಲ್ಲವೂ 4 ದಿನಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು: ಪ್ರತಿ ತಂತ್ರಜ್ಞಾನಕ್ಕೆ ಎರಡು ದಿನಗಳು. ಅದರ ನಂತರ, ನಾನು ಮುಂದಿನ ಹಂತಕ್ಕೆ ಸಿದ್ಧನಾಗಿದ್ದೆ, ಅವುಗಳೆಂದರೆ DEV ಮತ್ತು ಸ್ಟೇಜಿಂಗ್ ಡೇಟಾ ಕೇಂದ್ರಗಳ ರಚನೆ.

ದೇವ್ ಮತ್ತು ಸ್ಟೇಜಿಂಗ್

ಹಂತವು ವಾಸ್ತವವಾಗಿ ಉತ್ಪಾದನೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪುನರಾವರ್ತಿಸುತ್ತದೆ. ದೇವ್ ಎನ್ನುವುದು ಮುಖ್ಯವಾಗಿ ವರ್ಚುವಲ್ ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿ ನಿರ್ಮಿಸಲಾದ ಅತೀವವಾಗಿ ಸ್ಟ್ರಿಪ್ಡ್-ಡೌನ್ ಪ್ರತಿಯಾಗಿದೆ. ಹೊಸ ವಿಧಾನಕ್ಕೆ ಸೂಕ್ತವಾದ ಪರಿಸ್ಥಿತಿ. ಒಟ್ಟಾರೆ ಪ್ರಕ್ರಿಯೆಯಿಂದ ನಾನು ಕಳೆದ ಸಮಯವನ್ನು ನಾನು ಪ್ರತ್ಯೇಕಿಸಿದರೆ, ಕೆಲಸವು 2 ವಾರಗಳಿಗಿಂತ ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುವುದಿಲ್ಲ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಮುಖ್ಯ ಸಮಯವು ಇನ್ನೊಂದು ಬದಿಗೆ ಕಾಯುತ್ತಿದೆ ಮತ್ತು ಒಟ್ಟಿಗೆ ಸಮಸ್ಯೆಗಳನ್ನು ಹುಡುಕುತ್ತಿದೆ. 3 ನೇ ಪಕ್ಷದ ಅನುಷ್ಠಾನವು ಇತರರಿಂದ ಬಹುತೇಕ ಗಮನಿಸಲಿಲ್ಲ. ಹಬ್ರೆಯಲ್ಲಿ ಏನನ್ನಾದರೂ ಕಲಿಯಲು ಮತ್ತು ಒಂದೆರಡು ಲೇಖನಗಳನ್ನು ಬರೆಯಲು ಸಹ ಸಮಯವಿತ್ತು :)

ನಾವು ಸಂಕ್ಷಿಪ್ತಗೊಳಿಸೋಣ

ಆದ್ದರಿಂದ, ಬಾಟಮ್ ಲೈನ್‌ನಲ್ಲಿ ನಾನು ಏನು ಹೊಂದಿದ್ದೇನೆ?

• ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಬದಲಾಯಿಸಲು ನಾನು ಮಾಡಬೇಕಾಗಿರುವುದು ಸರಳ, ಸ್ಪಷ್ಟವಾಗಿ ರಚನೆಯಾದ YAML ಫೈಲ್ ಅನ್ನು ಕಾನ್ಫಿಗರೇಶನ್ ನಿಯತಾಂಕಗಳೊಂದಿಗೆ ಬದಲಾಯಿಸುವುದು. ನಾನು ಪೈಥಾನ್ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಎಂದಿಗೂ ಬದಲಾಯಿಸುವುದಿಲ್ಲ ಮತ್ತು ಬಹಳ ಅಪರೂಪವಾಗಿ (ದೋಷವಿದ್ದರೆ ಮಾತ್ರ) ನಾನು ಜಿಂಜಾ2 ಹೀಟ್‌ಲೇಟ್ ಅನ್ನು ಬದಲಾಯಿಸುತ್ತೇನೆ
• ದಸ್ತಾವೇಜನ್ನು ದೃಷ್ಟಿಕೋನದಿಂದ, ಇದು ಬಹುತೇಕ ಆದರ್ಶ ಪರಿಸ್ಥಿತಿಯಾಗಿದೆ. ನೀವು ದಸ್ತಾವೇಜನ್ನು ಬದಲಾಯಿಸುತ್ತೀರಿ (YAML ಫೈಲ್‌ಗಳು NIP ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ) ಮತ್ತು ಈ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಉಪಕರಣಕ್ಕೆ ಅಪ್‌ಲೋಡ್ ಮಾಡಿ. ಈ ರೀತಿಯಲ್ಲಿ ನಿಮ್ಮ ದಸ್ತಾವೇಜನ್ನು ಯಾವಾಗಲೂ ನವೀಕೃತವಾಗಿರುತ್ತದೆ

ಇದೆಲ್ಲವೂ ಎಂಬ ಅಂಶಕ್ಕೆ ಕಾರಣವಾಯಿತು

• ದೋಷದ ಪ್ರಮಾಣವು ಸುಮಾರು 0 ಕ್ಕೆ ಇಳಿದಿದೆ
• 90 ರಷ್ಟು ದಿನಚರಿ ಕಳೆದುಹೋಗಿದೆ
• ಅನುಷ್ಠಾನದ ವೇಗವು ಗಮನಾರ್ಹವಾಗಿ ಹೆಚ್ಚಾಗಿದೆ

ಪಾವತಿ, F5Y, ACY

ಅದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಕೆಲವು ಉದಾಹರಣೆಗಳು ಸಾಕು ಎಂದು ನಾನು ಹೇಳಿದೆ.
ನನ್ನ ಕೆಲಸದ ಸಮಯದಲ್ಲಿ ರಚಿಸಲಾದ ಸಣ್ಣ (ಮತ್ತು ಸಹಜವಾಗಿ ಮಾರ್ಪಡಿಸಿದ) ಆವೃತ್ತಿ ಇಲ್ಲಿದೆ.

ಪಾವತಿ = ನಿಯೋಜನೆ Pಹಲೋ Aನಿಂದ Yaml = Yaml ನಿಂದ ಪಾಲೋ ಆಲ್ಟೊ
F5Y = ನಿಯೋಜನೆ F5 ರಿಂದ Yaml = F5 ರಿಂದ Yaml (ಶೀಘ್ರದಲ್ಲೇ ಬರಲಿದೆ)
ACY = ನಿಯೋಜನೆ ACನಾನು Yaml = F5 ರಿಂದ Yಆಗಾಗ್ಗೆ

ನಾನು ACY ಬಗ್ಗೆ ಕೆಲವು ಪದಗಳನ್ನು ಸೇರಿಸುತ್ತೇನೆ (ACI ನೊಂದಿಗೆ ಗೊಂದಲಕ್ಕೀಡಾಗಬಾರದು).

ಈ ಪವಾಡವನ್ನು (ಮತ್ತು ಉತ್ತಮ ರೀತಿಯಲ್ಲಿಯೂ) ಖಂಡಿತವಾಗಿ ನೆಟ್‌ವರ್ಕರ್‌ಗಳಿಂದ ರಚಿಸಲಾಗಿಲ್ಲ ಎಂದು ACI ಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿದವರಿಗೆ ತಿಳಿದಿದೆ :). ನೆಟ್ವರ್ಕ್ ಬಗ್ಗೆ ನಿಮಗೆ ತಿಳಿದಿರುವ ಎಲ್ಲವನ್ನೂ ಮರೆತುಬಿಡಿ - ಅದು ನಿಮಗೆ ಉಪಯುಕ್ತವಾಗುವುದಿಲ್ಲ!
ಇದು ಸ್ವಲ್ಪ ಉತ್ಪ್ರೇಕ್ಷಿತವಾಗಿದೆ, ಆದರೆ ಕಳೆದ 3 ವರ್ಷಗಳಿಂದ ನಾನು ನಿರಂತರವಾಗಿ ACI ಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇನೆ ಎಂಬ ಭಾವನೆಯನ್ನು ಇದು ಸ್ಥೂಲವಾಗಿ ತಿಳಿಸುತ್ತದೆ.

ಮತ್ತು ಈ ಸಂದರ್ಭದಲ್ಲಿ, ACY ಬದಲಾವಣೆಯ ನಿಯಂತ್ರಣ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿರ್ಮಿಸುವ ಅವಕಾಶ ಮಾತ್ರವಲ್ಲ (ಇದು ACI ಯ ಸಂದರ್ಭದಲ್ಲಿ ವಿಶೇಷವಾಗಿ ಮುಖ್ಯವಾಗಿದೆ, ಏಕೆಂದರೆ ಇದು ನಿಮ್ಮ ಡೇಟಾ ಕೇಂದ್ರದ ಕೇಂದ್ರ ಮತ್ತು ಅತ್ಯಂತ ನಿರ್ಣಾಯಕ ಭಾಗವಾಗಿದೆ), ಆದರೆ ನಿಮಗೆ ನೀಡುತ್ತದೆ ಕಾನ್ಫಿಗರೇಶನ್ ರಚಿಸಲು ಬಳಕೆದಾರ ಸ್ನೇಹಿ ಇಂಟರ್ಫೇಸ್.

ಈ ಯೋಜನೆಯ ಇಂಜಿನಿಯರ್‌ಗಳು ನಿಖರವಾಗಿ ಅದೇ ಉದ್ದೇಶಗಳಿಗಾಗಿ YAML ಬದಲಿಗೆ ACI ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು Excel ಅನ್ನು ಬಳಸುತ್ತಾರೆ. ಎಕ್ಸೆಲ್ ಅನ್ನು ಬಳಸುವುದರಿಂದ ಸಹಜವಾಗಿ ಅನುಕೂಲಗಳಿವೆ:

• ಒಂದು ಫೈಲ್‌ನಲ್ಲಿ ನಿಮ್ಮ NIP
• ಕ್ಲೈಂಟ್ ನೋಡಲು ಆಹ್ಲಾದಕರವಾದ ಸುಂದರವಾದ ಚಿಹ್ನೆಗಳು
• ನೀವು ಕೆಲವು ಎಕ್ಸೆಲ್ ಉಪಕರಣಗಳನ್ನು ಬಳಸಬಹುದು

ಆದರೆ ಒಂದು ಮೈನಸ್ ಇದೆ, ಮತ್ತು ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ ಇದು ಸಾಧಕವನ್ನು ಮೀರಿಸುತ್ತದೆ. ಬದಲಾವಣೆಗಳನ್ನು ನಿಯಂತ್ರಿಸುವುದು ಮತ್ತು ತಂಡದ ಕೆಲಸವನ್ನು ಸಂಘಟಿಸುವುದು ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗುತ್ತದೆ.

ACY ವಾಸ್ತವವಾಗಿ ನಾನು ACI ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು 3ನೇ ವ್ಯಕ್ತಿಗೆ ಬಳಸಿದ ಅದೇ ವಿಧಾನಗಳ ಅಪ್ಲಿಕೇಶನ್ ಆಗಿದೆ.

ಮೂಲ: www.habr.com