ಅಪ್ಲಿಕೇಶನ್ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ನೀಲಿ-ಹಸಿರು ನಿಯೋಜನೆ, php ಮತ್ತು ಡಾಕರ್‌ನಲ್ಲಿ ಉದಾಹರಣೆಗಳೊಂದಿಗೆ ಟ್ವೆಲ್ವ್-ಫ್ಯಾಕ್ಟರ್ ಅಪ್ಲಿಕೇಶನ್ ವಿಧಾನವನ್ನು ಆಧರಿಸಿದೆ

ಮೊದಲಿಗೆ, ಸ್ವಲ್ಪ ಸಿದ್ಧಾಂತ. ಏನಾಯಿತು ಹನ್ನೆರಡು ಅಂಶಗಳ ಅಪ್ಲಿಕೇಶನ್?

ಸರಳವಾಗಿ ಹೇಳುವುದಾದರೆ, ಈ ಡಾಕ್ಯುಮೆಂಟ್ ಅನ್ನು SaaS ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಅಭಿವೃದ್ಧಿಯನ್ನು ಸರಳೀಕರಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ, ಆಧುನಿಕ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಹೆಚ್ಚಾಗಿ ಎದುರಾಗುವ ಸಮಸ್ಯೆಗಳು ಮತ್ತು ಅಭ್ಯಾಸಗಳ ಕುರಿತು ಡೆವಲಪರ್‌ಗಳು ಮತ್ತು DevOps ಎಂಜಿನಿಯರ್‌ಗಳಿಗೆ ತಿಳಿಸುವ ಮೂಲಕ ಸಹಾಯ ಮಾಡುತ್ತದೆ.

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

ಹನ್ನೆರಡು ಅಂಶಗಳ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಯಾವುದೇ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯಲ್ಲಿ ಬರೆಯಲಾದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಅನ್ವಯಿಸಬಹುದು ಮತ್ತು ಯಾವುದೇ ಬ್ಯಾಕಿಂಗ್ ಸೇವೆಗಳ ಸಂಯೋಜನೆಯನ್ನು ಬಳಸಬಹುದಾಗಿದೆ (ಡೇಟಾಬೇಸ್‌ಗಳು, ಸಂದೇಶ ಸರತಿಗಳು, ಸಂಗ್ರಹಗಳು, ಇತ್ಯಾದಿ.).

ಈ ವಿಧಾನವನ್ನು ಆಧರಿಸಿದ ಅಂಶಗಳ ಬಗ್ಗೆ ಸಂಕ್ಷಿಪ್ತವಾಗಿ:

1. ಕೋಡ್ಬೇಸ್ - ಆವೃತ್ತಿ ನಿಯಂತ್ರಣದಲ್ಲಿ ಒಂದು ಕೋಡ್‌ಬೇಸ್ ಅನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲಾಗಿದೆ - ಬಹು ನಿಯೋಜನೆಗಳು
2. ಅವಲಂಬನೆಗಳು - ಅವಲಂಬನೆಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಘೋಷಿಸಿ ಮತ್ತು ಪ್ರತ್ಯೇಕಿಸಿ
3. ಸಂರಚನೆ - ರನ್ಟೈಮ್ನಲ್ಲಿ ಸಂರಚನೆಯನ್ನು ಉಳಿಸಿ
4. ಬ್ಯಾಕಿಂಗ್ ಸೇವೆಗಳು - ಬ್ಯಾಕಿಂಗ್ ಸೇವೆಗಳನ್ನು ಪ್ಲಗ್-ಇನ್ ಸಂಪನ್ಮೂಲಗಳಾಗಿ ಪರಿಗಣಿಸಿ
5. ನಿರ್ಮಿಸಿ, ಬಿಡುಗಡೆ ಮಾಡಿ, ಓಡಿಸಿ - ಜೋಡಣೆ ಮತ್ತು ಮರಣದಂಡನೆ ಹಂತಗಳನ್ನು ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಪ್ರತ್ಯೇಕಿಸಿ
6. ಪ್ರಕ್ರಿಯೆಗಳು - ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ ಸ್ಥಿತಿಯಿಲ್ಲದ ಪ್ರಕ್ರಿಯೆಗಳಾಗಿ ರನ್ ಮಾಡಿ
7. ಪೋರ್ಟ್ ಬೈಂಡಿಂಗ್ - ಪೋರ್ಟ್ ಬೈಂಡಿಂಗ್ ಮೂಲಕ ಸೇವೆಗಳನ್ನು ರಫ್ತು ಮಾಡಿ
8. ಸಮಾನಾಂತರತೆ - ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಬಳಸಿಕೊಂಡು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಅಳೆಯಿರಿ
9. ವಿಲೇವಾರಿ - ವೇಗದ ಪ್ರಾರಂಭ ಮತ್ತು ಕ್ಲೀನ್ ಶಟ್‌ಡೌನ್‌ನೊಂದಿಗೆ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಹೆಚ್ಚಿಸಿ
10. ಅಪ್ಲಿಕೇಶನ್ ಅಭಿವೃದ್ಧಿ/ಕಾರ್ಯಾಚರಣೆ ಸಮಾನತೆ - ನಿಮ್ಮ ಅಭಿವೃದ್ಧಿ, ವೇದಿಕೆ ಮತ್ತು ಉತ್ಪಾದನಾ ಪರಿಸರವನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಒಂದೇ ರೀತಿ ಇರಿಸಿ
11. ಲಾಗಿಂಗ್ - ಲಾಗ್ ಅನ್ನು ಘಟನೆಗಳ ಸ್ಟ್ರೀಮ್ ಆಗಿ ವೀಕ್ಷಿಸಿ
12. ಆಡಳಿತ ಕಾರ್ಯಗಳು - ತಾತ್ಕಾಲಿಕ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಆಡಳಿತ/ನಿರ್ವಹಣೆ ಕಾರ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸಿ

ಕೆಳಗಿನ ಸಂಪನ್ಮೂಲಗಳಿಂದ ನೀವು 12 ಅಂಶಗಳ ಕುರಿತು ಹೆಚ್ಚಿನ ಮಾಹಿತಿಯನ್ನು ಪಡೆಯಬಹುದು:

• ಅಧಿಕೃತ ಮೂಲ - ಓದಲೇಬೇಕು
• ಹಬರ್ ಕುರಿತು ಲೇಖನ. ಹನ್ನೆರಡು ಅಂಶಗಳ ಅಪ್ಲಿಕೇಶನ್ - ಅಧಿಕೃತ ಅನುವಾದ
• ಹಬರ್ ಕುರಿತು ಲೇಖನ. 7 ಅಂಶಗಳ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ 12 ಕಾಣೆಯಾದ ಅಂಶಗಳು - ಅವುಗಳನ್ನು ಸುಧಾರಿಸುವ ಗುರಿಯೊಂದಿಗೆ 12 ಅಂಶಗಳ ಹೊಸ ನೋಟ.

ನೀಲಿ-ಹಸಿರು ನಿಯೋಜನೆ ಎಂದರೇನು?

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

ಕ್ಲಾಸಿಕ್ ಬಿಜಿ ಡಿಪ್ಲೋಯ್ ಸ್ಕೀಮ್ ಕೆಳಗಿನ ಚಿತ್ರದಲ್ಲಿ ತೋರಿಸಿರುವಂತೆ ಕಾಣುತ್ತದೆ.

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

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

ಕೆಟ್ಟ ಮತ್ತು ಒಳ್ಳೆಯ ಸಲಹೆ

ಹಕ್ಕುತ್ಯಾಗ: ಕೆಳಗಿನ ಉದಾಹರಣೆಗಳು ನಾನು ಬಳಸುವ ಉಪಯುಕ್ತತೆಗಳು/ವಿಧಾನಗಳನ್ನು ತೋರಿಸುತ್ತವೆ, ನೀವು ಒಂದೇ ರೀತಿಯ ಕಾರ್ಯಗಳನ್ನು ಹೊಂದಿರುವ ಯಾವುದೇ ಪರ್ಯಾಯಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬಳಸಬಹುದು.

ಹೆಚ್ಚಿನ ಉದಾಹರಣೆಗಳು ಒಂದು ರೀತಿಯಲ್ಲಿ ಅಥವಾ ಇನ್ನೊಂದು ರೀತಿಯಲ್ಲಿ ವೆಬ್ ಅಭಿವೃದ್ಧಿಯೊಂದಿಗೆ ಛೇದಿಸುತ್ತವೆ (ಇದು ಆಶ್ಚರ್ಯಕರವಾಗಿದೆ), PHP ಮತ್ತು ಡಾಕರ್‌ನೊಂದಿಗೆ.

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

1. ಕೋಡ್ಬೇಸ್

ಒಂದು ಸಮಯದಲ್ಲಿ ಸರ್ವರ್‌ಗಳಿಗೆ ಫೈಲ್‌ಗಳನ್ನು ಅಪ್‌ಲೋಡ್ ಮಾಡಲು FTP ಮತ್ತು FileZilla ಅನ್ನು ಬಳಸಿ, ಉತ್ಪಾದನಾ ಸರ್ವರ್‌ನಲ್ಲಿ ಹೊರತುಪಡಿಸಿ ಬೇರೆಲ್ಲಿಯೂ ಕೋಡ್ ಅನ್ನು ಸಂಗ್ರಹಿಸಬೇಡಿ.

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

2. ಅವಲಂಬನೆಗಳು

ಫೋಲ್ಡರ್‌ಗಳಲ್ಲಿನ ಎಲ್ಲಾ ಲೈಬ್ರರಿಗಳನ್ನು ನೇರವಾಗಿ ಯೋಜನೆಯ ಮೂಲಕ್ಕೆ ಡೌನ್‌ಲೋಡ್ ಮಾಡಿ. ಲೈಬ್ರರಿಯ ಪ್ರಸ್ತುತ ಆವೃತ್ತಿಯೊಂದಿಗೆ ಹೊಸ ಕೋಡ್ ಅನ್ನು ಫೋಲ್ಡರ್‌ಗೆ ವರ್ಗಾಯಿಸುವ ಮೂಲಕ ನವೀಕರಣಗಳನ್ನು ಮಾಡಿ. 20 ಹೆಚ್ಚಿನ ಸೇವೆಗಳು ಚಾಲನೆಯಲ್ಲಿರುವ ಹೋಸ್ಟ್ ಸರ್ವರ್‌ನಲ್ಲಿ ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಉಪಯುಕ್ತತೆಗಳನ್ನು ನೇರವಾಗಿ ಸ್ಥಾಪಿಸಿ.

ಯೋಜನೆಯು ಯಾವಾಗಲೂ ಸ್ಪಷ್ಟವಾಗಿ ಅರ್ಥವಾಗುವ ಅವಲಂಬನೆಗಳ ಪಟ್ಟಿಯನ್ನು ಹೊಂದಿರಬೇಕು (ಅವಲಂಬನೆಯಿಂದ ನಾನು ಪರಿಸರವನ್ನು ಸಹ ಅರ್ಥೈಸುತ್ತೇನೆ). ಎಲ್ಲಾ ಅವಲಂಬನೆಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಬೇಕು ಮತ್ತು ಪ್ರತ್ಯೇಕಿಸಬೇಕು.
ಉದಾಹರಣೆಯಾಗಿ ತೆಗೆದುಕೊಳ್ಳೋಣ ಸಂಯೋಜಕ и ಡಾಕರ್.

ಸಂಯೋಜಕ — PHP ನಲ್ಲಿ ಲೈಬ್ರರಿಗಳನ್ನು ಸ್ಥಾಪಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್. ಸಂಯೋಜಕವು ಆವೃತ್ತಿಗಳನ್ನು ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಅಥವಾ ಸಡಿಲವಾಗಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ. ಸರ್ವರ್‌ನಲ್ಲಿ 20 ವಿಭಿನ್ನ ಯೋಜನೆಗಳಿರಬಹುದು ಮತ್ತು ಪ್ರತಿಯೊಂದೂ ಪ್ಯಾಕೇಜುಗಳು ಮತ್ತು ಲೈಬ್ರರಿಗಳ ವೈಯಕ್ತಿಕ ಪಟ್ಟಿಯನ್ನು ಹೊಂದಿರುತ್ತದೆ.

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

3. ಸಂರಚನೆ

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

ಸಂರಚನೆಗಳು - ಯೋಜನೆಯ ನಿಯೋಜನೆಗಳು ಭಿನ್ನವಾಗಿರಬೇಕಾದ ಏಕೈಕ ಮಾರ್ಗವಾಗಿದೆ. ತಾತ್ತ್ವಿಕವಾಗಿ, ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ಪರಿಸರ ವೇರಿಯಬಲ್‌ಗಳ ಮೂಲಕ ರವಾನಿಸಬೇಕು (env vars).

ಅಂದರೆ, ನೀವು ಹಲವಾರು ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳನ್ನು .config.prod .config.local ಅನ್ನು ಸಂಗ್ರಹಿಸಿದರೂ ಮತ್ತು ನಿಯೋಜನೆಯ ಸಮಯದಲ್ಲಿ ಅವುಗಳನ್ನು .config (ಅಪ್ಲಿಕೇಶನ್ ಡೇಟಾವನ್ನು ಓದುವ ಮುಖ್ಯ ಸಂರಚನೆ) ಗೆ ಮರುಹೆಸರಿಸಿದರೂ ಸಹ - ಇದು ಸರಿಯಾದ ವಿಧಾನವಲ್ಲ, ಏಕೆಂದರೆ ಈ ಸಂದರ್ಭದಲ್ಲಿ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳ ಮಾಹಿತಿಯು ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಸಾರ್ವಜನಿಕವಾಗಿ ಲಭ್ಯವಿರುತ್ತದೆ ಮತ್ತು ಪ್ರೊಡಕ್ಷನ್ ಸರ್ವರ್‌ನಿಂದ ಡೇಟಾ ರಾಜಿಯಾಗುತ್ತದೆ. ಎಲ್ಲಾ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ನೇರವಾಗಿ ನಿಯೋಜನೆ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ (CI/CD) ಸಂಗ್ರಹಿಸಬೇಕು ಮತ್ತು ನಿಯೋಜನೆಯ ಸಮಯದಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ಪರಿಸರಕ್ಕೆ ಅಗತ್ಯವಿರುವ ವಿಭಿನ್ನ ಮೌಲ್ಯಗಳೊಂದಿಗೆ ವಿಭಿನ್ನ ಪರಿಸರಗಳಿಗೆ ರಚಿಸಬೇಕು.

4. ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸೇವೆಗಳು

ಪರಿಸರಕ್ಕೆ ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಸಂಬಂಧಿಸಿರಿ, ಕೆಲವು ಪರಿಸರದಲ್ಲಿ ಒಂದೇ ಸೇವೆಗಳಿಗೆ ವಿಭಿನ್ನ ಸಂಪರ್ಕಗಳನ್ನು ಬಳಸಿ.

ವಾಸ್ತವವಾಗಿ, ಈ ಹಂತವು ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳ ಬಿಂದುದೊಂದಿಗೆ ಬಲವಾಗಿ ಅತಿಕ್ರಮಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಈ ಹಂತವಿಲ್ಲದೆ, ಸಾಮಾನ್ಯ ಕಾನ್ಫಿಗರೇಶನ್ ಡೇಟಾವನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ, ಕಾನ್ಫಿಗರ್ ಮಾಡುವ ಸಾಮರ್ಥ್ಯವು ಯಾವುದಕ್ಕೂ ಇಳಿಯುವುದಿಲ್ಲ.

ಕ್ಯೂ ಸರ್ವರ್‌ಗಳು, ಡೇಟಾಬೇಸ್‌ಗಳು, ಕ್ಯಾಶಿಂಗ್ ಸೇವೆಗಳಂತಹ ಬಾಹ್ಯ ಸೇವೆಗಳಿಗೆ ಎಲ್ಲಾ ಸಂಪರ್ಕಗಳು ಸ್ಥಳೀಯ ಪರಿಸರ ಮತ್ತು ಮೂರನೇ ವ್ಯಕ್ತಿಯ / ಉತ್ಪಾದನಾ ಪರಿಸರ ಎರಡಕ್ಕೂ ಒಂದೇ ಆಗಿರಬೇಕು. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಯಾವುದೇ ಸಮಯದಲ್ಲಿ, ಸಂಪರ್ಕದ ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ಬದಲಾಯಿಸುವ ಮೂಲಕ, ನಾನು ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್ ಅನ್ನು ಬದಲಾಯಿಸದೆಯೇ ಬೇಸ್ #1 ಗೆ ಬೇಸ್ #2 ನೊಂದಿಗೆ ಕರೆಗಳನ್ನು ಬದಲಾಯಿಸಬಹುದು. ಅಥವಾ, ಮುಂದೆ ನೋಡುತ್ತಿರುವಂತೆ, ಸೇವೆಯನ್ನು ಸ್ಕೇಲಿಂಗ್ ಮಾಡುವಾಗ, ಹೆಚ್ಚುವರಿ ಕ್ಯಾಶ್ ಸರ್ವರ್‌ಗಾಗಿ ನೀವು ಯಾವುದೇ ವಿಶೇಷ ರೀತಿಯಲ್ಲಿ ಸಂಪರ್ಕವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಬೇಕಾಗಿಲ್ಲ.

5. ನಿರ್ಮಿಸಿ, ಬಿಡುಗಡೆ ಮಾಡಿ, ಕಾರ್ಯಗತಗೊಳಿಸಿ

ಸರ್ವರ್‌ನಲ್ಲಿ ಕೋಡ್‌ನ ಅಂತಿಮ ಆವೃತ್ತಿಯನ್ನು ಮಾತ್ರ ಹೊಂದಿರಿ, ಬಿಡುಗಡೆಯನ್ನು ಹಿಂತಿರುಗಿಸುವ ಅವಕಾಶವಿಲ್ಲ. ಡಿಸ್ಕ್ ಜಾಗವನ್ನು ತುಂಬುವ ಅಗತ್ಯವಿಲ್ಲ. ದೋಷದೊಂದಿಗೆ ಉತ್ಪಾದನೆಗೆ ಕೋಡ್ ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡಬಹುದು ಎಂದು ಭಾವಿಸುವ ಯಾರಾದರೂ ಕೆಟ್ಟ ಪ್ರೋಗ್ರಾಮರ್!

ನಿಯೋಜನೆಯ ಎಲ್ಲಾ ಹಂತಗಳನ್ನು ಪರಸ್ಪರ ಬೇರ್ಪಡಿಸಬೇಕು.

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

ಇಲ್ಲಿ ನಾವು ನೀಲಿ-ಹಸಿರು ನಿಯೋಜನೆಯನ್ನು ನೆನಪಿಸಿಕೊಳ್ಳುತ್ತೇವೆ, ಇದು ಕೋಡ್ ನಡುವೆ ಬದಲಾಯಿಸಲು ಮಾತ್ರವಲ್ಲದೆ ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳ ನಡುವೆ ಬದಲಾಯಿಸಲು ಮತ್ತು ಎಲ್ಲವನ್ನೂ ಹಿಂತಿರುಗಿಸುವ ಸಾಮರ್ಥ್ಯದೊಂದಿಗೆ ಪರಿಸರಗಳಿಗೆ ಸಹ ಅನುಮತಿಸುತ್ತದೆ.

6. ಪ್ರಕ್ರಿಯೆಗಳು

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

ಸೆಷನ್‌ಗಳಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, ಥರ್ಡ್-ಪಾರ್ಟಿ ಸೇವೆಗಳಿಂದ (memcached, redis) ನಿಯಂತ್ರಿತ ಸಂಗ್ರಹದಲ್ಲಿ ಮಾತ್ರ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಿ, ಆದ್ದರಿಂದ ನೀವು 20 ಅಪ್ಲಿಕೇಶನ್ ಪ್ರಕ್ರಿಯೆಗಳು ಚಾಲನೆಯಲ್ಲಿದ್ದರೂ ಸಹ, ಅವುಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ಸಂಗ್ರಹವನ್ನು ಪ್ರವೇಶಿಸಿದ ನಂತರ ಕ್ಲೈಂಟ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಬಳಕೆದಾರರು ಅಪ್ಲಿಕೇಶನ್‌ನೊಂದಿಗೆ ಮತ್ತೊಂದು ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದ ಅದೇ ಸ್ಥಿತಿ. ಈ ವಿಧಾನದೊಂದಿಗೆ, ನೀವು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸೇವೆಗಳ ಎಷ್ಟು ನಕಲುಗಳನ್ನು ಬಳಸಿದರೂ, ಎಲ್ಲವೂ ಸಾಮಾನ್ಯವಾಗಿ ಮತ್ತು ಡೇಟಾಗೆ ಪ್ರವೇಶದೊಂದಿಗೆ ಸಮಸ್ಯೆಗಳಿಲ್ಲದೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ.

7. ಪೋರ್ಟ್ ಬೈಂಡಿಂಗ್

ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸೇವೆಗಳೊಂದಿಗೆ ಹೇಗೆ ಕೆಲಸ ಮಾಡಬೇಕೆಂದು ವೆಬ್ ಸರ್ವರ್ ಮಾತ್ರ ತಿಳಿದಿರಬೇಕು. ಅಥವಾ ಇನ್ನೂ ಉತ್ತಮ, ವೆಬ್ ಸರ್ವರ್ ಒಳಗೆ ನೇರವಾಗಿ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸೇವೆಗಳನ್ನು ಸ್ಥಾಪಿಸಿ. ಉದಾಹರಣೆಗೆ, Apache ನಲ್ಲಿ PHP ಮಾಡ್ಯೂಲ್ ಆಗಿ.
ಕೆಲವು ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ (localgost:5432, localhost:3000, nginx:80, php-fpm:9000) ಪ್ರವೇಶದ ಮೂಲಕ ನಿಮ್ಮ ಎಲ್ಲಾ ಸೇವೆಗಳು ಪರಸ್ಪರ ಪ್ರವೇಶಿಸಬಹುದು, ಅಂದರೆ, nginx ನಿಂದ ನಾನು php-fpm ಮತ್ತು ಗೆ ಎರಡನ್ನೂ ಪ್ರವೇಶಿಸಬಹುದು postgres, ಮತ್ತು php-fpm ನಿಂದ postgres ಮತ್ತು nginx ಗೆ ಮತ್ತು ವಾಸ್ತವವಾಗಿ ಪ್ರತಿ ಸೇವೆಯಿಂದ ನಾನು ಇನ್ನೊಂದು ಸೇವೆಯನ್ನು ಪ್ರವೇಶಿಸಬಹುದು. ಈ ರೀತಿಯಾಗಿ, ಸೇವೆಯ ಕಾರ್ಯಸಾಧ್ಯತೆಯು ಮತ್ತೊಂದು ಸೇವೆಯ ಕಾರ್ಯಸಾಧ್ಯತೆಗೆ ಸಂಬಂಧಿಸಿಲ್ಲ.

8. ಸಮಾನಾಂತರತೆ

ಒಂದು ಪ್ರಕ್ರಿಯೆಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿ, ಇಲ್ಲದಿದ್ದರೆ ಹಲವಾರು ಪ್ರಕ್ರಿಯೆಗಳು ಪರಸ್ಪರ ಹೊಂದಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ!

ಸ್ಕೇಲಿಂಗ್ಗಾಗಿ ಕೊಠಡಿಯನ್ನು ಬಿಡಿ. ಇದಕ್ಕಾಗಿ ಡಾಕರ್ ಸಮೂಹವು ಉತ್ತಮವಾಗಿದೆ.
ಡಾಕರ್ ಸಮೂಹವು ವಿಭಿನ್ನ ಯಂತ್ರಗಳು ಮತ್ತು ಒಂದೇ ಗಣಕದಲ್ಲಿ ಕಂಟೈನರ್‌ಗಳ ಗುಂಪಿನ ನಡುವೆ ಕಂಟೈನರ್‌ಗಳ ಸಮೂಹಗಳನ್ನು ರಚಿಸಲು ಮತ್ತು ನಿರ್ವಹಿಸಲು ಒಂದು ಸಾಧನವಾಗಿದೆ.

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

9. ವಿಲೇವಾರಿ

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

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

10. ಅಪ್ಲಿಕೇಶನ್ ಅಭಿವೃದ್ಧಿ/ಕಾರ್ಯಾಚರಣೆ ಸಮಾನತೆ

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

ವಾಸ್ತವದಲ್ಲಿ, ಎಲ್ಲಾ ನಿಯೋಜನೆಗಳು ಮತ್ತು ಕೋಡ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು ಬಹುತೇಕ ಒಂದೇ ಪರಿಸರದಲ್ಲಿರಬೇಕು (ನಾವು ಭೌತಿಕ ಯಂತ್ರಾಂಶದ ಬಗ್ಗೆ ಮಾತನಾಡುವುದಿಲ್ಲ). ಅಲ್ಲದೆ, ಯಾವುದೇ ಅಭಿವೃದ್ಧಿ ಉದ್ಯೋಗಿ ಅಗತ್ಯವಿದ್ದರೆ ಉತ್ಪಾದನೆಗೆ ಕೋಡ್ ಅನ್ನು ನಿಯೋಜಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ, ಮತ್ತು ಕೆಲವು ವಿಶೇಷವಾಗಿ ತರಬೇತಿ ಪಡೆದ ಡೆವೊಪ್ಸ್ ಇಲಾಖೆ ಅಲ್ಲ, ವಿಶೇಷ ಶಕ್ತಿಗೆ ಧನ್ಯವಾದಗಳು ಮಾತ್ರ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಉತ್ಪಾದನೆಗೆ ಎತ್ತುತ್ತದೆ.

ಇದಕ್ಕೆ ಡಾಕರ್ ಕೂಡ ನಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತಾರೆ. ಹಿಂದಿನ ಎಲ್ಲಾ ಅಂಶಗಳನ್ನು ಗಮನಿಸಿದರೆ, ಡಾಕರ್ ಅನ್ನು ಬಳಸುವುದರಿಂದ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಮತ್ತು ಸ್ಥಳೀಯ ಯಂತ್ರದಲ್ಲಿ ಒಂದು ಅಥವಾ ಎರಡು ಆಜ್ಞೆಗಳನ್ನು ನಮೂದಿಸಲು ಪರಿಸರವನ್ನು ನಿಯೋಜಿಸುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ತರುತ್ತದೆ.

11. ದಾಖಲೆಗಳು

ನಾವು ಫೈಲ್‌ಗಳು ಮತ್ತು ಡೇಟಾಬೇಸ್‌ಗಳಿಗೆ ಲಾಗ್‌ಗಳನ್ನು ಬರೆಯುತ್ತೇವೆ! ನಾವು ಲಾಗ್‌ಗಳಿಂದ ಫೈಲ್‌ಗಳು ಮತ್ತು ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸುವುದಿಲ್ಲ. 9000 ಪೆಟಾ ಬೈಟ್‌ಗಳಿರುವ ಹಾರ್ಡ್ ಡ್ರೈವ್ ಅನ್ನು ಖರೀದಿಸೋಣ ಮತ್ತು ಅದು ಉತ್ತಮವಾಗಿದೆ.

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

12. ಆಡಳಿತ ಕಾರ್ಯಗಳು

ಡೇಟಾ, ಡೇಟಾಬೇಸ್‌ಗಳು ಇತ್ಯಾದಿಗಳನ್ನು ನವೀಕರಿಸಲು, API ನಲ್ಲಿ ಪ್ರತ್ಯೇಕವಾಗಿ ರಚಿಸಲಾದ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಬಳಸಿ, ಅದನ್ನು ಸತತವಾಗಿ 2 ಬಾರಿ ಕಾರ್ಯಗತಗೊಳಿಸುವುದರಿಂದ ಎಲ್ಲವೂ ನಕಲು ಮಾಡಲಾಗುವುದು. ಆದರೆ ನೀವು ಮೂರ್ಖರಲ್ಲ, ನೀವು ಎರಡು ಬಾರಿ ಕ್ಲಿಕ್ ಮಾಡುವುದಿಲ್ಲ ಮತ್ತು ನಮಗೆ ವಲಸೆ ಅಗತ್ಯವಿಲ್ಲ.

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

PHP, Laravel, Laradock, Docker-compose ನಲ್ಲಿ ಉದಾಹರಣೆ ಅನುಷ್ಠಾನ

P.S ಎಲ್ಲಾ ಉದಾಹರಣೆಗಳನ್ನು MacOS ನಲ್ಲಿ ಮಾಡಲಾಗಿದೆ. ಅವುಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವು ಲಿನಕ್ಸ್‌ಗೆ ಸಹ ಸೂಕ್ತವಾಗಿದೆ. ವಿಂಡೋಸ್ ಬಳಕೆದಾರರೇ, ನನ್ನನ್ನು ಕ್ಷಮಿಸಿ, ಆದರೆ ನಾನು ವಿಂಡೋಸ್‌ನೊಂದಿಗೆ ದೀರ್ಘಕಾಲ ಕೆಲಸ ಮಾಡಿಲ್ಲ.

ನಮ್ಮ PC ಯಲ್ಲಿ PHP ಯ ಯಾವುದೇ ಆವೃತ್ತಿಯನ್ನು ಸ್ಥಾಪಿಸದ ಮತ್ತು ಏನೂ ಇಲ್ಲದಿರುವ ಪರಿಸ್ಥಿತಿಯನ್ನು ನಾವು ಊಹಿಸೋಣ.
ಡಾಕರ್ ಮತ್ತು ಡಾಕರ್-ಕಂಪೋಸ್‌ನ ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಗಳನ್ನು ಸ್ಥಾಪಿಸಿ. (ಇದನ್ನು ಅಂತರ್ಜಾಲದಲ್ಲಿ ಕಾಣಬಹುದು)

docker -v && 
docker-compose -v

1. ಹಾಕಿ ಲಾರಾಡಾಕ್

git clone https://github.com/Laradock/laradock.git && 
ls

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

2. ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಚಲಾಯಿಸಲು Laradock ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ.

cd laradock && 
cp env-example .env

2.1. ಕೆಲವು ಸಂಪಾದಕದಲ್ಲಿ ಹ್ಯಾಬ್ರ್ ಡೈರೆಕ್ಟರಿಯನ್ನು ತೆರೆಯಿರಿ (ಲಾರಾಡಾಕ್ ಅನ್ನು ಕ್ಲೋನ್ ಮಾಡಿದ ಮೂಲ ಫೋಲ್ಡರ್). (ನನ್ನ PHPS ಸ್ಟಾರ್ಮ್ ಸಂದರ್ಭದಲ್ಲಿ)

ಈ ಹಂತದಲ್ಲಿ ನಾವು ಯೋಜನೆಗೆ ಹೆಸರನ್ನು ಮಾತ್ರ ನೀಡುತ್ತೇವೆ.

2.2 ಕಾರ್ಯಸ್ಥಳದ ಚಿತ್ರವನ್ನು ಪ್ರಾರಂಭಿಸಿ. (ನಿಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಚಿತ್ರಗಳನ್ನು ನಿರ್ಮಿಸಲು ಸ್ವಲ್ಪ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ)
ವರ್ಕ್‌ಸ್ಪೇಸ್ ಡೆವಲಪರ್ ಪರವಾಗಿ ಫ್ರೇಮ್‌ವರ್ಕ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ವಿಶೇಷವಾಗಿ ಸಿದ್ಧಪಡಿಸಿದ ಚಿತ್ರವಾಗಿದೆ.

ನಾವು ಬಳಸಿ ಕಂಟೇನರ್ ಒಳಗೆ ಹೋಗುತ್ತೇವೆ

docker-compose up -d workspace && 
docker-compose exec workspace bash

2.3 ಲಾರಾವೆಲ್ ಅನ್ನು ಸ್ಥಾಪಿಸಲಾಗುತ್ತಿದೆ

composer create-project --prefer-dist laravel/laravel application

2.4 ಅನುಸ್ಥಾಪನೆಯ ನಂತರ, ಯೋಜನೆಯೊಂದಿಗೆ ಡೈರೆಕ್ಟರಿಯನ್ನು ರಚಿಸಲಾಗಿದೆಯೇ ಎಂದು ನಾವು ಪರಿಶೀಲಿಸುತ್ತೇವೆ ಮತ್ತು ಸಂಯೋಜನೆಯನ್ನು ಕೊಲ್ಲುತ್ತೇವೆ.

ls
exit
docker-compose down

2.5 ನಾವು PHPStorm ಗೆ ಹಿಂತಿರುಗಿ ಮತ್ತು .env ಫೈಲ್‌ನಲ್ಲಿ ನಮ್ಮ ಲಾರಾವೆಲ್ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಸರಿಯಾದ ಮಾರ್ಗವನ್ನು ಹೊಂದಿಸೋಣ.

3. ಎಲ್ಲಾ ಕೋಡ್ ಅನ್ನು Git ಗೆ ಸೇರಿಸಿ.

ಇದನ್ನು ಮಾಡಲು, ನಾವು ಗಿಥಬ್‌ನಲ್ಲಿ (ಅಥವಾ ಬೇರೆಲ್ಲಿಯಾದರೂ) ರೆಪೊಸಿಟರಿಯನ್ನು ರಚಿಸುತ್ತೇವೆ. ಟರ್ಮಿನಲ್‌ನಲ್ಲಿರುವ habr ಡೈರೆಕ್ಟರಿಗೆ ಹೋಗೋಣ ಮತ್ತು ಕೆಳಗಿನ ಕೋಡ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸೋಣ.

echo "# habr-12factor" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin [email protected]:nzulfigarov/habr-12factor.git # здесь будет ссылка на ваш репо
git push -u origin master
git status

ಎಲ್ಲವೂ ಕ್ರಮದಲ್ಲಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸೋಣ.

ಅನುಕೂಲಕ್ಕಾಗಿ, Git ಗಾಗಿ ಕೆಲವು ದೃಶ್ಯ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಬಳಸಲು ನಾನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ, ನನ್ನ ಸಂದರ್ಭದಲ್ಲಿ ಅದು ಗಿಟ್ಕ್ರಾಕೆನ್. (ಇಲ್ಲಿ ಉಲ್ಲೇಖಿತ ಲಿಂಕ್ ಇದೆ)

4. ಪ್ರಾರಂಭಿಸೋಣ!

ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು, 80 ಮತ್ತು 443 ಪೋರ್ಟ್‌ಗಳಲ್ಲಿ ಏನೂ ಸ್ಥಗಿತಗೊಳ್ಳುತ್ತಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.

docker-compose up -d nginx php-fpm

ಹೀಗಾಗಿ, ನಮ್ಮ ಯೋಜನೆಯು 3 ಪ್ರತ್ಯೇಕ ಸೇವೆಗಳನ್ನು ಒಳಗೊಂಡಿದೆ:

• nginx - ವೆಬ್ ಸರ್ವರ್
• php-fpm - ವೆಬ್ ಸರ್ವರ್‌ನಿಂದ ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸಲು php
• ಕಾರ್ಯಸ್ಥಳ - ಡೆವಲಪರ್‌ಗಳಿಗಾಗಿ php

ಈ ಸಮಯದಲ್ಲಿ, ನಾವು 4 ರಲ್ಲಿ 12 ಅಂಕಗಳನ್ನು ಪೂರೈಸುವ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ರಚಿಸಿದ್ದೇವೆ ಎಂದು ಸಾಧಿಸಿದ್ದೇವೆ, ಅವುಗಳೆಂದರೆ:

1. ಕೋಡ್ಬೇಸ್ — ಎಲ್ಲಾ ಕೋಡ್ ಒಂದೇ ರೆಪೊಸಿಟರಿಯಲ್ಲಿದೆ (ಸಣ್ಣ ಟಿಪ್ಪಣಿ: ಲಾರಾವೆಲ್ ಯೋಜನೆಯೊಳಗೆ ಡಾಕರ್ ಅನ್ನು ಸೇರಿಸುವುದು ಸರಿಯಾಗಿರಬಹುದು, ಆದರೆ ಇದು ಮುಖ್ಯವಲ್ಲ).

2. ಅವಲಂಬನೆಗಳು - ನಮ್ಮ ಎಲ್ಲಾ ಅವಲಂಬನೆಗಳನ್ನು ಅಪ್ಲಿಕೇಶನ್/composer.json ನಲ್ಲಿ ಮತ್ತು ಪ್ರತಿ ಕಂಟೇನರ್‌ನ ಪ್ರತಿ ಡಾಕರ್‌ಫೈಲ್‌ನಲ್ಲಿ ಸ್ಪಷ್ಟವಾಗಿ ಬರೆಯಲಾಗಿದೆ.

3. ಬ್ಯಾಕಿಂಗ್ ಸೇವೆಗಳು - ಪ್ರತಿಯೊಂದು ಸೇವೆಗಳು (php-fom, nignx, ವರ್ಕ್‌ಸ್ಪೇಸ್) ತನ್ನದೇ ಆದ ಜೀವನವನ್ನು ನಡೆಸುತ್ತದೆ ಮತ್ತು ಹೊರಗಿನಿಂದ ಸಂಪರ್ಕ ಹೊಂದಿದೆ ಮತ್ತು ಒಂದು ಸೇವೆಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ, ಇತರವು ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ.

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

5. ಪೋರ್ಟ್ ಬೈಂಡಿಂಗ್

docker ps

ನಾವು ನೋಡುವಂತೆ, ಪ್ರತಿಯೊಂದು ಸೇವೆಯು ತನ್ನದೇ ಆದ ಬಂದರಿನಲ್ಲಿ ಚಲಿಸುತ್ತದೆ ಮತ್ತು ಎಲ್ಲಾ ಇತರ ಸೇವೆಗಳಿಗೆ ಪ್ರವೇಶಿಸಬಹುದಾಗಿದೆ.

6. ಸಮಾನಾಂತರತೆ

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

ಕಂಟೇನರ್‌ಗಳನ್ನು ನಿಲ್ಲಿಸಿ ಧ್ವಜದ ಮೂಲಕ ಓಡಿಸೋಣ --ಸ್ಕೇಲ್

docker-compose down && 
docker-compose up -d --scale php-fpm=3 nginx php-fpm

ನಾವು ನೋಡುವಂತೆ, php-fpm ಕಂಟೇನರ್‌ನ ಪ್ರತಿಗಳನ್ನು ರಚಿಸಲಾಗಿದೆ. ಈ ಕಂಟೇನರ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ ನಾವು ಏನನ್ನೂ ಬದಲಾಯಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. ನಾವು ಅದನ್ನು ಪೋರ್ಟ್ 9000 ನಲ್ಲಿ ಪ್ರವೇಶಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತೇವೆ ಮತ್ತು ಡಾಕರ್ ನಮಗೆ ಕಂಟೈನರ್‌ಗಳ ನಡುವಿನ ಲೋಡ್ ಅನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ.

7. ವಿಲೇವಾರಿ - ಪ್ರತಿ ಕಂಟೇನರ್ ಅನ್ನು ಇನ್ನೊಂದಕ್ಕೆ ಹಾನಿಯಾಗದಂತೆ ಕೊಲ್ಲಬಹುದು. ಕಂಟೇನರ್ ಅನ್ನು ನಿಲ್ಲಿಸುವುದು ಅಥವಾ ಮರುಪ್ರಾರಂಭಿಸುವುದು ನಂತರದ ಉಡಾವಣೆಗಳ ಸಮಯದಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್‌ನ ಕಾರ್ಯಾಚರಣೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ. ಪ್ರತಿ ಕಂಟೇನರ್ ಅನ್ನು ಯಾವುದೇ ಸಮಯದಲ್ಲಿ ಎತ್ತಬಹುದು.

8. ಅಪ್ಲಿಕೇಶನ್ ಅಭಿವೃದ್ಧಿ/ಕಾರ್ಯಾಚರಣೆ ಸಮಾನತೆ - ನಮ್ಮ ಎಲ್ಲಾ ಪರಿಸರಗಳು ಒಂದೇ ಆಗಿವೆ. ಉತ್ಪಾದನೆಯಲ್ಲಿ ಸರ್ವರ್‌ನಲ್ಲಿ ಸಿಸ್ಟಮ್ ಅನ್ನು ಚಲಾಯಿಸುವ ಮೂಲಕ, ನಿಮ್ಮ ಆಜ್ಞೆಗಳಲ್ಲಿ ನೀವು ಏನನ್ನೂ ಬದಲಾಯಿಸಬೇಕಾಗಿಲ್ಲ. ಎಲ್ಲವೂ ಒಂದೇ ರೀತಿಯಲ್ಲಿ ಡಾಕರ್ ಅನ್ನು ಆಧರಿಸಿರುತ್ತದೆ.

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

 docker-compose logs -f

ಆದರೆ PHP ಮತ್ತು Nginx ನಲ್ಲಿನ ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯಗಳು ಫೈಲ್‌ಗೆ ಲಾಗ್‌ಗಳನ್ನು ಬರೆಯುತ್ತವೆ ಎಂಬ ಕ್ಯಾಚ್ ಇದೆ. 12 ಅಂಶಗಳನ್ನು ಪೂರೈಸಲು, ಇದು ಅವಶ್ಯಕ ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸಿ ಪ್ರತಿ ಕಂಟೇನರ್‌ನ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳಲ್ಲಿ ಫೈಲ್‌ಗೆ ಲಾಗ್‌ಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಬರೆಯುವುದು.

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

10. ಆಡಳಿತ ಕಾರ್ಯಗಳು - ಎಲ್ಲಾ ಆಡಳಿತ ಕಾರ್ಯಗಳನ್ನು 12 ಅಂಶಗಳ ಅಪ್ಲಿಕೇಶನ್‌ನ ಸೃಷ್ಟಿಕರ್ತರು ಬಯಸಿದಂತೆ ನಿಖರವಾಗಿ ಕುಶಲಕರ್ಮಿಗಳ ಉಪಕರಣಕ್ಕೆ ಧನ್ಯವಾದಗಳು ಲಾರಾವೆಲ್ ಮೂಲಕ ಪರಿಹರಿಸಲಾಗುತ್ತದೆ.

ಉದಾಹರಣೆಯಾಗಿ, ಕೆಲವು ಆಜ್ಞೆಗಳನ್ನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಾನು ತೋರಿಸುತ್ತೇನೆ.
ನಾವು ಕಂಟೇನರ್ಗೆ ಹೋಗುತ್ತೇವೆ.

 
docker-compose exec workspace bash
php artisan list

ಈಗ ನಾವು ಯಾವುದೇ ಆಜ್ಞೆಯನ್ನು ಬಳಸಬಹುದು. (ದಯವಿಟ್ಟು ಗಮನಿಸಿ, ನಾವು ಡೇಟಾಬೇಸ್ ಮತ್ತು ಸಂಗ್ರಹವನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿಲ್ಲ, ಆದ್ದರಿಂದ ಅರ್ಧದಷ್ಟು ಆಜ್ಞೆಗಳನ್ನು ಸರಿಯಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಅವುಗಳನ್ನು ಕ್ಯಾಶ್ ಮತ್ತು ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ).

11. ಸಂರಚನೆಗಳು ಮತ್ತು 12. ನಿರ್ಮಿಸಿ, ಬಿಡುಗಡೆ ಮಾಡಿ, ಓಡಿಸಿ

ನಾನು ಈ ಭಾಗವನ್ನು ನೀಲಿ-ಹಸಿರು ನಿಯೋಜನೆಗೆ ಅರ್ಪಿಸಲು ಬಯಸುತ್ತೇನೆ, ಆದರೆ ಈ ಲೇಖನಕ್ಕೆ ಇದು ತುಂಬಾ ವಿಸ್ತಾರವಾಗಿದೆ. ಇದರ ಬಗ್ಗೆ ಪ್ರತ್ಯೇಕ ಲೇಖನ ಬರೆಯುತ್ತೇನೆ.

ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಹೇಳುವುದಾದರೆ, ಪರಿಕಲ್ಪನೆಯು CI/CD ವ್ಯವಸ್ಥೆಗಳನ್ನು ಆಧರಿಸಿದೆ ಜೆಂಕಿನ್ಸ್ и ಗಿಟ್ಲಾಬ್ ಸಿಐ. ಎರಡರಲ್ಲೂ, ನೀವು ನಿರ್ದಿಷ್ಟ ಪರಿಸರಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಪರಿಸರ ಅಸ್ಥಿರಗಳನ್ನು ಹೊಂದಿಸಬಹುದು. ಅಂತೆಯೇ, ಈ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, ಪಾಯಿಂಟ್ ಸಿ ಅನ್ನು ಪೂರೈಸಲಾಗುತ್ತದೆ ಸಂರಚನೆಗಳು.

ಮತ್ತು ಪಾಯಿಂಟ್ ಬಗ್ಗೆ ನಿರ್ಮಿಸಿ, ಬಿಡುಗಡೆ ಮಾಡಿ, ಓಡಿಸಿ ಹೆಸರಿನೊಂದಿಗೆ ಅಂತರ್ನಿರ್ಮಿತ ಕಾರ್ಯಗಳ ಮೂಲಕ ಪರಿಹರಿಸಲಾಗುತ್ತದೆ ಪೈಪ್ಲೈನ್.

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

ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್ ನಲ್ಲಿದೆ github.
ಈ ರೆಪೊಸಿಟರಿಯನ್ನು ಕ್ಲೋನಿಂಗ್ ಮಾಡುವಾಗ ಸಬ್ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲು ಮರೆಯಬೇಡಿ.

P.S.: ಈ ಎಲ್ಲಾ ವಿಧಾನಗಳನ್ನು ಯಾವುದೇ ಇತರ ಉಪಯುಕ್ತತೆಗಳು ಮತ್ತು ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಗಳೊಂದಿಗೆ ಬಳಸಬಹುದು. ಮುಖ್ಯ ವಿಷಯವೆಂದರೆ ಸಾರವು ಭಿನ್ನವಾಗಿರುವುದಿಲ್ಲ.

ಮೂಲ: www.habr.com