ProHoster > Blogs > Administrācija > Izmēģināt jaunus rÄ«kus, lai izveidotu un automatizētu izvietoÅ”anu Kubernetes

Izmēģināt jaunus rÄ«kus, lai izveidotu un automatizētu izvietoÅ”anu Kubernetes

Izmēģināt jaunus rÄ«kus, lai izveidotu un automatizētu izvietoÅ”anu Kubernetes

Sveiki! Nesen ir izlaisti daudzi lieliski automatizācijas rÄ«ki gan Docker attēlu veidoÅ”anai, gan izvietoÅ”anai Kubernetes. Å ajā sakarā es nolēmu paspēlēties ar GitLab, rÅ«pÄ«gi izpētÄ«t tā iespējas un, protams, izveidot cauruļvadu.

Å o darbu iedvesmoja vietne kubernetes.io, kas tiek Ä£enerēts no pirmkodi automātiski, un katram nosÅ«tÄ«tajam pÅ«la pieprasÄ«jumam robots automātiski Ä£enerē vietnes priekÅ”skatÄ«juma versiju ar jÅ«su izmaiņām un nodroÅ”ina saiti apskatei.

Es mēģināju izveidot lÄ«dzÄ«gu procesu no nulles, bet pilnÄ«bā balstÄ«ts uz Gitlab CI un bezmaksas rÄ«kiem, kurus esmu pieradis izmantot, lai izvietotu lietojumprogrammas Kubernetes. Å odien es beidzot pastāstÄ«Å”u vairāk par viņiem.

Rakstā tiks apspriesti tādi rīki kā:
Hugo, qbec, kaniko, git-crypt Šø GitLab CI ar dinamiskas vides izveidi.

Saturs

  1. Iepazīstieties ar Hugo
  2. Docker faila sagatavoŔana
  3. IepazīŔanās ar kaniko
  4. IepazīŔanās ar qbec
  5. Mēģina Gitlab-runner ar Kubernetes-izpildītāju
  6. Helm diagrammu izvietoŔana ar qbec
  7. Iepazīstinām ar git-crypt
  8. Rīkkopas attēla izveide
  9. MÅ«su pirmais cauruļvads un attēlu komplektÄ“Å”ana pēc tagiem
  10. IzvietoŔanas automatizācija
  11. Artefakti un montāža, spiežot uz meistaru
  12. Dinamiskas vides
  13. Pārskatiet lietotnes

1. IepazīŔanās ar Hugo

Kā mÅ«su projekta piemēru mēs mēģināsim izveidot dokumentācijas publicÄ“Å”anas vietni, kas veidota uz Hugo. Hugo ir statiska satura Ä£enerators.

Tiem, kas nav pazÄ«stami ar statiskajiem Ä£eneratoriem, es jums pastāstÄ«Å”u nedaudz vairāk par tiem. AtŔķirÄ«bā no parastajiem vietņu dzinējiem ar datu bāzi un dažiem PHP, kas pēc lietotāja pieprasÄ«juma Ä£enerē lapas lidojumā, statiskie Ä£eneratori ir veidoti nedaudz savādāk. Tie ļauj iegÅ«t avotus, parasti failu kopu Markdown iezÄ«mÄ“Å”anas un motÄ«vu veidnēs, un pēc tam apkopot tos pilnÄ«bā pabeigtā vietnē.

Tas ir, kā rezultātā jÅ«s saņemsiet direktoriju struktÅ«ru un Ä£enerētu HTML failu kopu, ko varēsit vienkārÅ”i augÅ”upielādēt jebkurā lētajā mitināŔanā un iegÅ«t funkcionējoÅ”u vietni.

Varat instalēt Hugo lokāli un izmēģināt:

Jaunas vietnes inicializācija:

hugo new site docs.example.org

Un tajā paŔā laikā git repozitorijs:

cd docs.example.org
git init

LÄ«dz Å”im mÅ«su vietne ir senatnÄ«ga, un, lai tajā kaut kas parādÄ«tos, mums vispirms ir jāsavieno motÄ«vs; motÄ«vs ir tikai veidņu un noteiktu noteikumu kopums, pēc kuriem tiek Ä£enerēta mÅ«su vietne.

Tēmai mēs izmantosim Mācīties, kas, manuprāt, ir lieliski piemērots dokumentācijas vietnei.

Es vēlos pievērst Ä«paÅ”u uzmanÄ«bu tam, ka mums nav jāsaglabā motÄ«vu faili mÅ«su projektu repozitorijā; tā vietā mēs varam to vienkārÅ”i savienot, izmantojot git apakÅ”modulis:

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

Tādējādi mÅ«su repozitorijā bÅ«s tikai faili, kas ir tieÅ”i saistÄ«ti ar mÅ«su projektu, un pievienotā tēma paliks kā saite uz konkrētu repozitoriju un commit tajā, tas ir, to vienmēr var izvilkt no sākotnējā avota un nebaidÄ«ties no tā. nesavienojamas izmaiņas.

Izlabosim konfigurāciju config.toml:

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

Jau Ŕajā posmā jūs varat skriet:

hugo server

Un adresē http://localhost:1313/ pārbaudiet mūsu jaunizveidoto vietni, visas direktorijā veiktās izmaiņas automātiski atjaunina atvērto lapu pārlūkprogrammā, ļoti ērti!

Mēģināsim izveidot titullapu content/_index.md:

# My docs site

## Welcome to the docs!

You will be very smart :-)

Jaunizveidotās lapas ekrānuzņēmums

Izmēģināt jaunus rÄ«kus, lai izveidotu un automatizētu izvietoÅ”anu Kubernetes

Lai izveidotu vietni, vienkārŔi palaidiet:

hugo

Direktorija saturs publisks/ un tā būs jūsu vietne.
Jā, starp citu, tūlīt pievienosim to .gitignore:

echo /public > .gitignore

Neaizmirstiet veikt mūsu izmaiņas:

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

2. Docker faila sagatavoŔana

Ir pienācis laiks definēt mūsu repozitorija struktūru. Es parasti izmantoju kaut ko līdzīgu:

.
ā”œā”€ā”€ deploy
ā”‚   ā”œā”€ā”€ app1
ā”‚   ā””ā”€ā”€ app2
ā””ā”€ā”€ dockerfiles
    ā”œā”€ā”€ image1
    ā””ā”€ā”€ image2

  • dockerfiles/ ā€” satur direktorijus ar Dockerfiles un visu nepiecieÅ”amo, lai izveidotu mÅ«su Docker attēlus.
  • izvietot/ ā€” satur direktorijus mÅ«su lietojumprogrammu izvietoÅ”anai Kubernetes

Tādējādi mēs izveidosim savu pirmo Dockerfile Å”ajā ceļā 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" ]

Kā redzat, Dockerfile satur divus NO, Å”o funkciju sauc daudzpakāpju uzbÅ«ve un ļauj no galÄ«gā Docker attēla izslēgt visu nevajadzÄ«go.
Tādējādi galÄ«gajā attēlā bÅ«s tikai tumÅ”shttpd (viegls HTTP serveris) un publisks/ ā€” mÅ«su statiski Ä£enerētās vietnes saturs.

Neaizmirstiet veikt mūsu izmaiņas:

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

3. Kaniko iepazīŔana

Kā doka attēlu veidotājs es nolēmu izmantot kaniko, jo tā darbÄ«bai nav nepiecieÅ”ams docker dēmons, un paÅ”u veidoÅ”anu var veikt jebkurā datorā, un keÅ”atmiņu var glabāt tieÅ”i reÄ£istrā, tādējādi novērÅ”ot nepiecieÅ”amÄ«bu pēc pilnvērtÄ«gas pastāvÄ«gas krātuves.

Lai izveidotu attēlu, vienkārÅ”i palaidiet konteineru ar kaniko izpildÄ«tājs un nododiet tam paÅ”reizējo bÅ«vÄ“Å”anas kontekstu; to var izdarÄ«t arÄ« lokāli, izmantojot 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

Kur registry.gitlab.com/kvaps/docs.example.org/website ā€” jÅ«su doka attēla nosaukums; pēc izveides tas tiks automātiski palaists dokstacijas reÄ£istrā.

Parametrs -- keÅ”atmiņa ļauj keÅ”atmiņā saglabāt slāņus docker reÄ£istrā; dotajā piemērā tie tiks saglabāti registry.gitlab.com/kvaps/docs.example.org/website/cache, bet varat norādÄ«t citu ceļu, izmantojot parametru --keÅ”atmiņas repo.

Docker-reģistra ekrānuzņēmums

Izmēģināt jaunus rÄ«kus, lai izveidotu un automatizētu izvietoÅ”anu Kubernetes

4. IepazīŔanās ar qbec

Qbec ir izvietoÅ”anas rÄ«ks, kas ļauj deklaratÄ«vi aprakstÄ«t lietojumprogrammas manifestus un izvietot tos Kubernetes. Jsonnet kā galvenās sintakses izmantoÅ”ana ļauj ievērojami vienkārÅ”ot atŔķirÄ«bu aprakstu dažādās vidēs, kā arÄ« gandrÄ«z pilnÄ«bā novērÅ” koda atkārtoÅ”anos.

ÄŖpaÅ”i tas var attiekties uz gadÄ«jumiem, kad lietojumprogramma ir jāizvieto vairākos klasteros ar dažādiem parametriem un vēlaties tos deklaratÄ«vi aprakstÄ«t Git.

Qbec ļauj arÄ« renderēt Helm diagrammas, nododot tām nepiecieÅ”amos parametrus un pēc tam darbināt tās tāpat kā parastos manifestus, tostarp var tām pielietot dažādas mutācijas, un tas savukārt ļauj atbrÄ«voties no nepiecieÅ”amÄ«bas izmantojiet ChartMuseum. Tas ir, jÅ«s varat saglabāt un renderēt diagrammas tieÅ”i no git, kur tās pieder.

Kā jau teicu iepriekÅ”, mēs saglabāsim visas izvietoÅ”anas direktorijā izvietot/:

mkdir deploy
cd deploy

Inicializēsim savu pirmo lietojumprogrammu:

qbec init website
cd website

Tagad mūsu lietojumprogrammas struktūra izskatās Ŕādi:

.
ā”œā”€ā”€ components
ā”œā”€ā”€ environments
ā”‚   ā”œā”€ā”€ base.libsonnet
ā”‚   ā””ā”€ā”€ default.libsonnet
ā”œā”€ā”€ params.libsonnet
ā””ā”€ā”€ qbec.yaml

paskatīsimies uz failu qbec.yaml:

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

Å eit mÅ«s galvenokārt interesē spec.vide, qbec mums jau ir izveidojis noklusējuma vidi un paņēmis servera adresi, kā arÄ« nosaukumvietu no mÅ«su paÅ”reizējās kubeconfig.
Tagad, izvietojot uz noklusējuma vidē, qbec vienmēr izvietos tikai norādÄ«tajā Kubernetes klasterÄ« un norādÄ«tajā nosaukumvietā, tas ir, jums vairs nav jāpārslēdzas starp kontekstiem un nosaukumvietām, lai veiktu izvietoÅ”anu.
Ja nepiecieÅ”ams, jÅ«s vienmēr varat atjaunināt iestatÄ«jumus Å”ajā failā.

Visas jūsu vides ir aprakstītas qbec.yaml, un failā params.libsonnet, kur ir rakstīts, kur tiem iegūt parametrus.

Tālāk mēs redzam divus direktorijus:

  • sastāvdaļas/ ā€” Å”eit tiks saglabāti visi mÅ«su lietojumprogrammas manifesti; tos var aprakstÄ«t gan jsonnet, gan parastajos yaml failos
  • vide/ ā€” Å”eit mēs aprakstÄ«sim visus mÅ«su vides mainÄ«gos (parametrus).

Pēc noklusējuma mums ir divi faili:

  • Environments/base.libsonnet - tajā bÅ«s kopēji parametri visām vidēm
  • Environments/default.libsonnet ā€” satur parametrus, kas ir ignorēti videi noklusējuma

atvērsim Environments/base.libsonnet un tur pievienojiet parametrus mūsu pirmajam komponentam:

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

Izveidosim arī savu pirmo komponentu komponenti/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,
                },
              },
            ],
          },
        },
      ],
    },
  },
]

Å ajā failā mēs aprakstÄ«jām trÄ«s Kubernetes entÄ«tijas vienlaikus, tās ir: IzvietoÅ”anas, Serviss Šø IekļūŔana. Ja mēs vēlētos, mēs tos varētu salikt dažādos komponentos, bet Å”ajā posmā mums pietiks ar vienu.

sintakse jsonnet ir ļoti lÄ«dzÄ«gs parastajam json, principā parastais json jau ir derÄ«gs jsonnet, tāpēc sākumā jums var bÅ«t vieglāk izmantot tieÅ”saistes pakalpojumus, piemēram, yaml2json lai pārvērstu savu parasto yaml par json, vai, ja jÅ«su komponenti nesatur nevienu mainÄ«go, tad tos var aprakstÄ«t parastā yaml formātā.

Strādājot ar jsonnet Es ļoti iesaku instalēt spraudni jūsu redaktoram

Piemēram, vim ir spraudnis vim-jsonnet, kas ieslēdz sintakses izcelÅ”anu un tiek automātiski izpildÄ«ts jsonnet fmt katru reizi, kad saglabājat (nepiecieÅ”ams instalēt jsonnet).

Viss ir gatavs, tagad mēs varam sākt izvietot:

Lai redzētu, ko esam ieguvuÅ”i, izpildÄ«sim:

qbec show default

Izvadē jūs redzēsit renderētus yaml manifestus, kas tiks lietoti noklusējuma klasterim.

Lieliski, tagad piesakieties:

qbec apply default

Izvadā jūs vienmēr redzēsit, kas tiks darīts jūsu klasterī, qbec lūgs jums piekrist izmaiņām, ierakstot y varēsi apstiprināt savus nodomus.

MÅ«su lietojumprogramma ir gatava un izvietota!

Ja veicat izmaiņas, vienmēr varat rÄ«koties Ŕādi:

qbec diff default

lai redzētu, kā Ŕīs izmaiņas ietekmēs paÅ”reizējo izvietoÅ”anu

Neaizmirstiet veikt mūsu izmaiņas:

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

5. Izmēģinot Gitlab-runner ar Kubernetes-izpildītāju

Vēl nesen izmantoju tikai parasto gitlab-runner uz iepriekÅ” sagatavotas iekārtas (LXC konteiners) ar čaulu vai dokeru-izpildÄ«tāju. Sākotnēji mÅ«su Gitlab laboratorijā bija vairāki Ŕādi skrējēji visā pasaulē. Viņi savāca docker attēlus visiem projektiem.

Bet, kā liecina prakse, Ŕī iespēja nav pati ideālākā gan praktiskuma, gan droŔības ziņā. Daudz labāk un ideoloÄ£iski pareizāk ir katram projektam vai pat katrai videi izvietot atseviŔķus skrējējus.

Par laimi, tā nemaz nav problēma, jo tagad mēs izvietosim gitlab-runner tieÅ”i kā daļa no mÅ«su projekta tieÅ”i Kubernetes.

Gitlab nodroÅ”ina gatavu stÅ«res diagrammu Gitlab-runner izvietoÅ”anai Kubernetes. Tāpēc viss, kas jums jādara, ir noskaidrot reÄ£istrācijas marÄ·ieris mÅ«su projektam IestatÄ«jumi -> CI / CD -> Skrējēji un nodod to stÅ«rei:

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

Kur:

  • https://gitlab.com ā€” jÅ«su Gitlab servera adrese.
  • yga8y-jdCusVDn_t4Wxc ā€” reÄ£istrācijas marÄ·ieris jÅ«su projektam.
  • rbac.create=true ā€” nodroÅ”ina skrējējam nepiecieÅ”amo privilēģiju daudzumu, lai, izmantojot kubernetes-executor, varētu izveidot podi mÅ«su uzdevumu veikÅ”anai.

Ja viss ir izdarīts pareizi, sadaļā vajadzētu redzēt reģistrētu skrējēju Runners, jūsu projekta iestatījumos.

Pievienotā skrējēja ekrānuzņēmums

Izmēģināt jaunus rÄ«kus, lai izveidotu un automatizētu izvietoÅ”anu Kubernetes

Vai tas ir tik vienkārÅ”i? - Jā, tas ir tik vienkārÅ”i! Vairs nav jārēķinās ar skrējēju manuālu reÄ£istrāciju, turpmāk skrējēji tiks izveidoti un iznÄ«cināti automātiski.

6. Izvietojiet Helm diagrammas ar QBEC

Tā kā mēs nolēmām apsvērt gitlab-runner daļa no mūsu projekta, ir pienācis laiks to aprakstīt mūsu Git repozitorijā.

Mēs to varētu raksturot kā atseviŔķu sastāvdaļu mājas lapa, bet nākotnē plānojam izvietot dažādas kopijas mājas lapa ļoti bieži, atŔķirÄ«bā no gitlab-runner, kas tiks izvietots tikai vienu reizi vienā Kubernetes klasterÄ«. Tātad inicializēsim atseviŔķu lietojumprogrammu:

cd deploy
qbec init gitlab-runner
cd gitlab-runner

Å oreiz mēs neaprakstÄ«sim Kubernetes entÄ«tijas manuāli, bet ņemsim gatavu Helm diagrammu. Viena no qbec priekÅ”rocÄ«bām ir iespēja renderēt Helm diagrammas tieÅ”i no Git repozitorija.

Savienosim to, izmantojot git apakŔmoduli:

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

Tagad direktorijs pārdevējs/gitlab-runner Mums ir repozitorijs ar gitlab-runner diagrammu.

Līdzīgā veidā jūs varat savienot citus repozitorijus, piemēram, visu repozitoriju ar oficiālajām diagrammām https://github.com/helm/charts

Aprakstīsim komponentu komponenti/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,
  }
)

Pirmais arguments, lai expandHelmTemplate mēs izejam ceļu uz diagrammu, tad parametri.vērtības, ko ņemam no vides parametriem, tad nāk objekts ar

  • nosaukums Veidne ā€” laidiena nosaukums
  • namespace ā€” nosaukumu telpa pārcelta uz stÅ«ri
  • Å”o failu ā€” obligātais parametrs, kas nodod ceļu uz paÅ”reizējo failu
  • runÄ«gs - parāda komandu stÅ«res veidne ar visiem argumentiem diagrammas renderÄ“Å”anas laikā

Tagad aprakstīsim mūsu komponenta parametrus Environments/base.libsonnet:

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

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

ŠžŠ±Ń€Š°Ń‚ŠøтŠµ Š²Š½ŠøŠ¼Š°Š½ŠøŠµ runnerRegistrationToken mēs ņemam no ārēja faila Secrets/base.libsonnet, izveidosim to:

{
  runnerRegistrationToken: 'yga8y-jdCusVDn_t4Wxc',
}

Pārbaudīsim, vai viss darbojas:

qbec show default

ja viss ir kārtÄ«bā, mēs varam dzēst mÅ«su iepriekÅ” izvietoto laidienu, izmantojot Helm:

helm uninstall gitlab-runner

un izvietojiet to tādā paŔā veidā, bet caur qbec:

qbec apply default

7. Ievads git-crypt

Git-crypt ir rÄ«ks, kas ļauj iestatÄ«t caurspÄ«dÄ«gu Å”ifrÄ“Å”anu jÅ«su repozitorijai.

Šobrīd mūsu gitlab-runner direktoriju struktūra izskatās Ŕādi:

.
ā”œā”€ā”€ components
ā”‚   ā”œā”€ā”€ gitlab-runner.jsonnet
ā”œā”€ā”€ environments
ā”‚   ā”œā”€ā”€ base.libsonnet
ā”‚   ā””ā”€ā”€ default.libsonnet
ā”œā”€ā”€ params.libsonnet
ā”œā”€ā”€ qbec.yaml
ā”œā”€ā”€ secrets
ā”‚   ā””ā”€ā”€ base.libsonnet
ā””ā”€ā”€ vendor
    ā””ā”€ā”€ gitlab-runner (submodule)

Bet noslēpumu glabāŔana pakalpojumā Git nav droÅ”a, vai ne? Tāpēc mums tie ir pareizi jāŔifrē.

Parasti viena mainīgā lieluma dēļ tam ne vienmēr ir jēga. Jūs varat pārsūtīt noslēpumus uz qbec un izmantojot jūsu CI sistēmas vides mainīgos.
Bet ir vērts atzÄ«mēt, ka ir arÄ« sarežģītāki projekti, kuros var bÅ«t daudz vairāk noslēpumu; to visu pārsÅ«tÄ«Å”ana, izmantojot vides mainÄ«gos, bÅ«s ārkārtÄ«gi sarežģīta.

Turklāt Å”ajā gadÄ«jumā es nevarētu jums pastāstÄ«t par tik brÄ«niŔķīgu rÄ«ku kā git-crypt.

git-crypt Tas ir ērts arÄ« ar to, ka ļauj saglabāt visu noslēpumu vēsturi, kā arÄ« salÄ«dzināt, apvienot un atrisināt konfliktus tādā paŔā veidā, kā mēs esam pieraduÅ”i darÄ«t Git gadÄ«jumā.

Pirmā lieta pēc uzstādÄ«Å”anas git-crypt mums ir jāģenerē mÅ«su repozitorija atslēgas:

git crypt init

Ja jums ir PGP atslēga, varat nekavējoties pievienot sevi kā lÄ«dzstrādnieku Å”im projektam:

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

Tādā veidā jÅ«s vienmēr varat atÅ”ifrēt Å”o repozitoriju, izmantojot savu privāto atslēgu.

Ja jums nav PGP atslēgas un jūs to negaidāt, varat doties citā veidā un eksportēt projekta atslēgu:

git crypt export-key /path/to/keyfile

Tādējādi ikviens, kam ir eksportēts atslēgas fails varēs atÅ”ifrēt jÅ«su repozitoriju.

Ir pienācis laiks izveidot mūsu pirmo noslēpumu.
AtgādināŔu, ka mēs joprojām atrodamies direktorijā deploy/gitlab-runner/, kur mums ir direktorijs noslēpumi/, Å”ifrēsim visus tajā esoÅ”os failus, Å”im nolÅ«kam izveidosim failu noslēpumi/.gitattributes ar Ŕādu saturu:

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

Kā redzams no satura, visi faili ir maskēti * tiks braukts cauri git-crypt, izņemot lielāko daļu .gitattributes

Mēs to varam pārbaudīt, izpildot:

git crypt status -e

Izvade bÅ«s visu repozitorijā esoÅ”o failu saraksts, kuriem ir iespējota Å”ifrÄ“Å”ana

Tas arÄ« viss. Tagad mēs varam droÅ”i veikt izmaiņas:

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

Lai bloķētu repozitoriju, vienkārÅ”i palaidiet:

git crypt lock

un uzreiz visi Å”ifrētie faili pārvērtÄ«sies par kaut ko bināru, tos izlasÄ«t nebÅ«s iespējams.
Lai atÅ”ifrētu repozitoriju, palaidiet:

git crypt unlock

8. Izveidojiet rīku kastes attēlu

RÄ«kkopas attēls ir attēls ar visiem rÄ«kiem, ko izmantosim sava projekta izvietoÅ”anai. Gitlab skrējējs to izmantos, lai veiktu tipiskus izvietoÅ”anas uzdevumus.

Šeit viss ir vienkārŔi, izveidosim jaunu Dockerfiles/Toolbox/Dockerfile ar Ŕādu saturu:

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

Kā redzat, Å”ajā attēlā mēs instalējam visas utilÄ«tas, kuras izmantojām savas lietojumprogrammas izvietoÅ”anai. Mums tas Å”eit nav vajadzÄ«gs, ja vien kubectl, taču, iespējams, vēlēsities ar to paspēlēties cauruļvada iestatÄ«Å”anas posmā.

Turklāt, lai varētu sazināties ar Kubernetes un tajā izvietot, mums ir jākonfigurē loma gitlab-runner ģenerētajiem podiem.

Lai to izdarītu, dodieties uz direktoriju ar gitlab-runner:

cd deploy/gitlab-runner

un pievienojiet jaunu komponentu komponenti/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,
      },
    ],
  },
]

Mēs arÄ« aprakstÄ«sim jaunos parametrus Environments/base.libsonnet, kas tagad izskatās Ŕādi:

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

ŠžŠ±Ń€Š°Ń‚ŠøтŠµ Š²Š½ŠøŠ¼Š°Š½ŠøŠµ $.components.rbac.name attiecas uz nosaukums komponentam rbac

Pārbaudīsim, kas ir mainījies:

qbec diff default

un piemērot mūsu izmaiņas Kubernetes:

qbec apply default

Tāpat neaizmirstiet veikt mūsu izmaiņas 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. MÅ«su pirmais cauruļvads un attēlu salikÅ”ana pēc tagiem

Projekta saknē mēs izveidosim .gitlab-ci.yml ar Ŕādu saturu:

.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

LÅ«dzu, ņemiet vērā, ka mēs izmantojam GIT_SUBMODULE_STRATEGY: normāli tiem darbiem, kuros pirms izpildes ir skaidri jāinicializē apakÅ”moduļi.

Neaizmirstiet veikt mūsu izmaiņas:

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

Es domāju, ka mēs to varam droÅ”i saukt par versiju v0.0.1 un pievienojiet tagu:

git tag v0.0.1

Mēs pievienosim atzÄ«mes ikreiz, kad bÅ«s jāizlaiž jauna versija. AtzÄ«mes Docker attēlos tiks saistÄ«tas ar Git tagiem. Katrs nospiedums ar jaunu tagu inicializēs attēlu veidoÅ”anu ar Å”o tagu.

Darīsim to git push --tags, un apskatīsim mūsu pirmo konveijeru:

Pirmā cauruļvada ekrānuzņēmums

Izmēģināt jaunus rÄ«kus, lai izveidotu un automatizētu izvietoÅ”anu Kubernetes

Ir vērts pievērst uzmanÄ«bu faktam, ka montāža ar tagiem ir piemērota docker attēlu veidoÅ”anai, bet nav piemērota lietojumprogrammas izvietoÅ”anai Kubernetes. Tā kā vecajām saistÄ«bām var pieŔķirt jaunus tagus, Å”ajā gadÄ«jumā to konveijera inicializÄ“Å”ana novedÄ«s pie vecās versijas izvietoÅ”anas.

Lai atrisinātu Å”o problēmu, docker attēlu bÅ«vÄ“Å”ana parasti ir saistÄ«ta ar tagiem un lietojumprogrammas izvietoÅ”ana filiālē. meistars, kurā apkopoto attēlu versijas ir kodētas. Å eit varat inicializēt atcelÅ”anu ar vienkārÅ”u atgrieÅ”anu meistars- filiāles.

10. IzvērÅ”anas automatizācija

Lai Gitlab-runner atÅ”ifrētu mÅ«su noslēpumus, mums bÅ«s jāeksportē repozitorija atslēga un jāpievieno tā mÅ«su CI vides mainÄ«gajiem:

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

Mēs saglabāsim iegūto rindiņu Gitlab; lai to izdarītu, dodieties uz mūsu projekta iestatījumiem:
Iestatījumi -> CI / CD -> Mainīgie

Un izveidosim jaunu mainīgo:

tips
TaustiņŔ
Vērtība
Aizsargājamie
maskēts
Joma

File
GITCRYPT_KEY
<your string>
true (apmācības laikā var false)
true
All environments

Pievienotā mainīgā ekrānuzņēmums

Izmēģināt jaunus rÄ«kus, lai izveidotu un automatizētu izvietoÅ”anu Kubernetes

Tagad atjaunināsim mūsu .gitlab-ci.yml pievienojot tam:

.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

Å eit mēs esam iespējojuÅ”i vairākas jaunas qbec opcijas:

  • --root some/app ā€” ļauj noteikt konkrētas lietojumprogrammas direktoriju
  • --force:k8s-context __incluster__ - tas ir maÄ£isks mainÄ«gais, kas saka, ka izvietoÅ”ana notiks tajā paŔā klasterÄ«, kurā darbojas gtilab-runner. Tas ir nepiecieÅ”ams, jo pretējā gadÄ«jumā qbec mēģinās atrast piemērotu Kubernetes serveri jÅ«su kubeconfig
  • --pagaidi ā€” liek qbec gaidÄ«t, lÄ«dz tā izveidotie resursi nonāk gatavÄ«bas stāvoklÄ« un tikai tad iziet ar veiksmÄ«gu izejas kodu.
  • -Jā - vienkārÅ”i atspējo interaktÄ«vo apvalku Vai esat pārliecināts? kad tas ir izvietots.

Neaizmirstiet veikt mūsu izmaiņas:

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

Un pēc git push mēs redzēsim, kā mūsu lietojumprogrammas ir izvietotas:

Otrā cauruļvada ekrānuzņēmums

Izmēģināt jaunus rÄ«kus, lai izveidotu un automatizētu izvietoÅ”anu Kubernetes

11. Artefakti un montāža, spiežot uz meistaru

Parasti ar iepriekÅ” aprakstÄ«tajām darbÄ«bām pietiek, lai izveidotu un nodroÅ”inātu gandrÄ«z jebkuru mikropakalpojumu, taču mēs nevēlamies pievienot tagu katru reizi, kad mums ir jāatjaunina vietne. Tāpēc mēs izvēlēsimies dinamiskāku marÅ”rutu un iestatÄ«sim Ä«ssavilkuma izvietoÅ”anu galvenajā filiālē.

Ideja ir vienkārÅ”a: tagad mÅ«su tēls mājas lapa tiks pārbÅ«vēta katru reizi, kad iespiedÄ«sities meistarsun pēc tam automātiski izvietot Kubernetes.

Atjaunināsim Ŕīs divas darba vietas mūsu .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"

LÅ«dzu, ņemiet vērā, ka esam pievienojuÅ”i pavedienu meistars Šŗ refs darba vietām build_website un tagad lietojam $CI_COMMIT_REF_NAME nevis $CI_COMMIT_TAG, tas ir, mēs esam atsaistÄ«ti no tagiem pakalpojumā Git, un tagad mēs nosÅ«tÄ«sim attēlu ar tās izpildes filiāles nosaukumu, kas inicializēja konveijeru. Ir vērts atzÄ«mēt, ka tas darbosies arÄ« ar tagiem, kas ļaus mums saglabāt vietnes momentuzņēmumus ar noteiktu versiju docker-reÄ£istrā.

Ja jaunās vietnes versijas docker taga nosaukums var bÅ«t nemainÄ«gs, mums joprojām ir jāapraksta Kubernetes izmaiņas, pretējā gadÄ«jumā tā vienkārÅ”i nepārvietos lietojumprogrammu no jaunā attēla, jo tā nepamanÄ«s nekādas izmaiņas izvietoÅ”anas manifests.

Opcija ā€”vm:ext-str digest=ā€$DIGESTā€ qbec ā€” ļauj nosÅ«tÄ«t ārēju mainÄ«go jsonnet. Mēs vēlamies, lai ar katru mÅ«su lietojumprogrammas laidienu tā tiktu atkārtoti izvietota klasterÄ«. Mēs vairs nevaram izmantot taga nosaukumu, kas tagad var bÅ«t nemaināms, jo mums ir jābÅ«t piesaistÄ«tam konkrētai attēla versijai un jāaktivizē izvietoÅ”ana, kad tā mainās.

Šeit mums palīdzēs Kaniko spēja saglabāt īssavilkuma attēlu failā (opcija -- Digest-fails)
Pēc tam mēs pārsÅ«tÄ«sim Å”o failu un lasÄ«sim to izvietoÅ”anas laikā.

Atjaunināsim parametrus mūsu deploy/website/environments/base.libsonnet kas tagad izskatīsies Ŕādi:

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

Gatavs, tagad iesaistieties meistars inicializē docker attēla būvniecību mājas lapa, un pēc tam izvietojiet to Kubernetes.

Neaizmirstiet veikt mūsu izmaiņas:

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

Mēs pārbaudīsim vēlāk git push mums vajadzētu redzēt kaut ko līdzīgu:

Vadītāja konveijera ekrānuzņēmums

Izmēģināt jaunus rÄ«kus, lai izveidotu un automatizētu izvietoÅ”anu Kubernetes

Principā mums nav jāpārizvieto gitlab-runner ar katru nospieŔanu, ja vien, protams, nekas nav mainījies tā konfigurācijā, izlabosim to .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/**/*

izmaiņas ļaus jums uzraudzīt izmaiņas deploy/gitlab-runner/ un aktivizēs mūsu darbu tikai tad, ja tādi būs

Neaizmirstiet veikt mūsu izmaiņas:

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

git push, tā ir labāk:

Atjauninātā konveijera ekrānuzņēmums

Izmēģināt jaunus rÄ«kus, lai izveidotu un automatizētu izvietoÅ”anu Kubernetes

12. Dinamiskās vides

Ir pienācis laiks dažādot mūsu cauruļvadu ar dinamisku vidi.

Vispirms atjaunināsim darbu build_website mūsu .gitlab-ci.yml, noņemot bloku no tā tikai, kas piespiedīs Gitlab to aktivizēt jebkurā saistībā ar jebkuru filiāli:

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/

Pēc tam atjauniniet darbu deploy_website, pievienojiet tur bloku vide:

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"

Tas ļaus Gitlab saistīt darbu ar prod vidē un parādīt pareizo saiti uz to.

Tagad pievienosim vēl divus darbus:

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

Tie tiks palaisti pēc nosÅ«tÄ«Å”anas uz jebkuru filiāli, izņemot galveno, un izvietos vietnes priekÅ”skatÄ«juma versiju.

Mēs redzam jaunu qbec opciju: --app-tag ā€” tas ļauj atzÄ«mēt izvietotās lietojumprogrammas versijas un strādāt tikai Å”ajā tagā; veidojot un iznÄ«cinot resursus Kubernetes, qbec darbosies tikai ar tiem.
Tādā veidā mēs nevaram izveidot atseviŔķu vidi katrai apskatei, bet vienkārÅ”i izmantot to paÅ”u.

Å eit mēs arÄ« izmantojam qbec piemērot pārskatÄ«Å”anu, tā vietā qbec lietot noklusējumu - tieÅ”i Å”ajā brÄ«dÄ« mēs mēģināsim aprakstÄ«t mÅ«su vides atŔķirÄ«bas (pārskatÄ«Å”ana un noklusējuma):

Pievienot pārskata vide iekŔā deploy/website/qbec.yaml

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

Tad mēs to paziņosim 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

Un pierakstiet tam pielāgotos parametrus 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',
    },
  },
}

Apskatīsim arī jobu tuvāk stop_review, tas tiks aktivizēts, kad filiāle tiks dzēsta un lai gitlab nemēģinātu izrakstīties, tas tiek izmantots GIT_STRATEGY: nav, vēlāk mēs klonējam meistars- atzarot un dzēst atsauksmi, izmantojot to.
Tas ir nedaudz mulsinoÅ”i, bet es vēl neesmu atradis skaistāku veidu.
Alternatīva iespēja būtu izvietot katru atsauksmi viesnīcas nosaukumvietā, kuru vienmēr var pilnībā nojaukt.

Neaizmirstiet veikt mūsu izmaiņas:

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

git push, git checkout -b tests, git push izcelsmes tests, pārbaudiet:

Gitlab izveidoto vidi ekrānuzņēmums

Izmēģināt jaunus rÄ«kus, lai izveidotu un automatizētu izvietoÅ”anu Kubernetes

Viss darbojas? - lieliski, izdzēsiet mÅ«su testa zaru: git izrakstÄ«Å”anās meistars, git push izcelsme: tests, mēs pārbaudām, vai vides dzÄ“Å”anas darbi darbojās bez kļūdām.

Å eit es gribētu uzreiz precizēt, ka jebkurÅ” izstrādātājs projektā var izveidot filiāles, viņŔ var arÄ« mainÄ«ties .gitlab-ci.yml failu un piekļūt slepenajiem mainÄ«gajiem.
Tāpēc ir stingri ieteicams atļaut tos izmantot tikai aizsargātām zarām, piemēram, in meistarsvai izveidojiet atseviŔķu mainÄ«go kopu katrai videi.

13. Pārskatiet lietotnes

Pārskatiet lietotnes Å Ä« ir GitLab funkcija, kas ļauj katram repozitorijā esoÅ”ajam failam pievienot pogu, lai to ātri skatÄ«tu izvietotajā vidē.

Lai Ŕīs pogas tiktu parādÄ«tas, jums ir jāizveido fails .gitlab/route-map.yml un aprakstiet tajā visas ceļa pārvērtÄ«bas; mÅ«su gadÄ«jumā tas bÅ«s ļoti vienkārÅ”i:

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

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

Neaizmirstiet veikt mūsu izmaiņas:

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

git pushun pārbaudiet:

Lietotnes pārskatÄ«Å”anas pogas ekrānuzņēmums

Izmēģināt jaunus rÄ«kus, lai izveidotu un automatizētu izvietoÅ”anu Kubernetes

Darbs darīts!

Projekta avoti:

Paldies par uzmanÄ«bu, ceru, ka jums patika Izmēģināt jaunus rÄ«kus, lai izveidotu un automatizētu izvietoÅ”anu Kubernetes

Avots: www.habr.com

Pievieno komentāru