Slav! Di van demên dawî de, hem ji bo avakirina wêneyên Docker û hem jî ji bo bicihkirina Kubernetes gelek amûrên xweseriya xweş hatine berdan. Di vî warî de, min biryar da ku ez bi GitLab-ê re bilîzim, kapasîteyên wê bi baldarî lêkolîn bikim û, bê guman, boriyê saz bikim.

Ev xebat ji hêla malperê ve hatî îlhama kirin kubernetes.io, ku ji hatî çêkirin kodên çavkaniyê bixweber, û ji bo her daxwazek hewzê ku hatî şandin, robot bixweber bi guheztinên we ve guhertoyek pêşdîtinê ya malperê çêdike û ji bo temaşekirinê girêdanek peyda dike.

Min hewl da ku pêvajoyek wekhev ji sifrê ava bikim, lê bi tevahî li ser Gitlab CI û amûrên belaş ên ku ez bikar tînim ji bo bicihkirina sepanan li Kubernetes bikar tînim ava kir. Îro ez ê di dawiyê de ji we re bêtir li ser wan bibêjim.

Gotar dê li ser amûrên wekî:
Hugo, qbec, kaniko, git-crypt и GitLab CI bi afirandina derdorên dînamîk.

Contents

1. Bi Hugo re hevdîtin bikin
2. Amadekirina Dockerfile
3. Naskirina kaniko
4. Qbec nas kirin
5. Bi Kubernetes-îcrakar Gitlab-runner biceribînin
6. Bi qbec re nexşeyên Helm bicîh dikin
7. Danasîna git-crypt
8. Afirandina wêneyek toolboxê
9. Rêzeya meya yekem û berhevkirina wêneyan ji hêla nîşanan ve
10. otomatê de Deployment
11. Artifacts û meclîsê dema ku ji bo masterê dikişîne
12. derdorên dînamîk
13. Apps Review

1. Naskirina Hugo

Wekî mînakek projeya xwe, em ê hewl bidin ku malperek weşana belgeyan ku li ser Hugo hatî çêkirin biafirînin. Hugo hilberînerek naveroka statîk e.

Ji bo yên ku bi jeneratorên statîk nizanin, ez ê ji we re hinekî bêtir li ser wan bibêjim. Berevajî motorên malperê yên kevneşopî yên bi databas û hin PHP-ê, ku dema ku ji hêla bikarhênerek ve tê xwestin, rûpelan di firînê de çêdikin, jeneratorên statîk hinekî cûda têne sêwirandin. Ew dihêlin hûn çavkaniyan bigirin, bi gelemperî komek pelan di nîşankirin û şablonên mijarê de Markdown, dûv re wan li malperek bi tevahî qediya berhev bikin.

Ango, wekî encam, hûn ê avahiyek pelrêça û komek pelên HTML-ê yên hilberandî bistînin, ku hûn dikarin bi hêsanî li her mêvandariyek erzan bar bikin û malperek xebitandinê bistînin.

Hûn dikarin Hugo herêmî saz bikin û wê biceribînin:

Destpêkirina malperek nû:

hugo new site docs.example.org

Û di heman demê de depoya git:

cd docs.example.org
git init

Heya nuha, malpera me paqij e û ji bo ku tiştek li ser xuya bibe, em pêşî hewce ne ku mijarek ve girêbidin; mijarek tenê komek şablon û qaîdeyên diyarkirî ye ku malpera me pê tê çêkirin.

Ji bo mijarê em ê bikar bînin Fêrbûn, ku, bi dîtina min, ji bo malperek belgekirinê bêkêmasî ye.

Ez dixwazim bi taybetî bala xwe bidim ser vê yekê ku em ne hewce ne ku pelên mijarê di depoya projeya xwe de hilînin; li şûna wê, em dikarin bi hêsanî wê bi karanîna wê ve girêbidin. git submodule:

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

Ji ber vê yekê, depoya me dê tenê pelên ku rasterast bi projeya me ve girêdayî ne vehewîne, û mijara girêdayî dê wekî girêdanek ji depoyek taybetî re bimîne û di wê de peywirdariyek bimîne, ango, ew her gav dikare ji çavkaniya bingehîn were derxistin û jê netirse. guhertinên lihevhatî.

Ka em konfigurasyonê rast bikin config.toml:

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

Jixwe di vê qonaxê de hûn dikarin birevin:

hugo server

Û li navnîşanê http://localhost:1313/ malpera meya nû hatî afirandin kontrol bikin, hemî guhertinên ku di pelrêçê de têne çêkirin bixweber rûpela vekirî ya di gerokê de nûve bikin, pir rehet!

Ka em hewl bidin ku di nav de rûpelek serpêhatiyek çêbikin naveroka/_index.md:

# My docs site

## Welcome to the docs!

You will be very smart :-)

Dîmenê rûpela nû hatî afirandin

Ji bo afirandina malperek, tenê bimeşînin:

hugo

naveroka Directory alenî/ û dê bibe malpera we.
Erê, bi awayê, em tavilê wê lê zêde bikin .gitignore:

echo /public > .gitignore

Ji bîr nekin ku guhertinên me bikin:

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

2. Amadekirina Dockerfile

Wext e ku em strukturê depoya xwe diyar bikin. Ez bi gelemperî tiştek wekî bikar tîne:

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

• dockerfiles/ - pelrêçan bi Dockerfiles û her tiştê ku ji bo avakirina wêneyên me yên Docker hewce ne vedihewîne.
• bikaranîn/ - pelrêçan ji bo bicihkirina sepanên me li Kubernetes vedihewîne

Bi vî rengî, em ê di rê de Dockerfile-ya xweya yekem biafirînin dockerfiles/malper/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" ]

Wekî ku hûn dikarin bibînin, Dockerfile du hene JI, ev taybetmendî tê gotin avakirina pir-qonaxa û dihêle hûn her tiştê nehewce ji wêneya paşîn a dokerê derxînin.
Bi vî rengî, wêneya paşîn dê tenê hebe tarîhttpd (pêşkêşkara HTTP ya sivik) û alenî/ - naveroka malpera me ya statîkî hatî çêkirin.

Ji bîr nekin ku guhertinên me bikin:

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

3. Naskirina kaniko

Wekî çêkerek wêneya docker, min biryar da ku bikar bînim kaniko, ji ber ku xebata wê ne hewceyî damemonek dokerê ye, û avahî bixwe dikare li ser her makîneyê were bicîh kirin û cache rasterast di qeydê de were hilanîn, bi vî rengî hewcedariya xwedan hilanîna domdar a bêkêmasî ji holê radike.

Ji bo avakirina wêneyê, tenê konteynerê bi rêve bikin kaniko îcrakar û wê çarçoweya avakirina heyî derbas bikin; ev jî dikare li herêmê, bi rêya docker ve were kirin:

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

Derê registry.gitlab.com/kvaps/docs.example.org/website - Navê wêneya dokera we; piştî çêkirinê, ew ê bixweber di nav tomara dokerê de were destpêkirin.

Parîsê --cache destûrê dide te ku hûn qatan di qeyda dokerê de cache bikin; ji bo mînaka hatî dayîn, ew ê tê de bêne tomar kirin registry.gitlab.com/kvaps/docs.example.org/website/cache, lê hûn dikarin rêyek din bi karanîna pîvanê diyar bikin --cache-repo.

Dîmenê docker-qeydê

4. Naskirina qbec

Qbec amûrek bicîhkirinê ye ku dihêle hûn bi eşkereyî diyardeyên serîlêdana xwe diyar bikin û wan li Kubernetes bicîh bikin. Bikaranîna Jsonnet wekî hevoksaziya sereke dihêle hûn danasîna cûdahiyan di nav gelek hawîrdoran de pir hêsan bikin, û her weha hema hema bi tevahî dubarekirina kodê ji holê radike.

Ev dikare bi taybetî di rewşên ku hûn hewce ne ku serîlêdanek li gelek koman bi parametreyên cihêreng bicîh bikin û dixwazin wan bi eşkereyî di Git de binav bikin rast be.

Qbec di heman demê de dihêle hûn nexşeyên Helm bi derbaskirina wan pîvanên pêwîst re bidin çêkirin û dûv re wan bi heman awayê diyardeyên birêkûpêk bixebitînin, di nav de hûn dikarin mutasyonên cihêreng li wan bicîh bikin, û ev, di encamê de, dihêle hûn ji hewcedariyê xilas bibin. ChartMuseum bikar bînin. Ango, hûn dikarin nexşeyan rasterast ji git, cihê ku ew in, hilînin û bidin.

Wekî ku min berê jî got, em ê hemî bicîhkirinan di pelrêçek de hilînin bikaranîn/:

mkdir deploy
cd deploy

Ka em serîlêdana xweya yekem dest pê bikin:

qbec init website
cd website

Naha avahiya serîlêdana me wiha xuya dike:

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

em li dosyayê binêrin qbec.yaml:

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

Li vir em di serî de eleqedar in spec.hawirdoran, qbec jixwe ji me re hawîrdorek xwerû çêkiriye û navnîşana serverê, û hem jî cîhê navan ji kubeconfiga meya heyî girtiye.
Niha dema ku li destçûnî jîngehê, qbec dê her gav tenê li koma Kubernetes a diyarkirî û li cîhê navên diyarkirî bicîh bike, ango, hûn êdî neçar in ku hûn di navbera çarçove û cîhên navan de biguhezînin da ku bicîh bikin.
Ger hewce be, hûn dikarin her gav mîhengên vê pelê nûve bikin.

Hemî derdorên we di nav de têne diyar kirin qbec.yaml, û di pelê de params.libsonnet, li ku derê dibêje ku meriv ji bo wan parametreyan li ku derê bigire.

Piştre em du peldankan dibînin:

• pêkhate/ - Hemî diyardeyên ji bo serîlêdana me dê li vir werin hilanîn; ew dikarin hem di pelên jsonnet û hem jî di pelên yaml yên birêkûpêk de bêne şirove kirin
• hawirdor/ - li vir em ê hemî guherbarên (parametreyên) ji bo hawîrdora xwe diyar bikin.

Bi xwerû du pelên me hene:

• derdorên/base.libsonnet - ew ê ji bo hemî hawîrdoran pîvanên hevpar hebe
• derdorên/default.libsonnet - Parametreyên ku ji bo jîngehê hatine dorpêç kirin vedihewîne destçûnî

em vekin derdorên/base.libsonnet û ji bo pêkhateya meya yekem li wir parametreyan zêde bikin:

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

Werin em jî pêkhateya xwe ya yekem biafirînin pêkhateyên/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,
                },
              },
            ],
          },
        },
      ],
    },
  },
]

Di vê pelê de me sê hebûnên Kubernetes yekcar rave kir, ev in: Dêrîn, Xizmetkar и Ingress. Ger me bixwesta me dikarîbû wan bixista nav pêkhateyên cuda, lê di vê qonaxê de yek têra me dike.

syntax jsonnet pir dişibihe json-ya birêkûpêk, di prensîbê de, json-ya birêkûpêk jixwe jsonnet derbasdar e, ji ber vê yekê di destpêkê de dibe ku ji we re hêsantir be ku hûn karûbarên serhêl ên mîna bikar bînin yaml2json ji bo veguhertina yaml-ya xweya adetî nav json, an jî, heke pêkhateyên we tu guhêrbar negirin, wê hingê ew dikarin di forma yaml-a birêkûpêk de bêne şirove kirin.

Dema ku kar bi jsonnet Ez pir pêşniyar dikim ku pêvekek ji bo edîtorê xwe saz bikin

Mînakî, pêvekek ji bo vim heye vim-jsonnet, ku ronîkirina hevoksaziyê vedike û bixweber dike jsonnet fmt her gava ku hûn hilînin (ji bo sazkirina jsonnet hewce dike).

Her tişt amade ye, naha em dikarin dest bi belavkirinê bikin:

Ji bo ku em bibînin ka me çi girt, em birevin:

qbec show default

Di encam de, hûn ê diyardeyên yaml-ê yên ku dê li koma xwerû werin sepandin bibînin.

Mezin, naha serlêdan bikin:

qbec apply default

Di encam de hûn ê her gav bibînin ka dê di koma we de çi were kirin, qbec dê ji we bixwaze ku hûn bi nivîsandina guhertinan bipejirînin. y hûn ê bikaribin niyeta xwe piştrast bikin.

Serlêdana me amade ye û belav bûye!

Ger hûn guhertinan bikin, hûn dikarin her gav bikin:

qbec diff default

ji bo dîtina van guhertinan dê çawa bandorê li bicihkirina heyî bike

Ji bîr nekin ku guhertinên me bikin:

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

5. Hewldana Gitlab-runner bi Kubernetes-îcrakar

Heta vê dawiyê min tenê bi rêkûpêk bikar anî gitlab-runner li ser makîneyek pêş-amadekirî (konteynerê LXC) bi şêl an doker-îcrakar. Di destpêkê de, me di gitlabê de çend bezvanên weha li seranserê cîhanê diyar kirin. Wan ji bo hemî projeyan wêneyên doker berhev kirin.

Lê wekî ku pratîkê destnîşan kiriye, ev vebijark hem ji hêla pratîkî û hem jî ji hêla ewlehiyê ve ne ya herî îdeal e. Pir çêtir û ji hêla îdeolojîkî ve rasttir e ku ji bo her projeyê, an jî ji bo her hawîrdorê bezvanên cihêreng werin bicîh kirin.

Xweşbextane, ev qet ne pirsgirêkek e, ji ber ku niha em ê bicîh bikin gitlab-runner rasterast wekî beşek projeya me ya rast li Kubernetes.

Gitlab ji bo bicîhkirina gitlab-runner li Kubernetes nexşeyek helmê ya amade peyda dike. Ji ber vê yekê ya ku hûn hewce ne bikin ev e ku hûn fêr bibin nîşana tomarkirinê ji bo projeya me li Settings -> CI / CD -> Runners û jê re derbas bikin:

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

Çu:

• https://gitlab.com - navnîşana servera xweya Gitlab.
• yga8y-jdCusVDn_t4Wxc - nîşana qeydkirinê ji bo projeya we.
• rbac.create=rast - ji bo ku bikaribe bi karanîna kubernetes-executor peywirên xwe pêk bîne, rêjeyeka pêwîst îmtiyazên bezê peyda dike.

Ger her tişt bi rêkûpêk hatî çêkirin, divê hûn di beşê de bezek qeydkirî bibînin Runners, di mîhengên projeya xwe de.

Dîmena bezê ya lêzêdekirî

Ma ew qas hêsan e? - Erê, ew qas hêsan e! Bi qeydkirina bezê bi destan re êdî alozî nema, ji niha û pê ve dê bazdan bixweber werin afirandin û hilweşandin.

6. Bi QBEC re nexşeyên Helm bicîh bikin

Ji ber ku me biryar da ku em bifikirin gitlab-runner beşek ji projeya me ye, ew dem e ku em wê di depoya xweya Git de rave bikin.

Em dikarin wê wekî pêkhateyek cuda binav bikin malpera, lê di pêşerojê de em plan dikin ku kopiyên cûda belav bikin malpera pir caran, berevajî gitlab-runner, ku dê li her komek Kubernetes tenê carekê were bicîh kirin. Ji ber vê yekê bila em ji bo wê serîlêdanek cihê dest pê bikin:

cd deploy
qbec init gitlab-runner
cd gitlab-runner

Vê carê em ê saziyên Kubernetes bi destan rave nekin, lê dê nexşeyek Helm a amade bistînin. Yek ji avantajên qbec ev e ku meriv nexşeyên Helm rasterast ji depoyek Git veguhezîne.

Ka em wê bi karanîna submodula git ve girêbidin:

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

Niha pelrêça vendor / gitlab-runner Me depoyek bi nexşeyek ji bo gitlab-runner heye.

Bi vî rengî, hûn dikarin depoyên din, mînakî, tevahî depo bi nexşeyên fermî ve girêdin. https://github.com/helm/charts

Ka em beşê şirove bikin pêkhateyên/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,
  }
)

Argumana yekem ji bo berfirehHelmŞablon em rê li ser chart, paşê paras.nirx, ya ku em ji pîvanên hawirdorê digirin, dûv re tişt tê

• nameŞablon - navê berdanê
• navnasî - cîhê navan li helmê hate veguheztin
• thisPel - Parametreyek pêdivî ye ku riya pelê heyî derbas dike
• devkî - fermanê nîşan dide şablonê helm bi hemû argumanan dema ku nexşeyê rendering

Naha em werin pîvanên pêkhateya xwe di nav de diyar bikin derdorên/base.libsonnet:

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

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

Bawer bikin runnerRegistrationToken em ji pelek derveyî digirin razên/base.libsonnet, em wê biafirînin:

{
  runnerRegistrationToken: 'yga8y-jdCusVDn_t4Wxc',
}

Ka em kontrol bikin ka her tişt dixebite:

qbec show default

heke her tişt bi rêkûpêk be, wê hingê em dikarin serbestberdana xweya berê ya bi navgîniya Helm veqetînin:

helm uninstall gitlab-runner

û wê bi heman rengî bicîh bikin, lê bi qbec:

qbec apply default

7. Destpêka git-crypt

Git-crypt amûrek e ku dihêle hûn ji bo depoya xwe şîfrekirina zelal saz bikin.

Vê gavê, avahiya pelrêça me ji bo gitlab-runner wiha xuya dike:

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

Lê hilanîna sirên li Git ne ewle ye, ne wusa? Ji ber vê yekê divê em wan bi rêkûpêk şîfre bikin.

Bi gelemperî, ji bo xatirê yek guhêrbar, ev her gav wate nake. Hûn dikarin sirên veguhezînin qbec û bi navgîniya guhêrbarên jîngehê yên pergala weya CI.
Lê hêjayî gotinê ye ku di heman demê de projeyên tevlihevtir jî hene ku dikarin gelek sirên din jî bihewînin; veguheztina wan hemî bi guhêrbarên hawîrdorê dê pir dijwar be.

Wekî din, di vê rewşê de ez ê nikaribim ji we re qala amûrek wusa ecêb bikim git-crypt.

git-crypt Di heman demê de hêsan e ku ew dihêle hûn tevahiya dîroka nehêniyan hilînin, û hem jî bi heman awayê ku em di doza Git de didin ber hev, hev bikin û nakokiyan çareser bikin.

Tişta yekem piştî sazkirinê git-crypt divê em ji bo depoya xwe mifteyan biafirînin:

git crypt init

Heke we mifteyek PGP heye, wê hingê hûn dikarin tavilê xwe wekî hevkarek ji bo vê projeyê zêde bikin:

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

Bi vî rengî hûn her gav dikarin vê depoyê bi karanîna mifteya xweya taybet deşîfre bikin.

Heke we mifteyek PGP tune û li hêviya we ne, wê hingê hûn dikarin rêyek din biçin û mifteya projeyê derxînin:

git crypt export-key /path/to/keyfile

Bi vî awayî, her kesê ku îxracat heye keyfile dê bikaribe depoya xwe deşîfre bike.

Wext e ku em sira xwe ya yekem saz bikin.
Bihêle ez ji we re bînim bîra we ku em hîn jî di pelrêça de ne deploy/gitlab-runner/, li ku derê pelrêçek me heye razên/, em hemî pelên tê de şîfre bikin, ji bo vê yekê em ê pelek çêbikin razên/.gitattributes bi naveroka jêrîn:

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

Wekî ku ji naverokê tê dîtin, hemî pelan têne mask kirin * dê bi rê ve bibin git-crypt, ji bilî yên herî .gitattributes

Em dikarin vê bi xebitandinê kontrol bikin:

git crypt status -e

Hilber dê navnîşek hemî pelên di depoyê de be ku şîfrekirina wan çalak e

Ew hemî ye, naha em dikarin bi ewlehî guhartinên xwe bikin:

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

Ji bo astengkirina depoyek, tenê bimeşînin:

git crypt lock

û tavilê hemî pelên şîfrekirî dê bibin tiştek binary, xwendina wan dê ne gengaz be.
Ji bo şîfrekirina depoyê, bixebitin:

git crypt unlock

8. Wêneyek toolboxê çêbikin

Wêneyek toolbox wêneyek bi hemî amûrên ku em ê bikar bînin da ku projeya xwe bicîh bikin. Ew ê ji hêla gerokê Gitlab ve were bikar anîn da ku peywirên bicîhkirina tîpîk pêk bîne.

Li vir her tişt hêsan e, em yekî nû biafirînin dockerfiles / toolbox / Dockerfile bi naveroka jêrîn:

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

Wekî ku hûn dikarin bibînin, di vê wêneyê de em hemî karûbarên ku me bikar anîn da ku serlêdana xwe bicîh bikin saz dikin. Heya ku em li vir ne hewce ne kubectl, lê dibe ku hûn bixwazin di qonaxa sazkirina boriyê de pê re bilîzin.

Di heman demê de, ji bo ku em karibin bi Kubernetes re têkilî daynin û jê re bicîh bikin, pêdivî ye ku em ji bo podên ku ji hêla gitlab-runner ve têne hilberandin rolek mîheng bikin.

Ji bo vê yekê, em biçin pelrêça bi gitlab-runner:

cd deploy/gitlab-runner

û hêmanek nû lê zêde bike pêkhateyên/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,
      },
    ],
  },
]

Em ê di nav de pîvanên nû jî diyar bikin derdorên/base.libsonnet, ku niha bi vî rengî xuya dike:

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

Bawer bikin $.components.rbac.name behsa nav ji bo pêkhatê rbac

Ka em binihêrin ka çi guherî:

qbec diff default

û guhertinên me li Kubernetes bicîh bikin:

qbec apply default

Di heman demê de, ji bîr nekin ku guheztinên me li git bikin:

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. Yekem lûle û kombûna meya wêneyan ji hêla nîşanan ve

Di bingeha projeyê de em ê çêbikin .gitlab-ci.yml bi naveroka jêrîn:

.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

Ji kerema xwe bala xwe bidin ku em bikar tînin GIT_SUBMODULE_STRATEGY: normal ji bo wan karên ku hûn hewce ne ku berî darvekirinê bi eşkereyî binemodulan dest pê bikin.

Ji bîr nekin ku guhertinên me bikin:

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

Ez difikirim ku em dikarin bi ewlehî vê guhertoyek binav bikin v0.0.1 û tagê lê zêde bike:

git tag v0.0.1

Em ê etîketan lê zêde bikin her ku hewce bike ku guhertoyek nû derxînin. Etîketên di wêneyên Docker de dê bi etîketên Git ve werin girêdan. Her pêvekek bi tagek nû dê avakirina wêneyan bi vê tagê dest pê bike.

Werin em bikin git push --etîketan, û werin em li xeta xweya yekem binêrin:

Screenshot ji boriya yekem

Hêja ye ku bala we bikişîne ser vê yekê ku kombûna bi etîketan ji bo avakirina wêneyên dokerê maqûl e, lê ji bo bicîhkirina serîlêdanek li Kubernetes ne maqûl e. Ji ber ku etîketên nû dikarin li peywirên kevin werin danîn, di vê rewşê de, destpêkirina boriyê ji bo wan dê bibe sedema bicîhkirina guhertoya kevn.

Ji bo çareserkirina vê pirsgirêkê, bi gelemperî avakirina wêneyên docker bi nîşanan ve girêdayî ye, û bicîhkirina serîlêdanê li şaxek mamoste, ku tê de guhertoyên wêneyên berhevkirî bi hişk têne kod kirin. Li vir e ku hûn dikarin bi vegerandinek hêsan ve vegerandinê dest pê bikin mamoste- şaxên.

10. Xweseriya belavkirinê

Ji bo ku Gitlab-runner razên me veşêre, em ê hewce bikin ku mifteya depoyê derxînin û wê li guhêrbarên hawîrdora xweya CI-yê zêde bikin:

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

Em ê xeta encam li Gitlab hilînin; ji bo vê yekê, em biçin mîhengên projeya xwe:
Mîheng -> CI / CD -> Guherbar

Û em guherbarek nû biafirînin:

Awa
Qûfle
Giranî
parastin
Masked
di çarçoveya

File
GITCRYPT_KEY
<your string>
true (di dema perwerdeyê de hûn dikarin false)
true
All environments

Dîmena guherbara zêdekirî

Naha werin em xwe nûve bikin .gitlab-ci.yml lê zêde kirin:

.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

Li vir me ji bo qbec çend vebijarkên nû çalak kirine:

• - hindek/app root - dihêle hûn pelrêça serîlêdanek taybetî diyar bikin
• --force:k8s-context __incluster__ - ev guhêrbarek efsûnî ye ku dibêje ku bicîhkirin dê di heman komê de ku gtilab-runner tê de dixebite pêk were. Ev pêdivî ye ji ber ku wekî din qbec dê hewl bide ku di kubeconfig-a we de serverek Kubernetes-a minasib bibîne
• --payin - zorê dide qbec ku li bendê bimîne heya ku çavkaniyên ku ew diafirîne bikeve rewşa Amade û tenê dûv re bi kodek derketinê ya serfiraz derkeve.
• -erê - bi tenê şêlê înteraktîf asteng dike Piştrastin? dema belav kirin.

Ji bîr nekin ku guhertinên me bikin:

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

Û piştî git push em ê bibînin ka serlêdanên me çawa hatine bicîh kirin:

Dîmenê lûleya duyemîn

11. Artifacts û civîn dema ku ji bo masterê dehf dikin

Bi gelemperî, gavên ku li jor hatine destnîşan kirin ji bo avakirina û radestkirina hema hema her mîkroxizmetê bes in, lê em naxwazin her gava ku em hewce ne ku malperê nûve bikin etîketek zêde bikin. Ji ber vê yekê, em ê rêgezek dînamîktir bavêjin û di şaxê masterê de veqetandinek digest saz bikin.

Fikir hêsan e: niha wêneyê me malpera her gava ku hûn têxin hundur dê ji nû ve were çêkirin mamoste, û dûv re bixweber li Kubernetes bicîh bikin.

Ka em van her du karan di nav xwe de nûve bikin .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"

Ji kerema xwe not bikin ku me mijarek zêde kiriye mamoste к refs ji bo karan build_website û em niha bikar tînin $CI_COMMIT_REF_NAME li gorî $CI_COMMIT_TAG, ango, em ji etîketên Git veqetandî ne û naha em ê wêneyek bi navê şaxê commit ku boriyê dest pê kiriye bişopînin. Hêjayî gotinê ye ku ev ê bi etîketan re jî bixebite, ku dê bihêle ku em dîmenên malperek bi guhertoyek taybetî di doker-qeyda tomar bikin.

Gava ku navê etîketa dockerê ya ji bo guhertoyek nû ya malperê bê guheztin, em hîn jî neçar in ku guheztinên Kubernetes diyar bikin, wekî din ew ê bi hêsanî serîlêdanê ji wêneya nû ji nû ve neke, ji ber ku ew ê di nav wêneyê de ti guhertinan nebîne. eşkerekirina belavbûnê.

Dibe —vm:ext-str digest="$DIGEST" ji bo qbec - dihêle hûn guhêrbarek derveyî ji jsonnet re derbas bikin. Em dixwazin ku ew bi her serbestberdana serîlêdana me re di komê de ji nû ve were bicîh kirin. Em êdî nekarin navê etîketê bikar bînin, ku naha dikare bê guhêrbar be, ji ber ku pêdivî ye ku em bi guhertoyek taybetî ya wêneyê ve girêdayî bin û gava ku ew diguhezîne veqetandinê bişopînin.

Li vir em ê ji kapasîteya Kaniko re bibin alîkar ku wêneyek hûrgulî li pelek tomar bike (vebijark --digest-pel)
Dûv re em ê vê pelê veguhezînin û di dema danînê de bixwînin.

Ka em parametreyên xwe nûve bikin deploy/malper/hawirdor/base.libsonnet ku niha dê bi vî rengî xuya bike:

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

Qediya, niha her tedbîrek tê mamoste avakirina wêneya docker ji bo dest pê dike malpera, û paşê wê li Kubernetes bicîh bikin.

Ji bîr nekin ku guhertinên me bikin:

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

Em ê paşê kontrol bikin git push divê em tiştekî wiha bibînin:

Dîmenê boriyê ji bo master

Di prensîbê de, em ne hewce ne ku bi her pêvekê re gitlab-runner ji nû ve saz bikin, heya ku, bê guman, tiştek di veavakirina wê de neguheriye, em wê di nav de rast bikin. .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/**/*

guhertin dê destûrê bide we ku hûn guhertinên di nav de bişopînin deploy/gitlab-runner/ û tenê heke hebin dê karê me bide destpêkirin

Ji bîr nekin ku guhertinên me bikin:

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

git push, ev baştir e:

Dîmenê lûleya nûvekirî

12. Derdorên dînamîk

Wext e ku em xeta boriyê xwe bi hawîrdorên dînamîkî re cihêreng bikin.

Pêşîn, bila em kar nûve bikin build_website di me de .gitlab-ci.yml, rakirina blokê jê re bes, ku dê zorê bide Gitlab ku wê li ser her commitek ji her şaxek re bixebitîne:

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/

Dûv re kar nûve bikin deploy_website, blokek li wir zêde bike dor:

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"

Ev ê bihêle ku Gitlab bi kar re têkildar be çêkerî jîngehê û girêdana wê ya rast nîşan bide.

Naha em du karên din lê zêde bikin:

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

Ew ê li ser her şaxên ji bilî masterê werin destpêkirin û dê guhertoya pêşdîtinê ya malperê bicîh bikin.

Em ji bo qbec vebijarkek nû dibînin: --app-tag - ew dihêle hûn guhertoyên bicîhkirî yên serîlêdanê etîket bikin û tenê di hundurê vê tagê de bixebitin; dema ku çavkaniyên li Kubernetes çêbikin û hilweşînin, qbec dê tenê bi wan re bixebite.
Bi vî rengî em nekarin ji bo her vekolînê jîngehek cihê biafirînin, lê tenê heman yek ji nû ve bikar bînin.

Li vir em jî bikar tînin qbec serlêdana nirxandinê, di şona qbec standard bicîh bikin - ev tam ew kêlî ye ku em ê hewl bidin ku cûdahiyên ji bo hawîrdorên xwe diyar bikin (nirxandin û xwerû):

Em lê zêde bikin axaftin jîngehê di deploy/website/qbec.yaml

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

Wê demê em ê di nav de ragihînin 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

Û ji bo wê pîvanên xwerû binivîsin deploy/malper/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',
    },
  },
}

Werin em ji nêz ve li jobu jî binêrin stop_review, dema ku şax were jêbirin ew ê were xebitandin û ji ber ku gitlab neceribîne ku bişopîne ew tê bikar anîn GIT_STRATEGY: tune, paşê em klon dikin mamoste-şaxê û bi riya wê vekolînê jêbirin.
Ew hinekî tevlihev e, lê min hîn rêyek xweşiktir nedîtiye.
Vebijarkek alternatîf dê ev be ku her vekolînek li cîhek navek otêlê were bicîh kirin, ku her gav dikare bi tevahî were hilweşandin.

Ji bîr nekin ku guhertinên me bikin:

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

git push, git checkout -b test, git push test original, kontrol bikin:

Dîmenê derdorên ku li Gitlab hatine afirandin

Her tişt dixebite? - mezin, şaxê ceribandina me jêbirin: master git checkout, git push eslê :ceribandin, em kontrol dikin ku karên jêbirina jîngehê bêyî xeletî dixebitin.

Li vir ez dixwazim tavilê zelal bikim ku her pêşdebirek di projeyekê de dikare şaxan biafirîne, ew jî dikare biguhezîne .gitlab-ci.yml pel û gihîştina guherbarên veşartî.
Ji ber vê yekê, bi tundî tê pêşniyar kirin ku destûr bidin karanîna wan tenê ji bo şaxên parastî, mînakî di mamoste, an jî ji bo her hawîrdorê komek cûda cûda biafirînin.

13. Apps Review

Apps Review Ev taybetmendiyek GitLab-ê ye ku dihêle hûn ji bo her pelê di depoyê de bişkokek zêde bikin da ku bi lez wê li hawîrdorek belavkirî bibînin.

Ji bo ku ev bişkok xuya bibin, hûn hewce ne ku pelek çêbikin .gitlab/route-map.yml û hemî veguherînên rêgezê di wê de diyar bikin; di rewşa me de ew ê pir hêsan be:

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

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

Ji bîr nekin ku guhertinên me bikin:

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

git push, û kontrol bikin:

Dîmenê bişkojka App Review

Kar qediya!

Çavkaniyên projeyê:

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

Spas ji bo baldariya we, ez hêvî dikim ku we jê hez kir

Source: www.habr.com