ಸಾಮಾನ್ಯ ಡಾಕರ್‌ಫೈಲ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ನೀವು ಈಗ ಡಾಕರ್ ಚಿತ್ರಗಳನ್ನು ವರ್ಫ್‌ನಲ್ಲಿ ನಿರ್ಮಿಸಬಹುದು

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

ನಾವು ಮಾತನಾಡುತ್ತೇವೆ werf — GitOps ಯುಟಿಲಿಟಿಯು ಯಾವುದೇ CI/CD ಸಿಸ್ಟಮ್‌ನೊಂದಿಗೆ ಸಂಯೋಜಿಸುತ್ತದೆ ಮತ್ತು ಸಂಪೂರ್ಣ ಅಪ್ಲಿಕೇಶನ್ ಜೀವನಚಕ್ರದ ನಿರ್ವಹಣೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ, ಅನುಮತಿಸುತ್ತದೆ:

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

DevOps ಇಂಜಿನಿಯರ್‌ಗಳಿಗೆ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಮೇಲೆ ನಿಯಂತ್ರಣವನ್ನು ನೀಡುವ ಏಕೈಕ ಏಕೀಕೃತ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಕಡಿಮೆ-ಮಟ್ಟದ ಪರಿಕರಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದು ಯೋಜನೆಯ ತತ್ವವಾಗಿದೆ. ಸಾಧ್ಯವಾದರೆ, ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಉಪಯುಕ್ತತೆಗಳನ್ನು (ಹೆಲ್ಮ್ ಮತ್ತು ಡಾಕರ್ ನಂತಹ) ಬಳಸಬೇಕು. ಸಮಸ್ಯೆಗೆ ಯಾವುದೇ ಪರಿಹಾರವಿಲ್ಲದಿದ್ದರೆ, ಇದಕ್ಕಾಗಿ ಅಗತ್ಯವಿರುವ ಎಲ್ಲವನ್ನೂ ನಾವು ರಚಿಸಬಹುದು ಮತ್ತು ಬೆಂಬಲಿಸಬಹುದು.

ಹಿನ್ನೆಲೆ: ನಿಮ್ಮ ಸ್ವಂತ ಚಿತ್ರ ಸಂಗ್ರಾಹಕ

ವರ್ಫ್‌ನಲ್ಲಿನ ಚಿತ್ರ ಸಂಗ್ರಾಹಕರೊಂದಿಗೆ ಇದು ಏನಾಯಿತು: ಸಾಮಾನ್ಯ ಡಾಕರ್‌ಫೈಲ್ ನಮಗೆ ಸಾಕಾಗಲಿಲ್ಲ. ನೀವು ಯೋಜನೆಯ ಇತಿಹಾಸವನ್ನು ತ್ವರಿತವಾಗಿ ನೋಡಿದರೆ, ಈ ಸಮಸ್ಯೆಯು ಈಗಾಗಲೇ ವರ್ಫ್‌ನ ಮೊದಲ ಆವೃತ್ತಿಗಳಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡಿದೆ (ನಂತರ ಇನ್ನೂ ಡಪ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ).

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

1. ಕೆಳಗಿನ ಪ್ರಮಾಣಿತ ಯೋಜನೆಯ ಪ್ರಕಾರ ವಿಶಿಷ್ಟವಾದ ಸಣ್ಣ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುವ ಅಗತ್ಯತೆ:
   • ಸಿಸ್ಟಮ್-ವೈಡ್ ಅಪ್ಲಿಕೇಶನ್ ಅವಲಂಬನೆಗಳನ್ನು ಸ್ಥಾಪಿಸಿ,
   • ಅಪ್ಲಿಕೇಶನ್ ಅವಲಂಬನೆ ಗ್ರಂಥಾಲಯಗಳ ಬಂಡಲ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿ,
   • ಸ್ವತ್ತುಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ,
   • ಮತ್ತು ಮುಖ್ಯವಾಗಿ, ಚಿತ್ರದಲ್ಲಿನ ಕೋಡ್ ಅನ್ನು ತ್ವರಿತವಾಗಿ ಮತ್ತು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ನವೀಕರಿಸಿ.
2. ಪ್ರಾಜೆಕ್ಟ್ ಫೈಲ್‌ಗಳಿಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಿದಾಗ, ಬದಲಾದ ಫೈಲ್‌ಗಳಿಗೆ ಪ್ಯಾಚ್ ಅನ್ನು ಅನ್ವಯಿಸುವ ಮೂಲಕ ಬಿಲ್ಡರ್ ತ್ವರಿತವಾಗಿ ಹೊಸ ಲೇಯರ್ ಅನ್ನು ರಚಿಸಬೇಕು.
3. ಕೆಲವು ಫೈಲ್‌ಗಳು ಬದಲಾಗಿದ್ದರೆ, ಅನುಗುಣವಾದ ಅವಲಂಬಿತ ಹಂತವನ್ನು ಮರುನಿರ್ಮಾಣ ಮಾಡುವುದು ಅವಶ್ಯಕ.

ಇಂದು ನಮ್ಮ ಸಂಗ್ರಾಹಕರಿಗೆ ಅನೇಕ ಇತರ ಸಾಧ್ಯತೆಗಳಿವೆ, ಆದರೆ ಇವು ಆರಂಭಿಕ ಆಸೆಗಳು ಮತ್ತು ಪ್ರಚೋದನೆಗಳಾಗಿವೆ.

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

ರೂಬಿಯಲ್ಲಿ ಡಪ್‌ಗಾಗಿ ಹಳೆಯ ಸಂರಚನೆ

YAML ನಲ್ಲಿ werf ಗಾಗಿ ಪ್ರಸ್ತುತ ಸಂರಚನೆ

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

NB: ಈ ಸಮಯದಲ್ಲಿ, ನಮ್ಮ ಸಂಗ್ರಾಹಕವು ತನ್ನದೇ ಆದ ಸಂರಚನೆಯೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ (YAML ನಲ್ಲಿ) ಮತ್ತು ಸ್ಟೇಪಲ್ ಕಲೆಕ್ಟರ್ ಎಂದು ಕರೆಯಲ್ಪಡುತ್ತದೆ, ಇದು ಈಗಾಗಲೇ ಸಾಕಷ್ಟು ಶಕ್ತಿಯುತ ಸಾಧನವಾಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಿದೆ. ಅದರ ವಿವರವಾದ ವಿವರಣೆಯು ಪ್ರತ್ಯೇಕ ಲೇಖನಗಳಿಗೆ ಅರ್ಹವಾಗಿದೆ ಮತ್ತು ಮೂಲಭೂತ ವಿವರಗಳನ್ನು ಕಾಣಬಹುದು ದಸ್ತಾವೇಜನ್ನು.

ಸಮಸ್ಯೆಯ ಅರಿವು

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

ಈ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುವ ಬದಲು, ನಾವು ಪರಿಹಾರವನ್ನು ನೀಡುತ್ತೇವೆ. ನೀವು ಈಗಾಗಲೇ ಡಾಕರ್‌ಫೈಲ್ (ಅಥವಾ ಡಾಕರ್‌ಫೈಲ್‌ಗಳ ಸೆಟ್) ಹೊಂದಿದ್ದರೆ ಮತ್ತು ವರ್ಫ್ ಅನ್ನು ಬಳಸಲು ಬಯಸಿದರೆ ಏನು ಮಾಡಬೇಕು?

NB: ಅಂದಹಾಗೆ, ನೀವು ವರ್ಫ್ ಅನ್ನು ಏಕೆ ಬಳಸಲು ಬಯಸುತ್ತೀರಿ? ಮುಖ್ಯ ಲಕ್ಷಣಗಳು ಈ ಕೆಳಗಿನವುಗಳಿಗೆ ಬರುತ್ತವೆ:

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

ಅವುಗಳ ಸಂಪೂರ್ಣ ಪಟ್ಟಿಯನ್ನು ಇಲ್ಲಿ ಕಾಣಬಹುದು ಯೋಜನೆಯ ಪುಟ.

ಆದ್ದರಿಂದ, ಮೊದಲು ನಾವು ನಮ್ಮ ಸಂರಚನೆಯಲ್ಲಿ ಡಾಕರ್‌ಫೈಲ್ ಅನ್ನು ಪುನಃ ಬರೆಯಲು ಮುಂದಾಗಿದ್ದರೆ, ಈಗ ನಾವು ಸಂತೋಷದಿಂದ ಹೇಳುತ್ತೇವೆ: "ವರ್ಫ್ ನಿಮ್ಮ ಡಾಕರ್‌ಫೈಲ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲಿ!"

ಹೇಗೆ ಬಳಸುವುದು?

ಈ ವೈಶಿಷ್ಟ್ಯದ ಸಂಪೂರ್ಣ ಅನುಷ್ಠಾನವು ಬಿಡುಗಡೆಯಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡಿದೆ werf v1.0.3-beta.1. ಸಾಮಾನ್ಯ ತತ್ವವು ಸರಳವಾಗಿದೆ: ಬಳಕೆದಾರರು werf ಸಂರಚನೆಯಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಡಾಕರ್‌ಫೈಲ್‌ಗೆ ಮಾರ್ಗವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತಾರೆ ಮತ್ತು ನಂತರ ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸುತ್ತಾರೆ werf build... ಮತ್ತು ಅದು ಇಲ್ಲಿದೆ - ವರ್ಫ್ ಚಿತ್ರವನ್ನು ಜೋಡಿಸುತ್ತಾನೆ. ಒಂದು ಅಮೂರ್ತ ಉದಾಹರಣೆಯನ್ನು ನೋಡೋಣ.

ಮುಂದಿನದನ್ನು ಘೋಷಿಸೋಣ Dockerfile ಯೋಜನೆಯ ಮೂಲದಲ್ಲಿ:

FROM ubuntu:18.04
RUN echo Building ...

ಮತ್ತು ನಾವು ಘೋಷಿಸುತ್ತೇವೆ werf.yamlಇದನ್ನು ಬಳಸುತ್ತದೆ Dockerfile:

configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile

ಎಲ್ಲಾ! ಎಡಕ್ಕೆ ಓಡು werf build:

ಹೆಚ್ಚುವರಿಯಾಗಿ, ನೀವು ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಘೋಷಿಸಬಹುದು werf.yaml ವಿವಿಧ ಡಾಕರ್‌ಫೈಲ್‌ಗಳಿಂದ ಏಕಕಾಲದಲ್ಲಿ ಹಲವಾರು ಚಿತ್ರಗಳನ್ನು ನಿರ್ಮಿಸಲು:

configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend

ಅಂತಿಮವಾಗಿ, ಇದು ಹೆಚ್ಚುವರಿ ನಿರ್ಮಾಣ ನಿಯತಾಂಕಗಳನ್ನು ರವಾನಿಸುವುದನ್ನು ಸಹ ಬೆಂಬಲಿಸುತ್ತದೆ, ಉದಾಹರಣೆಗೆ --build-arg и --add-host - ವರ್ಫ್ ಕಾನ್ಫಿಗರ್ ಮೂಲಕ. ಡಾಕರ್‌ಫೈಲ್ ಇಮೇಜ್ ಕಾನ್ಫಿಗರೇಶನ್‌ನ ಸಂಪೂರ್ಣ ವಿವರಣೆ ಇಲ್ಲಿ ಲಭ್ಯವಿದೆ ದಸ್ತಾವೇಜನ್ನು ಪುಟ.

ಇದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ?

ನಿರ್ಮಾಣ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ, ಡಾಕರ್ ಕಾರ್ಯಗಳಲ್ಲಿ ಸ್ಥಳೀಯ ಲೇಯರ್‌ಗಳ ಪ್ರಮಾಣಿತ ಸಂಗ್ರಹ. ಆದಾಗ್ಯೂ, ಮುಖ್ಯವಾದುದೆಂದರೆ ಅದು ವರ್ಫ್ ಕೂಡ ಡಾಕರ್‌ಫೈಲ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಅದರ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಸಂಯೋಜಿಸುತ್ತದೆ. ಇದರ ಅರ್ಥ ಏನು?

1. ಡಾಕರ್‌ಫೈಲ್‌ನಿಂದ ನಿರ್ಮಿಸಲಾದ ಪ್ರತಿಯೊಂದು ಚಿತ್ರವು ಒಂದು ಹಂತವನ್ನು ಒಳಗೊಂಡಿದೆ dockerfile (ವರ್ಫ್‌ನಲ್ಲಿ ಯಾವ ಹಂತಗಳಿವೆ ಎಂಬುದರ ಕುರಿತು ನೀವು ಇನ್ನಷ್ಟು ಓದಬಹುದು ಇಲ್ಲಿ).
2. ವೇದಿಕೆಗಾಗಿ dockerfile werf ಡಾಕರ್‌ಫೈಲ್ ಕಾನ್ಫಿಗರೇಶನ್‌ನ ವಿಷಯಗಳನ್ನು ಅವಲಂಬಿಸಿರುವ ಸಹಿಯನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತದೆ. ಡಾಕರ್‌ಫೈಲ್ ಕಾನ್ಫಿಗರೇಶನ್ ಬದಲಾದಾಗ, ಹಂತದ ಸಹಿ ಬದಲಾಗುತ್ತದೆ dockerfile ಮತ್ತು werf ಹೊಸ ಡಾಕರ್‌ಫೈಲ್ ಸಂರಚನೆಯೊಂದಿಗೆ ಈ ಹಂತದ ಮರುನಿರ್ಮಾಣವನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಸಹಿ ಬದಲಾಗದಿದ್ದರೆ, werf ಸಂಗ್ರಹದಿಂದ ಚಿತ್ರವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ (ವರ್ಫ್‌ನಲ್ಲಿ ಸಹಿಗಳ ಬಳಕೆಯ ಕುರಿತು ಹೆಚ್ಚಿನ ವಿವರಗಳನ್ನು ವಿವರಿಸಲಾಗಿದೆ ಈ ವರದಿ).
3. ಮುಂದೆ, ಸಂಗ್ರಹಿಸಿದ ಚಿತ್ರಗಳನ್ನು ಆಜ್ಞೆಯೊಂದಿಗೆ ಪ್ರಕಟಿಸಬಹುದು werf publish (ಅಥವಾ werf build-and-publish) ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ಗೆ ನಿಯೋಜನೆಗಾಗಿ ಅದನ್ನು ಬಳಸಿ. ಡಾಕರ್ ರಿಜಿಸ್ಟ್ರಿಗೆ ಪ್ರಕಟಿಸಲಾದ ಚಿತ್ರಗಳನ್ನು ಸ್ಟ್ಯಾಂಡರ್ಡ್ ವರ್ಫ್ ಕ್ಲೀನಪ್ ಪರಿಕರಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಸ್ವಚ್ಛಗೊಳಿಸಲಾಗುತ್ತದೆ, ಅಂದರೆ. ಹಳೆಯ ಚಿತ್ರಗಳು (N ದಿನಗಳಿಗಿಂತ ಹಳೆಯದು), ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ Git ಶಾಖೆಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಚಿತ್ರಗಳು ಮತ್ತು ಇತರ ನೀತಿಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸ್ವಚ್ಛಗೊಳಿಸಲಾಗುತ್ತದೆ.

ಇಲ್ಲಿ ವಿವರಿಸಿದ ಅಂಶಗಳ ಕುರಿತು ಹೆಚ್ಚಿನ ವಿವರಗಳನ್ನು ದಸ್ತಾವೇಜನ್ನು ಕಾಣಬಹುದು:

• ಪ್ರಕಾಶನ ಪ್ರಕ್ರಿಯೆ;
• ಕುಬರ್ನೆಟ್ಸ್ ನಿಯೋಜನೆ ಪ್ರಕ್ರಿಯೆಯೊಂದಿಗೆ ಏಕೀಕರಣ;
• ಸ್ವಚ್ aning ಗೊಳಿಸುವ ಪ್ರಕ್ರಿಯೆ.

ಸೂಚನೆಗಳು ಮತ್ತು ಮುನ್ನೆಚ್ಚರಿಕೆಗಳು

1. ADD ನಲ್ಲಿ ಬಾಹ್ಯ URL ಬೆಂಬಲಿಸುವುದಿಲ್ಲ

ಪ್ರಸ್ತುತ ಇದು ನಿರ್ದೇಶನದಲ್ಲಿ ಬಾಹ್ಯ URL ಅನ್ನು ಬಳಸಲು ಬೆಂಬಲಿತವಾಗಿಲ್ಲ ADD. ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ URL ನಲ್ಲಿನ ಸಂಪನ್ಮೂಲವು ಬದಲಾದಾಗ ವರ್ಫ್ ಮರುನಿರ್ಮಾಣವನ್ನು ಪ್ರಾರಂಭಿಸುವುದಿಲ್ಲ. ನಾವು ಶೀಘ್ರದಲ್ಲೇ ಈ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಸೇರಿಸಲು ಯೋಜಿಸುತ್ತೇವೆ.

2. ನೀವು ಚಿತ್ರಕ್ಕೆ .git ಅನ್ನು ಸೇರಿಸಲಾಗುವುದಿಲ್ಲ

ಸಾಮಾನ್ಯವಾಗಿ ಹೇಳುವುದಾದರೆ, ಡೈರೆಕ್ಟರಿಯನ್ನು ಸೇರಿಸುವುದು .git ಚಿತ್ರದಲ್ಲಿ - ಕೆಟ್ಟ ಅಭ್ಯಾಸ ಮತ್ತು ಇಲ್ಲಿ ಏಕೆ:

1. ವೇಳೆ .git ಅಂತಿಮ ಚಿತ್ರದಲ್ಲಿ ಉಳಿದಿದೆ, ಇದು ತತ್ವಗಳನ್ನು ಉಲ್ಲಂಘಿಸುತ್ತದೆ 12 ಅಂಶಗಳ ಅಪ್ಲಿಕೇಶನ್: ಅಂತಿಮ ಚಿತ್ರವನ್ನು ಒಂದೇ ಬದ್ಧತೆಗೆ ಲಿಂಕ್ ಮಾಡಬೇಕಾಗಿರುವುದರಿಂದ, ಅದನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ git checkout ಅನಿಯಂತ್ರಿತ ಬದ್ಧತೆ.
2. .git ಚಿತ್ರದ ಗಾತ್ರವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ (ದೊಡ್ಡ ಫೈಲ್‌ಗಳನ್ನು ಒಮ್ಮೆ ಸೇರಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ನಂತರ ಅಳಿಸಲಾಗುತ್ತದೆ ಎಂಬ ಅಂಶದಿಂದಾಗಿ ರೆಪೊಸಿಟರಿಯು ದೊಡ್ಡದಾಗಿರಬಹುದು). ನಿರ್ದಿಷ್ಟ ಬದ್ಧತೆಯೊಂದಿಗೆ ಮಾತ್ರ ಸಂಬಂಧಿಸಿದ ಕೆಲಸದ ಮರದ ಗಾತ್ರವು Git ನಲ್ಲಿನ ಕಾರ್ಯಾಚರಣೆಗಳ ಇತಿಹಾಸವನ್ನು ಅವಲಂಬಿಸಿರುವುದಿಲ್ಲ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಸೇರ್ಪಡೆ ಮತ್ತು ನಂತರದ ತೆಗೆದುಹಾಕುವಿಕೆ .git ಅಂತಿಮ ಚಿತ್ರದಿಂದ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ: ಚಿತ್ರವು ಇನ್ನೂ ಹೆಚ್ಚುವರಿ ಪದರವನ್ನು ಪಡೆದುಕೊಳ್ಳುತ್ತದೆ - ಡಾಕರ್ ಈ ರೀತಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
3. ಡಾಕರ್ ಅನಗತ್ಯವಾದ ಮರುನಿರ್ಮಾಣವನ್ನು ಪ್ರಾರಂಭಿಸಬಹುದು, ಅದೇ ಬದ್ಧತೆಯನ್ನು ನಿರ್ಮಿಸಲಾಗಿದ್ದರೂ ಸಹ, ಆದರೆ ವಿವಿಧ ಕೆಲಸ-ಮರಗಳಿಂದ. ಉದಾಹರಣೆಗೆ, GitLab ಪ್ರತ್ಯೇಕ ಕ್ಲೋನ್ ಡೈರೆಕ್ಟರಿಗಳನ್ನು ರಚಿಸುತ್ತದೆ /home/gitlab-runner/builds/HASH/[0-N]/yourproject ಸಮಾನಾಂತರ ಜೋಡಣೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದಾಗ. ಹೆಚ್ಚುವರಿ ಮರುಜೋಡಣೆಯು ಡೈರೆಕ್ಟರಿಯ ಕಾರಣದಿಂದಾಗಿರುತ್ತದೆ .git ಒಂದೇ ರೆಪೊಸಿಟರಿಯ ವಿಭಿನ್ನ ಕ್ಲೋನ್ ಆವೃತ್ತಿಗಳಲ್ಲಿ ವಿಭಿನ್ನವಾಗಿದೆ, ಅದೇ ಬದ್ಧತೆಯನ್ನು ನಿರ್ಮಿಸಿದ್ದರೂ ಸಹ.

ವರ್ಫ್ ಅನ್ನು ಬಳಸುವಾಗ ಕೊನೆಯ ಹಂತವು ಸಹ ಪರಿಣಾಮಗಳನ್ನು ಹೊಂದಿದೆ. ಕೆಲವು ಕಮಾಂಡ್‌ಗಳನ್ನು ಚಲಾಯಿಸುವಾಗ ವರ್ಫ್‌ಗೆ ಬಿಲ್ಟ್ ಕ್ಯಾಶ್ ಇರುವ ಅಗತ್ಯವಿದೆ (ಉದಾ. werf deploy) ಈ ಆಜ್ಞೆಗಳನ್ನು ಚಲಾಯಿಸಿದಾಗ, ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಚಿತ್ರಗಳಿಗೆ ಹಂತದ ಸಹಿಗಳನ್ನು werf ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತದೆ werf.yaml, ಮತ್ತು ಅವರು ಅಸೆಂಬ್ಲಿ ಸಂಗ್ರಹದಲ್ಲಿರಬೇಕು - ಇಲ್ಲದಿದ್ದರೆ ಆಜ್ಞೆಯು ಕೆಲಸವನ್ನು ಮುಂದುವರಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ವೇದಿಕೆಯ ಸಹಿ ವಿಷಯದ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದ್ದರೆ .git, ನಂತರ ನಾವು ಅಪ್ರಸ್ತುತ ಫೈಲ್‌ಗಳಲ್ಲಿನ ಬದಲಾವಣೆಗಳಿಗೆ ಅಸ್ಥಿರವಾದ ಸಂಗ್ರಹವನ್ನು ಪಡೆಯುತ್ತೇವೆ ಮತ್ತು werf ಅಂತಹ ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಕ್ಷಮಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ (ಹೆಚ್ಚಿನ ವಿವರಗಳಿಗಾಗಿ, ನೋಡಿ ದಸ್ತಾವೇಜನ್ನು).

ಸಾಮಾನ್ಯವಾಗಿ ಕೆಲವು ಅಗತ್ಯ ಫೈಲ್‌ಗಳನ್ನು ಮಾತ್ರ ಸೇರಿಸಲಾಗುತ್ತಿದೆ ಸೂಚನೆಗಳ ಮೂಲಕ ADD ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ ಲಿಖಿತ ದಕ್ಷತೆ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ Dockerfile, ಮತ್ತು ಇದಕ್ಕಾಗಿ ಸಂಗ್ರಹಿಸಲಾದ ಸಂಗ್ರಹದ ಸ್ಥಿರತೆಯನ್ನು ಸುಧಾರಿಸುತ್ತದೆ Dockerfile, Git ನಲ್ಲಿ ಅಪ್ರಸ್ತುತ ಬದಲಾವಣೆಗಳಿಗೆ.

ಫಲಿತಾಂಶ

ನಿರ್ದಿಷ್ಟ ಅಗತ್ಯಗಳಿಗಾಗಿ ನಮ್ಮ ಸ್ವಂತ ಬಿಲ್ಡರ್ ಅನ್ನು ಬರೆಯುವ ನಮ್ಮ ಆರಂಭಿಕ ಮಾರ್ಗವು ಕಠಿಣ, ಪ್ರಾಮಾಣಿಕ ಮತ್ತು ನೇರವಾಗಿತ್ತು: ಪ್ರಮಾಣಿತ ಡಾಕರ್‌ಫೈಲ್‌ನ ಮೇಲ್ಭಾಗದಲ್ಲಿ ಊರುಗೋಲುಗಳನ್ನು ಬಳಸುವ ಬದಲು, ನಾವು ಕಸ್ಟಮ್ ಸಿಂಟ್ಯಾಕ್ಸ್‌ನೊಂದಿಗೆ ನಮ್ಮ ಪರಿಹಾರವನ್ನು ಬರೆದಿದ್ದೇವೆ. ಮತ್ತು ಇದು ಅದರ ಪ್ರಯೋಜನಗಳನ್ನು ಹೊಂದಿತ್ತು: ಸ್ಟೇಪಲ್ ಕಲೆಕ್ಟರ್ ತನ್ನ ಕೆಲಸವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿಭಾಯಿಸುತ್ತಾನೆ.

ಆದಾಗ್ಯೂ, ನಮ್ಮ ಸ್ವಂತ ಬಿಲ್ಡರ್ ಬರೆಯುವ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ, ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಡಾಕರ್‌ಫೈಲ್‌ಗಳಿಗೆ ಬೆಂಬಲವನ್ನು ನಾವು ಕಳೆದುಕೊಂಡಿದ್ದೇವೆ. ಈ ನ್ಯೂನತೆಯನ್ನು ಈಗ ಸರಿಪಡಿಸಲಾಗಿದೆ, ಮತ್ತು ಭವಿಷ್ಯದಲ್ಲಿ ನಾವು ನಮ್ಮ ಕಸ್ಟಮ್ ಸ್ಟೇಪಲ್ ಬಿಲ್ಡರ್ ಜೊತೆಗೆ ಡಾಕರ್‌ಫೈಲ್ ಬೆಂಬಲವನ್ನು ವಿತರಣಾ ಬಿಲ್ಡ್‌ಗಳಿಗಾಗಿ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ ಬಳಸುವ ಬಿಲ್ಡ್‌ಗಳಿಗಾಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಯೋಜಿಸುತ್ತೇವೆ (ಅಂದರೆ ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ರನ್ನರ್‌ಗಳ ಮೇಲೆ ನಿರ್ಮಿಸುತ್ತದೆ, ಕನಿಕೊದಲ್ಲಿ ಮಾಡಿದಂತೆ).

ಆದ್ದರಿಂದ, ನೀವು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಒಂದೆರಡು ಡಾಕರ್‌ಫೈಲ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ... ಪ್ರಯತ್ನಿಸಿ werf!

PS ವಿಷಯದ ಕುರಿತು ದಾಖಲಾತಿಗಳ ಪಟ್ಟಿ

• ತ್ವರಿತ ಪ್ರಾರಂಭಕ್ಕಾಗಿ ಮಾರ್ಗದರ್ಶಿಗಳು;
• ಡಾಕರ್‌ಫೈಲ್ ಬಿಲ್ಡರ್ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳು;
• ವರ್ಫ್‌ನಲ್ಲಿ ಹಂತಗಳ ಸಾಧನ;
• ಚಿತ್ರ ಪ್ರಕಾಶನ ಪ್ರಕ್ರಿಯೆ;
• ಕುಬರ್ನೆಟ್ಸ್ ನಿಯೋಜನೆ ಪ್ರಕ್ರಿಯೆಯೊಂದಿಗೆ ಏಕೀಕರಣ;
• ಸ್ವಚ್ aning ಗೊಳಿಸುವ ಪ್ರಕ್ರಿಯೆ;
• ಡಾಕರ್‌ಫೈಲ್‌ಗೆ ಪರ್ಯಾಯವಾಗಿ ಸ್ಟೇಪಲ್ ಬಿಲ್ಡರ್.

ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿಯೂ ಓದಿ: "werf - Kubernetes ನಲ್ಲಿ CI/CD ಗಾಗಿ ನಮ್ಮ ಸಾಧನ (ವಿಮರ್ಶೆ ಮತ್ತು ವೀಡಿಯೊ ವರದಿ)».

ಮೂಲ: www.habr.com