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

ಮಾರಾಟದ ಉತ್ತುಂಗಕ್ಕೆ ಹಲವಾರು ತಿಂಗಳುಗಳ ಮೊದಲು ಉಪಕರಣಗಳು ಸೈಟ್‌ಗೆ ಬಂದವು. ಕಾರ್ಯಾಚರಣೆಯ ಸೇವೆ, ಸಹಜವಾಗಿ, ಉತ್ಪಾದನಾ ಪರಿಸರಕ್ಕೆ ತರಲು ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಹೇಗೆ ಮತ್ತು ಏನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕೆಂದು ತಿಳಿದಿದೆ. ಆದರೆ ನಾವು ಇದನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಬೇಕು ಮತ್ತು ಮಾನವ ಅಂಶವನ್ನು ತೊಡೆದುಹಾಕಬೇಕು. ಇದರ ಜೊತೆಗೆ, ಕಂಪನಿಗೆ ನಿರ್ಣಾಯಕವಾದ SAP ಸಿಸ್ಟಮ್‌ಗಳ ಒಂದು ಸೆಟ್‌ನ ವಲಸೆಯ ಮೊದಲು ಸರ್ವರ್‌ಗಳನ್ನು ಬದಲಾಯಿಸಲಾಯಿತು.

ಹೊಸ ಸರ್ವರ್‌ಗಳ ಕಾರ್ಯಾರಂಭವನ್ನು ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಗಡುವಿಗೆ ಕಟ್ಟಲಾಗಿದೆ. ಮತ್ತು ಅದನ್ನು ಚಲಿಸುವಿಕೆಯು ಒಂದು ಶತಕೋಟಿ ಉಡುಗೊರೆಗಳ ಸಾಗಣೆ ಮತ್ತು ವ್ಯವಸ್ಥೆಗಳ ವಲಸೆ ಎರಡನ್ನೂ ಅಪಾಯಕ್ಕೆ ಒಳಪಡಿಸುತ್ತದೆ. ಫಾದರ್ ಫ್ರಾಸ್ಟ್ ಮತ್ತು ಸಾಂಟಾ ಕ್ಲಾಸ್ ಅನ್ನು ಒಳಗೊಂಡಿರುವ ತಂಡವು ಸಹ ದಿನಾಂಕವನ್ನು ಬದಲಾಯಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ - ನೀವು ವರ್ಷಕ್ಕೊಮ್ಮೆ ಮಾತ್ರ ಗೋದಾಮಿನ ನಿರ್ವಹಣೆಗಾಗಿ SAP ವ್ಯವಸ್ಥೆಯನ್ನು ವರ್ಗಾಯಿಸಬಹುದು. ಡಿಸೆಂಬರ್ 31 ರಿಂದ ಜನವರಿ 1 ರವರೆಗೆ, ಚಿಲ್ಲರೆ ವ್ಯಾಪಾರಿಗಳ ಬೃಹತ್ ಗೋದಾಮುಗಳು, ಒಟ್ಟು 20 ಫುಟ್ಬಾಲ್ ಮೈದಾನಗಳ ಗಾತ್ರದಲ್ಲಿ, 15 ಗಂಟೆಗಳ ಕಾಲ ತಮ್ಮ ಕೆಲಸವನ್ನು ನಿಲ್ಲಿಸುತ್ತವೆ. ಮತ್ತು ಸಿಸ್ಟಮ್ ಅನ್ನು ಚಲಿಸುವ ಏಕೈಕ ಅವಧಿ ಇದು. ಸರ್ವರ್‌ಗಳನ್ನು ಪರಿಚಯಿಸುವಾಗ ನಮಗೆ ಯಾವುದೇ ದೋಷವಿಲ್ಲ.

ನಾನು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳುತ್ತೇನೆ: ನನ್ನ ಕಥೆಯು ನಮ್ಮ ತಂಡವು ಬಳಸುವ ಪರಿಕರಗಳು ಮತ್ತು ಕಾನ್ಫಿಗರೇಶನ್ ನಿರ್ವಹಣೆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರತಿಬಿಂಬಿಸುತ್ತದೆ.

ಸಂರಚನಾ ನಿರ್ವಹಣಾ ಸಂಕೀರ್ಣವು ಹಲವಾರು ಹಂತಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ಮುಖ್ಯ ಅಂಶವೆಂದರೆ CMS ವ್ಯವಸ್ಥೆ. ಕೈಗಾರಿಕಾ ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ, ಹಂತಗಳಲ್ಲಿ ಒಂದರ ಅನುಪಸ್ಥಿತಿಯು ಅನಿವಾರ್ಯವಾಗಿ ಅಹಿತಕರ ಪವಾಡಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ.

OS ಅನುಸ್ಥಾಪನ ನಿರ್ವಹಣೆ

ಮೊದಲ ಹಂತವು ಭೌತಿಕ ಮತ್ತು ವರ್ಚುವಲ್ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳ ಸ್ಥಾಪನೆಯನ್ನು ನಿರ್ವಹಿಸುವ ವ್ಯವಸ್ಥೆಯಾಗಿದೆ. ಇದು ಮೂಲ OS ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ರಚಿಸುತ್ತದೆ, ಮಾನವ ಅಂಶವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.

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

BIOS/ಫರ್ಮ್‌ವೇರ್ ಮಟ್ಟದಿಂದ OS ಗೆ ಸರ್ವರ್‌ಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡುವುದು ಅನುಸ್ಥಾಪನ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಗೆ "ಗರಿಷ್ಠ" ಕಾರ್ಯವಾಗಿದೆ. ಇಲ್ಲಿ ಹೆಚ್ಚು ಉಪಕರಣಗಳು ಮತ್ತು ಸೆಟಪ್ ಕಾರ್ಯಗಳನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ವೈವಿಧ್ಯಮಯ ಸಾಧನಗಳಿಗಾಗಿ, ನೀವು ಪರಿಗಣಿಸಬಹುದು ರೆಡ್‌ಫಿಶ್ API. ಎಲ್ಲಾ ಯಂತ್ರಾಂಶಗಳು ಒಬ್ಬ ಮಾರಾಟಗಾರರಿಂದ ಆಗಿದ್ದರೆ, ಸಿದ್ಧ ನಿರ್ವಹಣಾ ಸಾಧನಗಳನ್ನು ಬಳಸಲು ಇದು ಹೆಚ್ಚು ಅನುಕೂಲಕರವಾಗಿರುತ್ತದೆ (ಉದಾಹರಣೆಗೆ, HP ILO ಆಂಪ್ಲಿಫೈಯರ್, DELL OpenManage, ಇತ್ಯಾದಿ).

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

HashiСorp Packer ಬಳಸಿ ಸಿದ್ಧಪಡಿಸಿದ ಟೆಂಪ್ಲೇಟ್‌ಗಳನ್ನು ಆಧರಿಸಿ ನಾವು ವರ್ಚುವಲ್ ಸರ್ವರ್‌ಗಳನ್ನು ರಚಿಸಿದ್ದೇವೆ. ಕಾರಣ ಒಂದೇ ಆಗಿತ್ತು: OS ಅನ್ನು ಸ್ಥಾಪಿಸುವಾಗ ಸಂಭವನೀಯ ಮಾನವ ದೋಷಗಳನ್ನು ತಡೆಗಟ್ಟಲು. ಆದರೆ, ಭೌತಿಕ ಸರ್ವರ್‌ಗಳಿಗಿಂತ ಭಿನ್ನವಾಗಿ, PXE, ನೆಟ್‌ವರ್ಕ್ ಬೂಟಿಂಗ್ ಮತ್ತು VLAN ಬದಲಾವಣೆಗಳ ಅಗತ್ಯವನ್ನು ಪ್ಯಾಕರ್ ತೆಗೆದುಹಾಕುತ್ತದೆ. ಇದು ವರ್ಚುವಲ್ ಸರ್ವರ್‌ಗಳನ್ನು ರಚಿಸಲು ಸುಲಭ ಮತ್ತು ಸರಳಗೊಳಿಸಿದೆ.

ಅಕ್ಕಿ. 1. ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂಗಳ ಅನುಸ್ಥಾಪನೆಯನ್ನು ನಿರ್ವಹಿಸುವುದು.

ರಹಸ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು

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

ಈ ರಹಸ್ಯಗಳನ್ನು ಎಲ್ಲಿ ಮತ್ತು ಹೇಗೆ ಸಂಗ್ರಹಿಸಬೇಕು ಎಂದು ನೀವು ಮೊದಲಿನಿಂದಲೂ ನಿರ್ಧರಿಸದಿದ್ದರೆ, ಮಾಹಿತಿ ಸುರಕ್ಷತೆಯ ಅವಶ್ಯಕತೆಗಳ ತೀವ್ರತೆಯನ್ನು ಅವಲಂಬಿಸಿ, ಈ ಕೆಳಗಿನ ಶೇಖರಣಾ ವಿಧಾನಗಳು ಸಾಧ್ಯತೆಯಿದೆ:

• ನೇರವಾಗಿ ಸಂರಚನಾ ನಿಯಂತ್ರಣ ಕೋಡ್‌ನಲ್ಲಿ ಅಥವಾ ರೆಪೊಸಿಟರಿಯಲ್ಲಿರುವ ಫೈಲ್‌ಗಳಲ್ಲಿ;
• ವಿಶೇಷ ಸಂರಚನಾ ನಿರ್ವಹಣಾ ಸಾಧನಗಳಲ್ಲಿ (ಉದಾಹರಣೆಗೆ, ಅನ್ಸಿಬಲ್ ವಾಲ್ಟ್);
• CI/CD ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ (ಜೆಂಕಿನ್ಸ್/ಟೀಮ್‌ಸಿಟಿ/GitLab/ಇತ್ಯಾದಿ.) ಅಥವಾ ಸಂರಚನಾ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ (Ansible Tower/Ansible AWX);
• ರಹಸ್ಯಗಳನ್ನು "ಹಸ್ತಚಾಲಿತವಾಗಿ" ಸಹ ವರ್ಗಾಯಿಸಬಹುದು. ಉದಾಹರಣೆಗೆ, ಅವುಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಸ್ಥಳದಲ್ಲಿ ಹಾಕಲಾಗುತ್ತದೆ ಮತ್ತು ನಂತರ ಅವುಗಳನ್ನು ಸಂರಚನಾ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಗಳಿಂದ ಬಳಸಲಾಗುತ್ತದೆ;
• ಮೇಲಿನ ವಿವಿಧ ಸಂಯೋಜನೆಗಳು.

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

ನಾವು ಕೇಂದ್ರೀಕೃತ ರಹಸ್ಯ ಸಂಗ್ರಹ HashiCorp ವಾಲ್ಟ್ ಅನ್ನು ಬಳಸಿದ್ದೇವೆ. ಇದು ನಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು:

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

ಈಗ ನಾವು ಕೇಂದ್ರ ದೃಢೀಕರಣ ಮತ್ತು ಅಧಿಕಾರ ವ್ಯವಸ್ಥೆಗೆ ಹೋಗೋಣ. ಇದು ಇಲ್ಲದೆ ಮಾಡಲು ಸಾಧ್ಯವಾಯಿತು, ಆದರೆ ಅನೇಕ ಸಂಬಂಧಿತ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಬಳಕೆದಾರರನ್ನು ನಿರ್ವಹಿಸುವುದು ತುಂಬಾ ಕ್ಷುಲ್ಲಕವಲ್ಲ. ನಾವು LDAP ಸೇವೆಯ ಮೂಲಕ ದೃಢೀಕರಣ ಮತ್ತು ದೃಢೀಕರಣವನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದೇವೆ. ಇಲ್ಲದಿದ್ದರೆ, ವಾಲ್ಟ್ ಬಳಕೆದಾರರಿಗೆ ದೃಢೀಕರಣ ಟೋಕನ್‌ಗಳನ್ನು ನಿರಂತರವಾಗಿ ನೀಡಬೇಕಾಗುತ್ತದೆ ಮತ್ತು ಟ್ರ್ಯಾಕ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಮತ್ತು ಬಳಕೆದಾರರನ್ನು ಅಳಿಸುವುದು ಮತ್ತು ಸೇರಿಸುವುದು "ನಾನು ಈ ಬಳಕೆದಾರ ಖಾತೆಯನ್ನು ಎಲ್ಲೆಡೆ ರಚಿಸಿದ್ದೇನೆ/ಅಳಿಸಿದ್ದೇನೆಯೇ?" ಎಂಬ ಅನ್ವೇಷಣೆಯಾಗಿ ಬದಲಾಗುತ್ತದೆ.

ನಾವು ನಮ್ಮ ಸಿಸ್ಟಂಗೆ ಇನ್ನೊಂದು ಹಂತವನ್ನು ಸೇರಿಸುತ್ತೇವೆ: ರಹಸ್ಯ ನಿರ್ವಹಣೆ ಮತ್ತು ಕೇಂದ್ರ ದೃಢೀಕರಣ/ಅಧಿಕಾರ:

ಅಕ್ಕಿ. 2. ರಹಸ್ಯ ನಿರ್ವಹಣೆ.

ಸಂರಚನಾ ನಿರ್ವಹಣೆ

ನಾವು ಕೋರ್ಗೆ ಬಂದಿದ್ದೇವೆ - CMS ಸಿಸ್ಟಮ್. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಇದು Ansible ಮತ್ತು Red Hat Ansible AWX ನ ಸಂಯೋಜನೆಯಾಗಿದೆ.

ಅನ್ಸಿಬಲ್ ಬದಲಿಗೆ ಚೆಫ್, ಪಪೆಟ್, ಸಾಲ್ಟ್‌ಸ್ಟಾಕ್ ಅನ್ನು ಬಳಸಬಹುದು. ನಾವು ಹಲವಾರು ಮಾನದಂಡಗಳ ಆಧಾರದ ಮೇಲೆ ಅನ್ಸಿಬಲ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ್ದೇವೆ.

• ಮೊದಲನೆಯದಾಗಿ, ಇದು ಬಹುಮುಖತೆಯಾಗಿದೆ. ನಿಯಂತ್ರಣಕ್ಕಾಗಿ ರೆಡಿಮೇಡ್ ಮಾಡ್ಯೂಲ್ಗಳ ಒಂದು ಸೆಟ್ ಛಾಪು ಮೂಡಿಸುತ್ತದೆ. ಮತ್ತು ನೀವು ಅದನ್ನು ಸಾಕಷ್ಟು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ, ನೀವು GitHub ಮತ್ತು Galaxy ನಲ್ಲಿ ಹುಡುಕಬಹುದು.
• ಎರಡನೆಯದಾಗಿ, ನಿರ್ವಹಿಸಿದ ಸಲಕರಣೆಗಳಲ್ಲಿ ಏಜೆಂಟ್ಗಳನ್ನು ಸ್ಥಾಪಿಸಲು ಮತ್ತು ಬೆಂಬಲಿಸಲು ಅಗತ್ಯವಿಲ್ಲ, ಅವರು ಲೋಡ್ನಲ್ಲಿ ಹಸ್ತಕ್ಷೇಪ ಮಾಡುವುದಿಲ್ಲ ಎಂದು ಸಾಬೀತುಪಡಿಸಿ ಮತ್ತು "ಬುಕ್ಮಾರ್ಕ್ಗಳ" ಅನುಪಸ್ಥಿತಿಯನ್ನು ದೃಢೀಕರಿಸಿ.
• ಮೂರನೆಯದಾಗಿ, ಅನ್ಸಿಬಲ್ ಪ್ರವೇಶಕ್ಕೆ ಕಡಿಮೆ ತಡೆಗೋಡೆ ಹೊಂದಿದೆ. ಒಬ್ಬ ಸಮರ್ಥ ಎಂಜಿನಿಯರ್ ಉತ್ಪನ್ನದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಮೊದಲ ದಿನದಂದು ಅಕ್ಷರಶಃ ವರ್ಕಿಂಗ್ ಪ್ಲೇಬುಕ್ ಅನ್ನು ಬರೆಯುತ್ತಾರೆ.

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

ಇಂತಹ ಸಮಸ್ಯೆಗಳ ಸಿಂಹಪಾಲು Red Hat ಮೂಲಕ ಪರಿಹರಿಸಲ್ಪಡುತ್ತದೆ ಅನ್ಸಿಬಲ್ ಟವರ್, ಅಥವಾ ಅವರ ಓಪನ್ ಸೋರ್ಸ್ ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಯೋಜನೆ ಅನ್ಸಿಬಲ್ AWX. ಅದಕ್ಕಾಗಿಯೇ ನಾವು ಅದನ್ನು ಗ್ರಾಹಕರಿಗೆ ಆದ್ಯತೆ ನೀಡಿದ್ದೇವೆ.

ಮತ್ತು ನಮ್ಮ CMS ಸಿಸ್ಟಂನ ಭಾವಚಿತ್ರಕ್ಕೆ ಮತ್ತೊಂದು ಸ್ಪರ್ಶ. ಅನ್ಸಿಬಲ್ ಪ್ಲೇಬುಕ್ ಅನ್ನು ಕೋಡ್ ರೆಪೊಸಿಟರಿ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸಬೇಕು. ನಮ್ಮ ಬಳಿ ಇದೆ GitLab CE.

ಆದ್ದರಿಂದ, ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ಸ್ವತಃ ಅನ್ಸಿಬಲ್/ಅನ್ಸಿಬಲ್ AWX/GitLab ಸಂಯೋಜನೆಯಿಂದ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ (Fig. 3 ನೋಡಿ). ಸಹಜವಾಗಿ, AWX/GitLab ಅನ್ನು ಒಂದೇ ದೃಢೀಕರಣ ವ್ಯವಸ್ಥೆಯೊಂದಿಗೆ ಸಂಯೋಜಿಸಲಾಗಿದೆ ಮತ್ತು ಅನ್ಸಿಬಲ್ ಪ್ಲೇಬುಕ್ ಅನ್ನು HashiCorp ವಾಲ್ಟ್‌ನೊಂದಿಗೆ ಸಂಯೋಜಿಸಲಾಗಿದೆ. ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳು ಉತ್ಪಾದನಾ ಪರಿಸರವನ್ನು ಅನ್ಸಿಬಲ್ AWX ಮೂಲಕ ಮಾತ್ರ ಪ್ರವೇಶಿಸುತ್ತವೆ, ಇದರಲ್ಲಿ ಎಲ್ಲಾ “ಆಟದ ನಿಯಮಗಳನ್ನು” ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿದೆ: ಯಾರು ಏನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು, CMS ಗಾಗಿ ಕಾನ್ಫಿಗರೇಶನ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಕೋಡ್ ಅನ್ನು ಎಲ್ಲಿ ಪಡೆಯಬೇಕು ಇತ್ಯಾದಿ.

ಅಕ್ಕಿ. 3. ಕಾನ್ಫಿಗರೇಶನ್ ನಿರ್ವಹಣೆ.

ಪರೀಕ್ಷಾ ನಿರ್ವಹಣೆ

ನಮ್ಮ ಸಂರಚನೆಯನ್ನು ಕೋಡ್ ರೂಪದಲ್ಲಿ ಪ್ರಸ್ತುತಪಡಿಸಲಾಗಿದೆ. ಆದ್ದರಿಂದ, ನಾವು ಸಾಫ್ಟ್‌ವೇರ್ ಡೆವಲಪರ್‌ಗಳಂತೆಯೇ ಅದೇ ನಿಯಮಗಳ ಮೂಲಕ ಆಡಲು ಒತ್ತಾಯಿಸಲ್ಪಡುತ್ತೇವೆ. ಉತ್ಪಾದನಾ ಸರ್ವರ್‌ಗಳಿಗೆ ನಾವು ಅಭಿವೃದ್ಧಿ, ನಿರಂತರ ಪರೀಕ್ಷೆ, ವಿತರಣೆ ಮತ್ತು ಕಾನ್ಫಿಗರೇಶನ್ ಕೋಡ್‌ನ ಅಪ್ಲಿಕೇಶನ್ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಸಂಘಟಿಸುವ ಅಗತ್ಯವಿದೆ.

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

• ಪ್ರತಿ ಪಾತ್ರವನ್ನು ಘಟಕ ಪರೀಕ್ಷೆಗಳಿಂದ ಮುಚ್ಚಲಾಗುತ್ತದೆ;
• ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಕೋಡ್‌ನಲ್ಲಿ ಯಾವುದೇ ಬದಲಾವಣೆ ಕಂಡುಬಂದಾಗ ಪರೀಕ್ಷೆಗಳು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ರನ್ ಆಗುತ್ತವೆ;
• ಎಲ್ಲಾ ಪರೀಕ್ಷೆಗಳು ಮತ್ತು ಕೋಡ್ ವಿಮರ್ಶೆಯನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಉತ್ತೀರ್ಣರಾದ ನಂತರವೇ ಸಂರಚನಾ ನಿರ್ವಹಣಾ ಕೋಡ್‌ನಲ್ಲಿನ ಬದಲಾವಣೆಗಳನ್ನು ಉತ್ಪಾದನಾ ಪರಿಸರಕ್ಕೆ ಬಿಡುಗಡೆ ಮಾಡಲಾಗುತ್ತದೆ.

ಕೋಡ್ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಸಂರಚನಾ ನಿರ್ವಹಣೆ ಶಾಂತ ಮತ್ತು ಹೆಚ್ಚು ಊಹಿಸಬಹುದಾದ ಮಾರ್ಪಟ್ಟಿದೆ. ನಿರಂತರ ಪರೀಕ್ಷೆಯನ್ನು ಆಯೋಜಿಸಲು, ನಾವು GitLab CI/CD ಟೂಲ್ಕಿಟ್ ಅನ್ನು ಬಳಸಿದ್ದೇವೆ ಮತ್ತು ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ ಅನ್ಸಿಬಲ್ ಅಣು.

ಕಾನ್ಫಿಗರೇಶನ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಕೋಡ್‌ನಲ್ಲಿ ಬದಲಾವಣೆಯಾದಾಗ, GitLab CI/CD ಅಣುವನ್ನು ಕರೆಯುತ್ತದೆ:

• ಇದು ಕೋಡ್ ಸಿಂಟ್ಯಾಕ್ಸ್ ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ,
• ಡಾಕರ್ ಕಂಟೇನರ್ ಅನ್ನು ಎತ್ತುತ್ತದೆ,
• ರಚಿಸಿದ ಕಂಟೇನರ್‌ಗೆ ಮಾರ್ಪಡಿಸಿದ ಕೋಡ್ ಅನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ,
• ಅಸಮರ್ಥತೆಗಾಗಿ ಪಾತ್ರವನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ ಮತ್ತು ಈ ಕೋಡ್‌ಗಾಗಿ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸುತ್ತದೆ (ಇಲ್ಲಿ ಗ್ರ್ಯಾನ್ಯುಲಾರಿಟಿ ಅನ್ಸಿಬಲ್ ರೋಲ್ ಮಟ್ಟದಲ್ಲಿದೆ, ಚಿತ್ರ 4 ನೋಡಿ).

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

ಅಕ್ಕಿ. 4. GitLab CI/CD ನಲ್ಲಿ ಪಾತ್ರಗಳ ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆ.

ಉತ್ಪಾದನಾ ವ್ಯವಸ್ಥೆಗಳ ಕಾರ್ಯಾಚರಣೆಗೆ ಸಂಬಂಧಿಸಿದ ಸಮಸ್ಯೆಯೂ ಇದೆ. ನಿಜ ಜೀವನದಲ್ಲಿ, ಕೇವಲ CMS ಕೋಡ್ ಮೂಲಕ ಕಾನ್ಫಿಗರೇಶನ್ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡುವುದು ತುಂಬಾ ಕಷ್ಟ. ಕೋಡ್ ಎಡಿಟಿಂಗ್, ಪರೀಕ್ಷೆ, ಅನುಮೋದನೆ ಇತ್ಯಾದಿಗಳಿಗಾಗಿ ಕಾಯದೆ ಎಂಜಿನಿಯರ್ "ಇಲ್ಲಿ ಮತ್ತು ಈಗ" ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಬದಲಾಯಿಸಬೇಕಾದಾಗ ತುರ್ತು ಸಂದರ್ಭಗಳು ಉದ್ಭವಿಸುತ್ತವೆ.

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

ಆದ್ದರಿಂದ, ನಿರಂತರ ಪರೀಕ್ಷೆಯ ಜೊತೆಗೆ, ಕಾನ್ಫಿಗರೇಶನ್ ವ್ಯತ್ಯಾಸಗಳಿಗಾಗಿ ನಾವು ಉತ್ಪಾದನಾ ಪರಿಸರವನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇವೆ. ನಾವು ಸರಳವಾದ ಆಯ್ಕೆಯನ್ನು ಆರಿಸಿದ್ದೇವೆ: CMS ಕಾನ್ಫಿಗರೇಶನ್ ಕೋಡ್ ಅನ್ನು "ಡ್ರೈ ರನ್" ಮೋಡ್‌ನಲ್ಲಿ ಚಾಲನೆ ಮಾಡುವುದು, ಅಂದರೆ, ಬದಲಾವಣೆಗಳನ್ನು ಅನ್ವಯಿಸದೆ, ಆದರೆ ಯೋಜಿತ ಮತ್ತು ನಿಜವಾದ ಸಂರಚನೆಯ ನಡುವಿನ ಎಲ್ಲಾ ವ್ಯತ್ಯಾಸಗಳ ಅಧಿಸೂಚನೆಯೊಂದಿಗೆ. ಪ್ರೊಡಕ್ಷನ್ ಸರ್ವರ್‌ಗಳಲ್ಲಿ "-ಚೆಕ್" ಆಯ್ಕೆಯೊಂದಿಗೆ ಎಲ್ಲಾ ಅನ್ಸಿಬಲ್ ಪ್ಲೇಬುಕ್‌ಗಳನ್ನು ನಿಯತಕಾಲಿಕವಾಗಿ ರನ್ ಮಾಡುವ ಮೂಲಕ ನಾವು ಇದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದ್ದೇವೆ. ಯಾವಾಗಲೂ ಹಾಗೆ, ಪ್ಲೇಬುಕ್ ಅನ್ನು ನವೀಕೃತವಾಗಿ ಪ್ರಾರಂಭಿಸಲು ಮತ್ತು ಇರಿಸಿಕೊಳ್ಳಲು Ansible AWX ಕಾರಣವಾಗಿದೆ (Fig. 5 ನೋಡಿ):

ಅಕ್ಕಿ. 5. ಅನ್ಸಿಬಲ್ AWX ನಲ್ಲಿ ಕಾನ್ಫಿಗರೇಶನ್ ವ್ಯತ್ಯಾಸಗಳಿಗಾಗಿ ಪರಿಶೀಲಿಸುತ್ತದೆ.

ತಪಾಸಣೆಯ ನಂತರ, AWX ನಿರ್ವಾಹಕರಿಗೆ ವ್ಯತ್ಯಾಸದ ವರದಿಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ. ಅವರು ಸಮಸ್ಯಾತ್ಮಕ ಸಂರಚನೆಯನ್ನು ಅಧ್ಯಯನ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ನಂತರ ಅದನ್ನು ಸರಿಹೊಂದಿಸಿದ ಪ್ಲೇಬುಕ್‌ಗಳ ಮೂಲಕ ಸರಿಪಡಿಸುತ್ತಾರೆ. ಉತ್ಪಾದನಾ ಪರಿಸರದಲ್ಲಿ ನಾವು ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತೇವೆ ಮತ್ತು CMS ಯಾವಾಗಲೂ ನವೀಕೃತವಾಗಿರುತ್ತದೆ ಮತ್ತು ಸಿಂಕ್ರೊನೈಸ್ ಆಗಿರುತ್ತದೆ. CMS ಕೋಡ್ ಅನ್ನು "ಉತ್ಪಾದನೆ" ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಬಳಸಿದಾಗ ಇದು ಅಹಿತಕರ "ಪವಾಡಗಳನ್ನು" ತೆಗೆದುಹಾಕುತ್ತದೆ.

ನಾವು ಈಗ ಅನ್ಸಿಬಲ್ AWX/GitLab/Molecule (ಚಿತ್ರ 6) ಒಳಗೊಂಡಿರುವ ಪ್ರಮುಖ ಪರೀಕ್ಷಾ ಪದರವನ್ನು ಹೊಂದಿದ್ದೇವೆ.

ಅಕ್ಕಿ. 6. ಪರೀಕ್ಷಾ ನಿರ್ವಹಣೆ.

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

ಇಂದು ಸರ್ವರ್‌ಗಳು ಮತ್ತು ಪರಿಸರದ ಸೆಟ್ಟಿಂಗ್‌ಗಳಲ್ಲಿ "ರಹಸ್ಯ ಜ್ಞಾನ" ಇಲ್ಲ. ಎಲ್ಲಾ ಅಗತ್ಯ ವೈಶಿಷ್ಟ್ಯಗಳು ಪ್ಲೇಬುಕ್ನಲ್ಲಿ ಪ್ರತಿಫಲಿಸುತ್ತದೆ. ಇನ್ನು ಸೃಜನಶೀಲತೆ ಮತ್ತು ಅಸ್ಪಷ್ಟ ಸೂಚನೆಗಳಿಲ್ಲ: "ಇದನ್ನು ಸಾಮಾನ್ಯ Oracle ನಂತೆ ಸ್ಥಾಪಿಸಿ, ಆದರೆ ನೀವು ಒಂದೆರಡು sysctl ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಬೇಕು ಮತ್ತು ಅಗತ್ಯವಿರುವ UID ಯೊಂದಿಗೆ ಬಳಕೆದಾರರನ್ನು ಸೇರಿಸಬೇಕು. ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿರುವ ಹುಡುಗರನ್ನು ಕೇಳಿ, ಅವರಿಗೆ ತಿಳಿದಿದೆ».

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

ಮತ್ತು ಸಹಜವಾಗಿ, ನಾವು ಹಲವಾರು ದಿನಗಳಿಂದ ಗಂಟೆಗಳವರೆಗೆ ಕಾರ್ಯಾಚರಣೆಗೆ ಸರ್ವರ್‌ಗಳ ಉಡಾವಣೆಯನ್ನು ವೇಗಗೊಳಿಸಿದ್ದೇವೆ.

ಸರಿ, ಹೊಸ ವರ್ಷದ ಮುನ್ನಾದಿನದಂದು, ಮಕ್ಕಳು ಸಂತೋಷದಿಂದ ಉಡುಗೊರೆಗಳನ್ನು ಬಿಚ್ಚುತ್ತಿರುವಾಗ ಮತ್ತು ವಯಸ್ಕರು ಚೈಮ್ಸ್ ಹೊಡೆಯುತ್ತಿದ್ದಂತೆ ಶುಭಾಶಯಗಳನ್ನು ಕೋರಿದಾಗ, ನಮ್ಮ ಎಂಜಿನಿಯರ್‌ಗಳು SAP ವ್ಯವಸ್ಥೆಯನ್ನು ಹೊಸ ಸರ್ವರ್‌ಗಳಿಗೆ ಸ್ಥಳಾಂತರಿಸಿದರು. ಸಾಂಟಾ ಕ್ಲಾಸ್ ಕೂಡ ಉತ್ತಮ ಪವಾಡಗಳನ್ನು ಚೆನ್ನಾಗಿ ತಯಾರಿಸಿದವರು ಎಂದು ಹೇಳುತ್ತಾರೆ.

PS ಗ್ರಾಹಕರು ಕಾನ್ಫಿಗರೇಶನ್ ನಿರ್ವಹಣೆ ಸಮಸ್ಯೆಗಳನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಸರಳವಾಗಿ ಪರಿಹರಿಸಲು ಬಯಸುತ್ತಾರೆ ಎಂಬ ಅಂಶವನ್ನು ನಮ್ಮ ತಂಡವು ಹೆಚ್ಚಾಗಿ ಎದುರಿಸುತ್ತದೆ. ತಾತ್ತ್ವಿಕವಾಗಿ, ಮ್ಯಾಜಿಕ್ ಮೂಲಕ - ಒಂದು ಸಾಧನದೊಂದಿಗೆ. ಆದರೆ ಜೀವನದಲ್ಲಿ ಎಲ್ಲವೂ ಹೆಚ್ಚು ಜಟಿಲವಾಗಿದೆ (ಹೌದು, ಬೆಳ್ಳಿ ಗುಂಡುಗಳನ್ನು ಮತ್ತೆ ವಿತರಿಸಲಾಗಿಲ್ಲ): ಗ್ರಾಹಕರ ತಂಡಕ್ಕೆ ಅನುಕೂಲಕರವಾದ ಸಾಧನಗಳನ್ನು ಬಳಸಿಕೊಂಡು ನೀವು ಸಂಪೂರ್ಣ ಪ್ರಕ್ರಿಯೆಯನ್ನು ರಚಿಸಬೇಕು.

ಲೇಖಕ: ಸೆರ್ಗೆ ಆರ್ಟೆಮೊವ್, ವಿಭಾಗದ ವಾಸ್ತುಶಿಲ್ಪಿ DevOps ಪರಿಹಾರಗಳು "ಜೆಟ್ ಇನ್ಫೋಸಿಸ್ಟಮ್ಸ್"

ಮೂಲ: www.habr.com