ProHoster > Blogi > Haldamine > Uute tööriistade proovimine Kubernetes juurutamise loomiseks ja automatiseerimiseks

Uute tööriistade proovimine Kubernetes juurutamise loomiseks ja automatiseerimiseks

Uute tööriistade proovimine Kubernetes juurutamise loomiseks ja automatiseerimiseks

Tere! Hiljuti on välja antud palju lahedaid automatiseerimistööriistu nii Dockeri piltide loomiseks kui ka Kubernetes juurutamiseks. Sellega seoses otsustasin GitLabiga ringi mängida, selle võimalusi põhjalikult uurida ja loomulikult torujuhtme paika panna.

See töö on inspireeritud veebisaidilt kubernetes.io, mis on loodud lähtekoodid automaatselt ja iga saadetud basseinipäringu kohta genereerib robot automaatselt saidi eelvaateversiooni koos teie muudatustega ja annab vaatamiseks lingi.

Üritasin luua sarnase protsessi nullist, kuid tuginesin täielikult Gitlab CI-le ja tasuta tööriistadele, mida olen harjunud kasutama rakenduste juurutamiseks Kubernetes. Täna räägin teile lõpuks neist lähemalt.

Artiklis käsitletakse selliseid tööriistu nagu:
Hugo, qbec, kaniko, git-krüpt и GitLab CI dünaamiliste keskkondade loomisega.

Sisu

  1. Saage tuttavaks Hugoga
  2. Dockeri faili ettevalmistamine
  3. Kanikoga tutvumine
  4. qbeciga tutvumine
  5. Proovin Gitlab-runnerit Kubernetes-täitjaga
  6. Helmi diagrammide juurutamine qbeci abil
  7. Tutvustame git-crypt
  8. Tööriistakasti pildi loomine
  9. Meie esimene konveier ja piltide kokkupanek siltide järgi
  10. Juurutamise automatiseerimine
  11. Artefaktid ja kokkupanek kaptenile lükkamisel
  12. Dünaamilised keskkonnad
  13. Vaadake üle rakendused

1. Hugoga tutvumine

Näitena oma projektist proovime luua Hugole ehitatud dokumentatsiooni avaldamise saidi. Hugo on staatiline sisugeneraator.

Neile, kes pole staatiliste generaatoritega tuttavad, räägin teile nende kohta veidi rohkem. Erinevalt tavapärastest andmebaasi ja mõne PHP-ga veebisaidimootoritest, mis kasutaja soovil käigupealt lehti genereerivad, on staatilised generaatorid konstrueeritud veidi teisiti. Need võimaldavad teil võtta allikaid, tavaliselt Markdowni märgistuse ja teemamallide failide komplekti, seejärel kompileerida need täielikult valmis veebisaidiks.

See tähendab, et selle tulemusel saate kataloogistruktuuri ja genereeritud HTML-failide komplekti, mille saate lihtsalt mis tahes odavasse hostimisse üles laadida ja saada toimiva veebisaidi.

Saate installida Hugo kohapeal ja proovida seda:

Uue saidi lähtestamine:

hugo new site docs.example.org

Ja samal ajal giti hoidla:

cd docs.example.org
git init

Siiani on meie sait puutumatu ja selleks, et sellel midagi ilmuks, peame esmalt ühendama teema; teema on lihtsalt mallide ja määratud reeglite kogum, mille järgi meie sait luuakse.

Teema jaoks, mida kasutame Õppima, mis minu arvates sobib suurepäraselt dokumentatsiooni saidile.

Tahaksin pöörata erilist tähelepanu asjaolule, et me ei pea teemafaile oma projektihoidlasse salvestama, vaid saame selle lihtsalt ühendada kasutades git alammoodul:

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

Seega sisaldab meie hoidla ainult meie projektiga otseselt seotud faile ja ühendatud teema jääb lingiks konkreetsele hoidlale ja selles sisalduva kohustusena, see tähendab, et selle saab alati algallikast tõmmata ja mitte karta kokkusobimatud muudatused.

Parandame konfiguratsiooni config.toml:

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

Juba selles etapis saate joosta:

hugo server

Ja aadressil http://localhost:1313/ vaadake meie vastloodud veebisaiti, kõik kataloogis tehtud muudatused värskendavad automaatselt brauseris avatud lehte, väga mugav!

Proovime luua kaanelehe sisu/_index.md:

# My docs site

## Welcome to the docs!

You will be very smart :-)

Ekraanipilt vastloodud lehelt

Uute tööriistade proovimine Kubernetes juurutamise loomiseks ja automatiseerimiseks

Saidi loomiseks käivitage lihtsalt:

hugo

Kataloogi sisu avalik/ ja sellest saab teie veebisait.
Jah, muide, lisame selle kohe juurde .põlgur:

echo /public > .gitignore

Ärge unustage teha meie muudatusi:

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

2. Dockeri faili ettevalmistamine

On aeg määratleda meie hoidla struktuur. Tavaliselt kasutan midagi sellist:

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

  • dockerfiles/ — sisaldab Dockeri failidega katalooge ja kõike, mis on vajalik meie Dockeri piltide loomiseks.
  • juurutada/ — sisaldab katalooge meie rakenduste juurutamiseks Kubernetesesse

Seega loome tee ääres oma esimese Docker-faili 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" ]

Nagu näete, sisaldab Dockerfile kahte ALATES, seda funktsiooni nimetatakse mitmeastmeline ehitus ja võimaldab lõplikust Dockeri pildist välja jätta kõik ebavajaliku.
Seega sisaldab lõplik pilt ainult tumehttpd (kerge HTTP-server) ja avalik/ — meie staatiliselt loodud veebisaidi sisu.

Ärge unustage teha meie muudatusi:

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

3. Kanikoga tutvumine

Dockeri pildiehitajana otsustasin kasutada kaniko, kuna selle tööks ei ole vaja dokkedeemonit ja ehitamist saab teha mis tahes masinas ja vahemälu saab salvestada otse registrisse, välistades sellega vajaduse täisväärtusliku püsiva salvestusruumi järele.

Kujutise koostamiseks käivitage konteiner kaniko käsutäitja ja edastage see praegune ehituskontekst; seda saab teha ka kohapeal, dokkeri kaudu:

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

kus registry.gitlab.com/kvaps/docs.example.org/website - teie dokipildi nimi; pärast loomist käivitatakse see automaatselt dockeri registrisse.

Parameeter -- vahemälu võimaldab kihte vahemällu salvestada dockeri registris; antud näite puhul salvestatakse need sisse registry.gitlab.com/kvaps/docs.example.org/website/cache, kuid saate parameetri abil määrata teise tee -- vahemälu repo.

Dockeri registri ekraanipilt

Uute tööriistade proovimine Kubernetes juurutamise loomiseks ja automatiseerimiseks

4. qbeciga tutvumine

Qbec on juurutustööriist, mis võimaldab teil deklaratiivselt kirjeldada oma rakenduse manifeste ja juurutada need Kubernetesesse. Jsonneti kasutamine peamise süntaksina võimaldab oluliselt lihtsustada erinevate keskkondade erinevuste kirjeldamist ja samuti välistab peaaegu täielikult koodi kordamise.

See võib olla eriti tõsi juhtudel, kui peate juurutama rakenduse mitmele erinevate parameetritega klastrile ja soovite neid Gitis deklaratiivselt kirjeldada.

Qbec võimaldab teil renderdada ka Helmi diagramme, edastades neile vajalikud parameetrid ja seejärel kasutada neid samamoodi nagu tavalisi manifeste, sh saate neile rakendada erinevaid mutatsioone ja see omakorda võimaldab teil vabaneda vajadusest kasutage ChartMuseumi. See tähendab, et saate diagramme salvestada ja renderdada otse gitist, kuhu need kuuluvad.

Nagu ma varem ütlesin, salvestame kõik juurutused kataloogi juurutada/:

mkdir deploy
cd deploy

Initsialiseerime oma esimese rakenduse:

qbec init website
cd website

Nüüd näeb meie rakenduse struktuur välja selline:

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

vaatame faili qbec.yaml:

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

Siin huvitab meid eelkõige spec.environments, qbec on juba loonud meie jaoks vaikekeskkonna ja võtnud serveri aadressi ja ka nimeruumi meie praegusest kubeconfigist.
Nüüd juurutamisel vaikimisi keskkonnas juurutab qbec alati ainult määratud Kubernetese klastris ja määratud nimeruumis, see tähendab, et juurutamiseks ei pea te enam kontekstide ja nimeruumide vahel lülituma.
Vajadusel saate selle faili seadeid alati värskendada.

Kõiki teie keskkondi on kirjeldatud artiklis qbec.yaml, ja failis params.libsonnet, kus on kirjas, kust nende jaoks parameetreid hankida.

Järgmisena näeme kahte kataloogi:

  • komponendid / — kõik meie rakenduse manifestid salvestatakse siia; neid saab kirjeldada nii jsonnet- kui ka tavalistes yaml-failides
  • keskkonnad/ — siin kirjeldame kõiki meie keskkondade muutujaid (parameetreid).

Vaikimisi on meil kaks faili:

  • Environments/base.libsonnet - see sisaldab kõigi keskkondade jaoks ühiseid parameetreid
  • Environments/default.libsonnet — sisaldab keskkonna jaoks tühistatud parameetreid vaikimisi

teeme lahti Environments/base.libsonnet ja lisage sinna meie esimese komponendi parameetrid:

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

Loome ka oma esimese komponendi komponendid/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,
                },
              },
            ],
          },
        },
      ],
    },
  },
]

Selles failis kirjeldasime korraga kolme Kubernetese olemit, need on: Deployment, Teenus и Ingress. Soovi korral saaksime need erinevatesse komponentidesse panna, kuid praeguses etapis piisab meile ühest.

süntaks jsonnet on väga sarnane tavalise jsoniga, põhimõtteliselt on tavaline json juba kehtiv jsonnet, nii et alguses võib teil olla lihtsam kasutada selliseid võrguteenuseid nagu yaml2json tavalise yamli teisendamiseks jsoniks või kui teie komponendid ei sisalda muutujaid, saab neid kirjeldada tavalise yamli kujul.

Töötades koos jsonnet Soovitan tungivalt installida oma redaktori jaoks pistikprogramm

Näiteks vimi jaoks on olemas pistikprogramm vim-jsonnet, mis lülitab süntaksi esiletõstmise sisse ja käivitab automaatselt jsonnet fmt iga kord, kui salvestate (nõuab jsonnet installimist).

Kõik on valmis, nüüd saame alustada juurutamist:

Et näha, mis meil on, käivitame:

qbec show default

Väljundis näete renderdatud yamli manifeste, mis rakendatakse vaikeklastrile.

Suurepärane, nüüd kandideeri:

qbec apply default

Väljundis näete alati, mida teie klastris tehakse, qbec palub teil muudatustega nõustuda, tippides y saate oma kavatsusi kinnitada.

Meie rakendus on valmis ja kasutusele võetud!

Kui teete muudatusi, saate alati teha:

qbec diff default

et näha, kuidas need muudatused praegust juurutamist mõjutavad

Ärge unustage teha meie muudatusi:

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

5. Proovime Gitlab-runnerit Kubernetes-täitjaga

Kuni viimase ajani kasutasin ainult tavalist gitlab-jooksja eelnevalt ettevalmistatud masinal (LXC konteiner) koos kesta või dokkija-täituriga. Algselt oli meie Gitlabis globaalselt määratletud mitu sellist jooksjat. Nad kogusid kõigi projektide jaoks dokkerite pilte.

Kuid nagu praktika on näidanud, pole see valik kõige ideaalsem nii praktilisuse kui ka ohutuse seisukohalt. Palju parem ja ideoloogiliselt õigem on panna iga projekti või isegi iga keskkonna jaoks eraldi jooksjad.

Õnneks pole see üldse probleem, sest nüüd võtame kasutusele gitlab-jooksja otse meie projekti osana otse Kuberneteses.

Gitlab pakub valmis tüüridiagrammi gitlab-runneri juurutamiseks Kubernetesesse. Nii et kõik, mida pead tegema, on teada saada registreerimismärk meie projekti jaoks Seaded -> CI / CD -> Jooksjad ja anna see roolile:

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

Kui:

  • https://gitlab.com - teie Gitlabi serveri aadress.
  • yga8y-jdCusVDn_t4Wxc — teie projekti registreerimismärk.
  • rbac.create=true — annab jooksjale vajalikul hulgal õigusi, et ta saaks kubernetes-executori abil meie ülesannete täitmiseks luua kaunasid.

Kui kõik on õigesti tehtud, peaksite jaotises nägema registreerunud jooksjat Paremuselt, oma projekti seadetes.

Lisatud jooksja ekraanipilt

Uute tööriistade proovimine Kubernetes juurutamise loomiseks ja automatiseerimiseks

Kas see on nii lihtne? - jah, see on nii lihtne! Enam pole vaja vaeva jooksjate käsitsi registreerimisega, nüüdsest luuakse ja hävitatakse jooksjad automaatselt.

6. Kasutage QBEC-iga Helmi diagramme

Kuna otsustasime kaaluda gitlab-jooksja osa meie projektist, on aeg seda meie Giti hoidlas kirjeldada.

Võiksime seda kirjeldada eraldi komponendina veebisait, kuid tulevikus plaanime juurutada erinevaid koopiaid veebisait väga sageli, erinevalt gitlab-jooksja, mida kasutatakse ainult üks kord Kubernetese klastri kohta. Initsialiseerime selle jaoks eraldi rakenduse:

cd deploy
qbec init gitlab-runner
cd gitlab-runner

Seekord ei kirjelda me Kubernetese üksusi käsitsi, vaid võtame valmis Helmi diagrammi. Üks qbeci eeliseid on võimalus renderdada Helmi diagramme otse Giti hoidlast.

Ühendame selle git alammooduli abil:

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

Nüüd kataloog müüja/gitlab-runner Meil on gitlab-runneri diagrammiga hoidla.

Sarnasel viisil saate ühendada ka teisi hoidlaid, näiteks kogu hoidla ametlike diagrammidega https://github.com/helm/charts

Kirjeldame komponenti komponendid/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,
  }
)

Esimene argument sellele laiendage HelmTemplate siis liigume diagrammi juurde parameetrid.väärtused, mille võtame keskkonna parameetritest, siis tuleb objekt koos

  • nimiMall - väljalaske nimi
  • nimeruum — nimeruum üle tüürile
  • see fail — nõutav parameeter, mis edastab praeguse faili tee
  • paljusõnaline - näitab käsku tüüri mall koos kõigi argumentidega diagrammi renderdamisel

Nüüd kirjeldame meie komponendi parameetreid Environments/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 võtame välisest failist Secrets/base.libsonnet, loome selle:

{
  runnerRegistrationToken: 'yga8y-jdCusVDn_t4Wxc',
}

Kontrollime, kas kõik töötab:

qbec show default

Kui kõik on korras, saame oma varem juurutatud versiooni Helmi kaudu kustutada:

helm uninstall gitlab-runner

ja juurutage see samal viisil, kuid qbeci kaudu:

qbec apply default

7. Sissejuhatus git-crypt

Git-crypt on tööriist, mis võimaldab seadistada oma hoidla jaoks läbipaistvat krüptimist.

Praegu näeb meie gitlab-runneri kataloogistruktuur välja selline:

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

Kuid saladuste talletamine Gitis pole ohutu, eks? Seega peame need korralikult krüpteerima.

Tavaliselt ei ole see ühe muutuja huvides alati mõttekas. Saate edastada saladusi qbec ja teie CI-süsteemi keskkonnamuutujate kaudu.
Kuid väärib märkimist, et on ka keerukamaid projekte, mis võivad sisaldada palju rohkem saladusi, nende kõigi ülekandmine keskkonnamuutujate kaudu on äärmiselt keeruline.

Veelgi enam, sel juhul ei saaks ma teile rääkida sellisest suurepärasest tööriistast nagu git-krüpt.

git-krüpt See on mugav ka selle poolest, et võimaldab salvestada kogu saladuste ajaloo, samuti võrrelda, liita ja lahendada konflikte samamoodi, nagu oleme harjunud Giti puhul tegema.

Esimene asi pärast paigaldamist git-krüpt peame genereerima oma hoidla jaoks võtmed:

git crypt init

Kui teil on PGP-võti, saate end kohe selle projekti kaasautoriks lisada:

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

Nii saate selle hoidla alati oma privaatvõtme abil dekrüpteerida.

Kui teil pole PGP-võtit ja te ei oota seda, võite minna teist teed ja eksportida projektivõtme:

git crypt export-key /path/to/keyfile

Seega igaüks, kellel on eksporditud võtmefail saab teie hoidla dekrüpteerida.

On aeg üles seada meie esimene saladus.
Tuletan meelde, et oleme endiselt kataloogis juurutamine/gitlab-runner/, kus meil on kataloog saladused/, krüpteerime kõik selles olevad failid, selleks loome faili saladused/.gitattributes järgmise sisuga:

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

Nagu sisust näha, on kõik failid maskeeritud * sõidetakse läbi git-krüpt, välja arvatud enamik .gitattributes

Seda saame kontrollida, käivitades:

git crypt status -e

Väljund on kõigi hoidlas olevate failide loend, mille krüpteerimine on lubatud

See on kõik, nüüd saame oma muudatused turvaliselt sisse viia:

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

Hoidla blokeerimiseks käivitage lihtsalt:

git crypt lock

ja kohe muutuvad kõik krüptitud failid binaarseks, neid on võimatu lugeda.
Hoidla dekrüpteerimiseks käivitage:

git crypt unlock

8. Loo tööriistakasti pilt

Tööriistakasti pilt on pilt koos kõigi tööriistadega, mida oma projekti juurutamiseks kasutame. Gitlabi jooksja kasutab seda tüüpiliste juurutusülesannete täitmiseks.

Siin on kõik lihtne, loome uue dockerfiles/tööriistakast/Dockerfile järgmise sisuga:

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

Nagu näete, installime sellel pildil kõik utiliidid, mida kasutasime oma rakenduse juurutamiseks. Meil pole seda siin vaja, välja arvatud juhul kubectl, kuid võiksite sellega torujuhtme seadistamise etapis ringi mängida.

Samuti peame Kubernetesiga suhtlemiseks ja selle juurutamiseks konfigureerima rolli gitlab-runneri genereeritud kaustadele.

Selleks minge gitlab-runneriga kataloogi:

cd deploy/gitlab-runner

ja lisage uus komponent komponendid/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,
      },
    ],
  },
]

Kirjeldame ka uusi parameetreid Environments/base.libsonnet, mis näeb nüüd välja selline:

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 viitab nimi komponendi jaoks rbac

Vaatame, mis on muutunud:

qbec diff default

ja rakendage meie muudatused Kubernetesele:

qbec apply default

Samuti ärge unustage meie muudatusi giti sisse kanda:

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. Meie esimene konveier ja piltide kokkupanek siltide järgi

Projekti juureks loome .gitlab-ci.yml järgmise sisuga:

.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

Pange tähele, et kasutame GIT_SUBMODULE_STRATEGY: tavaline nende tööde jaoks, kus peate alammoodulid enne käivitamist selgesõnaliselt lähtestama.

Ärge unustage teha meie muudatusi:

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

Ma arvan, et võime seda julgelt versiooniks nimetada v0.0.1 ja lisa silt:

git tag v0.0.1

Lisame silte alati, kui peame uue versiooni välja andma. Dockeri piltide sildid seotakse Giti siltidega. Iga uue sildiga tõuge initsialiseerib selle sildiga piltide koostamise.

Teeme seda git push --sildid, ja vaatame oma esimest torujuhet:

Esimese torujuhtme ekraanipilt

Uute tööriistade proovimine Kubernetes juurutamise loomiseks ja automatiseerimiseks

Tasub juhtida tähelepanu asjaolule, et siltide järgi kokkupanek sobib dokkerite kujutiste ehitamiseks, kuid ei sobi rakenduse Kubernetes juurutamiseks. Kuna vanadele sissekannetele saab määrata uusi silte, viib antud juhul nende jaoks konveieri lähtestamine vana versiooni juurutamiseni.

Selle probleemi lahendamiseks seotakse dockeri kujutiste ehitamine tavaliselt siltidega ja rakenduse juurutamine harusse meister, milles kogutud piltide versioonid on kõvakoodiga kodeeritud. Siin saate tagasipööramise lähtestada lihtsa tagasipööramisega meister-oksad.

10. Kasutuselevõtmise automatiseerimine

Selleks, et Gitlab-runner saaks meie saladused dekrüpteerida, peame hoidla võtme eksportima ja lisama selle oma CI keskkonnamuutujatele:

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

Salvestame saadud rea Gitlabi; selleks minge oma projekti seadetesse:
Seadistused -> CI / CD -> Muutujad

Ja loome uue muutuja:

KASUTUSALA
Võti
Väärtus
Kaitstud
Maskitud
Ulatus

File
GITCRYPT_KEY
<your string>
true (koolituse ajal saate false)
true
All environments

Lisatud muutuja ekraanipilt

Uute tööriistade proovimine Kubernetes juurutamise loomiseks ja automatiseerimiseks

Nüüd värskendame oma .gitlab-ci.yml lisades sellele:

.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

Siin oleme qbeci jaoks lubanud mitu uut valikut:

  • -- juurutada mõni/rakendus — võimaldab määrata konkreetse rakenduse kataloogi
  • --force:k8s-context __incluster__ - see on maagiline muutuja, mis ütleb, et juurutamine toimub samas klastris, kus töötab gtilab-runner. See on vajalik, kuna vastasel juhul proovib qbec leida sinu kubeconfigis sobivat Kubernetese serverit
  • -- oota — sunnib qbeci ootama, kuni tema loodud ressursid lähevad valmisolekusse, ja alles siis väljub eduka väljumiskoodiga.
  • — jah - lihtsalt keelab interaktiivse kesta Oled sa kindel? kui kasutusele võetud.

Ärge unustage teha meie muudatusi:

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

Ja pärast git push näeme, kuidas meie rakendused on juurutatud:

Ekraanipilt teisest torujuhtmest

Uute tööriistade proovimine Kubernetes juurutamise loomiseks ja automatiseerimiseks

11. Artefaktid ja kokkupanek meisterdamisel

Tavaliselt piisab ülalkirjeldatud sammudest peaaegu iga mikroteenuse loomiseks ja pakkumiseks, kuid me ei soovi lisada sildi iga kord, kui peame saiti värskendama. Seetõttu valime dünaamilisema marsruudi ja seadistame põhiharus kokkuvõtte juurutamise.

Idee on lihtne: nüüd meie pilt veebisait ehitatakse uuesti iga kord, kui sisenete meisterja seejärel automaatselt juurutada Kubernetesesse.

Värskendame neid kahte töökohta meie .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"

Pange tähele, et oleme lisanud lõime meister к viited töökohtade jaoks build_website ja nüüd kasutame $CI_COMMIT_REF_NAME asemel $CI_COMMIT_TAG, see tähendab, et oleme Gitis siltidest lahti ühendatud ja nüüd lükkame pildi konveieri initsialiseerinud kinnistamisharu nimega. Väärib märkimist, et see töötab ka siltidega, mis võimaldab meil salvestada dokkide registrisse konkreetse versiooniga saidi hetktõmmiseid.

Kui saidi uue versiooni dockeri märgendi nime saab muuta, peame siiski kirjeldama Kubernetese muudatusi, vastasel juhul lihtsalt ei juuruta see rakendust uuelt pildilt ümber, kuna see ei märka juurutamisel muudatusi manifest.

Variant —vm:ext-str digest=”$DIGEST” qbec jaoks – võimaldab edastada välise muutuja jsonnetile. Soovime, et see paigutataks klastris ümber meie rakenduse iga väljalaskega. Me ei saa enam kasutada märgendi nime, mida ei saa nüüd muuta, kuna peame olema seotud pildi konkreetse versiooniga ja käivitama juurutamise, kui see muutub.

Siin aitab meid Kaniko võimalus salvestada kokkuvõtte pilt faili (valik --digest-fail)
Seejärel edastame selle faili ja loeme seda juurutamise ajal.

Värskendame oma parameetreid deploy/website/environments/base.libsonnet mis näeb nüüd välja selline:

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

Valmis, nüüd on kõik kohustused meister lähtestab dockeri kujutise ehitamise veebisaitja seejärel juurutada see Kubernetesesse.

Ärge unustage teha meie muudatusi:

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

Kontrollime hiljem git push peaksime nägema midagi sellist:

Konveieri ekraanipilt kapteni jaoks

Uute tööriistade proovimine Kubernetes juurutamise loomiseks ja automatiseerimiseks

Põhimõtteliselt ei pea me gitlab-runnerit iga tõukega ümber paigutama, välja arvatud juhul, kui selle konfiguratsioonis pole midagi muutunud, parandame selle .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/**/*

muutused võimaldab teil jälgida muutusi juurutamine/gitlab-runner/ ja käivitab meie töö ainult siis, kui neid on

Ärge unustage teha meie muudatusi:

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

git push, see on parem:

Ekraanipilt värskendatud torujuhtmest

Uute tööriistade proovimine Kubernetes juurutamise loomiseks ja automatiseerimiseks

12. Dünaamilised keskkonnad

On aeg mitmekesistada oma torustikku dünaamiliste keskkondadega.

Esiteks värskendame tööd build_website meie .gitlab-ci.yml, eemaldades sellelt ploki ainult, mis sunnib Gitlabi käivitama selle mis tahes haru kohustuste korral:

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/

Seejärel värskendage töökohta juurutamise_veebisait, lisage sinna plokk keskkond:

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"

See võimaldab Gitlabil töö seostada prod keskkond ja kuvage sellele õige link.

Lisame nüüd veel kaks töökohta:

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

Need käivitatakse tõuke korral mis tahes harusse, välja arvatud juht, ja juurutavad saidi eelvaateversiooni.

Näeme qbeci jaoks uut valikut: --rakenduse silt — see võimaldab teil märgistada rakenduse juurutatud versioone ja töötada ainult selle sildi sees; Kubernetesis ressursside loomisel ja hävitamisel töötab qbec ainult nendega.
Nii ei saa me luua iga arvustuse jaoks eraldi keskkonda, vaid lihtsalt sama keskkonda uuesti kasutada.

Siin kasutame ka qbec rakenda ülevaatust, selle asemel qbec rakenda vaikeseadet - see on täpselt hetk, mil proovime kirjeldada meie keskkondade erinevusi (ülevaatus ja vaikimisi):

Lisage läbi keskkond sisse deploy/website/qbec.yaml

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

Siis me kuulutame selle sisse 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

Ja kirjutage üles selle kohandatud parameetrid 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',
    },
  },
}

Vaatame lähemalt ka jobu stop_review, käivitub see siis, kui haru kustutatakse ja et gitlab ei prooviks välja võtta seda kasutatakse GIT_STRATEGY: puudub, hiljem kloonime meister-harutage ja kustutage selle kaudu ülevaade.
See on veidi segane, kuid ma pole veel ilusamat viisi leidnud.
Alternatiivne võimalus oleks paigutada iga arvustus hotelli nimeruumi, mille saab alati täielikult lammutada.

Ärge unustage teha meie muudatusi:

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

git push, git checkout -b test, git push päritolu test, Kontrollima:

Ekraanipilt Gitlabis loodud keskkondadest

Uute tööriistade proovimine Kubernetes juurutamise loomiseks ja automatiseerimiseks

Kas kõik töötab? - suurepärane, kustutage meie testharu: git kassade kapten, git push päritolu: test, kontrollime, kas keskkonna kustutamistööd töötasid vigadeta.

Siinkohal tahaksin kohe selgitada, et iga projekti arendaja võib filiaale luua, ta võib ka muuta .gitlab-ci.yml faili ja juurdepääsu salajastele muutujatele.
Seetõttu on tungivalt soovitatav lubada nende kasutamine ainult kaitstud okste jaoks, näiteks in meistervõi looge iga keskkonna jaoks eraldi muutujate komplekt.

13. Vaadake rakendused üle

Vaadake üle rakendused See on GitLabi funktsioon, mis võimaldab teil igale hoidlas olevale failile lisada nupu, et seda juurutatud keskkonnas kiiresti vaadata.

Nende nuppude kuvamiseks peate looma faili .gitlab/route-map.yml ja kirjeldage selles kõiki teeteisendusi; meie puhul on see väga lihtne:

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

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

Ärge unustage teha meie muudatusi:

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

git pushja kontrollige:

Rakenduse ülevaatamise nupu ekraanipilt

Uute tööriistade proovimine Kubernetes juurutamise loomiseks ja automatiseerimiseks

Töö on tehtud!

Projekti allikad:

Tänan tähelepanu eest, loodan, et teile meeldis Uute tööriistade proovimine Kubernetes juurutamise loomiseks ja automatiseerimiseks

Allikas: www.habr.com

Lisa kommentaar