Բարեւ Ձեզ! Վերջերս թողարկվել են շատ զովացուցիչ ավտոմատացման գործիքներ ինչպես Docker պատկերներ ստեղծելու, այնպես էլ Kubernetes-ում տեղակայման համար: Այս առումով ես որոշեցի խաղալ GitLab-ի հետ, մանրակրկիտ ուսումնասիրել նրա հնարավորությունները և, իհարկե, կարգավորել խողովակաշարը:

Այս աշխատանքը ոգեշնչվել է կայքից kubernetes.io, որը առաջանում է աղբյուրի կոդերը ավտոմատ կերպով, և յուրաքանչյուր ուղարկված լողավազանի հարցում ռոբոտը ավտոմատ կերպով ստեղծում է կայքի նախադիտման տարբերակը՝ ձեր փոփոխություններով և տրամադրում է հղում դիտելու համար:

Ես փորձեցի զրոյից կառուցել նմանատիպ գործընթաց, բայց ամբողջությամբ կառուցված է Gitlab CI-ի և անվճար գործիքների վրա, որոնք ես սովոր եմ օգտագործել հավելվածները Kubernetes-ում տեղակայելու համար: Այսօր ես վերջապես ձեզ ավելին կպատմեմ նրանց մասին:

Հոդվածում կքննարկվեն այնպիսի գործիքներ, ինչպիսիք են.
Ուգո, qbec, կանիկո, git-crypt и GitLab CI դինամիկ միջավայրերի ստեղծմամբ։

Բովանդակություն

Հանդիպեք Հյուգոյին
Dockerfile-ի պատրաստում
Կանիկոյի հետ ծանոթանալը
Ծանոթանալ qbec-ին
Փորձում ենք Gitlab-runner-ը Kubernetes-ի կատարողի հետ
Helm գծապատկերների տեղակայում qbec-ով
Ներկայացնում ենք git-crypt
Գործիքների տուփի պատկերի ստեղծում
Մեր առաջին խողովակաշարը և պատկերների հավաքումն ըստ պիտակների
Տեղակայման ավտոմատացում
Արտեֆակտներ և հավաքում, երբ հրում եք տիրապետել
Դինամիկ միջավայրեր
Վերանայեք հավելվածները

1. Հյուգոյի հետ ծանոթանալը

Որպես մեր նախագծի օրինակ՝ մենք կփորձենք ստեղծել Հյուգոյի վրա հիմնված փաստաթղթերի հրապարակման կայք: Hugo-ն ստատիկ բովանդակության գեներատոր է:

Նրանց համար, ովքեր ծանոթ չեն ստատիկ գեներատորներին, ես ձեզ մի փոքր ավելին կպատմեմ դրանց մասին: Ի տարբերություն սովորական վեբկայքերի շարժիչների տվյալների բազայով և որոշ PHP-ներով, որոնք, երբ օգտատերը պահանջում է, ստեղծում են էջեր անմիջապես, ստատիկ գեներատորները նախագծված են մի փոքր այլ կերպ: Նրանք թույլ են տալիս վերցնել աղբյուրներ, սովորաբար ֆայլերի մի շարք Markdown-ի նշագրման և թեմայի ձևանմուշների մեջ, այնուհետև դրանք կազմել ամբողջությամբ ավարտված վեբկայքի մեջ:

Այսինքն՝ արդյունքում դուք կստանաք գրացուցակի կառուցվածք և ստեղծվող HTML ֆայլերի մի շարք, որոնք կարող եք պարզապես վերբեռնել ցանկացած էժան հոսթինգ և ստանալ աշխատանքային կայք։

Դուք կարող եք տեղադրել Hugo-ն տեղական և փորձել այն.

Նոր կայքի սկզբնավորում.

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 :-)

Նորաստեղծ էջի սքրինշոթը

Կայք ստեղծելու համար պարզապես գործարկեք՝

hugo

Գրացուցակի բովանդակությունը հանրային/ և կլինի ձեր կայքը:
Այո, ի դեպ, անմիջապես ավելացնենք .gitignore:

echo /public > .gitignore

Մի մոռացեք կատարել մեր փոփոխությունները՝

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

2. Dockerfile-ի պատրաստում

Ժամանակն է սահմանել մեր պահեստի կառուցվածքը: Ես սովորաբար օգտագործում եմ նման բան.

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

dockerfiles/ — պարունակում են դիրեկտորիաներ 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. Կանիկոյի հետ ծանոթանալը

Որպես docker image builder, ես որոշեցի օգտագործել կանիկո, քանի որ դրա շահագործումը չի պահանջում դոկեր դեյմոն, և կառուցումն ինքնին կարող է իրականացվել ցանկացած մեքենայի վրա, և քեշը կարող է ուղղակիորեն պահվել ռեեստրում, դրանով իսկ վերացնելով լիարժեք մշտական պահեստ ունենալու անհրաժեշտությունը:

Պատկերը ստեղծելու համար պարզապես գործարկեք կոնտեյները կանիկո կատարող և փոխանցեք այն ընթացիկ կառուցման համատեքստում; դա կարող է կատարվել նաև տեղական մակարդակում՝ docker-ի միջոցով.

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 — ձեր դոկերի պատկերի անունը; կառուցելուց հետո այն ավտոմատ կերպով կգործարկվի դոկերի գրանցամատյանում:

Parameter -- քեշ թույլ է տալիս քեշավորել շերտերը դոկերի ռեեստրում, տրված օրինակի համար դրանք կպահվեն registry.gitlab.com/kvaps/docs.example.org/website/cache, բայց դուք կարող եք նշել մեկ այլ ճանապարհ՝ օգտագործելով պարամետրը --cache-repo.

Docker-registry-ի սքրինշոթը

4. Ծանոթանալ qbec-ին

Քբեք տեղակայման գործիք է, որը թույլ է տալիս դեկլարատիվ կերպով նկարագրել ձեր հավելվածի մանիֆեստները և դրանք տեղակայել Kubernetes-ում: Jsonnet-ի օգտագործումը որպես հիմնական շարահյուսություն թույլ է տալիս մեծապես պարզեցնել տարբեր միջավայրերի միջև եղած տարբերությունների նկարագրությունը, ինչպես նաև գրեթե ամբողջությամբ վերացնում է կոդի կրկնությունը:

Սա կարող է հատկապես ճիշտ լինել այն դեպքերում, երբ դուք պետք է հավելված տեղակայեք տարբեր պարամետրերով մի քանի կլաստերներում և ցանկանում եք դրանք դեկլարատիվ կերպով նկարագրել Git-ում:

Qbec-ը նաև թույլ է տալիս Ձեզ տրամադրել Helm գծապատկերները՝ փոխանցելով դրանց անհրաժեշտ պարամետրերը և այնուհետև գործարկել դրանք այնպես, ինչպես սովորական մանիֆեստները, այդ թվում՝ կարող եք կիրառել տարբեր մուտացիաներ դրանց վրա, և դա, իր հերթին, թույլ է տալիս ազատվել անհրաժեշտությունից։ օգտագործել 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: {}

Այստեղ մեզ առաջին հերթին հետաքրքրում է սպեկտր.միջավայրեր, 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',
    },
  },
}

Եկեք նաև ստեղծենք մեր առաջին բաղադրիչը 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,
                },
              },
            ],
          },
        },
      ],
    },
  },
]

Այս ֆայլում մենք նկարագրեցինք միանգամից երեք Kubernetes սուբյեկտներ, դրանք են. տեղակայումը, Ծառայությունների и Մուտք. Եթե ցանկանայինք, կարող էինք դրանք դնել տարբեր բաղադրիչների մեջ, բայց այս փուլում մեզ բավական կլինի մեկը։

շարահյուսություն jsonnet շատ նման է սովորական json-ին, սկզբունքորեն սովորական json-ն արդեն վավեր է jsonnet-ին, ուստի սկզբում ձեզ համար կարող է ավելի հեշտ լինել օգտվել առցանց ծառայություններից, ինչպիսիք են. yaml2json ձեր սովորական yaml-ը json-ի վերածելու համար, կամ, եթե ձեր բաղադրիչները չեն պարունակում որևէ փոփոխական, ապա դրանք կարող են նկարագրվել սովորական yaml-ի տեսքով:

հետ աշխատելիս jsonnet Ես բարձր խորհուրդ եմ տալիս տեղադրել հավելված ձեր խմբագրի համար

Օրինակ, vim-ի համար կա plugin vim-jsonnet, որը միացնում է շարահյուսության ընդգծումը և ավտոմատ կերպով կատարում jsonnet fmt ամեն անգամ փրկելիս (պահանջում է տեղադրել jsonnet):

Ամեն ինչ պատրաստ է, այժմ մենք կարող ենք սկսել տեղակայումը.

Տեսնելու համար, թե ինչ ենք ստացել, վազենք.

qbec show default

Ելքում դուք կտեսնեք rendered yaml մանիֆեստներ, որոնք կկիրառվեն լռելյայն կլաստերի վրա:

Գերազանց, հիմա դիմիր.

qbec apply default

Ելքում դուք միշտ կտեսնեք, թե ինչ է արվելու ձեր կլաստերում, qbec-ը ձեզ կխնդրի համաձայնել փոփոխություններին՝ մուտքագրելով y դուք կկարողանաք հաստատել ձեր մտադրությունները:

Մեր հավելվածը պատրաստ է և գործարկված:

Եթե դուք փոփոխություններ եք կատարում, միշտ կարող եք անել.

qbec diff default

տեսնել, թե ինչպես այս փոփոխությունները կազդեն ընթացիկ տեղակայման վրա

Մի մոռացեք կատարել մեր փոփոխությունները՝

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

5. Փորձելով Gitlab-runner-ը Kubernetes-ի կատարողի հետ

Մինչեւ վերջերս ես օգտագործում էի միայն սովորական gitlab-runner նախապես պատրաստված մեքենայի վրա (LXC կոնտեյներ) կեղևով կամ դոկեր-կատարողով: Սկզբում մենք ունեինք մի քանի նման վազորդներ, որոնք գլոբալ կերպով սահմանված էին մեր gitlab-ում: Նրանք հավաքեցին դոկերի պատկերներ բոլոր նախագծերի համար:

Բայց ինչպես ցույց է տվել պրակտիկան, այս տարբերակը ամենաիդեալականը չէ թե՛ գործնականության, թե՛ անվտանգության առումով: Շատ ավելի լավ է և գաղափարապես ավելի ճիշտ է, որ յուրաքանչյուր նախագծի կամ նույնիսկ յուրաքանչյուր միջավայրի համար տեղակայվեն առանձին վազորդներ:

Բարեբախտաբար, դա ամենևին էլ խնդիր չէ, քանի որ հիմա մենք տեղակայելու ենք gitlab-runner ուղղակիորեն որպես մեր նախագծի մաս հենց Kubernetes-ում:

Gitlab-ը տրամադրում է պատրաստի ղեկային աղյուսակ՝ gitlab-runner-ը Kubernetes-ում տեղակայելու համար: Այսպիսով, ձեզ հարկավոր է միայն պարզել գրանցման նշան մեր նախագծի համար Պարամետրեր -> CI / CD -> Runners և փոխանցիր այն ղեկին:

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-ի միջոցով մեր առաջադրանքները կատարելու համար:

Եթե ամեն ինչ ճիշտ է արված, դուք պետք է տեսնեք գրանցված վազորդ բաժնում Runners, ձեր նախագծի կարգավորումներում:

Ավելացված վազորդի սքրինշոթը

Արդյո՞ք դա այդքան պարզ է: - այո, դա այնքան պարզ է: Այլևս դժվարություններ չկան վազորդներին ձեռքով գրանցելու հետ կապված, այսուհետ վազորդները կստեղծվեն և կոչնչացվեն ավտոմատ կերպով:

6. Տեղադրեք Helm գծապատկերները QBEC-ով

Քանի որ մենք որոշեցինք դիտարկել gitlab-runner մեր նախագծի մի մասը, ժամանակն է այն նկարագրել մեր Git պահոցում:

Մենք այն կարող էինք բնութագրել որպես առանձին բաղադրիչ կայքը, բայց ապագայում մենք նախատեսում ենք տեղակայել տարբեր օրինակներ կայքը շատ հաճախ, ի տարբերություն gitlab-runner, որը կտեղակայվի միայն մեկ անգամ Kubernetes կլաստերի համար: Այսպիսով, եկեք նախաստորագրենք դրա համար առանձին հավելված.

cd deploy
qbec init gitlab-runner
cd gitlab-runner

Այս անգամ մենք ձեռքով չենք նկարագրի Kubernetes-ի սուբյեկտները, այլ կվերցնենք պատրաստի Helm աղյուսակը: Qbec-ի առավելություններից մեկը Helm գծապատկերները ուղղակիորեն Git պահոցից ներկայացնելու հնարավորությունն է:

Եկեք միացնենք այն git ենթամոդուլի միջոցով.

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

Այժմ գրացուցակը վաճառող/gitlab-runner Մենք ունենք շտեմարան gitlab-runner-ի գծապատկերով:

Նմանապես, դուք կարող եք միացնել այլ պահեստներ, օրինակ, ամբողջ պահեստը պաշտոնական գծապատկերներով 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 մենք անցնում ենք գծապատկերի ճանապարհը, ապա պարամս.արժեքներ, որը վերցնում ենք շրջակա միջավայրի պարամետրերից, հետո գալիս է օբյեկտը

nameTemplate - թողարկման անվանումը
անուն տարածություն — անվանատարածքը փոխանցվել է ղեկին
այս Ֆայլը — պահանջվող պարամետր, որն անցնում է ընթացիկ ֆայլի ուղին
բանավոր - ցույց է տալիս հրամանը ղեկի ձևանմուշ գծապատկերը մատուցելիս բոլոր փաստարկներով

Այժմ եկեք նկարագրենք մեր բաղադրիչի պարամետրերը միջավայրեր/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 մենք վերցնում ենք արտաքին ֆայլից գաղտնիքներ/base.libsonnet, եկեք ստեղծենք այն.

{
  runnerRegistrationToken: 'yga8y-jdCusVDn_t4Wxc',
}

Եկեք ստուգենք, արդյոք ամեն ինչ աշխատում է.

qbec show default

եթե ամեն ինչ կարգին է, ապա մենք կարող ենք ջնջել մեր նախկինում տեղադրված թողարկումը Helm-ի միջոցով.

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, բացառությամբ մեծամասնության .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/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

Ինչպես տեսնում եք, այս նկարում մենք տեղադրում ենք բոլոր կոմունալ ծառայությունները, որոնք օգտագործել ենք մեր հավելվածը տեղակայելու համար: Մեզ այստեղ դա պետք չէ, քանի դեռ կուբեկտլ, բայց դուք կարող եք խաղալ դրա հետ խողովակաշարի տեղադրման փուլում:

Նաև, որպեսզի կարողանանք շփվել Kubernetes-ի հետ և տեղակայվել դրանում, մենք պետք է կարգավորենք դերը gitlab-runner-ի կողմից ստեղծվող pods-ի համար:

Դա անելու համար եկեք գնանք 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

Մենք կավելացնենք պիտակներ, երբ անհրաժեշտ լինի թողարկել նոր տարբերակ: Docker պատկերներում պիտակները կկապվեն Git թեգերի հետ: Նոր պիտակով յուրաքանչյուր սեղմում կսկսվի այս պիտակով պատկերների կառուցումը:

Եկեք անենք դա git push --tags, և եկեք նայենք մեր առաջին խողովակաշարին.

Առաջին խողովակաշարի սքրինշոթը

Արժե ձեր ուշադրությունը հրավիրել այն փաստի վրա, որ պիտակներով հավաքումը հարմար է docker պատկերներ կառուցելու համար, բայց հարմար չէ Kubernetes-ում հավելված տեղակայելու համար: Քանի որ նոր պիտակներ կարող են վերագրվել հին commit-ներին, այս դեպքում դրանց համար խողովակաշարի սկզբնավորումը կհանգեցնի հին տարբերակի տեղակայմանը:

Այս խնդիրը լուծելու համար սովորաբար դոկերի պատկերների կառուցումը կապված է պիտակների հետ, իսկ հավելվածի տեղակայումը մասնաճյուղում վարպետ, որտեղ հավաքված պատկերների տարբերակները կոշտ կոդավորված են: Սա այն վայրն է, որտեղ դուք կարող եք նախաստորագրել վերադարձը պարզ ետադարձով վարպետ-մասնաճյուղերը.

10. Տեղակայման ավտոմատացում

Որպեսզի Gitlab-runner-ը վերծանի մեր գաղտնիքները, մեզ անհրաժեշտ կլինի արտահանել պահեստի բանալին և ավելացնել այն մեր CI միջավայրի փոփոխականներին.

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

Մենք կպահենք ստացված տողը Gitlab-ում; դա անելու համար եկեք գնանք մեր նախագծի կարգավորումները.
Պարամետրեր -> CI / CD -> Փոփոխականներ

Եվ եկեք ստեղծենք նոր փոփոխական.

Տիպ
Բանալի
Արժեք
Պաշտպանված
masked
Շրջանակ

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-ը կփորձի գտնել համապատասխան Kubernetes սերվեր ձեր kubeconfig-ում
--սպասեք — ստիպում է qbec-ին սպասել, մինչև իր ստեղծած ռեսուրսները մտնեն Ready վիճակ և միայն դրանից հետո դուրս գան հաջող ելքի կոդով:
— այո - պարզապես անջատում է ինտերակտիվ վահանակը Համոզված ես? երբ տեղակայված է:

Մի մոռացեք կատարել մեր փոփոխությունները՝

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

Եւ հետո գնալ մղել մենք կտեսնենք, թե ինչպես են տեղակայվել մեր հավելվածները.

Երկրորդ խողովակաշարի սքրինշոթը

11. Արտեֆակտներ և հավաքում, երբ հրում եք տիրապետելու

Սովորաբար, վերը նկարագրված քայլերը բավարար են գրեթե ցանկացած միկրոսերվիս ստեղծելու և մատուցելու համար, բայց մենք չենք ցանկանում պիտակ ավելացնել ամեն անգամ, երբ մեզ անհրաժեշտ է թարմացնել կայքը։ Հետևաբար, մենք կանցնենք ավելի դինամիկ երթուղի և կստեղծենք digest տեղակայում հիմնական մասնաճյուղում:

Գաղափարը պարզ է. այժմ պատկերը մեր կայքը կվերակառուցվի ամեն անգամ, երբ ներս մտնեք վարպետ, և այնուհետև ավտոմատ կերպով տեղակայվել 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"

Խնդրում ենք նկատի ունենալ, որ մենք ավելացրել ենք թեմա վարպետ к վկայակոչելով աշխատատեղերի համար build_website և մենք հիմա օգտագործում ենք $CI_COMMIT_REF_NAME փոխարենը $CI_COMMIT_TAG, այսինքն՝ մենք անջատված ենք Git-ում պիտակներից, և այժմ մենք կհրաժարվենք պատկեր՝ commit մասնաճյուղի անունով, որը սկզբնավորել է խողովակաշարը։ Հարկ է նշել, որ սա կաշխատի նաև պիտակների հետ, ինչը թույլ կտա մեզ պահպանել որոշակի տարբերակով կայքի ակնոցները docker-registry-ում:

Երբ կայքի նոր տարբերակի համար docker պիտակի անունը կարող է անփոփոխ մնալ, մենք դեռ պետք է նկարագրենք Kubernetes-ի փոփոխությունները, հակառակ դեպքում այն պարզապես չի վերաբաշխի հավելվածը նոր պատկերից, քանի որ այն չի նկատի որևէ փոփոխություն: տեղակայման դրսևորում.

Տարբերակ —vm:ext-str digest="$DIGEST" qbec-ի համար - թույլ է տալիս արտաքին փոփոխական փոխանցել jsonnet-ին: Մենք ցանկանում ենք, որ այն վերատեղակայվի կլաստերում մեր հավելվածի յուրաքանչյուր թողարկումով: Մենք այլևս չենք կարող օգտագործել պիտակի անունը, որն այժմ կարող է անփոփոխ լինել, քանի որ մենք պետք է կապված լինենք պատկերի որոշակի տարբերակի հետ և գործարկենք տեղակայումը, երբ այն փոխվի:

Այստեղ մեզ կօգնի Kaniko-ի կարողությունը՝ պահպանել ամփոփ պատկերը ֆայլում (տարբերակ -- digest-ֆայլ)
Այնուհետև մենք կփոխանցենք այս ֆայլը և կկարդանք այն տեղակայման պահին:

Եկեք թարմացնենք պարամետրերը մեր համար 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',
    },
  },
}

Կատարված է, այժմ ցանկացած պարտավորություն վարպետ սկզբնավորում է docker պատկերի կառուցումը կայքը, և այնուհետև տեղակայեք այն Kubernetes-ում:

Մի մոռացեք կատարել մեր փոփոխությունները՝

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

Մենք ավելի ուշ կստուգենք գնալ մղել մենք պետք է տեսնենք նման բան.

Խողովակաշարի սքրինշոթը վարպետի համար

Սկզբունքորեն, մենք կարիք չունենք վերաբաշխել 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"

գնալ մղել, դա ավելի լավ է:

Թարմացված խողովակաշարի էկրանի պատկերը

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-ի համար. --app-tag — այն թույլ է տալիս պիտակավորել հավելվածի տեղաբաշխված տարբերակները և աշխատել միայն այս պիտակի շրջանակներում; 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',
    },
  },
}

Եկեք նաև մանրամասն նայենք jobu-ին stop_review, այն կգործարկվի, երբ մասնաճյուղը ջնջվի, և որպեսզի gitlab-ը չփորձի վճարել, այն օգտագործվում է GIT_STRATEGY. ոչ, հետագայում մենք կլոնավորում ենք վարպետ- մասնաճյուղ և ջնջել ակնարկը դրա միջոցով:
Դա մի փոքր շփոթեցնող է, բայց ես դեռ ավելի գեղեցիկ միջոց չեմ գտել:
Այլընտրանքային տարբերակ կլինի յուրաքանչյուր ակնարկ տեղադրել հյուրանոցի անվանական տարածքում, որը միշտ կարող է ամբողջությամբ քանդվել:

Մի մոռացեք կատարել մեր փոփոխությունները՝

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

գնալ մղել, git checkout -b թեստ, git push ծագման թեստ, ստուգեք.

Gitlab-ում ստեղծված միջավայրերի սքրինշոթ

Ամեն ինչ աշխատում է? - հիանալի, ջնջեք մեր թեստային մասնաճյուղը. գն ստուգում վարպետ, git push origin :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"

գնալ մղելև ստուգեք.

Վերանայման հավելվածի կոճակի սքրինշոթ

Աշխատանքն ավարտված է:

Ծրագրի աղբյուրները.

Gitlab-ում. https://gitlab.com/kvaps/docs.example.org
GitHub-ում. https://github.com/kvaps/docs.example.org

Շնորհակալություն ուշադրության համար, հուսով եմ այն ձեզ դուր եկավ

Source: www.habr.com

Փորձում ենք նոր գործիքներ Kubernetes-ում տեղակայման կառուցման և ավտոմատացման համար

Բովանդակություն

1. Հյուգոյի հետ ծանոթանալը

2. Dockerfile-ի պատրաստում

3. Կանիկոյի հետ ծանոթանալը

4. Ծանոթանալ qbec-ին

5. Փորձելով Gitlab-runner-ը Kubernetes-ի կատարողի հետ

6. Տեղադրեք Helm գծապատկերները QBEC-ով

7. Ներածություն git-crypt

8. Ստեղծեք գործիքատուփի պատկեր

9. Մեր առաջին խողովակաշարը և պատկերների հավաքումն ըստ պիտակների

10. Տեղակայման ավտոմատացում

11. Արտեֆակտներ և հավաքում, երբ հրում եք տիրապետելու

12. Դինամիկ միջավայրեր

13. Վերանայեք հավելվածները

Աշխատանքն ավարտված է:

Добавить комментарий Չեղարկել պատասխանել