ಒಂದು ವಿಧಾನ ಐಎಸಿ (ಕೋಡ್ ಆಗಿ ಮೂಲಸೌಕರ್ಯ) ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಸಂಗ್ರಹವಾಗಿರುವ ಕೋಡ್ ಅನ್ನು ಮಾತ್ರವಲ್ಲದೆ ಈ ಕೋಡ್ ಅನ್ನು ಸುತ್ತುವರೆದಿರುವ ಜನರು ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಸಾಫ್ಟ್‌ವೇರ್ ಅಭಿವೃದ್ಧಿಯಿಂದ ಮೂಲಸೌಕರ್ಯ ನಿರ್ವಹಣೆ ಮತ್ತು ವಿವರಣೆಯವರೆಗಿನ ವಿಧಾನಗಳನ್ನು ಮರುಬಳಕೆ ಮಾಡಲು ಸಾಧ್ಯವೇ? ನೀವು ಲೇಖನವನ್ನು ಓದುವಾಗ ಈ ವಿಚಾರವನ್ನು ಮನಸ್ಸಿನಲ್ಲಿಟ್ಟುಕೊಳ್ಳುವುದು ಒಳ್ಳೆಯದು.

ಇದು ನನ್ನ ಪ್ರತಿಲಿಪಿ ಪ್ರದರ್ಶನಗಳು ಮೇಲೆ DevopsConf 2019-05-28.

ಸ್ಲೈಡ್‌ಗಳು ಮತ್ತು ವೀಡಿಯೊಗಳು

ಬ್ಯಾಷ್ ಇತಿಹಾಸವಾಗಿ ಮೂಲಸೌಕರ್ಯ

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

ಸ್ವಲ್ಪ ಆಸೆಯಿಂದ, ನಾವು ಅದನ್ನು ಹೇಳಬಹುದು ಬ್ಯಾಷ್ ಇತಿಹಾಸವಾಗಿ ಮೂಲಸೌಕರ್ಯ ಇದು ಕೋಡ್‌ನಂತಿದೆ:

ಪುನರುತ್ಪಾದನೆ: ನೀವು ಬ್ಯಾಷ್ ಇತಿಹಾಸವನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು, ಅಲ್ಲಿಂದ ಆಜ್ಞೆಗಳನ್ನು ಚಲಾಯಿಸಬಹುದು ಮತ್ತು ನೀವು ಔಟ್‌ಪುಟ್ ಆಗಿ ವರ್ಕಿಂಗ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಪಡೆಯಬಹುದು.
ಆವೃತ್ತಿ: ಯಾರು ಬಂದರು ಮತ್ತು ಅವರು ಏನು ಮಾಡಿದರು ಎಂದು ನಿಮಗೆ ತಿಳಿದಿದೆ, ಮತ್ತೆ, ಇದು ನಿರ್ಗಮನದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಕಾನ್ಫಿಗರೇಶನ್‌ಗೆ ನಿಮ್ಮನ್ನು ಕರೆದೊಯ್ಯುತ್ತದೆ ಎಂಬುದು ಸತ್ಯವಲ್ಲ.
ಇತಿಹಾಸ: ಯಾರು ಏನು ಮಾಡಿದರು ಎಂಬ ಕಥೆ. ನೀವು ಸರ್ವರ್ ಅನ್ನು ಕಳೆದುಕೊಂಡರೆ ಮಾತ್ರ ನೀವು ಅದನ್ನು ಬಳಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.

ನಾನು ಏನು ಮಾಡಬೇಕು?

ಕೋಡ್ ಆಗಿ ಮೂಲಸೌಕರ್ಯ

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

ಶುಷ್ಕ

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

ssh ಮೂಲಕ ಇಲ್ಲಿ ಲಾಗ್ ಇನ್ ಮಾಡಿ ಮತ್ತು ಆಜ್ಞೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿ.
ಅಲ್ಲಿ ಫೈಲ್ ಅನ್ನು ನಕಲಿಸಿ.
ಇಲ್ಲಿ ಸಂರಚನೆಯನ್ನು ಸರಿಪಡಿಸಿ.
ಅಲ್ಲಿ ಸೇವೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿ
...
ಲಾಭ!

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

DRY (ನಿಮ್ಮನ್ನು ಪುನರಾವರ್ತಿಸಬೇಡಿ) ನಂತಹ ಅಭ್ಯಾಸವಿದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ. ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕೋಡ್ ಅನ್ನು ಮರುಬಳಕೆ ಮಾಡುವ ಆಲೋಚನೆ ಇದೆ. ಇದು ಸರಳವೆಂದು ತೋರುತ್ತದೆ, ಆದರೆ ನಾವು ಈಗಿನಿಂದಲೇ ಇದಕ್ಕೆ ಬರಲಿಲ್ಲ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಇದು ನೀರಸ ಕಲ್ಪನೆಯಾಗಿದೆ: ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳಿಂದ ಸಂರಚನೆಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು. ಆ. ಅನುಸ್ಥಾಪನೆಯನ್ನು ಹೇಗೆ ಪ್ರತ್ಯೇಕವಾಗಿ ನಿಯೋಜಿಸಲಾಗಿದೆ ಎಂಬುದರ ವ್ಯವಹಾರ ತರ್ಕ, ಪ್ರತ್ಯೇಕವಾಗಿ ಸಂರಚನೆಗಳು.

CFM ಗಾಗಿ SOLID

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

ಏಕ ಜವಾಬ್ದಾರಿ ತತ್ವ

ಪ್ರತಿಯೊಂದು ವರ್ಗವು ಕೇವಲ ಒಂದು ಕಾರ್ಯವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ.

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

ಓಪನ್ ಕ್ಲೋಸ್ಡ್ ಪ್ರಿನ್ಸಿಪಲ್

ತೆರೆದ/ಮುಚ್ಚಿದ ತತ್ವ.

ವಿಸ್ತರಣೆಗೆ ತೆರೆಯಿರಿ: ಅಂದರೆ ಹೊಸ ಅಸ್ತಿತ್ವದ ಪ್ರಕಾರಗಳನ್ನು ರಚಿಸುವ ಮೂಲಕ ಅಸ್ತಿತ್ವದ ನಡವಳಿಕೆಯನ್ನು ವಿಸ್ತರಿಸಬಹುದು.
ಬದಲಾವಣೆಗೆ ಮುಚ್ಚಲಾಗಿದೆ: ಅಸ್ತಿತ್ವದ ನಡವಳಿಕೆಯನ್ನು ವಿಸ್ತರಿಸುವ ಪರಿಣಾಮವಾಗಿ, ಆ ಘಟಕಗಳನ್ನು ಬಳಸುವ ಕೋಡ್‌ಗೆ ಯಾವುದೇ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಬಾರದು.

ಆರಂಭದಲ್ಲಿ, ನಾವು ವರ್ಚುವಲ್ ಯಂತ್ರಗಳಲ್ಲಿ ಪರೀಕ್ಷಾ ಮೂಲಸೌಕರ್ಯವನ್ನು ನಿಯೋಜಿಸಿದ್ದೇವೆ, ಆದರೆ ನಿಯೋಜನೆಯ ವ್ಯವಹಾರ ತರ್ಕವು ಅನುಷ್ಠಾನದಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿರುವುದರಿಂದ, ಯಾವುದೇ ತೊಂದರೆಗಳಿಲ್ಲದೆ ನಾವು ಬೇರ್ಮೆಟಲ್‌ಗೆ ರೋಲಿಂಗ್ ಅನ್ನು ಸೇರಿಸಿದ್ದೇವೆ.

ಲಿಸ್ಕೋವ್ ಪರ್ಯಾಯ ತತ್ವ

ಬಾರ್ಬರಾ ಲಿಸ್ಕೋವ್ ಅವರ ಪರ್ಯಾಯ ತತ್ವ. ಪ್ರೋಗ್ರಾಂನ ಸರಿಯಾದ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ಬದಲಾಯಿಸದೆಯೇ ಪ್ರೋಗ್ರಾಂನಲ್ಲಿನ ವಸ್ತುಗಳು ಅವುಗಳ ಉಪವಿಧಗಳ ನಿದರ್ಶನಗಳೊಂದಿಗೆ ಬದಲಾಯಿಸಲ್ಪಡಬೇಕು

ನೀವು ಅದನ್ನು ಹೆಚ್ಚು ವಿಶಾಲವಾಗಿ ನೋಡಿದರೆ, ಅಲ್ಲಿ ಅನ್ವಯಿಸಬಹುದಾದ ಯಾವುದೇ ನಿರ್ದಿಷ್ಟ ಯೋಜನೆಯ ವೈಶಿಷ್ಟ್ಯವಲ್ಲ ಘನ, ಇದು ಸಾಮಾನ್ಯವಾಗಿ CFM ಬಗ್ಗೆ, ಉದಾಹರಣೆಗೆ, ಮತ್ತೊಂದು ಯೋಜನೆಯಲ್ಲಿ ವಿವಿಧ ಜಾವಾ, ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ಗಳು, ಡೇಟಾಬೇಸ್‌ಗಳು, OS, ಇತ್ಯಾದಿಗಳ ಮೇಲೆ ಪೆಟ್ಟಿಗೆಯ ಜಾವಾ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿಯೋಜಿಸಲು ಇದು ಅಗತ್ಯವಾಗಿರುತ್ತದೆ. ಈ ಉದಾಹರಣೆಯನ್ನು ಬಳಸಿಕೊಂಡು, ನಾನು ಮತ್ತಷ್ಟು ತತ್ವಗಳನ್ನು ಪರಿಗಣಿಸುತ್ತೇನೆ ಘನ

ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಇಂಬ್ಜಾವಾ ಅಥವಾ ಒರಾಕ್ಲೆಜಾವಾ ಪಾತ್ರವನ್ನು ಸ್ಥಾಪಿಸಿದ್ದರೆ, ನಾವು ಜಾವಾ ಬೈನರಿ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ಮೂಲಸೌಕರ್ಯ ತಂಡದೊಳಗೆ ಒಪ್ಪಂದವಿದೆ. ಇದು ಅವಶ್ಯಕ ಏಕೆಂದರೆ ಅಪ್ಸ್ಟ್ರೀಮ್ ಪಾತ್ರಗಳು ಈ ನಡವಳಿಕೆಯ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ; ಅವರು ಜಾವಾವನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತಾರೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಅಪ್ಲಿಕೇಶನ್ ನಿಯೋಜನೆಯ ತರ್ಕವನ್ನು ಬದಲಾಯಿಸದೆಯೇ ಒಂದು ಜಾವಾ ಅನುಷ್ಠಾನ/ಆವೃತ್ತಿಯನ್ನು ಇನ್ನೊಂದಕ್ಕೆ ಬದಲಾಯಿಸಲು ಇದು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

ಇಲ್ಲಿ ಸಮಸ್ಯೆಯು ಅನ್ಸಿಬಲ್‌ನಲ್ಲಿ ಇದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಅಸಾಧ್ಯವಾಗಿದೆ ಎಂಬ ಅಂಶದಲ್ಲಿದೆ, ಇದರ ಪರಿಣಾಮವಾಗಿ ತಂಡದೊಳಗೆ ಕೆಲವು ಒಪ್ಪಂದಗಳು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ.

ಇಂಟರ್ಫೇಸ್ ಪ್ರತ್ಯೇಕತೆಯ ತತ್ವ

ಇಂಟರ್ಫೇಸ್ ಬೇರ್ಪಡಿಕೆ ತತ್ವ: "ಹಲವು ಕ್ಲೈಂಟ್-ನಿರ್ದಿಷ್ಟ ಇಂಟರ್ಫೇಸ್ಗಳು ಒಂದು ಸಾಮಾನ್ಯ-ಉದ್ದೇಶದ ಇಂಟರ್ಫೇಸ್ಗಿಂತ ಉತ್ತಮವಾಗಿವೆ.

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

ಅವಲಂಬನೆ ವಿಲೋಮ ತತ್ವ

ಅವಲಂಬನೆ ವಿಲೋಮ ತತ್ವ. ಉನ್ನತ ಮಟ್ಟದ ಮಾಡ್ಯೂಲ್‌ಗಳು ಕೆಳ ಹಂತದಲ್ಲಿರುವ ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಅವಲಂಬಿಸಿರಬಾರದು. ಎರಡೂ ವಿಧದ ಮಾಡ್ಯೂಲ್‌ಗಳು ಅಮೂರ್ತತೆಯ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರಬೇಕು. ಅಮೂರ್ತತೆಗಳು ವಿವರಗಳನ್ನು ಅವಲಂಬಿಸಿರಬಾರದು. ವಿವರಗಳು ಅಮೂರ್ತತೆಯ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರಬೇಕು.

ಇಲ್ಲಿ ಉದಾಹರಣೆಯು ಆಂಟಿಪ್ಯಾಟರ್ನ್ ಅನ್ನು ಆಧರಿಸಿದೆ.

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

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

ಪರಸ್ಪರ ಕ್ರಿಯೆ

ಮೂಲಸೌಕರ್ಯವು ಕೋಡ್‌ನ ಬಗ್ಗೆ ಮಾತ್ರವಲ್ಲ, ಕೋಡ್ ಮತ್ತು ಜನರ ನಡುವಿನ ಸಂಬಂಧ, ಮೂಲಸೌಕರ್ಯ ಅಭಿವರ್ಧಕರ ನಡುವಿನ ಪರಸ್ಪರ ಕ್ರಿಯೆಗಳ ಬಗ್ಗೆಯೂ ಆಗಿದೆ.

ಬಸ್ ಅಂಶ

ನಿಮ್ಮ ಯೋಜನೆಯಲ್ಲಿ ನೀವು ವಾಸ್ಯವನ್ನು ಹೊಂದಿದ್ದೀರಿ ಎಂದು ಭಾವಿಸೋಣ. ವಾಸ್ಯಾ ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯದ ಬಗ್ಗೆ ಎಲ್ಲವನ್ನೂ ತಿಳಿದಿದ್ದಾರೆ, ವಾಸ್ಯಾ ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಕಣ್ಮರೆಯಾದರೆ ಏನಾಗುತ್ತದೆ? ಇದು ಅತ್ಯಂತ ನೈಜ ಪರಿಸ್ಥಿತಿಯಾಗಿದೆ, ಏಕೆಂದರೆ ಅವನು ಬಸ್‌ನಿಂದ ಹೊಡೆಯಬಹುದು. ಕೆಲವೊಮ್ಮೆ ಇದು ಸಂಭವಿಸುತ್ತದೆ. ಇದು ಸಂಭವಿಸಿದಲ್ಲಿ ಮತ್ತು ಕೋಡ್, ಅದರ ರಚನೆ, ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಕಾಣಿಸಿಕೊಳ್ಳುವಿಕೆಗಳು ಮತ್ತು ಪಾಸ್ವರ್ಡ್ಗಳ ಬಗ್ಗೆ ಜ್ಞಾನವನ್ನು ತಂಡದ ನಡುವೆ ವಿತರಿಸದಿದ್ದರೆ, ನೀವು ಹಲವಾರು ಅಹಿತಕರ ಸಂದರ್ಭಗಳನ್ನು ಎದುರಿಸಬಹುದು. ಈ ಅಪಾಯಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಮತ್ತು ತಂಡದೊಳಗೆ ಜ್ಞಾನವನ್ನು ವಿತರಿಸಲು, ನೀವು ವಿವಿಧ ವಿಧಾನಗಳನ್ನು ಬಳಸಬಹುದು

ಜೋಡಿ ಡೆವೊಪ್ಸಿಂಗ್

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

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

ಕೋಡ್ ವಿಮರ್ಶೆ

ವಸ್ತುನಿಷ್ಠವಾಗಿ, ಮೂಲಸೌಕರ್ಯ ಮತ್ತು ಕೋಡ್ ವಿಮರ್ಶೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಜ್ಞಾನವನ್ನು ಪ್ರಸಾರ ಮಾಡಲು ಇದು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ:

ಮೂಲಸೌಕರ್ಯವನ್ನು ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಕೋಡ್ ಮೂಲಕ ವಿವರಿಸಲಾಗಿದೆ.
ಬದಲಾವಣೆಗಳು ಪ್ರತ್ಯೇಕ ಶಾಖೆಯಲ್ಲಿ ಸಂಭವಿಸುತ್ತವೆ.
ವಿಲೀನ ವಿನಂತಿಯ ಸಮಯದಲ್ಲಿ, ಮೂಲಸೌಕರ್ಯದಲ್ಲಿನ ಬದಲಾವಣೆಗಳ ಡೆಲ್ಟಾವನ್ನು ನೀವು ನೋಡಬಹುದು.

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

ಕೋಡ್ ಶೈಲಿ

ಕಾಲಾನಂತರದಲ್ಲಿ, ವಿಮರ್ಶೆಗಳ ಸಮಯದಲ್ಲಿ ಜಗಳಗಳು ಕಾಣಿಸಿಕೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸಿದವು, ಏಕೆಂದರೆ... ವಿಮರ್ಶಕರು ತಮ್ಮದೇ ಆದ ಶೈಲಿಯನ್ನು ಹೊಂದಿದ್ದರು ಮತ್ತು ವಿಮರ್ಶಕರ ತಿರುಗುವಿಕೆಯು ಅವುಗಳನ್ನು ವಿಭಿನ್ನ ಶೈಲಿಗಳೊಂದಿಗೆ ಜೋಡಿಸಲಾಗಿದೆ: 2 ಸ್ಪೇಸ್‌ಗಳು ಅಥವಾ 4, ಕ್ಯಾಮಲ್‌ಕೇಸ್ ಅಥವಾ ಸ್ನೇಕ್_ಕೇಸ್. ಇದನ್ನು ತಕ್ಷಣ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ.

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

ಗ್ರೀನ್ ಬಿಲ್ಡ್ ಮಾಸ್ಟರ್

ಸಮಯವು ಹಾದುಹೋಗುತ್ತದೆ, ಮತ್ತು ಕೆಲವು ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ಉತ್ತೀರ್ಣರಾಗದ ಬದ್ಧತೆಯನ್ನು ಮಾಸ್ಟರ್‌ಗೆ ಅನುಮತಿಸಲಾಗುವುದಿಲ್ಲ ಎಂಬ ತೀರ್ಮಾನಕ್ಕೆ ನಾವು ಬಂದಿದ್ದೇವೆ. Voila! ನಾವು ಗ್ರೀನ್ ಬಿಲ್ಡ್ ಮಾಸ್ಟರ್ ಅನ್ನು ಕಂಡುಹಿಡಿದಿದ್ದೇವೆ, ಇದನ್ನು ಸಾಫ್ಟ್‌ವೇರ್ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ದೀರ್ಘಕಾಲ ಅಭ್ಯಾಸ ಮಾಡಲಾಗಿದೆ:

ಪ್ರತ್ಯೇಕ ಶಾಖೆಯಲ್ಲಿ ಅಭಿವೃದ್ಧಿ ನಡೆಯುತ್ತಿದೆ.
ಈ ಥ್ರೆಡ್‌ನಲ್ಲಿ ಪರೀಕ್ಷೆಗಳು ನಡೆಯುತ್ತಿವೆ.
ಪರೀಕ್ಷೆಗಳು ವಿಫಲವಾದರೆ, ಕೋಡ್ ಅದನ್ನು ಮಾಸ್ಟರ್ ಆಗಿ ಮಾಡುವುದಿಲ್ಲ.

ಈ ನಿರ್ಧಾರವು ತುಂಬಾ ನೋವಿನಿಂದ ಕೂಡಿದೆ, ಏಕೆಂದರೆ ... ಬಹಳಷ್ಟು ವಿವಾದಗಳನ್ನು ಉಂಟುಮಾಡಿತು, ಆದರೆ ಅದು ಯೋಗ್ಯವಾಗಿತ್ತು, ಏಕೆಂದರೆ... ವಿಮರ್ಶೆಗಳು ಶೈಲಿಯಲ್ಲಿ ವ್ಯತ್ಯಾಸಗಳಿಲ್ಲದೆ ವಿಲೀನಕ್ಕಾಗಿ ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಪ್ರಾರಂಭಿಸಿದವು ಮತ್ತು ಕಾಲಾನಂತರದಲ್ಲಿ ಸಮಸ್ಯೆಯ ಪ್ರದೇಶಗಳ ಸಂಖ್ಯೆಯು ಕಡಿಮೆಯಾಗಲು ಪ್ರಾರಂಭಿಸಿತು.

IaC ಪರೀಕ್ಷೆ

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

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

IaC ಪರೀಕ್ಷಾ ಪಿರಮಿಡ್

IaC ಪರೀಕ್ಷೆ: ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆ

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

ಬ್ಯಾಷ್ ಟ್ರಿಕಿ ಆಗಿದೆ

ಒಂದು ಕ್ಷುಲ್ಲಕ ಉದಾಹರಣೆಯನ್ನು ನೋಡೋಣ. ಪ್ರಸ್ತುತ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿರುವ ಎಲ್ಲಾ ಫೈಲ್‌ಗಳನ್ನು ಆಯ್ಕೆಮಾಡಿ ಮತ್ತು ಇನ್ನೊಂದು ಸ್ಥಳಕ್ಕೆ ನಕಲಿಸಿ. ಮನಸ್ಸಿಗೆ ಬರುವ ಮೊದಲ ವಿಷಯ:

for i in * ; do 
    cp $i /some/path/$i.bak
done

ಫೈಲ್ ಹೆಸರಿನಲ್ಲಿ ಜಾಗವಿದ್ದರೆ ಏನು? ಸರಿ, ಸರಿ, ನಾವು ಬುದ್ಧಿವಂತರಾಗಿದ್ದೇವೆ, ಉಲ್ಲೇಖಗಳನ್ನು ಹೇಗೆ ಬಳಸುವುದು ಎಂದು ನಮಗೆ ತಿಳಿದಿದೆ:

for i in * ; do cp "$i" "/some/path/$i.bak" ; done

ಚೆನ್ನಾಗಿ ಮಾಡಿದ್ದೀರಾ? ಇಲ್ಲ! ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಏನೂ ಇಲ್ಲದಿದ್ದರೆ ಏನು, ಅಂದರೆ. ಗ್ಲೋಬಿಂಗ್ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ.

find . -type f -exec mv -v {} dst/{}.bak ;

ಈಗ ಚೆನ್ನಾಗಿದೆಯೇ? ಇಲ್ಲ... ಫೈಲ್ ಹೆಸರಿನಲ್ಲಿ ಏನಿರಬಹುದೆಂಬುದನ್ನು ಮರೆತುಬಿಟ್ಟಿದೆ n.

touch x
mv x  "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dir

ಸ್ಥಾಯೀ ವಿಶ್ಲೇಷಣಾ ಸಾಧನಗಳು

ನಾವು ಉಲ್ಲೇಖಗಳನ್ನು ಮರೆತಾಗ ಹಿಂದಿನ ಹಂತದ ಸಮಸ್ಯೆಯನ್ನು ಹಿಡಿಯಬಹುದು, ಇದಕ್ಕಾಗಿ ಪ್ರಕೃತಿಯಲ್ಲಿ ಹಲವು ಪರಿಹಾರಗಳಿವೆ ಶೆಲ್ ಚೆಕ್, ಸಾಮಾನ್ಯವಾಗಿ ಅವುಗಳಲ್ಲಿ ಬಹಳಷ್ಟು ಇವೆ, ಮತ್ತು ಹೆಚ್ಚಾಗಿ ನಿಮ್ಮ IDE ಅಡಿಯಲ್ಲಿ ನಿಮ್ಮ ಸ್ಟಾಕ್‌ಗಾಗಿ ನೀವು ಲಿಂಟರ್ ಅನ್ನು ಕಾಣಬಹುದು.

ಭಾಷಾ
ಉಪಕರಣ

ಬ್ಯಾಷ್
ಶೆಲ್ ಚೆಕ್

ರೂಬಿ
ರೂಬೋಕಾಪ್

ಪೈಥಾನ್
ಪೈಲಿಂಟ್

ಉತ್ತರಿಸಬಲ್ಲ
ಅನ್ಸಿಬಲ್ ಲಿಂಟ್

IaC ಪರೀಕ್ಷೆ: ಘಟಕ ಪರೀಕ್ಷೆಗಳು

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

ಆರಂಭದಲ್ಲಿ ನಾವು ಮಾತನಾಡಿದ್ದೇವೆ ಘನ ಮತ್ತು ನಮ್ಮ ಮೂಲಸೌಕರ್ಯವು ಸಣ್ಣ ಇಟ್ಟಿಗೆಗಳಿಂದ ಕೂಡಿರಬೇಕು. ಅವರ ಸಮಯ ಬಂದಿದೆ.

ಮೂಲಸೌಕರ್ಯವನ್ನು ಸಣ್ಣ ಇಟ್ಟಿಗೆಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ, ಉದಾಹರಣೆಗೆ, ಅನ್ಸಿಬಲ್ ಪಾತ್ರಗಳು.
ಕೆಲವು ರೀತಿಯ ಪರಿಸರವನ್ನು ನಿಯೋಜಿಸಲಾಗಿದೆ, ಅದು ಡಾಕರ್ ಅಥವಾ VM ಆಗಿರಬಹುದು.
ಈ ಪರೀಕ್ಷಾ ಪರಿಸರಕ್ಕೆ ನಾವು ನಮ್ಮ ಅನ್ಸಿಬಲ್ ಪಾತ್ರವನ್ನು ಅನ್ವಯಿಸುತ್ತೇವೆ.
ನಾವು ನಿರೀಕ್ಷಿಸಿದಂತೆ ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡಿದೆ ಎಂದು ನಾವು ಪರಿಶೀಲಿಸುತ್ತೇವೆ (ನಾವು ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸುತ್ತೇವೆ).
ಸರಿ ಅಥವಾ ಸರಿ ಅಲ್ಲ ಎಂದು ನಾವು ನಿರ್ಧರಿಸುತ್ತೇವೆ.

IaC ಪರೀಕ್ಷೆ: ಘಟಕ ಪರೀಕ್ಷೆ ಉಪಕರಣಗಳು

ಪ್ರಶ್ನೆ, CFM ಗಾಗಿ ಪರೀಕ್ಷೆಗಳು ಯಾವುವು? ನೀವು ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಸರಳವಾಗಿ ಚಲಾಯಿಸಬಹುದು ಅಥವಾ ಇದಕ್ಕಾಗಿ ನೀವು ಸಿದ್ಧ ಪರಿಹಾರಗಳನ್ನು ಬಳಸಬಹುದು:

CFM
ಉಪಕರಣ

ಅನುಕಂಪ
ಟೆಸ್ಟಿನ್ಫ್ರಾ

ತಲೆ
ಇನ್ಸ್ಪೆಕ್

ತಲೆ
ಸರ್ವರ್ಸ್ಪೆಕ್

ಉಪ್ಪಿನ ಬಣವೆ
ಗಾಸ್

testinfra ಗಾಗಿ ಉದಾಹರಣೆ, ಬಳಕೆದಾರರನ್ನು ಪರಿಶೀಲಿಸಲಾಗುತ್ತಿದೆ test1, test2 ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಮತ್ತು ಗುಂಪಿನಲ್ಲಿದ್ದಾರೆ sshusers:

def test_default_users(host):
    users = ['test1', 'test2' ]
    for login in users:
        assert host.user(login).exists
        assert 'sshusers' in host.user(login).groups

ಯಾವುದನ್ನು ಆರಿಸಬೇಕು? ಪ್ರಶ್ನೆಯು ಸಂಕೀರ್ಣ ಮತ್ತು ಅಸ್ಪಷ್ಟವಾಗಿದೆ, 2018-2019 ಗಾಗಿ ಗಿಥಬ್‌ನಲ್ಲಿನ ಯೋಜನೆಗಳಲ್ಲಿನ ಬದಲಾವಣೆಗಳ ಉದಾಹರಣೆ ಇಲ್ಲಿದೆ:

IaC ಪರೀಕ್ಷಾ ಚೌಕಟ್ಟುಗಳು

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

CFM
ಉಪಕರಣ

ಅನುಕಂಪ
ಅಣು

ತಲೆ
ಟೆಸ್ಟ್ ಕಿಚನ್

ಟೆರಾಫಾರ್ಮ್
ಟೆರಾಟೆಸ್ಟ್

2018-2019 ಗಾಗಿ ಗಿಥಬ್‌ನಲ್ಲಿನ ಯೋಜನೆಗಳಲ್ಲಿನ ಬದಲಾವಣೆಗಳ ಉದಾಹರಣೆ:

ಅಣು vs. ಟೆಸ್ಟ್ಕಿಚನ್

ಆರಂಭದಲ್ಲಿ ನಾವು ಟೆಸ್ಟ್ಕಿಚನ್ ಅನ್ನು ಬಳಸಲು ಪ್ರಯತ್ನಿಸಿದೆ:

ಸಮಾನಾಂತರವಾಗಿ VM ಅನ್ನು ರಚಿಸಿ.
ಅನ್ಸಿಬಲ್ ಪಾತ್ರಗಳನ್ನು ಅನ್ವಯಿಸಿ.
ತಪಾಸಣೆ ರನ್ ಮಾಡಿ.

25-35 ಪಾತ್ರಗಳಿಗೆ ಇದು 40-70 ನಿಮಿಷಗಳ ಕಾಲ ಕೆಲಸ ಮಾಡಿತು, ಅದು ದೀರ್ಘವಾಗಿತ್ತು.

ಮುಂದಿನ ಹಂತವು ಜೆಂಕಿನ್ಸ್/ಡಾಕರ್/ಆನ್ಸಿಬಲ್/ಮಾಲಿಕ್ಯೂಲ್‌ಗೆ ಪರಿವರ್ತನೆಯಾಗಿದೆ. ವೈಚಾರಿಕವಾಗಿ ಎಲ್ಲವೂ ಒಂದೇ

ಲಿಂಟ್ ಪ್ಲೇಬುಕ್ಸ್.
ಪಾತ್ರಗಳನ್ನು ಸಾಲು ಮಾಡಿ.
ಧಾರಕವನ್ನು ಪ್ರಾರಂಭಿಸಿ
ಅನ್ಸಿಬಲ್ ಪಾತ್ರಗಳನ್ನು ಅನ್ವಯಿಸಿ.
testinfra ರನ್ ಮಾಡಿ.
ದುರ್ಬಲತೆಯನ್ನು ಪರಿಶೀಲಿಸಿ.

40 ಪಾತ್ರಗಳಿಗೆ ಲಿಂಟಿಂಗ್ ಮತ್ತು ಒಂದು ಡಜನ್ ಪರೀಕ್ಷೆಗಳು ಸುಮಾರು 15 ನಿಮಿಷಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸಿದವು.

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

IaC ಪರೀಕ್ಷೆ: ಏಕೀಕರಣ ಪರೀಕ್ಷೆಗಳು

ಮೂಲಸೌಕರ್ಯ ಪರೀಕ್ಷೆಯ ಪಿರಮಿಡ್‌ನ ಮುಂದಿನ ಹಂತವು ಏಕೀಕರಣ ಪರೀಕ್ಷೆಗಳಾಗಿರುತ್ತದೆ. ಅವು ಘಟಕ ಪರೀಕ್ಷೆಗಳಿಗೆ ಹೋಲುತ್ತವೆ:

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

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

IaC ಪರೀಕ್ಷೆ: ಎಂಡ್ ಟು ಎಂಡ್ ಪರೀಕ್ಷೆಗಳು

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

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

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

ಸಂಶೋಧನಾ ಕಲ್ಪನೆಯು ಮತ್ತಷ್ಟು ಹೋಯಿತು, ಮತ್ತು ಓಪನ್‌ಶಿಫ್ಟ್‌ನಲ್ಲಿ ಅವರು ಎಪಿಬಿ (ಅನ್ಸಿಬಲ್ ಪ್ಲೇಬುಕ್ ಬಂಡಲ್) ನಂತಹ ವಿಷಯವನ್ನು ಕಂಡುಕೊಂಡರು, ಇದು ಮೂಲಸೌಕರ್ಯವನ್ನು ಕಂಟೇನರ್‌ನಲ್ಲಿ ಹೇಗೆ ನಿಯೋಜಿಸುವುದು ಎಂಬುದರ ಕುರಿತು ಜ್ಞಾನವನ್ನು ಪ್ಯಾಕ್ ಮಾಡಲು ನಿಮಗೆ ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಆ. ಮೂಲಸೌಕರ್ಯವನ್ನು ಹೇಗೆ ನಿಯೋಜಿಸಬೇಕು ಎಂಬುದರ ಕುರಿತು ಪುನರಾವರ್ತಿತ, ಪರೀಕ್ಷಿಸಬಹುದಾದ ಜ್ಞಾನದ ಅಂಶವಿದೆ.

ನಾವು ವೈವಿಧ್ಯಮಯ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಓಡುವವರೆಗೂ ಇದೆಲ್ಲವೂ ಚೆನ್ನಾಗಿದೆ: ಪರೀಕ್ಷೆಗಳಿಗೆ ನಮಗೆ ವಿಂಡೋಸ್ ಅಗತ್ಯವಿದೆ. ಪರಿಣಾಮವಾಗಿ, ಏನು, ಎಲ್ಲಿ, ಹೇಗೆ ನಿಯೋಜಿಸಬೇಕು ಮತ್ತು ಪರೀಕ್ಷಿಸಬೇಕು ಎಂಬ ಜ್ಞಾನವು ಜೆಂಕಿನ್ಸ್‌ನಲ್ಲಿದೆ.

ತೀರ್ಮಾನ

ಕೋಡ್‌ನಂತೆ ಮೂಲಸೌಕರ್ಯ

ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಕೋಡ್.
ಮಾನವ ಸಂವಹನ.
ಮೂಲಸೌಕರ್ಯ ಪರೀಕ್ಷೆ.

ಕೊಂಡಿಗಳು

ಮೂಲ: www.habr.com

200 ಲೈನ್‌ಗಳ ಇನ್‌ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್ ಕೋಡ್ ಪರೀಕ್ಷೆಯಿಂದ ನಾನು ಕಲಿತದ್ದು