ಒಂದು ವೈಶಿಷ್ಟ್ಯವು ಉತ್ಪಾದನೆಗೆ ಬರುವ ಮೊದಲು, ಸಂಕೀರ್ಣವಾದ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ಗಳು ಮತ್ತು CI/CD ಈ ದಿನಗಳಲ್ಲಿ, ಪರೀಕ್ಷೆಗಳು ಮತ್ತು ವಿತರಣೆಗೆ ಬದ್ಧತೆಯಿಂದ ಹೋಗಲು ಬಹಳ ದೂರವಿದೆ. ಹಿಂದೆ, ನೀವು FTP ಮೂಲಕ ಹೊಸ ಫೈಲ್ಗಳನ್ನು ಅಪ್ಲೋಡ್ ಮಾಡಬಹುದು (ಯಾರೂ ಇನ್ನು ಮುಂದೆ ಹಾಗೆ ಮಾಡುವುದಿಲ್ಲ, ಸರಿ?), ಮತ್ತು "ನಿಯೋಜನೆ" ಪ್ರಕ್ರಿಯೆಯು ಸೆಕೆಂಡುಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು. ಈಗ ನೀವು ವಿಲೀನ ವಿನಂತಿಯನ್ನು ರಚಿಸಬೇಕಾಗಿದೆ ಮತ್ತು ವೈಶಿಷ್ಟ್ಯವು ಬಳಕೆದಾರರನ್ನು ತಲುಪಲು ಬಹಳ ಸಮಯ ಕಾಯಬೇಕು.
ಈ ಮಾರ್ಗದ ಭಾಗವು ಡಾಕರ್ ಚಿತ್ರವನ್ನು ನಿರ್ಮಿಸುತ್ತಿದೆ. ಕೆಲವೊಮ್ಮೆ ಅಸೆಂಬ್ಲಿ ನಿಮಿಷಗಳವರೆಗೆ ಇರುತ್ತದೆ, ಕೆಲವೊಮ್ಮೆ ಹತ್ತಾರು ನಿಮಿಷಗಳು, ಇದನ್ನು ಸಾಮಾನ್ಯ ಎಂದು ಕರೆಯಲಾಗುವುದಿಲ್ಲ. ಈ ಲೇಖನದಲ್ಲಿ, ನಾವು ಸರಳವಾದ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ, ನಾವು ಚಿತ್ರವನ್ನು ಪ್ಯಾಕೇಜ್ ಮಾಡುತ್ತೇವೆ, ನಿರ್ಮಾಣವನ್ನು ವೇಗಗೊಳಿಸಲು ಹಲವಾರು ವಿಧಾನಗಳನ್ನು ಅನ್ವಯಿಸುತ್ತೇವೆ ಮತ್ತು ಈ ವಿಧಾನಗಳು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಎಂಬುದರ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳನ್ನು ನೋಡೋಣ.
ಮಾಧ್ಯಮ ವೆಬ್ಸೈಟ್ಗಳನ್ನು ರಚಿಸುವಲ್ಲಿ ಮತ್ತು ಬೆಂಬಲಿಸುವಲ್ಲಿ ನಮಗೆ ಉತ್ತಮ ಅನುಭವವಿದೆ:
ನಾವು GitLab ಗೆ ನಿಯೋಜಿಸುತ್ತೇವೆ. ನಾವು ಚಿತ್ರಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ, ಅವುಗಳನ್ನು GitLab ರಿಜಿಸ್ಟ್ರಿಗೆ ತಳ್ಳುತ್ತೇವೆ ಮತ್ತು ಅವುಗಳನ್ನು ಉತ್ಪಾದನೆಗೆ ಹೊರತರುತ್ತೇವೆ. ಈ ಪಟ್ಟಿಯಲ್ಲಿರುವ ದೀರ್ಘವಾದ ವಿಷಯವೆಂದರೆ ಚಿತ್ರಗಳನ್ನು ಜೋಡಿಸುವುದು. ಉದಾಹರಣೆಗೆ: ಆಪ್ಟಿಮೈಸೇಶನ್ ಇಲ್ಲದೆ, ಪ್ರತಿ ಬ್ಯಾಕೆಂಡ್ ಬಿಲ್ಡ್ 14 ನಿಮಿಷಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು.
ಕೊನೆಯಲ್ಲಿ, ನಾವು ಇನ್ನು ಮುಂದೆ ಈ ರೀತಿ ಬದುಕಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ಸ್ಪಷ್ಟವಾಯಿತು ಮತ್ತು ಚಿತ್ರಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಏಕೆ ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತಿದೆ ಎಂದು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ನಾವು ಕುಳಿತಿದ್ದೇವೆ. ಪರಿಣಾಮವಾಗಿ, ನಾವು ಅಸೆಂಬ್ಲಿ ಸಮಯವನ್ನು 30 ಸೆಕೆಂಡುಗಳಿಗೆ ಕಡಿಮೆ ಮಾಡಲು ನಿರ್ವಹಿಸುತ್ತಿದ್ದೇವೆ!
ಈ ಲೇಖನಕ್ಕಾಗಿ, ರಿಮೈಂಡರ್ನ ಪರಿಸರಕ್ಕೆ ಸಂಬಂಧಿಸದಿರಲು, ಖಾಲಿ ಕೋನೀಯ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಜೋಡಿಸುವ ಉದಾಹರಣೆಯನ್ನು ನೋಡೋಣ. ಆದ್ದರಿಂದ, ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ರಚಿಸೋಣ:
ng n app
ಅದಕ್ಕೆ PWA ಸೇರಿಸಿ (ನಾವು ಪ್ರಗತಿಪರರು):
ng add @angular/pwa --project app
ಒಂದು ಮಿಲಿಯನ್ npm ಪ್ಯಾಕೇಜ್ಗಳನ್ನು ಡೌನ್ಲೋಡ್ ಮಾಡುತ್ತಿರುವಾಗ, ಡಾಕರ್ ಚಿತ್ರವು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡೋಣ. ಡಾಕರ್ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ಪ್ಯಾಕೇಜ್ ಮಾಡುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಒದಗಿಸುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಕಂಟೇನರ್ ಎಂದು ಕರೆಯಲಾಗುವ ಪ್ರತ್ಯೇಕ ಪರಿಸರದಲ್ಲಿ ರನ್ ಮಾಡುತ್ತದೆ. ಪ್ರತ್ಯೇಕತೆಗೆ ಧನ್ಯವಾದಗಳು, ನೀವು ಒಂದು ಸರ್ವರ್ನಲ್ಲಿ ಏಕಕಾಲದಲ್ಲಿ ಅನೇಕ ಕಂಟೇನರ್ಗಳನ್ನು ಚಲಾಯಿಸಬಹುದು. ಕಂಟೈನರ್ಗಳು ವರ್ಚುವಲ್ ಯಂತ್ರಗಳಿಗಿಂತ ಹೆಚ್ಚು ಹಗುರವಾಗಿರುತ್ತವೆ ಏಕೆಂದರೆ ಅವು ನೇರವಾಗಿ ಸಿಸ್ಟಮ್ ಕರ್ನಲ್ನಲ್ಲಿ ಚಲಿಸುತ್ತವೆ. ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ನೊಂದಿಗೆ ಕಂಟೇನರ್ ಅನ್ನು ಚಲಾಯಿಸಲು, ನಾವು ಮೊದಲು ಚಿತ್ರವನ್ನು ರಚಿಸಬೇಕಾಗಿದೆ ಅದರಲ್ಲಿ ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ರನ್ ಆಗಲು ಅಗತ್ಯವಿರುವ ಎಲ್ಲವನ್ನೂ ನಾವು ಪ್ಯಾಕೇಜ್ ಮಾಡುತ್ತೇವೆ. ಮೂಲಭೂತವಾಗಿ, ಚಿತ್ರವು ಫೈಲ್ ಸಿಸ್ಟಮ್ನ ನಕಲು ಆಗಿದೆ. ಉದಾಹರಣೆಗೆ, ಡಾಕರ್ಫೈಲ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ:
FROM node:12.16.2
WORKDIR /app
COPY . .
RUN npm ci
RUN npm run build --prod
ಡಾಕರ್ಫೈಲ್ ಎನ್ನುವುದು ಸೂಚನೆಗಳ ಗುಂಪಾಗಿದೆ; ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದನ್ನು ಮಾಡುವ ಮೂಲಕ, ಡಾಕರ್ ಬದಲಾವಣೆಗಳನ್ನು ಫೈಲ್ ಸಿಸ್ಟಮ್ಗೆ ಉಳಿಸುತ್ತದೆ ಮತ್ತು ಹಿಂದಿನವುಗಳಲ್ಲಿ ಅವುಗಳನ್ನು ಒವರ್ಲೇ ಮಾಡುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ತಂಡವು ತನ್ನದೇ ಆದ ಪದರವನ್ನು ರಚಿಸುತ್ತದೆ. ಮತ್ತು ಮುಗಿದ ಚಿತ್ರವು ಪದರಗಳನ್ನು ಒಟ್ಟಿಗೆ ಸಂಯೋಜಿಸಲಾಗಿದೆ.
ತಿಳಿಯುವುದು ಮುಖ್ಯ: ಪ್ರತಿ ಡಾಕರ್ ಲೇಯರ್ ಕ್ಯಾಶ್ ಮಾಡಬಹುದು. ಕೊನೆಯ ನಿರ್ಮಾಣದ ನಂತರ ಏನೂ ಬದಲಾಗದಿದ್ದರೆ, ಆಜ್ಞೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಬದಲು, ಡಾಕರ್ ರೆಡಿಮೇಡ್ ಲೇಯರ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಸಂಗ್ರಹದ ಬಳಕೆಯಿಂದಾಗಿ ನಿರ್ಮಾಣ ವೇಗದಲ್ಲಿ ಮುಖ್ಯ ಹೆಚ್ಚಳವಾಗುವುದರಿಂದ, ನಿರ್ಮಾಣ ವೇಗವನ್ನು ಅಳೆಯುವಾಗ ನಾವು ನಿರ್ದಿಷ್ಟವಾಗಿ ಸಿದ್ಧಪಡಿಸಿದ ಸಂಗ್ರಹದೊಂದಿಗೆ ಚಿತ್ರವನ್ನು ನಿರ್ಮಿಸಲು ಗಮನ ಹರಿಸುತ್ತೇವೆ. ಆದ್ದರಿಂದ, ಹಂತ ಹಂತವಾಗಿ:
- ಹಿಂದಿನ ರನ್ಗಳು ಪರೀಕ್ಷೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರದಂತೆ ನಾವು ಚಿತ್ರಗಳನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಅಳಿಸುತ್ತೇವೆ.
docker rmi $(docker images -q)
- ನಾವು ಮೊದಲ ಬಾರಿಗೆ ನಿರ್ಮಾಣವನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ.
time docker build -t app .
- ನಾವು src/index.html ಫೈಲ್ ಅನ್ನು ಬದಲಾಯಿಸುತ್ತೇವೆ - ನಾವು ಪ್ರೋಗ್ರಾಮರ್ನ ಕೆಲಸವನ್ನು ಅನುಕರಿಸುತ್ತೇವೆ.
- ನಾವು ಎರಡನೇ ಬಾರಿಗೆ ನಿರ್ಮಾಣವನ್ನು ನಡೆಸುತ್ತೇವೆ.
time docker build -t app .
ಚಿತ್ರಗಳನ್ನು ನಿರ್ಮಿಸಲು ಪರಿಸರವನ್ನು ಸರಿಯಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದರೆ (ಕೆಳಗೆ ಇನ್ನಷ್ಟು), ನಂತರ ಬಿಲ್ಡ್ ಪ್ರಾರಂಭವಾದಾಗ, ಡಾಕರ್ ಈಗಾಗಲೇ ಬೋರ್ಡ್ನಲ್ಲಿ ಸಂಗ್ರಹಗಳ ಗುಂಪನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಸಂಗ್ರಹವನ್ನು ಹೇಗೆ ಬಳಸುವುದು ಎಂಬುದನ್ನು ಕಲಿಯುವುದು ನಮ್ಮ ಕಾರ್ಯವಾಗಿದೆ, ಇದರಿಂದಾಗಿ ನಿರ್ಮಾಣವು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಹೋಗುತ್ತದೆ. ಸಂಗ್ರಹವಿಲ್ಲದೆ ಬಿಲ್ಡ್ ಅನ್ನು ಚಾಲನೆ ಮಾಡುವುದು ಒಮ್ಮೆ ಮಾತ್ರ ಸಂಭವಿಸುತ್ತದೆ ಎಂದು ನಾವು ಊಹಿಸುತ್ತಿರುವುದರಿಂದ-ಮೊದಲ ಬಾರಿಗೆ-ಆದ್ದರಿಂದ ಮೊದಲ ಬಾರಿಗೆ ಎಷ್ಟು ನಿಧಾನವಾಗಿತ್ತು ಎಂಬುದನ್ನು ನಾವು ನಿರ್ಲಕ್ಷಿಸಬಹುದು. ಪರೀಕ್ಷೆಗಳಲ್ಲಿ, ಸಂಗ್ರಹಗಳು ಈಗಾಗಲೇ ಬೆಚ್ಚಗಾಗುವಾಗ ಮತ್ತು ನಮ್ಮ ಕೇಕ್ ಅನ್ನು ತಯಾರಿಸಲು ನಾವು ಸಿದ್ಧರಾಗಿರುವಾಗ, ನಿರ್ಮಾಣದ ಎರಡನೇ ರನ್ ನಮಗೆ ಮುಖ್ಯವಾಗಿದೆ. ಆದಾಗ್ಯೂ, ಕೆಲವು ಸಲಹೆಗಳು ಮೊದಲ ನಿರ್ಮಾಣದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ.
ಪ್ರಾಜೆಕ್ಟ್ ಫೋಲ್ಡರ್ನಲ್ಲಿ ಮೇಲೆ ವಿವರಿಸಿದ ಡಾಕರ್ಫೈಲ್ ಅನ್ನು ಹಾಕೋಣ ಮತ್ತು ನಿರ್ಮಾಣವನ್ನು ಪ್ರಾರಂಭಿಸೋಣ. ಓದಲು ಸುಲಭವಾಗುವಂತೆ ಎಲ್ಲಾ ಪಟ್ಟಿಗಳನ್ನು ಮಂದಗೊಳಿಸಲಾಗಿದೆ.
$ time docker build -t app .
Sending build context to Docker daemon 409MB
Step 1/5 : FROM node:12.16.2
Status: Downloaded newer image for node:12.16.2
Step 2/5 : WORKDIR /app
Step 3/5 : COPY . .
Step 4/5 : RUN npm ci
added 1357 packages in 22.47s
Step 5/5 : RUN npm run build --prod
Date: 2020-04-16T19:20:09.664Z - Hash: fffa0fddaa3425c55dd3 - Time: 37581ms
Successfully built c8c279335f46
Successfully tagged app:latest
real 5m4.541s
user 0m0.000s
sys 0m0.000s
ನಾವು src/index.html ನ ವಿಷಯಗಳನ್ನು ಬದಲಾಯಿಸುತ್ತೇವೆ ಮತ್ತು ಅದನ್ನು ಎರಡನೇ ಬಾರಿಗೆ ರನ್ ಮಾಡುತ್ತೇವೆ.
$ time docker build -t app .
Sending build context to Docker daemon 409MB
Step 1/5 : FROM node:12.16.2
Step 2/5 : WORKDIR /app
---> Using cache
Step 3/5 : COPY . .
Step 4/5 : RUN npm ci
added 1357 packages in 22.47s
Step 5/5 : RUN npm run build --prod
Date: 2020-04-16T19:26:26.587Z - Hash: fffa0fddaa3425c55dd3 - Time: 37902ms
Successfully built 79f335df92d3
Successfully tagged app:latest
real 3m33.262s
user 0m0.000s
sys 0m0.000s
ನಾವು ಚಿತ್ರವನ್ನು ಹೊಂದಿದ್ದೇವೆಯೇ ಎಂದು ನೋಡಲು, ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸಿ docker images
:
REPOSITORY TAG IMAGE ID CREATED SIZE
app latest 79f335df92d3 About a minute ago 1.74GB
ನಿರ್ಮಿಸುವ ಮೊದಲು, ಡಾಕರ್ ಪ್ರಸ್ತುತ ಸಂದರ್ಭದಲ್ಲಿ ಎಲ್ಲಾ ಫೈಲ್ಗಳನ್ನು ತೆಗೆದುಕೊಂಡು ತನ್ನ ಡೀಮನ್ಗೆ ಕಳುಹಿಸುತ್ತಾನೆ Sending build context to Docker daemon 409MB
. ಬಿಲ್ಡ್ ಕಮಾಂಡ್ಗೆ ಕೊನೆಯ ಆರ್ಗ್ಯುಮೆಂಟ್ ಆಗಿ ಬಿಲ್ಡ್ ಕಾಂಟೆಕ್ಸ್ಟ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿದೆ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಇದು ಪ್ರಸ್ತುತ ಡೈರೆಕ್ಟರಿ - “.”, - ಮತ್ತು ಡಾಕರ್ ಈ ಫೋಲ್ಡರ್ನಲ್ಲಿ ನಾವು ಹೊಂದಿರುವ ಎಲ್ಲವನ್ನೂ ಎಳೆಯುತ್ತದೆ. 409 MB ಬಹಳಷ್ಟು ಆಗಿದೆ: ಅದನ್ನು ಹೇಗೆ ಸರಿಪಡಿಸುವುದು ಎಂದು ಯೋಚಿಸೋಣ.
ಸಂದರ್ಭವನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು
ಸಂದರ್ಭವನ್ನು ಕಡಿಮೆ ಮಾಡಲು, ಎರಡು ಆಯ್ಕೆಗಳಿವೆ. ಅಥವಾ ಜೋಡಣೆಗೆ ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಫೈಲ್ಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಫೋಲ್ಡರ್ನಲ್ಲಿ ಇರಿಸಿ ಮತ್ತು ಡಾಕರ್ ಸಂದರ್ಭವನ್ನು ಈ ಫೋಲ್ಡರ್ಗೆ ಸೂಚಿಸಿ. ಇದು ಯಾವಾಗಲೂ ಅನುಕೂಲಕರವಾಗಿಲ್ಲದಿರಬಹುದು, ಆದ್ದರಿಂದ ವಿನಾಯಿತಿಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಲು ಸಾಧ್ಯವಿದೆ: ಸಂದರ್ಭಕ್ಕೆ ಏನು ಎಳೆಯಬಾರದು. ಇದನ್ನು ಮಾಡಲು, ಯೋಜನೆಯಲ್ಲಿ .dockerignore ಫೈಲ್ ಅನ್ನು ಹಾಕಿ ಮತ್ತು ನಿರ್ಮಾಣಕ್ಕೆ ಏನು ಅಗತ್ಯವಿಲ್ಲ ಎಂಬುದನ್ನು ಸೂಚಿಸಿ:
.git
/node_modules
ಮತ್ತು ನಿರ್ಮಾಣವನ್ನು ಮತ್ತೆ ಚಲಾಯಿಸಿ:
$ time docker build -t app .
Sending build context to Docker daemon 607.2kB
Step 1/5 : FROM node:12.16.2
Step 2/5 : WORKDIR /app
---> Using cache
Step 3/5 : COPY . .
Step 4/5 : RUN npm ci
added 1357 packages in 22.47s
Step 5/5 : RUN npm run build --prod
Date: 2020-04-16T19:33:54.338Z - Hash: fffa0fddaa3425c55dd3 - Time: 37313ms
Successfully built 4942f010792a
Successfully tagged app:latest
real 1m47.763s
user 0m0.000s
sys 0m0.000s
607.2 KB 409 MB ಗಿಂತ ಉತ್ತಮವಾಗಿದೆ. ನಾವು ಚಿತ್ರದ ಗಾತ್ರವನ್ನು 1.74 ರಿಂದ 1.38 GB ಗೆ ಕಡಿಮೆಗೊಳಿಸಿದ್ದೇವೆ:
REPOSITORY TAG IMAGE ID CREATED SIZE
app latest 4942f010792a 3 minutes ago 1.38GB
ಚಿತ್ರದ ಗಾತ್ರವನ್ನು ಮತ್ತಷ್ಟು ಕಡಿಮೆ ಮಾಡಲು ಪ್ರಯತ್ನಿಸೋಣ.
ನಾವು ಆಲ್ಪೈನ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ
ಚಿತ್ರದ ಗಾತ್ರದಲ್ಲಿ ಉಳಿಸಲು ಇನ್ನೊಂದು ಮಾರ್ಗವೆಂದರೆ ಸಣ್ಣ ಪೋಷಕ ಚಿತ್ರವನ್ನು ಬಳಸುವುದು. ಪೋಷಕರ ಚಿತ್ರವು ನಮ್ಮ ಚಿತ್ರವನ್ನು ಸಿದ್ಧಪಡಿಸಿದ ಆಧಾರದ ಮೇಲೆ ಚಿತ್ರವಾಗಿದೆ. ಕೆಳಗಿನ ಪದರವನ್ನು ಆಜ್ಞೆಯಿಂದ ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿದೆ FROM
ಡಾಕರ್ಫೈಲ್ನಲ್ಲಿ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಈಗಾಗಲೇ ನೋಡೆಜ್ಗಳನ್ನು ಸ್ಥಾಪಿಸಿರುವ ಉಬುಂಟು ಆಧಾರಿತ ಚಿತ್ರವನ್ನು ಬಳಸುತ್ತಿದ್ದೇವೆ. ಮತ್ತು ಅದು ತೂಗುತ್ತದೆ ...
$ docker images -a | grep node
node 12.16.2 406aa3abbc6c 17 minutes ago 916MB
... ಸುಮಾರು ಒಂದು ಗಿಗಾಬೈಟ್. ಆಲ್ಪೈನ್ ಲಿನಕ್ಸ್ ಆಧಾರಿತ ಚಿತ್ರವನ್ನು ಬಳಸಿಕೊಂಡು ನೀವು ಪರಿಮಾಣವನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡಬಹುದು. ಆಲ್ಪೈನ್ ಬಹಳ ಚಿಕ್ಕ ಲಿನಕ್ಸ್ ಆಗಿದೆ. ಆಲ್ಪೈನ್ ಆಧಾರಿತ ನೋಡ್ಗಳ ಡಾಕರ್ ಚಿತ್ರವು ಕೇವಲ 88.5 MB ತೂಗುತ್ತದೆ. ಆದ್ದರಿಂದ ಮನೆಗಳಲ್ಲಿ ನಮ್ಮ ಉತ್ಸಾಹಭರಿತ ಚಿತ್ರವನ್ನು ಬದಲಾಯಿಸೋಣ:
FROM node:12.16.2-alpine3.11
RUN apk --no-cache --update --virtual build-dependencies add
python
make
g++
WORKDIR /app
COPY . .
RUN npm ci
RUN npm run build --prod
ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿರ್ಮಿಸಲು ಅಗತ್ಯವಿರುವ ಕೆಲವು ವಿಷಯಗಳನ್ನು ನಾವು ಸ್ಥಾಪಿಸಬೇಕಾಗಿದೆ. ಹೌದು, ಪೈಥಾನ್ ¯(°_o)/¯ ಇಲ್ಲದೆ ಕೋನೀಯ ರಚನೆಯಾಗುವುದಿಲ್ಲ
ಆದರೆ ಚಿತ್ರದ ಗಾತ್ರವು 150 MB ಗೆ ಇಳಿದಿದೆ:
REPOSITORY TAG IMAGE ID CREATED SIZE
app latest aa031edc315a 22 minutes ago 761MB
ಇನ್ನೂ ಮುಂದೆ ಹೋಗೋಣ.
ಬಹು ಹಂತದ ಜೋಡಣೆ
ಚಿತ್ರದಲ್ಲಿ ಇರುವುದೆಲ್ಲವೂ ನಿರ್ಮಾಣದಲ್ಲಿ ನಮಗೆ ಬೇಕಿಲ್ಲ.
$ docker run app ls -lah
total 576K
drwxr-xr-x 1 root root 4.0K Apr 16 19:54 .
drwxr-xr-x 1 root root 4.0K Apr 16 20:00 ..
-rwxr-xr-x 1 root root 19 Apr 17 2020 .dockerignore
-rwxr-xr-x 1 root root 246 Apr 17 2020 .editorconfig
-rwxr-xr-x 1 root root 631 Apr 17 2020 .gitignore
-rwxr-xr-x 1 root root 181 Apr 17 2020 Dockerfile
-rwxr-xr-x 1 root root 1020 Apr 17 2020 README.md
-rwxr-xr-x 1 root root 3.6K Apr 17 2020 angular.json
-rwxr-xr-x 1 root root 429 Apr 17 2020 browserslist
drwxr-xr-x 3 root root 4.0K Apr 16 19:54 dist
drwxr-xr-x 3 root root 4.0K Apr 17 2020 e2e
-rwxr-xr-x 1 root root 1015 Apr 17 2020 karma.conf.js
-rwxr-xr-x 1 root root 620 Apr 17 2020 ngsw-config.json
drwxr-xr-x 1 root root 4.0K Apr 16 19:54 node_modules
-rwxr-xr-x 1 root root 494.9K Apr 17 2020 package-lock.json
-rwxr-xr-x 1 root root 1.3K Apr 17 2020 package.json
drwxr-xr-x 5 root root 4.0K Apr 17 2020 src
-rwxr-xr-x 1 root root 210 Apr 17 2020 tsconfig.app.json
-rwxr-xr-x 1 root root 489 Apr 17 2020 tsconfig.json
-rwxr-xr-x 1 root root 270 Apr 17 2020 tsconfig.spec.json
-rwxr-xr-x 1 root root 1.9K Apr 17 2020 tslint.json
ಸಹಾಯದಿಂದ docker run app ls -lah
ನಮ್ಮ ಚಿತ್ರವನ್ನು ಆಧರಿಸಿ ನಾವು ಕಂಟೇನರ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ app
ಮತ್ತು ಅದರಲ್ಲಿ ಆಜ್ಞೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದರು ls -lah
, ಅದರ ನಂತರ ಕಂಟೇನರ್ ತನ್ನ ಕೆಲಸವನ್ನು ಪೂರ್ಣಗೊಳಿಸಿತು.
ಉತ್ಪಾದನೆಯಲ್ಲಿ ನಮಗೆ ಫೋಲ್ಡರ್ ಮಾತ್ರ ಬೇಕಾಗುತ್ತದೆ dist
. ಹೀಗಿರುವಾಗ ಕಡತಗಳನ್ನು ಹೇಗೋ ಹೊರಗೆ ಕೊಡಬೇಕಾಗುತ್ತದೆ. ನೀವು ನೋಡ್ಗಳಲ್ಲಿ ಕೆಲವು HTTP ಸರ್ವರ್ ಅನ್ನು ಚಲಾಯಿಸಬಹುದು. ಆದರೆ ನಾವು ಅದನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತೇವೆ. "y" ಎಂಬ ನಾಲ್ಕು ಅಕ್ಷರಗಳನ್ನು ಹೊಂದಿರುವ ರಷ್ಯಾದ ಪದವನ್ನು ಊಹಿಸಿ. ಸರಿ! Ynzhynyksy. nginx ನೊಂದಿಗೆ ಚಿತ್ರವನ್ನು ತೆಗೆದುಕೊಳ್ಳೋಣ, ಅದರಲ್ಲಿ ಫೋಲ್ಡರ್ ಅನ್ನು ಇರಿಸಿ dist
ಮತ್ತು ಸಣ್ಣ ಸಂರಚನೆ:
server {
listen 80 default_server;
server_name localhost;
charset utf-8;
root /app/dist;
location / {
try_files $uri $uri/ /index.html;
}
}
ಬಹು-ಹಂತದ ನಿರ್ಮಾಣವು ಇದೆಲ್ಲವನ್ನೂ ಮಾಡಲು ನಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ನಮ್ಮ ಡಾಕರ್ಫೈಲ್ ಅನ್ನು ಬದಲಾಯಿಸೋಣ:
FROM node:12.16.2-alpine3.11 as builder
RUN apk --no-cache --update --virtual build-dependencies add
python
make
g++
WORKDIR /app
COPY . .
RUN npm ci
RUN npm run build --prod
FROM nginx:1.17.10-alpine
RUN rm /etc/nginx/conf.d/default.conf
COPY nginx/static.conf /etc/nginx/conf.d
COPY --from=builder /app/dist/app .
ಈಗ ನಮಗೆ ಎರಡು ಸೂಚನೆಗಳಿವೆ FROM
ಡಾಕರ್ಫೈಲ್ನಲ್ಲಿ, ಪ್ರತಿಯೊಂದೂ ವಿಭಿನ್ನ ನಿರ್ಮಾಣ ಹಂತವನ್ನು ನಡೆಸುತ್ತದೆ. ನಾವು ಮೊದಲನೆಯವರನ್ನು ಕರೆದಿದ್ದೇವೆ builder
, ಆದರೆ ಕೊನೆಯದರಿಂದ ಪ್ರಾರಂಭಿಸಿ, ನಮ್ಮ ಅಂತಿಮ ಚಿತ್ರವನ್ನು ಸಿದ್ಧಪಡಿಸಲಾಗುತ್ತದೆ. ಹಿಂದಿನ ಹಂತದಲ್ಲಿ ನಮ್ಮ ಅಸೆಂಬ್ಲಿಯ ಕಲಾಕೃತಿಯನ್ನು nginx ನೊಂದಿಗೆ ಅಂತಿಮ ಚಿತ್ರಕ್ಕೆ ನಕಲಿಸುವುದು ಕೊನೆಯ ಹಂತವಾಗಿದೆ. ಚಿತ್ರದ ಗಾತ್ರವು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆಯಾಗಿದೆ:
REPOSITORY TAG IMAGE ID CREATED SIZE
app latest 2c6c5da07802 29 minutes ago 36MB
ನಮ್ಮ ಚಿತ್ರದೊಂದಿಗೆ ಕಂಟೇನರ್ ಅನ್ನು ರನ್ ಮಾಡೋಣ ಮತ್ತು ಎಲ್ಲವೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ:
docker run -p8080:80 app
-p8080:80 ಆಯ್ಕೆಯನ್ನು ಬಳಸಿಕೊಂಡು, ನಾವು ನಮ್ಮ ಹೋಸ್ಟ್ ಯಂತ್ರದಲ್ಲಿ ಪೋರ್ಟ್ 8080 ಅನ್ನು nginx ರನ್ ಆಗಿರುವ ಕಂಟೇನರ್ ಒಳಗೆ ಪೋರ್ಟ್ 80 ಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡಿದ್ದೇವೆ. ಬ್ರೌಸರ್ ತೆರೆಯಿರಿ
ಚಿತ್ರದ ಗಾತ್ರವನ್ನು 1.74 GB ಯಿಂದ 36 MB ಗೆ ಕಡಿಮೆ ಮಾಡುವುದರಿಂದ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಉತ್ಪಾದನೆಗೆ ತಲುಪಿಸಲು ತೆಗೆದುಕೊಳ್ಳುವ ಸಮಯವನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಆದರೆ ಅಸೆಂಬ್ಲಿ ಸಮಯಕ್ಕೆ ಹಿಂತಿರುಗಿ ನೋಡೋಣ.
$ time docker build -t app .
Sending build context to Docker daemon 608.8kB
Step 1/11 : FROM node:12.16.2-alpine3.11 as builder
Step 2/11 : RUN apk --no-cache --update --virtual build-dependencies add python make g++
---> Using cache
Step 3/11 : WORKDIR /app
---> Using cache
Step 4/11 : COPY . .
Step 5/11 : RUN npm ci
added 1357 packages in 47.338s
Step 6/11 : RUN npm run build --prod
Date: 2020-04-16T21:16:03.899Z - Hash: fffa0fddaa3425c55dd3 - Time: 39948ms
---> 27f1479221e4
Step 7/11 : FROM nginx:stable-alpine
Step 8/11 : WORKDIR /app
---> Using cache
Step 9/11 : RUN rm /etc/nginx/conf.d/default.conf
---> Using cache
Step 10/11 : COPY nginx/static.conf /etc/nginx/conf.d
---> Using cache
Step 11/11 : COPY --from=builder /app/dist/app .
Successfully built d201471c91ad
Successfully tagged app:latest
real 2m17.700s
user 0m0.000s
sys 0m0.000s
ಪದರಗಳ ಕ್ರಮವನ್ನು ಬದಲಾಯಿಸುವುದು
ನಮ್ಮ ಮೊದಲ ಮೂರು ಹಂತಗಳನ್ನು ಸಂಗ್ರಹಿಸಲಾಗಿದೆ (ಸುಳಿವು Using cache
) ನಾಲ್ಕನೇ ಹಂತದಲ್ಲಿ, ಎಲ್ಲಾ ಪ್ರಾಜೆಕ್ಟ್ ಫೈಲ್ಗಳನ್ನು ನಕಲಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಐದನೇ ಹಂತದಲ್ಲಿ ಅವಲಂಬನೆಗಳನ್ನು ಸ್ಥಾಪಿಸಲಾಗುತ್ತದೆ RUN npm ci
- 47.338 ಸೆ. ಅವಲಂಬನೆಗಳು ಬಹಳ ವಿರಳವಾಗಿ ಬದಲಾದರೆ ಪ್ರತಿ ಬಾರಿ ಮರುಸ್ಥಾಪಿಸುವುದು ಏಕೆ? ಅವುಗಳನ್ನು ಏಕೆ ಸಂಗ್ರಹಿಸಲಾಗಿಲ್ಲ ಎಂದು ಲೆಕ್ಕಾಚಾರ ಮಾಡೋಣ. ಕಮಾಂಡ್ ಮತ್ತು ಅದಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಫೈಲ್ಗಳು ಬದಲಾಗಿದೆಯೇ ಎಂದು ನೋಡಲು ಡಾಕರ್ ಲೇಯರ್ ಮೂಲಕ ಲೇಯರ್ ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ. ನಾಲ್ಕನೇ ಹಂತದಲ್ಲಿ, ನಾವು ನಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್ನ ಎಲ್ಲಾ ಫೈಲ್ಗಳನ್ನು ನಕಲಿಸುತ್ತೇವೆ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಬದಲಾವಣೆಗಳಿವೆ, ಆದ್ದರಿಂದ ಡಾಕರ್ ಈ ಪದರವನ್ನು ಸಂಗ್ರಹದಿಂದ ತೆಗೆದುಕೊಳ್ಳುವುದಿಲ್ಲ, ಆದರೆ ನಂತರದ ಎಲ್ಲವುಗಳೂ ಸಹ! ಡಾಕರ್ಫೈಲ್ಗೆ ಕೆಲವು ಸಣ್ಣ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡೋಣ.
FROM node:12.16.2-alpine3.11 as builder
RUN apk --no-cache --update --virtual build-dependencies add
python
make
g++
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build --prod
FROM nginx:1.17.10-alpine
RUN rm /etc/nginx/conf.d/default.conf
COPY nginx/static.conf /etc/nginx/conf.d
COPY --from=builder /app/dist/app .
ಮೊದಲಿಗೆ, package.json ಮತ್ತು pack-lock.json ಅನ್ನು ನಕಲಿಸಲಾಗುತ್ತದೆ, ನಂತರ ಅವಲಂಬನೆಗಳನ್ನು ಸ್ಥಾಪಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಅದರ ನಂತರ ಮಾತ್ರ ಸಂಪೂರ್ಣ ಯೋಜನೆಯನ್ನು ನಕಲಿಸಲಾಗುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ:
$ time docker build -t app .
Sending build context to Docker daemon 608.8kB
Step 1/12 : FROM node:12.16.2-alpine3.11 as builder
Step 2/12 : RUN apk --no-cache --update --virtual build-dependencies add python make g++
---> Using cache
Step 3/12 : WORKDIR /app
---> Using cache
Step 4/12 : COPY package*.json ./
---> Using cache
Step 5/12 : RUN npm ci
---> Using cache
Step 6/12 : COPY . .
Step 7/12 : RUN npm run build --prod
Date: 2020-04-16T21:29:44.770Z - Hash: fffa0fddaa3425c55dd3 - Time: 38287ms
---> 1b9448c73558
Step 8/12 : FROM nginx:stable-alpine
Step 9/12 : WORKDIR /app
---> Using cache
Step 10/12 : RUN rm /etc/nginx/conf.d/default.conf
---> Using cache
Step 11/12 : COPY nginx/static.conf /etc/nginx/conf.d
---> Using cache
Step 12/12 : COPY --from=builder /app/dist/app .
Successfully built a44dd7c217c3
Successfully tagged app:latest
real 0m46.497s
user 0m0.000s
sys 0m0.000s
46 ನಿಮಿಷಗಳ ಬದಲಿಗೆ 3 ಸೆಕೆಂಡುಗಳು - ಹೆಚ್ಚು ಉತ್ತಮ! ಪದರಗಳ ಸರಿಯಾದ ಕ್ರಮವು ಮುಖ್ಯವಾಗಿದೆ: ಮೊದಲು ನಾವು ಏನನ್ನು ಬದಲಾಯಿಸುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ನಕಲಿಸುತ್ತೇವೆ, ನಂತರ ಯಾವುದು ಅಪರೂಪವಾಗಿ ಬದಲಾಗುತ್ತದೆ ಮತ್ತು ಅಂತಿಮವಾಗಿ ಆಗಾಗ್ಗೆ ಬದಲಾಗುತ್ತದೆ.
ಮುಂದೆ, CI/CD ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಚಿತ್ರಗಳನ್ನು ಜೋಡಿಸುವ ಕುರಿತು ಕೆಲವು ಪದಗಳು.
ಸಂಗ್ರಹಕ್ಕಾಗಿ ಹಿಂದಿನ ಚಿತ್ರಗಳನ್ನು ಬಳಸುವುದು
ನಿರ್ಮಾಣಕ್ಕಾಗಿ ನಾವು ಕೆಲವು ರೀತಿಯ SaaS ಪರಿಹಾರವನ್ನು ಬಳಸಿದರೆ, ಸ್ಥಳೀಯ ಡಾಕರ್ ಸಂಗ್ರಹವು ಸ್ವಚ್ಛ ಮತ್ತು ತಾಜಾವಾಗಿರಬಹುದು. ಬೇಯಿಸಿದ ಪದರಗಳನ್ನು ಪಡೆಯಲು ಡಾಕರ್ಗೆ ಸ್ಥಳವನ್ನು ನೀಡಲು, ಅವನಿಗೆ ಹಿಂದಿನ ನಿರ್ಮಿಸಿದ ಚಿತ್ರವನ್ನು ನೀಡಿ.
GitHub ಕ್ರಿಯೆಗಳಲ್ಲಿ ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿರ್ಮಿಸುವ ಉದಾಹರಣೆಯನ್ನು ತೆಗೆದುಕೊಳ್ಳೋಣ. ನಾವು ಈ ಸಂರಚನೆಯನ್ನು ಬಳಸುತ್ತೇವೆ
on:
push:
branches:
- master
name: Test docker build
jobs:
deploy:
name: Build
runs-on: ubuntu-latest
env:
IMAGE_NAME: docker.pkg.github.com/${{ github.repository }}/app
IMAGE_TAG: ${{ github.sha }}
steps:
- name: Checkout
uses: actions/checkout@v2
- name: Login to GitHub Packages
env:
TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
docker login docker.pkg.github.com -u $GITHUB_ACTOR -p $TOKEN
- name: Build
run: |
docker build
-t $IMAGE_NAME:$IMAGE_TAG
-t $IMAGE_NAME:latest
.
- name: Push image to GitHub Packages
run: |
docker push $IMAGE_NAME:latest
docker push $IMAGE_NAME:$IMAGE_TAG
- name: Logout
run: |
docker logout docker.pkg.github.com
ಚಿತ್ರವನ್ನು ಎರಡು ನಿಮಿಷ ಮತ್ತು 20 ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಜೋಡಿಸಲಾಗಿದೆ ಮತ್ತು GitHub ಪ್ಯಾಕೇಜುಗಳಿಗೆ ತಳ್ಳಲಾಗುತ್ತದೆ:
ಈಗ ನಾವು ಬಿಲ್ಡ್ ಅನ್ನು ಬದಲಾಯಿಸೋಣ ಆದ್ದರಿಂದ ಹಿಂದಿನ ನಿರ್ಮಿಸಿದ ಚಿತ್ರಗಳ ಆಧಾರದ ಮೇಲೆ ಸಂಗ್ರಹವನ್ನು ಬಳಸಲಾಗುತ್ತದೆ:
on:
push:
branches:
- master
name: Test docker build
jobs:
deploy:
name: Build
runs-on: ubuntu-latest
env:
IMAGE_NAME: docker.pkg.github.com/${{ github.repository }}/app
IMAGE_TAG: ${{ github.sha }}
steps:
- name: Checkout
uses: actions/checkout@v2
- name: Login to GitHub Packages
env:
TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
docker login docker.pkg.github.com -u $GITHUB_ACTOR -p $TOKEN
- name: Pull latest images
run: |
docker pull $IMAGE_NAME:latest || true
docker pull $IMAGE_NAME-builder-stage:latest || true
- name: Images list
run: |
docker images
- name: Build
run: |
docker build
--target builder
--cache-from $IMAGE_NAME-builder-stage:latest
-t $IMAGE_NAME-builder-stage
.
docker build
--cache-from $IMAGE_NAME-builder-stage:latest
--cache-from $IMAGE_NAME:latest
-t $IMAGE_NAME:$IMAGE_TAG
-t $IMAGE_NAME:latest
.
- name: Push image to GitHub Packages
run: |
docker push $IMAGE_NAME-builder-stage:latest
docker push $IMAGE_NAME:latest
docker push $IMAGE_NAME:$IMAGE_TAG
- name: Logout
run: |
docker logout docker.pkg.github.com
ಎರಡು ಆಜ್ಞೆಗಳನ್ನು ಏಕೆ ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ ಎಂದು ನಾವು ಮೊದಲು ಹೇಳಬೇಕಾಗಿದೆ build
. ವಾಸ್ತವವೆಂದರೆ ಮಲ್ಟಿಸ್ಟೇಜ್ ಅಸೆಂಬ್ಲಿಯಲ್ಲಿ ಪರಿಣಾಮವಾಗಿ ಚಿತ್ರವು ಕೊನೆಯ ಹಂತದಿಂದ ಪದರಗಳ ಗುಂಪಾಗಿರುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಹಿಂದಿನ ಲೇಯರ್ಗಳಿಂದ ಲೇಯರ್ಗಳನ್ನು ಚಿತ್ರದಲ್ಲಿ ಸೇರಿಸಲಾಗುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, ಹಿಂದಿನ ಬಿಲ್ಡ್ನಿಂದ ಅಂತಿಮ ಚಿತ್ರವನ್ನು ಬಳಸುವಾಗ, ನೋಡೆಜ್ಗಳೊಂದಿಗೆ (ಬಿಲ್ಡರ್ ಹಂತ) ಚಿತ್ರವನ್ನು ನಿರ್ಮಿಸಲು ಡಾಕರ್ ಸಿದ್ಧ ಲೇಯರ್ಗಳನ್ನು ಕಂಡುಹಿಡಿಯಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, ಮಧ್ಯಂತರ ಚಿತ್ರವನ್ನು ರಚಿಸಲಾಗಿದೆ $IMAGE_NAME-builder-stage
ಮತ್ತು ಅದನ್ನು GitHub ಪ್ಯಾಕೇಜುಗಳಿಗೆ ತಳ್ಳಲಾಗುತ್ತದೆ ಇದರಿಂದ ಅದನ್ನು ನಂತರದ ನಿರ್ಮಾಣದಲ್ಲಿ ಸಂಗ್ರಹ ಮೂಲವಾಗಿ ಬಳಸಬಹುದು.
ಒಟ್ಟು ಜೋಡಣೆಯ ಸಮಯವನ್ನು ಒಂದೂವರೆ ನಿಮಿಷಕ್ಕೆ ಇಳಿಸಲಾಯಿತು. ಹಿಂದಿನ ಚಿತ್ರಗಳನ್ನು ಎಳೆಯಲು ಅರ್ಧ ನಿಮಿಷವನ್ನು ಕಳೆಯಲಾಗುತ್ತದೆ.
ಪೂರ್ವ ಚಿತ್ರಣ
ಕ್ಲೀನ್ ಡಾಕರ್ ಸಂಗ್ರಹದ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಇನ್ನೊಂದು ಮಾರ್ಗವೆಂದರೆ ಕೆಲವು ಲೇಯರ್ಗಳನ್ನು ಮತ್ತೊಂದು ಡಾಕರ್ಫೈಲ್ಗೆ ಸರಿಸಿ, ಅದನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ನಿರ್ಮಿಸಿ, ಅದನ್ನು ಕಂಟೈನರ್ ರಿಜಿಸ್ಟ್ರಿಗೆ ತಳ್ಳುವುದು ಮತ್ತು ಅದನ್ನು ಪೋಷಕರಾಗಿ ಬಳಸುವುದು.
ಕೋನೀಯ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿರ್ಮಿಸಲು ನಾವು ನಮ್ಮದೇ ಆದ nodejs ಚಿತ್ರವನ್ನು ರಚಿಸುತ್ತೇವೆ. ಯೋಜನೆಯಲ್ಲಿ Dockerfile.node ಅನ್ನು ರಚಿಸಿ
FROM node:12.16.2-alpine3.11
RUN apk --no-cache --update --virtual build-dependencies add
python
make
g++
ನಾವು ಡಾಕರ್ ಹಬ್ನಲ್ಲಿ ಸಾರ್ವಜನಿಕ ಚಿತ್ರವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ ಮತ್ತು ತಳ್ಳುತ್ತೇವೆ:
docker build -t exsmund/node-for-angular -f Dockerfile.node .
docker push exsmund/node-for-angular:latest
ಈಗ ನಮ್ಮ ಮುಖ್ಯ ಡಾಕರ್ಫೈಲ್ನಲ್ಲಿ ನಾವು ಸಿದ್ಧಪಡಿಸಿದ ಚಿತ್ರವನ್ನು ಬಳಸುತ್ತೇವೆ:
FROM exsmund/node-for-angular:latest as builder
...
ನಮ್ಮ ಉದಾಹರಣೆಯಲ್ಲಿ, ನಿರ್ಮಾಣ ಸಮಯವು ಕಡಿಮೆಯಾಗುವುದಿಲ್ಲ, ಆದರೆ ನೀವು ಅನೇಕ ಯೋಜನೆಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದರಲ್ಲೂ ಒಂದೇ ಅವಲಂಬನೆಯನ್ನು ಸ್ಥಾಪಿಸಬೇಕಾದರೆ ಪೂರ್ವ-ನಿರ್ಮಿತ ಚಿತ್ರಗಳು ಉಪಯುಕ್ತವಾಗಬಹುದು.
ಡಾಕರ್ ಚಿತ್ರಗಳ ನಿರ್ಮಾಣವನ್ನು ವೇಗಗೊಳಿಸಲು ನಾವು ಹಲವಾರು ವಿಧಾನಗಳನ್ನು ನೋಡಿದ್ದೇವೆ. ನಿಯೋಜನೆಯು ತ್ವರಿತವಾಗಿ ನಡೆಯಬೇಕೆಂದು ನೀವು ಬಯಸಿದರೆ, ನಿಮ್ಮ ಯೋಜನೆಯಲ್ಲಿ ಇದನ್ನು ಬಳಸಲು ಪ್ರಯತ್ನಿಸಿ:
- ಸಂದರ್ಭವನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು;
- ಸಣ್ಣ ಪೋಷಕ ಚಿತ್ರಗಳ ಬಳಕೆ;
- ಬಹುಹಂತದ ಜೋಡಣೆ;
- ಸಂಗ್ರಹವನ್ನು ಸಮರ್ಥವಾಗಿ ಬಳಸಿಕೊಳ್ಳಲು ಡಾಕರ್ಫೈಲ್ನಲ್ಲಿನ ಸೂಚನೆಗಳ ಕ್ರಮವನ್ನು ಬದಲಾಯಿಸುವುದು;
- CI/CD ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಸಂಗ್ರಹವನ್ನು ಹೊಂದಿಸುವುದು;
- ಚಿತ್ರಗಳ ಪ್ರಾಥಮಿಕ ರಚನೆ.
ಡಾಕರ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಉದಾಹರಣೆಯು ಸ್ಪಷ್ಟಪಡಿಸುತ್ತದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ ಮತ್ತು ನಿಮ್ಮ ನಿಯೋಜನೆಯನ್ನು ನೀವು ಅತ್ಯುತ್ತಮವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಲೇಖನದ ಉದಾಹರಣೆಗಳೊಂದಿಗೆ ಆಟವಾಡಲು, ಭಂಡಾರವನ್ನು ರಚಿಸಲಾಗಿದೆ
ಮೂಲ: www.habr.com