Здраво! Недавно су објављени многи сјајни алати за аутоматизацију и за прављење Доцкер слика и за примену у Кубернетес. С тим у вези, одлучио сам да се поиграм са ГитЛабом, темељно проучим његове могућности и, наравно, поставим цевовод.

Овај рад је инспирисан веб страницом кубернетес.ио, који се генерише из изворни кодови аутоматски, а за сваки послат захтев за базен, робот аутоматски генерише верзију сајта за преглед са вашим изменама и пружа везу за преглед.

Покушао сам да направим сличан процес од нуле, али у потпуности изграђен на Гитлаб ЦИ и бесплатним алатима које сам навикао да користим за постављање апликација у Кубернетес. Данас ћу вам коначно рећи нешто више о њима.

У чланку ће се говорити о алатима као што су:
Хуго, кбец, канико, гит-црипт и ГитЛаб ЦИ уз стварање динамичних окружења.

Садржај

1. Упознајте Хуга
2. Припрема Доцкерфиле-а
3. Упознавање канико
4. Упознавање кбец-а
5. Испробавање Гитлаб-руннер-а са Кубернетес-екецутор-ом
6. Примена Хелм графикона са кбец-ом
7. Представљамо гит-црипт
8. Креирање слике кутије са алаткама
9. Наш први цевовод и склапање слика по ознакама
10. Аутоматизација имплементације
11. Артефакти и монтажа приликом гурања до мастера
12. Динамична окружења
13. Прегледајте апликације

1. Упознавање Хуга

Као пример нашег пројекта, покушаћемо да направимо сајт за објављивање документације изграђен на Хугу. Хуго је генератор статичког садржаја.

За оне који нису упознати са статичким генераторима, рећи ћу вам нешто више о њима. За разлику од конвенционалних механизама за веб сајтове са базом података и неким ПХП-ом, који на захтев корисника генеришу странице у ходу, статички генератори су дизајнирани мало другачије. Они вам омогућавају да узмете изворе, обично скуп датотека у Маркдовн ознакама и шаблонима тема, а затим их саставите у потпуно готову веб локацију.

То јест, као резултат, добићете структуру директоријума и скуп генерисаних ХТМЛ датотека, које можете једноставно да отпремите на било који јефтини хостинг и добијете радну веб локацију.

Можете инсталирати Хуго локално и испробати га:

Иницијализација новог сајта:

hugo new site docs.example.org

И у исто време гит спремиште:

cd docs.example.org
git init

За сада је наш сајт нетакнут и да би се нешто појавило на њему, потребно је прво да повежемо тему; тема је само скуп шаблона и одређених правила по којима се наш сајт генерише.

За тему коју ћемо користити Научити, који је, по мом мишљењу, савршено прикладан за сајт за документацију.

Желео бих да обратим посебну пажњу на чињеницу да не морамо да чувамо датотеке тема у нашем репозиторијуму пројекта; уместо тога, можемо га једноставно повезати помоћу гит подмодул:

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

Дакле, наше спремиште ће садржати само датотеке директно везане за наш пројекат, а повезана тема ће остати као веза до одређеног спремишта и урезивање у њему, односно увек се може извући из оригиналног извора и не плашити се неспојиве промене.

Исправимо конфигурацију цонфиг.томл:

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

Већ у овој фази можете покренути:

hugo server

И то на адреси http://localhost:1313/ проверите нашу новостворену веб страницу, све промене направљене у директоријуму аутоматски ажурирају отворену страницу у претраживачу, веома згодно!

Хајде да покушамо да направимо насловну страну у цонтент/_индек.мд:

# My docs site

## Welcome to the docs!

You will be very smart :-)

Снимак екрана новокреиране странице

Да бисте генерисали сајт, само покрените:

hugo

Садржај именика јавно/ и биће ваша веб локација.
Да, узгред, хајде да га одмах додамо .гитигноре:

echo /public > .gitignore

Не заборавите да унесете наше промене:

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

2. Припрема Доцкерфиле-а

Време је да дефинишемо структуру нашег спремишта. Обично користим нешто попут:

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

• доцкерфилес/ — садрже директоријуме са Доцкер фајловима и свиме што је потребно за прављење наших Доцкер слика.
• развити/ — садржи директоријуме за постављање наших апликација у Кубернетес

Тако ћемо креирати наш први Доцкерфиле дуж путање доцкерфилес/вебсите/Доцкерфиле

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" ]

Као што видите, Доцкерфиле садржи два ИЗ, ова прилика се зове вишестепена изградња и омогућава вам да искључите све непотребно из коначне доцкер слике.
Дакле, коначна слика ће садржати само даркхттпд (лаки ХТТП сервер) и јавно/ — садржај наше статички генерисане веб странице.

Не заборавите да унесете наше промене:

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

3. Упознавање канико

Као градитељ доцкер слика, одлучио сам да користим канико, пошто за његов рад није потребан доцкер демон, а сама градња се може извршити на било којој машини и кеш се може ускладиштити директно у регистратору, чиме се елиминише потреба за пуноправним постојаним складиштем.

Да бисте направили слику, само покрените контејнер са канико извршилац и проследите му тренутни контекст изградње; ово се такође може урадити локално, преко доцкер-а:

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

где регистри.гитлаб.цом/квапс/доцс.екампле.орг/вебсите — назив ваше доцкер слике; након изградње, аутоматски ће бити покренут у регистратор доцкер-а.

Параметар --цацхе омогућава вам да кеширате слојеве у доцкер регистру; у датом примеру они ће бити сачувани регистри.гитлаб.цом/квапс/доцс.екампле.орг/вебсите/цацхе, али можете одредити другу путању помоћу параметра --цацхе-репо.

Снимак екрана доцкер-регистра

4. Упознавање кбец-а

Кбец је алатка за примену која вам омогућава да декларативно опишете манифесте своје апликације и примените их на Кубернетес. Коришћење Јсоннет-а као главне синтаксе омогућава вам да у великој мери поједноставите опис разлика у више окружења, а такође скоро у потпуности елиминишете понављање кода.

Ово може бити посебно тачно у случајевима када треба да примените апликацију на неколико кластера са различитим параметрима и желите да их декларативно опишете у Гиту.

Кбец вам такође омогућава да прикажете Хелмове графиконе тако што ћете им прослеђивати неопходне параметре, а затим управљати њима на исти начин као и редовним манифестима, укључујући и на њих можете применити различите мутације, а то вам, заузврат, омогућава да се ослободите потребе да користите ЦхартМусеум. То јест, можете да складиштите и рендерујете графиконе директно из гит-а, где им је место.

Као што сам раније рекао, све имплементације ћемо чувати у директоријуму развити/:

mkdir deploy
cd deploy

Хајде да иницијализујемо нашу прву апликацију:

qbec init website
cd website

Сада структура наше апликације изгледа овако:

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

погледајмо фајл кбец.иамл:

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

Овде нас првенствено занима спец.енвиронментс, кбец је већ креирао подразумевано окружење за нас и узео адресу сервера, као и именски простор из нашег тренутног кубецонфиг-а.
Сада приликом распоређивања на Уобичајено окружење, кбец ће се увек применити само на наведени Кубернетес кластер и на наведени простор имена, то јест, више не морате да прелазите између контекста и простора имена да бисте се применили.
Ако је потребно, увек можете ажурирати подешавања у овој датотеци.

Сва ваша окружења су описана у кбец.иамл, и у датотеци парамс.либсоннет, где пише где да добијете параметре за њих.

Затим видимо два директорија:

• компоненте / — сви манифести за нашу апликацију ће бити ускладиштени овде; могу се описати и у јсоннет иу регуларним иамл датотекама
• окружења/ — овде ћемо описати све варијабле (параметре) за наша окружења.

Подразумевано имамо две датотеке:

• окружења/басе.либсоннет - садржаће заједничке параметре за сва окружења
• окружења/подразумевано.либсоннет — садржи параметре замењене за окружење Уобичајено

отворимо окружења/басе.либсоннет и додајте параметре за нашу прву компоненту тамо:

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

Хајде да креирамо и нашу прву компоненту компоненте/вебсајт.јсоннет:

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

У овој датотеци смо описали три Кубернетес ентитета одједном, а то су: развој, сервис и Улаз. Да смо желели, могли бисмо да их ставимо у различите компоненте, али у овој фази ће нам једна бити довољна.

синтакса јсоннет је веома сличан обичном јсон-у, у принципу, обичан јсон је већ важећи јсоннет, тако да ће вам у почетку можда бити лакше да користите онлајн услуге као што су иамл2јсон да конвертујете свој уобичајени иамл у јсон, или, ако ваше компоненте не садрже никакве променљиве, онда се могу описати у облику обичног иамл-а.

При раду са јсоннет Топло препоручујем да инсталирате додатак за ваш уређивач

На пример, постоји додатак за вим вим-јсоннет, који укључује истицање синтаксе и аутоматски се извршава јсоннет фмт сваки пут када сачувате (захтева инсталиран јсоннет).

Све је спремно, сада можемо да почнемо да примењујемо:

Да видимо шта имамо, покренимо:

qbec show default

На излазу ћете видети приказане иамл манифесте који ће бити примењени на подразумевани кластер.

Одлично, сада примените:

qbec apply default

На излазу ћете увек видети шта ће бити урађено у вашем кластеру, кбец ће од вас тражити да се сложите са изменама тако што ћете укуцати y моћи ћете да потврдите своје намере.

Наша апликација је спремна и распоређена!

Ако унесете промене, увек можете да урадите:

qbec diff default

да видите како ће ове промене утицати на тренутну примену

Не заборавите да унесете наше промене:

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

5. Покушај Гитлаб-руннер-а са Кубернетес-екецутор-ом

До недавно сам користио само обичне гитлаб-руннер на унапред припремљеној машини (ЛКСЦ контејнер) са шкољком или доцкер-извршиоцем. У почетку смо имали неколико таквих тркача глобално дефинисаних у нашем гитлабу. Прикупили су доцкер слике за све пројекте.

Али, као што је пракса показала, ова опција није најидеалнија, како у погледу практичности, тако иу погледу сигурности. Много је боље и идеолошки исправније имати одвојене тркаче распоређене за сваки пројекат, или чак за свако окружење.

На срећу, то уопште није проблем, јер ћемо сада распоредити гитлаб-руннер директно као део нашег пројекта у Кубернетесу.

Гитлаб обезбеђује готов дијаграм управљања за примену гитлаб-руннер-а у Кубернетес. Дакле, све што треба да урадите је да сазнате регистрациони токен за наш пројекат у Подешавања -> ЦИ / ЦД -> Руннерс и пренесите га на кормило:

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

Где је:

• https://gitlab.com — адреса вашег Гитлаб сервера.
• ига8и-јдЦусВДн_т4Вкц — регистрациони токен за ваш пројекат.
• рбац.цреате=труе — пружа тркачу неопходну количину привилегија да би могао да креира подове за обављање наших задатака користећи кубернетес-екецутор.

Ако је све урађено како треба, требало би да видите регистрованог тркача у одељку Руннерс, у подешавањима вашег пројекта.

Снимак екрана додатог тркача

Да ли је то тако једноставно? - да, тако је једноставно! Нема више проблема са ручном регистрацијом тркача, од сада ће се тркачи аутоматски креирати и уништавати.

6. Поставите Хелм карте са КБЕЦ-ом

Пошто смо одлучили да размотримо гитлаб-руннер део нашег пројекта, време је да га опишемо у нашем Гит репозиторијуму.

Могли бисмо га описати као засебну компоненту , али у будућности планирамо да применимо различите копије врло често, за разлику од гитлаб-руннер, који ће бити распоређен само једном по Кубернетес кластеру. Дакле, хајде да иницијализујемо засебну апликацију за то:

cd deploy
qbec init gitlab-runner
cd gitlab-runner

Овог пута нећемо ручно описивати Кубернетес ентитете, већ ћемо узети готов Хелм графикон. Једна од предности кбец-а је могућност приказивања Хелмових графикона директно из Гит спремишта.

Хајде да га повежемо помоћу гит подмодула:

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

Сада именик вендор/гитлаб-руннер Имамо спремиште са графиконом за гитлаб-руннер.

На сличан начин можете повезати друга спремишта, на пример, цело спремиште са званичним графиконима https://github.com/helm/charts

Хајде да опишемо компоненту компоненте/гитлаб-руннер.јсоннет:

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

Први аргумент за екпандХелмТемплате онда пролазимо пут до графикона парамс.валуес, које узимамо из параметара окружења, затим долази објекат са

• намеТемплате — наслов издања
• простор имена — именски простор пребачен на кормило
• Овај фајл — обавезни параметар који прослеђује путању до тренутне датотеке
• вербосе - показује команду шаблон за кормило са свим аргументима приликом приказивања графикона

Сада хајде да опишемо параметре за нашу компоненту у окружења/басе.либсоннет:

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

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

Обратите внимание руннерРегистратионТокен узимамо из спољне датотеке сецретс/басе.либсоннет, хајде да га креирамо:

{
  runnerRegistrationToken: 'yga8y-jdCusVDn_t4Wxc',
}

Хајде да проверимо да ли све ради:

qbec show default

ако је све у реду, онда можемо да обришемо наше претходно распоређено издање преко Хелм-а:

helm uninstall gitlab-runner

и примените га на исти начин, али кроз кбец:

qbec apply default

7. Увод у гит-црипт

Гит-црипт је алатка која вам омогућава да поставите транспарентно шифровање за ваше спремиште.

У овом тренутку, наша структура директоријума за гитлаб-руннер изгледа овако:

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

Али чување тајни у Гиту није безбедно, зар не? Зато их морамо исправно шифровати.

Обично, зарад једне варијабле, ово нема увек смисла. Можете пренети тајне на кбец и кроз променљиве окружења вашег ЦИ система.
Али вреди напоменути да постоје и сложенији пројекти који могу садржати много више тајни; њихово преношење кроз варијабле окружења биће изузетно тешко.

Штавише, у овом случају не бих могао да вам кажем о тако дивном алату као гит-црипт.

гит-црипт Погодан је и по томе што вам омогућава да сачувате читаву историју тајни, као и да упоређујете, спајате и решавате конфликте на исти начин као што смо навикли да радимо у случају Гита.

Прва ствар након инсталације гит-црипт морамо да генеришемо кључеве за наше спремиште:

git crypt init

Ако имате ПГП кључ, можете одмах да се додате као сарадника за овај пројекат:

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

На овај начин увек можете дешифровати ово спремиште користећи свој приватни кључ.

Ако немате ПГП кључ и не очекујете га, онда можете ићи другим путем и извести кључ пројекта:

git crypt export-key /path/to/keyfile

Дакле, свако ко има извоз кеифиле моћи ће да дешифрује ваше спремиште.

Време је да поставимо нашу прву тајну.
Да вас подсетим да смо још увек у именику деплои/гитлаб-руннер/, где имамо именик тајне/, хајде да шифрујемо све датотеке у њему, за ово ћемо креирати датотеку тајне/.гитаттрибути са следећим садржајем:

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

Као што се види из садржаја, сви фајлови су маскирани * ће се возити гит-црипт, осим за већину .гитаттрибутес

Ово можемо проверити покретањем:

git crypt status -e

Излаз ће бити листа свих датотека у спремишту за које је омогућено шифровање

То је све, сада можемо безбедно да извршимо наше промене:

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

Да бисте блокирали спремиште, само покрените:

git crypt lock

и одмах ће се сви шифровани фајлови претворити у нешто бинарно, биће немогуће прочитати их.
Да дешифрујете спремиште, покрените:

git crypt unlock

8. Направите слику кутије са алаткама

Слика кутије са алаткама је слика са свим алатима које ћемо користити за имплементацију нашег пројекта. Гитлаб руннер ће га користити за обављање типичних задатака постављања.

Овде је све једноставно, хајде да направимо нову доцкерфилес/тоолбок/Доцкерфиле са следећим садржајем:

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

Као што видите, на овој слици инсталирамо све услужне програме које смо користили за постављање наше апликације. Не треба нам овде осим ако кубецтл, али можда бисте желели да се поиграте са њим током фазе подешавања цевовода.

Такође, да бисмо могли да комуницирамо са Кубернетес-ом и да се применимо на њега, морамо да конфигуришемо улогу за подове које генерише гитлаб-руннер.

Да бисмо то урадили, идемо у директоријум са гитлаб-руннер-ом:

cd deploy/gitlab-runner

и додајте нову компоненту компоненте/рбац.јсоннет:

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

Такође ћемо описати нове параметре у окружења/басе.либсоннет, који сада изгледа овако:

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

Обратите внимание $.цомпонентс.рбац.наме се односи на име за компоненту рбац

Хајде да проверимо шта се променило:

qbec diff default

и примените наше промене на Кубернетес:

qbec apply default

Такође, не заборавите да унесете наше промене у гит:

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. Наш први цевовод и склапање слика по ознакама

У основи пројекта који ћемо креирати .гитлаб-ци.имл са следећим садржајем:

.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

Имајте на уму да користимо ГИТ_СУБМОДУЛЕ_СТРАТЕГИ: нормално за оне послове где треба експлицитно да иницијализујете подмодуле пре извршења.

Не заборавите да унесете наше промене:

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

Мислим да ово можемо са сигурношћу назвати верзијом вКСНУМКС и додајте ознаку:

git tag v0.0.1

Додаћемо ознаке кад год треба да објавимо нову верзију. Ознаке у Доцкер сликама ће бити везане за Гит ознаке. Сваки притисак са новом ознаком ће иницијализовати изградњу слика са овом ознаком.

Вилл екецуте гит пусх --тагс, и погледајмо наш први цевовод:

Снимак екрана првог цевовода

Вреди скренути вашу пажњу на чињеницу да је монтажа помоћу ознака погодна за прављење доцкер слика, али није погодна за примену апликације у Кубернетес. Пошто се нове ознаке могу доделити старим урезивању, у овом случају, иницијализација цевовода за њих ће довести до примене старе верзије.

Да би се решио овај проблем, обично је прављење доцкер слика везано за ознаке, а постављање апликације на грану мајстор, у којој су верзије прикупљених слика чврсто кодиране. Ово је место где можете да покренете враћање једноставним враћањем мајстор-гранци.

10. Аутоматизација распоређивања

Да би Гитлаб-руннер дешифровао наше тајне, мораћемо да извеземо кључ спремишта и додамо га у наше ЦИ променљиве окружења:

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

Добијени ред ћемо сачувати у Гитлабу; да бисмо то урадили, идемо на подешавања нашег пројекта:
Подешавања -> ЦИ / ЦД -> Променљиве

И хајде да направимо нову променљиву:

тип
Кључ
вредност
заштићен
маскиран
Обим

File
GITCRYPT_KEY
<your string>
true (током обуке можете false)
true
All environments

Снимак екрана додате променљиве

Сада да ажурирамо наше .гитлаб-ци.имл додајући томе:

.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

Овде смо омогућили неколико нових опција за кбец:

• --роот соме/апп — омогућава вам да одредите именик одређене апликације
• --форце:к8с-цонтект __инцлустер__ - ово је магична варијабла која каже да ће се имплементација догодити у истом кластеру у којем је покренут гтилаб-руннер. Ово је неопходно јер ће у супротном кбец покушати да пронађе одговарајући Кубернетес сервер у вашем кубецонфигу
• --чекати — присиљава кбец да сачека док ресурси које креира не пређу у стање Реади и тек онда изађе са успешним излазним кодом.
• -да - једноставно онемогућава интерактивну шкољку Да ли сте сигурни? када је распоређен.

Не заборавите да унесете наше промене:

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

И после гит пусх видећемо како су наше апликације распоређене:

Снимак екрана другог цевовода

11. Артефакти и монтажа приликом гурања до мастера

Обично су горе описани кораци довољни за прављење и испоруку скоро сваке микроуслуге, али не желимо да додамо ознаку сваки пут када треба да ажурирамо веб локацију. Због тога ћемо узети динамичнији пут и подесити примену сажетка у главној грани.

Идеја је једноставна: сада слика нашег биће поново изграђен сваки пут када уђете мајстор, а затим се аутоматски примени у Кубернетес.

Хајде да ажурирамо ова два посла у нашем .гитлаб-ци.имл:

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"

Имајте на уму да смо додали нит мајстор к рефс за послове буилд_вебсите и сада користимо $ЦИ_ЦОММИТ_РЕФ_НАМЕ уместо $ЦИ_ЦОММИТ_ТАГ, односно одвезани смо од тагова у Гиту и сада ћемо гурнути слику са именом гране урезивања која је иницијализовала цевовод. Вреди напоменути да ће ово функционисати и са ознакама, што ће нам омогућити да сачувамо снимке сајта са одређеном верзијом у доцкер-регистру.

Када назив доцкер ознаке за нову верзију сајта може да буде непромењен, и даље морамо да опишемо промене у Кубернетес-у, иначе једноставно неће поново поставити апликацију са нове слике, јер неће приметити никакве промене у манифест распоређивања.

Опција —вм:ект-стр дигест=”$ДИГЕСТ” за кбец - омогућава вам да проследите спољну променљиву у јсоннет. Желимо да се поново распореди у кластер са сваким издањем наше апликације. Више не можемо да користимо назив ознаке, који сада може да буде непроменљив, пошто морамо да будемо везани за одређену верзију слике и да покренемо примену када се промени.

Овде ће нам помоћи Каникова способност да сачува сажету слику у датотеку (опција --дигест-филе)
Затим ћемо пренети ову датотеку и прочитати је у тренутку постављања.

Хајде да ажурирамо параметре за наше деплои/вебсите/енвиронментс/басе.либсоннет који ће сада изгледати овако:

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

Урађено, сада укључите све обавезе мајстор иницијализује изградњу доцкер слике за , а затим га примените у Кубернетес.

Не заборавите да унесете наше промене:

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

Проверићемо касније гит пусх требало би да видимо нешто овако:

Снимак екрана цевовода за мастер

У принципу, не морамо да поново распоређујемо гитлаб-руннер са сваким притиском, осим ако се, наравно, ништа није променило у његовој конфигурацији, хајде да то поправимо у .гитлаб-ци.имл:

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/**/*

промене ће вам омогућити да пратите промене у деплои/гитлаб-руннер/ и покренуће наш посао само ако их има

Не заборавите да унесете наше промене:

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

гит пусх, тако је боље:

Снимак екрана ажурираног цевовода

12. Динамичка окружења

Време је да диверзификујемо наш цевовод динамичким окружењима.

Прво, хајде да ажурирамо посао буилд_вебсите у нашем .гитлаб-ци.имл, уклањајући блок са њега само, што ће приморати Гитлаб да га покрене на било ком урезивању на било коју грану:

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/

Затим ажурирајте посао деплои_вебсите, додајте блок тамо околина:

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_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

Они ће бити покренути након притиска на било коју грану осим мастер и примениће верзију сајта за преглед.

Видимо нову опцију за кбец: --апп-таг — омогућава вам да означите примењене верзије апликације и радите само у оквиру ове ознаке; када креирате и уништавате ресурсе у Кубернетесу, кбец ће радити само са њима.
На овај начин не можемо креирати посебно окружење за сваку рецензију, већ једноставно поново користити исто.

Овде такође користимо кбец применити преглед, уместо кбец применити подразумевано - ово је управо тренутак када ћемо покушати да опишемо разлике за наша окружења (преглед и подразумевано):

Додајмо преглед окружење у деплои/вебсите/кбец.иамл

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

Онда ћемо то прогласити у деплои/вебсите/парамс.либсоннет:

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

И запишите прилагођене параметре за то деплои/вебсите/енвиронментс/ревиев.либсоннет:

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

Хајде да погледамо и посао изблиза стоп_ревиев, покренуће се када се грана обрише и тако да гитлаб не покуша да одјави да се користи ГИТ_СТРАТЕГИ: нема, касније ћемо клонирати мајстор-гранати и брисати преглед преко њега.
Мало је збуњујуће, али још нисам нашао лепши начин.
Алтернативна опција би била да се свака рецензија распореди у именски простор хотела, који се увек може у потпуности срушити.

Не заборавите да унесете наше промене:

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

гит пусх, гит цхецкоут -б тест, гит пусх тест порекла, проверавати:

Снимак екрана креираних окружења у Гитлабу

Све ради? - одлично, избришите нашу тест грану: гит цхецкоут мастер, гит пусх оригин :тест, проверавамо да ли су послови брисања окружења радили без грешака.

Овде бих одмах желео да разјасним да сваки програмер у пројекту може да креира гране, он такође може да се мења .гитлаб-ци.имл фајл и приступне тајне променљиве.
Због тога се снажно препоручује да се њихова употреба дозволи само за заштићене гране, на пример у мајстор, или креирајте посебан скуп варијабли за свако окружење.

13. Прегледајте апликације

Прегледајте апликације Ово је ГитЛаб функција која вам омогућава да додате дугме за сваку датотеку у спремишту да бисте је брзо прегледали у примењеном окружењу.

Да би се ова дугмад појавила, потребно је да креирате датотеку .гитлаб/роуте-мап.имл и описати све трансформације путање у њему; у нашем случају то ће бити врло једноставно:

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

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

Не заборавите да унесете наше промене:

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

гит пусх, и проверите:

Снимак екрана дугмета Прегледајте апликацију

Посао је готов!

Извори пројекта:

• на Гитлабу: https://gitlab.com/kvaps/docs.example.org
• на ГитХуб-у: https://github.com/kvaps/docs.example.org

Хвала вам на пажњи, надам се да вам се допало

Извор: ввв.хабр.цом