Hello! Bubar, akeh alat otomatisasi sing keren wis dirilis kanggo nggawe gambar Docker lan kanggo penyebaran menyang Kubernetes. Ing babagan iki, aku mutusake kanggo muter-muter karo GitLab, sinau kanthi teliti kemampuane lan, mesthine, nyetel pipa.

Karya iki diilhami dening situs web kubernetes.io, kang kui saka kode sumber kanthi otomatis, lan kanggo saben panjalukan blumbang dikirim, robot kanthi otomatis ngasilake versi pratinjau situs kanthi owah-owahan sampeyan lan menehi link kanggo ndeleng.

Aku nyoba mbangun proses sing padha saka awal, nanging kabeh dibangun ing Gitlab CI lan alat gratis sing wis digunakake kanggo nyebarake aplikasi menyang Kubernetes. Dina iki pungkasane aku bakal ngandhani luwih akeh babagan dheweke.

Artikel kasebut bakal ngrembug piranti kayata:
Hugo, qbec, kaniko, git-crypt и GitLab CI kanthi nggawe lingkungan dinamis.

Konten

1. Ketemu Hugo
2. Nyiyapake file Docker
3. Ngerti kaniko
4. Ngerti qbec
5. Nyoba Gitlab-runner karo Kubernetes-executor
6. Masang denah Helm karo qbec
7. Ngenalke git-crypt
8. Nggawe gambar kothak piranti
9. Pipa pisanan lan perakitan gambar kanthi tag
10. Otomasi panyebaran
11. Artefak lan Déwan nalika meksa nindakake perkara master
12. Lingkungan dinamis
13. Deleng Aplikasi

1. Ngerti Hugo

Minangka conto proyek kita, kita bakal nyoba nggawe situs penerbitan dokumentasi sing dibangun ing Hugo. Hugo minangka generator konten statis.

Kanggo sing ora menowo generator statis, Aku bakal pitutur marang kowe sethitik liyane babagan. Ora kaya mesin situs web konvensional kanthi basis data lan sawetara PHP, sing, nalika dijaluk pangguna, ngasilake kaca kanthi cepet, generator statis dirancang rada beda. Dheweke ngidini sampeyan njupuk sumber, biasane sakumpulan file ing markup Markdown lan template tema, banjur ngumpulake menyang situs web sing wis rampung.

Dadi, minangka asil, sampeyan bakal nampa struktur direktori lan set file HTML sing digawe, sing mung bisa diunggah menyang hosting sing murah lan entuk situs web sing bisa digunakake.

Sampeyan bisa nginstal Hugo sacara lokal lan nyoba:

Miwiti situs anyar:

hugo new site docs.example.org

Lan ing wektu sing padha repositori git:

cd docs.example.org
git init

Nganti saiki, situs kita resik lan supaya ana sing katon, mula kita kudu nyambungake tema; tema mung sakumpulan template lan aturan tartamtu sing digawe situs kita.

Kanggo tema sing bakal kita gunakake sinau, kang, ing mratelakake panemume, iku sampurna cocog kanggo situs dokumentasi.

Aku pengin menehi perhatian khusus kanggo kasunyatan manawa kita ora perlu nyimpen file tema ing repositori proyek kita; tinimbang, kita mung bisa nyambungake nggunakake submodul git:

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

Mangkono, repositori kita mung bakal ngemot file sing ana hubungane langsung karo proyek kita, lan tema sing disambungake bakal tetep minangka link menyang repositori tartamtu lan komitmen, yaiku, bisa ditarik saka sumber asli lan ora wedi. owah-owahan sing ora cocog.

Ayo mbenerake konfigurasi config.toml:

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

Wis ing tahap iki sampeyan bisa mbukak:

hugo server

Lan ing alamat http://localhost:1313/ mriksa situs web sing mentas digawe, kabeh owah-owahan sing digawe ing direktori kanthi otomatis nganyari kaca mbukak ing browser, trep banget!

Ayo nyoba nggawe kaca panutup ing isi/_index.md:

# My docs site

## Welcome to the docs!

You will be very smart :-)

Screenshot kaca sing mentas digawe

Kanggo nggawe situs, mung mbukak:

hugo

Isi direktori umum/ lan bakal dadi situs web sampeyan.
Ya wis, ayo langsung ditambahi .giignore:

echo /public > .gitignore

Aja lali kanggo nindakake owah-owahan kita:

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

2. Nyiapake Dockerfile

Wektu kanggo nemtokake struktur repositori kita. Aku biasane nggunakake kaya:

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

• dockerfiles/ - ngemot direktori karo Dockerfiles lan kabeh sing dibutuhake kanggo nggawe gambar Docker.
• masang/ — ngemot direktori kanggo nyebarake aplikasi kita menyang Kubernetes

Mangkono, kita bakal nggawe Dockerfile pisanan kita ing dalan dockerfiles / situs web / 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" ]

Kaya sing sampeyan ngerteni, Dockerfile ngemot loro saka, kesempatan iki diarani mbangun multi-tataran lan ngidini sampeyan ngilangi kabeh sing ora perlu saka gambar Docker pungkasan.
Mangkono, gambar pungkasan mung bakal ngemot petenghttpd (server HTTP entheng) lan umum/ — isi situs web sing digawe statis.

Aja lali kanggo nindakake owah-owahan kita:

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

3. Ngerti kaniko

Minangka tukang gambar docker, aku mutusake kanggo nggunakake kaniko, amarga operasi kasebut ora mbutuhake daemon docker, lan mbangun dhewe bisa ditindakake ing mesin apa wae lan cache bisa disimpen langsung ing registri, saéngga ngilangi kabutuhan panyimpenan sing terus-terusan.

Kanggo mbangun gambar, mung mbukak wadhah karo kaniko pelaksana lan pass konteks mbangun saiki; iki uga bisa ditindakake sacara lokal, liwat 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

Ngendi registry.gitlab.com/kvaps/docs.example.org/website - jeneng gambar docker sampeyan; sawise mbangun, bakal diluncurake kanthi otomatis menyang registri docker.

Parameter --cache ngijini sampeyan kanggo cache lapisan ing pendaptaran docker; kanggo conto diwenehi, padha bakal disimpen ing registry.gitlab.com/kvaps/docs.example.org/website/cache, nanging sampeyan bisa nemtokake path liyane nggunakake parameter --cache-repo.

Screenshot saka docker-registry

4. Ngerti qbec

Qbec minangka alat panyebaran sing ngidini sampeyan njlèntrèhaké manifests aplikasi lan nyebar menyang Kubernetes. Nggunakake Jsonnet minangka sintaks utama ngidini sampeyan nyederhanakake katrangan babagan beda ing pirang-pirang lingkungan, lan uga meh ngilangi pengulangan kode.

Iki bisa uga bener ing kasus nalika sampeyan kudu masang aplikasi menyang sawetara klompok kanthi paramèter sing beda-beda lan pengin njlèntrèhaké kanthi deklaratif ing Git.

Qbec uga ngijini sampeyan kanggo nerjemahake denah Helm dening maringaken paramèter sing perlu lan banjur operate ing cara sing padha karo manifests biasa, kalebu sampeyan bisa aplikasi macem-macem mutasi kanggo wong-wong mau, lan iki, siji, ngijini sampeyan kanggo njaluk nyisihaken saka perlu nggunakake ChartMuseum. Yaiku, sampeyan bisa nyimpen lan nerjemahake grafik langsung saka git, ing ngendi wae.

Kaya sing dakkandhakake sadurunge, kita bakal nyimpen kabeh penyebaran ing direktori masang/:

mkdir deploy
cd deploy

Ayo miwiti aplikasi pisanan kita:

qbec init website
cd website

Saiki struktur aplikasi kita katon kaya iki:

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

ayo dideleng file kasebut qbec.yaml:

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

Kene kita utamané kasengsem ing spec.lingkungan, qbec wis nggawe lingkungan standar kanggo kita lan njupuk alamat server, uga namespace saka kubeconfig kita saiki.
Saiki nalika deploying kanggo standar lingkungan, qbec bakal tansah nyebarke mung kanggo kluster Kubernetes sing ditemtokake lan kanggo spasi jeneng sing ditemtokake, yaiku, sampeyan ora kudu ngalih ing antarane konteks lan spasi jeneng kanggo nindakake penyebaran.
Yen perlu, sampeyan bisa tansah nganyari setelan ing berkas iki.

Kabeh lingkungan sampeyan diterangake ing qbec.yaml, lan ing file params.libsonnet, ngendi ngandika ngendi kanggo njaluk paramèter kanggo wong-wong mau.

Sabanjure kita ndeleng rong direktori:

• komponen / - kabeh manifests kanggo aplikasi kita bakal disimpen ing kene; bisa diterangake ing file jsonnet lan yaml biasa
• lingkungan/ - ing kene kita bakal njlèntrèhaké kabeh variabel (parameter) kanggo lingkungan kita.

Kanthi gawan, kita duwe rong file:

• environments/base.libsonnet - bakal ngemot paramèter umum kanggo kabeh lingkungan
• lingkungan/default.libsonnet - ngandhut paramèter overridden kanggo lingkungan standar

ayo mbukak environments/base.libsonnet lan tambahake paramèter kanggo komponen pisanan kita ing kana:

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

Ayo uga nggawe komponen pisanan kita component/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,
                },
              },
            ],
          },
        },
      ],
    },
  },
]

Ing file iki kita nerangake telung entitas Kubernetes bebarengan, yaiku: penyebaran prajurit, Service и Ingress. Yen kita pengin, kita bisa nyelehake menyang komponen sing beda-beda, nanging ing tahap iki, siji bakal cukup kanggo kita.

sintaks jsonnet mirip banget karo json biasa, ing prinsip, json biasa wis dadi jsonnet sing sah, mula bisa uga luwih gampang sampeyan nggunakake layanan online kaya yaml2json Ngonversi yaml biasa dadi json, utawa, yen komponen sampeyan ora ngemot variabel, mula bisa diterangake ing wangun yaml biasa.

Nalika nggarap jsonnet Aku banget nyaranake nginstal plugin kanggo editor sampeyan

Contone, ana plugin kanggo vim vim-jsonnet, sing ngaktifake panyorot sintaks lan dieksekusi kanthi otomatis jsonnet fmt saben-saben sampeyan nyimpen (mbutuhake jsonnet diinstal).

Kabeh wis siyap, saiki kita bisa miwiti nyebarake:

Kanggo ndeleng apa sing entuk, ayo mbukak:

qbec show default

Ing output, sampeyan bakal weruh manifests yaml render sing bakal diterapake ing kluster standar.

Apik, saiki aplikasi:

qbec apply default

Ing output sampeyan bakal tansah ndeleng apa sing bakal ditindakake ing kluster sampeyan, qbec bakal njaluk sampeyan setuju karo owah-owahan kanthi ngetik y sampeyan bakal bisa kanggo konfirmasi niat.

Aplikasi kita wis siyap lan disebarake!

Yen sampeyan nggawe owah-owahan, sampeyan bisa nindakake:

qbec diff default

kanggo ndeleng carane owah-owahan iki bakal mengaruhi penyebaran saiki

Aja lali kanggo nindakake owah-owahan kita:

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

5. Nyoba Gitlab-runner karo Kubernetes-eksekutor

Nganti saiki aku mung nganggo biasa gitlab-runner ing mesin sing wis disiapake (wadhah LXC) karo cangkang utawa docker-executor. Kaping pisanan, kita duwe sawetara pelari sing ditetepake sacara global ing gitlab kita. Dheweke nglumpukake gambar docker kanggo kabeh proyek.

Nanging minangka praktik wis ditampilake, pilihan iki ora paling becik, ing babagan kepraktisan lan safety. Iku luwih apik lan ideologically luwih bener duwe pelari kapisah tugasaken kanggo saben project, utawa malah kanggo saben lingkungan.

Untunge, iki ora dadi masalah, amarga saiki kita bakal nyebarake gitlab-runner langsung minangka bagéan saka project kita tengen ing Kubernetes.

Gitlab nyedhiyakake grafik helm sing wis siap kanggo nyebarake gitlab-runner menyang Kubernetes. Dadi kabeh sing kudu ditindakake yaiku ngerteni token registrasi kanggo proyek kita ing Setelan -> CI / CD -> Runners lan liwati menyang setir:

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

Ngendi:

• https://gitlab.com — alamat server Gitlab sampeyan.
• yga8y-jdCusVDn_t4Wxc - token registrasi kanggo proyek sampeyan.
• rbac.create=bener - nyedhiyakake pelari kanthi jumlah hak istimewa sing dibutuhake supaya bisa nggawe pods kanggo nindakake tugas kita nggunakake kubernetes-executor.

Yen kabeh wis rampung kanthi bener, sampeyan kudu ndeleng runner kadhaptar ing bagean kasebut Pelatih, ing setelan proyek sampeyan.

Screenshot saka runner ditambahaké

Apa iku prasaja? - ya, iku sing prasaja! Ora ana repot ndhaptar pelari kanthi manual, wiwit saiki pelari bakal digawe lan dirusak kanthi otomatis.

6. Nyebar denah Helm karo QBEC

Awit kita mutusaké kanggo nimbang gitlab-runner bagean saka project kita, iku wektu kanggo njlèntrèhaké ing repositori Git kita.

Kita bisa njlèntrèhaké minangka komponen kapisah situs, nanging ing mangsa ngarep kita rencana kanggo nyebarake salinan sing beda-beda situs asring banget, ora kaya gitlab-runner, sing bakal disebarake mung sapisan saben kluster Kubernetes. Dadi ayo miwiti aplikasi sing kapisah:

cd deploy
qbec init gitlab-runner
cd gitlab-runner

Wektu iki kita ora bakal njlèntrèhaké entitas Kubernetes kanthi manual, nanging bakal njupuk bagan Helm sing wis siap. Salah sawijining kaluwihan qbec yaiku kemampuan kanggo nggawe grafik Helm langsung saka gudang Git.

Ayo sambungake nggunakake submodule git:

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

Saiki direktori vendor / gitlab-runner Kita duwe repositori kanthi grafik kanggo gitlab-runner.

Kanthi cara sing padha, sampeyan bisa nyambungake repositori liyane, umpamane, kabeh repositori kanthi grafik resmi https://github.com/helm/charts

Ayo dadi njlèntrèhaké komponen komponen/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,
  }
)

Argumentasi pisanan kanggo expandHelmTemplate kita pass path menyang grafik, banjur params.nilai, sing kita njupuk saka paramèter lingkungan, banjur nerangake obyek karo

• nameTemplate - jeneng release
• namespace - namespace ditransfer menyang setir
• File iki - parameter sing dibutuhake sing ngliwati path menyang file saiki
• tembung kriya - nuduhake printah Cithakan helm karo kabeh argumen nalika nggawe grafik

Saiki ayo njlèntrèhaké paramèter kanggo komponen kita ing 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,
      },
    },
  },
}

Delengen runnerRegistrationToken kita njupuk saka file external rahasia/base.libsonnet, ayo nggawe:

{
  runnerRegistrationToken: 'yga8y-jdCusVDn_t4Wxc',
}

Ayo priksa manawa kabeh bisa digunakake:

qbec show default

yen kabeh wis rapi, mula kita bisa mbusak rilis sing wis disebarake liwat Helm:

helm uninstall gitlab-runner

lan nyebarake kanthi cara sing padha, nanging liwat qbec:

qbec apply default

7. Pambuka kanggo git-crypt

Git-crypt minangka alat sing ngidini sampeyan nyetel enkripsi transparan kanggo gudang sampeyan.

Saiki, struktur direktori kita kanggo gitlab-runner katon kaya iki:

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

Nanging nyimpen rahasia ing Git ora aman, ta? Dadi kita kudu ndhelik kanthi bener.

Biasane, kanggo siji variabel, iki ora mesthi ana akal. Sampeyan bisa nransfer rahasia menyang qbec lan liwat variabel lingkungan sistem CI sampeyan.
Nanging kudu dicathet yen ana uga proyek sing luwih rumit sing bisa ngemot luwih akeh rahasia; nransfer kabeh liwat variabel lingkungan bakal angel banget.

Menapa malih, ing kasus iki, aku ora bakal bisa nyritakake babagan alat sing apik banget git-crypt.

git-crypt Sampeyan uga trep amarga ngidini sampeyan nyimpen kabeh sejarah rahasia, uga mbandhingake, nggabungake lan ngrampungake konflik kanthi cara sing padha kaya sing biasa ditindakake ing kasus Git.

Kaping pisanan sawise instalasi git-crypt kita kudu ngasilake kunci kanggo repositori kita:

git crypt init

Yen sampeyan duwe kunci PGP, sampeyan bisa langsung nambah dhewe minangka kolaborator kanggo proyek iki:

git-crypt add-gpg-user kvapss@gmail.com

Kanthi cara iki sampeyan bisa tansah dekripsi gudang iki nggunakake kunci pribadi.

Yen sampeyan ora duwe kunci PGP lan ora ngarep-arep, sampeyan bisa ngekspor kunci proyek kasebut:

git crypt export-key /path/to/keyfile

Mangkono, sapa sing wis diekspor file kunci bakal bisa dekripsi repositori sampeyan.

Iku wektu kanggo nyetel rahasia pisanan kita.
Ayo kula ngelingake yen kita isih ana ing direktori deploy/gitlab-runner/, ngendi kita duwe direktori rahasia/, ayo enkripsi kabeh file ing kono, kanggo iki kita bakal nggawe file rahasia/.gitattributes kanthi isi ing ngisor iki:

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

Kaya sing bisa dideleng saka konten kasebut, kabeh file ditutupi * bakal mimpin liwat git-crypt, kajaba sing paling .gitattributes

Kita bisa mriksa iki kanthi mlaku:

git crypt status -e

Output bakal dadi dhaptar kabeh file ing repositori sing enkripsi diaktifake

Iku kabeh, saiki kita bisa nindakake owah-owahan kanthi aman:

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

Kanggo mblokir repositori, mung mbukak:

git crypt lock

lan langsung kabeh file sing dienkripsi bakal dadi binar, mula ora bisa diwaca.
Kanggo dekripsi repositori, bukak:

git crypt unlock

8. Nggawe gambar kothak piranti

Gambar kothak piranti minangka gambar kanthi kabeh alat sing bakal digunakake kanggo nyebarake proyek. Bakal digunakake dening pelari Gitlab kanggo nindakake tugas panyebaran khas.

Kabeh gampang ing kene, ayo nggawe sing anyar dockerfiles/toolbox/Dockerfile kanthi isi ing ngisor iki:

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

Kaya sing sampeyan ngerteni, ing gambar iki, kita nginstal kabeh utilitas sing digunakake kanggo nyebarake aplikasi. Kita ora butuh ing kene kajaba kubectl, nanging sampeyan bisa uga pengin muter-muter nalika fase persiyapan pipa.

Uga, supaya bisa komunikasi karo Kubernetes lan nyebarake, kita kudu ngatur peran kanggo polong sing digawe dening gitlab-runner.

Kanggo nindakake iki, ayo pindhah menyang direktori nganggo gitlab-runner:

cd deploy/gitlab-runner

lan nambah komponen anyar komponen/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,
      },
    ],
  },
]

Kita uga bakal njlèntrèhaké paramèter anyar ing environments/base.libsonnet, sing saiki katon kaya iki:

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

Delengen $.components.rbac.name nuduhake jeneng kanggo komponen rbac

Ayo priksa apa sing wis diganti:

qbec diff default

lan aplikasi owah-owahan kita menyang Kubernetes:

qbec apply default

Uga, aja lali nindakake owah-owahan menyang 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. Pipo pisanan lan perakitan gambar kanthi tag

Ing ROOT saka project kita bakal nggawe .gitlab-ci.yml kanthi isi ing ngisor iki:

.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

Wigati dimangerteni yen kita nggunakake GIT_SUBMODULE_STRATEGY: normal kanggo proyek sing sampeyan kudu nginisialisasi submodul kanthi jelas sadurunge eksekusi.

Aja lali kanggo nindakake owah-owahan kita:

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

Aku kita bisa kanthi aman nelpon iki versi v0.0.1 lan nambah tag:

git tag v0.0.1

Kita bakal nambah tag kapan kita kudu ngeculake versi anyar. Tag ing gambar Docker bakal diikat karo tag Git. Saben push kanthi tag anyar bakal nggawe wiwitan gambar kanthi tag iki.

Ayo padha nindakake git push --tags, lan ayo goleki pipa pertama kita:

Screenshot saka pipeline pisanan

Iku worth tarik manungsa waé kanggo kasunyatan sing perakitan dening tags cocok kanggo mbangun gambar docker, nanging ora cocok kanggo deploying aplikasi kanggo Kubernetes. Amarga tag anyar bisa ditugasake menyang komitmen lawas, ing kasus iki, nginisialisasi pipa kasebut bakal nyebabake penyebaran versi lawas.

Kanggo ngatasi masalah iki, biasane mbangun gambar docker diikat karo tag, lan panyebaran aplikasi menyang cabang. Master, kang versi gambar sing diklumpukake hardcoded. Iki ngendi sampeyan bisa initialize rollback karo bali prasaja Master- cabang.

10. Otomatisasi penyebaran

Supaya Gitlab-runner bisa dekripsi rahasia kita, kita kudu ngekspor kunci repositori lan ditambahake menyang variabel lingkungan CI kita:

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

Kita bakal nyimpen baris asil ing Gitlab; kanggo nindakake iki, ayo pindhah menyang setelan proyek:
Setelan -> CI / CD -> Variabel

Lan ayo nggawe variabel anyar:

Koleksi
Key
Value
dilindhungi
Masked
Scope

File
GITCRYPT_KEY
<your string>
true (sajrone latihan sampeyan bisa false)
true
All environments

Screenshot saka variabel sing ditambahake

Saiki ayo nganyari kita .gitlab-ci.yml nambahi:

.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

Ing kene kita wis ngaktifake sawetara opsi anyar kanggo qbec:

• --root sawetara / app — ngidini sampeyan nemtokake direktori aplikasi tartamtu
• --force:k8s-context __incluster__ - iki variabel tenung sing ngandika sing penyebaran prajurit bakal kelakon ing kluster padha kang gtilab-runner mlaku. Iki perlu amarga yen qbec bakal nyoba golek server Kubernetes cocok ing kubeconfig Panjenengan
• --ngenteni - meksa qbec ngenteni nganti sumber daya sing digawe menyang negara Siap lan mung banjur metu karo sukses metu-kode.
• — ya - mung mateni cangkang interaktif Sampeyan yakin? nalika disebarake.

Aja lali kanggo nindakake owah-owahan kita:

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

Lan sawise git push kita bakal weruh carane aplikasi kita wis disebarake:

Screenshot saka pipa kapindho

11. Artefak lan Déwan nalika meksa nindakake perkara master

Biasane, langkah-langkah sing diterangake ing ndhuwur cukup kanggo mbangun lan ngirim meh kabeh layanan mikro, nanging kita ora pengin nambah tag saben-saben kita kudu nganyari situs kasebut. Mulane, kita bakal njupuk rute sing luwih dinamis lan nyiyapake penyebaran pencernaan ing cabang master.

Ide iki prasaja: saiki gambar kita situs bakal dibangun maneh saben-saben sampeyan push menyang Master, banjur disebarake kanthi otomatis menyang Kubernetes.

Ayo nganyari loro proyek iki ing kita .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"

Wigati dimangerteni yen kita wis nambahake thread Master к refs kanggo proyek mbangun_situs web lan saiki kita nggunakake $CI_COMMIT_REF_NAME tinimbang $CI_COMMIT_TAG, yaiku, kita dibubarake saka tag ing Git lan saiki kita bakal push gambar kanthi jeneng cabang commit sing miwiti pipa. Wigati dicathet yen iki uga bakal bisa digunakake karo tag, sing bakal ngidini kita nyimpen jepretan situs kanthi versi tartamtu ing pendaptaran docker.

Nalika jeneng tag docker kanggo versi anyar saka situs bisa ora diganti, kita isih kudu njlèntrèhaké owah-owahan ing Kubernetes, yen ora, iku mung ora bakal redeploy aplikasi saka gambar anyar, amarga ora bakal sok dong mirsani owah-owahan ing panyebaran manifest.

Pilihan —vm:ext-str digest=”$DIGEST” kanggo qbec - ngijini sampeyan kanggo pass variabel external kanggo jsonnet. Kita pengin supaya redeployed ing kluster karo saben release saka aplikasi kita. Kita ora bisa nggunakake jeneng tag maneh, sing saiki ora bisa diganti, amarga kita kudu diikat menyang versi tartamtu saka gambar lan micu penyebaran nalika owah-owahan.

Ing kene kita bakal dibantu dening kemampuan Kaniko kanggo nyimpen gambar sing dicerna menyang file (opsi --digest-file)
Banjur kita bakal nransfer file iki lan maca ing wektu penyebaran.

Ayo nganyari paramèter kanggo kita deploy/website/environments/base.libsonnet sing saiki bakal katon kaya iki:

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

Rampung, saiki ana komitmen apa wae Master initializes mbangun gambar docker kanggo situs, banjur pasang menyang Kubernetes.

Aja lali kanggo nindakake owah-owahan kita:

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

Dipriksa mengko git push kita kudu ndeleng kaya iki:

Screenshot saka pipeline kanggo master

Ing asas, kita ora perlu redeploy gitlab-runner karo saben push, kajaba, mesthi, ora ana owah-owahan ing konfigurasi sawijining, ayo ndandani ing .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/**/*

malih bakal ngidini sampeyan ngawasi owah-owahan ing deploy/gitlab-runner/ lan bakal micu proyek kita mung yen ana

Aja lali kanggo nindakake owah-owahan kita:

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

git push, kuwi luwih apik:

Gambar saka pipa sing dianyari

12. Lingkungan dinamis

Iku wektu kanggo diversifikasi pipa karo lingkungan dinamis.

Pisanan, ayo nganyari proyek mbangun_situs web ing kita .gitlab-ci.yml, mbusak blok saka iku mung, sing bakal meksa Gitlab kanggo micu ing sembarang komit menyang cabang apa wae:

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/

Banjur nganyari proyek deploy_website, nambah blok ana lingkungan:

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"

Iki bakal ngidini Gitlab nggandhengake proyek kasebut produk lingkungan lan nampilake link sing bener.

Saiki ayo nambah rong proyek liyane:

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

Dheweke bakal diluncurake kanthi push menyang cabang apa wae kajaba master lan bakal masang versi pratinjau situs kasebut.

Kita ndeleng opsi anyar kanggo qbec: --app-tag - ngidini sampeyan menehi tag versi aplikasi sing wis disebarake lan mung bisa digunakake ing tag iki; nalika nggawe lan ngrusak sumber daya ing Kubernetes, qbec mung bisa digunakake.
Kanthi cara iki, kita ora bisa nggawe lingkungan sing kapisah kanggo saben review, nanging mung nggunakake maneh lingkungan sing padha.

Kene kita uga nggunakake qbec aplikasi review, tinimbang qbec aplikasi standar - iki persis nalika kita bakal nyoba kanggo njlèntrèhaké beda kanggo lingkungan kita (review lan standar):

Ayo ditambahake review lingkungan ing deploy/website/qbec.yaml

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

Banjur kita bakal ngumumake ing 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

Lan tulisake paramèter khusus ing 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',
    },
  },
}

Ayo uga nliti jobu stop_review, bakal dipicu nalika cabang dibusak lan supaya gitlab ora nyoba mriksa metu digunakake GIT_STRATEGY: ora ana, mengko kita kloning Master-cabang lan mbusak review liwat.
Iku rada bingung, nanging aku durung nemokake cara sing luwih apik.
Pilihan alternatif yaiku masang saben review menyang ruang jeneng hotel, sing bisa dibongkar kabeh.

Aja lali kanggo nindakake owah-owahan kita:

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

git push, git checkout -b tes, tes asal git push, mrikso:

Screenshot saka lingkungan digawe ing Gitlab

Kabeh bisa digunakake? - apik, mbusak cabang tes kita: master checkout git, git push asal: test, kita priksa manawa proyek pambusakan lingkungan bisa digunakake tanpa kesalahan.

Ing kene aku pengin langsung njlentrehake manawa pangembang ing proyek bisa nggawe cabang, dheweke uga bisa ngganti .gitlab-ci.yml file lan ngakses variabel rahasia.
Mulane, dianjurake kanggo nggunakake mung kanggo cabang sing dilindhungi, contone ing Master, utawa nggawe set variabel sing kapisah kanggo saben lingkungan.

13. Priksa Aplikasi

Deleng Aplikasi Iki minangka fitur GitLab sing ngidini sampeyan nambah tombol kanggo saben file ing repositori supaya bisa ndeleng kanthi cepet ing lingkungan sing disebarake.

Supaya tombol kasebut katon, sampeyan kudu nggawe file .gitlab/rute-map.yml lan njlèntrèhaké kabeh transformasi path ing; ing kasus kita bakal gampang banget:

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

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

Aja lali kanggo nindakake owah-owahan kita:

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

git push, lan priksa:

Screenshot saka tombol Review App

Proyek wis rampung!

Sumber proyek:

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

Matur nuwun kanggo perhatian sampeyan, muga-muga sampeyan seneng

Source: www.habr.com