Halò! O chionn ghoirid, chaidh mòran innealan fèin-ghluasaid fionnar a leigeil ma sgaoil an dà chuid airson ìomhaighean Docker a thogail agus airson an cleachdadh gu Kubernetes. A thaobh seo, chuir mi romham cluich timcheall le GitLab, sgrùdadh mionaideach a dhèanamh air na comasan aige agus, gu dearbh, an loidhne-phìoban a stèidheachadh.

Chaidh an obair seo a bhrosnachadh leis an làrach-lìn cubernetes.io, a tha air a ghineadh o còdan stòr gu fèin-ghluasadach, agus airson gach iarrtas amar a thèid a chuir a-steach, bidh an inneal-fuadain gu fèin-ghluasadach a’ gineadh dreach ro-shealladh den làrach leis na h-atharrachaidhean agad agus a ’toirt seachad ceangal airson coimhead.

Dh’ fheuch mi ri pròiseas coltach ris a thogail bhon toiseach, ach air a thogail gu tur air Gitlab CI agus innealan an-asgaidh a tha mi cleachdte ri bhith a’ cleachdadh gus tagraidhean a chuir gu Kubernetes. An-diugh innsidh mi dhut mu dheireadh mun deidhinn.

Beachdaichidh an artaigil air innealan leithid:
Hugo, qbec, cainneach, git-crypt и GitLab CI le cruthachadh àrainneachdan fiùghantach.

Susbaint

1. Coinnich ri Hugo
2. Ag ullachadh an Dockerfile
3. A’ faighinn eòlas air kaniko
4. A 'faighinn eòlas air qbec
5. A’ feuchainn Gitlab-runner le Kubernetes-tiomnaidh
6. A’ cleachdadh chlàran Helm le qbec
7. A’ toirt a-steach git-crypt
8. A 'cruthachadh ìomhaigh bogsa innealan
9. A’ chiad loidhne-phìoban againn agus co-chruinneachadh dhealbhan le tagaichean
10. Automation cleachdadh
11. Artifacts agus co-chruinneachadh nuair a thathar a 'putadh gu maighstir
12. Àrainneachdan fiùghantach
13. Dèan lèirmheas air Apps

1. A' faighinn eòlas air Hugo

Mar eisimpleir den phròiseact againn, feuchaidh sinn ri làrach foillseachaidh sgrìobhainnean a chruthachadh a chaidh a thogail air Hugo. Tha Hugo na ghineadair susbaint statach.

Dhaibhsan nach eil eòlach air gineadairean statach, innsidh mi beagan a bharrachd dhut mun deidhinn. Eu-coltach ri einnseanan àbhaisteach làrach-lìn le stòr-dàta agus cuid de PHP, a bhios, nuair a dh'iarras neach-cleachdaidh, a 'gineadh duilleagan air an itealan, tha gineadairean statach air an dealbhadh beagan eadar-dhealaichte. Leigidh iad leat stòran a ghabhail, mar as trice seata de fhaidhlichean ann an comharrachadh Markdown agus teamplaidean cuspair, agus an uairsin gan cur ri chèile gu làrach-lìn gu tur deiseil.

Is e sin, mar thoradh air an sin, gheibh thu structar eòlaire agus seata de fhaidhlichean HTML gineadh, as urrainn dhut dìreach a luchdachadh suas gu aoigheachd saor sam bith agus làrach-lìn obrach fhaighinn.

Faodaidh tu Hugo a stàladh gu h-ionadail agus feuch e:

A’ tòiseachadh làrach ùr:

hugo new site docs.example.org

Agus aig an aon àm an stòr git:

cd docs.example.org
git init

Gu ruige seo, tha an làrach againn pristine agus gus an nochd rudeigin air, feumaidh sinn an toiseach cuspair a cheangal; chan eil ann an cuspair ach seata de theamplaidean agus riaghailtean sònraichte a rèir a bheil an làrach againn air a chruthachadh.

Airson an cuspair a chleachdas sinn Ionnsaich, a tha, nam bheachd-sa, gu math freagarrach airson làrach sgrìobhainnean.

Bu mhath leam aire shònraichte a thoirt don fhìrinn nach fheum sinn na faidhlichean cuspair a shàbhaladh anns an stòr pròiseict againn; an àite sin, is urrainn dhuinn dìreach a cheangal le bhith a ’cleachdadh fo-mhodal git:

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

Mar sin, cha bhi anns an stòr-tasgaidh againn ach faidhlichean a tha dìreach co-cheangailte ris a’ phròiseact againn, agus bidh an cuspair ceangailte fhathast mar cheangal ri stòr sònraichte agus gealltanas ann, is e sin, faodar an-còmhnaidh a tharraing bhon stòr thùsail agus na biodh eagal ort. atharrachaidhean neo-fhreagarrach.

Nach cuir sinn ceart an config config.toml:

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

A-cheana aig an ìre seo faodaidh tu ruith:

hugo server

Agus aig an t-seòladh http://localhost:1313/ thoir sùil air an làrach-lìn againn a chaidh a chruthachadh às ùr, bidh a h-uile atharrachadh a chaidh a dhèanamh san eòlaire ag ùrachadh duilleag fosgailte sa bhrobhsair gu fèin-ghluasadach, gu math goireasach!

Feuchaidh sinn ri duilleag còmhdaich a chruthachadh a-steach susbaint/_index.md:

# My docs site

## Welcome to the docs!

You will be very smart :-)

Glacadh-sgrìn den duilleag a chaidh a chruthachadh às ùr

Gus làrach-lìn a chruthachadh, dìreach ruith:

hugo

Clàr-innse susbaint poblach/ agus bidh e na làrach-lìn agad.
Tha, leis an t-slighe, leig leinn sa bhad a chuir ris .gitnore:

echo /public > .gitignore

Na dì-chuimhnich na h-atharrachaidhean againn a dhèanamh:

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

2. Ag ullachadh an Dockerfile

Tha an t-àm ann structar ar stòr-tasgaidh a mhìneachadh. Mar as trice bidh mi a’ cleachdadh rudeigin mar:

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

• faidhlichean docker/ - bidh clàran ann le Dockerfiles agus a h-uile dad a tha riatanach airson na h-ìomhaighean Docker againn a thogail.
• cleachdadh/ - tha clàran ann airson na tagraidhean againn a chuir gu Kubernetes

Mar sin, cruthaichidh sinn a’ chiad Dockerfile againn air an t-slighe dockerfiles/làrach-lìn/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" ]

Mar a chì thu, tha dhà anns an Dockerfile BHO BHO, goirear an cothrom so togail ioma-ìre agus leigidh e leat a h-uile dad neo-riatanach a chuir a-mach às an ìomhaigh docker mu dheireadh.
Mar sin, cha bhi ann ach an dealbh mu dheireadh dorchahttpd (frithealaiche HTTP aotrom) agus poblach/ - susbaint na làraich-lìn againn a chaidh a chruthachadh gu statach.

Na dì-chuimhnich na h-atharrachaidhean againn a dhèanamh:

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

3. A' faighinn eòlas air kaniko

Mar neach-togail ìomhaighean docker, chuir mi romham a chleachdadh cainneach, leis nach eil feum aig an obair aige air daemon docker, agus faodar an togail fhèin a dhèanamh air inneal sam bith agus faodar an tasgadan a stòradh gu dìreach sa chlàr, agus mar sin cuir às don fheum air stòradh leantainneach làn-chuimseach.

Gus an ìomhaigh a thogail, dìreach ruith an soitheach le neach-tiomnaidh kaniko agus thoir seachad an co-theacsa togail gnàthach; faodar seo a dhèanamh gu h-ionadail cuideachd, tro 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

Càite registry.gitlab.com/kvaps/docs.example.org/website - ainm an ìomhaigh docker agad; às deidh a thogail, thèid a chuir air bhog gu fèin-ghluasadach ann an clàr an docker.

Parameter --cache a’ leigeil leat sreathan a thasgadh ann an clàr an docker; mar eisimpleir a chaidh a thoirt seachad, thèid an sàbhaladh a-steach registry.gitlab.com/kvaps/docs.example.org/website/cache, ach faodaidh tu slighe eile a shònrachadh a’ cleachdadh am paramadair --cache-repo.

Glacadh-sgrìn de docker-registry

4. A' faighinn eòlas qbec

Qbec na inneal cleachdadh a leigeas leat cunntas dearbhach a dhèanamh air na taisbeanaidhean tagraidh agad agus an cur gu Kubernetes. Le bhith a’ cleachdadh Jsonnet mar am prìomh cho-chòrdadh leigidh sin leat an tuairisgeul air eadar-dhealachaidhean thar ioma àrainneachdan a dhèanamh nas sìmplidhe, agus cuideachd cuir às do ath-aithris còd cha mhòr gu tur.

Faodaidh seo a bhith gu sònraichte fìor ann an cùisean far am feum thu tagradh a chuir gu grunn chlàran le diofar pharaimearan agus gu bheil thu airson cunntas dearbhach a thoirt orra ann an Git.

Leigidh Qbec leat clàran Helm a thoirt seachad le bhith a’ toirt seachad na crìochan riatanach dhaibh agus an uairsin gan obrachadh san aon dòigh ri taisbeanaidhean cunbhalach, a’ toirt a-steach faodaidh tu diofar mùthaidhean a chuir an sàs annta, agus leigidh seo leat, an uair sin, faighinn cuidhteas an fheum air Cleachd Taigh-tasgaidh Chart. Is e sin, faodaidh tu clàran a stòradh agus a thoirt seachad gu dìreach bho git, far a bheil iad.

Mar a thuirt mi na bu thràithe, stòraidh sinn a h-uile cleachdadh ann an eòlaire cleachdadh/:

mkdir deploy
cd deploy

Tòisichidh sinn a’ chiad iarrtas againn:

qbec init website
cd website

A-nis tha structar an tagraidh againn a’ coimhead mar seo:

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

leig dhuinn coimhead air an fhaidhle qbec.yaml:

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

An seo tha ùidh againn sa mhòr-chuid sònrachaidhean, Tha qbec mu thràth air àrainneachd bunaiteach a chruthachadh dhuinn agus thug e seòladh an fhrithealaiche, a bharrachd air namespace bhon kubeconfig gnàthach againn.
A-nis nuair a thèid a chuir gu default àrainneachd, bidh qbec an-còmhnaidh a’ cleachdadh dìreach don bhuidheann Kubernetes ainmichte agus chun àite-ainm ainmichte, is e sin, chan fheum thu tuilleadh gluasad eadar co-theacsan agus àiteachan ainmean gus an cleachdadh.
Ma tha feum air, faodaidh tu an-còmhnaidh na roghainnean san fhaidhle seo ùrachadh.

Tha na h-àrainneachdan agad uile air am mìneachadh ann an qbec.yaml, agus anns an fhaidhle params.libsonnet, far a bheil e ag innse càite am faigh iad na crìochan dhaibh.

An ath rud chì sinn dà chlàr:

• co-phàirtean / - thèid a h-uile manifesto airson an tagraidh againn a stòradh an seo; faodar cunntas a thoirt orra an dà chuid ann am faidhlichean jsonnet agus cunbhalach yaml
• àrainneachdan/ - an seo bheir sinn cunntas air na caochladairean (parameatairean) airson na h-àrainneachdan againn.

Gu gnàthach tha dà fhaidhle againn:

• àrainneachdan/base.libsonnet - bidh crìochan coitcheann ann airson a h-uile àrainneachd
• àrainneachdan/default.libsonnet - a’ toirt a-steach paramadairean air an toirt thairis airson na h-àrainneachd default

fosgail sinn àrainneachdan/base.libsonnet agus cuir crìochan airson a’ chiad phàirt againn an sin:

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

Cruthaichidh sinn a’ chiad phàirt againn cuideachd co-phàirtean/làrach-lìn.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,
                },
              },
            ],
          },
        },
      ],
    },
  },
]

Anns an fhaidhle seo thug sinn cunntas air trì buidhnean Kubernetes aig an aon àm, is iad sin: Cleachdadh, seirbheis и Ingress. Nam biodh sinn ag iarraidh, dh'fhaodadh sinn an cur ann an diofar phàirtean, ach aig an ìre seo bidh aon gu leòr dhuinn.

sheantansan jsonnet glè choltach ri json cunbhalach, ann am prionnsapal, tha json cunbhalach mar-thà dligheach jsonnet, agus mar sin an toiseach is dòcha gum bi e nas fhasa dhut seirbheisean air-loidhne a chleachdadh mar aml2json gus an yaml àbhaisteach agad a thionndadh gu json, no, mura h-eil caochladairean sam bith anns na co-phàirtean agad, faodar an ainmeachadh ann an cruth yaml cunbhalach.

Nuair a bhios tu ag obair le jsonnet Tha mi gu mòr a’ moladh plugan a stàladh airson an deasaiche agad

Mar eisimpleir, tha plugan ann airson vim vim-jsonnet, a thionndaidheas soilleireachadh co-chòrdadh agus a chuireas gu bàs gu fèin-ghluasadach jsonnet fmt gach turas a shàbhaileas tu (feumar jsonnet a chuir a-steach).

Tha a h-uile dad deiseil, a-nis is urrainn dhuinn tòiseachadh a ’cleachdadh:

Gus faicinn dè fhuair sinn, ruithidh sinn:

qbec show default

Aig an toradh, chì thu taisbeanaidhean yaml air an toirt seachad a thèid a chuir a-steach don bhuidheann àbhaisteach.

Sgoinneil, cuir a-steach a-nis:

qbec apply default

Aig an toradh chì thu an-còmhnaidh dè a thèid a dhèanamh sa bhuidheann agad, iarraidh qbec ort aontachadh ris na h-atharrachaidhean le bhith a’ taipeadh y bidh e comasach dhut do rùintean a dhearbhadh.

Tha an tagradh againn deiseil agus air a chuir a-steach!

Ma nì thu atharrachaidhean, faodaidh tu an-còmhnaidh a dhèanamh:

qbec diff default

gus faicinn mar a bheir na h-atharrachaidhean sin buaidh air cleachdadh làithreach

Na dì-chuimhnich na h-atharrachaidhean againn a dhèanamh:

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

5. A 'feuchainn Gitlab-ruitheadair le Kubernetes-tiomnaidh

Gu ruige o chionn ghoirid cha robh mi a’ cleachdadh ach cunbhalach gitlab-ruith air inneal ro-ullaichte (soitheach LXC) le slige no neach-tiomnaidh docker. An toiseach, bha grunn ruitheadairean mar sin air am mìneachadh air feadh na cruinne nar gitlab. Chruinnich iad ìomhaighean docker airson a h-uile pròiseact.

Ach mar a tha cleachdadh air sealltainn, chan eil an roghainn seo as fheàrr, an dà chuid a thaobh practaigeach agus sàbhailteachd. Tha e tòrr nas fheàrr agus nas ideòlach a bhith ceart ruitheadairean fa leth a bhith air an cleachdadh airson gach pròiseact, no eadhon airson gach àrainneachd.

Gu fortanach, chan eil seo na dhuilgheadas idir, oir a-nis bidh sinn ga chleachdadh gitlab-ruith gu dìreach mar phàirt den phròiseact againn ceart ann an Kubernetes.

Tha Gitlab a’ toirt seachad clàr-stiùiridh deiseil airson a bhith a’ cleachdadh ruitheadair gitlab gu Kubernetes. Mar sin chan eil agad ach faighinn a-mach tòcan clàraidh airson ar pròiseact ann an Settings -> CI / CD -> Runners agus cuir thairis e gu stiùir:

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

Càite:

• https://gitlab.com - seòladh an t-seirbheisiche Gitlab agad.
• yga8y-jdCusVDn_t4Wxc - comharra clàraidh airson do phròiseact.
• rbac.create = fìor - a’ toirt na h-uiread de shochairean don ruitheadair gus a bhith comasach air pods a chruthachadh gus ar gnìomhan a choileanadh a’ cleachdadh kubernetes-executor.

Ma thèid a h-uile càil a dhèanamh ceart, bu chòir dhut ruitheadair clàraichte fhaicinn san roinn Runners, anns na roghainnean pròiseict agad.

Glacadh-sgrìn den ruitheadair a bharrachd

A bheil e cho sìmplidh sin? - tha, tha e cho sìmplidh sin! Cha bhith barrachd duilgheadas ann le bhith a’ clàradh ruitheadairean le làimh, bho seo a-mach thèid ruitheadairean a chruthachadh agus a sgrios gu fèin-ghluasadach.

6. Cleachd clàran Helm le QBEC

Bhon a chuir sinn romhainn beachdachadh gitlab-ruith mar phàirt den phròiseact againn, tha an t-àm ann cunntas a thoirt air anns an stòr Git againn.

Dh’ fhaodadh sinn a mhìneachadh mar phàirt air leth Bidh, ach san àm ri teachd tha sinn an dùil lethbhric eadar-dhealaichte a chleachdadh Bidh glè thric, eu-coltach gitlab-ruith, a thèid a chleachdadh dìreach aon turas gach buidheann Kubernetes. Mar sin tòisichidh sinn tagradh air leth air a shon:

cd deploy
qbec init gitlab-runner
cd gitlab-runner

An turas seo cha toir sinn cunntas air buidhnean Kubernetes le làimh, ach gabhaidh sinn cairt Helm deiseil. Is e aon de na buannachdan aig qbec an comas clàran Helm a thoirt seachad gu dìreach bho stòr Git.

Nach ceangail sinn e le bhith a’ cleachdadh git submodule:

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

A-nis an eòlaire reiceadair/gitlab-runner Tha stòr againn le clàr airson gitlab-runner.

San aon dòigh, faodaidh tu stòran eile a cheangal, mar eisimpleir, an stòr gu lèir le clàran oifigeil https://github.com/helm/charts

Bheir sinn cunntas air a 'phàirt co-phàirtean/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,
  }
)

A ' chiad argamaid a leudaichHelmTemplate thèid sinn seachad air an t-slighe chun a 'chlàir, an uairsin params.values, a bheir sinn bho pharaimearan na h-àrainneachd, an uairsin thig an nì leis

• ainm Teamplaid - tiotal foillseachaidh
• ainm-àite - ainm-àite air a ghluasad gu stiùir
• am faidhle seo - paramadair riatanach a thèid seachad air an t-slighe chun fhaidhle gnàthach
• gnìomhair - a 'sealltainn an àithne teamplaid stiùir leis na h-argamaidean uile nuair a thathar a’ toirt seachad a’ chairt

A-nis bheir sinn cunntas air na crìochan airson ar pàirt ann àrainneachdan/base.libsonnet:

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

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

Thoir aire ruitheadairRegistrationToken bheir sinn à faidhle taobh a-muigh dìomhaireachdan/base.libsonnet, cruthaichidh sinn e:

{
  runnerRegistrationToken: 'yga8y-jdCusVDn_t4Wxc',
}

Feuch an dèan sinn cinnteach a bheil a h-uile càil ag obair:

qbec show default

ma tha a h-uile càil ann an òrdugh, is urrainn dhuinn an sgaoileadh a chaidh a chleachdadh roimhe seo a dhubhadh às tro Helm:

helm uninstall gitlab-runner

agus cuir an gnìomh e san aon dòigh, ach tro qbec:

qbec apply default

7. Ro-ràdh gu git-crypt

Git-crypt na inneal a leigeas leat crioptachadh follaiseach a stèidheachadh airson do stòr.

Aig an àm seo, tha an structar eòlaire againn airson gitlab-runner a’ coimhead mar seo:

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

Ach chan eil e sàbhailte dìomhaireachdan a stòradh ann an Git, an e? Mar sin feumaidh sinn an crioptachadh gu ceart.

Mar as trice, air sgàth aon chaochladair, chan eil seo daonnan a 'dèanamh ciall. Faodaidh tu dìomhaireachdan a ghluasad gu qbec agus tro chaochladairean àrainneachd an t-siostam CI agad.
Ach is fhiach a bhith mothachail gu bheil pròiseactan nas iom-fhillte ann cuideachd anns am faod mòran a bharrachd dìomhaireachdan a bhith ann; bidh e air leth duilich an gluasad gu lèir tro chaochladairean àrainneachd.

A bharrachd air an sin, anns a 'chùis seo cha b' urrainn dhomh innse dhut mu inneal cho iongantach git-crypt.

git-crypt Tha e cuideachd goireasach leis gu bheil e a’ toirt cothrom dhut eachdraidh iomlan dìomhaireachdan a shàbhaladh, a bharrachd air coimeas a dhèanamh, tighinn còmhla agus còmhstrithean fhuasgladh san aon dòigh ’s a tha sinn cleachdte ri bhith a’ dèanamh ann an cùis Git.

A 'chiad rud às deidh an stàladh git-crypt feumaidh sinn iuchraichean a ghineadh airson ar stòr:

git crypt init

Ma tha iuchair PGP agad, faodaidh tu thu fhèin a chuir ris sa bhad mar cho-obraiche airson a’ phròiseict seo:

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

San dòigh seo faodaidh tu an-còmhnaidh an stòr-dàta seo a dhì-chrioptachadh leis an iuchair phrìobhaideach agad.

Mura h-eil iuchair PGP agad agus nach eil dùil agad ris, faodaidh tu a dhol an rathad eile agus iuchair a’ phròiseict às-mhalairt:

git crypt export-key /path/to/keyfile

Mar sin, neach sam bith aig a bheil às-mhalairt iuchrach bidh e comasach dhut an stòr-dàta agad a dhì-chrioptachadh.

Tha an t-àm ann a’ chiad dìomhaireachd againn a stèidheachadh.
Leig leam do chuimhneachadh gu bheil sinn fhathast san eòlaire cleachdadh/gitlab-runner/, far a bheil eòlaire againn dìomhaireachdan/, crioptaichidh sinn a h-uile faidhle a tha ann, airson seo cruthaichidh sinn faidhle dìomhaireachdan/.gitatributes leis an t-susbaint a leanas:

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

Mar a chithear bhon t-susbaint, tha na faidhlichean uile air am falach * thèid a stiùireadh troimhe git-crypt, ach a mhàin a' mhòr-chuid .gittributes

Faodaidh sinn seo a sgrùdadh le bhith a’ ruith:

git crypt status -e

Bidh an toradh na liosta de na faidhlichean uile san stòr far a bheil crioptachadh air a chomasachadh

Sin uile, a-nis is urrainn dhuinn na h-atharrachaidhean againn a ghealltainn gu sàbhailte:

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

Gus casg a chuir air stòr, dìreach ruith:

git crypt lock

agus sa bhad tionndaidh a h-uile faidhle crioptaichte gu rudeigin dà-chànanach, bidh e do-dhèanta an leughadh.
Gus an stòr-dàta a dhì-chrioptachadh, ruith:

git crypt unlock

8. Cruthaich ìomhaigh bogsa innealan

Is e ìomhaigh bogsa inneal ìomhaigh leis na h-innealan gu lèir a chleachdas sinn gus ar pròiseact a chuir an gnìomh. Thèid a chleachdadh leis an ruitheadair Gitlab gus gnìomhan cleachdadh àbhaisteach a dhèanamh.

Tha a h-uile dad sìmplidh an seo, cruthaichidh sinn fear ùr faidhlichean docker / bogsa inneal / Dockerfile leis an t-susbaint a leanas:

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

Mar a chì thu, san ìomhaigh seo bidh sinn a’ stàladh a h-uile goireas a chleachd sinn airson an tagradh againn a chleachdadh. Chan eil feum againn air an seo mura h-eil cubectl, ach is dòcha gum bi thu airson cluich leis aig àm stèidheachadh na loidhne-phìoban.

Cuideachd, gus a bhith comasach air conaltradh le Kubernetes agus a chleachdadh, feumaidh sinn àite a dhealbhadh airson na pods a ghineadh le gitlab-runner.

Gus seo a dhèanamh, rachamaid chun an eòlaire le gitlab-runner:

cd deploy/gitlab-runner

agus cuir pìos ùr ris co-phàirtean/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,
      },
    ],
  },
]

Bheir sinn cunntas cuideachd air na paramadairean ùra ann an àrainneachdan/base.libsonnet, a tha a-nis coltach ri seo:

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

Thoir aire $.components.rbac.ainm a' toirt iomradh air ainm airson co-phàirt rbac

Feuch an dèan sinn sgrùdadh air na tha air atharrachadh:

qbec diff default

agus cuir na h-atharrachaidhean againn an sàs ann an Kubernetes:

qbec apply default

Cuideachd, na dìochuimhnich na h-atharrachaidhean againn a dhèanamh air git:

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. A 'chiad loidhne-phìoban againn agus co-chruinneachadh de dhealbhan le tagaichean

Aig cridhe a’ phròiseict cruthaichidh sinn .gitlab-ci.yml leis an t-susbaint a leanas:

.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

Thoir an aire gu bheil sinn a’ cleachdadh GIT_SUBMODULE_STRATEGY: àbhaisteach airson na h-obraichean sin far am feum thu fo-mhodalan a thòiseachadh gu soilleir mus tèid an cur gu bàs.

Na dì-chuimhnich na h-atharrachaidhean againn a dhèanamh:

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

Tha mi a’ smaoineachadh gun urrainn dhuinn seo a ghairm gu sàbhailte mar dhreach v0.0.1 agus cuir ris an taga:

git tag v0.0.1

Cuiridh sinn tagaichean ris nuair a dh’ fheumas sinn dreach ùr fhoillseachadh. Bidh tagaichean ann an ìomhaighean Docker ceangailte ri tagaichean Git. Tòisichidh gach putadh le taga ùr togail ìomhaighean leis an taga seo.

Dèanamaid e git push --tags, agus leig dhuinn sùil a thoirt air a’ chiad loidhne-phìoban againn:

Glacadh-sgrìn den chiad loidhne-phìoban

Is fhiach d ’aire a tharraing gu bheil co-chruinneachadh le tagaichean freagarrach airson ìomhaighean docker a thogail, ach nach eil e freagarrach airson tagradh a chuir gu Kubernetes. Leis gum faod tagaichean ùra a bhith air an sònrachadh do sheann gheallaidhean, anns a’ chùis seo, ma thèid an loidhne-phìoban a thòiseachadh dhaibh thèid an seann dreach a chleachdadh.

Gus an duilgheadas seo fhuasgladh, mar as trice bidh togail ìomhaighean docker ceangailte ri tagaichean, agus cleachdadh an tagraidh gu meur mhaighstir, anns a bheil dreachan de na h-ìomhaighean cruinnichte air an còdadh cruaidh. Seo far an urrainn dhut tilleadh air ais a thòiseachadh le tilleadh sìmplidh mhaighstir-meuran.

10. Automation cleachdadh

Gus an urrainn do Gitlab-runner na dìomhaireachdan againn a dhì-chrioptachadh, feumaidh sinn an iuchair tasgaidh às-mhalairt agus a chuir ris na caochladairean àrainneachd CI againn:

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

Sàbhailidh sinn an loidhne a thig às ann an Gitlab; gus seo a dhèanamh, rachamaid gu na roghainnean pròiseict againn:
Roghainnean -> CI / CD -> Caochlaidhean

Agus cruthaichidh sinn caochladair ùr:

Type
prìomh
luach
Dìon
falach
farsaingeachd

File
GITCRYPT_KEY
<your string>
true (rè an trèanaidh faodaidh tu false)
true
All environments

Glacadh-sgrìn den chaochladair a bharrachd

A-nis ùraich sinn ar .gitlab-ci.yml a' cur ris:

.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

An seo tha sinn air grunn roghainnean ùra a chomasachadh airson qbec:

• --root cuid/app - a’ leigeil leat eòlaire tagradh sònraichte a dhearbhadh
• --force:k8s-co-theacsa __incluster__ - is e caochladair draoidheil a tha seo a tha ag ràdh gun tachair an cleachdadh anns an aon bhuidheann anns a bheil gtilab-runner a’ ruith. Tha seo riatanach oir air dhòigh eile feuchaidh qbec ri frithealaiche Kubernetes iomchaidh a lorg anns an kubeconfig agad
• - - feitheamh - a’ toirt air qbec feitheamh gus an tèid na goireasan a chruthaicheas e a-steach don stàit Ready agus dìreach an uairsin falbh le còd fàgail soirbheachail.
• -Tha - dìreach cuir à comas an t-slige eadar-ghnìomhach A bheil thu cinnteach? nuair a thèid a chleachdadh.

Na dì-chuimhnich na h-atharrachaidhean againn a dhèanamh:

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

Agus às deidh putadh git chì sinn mar a tha na tagraidhean againn air an cleachdadh:

Glacadh-sgrìn den dàrna loidhne-phìoban

11. Artifacts agus co-chruinneachadh nuair a tha thu a 'putadh gu maighstir

Mar as trice, tha na ceumannan a tha air am mìneachadh gu h-àrd gu leòr airson cha mhòr microservice sam bith a thogail agus a lìbhrigeadh, ach chan eil sinn airson tag a chuir ris a h-uile uair a dh’ fheumas sinn an làrach ùrachadh. Mar sin, gabhaidh sinn slighe nas beothaile agus cuiridh sinn air dòigh cleachdadh cnàmhaidh anns a’ phrìomh mheur.

Tha am beachd sìmplidh: a-nis tha an ìomhaigh againn Bidh thèid ath-thogail a h-uile uair a phut thu a-steach mhaighstir, agus an uairsin cuir gu fèin-ghluasadach gu Kubernetes.

Nach ùraich sinn an dà obair seo nar .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"

Thoir an aire gu bheil sinn air snàithlean a chuir ris mhaighstir к refs airson obraichean làrach-lìn togail_ agus tha sinn a-nis a 'cleachdadh $CI_COMMIT_REF_NAME an àite $CI_COMMIT_TAG, is e sin, tha sinn air ar ceangal bho tagaichean ann an Git agus a-nis bidh sinn a 'putadh ìomhaigh le ainm a' mheur gealltanas a thòisich an loidhne-phìoban. Is fhiach a bhith mothachail gun obraich seo le tagaichean cuideachd, a leigeas leinn dealbhan de làrach a shàbhaladh le dreach sònraichte anns an docker-registry.

Nuair a dh’ fhaodas ainm an taga docker airson dreach ùr den làrach a bhith gun atharrachadh, feumaidh sinn fhathast cunntas a thoirt air na h-atharrachaidhean air Kubernetes, air neo cha bhith e dìreach ag ath-shuidheachadh an tagraidh bhon ìomhaigh ùr, leis nach mothaich e atharrachaidhean sam bith san cleachdadh follaiseach.

Roghainn —vm: ext-str digest =”$ DIGEST” airson qbec - a’ leigeil leat caochladair taobh a-muigh a chuir gu jsonnet. Tha sinn ag iarraidh sin le gach foillseachadh den tagradh againn gun tèid a chuir a-steach don bhuidheann. Chan urrainn dhuinn an t-ainm taga a chleachdadh tuilleadh, rud a dh’ fhaodadh a bhith gun atharrachadh a-nis, oir feumaidh sinn a bhith ceangailte ri dreach sònraichte den ìomhaigh agus an cleachdadh a bhrosnachadh nuair a dh’ atharraicheas e.

An seo bidh sinn air ar cuideachadh le comas Kaniko ìomhaigh chnàmh a shàbhaladh gu faidhle (roghainn --digest-faidhle)
An uairsin gluaisidh sinn am faidhle seo agus leughaidh sinn e aig àm an cleachdadh.

Nach ùraich sinn na paramadairean airson ar cleachdadh/làrach-lìn/àrainneachd/base.libsonnet a bhios a-nis coltach ri seo:

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

Dèanta, a-nis gealladh sam bith a-steach mhaighstir a’ tòiseachadh togail ìomhaigh docker airson Bidh, agus an uairsin cuir gu Kubernetes e.

Na dì-chuimhnich na h-atharrachaidhean againn a dhèanamh:

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

Nì sinn sgrùdadh nas fhaide air adhart putadh git bu chòir dhuinn rudeigin mar seo fhaicinn:

Glacadh-sgrìn den loidhne-phìoban airson maighstir

Ann am prionnsapal, chan fheum sinn ruitheadair gitlab ath-shuidheachadh le gach putadh, mura h-eil, gu dearbh, air atharrachadh san rèiteachadh aige, leig dhuinn a chàradh a-steach. .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/**/*

atharrachaidhean a leigeas leat sùil a chumail air atharrachaidhean ann an cleachdadh/gitlab-runner/ agus bheir e air adhart ar n-obair a-mhàin ma tha gin ann

Na dì-chuimhnich na h-atharrachaidhean againn a dhèanamh:

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

putadh git, tha sin nas fheàrr:

Glacadh-sgrìn den loidhne-phìoban ùraichte

12. Dynamic àrainneachdan

Tha an t-àm ann ar loidhne-phìoban iomadachadh le àrainneachdan fiùghantach.

An toiseach, leig dhuinn an obair ùrachadh làrach-lìn togail_ nar .gitlab-ci.yml, a 'toirt air falbh a' bhloc bhuaithe a-mhàin, a bheir air Gitlab a bhrosnachadh air gealltanas sam bith gu meur sam bith:

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/

An uairsin ùraich an obair làrach-lìn cleachdadh_, cuir bloc an sin àrainneachd:

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"

Leigidh seo le Gitlab an obair a cheangal ri prod àrainneachd agus seall an ceangal ceart ris.

A-nis cuiridh sinn dà obair eile ris:

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

Thèid an cur air bhog nuair a thèid iad gu meuran sam bith ach maighstir agus cleachdaidh iad an dreach ro-shealladh den làrach.

Chì sinn roghainn ùr airson qbec: --app-tag - leigidh e leat tionndaidhean cleachdte den tagradh a tagadh agus obrachadh taobh a-staigh an taga seo a-mhàin; nuair a bhios tu a’ cruthachadh agus a’ sgrios ghoireasan ann an Kubernetes, cha bhith qbec ag ​​obair leotha ach.
San dòigh seo chan urrainn dhuinn àrainneachd air leth a chruthachadh airson gach lèirmheas, ach dìreach ath-chleachdadh an aon fhear.

An seo tha sinn cuideachd a 'cleachdadh qbec tagradh ath-bhreithneachadh, An àite qbec cuir an gnìomh bunaiteach - is e seo an dearbh mhionaid nuair a dh’ fheuchas sinn ri cunntas a thoirt air na h-eadar-dhealachaidhean airson ar n-àrainneachdan (lèirmheas agus bunaiteach):

Cuiridh sinn ath-bhreithneachadh àrainneachd ann an cleachdadh/làrach-lìn/qbec.yaml

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

An uairsin cuiridh sinn an cèill e a-steach cleachdadh/làrach-lìn/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

Agus sgrìobh sìos na crìochan àbhaisteach air a shon ann cleachdadh/làrach-lìn/àrainneachd/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',
    },
  },
}

Bheir sinn cuideachd sùil nas mionaidiche air jobu stad_lèirmheas, thèid a phiobrachadh nuair a thèid am meur a sguabadh às agus gus nach bi gitlab a’ feuchainn ri faighinn a-mach gu bheil e air a chleachdadh GIT_STRATEGY: gin, nas fhaide air adhart bidh sinn a’ clonadh mhaighstir-branch agus sguab às lèirmheas troimhe.
Tha e rud beag troimh-chèile, ach chan eil mi air dòigh nas bòidhche a lorg fhathast.
B’ e roghainn eile gach lèirmheas a chuir gu àite ainm taigh-òsta, a dh’ fhaodar a leagail gu tur an-còmhnaidh.

Na dì-chuimhnich na h-atharrachaidhean againn a dhèanamh:

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

putadh git, git checkout -b deuchainn, deuchainn tùs git push, seic:

Glacadh-sgrìn de àrainneachdan cruthaichte ann an Gitlab

A bheil a h-uile càil ag obair? - sgoinneil, cuir às don mheur deuchainn againn: sgaoileadh, git push tùs: deuchainn, tha sinn a 'dèanamh cinnteach gun robh an àrainneachd a sguabadh às obraichean ag obair gun mhearachdan.

An seo bu mhath leam soilleireachadh sa bhad gum faod leasaiche sam bith ann am pròiseact geugan a chruthachadh, faodaidh e cuideachd atharrachadh .gitlab-ci.yml faidhle agus cothrom fhaighinn air caochladairean dìomhair.
Mar sin, thathas a’ moladh gu làidir an cleachdadh a cheadachadh a-mhàin airson geugan dìonta, mar eisimpleir ann an mhaighstir, no cruthaich seata caochladairean fa leth airson gach àrainneachd.

13. Apps lèirmheas

Dèan lèirmheas air Apps Is e feart GitLab a tha seo a leigeas leat putan a chuir ris airson gach faidhle san stòr gus fhaicinn gu sgiobalta ann an àrainneachd a tha air a chleachdadh.

Gus an nochd na putanan sin, feumaidh tu faidhle a chruthachadh .gitlab/slighe-mapa.yml agus thoir cunntas air a h-uile cruth-atharrachadh slighe innte; nar cùis bidh e gu math sìmplidh:

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

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

Na dì-chuimhnich na h-atharrachaidhean againn a dhèanamh:

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

putadh git, agus thoir sùil air:

Glacadh-sgrìn den phutan Review App

Tha an obair deiseil!

Stòran pròiseict:

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

Tapadh leibh airson an aire agad, tha mi an dòchas gun do chòrd e riut

Source: www.habr.com