ProHoster > බ්ලොග් > පරිපාලනය > Kubernetes හි යෙදවීම ගොඩනැගීම සහ ස්වයංක්‍රීය කිරීම සඳහා නව මෙවලම් උත්සාහ කරමින්

Kubernetes හි යෙදවීම ගොඩනැගීම සහ ස්වයංක්‍රීය කිරීම සඳහා නව මෙවලම් උත්සාහ කරමින්

Kubernetes හි යෙදවීම ගොඩනැගීම සහ ස්වයංක්‍රීය කිරීම සඳහා නව මෙවලම් උත්සාහ කරමින්

ආයුබෝවන්! මෑතකදී, ඩොකර් රූප තැනීම සඳහා සහ කුබර්නෙට්ස් වෙත යෙදවීම සඳහා බොහෝ සිසිල් ස්වයංක්‍රීය මෙවලම් නිකුත් කර ඇත. මේ සම්බන්ධයෙන්, මම GitLab සමඟ සෙල්ලම් කිරීමට තීරණය කළෙමි, එහි හැකියාවන් හොඳින් අධ්‍යයනය කර, ඇත්ත වශයෙන්ම, නල මාර්ගය සකස් කළෙමි.

මෙම කාර්යය වෙබ් අඩවියෙන් ආභාෂය ලැබීය kubernetes.io, වලින් ජනනය වන මූලාශ්ර කේත ස්වයංක්‍රීයව, සහ යවන සෑම සංචිත ඉල්ලීමක් සඳහාම, රොබෝවරයා ඔබගේ වෙනස්කම් සමඟින් වෙබ් අඩවියේ පෙරදසුන් අනුවාදයක් ස්වයංක්‍රීයව ජනනය කර බැලීම සඳහා සබැඳියක් සපයයි.

මම මුල සිටම සමාන ක්‍රියාවලියක් ගොඩනඟා ගැනීමට උත්සාහ කළ නමුත් සම්පූර්ණයෙන්ම ගොඩනගා ඇත්තේ Gitlab CI සහ Kubernetes වෙත යෙදුම් යෙදවීමට මා භාවිතා කරන නිදහස් මෙවලම් මතය. අද මම අවසානයේ ඔබට ඔවුන් ගැන වැඩි විස්තර කියන්නම්.

ලිපිය වැනි මෙවලම් සාකච්ඡා කරනු ඇත:
හූගෝ, qbec, කනිකෝ, git-crypt и ගිට්ලැබ් සීඅයි ගතික පරිසරයන් නිර්මාණය කිරීමත් සමඟ.

අන්තර්ගතය

  1. හියුගෝ හමුවන්න
  2. ඩොකර් ගොනුව සකස් කිරීම
  3. කනිකෝව දැන හඳුනා ගැනීම
  4. qbec දැන හඳුනා ගැනීම
  5. Kubernetes-executor සමඟ Gitlab-ධාවනය කිරීමට උත්සාහ කිරීම
  6. qbec සමඟ හෙල්ම් ප්‍රස්ථාර යෙදවීම
  7. git-crypt හඳුන්වා දීම
  8. මෙවලම් පෙට්ටියේ රූපයක් නිර්මාණය කිරීම
  9. අපගේ පළමු නල මාර්ගය සහ ටැග් මගින් පින්තූර එකලස් කිරීම
  10. යෙදවීමේ ස්වයංක්‍රීයකරණය
  11. මාස්ටර් වෙත තල්ලු කරන විට කෞතුක භාණ්ඩ සහ එකලස් කිරීම
  12. ගතික පරිසරයන්
  13. යෙදුම් සමාලෝචනය කරන්න

1. හියුගෝව දැන හඳුනා ගැනීම

අපගේ ව්යාපෘතියේ උදාහරණයක් ලෙස, අපි හියුගෝ මත ගොඩනගා ඇති ලේඛන ප්රකාශන අඩවියක් නිර්මාණය කිරීමට උත්සාහ කරමු. හියුගෝ යනු ස්ථිතික අන්තර්ගත උත්පාදකයකි.

ස්ථිතික උත්පාදක යන්ත්ර ගැන නොදන්නා අය සඳහා, මම ඔවුන් ගැන තව ටිකක් කියන්නම්. දත්ත සමුදායක් සහ සමහර PHP සහිත සාම්ප්‍රදායික වෙබ් අඩවි එන්ජින් මෙන් නොව, පරිශීලකයෙකු විසින් ඉල්ලා සිටින විට, පියාසර කිරීමේදී පිටු ජනනය කරයි, ස්ථිතික ජනක යන්ත්‍ර ටිකක් වෙනස් ලෙස නිර්මාණය කර ඇත. ඔවුන් ඔබට මූලාශ්‍ර ලබා ගැනීමට ඉඩ සලසයි, සාමාන්‍යයෙන් Markdown markup සහ තේමා සැකිලි තුළ ඇති ගොනු කට්ටලයක්, පසුව ඒවා සම්පූර්ණයෙන්ම නිමි වෙබ් අඩවියකට සම්පාදනය කරයි.

එනම්, ප්රතිඵලයක් වශයෙන්, ඔබට ඩිරෙක්ටරි ව්යුහයක් සහ ජනනය කරන ලද 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/ අපගේ අලුතින් සාදන ලද වෙබ් අඩවිය පරීක්ෂා කරන්න, නාමාවලියෙහි සිදු කරන ලද සියලුම වෙනස්කම් ස්වයංක්‍රීයව බ්‍රව්සරයේ විවෘත පිටුව යාවත්කාලීන කරන්න, ඉතා පහසුයි!

අපි ආවරණ පිටුවක් නිර්මාණය කිරීමට උත්සාහ කරමු අන්තර්ගතය/_index.md:

# My docs site

## Welcome to the docs!

You will be very smart :-)

අලුතින් සාදන ලද පිටුවේ තිර රුව

Kubernetes හි යෙදවීම ගොඩනැගීම සහ ස්වයංක්‍රීය කිරීම සඳහා නව මෙවලම් උත්සාහ කරමින්

අඩවියක් උත්පාදනය කිරීමට, ක්‍රියාත්මක කරන්න:

hugo

නාමාවලි අන්තර්ගතය පොදු/ සහ ඔබේ වෙබ් අඩවිය වනු ඇත.
ඔව්, මාර්ගය වන විට, අපි එය වහාම එකතු කරමු .ගිටිගෝර්:

echo /public > .gitignore

අපගේ වෙනස්කම් සිදු කිරීමට අමතක නොකරන්න:

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

2. Dockerfile සකස් කිරීම

අපගේ ගබඩාවේ ව්‍යුහය නිර්වචනය කිරීමට කාලයයි. මම සාමාන්‍යයෙන් මෙවැනි දෙයක් භාවිතා කරනවා:

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

  • ඩොකර් ගොනු/ - Dockerfiles සහිත නාමාවලි සහ අපගේ Docker පින්තූර ගොඩනැගීමට අවශ්‍ය සියල්ල අඩංගු වේ.
  • යෙදවීම/ — අපගේ යෙදුම් Kubernetes වෙත යෙදවීම සඳහා නාමාවලි අඩංගු වේ

මේ අනුව, අපි අපගේ පළමු Dockerfile මාර්ගය ඔස්සේ නිර්මාණය කරමු 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" ]

ඔබට පෙනෙන පරිදි, Dockerfile දෙකක් අඩංගු වේ සිට, මෙම අවස්ථාව හැඳින්වේ බහු අදියර ගොඩනැගීම සහ අවසාන ඩොකර් රූපයෙන් අනවශ්‍ය සියල්ල ඉවත් කිරීමට ඔබට ඉඩ සලසයි.
මේ අනුව, අවසාන රූපය පමණක් අඩංගු වනු ඇත අඳුරුhttpd (සැහැල්ලු HTTP සේවාදායකය) සහ පොදු/ - අපගේ ස්ථිතිකව ජනනය කරන ලද වෙබ් අඩවියේ අන්තර්ගතය.

අපගේ වෙනස්කම් සිදු කිරීමට අමතක නොකරන්න:

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

3. කනිකෝව දැන හඳුනා ගැනීම

ඩොකර් රූප සාදන්නෙකු ලෙස, මම භාවිතා කිරීමට තීරණය කළෙමි කනිකෝ, එහි ක්‍රියාකාරිත්වය සඳහා ඩොකර් ඩීමන් අවශ්‍ය නොවන අතර, ගොඩ නැගීම ඕනෑම යන්ත්‍රයක සිදු කළ හැකි අතර හැඹිලිය සෘජුවම රෙජිස්ට්‍රියේ ගබඩා කළ හැකි බැවින්, එමඟින් පූර්ණ ස්ථීර ගබඩාවක් තිබීමේ අවශ්‍යතාවය ඉවත් කරයි.

රූපය ගොඩනැගීමට, කන්ටේනරය ධාවනය කරන්න kaniko executor සහ එය වත්මන් ගොඩනැගීමේ සන්දර්භය ලබා දෙන්න; මෙය ඩොකර් හරහා දේශීයව ද කළ හැකිය:

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.

docker-registry හි තිර රුවක්

Kubernetes හි යෙදවීම ගොඩනැගීම සහ ස්වයංක්‍රීය කිරීම සඳහා නව මෙවලම් උත්සාහ කරමින්

4. qbec දැන හඳුනා ගැනීම

Qbec ඔබගේ යෙදුම් ප්‍රකාශන ප්‍රකාශනාත්මකව විස්තර කිරීමට සහ ඒවා Kubernetes වෙත යෙදවීමට ඔබට ඉඩ සලසන යෙදවුම් මෙවලමකි. Jsonnet ප්‍රධාන වාක්‍ය ඛණ්ඩය ලෙස භාවිතා කිරීමෙන් ඔබට විවිධ පරිසරයන් හරහා ඇති වෙනස්කම් පිළිබඳ විස්තරය බෙහෙවින් සරල කිරීමට ඉඩ සලසයි, තවද කේත පුනරාවර්තනය සම්පූර්ණයෙන්ම පාහේ ඉවත් කරයි.

ඔබට විවිධ පරාමිති සහිත පොකුරු කිහිපයකට යෙදුමක් යෙදවීමට අවශ්‍ය වන සහ ඒවා Git හි ප්‍රකාශනාත්මකව විස්තර කිරීමට අවශ්‍ය අවස්ථාවන්හිදී මෙය විශේෂයෙන්ම සත්‍ය විය හැක.

අවශ්‍ය පරාමිති ලබා දීමෙන් හෙල්ම් ප්‍රස්ථාර ලබා දීමට Qbec ඔබට ඉඩ සලසයි, ඉන්පසු ඔබට ඒවාට විවිධ විකෘති යෙදිය හැකිය ඇතුළුව සාමාන්‍ය ප්‍රකාශන මෙන් ඒවා ක්‍රියාත්මක කරන්න, සහ මෙය ඔබට අවශ්‍යතාවයෙන් මිදීමට ඉඩ සලසයි. ChartMuseum භාවිතා කරන්න. එනම්, ඔබට ප්‍රස්ථාර ඒවා අයත් වන 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.පරිසර, qbec දැනටමත් අප සඳහා පෙරනිමි පරිසරයක් නිර්මාණය කර ඇති අතර අපගේ වත්මන් kubeconfig වෙතින් සේවාදායක ලිපිනය මෙන්ම නාම අවකාශයද ලබාගෙන ඇත.
දැන් යෙදවීමේදී පැහැර හැරීමකි පරිසරය, qbec සෑම විටම යොදවනු ලබන්නේ නිශ්චිත Kubernetes පොකුරට සහ නිශ්චිත නාම අවකාශයට පමණි, එනම්, යෙදවීමක් සිදු කිරීම සඳහා ඔබට තවදුරටත් සන්දර්භ සහ නාම අවකාශයන් අතර මාරු වීමට අවශ්‍ය නොවේ.
අවශ්‍ය නම්, ඔබට සැම විටම මෙම ගොනුවේ සිටුවම් යාවත්කාලීන කළ හැක.

ඔබගේ සියලු පරිසරයන් විස්තර කර ඇත 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,
                },
              },
            ],
          },
        },
      ],
    },
  },
]

මෙම ගොනුවේ අපි එකවර Kubernetes ආයතන තුනක් විස්තර කළෙමු, මේවා: යෙදවීම, සේවය и ආක්රමණය. අපට අවශ්‍ය නම්, අපට ඒවා විවිධ සංරචක වලට දැමිය හැකිය, නමුත් මෙම අදියරේදී එකක් අපට ප්‍රමාණවත් වනු ඇත.

කාරක රීති jsonnet සාමාන්‍ය json ට බෙහෙවින් සමාන ය, ප්‍රතිපත්තිමය වශයෙන්, සාමාන්‍ය json දැනටමත් වලංගු jsonnet වේ, එබැවින් මුලදී ඔබට වැනි සබැඳි සේවා භාවිතා කිරීම පහසු විය හැකිය yaml2json ඔබේ සුපුරුදු yaml json බවට පරිවර්තනය කිරීමට, හෝ, ඔබේ සංරචකවල කිසිදු විචල්‍යයක් නොමැති නම්, ඒවා සාමාන්‍ය yaml ආකාරයෙන් විස්තර කළ හැක.

සමඟ වැඩ කරන විට jsonnet ඔබගේ සංස්කාරකය සඳහා ප්ලගිනයක් ස්ථාපනය කිරීම මම තරයේ නිර්දේශ කරමි

උදාහරණයක් ලෙස, vim සඳහා ප්ලගිනයක් ඇත vim-jsonnet, එය සින්ටැක්ස් උද්දීපනය සක්‍රීය කර ස්වයංක්‍රීයව ක්‍රියාත්මක වේ 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. Kubernetes-executor සමඟ Gitlab-runner උත්සාහ කිරීම

මෑතක් වන තුරු මම භාවිතා කළේ නිතිපතා පමණි gitlab-runner shell හෝ docker-executor සහිත පෙර සූදානම් කළ යන්ත්‍රයක් (LXC බහාලුම්) මත. මුලදී, අපගේ gitlab හි ගෝලීය වශයෙන් නිර්වචනය කර ඇති එවැනි ධාවකයන් කිහිප දෙනෙක් සිටියහ. ඔවුන් සියලු ව්‍යාපෘති සඳහා ඩොකර් පින්තූර එකතු කළහ.

නමුත් ප්රායෝගිකව පෙන්වා දී ඇති පරිදි, මෙම විකල්පය ප්රායෝගිකත්වය සහ ආරක්ෂාව යන දෙකම වඩාත්ම පරමාදර්ශී නොවේ. එක් එක් ව්‍යාපෘතිය සඳහා හෝ එක් එක් පරිසරය සඳහා වෙන වෙනම ධාවකයන් යෙදවීම වඩා හොඳ සහ මතවාදීව වඩා නිවැරදි ය.

වාසනාවකට මෙන්, මෙය කිසිසේත්ම ගැටළුවක් නොවේ, දැන් අපි යොදවන්නෙමු gitlab-runner කෙලින්ම Kubernetes හි අපගේ ව්‍යාපෘතියේ කොටසක් ලෙස.

Gitlab, Kubernetes වෙත gitlab-runner යෙදවීම සඳහා සූදානම් කළ හෙල්ම් ප්‍රස්ථාරයක් සපයයි. එබැවින් ඔබ කළ යුත්තේ එය සොයා ගැනීමයි ලියාපදිංචි සංකේතය අපගේ ව්‍යාපෘතිය සඳහා සැකසීම් -> 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=ඇත්ත — kubernetes-executor භාවිතයෙන් අපගේ කාර්යයන් ඉටු කිරීම සඳහා කරල් නිර්මාණය කිරීමට හැකි වන පරිදි ධාවකයාට අවශ්‍ය වරප්‍රසාද ප්‍රමාණය සපයයි.

සෑම දෙයක්ම නිවැරදිව සිදු කර ඇත්නම්, ඔබ කොටසෙහි ලියාපදිංචි ධාවකයෙකු දැකිය යුතුය ධාවකයන්, ඔබේ ව්‍යාපෘති සැකසීම් තුළ.

එකතු කරන ලද ධාවකයේ තිර රුව

Kubernetes හි යෙදවීම ගොඩනැගීම සහ ස්වයංක්‍රීය කිරීම සඳහා නව මෙවලම් උත්සාහ කරමින්

එය එතරම් සරලද? - ඔව්, එය ඉතා සරලයි! ධාවකයන් අතින් ලියාපදිංචි වීමෙන් තවත් කරදරයක් නැත, මෙතැන් සිට ධාවකයන් ස්වයංක්‍රීයව නිර්මාණය වී විනාශ වනු ඇත.

6. QBEC සමඟ හෙල්ම් ප්‍රස්ථාර යොදන්න

අපි සලකා බැලීමට තීරණය කළ නිසා gitlab-runner අපගේ ව්‍යාපෘතියේ කොටසක්, එය අපගේ Git ගබඩාවේ විස්තර කිරීමට කාලයයි.

අපට එය වෙනම සංරචකයක් ලෙස විස්තර කළ හැකිය වෙබ් අඩවිය, නමුත් අනාගතයේදී අපි විවිධ පිටපත් යෙදවීමට සැලසුම් කරමු වෙබ් අඩවිය බොහෝ විට, මෙන් නොව gitlab-runner, එය Kubernetes පොකුරකට එක් වරක් පමණක් යොදවනු ලැබේ. එබැවින් අපි ඒ සඳහා වෙනම යෙදුමක් ආරම්භ කරමු:

cd deploy
qbec init gitlab-runner
cd gitlab-runner

මෙවර අපි Kubernetes ආයතන හස්තීයව විස්තර නොකර, සූදානම් කළ Helm සටහනක් ගනිමු. qbec හි ඇති එක් වාසියක් වන්නේ Git ගබඩාවකින් කෙලින්ම Helm ප්‍රස්ථාර ලබා දීමේ හැකියාවයි.

අපි එය git උපමොඩියුලය භාවිතයෙන් සම්බන්ධ කරමු:

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

දැන් නාමාවලිය වෙළෙන්දා / gitlab-runner අපට 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,
  }
)

පළමු තර්කය 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,
      },
    },
  },
}

අවධානය යොමු කරන්න ධාවකයා ලියාපදිංචි ටෝකන් අපි බාහිර ගොනුවකින් ගන්නෙමු රහස්/base.libsonnet, අපි එය නිර්මාණය කරමු:

{
  runnerRegistrationToken: 'yga8y-jdCusVDn_t4Wxc',
}

සෑම දෙයක්ම ක්‍රියාත්මක වේදැයි පරීක්ෂා කරමු:

qbec show default

සෑම දෙයක්ම පිළිවෙලට තිබේ නම්, අපට හෙල්ම් හරහා අපගේ පෙර යෙදවූ නිකුතුව මකා දැමිය හැක:

helm uninstall gitlab-runner

සහ එය එකම ආකාරයකින් යොදවන්න, නමුත් qbec හරහා:

qbec apply default

7. git-crypt හැඳින්වීම

Git-crypt ඔබේ ගබඩාව සඳහා විනිවිද පෙනෙන සංකේතනය සැකසීමට ඔබට ඉඩ සලසන මෙවලමකි.

මේ මොහොතේ, 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-crypt.

git-crypt Git සම්බන්ධයෙන් අප පුරුදු වී සිටින ආකාරයටම රහස්වල සමස්ත ඉතිහාසයම සුරැකීමට මෙන්ම ගැටුම් සංසන්දනය කිරීමට, ඒකාබද්ධ කිරීමට සහ විසඳීමට එය ඔබට ඉඩ සලසයි.

ස්ථාපනය කිරීමෙන් පසු පළමු දෙය git-crypt අපගේ ගබඩාව සඳහා යතුරු ජනනය කිරීමට අපට අවශ්‍ය වේ:

git crypt init

ඔබට PGP යතුරක් තිබේ නම්, ඔබට වහාම මෙම ව්‍යාපෘතිය සඳහා සහකාරකයෙකු ලෙස ඔබම එක් කළ හැක:

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

මේ ආකාරයෙන් ඔබට සැමවිටම ඔබගේ පුද්ගලික යතුර භාවිතයෙන් මෙම ගබඩාව විකේතනය කළ හැක.

ඔබට PGP යතුරක් නොමැති නම් සහ එය බලාපොරොත්තු නොවන්නේ නම්, ඔබට වෙනත් මාර්ගයකට ගොස් ව්‍යාපෘති යතුර අපනයනය කළ හැකිය:

git crypt export-key /path/to/keyfile

මේ අනුව, අපනයනය කර ඇති ඕනෑම කෙනෙකුට යතුරු ගොනුව ඔබගේ ගබඩාව විකේතනය කිරීමට හැකි වනු ඇත.

අපගේ පළමු රහස සැකසීමට කාලයයි.
අපි තවමත් නාමාවලියේ සිටින බව මම ඔබට මතක් කරමි deploy/gitlab-runner/, අපට නාමාවලියක් ඇති තැන රහස්/, අපි එහි ඇති සියලුම ගොනු සංකේතනය කරමු, මේ සඳහා අපි ගොනුවක් සාදන්නෙමු රහස්/.gitattributes පහත අන්තර්ගතය සමඟ:

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

අන්තර්ගතයෙන් දැකිය හැකි පරිදි, සියලුම ගොනු ආවරණය කර ඇත * හරහා ධාවනය කරනු ලැබේ git-crypt, වඩාත්ම හැර .gitatributes

ධාවනය කිරීමෙන් අපට මෙය පරීක්ෂා කළ හැකිය:

git crypt status -e

ප්‍රතිදානය යනු සංකේතනය සක්‍රීය කර ඇති ගබඩාවේ ඇති සියලුම ගොනු ලැයිස්තුවකි

එපමණයි, දැන් අපට අපගේ වෙනස්කම් ආරක්ෂිතව කළ හැකිය:

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

ගබඩාවක් අවහිර කිරීමට, ක්‍රියාත්මක කරන්න:

git crypt lock

සහ වහාම සියලු සංකේතාත්මක ගොනු ද්විමය දෙයක් බවට පත් වනු ඇත, එය කියවීමට නොහැකි වනු ඇත.
ගබඩාව විකේතනය කිරීමට, ධාවනය කරන්න:

git crypt unlock

8. මෙවලම් පෙට්ටියේ රූපයක් සාදන්න

මෙවලම් පෙට්ටි රූපයක් යනු අපගේ ව්‍යාපෘතිය යෙදවීමට අප භාවිතා කරන සියලුම මෙවලම් සහිත රූපයකි. එය සාමාන්‍ය යෙදවීමේ කාර්යයන් කිරීමට Gitlab ධාවකය විසින් භාවිතා කරනු ඇත.

මෙහි සෑම දෙයක්ම සරලයි, අපි අලුත් එකක් නිර්මාණය කරමු dockerfiles/toolbox/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, නමුත් නල මාර්ග සැකසීමේ අදියරේදී ඔබට එය සමඟ සෙල්ලම් කිරීමට අවශ්‍ය විය හැකිය.

එසේම, Kubernetes සමඟ සන්නිවේදනය කිරීමට සහ එයට යෙදවීමට හැකි වීම සඳහා, අපි gitlab-runner විසින් ජනනය කරන ලද කරල් සඳහා භූමිකාවක් වින්‍යාසගත කළ යුතුය.

මෙය සිදු කිරීම සඳහා, අපි gitlab-runner සමඟ නාමාවලිය වෙත යමු:

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 push --tags, සහ අපගේ පළමු නල මාර්ගය දෙස බලමු:

පළමු නල මාර්ගයේ තිර රුව

Kubernetes හි යෙදවීම ගොඩනැගීම සහ ස්වයංක්‍රීය කිරීම සඳහා නව මෙවලම් උත්සාහ කරමින්

ටැග් මගින් එකලස් කිරීම ඩොකර් රූප තැනීම සඳහා සුදුසු නමුත් Kubernetes වෙත යෙදුමක් යෙදවීමට සුදුසු නොවන බව ඔබේ අවධානයට යොමු කිරීම වටී. පැරණි කැපවීම් සඳහා නව ටැග් පැවරිය හැකි බැවින්, මෙම අවස්ථාවෙහිදී, ඒවා සඳහා නල මාර්ගය ආරම්භ කිරීම පැරණි අනුවාදයේ යෙදවීමට හේතු වේ.

මෙම ගැටළුව විසඳීම සඳහා, සාමාන්‍යයෙන් ඩොකර් රූප ගොඩනැගීම ටැග් වලට බැඳී ඇති අතර යෙදුම ශාඛාවකට යෙදවීම ස්වාමියා, එකතු කරන ලද පින්තූරවල අනුවාද දෘඪ කේත කර ඇත. ඔබට සරල ප්‍රතිවර්තනයක් සමඟ ආපසු හැරීම ආරම්භ කළ හැකි ස්ථානය මෙයයි ස්වාමියා-ශාඛා.

10. යෙදවීම ස්වයංක්‍රීයකරණය

Gitlab-runner හට අපගේ රහස් විකේතනය කිරීම සඳහා, අපට ගබඩා යතුර අපනයනය කර එය අපගේ 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

එකතු කරන ලද විචල්‍යයේ තිර රුව

Kubernetes හි යෙදවීම ගොඩනැගීම සහ ස්වයංක්‍රීය කිරීම සඳහා නව මෙවලම් උත්සාහ කරමින්

දැන් අපි අපේ යාවත්කාලීන කරමු .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 සඳහා නව විකල්ප කිහිපයක් සක්‍රීය කර ඇත:

  • --root some/app - විශේෂිත යෙදුමක නාමාවලිය තීරණය කිරීමට ඔබට ඉඩ සලසයි
  • --force:k8s-context __incluster__ - මෙය මැජික් විචල්‍යයක් වන අතර එය gtilab-runner ක්‍රියාත්මක වන එම පොකුරේම යෙදවීම සිදුවනු ඇත. මෙය අවශ්‍ය වන්නේ එසේ නොමැතිනම් qbec ඔබගේ kubeconfig හි සුදුසු Kubernetes සේවාදායකයක් සොයා ගැනීමට උත්සාහ කරන බැවිනි.
  • --ඉන්න — qbec හට එය නිර්මාණය කරන සම්පත් සූදානම් තත්ත්වයට යන තෙක් බලා සිටීමට බල කරන අතර පසුව පමණක් සාර්ථක පිටවීමේ කේතයකින් පිටවන්න.
  • -ඔව් - සරලව අන්තර්ක්‍රියාකාරී කවචය අක්‍රීය කරයි ඔබට විශ්වාසද? යොදවන විට.

අපගේ වෙනස්කම් සිදු කිරීමට අමතක නොකරන්න:

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

සහ පසුව git push අපගේ යෙදුම් යොදවා ඇති ආකාරය අපි බලමු:

දෙවන නල මාර්ගයේ තිර රුව

Kubernetes හි යෙදවීම ගොඩනැගීම සහ ස්වයංක්‍රීය කිරීම සඳහා නව මෙවලම් උත්සාහ කරමින්

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"

අපි ත්‍රෙඩ් එකක් එකතු කර ඇති බව කරුණාවෙන් සලකන්න ස්වාමියා к refs රැකියා සඳහා ගොඩනැගීම_වෙබ් අඩවිය සහ අපි දැන් භාවිතා කරමු $CI_COMMIT_REF_NAME වෙනුවට $CI_COMMIT_TAG, එනම්, අපි Git හි ටැග් වලින් ගලවා ඇති අතර දැන් අපි නල මාර්ගය ආරම්භ කළ කැපවූ ශාඛාවේ නම සහිත රූපයක් තල්ලු කරමු. මෙය ටැග් සමඟ ද ක්‍රියා කරන බව සඳහන් කිරීම වටී, එමඟින් ඩොකර්-රෙජිස්ට්‍රියේ නිශ්චිත අනුවාදයක් සහිත වෙබ් අඩවියක ස්නැප්ෂොට් සුරැකීමට අපට ඉඩ සලසයි.

වෙබ් අඩවියේ නව අනුවාදයක් සඳහා වන ඩොකර් ටැගයේ නම නොවෙනස් විය හැකි විට, අපට තවමත් Kubernetes හි වෙනස්කම් විස්තර කිරීමට සිදු වේ, එසේ නොමැතිනම් එය නව රූපයෙන් යෙදුම නැවත නොයෙදේ, මන්ද එය එහි කිසිදු වෙනසක් නොදකිනු ඇත. යෙදවීමේ ප්‍රකාශනය.

විකල්පය —vm:ext-str digest=”$DIGEST” qbec සඳහා - jsonnet වෙත බාහිර විචල්‍යයක් යැවීමට ඔබට ඉඩ සලසයි. අපගේ යෙදුමේ සෑම නිකුතුවක් සමඟම එය පොකුරේ නැවත යෙදවීමට අපට අවශ්‍යය. රූපයේ නිශ්චිත අනුවාදයකට සම්බන්ධ වී එය වෙනස් වූ විට යෙදවීම අවුලුවාලීමට අවශ්‍ය බැවින්, දැන් වෙනස් කළ නොහැකි ටැග් නාමය අපට තවදුරටත් භාවිත කළ නොහැක.

මෙහිදී අපට කනිකෝට ඩයිජස්ට් රූපයක් ගොනුවකට සුරැකීමේ හැකියාව උපකාර වනු ඇත (විකල්ප --digest-ගොනුව)
එවිට අපි මෙම ගොනුව මාරු කර එය යෙදවීමේදී කියවමු.

අපි අපේ සඳහා පරාමිතීන් යාවත්කාලීන කරමු යෙදවීම/වෙබ් අඩවිය/පරිසර/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',
    },
  },
}

ඉවරයි, දැන් ඕනෑම කැපවීමක් කරන්න ස්වාමියා සඳහා ඩොකර් රූපය ගොඩනැගීම ආරම්භ කරයි වෙබ් අඩවිය, පසුව එය Kubernetes වෙත යොදවන්න.

අපගේ වෙනස්කම් සිදු කිරීමට අමතක නොකරන්න:

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

අපි පසුව පරීක්ෂා කරන්නෙමු git push අපි මේ වගේ දෙයක් දැකිය යුතුයි:

මාස්ටර් සඳහා නල මාර්ගයේ තිර රුව

Kubernetes හි යෙදවීම ගොඩනැගීම සහ ස්වයංක්‍රීය කිරීම සඳහා නව මෙවලම් උත්සාහ කරමින්

ප්‍රතිපත්තිමය වශයෙන්, අපට සෑම තල්ලුවක් සමඟම gitlab-runner නැවත යෙදවීමට අවශ්‍ය නැත, ඇත්ත වශයෙන්ම, එහි වින්‍යාසය තුළ කිසිවක් වෙනස් වී නොමැති නම්, අපි එය නිවැරදි කරමු .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 push, එය වඩා හොඳයි:

යාවත්කාලීන නල මාර්ගයේ තිර රුව

Kubernetes හි යෙදවීම ගොඩනැගීම සහ ස්වයංක්‍රීය කිරීම සඳහා නව මෙවලම් උත්සාහ කරමින්

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:
  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 සඳහා නව විකල්පයක් දකිමු: --app-tag — එය ඔබට යෙදුමේ යොදවා ඇති අනුවාද ටැග් කිරීමට සහ මෙම ටැගය තුළ පමණක් වැඩ කිරීමට ඉඩ සලසයි; Kubernetes හි සම්පත් නිර්මාණය කිරීමේදී සහ විනාශ කිරීමේදී, qbec ඒවා සමඟ පමණක් ක්‍රියා කරයි.
මේ ආකාරයෙන් අපට එක් එක් සමාලෝචනය සඳහා වෙනම පරිසරයක් නිර්මාණය කළ නොහැක, නමුත් එකම එක නැවත භාවිතා කරන්න.

මෙන්න අපිත් පාවිච්චි කරනවා qbec සමාලෝචන අයදුම් කරන්න, වෙනුවට qbec පෙරනිමියෙන් යොදන්න - අපගේ පරිසරය සඳහා වෙනස්කම් විස්තර කිරීමට අප උත්සාහ කරන මොහොත මෙයයි (සමාලෝචනය සහ පෙරනිමිය):

එකතු කරන්න සමාලෝචනය පරිසරය තුළ යෙදවීම/වෙබ් අඩවිය/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',
    },
  },
}

අපි jobu ගැනත් සමීපව බලමු නැවතුම්_සමාලෝචනය, ශාඛාව මකා දැමූ විට එය ක්‍රියා විරහිත වන අතර gitlab එය පරීක්ෂා කිරීමට උත්සාහ නොකරනු ඇත. GIT_STRATEGY: කිසිවක් නැත, පසුව අපි ක්ලෝන කරමු ස්වාමියා- ශාඛාව සහ එය හරහා සමාලෝචන මකා දමන්න.
එය ටිකක් අවුල් සහගතයි, නමුත් මම තවම ලස්සන මාර්ගයක් සොයාගෙන නැත.
විකල්ප විකල්පයක් වනුයේ සෑම සමාලෝචනයක්ම හෝටල් නාම අවකාශයකට යෙදවීමයි, එය සැමවිටම සම්පූර්ණයෙන්ම කඩා දැමිය හැක.

අපගේ වෙනස්කම් සිදු කිරීමට අමතක නොකරන්න:

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

git push, git Checkout -b පරීක්ෂණය, git push මූල පරීක්ෂණය, චෙක් පත:

Gitlab හි නිර්මාණය කරන ලද පරිසරයේ තිර රුව

Kubernetes හි යෙදවීම ගොඩනැගීම සහ ස්වයංක්‍රීය කිරීම සඳහා නව මෙවලම් උත්සාහ කරමින්

හැම දෙයක්ම වැඩ කරනවාද? - නියමයි, අපගේ පරීක්ෂණ ශාඛාව මකන්න: git පිටවීමේ මාස්ටර්, git push සම්භවය: test, පරිසරය මකාදැමීමේ රැකියා දෝෂයකින් තොරව ක්‍රියාත්මක වූ බව අපි පරීක්ෂා කරමු.

ව්‍යාපෘතියක ඕනෑම සංවර්ධකයෙකුට ශාඛා නිර්මාණය කළ හැකි බවත්, ඔහුට වෙනස් කළ හැකි බවත් මෙහිදී මම වහාම පැහැදිලි කිරීමට කැමැත්තෙමි .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 push, සහ පරීක්ෂා කරන්න:

සමාලෝචන යෙදුම් බොත්තමෙහි තිර රුව

Kubernetes හි යෙදවීම ගොඩනැගීම සහ ස්වයංක්‍රීය කිරීම සඳහා නව මෙවලම් උත්සාහ කරමින්

කාර්යය නිමයි!

ව්යාපෘති මූලාශ්ර:

ඔබේ අවධානයට ස්තූතියි, ඔබ එයට කැමති වූ බව මම විශ්වාස කරමි Kubernetes හි යෙදවීම ගොඩනැගීම සහ ස්වයංක්‍රීය කිරීම සඳහා නව මෙවලම් උත්සාහ කරමින්

මූලාශ්රය: www.habr.com

අදහස් එක් කරන්න