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

ಈ ಕೆಲಸವು ವೆಬ್‌ಸೈಟ್‌ನಿಂದ ಪ್ರೇರಿತವಾಗಿದೆ kubernetes.io, ಇದು ಉತ್ಪತ್ತಿಯಾಗುತ್ತದೆ ಮೂಲ ಸಂಕೇತಗಳು ಸ್ವಯಂಚಾಲಿತವಾಗಿ, ಮತ್ತು ಕಳುಹಿಸಲಾದ ಪ್ರತಿ ಪೂಲ್ ವಿನಂತಿಗೆ, ರೋಬೋಟ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನಿಮ್ಮ ಬದಲಾವಣೆಗಳೊಂದಿಗೆ ಸೈಟ್‌ನ ಪೂರ್ವವೀಕ್ಷಣೆ ಆವೃತ್ತಿಯನ್ನು ರಚಿಸುತ್ತದೆ ಮತ್ತು ವೀಕ್ಷಣೆಗಾಗಿ ಲಿಂಕ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ.

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

ಲೇಖನವು ಅಂತಹ ಸಾಧನಗಳನ್ನು ಚರ್ಚಿಸುತ್ತದೆ:
ಹ್ಯೂಗೊ, qbec, ಕಣಿಕೋ, git-ಕ್ರಿಪ್ಟ್ и ಗಿಟ್ಲ್ಯಾಬ್ ಸಿಐ ಕ್ರಿಯಾತ್ಮಕ ಪರಿಸರಗಳ ರಚನೆಯೊಂದಿಗೆ.

ವಿಷಯ

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

1. ಹ್ಯೂಗೋವನ್ನು ತಿಳಿದುಕೊಳ್ಳುವುದು

ನಮ್ಮ ಯೋಜನೆಯ ಉದಾಹರಣೆಯಾಗಿ, ನಾವು ಹ್ಯೂಗೋದಲ್ಲಿ ನಿರ್ಮಿಸಲಾದ ದಸ್ತಾವೇಜನ್ನು ಪ್ರಕಟಿಸುವ ಸೈಟ್ ಅನ್ನು ರಚಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ. ಹ್ಯೂಗೋ ಸ್ಥಿರ ವಿಷಯ ಜನರೇಟರ್ ಆಗಿದೆ.

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

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

ನೀವು ಸ್ಥಳೀಯವಾಗಿ ಹ್ಯೂಗೋವನ್ನು ಸ್ಥಾಪಿಸಬಹುದು ಮತ್ತು ಇದನ್ನು ಪ್ರಯತ್ನಿಸಬಹುದು:

ಹೊಸ ಸೈಟ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತಿದೆ:

hugo new site docs.example.org

ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ಜಿಟ್ ರೆಪೊಸಿಟರಿ:

cd docs.example.org
git init

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

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

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

git submodule add https://github.com/matcornic/hugo-theme-learn themes/learn

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

ಸಂರಚನೆಯನ್ನು ಸರಿಪಡಿಸೋಣ config.toml:

baseURL = "http://docs.example.org/"
languageCode = "en-us"
title = "My Docs Site"
theme = "learn"

ಈಗಾಗಲೇ ಈ ಹಂತದಲ್ಲಿ ನೀವು ಚಲಾಯಿಸಬಹುದು:

hugo server

ಮತ್ತು ವಿಳಾಸದಲ್ಲಿ http://localhost:1313/ ನಮ್ಮ ಹೊಸದಾಗಿ ರಚಿಸಲಾದ ವೆಬ್‌ಸೈಟ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿ, ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಮಾಡಿದ ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳು ಬ್ರೌಸರ್‌ನಲ್ಲಿ ತೆರೆದ ಪುಟವನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನವೀಕರಿಸಿ, ತುಂಬಾ ಅನುಕೂಲಕರವಾಗಿದೆ!

ಕವರ್ ಪುಟವನ್ನು ರಚಿಸಲು ಪ್ರಯತ್ನಿಸೋಣ ವಿಷಯ/_index.md:

# My docs site

## Welcome to the docs!

You will be very smart :-)

ಹೊಸದಾಗಿ ರಚಿಸಲಾದ ಪುಟದ ಸ್ಕ್ರೀನ್‌ಶಾಟ್

ಸೈಟ್ ರಚಿಸಲು, ಕೇವಲ ರನ್ ಮಾಡಿ:

hugo

ಡೈರೆಕ್ಟರಿ ವಿಷಯಗಳು ಸಾರ್ವಜನಿಕ/ ಮತ್ತು ನಿಮ್ಮ ವೆಬ್‌ಸೈಟ್ ಆಗಿರುತ್ತದೆ.
ಹೌದು, ಮೂಲಕ, ಅದನ್ನು ತಕ್ಷಣವೇ ಸೇರಿಸೋಣ .ಗಿಟಿಗ್ನೋರ್:

echo /public > .gitignore

ನಮ್ಮ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲು ಮರೆಯಬೇಡಿ:

git add .
git commit -m "New site created"

2. ಡಾಕರ್‌ಫೈಲ್ ಅನ್ನು ಸಿದ್ಧಪಡಿಸುವುದು

ನಮ್ಮ ರೆಪೊಸಿಟರಿಯ ರಚನೆಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಲು ಇದು ಸಮಯ. ನಾನು ಸಾಮಾನ್ಯವಾಗಿ ಈ ರೀತಿಯದನ್ನು ಬಳಸುತ್ತೇನೆ:

.
├── deploy
│   ├── app1
│   └── app2
└── dockerfiles
    ├── image1
    └── image2

• ಡಾಕರ್ ಫೈಲ್ಸ್/ - ಡಾಕರ್‌ಫೈಲ್‌ಗಳೊಂದಿಗೆ ಡೈರೆಕ್ಟರಿಗಳನ್ನು ಮತ್ತು ನಮ್ಮ ಡಾಕರ್ ಚಿತ್ರಗಳನ್ನು ನಿರ್ಮಿಸಲು ಅಗತ್ಯವಿರುವ ಎಲ್ಲವನ್ನೂ ಒಳಗೊಂಡಿರುತ್ತದೆ.
• ನಿಯೋಜಿಸು/ - ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಕುಬರ್ನೆಟ್‌ಗಳಿಗೆ ನಿಯೋಜಿಸಲು ಡೈರೆಕ್ಟರಿಗಳನ್ನು ಒಳಗೊಂಡಿದೆ

ಹೀಗಾಗಿ, ನಾವು ಹಾದಿಯಲ್ಲಿ ನಮ್ಮ ಮೊದಲ ಡಾಕರ್‌ಫೈಲ್ ಅನ್ನು ರಚಿಸುತ್ತೇವೆ ಡಾಕರ್‌ಫೈಲ್‌ಗಳು/ವೆಬ್‌ಸೈಟ್/ಡಾಕರ್‌ಫೈಲ್

FROM alpine:3.11 as builder
ARG HUGO_VERSION=0.62.0
RUN wget -O- https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_${HUGO_VERSION}_linux-64bit.tar.gz | tar -xz -C /usr/local/bin
ADD . /src
RUN hugo -s /src

FROM alpine:3.11
RUN apk add --no-cache darkhttpd
COPY --from=builder /src/public /var/www
ENTRYPOINT [ "/usr/bin/darkhttpd" ]
CMD [ "/var/www" ]

ನೀವು ನೋಡುವಂತೆ, ಡಾಕರ್‌ಫೈಲ್ ಎರಡನ್ನು ಒಳಗೊಂಡಿದೆ FROM, ಈ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ ಬಹು ಹಂತದ ನಿರ್ಮಾಣ ಮತ್ತು ಅಂತಿಮ ಡಾಕರ್ ಚಿತ್ರದಿಂದ ಅನಗತ್ಯವಾದ ಎಲ್ಲವನ್ನೂ ಹೊರಗಿಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
ಹೀಗಾಗಿ, ಅಂತಿಮ ಚಿತ್ರವು ಮಾತ್ರ ಒಳಗೊಂಡಿರುತ್ತದೆ ಡಾರ್ಕ್httpd (ಹಗುರ HTTP ಸರ್ವರ್) ಮತ್ತು ಸಾರ್ವಜನಿಕ/ - ನಮ್ಮ ಸ್ಥಿರವಾಗಿ ರಚಿಸಲಾದ ವೆಬ್‌ಸೈಟ್‌ನ ವಿಷಯ.

ನಮ್ಮ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲು ಮರೆಯಬೇಡಿ:

git add dockerfiles/website
git commit -m "Add Dockerfile for website"

3. ಕನಿಕೊವನ್ನು ತಿಳಿದುಕೊಳ್ಳುವುದು

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

ಚಿತ್ರವನ್ನು ನಿರ್ಮಿಸಲು, ಕೇವಲ ಧಾರಕವನ್ನು ರನ್ ಮಾಡಿ ಕಾಣಿಕೋ ನಿರ್ವಾಹಕ ಮತ್ತು ಪ್ರಸ್ತುತ ನಿರ್ಮಾಣ ಸಂದರ್ಭವನ್ನು ರವಾನಿಸಿ; ಇದನ್ನು ಡಾಕರ್ ಮೂಲಕ ಸ್ಥಳೀಯವಾಗಿಯೂ ಮಾಡಬಹುದು:

docker run -ti --rm 
  -v $PWD:/workspace 
  -v ~/.docker/config.json:/kaniko/.docker/config.json:ro 
  gcr.io/kaniko-project/executor:v0.15.0 
  --cache 
  --dockerfile=dockerfiles/website/Dockerfile 
  --destination=registry.gitlab.com/kvaps/docs.example.org/website:v0.0.1

ಎಲ್ಲಿ registry.gitlab.com/kvaps/docs.example.org/website - ನಿಮ್ಮ ಡಾಕರ್ ಚಿತ್ರದ ಹೆಸರು; ನಿರ್ಮಿಸಿದ ನಂತರ, ಅದನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಡಾಕರ್ ರಿಜಿಸ್ಟ್ರಿಗೆ ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ.

ನಿಯತಾಂಕ --ಸಂಗ್ರಹ ಡಾಕರ್ ರಿಜಿಸ್ಟ್ರಿಯಲ್ಲಿ ಲೇಯರ್‌ಗಳನ್ನು ಕ್ಯಾಶ್ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ; ನೀಡಿರುವ ಉದಾಹರಣೆಗಾಗಿ, ಅವುಗಳನ್ನು ಉಳಿಸಲಾಗುತ್ತದೆ registry.gitlab.com/kvaps/docs.example.org/website/cache, ಆದರೆ ನೀವು ನಿಯತಾಂಕವನ್ನು ಬಳಸಿಕೊಂಡು ಇನ್ನೊಂದು ಮಾರ್ಗವನ್ನು ಸೂಚಿಸಬಹುದು --ಸಂಗ್ರಹ-ರೆಪೋ.

ಡಾಕರ್-ರಿಜಿಸ್ಟ್ರಿಯ ಸ್ಕ್ರೀನ್‌ಶಾಟ್

4. qbec ಅನ್ನು ತಿಳಿದುಕೊಳ್ಳುವುದು

Qbec ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಮ್ಯಾನಿಫೆಸ್ಟ್‌ಗಳನ್ನು ಘೋಷಣಾತ್ಮಕವಾಗಿ ವಿವರಿಸಲು ಮತ್ತು ಅವುಗಳನ್ನು ಕುಬರ್ನೆಟ್‌ಗಳಿಗೆ ನಿಯೋಜಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ನಿಯೋಜನೆ ಸಾಧನವಾಗಿದೆ. Jsonnet ಅನ್ನು ಮುಖ್ಯ ಸಿಂಟ್ಯಾಕ್ಸ್ ಆಗಿ ಬಳಸುವುದರಿಂದ ಬಹು ಪರಿಸರದಲ್ಲಿ ವ್ಯತ್ಯಾಸಗಳ ವಿವರಣೆಯನ್ನು ಹೆಚ್ಚು ಸರಳಗೊಳಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ ಮತ್ತು ಕೋಡ್ ಪುನರಾವರ್ತನೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತೆಗೆದುಹಾಕುತ್ತದೆ.

ನೀವು ವಿವಿಧ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳೊಂದಿಗೆ ಹಲವಾರು ಕ್ಲಸ್ಟರ್‌ಗಳಿಗೆ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿಯೋಜಿಸಲು ಮತ್ತು ಅವುಗಳನ್ನು Git ನಲ್ಲಿ ಘೋಷಣಾತ್ಮಕವಾಗಿ ವಿವರಿಸಲು ಬಯಸುವ ಸಂದರ್ಭಗಳಲ್ಲಿ ಇದು ವಿಶೇಷವಾಗಿ ನಿಜವಾಗಬಹುದು.

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

ನಾನು ಮೊದಲೇ ಹೇಳಿದಂತೆ, ನಾವು ಎಲ್ಲಾ ನಿಯೋಜನೆಗಳನ್ನು ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತೇವೆ ನಿಯೋಜಿಸು/:

mkdir deploy
cd deploy

ನಮ್ಮ ಮೊದಲ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸೋಣ:

qbec init website
cd website

ಈಗ ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ರಚನೆಯು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

.
├── components
├── environments
│   ├── base.libsonnet
│   └── default.libsonnet
├── params.libsonnet
└── qbec.yaml

ಫೈಲ್ ಅನ್ನು ನೋಡೋಣ qbec.yaml:

apiVersion: qbec.io/v1alpha1
kind: App
metadata:
  name: website
spec:
  environments:
    default:
      defaultNamespace: docs
      server: https://kubernetes.example.org:8443
  vars: {}

ಇಲ್ಲಿ ನಾವು ಪ್ರಾಥಮಿಕವಾಗಿ ಆಸಕ್ತಿ ಹೊಂದಿದ್ದೇವೆ spec.environments, qbec ಈಗಾಗಲೇ ನಮಗಾಗಿ ಡೀಫಾಲ್ಟ್ ಪರಿಸರವನ್ನು ರಚಿಸಿದೆ ಮತ್ತು ಸರ್ವರ್ ವಿಳಾಸವನ್ನು ಮತ್ತು ನಮ್ಮ ಪ್ರಸ್ತುತ kubeconfig ನಿಂದ ನೇಮ್‌ಸ್ಪೇಸ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡಿದೆ.
ಈಗ ನಿಯೋಜಿಸುವಾಗ ಡೀಫಾಲ್ಟ್ ಪರಿಸರ, qbec ಯಾವಾಗಲೂ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗೆ ಮತ್ತು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗೆ ಮಾತ್ರ ನಿಯೋಜಿಸುತ್ತದೆ, ಅಂದರೆ, ನಿಯೋಜನೆಯನ್ನು ನಿರ್ವಹಿಸಲು ನೀವು ಇನ್ನು ಮುಂದೆ ಸಂದರ್ಭಗಳು ಮತ್ತು ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳ ನಡುವೆ ಬದಲಾಯಿಸಬೇಕಾಗಿಲ್ಲ.
ಅಗತ್ಯವಿದ್ದರೆ, ನೀವು ಯಾವಾಗಲೂ ಈ ಫೈಲ್‌ನಲ್ಲಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ನವೀಕರಿಸಬಹುದು.

ನಿಮ್ಮ ಎಲ್ಲಾ ಪರಿಸರಗಳನ್ನು ವಿವರಿಸಲಾಗಿದೆ qbec.yaml, ಮತ್ತು ಫೈಲ್‌ನಲ್ಲಿ params.libsonnet, ಅಲ್ಲಿ ಅವರಿಗೆ ನಿಯತಾಂಕಗಳನ್ನು ಎಲ್ಲಿ ಪಡೆಯಬೇಕೆಂದು ಹೇಳುತ್ತದೆ.

ಮುಂದೆ ನಾವು ಎರಡು ಡೈರೆಕ್ಟರಿಗಳನ್ನು ನೋಡುತ್ತೇವೆ:

• ಘಟಕಗಳು/ - ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಾಗಿ ಎಲ್ಲಾ ಮ್ಯಾನಿಫೆಸ್ಟ್‌ಗಳನ್ನು ಇಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ; ಅವುಗಳನ್ನು jsonnet ಮತ್ತು ಸಾಮಾನ್ಯ yaml ಫೈಲ್‌ಗಳಲ್ಲಿ ವಿವರಿಸಬಹುದು
• ಪರಿಸರ/ — ಇಲ್ಲಿ ನಾವು ನಮ್ಮ ಪರಿಸರಕ್ಕಾಗಿ ಎಲ್ಲಾ ಅಸ್ಥಿರಗಳನ್ನು (ಪ್ಯಾರಾಮೀಟರ್‌ಗಳು) ವಿವರಿಸುತ್ತೇವೆ.

ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ನಾವು ಎರಡು ಫೈಲ್ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ:

• ಪರಿಸರಗಳು/base.libsonnet - ಇದು ಎಲ್ಲಾ ಪರಿಸರಗಳಿಗೆ ಸಾಮಾನ್ಯ ನಿಯತಾಂಕಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ
• ಪರಿಸರಗಳು/default.libsonnet - ಪರಿಸರಕ್ಕೆ ಅತಿಕ್ರಮಿಸಲಾದ ನಿಯತಾಂಕಗಳನ್ನು ಒಳಗೊಂಡಿದೆ ಡೀಫಾಲ್ಟ್

ತೆರೆಯೋಣ ಪರಿಸರಗಳು/base.libsonnet ಮತ್ತು ಅಲ್ಲಿ ನಮ್ಮ ಮೊದಲ ಘಟಕಕ್ಕೆ ನಿಯತಾಂಕಗಳನ್ನು ಸೇರಿಸಿ:

{
  components: {
    website: {
      name: 'example-docs',
      image: 'registry.gitlab.com/kvaps/docs.example.org/website:v0.0.1',
      replicas: 1,
      containerPort: 80,
      servicePort: 80,
      nodeSelector: {},
      tolerations: [],
      ingressClass: 'nginx',
      domain: 'docs.example.org',
    },
  },
}

ನಮ್ಮ ಮೊದಲ ಘಟಕವನ್ನು ಸಹ ರಚಿಸೋಣ ಘಟಕಗಳು/website.jsonnet:

local env = {
  name: std.extVar('qbec.io/env'),
  namespace: std.extVar('qbec.io/defaultNs'),
};
local p = import '../params.libsonnet';
local params = p.components.website;

[
  {
    apiVersion: 'apps/v1',
    kind: 'Deployment',
    metadata: {
      labels: { app: params.name },
      name: params.name,
    },
    spec: {
      replicas: params.replicas,
      selector: {
        matchLabels: {
          app: params.name,
        },
      },
      template: {
        metadata: {
          labels: { app: params.name },
        },
        spec: {
          containers: [
            {
              name: 'darkhttpd',
              image: params.image,
              ports: [
                {
                  containerPort: params.containerPort,
                },
              ],
            },
          ],
          nodeSelector: params.nodeSelector,
          tolerations: params.tolerations,
          imagePullSecrets: [{ name: 'regsecret' }],
        },
      },
    },
  },
  {
    apiVersion: 'v1',
    kind: 'Service',
    metadata: {
      labels: { app: params.name },
      name: params.name,
    },
    spec: {
      selector: {
        app: params.name,
      },
      ports: [
        {
          port: params.servicePort,
          targetPort: params.containerPort,
        },
      ],
    },
  },
  {
    apiVersion: 'extensions/v1beta1',
    kind: 'Ingress',
    metadata: {
      annotations: {
        'kubernetes.io/ingress.class': params.ingressClass,
      },
      labels: { app: params.name },
      name: params.name,
    },
    spec: {
      rules: [
        {
          host: params.domain,
          http: {
            paths: [
              {
                backend: {
                  serviceName: params.name,
                  servicePort: params.servicePort,
                },
              },
            ],
          },
        },
      ],
    },
  },
]

ಈ ಫೈಲ್‌ನಲ್ಲಿ ನಾವು ಮೂರು ಕುಬರ್ನೆಟ್ಸ್ ಘಟಕಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ವಿವರಿಸಿದ್ದೇವೆ, ಅವುಗಳೆಂದರೆ: ನಿಯೋಜನೆ, ಸೇವೆ и ಪ್ರವೇಶ. ನಾವು ಬಯಸಿದರೆ, ನಾವು ಅವುಗಳನ್ನು ವಿಭಿನ್ನ ಘಟಕಗಳಾಗಿ ಹಾಕಬಹುದು, ಆದರೆ ಈ ಹಂತದಲ್ಲಿ ನಮಗೆ ಒಂದು ಸಾಕು.

ವಾಕ್ಯ jsonnet ಸಾಮಾನ್ಯ json ಗೆ ಹೋಲುತ್ತದೆ, ತಾತ್ವಿಕವಾಗಿ, ಸಾಮಾನ್ಯ json ಈಗಾಗಲೇ ಮಾನ್ಯವಾದ jsonnet ಆಗಿದೆ, ಆದ್ದರಿಂದ ಮೊದಲಿಗೆ ನೀವು ಆನ್‌ಲೈನ್ ಸೇವೆಗಳನ್ನು ಬಳಸಲು ಸುಲಭವಾಗಬಹುದು yaml2json ನಿಮ್ಮ ಸಾಮಾನ್ಯ ಯಾಮ್ಲ್ ಅನ್ನು json ಆಗಿ ಪರಿವರ್ತಿಸಲು, ಅಥವಾ, ನಿಮ್ಮ ಘಟಕಗಳು ಯಾವುದೇ ಅಸ್ಥಿರಗಳನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ, ಅವುಗಳನ್ನು ಸಾಮಾನ್ಯ ಯಾಮ್ಲ್ ರೂಪದಲ್ಲಿ ವಿವರಿಸಬಹುದು.

ಕೆಲಸ ಮಾಡುವಾಗ jsonnet ನಿಮ್ಮ ಸಂಪಾದಕಕ್ಕಾಗಿ ಪ್ಲಗಿನ್ ಅನ್ನು ಸ್ಥಾಪಿಸಲು ನಾನು ಹೆಚ್ಚು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ

ಉದಾಹರಣೆಗೆ, vim ಗಾಗಿ ಪ್ಲಗಿನ್ ಇದೆ ವಿಮ್-ಜೆಸೊನೆಟ್, ಇದು ಸಿಂಟ್ಯಾಕ್ಸ್ ಹೈಲೈಟ್ ಮಾಡುವಿಕೆಯನ್ನು ಆನ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ jsonnet fmt ನೀವು ಉಳಿಸುವ ಪ್ರತಿ ಬಾರಿ (jsonnet ಅನ್ನು ಸ್ಥಾಪಿಸುವ ಅಗತ್ಯವಿದೆ).

ಎಲ್ಲವೂ ಸಿದ್ಧವಾಗಿದೆ, ಈಗ ನಾವು ನಿಯೋಜಿಸಲು ಪ್ರಾರಂಭಿಸಬಹುದು:

ನಾವು ಏನನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ ಎಂಬುದನ್ನು ನೋಡಲು, ಓಡೋಣ:

qbec show default

ಔಟ್‌ಪುಟ್‌ನಲ್ಲಿ, ಡೀಫಾಲ್ಟ್ ಕ್ಲಸ್ಟರ್‌ಗೆ ಅನ್ವಯಿಸಲಾಗುವ ರೆಂಡರ್ಡ್ yaml ಮ್ಯಾನಿಫೆಸ್ಟ್‌ಗಳನ್ನು ನೀವು ನೋಡುತ್ತೀರಿ.

ಅದ್ಭುತವಾಗಿದೆ, ಈಗ ಅನ್ವಯಿಸಿ:

qbec apply default

ಔಟ್‌ಪುಟ್‌ನಲ್ಲಿ ನಿಮ್ಮ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಏನು ಮಾಡಲಾಗುವುದು ಎಂಬುದನ್ನು ನೀವು ಯಾವಾಗಲೂ ನೋಡುತ್ತೀರಿ, ಟೈಪ್ ಮಾಡುವ ಮೂಲಕ ಬದಲಾವಣೆಗಳನ್ನು ಒಪ್ಪಿಕೊಳ್ಳಲು qbec ನಿಮ್ಮನ್ನು ಕೇಳುತ್ತದೆ y ನಿಮ್ಮ ಉದ್ದೇಶಗಳನ್ನು ದೃಢೀಕರಿಸಲು ನಿಮಗೆ ಸಾಧ್ಯವಾಗುತ್ತದೆ.

ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಸಿದ್ಧವಾಗಿದೆ ಮತ್ತು ನಿಯೋಜಿಸಲಾಗಿದೆ!

ನೀವು ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಿದರೆ, ನೀವು ಯಾವಾಗಲೂ ಮಾಡಬಹುದು:

qbec diff default

ಈ ಬದಲಾವಣೆಗಳು ಪ್ರಸ್ತುತ ನಿಯೋಜನೆಯ ಮೇಲೆ ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ ಎಂಬುದನ್ನು ನೋಡಲು

ನಮ್ಮ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲು ಮರೆಯಬೇಡಿ:

cd ../..
git add deploy/website
git commit -m "Add deploy for website"

5. ಕುಬರ್ನೆಟ್ಸ್-ಎಕ್ಸಿಕ್ಯೂಟರ್ ಜೊತೆಗೆ ಗಿಟ್ಲ್ಯಾಬ್-ರನ್ನರ್ ಪ್ರಯತ್ನಿಸಲಾಗುತ್ತಿದೆ

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

ಆದರೆ ಅಭ್ಯಾಸವು ತೋರಿಸಿದಂತೆ, ಪ್ರಾಯೋಗಿಕತೆ ಮತ್ತು ಸುರಕ್ಷತೆಯ ದೃಷ್ಟಿಯಿಂದ ಈ ಆಯ್ಕೆಯು ಹೆಚ್ಚು ಸೂಕ್ತವಲ್ಲ. ಪ್ರತಿ ಯೋಜನೆಗೆ ಅಥವಾ ಪ್ರತಿ ಪರಿಸರಕ್ಕೂ ಪ್ರತ್ಯೇಕ ಓಟಗಾರರನ್ನು ನಿಯೋಜಿಸುವುದು ಹೆಚ್ಚು ಉತ್ತಮ ಮತ್ತು ಸೈದ್ಧಾಂತಿಕವಾಗಿ ಹೆಚ್ಚು ಸರಿಯಾಗಿದೆ.

ಅದೃಷ್ಟವಶಾತ್, ಇದು ಸಮಸ್ಯೆಯಲ್ಲ, ಈಗ ನಾವು ನಿಯೋಜಿಸುತ್ತೇವೆ ಗಿಟ್ಲ್ಯಾಬ್-ರನ್ನರ್ ನೇರವಾಗಿ Kubernetes ನಲ್ಲಿ ನಮ್ಮ ಯೋಜನೆಯ ಭಾಗವಾಗಿ.

ಕ್ಯುಬರ್ನೆಟ್ಸ್‌ಗೆ ಗಿಟ್‌ಲ್ಯಾಬ್-ರನ್ನರ್ ಅನ್ನು ನಿಯೋಜಿಸಲು ಗಿಟ್‌ಲ್ಯಾಬ್ ರೆಡಿಮೇಡ್ ಹೆಲ್ಮ್ ಚಾರ್ಟ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ ನೀವು ಮಾಡಬೇಕಾಗಿರುವುದು ಕಂಡುಹಿಡಿಯುವುದು ನೋಂದಣಿ ಟೋಕನ್ ನಮ್ಮ ಯೋಜನೆಗಾಗಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳು -> CI / CD -> ರನ್ನರ್ಸ್ ಮತ್ತು ಅದನ್ನು ಚುಕ್ಕಾಣಿ ಹಿಡಿಯಿರಿ:

helm repo add gitlab https://charts.gitlab.io

helm install gitlab-runner 
  --set gitlabUrl=https://gitlab.com 
  --set runnerRegistrationToken=yga8y-jdCusVDn_t4Wxc 
  --set rbac.create=true 
  gitlab/gitlab-runner

ಎಲ್ಲಿ:

• https://gitlab.com - ನಿಮ್ಮ Gitlab ಸರ್ವರ್‌ನ ವಿಳಾಸ.
• yga8y-jdCusVDn_t4Wxc - ನಿಮ್ಮ ಯೋಜನೆಗಾಗಿ ನೋಂದಣಿ ಟೋಕನ್.
• rbac.create=true - kubernetes-executor ಅನ್ನು ಬಳಸಿಕೊಂಡು ನಮ್ಮ ಕಾರ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಪಾಡ್‌ಗಳನ್ನು ರಚಿಸಲು ಸಾಧ್ಯವಾಗುವಂತೆ ರನ್ನರ್‌ಗೆ ಅಗತ್ಯ ಪ್ರಮಾಣದ ಸವಲತ್ತುಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ.

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

ಸೇರಿಸಿದ ರನ್ನರ್‌ನ ಸ್ಕ್ರೀನ್‌ಶಾಟ್

ಇದು ಸರಳವಾಗಿದೆಯೇ? - ಹೌದು, ಇದು ತುಂಬಾ ಸರಳವಾಗಿದೆ! ಓಟಗಾರರನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ನೋಂದಾಯಿಸುವುದರೊಂದಿಗೆ ಯಾವುದೇ ತೊಂದರೆಯಿಲ್ಲ, ಇನ್ನು ಮುಂದೆ ಓಟಗಾರರು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ರಚಿಸಲ್ಪಡುತ್ತಾರೆ ಮತ್ತು ನಾಶವಾಗುತ್ತಾರೆ.

6. QBEC ಯೊಂದಿಗೆ ಹೆಲ್ಮ್ ಚಾರ್ಟ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಿ

ನಾವು ಪರಿಗಣಿಸಲು ನಿರ್ಧರಿಸಿದ್ದರಿಂದ ಗಿಟ್ಲ್ಯಾಬ್-ರನ್ನರ್ ನಮ್ಮ ಯೋಜನೆಯ ಭಾಗವಾಗಿ, ಅದನ್ನು ನಮ್ಮ Git ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ವಿವರಿಸುವ ಸಮಯ.

ನಾವು ಅದನ್ನು ಪ್ರತ್ಯೇಕ ಘಟಕವಾಗಿ ವಿವರಿಸಬಹುದು ವೆಬ್ಸೈಟ್, ಆದರೆ ಭವಿಷ್ಯದಲ್ಲಿ ನಾವು ವಿವಿಧ ಪ್ರತಿಗಳನ್ನು ನಿಯೋಜಿಸಲು ಯೋಜಿಸುತ್ತೇವೆ ವೆಬ್ಸೈಟ್ ಆಗಾಗ್ಗೆ, ಭಿನ್ನವಾಗಿ ಗಿಟ್ಲ್ಯಾಬ್-ರನ್ನರ್, ಇದನ್ನು ಪ್ರತಿ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗೆ ಒಮ್ಮೆ ಮಾತ್ರ ನಿಯೋಜಿಸಲಾಗುವುದು. ಆದ್ದರಿಂದ ಅದಕ್ಕಾಗಿ ಪ್ರತ್ಯೇಕ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸೋಣ:

cd deploy
qbec init gitlab-runner
cd gitlab-runner

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

ಜಿಟ್ ಸಬ್ ಮಾಡ್ಯೂಲ್ ಬಳಸಿ ಅದನ್ನು ಸಂಪರ್ಕಿಸೋಣ:

git submodule add https://gitlab.com/gitlab-org/charts/gitlab-runner vendor/gitlab-runner

ಈಗ ಡೈರೆಕ್ಟರಿ ಮಾರಾಟಗಾರ/ಗಿಟ್ಲ್ಯಾಬ್-ರನ್ನರ್ ನಾವು ಗಿಟ್ಲ್ಯಾಬ್-ರನ್ನರ್‌ಗಾಗಿ ಚಾರ್ಟ್‌ನೊಂದಿಗೆ ರೆಪೊಸಿಟರಿಯನ್ನು ಹೊಂದಿದ್ದೇವೆ.

ಅದೇ ರೀತಿಯಲ್ಲಿ, ನೀವು ಇತರ ರೆಪೊಸಿಟರಿಗಳನ್ನು ಸಂಪರ್ಕಿಸಬಹುದು, ಉದಾಹರಣೆಗೆ, ಅಧಿಕೃತ ಚಾರ್ಟ್ಗಳೊಂದಿಗೆ ಸಂಪೂರ್ಣ ರೆಪೊಸಿಟರಿ https://github.com/helm/charts

ಘಟಕವನ್ನು ವಿವರಿಸೋಣ ಘಟಕಗಳು/gitlab-runner.jsonnet:

local env = {
  name: std.extVar('qbec.io/env'),
  namespace: std.extVar('qbec.io/defaultNs'),
};
local p = import '../params.libsonnet';
local params = p.components.gitlabRunner;

std.native('expandHelmTemplate')(
  '../vendor/gitlab-runner',
  params.values,
  {
    nameTemplate: params.name,
    namespace: env.namespace,
    thisFile: std.thisFile,
    verbose: true,
  }
)

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

• ಹೆಸರು ಟೆಂಪ್ಲೇಟು - ಬಿಡುಗಡೆ ಶೀರ್ಷಿಕೆ
• ನೇಮ್‌ಸ್ಪೇಸ್ - ನೇಮ್‌ಸ್ಪೇಸ್ ಅನ್ನು ಚುಕ್ಕಾಣಿಗೆ ವರ್ಗಾಯಿಸಲಾಗಿದೆ
• ಈ ಫೈಲ್ - ಪ್ರಸ್ತುತ ಫೈಲ್‌ಗೆ ಮಾರ್ಗವನ್ನು ಹಾದುಹೋಗುವ ಅಗತ್ಯವಿರುವ ನಿಯತಾಂಕ
• ವರ್ಬೋಸ್ - ಆಜ್ಞೆಯನ್ನು ತೋರಿಸುತ್ತದೆ ಚುಕ್ಕಾಣಿ ಟೆಂಪ್ಲೇಟ್ ಚಾರ್ಟ್ ಅನ್ನು ಸಲ್ಲಿಸುವಾಗ ಎಲ್ಲಾ ವಾದಗಳೊಂದಿಗೆ

ಈಗ ನಮ್ಮ ಘಟಕದ ನಿಯತಾಂಕಗಳನ್ನು ವಿವರಿಸೋಣ ಪರಿಸರಗಳು/base.libsonnet:

local secrets = import '../secrets/base.libsonnet';

{
  components: {
    gitlabRunner: {
      name: 'gitlab-runner',
      values: {
        gitlabUrl: 'https://gitlab.com/',
        rbac: {
          create: true,
        },
        runnerRegistrationToken: secrets.runnerRegistrationToken,
      },
    },
  },
}

ಗಮನ ಕೊಡಿ ರನ್ನರ್ ನೋಂದಣಿ ಟೋಕನ್ ನಾವು ಬಾಹ್ಯ ಫೈಲ್‌ನಿಂದ ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ ರಹಸ್ಯಗಳು/base.libsonnet, ಅದನ್ನು ರಚಿಸೋಣ:

{
  runnerRegistrationToken: 'yga8y-jdCusVDn_t4Wxc',
}

ಎಲ್ಲವೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸೋಣ:

qbec show default

ಎಲ್ಲವೂ ಕ್ರಮದಲ್ಲಿದ್ದರೆ, ಹೆಲ್ಮ್ ಮೂಲಕ ನಮ್ಮ ಹಿಂದೆ ನಿಯೋಜಿಸಲಾದ ಬಿಡುಗಡೆಯನ್ನು ನಾವು ಅಳಿಸಬಹುದು:

helm uninstall gitlab-runner

ಮತ್ತು ಅದನ್ನು ಅದೇ ರೀತಿಯಲ್ಲಿ ನಿಯೋಜಿಸಿ, ಆದರೆ qbec ಮೂಲಕ:

qbec apply default

7. ಜಿಟ್-ಕ್ರಿಪ್ಟ್‌ಗೆ ಪರಿಚಯ

ಜಿಟ್-ಕ್ರಿಪ್ಟ್ ನಿಮ್ಮ ರೆಪೊಸಿಟರಿಗಾಗಿ ಪಾರದರ್ಶಕ ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಅನ್ನು ಹೊಂದಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಸಾಧನವಾಗಿದೆ.

ಈ ಸಮಯದಲ್ಲಿ, ಗಿಟ್ಲ್ಯಾಬ್-ರನ್ನರ್‌ಗಾಗಿ ನಮ್ಮ ಡೈರೆಕ್ಟರಿ ರಚನೆಯು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

.
├── components
│   ├── gitlab-runner.jsonnet
├── environments
│   ├── base.libsonnet
│   └── default.libsonnet
├── params.libsonnet
├── qbec.yaml
├── secrets
│   └── base.libsonnet
└── vendor
    └── gitlab-runner (submodule)

ಆದರೆ Git ನಲ್ಲಿ ರಹಸ್ಯಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದು ಸುರಕ್ಷಿತವಲ್ಲ, ಅಲ್ಲವೇ? ಆದ್ದರಿಂದ ನಾವು ಅವುಗಳನ್ನು ಸರಿಯಾಗಿ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಬೇಕಾಗಿದೆ.

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

ಇದಲ್ಲದೆ, ಈ ಸಂದರ್ಭದಲ್ಲಿ ನಾನು ಅಂತಹ ಅದ್ಭುತ ಸಾಧನದ ಬಗ್ಗೆ ಹೇಳಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ git-ಕ್ರಿಪ್ಟ್.

git-ಕ್ರಿಪ್ಟ್ ಇದು ಅನುಕೂಲಕರವಾಗಿದೆ, ಇದು ರಹಸ್ಯಗಳ ಸಂಪೂರ್ಣ ಇತಿಹಾಸವನ್ನು ಉಳಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಜೊತೆಗೆ ನಾವು Git ವಿಷಯದಲ್ಲಿ ಮಾಡುವ ರೀತಿಯಲ್ಲಿಯೇ ಸಂಘರ್ಷಗಳನ್ನು ಹೋಲಿಸಿ, ವಿಲೀನಗೊಳಿಸಿ ಮತ್ತು ಪರಿಹರಿಸಬಹುದು.

ಅನುಸ್ಥಾಪನೆಯ ನಂತರ ಮೊದಲ ವಿಷಯ git-ಕ್ರಿಪ್ಟ್ ನಮ್ಮ ರೆಪೊಸಿಟರಿಗಾಗಿ ನಾವು ಕೀಗಳನ್ನು ರಚಿಸಬೇಕಾಗಿದೆ:

git crypt init

ನೀವು PGP ಕೀಯನ್ನು ಹೊಂದಿದ್ದರೆ, ನಂತರ ನೀವು ತಕ್ಷಣ ಈ ಯೋಜನೆಗೆ ಸಹಯೋಗಿಯಾಗಿ ನಿಮ್ಮನ್ನು ಸೇರಿಸಿಕೊಳ್ಳಬಹುದು:

git-crypt add-gpg-user [email protected]

ಈ ರೀತಿಯಾಗಿ ನೀವು ಯಾವಾಗಲೂ ನಿಮ್ಮ ಖಾಸಗಿ ಕೀಲಿಯನ್ನು ಬಳಸಿಕೊಂಡು ಈ ರೆಪೊಸಿಟರಿಯನ್ನು ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡಬಹುದು.

ನೀವು PGP ಕೀಲಿಯನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ ಮತ್ತು ಅದನ್ನು ನಿರೀಕ್ಷಿಸದಿದ್ದರೆ, ನೀವು ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೋಗಿ ಪ್ರಾಜೆಕ್ಟ್ ಕೀಯನ್ನು ರಫ್ತು ಮಾಡಬಹುದು:

git crypt export-key /path/to/keyfile

ಹೀಗಾಗಿ, ರಫ್ತು ಮಾಡಿದ ಯಾರಾದರೂ ಕೀಫೈಲ್ ನಿಮ್ಮ ರೆಪೊಸಿಟರಿಯನ್ನು ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.

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

* filter=git-crypt diff=git-crypt
.gitattributes !filter !diff

ವಿಷಯದಿಂದ ನೋಡಬಹುದಾದಂತೆ, ಎಲ್ಲಾ ಫೈಲ್‌ಗಳನ್ನು ಮರೆಮಾಡಲಾಗಿದೆ * ಮೂಲಕ ಚಾಲನೆ ನೀಡಲಾಗುವುದು git-ಕ್ರಿಪ್ಟ್, ಹೆಚ್ಚಿನದನ್ನು ಹೊರತುಪಡಿಸಿ .ಗಿಟಾಟ್ರಿಬ್ಯೂಟ್ಸ್

ಚಾಲನೆಯಲ್ಲಿರುವ ಮೂಲಕ ನಾವು ಇದನ್ನು ಪರಿಶೀಲಿಸಬಹುದು:

git crypt status -e

ಔಟ್‌ಪುಟ್ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲಾದ ಎಲ್ಲಾ ಫೈಲ್‌ಗಳ ಪಟ್ಟಿಯಾಗಿರುತ್ತದೆ

ಅಷ್ಟೆ, ಈಗ ನಾವು ನಮ್ಮ ಬದಲಾವಣೆಗಳನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಮಾಡಬಹುದು:

cd ../..
git add .
git commit -m "Add deploy for gitlab-runner"

ರೆಪೊಸಿಟರಿಯನ್ನು ನಿರ್ಬಂಧಿಸಲು, ಕೇವಲ ರನ್ ಮಾಡಿ:

git crypt lock

ಮತ್ತು ತಕ್ಷಣವೇ ಎಲ್ಲಾ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಲಾದ ಫೈಲ್‌ಗಳು ಬೈನರಿಯಾಗಿ ಬದಲಾಗುತ್ತವೆ, ಅವುಗಳನ್ನು ಓದುವುದು ಅಸಾಧ್ಯ.
ರೆಪೊಸಿಟರಿಯನ್ನು ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡಲು, ರನ್ ಮಾಡಿ:

git crypt unlock

8. ಟೂಲ್‌ಬಾಕ್ಸ್ ಚಿತ್ರವನ್ನು ರಚಿಸಿ

ಟೂಲ್‌ಬಾಕ್ಸ್ ಚಿತ್ರವು ನಮ್ಮ ಯೋಜನೆಯನ್ನು ನಿಯೋಜಿಸಲು ನಾವು ಬಳಸುವ ಎಲ್ಲಾ ಪರಿಕರಗಳನ್ನು ಹೊಂದಿರುವ ಚಿತ್ರವಾಗಿದೆ. ವಿಶಿಷ್ಟವಾದ ನಿಯೋಜನೆ ಕಾರ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸಲು Gitlab ರನ್ನರ್ ಇದನ್ನು ಬಳಸುತ್ತಾರೆ.

ಇಲ್ಲಿ ಎಲ್ಲವೂ ಸರಳವಾಗಿದೆ, ಹೊಸದನ್ನು ರಚಿಸೋಣ ಡಾಕರ್‌ಫೈಲ್‌ಗಳು/ಟೂಲ್‌ಬಾಕ್ಸ್/ಡಾಕರ್‌ಫೈಲ್ ಕೆಳಗಿನ ವಿಷಯದೊಂದಿಗೆ:

FROM alpine:3.11

RUN apk add --no-cache git git-crypt

RUN QBEC_VER=0.10.3 
 && wget -O- https://github.com/splunk/qbec/releases/download/v${QBEC_VER}/qbec-linux-amd64.tar.gz 
     | tar -C /tmp -xzf - 
 && mv /tmp/qbec /tmp/jsonnet-qbec /usr/local/bin/

RUN KUBECTL_VER=1.17.0 
 && wget -O /usr/local/bin/kubectl 
      https://storage.googleapis.com/kubernetes-release/release/v${KUBECTL_VER}/bin/linux/amd64/kubectl 
 && chmod +x /usr/local/bin/kubectl

RUN HELM_VER=3.0.2 
 && wget -O- https://get.helm.sh/helm-v${HELM_VER}-linux-amd64.tar.gz 
     | tar -C /tmp -zxf - 
 && mv /tmp/linux-amd64/helm /usr/local/bin/helm

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

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

ಇದನ್ನು ಮಾಡಲು, ಗಿಟ್ಲ್ಯಾಬ್-ರನ್ನರ್ನೊಂದಿಗೆ ಡೈರೆಕ್ಟರಿಗೆ ಹೋಗೋಣ:

cd deploy/gitlab-runner

ಮತ್ತು ಹೊಸ ಘಟಕವನ್ನು ಸೇರಿಸಿ ಘಟಕಗಳು/rbac.jsonnet:

local env = {
  name: std.extVar('qbec.io/env'),
  namespace: std.extVar('qbec.io/defaultNs'),
};
local p = import '../params.libsonnet';
local params = p.components.rbac;

[
  {
    apiVersion: 'v1',
    kind: 'ServiceAccount',
    metadata: {
      labels: {
        app: params.name,
      },
      name: params.name,
    },
  },
  {
    apiVersion: 'rbac.authorization.k8s.io/v1',
    kind: 'Role',
    metadata: {
      labels: {
        app: params.name,
      },
      name: params.name,
    },
    rules: [
      {
        apiGroups: [
          '*',
        ],
        resources: [
          '*',
        ],
        verbs: [
          '*',
        ],
      },
    ],
  },
  {
    apiVersion: 'rbac.authorization.k8s.io/v1',
    kind: 'RoleBinding',
    metadata: {
      labels: {
        app: params.name,
      },
      name: params.name,
    },
    roleRef: {
      apiGroup: 'rbac.authorization.k8s.io',
      kind: 'Role',
      name: params.name,
    },
    subjects: [
      {
        kind: 'ServiceAccount',
        name: params.name,
        namespace: env.namespace,
      },
    ],
  },
]

ನಾವು ಹೊಸ ನಿಯತಾಂಕಗಳನ್ನು ಸಹ ವಿವರಿಸುತ್ತೇವೆ ಪರಿಸರಗಳು/base.libsonnet, ಇದು ಈಗ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

local secrets = import '../secrets/base.libsonnet';

{
  components: {
    gitlabRunner: {
      name: 'gitlab-runner',
      values: {
        gitlabUrl: 'https://gitlab.com/',
        rbac: {
          create: true,
        },
        runnerRegistrationToken: secrets.runnerRegistrationToken,
        runners: {
          serviceAccountName: $.components.rbac.name,
          image: 'registry.gitlab.com/kvaps/docs.example.org/toolbox:v0.0.1',
        },
      },
    },
    rbac: {
      name: 'gitlab-runner-deploy',
    },
  },
}

ಗಮನ ಕೊಡಿ $.components.rbac.name ಸೂಚಿಸುತ್ತದೆ ಹೆಸರು ಘಟಕಕ್ಕಾಗಿ rbac

ಏನು ಬದಲಾಗಿದೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸೋಣ:

qbec diff default

ಮತ್ತು ನಮ್ಮ ಬದಲಾವಣೆಗಳನ್ನು Kubernetes ಗೆ ಅನ್ವಯಿಸಿ:

qbec apply default

ಅಲ್ಲದೆ, ನಮ್ಮ ಬದಲಾವಣೆಗಳನ್ನು git ಗೆ ಒಪ್ಪಿಸಲು ಮರೆಯಬೇಡಿ:

cd ../..
git add dockerfiles/toolbox
git commit -m "Add Dockerfile for toolbox"
git add deploy/gitlab-runner
git commit -m "Configure gitlab-runner to use toolbox"

9. ನಮ್ಮ ಮೊದಲ ಪೈಪ್‌ಲೈನ್ ಮತ್ತು ಟ್ಯಾಗ್‌ಗಳ ಮೂಲಕ ಚಿತ್ರಗಳ ಜೋಡಣೆ

ಯೋಜನೆಯ ಮೂಲದಲ್ಲಿ ನಾವು ರಚಿಸುತ್ತೇವೆ .gitlab-ci.yml ಕೆಳಗಿನ ವಿಷಯದೊಂದಿಗೆ:

.build_docker_image:
  stage: build
  image:
    name: gcr.io/kaniko-project/executor:debug-v0.15.0
    entrypoint: [""]
  before_script:
    - echo "{"auths":{"$CI_REGISTRY":{"username":"$CI_REGISTRY_USER","password":"$CI_REGISTRY_PASSWORD"}}}" > /kaniko/.docker/config.json

build_toolbox:
  extends: .build_docker_image
  script:
    - /kaniko/executor --cache --context $CI_PROJECT_DIR/dockerfiles/toolbox --dockerfile $CI_PROJECT_DIR/dockerfiles/toolbox/Dockerfile --destination $CI_REGISTRY_IMAGE/toolbox:$CI_COMMIT_TAG
  only:
    refs:
      - tags

build_website:
  extends: .build_docker_image
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  script:
    - /kaniko/executor --cache --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/dockerfiles/website/Dockerfile --destination $CI_REGISTRY_IMAGE/website:$CI_COMMIT_TAG
  only:
    refs:
      - tags

ನಾವು ಬಳಸುತ್ತೇವೆ ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ GIT_SUBMODULE_STRATEGY: ಸಾಮಾನ್ಯ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮೊದಲು ನೀವು ಸಬ್ ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಪ್ರಾರಂಭಿಸಬೇಕಾದ ಕೆಲಸಗಳಿಗಾಗಿ.

ನಮ್ಮ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲು ಮರೆಯಬೇಡಿ:

git add .gitlab-ci.yml
git commit -m "Automate docker build"

ನಾವು ಇದನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಆವೃತ್ತಿ ಎಂದು ಕರೆಯಬಹುದು ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ v0.0.1 ಮತ್ತು ಟ್ಯಾಗ್ ಸೇರಿಸಿ:

git tag v0.0.1

ನಾವು ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಬಿಡುಗಡೆ ಮಾಡಬೇಕಾದಾಗ ನಾವು ಟ್ಯಾಗ್‌ಗಳನ್ನು ಸೇರಿಸುತ್ತೇವೆ. ಡಾಕರ್ ಚಿತ್ರಗಳಲ್ಲಿನ ಟ್ಯಾಗ್‌ಗಳನ್ನು Git ಟ್ಯಾಗ್‌ಗಳಿಗೆ ಜೋಡಿಸಲಾಗುತ್ತದೆ. ಹೊಸ ಟ್ಯಾಗ್‌ನೊಂದಿಗೆ ಪ್ರತಿ ಪುಶ್ ಈ ಟ್ಯಾಗ್‌ನೊಂದಿಗೆ ಚಿತ್ರಗಳ ನಿರ್ಮಾಣವನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ.

ಅದನ್ನು ಮಾಡೋಣ git ಪುಶ್ --ಟ್ಯಾಗ್‌ಗಳು, ಮತ್ತು ನಮ್ಮ ಮೊದಲ ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ನೋಡೋಣ:

ಮೊದಲ ಪೈಪ್‌ಲೈನ್‌ನ ಸ್ಕ್ರೀನ್‌ಶಾಟ್

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

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

10. ನಿಯೋಜನೆಯ ಆಟೊಮೇಷನ್

Gitlab-ರನ್ನರ್ ನಮ್ಮ ರಹಸ್ಯಗಳನ್ನು ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡಲು, ನಾವು ರೆಪೊಸಿಟರಿ ಕೀಯನ್ನು ರಫ್ತು ಮಾಡಬೇಕಾಗುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ನಮ್ಮ CI ಪರಿಸರ ವೇರಿಯಬಲ್‌ಗಳಿಗೆ ಸೇರಿಸಬೇಕು:

git crypt export-key /tmp/docs-repo.key
base64 -w0 /tmp/docs-repo.key; echo

ನಾವು ಫಲಿತಾಂಶದ ಸಾಲನ್ನು Gitlab ನಲ್ಲಿ ಉಳಿಸುತ್ತೇವೆ; ಇದನ್ನು ಮಾಡಲು, ನಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಗೆ ಹೋಗೋಣ:
ಸೆಟ್ಟಿಂಗ್‌ಗಳು -> CI / CD -> ಅಸ್ಥಿರ

ಮತ್ತು ಹೊಸ ವೇರಿಯೇಬಲ್ ಅನ್ನು ರಚಿಸೋಣ:

ಪ್ರಕಾರ
ಕೀ
ಮೌಲ್ಯ
ಸಂರಕ್ಷಿಸಲಾಗಿದೆ
ಮುಖವಾಡ
ವ್ಯಾಪ್ತಿ

File
GITCRYPT_KEY
<your string>
true (ತರಬೇತಿ ಸಮಯದಲ್ಲಿ ನೀವು ಮಾಡಬಹುದು false)
true
All environments

ಸೇರಿಸಿದ ವೇರಿಯಬಲ್‌ನ ಸ್ಕ್ರೀನ್‌ಶಾಟ್

ಈಗ ನಮ್ಮದನ್ನು ನವೀಕರಿಸೋಣ .gitlab-ci.yml ಅದಕ್ಕೆ ಸೇರಿಸುವುದು:

.deploy_qbec_app:
  stage: deploy
  only:
    refs:
      - master

deploy_gitlab_runner:
  extends: .deploy_qbec_app
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  before_script:
    - base64 -d "$GITCRYPT_KEY" | git-crypt unlock -
  script:
    - qbec apply default --root deploy/gitlab-runner --force:k8s-context __incluster__ --wait --yes

deploy_website:
  extends: .deploy_qbec_app
  script:
    - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes

ಇಲ್ಲಿ ನಾವು qbec ಗಾಗಿ ಹಲವಾರು ಹೊಸ ಆಯ್ಕೆಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದ್ದೇವೆ:

• --ರೂಟ್ ಕೆಲವು/ಅಪ್ಲಿಕೇಶನ್ - ನಿರ್ದಿಷ್ಟ ಅಪ್ಲಿಕೇಶನ್‌ನ ಡೈರೆಕ್ಟರಿಯನ್ನು ನಿರ್ಧರಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ
• --force:k8s-context __incluster__ - ಇದು ಮ್ಯಾಜಿಕ್ ವೇರಿಯೇಬಲ್ ಆಗಿದ್ದು, ಜಿಟಿಲ್ಯಾಬ್-ರನ್ನರ್ ಚಾಲನೆಯಲ್ಲಿರುವ ಅದೇ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ನಿಯೋಜನೆಯು ಸಂಭವಿಸುತ್ತದೆ ಎಂದು ಹೇಳುತ್ತದೆ. ಇದು ಅವಶ್ಯಕ ಏಕೆಂದರೆ ಇಲ್ಲದಿದ್ದರೆ qbec ನಿಮ್ಮ kubeconfig ನಲ್ಲಿ ಸೂಕ್ತವಾದ Kubernetes ಸರ್ವರ್ ಅನ್ನು ಹುಡುಕಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ
• --ನಿರೀಕ್ಷಿಸಿ — qbec ಅನ್ನು ಅದು ರಚಿಸುವ ಸಂಪನ್ಮೂಲಗಳು ಸಿದ್ಧ ಸ್ಥಿತಿಗೆ ಹೋಗುವವರೆಗೆ ಕಾಯುವಂತೆ ಒತ್ತಾಯಿಸುತ್ತದೆ ಮತ್ತು ನಂತರ ಮಾತ್ರ ಯಶಸ್ವಿ ನಿರ್ಗಮನ-ಕೋಡ್‌ನೊಂದಿಗೆ ನಿರ್ಗಮಿಸುತ್ತದೆ.
• -ಹೌದು - ಸಂವಾದಾತ್ಮಕ ಶೆಲ್ ಅನ್ನು ಸರಳವಾಗಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ ನೀವು ಖಚಿತವಾಗಿರುವಿರಾ? ನಿಯೋಜಿಸಿದಾಗ.

ನಮ್ಮ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲು ಮರೆಯಬೇಡಿ:

git add .gitlab-ci.yml
git commit -m "Automate deploy"

ಮತ್ತು ನಂತರ ಜಿಟ್ ಪುಶ್ ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಹೇಗೆ ನಿಯೋಜಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ:

ಎರಡನೇ ಪೈಪ್‌ಲೈನ್‌ನ ಸ್ಕ್ರೀನ್‌ಶಾಟ್

11. ಮಾಸ್ಟರ್ಗೆ ತಳ್ಳುವಾಗ ಕಲಾಕೃತಿಗಳು ಮತ್ತು ಜೋಡಣೆ

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

ಕಲ್ಪನೆ ಸರಳವಾಗಿದೆ: ಈಗ ನಮ್ಮ ಚಿತ್ರ ವೆಬ್ಸೈಟ್ ನೀವು ತಳ್ಳಿದಾಗಲೆಲ್ಲಾ ಮರುನಿರ್ಮಿಸಲಾಗುವುದು ಮಾಸ್ಟರ್, ತದನಂತರ ಸ್ವಯಂಚಾಲಿತವಾಗಿ Kubernetes ಗೆ ನಿಯೋಜಿಸಿ.

ನಮ್ಮಲ್ಲಿ ಈ ಎರಡು ಉದ್ಯೋಗಗಳನ್ನು ನವೀಕರಿಸೋಣ .gitlab-ci.yml:

build_website:
  extends: .build_docker_image
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  script:
    - mkdir -p $CI_PROJECT_DIR/artifacts
    - /kaniko/executor --cache --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/dockerfiles/website/Dockerfile --destination $CI_REGISTRY_IMAGE/website:$CI_COMMIT_REF_NAME --digest-file $CI_PROJECT_DIR/artifacts/website.digest
  artifacts:
    paths:
      - artifacts/
  only:
    refs:
      - master
      - tags

deploy_website:
  extends: .deploy_qbec_app
  script:
    - DIGEST="$(cat artifacts/website.digest)"
    - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST"

ನಾವು ಥ್ರೆಡ್ ಅನ್ನು ಸೇರಿಸಿದ್ದೇವೆ ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ ಮಾಸ್ಟರ್ к ಉಲ್ಲೇಖಿಸುತ್ತದೆ ಉದ್ಯೋಗಗಳಿಗಾಗಿ ಬಿಲ್ಡ್_ವೆಬ್‌ಸೈಟ್ ಮತ್ತು ನಾವು ಈಗ ಬಳಸುತ್ತೇವೆ $CI_COMMIT_REF_NAME вместо $CI_COMMIT_TAG, ಅಂದರೆ, ನಾವು Git ನಲ್ಲಿನ ಟ್ಯಾಗ್‌ಗಳಿಂದ ಬಿಚ್ಚಲ್ಪಟ್ಟಿದ್ದೇವೆ ಮತ್ತು ಈಗ ನಾವು ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದ ಕಮಿಟ್ ಶಾಖೆಯ ಹೆಸರಿನೊಂದಿಗೆ ಚಿತ್ರವನ್ನು ತಳ್ಳುತ್ತೇವೆ. ಇದು ಟ್ಯಾಗ್‌ಗಳೊಂದಿಗೆ ಸಹ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ಗಮನಿಸಬೇಕಾದ ಅಂಶವಾಗಿದೆ, ಇದು ಡಾಕರ್-ರಿಜಿಸ್ಟ್ರಿಯಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ಆವೃತ್ತಿಯೊಂದಿಗೆ ಸೈಟ್‌ನ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳನ್ನು ಉಳಿಸಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

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

ಆಯ್ಕೆ —vm:ext-str ಡೈಜೆಸ್ಟ್=”$DIGEST” qbec ಗಾಗಿ - ಬಾಹ್ಯ ವೇರಿಯಬಲ್ ಅನ್ನು jsonnet ಗೆ ರವಾನಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಪ್ರತಿ ಬಿಡುಗಡೆಯೊಂದಿಗೆ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಅದನ್ನು ಮರುನಿಯೋಜಿಸಬೇಕೆಂದು ನಾವು ಬಯಸುತ್ತೇವೆ. ನಾವು ಇನ್ನು ಮುಂದೆ ಟ್ಯಾಗ್ ಹೆಸರನ್ನು ಬಳಸಲಾಗುವುದಿಲ್ಲ, ಅದನ್ನು ಈಗ ಬದಲಾಯಿಸಲಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ನಾವು ಚಿತ್ರದ ನಿರ್ದಿಷ್ಟ ಆವೃತ್ತಿಗೆ ಸಂಬಂಧಿಸಿರಬೇಕು ಮತ್ತು ಅದು ಬದಲಾದಾಗ ನಿಯೋಜನೆಯನ್ನು ಪ್ರಚೋದಿಸುತ್ತದೆ.

ಡೈಜೆಸ್ಟ್ ಇಮೇಜ್ ಅನ್ನು ಫೈಲ್‌ಗೆ ಉಳಿಸಲು ಕನಿಕೊ ಅವರ ಸಾಮರ್ಥ್ಯದಿಂದ ಇಲ್ಲಿ ನಮಗೆ ಸಹಾಯವಾಗುತ್ತದೆ (ಆಯ್ಕೆ --ಡೈಜೆಸ್ಟ್-ಫೈಲ್)
ನಂತರ ನಾವು ಈ ಫೈಲ್ ಅನ್ನು ವರ್ಗಾಯಿಸುತ್ತೇವೆ ಮತ್ತು ನಿಯೋಜನೆಯ ಸಮಯದಲ್ಲಿ ಅದನ್ನು ಓದುತ್ತೇವೆ.

ನಮಗಾಗಿ ನಿಯತಾಂಕಗಳನ್ನು ನವೀಕರಿಸೋಣ ನಿಯೋಜಿಸಿ/ವೆಬ್‌ಸೈಟ್/ಪರಿಸರ/base.libsonnet ಅದು ಈಗ ಈ ರೀತಿ ಕಾಣಿಸುತ್ತದೆ:

{
  components: {
    website: {
      name: 'example-docs',
      image: 'registry.gitlab.com/kvaps/docs.example.org/website@' + std.extVar('digest'),
      replicas: 1,
      containerPort: 80,
      servicePort: 80,
      nodeSelector: {},
      tolerations: [],
      ingressClass: 'nginx',
      domain: 'docs.example.org',
    },
  },
}

ಮುಗಿದಿದೆ, ಈಗ ಯಾವುದೇ ಬದ್ಧತೆ ಇದೆ ಮಾಸ್ಟರ್ ಗಾಗಿ ಡಾಕರ್ ಚಿತ್ರದ ನಿರ್ಮಾಣವನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ವೆಬ್ಸೈಟ್, ತದನಂತರ ಅದನ್ನು ಕುಬರ್ನೆಟ್ಸ್ಗೆ ನಿಯೋಜಿಸಿ.

ನಮ್ಮ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲು ಮರೆಯಬೇಡಿ:

git add .
git commit -m "Configure dynamic build"

ನಾವು ನಂತರ ಪರಿಶೀಲಿಸುತ್ತೇವೆ ಜಿಟ್ ಪುಶ್ ನಾವು ಈ ರೀತಿಯದನ್ನು ನೋಡಬೇಕು:

ಮಾಸ್ಟರ್‌ಗಾಗಿ ಪೈಪ್‌ಲೈನ್‌ನ ಸ್ಕ್ರೀನ್‌ಶಾಟ್

ತಾತ್ವಿಕವಾಗಿ, ನಾವು ಪ್ರತಿ ಪುಶ್‌ನೊಂದಿಗೆ ಗಿಟ್‌ಲ್ಯಾಬ್-ರನ್ನರ್ ಅನ್ನು ಮರುಹಂಚಿಕೆ ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ, ಹೊರತು, ಅದರ ಸಂರಚನೆಯಲ್ಲಿ ಏನೂ ಬದಲಾಗಿಲ್ಲ, ಅದನ್ನು ಸರಿಪಡಿಸೋಣ .gitlab-ci.yml:

deploy_gitlab_runner:
  extends: .deploy_qbec_app
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  before_script:
    - base64 -d "$GITCRYPT_KEY" | git-crypt unlock -
  script:
    - qbec apply default --root deploy/gitlab-runner --force:k8s-context __incluster__ --wait --yes
  only:
    changes:
      - deploy/gitlab-runner/**/*

ಬದಲಾವಣೆಗಳನ್ನು ಬದಲಾವಣೆಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ ನಿಯೋಜಿಸಿ/ಗಿಟ್ಲ್ಯಾಬ್-ರನ್ನರ್/ ಮತ್ತು ಯಾವುದಾದರೂ ಇದ್ದರೆ ಮಾತ್ರ ನಮ್ಮ ಕೆಲಸವನ್ನು ಪ್ರಚೋದಿಸುತ್ತದೆ

ನಮ್ಮ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲು ಮರೆಯಬೇಡಿ:

git add .gitlab-ci.yml
git commit -m "Reduce gitlab-runner deploy"

ಜಿಟ್ ಪುಶ್, ಅದು ಉತ್ತಮವಾಗಿದೆ:

ನವೀಕರಿಸಿದ ಪೈಪ್‌ಲೈನ್‌ನ ಸ್ಕ್ರೀನ್‌ಶಾಟ್

12. ಡೈನಾಮಿಕ್ ಪರಿಸರಗಳು

ಡೈನಾಮಿಕ್ ಪರಿಸರದೊಂದಿಗೆ ನಮ್ಮ ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ವೈವಿಧ್ಯಗೊಳಿಸಲು ಇದು ಸಮಯ.

ಮೊದಲಿಗೆ, ಕೆಲಸವನ್ನು ನವೀಕರಿಸೋಣ ಬಿಲ್ಡ್_ವೆಬ್‌ಸೈಟ್ ನಮ್ಮಲ್ಲಿ .gitlab-ci.yml, ಅದರಿಂದ ಬ್ಲಾಕ್ ಅನ್ನು ತೆಗೆದುಹಾಕುವುದು ಮಾತ್ರ, ಇದು ಯಾವುದೇ ಶಾಖೆಗೆ ಯಾವುದೇ ಬದ್ಧತೆಯ ಮೇಲೆ ಅದನ್ನು ಪ್ರಚೋದಿಸಲು Gitlab ಅನ್ನು ಒತ್ತಾಯಿಸುತ್ತದೆ:

build_website:
  extends: .build_docker_image
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  script:
    - mkdir -p $CI_PROJECT_DIR/artifacts
    - /kaniko/executor --cache --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/dockerfiles/website/Dockerfile --destination $CI_REGISTRY_IMAGE/website:$CI_COMMIT_REF_NAME --digest-file $CI_PROJECT_DIR/artifacts/website.digest
  artifacts:
    paths:
      - artifacts/

ನಂತರ ಕೆಲಸವನ್ನು ನವೀಕರಿಸಿ deploy_website, ಅಲ್ಲಿ ಒಂದು ಬ್ಲಾಕ್ ಅನ್ನು ಸೇರಿಸಿ ಪರಿಸರ:

deploy_website:
  extends: .deploy_qbec_app
  environment:
    name: prod
    url: https://docs.example.org
  script:
    - DIGEST="$(cat artifacts/website.digest)"
    - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST"

ಇದು Gitlab ಗೆ ಕೆಲಸವನ್ನು ಸಂಯೋಜಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ ಉತ್ಪನ್ನ ಪರಿಸರ ಮತ್ತು ಅದಕ್ಕೆ ಸರಿಯಾದ ಲಿಂಕ್ ಅನ್ನು ಪ್ರದರ್ಶಿಸಿ.

ಈಗ ನಾವು ಇನ್ನೂ ಎರಡು ಉದ್ಯೋಗಗಳನ್ನು ಸೇರಿಸೋಣ:

deploy_website:
  extends: .deploy_qbec_app
  environment:
    name: prod
    url: https://docs.example.org
  script:
    - DIGEST="$(cat artifacts/website.digest)"
    - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST"

deploy_review:
  extends: .deploy_qbec_app
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: http://$CI_ENVIRONMENT_SLUG.docs.example.org
    on_stop: stop_review
  script:
    - DIGEST="$(cat artifacts/website.digest)"
    - qbec apply review --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST" --vm:ext-str subdomain="$CI_ENVIRONMENT_SLUG" --app-tag "$CI_ENVIRONMENT_SLUG"
  only:
    refs:
    - branches
  except:
    refs:
      - master

stop_review:
  extends: .deploy_qbec_app
  environment:
    name: review/$CI_COMMIT_REF_NAME
    action: stop
  stage: deploy
  before_script:
    - git clone "$CI_REPOSITORY_URL" master
    - cd master
  script:
    - qbec delete review --root deploy/website --force:k8s-context __incluster__ --yes --vm:ext-str digest="$DIGEST" --vm:ext-str subdomain="$CI_ENVIRONMENT_SLUG" --app-tag "$CI_ENVIRONMENT_SLUG"
  variables:
    GIT_STRATEGY: none
  only:
    refs:
    - branches
  except:
    refs:
      - master
  when: manual

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

ನಾವು qbec ಗಾಗಿ ಹೊಸ ಆಯ್ಕೆಯನ್ನು ನೋಡುತ್ತೇವೆ: --ಅಪ್ಲಿಕೇಶನ್-ಟ್ಯಾಗ್ — ಇದು ಅಪ್ಲಿಕೇಶನ್‌ನ ನಿಯೋಜಿಸಲಾದ ಆವೃತ್ತಿಗಳನ್ನು ಟ್ಯಾಗ್ ಮಾಡಲು ಮತ್ತು ಈ ಟ್ಯಾಗ್‌ನಲ್ಲಿ ಮಾತ್ರ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ; ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಸಂಪನ್ಮೂಲಗಳನ್ನು ರಚಿಸುವಾಗ ಮತ್ತು ನಾಶಪಡಿಸುವಾಗ, qbec ಅವರೊಂದಿಗೆ ಮಾತ್ರ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ಈ ರೀತಿಯಾಗಿ ನಾವು ಪ್ರತಿ ವಿಮರ್ಶೆಗೆ ಪ್ರತ್ಯೇಕ ಪರಿಸರವನ್ನು ರಚಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಆದರೆ ಅದೇ ಒಂದು ಮರುಬಳಕೆ ಮಾಡಿ.

ಇಲ್ಲಿ ನಾವು ಸಹ ಬಳಸುತ್ತೇವೆ qbec ವಿಮರ್ಶೆಯನ್ನು ಅನ್ವಯಿಸಿ, ಬದಲಾಗಿ qbec ಡೀಫಾಲ್ಟ್ ಅನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ - ಇದು ನಿಖರವಾಗಿ ನಾವು ನಮ್ಮ ಪರಿಸರದ ವ್ಯತ್ಯಾಸಗಳನ್ನು ವಿವರಿಸಲು ಪ್ರಯತ್ನಿಸುವ ಕ್ಷಣವಾಗಿದೆ (ವಿಮರ್ಶೆ ಮತ್ತು ಡೀಫಾಲ್ಟ್):

ಸೇರಿಸೋಣ ವಿಮರ್ಶೆ ಪರಿಸರದಲ್ಲಿ deploy/website/qbec.yaml

spec:
  environments:
    review:
      defaultNamespace: docs
      server: https://kubernetes.example.org:8443

ನಂತರ ನಾವು ಅದನ್ನು ಘೋಷಿಸುತ್ತೇವೆ ನಿಯೋಜಿಸಿ/ವೆಬ್‌ಸೈಟ್/params.libsonnet:

local env = std.extVar('qbec.io/env');
local paramsMap = {
  _: import './environments/base.libsonnet',
  default: import './environments/default.libsonnet',
  review: import './environments/review.libsonnet',
};

if std.objectHas(paramsMap, env) then paramsMap[env] else error 'environment ' + env + ' not defined in ' + std.thisFile

ಮತ್ತು ಅದಕ್ಕೆ ಕಸ್ಟಮ್ ನಿಯತಾಂಕಗಳನ್ನು ಬರೆಯಿರಿ ನಿಯೋಜಿಸಿ/ವೆಬ್‌ಸೈಟ್/ಪರಿಸರ/review.libsonnet:

// this file has the param overrides for the default environment
local base = import './base.libsonnet';
local slug = std.extVar('qbec.io/tag');
local subdomain = std.extVar('subdomain');

base {
  components+: {
    website+: {
      name: 'example-docs-' + slug,
      domain: subdomain + '.docs.example.org',
    },
  },
}

ಜೋಬುವನ್ನು ಸಹ ಹತ್ತಿರದಿಂದ ನೋಡೋಣ ನಿಲ್ಲಿಸು_ವಿಮರ್ಶೆ, ಶಾಖೆಯನ್ನು ಅಳಿಸಿದಾಗ ಅದು ಪ್ರಚೋದಿಸಲ್ಪಡುತ್ತದೆ ಮತ್ತು ಆದ್ದರಿಂದ gitlab ಅದನ್ನು ಚೆಕ್ಔಟ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುವುದಿಲ್ಲ GIT_STRATEGY: ಯಾವುದೂ ಇಲ್ಲ, ನಂತರ ನಾವು ಕ್ಲೋನ್ ಮಾಡುತ್ತೇವೆ ಮಾಸ್ಟರ್- ಶಾಖೆ ಮತ್ತು ಅದರ ಮೂಲಕ ವಿಮರ್ಶೆಯನ್ನು ಅಳಿಸಿ.
ಇದು ಸ್ವಲ್ಪ ಗೊಂದಲಮಯವಾಗಿದೆ, ಆದರೆ ನಾನು ಇನ್ನೂ ಸುಂದರವಾದ ಮಾರ್ಗವನ್ನು ಕಂಡುಕೊಂಡಿಲ್ಲ.
ಪ್ರತಿ ವಿಮರ್ಶೆಯನ್ನು ಹೋಟೆಲ್ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗೆ ನಿಯೋಜಿಸುವುದು ಪರ್ಯಾಯ ಆಯ್ಕೆಯಾಗಿದೆ, ಅದನ್ನು ಯಾವಾಗಲೂ ಸಂಪೂರ್ಣವಾಗಿ ಕೆಡವಬಹುದು.

ನಮ್ಮ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲು ಮರೆಯಬೇಡಿ:

git add .
git commit -m "Enable automatic review"

ಜಿಟ್ ಪುಶ್, git ಚೆಕ್ಔಟ್ -b ಪರೀಕ್ಷೆ, git ಪುಶ್ ಮೂಲ ಪರೀಕ್ಷೆ, ಪರಿಶೀಲಿಸಿ:

Gitlab ನಲ್ಲಿ ರಚಿಸಲಾದ ಪರಿಸರಗಳ ಸ್ಕ್ರೀನ್‌ಶಾಟ್

ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡುತ್ತಿದೆಯೇ? - ಅದ್ಭುತವಾಗಿದೆ, ನಮ್ಮ ಪರೀಕ್ಷಾ ಶಾಖೆಯನ್ನು ಅಳಿಸಿ: git ಚೆಕ್ out ಟ್ ಮಾಸ್ಟರ್, git ಪುಶ್ ಮೂಲ: ಪರೀಕ್ಷೆ, ಪರಿಸರದ ಅಳಿಸುವಿಕೆ ಕೆಲಸಗಳು ದೋಷಗಳಿಲ್ಲದೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿವೆ ಎಂದು ನಾವು ಪರಿಶೀಲಿಸುತ್ತೇವೆ.

ಪ್ರಾಜೆಕ್ಟ್‌ನಲ್ಲಿ ಯಾವುದೇ ಡೆವಲಪರ್ ಶಾಖೆಗಳನ್ನು ರಚಿಸಬಹುದು, ಅವನು ಸಹ ಬದಲಾಯಿಸಬಹುದು ಎಂದು ಇಲ್ಲಿ ನಾನು ತಕ್ಷಣ ಸ್ಪಷ್ಟಪಡಿಸಲು ಬಯಸುತ್ತೇನೆ .gitlab-ci.yml ಫೈಲ್ ಮತ್ತು ಪ್ರವೇಶ ರಹಸ್ಯ ಅಸ್ಥಿರ.
ಆದ್ದರಿಂದ, ರಕ್ಷಿತ ಶಾಖೆಗಳಿಗೆ ಮಾತ್ರ ಅವುಗಳ ಬಳಕೆಯನ್ನು ಅನುಮತಿಸಲು ಬಲವಾಗಿ ಶಿಫಾರಸು ಮಾಡಲಾಗಿದೆ, ಉದಾಹರಣೆಗೆ ಮಾಸ್ಟರ್, ಅಥವಾ ಪ್ರತಿ ಪರಿಸರಕ್ಕೆ ಪ್ರತ್ಯೇಕವಾದ ಅಸ್ಥಿರಗಳನ್ನು ರಚಿಸಿ.

13. ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ

ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ ಇದು GitLab ವೈಶಿಷ್ಟ್ಯವಾಗಿದ್ದು, ನಿಯೋಜಿತ ಪರಿಸರದಲ್ಲಿ ತ್ವರಿತವಾಗಿ ವೀಕ್ಷಿಸಲು ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಪ್ರತಿ ಫೈಲ್‌ಗೆ ಬಟನ್ ಅನ್ನು ಸೇರಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

ಈ ಗುಂಡಿಗಳು ಕಾಣಿಸಿಕೊಳ್ಳಲು, ನೀವು ಫೈಲ್ ಅನ್ನು ರಚಿಸಬೇಕಾಗಿದೆ .gitlab/route-map.yml ಮತ್ತು ಅದರಲ್ಲಿರುವ ಎಲ್ಲಾ ಮಾರ್ಗ ರೂಪಾಂತರಗಳನ್ನು ವಿವರಿಸಿ; ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ ಇದು ತುಂಬಾ ಸರಳವಾಗಿರುತ್ತದೆ:

# Indices
- source: /content/(.+?)_index.(md|html)/ 
  public: '1'

# Pages
- source: /content/(.+?).(md|html)/ 
  public: '1/'

ನಮ್ಮ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲು ಮರೆಯಬೇಡಿ:

git add .gitlab/
git commit -m "Enable review apps"

ಜಿಟ್ ಪುಶ್, ಮತ್ತು ಪರಿಶೀಲಿಸಿ:

ವಿಮರ್ಶೆ ಅಪ್ಲಿಕೇಶನ್ ಬಟನ್‌ನ ಸ್ಕ್ರೀನ್‌ಶಾಟ್

ಕೆಲಸ ಮುಗಿದಿದೆ!

ಯೋಜನೆಯ ಮೂಲಗಳು:

• Gitlab ನಲ್ಲಿ: https://gitlab.com/kvaps/docs.example.org
• GitHub ನಲ್ಲಿ: https://github.com/kvaps/docs.example.org

ನಿಮ್ಮ ಗಮನಕ್ಕೆ ಧನ್ಯವಾದಗಳು, ನೀವು ಅದನ್ನು ಇಷ್ಟಪಟ್ಟಿದ್ದೀರಿ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ

ಮೂಲ: www.habr.com