Tere! Viimasel ajal on ilmunud palju toredaid automatiseerimistööriistu nii Docker-piltide ehitamiseks kui ka Kubernetesesse juurutamiseks. Seetõttu otsustasin mängida GitLabiga, uurida selle võimalusi ning muidugi seadistada pipeline'i.

Selle töö inspiratsiooniks oli veebisait kubernetes.io, mis genereeritakse allikakoodidest automaatset, ning iga saadetud pull request'i puhul genereerib robot automaatselt saidi eelvaate versiooni koos sinu muudatustega ja pakub linki vaatamiseks.

Olen püüdnud ehitada sarnast protsessi nullist, kuid täielikult GitLab CI-l ja vaba tarkvaraga, mida olen harjunud kasutama rakenduste juurutamiseks Kubernetesesse. Täna räägin nendest täpsemalt.

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

Sisukord

Tutvus Hugo'ga
Dockerfile'i ettevalmistamine
Tutvus kaniko'ga
Tutvus qbec'iga
Proovime GitLab-runnery Kubernetes-executor'iga
Helm-chartide juurutamine qbec'iga
Tutvus git-crypt'iga
Loome toolbox-pildi
Meie esimene pipeline ja piltide kogumine sildide järgi
Automatiseerimine
Tegevused ja kogumine masterisse push'imisel
Dünaamilised keskkonnad
Ülevaate rakendused

1. Tutvumine Hugo'ga

Kuna näidisena proovime luua dokumentatsiooni avaldamiseks mõeldud veebilehte, mis on loodud Hugo'ga. Hugo on staatiline sisugeneraator.

Kellele staatilised generaatorid ei ole tuttavad, siis natuke täiendavat teavet. Erinevalt tavalistest veebimootoritest, millel on andmebaas ja PHP, mis genereerivad lehti jooksvalt, töötavad staatilised generaatorid veidi teisiti. Need võimaldavad võtta lähtekoodid, tavaliselt on need komplekt Markdown-formaadis faile ja teemasid, ning seejärel koostada need täiesti valmis veebileheks.

Seega saad veebilehe, millel on kaustastruktuur ja komplekt genereeritud HTML-faile, mida saab lihtsalt üles laadida igale odavale hostimisele ja saada toimiv veebileht.

Hugo saab paigaldada kohapeal ja proovida seda kasutada:

Algatame uue veebilehe:

hugo new site docs.example.org

Ja samal ajal git-reposiitoriumi:

cd docs.example.org
git init

Praegu on meie veebisait puhtalt tühi ning enne, kui sinna midagi lisada, peame kõigepealt teema aktiveerima. Teema on lihtsalt mallide ja määratud reeglite kogum, mille järgi meie veebisait genereeritakse.

Teemana kasutame Learn, mis minu arvates sobib dokumentatsiooni saidile nagu valatult.

Erilist tähelepanu väärib see, et me ei pea teema faile oma projekti hoidlas hoidma; selle asemel saame selle lihtsalt aktiveerida, kasutades git submodule:

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

Nii on meie hoidlas ainult need failid, mis on otseselt seotud meie projektiga, ja aktiveeritud teema jääb viidatud konkreetse hoidla ja commit'ina, mille kaudu saab selle alati originaallähte taastada ilma ühilduvusprobleemide kartmata.

Parandame konfiguratsiooni config.toml:

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

Juba sellel etapil saab käivitada:

hugo server

Ja aadressil http://localhost:1313/ kontrollige meie just loodud veebisaiti, kõik kaustas tehtud muudatused uuendavad automaatselt avatud lehte brauseris, väga mugav!

Proovime luua peamist lehte content/_index.md:

# My docs site

## Welcome to the docs!

You will be very smart :-)

Ekraanipilt just loodud lehe kohta

Veebisaidi genereerimiseks piisab, kui käivitada:

hugo

Kausta sisaldus public/ ja sellest saab teie veebisait.
Jah, muide, lisame selle kohe .gitignore:

echo /public > .gitignore

Ärge unustage oma muudatusi commit'ida:

git add .
git commit -m "Uus sait loodud"

2. Dockerfile'i ettevalmistamine

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

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

dockerfiles/ — sisaldab kaustu Dockerfile'idega ja kõik vajalikud meie docker-piltide koostamiseks.
deploy/ — sisaldab kaustu meie rakenduste juurutamiseks Kubernetesesse.

Nii loome meie esimese Dockerfile'i teel 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" ]

Kuidas näha, Dockerfile sisaldab kahte FROM, seda võimalust nimetatakse multi-stage build ja võimaldab välistada lõpp-dockerpildist kõik vajalikud.
Nii et lõpppilt sisaldab ainult darkhttpd (kergekaaluline HTTP-server) ja public/ — sisu meie staatiliselt genereeritud saidilt.

Ärge unustage oma muudatusi commit'ida:

git add dockerfiles/website
git commit -m "Lisa Dockerfile veebisaidi jaoks"

3. Tutvumine kanikoga

Dockerpiltide koostamiseks otsustasin kasutada kaniko, kuna selle toimimiseks ei ole vajalik docker-daemon ning koostamise saab teostada mis tahes masinal, salvestades vahemälu otse registrisse, vabastades seeläbi vajadusest omada täisfunktsionaalset püsivaru.

Pildi koostamiseks piisab konteineri käivitamisest kaniko executor ja edastada sellele praegune koostamise kontekst, seda saab teha ka lokaalsetelt, kasutades dockerit:

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 dockerpildi nimi, pärast koostamist saadetakse see automaatselt docker-registrisse.

Parameeter —cache aitab kuvada kihtide vahemälu docker registry-s, antud näite puhul salvestatakse need registry.gitlab.com/kvaps/docs.example.org/website/cache, kuid saate määrata ka teise tee parameetri kaudu —cache-repo.

Kuvamine docker-registry's

4. Ülevaade qbec'ist

Qbec on rakenduse manifeste deklareeriv tööriist, mis võimaldab neid deploida Kubernetesesse. Jsonnet'i kasutamine peamise süntaksina lihtsustab väga palju erinevuste kirjeldamist erinevate keskkondade vahel ning peaaegu täielikult kõrvaldab koodi korduvuse.

See on eriti asjakohane olukordades, kus peate rakendust deploima mitmesse klastrisse erinevate seadistustega ja soovite neid deklareerivalt Git'is kirjeldada.

Qbec võimaldab ka Helm-i graafikute renderdamist, edastades neile vajalikud parameetrid ja seejärel töötades nendega nagu tavaliste manfestidega, sealhulgas saab neile rakendada erinevaid mutatsioone, mis omakorda võimaldab vältida ChartMuseum'i kasutamist. St graafikuid saab salvestada ja renderdada otse git'ist, kus need ka tegelikult peaksid olema.

Nagu ma varem ütlesin, salvestame kõik deployd kausta deploy/:

mkdir deploy
cd deploy

Alustame meie esimest rakendust:

qbec init website
cd website

Praegu näeb meie rakenduse struktuur välja nii:

.
├── 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 meie eest loonud default keskkonna ja võtnud serveri aadressi ning namespace'i meie praegusest kubeconfig'ist.
Nüüd deployimisel default keskkonda, deployib qbec alati ainult määratud Kubernetes-klastrisse ja määratud nimeteekonda, mis tähendab, et te ei pea enam kontekste ja nimeteeke vahetama, et teha deploy.
Vajadusel saate alati selle faili seadeid värskendada.

Kõik teie keskkonnad on kirjeldatud qbec.yaml, ja failis params.libsonnet, kus on kirjas, kust võtta nende jaoks parameetrid.

Edasi näeme kahte kausta:

components/ — siia salvestatakse kõik meie rakenduse manifestid, need võivad olla kirjeldatud nii jsonnet'i kui ka tavapäraste yaml-failidena
keskkonnad/ — siin kirjeldame kõiki meie keskkondade muutujaid (parameetreid).

Vaikimisi on meil kaks faili:

keskkonnad/base.libsonnet — see sisaldab kõiki ühiseid parameetreid kõikidele keskkondadele
keskkonnad/default.libsonnet — sisaldab keskkonnale ülekirjutatud parameetreid default

Avame nüüd keskkonnad/base.libsonnet ja lisame sinna parameetrid meie esimesesele komponendile:

{
  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 meie esimese komponendi 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,
                },
              },
            ],
          },
        },
      ],
    },
  },
]

Selles failis oleme kirjeldanud kolme Kubernetes'i elementi: Deployment, Teenused ja Ingress. Soovi korral saaksime need välja tuua erinevatesse komponente, kuid praegusel etapil piisab meile ühest.

Süntaks jsonnet on väga sarnane tavalisele json'ile, tegelikult on tavaline json juba kehtiv jsonnet, nii et alguses võib teil olla lihtsam kasutada veebiteenuseid nagu yaml2json et konvertida teile tuttav yaml json-ks, või kui teie komponendid ei sisalda mingeid muutujaid, siis saab need täiesti hästi kirjeldada tavalise yaml-ina.

Töötades jsonnet soovitan tungivalt installida oma tekstiredaktorisse lisa
Näiteks vim'i jaoks on olemas lisa vim-jsonnet, mis sisaldab süntaksi esitlemist ja automaatselt käivitab jsonnet fmt iga salvestamise korral (nõuab installitud jsonnet'i).

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

Et näha, mida oleme saavutanud, teeme järgmist:

qbec show default

Väljundis näete renderdatud yaml-manifestid, mis rakendatakse default klastris.

Suurepärane, nüüd rakendame:

qbec apply default

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

Nüüd on meie rakendus edukalt juurutatud!

Muutuste korral saate alati esitada:

qbec diff default

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

Ärge unustage oma muudatusi commit'ida:

cd ../..
git add deploy/website
git commit -m "Lisa juurutus veebilehele"

5. Proovime Gitlab-runnerit Kubernetes-executoriga

Kuni hiljuti kasutasin ainult tavalist gitlab-runner eelnevalt ettevalmistatud masinas (LXC konteineris) shell- või docker-executoriga. Esiteks oli meil mõned sellised runnerid, mis olid globaalselt määratletud meie GitLabis. Nad kogusid docker-pilte kõikidele projektidele.

Kuid nagu praktika näitas — see variant ei ole kõige ideaalne, nii praktilisuse kui ka turvalisuse osas. Oluliselt parem ja ideoloogiliselt õigem on omada eraldi runnerid, mis on juurutatud iga projekti jaoks, või isegi iga keskkonna jaoks.

Õnneks ei ole see probleem, kuna nüüd juurutame gitlab-runner otseselt osana meie projektist otse Kubernetesesse.

Gitlab pakub valmis helm-charti gitlab-runneri juurutamiseks Kubernetesesse. Seega on kõik, mis teil on vaja, teada registreerimise token meie projekti jaoks Seaded —> CI / CD —> Runners ja edastada see helm:

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

Kus:

https://gitlab.com — sinu Gitlab-serveri aadress.
yga8y-jdCusVDn_t4Wxc — registreerimise token teie projekti jaoks.
rbac.create=true — annab runner'ile vajalikud õigused, et luua pod'e meie ülesannete täitmiseks kubernetes-executor'i abil.

Kui kõik on õigesti tehtud, peaksite nägema registreeritud runner'it jaotises Runners, teie projekti seadetes.

Ekraanipilt lisatud runner'ist

Kas see on tõesti nii lihtne? — jah, see on tõesti nii lihtne! Ei mingit vaeva runner'ite käsitsi registreerimisega, alates nüüd luuakse ja hävitatakse runner'id automaatselt.

6. Helm charte QBEC'iga.

Kuna oleme otsustanud pidada gitlab-runner osaks meie projektist, on aeg kirjeldada seda meie Git-repositoris.

Saaksime seda kirjeldada kui eraldi komponenti website, kuid tulevikus plaanime erinevaid koopiaid väga tihti käivitada, erinevalt website , mis paigaldatakse vaid üks kord iga Kubernetes'i klastri jaoks. Nii et alustame eraldi rakenduse seadistamist: gitlab-runnercd deploy qbec init gitlab-runner cd gitlab-runner

cd deploy
qbec init gitlab-runner
cd gitlab-runner

Seekord ei kirjelda me Kubernetes'e objekte käsitsi, vaid kasutame valmis Helm'i chart'i. Üks qbec'i eeliseid on võimalus renderdada Helm'i chart'e otse Git'i repoitooriumist.

Lisame selle git submodule'i abil:

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

Nüüd kaust vendor/gitlab-runner sisaldab meie jaoks repoitooriumit GitLab Runner'i chart'iga.

Sarnasel viisil saab lisada ka teisi repoitooriume, näiteks ametlikud chart'id tervikuna. https://github.com/helm/charts

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

Esimese argumendina expandHelmTemplate edastame tee chart'ini, seejärel params.values, mille võtame keskkonna parameetritest, seejärel tuleb objekt, mis sisaldab

nameTemplate — väljaande nimi
namespace — helm'ile edastatav nimetand.
thisFile — kohustuslik parameeter, mis edastab tee praegusele failile.
verbose — näitab käsu helm template kõikide argumentidega chart'i renderdades.

Kirjeldame nüüd meie komponendi parameetreid. keskkonnad/base.libsonnet:

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

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

Pange tähele runnerRegistrationToken me 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, siis saame eemaldada meie eelneva Helmiga väljastatud välja:

helm uninstall gitlab-runner

ja väljastada selle uuesti, aga juba qbec'i kaudu:

qbec apply default

7. Tutvumine git-cryptiga

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

Praegu näeb meie gitlab-runner'i kaustastruktuur välja järgmiselt:

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

Aga salajaste hoidmine Git'is ei ole ohutu, eks? Nii et peame need korralikult krüpteerima.

Tavaliselt ei pruugi ühe muutuja jaoks see alati mõtet omada. Võite edastada saladusi qbec ja läbi teie CI-süsteemi keskkonnaväli.
Kuid tasub märkida, et on ka keerulisemaid projekte, mis võivad sisaldada palju rohkem saladusi; nende edastamine keskkonnamuutujate kaudu oleks äärmiselt keeruline.
Lisaks ei oleks mul sel juhul võimalik rääkida teile nii suurepärasest tööriistast nagu git-crypt.
git-crypt on samuti mugav, kuna see võimaldab säilitada kogu saladuste ajalugu, samuti võrrelda, ühendada ja lahendada konflikte just nagu me oleme harjunud seda tegema Gitiga.

Esimese asjana pärast installimist git-crypt peame genereerima võtmed meie hoidla jaoks:

git crypt init

Kui teil on PGP-võti, saate kohe lisada ennast koostööpartneriks selle projekti jaoks:

git-crypt add-gpg-user kvapss@gmail.com

Nii et saate alati selle hoidla dekrüpteerida, kasutades oma privaatvõtit.

Kui aga teil pole PGP-võtit ja ei näe seda ka tulevikus, siis võite minna teist teed ja eksportida projekti võtme:

git crypt export-key /path/to/keyfile

Nii et igaüks, kellel on eksporditud keyfile suudab teie hoidla dekrüpteerida.

On aeg seadistada meie esimene saladus.
Tuletan meelde, et oleme jätkuvalt kaustas deploy/gitlab-runner/, kus meil on direktorium secrets/, krüpteerime kõik failid selles, loome faili secrets/.gitattributes sellise sisuga:

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

Nagu näha on, kõik failid mustri järgi * kullakse läbi git-crypt, välja arvatud .gitattributes

Seda saame kontrollida käivitades:

git crypt status -e

Väljundina saame loetelu kõigist failidest repos, mille jaoks krüptimine on sisse lülitatud

Ja kõik, nüüd saame julgelt oma muudatused commida:

cd ../..
git add .
git commit -m "Lisa deploy gitlab-runnerile"

Repo lukustamiseks piisab, kui käivitada:

git crypt lock

ja hetkega muutuvad kõik krüpteeritud failid binaarseks millekski, nende lugemine on võimatu.
Repo dekrüpteerimiseks käivitage:

git crypt unlock

8. Loome toolbox-pildi

Toolbox-pilt on selline pilt kõigi tööriistadega, mida kasutame meie projekti juurutamiseks. Seda kasutab gitlab-runner tavaliste juurutamiste tööde täitmiseks.

Siin on kõik lihtne, loome uue dockerfiles/toolbox/Dockerfile sellise 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 võite märgata, installime selles pildis kõik utiliidid, mida kasutasime oma rakenduse juurutamiseks. Me ei vaja siin midagi muud, kubectl, kuid võib-olla soovite sellega mängida toru seadistamise etapis.

Samuti, et saaksime suhelda Kubernetesega ja teha juurutusi, peame seadistama rolli gitlab-runneri genereeritud podidele.

Selleks liigume gitlab-runneri katalooge:

cd deploy/gitlab-runner

ja lisame uue komponendi components/rbac.jsonnet:

local env = {
  name: std.extVar('qbec.io/env'),
  namespace: std.extVar('qbec.io/defaultNs'),
};
local p = import '../params.libsonnet';
local params = p.components.rbac;

[
  {
    apiVersion: 'v1',
    kind: 'ServiceAccount',
    metadata: {
      labels: {
        app: params.name,
      },
      name: params.name,
    },
  },
  {
    apiVersion: 'rbac.authorization.k8s.io/v1',
    kind: 'Role',
    metadata: {
      labels: {
        app: params.name,
      },
      name: params.name,
    },
    rules: [
      {
        apiGroups: [
          '*',
        ],
        resources: [
          '*',
        ],
        verbs: [
          '*',
        ],
      },
    ],
  },
  {
    apiVersion: 'rbac.authorization.k8s.io/v1',
    kind: 'RoleBinding',
    metadata: {
      labels: {
        app: params.name,
      },
      name: params.name,
    },
    roleRef: {
      apiGroup: 'rbac.authorization.k8s.io',
      kind: 'Role',
      name: params.name,
    },
    subjects: [
      {
        kind: 'ServiceAccount',
        name: params.name,
        namespace: env.namespace,
      },
    ],
  },
]

Samas kirjeldame uusi parameetreid keskkonnad/base.libsonnet, mis nüüd näeb välja nii:

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

Pange tähele $.components.rbac.name viitab name komponendi rbac

Kontrollime, mis on muutunud:

qbec diff default

ja rakendame meie muudatused Kuberneteses:

qbec apply default

Ärge unustage oma muudatusi git-is commida:

cd ../..
git add dockerfiles/toolbox
git commit -m "Lisa Dockerfile toolbox'ile"
git add deploy/gitlab-runner
git commit -m "Konfigureeri gitlab-runner kasutama toolbox'i"

9. Meie esimene pipeline ja image'ide koostamine sildiga

Projekti juures loome .gitlab-ci.yml sellise 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: normal tööde jaoks, kus tuleb selgelt alustada alamsubmodule enne täitmist.

Ärge unustage oma muudatusi commit'ida:

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

Mõtleks, et seda võib julgelt nimetada versiooniks v0.0.1 ja lisada silt:

git tag v0.0.1

Me märkige iga kord, kui peame välja andma uue versiooni. Docker-piltide sildid seotakse Git-siltidega. Iga uus silt, mis pushitakse, käivitab nende siltidega piltide koostamise.

Täidame git push —tags, ja vaatame meie esimest torujuhet:

Esimese torujuhe ekraanipilt

Oluline on märkida, et siltide koostamine sobib docker-piltide loomiseks, kuid ei sobi rakenduse juurutamiseks Kuberneteses. Kuna uusi silte võib määrata ka vanadele commit'idele, siis nende jaoks torujuhtme käivitamine tooks kaasa vana versiooni juurutamise.
Selle probleemi lahendamiseks seotakse tavaliselt docker-piltide koostamine silte ja rakenduse juurutamine harudega master, kus on kõvakettale kirjutatud koostatud piltide versioonid. Just sel juhul saate tagasi pöörduda lihtsa revert master-haru.

10. Juurutamise automatiseerimine

Kuna Gitlab-runner peab meie salajaseid võtmeid dekodeerima, peame eksportima hoidla võtme ja lisama selle meie CI keskkonnamuutujatesse:

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

salvestame saadud stringi Gitlabi, selleks läheme oma projekti seadistusse:
Seaded —> CI / CD —> Muutujad

Ja loome uue muutuja:

Tüüp
Avaõigus
Väärtus
Kaitstud
Maskeeritud
Ulatus

File
GITCRYPT_KEY
<teie string>
true (õpetamise ajaks võib ka false)
true
Kõik keskkonnad

Lisatud muutuja ekraanipilt

Nüüd uuendame meie .gitlab-ci.yml lisades sinna:

.deploy_qbec_app:
  etapp: turuletoomine
  ainult:
    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 kasutanud mitmeid uusi valikuid qbec jaoks:

—root some/app — võimaldab määrata konkreetse rakenduse kausta
—force:k8s-context __incluster__ — see on maagiline muutuj, mis ütleb, et juurutamine toimub samas klastris, kus gitlab-runner töötab. Seda on vaja teha, kuna muidu üritab qbec leida sobivat Kubernetes serverit teie kubeconfig'ist
—wait — sunnib qbec ootama, kuni loodud ressursid on seisundis Ready, ja lõpetab alles siis edukalt.
—yes — lihtsalt väljalülitab interaktiivse shelli Kas olete kindel? juurutamisel.

Ärge unustage oma muudatusi commit'ida:

git add .gitlab-ci.yml
git commit -m "Automatiseeri juurutamine"

Ja pärast git push näeme, kuidas meie rakendused on üles seatud:

Teise voolu ekraanipilt

11. Aine ja kogumine masterisse push'imisel

Tavaliselt piisab ülaltoodud sammudest peaaegu igasuguse mikroteenuse kogumiseks ja tarnimiseks, kuid me ei soovi iga kord, kui me peame veebilehte uuendama, sildiga ära märgata. Seetõttu liigume dünaamilisema meetodi poole ja seadistame juurutamise digest'i alusel master harus.

Idee on lihtne: nüüd meie website pildid koostatakse iga kord, kui push'ime master, ja seejärel juurutatakse automaatselt Kubernetesesse.

Uuendame need kaks tööd 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 haru master kellele refs tööle build_website ja me nüüd kasutame $CI_COMMIT_REF_NAME asetatakse $CI_COMMIT_TAG, see me vabastame end Git'i siltidest ja hakkame nüüd sunnima pilti, mille nimi on commit-i haru, mis algatab toru. Tasub märkida, et see töötab ka siltidega, mis võimaldab meil salvestada saidi hetkeseise, millel on konkreetne versioon docker-registry's.

Kui uue saidi versiooni docker-sildi nimi võib olla muutumatu, peame siiski muutustele kirjeldama Kuberneteses, vastasel juhul ei deploy'ita rakendust lihtsalt uue pildiga, kuna see ei märka manifestis mingeid muudatusi.

Valik —vm:ext-str digest=»$DIGEST» qbec'i jaoks — võimaldab edastada välist muutuja jsonnet'isse. Tahame, et iga rakenduse väljaande korral see uuesti deploy'itaks klastrisse. Nüüd ei saa me kasutada sildi nime, mis võib olla muutumatu, kuna peame seonduma kindla pildiversiooniga ja käivitama deploy, kui see muutub.

Siin aitab meid Kaniko võimalus salvestada pildi digest faili (valik —digest-file)
Seejärel edastame selle faili ja loeme selle deploy hetkeks.

Uuendame parameetreid meie deploy/website/environments/base.libsonnet mis nüüd näeb välja nii:

{
  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 igasugune commiit master käivitab docker-pildi koostamise website, seejärel selle juurutamise Kubernetesesse.

Ärge unustage oma muudatusi commit'ida:

git add .
git commit -m "Konfigureeri dünaamiline koostamine"

Kontrollime, pärast git push peaksime nägema midagi sellist:

Masteri pipeline'i ekraanipilt

Põhimõtteliselt ei ole meil vajadust gitlab-runnerit iga push'i korral uuesti juurutada, kui, muidugi, selle konfiguratsioonis ei ole midagi muutunud, parandame seda .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/**/*

changes aitab jälgida muudatusi deploy/gitlab-runner/ ja see käivitab meie töö ainult siis, kui selliseid on

Ärge unustage oma muudatusi commit'ida:

git add .gitlab-ci.yml
git commit -m "Vähenda gitlab-runneri juurutust"

git push, nii et see on parem:

Uuendatud pipeline'i ekraanipilt

12. Dünaamilised keskkonnad

On aeg rikastada meie pipeline'i dünaamiliste keskkondadega.

Alustame töö uuendamisega build_website meie .gitlab-ci.yml, eemaldades sellest ploki only, mis see paneb Gitlabi käivitama seda igasuguste commit'idega igasugustele harudele:

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 uuendame tööd deploy_website, lisame sinna ploki environment:

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 siduda töö prod keskkonnaga ja kuvada sellele õige viit.

Nüüd lisame veel kaks tööd:

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 run when pushing to any branches except master and will deploy a preview version of the website.

We see a new option for qbec: —app-tag — it allows tagging the deployed versions of the application and operating only within that tag; when creating and destroying resources in Kubernetes, qbec will only work with those.
Nii saame luua eraldi keskkonnas iga ülevaate jaoks, vaid lihtsalt kasutada ühte ja sama.

Siin kasutame samuti qbec rakenda ülevaade, selle asemel qbec apply default — see on just see hetk, mil püüame kirjeldada erinevusi meie keskkondade (ülevaade ja vaike) vahel:

Lisame ülevaate keskkond deploy/website/qbec.yaml

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

Seejärel kuulutame selle 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 'keskkond ' + env + ' pole määratud ' + std.thisFile

Ja salvestame selle jaoks 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',
    },
  },
}

Vaadakem tähelepanelikumalt tööd stop_review, see käivitub filiaali kustutamisel ja et gitlab ei prooviks selle peale checkouti, kasutatakse GIT_STRATEGY: none, hiljem kloonime master-filiaali ja kustutame ülevaate selle kaudu.
Natuke keeruline, aga ma pole leidnud ilusamat viisi.
Alternatiivne variant võib olla iga ülevaate juurutamine eraldi nimiruumis, mille saab alati täielikult kustutada.

Ärge unustage oma muudatusi commit'ida:

git add .
git commit -m "Lülita sisse automaatne ülevaade"

git push, git checkout -b test, git push origin test, kontrollime:

Gitlabis loodud keskkondade ekraanipilt

Kas kõik töötab? — suurepärane, kustutame meie testiharuna: git checkout master, git push origin :test, veendume, et keskkonna kustutamise tööd on möödunud ilma vigadeta.

Siin on oluline märkida, et harude loomine on lubatud igale arendajale projekti raames, ta võib ka muuta .gitlab-ci.yml faili ja pääseda ligi salajastele muutujatele.
Seega on tungivalt soovitatav lubada nende kasutamine ainult kaitstud harude jaoks, näiteks master, või luua igas keskkonnas eraldi muutujate komplekt.

13. Review Apps

Ülevaate rakendused see on GitLabi võimalus, mis võimaldab igale failile repo'tes lisada nupu kiireks eelvaateks rakenduste keskkonnas.

Kuna need nupud ilmuvad, tuleb luua fail .gitlab/route-map.yml ja määratleda selles kõik teede transformatsioonid, meie puhul on see väga lihtne:

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

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

Ärge unustage oma muudatusi commit'ida:

git add .gitlab/
git commit -m "Aktiveeri ülevaatamisrakendused"

git push, ja kontrollime:

Review App nupu ekraanipilt

Töö on tehtud!

Projekti allikad:

Gitlabis: https://gitlab.com/kvaps/docs.example.org
GitHubis: https://github.com/kvaps/docs.example.org

Aitäh tähelepanu eest, loodan, et teile meeldis

Allikas: habr.com

Proovime uusi tööriistu Kuberneteses ehitamiseks ja automatiseerimiseks

Sisukord

1. Tutvumine Hugo'ga

2. Dockerfile'i ettevalmistamine

3. Tutvumine kanikoga

4. Ülevaade qbec'ist

5. Proovime Gitlab-runnerit Kubernetes-executoriga

6. Helm charte QBEC'iga.

7. Tutvumine git-cryptiga

8. Loome toolbox-pildi

9. Meie esimene pipeline ja image'ide koostamine sildiga

10. Juurutamise automatiseerimine

11. Aine ja kogumine masterisse push'imisel

12. Dünaamilised keskkonnad

13. Review Apps

Töö on tehtud!