Helló! A közelmúltban számos nagyszerű automatizálási eszköz jelent meg mind a Docker-képképek készítéséhez, mind a Kubernetes-be való telepítéshez. Ezzel kapcsolatban úgy döntöttem, hogy eljátszom a GitLabot, alaposan megvizsgálom a képességeit, és természetesen felállítom a folyamatot.

Ezt a munkát a weboldal ihlette kubernetes.io, amelyből generálódik forráskódok automatikusan, és minden egyes elküldött készletkéréshez a robot automatikusan létrehozza a webhely előnézeti verzióját az Ön módosításaival, és egy hivatkozást biztosít a megtekintéshez.

Megpróbáltam a semmiből felépíteni egy hasonló folyamatot, de teljes egészében a Gitlab CI-re és az ingyenes eszközökre építettem, amelyeket az alkalmazások Kubernetes rendszerbe való telepítéséhez szoktam használni. Ma végre többet mesélek róluk.

A cikk olyan eszközöket tárgyal, mint például:
Hugo, qbec, kaniko, git-crypt и GitLab CI dinamikus környezetek kialakításával.

Tartalom

1. Találkozz Hugoval
2. A Dockerfile előkészítése
3. Kaniko megismerése
4. A qbec megismerése
5. A Gitlab-runner kipróbálása Kubernetes-végrehajtóval
6. Helm diagramok telepítése qbec segítségével
7. Bemutatkozik a git-crypt
8. Eszköztár-kép készítése
9. Első folyamatunk és képek összeállítása címkék alapján
10. Telepítési automatizálás
11. Műtermékek és összeszerelés a masterre tolásakor
12. Dinamikus környezetek
13. Tekintse át az alkalmazásokat

1. Hugó megismerése

Projektünk példájaként megpróbálunk létrehozni egy Hugo-ra épített dokumentációs publikációs oldalt. A Hugo egy statikus tartalomgenerátor.

Azok számára, akik nem ismerik a statikus generátorokat, mesélek egy kicsit többet róluk. Ellentétben az adatbázissal és néhány PHP-val rendelkező hagyományos webhelymotorokkal, amelyek a felhasználó kérésére menet közben generálnak oldalakat, a statikus generátorok egy kicsit másképp vannak kialakítva. Lehetővé teszik a források, általában a Markdown jelölő- és témasablonok fájlkészletének felvételét, majd ezekből egy teljesen kész webhelyté való fordítást.

Ez azt jelenti, hogy ennek eredményeként kap egy könyvtárstruktúrát és egy generált HTML-fájlkészletet, amelyet egyszerűen feltölthet bármely olcsó tárhelyre, és működő webhelyet kaphat.

Helyben telepítheti a Hugo-t, és kipróbálhatja:

Új webhely inicializálása:

hugo new site docs.example.org

És ugyanakkor a git tárház:

cd docs.example.org
git init

Eddig az oldalunk tiszta, és ahhoz, hogy valami megjelenjen rajta, először egy témát kell összekapcsolnunk, a téma csak sablonok és meghatározott szabályok halmaza, amelyek alapján az oldalunk létrejön.

A témához használjuk Tanul, ami véleményem szerint tökéletesen alkalmas dokumentációs oldalnak.

Külön szeretném felhívni a figyelmet arra, hogy a témafájlokat nem kell a projekttárunkba mentenünk, hanem egyszerűen csatlakoztathatjuk git almodul:

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

Így a repositorynk csak a projektünkhöz közvetlenül kapcsolódó fájlokat fog tartalmazni, a kapcsolódó téma pedig egy adott tárhelyre mutató hivatkozásként és abban egy commit marad, vagyis mindig az eredeti forrásból lehívható és nem kell félni összeférhetetlen változások.

Javítsuk ki a konfigurációt config.toml:

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

Már ebben a szakaszban futhat:

hugo server

És a címen http://localhost:1313/ nézze meg újonnan létrehozott weboldalunkat, a címtárban végrehajtott változtatások automatikusan frissítik a böngészőben megnyitott oldalt, nagyon kényelmes!

Próbáljunk meg létrehozni egy fedőlapot content/_index.md:

# My docs site

## Welcome to the docs!

You will be very smart :-)

Képernyőkép az újonnan létrehozott oldalról

Webhely létrehozásához futtassa:

hugo

Könyvtár tartalma nyilvános/ és az Ön webhelye lesz.
Igen, mellesleg azonnal tegyük hozzá .gitignore:

echo /public > .gitignore

Ne felejtse el végrehajtani a változtatásainkat:

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

2. A Dockerfile előkészítése

Itt az ideje, hogy meghatározzuk adattárunk szerkezetét. Általában valami ilyesmit használok:

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

• dockerfiles/ — Dockerfiles-könyvtárakat és mindent, ami a Docker-képképeink elkészítéséhez szükséges.
• telepíteni/ — olyan könyvtárakat tartalmaz, amelyek segítségével telepíthetjük alkalmazásainkat a Kubernetes rendszerbe

Így létrehozzuk az első Docker-fájlunkat az útvonal mentén 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" ]

Mint látható, a Dockerfile kettőt tartalmaz FROM, ezt a funkciót hívják többlépcsős felépítés és lehetővé teszi minden szükségtelen kizárását a végső docker-képből.
Így a végső kép csak tartalmaz sötéthttpd (könnyű HTTP szerver) és nyilvános/ — statikusan generált weboldalunk tartalma.

Ne felejtse el végrehajtani a változtatásainkat:

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

3. Kaniko megismerése

Docker image-készítőként a használata mellett döntöttem kaniko, mivel működéséhez nincs szükség docker démonra, maga a build pedig bármilyen gépen végrehajtható, a gyorsítótár pedig közvetlenül a registry-ben tárolható, így nincs szükség teljes értékű perzisztens tárolóra.

A kép elkészítéséhez futtassa a tárolót a következővel kaniko végrehajtó és adja át neki az aktuális összeállítási környezetet; ez helyileg is megtehető, a docker segítségével:

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

ahol registry.gitlab.com/kvaps/docs.example.org/website — a docker-kép neve; felépítés után automatikusan elindul a docker-nyilvántartásba.

Paraméter --gyorsítótár lehetővé teszi a rétegek gyorsítótárazását a docker rendszerleíró adatbázisában; a megadott példában ezek mentésre kerülnek registry.gitlab.com/kvaps/docs.example.org/website/cache, de a paraméter segítségével más elérési utat is megadhat --cache-repo.

Képernyőkép a docker-nyilvántartásról

4. A qbec megismerése

Qbec egy üzembe helyezési eszköz, amely lehetővé teszi az alkalmazás jegyzékfájljainak deklaratív leírását, és azok üzembe helyezését a Kubernetesben. A Jsonnet fő szintaxisként való használata lehetővé teszi, hogy nagymértékben leegyszerűsítse a különböző környezetek közötti különbségek leírását, és szinte teljesen kiküszöböli a kódismétlést.

Ez különösen igaz lehet olyan esetekben, amikor egy alkalmazást több, különböző paraméterekkel rendelkező fürthöz kell telepítenie, és deklaratív módon szeretné leírni azokat a Gitben.

A Qbec lehetővé teszi a Helm diagramok megjelenítését is úgy, hogy átadja nekik a szükséges paramétereket, majd ugyanúgy kezelheti őket, mint a normál manifeszteket, beleértve különféle mutációkat is alkalmazva rajtuk, és ez pedig lehetővé teszi, hogy megszabaduljon a szükséges paraméterektől. használja a ChartMuseumot. Ez azt jelenti, hogy közvetlenül a git-ből tárolhatja és renderelheti a diagramokat, ahol azok tartoznak.

Ahogy korábban mondtam, az összes telepítést egy könyvtárban fogjuk tárolni telepíteni/:

mkdir deploy
cd deploy

Inicializáljuk első alkalmazásunkat:

qbec init website
cd website

Most az alkalmazásunk szerkezete így néz ki:

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

nézzük meg a fájlt qbec.yaml:

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

Itt elsősorban az érdekel minket spec.environments, a qbec már létrehozott nekünk egy alapértelmezett környezetet, és átvette a szerver címét, valamint a névteret a jelenlegi kubeconfigunkból.
Most a telepítéskor alapértelmezett környezetben, a qbec mindig csak a megadott Kubernetes-fürtre és a megadott névtérre telepíti, vagyis többé nem kell váltania a környezetek és a névterek között a telepítés végrehajtásához.
Ha szükséges, bármikor frissítheti a beállításokat ebben a fájlban.

Az összes környezet leírása itt található qbec.yaml, és a fájlban params.libsonnet, ahol azt írja, hogy hol lehet beszerezni hozzájuk a paramétereket.

Ezután két könyvtárat látunk:

• alkatrészek / - az alkalmazásunk összes manifestje itt lesz tárolva; leírhatók jsonnet és normál yaml fájlokban is
• környezetek/ — itt leírjuk a környezetünk összes változóját (paraméterét).

Alapértelmezés szerint két fájlunk van:

• Environments/base.libsonnet - minden környezethez közös paramétereket fog tartalmazni
• Environments/default.libsonnet — a környezet számára felülírt paramétereket tartalmaz alapértelmezett

nyissuk ki Environments/base.libsonnet és adja hozzá az első komponensünk paramétereit:

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

Készítsük el az első komponensünket is 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,
                },
              },
            ],
          },
        },
      ],
    },
  },
]

Ebben a fájlban három Kubernetes entitást írtunk le egyszerre, ezek a következők: bevetés, szolgáltatás и Bemenetel. Ha akarjuk, különböző komponensekbe rakhatjuk őket, de ebben a szakaszban egy is elég lesz nekünk.

szintaxis jsonnet nagyon hasonlít a normál json-hoz, elvileg a normál json már érvényes jsonnet, így eleinte könnyebb lehet az online szolgáltatások használata, mint pl. yaml2json a szokásos yaml json-ba konvertálásához, vagy ha a komponensei nem tartalmaznak változókat, akkor leírhatók normál yaml formájában.

Amikor dolgozik jsonnet Erősen javaslom egy bővítmény telepítését a szerkesztőhöz

Például van egy plugin a vim-hez vim-jsonnet, amely bekapcsolja a szintaktikai kiemelést és automatikusan végrehajtja jsonnet fmt minden mentéskor (telepített jsonnet szükséges).

Minden készen áll, elkezdhetjük a telepítést:

Hogy lássuk, mit kaptunk, futtassuk:

qbec show default

A kimeneten megjelennek a renderelt yaml-jegyzékek, amelyek az alapértelmezett fürtre lesznek alkalmazva.

Remek, most jelentkezz:

qbec apply default

A kimeneten mindig látni fogja, hogy mi fog történni a fürtben, a qbec megkéri, hogy fogadja el a változtatásokat y meg tudja majd erősíteni szándékait.

Alkalmazásunk elkészült és bevezetett!

Ha változtatásokat hajt végre, mindig megteheti:

qbec diff default

hogy megtudja, hogyan érintik ezek a változtatások a jelenlegi telepítést

Ne felejtse el végrehajtani a változtatásainkat:

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

5. Gitlab-runner kipróbálása Kubernetes-végrehajtóval

Egészen mostanáig csak rendszeresen használtam gitlab-runner előre elkészített gépen (LXC konténer) shell-el vagy docker-végrehajtóval. Kezdetben több ilyen futót határoztunk meg globálisan a gitlabunkban. Docker képeket gyűjtöttek minden projekthez.

De amint a gyakorlat megmutatta, ez a lehetőség nem a legideálisabb, mind a praktikum, mind a biztonság szempontjából. Sokkal jobb és ideológiailag helyesebb, ha minden projekthez, vagy akár minden környezethez külön futókat telepítenek.

Szerencsére ez egyáltalán nem probléma, hiszen most bevetjük gitlab-runner közvetlenül a projektünk részeként közvetlenül Kubernetesben.

A Gitlab kész sisakdiagramot biztosít a gitlab-runner Kubernetes rendszerbe történő telepítéséhez. Tehát csak annyit kell tennie, hogy megtudja regisztrációs token projektünkhöz Beállítások -> CI / CD -> Futók és add át a kormánynak:

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

Hol:

• https://gitlab.com — a Gitlab szerver címe.
• yga8y-jdCusVDn_t4Wxc — regisztrációs token a projekthez.
• rbac.create=true — biztosítja a futtatónak a szükséges mennyiségű jogosultságot ahhoz, hogy a kubernetes-executor segítségével podokat tudjon létrehozni feladataink elvégzéséhez.

Ha mindent jól csinált, akkor egy regisztrált futót kell látnia a részben Futók, a projekt beállításaiban.

Képernyőkép a hozzáadott futóról

Ilyen egyszerű? - Igen, ez ilyen egyszerű! Nincs több gond a futók manuális regisztrációjával, mostantól a futók létrehozása és megsemmisítése automatikusan történik.

6. Telepítse a Helm diagramokat a QBEC segítségével

Mivel úgy döntöttünk, hogy megfontoljuk gitlab-runner projektünk része, itt az ideje, hogy leírjuk a Git adattárunkban.

Leírhatnánk külön komponensként , de a jövőben különböző példányok telepítését tervezzük nagyon gyakran, ellentétben gitlab-runner, amely Kubernetes-fürtönként csak egyszer lesz üzembe helyezve. Tehát inicializáljunk hozzá egy külön alkalmazást:

cd deploy
qbec init gitlab-runner
cd gitlab-runner

Ezúttal nem manuálisan írjuk le a Kubernetes entitásokat, hanem egy kész Helm diagramot veszünk. A qbec egyik előnye, hogy a Helm diagramokat közvetlenül egy Git tárolóból lehet renderelni.

Csatlakoztassuk a git almodul segítségével:

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

Most a könyvtár szállító/gitlab-runner Van egy adattárunk a gitlab-runner diagramjával.

Hasonló módon csatlakoztathat más tárolókat, például a teljes tárat hivatalos diagramokkal https://github.com/helm/charts

Leírjuk az összetevőt 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,
  }
)

Az első érv, hogy expandHelmTemplate akkor átadjuk az utat a diagramhoz paraméterek.értékek, amelyet a környezeti paraméterekből veszünk, majd jön az objektum

• nameSablon - kiadás neve
• névtér — névtér átkerült a kormányra
• ez a fájl — egy kötelező paraméter, amely átadja az aktuális fájl elérési útját
• bőbeszédű - mutatja a parancsot sisak sablon az összes érvvel a diagram megjelenítése során

Most írjuk le a komponensünk paramétereit 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,
      },
    },
  },
}

Figyeljen oda runnerRegistrationToken külső fájlból veszünk secrets/base.libsonnet, hozzuk létre:

{
  runnerRegistrationToken: 'yga8y-jdCusVDn_t4Wxc',
}

Nézzük meg, hogy minden működik-e:

qbec show default

Ha minden rendben van, akkor a Helmen keresztül törölhetjük a korábban telepített kiadásunkat:

helm uninstall gitlab-runner

és ugyanúgy telepítse, de qbec-en keresztül:

qbec apply default

7. Bevezetés a git-crypt-be

Git-crypt egy olyan eszköz, amely lehetővé teszi az átlátszó titkosítás beállítását a tárhely számára.

Jelenleg a gitlab-runner könyvtárstruktúrája így néz ki:

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

De a titkok tárolása a Gitben nem biztonságos, igaz? Tehát megfelelően titkosítanunk kell őket.

Általában egy változó miatt ennek nem mindig van értelme. A titkokat átviheti ide qbec és a CI-rendszer környezeti változóin keresztül.
De érdemes megjegyezni, hogy vannak bonyolultabb projektek is, amelyek sokkal több titkot tartalmazhatnak, ezeknek a környezeti változókon keresztül történő átvitele rendkívül nehéz lesz.

Ráadásul ebben az esetben nem tudnék mesélni egy olyan csodálatos eszközről, mint git-crypt.

git-crypt Ez abból a szempontból is kényelmes, hogy lehetővé teszi a titkok teljes történetének elmentését, valamint a konfliktusok összehasonlítását, összevonását és feloldását, ahogyan azt a Git esetében megszoktuk.

Az első dolog a telepítés után git-crypt kulcsokat kell generálnunk a tárhelyünkhöz:

git crypt init

Ha rendelkezik PGP-kulccsal, azonnal felveheti magát együttműködőként ehhez a projekthez:

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

Így mindig visszafejtheti ezt a tárolót a privát kulcsával.

Ha nem rendelkezik PGP-kulccsal, és nem is vár rá, akkor a másik irányba mehet, és exportálhatja a projektkulcsot:

git crypt export-key /path/to/keyfile

Így bárki, akinek van egy exportált kulcsfájlt képes lesz visszafejteni az adattárat.

Ideje feltárni első titkunkat.
Hadd emlékeztesselek arra, hogy még mindig a címtárban vagyunk deploy/gitlab-runner/, ahol van egy könyvtárunk titkok/, titkosítsuk az összes benne lévő fájlt, ehhez készítünk egy fájlt titkok/.gitattributes a következő tartalommal:

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

Amint a tartalomból látható, minden fájl maszkolt * keresztül fogják hajtani git-crypt, kivéve a legtöbbet .gitattributes

Ezt a következő futtatással ellenőrizhetjük:

git crypt status -e

A kimenet a lerakatban lévő összes olyan fájl listája lesz, amelynél engedélyezve van a titkosítás

Ennyi, most már nyugodtan végrehajthatjuk változtatásainkat:

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

Egy adattár blokkolásához futtassa:

git crypt lock

és azonnal az összes titkosított fájl binárissá válik, lehetetlen lesz elolvasni őket.
A tároló visszafejtéséhez futtassa:

git crypt unlock

8. Hozzon létre egy eszköztár képet

Az eszköztár kép egy olyan kép, amely tartalmazza az összes olyan eszközt, amelyet a projektünk telepítéséhez használunk. A Gitlab futtatója fogja használni a tipikus telepítési feladatok elvégzésére.

Itt minden egyszerű, hozzunk létre egy újat dockerfiles/toolbox/Dockerfile a következő tartalommal:

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

Amint láthatja, ezen a képen telepítjük az összes olyan segédprogramot, amelyet az alkalmazásunk telepítéséhez használtunk. Itt nincs rá szükségünk, hacsak nem kubectl, de érdemes lehet vele játszani a csővezeték beállítási szakaszában.

Továbbá, hogy kommunikálni tudjunk a Kubernetes-szel és telepíteni tudjunk rá, be kell állítanunk egy szerepet a gitlab-runner által generált podokhoz.

Ehhez menjünk a gitlab-runner könyvtárba:

cd deploy/gitlab-runner

és adjunk hozzá egy új összetevőt 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,
      },
    ],
  },
]

Leírjuk az új paramétereket is Environments/base.libsonnet, ami most így néz ki:

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

Figyeljen oda $.components.rbac.name utal rá név alkatrészhez rbac

Nézzük, mi változott:

qbec diff default

és alkalmazzuk a változtatásainkat a Kubernetesre:

qbec apply default

Ezenkívül ne felejtse el véglegesíteni a módosításainkat a git-ben:

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. Első csővezetékünk és képek összeállítása címkék alapján

A projekt gyökerénél fogunk létrehozni .gitlab-ci.yml a következő tartalommal:

.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

Felhívjuk figyelmét, hogy használjuk GIT_SUBMODULE_STRATEGY: normál azokhoz a feladatokhoz, ahol az almodulokat kifejezetten inicializálni kell a végrehajtás előtt.

Ne felejtse el végrehajtani a változtatásainkat:

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

Azt hiszem, nyugodtan nevezhetjük ezt egy verziónak v0.0.1 és add hozzá a címkét:

git tag v0.0.1

Amikor új verziót kell kiadnunk, címkéket adunk hozzá. A Docker-képekben lévő címkék Git-címkékhez lesznek kötve. Minden új címkével történő leküldés inicializálja a képek összeállítását ezzel a címkével.

teljesít git push --tags, és nézzük az első folyamatot:

Képernyőkép az első csővezetékről

Érdemes felhívni a figyelmet arra, hogy a címkék szerinti összeállítás alkalmas docker képek készítésére, de nem alkalmas alkalmazás Kubernetes-be való telepítésére. Mivel új címkék rendelhetők a régi véglegesítésekhez, ebben az esetben a folyamat inicializálása a régi verzió telepítéséhez vezet.

A probléma megoldása érdekében általában a docker-képek felépítése címkékhez van kötve, és az alkalmazás telepítése egy ágra mester, amelyben az összegyűjtött képek változatai hardkódolva vannak. Itt inicializálhatja a visszaállítást egy egyszerű visszaállítással mester-ágak.

10. A telepítés automatizálása

Annak érdekében, hogy a Gitlab-runner visszafejtse titkainkat, exportálnunk kell a tárolókulcsot, és hozzá kell adnunk a CI környezeti változókhoz:

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

Az eredményül kapott sort elmentjük a Gitlabba; ehhez menjünk a projektbeállításokhoz:
Beállítások -> CI / CD -> Változók

És hozzunk létre egy új változót:

típus
Kulcs
Érték
Védett
Álarcos
Kör

File
GITCRYPT_KEY
<your string>
true (a képzés alatt megteheti false)
true
All environments

Képernyőkép a hozzáadott változóról

Most frissítsük a mi .gitlab-ci.yml hozzátéve:

.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

Itt több új lehetőséget is engedélyeztünk a qbec számára:

• --root some/app — lehetővé teszi egy adott alkalmazás könyvtárának meghatározását
• --force:k8s-context __incluster__ - ez egy mágikus változó, amely azt mondja, hogy a telepítés ugyanabban a fürtben történik, amelyben a gtilab-runner fut. Erre azért van szükség, mert különben a qbec megpróbál megfelelő Kubernetes szervert találni a kubeconfigban
• --várjon — arra kényszeríti a qbec-et, hogy várjon, amíg az általa létrehozott erőforrások kész állapotba kerülnek, és csak ezután lépnek ki sikeres kilépési kóddal.
• -Igen - egyszerűen letiltja az interaktív héjat Biztos vagy benne? bevetéskor.

Ne felejtse el végrehajtani a változtatásainkat:

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

És utána git push meglátjuk, hogyan kerültek telepítésre az alkalmazásaink:

Képernyőkép a második csővezetékről

11. Műtermékek és összeszerelés a masterre tolásakor

Általában a fent leírt lépések elegendőek szinte bármilyen mikroszolgáltatás létrehozásához és biztosításához, de nem szeretnénk minden alkalommal címkét hozzáadni, amikor frissíteni kell az oldalt. Ezért egy dinamikusabb útvonalat választunk, és beállítunk egy kivonat telepítést a fő ágban.

Az ötlet egyszerű: most a mi képünk minden alkalommal újjáépítik, amikor belépsz mester, majd automatikusan telepíti a Kubernetesre.

Frissítsük ezt a két munkát nálunk .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"

Felhívjuk figyelmét, hogy hozzáadtunk egy szálat mester к refs munkahelyekre build_website és most használjuk $CI_COMMIT_REF_NAME helyett $CI_COMMIT_TAG, vagyis a Gitben leválasztjuk a címkéket, és most egy képet fogunk tolni a folyamatot inicializáló commit ág nevével. Érdemes megjegyezni, hogy ez a címkékkel is működik, ami lehetővé teszi számunkra, hogy pillanatképeket mentsünk egy adott verziójú webhelyről a docker-nyilvántartásba.

Ha a webhely új verziójához tartozó docker címke neve változatlanul hagyható, akkor is le kell írnunk a változtatásokat a Kubernetesben, különben egyszerűen nem telepíti át az alkalmazást az új lemezképről, mivel nem észlel semmilyen változást a telepítési jegyzék.

választási lehetőség —vm:ext-str digest=”$DIGEST” qbec esetén - lehetővé teszi egy külső változó átadását a jsonnet számára. Azt akarjuk, hogy az alkalmazásunk minden egyes kiadásával újratelepítsék a fürtben. A címkenevet már nem használhatjuk, ami mostantól megváltoztathatatlan, mivel a kép egy adott verziójához kell kapcsolódnunk, és ha az megváltozik, elindítjuk a telepítést.

Itt segítségünkre lesz Kaniko azon képessége, hogy egy kivonatképet fájlba menthet (opció --kivonat-fájl)
Ezután átvisszük ezt a fájlt, és a telepítéskor elolvassuk.

Frissítsük a paramétereinket deploy/website/environments/base.libsonnet ami most így fog kinézni:

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

Kész, most bármilyen kötelezettséget vállaljon mester inicializálja a docker lemezkép felépítését , majd telepítse a Kubernetesre.

Ne felejtse el végrehajtani a változtatásainkat:

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

Később ellenőrizzük git push valami ilyesmit kellene látnunk:

Képernyőkép a fő csővezetékről

Elvileg nem kell újratelepítenünk a gitlab-runnert minden egyes lenyomásnál, kivéve, ha természetesen semmi nem változott a konfigurációjában, javítsuk meg .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/**/*

változások lehetővé teszi a változások nyomon követését deploy/gitlab-runner/ és csak akkor váltja ki a munkánkat, ha vannak

Ne felejtse el végrehajtani a változtatásainkat:

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

git push, ez jobb:

Képernyőkép a frissített folyamatról

12. Dinamikus környezetek

Itt az ideje, hogy dinamikus környezetekkel diverzifikáljuk a folyamatot.

Először frissítsük a munkát build_website a mi .gitlab-ci.yml, távolítsa el róla a blokkot csak, ami arra kényszeríti a Gitlabot, hogy elindítsa azt bármely ágon végrehajtott commit esetén:

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/

Ezután frissítse a munkát telepítési_webhely, adjon hozzá egy blokkot környezet:

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"

Ez lehetővé teszi, hogy a Gitlab társítsa a munkát a következővel döf környezetet, és jelenítse meg a megfelelő hivatkozást.

Most adjunk hozzá még két munkát:

deploy_website:
  extends: .deploy_qbec_app
  environment:
    name: prod
    url: https://docs.example.org
  script:
    - DIGEST="$(cat artifacts/website.digest)"
    - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST"

deploy_review:
  extends: .deploy_qbec_app
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: http://$CI_ENVIRONMENT_SLUG.docs.example.org
    on_stop: stop_review
  script:
    - DIGEST="$(cat artifacts/website.digest)"
    - qbec apply review --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST" --vm:ext-str subdomain="$CI_ENVIRONMENT_SLUG" --app-tag "$CI_ENVIRONMENT_SLUG"
  only:
    refs:
    - branches
  except:
    refs:
      - master

stop_review:
  extends: .deploy_qbec_app
  environment:
    name: review/$CI_COMMIT_REF_NAME
    action: stop
  stage: deploy
  before_script:
    - git clone "$CI_REPOSITORY_URL" master
    - cd master
  script:
    - qbec delete review --root deploy/website --force:k8s-context __incluster__ --yes --vm:ext-str digest="$DIGEST" --vm:ext-str subdomain="$CI_ENVIRONMENT_SLUG" --app-tag "$CI_ENVIRONMENT_SLUG"
  variables:
    GIT_STRATEGY: none
  only:
    refs:
    - branches
  except:
    refs:
      - master
  when: manual

Leküldéskor bármely ágra elindulnak, kivéve a mestert, és telepítik a webhely előnézeti verzióját.

Látunk egy új lehetőséget a qbec számára: --app-tag — lehetővé teszi az alkalmazás telepített verzióinak címkézését és csak ezen a címkén belüli működését; a Kubernetes erőforrásainak létrehozásakor és megsemmisítésekor a qbec csak ezekkel fog működni.
Így nem tudunk minden áttekintéshez külön környezetet létrehozni, hanem egyszerűen újra felhasználhatjuk ugyanazt.

Itt is használjuk qbec alkalmazza a felülvizsgálatot, ahelyett qbec alapértelmezett alkalmazása - pontosan ez az a pillanat, amikor megpróbáljuk leírni a környezetünkben tapasztalható különbségeket (áttekintés és alapértelmezett):

Tegyük hozzá Kritika környezet be deploy/website/qbec.yaml

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

Akkor bejelentjük 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

És írja le az egyéni paramétereket 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',
    },
  },
}

Nézzük meg közelebbről is a jobu-t stop_review, akkor aktiválódik, amikor az ágat töröljük, és hogy a gitlab ne próbálja meg a fizetést GIT_STRATEGY: nincs, később klónozzuk mester-elágazás, és ezen keresztül törölje a véleményt.
Kicsit zavaró, de ennél szebb módot még nem találtam.
Egy másik lehetőség az, hogy minden értékelést egy szállodanévtérbe helyeznek el, amely mindig teljesen lebontható.

Ne felejtse el végrehajtani a változtatásainkat:

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

git push, git checkout -b teszt, git push eredet teszt, jelölje be:

Képernyőkép a Gitlabban létrehozott környezetekről

Minden működik? - remek, töröld a tesztágunkat: git pénztár mester, git push eredet :teszt, ellenőrizzük, hogy a környezettörlési feladatok hiba nélkül működtek-e.

Itt azonnal szeretném tisztázni, hogy egy projektben bármely fejlesztő létrehozhat ágakat, ő is változtathat .gitlab-ci.yml fájlokat és hozzáférést biztosít a titkos változókhoz.
Ezért erősen ajánlott, hogy csak védett ágakban engedélyezzék a használatukat, például in mester, vagy hozzon létre külön változókészletet minden környezethez.

13. Tekintse át az alkalmazásokat

Tekintse át az alkalmazásokat Ez egy GitLab-funkció, amely lehetővé teszi, hogy a tárolóban lévő minden egyes fájlhoz egy gombot adjon hozzá, hogy gyorsan megtekinthesse azokat egy telepített környezetben.

Ahhoz, hogy ezek a gombok megjelenjenek, létre kell hoznia egy fájlt .gitlab/route-map.yml és írja le benne az összes útvonal-transzformációt; esetünkben ez nagyon egyszerű lesz:

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

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

Ne felejtse el végrehajtani a változtatásainkat:

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

git push, és ellenőrizze:

Képernyőkép az Alkalmazás áttekintése gombról

A munka kész!

A projekt forrásai:

• a Gitlabon: https://gitlab.com/kvaps/docs.example.org
• a GitHubon: https://github.com/kvaps/docs.example.org

Köszönöm a figyelmet, remélem tetszett

Forrás: will.com