Halló! Nýlega hafa mörg flott sjálfvirkniverkfæri verið gefin út bæði til að byggja Docker myndir og til að dreifa á Kubernetes. Í þessu sambandi ákvað ég að leika mér með GitLab, rannsaka hæfileika þess vandlega og að sjálfsögðu setja upp leiðsluna.

Þetta verk var innblásið af vefsíðunni kubernetes.io, sem er myndað úr frumkóða sjálfkrafa, og fyrir hverja laugarbeiðni sem send er, býr vélmennið sjálfkrafa til forskoðunarútgáfu af síðunni með breytingunum þínum og gefur upp hlekk til að skoða.

Ég reyndi að byggja svipað ferli frá grunni, en byggt algjörlega á Gitlab CI og ókeypis verkfærum sem ég er vanur að nota til að dreifa forritum á Kubernetes. Í dag mun ég loksins segja þér meira frá þeim.

Greinin mun fjalla um verkfæri eins og:
Hugo, qbec, kaniko, git-crypt и GitLab CI með því að skapa kraftmikið umhverfi.

Innihald

1. Hittu Hugo
2. Undirbúningur Dockerfile
3. Að kynnast kaniko
4. Að kynnast qbec
5. Er að prófa Gitlab-runner með Kubernetes-executor
6. Sendir Helm töflur með qbec
7. Við kynnum git-crypt
8. Að búa til verkfærakistumynd
9. Fyrsta leiðsla okkar og samsetning mynda eftir merkjum
10. Sjálfvirkni dreifingarinnar
11. Artifacts og samsetning þegar ýtt er til að ná tökum á
12. Dynamiskt umhverfi
13. Skoðaðu forrit

1. Að kynnast Hugo

Sem dæmi um verkefnið okkar munum við reyna að búa til skjalaútgáfusíðu byggða á Hugo. Hugo er kyrrstæður efnisframleiðandi.

Fyrir þá sem ekki þekkja truflanir rafala, mun ég segja þér aðeins meira um þá. Ólíkt hefðbundnum vefsíðuvélum með gagnagrunni og sumum PHP, sem, þegar notandi biður um það, búa til síður á flugu, eru truflanir rafala hannaðir aðeins öðruvísi. Þeir gera þér kleift að taka heimildir, venjulega sett af skrám í Markdown merkingu og þemasniðmátum, og safna þeim síðan saman í fullbúna vefsíðu.

Það er, fyrir vikið færðu möppuskipulag og sett af mynduðum HTML skrám, sem þú getur einfaldlega hlaðið upp á hvaða ódýra hýsingu sem er og fengið virka vefsíðu.

Þú getur sett Hugo upp á staðnum og prófað það:

Uppsetning nýrrar síðu:

hugo new site docs.example.org

Og á sama tíma git geymslan:

cd docs.example.org
git init

Hingað til er síðan okkar óspillt og til þess að eitthvað birtist á henni þurfum við fyrst að tengja þema; þema er bara sett af sniðmátum og tilgreindum reglum sem síðan okkar er búin til.

Fyrir þemað sem við munum nota Læra, sem að mínu mati hentar fullkomlega fyrir skjalasíðu.

Mig langar að taka sérstaklega eftir því að við þurfum ekki að vista þemaskrárnar í geymslu verkefnisins okkar, heldur getum við einfaldlega tengt það með því að nota git undireining:

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

Þannig mun geymslan okkar aðeins innihalda skrár sem tengjast verkefninu okkar beint og tengt þemað verður áfram sem hlekkur á tiltekna geymslu og skuldbinding í henni, það er að segja að það er alltaf hægt að draga það úr upprunalegum uppruna og ekki vera hræddur við ósamrýmanlegar breytingar.

Við skulum leiðrétta stillinguna config.toml:

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

Nú þegar á þessu stigi geturðu keyrt:

hugo server

Og á heimilisfanginu http://localhost:1313/ athugaðu nýstofnaða vefsíðu okkar, allar breytingar sem gerðar eru í skránni uppfæra sjálfkrafa opna síðu í vafranum, mjög þægilegt!

Við skulum reyna að búa til forsíðu í content/_index.md:

# My docs site

## Welcome to the docs!

You will be very smart :-)

Skjáskot af nýstofnuðu síðunni

Til að búa til síðu skaltu bara keyra:

hugo

Innihald skráar áhorfendur/ og verður vefsíðan þín.
Já, við the vegur, við skulum strax bæta því við .gitignore:

echo /public > .gitignore

Ekki gleyma að skuldbinda breytingar okkar:

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

2. Undirbúningur Dockerfile

Það er kominn tími til að skilgreina uppbyggingu geymslunnar okkar. Ég nota venjulega eitthvað eins og:

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

• dockerfiles/ - innihalda möppur með Dockerfiles og allt sem þarf til að búa til Docker myndirnar okkar.
• dreifa/ — inniheldur möppur til að dreifa forritunum okkar á Kubernetes

Þannig munum við búa til fyrstu Dockerfile okkar á leiðinni 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" ]

Eins og þú sérð inniheldur Dockerfile tvo FRÁ, þessi eiginleiki er kallaður fjölþrepa byggingu og gerir þér kleift að útiloka allt sem er óþarft frá endanlegu docker myndinni.
Þannig mun lokamyndin aðeins innihalda dökk httpd (léttur HTTP netþjónn) og áhorfendur/ — innihald vefsvæðis okkar sem er kyrrstætt myndað.

Ekki gleyma að skuldbinda breytingar okkar:

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

3. Að kynnast kaniko

Sem bryggjumyndasmiður ákvað ég að nota kaniko, þar sem aðgerð þess krefst ekki bryggjupúkunnar, og smíðin sjálf er hægt að framkvæma á hvaða vél sem er og skyndiminni er hægt að geyma beint í skránni, og útilokar þar með þörfina á að hafa fullgilda viðvarandi geymslu.

Til að byggja myndina skaltu bara keyra ílátið með kaniko framkvæmdastjóri og sendu það núverandi byggingarsamhengi; þetta er líka hægt að gera á staðnum, í gegnum 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

Hvar registry.gitlab.com/kvaps/docs.example.org/website - nafnið á Docker myndinni þinni; eftir byggingu verður það sjálfkrafa ræst í docker registry.

Viðfang --skyndiminni gerir þér kleift að vista lög í docker-skránni; fyrir dæmið sem gefið er verða þau vistuð í registry.gitlab.com/kvaps/docs.example.org/website/cache, en þú getur tilgreint aðra slóð með því að nota færibreytuna --cache-repo.

Skjáskot af docker-registry

4. Að kynnast qbec

Qbec er dreifingartæki sem gerir þér kleift að lýsa umsóknarskrám þínum með yfirlýsandi hætti og dreifa þeim á Kubernetes. Notkun Jsonnet sem aðalsetningafræði gerir þér kleift að einfalda lýsingu á mismun milli margra umhverfi til muna og útilokar líka nánast algjörlega endurtekningu kóða.

Þetta getur sérstaklega átt við í þeim tilvikum þar sem þú þarft að dreifa forriti í nokkra klasa með mismunandi breytur og vilt lýsa þeim með yfirlýsandi hætti í Git.

Qbec gerir þér einnig kleift að birta Helm töflur með því að gefa þeim nauðsynlegar færibreytur og stjórna þeim síðan á sama hátt og venjulegar birtingarmyndir, þar á meðal geturðu beitt ýmsum stökkbreytingum á þau, og þetta gerir þér aftur kleift að losna við þörfina á að nota ChartMuseum. Það er að segja, þú getur geymt og birt töflur beint úr git, þar sem þau eiga heima.

Eins og ég sagði áðan munum við geyma allar dreifingar í möppu dreifa/:

mkdir deploy
cd deploy

Við skulum frumstilla fyrsta forritið okkar:

qbec init website
cd website

Nú lítur uppbygging umsóknar okkar svona út:

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

við skulum skoða skrána qbec.yaml:

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

Hér höfum við fyrst og fremst áhuga á sérstakur.umhverfi, qbec hefur þegar búið til sjálfgefið umhverfi fyrir okkur og tekið netfang netþjónsins, sem og nafnrými úr núverandi kubeconfig okkar.
Nú þegar verið er að dreifa til sjálfgefið umhverfi, qbec mun alltaf dreifa aðeins á tilgreindan Kubernetes þyrping og á tilgreint nafnrými, það er, þú þarft ekki lengur að skipta á milli samhengi og nafnrýmis til að dreifa.
Ef nauðsyn krefur geturðu alltaf uppfært stillingarnar í þessari skrá.

Öllu umhverfi þínu er lýst í qbec.yaml, og í skránni params.libsonnet, þar sem segir hvar á að fá færibreytur fyrir þær.

Næst sjáum við tvær möppur:

• íhlutir/ - allar upplýsingaskrár fyrir forritið okkar verða geymdar hér; þeim er hægt að lýsa bæði í jsonnet og venjulegum yaml skrám
• umhverfi/ — hér munum við lýsa öllum breytum (færibreytum) fyrir umhverfi okkar.

Sjálfgefið er að við höfum tvær skrár:

• umhverfi/base.libsonnet - það mun innihalda algengar breytur fyrir öll umhverfi
• umhverfi/default.libsonnet — inniheldur færibreytur sem er hnekkt fyrir umhverfið sjálfgefið

opnum umhverfi/base.libsonnet og bæta við breytum fyrir fyrsta íhlutinn okkar þar:

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

Við skulum líka búa til fyrsta íhlutinn okkar íhlutir/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,
                },
              },
            ],
          },
        },
      ],
    },
  },
]

Í þessari skrá lýstum við þremur Kubernetes einingar í einu, þetta eru: dreifing, þjónusta и Innstreymi. Ef við vildum gætum við sett þá í mismunandi íhluti, en á þessu stigi mun einn vera nóg fyrir okkur.

Setningafræði jsonnet er mjög svipað venjulegu json, í grundvallaratriðum er venjulegt json nú þegar gilt jsonnet, svo í fyrstu gæti verið auðveldara fyrir þig að nota netþjónustu eins og yaml2json til að breyta venjulegu yaml í json, eða, ef íhlutir þínir innihalda engar breytur, þá er hægt að lýsa þeim í formi venjulegs yaml.

Þegar unnið er með jsonnet Ég mæli eindregið með því að setja upp viðbót fyrir ritstjórann þinn

Til dæmis er viðbót fyrir vim vim-jsonnet, sem kveikir á setningafræði auðkenningu og keyrir sjálfkrafa jsonnet fmt í hvert skipti sem þú vistar (þarf að setja upp jsonnet).

Allt er tilbúið, nú getum við byrjað að dreifa:

Til að sjá hvað við fengum, skulum hlaupa:

qbec show default

Við úttakið muntu sjá birtar yaml birtingarmyndir sem verða notaðar á sjálfgefna klasann.

Frábært, notaðu nú:

qbec apply default

Við úttakið muntu alltaf sjá hvað verður gert í klasanum þínum, qbec mun biðja þig um að samþykkja breytingarnar með því að slá inn y þú munt geta staðfest fyrirætlanir þínar.

Forritið okkar er tilbúið og dreift!

Ef þú gerir breytingar geturðu alltaf gert:

qbec diff default

til að sjá hvernig þessar breytingar munu hafa áhrif á núverandi dreifingu

Ekki gleyma að skuldbinda breytingar okkar:

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

5. Reynir Gitlab-runner með Kubernetes-executor

Þar til nýlega notaði ég bara venjulega gitlab-hlaupari á fyrirfram tilbúinni vél (LXC ílát) með skel eða docker-executor. Upphaflega höfðum við nokkra slíka hlaupara skilgreinda á heimsvísu í gitlabinu okkar. Þeir söfnuðu bryggjumyndum fyrir öll verkefni.

En eins og æfingin hefur sýnt er þessi valkostur ekki sá besti, bæði hvað varðar hagkvæmni og öryggi. Það er miklu betra og hugmyndafræðilega réttara að hafa sérstaka hlaupara fyrir hvert verkefni, eða jafnvel fyrir hvert umhverfi.

Sem betur fer er þetta alls ekki vandamál þar sem nú munum við dreifa gitlab-hlaupari beint sem hluti af verkefninu okkar í Kubernetes.

Gitlab býður upp á tilbúið stýrikort til að dreifa gitlab-runner á Kubernetes. Þannig að allt sem þú þarft að gera er að komast að því skráningartákn fyrir verkefnið okkar í Stillingar -> CI / CD -> Hlauparar og sendu það til stjórnarinnar:

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

Hvar:

• https://gitlab.com - heimilisfang Gitlab netþjónsins þíns.
• yga8y-jdCusVDn_t4Wxc — skráningartákn fyrir verkefnið þitt.
• rbac.create=true — veitir hlauparanum nauðsynleg magn af forréttindum til að geta búið til belg til að framkvæma verkefni okkar með því að nota kubernetes-executor.

Ef allt er rétt gert ættirðu að sjá skráðan hlaupara í kaflanum Runners, í verkefnastillingunum þínum.

Skjáskot af hlauparanum sem bætt var við

Er þetta svona einfalt? - já, svo einfalt er það! Ekki meira vesen með að skrá hlaupara handvirkt, héðan í frá verða hlauparar búnir til og eytt sjálfkrafa.

6. Settu upp Helm töflur með QBEC

Þar sem við ákváðum að íhuga gitlab-hlaupari hluti af verkefninu okkar, það er kominn tími til að lýsa því í Git geymslunni okkar.

Við gætum lýst því sem sérstökum þætti vefsíðu., en í framtíðinni ætlum við að dreifa mismunandi eintökum vefsíðu. mjög oft, ólíkt gitlab-hlaupari, sem verður aðeins notað einu sinni í hverjum Kubernetes klasa. Svo við skulum frumstilla sérstakt forrit fyrir það:

cd deploy
qbec init gitlab-runner
cd gitlab-runner

Að þessu sinni munum við ekki lýsa Kubernetes einingum handvirkt, heldur munum við taka tilbúið Helm töflu. Einn af kostum qbec er hæfileikinn til að birta Helm töflur beint úr Git geymslu.

Við skulum tengja það með git undireiningu:

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

Nú skráin söluaðili/gitlab-hlaupari Við erum með geymslu með töflu fyrir gitlab-runner.

Á svipaðan hátt geturðu tengt aðrar geymslur, til dæmis alla geymsluna við opinber töflur https://github.com/helm/charts

Við skulum lýsa þættinum hluti/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,
  }
)

Fyrstu rökin til expandHelmTemplate þá förum við leiðina að töflunni params.gildi, sem við tökum úr umhverfisbreytum, þá kemur hluturinn með

• nafnSniðmát - útgáfutitill
• nafnrými — nafnrými flutt yfir á stýri
• þessa skrá — nauðsynleg færibreyta sem sendir slóðina að núverandi skrá
• orðréttur - sýnir skipunina sniðmát hjálms með öllum rökum við gerð töflunnar

Nú skulum við lýsa breytum fyrir íhlutinn okkar í umhverfi/base.libsonnet:

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

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

Borgaðu eftirtekt runnerRegistrationToken við tökum úr utanaðkomandi skrá secrets/base.libsonnet, búum það til:

{
  runnerRegistrationToken: 'yga8y-jdCusVDn_t4Wxc',
}

Athugum hvort allt virkar:

qbec show default

ef allt er í lagi, þá getum við eytt fyrri útgáfu okkar í gegnum Helm:

helm uninstall gitlab-runner

og notaðu það á sama hátt, en í gegnum qbec:

qbec apply default

7. Kynning á git-crypt

Git-crypt er tól sem gerir þér kleift að setja upp gagnsæja dulkóðun fyrir geymsluna þína.

Í augnablikinu lítur möppuuppbyggingin okkar fyrir gitlab-runner svona út:

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

En að geyma leyndarmál í Git er ekki öruggt, er það? Svo við þurfum að dulkóða þær almennilega.

Venjulega, vegna einnar breytu, er þetta ekki alltaf skynsamlegt. Þú getur flutt leyndarmál til qbec og í gegnum umhverfisbreytur CI kerfisins þíns.
En það er athyglisvert að það eru líka flóknari verkefni sem geta innihaldið miklu fleiri leyndarmál; að flytja þau öll í gegnum umhverfisbreytur verður mjög erfitt.

Þar að auki, í þessu tilfelli myndi ég ekki geta sagt þér frá svo dásamlegu tæki eins og git-crypt.

git-crypt Það er líka þægilegt að því leyti að það gerir þér kleift að vista alla sögu leyndarmála, sem og bera saman, sameina og leysa átök á sama hátt og við erum vön að gera í tilviki Git.

Það fyrsta eftir uppsetningu git-crypt við þurfum að búa til lykla fyrir geymsluna okkar:

git crypt init

Ef þú ert með PGP lykil geturðu strax bætt sjálfum þér við sem samstarfsaðila fyrir þetta verkefni:

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

Þannig geturðu alltaf afkóðað þessa geymslu með einkalyklinum þínum.

Ef þú ert ekki með PGP lykil og býst ekki við honum, þá geturðu farið í hina áttina og flutt út verkefnislykilinn:

git crypt export-key /path/to/keyfile

Þannig allir sem hafa flutt út lykilskrá mun geta afkóðað geymsluna þína.

Það er kominn tími til að setja upp fyrsta leyndarmálið okkar.
Ég minni á að við erum enn í skránni deploy/gitlab-runner/, þar sem við höfum möppu leyndarmál/, við skulum dulkóða allar skrárnar í henni, til þess munum við búa til skrá leyndarmál/.gitattributes með eftirfarandi innihaldi:

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

Eins og sést af innihaldinu eru allar skrár grímuklæddar * verður ekið í gegn git-crypt, nema hæstv .gitattributes

Við getum athugað þetta með því að keyra:

git crypt status -e

Úttakið verður listi yfir allar skrár í geymslunni sem dulkóðun er virkjuð fyrir

Það er allt, nú getum við örugglega framkvæmt breytingar okkar:

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

Til að loka á geymslu skaltu bara keyra:

git crypt lock

og strax munu allar dulkóðaðar skrár breytast í tvöfalda eitthvað, það verður ómögulegt að lesa þær.
Til að afkóða geymsluna skaltu keyra:

git crypt unlock

8. Búðu til verkfærakistumynd

Verkfærakassamynd er mynd með öllum verkfærum sem við munum nota til að dreifa verkefninu okkar. Það verður notað af Gitlab hlauparanum til að framkvæma dæmigerð dreifingarverkefni.

Allt er einfalt hér, við skulum búa til nýjan dockerfiles/tólkassi/Dockerfile með eftirfarandi innihaldi:

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

Eins og þú sérð, á þessari mynd setjum við upp öll tólin sem við notuðum til að dreifa forritinu okkar. Við þurfum þess ekki hér nema kubectl, en þú gætir viljað leika þér með það meðan á leiðsluuppsetningu stendur.

Einnig, til þess að geta átt samskipti við Kubernetes og dreift á það, þurfum við að stilla hlutverk fyrir belg sem myndast af gitlab-runner.

Til að gera þetta, förum í möppuna með gitlab-runner:

cd deploy/gitlab-runner

og bæta við nýjum þætti íhlutir/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,
      },
    ],
  },
]

Við munum einnig lýsa nýju breytunum í umhverfi/base.libsonnet, sem lítur nú svona út:

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

Borgaðu eftirtekt $.components.rbac.name er átt við nafn fyrir þáltill rbac

Við skulum athuga hvað hefur breyst:

qbec diff default

og notaðu breytingar okkar á Kubernetes:

qbec apply default

Einnig, ekki gleyma að skuldbinda breytingar okkar á 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. Fyrsta leiðslan okkar og samsetning mynda eftir merkjum

Í rót verkefnisins munum við búa til .gitlab-ci.yml með eftirfarandi innihaldi:

.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

Vinsamlegast athugaðu að við notum GIT_SUBMODULE_STRATEGY: eðlilegt fyrir þau störf þar sem þú þarft að frumstilla undireiningar fyrir framkvæmd.

Ekki gleyma að skuldbinda breytingar okkar:

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

Ég held að það sé óhætt að kalla þetta útgáfu v0.0.1 og bættu við merkinu:

git tag v0.0.1

Við munum bæta við merkjum þegar við þurfum að gefa út nýja útgáfu. Merki í Docker myndum verða bundin við Git merki. Hver ýta með nýju merki mun frumstilla byggingu mynda með þessu merki.

Gerum það git push --tags, og við skulum líta á fyrstu leiðsluna okkar:

Skjáskot af fyrstu leiðslunni

Það er þess virði að vekja athygli þína á því að samsetning með merkjum er hentugur til að búa til bryggjumyndir, en hentar ekki til að dreifa forriti á Kubernetes. Þar sem hægt er að úthluta nýjum merkjum til gamalla skuldbindinga, í þessu tilfelli, mun frumstilla leiðslunnar fyrir þau leiða til dreifingar á gömlu útgáfunni.

Til að leysa þetta vandamál er smíði docker-mynda venjulega bundin við merki og dreifing forritsins í útibú húsbóndi, þar sem útgáfur af söfnuðu myndunum eru harðkóðaðar. Þetta er þar sem þú getur frumstillt afturköllun með einfaldri afturköllun húsbóndi-útibú.

10. Sjálfvirkni dreifingarinnar

Til þess að Gitlab-runner geti afkóðað leyndarmál okkar þurfum við að flytja út geymslulykilinn og bæta honum við CI umhverfisbreyturnar okkar:

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

Við munum vista línuna sem myndast í Gitlab; til að gera þetta skulum við fara í verkefnastillingarnar okkar:
Stillingar -> CI / CD -> Breytur

Og búum til nýja breytu:

Gerð
Key
gildi
Vernda
masked
Gildissvið

File
GITCRYPT_KEY
<your string>
true (meðan á þjálfun stendur getur þú false)
true
All environments

Skjáskot af breytunni sem bætt var við

Nú skulum við uppfæra okkar .gitlab-ci.yml bætir við það:

.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

Hér höfum við virkjað nokkra nýja valkosti fyrir qbec:

• --root some/app — gerir þér kleift að ákvarða möppu tiltekins forrits
• --force:k8s-samhengi __incluster__ - þetta er töfrabreyta sem segir að dreifingin muni eiga sér stað í sama klasa og gtilab-runner er í gangi. Þetta er nauðsynlegt vegna þess að annars mun qbec reyna að finna viðeigandi Kubernetes netþjón í kubeconfig þinni
• --bíddu — neyðir qbec til að bíða þar til auðlindirnar sem það býr til fara í tilbúið ástand og aðeins þá hætta með árangursríkan útgöngukóða.
• -Já - slekkur einfaldlega á gagnvirku skelinni Ertu viss? þegar komið er á vettvang.

Ekki gleyma að skuldbinda breytingar okkar:

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

Og eftir git ýta við munum sjá hvernig forritunum okkar hefur verið dreift:

Skjáskot af annarri leiðslunni

11. Artifacts og samsetning þegar ýtt er á meistara

Venjulega duga skrefin sem lýst er hér að ofan til að byggja upp og afhenda nánast hvaða örþjónustu sem er, en við viljum ekki bæta við merki í hvert skipti sem við þurfum að uppfæra síðuna. Þess vegna munum við taka kraftmeiri leið og setja upp samdráttaruppsetningu í aðalgreininni.

Hugmyndin er einföld: nú er ímynd okkar vefsíðu. verður endurbyggt í hvert skipti sem þú ýtir inn húsbóndi, og dreift síðan sjálfkrafa til Kubernetes.

Við skulum uppfæra þessi tvö störf í okkar .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"

Vinsamlegast athugaðu að við höfum bætt við þræði húsbóndi к dómsmrh fyrir störf byggja_vefsíðu og við notum núna $CI_COMMIT_REF_NAME í staðinn fyrir $CI_COMMIT_TAG, það er að segja, við erum losuð frá merkjum í Git og nú munum við ýta á mynd með nafni commit greinarinnar sem frumstillti leiðsluna. Þess má geta að þetta mun einnig virka með merkjum, sem gerir okkur kleift að vista skyndimyndir af síðu með tiltekinni útgáfu í docker-skránni.

Þegar nafnið á docker taginu fyrir nýja útgáfu af síðunni getur verið óbreytt verðum við samt að lýsa breytingunum á Kubernetes, annars mun það einfaldlega ekki endurdreifa forritinu frá nýju myndinni, þar sem það mun ekki taka eftir neinum breytingum á dreifingarskrá.

Valkostur —vm:ext-str digest="$DIGEST" fyrir qbec - gerir þér kleift að senda ytri breytu til jsonnet. Við viljum að það verði endurdreift í klasanum með hverri útgáfu af forritinu okkar. Við getum ekki lengur notað merkisheitið, sem nú getur verið óbreytanlegt, þar sem við þurfum að vera bundin við ákveðna útgáfu af myndinni og kveikja á dreifingunni þegar hún breytist.

Hér munum við hjálpa okkur af getu Kaniko til að vista samantektarmynd í skrá (valkostur --digest-skrá)
Síðan munum við flytja þessa skrá og lesa hana þegar hún er dreifing.

Við skulum uppfæra breytur fyrir okkar deploy/website/environments/base.libsonnet sem mun nú líta svona út:

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

Búið, nú skuldbinda sig húsbóndi frumstillir byggingu docker myndarinnar fyrir vefsíðu., og settu það síðan í Kubernetes.

Ekki gleyma að skuldbinda breytingar okkar:

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

Við athugum síðar git ýta við ættum að sjá eitthvað á þessa leið:

Skjáskot af leiðslu fyrir meistara

Í grundvallaratriðum þurfum við ekki að endurvirkja gitlab-runner við hverja ýtingu, nema auðvitað hafi ekkert breyst í uppsetningu hans, við skulum laga það í .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/**/*

breytingar gerir þér kleift að fylgjast með breytingum á deploy/gitlab-runner/ og mun aðeins kveikja starf okkar ef það eru einhver

Ekki gleyma að skuldbinda breytingar okkar:

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

git ýta, það er betra:

Skjáskot af uppfærðri leiðslu

12. Kvikt umhverfi

Það er kominn tími til að auka fjölbreytni í leiðslu okkar með kraftmiklu umhverfi.

Fyrst skulum við uppfæra starfið byggja_vefsíðu í okkar .gitlab-ci.yml, fjarlægja blokkina úr því aðeins, sem mun neyða Gitlab til að kveikja á því á hvaða skuldbindingu sem er í hvaða grein sem er:

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/

Uppfærðu síðan starfið deploy_website, bæta við blokk þar umhverfi:

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"

Þetta gerir Gitlab kleift að tengja starfið við prod umhverfi og birta réttan hlekk á það.

Nú skulum við bæta við tveimur störfum í viðbót:

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

Þeir verða ræstir þegar þeir eru ýttir í hvaða útibú sem er nema meistara og munu birta forskoðunarútgáfu síðunnar.

Við sjáum nýjan valkost fyrir qbec: --app-merki — það gerir þér kleift að merkja notaðar útgáfur af forritinu og vinna aðeins innan þessa merkis; þegar þú býrð til og eyðir auðlindum í Kubernetes mun qbec aðeins starfa með þeim.
Þannig getum við ekki búið til sérstakt umhverfi fyrir hverja umsögn, heldur einfaldlega endurnýtt það sama.

Hér notum við líka qbec beita endurskoðun, í staðinn fyrir qbec gilda sjálfgefið - þetta er einmitt augnablikið þegar við munum reyna að lýsa muninum fyrir umhverfi okkar (endurskoðun og sjálfgefið):

Við skulum bæta við endurskoða umhverfi í deploy/website/qbec.yaml

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

Þá munum við lýsa því yfir 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

Og skrifaðu niður sérsniðnar færibreytur fyrir það í 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',
    },
  },
}

Skoðum líka Jobu nánar stop_review, það verður ræst þegar útibúinu er eytt og svo að gitlab reyni ekki að borga er það notað GIT_STRATEGY: engin, síðar klónum við húsbóndi-útibúa og eyða umsögn í gegnum það.
Það er svolítið ruglingslegt, en ég hef ekki fundið fallegri leið ennþá.
Annar valkostur væri að dreifa hverri umsögn á nafnsvæði hótels, sem alltaf er hægt að rífa að öllu leyti.

Ekki gleyma að skuldbinda breytingar okkar:

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

git ýta, git checkout -b próf, git push uppruna próf, athugaðu:

Skjáskot af búið umhverfi í Gitlab

Er allt að virka? - frábært, eyða prófunargreininni okkar: git kassa meistari, git push origin :test, við athugum hvort umhverfiseyðingarstörfin virkuðu án villna.

Hér vil ég strax skýra að hvaða verktaki sem er í verkefni getur búið til útibú, hann getur líka breytt .gitlab-ci.yml skrá og fá aðgang að leynilegum breytum.
Þess vegna er eindregið mælt með því að leyfa notkun þeirra eingöngu fyrir verndaðar greinar, til dæmis í húsbóndi, eða búðu til sérstakt sett af breytum fyrir hvert umhverfi.

13. Skoðaðu öpp

Skoðaðu forrit Þetta er GitLab eiginleiki sem gerir þér kleift að bæta við hnappi fyrir hverja skrá í geymslunni til að skoða hana fljótt í uppsettu umhverfi.

Til þess að þessir hnappar birtist þarftu að búa til skrá .gitlab/leiðakort.yml og lýstu öllum leiðumbreytingum í því; í okkar tilviki verður það mjög einfalt:

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

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

Ekki gleyma að skuldbinda breytingar okkar:

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

git ýta, og athugaðu:

Skjáskot af hnappinum Review App

Starfið er búið!

Heimildir verkefnisins:

• á Gitlab: https://gitlab.com/kvaps/docs.example.org
• á GitHub: https://github.com/kvaps/docs.example.org

Þakka þér fyrir athyglina, ég vona að þér líkaði við hana

Heimild: www.habr.com