"ಸ್ಟಾರ್ಟ್ಅಪ್" ನಿಂದ ಒಂದು ಡಜನ್ ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ಸಾವಿರಾರು ಸರ್ವರ್‌ಗಳಿಗೆ. ಲಿನಕ್ಸ್ ಮೂಲಸೌಕರ್ಯದ ಬೆಳವಣಿಗೆಯನ್ನು ನಾವು ಹೇಗೆ ಬೆನ್ನಟ್ಟಿದ್ದೇವೆ

ನಿಮ್ಮ ಐಟಿ ಮೂಲಸೌಕರ್ಯವು ತುಂಬಾ ವೇಗವಾಗಿ ಬೆಳೆದರೆ, ನೀವು ಬೇಗ ಅಥವಾ ನಂತರ ಆಯ್ಕೆಯನ್ನು ಎದುರಿಸಬೇಕಾಗುತ್ತದೆ: ಅದನ್ನು ಬೆಂಬಲಿಸಲು ಮಾನವ ಸಂಪನ್ಮೂಲಗಳನ್ನು ರೇಖೀಯವಾಗಿ ಹೆಚ್ಚಿಸಿ ಅಥವಾ ಯಾಂತ್ರೀಕೃತಗೊಂಡವನ್ನು ಪ್ರಾರಂಭಿಸಿ. ಕೆಲವು ಹಂತದವರೆಗೆ, ನಾವು ಮೊದಲ ಮಾದರಿಯಲ್ಲಿ ವಾಸಿಸುತ್ತಿದ್ದೆವು ಮತ್ತು ನಂತರ ಮೂಲಸೌಕರ್ಯ-ಕೋಡ್‌ಗೆ ದೀರ್ಘ ಮಾರ್ಗವು ಪ್ರಾರಂಭವಾಯಿತು.

ಸಹಜವಾಗಿ, NSPK ಒಂದು ಆರಂಭಿಕ ಅಲ್ಲ, ಆದರೆ ಅಂತಹ ವಾತಾವರಣವು ಅದರ ಅಸ್ತಿತ್ವದ ಮೊದಲ ವರ್ಷಗಳಲ್ಲಿ ಕಂಪನಿಯಲ್ಲಿ ಆಳ್ವಿಕೆ ನಡೆಸಿತು ಮತ್ತು ಅವು ಬಹಳ ಆಸಕ್ತಿದಾಯಕ ವರ್ಷಗಳಾಗಿವೆ. ನನ್ನ ಹೆಸರು ಕೊರ್ನ್ಯಾಕೋವ್ ಡಿಮಿಟ್ರಿ, ನಾನು 10 ವರ್ಷಗಳಿಂದ ಹೆಚ್ಚಿನ ಲಭ್ಯತೆಯ ಅಗತ್ಯತೆಗಳೊಂದಿಗೆ Linux ಮೂಲಸೌಕರ್ಯವನ್ನು ಬೆಂಬಲಿಸುತ್ತಿದ್ದೇನೆ. ಅವರು ಜನವರಿ 2016 ರಲ್ಲಿ NSPK ತಂಡಕ್ಕೆ ಸೇರಿದರು ಮತ್ತು ದುರದೃಷ್ಟವಶಾತ್, ಕಂಪನಿಯ ಅಸ್ತಿತ್ವದ ಪ್ರಾರಂಭವನ್ನು ನೋಡಲಿಲ್ಲ, ಆದರೆ ದೊಡ್ಡ ಬದಲಾವಣೆಗಳ ಹಂತದಲ್ಲಿ ಬಂದರು.

ಸಾಮಾನ್ಯವಾಗಿ, ನಮ್ಮ ತಂಡವು ಕಂಪನಿಗೆ 2 ಉತ್ಪನ್ನಗಳನ್ನು ಪೂರೈಸುತ್ತದೆ ಎಂದು ನಾವು ಹೇಳಬಹುದು. ಮೊದಲನೆಯದು ಮೂಲಸೌಕರ್ಯ. ಮೇಲ್ ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕು, DNS ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕು ಮತ್ತು ಡೊಮೇನ್ ನಿಯಂತ್ರಕಗಳು ಕ್ರ್ಯಾಶ್ ಆಗದ ಸರ್ವರ್‌ಗಳಿಗೆ ನಿಮ್ಮನ್ನು ಅನುಮತಿಸಬೇಕು. ಕಂಪನಿಯ ಐಟಿ ಲ್ಯಾಂಡ್‌ಸ್ಕೇಪ್ ದೊಡ್ಡದಾಗಿದೆ! ಇವು ವ್ಯಾಪಾರ ಮತ್ತು ಮಿಷನ್ ನಿರ್ಣಾಯಕ ವ್ಯವಸ್ಥೆಗಳು, ಕೆಲವು ಲಭ್ಯತೆಯ ಅವಶ್ಯಕತೆಗಳು 99,999. ಎರಡನೆಯ ಉತ್ಪನ್ನವೆಂದರೆ ಸರ್ವರ್‌ಗಳು, ಭೌತಿಕ ಮತ್ತು ವರ್ಚುವಲ್. ಅಸ್ತಿತ್ವದಲ್ಲಿರುವವುಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕಾಗುತ್ತದೆ ಮತ್ತು ಹೊಸದನ್ನು ನಿಯಮಿತವಾಗಿ ಅನೇಕ ಇಲಾಖೆಗಳಿಂದ ಗ್ರಾಹಕರಿಗೆ ತಲುಪಿಸಬೇಕು. ಈ ಲೇಖನದಲ್ಲಿ ನಾನು ಸರ್ವರ್ ಜೀವನ ಚಕ್ರಕ್ಕೆ ಜವಾಬ್ದಾರರಾಗಿರುವ ಮೂಲಸೌಕರ್ಯವನ್ನು ಹೇಗೆ ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದೇವೆ ಎಂಬುದರ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಲು ಬಯಸುತ್ತೇನೆ.

ಪ್ರಯಾಣದ ಪ್ರಾರಂಭ

ನಮ್ಮ ಪ್ರಯಾಣದ ಆರಂಭದಲ್ಲಿ, ನಮ್ಮ ತಂತ್ರಜ್ಞಾನದ ಸ್ಟಾಕ್ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:
OS CentOS 7
FreeIPA ಡೊಮೇನ್ ನಿಯಂತ್ರಕಗಳು
ಆಟೊಮೇಷನ್ - ಅನ್ಸಿಬಲ್(+ಟವರ್), ಚಮ್ಮಾರ

ಇದೆಲ್ಲವೂ 3 ಡೊಮೇನ್‌ಗಳಲ್ಲಿ ನೆಲೆಗೊಂಡಿದೆ, ಹಲವಾರು ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ಹರಡಿದೆ. ಒಂದು ಡೇಟಾ ಸೆಂಟರ್‌ನಲ್ಲಿ ಕಚೇರಿ ವ್ಯವಸ್ಥೆಗಳು ಮತ್ತು ಪರೀಕ್ಷಾ ಸೈಟ್‌ಗಳಿವೆ, ಉಳಿದವುಗಳಲ್ಲಿ PROD ಇದೆ.

ಒಂದು ಹಂತದಲ್ಲಿ ಸರ್ವರ್‌ಗಳನ್ನು ರಚಿಸುವುದು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

VM ಟೆಂಪ್ಲೇಟ್‌ನಲ್ಲಿ, CentOS ಕನಿಷ್ಠವಾಗಿರುತ್ತದೆ ಮತ್ತು ಅಗತ್ಯವಿರುವ ಕನಿಷ್ಠವು ಸರಿಯಾದ /etc/resolv.conf ನಂತೆ ಇರುತ್ತದೆ, ಉಳಿದವು ಅನ್ಸಿಬಲ್ ಮೂಲಕ ಬರುತ್ತದೆ.

CMDB - ಎಕ್ಸೆಲ್.

ಸರ್ವರ್ ಭೌತಿಕವಾಗಿದ್ದರೆ, ವರ್ಚುವಲ್ ಯಂತ್ರವನ್ನು ನಕಲಿಸುವ ಬದಲು, ಕಾಬ್ಲರ್ ಬಳಸಿ ಓಎಸ್ ಅನ್ನು ಸ್ಥಾಪಿಸಲಾಗಿದೆ - ಟಾರ್ಗೆಟ್ ಸರ್ವರ್‌ನ MAC ವಿಳಾಸಗಳನ್ನು ಕಾಬ್ಲರ್ ಸಂರಚನೆಗೆ ಸೇರಿಸಲಾಗುತ್ತದೆ, ಸರ್ವರ್ DHCP ಮೂಲಕ IP ವಿಳಾಸವನ್ನು ಪಡೆಯುತ್ತದೆ, ಮತ್ತು ನಂತರ OS ಸೇರಿಸಲಾಗುತ್ತದೆ.

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

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

ಉದಾಹರಣೆಗೆ, ನಾವು ಎಲ್ಲಾ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಕೆಲವು ಸಂರಚನೆಗಳನ್ನು ಬದಲಾಯಿಸಲು ಬಯಸುತ್ತೇವೆ:

1. ನಾವು ಲಾಜಿಕಲ್ ಸೆಗ್ಮೆಂಟ್/ಡೇಟಾ ಸೆಂಟರ್‌ನಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಬದಲಾಯಿಸುತ್ತೇವೆ. ಕೆಲವೊಮ್ಮೆ ಒಂದು ದಿನದಲ್ಲಿ ಅಲ್ಲ - ಪ್ರವೇಶಿಸುವಿಕೆ ಅಗತ್ಯತೆಗಳು ಮತ್ತು ದೊಡ್ಡ ಸಂಖ್ಯೆಗಳ ಕಾನೂನು ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳನ್ನು ಒಂದೇ ಬಾರಿಗೆ ಅನ್ವಯಿಸಲು ಅನುಮತಿಸುವುದಿಲ್ಲ. ಮತ್ತು ಕೆಲವು ಬದಲಾವಣೆಗಳು ಸಂಭಾವ್ಯವಾಗಿ ವಿನಾಶಕಾರಿ ಮತ್ತು ಏನನ್ನಾದರೂ ಮರುಪ್ರಾರಂಭಿಸುವ ಅಗತ್ಯವಿರುತ್ತದೆ - ಸೇವೆಗಳಿಂದ OS ಗೆ.
2. ಅನ್ಸಿಬಲ್ನಲ್ಲಿ ಅದನ್ನು ಸರಿಪಡಿಸುವುದು
3. ನಾವು ಅದನ್ನು ಕಾಬ್ಲರ್ನಲ್ಲಿ ಸರಿಪಡಿಸುತ್ತೇವೆ
4. ಪ್ರತಿ ತಾರ್ಕಿಕ ವಿಭಾಗ/ಡೇಟಾ ಕೇಂದ್ರಕ್ಕೆ N ಬಾರಿ ಪುನರಾವರ್ತಿಸಿ

ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳು ಸುಗಮವಾಗಿ ನಡೆಯಲು, ಅನೇಕ ಅಂಶಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುವುದು ಅಗತ್ಯವಾಗಿತ್ತು ಮತ್ತು ಬದಲಾವಣೆಗಳು ನಿರಂತರವಾಗಿ ಸಂಭವಿಸುತ್ತವೆ.

• ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಅನ್ಸಿಬಲ್ ಕೋಡ್, ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳು
• ಆಂತರಿಕ ಉತ್ತಮ ಅಭ್ಯಾಸಗಳನ್ನು ಬದಲಾಯಿಸುವುದು
• ಘಟನೆಗಳು/ಅಪಘಾತಗಳ ವಿಶ್ಲೇಷಣೆಯ ಫಲಿತಾಂಶಗಳ ಆಧಾರದ ಮೇಲೆ ಬದಲಾವಣೆಗಳು
• ಆಂತರಿಕ ಮತ್ತು ಬಾಹ್ಯ ಎರಡೂ ಭದ್ರತಾ ಮಾನದಂಡಗಳನ್ನು ಬದಲಾಯಿಸುವುದು. ಉದಾಹರಣೆಗೆ, PCI DSS ಅನ್ನು ಪ್ರತಿ ವರ್ಷ ಹೊಸ ಅವಶ್ಯಕತೆಗಳೊಂದಿಗೆ ನವೀಕರಿಸಲಾಗುತ್ತದೆ

ಮೂಲಸೌಕರ್ಯಗಳ ಬೆಳವಣಿಗೆ ಮತ್ತು ಪ್ರಯಾಣದ ಆರಂಭ

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

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

ಒಂದೆರಡು ಉಪಕರಣಗಳನ್ನು ಸೇರಿಸಲು ಇದು ಉಳಿದಿದೆ.

ನಾವು GitLab CE ಅನ್ನು ನಮ್ಮ ಕೋಡ್ ರೆಪೊಸಿಟರಿಯಾಗಿ ಆಯ್ಕೆ ಮಾಡಿದ್ದೇವೆ, ಅದರ ಅಂತರ್ನಿರ್ಮಿತ CI/CD ಮಾಡ್ಯೂಲ್‌ಗಳಿಗೆ ಕಡಿಮೆ ಅಲ್ಲ.

ರಹಸ್ಯಗಳ ವಾಲ್ಟ್ - ಹ್ಯಾಶಿಕಾರ್ಪ್ ವಾಲ್ಟ್, incl. ಉತ್ತಮ API ಗಾಗಿ.

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

ನಮ್ಮ ಆಯ್ಕೆ:

ಅಣು + ಟೆಸ್ಟಿನ್ಫ್ರಾ
ಅನ್ಸಿಬಲ್ + ಟವರ್ + AWX
ವರ್ಲ್ಡ್ ಆಫ್ ಸರ್ವರ್ + DITNET (ಸ್ವಂತ ಅಭಿವೃದ್ಧಿ)
ಚಮ್ಮಾರ
Gitlab + GitLab ರನ್ನರ್
ಹ್ಯಾಶಿಕಾರ್ಪ್ ವಾಲ್ಟ್

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

• "ಗೋಲ್ಡನ್ ಇಮೇಜ್" ನಿಂದ ಸರ್ವರ್ಗಳನ್ನು ನಕಲಿಸುವುದು ಕೆಟ್ಟದು!ಮುಖ್ಯ ಅನನುಕೂಲವೆಂದರೆ ಚಿತ್ರಗಳು ಈಗ ಯಾವ ಸ್ಥಿತಿಯಲ್ಲಿವೆ ಎಂಬುದು ನಿಮಗೆ ತಿಳಿದಿಲ್ಲ ಮತ್ತು ಎಲ್ಲಾ ವರ್ಚುವಲೈಸೇಶನ್ ಫಾರ್ಮ್‌ಗಳಲ್ಲಿನ ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳು ಎಲ್ಲಾ ಚಿತ್ರಗಳಿಗೆ ಬರುತ್ತವೆ.
• ಡೀಫಾಲ್ಟ್ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳನ್ನು ಕನಿಷ್ಠವಾಗಿ ಬಳಸಿ ಮತ್ತು ಮುಖ್ಯ ಸಿಸ್ಟಮ್ ಫೈಲ್‌ಗಳಿಗೆ ನೀವು ಜವಾಬ್ದಾರರಾಗಿರುವ ಇತರ ಇಲಾಖೆಗಳೊಂದಿಗೆ ಒಪ್ಪಿಕೊಳ್ಳಿ, ಉದಾಹರಣೆಗೆ:
  1. /etc/sysctl.conf ಖಾಲಿ ಬಿಡಿ, ಸೆಟ್ಟಿಂಗ್‌ಗಳು /etc/sysctl.d/ ನಲ್ಲಿ ಮಾತ್ರ ಇರಬೇಕು. ಒಂದು ಫೈಲ್‌ನಲ್ಲಿ ನಿಮ್ಮ ಡೀಫಾಲ್ಟ್, ಇನ್ನೊಂದು ಫೈಲ್‌ನಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಕಸ್ಟಮ್.
  2. systemd ಯೂನಿಟ್‌ಗಳನ್ನು ಎಡಿಟ್ ಮಾಡಲು ಓವರ್‌ರೈಡ್ ಫೈಲ್‌ಗಳನ್ನು ಬಳಸಿ.
• ಎಲ್ಲಾ ಸಂರಚನೆಗಳನ್ನು ಟೆಂಪ್ಲೇಟ್ ಮಾಡಿ ಮತ್ತು ಅವುಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಸೇರಿಸಿ; ಸಾಧ್ಯವಾದರೆ, ಪ್ಲೇಬುಕ್‌ಗಳಲ್ಲಿ ಯಾವುದೇ ಸೆಡ್ ಅಥವಾ ಅದರ ಸಾದೃಶ್ಯಗಳಿಲ್ಲ
• ಕಾನ್ಫಿಗರೇಶನ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಸಿಸ್ಟಮ್ ಕೋಡ್ ಅನ್ನು ಮರುಫ್ಯಾಕ್ಟರಿಂಗ್ ಮಾಡುವುದು:
  1. ಕಾರ್ಯಗಳನ್ನು ತಾರ್ಕಿಕ ಘಟಕಗಳಾಗಿ ವಿಭಜಿಸಿ ಮತ್ತು ಏಕಶಿಲೆಯನ್ನು ಪಾತ್ರಗಳಾಗಿ ಪುನಃ ಬರೆಯಿರಿ
  2. ಲಿಂಟರ್ ಬಳಸಿ! ಅನ್ಸಿಬಲ್-ಲಿಂಟ್, ಯಾಮ್ಲ್-ಲಿಂಟ್, ಇತ್ಯಾದಿ
  3. ನಿಮ್ಮ ವಿಧಾನವನ್ನು ಬದಲಾಯಿಸಿ! ಬ್ಯಾಷ್‌ಸಿಬಲ್ ಇಲ್ಲ. ವ್ಯವಸ್ಥೆಯ ಸ್ಥಿತಿಯನ್ನು ವಿವರಿಸುವುದು ಅವಶ್ಯಕ
• ಎಲ್ಲಾ ಅನ್ಸಿಬಲ್ ಪಾತ್ರಗಳಿಗೆ ನೀವು ಅಣುವಿನಲ್ಲಿ ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯಬೇಕು ಮತ್ತು ದಿನಕ್ಕೆ ಒಮ್ಮೆ ವರದಿಗಳನ್ನು ರಚಿಸಬೇಕು.
• ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಪರೀಕ್ಷೆಗಳನ್ನು ಸಿದ್ಧಪಡಿಸಿದ ನಂತರ (ಅವುಗಳಲ್ಲಿ 100 ಕ್ಕಿಂತ ಹೆಚ್ಚು ಇವೆ), ಸುಮಾರು 70000 ದೋಷಗಳು ಕಂಡುಬಂದಿವೆ. ಅದನ್ನು ಸರಿಪಡಿಸಲು ಹಲವು ತಿಂಗಳು ಬೇಕಾಯಿತು.

ನಮ್ಮ ಅನುಷ್ಠಾನ

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

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

ಸರ್ವರ್‌ಗಳನ್ನು ರಚಿಸಲು ಹಲವು ಆಯ್ಕೆಗಳಿವೆ. ನಾವು ಕಸ್ಟಮ್ ಪೈಥಾನ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಆರಿಸುವುದನ್ನು ಕೊನೆಗೊಳಿಸಿದ್ದೇವೆ. ಮತ್ತು CI ಅನ್ಸಿಬಲ್‌ಗಾಗಿ:

- name: create1.yml - Create a VM from a template
  vmware_guest:
    hostname: "{{datacenter}}".domain.ru
    username: "{{ username_vc }}"
    password: "{{ password_vc }}"
    validate_certs: no
    cluster: "{{cluster}}"
    datacenter: "{{datacenter}}"
    name: "{{ name }}"
    state: poweredon
    folder: "/{{folder}}"
    template: "{{template}}"
    customization:
      hostname: "{{ name }}"
      domain: domain.ru
      dns_servers:
        - "{{ ipa1_dns }}"
        - "{{ ipa2_dns }}"
    networks:
      - name: "{{ network }}"
        type: static
        ip: "{{ip}}"
        netmask: "{{netmask}}"
        gateway: "{{gateway}}"
        wake_on_lan: True
        start_connected: True
        allow_guest_control: True
    wait_for_ip_address: yes
    disk:
      - size_gb: 1
        type: thin
        datastore: "{{datastore}}"
      - size_gb: 20
        type: thin
        datastore: "{{datastore}}"

ಇದು ನಾವು ಬಂದಿದ್ದೇವೆ, ವ್ಯವಸ್ಥೆಯು ಬದುಕಲು ಮತ್ತು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಮುಂದುವರಿಯುತ್ತದೆ.

• 17 ಸರ್ವರ್ ಅನ್ನು ಹೊಂದಿಸಲು ಪ್ರಮುಖ ಪಾತ್ರಗಳು. ಪ್ರತಿಯೊಂದು ಪಾತ್ರಗಳನ್ನು ಪ್ರತ್ಯೇಕ ತಾರ್ಕಿಕ ಕಾರ್ಯವನ್ನು ಪರಿಹರಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ (ಲಾಗಿಂಗ್, ಆಡಿಟಿಂಗ್, ಬಳಕೆದಾರರ ಅಧಿಕಾರ, ಮೇಲ್ವಿಚಾರಣೆ, ಇತ್ಯಾದಿ).
• ಪಾತ್ರ ಪರೀಕ್ಷೆ. ಅಣು + ಟೆಸ್ಟ್‌ಇನ್‌ಫ್ರಾ.
• ಸ್ವಂತ ಅಭಿವೃದ್ಧಿ: CMDB + ಆರ್ಕೆಸ್ಟ್ರೇಟರ್.
• ಸರ್ವರ್ ರಚನೆಯ ಸಮಯವು ~30 ನಿಮಿಷಗಳು, ಸ್ವಯಂಚಾಲಿತ ಮತ್ತು ಕಾರ್ಯ ಸರದಿಯಿಂದ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಸ್ವತಂತ್ರವಾಗಿದೆ.
• ಎಲ್ಲಾ ವಿಭಾಗಗಳಲ್ಲಿ ಮೂಲಸೌಕರ್ಯದ ಒಂದೇ ಸ್ಥಿತಿ/ಹೆಸರು - ಪ್ಲೇಬುಕ್‌ಗಳು, ರೆಪೊಸಿಟರಿಗಳು, ವರ್ಚುವಲೈಸೇಶನ್ ಅಂಶಗಳು.
• ಸ್ಟ್ಯಾಂಡರ್ಡ್‌ನೊಂದಿಗಿನ ವ್ಯತ್ಯಾಸಗಳ ಕುರಿತು ವರದಿಗಳ ಉತ್ಪಾದನೆಯೊಂದಿಗೆ ಸರ್ವರ್ ಸ್ಥಿತಿಯ ದೈನಂದಿನ ಪರಿಶೀಲನೆ.

ನನ್ನ ಕಥೆಯು ಅವರ ಪ್ರಯಾಣದ ಆರಂಭದಲ್ಲಿ ಇರುವವರಿಗೆ ಉಪಯುಕ್ತವಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ನೀವು ಯಾವ ಸ್ವಯಂಚಾಲಿತ ಸ್ಟಾಕ್ ಅನ್ನು ಬಳಸುತ್ತೀರಿ?

ಮೂಲ: www.habr.com