ਸਤ ਸ੍ਰੀ ਅਕਾਲ! ਹਾਲ ਹੀ ਵਿੱਚ, ਬਹੁਤ ਸਾਰੇ ਵਧੀਆ ਆਟੋਮੇਸ਼ਨ ਟੂਲ ਡੌਕਰ ਚਿੱਤਰਾਂ ਨੂੰ ਬਣਾਉਣ ਅਤੇ ਕੁਬਰਨੇਟਸ ਲਈ ਤੈਨਾਤੀ ਲਈ ਜਾਰੀ ਕੀਤੇ ਗਏ ਹਨ। ਇਸ ਸਬੰਧ ਵਿੱਚ, ਮੈਂ ਗਿੱਟਲੈਬ ਦੇ ਨਾਲ ਖੇਡਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ, ਇਸ ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ਦਾ ਚੰਗੀ ਤਰ੍ਹਾਂ ਅਧਿਐਨ ਕੀਤਾ ਅਤੇ, ਬੇਸ਼ਕ, ਪਾਈਪਲਾਈਨ ਸਥਾਪਤ ਕੀਤੀ।

ਇਹ ਕੰਮ ਵੈੱਬਸਾਈਟ ਤੋਂ ਪ੍ਰੇਰਿਤ ਸੀ kubernetes.io, ਜਿਸ ਤੋਂ ਉਤਪੰਨ ਹੁੰਦਾ ਹੈ ਸਰੋਤ ਕੋਡ ਸਵੈਚਲਿਤ ਤੌਰ 'ਤੇ, ਅਤੇ ਭੇਜੀ ਗਈ ਹਰੇਕ ਪੂਲ ਬੇਨਤੀ ਲਈ, ਰੋਬੋਟ ਆਪਣੇ ਆਪ ਹੀ ਤੁਹਾਡੀਆਂ ਤਬਦੀਲੀਆਂ ਨਾਲ ਸਾਈਟ ਦਾ ਪੂਰਵਦਰਸ਼ਨ ਸੰਸਕਰਣ ਤਿਆਰ ਕਰਦਾ ਹੈ ਅਤੇ ਦੇਖਣ ਲਈ ਇੱਕ ਲਿੰਕ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

ਮੈਂ ਸਕ੍ਰੈਚ ਤੋਂ ਇੱਕ ਸਮਾਨ ਪ੍ਰਕਿਰਿਆ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ, ਪਰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਗਿਟਲੈਬ ਸੀਆਈ ਅਤੇ ਮੁਫਤ ਟੂਲਸ 'ਤੇ ਬਣਾਇਆ ਗਿਆ ਹੈ ਜੋ ਮੈਂ ਕੁਬਰਨੇਟਸ ਲਈ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਤੈਨਾਤ ਕਰਨ ਲਈ ਵਰਤਣ ਲਈ ਆਦੀ ਹਾਂ। ਅੱਜ ਮੈਂ ਤੁਹਾਨੂੰ ਉਨ੍ਹਾਂ ਬਾਰੇ ਹੋਰ ਦੱਸਾਂਗਾ.

ਲੇਖ ਟੂਲਸ ਬਾਰੇ ਚਰਚਾ ਕਰੇਗਾ ਜਿਵੇਂ ਕਿ:
Hugo, 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

ਅਤੇ ਉਸੇ ਸਮੇਂ git ਰਿਪੋਜ਼ਟਰੀ:

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/ ਸਾਡੀ ਨਵੀਂ ਬਣਾਈ ਵੈੱਬਸਾਈਟ ਦੀ ਜਾਂਚ ਕਰੋ, ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਕੀਤੀਆਂ ਸਾਰੀਆਂ ਤਬਦੀਲੀਆਂ ਆਪਣੇ ਆਪ ਬਰਾਊਜ਼ਰ ਵਿੱਚ ਖੁੱਲ੍ਹੇ ਪੰਨੇ ਨੂੰ ਅੱਪਡੇਟ ਕਰਦੀਆਂ ਹਨ, ਬਹੁਤ ਸੁਵਿਧਾਜਨਕ!

ਵਿੱਚ ਇੱਕ ਕਵਰ ਪੇਜ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ content/_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

• dockerfiles/ - ਡੌਕਰਫਾਈਲਾਂ ਨਾਲ ਡਾਇਰੈਕਟਰੀਆਂ ਅਤੇ ਸਾਡੇ ਡੌਕਰ ਚਿੱਤਰਾਂ ਨੂੰ ਬਣਾਉਣ ਲਈ ਲੋੜੀਂਦੀ ਹਰ ਚੀਜ਼ ਸ਼ਾਮਲ ਕਰੋ।
• ਤੈਨਾਤ/ — ਸਾਡੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਕੁਬਰਨੇਟਸ 'ਤੇ ਤੈਨਾਤ ਕਰਨ ਲਈ ਡਾਇਰੈਕਟਰੀਆਂ ਰੱਖਦਾ ਹੈ

ਇਸ ਤਰ੍ਹਾਂ, ਅਸੀਂ ਮਾਰਗ ਦੇ ਨਾਲ ਆਪਣੀ ਪਹਿਲੀ ਡੌਕਰਫਾਈਲ ਬਣਾਵਾਂਗੇ dockerfiles/website/dockerfile

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" ]

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਵੇਖ ਸਕਦੇ ਹੋ, ਡੌਕਰਫਾਈਲ ਵਿੱਚ ਦੋ ਹਨ ਤੋਂ, ਇਸ ਮੌਕੇ ਨੂੰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਬਹੁ-ਪੜਾਅ ਦਾ ਨਿਰਮਾਣ ਅਤੇ ਤੁਹਾਨੂੰ ਅੰਤਿਮ ਡੌਕਰ ਚਿੱਤਰ ਤੋਂ ਬੇਲੋੜੀ ਹਰ ਚੀਜ਼ ਨੂੰ ਬਾਹਰ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।
ਇਸ ਤਰ੍ਹਾਂ, ਅੰਤਿਮ ਚਿੱਤਰ ਵਿੱਚ ਸਿਰਫ ਸ਼ਾਮਲ ਹੋਵੇਗਾ darkhttpd (ਹਲਕੇ HTTP ਸਰਵਰ) ਅਤੇ ਜਨਤਕ/ — ਸਾਡੀ ਸਥਿਰ ਤੌਰ 'ਤੇ ਤਿਆਰ ਕੀਤੀ ਵੈੱਬਸਾਈਟ ਦੀ ਸਮੱਗਰੀ।

ਸਾਡੇ ਬਦਲਾਅ ਕਰਨ ਲਈ ਨਾ ਭੁੱਲੋ:

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

3. ਕਨੀਕੋ ਨੂੰ ਜਾਣਨਾ

ਇੱਕ ਡੌਕਰ ਚਿੱਤਰ ਬਿਲਡਰ ਵਜੋਂ, ਮੈਂ ਵਰਤਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਕਨੀਕੋ, ਕਿਉਂਕਿ ਇਸਦੇ ਓਪਰੇਸ਼ਨ ਲਈ ਇੱਕ ਡੌਕਰ ਡੈਮਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਬਿਲਡ ਆਪਣੇ ਆਪ ਨੂੰ ਕਿਸੇ ਵੀ ਮਸ਼ੀਨ 'ਤੇ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਕੈਸ਼ ਨੂੰ ਸਿੱਧਾ ਰਜਿਸਟਰੀ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਇਸ ਤਰ੍ਹਾਂ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਿਰੰਤਰ ਸਟੋਰੇਜ ਦੀ ਜ਼ਰੂਰਤ ਨੂੰ ਖਤਮ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਚਿੱਤਰ ਨੂੰ ਬਣਾਉਣ ਲਈ, ਸਿਰਫ ਕੰਟੇਨਰ ਨਾਲ ਚਲਾਓ kaniko ਐਗਜ਼ੀਕਿਊਟਰ ਅਤੇ ਇਸਨੂੰ ਮੌਜੂਦਾ ਬਿਲਡ ਸੰਦਰਭ ਵਿੱਚ ਪਾਸ ਕਰੋ; ਇਹ ਡੌਕਰ ਦੁਆਰਾ, ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਵੀ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ:

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, ਪਰ ਤੁਸੀਂ ਪੈਰਾਮੀਟਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੋਈ ਹੋਰ ਮਾਰਗ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦੇ ਹੋ --cache-repo.

ਡੌਕਰ-ਰਜਿਸਟਰੀ ਦਾ ਸਕ੍ਰੀਨਸ਼ੌਟ

4. qbec ਨੂੰ ਜਾਣਨਾ

Qbec ਇੱਕ ਡਿਪਲਾਇਮੈਂਟ ਟੂਲ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਆਪਣੀ ਐਪਲੀਕੇਸ਼ਨ ਮੈਨੀਫੈਸਟ ਦਾ ਵਰਣਨ ਕਰਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਤੈਨਾਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। Jsonnet ਨੂੰ ਮੁੱਖ ਸੰਟੈਕਸ ਵਜੋਂ ਵਰਤਣਾ ਤੁਹਾਨੂੰ ਕਈ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ ਅੰਤਰਾਂ ਦੇ ਵਰਣਨ ਨੂੰ ਬਹੁਤ ਸਰਲ ਬਣਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਕੋਡ ਦੁਹਰਾਓ ਨੂੰ ਲਗਭਗ ਪੂਰੀ ਤਰ੍ਹਾਂ ਖਤਮ ਕਰਦਾ ਹੈ।

ਇਹ ਉਹਨਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ ਖਾਸ ਤੌਰ 'ਤੇ ਸੱਚ ਹੋ ਸਕਦਾ ਹੈ ਜਿੱਥੇ ਤੁਹਾਨੂੰ ਵੱਖ-ਵੱਖ ਮਾਪਦੰਡਾਂ ਵਾਲੇ ਕਈ ਕਲੱਸਟਰਾਂ ਵਿੱਚ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਤੈਨਾਤ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ Git ਵਿੱਚ ਘੋਸ਼ਣਾਤਮਕ ਤੌਰ 'ਤੇ ਵਰਣਨ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ।

Qbec ਤੁਹਾਨੂੰ ਹੈਲਮ ਚਾਰਟ ਨੂੰ ਲੋੜੀਂਦੇ ਮਾਪਦੰਡਾਂ ਨੂੰ ਪਾਸ ਕਰਕੇ ਰੈਂਡਰ ਕਰਨ ਦੀ ਵੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਉਹਨਾਂ ਨੂੰ ਨਿਯਮਤ ਮੈਨੀਫੈਸਟ ਵਾਂਗ ਹੀ ਸੰਚਾਲਿਤ ਕਰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ ਉਹਨਾਂ 'ਤੇ ਵੱਖ-ਵੱਖ ਪਰਿਵਰਤਨ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਇਹ, ਬਦਲੇ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਲੋੜ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਚਾਰਟ ਮਿਊਜ਼ੀਅਮ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਭਾਵ, ਤੁਸੀਂ ਚਾਰਟ ਨੂੰ ਸਿੱਧੇ git ਤੋਂ ਸਟੋਰ ਅਤੇ ਰੈਂਡਰ ਕਰ ਸਕਦੇ ਹੋ, ਜਿੱਥੇ ਉਹ ਸਬੰਧਤ ਹਨ।

ਜਿਵੇਂ ਕਿ ਮੈਂ ਪਹਿਲਾਂ ਕਿਹਾ ਸੀ, ਅਸੀਂ ਸਾਰੀਆਂ ਤੈਨਾਤੀਆਂ ਨੂੰ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਸਟੋਰ ਕਰਾਂਗੇ ਤੈਨਾਤ/:

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',
    },
  },
}

ਆਉ ਆਪਣਾ ਪਹਿਲਾ ਕੰਪੋਨੈਂਟ ਵੀ ਬਣਾਈਏ components/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 ਆਪਣੇ ਆਮ yaml ਨੂੰ json ਵਿੱਚ ਬਦਲਣ ਲਈ, ਜਾਂ, ਜੇਕਰ ਤੁਹਾਡੇ ਭਾਗਾਂ ਵਿੱਚ ਕੋਈ ਵੇਰੀਏਬਲ ਨਹੀਂ ਹਨ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਨਿਯਮਤ yaml ਦੇ ਰੂਪ ਵਿੱਚ ਵਰਣਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ jsonnet ਮੈਂ ਤੁਹਾਡੇ ਸੰਪਾਦਕ ਲਈ ਇੱਕ ਪਲੱਗਇਨ ਸਥਾਪਤ ਕਰਨ ਦੀ ਜ਼ੋਰਦਾਰ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹਾਂ

ਉਦਾਹਰਨ ਲਈ, vim ਲਈ ਇੱਕ ਪਲੱਗਇਨ ਹੈ vim-jsonnet, ਜੋ ਸਿੰਟੈਕਸ ਹਾਈਲਾਈਟਿੰਗ ਨੂੰ ਚਾਲੂ ਕਰਦਾ ਹੈ ਅਤੇ ਆਪਣੇ ਆਪ ਹੀ ਚਲਾਉਂਦਾ ਹੈ jsonnet fmt ਹਰ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਸੇਵ ਕਰਦੇ ਹੋ (ਜਸੋਨੈਟ ਸਥਾਪਤ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ)।

ਸਭ ਕੁਝ ਤਿਆਰ ਹੈ, ਹੁਣ ਅਸੀਂ ਤੈਨਾਤ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹਾਂ:

ਇਹ ਦੇਖਣ ਲਈ ਕਿ ਸਾਨੂੰ ਕੀ ਮਿਲਿਆ, ਚਲੋ:

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. ਕੁਬਰਨੇਟਸ-ਐਗਜ਼ੀਕਿਊਟਰ ਨਾਲ ਗਿਟਲੈਬ-ਰਨਰ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ

ਹਾਲ ਹੀ ਤੱਕ ਮੈਂ ਸਿਰਫ ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਵਰਤਿਆ gitlab-ਦੌੜਾਕ ਸ਼ੈੱਲ ਜਾਂ ਡੌਕਰ-ਐਗਜ਼ੀਕਿਊਟਰ ਨਾਲ ਪਹਿਲਾਂ ਤੋਂ ਤਿਆਰ ਮਸ਼ੀਨ (LXC ਕੰਟੇਨਰ) 'ਤੇ। ਸ਼ੁਰੂ ਵਿੱਚ, ਸਾਡੇ ਕੋਲ ਸਾਡੀ ਗਿਟਲੈਬ ਵਿੱਚ ਵਿਸ਼ਵ ਪੱਧਰ 'ਤੇ ਪਰਿਭਾਸ਼ਿਤ ਕਈ ਅਜਿਹੇ ਦੌੜਾਕ ਸਨ। ਉਹਨਾਂ ਨੇ ਸਾਰੇ ਪ੍ਰੋਜੈਕਟਾਂ ਲਈ ਡੌਕਰ ਚਿੱਤਰ ਇਕੱਠੇ ਕੀਤੇ.

ਪਰ ਜਿਵੇਂ ਕਿ ਅਭਿਆਸ ਨੇ ਦਿਖਾਇਆ ਹੈ, ਇਹ ਵਿਕਲਪ ਸਭ ਤੋਂ ਆਦਰਸ਼ ਨਹੀਂ ਹੈ, ਵਿਹਾਰਕਤਾ ਅਤੇ ਸੁਰੱਖਿਆ ਦੋਵਾਂ ਦੇ ਰੂਪ ਵਿੱਚ. ਹਰੇਕ ਪ੍ਰੋਜੈਕਟ ਲਈ, ਜਾਂ ਇੱਥੋਂ ਤੱਕ ਕਿ ਹਰੇਕ ਵਾਤਾਵਰਣ ਲਈ ਵੱਖਰੇ ਦੌੜਾਕਾਂ ਨੂੰ ਤੈਨਾਤ ਕਰਨਾ ਬਹੁਤ ਵਧੀਆ ਅਤੇ ਵਿਚਾਰਧਾਰਕ ਤੌਰ 'ਤੇ ਵਧੇਰੇ ਸਹੀ ਹੈ।

ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਇਹ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਹੁਣ ਅਸੀਂ ਤੈਨਾਤ ਕਰਾਂਗੇ gitlab-ਦੌੜਾਕ ਸਿੱਧੇ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਸਾਡੇ ਪ੍ਰੋਜੈਕਟ ਦੇ ਹਿੱਸੇ ਵਜੋਂ।

ਗਿਟਲੈਬ ਕੁਬਰਨੇਟਸ ਨੂੰ ਗਿਟਲੈਬ-ਰਨਰ ਨੂੰ ਤਾਇਨਾਤ ਕਰਨ ਲਈ ਤਿਆਰ-ਬਣਾਇਆ ਹੈਲਮ ਚਾਰਟ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਇਸ ਲਈ ਤੁਹਾਨੂੰ ਸਭ ਕੁਝ ਲੱਭਣ ਦੀ ਲੋੜ ਹੈ ਰਜਿਸਟਰੇਸ਼ਨ ਟੋਕਨ ਵਿੱਚ ਸਾਡੇ ਪ੍ਰੋਜੈਕਟ ਲਈ ਸੈਟਿੰਗਾਂ -> 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 - ਤੁਹਾਡੇ ਗਿਟਲਬ ਸਰਵਰ ਦਾ ਪਤਾ।
• yga8y-jdCusVDn_t4Wxc - ਤੁਹਾਡੇ ਪ੍ਰੋਜੈਕਟ ਲਈ ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਟੋਕਨ।
• rbac.create=true — ਕੁਬਰਨੇਟਸ-ਐਗਜ਼ੀਕਿਊਟਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਾਡੇ ਕੰਮ ਕਰਨ ਲਈ ਪੌਡ ਬਣਾਉਣ ਦੇ ਯੋਗ ਹੋਣ ਲਈ ਦੌੜਾਕ ਨੂੰ ਲੋੜੀਂਦੇ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

ਜੇ ਸਭ ਕੁਝ ਸਹੀ ਢੰਗ ਨਾਲ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਭਾਗ ਵਿੱਚ ਇੱਕ ਰਜਿਸਟਰਡ ਦੌੜਾਕ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ ਰਨਰ, ਤੁਹਾਡੀ ਪ੍ਰੋਜੈਕਟ ਸੈਟਿੰਗਾਂ ਵਿੱਚ।

ਸ਼ਾਮਲ ਕੀਤੇ ਗਏ ਦੌੜਾਕ ਦਾ ਸਕ੍ਰੀਨਸ਼ੌਟ

ਕੀ ਇਹ ਸਧਾਰਨ ਹੈ? - ਹਾਂ, ਇਹ ਬਹੁਤ ਸਧਾਰਨ ਹੈ! ਦੌੜਾਕਾਂ ਨੂੰ ਹੱਥੀਂ ਰਜਿਸਟਰ ਕਰਨ ਵਿੱਚ ਕੋਈ ਹੋਰ ਮੁਸ਼ਕਲ ਨਹੀਂ, ਹੁਣ ਤੋਂ ਦੌੜਾਕ ਆਪਣੇ ਆਪ ਹੀ ਬਣਾਏ ਅਤੇ ਨਸ਼ਟ ਹੋ ਜਾਣਗੇ।

6. QBEC ਨਾਲ ਹੈਲਮ ਚਾਰਟ ਲਗਾਓ

ਕਿਉਂਕਿ ਅਸੀਂ ਵਿਚਾਰ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ gitlab-ਦੌੜਾਕ ਸਾਡੇ ਪ੍ਰੋਜੈਕਟ ਦਾ ਹਿੱਸਾ ਹੈ, ਇਹ ਸਾਡੀ Git ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਇਸਦਾ ਵਰਣਨ ਕਰਨ ਦਾ ਸਮਾਂ ਹੈ.

ਅਸੀਂ ਇਸਨੂੰ ਇੱਕ ਵੱਖਰੇ ਹਿੱਸੇ ਵਜੋਂ ਵਰਣਨ ਕਰ ਸਕਦੇ ਹਾਂ ਵੈਬਸਾਈਟ, ਪਰ ਭਵਿੱਖ ਵਿੱਚ ਅਸੀਂ ਵੱਖ-ਵੱਖ ਕਾਪੀਆਂ ਤੈਨਾਤ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਹੇ ਹਾਂ ਵੈਬਸਾਈਟ ਬਹੁਤ ਅਕਸਰ, ਉਲਟ gitlab-ਦੌੜਾਕ, ਜੋ ਕਿ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਪ੍ਰਤੀ ਸਿਰਫ਼ ਇੱਕ ਵਾਰ ਤੈਨਾਤ ਕੀਤਾ ਜਾਵੇਗਾ। ਤਾਂ ਆਓ ਇਸਦੇ ਲਈ ਇੱਕ ਵੱਖਰੀ ਐਪਲੀਕੇਸ਼ਨ ਸ਼ੁਰੂ ਕਰੀਏ:

cd deploy
qbec init gitlab-runner
cd gitlab-runner

ਇਸ ਵਾਰ ਅਸੀਂ ਕੁਬਰਨੇਟਸ ਇਕਾਈਆਂ ਦਾ ਵਰਣਨ ਹੱਥੀਂ ਨਹੀਂ ਕਰਾਂਗੇ, ਪਰ ਇੱਕ ਤਿਆਰ ਹੈਲਮ ਚਾਰਟ ਲਵਾਂਗੇ। Qbec ਦੇ ਫਾਇਦਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈਲਮ ਚਾਰਟ ਨੂੰ ਸਿੱਧੇ ਇੱਕ Git ਰਿਪੋਜ਼ਟਰੀ ਤੋਂ ਰੈਂਡਰ ਕਰਨ ਦੀ ਯੋਗਤਾ ਹੈ।

ਆਉ ਇਸਨੂੰ git ਸਬਮੋਡਿਊਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕਨੈਕਟ ਕਰੀਏ:

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

ਹੁਣ ਡਾਇਰੈਕਟਰੀ ਵਿਕਰੇਤਾ/ਗਿਟਲੈਬ-ਰਨਰ ਸਾਡੇ ਕੋਲ gitlab-ਰਨਰ ਲਈ ਇੱਕ ਚਾਰਟ ਦੇ ਨਾਲ ਇੱਕ ਰਿਪੋਜ਼ਟਰੀ ਹੈ।

ਇਸੇ ਤਰ੍ਹਾਂ, ਤੁਸੀਂ ਹੋਰ ਰਿਪੋਜ਼ਟਰੀਆਂ ਨੂੰ ਜੋੜ ਸਕਦੇ ਹੋ, ਉਦਾਹਰਨ ਲਈ, ਅਧਿਕਾਰਤ ਚਾਰਟ ਨਾਲ ਪੂਰੀ ਰਿਪੋਜ਼ਟਰੀ https://github.com/helm/charts

ਆਉ ਕੰਪੋਨੈਂਟ ਦਾ ਵਰਣਨ ਕਰੀਏ components/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,
  }
)

ਨੂੰ ਪਹਿਲੀ ਦਲੀਲ expandHelmTemplate ਅਸੀਂ ਚਾਰਟ ਦਾ ਮਾਰਗ ਪਾਸ ਕਰਦੇ ਹਾਂ, ਫਿਰ 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,
      },
    },
  },
}

ਧਿਆਨ ਦੇਵੋ runnerRegistrationToken ਅਸੀਂ ਇੱਕ ਬਾਹਰੀ ਫਾਈਲ ਤੋਂ ਲੈਂਦੇ ਹਾਂ secrets/base.libsonnet, ਆਓ ਇਸਨੂੰ ਬਣਾਈਏ:

{
  runnerRegistrationToken: 'yga8y-jdCusVDn_t4Wxc',
}

ਚਲੋ ਜਾਂਚ ਕਰੀਏ ਕਿ ਕੀ ਸਭ ਕੁਝ ਕੰਮ ਕਰਦਾ ਹੈ:

qbec show default

ਜੇਕਰ ਸਭ ਕੁਝ ਕ੍ਰਮ ਵਿੱਚ ਹੈ, ਤਾਂ ਅਸੀਂ ਹੇਲਮ ਦੁਆਰਾ ਸਾਡੀ ਪਿਛਲੀ ਤੈਨਾਤ ਰੀਲੀਜ਼ ਨੂੰ ਮਿਟਾ ਸਕਦੇ ਹਾਂ:

helm uninstall gitlab-runner

ਅਤੇ ਇਸਨੂੰ ਉਸੇ ਤਰੀਕੇ ਨਾਲ ਲਾਗੂ ਕਰੋ, ਪਰ qbec ਦੁਆਰਾ:

qbec apply default

7. ਗਿੱਟ-ਕ੍ਰਿਪਟ ਨਾਲ ਜਾਣ-ਪਛਾਣ

ਗਿਟ-ਕ੍ਰਿਪਟ ਇੱਕ ਟੂਲ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਤੁਹਾਡੀ ਰਿਪੋਜ਼ਟਰੀ ਲਈ ਪਾਰਦਰਸ਼ੀ ਐਨਕ੍ਰਿਪਸ਼ਨ ਸੈਟ ਅਪ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

ਇਸ ਸਮੇਂ, gitlab-runner ਲਈ ਸਾਡੀ ਡਾਇਰੈਕਟਰੀ ਬਣਤਰ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ:

.
├── 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 crypt init

ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ PGP ਕੁੰਜੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਤੁਰੰਤ ਆਪਣੇ ਆਪ ਨੂੰ ਇਸ ਪ੍ਰੋਜੈਕਟ ਲਈ ਇੱਕ ਸਹਿਯੋਗੀ ਵਜੋਂ ਸ਼ਾਮਲ ਕਰ ਸਕਦੇ ਹੋ:

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

ਇਸ ਤਰ੍ਹਾਂ ਤੁਸੀਂ ਹਮੇਸ਼ਾ ਆਪਣੀ ਨਿੱਜੀ ਕੁੰਜੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਸ ਰਿਪੋਜ਼ਟਰੀ ਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕਰ ਸਕਦੇ ਹੋ।

ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ PGP ਕੁੰਜੀ ਨਹੀਂ ਹੈ ਅਤੇ ਇਸਦੀ ਉਮੀਦ ਨਹੀਂ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਦੂਜੇ ਤਰੀਕੇ ਨਾਲ ਜਾ ਸਕਦੇ ਹੋ ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਕੁੰਜੀ ਨੂੰ ਨਿਰਯਾਤ ਕਰ ਸਕਦੇ ਹੋ:

git crypt export-key /path/to/keyfile

ਇਸ ਤਰ੍ਹਾਂ, ਜਿਸ ਕਿਸੇ ਨੇ ਵੀ ਬਰਾਮਦ ਕੀਤਾ ਹੈ keyfile ਤੁਹਾਡੀ ਰਿਪੋਜ਼ਟਰੀ ਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕਰਨ ਦੇ ਯੋਗ ਹੋਵੇਗਾ।

ਇਹ ਸਾਡਾ ਪਹਿਲਾ ਰਾਜ਼ ਸਥਾਪਤ ਕਰਨ ਦਾ ਸਮਾਂ ਹੈ.
ਮੈਨੂੰ ਤੁਹਾਨੂੰ ਯਾਦ ਦਿਵਾਉਣ ਦਿਓ ਕਿ ਅਸੀਂ ਅਜੇ ਵੀ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਹਾਂ deploy/gitlab-runner/, ਜਿੱਥੇ ਸਾਡੇ ਕੋਲ ਇੱਕ ਡਾਇਰੈਕਟਰੀ ਹੈ ਭੇਦ/, ਆਓ ਇਸ ਵਿੱਚ ਸਾਰੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਐਨਕ੍ਰਿਪਟ ਕਰੀਏ, ਇਸਦੇ ਲਈ ਅਸੀਂ ਇੱਕ ਫਾਈਲ ਬਣਾਵਾਂਗੇ ਭੇਦ/.gitattributes ਹੇਠ ਦਿੱਤੀ ਸਮੱਗਰੀ ਦੇ ਨਾਲ:

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

ਜਿਵੇਂ ਕਿ ਸਮੱਗਰੀ ਤੋਂ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਸਾਰੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਮਾਸਕ ਕੀਤਾ ਗਿਆ ਹੈ * ਦੁਆਰਾ ਚਲਾਇਆ ਜਾਵੇਗਾ git-ਕ੍ਰਿਪਟ, ਸਭ ਨੂੰ ਛੱਡ ਕੇ .gitattributes

ਅਸੀਂ ਇਸਨੂੰ ਚਲਾ ਕੇ ਜਾਂਚ ਸਕਦੇ ਹਾਂ:

git crypt status -e

ਆਉਟਪੁੱਟ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਉਹਨਾਂ ਸਾਰੀਆਂ ਫਾਈਲਾਂ ਦੀ ਇੱਕ ਸੂਚੀ ਹੋਵੇਗੀ ਜਿਨ੍ਹਾਂ ਲਈ ਏਨਕ੍ਰਿਪਸ਼ਨ ਸਮਰੱਥ ਹੈ

ਬਸ, ਹੁਣ ਅਸੀਂ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਆਪਣੀਆਂ ਤਬਦੀਲੀਆਂ ਕਰ ਸਕਦੇ ਹਾਂ:

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

ਇੱਕ ਰਿਪੋਜ਼ਟਰੀ ਨੂੰ ਬਲੌਕ ਕਰਨ ਲਈ, ਬੱਸ ਚਲਾਓ:

git crypt lock

ਅਤੇ ਤੁਰੰਤ ਸਾਰੀਆਂ ਐਨਕ੍ਰਿਪਟਡ ਫਾਈਲਾਂ ਬਾਈਨਰੀ ਚੀਜ਼ ਵਿੱਚ ਬਦਲ ਜਾਣਗੀਆਂ, ਉਹਨਾਂ ਨੂੰ ਪੜ੍ਹਨਾ ਅਸੰਭਵ ਹੋ ਜਾਵੇਗਾ.
ਰਿਪੋਜ਼ਟਰੀ ਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕਰਨ ਲਈ, ਚਲਾਓ:

git crypt unlock

8. ਇੱਕ ਟੂਲਬਾਕਸ ਚਿੱਤਰ ਬਣਾਓ

ਇੱਕ ਟੂਲਬਾਕਸ ਚਿੱਤਰ ਇੱਕ ਚਿੱਤਰ ਹੁੰਦਾ ਹੈ ਜਿਸਦੀ ਵਰਤੋਂ ਅਸੀਂ ਆਪਣੇ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਕਰਾਂਗੇ। ਇਹ Gitlab ਦੌੜਾਕ ਦੁਆਰਾ ਆਮ ਤੈਨਾਤੀ ਕਾਰਜਾਂ ਨੂੰ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾਵੇਗਾ।

ਇੱਥੇ ਸਭ ਕੁਝ ਸਧਾਰਨ ਹੈ, ਆਓ ਇੱਕ ਨਵਾਂ ਬਣਾਓ dockerfiles/ਟੂਲਬਾਕਸ/Dockerfile ਹੇਠ ਦਿੱਤੀ ਸਮੱਗਰੀ ਦੇ ਨਾਲ:

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, ਪਰ ਤੁਸੀਂ ਪਾਈਪਲਾਈਨ ਸੈਟਅਪ ਪੜਾਅ ਦੌਰਾਨ ਇਸਦੇ ਨਾਲ ਖੇਡਣਾ ਚਾਹ ਸਕਦੇ ਹੋ।

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਕੁਬਰਨੇਟਸ ਨਾਲ ਸੰਚਾਰ ਕਰਨ ਅਤੇ ਇਸ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣ ਲਈ, ਸਾਨੂੰ ਗਿਟਲੈਬ-ਰਨਰ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੇ ਪੌਡਾਂ ਲਈ ਇੱਕ ਭੂਮਿਕਾ ਦੀ ਸੰਰਚਨਾ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਅਜਿਹਾ ਕਰਨ ਲਈ, ਆਓ gitlab-runner ਨਾਲ ਡਾਇਰੈਕਟਰੀ 'ਤੇ ਚੱਲੀਏ:

cd deploy/gitlab-runner

ਅਤੇ ਇੱਕ ਨਵਾਂ ਭਾਗ ਸ਼ਾਮਲ ਕਰੋ components/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

ਅਤੇ ਸਾਡੀਆਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਕੁਬਰਨੇਟਸ 'ਤੇ ਲਾਗੂ ਕਰੋ:

qbec apply default

ਨਾਲ ਹੀ, ਸਾਡੀਆਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਗਿੱਟ ਵਿੱਚ ਕਰਨਾ ਨਾ ਭੁੱਲੋ:

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 push --tags, ਅਤੇ ਆਓ ਸਾਡੀ ਪਹਿਲੀ ਪਾਈਪਲਾਈਨ ਨੂੰ ਵੇਖੀਏ:

ਪਹਿਲੀ ਪਾਈਪਲਾਈਨ ਦਾ ਸਕ੍ਰੀਨਸ਼ੌਟ

ਇਹ ਇਸ ਤੱਥ ਵੱਲ ਤੁਹਾਡਾ ਧਿਆਨ ਖਿੱਚਣ ਯੋਗ ਹੈ ਕਿ ਟੈਗਸ ਦੁਆਰਾ ਅਸੈਂਬਲੀ ਡੌਕਰ ਚਿੱਤਰਾਂ ਨੂੰ ਬਣਾਉਣ ਲਈ ਢੁਕਵੀਂ ਹੈ, ਪਰ ਕੁਬਰਨੇਟਸ ਲਈ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਤਾਇਨਾਤ ਕਰਨ ਲਈ ਢੁਕਵਾਂ ਨਹੀਂ ਹੈ। ਕਿਉਂਕਿ ਨਵੇਂ ਟੈਗ ਪੁਰਾਣੇ ਕਮਿਟਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ, ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਉਹਨਾਂ ਲਈ ਪਾਈਪਲਾਈਨ ਸ਼ੁਰੂ ਕਰਨ ਨਾਲ ਪੁਰਾਣੇ ਸੰਸਕਰਣ ਦੀ ਤੈਨਾਤੀ ਹੋਵੇਗੀ।

ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, ਆਮ ਤੌਰ 'ਤੇ ਡੌਕਰ ਚਿੱਤਰਾਂ ਦੇ ਨਿਰਮਾਣ ਨੂੰ ਟੈਗਸ ਨਾਲ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਇੱਕ ਸ਼ਾਖਾ ਵਿੱਚ ਤਾਇਨਾਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਮਾਸਟਰ, ਜਿਸ ਵਿੱਚ ਇਕੱਤਰ ਕੀਤੇ ਚਿੱਤਰਾਂ ਦੇ ਸੰਸਕਰਣ ਹਾਰਡਕੋਡ ਕੀਤੇ ਗਏ ਹਨ। ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਇੱਕ ਸਧਾਰਨ ਰੀਵਰਟ ਨਾਲ ਰੋਲਬੈਕ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹੋ ਮਾਸਟਰ- ਸ਼ਾਖਾਵਾਂ।

10. ਤੈਨਾਤੀ ਦਾ ਸਵੈਚਾਲਨ

Gitlab-ਰਨਰ ਨੂੰ ਸਾਡੇ ਰਾਜ਼ ਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕਰਨ ਲਈ, ਸਾਨੂੰ ਰਿਪੋਜ਼ਟਰੀ ਕੁੰਜੀ ਨੂੰ ਨਿਰਯਾਤ ਕਰਨ ਅਤੇ ਇਸਨੂੰ ਸਾਡੇ CI ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਵਿੱਚ ਜੋੜਨ ਦੀ ਲੋੜ ਹੋਵੇਗੀ:

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

ਅਸੀਂ ਨਤੀਜੇ ਵਾਲੀ ਲਾਈਨ ਨੂੰ ਗਿਟਲੈਬ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕਰਾਂਗੇ; ਅਜਿਹਾ ਕਰਨ ਲਈ, ਆਓ ਸਾਡੀਆਂ ਪ੍ਰੋਜੈਕਟ ਸੈਟਿੰਗਾਂ 'ਤੇ ਚੱਲੀਏ:
ਸੈਟਿੰਗਾਂ -> 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__ - ਇਹ ਇੱਕ ਜਾਦੂਈ ਵੇਰੀਏਬਲ ਹੈ ਜੋ ਕਹਿੰਦਾ ਹੈ ਕਿ ਤੈਨਾਤੀ ਉਸੇ ਕਲੱਸਟਰ ਵਿੱਚ ਹੋਵੇਗੀ ਜਿਸ ਵਿੱਚ gtilab-runner ਚੱਲ ਰਿਹਾ ਹੈ। ਇਹ ਜ਼ਰੂਰੀ ਹੈ ਕਿਉਂਕਿ ਨਹੀਂ ਤਾਂ qbec ਤੁਹਾਡੀ kubeconfig ਵਿੱਚ ਇੱਕ ਢੁਕਵਾਂ Kubernetes ਸਰਵਰ ਲੱਭਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੇਗਾ।
• --ਉਡੀਕ ਕਰੋ — qbec ਨੂੰ ਇੰਤਜ਼ਾਰ ਕਰਨ ਲਈ ਮਜ਼ਬੂਰ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਇਹ ਤਿਆਰ ਕੀਤੇ ਸਰੋਤ ਤਿਆਰ ਸਥਿਤੀ ਵਿੱਚ ਨਹੀਂ ਜਾਂਦੇ ਹਨ ਅਤੇ ਕੇਵਲ ਤਦ ਹੀ ਇੱਕ ਸਫਲ ਐਗਜ਼ਿਟ-ਕੋਡ ਨਾਲ ਬਾਹਰ ਨਿਕਲਦੇ ਹਨ।
• -ਹਾਂ - ਸਿਰਫ਼ ਇੰਟਰਐਕਟਿਵ ਸ਼ੈੱਲ ਨੂੰ ਅਯੋਗ ਕਰਦਾ ਹੈ ਤੁਹਾਨੂੰ ਪੂਰਾ ਵਿਸ਼ਵਾਸ ਹੈ? ਜਦੋਂ ਤਾਇਨਾਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਸਾਡੇ ਬਦਲਾਅ ਕਰਨ ਲਈ ਨਾ ਭੁੱਲੋ:

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

ਅਤੇ ਬਾਅਦ git ਧੱਕਾ ਅਸੀਂ ਦੇਖਾਂਗੇ ਕਿ ਸਾਡੀਆਂ ਅਰਜ਼ੀਆਂ ਕਿਵੇਂ ਤਾਇਨਾਤ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ:

ਦੂਜੀ ਪਾਈਪਲਾਈਨ ਦਾ ਸਕ੍ਰੀਨਸ਼ੌਟ

11. ਕਲਾਤਮਕ ਚੀਜ਼ਾਂ ਅਤੇ ਅਸੈਂਬਲੀ ਜਦੋਂ ਮਾਸਟਰ ਵੱਲ ਧੱਕਦੇ ਹਨ

ਆਮ ਤੌਰ 'ਤੇ, ਉੱਪਰ ਦੱਸੇ ਗਏ ਕਦਮ ਲਗਭਗ ਕਿਸੇ ਵੀ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਨੂੰ ਬਣਾਉਣ ਅਤੇ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਕਾਫੀ ਹੁੰਦੇ ਹਨ, ਪਰ ਜਦੋਂ ਵੀ ਸਾਨੂੰ ਸਾਈਟ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਤਾਂ ਅਸੀਂ ਕੋਈ ਟੈਗ ਨਹੀਂ ਜੋੜਨਾ ਚਾਹੁੰਦੇ। ਇਸ ਲਈ, ਅਸੀਂ ਇੱਕ ਹੋਰ ਗਤੀਸ਼ੀਲ ਰੂਟ ਲਵਾਂਗੇ ਅਤੇ ਮਾਸਟਰ ਬ੍ਰਾਂਚ ਵਿੱਚ ਇੱਕ ਡਾਇਜੈਸਟ ਤੈਨਾਤੀ ਸਥਾਪਤ ਕਰਾਂਗੇ।

ਇਹ ਵਿਚਾਰ ਸਧਾਰਨ ਹੈ: ਹੁਣ ਸਾਡੀ ਤਸਵੀਰ ਵੈਬਸਾਈਟ ਹਰ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਅੰਦਰ ਧੱਕੋਗੇ ਤਾਂ ਦੁਬਾਰਾ ਬਣਾਇਆ ਜਾਵੇਗਾ ਮਾਸਟਰ, ਅਤੇ ਫਿਰ ਆਪਣੇ ਆਪ ਕੁਬਰਨੇਟਸ 'ਤੇ ਤੈਨਾਤ ਕਰੋ।

ਆਉ ਆਪਣੇ ਵਿੱਚ ਇਹਨਾਂ ਦੋ ਨੌਕਰੀਆਂ ਨੂੰ ਅਪਡੇਟ ਕਰੀਏ .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"

ਕਿਰਪਾ ਕਰਕੇ ਨੋਟ ਕਰੋ ਕਿ ਅਸੀਂ ਇੱਕ ਧਾਗਾ ਜੋੜਿਆ ਹੈ ਮਾਸਟਰ к ਰਿਫਜ਼ ਨੌਕਰੀਆਂ ਲਈ build_website ਅਤੇ ਅਸੀਂ ਹੁਣ ਵਰਤਦੇ ਹਾਂ $CI_COMMIT_REF_NAME ਦੀ ਬਜਾਏ $CI_COMMIT_TAG, ਯਾਨੀ, ਅਸੀਂ ਗਿੱਟ ਵਿੱਚ ਟੈਗਸ ਤੋਂ ਮੁਕਤ ਹੋ ਗਏ ਹਾਂ ਅਤੇ ਹੁਣ ਅਸੀਂ ਪਾਈਪਲਾਈਨ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨ ਵਾਲੀ ਕਮਿਟ ਬ੍ਰਾਂਚ ਦੇ ਨਾਮ ਨਾਲ ਇੱਕ ਚਿੱਤਰ ਨੂੰ ਪੁਸ਼ ਕਰਾਂਗੇ। ਇਹ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ ਕਿ ਇਹ ਟੈਗਾਂ ਦੇ ਨਾਲ ਵੀ ਕੰਮ ਕਰੇਗਾ, ਜੋ ਸਾਨੂੰ ਡੌਕਰ-ਰਜਿਸਟਰੀ ਵਿੱਚ ਇੱਕ ਖਾਸ ਸੰਸਕਰਣ ਵਾਲੀ ਸਾਈਟ ਦੇ ਸਨੈਪਸ਼ਾਟ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨ ਦੀ ਆਗਿਆ ਦੇਵੇਗਾ।

ਜਦੋਂ ਸਾਈਟ ਦੇ ਇੱਕ ਨਵੇਂ ਸੰਸਕਰਣ ਲਈ ਡੌਕਰ ਟੈਗ ਦਾ ਨਾਮ ਬਦਲਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ ਹੈ, ਤਾਂ ਸਾਨੂੰ ਅਜੇ ਵੀ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਦਾ ਵਰਣਨ ਕਰਨਾ ਪਏਗਾ, ਨਹੀਂ ਤਾਂ ਇਹ ਨਵੇਂ ਚਿੱਤਰ ਤੋਂ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਦੁਬਾਰਾ ਲਾਗੂ ਨਹੀਂ ਕਰੇਗਾ, ਕਿਉਂਕਿ ਇਹ ਕਿਸੇ ਵੀ ਤਬਦੀਲੀ ਨੂੰ ਨੋਟਿਸ ਨਹੀਂ ਕਰੇਗਾ. ਤੈਨਾਤੀ ਮੈਨੀਫੈਸਟ।

ਵਿਕਲਪ —vm:ext-str digest=”$DIGEST” qbec ਲਈ - ਤੁਹਾਨੂੰ jsonnet ਨੂੰ ਇੱਕ ਬਾਹਰੀ ਵੇਰੀਏਬਲ ਪਾਸ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਅਸੀਂ ਚਾਹੁੰਦੇ ਹਾਂ ਕਿ ਇਸ ਨੂੰ ਸਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਹਰੇਕ ਰੀਲੀਜ਼ ਦੇ ਨਾਲ ਕਲੱਸਟਰ ਵਿੱਚ ਮੁੜ ਤੈਨਾਤ ਕੀਤਾ ਜਾਵੇ। ਅਸੀਂ ਹੁਣ ਟੈਗ ਨਾਮ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹਾਂ, ਜੋ ਹੁਣ ਬਦਲਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਸਾਨੂੰ ਚਿੱਤਰ ਦੇ ਇੱਕ ਖਾਸ ਸੰਸਕਰਣ ਨਾਲ ਬੰਨ੍ਹਣ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਜਦੋਂ ਇਹ ਬਦਲਦਾ ਹੈ ਤਾਂ ਤੈਨਾਤੀ ਨੂੰ ਟਰਿੱਗਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਇੱਥੇ ਸਾਨੂੰ ਇੱਕ ਡਾਈਜੈਸਟ ਚਿੱਤਰ ਨੂੰ ਇੱਕ ਫਾਈਲ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕਰਨ ਦੀ ਕਾਨੀਕੋ ਦੀ ਯੋਗਤਾ ਦੁਆਰਾ ਮਦਦ ਕੀਤੀ ਜਾਵੇਗੀ (ਵਿਕਲਪ --digest-file)
ਫਿਰ ਅਸੀਂ ਇਸ ਫਾਈਲ ਨੂੰ ਟ੍ਰਾਂਸਫਰ ਕਰਾਂਗੇ ਅਤੇ ਤੈਨਾਤੀ ਦੇ ਸਮੇਂ ਇਸਨੂੰ ਪੜ੍ਹਾਂਗੇ।

ਆਉ ਸਾਡੇ ਲਈ ਮਾਪਦੰਡਾਂ ਨੂੰ ਅਪਡੇਟ ਕਰੀਏ deploy/website/environments/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"

ਅਸੀਂ ਬਾਅਦ ਵਿੱਚ ਜਾਂਚ ਕਰਾਂਗੇ git ਧੱਕਾ ਸਾਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਕੁਝ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ:

ਮਾਸਟਰ ਲਈ ਪਾਈਪਲਾਈਨ ਦਾ ਸਕ੍ਰੀਨਸ਼ੌਟ

ਸਿਧਾਂਤ ਵਿੱਚ, ਸਾਨੂੰ ਹਰ ਇੱਕ ਪੁਸ਼ ਦੇ ਨਾਲ ਗਿਟਲੈਬ-ਰਨਰ ਨੂੰ ਦੁਬਾਰਾ ਤੈਨਾਤ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਹੈ, ਜਦੋਂ ਤੱਕ, ਬੇਸ਼ਕ, ਇਸਦੀ ਸੰਰਚਨਾ ਵਿੱਚ ਕੁਝ ਵੀ ਨਹੀਂ ਬਦਲਿਆ ਹੈ, ਆਓ ਇਸਨੂੰ ਠੀਕ ਕਰੀਏ .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/**/*

ਤਬਦੀਲੀਆਂ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇਵੇਗਾ deploy/gitlab-runner/ ਅਤੇ ਸਾਡੀ ਨੌਕਰੀ ਨੂੰ ਉਦੋਂ ਹੀ ਚਾਲੂ ਕਰੇਗਾ ਜੇਕਰ ਕੋਈ ਹੋਵੇ

ਸਾਡੇ ਬਦਲਾਅ ਕਰਨ ਲਈ ਨਾ ਭੁੱਲੋ:

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

git ਧੱਕਾ, ਉਹ ਟੀਕ:

ਅੱਪਡੇਟ ਕੀਤੀ ਪਾਈਪਲਾਈਨ ਦਾ ਸਕਰੀਨਸ਼ਾਟ

12. ਗਤੀਸ਼ੀਲ ਵਾਤਾਵਰਣ

ਇਹ ਸਾਡੀ ਪਾਈਪਲਾਈਨ ਨੂੰ ਗਤੀਸ਼ੀਲ ਵਾਤਾਵਰਣ ਨਾਲ ਵਿਭਿੰਨ ਬਣਾਉਣ ਦਾ ਸਮਾਂ ਹੈ।

ਪਹਿਲਾਂ, ਆਓ ਨੌਕਰੀ ਨੂੰ ਅਪਡੇਟ ਕਰੀਏ build_website ਸਾਡੇ ਵਿੱਚ .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 ਲਈ ਇੱਕ ਨਵਾਂ ਵਿਕਲਪ ਦੇਖਦੇ ਹਾਂ: --ਐਪ-ਟੈਗ — ਇਹ ਤੁਹਾਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਤੈਨਾਤ ਸੰਸਕਰਣਾਂ ਨੂੰ ਟੈਗ ਕਰਨ ਅਤੇ ਸਿਰਫ਼ ਇਸ ਟੈਗ ਦੇ ਅੰਦਰ ਕੰਮ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ; ਜਦੋਂ Kubernetes ਵਿੱਚ ਸਰੋਤ ਬਣਾਉਣ ਅਤੇ ਨਸ਼ਟ ਕਰਨ ਵੇਲੇ, qbec ਸਿਰਫ਼ ਉਹਨਾਂ ਨਾਲ ਕੰਮ ਕਰੇਗਾ।
ਇਸ ਤਰੀਕੇ ਨਾਲ ਅਸੀਂ ਹਰੇਕ ਸਮੀਖਿਆ ਲਈ ਇੱਕ ਵੱਖਰਾ ਵਾਤਾਵਰਣ ਨਹੀਂ ਬਣਾ ਸਕਦੇ ਹਾਂ, ਪਰ ਸਿਰਫ਼ ਉਸੇ ਨੂੰ ਦੁਬਾਰਾ ਵਰਤ ਸਕਦੇ ਹਾਂ।

ਇੱਥੇ ਅਸੀਂ ਵੀ ਵਰਤਦੇ ਹਾਂ qbec ਸਮੀਖਿਆ ਲਾਗੂ ਕਰੋ, ਦੇ ਬਜਾਏ qbec ਡਿਫਾਲਟ ਲਾਗੂ ਕਰੋ - ਇਹ ਬਿਲਕੁਲ ਉਹ ਪਲ ਹੈ ਜਦੋਂ ਅਸੀਂ ਆਪਣੇ ਵਾਤਾਵਰਨ (ਸਮੀਖਿਆ ਅਤੇ ਮੂਲ) ਲਈ ਅੰਤਰਾਂ ਦਾ ਵਰਣਨ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਾਂਗੇ:

ਜੋੜੋ ਸਮੀਖਿਆ ਵਿੱਚ ਵਾਤਾਵਰਣ deploy/website/qbec.yaml

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

ਫਿਰ ਅਸੀਂ ਇਸ ਵਿੱਚ ਘੋਸ਼ਣਾ ਕਰਾਂਗੇ deploy/website/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

ਅਤੇ ਇਸਦੇ ਲਈ ਕਸਟਮ ਪੈਰਾਮੀਟਰ ਲਿਖੋ deploy/website/environments/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',
    },
  },
}

ਆਓ ਜੌਬੂ 'ਤੇ ਵੀ ਡੂੰਘਾਈ ਨਾਲ ਵਿਚਾਰ ਕਰੀਏ stop_review, ਇਹ ਉਦੋਂ ਚਾਲੂ ਹੋ ਜਾਵੇਗਾ ਜਦੋਂ ਸ਼ਾਖਾ ਨੂੰ ਮਿਟਾਇਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇਸ ਲਈ ਗਿਟਲੈਬ ਚੈੱਕਆਉਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰੇ ਇਸਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ GIT_STRATEGY: ਕੋਈ ਨਹੀਂ, ਬਾਅਦ ਵਿੱਚ ਅਸੀਂ ਕਲੋਨ ਕਰਦੇ ਹਾਂ ਮਾਸਟਰ- ਬ੍ਰਾਂਚ ਅਤੇ ਇਸਦੇ ਦੁਆਰਾ ਸਮੀਖਿਆ ਨੂੰ ਮਿਟਾਓ.
ਇਹ ਥੋੜਾ ਉਲਝਣ ਵਾਲਾ ਹੈ, ਪਰ ਮੈਨੂੰ ਅਜੇ ਤੱਕ ਕੋਈ ਹੋਰ ਸੁੰਦਰ ਤਰੀਕਾ ਨਹੀਂ ਮਿਲਿਆ ਹੈ।
ਇੱਕ ਵਿਕਲਪਕ ਵਿਕਲਪ ਹਰੇਕ ਸਮੀਖਿਆ ਨੂੰ ਇੱਕ ਹੋਟਲ ਨੇਮਸਪੇਸ ਵਿੱਚ ਤੈਨਾਤ ਕਰਨਾ ਹੋਵੇਗਾ, ਜਿਸਨੂੰ ਹਮੇਸ਼ਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਢਾਹਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਸਾਡੇ ਬਦਲਾਅ ਕਰਨ ਲਈ ਨਾ ਭੁੱਲੋ:

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

git ਧੱਕਾ, git checkout -b ਟੈਸਟ, git ਪੁਸ਼ ਮੂਲ ਟੈਸਟ, ਚੈਕ:

ਗਿਟਲੈਬ ਵਿੱਚ ਬਣਾਏ ਵਾਤਾਵਰਨ ਦਾ ਸਕ੍ਰੀਨਸ਼ੌਟ

ਸਭ ਕੁਝ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ? - ਬਹੁਤ ਵਧੀਆ, ਸਾਡੀ ਟੈਸਟ ਸ਼ਾਖਾ ਨੂੰ ਮਿਟਾਓ: git ਚੈਕਆਉਟ ਮਾਸਟਰ, 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"

git ਧੱਕਾ, ਅਤੇ ਜਾਂਚ ਕਰੋ:

ਸਮੀਖਿਆ ਐਪ ਬਟਨ ਦਾ ਸਕ੍ਰੀਨਸ਼ੌਟ

ਕੰਮ ਹੋ ਗਿਆ ਹੈ!

ਪ੍ਰੋਜੈਕਟ ਸਰੋਤ:

• Gitlab 'ਤੇ: https://gitlab.com/kvaps/docs.example.org
• GitHub 'ਤੇ: https://github.com/kvaps/docs.example.org

ਤੁਹਾਡੇ ਧਿਆਨ ਲਈ ਧੰਨਵਾਦ, ਮੈਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਇਹ ਪਸੰਦ ਆਇਆ ਹੋਵੇਗਾ

ਸਰੋਤ: www.habr.com