ansible devops ಕೋಡ್ಸ್ಟೈಲ್
ಹೇ! ನನ್ನ ಹೆಸರು ನಾನು ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ವಿಭಾಗದಲ್ಲಿ ಎಂಜಿನಿಯರ್ ಆಗಿ ಕೆಲಸ ಮಾಡುತ್ತೇನೆ. ಪ್ರತಿದಿನ, ನೂರಾರು ಪ್ರಚಾರ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಹೊಸ ಅಪ್ಲಿಕೇಶನ್ ನಿರ್ಮಾಣಗಳನ್ನು ಹೊರತರಲಾಗುತ್ತದೆ. ಮತ್ತು ಈ ಲೇಖನದಲ್ಲಿ ನಾನು ಈ ಉದ್ದೇಶಗಳಿಗಾಗಿ ಅನ್ಸಿಬಲ್ ಅನ್ನು ಬಳಸುವ ನನ್ನ ಅನುಭವವನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತೇನೆ.
ಈ ಮಾರ್ಗದರ್ಶಿ ನಿಯೋಜನೆಯಲ್ಲಿ ಅಸ್ಥಿರಗಳನ್ನು ಸಂಘಟಿಸಲು ಒಂದು ಮಾರ್ಗವನ್ನು ನೀಡುತ್ತದೆ. ಈ ಮಾರ್ಗದರ್ಶಿ ಈಗಾಗಲೇ ತಮ್ಮ ಪ್ಲೇಬುಕ್‌ಗಳಲ್ಲಿ ಪಾತ್ರಗಳನ್ನು ಬಳಸುವ ಮತ್ತು ಓದಿದವರಿಗೆ ಉದ್ದೇಶಿಸಲಾಗಿದೆ , ಆದರೆ ಇದೇ ರೀತಿಯ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸುತ್ತಿದೆ:
- ಕೋಡ್ನಲ್ಲಿ ವೇರಿಯಬಲ್ ಅನ್ನು ಕಂಡುಕೊಂಡ ನಂತರ, ಅದು ಏನು ಜವಾಬ್ದಾರವಾಗಿದೆ ಎಂಬುದನ್ನು ತಕ್ಷಣವೇ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಅಸಾಧ್ಯ;
- ಹಲವಾರು ಪಾತ್ರಗಳಿವೆ, ಮತ್ತು ಅಸ್ಥಿರಗಳು ಒಂದು ಮೌಲ್ಯದೊಂದಿಗೆ ಸಂಬಂಧಿಸಬೇಕಾಗಿದೆ, ಆದರೆ ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ;
- ನಿಮ್ಮ ಪ್ಲೇಬುಕ್‌ಗಳಲ್ಲಿನ ವೇರಿಯೇಬಲ್‌ಗಳ ತರ್ಕವು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಇತರರಿಗೆ ವಿವರಿಸಲು ಕಷ್ಟವಾಗುತ್ತಿದೆ
ನಮ್ಮ ಕಂಪನಿಯಲ್ಲಿನ ಯೋಜನೆಗಳಲ್ಲಿ ನಾವು ಈ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸಿದ್ದೇವೆ, ಇದರ ಪರಿಣಾಮವಾಗಿ ನಮ್ಮ ಪ್ಲೇಬುಕ್‌ಗಳಲ್ಲಿ ವೇರಿಯಬಲ್‌ಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುವ ನಿಯಮಗಳಿಗೆ ನಾವು ಬಂದಿದ್ದೇವೆ, ಅದು ಸ್ವಲ್ಪ ಮಟ್ಟಿಗೆ ಈ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಿದೆ.
ಪಾತ್ರಗಳಲ್ಲಿ ಅಸ್ಥಿರ
ಒಂದು ಪಾತ್ರವು ನಿಯೋಜನೆ ವ್ಯವಸ್ಥೆಯ ಪ್ರತ್ಯೇಕ ವಸ್ತುವಾಗಿದೆ. ಯಾವುದೇ ಸಿಸ್ಟಮ್ ಆಬ್ಜೆಕ್ಟ್ನಂತೆ, ಇದು ಸಿಸ್ಟಮ್ನ ಉಳಿದ ಭಾಗಗಳೊಂದಿಗೆ ಸಂವಹನಕ್ಕಾಗಿ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಹೊಂದಿರಬೇಕು. ಅಂತಹ ಇಂಟರ್ಫೇಸ್ ರೋಲ್ ವೇರಿಯಬಲ್ ಆಗಿದೆ.
ಉದಾಹರಣೆಗೆ, ಪಾತ್ರವನ್ನು ತೆಗೆದುಕೊಳ್ಳೋಣ api, ಇದು ಸರ್ವರ್‌ನಲ್ಲಿ ಜಾವಾ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ. ಇದು ಯಾವ ಅಸ್ಥಿರಗಳನ್ನು ಹೊಂದಿರಬಹುದು?
ಪ್ರಕಾರದ ಪ್ರಕಾರ ವೇರಿಯಬಲ್ ಪಾತ್ರಗಳನ್ನು 2 ವಿಧಗಳಾಗಿ ವಿಂಗಡಿಸಬಹುದು:
1. Свойства
a) независимые от среды
б) зависимые от среды
2. Связи
a) слушатели
б) запросы внутри системы
в) запросы в среду
ವೇರಿಯಬಲ್ ಗುಣಲಕ್ಷಣಗಳು ಪಾತ್ರದ ನಡವಳಿಕೆಯನ್ನು ನಿರ್ಧರಿಸುವ ಅಸ್ಥಿರಗಳಾಗಿವೆ.
ಕ್ವೆರಿ ವೇರಿಯೇಬಲ್ಸ್ - ಇವುಗಳು ಅಸ್ಥಿರವಾಗಿದ್ದು, ಪಾತ್ರಕ್ಕೆ ಬಾಹ್ಯ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಗೊತ್ತುಪಡಿಸಲು ಮೌಲ್ಯವನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.
ವೇರಿಯಬಲ್ ಕೇಳುಗರು - ಇವುಗಳು ವೇರಿಯಬಲ್‌ಗಳಾಗಿದ್ದು, ವಿನಂತಿಯ ಅಸ್ಥಿರಗಳನ್ನು ರೂಪಿಸಲು ಮೌಲ್ಯವನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.
ಮತ್ತೊಂದೆಡೆ, 1a, 2a, 2b ಪರಿಸರವನ್ನು (ಹಾರ್ಡ್‌ವೇರ್, ಬಾಹ್ಯ ಸಂಪನ್ಮೂಲಗಳು, ಇತ್ಯಾದಿ) ಅವಲಂಬಿಸಿರದ ಅಸ್ಥಿರಗಳಾಗಿವೆ ಮತ್ತು ಡೀಫಾಲ್ಟ್ ಪಾತ್ರದಲ್ಲಿ ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯಗಳೊಂದಿಗೆ ತುಂಬಬಹುದು. ಆದಾಗ್ಯೂ, 1.b ಮತ್ತು 2.c ಪ್ರಕಾರದ ವೇರಿಯೇಬಲ್‌ಗಳನ್ನು 'ಉದಾಹರಣೆ' ಹೊರತುಪಡಿಸಿ ಮೌಲ್ಯಗಳೊಂದಿಗೆ ತುಂಬುವುದು ಅಸಾಧ್ಯ, ಏಕೆಂದರೆ ಅವು ಪರಿಸರವನ್ನು ಅವಲಂಬಿಸಿ ಸ್ಟ್ಯಾಂಡ್‌ನಿಂದ ಸ್ಟ್ಯಾಂಡ್‌ಗೆ ಬದಲಾಗುತ್ತವೆ.
ಕೋಡ್ ಶೈಲಿ
- ವೇರಿಯಬಲ್ ಹೆಸರು ಪಾತ್ರದ ಹೆಸರಿನೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗಬೇಕು. ಭವಿಷ್ಯದಲ್ಲಿ ವೇರಿಯಬಲ್ ಯಾವ ಪಾತ್ರದಿಂದ ಮತ್ತು ಅದು ಏನು ಜವಾಬ್ದಾರವಾಗಿದೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಲು ಇದು ಸುಲಭವಾಗುತ್ತದೆ.
- ಪಾತ್ರಗಳಲ್ಲಿ ವೇರಿಯೇಬಲ್‌ಗಳನ್ನು ಬಳಸುವಾಗ, ನೀವು ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಶನ್ ತತ್ವವನ್ನು ಅನುಸರಿಸಬೇಕು ಮತ್ತು ಪಾತ್ರದಲ್ಲಿ ಅಥವಾ ಪ್ರಸ್ತುತವು ಅವಲಂಬಿಸಿರುವ ಪಾತ್ರಗಳಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ಅಸ್ಥಿರಗಳನ್ನು ಬಳಸಬೇಕು.
-
ಅಸ್ಥಿರಗಳಿಗಾಗಿ ನಿಘಂಟುಗಳನ್ನು ಬಳಸುವುದನ್ನು ತಪ್ಪಿಸಿ. ನಿಘಂಟಿನಲ್ಲಿ ವೈಯಕ್ತಿಕ ಮೌಲ್ಯಗಳನ್ನು ಅನುಕೂಲಕರವಾಗಿ ಅತಿಕ್ರಮಿಸಲು ಅನ್ಸಿಬಲ್ ನಿಮಗೆ ಅನುಮತಿಸುವುದಿಲ್ಲ.
ಕೆಟ್ಟ ವೇರಿಯಬಲ್ನ ಉದಾಹರಣೆ:
myrole_user: login: admin password: adminಇಲ್ಲಿ ಲಾಗಿನ್ ಸ್ವತಂತ್ರ ವೇರಿಯೇಬಲ್ ಮತ್ತು ಪಾಸ್ವರ್ಡ್ ಅವಲಂಬಿತ ವೇರಿಯಬಲ್ ಆಗಿದೆ. ಆದರೆ
ಅವುಗಳನ್ನು ನಿಘಂಟಿನಲ್ಲಿ ಸಂಯೋಜಿಸಿರುವುದರಿಂದ, ನೀವು ಅದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಬೇಕಾಗುತ್ತದೆ
ಯಾವಾಗಲೂ. ಇದು ತುಂಬಾ ಅನಾನುಕೂಲವಾಗಿದೆ. ಈ ರೀತಿಯಲ್ಲಿ ಉತ್ತಮ:myrole_user_login: admin myrole_user_password: admin
ನಿಯೋಜನೆ ಪ್ಲೇಬುಕ್‌ಗಳಲ್ಲಿನ ವೇರಿಯೇಬಲ್‌ಗಳು
ನಿಯೋಜನೆ ಪ್ಲೇಬುಕ್ ಅನ್ನು ಕಂಪೈಲ್ ಮಾಡುವಾಗ (ಇನ್ನು ಮುಂದೆ ಪ್ಲೇಬುಕ್ ಎಂದು ಉಲ್ಲೇಖಿಸಲಾಗುತ್ತದೆ), ಅದನ್ನು ಪ್ರತ್ಯೇಕ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಇರಿಸಬೇಕೆಂಬ ನಿಯಮಕ್ಕೆ ನಾವು ಬದ್ಧರಾಗಿದ್ದೇವೆ. ಪಾತ್ರಗಳಂತೆಯೇ: ಪ್ರತಿಯೊಂದೂ ತನ್ನದೇ ಆದ ಜಿಟ್ ರೆಪೊಸಿಟರಿಯಲ್ಲಿದೆ. ಪಾತ್ರಗಳು ಮತ್ತು ಪ್ಲೇಬುಕ್ ನಿಯೋಜನೆ ವ್ಯವಸ್ಥೆಯ ವಿಭಿನ್ನ ಸ್ವತಂತ್ರ ವಸ್ತುಗಳು ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ ಮತ್ತು ಒಂದು ವಸ್ತುವಿನ ಬದಲಾವಣೆಗಳು ಇನ್ನೊಂದರ ಕಾರ್ಯಾಚರಣೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಬಾರದು. ಅಸ್ಥಿರಗಳ ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯಗಳನ್ನು ಬದಲಾಯಿಸುವ ಮೂಲಕ ಇದನ್ನು ಸಾಧಿಸಲಾಗುತ್ತದೆ.
ಪ್ಲೇಬುಕ್ ಅನ್ನು ಕಂಪೈಲ್ ಮಾಡುವಾಗ, ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಹೇಳುವುದಾದರೆ, ರೋಲ್ ಅಸ್ಥಿರಗಳ ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯಗಳನ್ನು ಎರಡು ಸ್ಥಳಗಳಲ್ಲಿ ಅತಿಕ್ರಮಿಸಲು ಸಾಧ್ಯವಿದೆ: ಪ್ಲೇಬುಕ್ ಅಸ್ಥಿರಗಳಲ್ಲಿ ಮತ್ತು ಇನ್ವೆಂಟರಿ ಅಸ್ಥಿರಗಳಲ್ಲಿ.
mydeploy # Каталог деплоя
├── deploy.yml # Плейбук деплоя
├── group_vars # Каталог переменных плейбука
│ ├── all.yml # Файл для переменных связи всей системы
│ └── myapi.yml # Файл переменных свойств группы myapi
└── inventories #
└── prod # Каталог окружения prod
├── prod.ini # Инвентори файл
└── group_vars # Каталог для переменных инвентори
└── myapi #
├── vars.yml # Средозависимые переменные группы myapi
└── vault.yml # Секреты (всегда средозависимы) ** -
ವ್ಯತ್ಯಾಸವೆಂದರೆ ಪ್ಲೇಬುಕ್ ವೇರಿಯಬಲ್‌ಗಳನ್ನು ಯಾವಾಗಲೂ ಅದೇ ಮಟ್ಟದಲ್ಲಿ ಪ್ಲೇಬುಕ್‌ಗಳನ್ನು ಕರೆಯುವಾಗ ಬಳಸಲಾಗುತ್ತದೆ. ಇದರರ್ಥ ಪರಿಸರ-ಸ್ವತಂತ್ರ ಅಸ್ಥಿರಗಳ ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯಗಳನ್ನು ಬದಲಾಯಿಸಲು ಈ ಅಸ್ಥಿರಗಳು ಉತ್ತಮವಾಗಿವೆ. ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ, ಇನ್ವೆಂಟರಿ ಅಸ್ಥಿರಗಳನ್ನು ನಿರ್ದಿಷ್ಟ ಪರಿಸರಕ್ಕೆ ಮಾತ್ರ ಬಳಸಲಾಗುತ್ತದೆ, ಇದು ಪರಿಸರ-ನಿರ್ದಿಷ್ಟ ವೇರಿಯಬಲ್‌ಗಳಿಗೆ ಸೂಕ್ತವಾಗಿದೆ.
ವೇರಿಯಬಲ್ ಆದ್ಯತೆಯು ಪ್ಲೇಬುಕ್ ವೇರಿಯೇಬಲ್‌ಗಳಲ್ಲಿ ಮತ್ತು ನಂತರ ಪ್ರತ್ಯೇಕವಾಗಿ ಒಂದು ದಾಸ್ತಾನುಗಳಲ್ಲಿ ವೇರಿಯೇಬಲ್‌ಗಳನ್ನು ಅತಿಕ್ರಮಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ಗಮನಿಸುವುದು ಮುಖ್ಯವಾಗಿದೆ.
ಇದರರ್ಥ ಈಗಾಗಲೇ ಈ ಹಂತದಲ್ಲಿ ವೇರಿಯೇಬಲ್ ಪರಿಸರ-ಅವಲಂಬಿತವಾಗಿದೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಲು ಮತ್ತು ಅದನ್ನು ಸೂಕ್ತವಾದ ಸ್ಥಳದಲ್ಲಿ ಇರಿಸಲು ಅವಶ್ಯಕವಾಗಿದೆ.
ಉದಾಹರಣೆಗೆ, ಒಂದು ಯೋಜನೆಯಲ್ಲಿ, SSL ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲು ಜವಾಬ್ದಾರರಾಗಿರುವ ವೇರಿಯೇಬಲ್ ದೀರ್ಘಕಾಲದವರೆಗೆ ಪರಿಸರ-ಅವಲಂಬಿತವಾಗಿದೆ, ಏಕೆಂದರೆ ಸ್ಟ್ಯಾಂಡ್‌ಗಳಲ್ಲಿ ನಮ್ಮ ನಿಯಂತ್ರಣಕ್ಕೆ ಮೀರಿದ ಕಾರಣಗಳಿಗಾಗಿ ನಾವು SSL ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ನಾವು ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಿದ ನಂತರ, ಅದು ಪರಿಸರ ಸ್ವತಂತ್ರವಾಯಿತು ಮತ್ತು ಪ್ಲೇಬುಕ್ ವೇರಿಯೇಬಲ್‌ಗಳಿಗೆ ಸರಿಸಲಾಗಿದೆ.
ಗುಂಪುಗಳಿಗೆ ಆಸ್ತಿ ಅಸ್ಥಿರ
ವಿಭಿನ್ನ ಜಾವಾ ಅಪ್ಲಿಕೇಶನ್‌ನೊಂದಿಗೆ 1 ಗುಂಪುಗಳ ಸರ್ವರ್‌ಗಳನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ಚಿತ್ರ 2 ರಲ್ಲಿ ನಮ್ಮ ಮಾದರಿಯನ್ನು ವಿಸ್ತರಿಸೋಣ, ಆದರೆ ವಿಭಿನ್ನ ಸೆಟ್ಟಿಂಗ್‌ಗಳೊಂದಿಗೆ.
ಈ ಸಂದರ್ಭದಲ್ಲಿ ಪ್ಲೇಬುಕ್ ಹೇಗಿರುತ್ತದೆ ಎಂದು ಊಹಿಸೋಣ:
- hosts: myapi
roles:
- api
- hosts: bbauth
roles:
- auth
- hosts: ghauth
roles:
- authನಾವು ಪ್ಲೇಬುಕ್‌ನಲ್ಲಿ ಮೂರು ಗುಂಪುಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಆದ್ದರಿಂದ group_vars ಇನ್ವೆಂಟರಿ ವೇರಿಯೇಬಲ್‌ಗಳು ಮತ್ತು ಪ್ಲೇಬುಕ್ ವೇರಿಯೇಬಲ್‌ಗಳಲ್ಲಿ ಒಂದೇ ಸಂಖ್ಯೆಯ ಗುಂಪು ಫೈಲ್‌ಗಳನ್ನು ರಚಿಸಲು ತಕ್ಷಣವೇ ಶಿಫಾರಸು ಮಾಡಲಾಗುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ ಒಂದು ಗುಂಪಿನ ಫೈಲ್ ಪ್ಲೇಬುಕ್‌ನಲ್ಲಿ ಮೇಲಿನ ಅಪ್ಲಿಕೇಶನ್‌ನ ಒಂದು ಅಂಶದ ವಿವರಣೆಯಾಗಿದೆ. ನೀವು ಪ್ಲೇಬುಕ್ ವೇರಿಯೇಬಲ್‌ಗಳಲ್ಲಿ ಗುಂಪು ಫೈಲ್ ಅನ್ನು ತೆರೆದಾಗ, ಗುಂಪಿನಲ್ಲಿ ಸ್ಥಾಪಿಸಲಾದ ಪಾತ್ರಗಳ ಡೀಫಾಲ್ಟ್ ನಡವಳಿಕೆಯಿಂದ ಎಲ್ಲಾ ವ್ಯತ್ಯಾಸಗಳನ್ನು ನೀವು ತಕ್ಷಣ ನೋಡುತ್ತೀರಿ. ಇನ್ವೆಂಟರಿ ವೇರಿಯಬಲ್‌ಗಳಲ್ಲಿ: ಸ್ಟ್ಯಾಂಡ್‌ನಿಂದ ಸ್ಟ್ಯಾಂಡ್‌ಗೆ ಗುಂಪಿನ ವರ್ತನೆಯಲ್ಲಿ ವ್ಯತ್ಯಾಸಗಳು.
ಕೋಡ್ ಶೈಲಿ
- host_vars ವೇರಿಯೇಬಲ್‌ಗಳನ್ನು ಬಳಸದಿರಲು ಪ್ರಯತ್ನಿಸಿ, ಏಕೆಂದರೆ ಅವು ಸಿಸ್ಟಮ್ ಅನ್ನು ವಿವರಿಸುವುದಿಲ್ಲ, ಆದರೆ ಒಂದು ವಿಶೇಷ ಪ್ರಕರಣ ಮಾತ್ರ, ಇದು ಭವಿಷ್ಯದಲ್ಲಿ ಪ್ರಶ್ನೆಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ: “ಈ ಹೋಸ್ಟ್ ಇತರರಿಂದ ಏಕೆ ಭಿನ್ನವಾಗಿದೆ?”, ಅದಕ್ಕೆ ಉತ್ತರ ಅಲ್ಲ ಹುಡುಕಲು ಯಾವಾಗಲೂ ಸುಲಭ.
ಸಂವಹನ ಅಸ್ಥಿರ
ಆದಾಗ್ಯೂ, ಆಸ್ತಿ ಅಸ್ಥಿರಗಳ ಬಗ್ಗೆ ಏನು, ಆದರೆ ಸಂವಹನ ಅಸ್ಥಿರಗಳ ಬಗ್ಗೆ ಏನು?
ಅವರ ವ್ಯತ್ಯಾಸವೆಂದರೆ ಅವರು ವಿಭಿನ್ನ ಗುಂಪುಗಳಲ್ಲಿ ಒಂದೇ ಅರ್ಥವನ್ನು ಹೊಂದಿರಬೇಕು.
ಮೊದಲಿಗೆ ಅದು ಆಗಿತ್ತು ಅಂತಹ ದೈತ್ಯಾಕಾರದ ನಿರ್ಮಾಣವನ್ನು ಬಳಸಿ:
hostvars[groups['bbauth'][0]]['auth_bind_port'], ಆದರೆ ಅವರು ತಕ್ಷಣ ಅದನ್ನು ತಿರಸ್ಕರಿಸಿದರು
ಏಕೆಂದರೆ ಇದು ಅನಾನುಕೂಲಗಳನ್ನು ಹೊಂದಿದೆ. ಮೊದಲನೆಯದಾಗಿ, ಬೃಹತ್ತನ. ಎರಡನೆಯದಾಗಿ, ಗುಂಪಿನಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ಹೋಸ್ಟ್ ಮೇಲೆ ಅವಲಂಬನೆ. ಮೂರನೆಯದಾಗಿ, ನಿಯೋಜನೆಯನ್ನು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು, ನಾವು ವಿವರಿಸಲಾಗದ ವೇರಿಯಬಲ್ನ ದೋಷವನ್ನು ಪಡೆಯಲು ಬಯಸದಿದ್ದರೆ ಎಲ್ಲಾ ಹೋಸ್ಟ್‌ಗಳಿಂದ ಸಂಗತಿಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದು ಅವಶ್ಯಕ.
ಪರಿಣಾಮವಾಗಿ, ಸಂವಹನ ಅಸ್ಥಿರಗಳನ್ನು ಬಳಸಲು ನಿರ್ಧರಿಸಲಾಯಿತು.
ಸಂವಹನ ಅಸ್ಥಿರ - ಇವು ಪ್ಲೇಬುಕ್‌ಗೆ ಸೇರಿದ ವೇರಿಯಬಲ್‌ಗಳಾಗಿವೆ ಮತ್ತು ಸಿಸ್ಟಮ್ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಸಂಪರ್ಕಿಸಲು ಅಗತ್ಯವಿದೆ.
ಸಂವಹನ ಅಸ್ಥಿರಗಳು ಸಾಮಾನ್ಯ ಸಿಸ್ಟಮ್ ವೇರಿಯೇಬಲ್‌ಗಳಲ್ಲಿ ಜನಪ್ರಿಯವಾಗಿವೆ group_vars/all/vars ಮತ್ತು ಪ್ರತಿ ಗುಂಪಿನಿಂದ ಎಲ್ಲಾ ಕೇಳುಗ ವೇರಿಯೇಬಲ್‌ಗಳನ್ನು ತೆಗೆದುಹಾಕುವ ಮೂಲಕ ಮತ್ತು ವೇರಿಯಬಲ್ನ ಪ್ರಾರಂಭಕ್ಕೆ ಕೇಳುಗನನ್ನು ತೆಗೆದುಹಾಕಲಾದ ಗುಂಪಿನ ಹೆಸರನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ರಚಿಸಲಾಗಿದೆ.
ಇದು ಹೆಸರುಗಳ ಏಕರೂಪತೆ ಮತ್ತು ಅತಿಕ್ರಮಿಸದಿರುವುದನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ.
ಮೇಲಿನ ಉದಾಹರಣೆಯಿಂದ ಅಸ್ಥಿರಗಳನ್ನು ಬಂಧಿಸಲು ಪ್ರಯತ್ನಿಸೋಣ:
ನಾವು ಪರಸ್ಪರ ಅವಲಂಬಿಸಿರುವ ಅಸ್ಥಿರಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ಊಹಿಸೋಣ:
# roles/api/defaults:
# Переменная запроса
api_auth1_address: "http://example.com:80"
api_auth2_address: "http://example2.com:80"
# roles/auth/defaults:
# Переменная слушатель
auth_bind_port: "20000"ಅದನ್ನು ಸಾಮಾನ್ಯ ವೇರಿಯೇಬಲ್‌ಗಳಾಗಿ ಇಡೋಣ group_vars/all/vars ಎಲ್ಲಾ ಕೇಳುಗರು, ಮತ್ತು ಗುಂಪಿನ ಹೆಸರನ್ನು ಶೀರ್ಷಿಕೆಗೆ ಸೇರಿಸಿ:
# group_vars/all/vars
bbauth_auth_bind_port: "20000"
ghauth_auth_bind_port: "30000"
# group_vars/bbauth/vars
auth_bind_port: "{{ bbauth_auth_bind_port }}"
# group_vars/ghauth/vars
auth_bind_port: "{{ ghauth_auth_bind_port }}"
# group_vars/myapi/vars
api_auth1_address: "http://{{ bbauth_auth_service_name }}:{{ bbauth_auth_bind_port }}"
api_auth2_address: "http://{{ ghauth_auth_service_name }}:{{ ghauth_auth_bind_port }}"ಈಗ, ಕನೆಕ್ಟರ್‌ನ ಮೌಲ್ಯವನ್ನು ಬದಲಾಯಿಸುವ ಮೂಲಕ, ವಿನಂತಿಯು ಪೋರ್ಟ್ ಇರುವ ಅದೇ ಸ್ಥಳಕ್ಕೆ ಹೋಗುತ್ತದೆ ಎಂದು ನಾವು ಖಚಿತವಾಗಿರುತ್ತೇವೆ.
ಕೋಡ್ ಶೈಲಿ
- ಪಾತ್ರಗಳು ಮತ್ತು ಗುಂಪುಗಳು ವಿಭಿನ್ನ ಸಿಸ್ಟಮ್ ಆಬ್ಜೆಕ್ಟ್‌ಗಳಾಗಿರುವುದರಿಂದ, ಅವು ವಿಭಿನ್ನ ಹೆಸರುಗಳನ್ನು ಹೊಂದಿರಬೇಕು, ನಂತರ ಲಿಂಕ್ ವೇರಿಯಬಲ್‌ಗಳು ಅವು ನಿರ್ದಿಷ್ಟ ಸರ್ವರ್‌ಗಳ ಗುಂಪಿಗೆ ಸೇರಿವೆ ಎಂದು ನಿಖರವಾಗಿ ಸೂಚಿಸುತ್ತವೆ ಮತ್ತು ಸಿಸ್ಟಮ್‌ನಲ್ಲಿನ ಪಾತ್ರಕ್ಕೆ ಅಲ್ಲ.
ಪರಿಸರ ಅವಲಂಬಿತ ಕಡತಗಳು
ಪಾತ್ರಗಳು ಪರಿಸರದಿಂದ ಪರಿಸರಕ್ಕೆ ಭಿನ್ನವಾಗಿರುವ ಫೈಲ್‌ಗಳನ್ನು ಬಳಸಬಹುದು.
ಅಂತಹ ಫೈಲ್‌ಗಳ ಉದಾಹರಣೆಯೆಂದರೆ SSL ಪ್ರಮಾಣಪತ್ರಗಳು. ಅವುಗಳನ್ನು ಪಠ್ಯ ರೂಪದಲ್ಲಿ ಸಂಗ್ರಹಿಸಿ
ವೇರಿಯೇಬಲ್ನಲ್ಲಿ ತುಂಬಾ ಅನುಕೂಲಕರವಾಗಿಲ್ಲ. ಆದರೆ ವೇರಿಯೇಬಲ್ ಒಳಗೆ ಅವರಿಗೆ ಮಾರ್ಗವನ್ನು ಸಂಗ್ರಹಿಸಲು ಅನುಕೂಲಕರವಾಗಿದೆ.
ಉದಾಹರಣೆಗೆ, ನಾವು ವೇರಿಯೇಬಲ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ api_ssl_key_file: "/path/to/file".
ಕೀ ಪ್ರಮಾಣಪತ್ರವು ಪರಿಸರದಿಂದ ಪರಿಸರಕ್ಕೆ ಬದಲಾಗುತ್ತದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿರುವುದರಿಂದ, ಇದು ಪರಿಸರ-ಅವಲಂಬಿತ ವೇರಿಯಬಲ್ ಆಗಿದೆ, ಅಂದರೆ ಅದು ಫೈಲ್‌ನಲ್ಲಿ ಇರಬೇಕು
group_vars/myapi/vars ವೇರಿಯೇಬಲ್‌ಗಳ ದಾಸ್ತಾನು, ಮತ್ತು 'ಉದಾಹರಣೆಗೆ' ಮೌಲ್ಯವನ್ನು ಹೊಂದಿರುತ್ತದೆ.
ಈ ಸಂದರ್ಭದಲ್ಲಿ ಅತ್ಯಂತ ಅನುಕೂಲಕರ ಮಾರ್ಗವೆಂದರೆ ಕೀ ಫೈಲ್ ಅನ್ನು ಪ್ಲೇಬುಕ್ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಹಾದಿಯಲ್ಲಿ ಹಾಕುವುದು
files/prod/certs/myapi.key, ನಂತರ ವೇರಿಯೇಬಲ್ನ ಮೌಲ್ಯವು ಹೀಗಿರುತ್ತದೆ:
api_ssl_key_file: "prod/certs/myapi.key". ನಿರ್ದಿಷ್ಟ ಸ್ಟ್ಯಾಂಡ್‌ನಲ್ಲಿ ಸಿಸ್ಟಮ್ ಅನ್ನು ನಿಯೋಜಿಸಲು ಜವಾಬ್ದಾರರಾಗಿರುವ ಜನರು ತಮ್ಮ ಫೈಲ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ತಮ್ಮದೇ ಆದ ಮೀಸಲಾದ ಸ್ಥಳವನ್ನು ಹೊಂದಿದ್ದಾರೆ ಎಂಬ ಅಂಶದಲ್ಲಿ ಅನುಕೂಲತೆ ಇರುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಮತ್ತೊಂದು ವ್ಯವಸ್ಥೆಯಿಂದ ಪೂರೈಸಿದರೆ, ಸರ್ವರ್‌ನಲ್ಲಿ ಪ್ರಮಾಣಪತ್ರಕ್ಕೆ ಸಂಪೂರ್ಣ ಮಾರ್ಗವನ್ನು ಸೂಚಿಸಲು ಸಾಧ್ಯವಿದೆ.
ಒಂದು ಪರಿಸರದಲ್ಲಿ ಬಹು ನಿಂತಿದೆ
ಸಾಮಾನ್ಯವಾಗಿ ಒಂದೇ ಪರಿಸರದಲ್ಲಿ ಕನಿಷ್ಠ ವ್ಯತ್ಯಾಸಗಳೊಂದಿಗೆ ಹಲವಾರು ಒಂದೇ ರೀತಿಯ ಸ್ಟ್ಯಾಂಡ್‌ಗಳನ್ನು ನಿಯೋಜಿಸುವ ಅವಶ್ಯಕತೆಯಿದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಪರಿಸರ-ಅವಲಂಬಿತ ಅಸ್ಥಿರಗಳನ್ನು ಈ ಪರಿಸರದಲ್ಲಿ ಬದಲಾಗದ ಮತ್ತು ಬದಲಾಗುವವುಗಳಾಗಿ ವಿಂಗಡಿಸುತ್ತೇವೆ. ಮತ್ತು ನಾವು ಎರಡನೆಯದನ್ನು ನೇರವಾಗಿ ದಾಸ್ತಾನು ಫೈಲ್‌ಗಳಿಗೆ ವರ್ಗಾಯಿಸುತ್ತೇವೆ. ಈ ಕುಶಲತೆಯ ನಂತರ, ಪರಿಸರ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ನೇರವಾಗಿ ಮತ್ತೊಂದು ದಾಸ್ತಾನು ರಚಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
ಇದು group_vars ಇನ್ವೆಂಟರಿಯನ್ನು ಮರುಬಳಕೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಕೆಲವು ವೇರಿಯೇಬಲ್‌ಗಳನ್ನು ನೇರವಾಗಿ ಸ್ವತಃ ಮರು ವ್ಯಾಖ್ಯಾನಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
ನಿಯೋಜನೆ ಯೋಜನೆಗಾಗಿ ಅಂತಿಮ ಡೈರೆಕ್ಟರಿ ರಚನೆ:
mydeploy # Каталог деплоя
├── deploy.yml # Плейбук деплоя
├── files # Каталог для файлов деплоя
│ ├── prod # Католог для средозависимых файлов стенда prod
│ │ └── certs #
│ │ └── myapi.key #
│ └── test1 # Каталог для средозависимых файлов стенда test1
├── group_vars # Каталог переменных плейбука
│ ├── all.yml # Файл для переменных связи всей системы
│ ├── myapi.yml # Файл переменных свойств группы myapi
│ ├── bbauth.yml #
│ └── ghauth.yml #
└── inventories #
├── prod # Каталог окружения prod
│ ├── group_vars # Каталог для переменных инвентори
│ │ ├── myapi #
│ │ │ ├── vars.yml # Средозависимые переменные группы myapi
│ │ │ └── vault.yml # Секреты (всегда средозависимы)
│ │ ├── bbauth #
│ │ │ ├── vars.yml #
│ │ │ └── vault.yml #
│ │ └── ghauth #
│ │ ├── vars.yml #
│ │ └── vault.yml #
│ └── prod.ini # Инвентори стенда prod
└── test # Каталог окружения test
├── group_vars #
│ ├── myapi #
│ │ ├── vars.yml #
│ │ └── vault.yml #
│ ├── bbauth #
│ │ ├── vars.yml #
│ │ └── vault.yml #
│ └── ghauth #
│ ├── vars.yml #
│ └── vault.yml #
├── test1.ini # Инвентори стенда test1 в среде test
└── test2.ini # Инвентори стенда test2 в среде testಒಟ್ಟುಗೂಡಿಸಲಾಗುತ್ತಿದೆ
ಲೇಖನಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಅಸ್ಥಿರಗಳನ್ನು ಸಂಘಟಿಸಿದ ನಂತರ: ಪ್ರತಿ ವೇರಿಯಬಲ್ ಫೈಲ್ ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯಕ್ಕೆ ಕಾರಣವಾಗಿದೆ. ಮತ್ತು ಫೈಲ್ ಕೆಲವು ಕಾರ್ಯಗಳನ್ನು ಹೊಂದಿರುವುದರಿಂದ, ಪ್ರತಿ ಫೈಲ್‌ನ ನಿಖರತೆಗೆ ಜವಾಬ್ದಾರರಾಗಿರುವ ಯಾರನ್ನಾದರೂ ನಿಯೋಜಿಸಲು ಸಾಧ್ಯವಾಯಿತು. ಉದಾಹರಣೆಗೆ, ಪ್ಲೇಬುಕ್ ವೇರಿಯೇಬಲ್‌ಗಳ ಸರಿಯಾದ ಭರ್ತಿಗೆ ಸಿಸ್ಟಮ್ ನಿಯೋಜನೆಯ ಡೆವಲಪರ್ ಜವಾಬ್ದಾರನಾಗುತ್ತಾನೆ, ಆದರೆ ಇನ್ವೆಂಟರಿಯಲ್ಲಿ ವಿವರಿಸಲಾದ ನಿರ್ವಾಹಕರು ಅಸ್ಥಿರಗಳ ದಾಸ್ತಾನುಗಳನ್ನು ಭರ್ತಿ ಮಾಡಲು ನೇರವಾಗಿ ಜವಾಬ್ದಾರರಾಗಿರುತ್ತಾರೆ.
ಪಾತ್ರಗಳು ತಮ್ಮದೇ ಆದ ಇಂಟರ್‌ಫೇಸ್‌ನೊಂದಿಗೆ ತಮ್ಮದೇ ಆದ ಅಭಿವೃದ್ಧಿ ಘಟಕವಾಗಿ ಮಾರ್ಪಟ್ಟವು, ರೋಲ್ ಡೆವಲಪರ್‌ಗೆ ಪಾತ್ರವನ್ನು ವ್ಯವಸ್ಥೆಗೆ ತಕ್ಕಂತೆ ಮಾಡುವ ಬದಲು ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಈ ಸಮಸ್ಯೆಯು ವಿಶೇಷವಾಗಿ ಪ್ರಚಾರದಲ್ಲಿ ಎಲ್ಲಾ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ಸಾಮಾನ್ಯ ಪಾತ್ರಗಳಿಗೆ ಸಂಬಂಧಿಸಿದೆ.
ಸಿಸ್ಟಂ ನಿರ್ವಾಹಕರು ಇನ್ನು ಮುಂದೆ ನಿಯೋಜನೆ ಕೋಡ್ ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕಾಗಿಲ್ಲ. ಯಶಸ್ವಿ ನಿಯೋಜನೆಗಾಗಿ ಅವರಿಗೆ ಬೇಕಾಗಿರುವುದು ಪರಿಸರ-ಅವಲಂಬಿತ ವೇರಿಯಬಲ್‌ಗಳ ಫೈಲ್‌ಗಳನ್ನು ಭರ್ತಿ ಮಾಡುವುದು.
ಸಾಹಿತ್ಯ
ಲೇಖಕ
ಕಲ್ಯುಜ್ನಿ ಡೆನಿಸ್ ಅಲೆಕ್ಸಾಂಡ್ರೊವಿಚ್
ಮೂಲ: www.habr.com