Tere! Viimase aja jooksul on ilmunud palju ägedaid automatiseerimise tööriistu nii Docker-piltide koostamiseks kui ka Kubernetesesse juurutamiseks. Seetõttu otsustasin katsetada GitLabiga, uurida selle võimalusi ning muidugi seadistada pipeline'i.

Selle töö inspiratsiooniks sai veebileht kubernetes.io, mis genereeritakse allikatest automaatsete kaudu ning iga saadetud pull requesti puhul genereerib robot automaatselt saidi eelvaateversiooni koos teie muudatustega ja pakub seda vaatamiseks linki.

Püüdlesin sarnase protsessi loomise poole nullist, kuid täiesti suunatud GitLab CI-le ning vabadele tööriistadele, mida olen harjunud kasutama rakenduste juurutamiseks Kubernetesesse. Täna jagan ma teiega nende kohta lähemalt.

Artiklis käsitletakse selliseid tööriistu nagu:
Hugo, git-crypt, kaniko, , mida käsitleti põhjalikult eelnevas artiklis. ja GitLab CI-d dünaamiliste keskkondade loomisel.

Sisukord

Tutvumine Hugoga
Dockerfile'i ettevalmistamine
Tutvumine kanikoga
Tutvumine qbeciga
Proovime GitLab-runnereid Kubernetes-executoriga
Helm-kartude juurutamine qbeciga
Tutvumine git-cryptiga
Loome toolbox-pildi
Meie esimesed pipeline ja piltide koostamine siltide kaupa
Juurutamise automatiseerimine
Artefaktid ja koostamine masterisse pushimise korral
Dünaamilised keskkonnad
Review Apps

1. Tutvumine Hugoga

Meie projekti näitena proovime luua dokumentatsiooni avaldamiseks mõeldud saiti, mis on üles ehitatud Hugole. Hugo on staatiline sisu genereerija.

Neile, kes pole staatiliste generaatoritega tuttavad, räägin neist pisut lähemalt. Erinevalt tavapärastest andmebaasi põhistest veebilehtedest ja mingist php-st, mis genereerivad kasutaja päringute korral lehti reaalajas, on staatilised generaatorid korraldatud veidi teisiti. Need võimaldavad võtta lähtefailid, tavaliselt on need Markdown-formaadis failide kogum ja malli määratlused, ning koostada need täielikult valmis veebileheks.

See tähendab, et tulemuseks on kaustastruktuur ja kogum genereeritud HTML-faile, mille saab lihtsalt üles laadida mistahes odavale hostimise teenusele ja saada töötav veebileht.

Hugo saab paigaldada kohalikult ja proovida seda praktikas:

Loodame uue saidi:

hugo new site docs.example.org

Ja ühtlasi git-reposiitori:

cd docs.example.org
git init

Praegu on meie sait puhas ja et midagi sinna ilmuks, peame kõigepealt teema aktiveerima, teema on lihtsalt hulk malle ja määratletud reegleid, mille alusel meie saidi genereeritakse.

Teemana kasutame Learn, mis on minu arvates ideaalne dokumentatsioonilehe jaoks.

Tuleb eraldi tähelepanu pöörata sellele, et me ei pea teema faile oma projekti hoidlas säilitama, selle asemel saame lihtsalt selle ühendamisega kasutada git submodule:

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

Nii jäävad meie hoidlas ainult failid, mis on otseselt seotud meie projektiga, ja ühendatud teema jääb viitena konkreetsele hoidla ja commit'ile, seega saab selle alati originaalallikast välja tõmmata ja mitte kartma ühilduvuse muutusi.

Parandame konfiguratsiooni config.toml:

baseURL = "http://docs.example.org/"
languageCode = "en-us"
title = "Minu dokumentide leht"
theme = "learn"

Juba sellel etapil saame käivitada:

hugo server

Ja aadressil http://localhost:1313/ kontrollida meie just loodud veebilehte, kõik muudatused kataloogis uuendavad automaatselt ka avatud lehte brauseris, väga mugav!

Proovime luua esilehe failis content/_index.md:

# My docs site

## Welcome to the docs!

You will be very smart :-)

Kuvake just loodud lehe ekraanipilt

Veebilehe genereerimiseks piisab, kui käivitada:

hugo

Katalooge sisu public/ ja need saavad olema teie veebileht.
Jah, muide, lisagem see kohe .gitignore:

echo /public > .gitignore

Ärge unustage meie muudatusi commitida:

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

2. Dockerfile valmistamine

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

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

dockerfiles/ — sisaldavad katalooge Dockerfile'ide ja kõike vajalikku meie docker-piltide koostamiseks.
deploy/ — sisaldab katalooge meie rakenduste juurutamiseks Kubernetesesse

Nii loome meie esimese Dockerfile'i teele 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 te näete, Dockerfile sisaldab kahte KUST, see võimalus nimetatakse multi-stage build ja võimaldab välistada lõplikust docker-pildist kõik mittevajalikud elemendid.
Nii sisaldab meie lõplik pilt ainult darkhttpd (kerge HTTP-server) ja public/ — meie staatiliselt genereeritud veebilehe sisu.

Ärge unustage meie muudatusi commitida:

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

3. Tutvumine kanikoga

Docker- kujundaja eestkasutamise otsustasin kasutada kaniko, kuna selle tööks ei ole vaja docker-daemonit, ja kogu kogumise saab teha igasugusel masinal, hoides vahemälu otse registris, vabastades seeläbi vajadusest omada täielikku püsivat salvestust.

Pildi koostamiseks piisab, kui käivitada konteiner kaniko täitja ja edastada talle praegune koostamise kontekst, seda saab teha ka kohalikult, läbi 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

Kus registry.gitlab.com/ kvaps/ docs.example.org/ website — teie docker-pildi nimi, pärast koostamist pushitakse see automaatselt docker-registrisse.

Parameeter —cache võimaldab salvestada kihid docker registrisse, antud näite puhul salvestatakse need registry.gitlab.com/ kvaps/ docs.example.org/ website/ cache, kuid võite määrata ka teise tee parameetriga —cache-repo.

Docker-registri ekraanipilt

4. Qbeci tutvumine

Qbec on deployimise tööriist, mis võimaldab teie rakenduse manifestide deklaratiivset kirjeldamist ja nende käivitamist Kuberneteses. Jsonnet'i kasutamine põhikeelena lihtsustab erinevuste kirjeldamist erinevate keskkondade vahel ning peaaegu täielikult vabastab koodi kordumisest.

See võib olla eriti oluline juhtudel, kui peate rakenduse mitmetesse klastritesse erinevate parameetritega juurutama ja soovite neid Git'is deklaratiivselt kirjeldada.

Qbec võimaldab samuti renderdada Helm-diagramme, edastades neile vajalikud parameetrid, ja hiljem käsitleda neid nagu tavalisi manifeste, sealhulgas saab neile rakendada erinevaid mutatsioone, mis omakorda vabastab ChartMuseum'i kasutamise vajadusest. See tähendab, et saate diagramme hoida ja renderdada otse git's, kus need tõeliselt kuuluvad.

Nagu ma varem ütlesin, hoiame kõik juurutamised kaustas deploy/:

mkdir deploy
cd deploy

Alustame oma esimest rakendust:

qbec init website
cd website

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

.
├── komponendid
├── keskkonnad
│ ├── 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 eest vaike keskkonna ja võtnud serveri aadressi, samuti nimistu meie praegusest kubeconfig'ist.
Nüüd, kui me rakendame Seejärel käivitame exec käsu ja ootame 5000 sekundit, et jätkata jälgimist: keskkonda, rakendab qbec alati ainult määratud Kubernetes-klastrisse ja määratud nimistusse, mis tähendab, et teil ei ole enam vaja kontekste ja nimistusi vahetada, et rakendust käivitada.
Vajadusel saate alati seda faili seadistusi uuendada.

Kõik teie keskkonnad on kirjeldatud qbec.yaml, ning failis params.libsonnet, kus on öeldud, kust tuleb neile parameetrid võtta.

Järgmine näeme kahte katalooge:

components/ — siia salvestatakse kõik manifeste meie rakenduse jaoks, need võivad olla kirjutatud nii jsonnetis kui ka tavalistes yaml-failides
environments/ — siin kirjeldame kõiki muutujaid (parameetreid) meie keskkondade jaoks.

Vaikimisi on meil kaks faili:

environments/base.libsonnet — see sisaldab kõiki keskkondadele ühiseid parameetreid
environments/default.libsonnet — sisaldab ümberdefineeritud parameetreid keskkonna jaoks Seejärel käivitame exec käsu ja ootame 5000 sekundit, et jätkata jälgimist:

Avame nüüd environments/base.libsonnet ja lisame sinna parameetrid meie esimese komponendi jaoks:

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

Loomime 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 kolm Kubernetes-üksust: Deployment, Teenused ja Ingress. Soovi korral oleksime võinud need erinevatesse komponentidesse jagada, kuid sellel etapil piisab meile ka ühest.

Süntaks jsonnet on väga sarnane tavalisest json failist, tegelikult on tavaline json juba kehtiv jsonnet, nii et esialgu võib teid aidata kasutada selliseid veebiteenuseid nagu yaml2json , et konverteerida tuttav yaml json formatiks või, kui teie komponendid ei sisalda mingeid muutujat, siis on need täiesti kirjeldatavad ka tavalise yaml kujul.

Töötades jsonnet Soovitan tungivalt installida teie redigeerijale pistikprogrammi:
Näiteks vimile on olemas pistikprogramm vim-jsonnet, mis sisaldab süntaksikaitset ja käivitab automaatselt jsonnet fmt igal salvestamisel (vajab installitud jsonnet'i).

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

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

qbec show default

Väljastusel näete renderdatud yaml-manifesti, mis rakendatakse default klastrisse.

Suurepärane, nüüd rakendame:

qbec apply default

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

Nüüd on meie rakendus juurutatud!

Muutatuste tegemisel võite alati teha:

qbec diff default

et näha, kuidas need muudatused mõjutavad praegust deploy'd

Ärge unustage meie muudatusi commitida:

cd ..\/..
git add deploy\/website
git commit -m "Lisa deploy veebisaidile"

5. Proovime Gitlab-runnerit Kubernetes-executoriga

Kuni hiljuti kasutasin ainult tavapärast gitlab-runner ettevalmistatud masinas (LXC-konteineris) shell- või docker-executoriga. Alguses oli meil mitu sellist runnerit, mis olid globaalselt määratud meie GitLabis. Need kogusid docker-pilte kõigi projektide jaoks.

Kuid praktika näitas, et see valik ei ole kõige ideaalne, ei praktilisuse ega turvalisuse osas. Oluliselt parem ja ideoloogiliselt õigesti on omada eraldi runner'eid, mis on deploy’dud iga projekti jaoks, kui ka igas keskkonnas.

Õnneks ei ole see probleem, kuna nüüd plaanime deploy'da gitlab-runner otse kui osa meie projektist otse Kubernetesesse.

GitLab pakub valmis helm-chart'i gitlab-runner'i deploy'imiseks Kubernetesesse. Seega on kõik, mida vajate, õppida registreerimise token meie projekti jaoks Settings —> CI \/ CD —> Runners ja edastada see helm'ile:

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 — teie GitLab serveri aadress.
yga8y-jdCusVDn_t4Wxc — registraator token teie projekti jaoks.
rbac.create=true — annab runner'ile vajaliku hulga õigusi, 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 seadistustes.

Kuvatõmmis lisatud runner'ist

Niivõrd lihtne? — jah, nii lihtne! Enam pole mingeid probleemide registreerimisel käsitsi, alates nüüd luuakse ja hävitatakse runner'id automaatselt.

6. Helm-chartide deploy QBEClt

Kuna oleme otsustanud lugeda gitlab-runner oma projekti osaks, on aeg see meie Git-repositooriumis kirja panna.

Me oleksime võinud seda kirjeldada kui eraldi komponenti veebisait, kuid tulevikus plaanime deploy'da erinevaid koopiaid veebisait väga tihti, erinevalt gitlab-runner, mis deploy’dakse vaid üks kord igale Kubernetes'ile. Nii et laseme alustada eraldi rakenduse loomisega:

cd deploy
qbec init gitlab-runner
cd gitlab-runner

Seekord me ei kirjelda Kubernetes'i objekte käsitsi, vaid kasutame valmistehtud Helm chart'i. Üks qbec'i eeliseid on see, et saame renderdada Helm chart'e otse Git-repositooriumist.

Liitume sellega git alamhargiga:

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

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

Sarnasel viisil saab liita ka teisi repositooriume, näiteks kogu repositooriumi ametlikest chart'idest. 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 anname tee chart'ini, seejärel params.values, mis tuleb keskkonnaparameetritest, seejärel tuleb objekt

nameTemplate — versiooni nimi
namespace — nõutav hälve Helm'ile
thisFile — kohustuslik parameter, mis edastab tee praegusele failile
verbose — näitab käsku helm template koos kõigi argumentidega chart'i renderdamisel.

Nüüd kirjeldame meie komponentide 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,
      },
    },
  },
}

Pange tähele runnerRegistrationToken saame välist 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 eemaldada meie varem Helm'i kaudu juurutatud versiooni:

helm uninstall gitlab-runner

ja juurutada sama, aga nüüd qbec'i kaudu:

qbec apply default

7. Tutvumine git-crypt'iga

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

Praegu näeb meie gitlab-runner'i kausta struktuur 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 hoidmine Git'is pole turvaline, eks? Nii et peame need korralikult krüpteerima.

Ühe muutuja puhul ei ole see alati mõistlik. Saate edastada saladusi git-crypt ja ka CI-süsteemid oma keskkonnamuutujate kaudu.
Kuid tasub märkida, et on ka keerulisemaid projekte, mis võivad sisaldada palju rohkem salajasi andmeid, mille edastamine keskkonnamuutujate kaudu oleks äärmiselt keeruline.
Lisaks ei oleks ma sel juhul saanud rääkida teile sellisest suurepärasest tööriistast nagu , mida käsitleti põhjalikult eelnevas artiklis..
, mida käsitleti põhjalikult eelnevas artiklis. on mugav ka selle poolest, et võimaldab salvestada kogu salajaste andmete ajalugu, samuti võrrelda, ühendada ja lahendada konflikte nii nagu me oleme harjunud seda tegema Git'i puhul.

Esimese asjana pärast installimist , mida käsitleti põhjalikult eelnevas artiklis. peame genereerima võtmed meie hoidla jaoks:

git crypt init

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

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

Nii saate alati dekrüpteerida seda hoidlat, kasutades oma privaatvõtit.

Kui aga teil ei ole PGP-võtit ja see ei ole plaanis, siis võite valida teise tee ja eksportida projekti võtme:

git crypt export-key /path/to/keyfile

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

On aeg seadistada meie esimene saladus.
Tuletan meelde, et me oleme endiselt kaustas deploy/gitlab-runner/, kus meil on kaust secrets/, alustame kõigi failide krüpteerimist, selleks loome faili secrets/.gitattributes sellise sisuga:

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

Kuidas näha sisu, kõik failid, mis vastavad mustrile * moodustatakse läbi , mida käsitleti põhjalikult eelnevas artiklis., välja arvatud fail .gitattributes

Saame seda kontrollida, käivitades:

git crypt status -e

Saame väljundis loetelu kõigist hoidla failidest, mille puhul on krüpteerimine lubatud.

See on kõik, nüüd saame julgelt oma muudatusi commitida:

cd ../..
git add .
git commit -m "Lisa deploy gitlab-runner'ile"

Hoidla lukustamiseks piisab, kui käivitada:

git crypt lock

ja kõik krüpteeritud failid muutuvad koheselt binaarseks nähtamatuks, neid ei ole võimalik lugeda.
Hoidla dekrüpteerimiseks käivitage:

git crypt unlock

8. Loome toolbox-pildi

Toolbox-pilt on selline pilt koos kõigi tööriistadega, mida kasutame meie projekti juurutamiseks. Seda kasutab gitlab-runner tüüpiliste juurutuste ülesannete täitmiseks.

Siin on kõik lihtne, loome uue dockerfiles/toolbox/Dockerfile sellise sisuga:

ALUSTADES 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 selles pildis kõik utiliidid, mida kasutasime meie rakenduse juurutamiseks. Me ei vaja siin ainult kubectl, kuid võib-olla soovite sellega mängida toru seadistamise etapis.

Samuti, et suhelda Kubernetesega ja seal juurutada, peame seadistama rolli gitlab-runner'i genereeritud pod'idele.

Selleks liigume gitlab-runner'i 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,
      },
    ],
  },
]

Samuti kirjeldame uusi parameetreid failis environments/base.libsonnet, mis nüüd näeb 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',
    },
  },
}

Pange tähele $.components.rbac.name viitab nimi komponendile rbac

Kontrollime, mis muutunud on:

qbec diff default

ja rakendame meie muudatused Kubernetesesse:

qbec apply default

Ärge unustage ka meie muudatusi git'i salvestada:

cd ../..
git add dockerfiles/toolbox
git commit -m "Lisa Dockerfile tööriistakasti jaoks"
git add deploy/gitlab-runner
git commit -m "Seadista gitlab-runner tööriistakasti kasutamiseks"

9. Meie esimene toru ja piltide ehitamine siltide järgi

Loome projekti juurtas. .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

Pöörake tähelepanu, et me kasutame GIT_SUBMODULE_STRATEGY: normal neid tööde jaoks, kus on vajalik alamsubmodulite selge initsialiseerimine enne täitmist.

Ärge unustage meie muudatusi commitida:

git add .gitlab-ci.yml
git commit -m "Automatiseerige Docker'i koostamine"

Arvan, et seda võib julgelt nimetada versiooniks v0.0.1 ja määrata sildi:

git tag v0.0.1

Sildid määratakse iga kord, kui on vaja vabastada uus versioon. Docker'i piltidele määratud sildid seotakse Git'i siltidega. Iga puhverdamine uue sildiga käivitab selle sildiga seotud piltide koostamise.

Täitke git push —tags, ja vaatame meie esimest pipelinet:

Esimese pipelini ekraanipilt

Märkimisväärne on see, et silte pidi olema hea Docker'i piltide koostamiseks, kuid ei sobi rakenduse paigaldamiseks Kubernetesesse. Kuna uusi silte võib määrata ka vanadele muudatustele, põhjustab nendele algatamine vana versiooni paigaldamist.
Selle probleemi lahendamiseks seotakse tavaliselt Docker'i piltide koostamine siltide, rakenduse paigaldamine aga harudega, mastermilles on kõvasti määratud koostatud piltide versioonid. Just sellsisel juhul suudate algatada tagasiviimise lihtsa tagasivõtmisega master-harule.

10. Paigaldamise automatiseerimine

Et Gitlab-runner suudaks meie saladusi dešifreerida, peame eksportima repositooriumi võtme ja lisama selle meie CI keskkonnamuutujatesse:

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

Saadud stringi salvestame Gitlabi, selleks liikume meie projekti seadete juurde:
Seaded -> CI / CD -> Muutujad

Ja loome uue muutuja:

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

Fail
GITCRYPT_KEY
<your string>
true (õppimise ajaks võib ka false)
true
Kõik keskkonnad

Lisatud muutuja ekraanipilt

Nüüd uuendame meie .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 kasutanud mitmeid uusi valikuid qbec'i jaoks:

—root some/app — võimaldab määrata konkreetse rakenduse kausta
—force:k8s-context __incluster__ — see on maagiline muutuja, mis ütleb, et deploy toimub samas klastris, kus gitlab-runner on käimas. See on vajalik, sest vastasel juhul püüab qbec leida sobivat Kubernetes- serverit teie kubeconfigist
—wait — sunnib qbec'it ootama, kuni loodud ressursid saavad valmis olekusse Ready, ja alles siis lõpetatakse edukalt exit-koodiga.
—yes — lihtsalt keelab interaktiivse shelli Kas oled kindel? deploy'i ajal.

Ärge unustage meie muudatusi commitida:

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

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

Teise pipeline'i ekraanipilt

11. Artefaktid ja ehitamine masterisse push'i ajal

Tavaliselt piisab eespool kirjeldatud sammudest peaaegu igasuguste mikroteenuste ehitamiseks ja tarnimiseks, kuid me ei soovi iga kord, kui peame saiti värskendama, sildistada. Seetõttu valime dünaamilisema lähenemise ja seadistame deploy'i digest'i alusel master haru.

Idee on lihtne: nüüd meie veebisait kujundatakse ümber iga kord, kui push'ime master, ja sonra automaatselt deploy'itakse Kubernetes'sse.

Uuendame nüüd neid kahte 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 aadressile refs the töö jaoks build_website ja nüüd kasutame $CI_COMMIT_REF_NAME asemel $CI_COMMIT_TAG, st eraldame end Git'i siltidest ja nüüd push'ime pildi, mille nimi on commit'i haru nimi, mis käivitas pipeline'i. Tuleb märkida, et see töötab ka siltide puhul, mis võimaldab meil säilitada saidi versiooni kindla versiooniga docker-registry's.

Kui docker-tagi nimi uue saidi versioonile võib muutumatuna jääda, peame ikkagi kirjeldama muudatusi Kuberneteses, vastasel juhul ei redeploy'ita rakendust uue pildiga, kuna muudatusi deploymendi manifestis ei märgita.

Valik —vm:ext-str digest=»$DIGEST» qbeci jaoks — võimaldab välise muutuja edastamist jsonnetis. Tahame, et meie rakenduse iga väljalase redeploy'itaks klastris. Me ei saa nüüd kasutada nime, mis võib jääda muutumatuks, kuna peame siduma konkreetse pildiversiooniga ja käivitama deployment'i, kui see muutub.

Siin aitab meid Kaniko suutlikkus salvestada pildi digesti faili (valik —digest-file)
Seejärel edastame ja loeme selle faili deploymendi hetkel.

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

{
  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 käivitab iga commit master docker-pildi koostamise veebisait, seejärel selle deploy Kubernetese keskkonda.

Ärge unustage meie muudatusi commitida:

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

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

Pipelines'i ekraanipilt masterist

Põhimõtteliselt ei ole meil vaja gitlab-runnerit iga push'i korral redeploy'ida, kui selle konfiguratsioonis midagi ei muutu, 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/**/*

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

Ärge unustage meie muudatusi commitida:

git add .gitlab-ci.yml
git commit -m "Vähenda gitlab-runneri deploy'd"

git push, nii on parem:

Uuendatud pipelines'i ekraanipilt

12. Dünaamilised keskkonnad

On aeg muuta meie pipelines dünaamilisteks keskkondadeks.

Esialgu uuendame töö build_website meie .gitlab-ci.yml, eemaldades sellest ploki only, mis sunnib Gitlab'i seda käivitama igal commit'il igas harus:

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öö deploy_website, lisame sinna ploki 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 siduda töökoha prod keskkonnaga ja kuvada sellele õige lingi.

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 käivitatakse, kui pushitakse mis tahes harudesse välja arvatud master, ja need deployivad saidi eelvaate versiooni.

Näeme uut võimalust qbec jaoks: —app-tag — see võimaldab märgistada deployitud rakenduse versioone ja töötada ainult selle märgise piires, Kuberneteses ressursside loomisel ja hävitamisel juhib qbec ainult neid.
Nii saame mitte luua eraldi keskkonda iga eelvaate jaoks, vaid lihtsalt kasutada sama.

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

Lisame ülevaate keskkonna deploy/website/qbec.yaml

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

Siis deklareerime 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 'environment ' + env + ' not defined in ' + std.thisFile

Ja kirjutame kohandatud parameetrid selle jaoks 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 on aktiveeritud haru kustutamisel ja et gitlab ei prooviks sellele checkouti teha, kasutatakse GIT_STRATEGY: none, hiljem kloonime master-okto ja kustutame arvustuse selle kaudu.
Veidi keeruline, kuid ma pole leidnud ilusamat viisi.
Alternatiivne variant võiks olla iga arvustuse suvandite eraldi nimelisse ruumi juurutamine, mille saab alati täielikult eemaldada.

Ärge unustage meie muudatusi commitida:

git add .
git commit -m "Luba automaatne arvustus"

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

Ekraanipilt loodud keskkondadest Gitlabis

Kas see töötab? — suurepärane, kustutame meie testimise haru: git checkout master, git push origin :test, kontrollime, et keskkonna kustutamise tööd töötasid ilma vigadeta.

Siin on kohe paslik täpsustada, et harude loomisega võib tegeleda iga arendaja projektis, ta võib ka muuta .gitlab-ci.yml faili ja saada juurdepääsu salajastele muutujaile.
Seetõttu on tungivalt soovitatav lubada nende kasutamine ainult kaitstud harude jaoks, näiteks master, või luua eraldi muutuja komplekt iga keskkonna jaoks.

13. Arvustuse rakendused

Review Apps see on selline Gitlabi võimalus, mis võimaldab iga faili repositooriumis lisada nupu selle kiireks vaatamiseks juurutatud keskkonnas.

Selleks, et need nupud ilmuksid, tuleb luua fail .gitlab/route-map.yml ja kirjeldada seal kõiki teepöördeid, meie puhul on see väga lihtne:

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

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

Ärge unustage meie muudatusi commitida:

git add .gitlab/
git commit -m "Luba arvustuse rakendused"

git push, ja kontrollime:

Ekraanipilt Review App nupust

Töö on tehtud!

Projekti lähtekoodid:

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

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

Allikas: habr.com

Katsetame uusi tööriistu Kubernetes'i kokkupanemiseks ja automaatimiseks

Sisukord

1. Tutvumine Hugoga

2. Dockerfile valmistamine

3. Tutvumine kanikoga

4. Qbeci tutvumine

5. Proovime Gitlab-runnerit Kubernetes-executoriga

6. Helm-chartide deploy QBEClt

7. Tutvumine git-crypt'iga

8. Loome toolbox-pildi

9. Meie esimene toru ja piltide ehitamine siltide järgi

10. Paigaldamise automatiseerimine

11. Artefaktid ja ehitamine masterisse push'i ajal

12. Dünaamilised keskkonnad

13. Arvustuse rakendused

Töö on tehtud!