Habari! Hivi majuzi, zana nyingi za baridi za otomatiki zimetolewa kwa ajili ya kujenga picha za Docker na kwa ajili ya kupelekwa Kubernetes. Katika suala hili, niliamua kucheza karibu na GitLab, kujifunza kikamilifu uwezo wake na, bila shaka, kuanzisha bomba.

Kazi hii iliongozwa na tovuti kubernetes.io, ambayo hutolewa kutoka misimbo ya chanzo kiotomatiki, na kwa kila ombi la bwawa linalotumwa, roboti hutengeneza kiotomatiki toleo la onyesho la kukagua tovuti na mabadiliko yako na hutoa kiungo cha kutazamwa.

Nilijaribu kuunda mchakato kama huo kutoka mwanzo, lakini umejengwa kabisa kwenye Gitlab CI na zana za bure ambazo nimezoea kutumia kupeleka programu kwa Kubernetes. Leo hatimaye nitakuambia zaidi juu yao.

Nakala hiyo itajadili zana kama vile:
Hugo, qbec, kaniko, git-crypt и GitLab CI na uundaji wa mazingira yenye nguvu.

Yaliyomo

1. Kutana na Hugo
2. Kuandaa faili ya Docker
3. Kufahamiana na kaniko
4. Kufahamiana na qbec
5. Kujaribu Gitlab-runner na Kubernetes-executor
6. Inapeleka chati za Helm na qbec
7. Tunakuletea git-crypt
8. Kuunda picha ya kisanduku cha zana
9. Bomba letu la kwanza na mkusanyiko wa picha kwa tagi
10. Uwekaji otomatiki
11. Mabaki na mkusanyiko wakati wa kusukuma kwa bwana
12. Mazingira yenye nguvu
13. Kagua Programu

1. Kufahamiana na Hugo

Kama mfano wa mradi wetu, tutajaribu kuunda tovuti ya kuchapisha nyaraka iliyojengwa kwenye Hugo. Hugo ni jenereta ya maudhui tuli.

Kwa wale ambao hawajui jenereta za tuli, nitakuambia zaidi kidogo juu yao. Tofauti na injini za tovuti za kawaida zilizo na hifadhidata na PHP fulani, ambayo, inapoombwa na mtumiaji, hutoa kurasa kwa kuruka, jenereta za tuli zimeundwa tofauti kidogo. Wanakuruhusu kuchukua vyanzo, kwa kawaida seti ya faili katika markup markup na violezo vya mandhari, kisha uzijumuishe kwenye tovuti iliyokamilika kabisa.

Hiyo ni, kwa matokeo, utapokea muundo wa saraka na seti ya faili za HTML zinazozalishwa, ambazo unaweza kupakia tu kwa mwenyeji wowote wa bei nafuu na kupata tovuti ya kazi.

Unaweza kusakinisha Hugo ndani ya nchi na ujaribu:

Kuanzisha tovuti mpya:

hugo new site docs.example.org

Na wakati huo huo hazina ya git:

cd docs.example.org
git init

Kufikia sasa, tovuti yetu ni safi na ili kitu kionekane juu yake, tunahitaji kwanza kuunganisha mada; mada ni seti ya violezo na sheria maalum kulingana na ambayo tovuti yetu inatolewa.

Kwa mada tutakayotumia Jifunze, ambayo, kwa maoni yangu, inafaa kabisa kwa tovuti ya nyaraka.

Ningependa kulipa kipaumbele maalum kwa ukweli kwamba hatuitaji kuhifadhi faili za mada kwenye hazina yetu ya mradi; badala yake, tunaweza kuiunganisha kwa kutumia git submodule:

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

Kwa hivyo, hazina yetu itakuwa na faili tu zinazohusiana moja kwa moja na mradi wetu, na mada iliyounganishwa itabaki kama kiunga cha hazina maalum na ahadi ndani yake, ambayo ni kwamba, inaweza kuvutwa kila wakati kutoka kwa chanzo asili na usiogope. mabadiliko yasiyolingana.

Wacha turekebishe usanidi config.toml:

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

Tayari katika hatua hii unaweza kukimbia:

hugo server

Na kwa anwani http://localhost:1313/ angalia tovuti yetu mpya iliyoundwa, mabadiliko yote yaliyofanywa kwenye saraka yanasasisha moja kwa moja ukurasa wazi kwenye kivinjari, rahisi sana!

Wacha tujaribu kuunda ukurasa wa jalada ndani content/_index.md:

# My docs site

## Welcome to the docs!

You will be very smart :-)

Picha ya skrini ya ukurasa mpya ulioundwa

Ili kutengeneza tovuti, endesha tu:

hugo

Yaliyomo kwenye saraka umma / na itakuwa tovuti yako.
Ndio, kwa njia, wacha tuiongeze mara moja .jisajili:

echo /public > .gitignore

Usisahau kufanya mabadiliko yetu:

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

2. Kuandaa Dockerfile

Ni wakati wa kufafanua muundo wa hazina yetu. Kawaida mimi hutumia kitu kama:

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

• dockerfiles/ - vyenye saraka na Dockerfiles na kila kitu muhimu ili kuunda picha zetu za Docker.
• peleka/ - ina saraka za kupeleka maombi yetu kwa Kubernetes

Kwa hivyo, tutaunda Dockerfile yetu ya kwanza njiani 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" ]

Kama unaweza kuona, Dockerfile ina mbili KUTOKA, kipengele hiki kinaitwa ujenzi wa hatua nyingi na hukuruhusu kuwatenga kila kitu kisichohitajika kutoka kwa picha ya mwisho ya kizimbani.
Kwa hivyo, picha ya mwisho itakuwa na tu gizahttpd (seva ya HTTP nyepesi) na umma / - Yaliyomo kwenye tovuti yetu iliyotengenezwa kwa takwimu.

Usisahau kufanya mabadiliko yetu:

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

3. Kufahamiana na kaniko

Kama mjenzi wa picha ya docker, niliamua kutumia kaniko, kwa kuwa uendeshaji wake hauhitaji daemon ya docker, na kujenga yenyewe inaweza kufanyika kwenye mashine yoyote na cache inaweza kuhifadhiwa moja kwa moja kwenye Usajili, na hivyo kuondokana na haja ya kuwa na hifadhi kamili ya kudumu.

Ili kuunda picha, endesha tu chombo na kaniko mtekelezaji na upitishe muktadha wa sasa wa ujenzi; hii inaweza pia kufanywa ndani ya nchi, kupitia kizimbani:

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

Je! registry.gitlab.com/kvaps/docs.example.org/website - jina la picha yako ya kizimbani; baada ya kujenga, itazinduliwa kiotomatiki kwenye sajili ya docker.

Parameter --cache hukuruhusu kuweka kashe tabaka kwenye sajili ya docker; kwa mfano uliopewa, watahifadhiwa ndani registry.gitlab.com/kvaps/docs.example.org/website/cache, lakini unaweza kutaja njia nyingine kwa kutumia parameta --cache-repo.

Picha ya skrini ya usajili wa docker

4. Kufahamiana na qbec

Qbec ni zana ya utumaji ambayo hukuruhusu kuelezea kwa uthabiti maonyesho ya programu yako na kuyapeleka kwa Kubernetes. Kutumia Jsonnet kama sintaksia kuu hukuruhusu kurahisisha sana maelezo ya tofauti katika mazingira mengi, na pia karibu kuondoa kabisa marudio ya msimbo.

Hii inaweza kuwa kweli hasa katika hali ambapo unahitaji kupeleka programu kwa vikundi kadhaa vilivyo na vigezo tofauti na unataka kuvielezea kwa uwazi katika Git.

Qbec pia hukuruhusu kutoa chati za Helm kwa kuzipitisha vigezo muhimu na kisha kuziendesha kwa njia sawa na udhihirisho wa kawaida, pamoja na unaweza kutumia mabadiliko kadhaa kwao, na hii, kwa upande wake, hukuruhusu kuondoa hitaji la tumia ChartMakumbusho. Hiyo ni, unaweza kuhifadhi na kutoa chati moja kwa moja kutoka kwa git, mahali zinapofaa.

Kama nilivyosema hapo awali, tutahifadhi usambazaji wote kwenye saraka peleka/:

mkdir deploy
cd deploy

Wacha tuanzishe programu yetu ya kwanza:

qbec init website
cd website

Sasa muundo wa maombi yetu unaonekana kama hii:

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

tuangalie faili qbec.yaml:

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

Hapa tunavutiwa kimsingi maalum.mazingira, qbec tayari imeunda mazingira chaguo-msingi kwa ajili yetu na kuchukua anwani ya seva, pamoja na nafasi ya majina kutoka kwa kubeconfig yetu ya sasa.
Sasa wakati wa kupeleka default mazingira, qbec itapeleka tu kwa nguzo maalum ya Kubernetes na kwa nafasi maalum ya majina, yaani, huhitaji tena kubadili kati ya miktadha na nafasi za majina ili kutekeleza utumaji.
Ikiwa ni lazima, unaweza kusasisha mipangilio katika faili hii kila wakati.

Mazingira yako yote yameelezewa ndani qbec.yaml, na kwenye faili params.libsonnet, ambapo inasema wapi kupata vigezo kwao.

Ifuatayo tunaona saraka mbili:

• vifaa / - maonyesho yote ya programu yetu yatahifadhiwa hapa; yanaweza kuelezewa katika jsonnet na faili za yaml za kawaida
• mazingira/ - hapa tutaelezea vigezo vyote (vigezo) vya mazingira yetu.

Kwa chaguo-msingi tuna faili mbili:

• mazingira/base.libsonnet - itakuwa na vigezo vya kawaida kwa mazingira yote
• mazingira/default.libsonnet - ina vigezo vilivyobatilishwa kwa mazingira default

tufungue mazingira/base.libsonnet na ongeza vigezo vya sehemu yetu ya kwanza hapo:

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

Wacha pia tuunde sehemu yetu ya kwanza vipengele/tovuti.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,
                },
              },
            ],
          },
        },
      ],
    },
  },
]

Katika faili hii tulielezea vyombo vitatu vya Kubernetes mara moja, hizi ni: Kuhamishwa, huduma и Ingress. Ikiwa tunataka, tunaweza kuziweka katika vipengele tofauti, lakini katika hatua hii moja itakuwa ya kutosha kwetu.

syntax jsonnet ni sawa na json ya kawaida, kimsingi, json ya kawaida tayari ni jsonnet halali, kwa hivyo mwanzoni inaweza kuwa rahisi kwako kutumia huduma za mkondoni kama vile. yaml2json kubadilisha yaml yako ya kawaida kuwa json, au, ikiwa vifaa vyako havina vigeuzo vyovyote, basi vinaweza kuelezewa kwa njia ya yaml ya kawaida.

Wakati wa kufanya kazi na jsonnet Ninapendekeza sana kusakinisha programu-jalizi kwa mhariri wako

Kwa mfano, kuna programu-jalizi ya vim vim-jsonnet, ambayo huwasha mwangaza wa sintaksia na kutekeleza kiotomatiki jsonnet fmt kila wakati unapohifadhi (inahitaji jsonnet kusakinishwa).

Kila kitu kiko tayari, sasa tunaweza kuanza kusambaza:

Ili kuona kile tulicho nacho, wacha tukimbie:

qbec show default

Kwenye pato, utaona maonyesho ya yaml yaliyotolewa ambayo yatatumika kwa nguzo chaguo-msingi.

Sawa, sasa tuma ombi:

qbec apply default

Kwenye pato utaona kila kitakachofanywa kwenye nguzo yako, qbec itakuuliza ukubali mabadiliko kwa kuandika. y utaweza kuthibitisha nia yako.

Programu yetu iko tayari na imetumwa!

Ukifanya mabadiliko, unaweza kufanya:

qbec diff default

kuona jinsi mabadiliko haya yataathiri uwekaji wa sasa

Usisahau kufanya mabadiliko yetu:

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

5. Kujaribu Gitlab-runner na Kubernetes-executor

Hadi hivi majuzi nilitumia kawaida tu gitlab-mkimbiaji kwenye mashine iliyotayarishwa awali (chombo cha LXC) kilicho na ganda au mtekelezaji wa docker. Hapo awali, tulikuwa na wakimbiaji kadhaa kama hao waliofafanuliwa kimataifa katika gitlab yetu. Walikusanya picha za docker kwa miradi yote.

Lakini kama mazoezi yameonyesha, chaguo hili sio bora zaidi, kwa suala la vitendo na usalama. Ni bora zaidi na sahihi zaidi kiitikadi kuwa na wakimbiaji tofauti waliotumwa kwa kila mradi, au hata kwa kila mazingira.

Kwa bahati nzuri, hii sio shida kabisa, kwani sasa tutapeleka gitlab-mkimbiaji moja kwa moja kama sehemu ya mradi wetu huko Kubernetes.

Gitlab hutoa chati ya usukani iliyotengenezwa tayari kwa ajili ya kupeleka gitlab-runner kwa Kubernetes. Kwa hivyo unachohitaji kufanya ni kujua ishara ya usajili kwa mradi wetu katika Mipangilio -> CI / CD -> Runners na kuipitisha kwenye usukani.

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

Ambapo:

• https://gitlab.com - anwani ya seva yako ya Gitlab.
• yga8y-jdCusVDn_t4Wxc - ishara ya usajili kwa mradi wako.
• rbac.tengeneza=kweli - humpa mkimbiaji kiasi kinachohitajika cha marupurupu ya kuweza kuunda maganda ili kutekeleza kazi zetu kwa kutumia kubernetes-executor.

Ikiwa kila kitu kimefanywa kwa usahihi, unapaswa kuona mkimbiaji aliyesajiliwa katika sehemu hiyo Wanariadha, katika mipangilio ya mradi wako.

Picha ya skrini ya mkimbiaji aliyeongezwa

Je, ni rahisi hivyo? - Ndio, ni rahisi sana! Hakuna shida tena na kusajili wakimbiaji kwa mikono, kuanzia sasa wakimbiaji wataundwa na kuharibiwa kiotomatiki.

6. Tumia chati za Helm na QBEC

Kwa kuwa tuliamua kuzingatia gitlab-mkimbiaji sehemu ya mradi wetu, ni wakati wa kuielezea katika hazina yetu ya Git.

Tunaweza kuielezea kama sehemu tofauti tovuti, lakini katika siku zijazo tunapanga kupeleka nakala tofauti tovuti mara nyingi sana, tofauti gitlab-mkimbiaji, ambayo itatumwa mara moja tu kwa kila kundi la Kubernetes. Kwa hivyo wacha tuanzishe programu tofauti yake:

cd deploy
qbec init gitlab-runner
cd gitlab-runner

Wakati huu hatutaelezea huluki za Kubernetes kwa mikono, lakini tutachukua chati ya Helm iliyotengenezwa tayari. Mojawapo ya faida za qbec ni uwezo wa kutoa chati za Helm moja kwa moja kutoka kwa hazina ya Git.

Wacha tuiunganishe kwa kutumia git submodule:

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

Sasa saraka muuzaji/gitlab-mkimbiaji Tuna hazina iliyo na chati ya gitlab-runner.

Vivyo hivyo, unaweza kuunganisha hazina zingine, kwa mfano, hazina nzima na chati rasmi https://github.com/helm/charts

Hebu tueleze sehemu vipengele/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,
  }
)

Hoja ya kwanza kwa expandHelmTemplate tunapitisha njia kwenye chati, basi params.maadili, ambayo tunachukua kutoka kwa vigezo vya mazingira, kisha inakuja kitu

• jinaKigezo - kichwa cha kutolewa
• nafasi ya jina - nafasi ya jina imehamishiwa kwenye usukani
• hiiFaili - parameter inayohitajika ambayo hupitisha njia ya faili ya sasa
• kitenzi - inaonyesha amri template ya usukani pamoja na hoja zote wakati wa kutoa chati

Sasa hebu tueleze vigezo vya sehemu yetu katika mazingira/base.libsonnet:

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

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

Makini RunnerRegistrationToken tunachukua kutoka kwa faili ya nje siri/msingi.libsonnet, tuunde:

{
  runnerRegistrationToken: 'yga8y-jdCusVDn_t4Wxc',
}

Wacha tuangalie ikiwa kila kitu kinafanya kazi:

qbec show default

ikiwa kila kitu kiko sawa, basi tunaweza kufuta toleo letu lililotumwa hapo awali kupitia Helm:

helm uninstall gitlab-runner

na uipeleke kwa njia ile ile, lakini kupitia qbec:

qbec apply default

7. Utangulizi wa git-crypt

Git-crypt ni zana inayokuruhusu kusanidi usimbaji fiche wa uwazi wa hazina yako.

Kwa sasa, muundo wetu wa saraka ya gitlab-runner inaonekana kama hii:

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

Lakini kuhifadhi siri katika Git si salama, sivyo? Kwa hivyo tunahitaji kusimba kwa njia fiche ipasavyo.

Kawaida, kwa sababu ya kutofautisha moja, hii haileti maana kila wakati. Unaweza kuhamisha siri kwa qbec na kupitia anuwai ya mazingira ya mfumo wako wa CI.
Lakini inafaa kuzingatia kwamba pia kuna miradi ngumu zaidi ambayo inaweza kuwa na siri nyingi zaidi; kuhamisha zote kupitia anuwai za mazingira itakuwa ngumu sana.

Kwa kuongezea, katika kesi hii nisingeweza kukuambia juu ya zana nzuri kama hii git-crypt.

git-crypt Pia ni rahisi kwa kuwa hukuruhusu kuokoa historia nzima ya siri, na pia kulinganisha, kuunganisha na kutatua migogoro kwa njia ile ile ambayo tumezoea kufanya katika kesi ya Git.

Jambo la kwanza baada ya ufungaji git-crypt tunahitaji kutoa funguo za hazina yetu:

git crypt init

Ikiwa una ufunguo wa PGP, basi unaweza kujiongeza mara moja kama mshiriki wa mradi huu:

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

Kwa njia hii unaweza kusimbua hazina hii kila wakati kwa kutumia ufunguo wako wa faragha.

Ikiwa huna ufunguo wa PGP na hutarajii, basi unaweza kwenda kwa njia nyingine na kuhamisha ufunguo wa mradi:

git crypt export-key /path/to/keyfile

Hivyo, mtu yeyote ambaye ana mauzo ya nje keyfile itaweza kusimbua hazina yako.

Ni wakati wa kuanzisha siri yetu ya kwanza.
Acha nikukumbushe kuwa bado tuko kwenye saraka peleka/gitlab-runner/, ambapo tuna saraka siri/, hebu tufiche faili zote ndani yake, kwa hili tutaunda faili siri/.gitattributes na maudhui yafuatayo:

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

Kama inavyoonekana kutoka kwa yaliyomo, faili zote zimefunikwa * itaendeshwa kupitia git-crypt, isipokuwa kwa wengi .gitattributes

Tunaweza kuangalia hii kwa kukimbia:

git crypt status -e

Matokeo yatakuwa orodha ya faili zote kwenye hazina ambayo usimbaji fiche umewezeshwa

Ni hayo tu, sasa tunaweza kufanya mabadiliko yetu kwa usalama:

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

Ili kuzuia hazina, endesha tu:

git crypt lock

na mara moja faili zote zilizosimbwa zitageuka kuwa kitu cha binary, haitawezekana kuzisoma.
Ili kusimbua hazina, endesha:

git crypt unlock

8. Unda picha ya kisanduku cha zana

Picha ya kisanduku cha zana ni picha iliyo na zana zote ambazo tutatumia kusambaza mradi wetu. Itatumiwa na mkimbiaji wa Gitlab kutekeleza majukumu ya kawaida ya kusambaza.

Kila kitu ni rahisi hapa, wacha tuunda mpya dockerfiles/Toolbox/Dockerfile na maudhui yafuatayo:

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

Kama unavyoona, katika picha hii tunasakinisha huduma zote ambazo tulitumia kupeleka programu yetu. Hatuhitaji hapa isipokuwa kubectl, lakini unaweza kutaka kucheza nayo wakati wa awamu ya usanidi wa bomba.

Pia, ili kuweza kuwasiliana na Kubernetes na kupeleka kwake, tunahitaji kusanidi jukumu la maganda yanayotokana na gitlab-runner.

Ili kufanya hivyo, wacha tuende kwenye saraka na gitlab-runner:

cd deploy/gitlab-runner

na kuongeza sehemu mpya vipengele/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,
      },
    ],
  },
]

Pia tutaelezea vigezo vipya katika mazingira/base.libsonnet, ambayo sasa inaonekana kama hii:

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

Makini $.components.rbac.name inahusu jina kwa kipengele rbac

Wacha tuangalie ni nini kimebadilika:

qbec diff default

na kutumia mabadiliko yetu kwa Kubernetes:

qbec apply default

Pia, usisahau kufanya mabadiliko yetu kwa 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. Bomba letu la kwanza na mkusanyiko wa picha kwa vitambulisho

Katika mizizi ya mradi tutaunda .gitlab-ci.yml na maudhui yafuatayo:

.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

Tafadhali kumbuka tunatumia GIT_SUBMODULE_STRATEGY: kawaida kwa kazi hizo ambapo unahitaji kuanzisha kwa uwazi submodule kabla ya utekelezaji.

Usisahau kufanya mabadiliko yetu:

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

Nadhani tunaweza kuliita toleo hili kwa usalama v0.0.1 na ongeza lebo:

git tag v0.0.1

Tutaongeza lebo wakati wowote tunapohitaji kutoa toleo jipya. Lebo kwenye picha za Docker zitaunganishwa na vitambulisho vya Git. Kila kisukuma kilicho na lebo mpya kitaanzisha muundo wa picha na lebo hii.

Hebu tufanye git push --tags, na tuangalie bomba letu la kwanza:

Picha ya skrini ya bomba la kwanza

Inafaa kuteka mawazo yako kwa ukweli kwamba kusanyiko kwa vitambulisho linafaa kwa ajili ya kujenga picha za docker, lakini haifai kwa kupeleka maombi kwa Kubernetes. Kwa kuwa vitambulisho vipya vinaweza kupewa ahadi za zamani, katika kesi hii, kuanzisha bomba kwao kutasababisha kupelekwa kwa toleo la zamani.

Ili kusuluhisha shida hii, kawaida muundo wa picha za docker umefungwa kwa vitambulisho, na kupelekwa kwa programu kwenye tawi. bwana, ambayo matoleo ya picha zilizokusanywa yamewekwa kwa njia ngumu. Hapa ndipo unaweza kuanzisha urejeshaji kwa urejeshaji rahisi bwana-matawi.

10. Automation ya kupelekwa

Ili Gitlab-runner iweze kusimbua siri zetu, tutahitaji kusafirisha ufunguo wa hazina na kuuongeza kwa anuwai ya mazingira ya CI:

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

Tutahifadhi laini inayotokana katika Gitlab; ili kufanya hivyo, wacha tuende kwenye mipangilio ya mradi wetu:
Mipangilio -> CI / CD -> Vigezo

Na wacha tuunde tofauti mpya:

aina
Muhimu
Thamani
Kulindwa
Imefungwa
Scope

File
GITCRYPT_KEY
<your string>
true (wakati wa mafunzo unaweza false)
true
All environments

Picha ya skrini ya kibadilishaji kilichoongezwa

Sasa wacha tusasishe yetu .gitlab-ci.yml kuongeza kwake:

.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

Hapa tumewezesha chaguzi kadhaa mpya za qbec:

• --root baadhi/programu - hukuruhusu kuamua saraka ya programu maalum
• --force:k8s-context __incluster__ - hii ni tofauti ya kichawi ambayo inasema kwamba kupelekwa kutatokea kwenye nguzo moja ambayo gtilab-runner inaendesha. Hii ni muhimu kwa sababu vinginevyo qbec itajaribu kupata seva inayofaa ya Kubernetes kwenye kubeconfig yako
• --subiri - hulazimisha qbec kusubiri hadi rasilimali inazounda ziende katika hali ya Tayari na kisha tu kuondoka na msimbo wa kuondoka uliofaulu.
• -ndiyo - inalemaza tu shell inayoingiliana Una uhakika? inapowekwa.

Usisahau kufanya mabadiliko yetu:

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

Na baada ya git kushinikiza tutaona jinsi maombi yetu yametumwa:

Picha ya skrini ya bomba la pili

11. Artifacts na mkusanyiko wakati wa kusukuma kwa bwana

Kwa kawaida, hatua zilizoelezwa hapo juu zinatosha kujenga na kutoa karibu huduma yoyote ndogo, lakini hatutaki kuongeza lebo kila wakati tunapohitaji kusasisha tovuti. Kwa hiyo, tutachukua njia yenye nguvu zaidi na kuanzisha upelekaji wa digest katika tawi kuu.

Wazo ni rahisi: sasa picha ya yetu tovuti itajengwa upya kila wakati unapoingia bwana, na kisha usambaze kiotomatiki kwa Kubernetes.

Wacha tusasishe kazi hizi mbili katika yetu .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"

Tafadhali kumbuka kuwa tumeongeza thread bwana к Ref kwa kazi kujenga_tovuti na sasa tunatumia $CI_COMMIT_REF_NAME badala ya $CI_COMMIT_TAG, yaani, tumefunguliwa kutoka kwa vitambulisho kwenye Git na sasa tutasukuma picha iliyo na jina la tawi la ahadi ambalo lilianzisha bomba. Inafaa kumbuka kuwa hii pia itafanya kazi na vitambulisho, ambavyo vitaturuhusu kuokoa snapshots za tovuti na toleo maalum katika usajili wa docker.

Wakati jina la lebo ya docker ya toleo jipya la tovuti inaweza kubadilishwa, bado tunapaswa kuelezea mabadiliko kwa Kubernetes, vinginevyo haitatuma tena programu kutoka kwa picha mpya, kwani haitaona mabadiliko yoyote katika uwekaji wazi.

Chaguo —vm:ext-str digest=”$DIGEST” kwa qbec - hukuruhusu kupitisha utaftaji wa nje kwa jsonnet. Tunataka isambazwe upya katika kundi kwa kila toleo la programu yetu. Hatuwezi tena kutumia jina la lebo, ambalo sasa haliwezi kubadilika, kwa kuwa tunahitaji kuunganishwa kwenye toleo mahususi la picha na kuanzisha utumaji inapobadilika.

Hapa tutasaidiwa na uwezo wa Kaniko wa kuhifadhi taswira kwenye faili (chaguo --digest-faili)
Kisha tutahamisha faili hii na kuisoma wakati wa kupelekwa.

Wacha tusasishe vigezo vya yetu deploy/website/environments/base.libsonnet ambayo sasa itaonekana kama hii:

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

Imekamilika, sasa ahadi yoyote bwana inaanzisha ujenzi wa picha ya kizimbani kwa tovuti, na kisha ipeleke kwa Kubernetes.

Usisahau kufanya mabadiliko yetu:

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

Tutaangalia baadaye git kushinikiza tunapaswa kuona kitu kama hiki:

Picha ya skrini ya bomba kwa bwana

Kimsingi, hatuitaji kupeleka tena gitlab-runner kwa kila msukumo, isipokuwa, bila shaka, hakuna kilichobadilika katika usanidi wake, wacha tuirekebishe. .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/**/*

mabadiliko itakuruhusu kufuatilia mabadiliko ndani peleka/gitlab-runner/ na itaanzisha kazi yetu ikiwa tu zipo

Usisahau kufanya mabadiliko yetu:

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

git kushinikiza, hiyo ni bora zaidi:

Picha ya skrini ya bomba iliyosasishwa

12. Mazingira yenye nguvu

Ni wakati wa kubadilisha bomba letu kwa mazingira yanayobadilika.

Kwanza, hebu tusasishe kazi kujenga_tovuti katika yetu .gitlab-ci.yml, kuondoa kizuizi kutoka kwake tu, ambayo italazimisha Gitlab kuichochea kwa ahadi yoyote kwa tawi lolote:

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/

Kisha sasisha kazi deploy_tovuti, ongeza kizuizi hapo mazingira:

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"

Hii itaruhusu Gitlab kuhusisha kazi na Prod mazingira na uonyeshe kiunga sahihi kwake.

Sasa hebu tuongeze kazi mbili zaidi:

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

Zitazinduliwa baada ya kusukuma kwa matawi yoyote isipokuwa bwana na zitapeleka toleo la onyesho la kuchungulia la tovuti.

Tunaona chaguo mpya kwa qbec: --app-tag - hukuruhusu kuweka lebo kwenye matoleo yaliyosambazwa ya programu na kufanya kazi ndani ya lebo hii pekee; wakati wa kuunda na kuharibu rasilimali katika Kubernetes, qbec itafanya kazi nazo pekee.
Kwa njia hii hatuwezi kuunda mazingira tofauti kwa kila ukaguzi, lakini tutumie tena yale yale.

Hapa pia tunatumia qbec tuma hakiki, badala ya qbec tumia chaguo-msingi - huu ndio wakati ambapo tutajaribu kuelezea tofauti za mazingira yetu (hakiki na chaguo-msingi):

Wacha tuongeze mapitio ya mazingira katika deploy/tovuti/qbec.yaml

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

Kisha tutaitangaza ndani 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

Na uandike vigezo maalum vyake ndani 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',
    },
  },
}

Hebu pia tuangalie kwa karibu jobu acha_mapitio, itachochewa wakati tawi limefutwa na ili gitlab isijaribu kuangalia inatumika GIT_STRATEGY: hakuna, baadaye sisi clone bwana-tawi na ufute ukaguzi kupitia hilo.
Inachanganya kidogo, lakini sijapata njia nzuri zaidi bado.
Chaguo mbadala litakuwa kupeleka kila ukaguzi kwenye nafasi ya majina ya hoteli, ambayo inaweza kubomolewa kabisa kila wakati.

Usisahau kufanya mabadiliko yetu:

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

git kushinikiza, git Checkout -b mtihani, mtihani wa asili wa git, angalia:

Picha ya skrini ya mazingira yaliyoundwa katika Gitlab

Kila kitu kinafanya kazi? - nzuri, futa tawi letu la majaribio: git checkout bwana, git push origin :test, tunaangalia kuwa kazi za kufuta mazingira zilifanya kazi bila makosa.

Hapa ningependa kufafanua mara moja kwamba mtengenezaji yeyote katika mradi anaweza kuunda matawi, anaweza pia kubadilisha .gitlab-ci.yml faili na ufikiaji wa anuwai za siri.
Kwa hiyo, inashauriwa sana kuruhusu matumizi yao tu kwa matawi yaliyohifadhiwa, kwa mfano katika bwana, au unda seti tofauti ya anuwai kwa kila mazingira.

13. Kagua Programu

Kagua Programu Hiki ni kipengee cha GitLab ambacho hukuruhusu kuongeza kitufe kwa kila faili kwenye hazina ili kuiona haraka katika mazingira yaliyotumwa.

Ili vifungo hivi kuonekana, unahitaji kuunda faili .gitlab/route-map.yml na ueleze mabadiliko yote ya njia ndani yake; kwa upande wetu itakuwa rahisi sana:

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

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

Usisahau kufanya mabadiliko yetu:

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

git kushinikiza, na angalia:

Picha ya skrini ya kitufe cha Kagua Programu

Kazi imekamilika!

Vyanzo vya mradi:

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

Asante kwa umakini wako, natumai umeipenda

Chanzo: mapenzi.com