Здравейте! Напоследък бяха пуснати много страхотни инструменти за автоматизация както за изграждане на Docker изображения, така и за внедряване в Kubernetes. В тази връзка реших да си поиграя с Gitlab, как да проуча възможностите му и, разбира се, да настроя тръбопровод.

Този сайт е вдъхновен от kubernetes.io, който се генерира от изходни кодове автоматично и за всяка изпратена заявка за изтегляне, роботът автоматично генерира предварителна версия на сайта с вашите промени и предоставя връзка за преглед.

Опитах се да създам подобен процес от нулата, но изцяло изграден върху Gitlab CI и безплатни инструменти, които използвах за внедряване на приложения в Kubernetes. Днес най-накрая ще ви разкажа повече за тях.

Статията ще обхване инструменти като:
Уго, qbec, канико, git-крипта и GitLab CI със създаването на динамична среда.

Съдържание

1. Запознаване с Хюго
2. Подготовка на Docker файла
3. Запознаване с kaniko
4. Въведение в qbec
5. Опитвам Gitlab-runner с Kubernetes-executor
6. Разположете диаграми на Helm с qbec
7. Въведение в git-crypt
8. Създайте изображение на кутия с инструменти
9. Първият ни конвейер и сглобяване на изображения по тагове
10. Внедряване на автоматизация
11. Артефакти и сглобяване при натискане за мастериране
12. Динамични среди
13. Преглед на приложенията

1. Запознаване с Хюго

Като пример за нашия проект ще се опитаме да създадем сайт за публикуване на документация, изграден върху Hugo. Hugo е генератор на статично съдържание.

За тези, които не са запознати със статичните генератори, ще ви разкажа малко повече за тях. За разлика от обикновените двигатели на сайтове с база данни и някакъв вид php, които при поискване от потребителя генерират страници в движение, статичните генератори са подредени малко по-различно. Те ви позволяват да вземете изходния код, обикновено набор от файлове в маркиране на Markdown и шаблони за теми, след което да ги компилирате в напълно завършен сайт.

Тоест на изхода ще получите структура на директория и набор от генерирани html файлове, които можете просто да качите на всеки евтин хостинг и да получите работещ сайт.

Можете да инсталирате Hugo локално и да го изпробвате:

Инициализиране на новия сайт:

hugo new site docs.example.org

И в същото време git хранилището:

cd docs.example.org
git init

Засега нашият сайт е чист и за да се появи нещо на него, първо трябва да свържем тема, темата е просто набор от шаблони и зададени правила, по които се генерира нашият сайт.

Като тема ще използваме Уча, който според мен е най-подходящ за сайт с документация.

Бих искал да обърна специално внимание на факта, че не е необходимо да запазваме файловете на темата в хранилището на нашия проект, вместо това можем просто да го свържем с git подмодул:

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

По този начин само файлове, пряко свързани с нашия проект, ще бъдат в нашето хранилище, а свързаната тема ще остане като връзка към конкретно хранилище и ангажимент в него, тоест винаги може да бъде изтеглен от оригиналния източник и да не се страхува на несъвместими промени.

Да оправим конфигурацията config.toml:

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

Вече на този етап можете да стартирате:

hugo server

И то на адреса http://localhost:1313/ проверете новосъздадения ни сайт, всички направени промени в директорията автоматично актуализират отворената страница в браузъра, много удобно!

Нека се опитаме да създадем заглавна страница в съдържание/_index.md:

# My docs site

## Welcome to the docs!

You will be very smart :-)

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

За да генерирате сайт, просто стартирайте:

hugo

Съдържание на директория обществена / и ще бъде вашият сайт.
Да, между другото, нека веднага да го включим .gitignore:

echo /public > .gitignore

Не забравяйте да извършите нашите промени:

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

2. Подготовка на Docker файла

Време е да дефинираме структурата на нашето хранилище. Обикновено използвам нещо като:

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

• dockerfiles/ - съдържат директории с Dockerfiles и всичко необходимо за изграждане на нашите докер изображения.
• разполагам/ - съдържа директории за внедряване на нашите приложения в Kubernetes

По този начин ние ще създадем нашия първи Dockerfile по пътя dockerfiles/уебсайт/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" ]

Както можете да видите, Dockerfile съдържа два ОТ, тази възможност се нарича многоетапно изграждане и ви позволява да изключите всичко ненужно от окончателното изображение на докер.
Така крайното изображение ще съдържа само darkhttpd (лек HTTP сървър) и обществена / - съдържанието на нашия статично генериран сайт.

Не забравяйте да извършите нашите промени:

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

3. Запознаване с kaniko

Като създател на докер изображения, реших да използвам канико, тъй като не изисква докер демон, за да работи, а самото сглобяване може да се извърши на всяка машина и да съхранява кеша директно в системния регистър, като по този начин се отървава от необходимостта да има пълноценно постоянно хранилище.

За да създадете изображението, просто стартирайте контейнера с kaniko изпълнител и прехвърлете текущия контекст на компилация към него, можете да го направите локално, чрез докер:

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

където registry.gitlab.com/kvaps/docs.example.org/website - името на вашия докер образ, след компилирането ще се стартира автоматично в докер регистъра.

Параметър --кеш ви позволява да кеширате слоеве в регистъра на докерите, за дадения пример те ще бъдат съхранени в registry.gitlab.com/kvaps/docs.example.org/website/cache, но можете да посочите друг път с параметъра --cache-repo.

Екранна снимка на докер регистър

4. Въведение в qbec

Qbec е инструмент за внедряване, който ви позволява декларативно да опишете манифестите на вашето приложение и да ги внедрите в Kubernetes. Използването на Jsonnet като основен синтаксис прави много лесно описанието на разликите за множество среди и също така почти напълно елиминира повторението на кода.

Това може да е особено вярно в случаите, когато трябва да внедрите приложение в няколко клъстера с различни параметри и искате да ги опишете декларативно в Git.

Qbec също ви позволява да изобразявате диаграми на Helm, като им предавате необходимите параметри и след това работите с тях по същия начин като обикновените манифести, включително възможността да прилагате различни мутации към тях, а това от своя страна елиминира необходимостта от използване на ChartMuseum. Тоест можете да съхранявате и изобразявате диаграми директно от git, където им е мястото.

Както казах преди, ще съхраняваме всички внедрявания в директорията разполагам/:

mkdir deploy
cd deploy

Нека инициализираме нашето първо приложение:

qbec init website
cd website

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

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

вижте файла qbec.yaml:

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

Тук се интересуваме преди всичко от спец.среди, qbec вече е създал средата по подразбиране за нас и е взел адреса на сървъра и пространството от имена от текущата ни kubeconfig.
Сега при внедряването на подразбиране среда, qbec винаги ще се разгръща само в посочения клъстер на Kubernetes и в посоченото пространство от имена, т.е. вече не трябва да превключвате между контексти и пространства от имена, за да разгърнете.
Ако е необходимо, винаги можете да актуализирате настройките в този файл.

Всички ваши среди са описани в qbec.yaml, и във файла params.libsonnet, което казва откъде трябва да вземете параметрите за тях.

След това виждаме две директории:

• компоненти / - всички манифести за нашето приложение ще се съхраняват тук, те могат да бъдат описани както в jsonnet, така и в обикновени yaml файлове
• среди/ - тук ще опишем всички променливи (параметри) за нашите среди.

По подразбиране имаме два файла:

• среди/base.libsonnet - ще съдържа общи параметри за всички среди
• среди/default.libsonnet - съдържа параметри, предефинирани за средата подразбиране

нека отворим среди/base.libsonnet и добавете параметри за нашия първи компонент там:

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

Нека създадем и нашия първи компонент компоненти/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,
                },
              },
            ],
          },
        },
      ],
    },
  },
]

В този файл ние описахме три Kubernetes обекта наведнъж, това са: внедряване, обслужване и Влизане. При желание бихме могли да ги разместим в различни компоненти, но на този етап един ни е достатъчен.

синтаксис jsonnet много подобен на обикновения json, по принцип обикновеният json вече е валиден jsonnet, така че в началото може да ви е по-лесно да използвате онлайн услуги като yaml2json за да конвертирате обичайния си yaml в json, или ако вашите компоненти не съдържат никакви променливи, тогава те могат да бъдат описани под формата на обикновен yaml.

При работа с jsonnet Горещо ви съветвам да инсталирате плъгин за вашия редактор

Например, има плъгин за vim vim-jsonnet, който включва осветяването на синтаксиса и се изпълнява автоматично jsonnet fmt при всяко запазване (изисква инсталиране на jsonnet).

Всичко е готово, сега можем да започнем внедряването:

За да видим какво имаме, нека стартираме:

qbec show default

На изхода ще видите изобразените манифести на yaml, които ще бъдат приложени към клъстера по подразбиране.

Страхотно, сега приложете:

qbec apply default

На изхода винаги ще виждате какво ще бъде направено във вашия клъстер, qbec ще ви помоли да приемете промените, като напишете y можете да потвърдите намеренията си.

Готово сега, нашето приложение е внедрено!

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

qbec diff default

за да видите как тези промени ще се отразят на текущото внедряване

Не забравяйте да извършите нашите промени:

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

5. Опитайте Gitlab-runner с Kubernetes-executor

До скоро използвах само обикновени gitlab-бегач на предварително подготвена машина (LXC контейнер) с shell- или docker-executor. Първоначално имахме няколко от тези бегачи, дефинирани глобално в нашата gitlab. Те създадоха докер изображения за всички проекти.

Но както показа практиката, тази опция не е най-идеалната, както от гледна точка на практичност, така и от гледна точка на сигурност. Много по-добре и идеологически правилно е да имате отделни бегачи, разположени за всеки проект и дори за всяка среда.

За щастие това изобщо не е проблем, тъй като сега ще се разположим gitlab-бегач директно като част от нашия проект точно в Kubernetes.

Gitlab предоставя готова хелм диаграма за внедряване на gitlab-runner в Kubernetes. Така че всичко, което трябва да знаете е регистрационен токен за нашия проект в Настройки -> CI / CD -> Runners и го предайте на кормилото:

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 е адресът на вашия Gitlab сървър.
• yga8y-jdCusVDn_t4Wxc - регистрационен токен за вашия проект.
• rbac.create=вярно - дава на бегача необходимия брой привилегии, за да може да създава подове за изпълнение на нашите задачи с помощта на kubernetes-executor.

Ако всичко е направено правилно, трябва да видите регистрирания бегач в секцията Runners, в настройките на вашия проект.

Екранна снимка на добавения бегач

Толкова ли е просто? - да, толкова е просто! Няма повече караница с ръчно регистриране на бегачи, отсега нататък бегачите ще се създават и унищожават автоматично.

6. Разположете диаграми на Helm с QBEC

Тъй като решихме да разгледаме gitlab-бегач част от нашия проект, време е да го опишем в нашето Git хранилище.

Можем да го опишем като отделен компонент уебсайт, но в бъдеще планираме да внедрим различни копия уебсайт много често, за разлика от gitlab-бегач, който ще бъде внедрен само веднъж на клъстер на Kubernetes. Така че нека инициализираме отделно приложение за него:

cd deploy
qbec init gitlab-runner
cd gitlab-runner

Този път няма да описваме Kubernetes обекти ръчно, а ще вземем готова Helm диаграма. Едно от предимствата на qbec е възможността да изобразявате Helm диаграми директно от Git хранилище.

Нека го активираме с помощта на git submodule:

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

Сега директорията доставчик/gitlab-runner съдържа нашето хранилище с диаграма за gitlab-runner.

Други хранилища могат да бъдат свързани по подобен начин, например цялото хранилище с официални диаграми https://github.com/helm/charts

Нека опишем компонента компоненти/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,
  }
)

Първият аргумент за expandHelmTemplate след това предаваме пътя към диаграмата params.values, които вземаме от параметрите на средата, след което идва обектът с

• nameTemplate - име на изданието
• пространство от имена - пространство от имена, предадено на helm
• този файл - задължителен параметър, който предава пътя към текущия файл
• многословен - показва команда шаблон за кормило с всички аргументи при рендиране на диаграма

Сега нека опишем параметрите за нашия компонент в среди/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 извличаме от външен файл secrets/base.libsonnet, нека го създадем:

{
  runnerRegistrationToken: 'yga8y-jdCusVDn_t4Wxc',
}

Нека проверим дали всичко работи:

qbec show default

ако всичко е наред, тогава можем да премахнем нашата по-рано внедрена чрез Helm версия:

helm uninstall gitlab-runner

и го внедрите, но чрез qbec:

qbec apply default

7. Въведение в git-crypt

git-crypt е инструмент, който ви позволява да настроите прозрачно криптиране за вашето хранилище.

В момента структурата на нашата директория за gitlab-runner изглежда така:

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

Но съхраняването на тайни в Git не е безопасно, нали? Така че трябва да ги шифроваме правилно.

Обикновено в името на една променлива не винаги има смисъл. Можете да прехвърляте тайни на qbec и чрез променливите на средата на вашата CI система.
Но си струва да се отбележи, че има и по-сложни проекти, които могат да съдържат много повече тайни, ще бъде изключително трудно да ги прехвърлите през променливите на средата.

Освен това в този случай не бих могъл да ви разкажа за такъв прекрасен инструмент като git-крипта.

git-крипта Също така е удобно с това, че ви позволява да запазвате цялата история на тайните, както и да сравнявате, обединявате и разрешавате конфликти по същия начин, както го правехме в случая с Git.

Първото нещо след инсталацията git-крипта трябва да генерираме ключове за нашето хранилище:

git crypt init

Ако имате PGP ключ, можете веднага да се добавите като сътрудник за този проект:

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

По този начин винаги можете да декриптирате това хранилище, като използвате личния си ключ.

Ако нямате PGP ключ и не се очаква, тогава можете да отидете по друг начин и да експортирате ключа на проекта:

git crypt export-key /path/to/keyfile

Така всеки, който притежава изнесен ключов файл ще може да дешифрира вашето хранилище.

Време е да създадем нашата първа тайна.
Нека ви напомня, че все още сме в указателя внедряване/gitlab-runner/където имаме директория тайни/, нека шифроваме всички файлове в него, за това ще създадем файл тайни/.gitattributes със съдържание като това:

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

Както се вижда от съдържанието, всички файлове по маска * ще премине през git-крипта, с изключение на .gitattributes

Можем да проверим това, като изпълним:

git crypt status -e

На изхода получаваме списък с всички файлове в хранилището, за които е активирано криптиране

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

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

За да блокирате хранилището, е достатъчно да изпълните:

git crypt lock

и незабавно всички криптирани файлове ще се превърнат в нещо двоично, ще бъде невъзможно да се прочетат.
За да декриптирате хранилището, изпълнете:

git crypt unlock

8. Създайте изображение на кутия с инструменти

Изображение на кутия с инструменти е изображение с всички инструменти, които ще използваме за внедряване на нашия проект. Той ще се използва от gitlab runner за изпълнение на типични задачи за внедряване.

Тук всичко е просто, създаваме ново dockerfiles/кутия с инструменти/Dockerfile със съдържание като това:

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

Както можете да видите, в това изображение инсталираме всички помощни програми, които използвахме за внедряване на нашето приложение. Нямаме нужда тук, освен ако kubectl, но може да искате да си поиграете с него, когато настройвате тръбопровода.

Също така, за да можем да комуникираме с Kubernetes и да го разположим, трябва да настроим роля за подовете, генерирани от gitlab-runner.

За да направите това, отидете в директорията с gitlab-runner'om:

cd deploy/gitlab-runner

и добавете нов компонент компоненти/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,
      },
    ],
  },
]

Също така описваме новите параметри в среди/base.libsonnet, което сега изглежда така:

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 отнася се до име за компонент rbac

Нека проверим какво се е променило:

qbec diff default

и прилагаме нашите промени към Kubernetes:

qbec apply default

Също така, не забравяйте да ангажирате нашите промени в 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. Първият ни конвейер и асемблиране на изображения по тагове

В основата на проекта, който ще създадем .gitlab-ci.yml със съдържание като това:

.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_SUBMODULE_STRATEGY: нормално за тези задачи, при които трябва изрично да инициализирате подмодули преди изпълнение.

Не забравяйте да извършите нашите промени:

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

Мисля, че можете спокойно да го наречете версия v0.0.1 и добавете етикет:

git tag v0.0.1

Ще окачваме етикети винаги, когато трябва да пуснем нова версия. Етикети в Docker изображения ще бъдат съпоставени с Git тагове. Всяко натискане с нов таг ще инициализира изграждане на изображение с този таг.

Ще се изпълни git push --tagsи вижте нашия първи тръбопровод:

Екранна снимка на първия конвейер

Струва си да се отбележи, че компилациите, базирани на етикети, са добри за изграждане на докер изображения, но не и за внедряване на приложение в Kubernetes. Тъй като новите тагове могат да бъдат присвоени и на стари ангажименти, в този случай инициализирането на конвейера за тях ще доведе до внедряването на старата версия.

За да се реши този проблем, изграждането на докер изображения обикновено е свързано с тагове и внедряването на приложението в клона майстор, в който версиите на събраните изображения са твърдо кодирани. В този случай можете да инициализирате връщане назад с просто връщане майстор- клонове.

10. Внедрете автоматизация

За да може Gitlab-runner да дешифрира нашите тайни, трябва да експортираме ключа на хранилището и да го добавим към нашите променливи на CI среда:

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

ще запазим получения низ в Gitlab, за това ще отидем в настройките на нашия проект:
Настройки —> CI / CD —> Променливи

И създайте нова променлива:

Тип
ключ
Стойност
Защитена
маскиран
Обхват

File
GITCRYPT_KEY
<your string>
true (по време на обучение можете false)
true
All environments

Екранна снимка на добавената променлива

Сега нека актуализираме нашия .gitlab-ci.yml добавяйки към него:

.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

Тук сме активирали някои нови опции за qbec:

• --root някои/приложение - позволява ви да определите директорията на конкретно приложение
• --force:k8s-контекст __incluster__ - това е магическа променлива, която казва, че внедряването ще се извърши в същия клъстер, в който работи gtilab-runner. Това е необходимо, в противен случай qbec ще се опита да намери подходящ Kubernetes сървър във вашия kubeconfig
• -изчакайте - принуждава qbec да изчака, докато ресурсите, които създава, преминат в състояние на готовност и едва тогава да завърши с успешен изходен код.
• -да - просто деактивира интерактивната обвивка Сигурен ли си? по време на разгръщането.

Не забравяйте да извършите нашите промени:

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

И след git push ще видим как са внедрени нашите приложения:

Екранна снимка на втория конвейер

11. Артефакти и сглобяване при натискане за мастериране

Обикновено горните стъпки са достатъчни за изграждане и доставяне на почти всяка микроуслуга, но не искаме да добавяме етикет всеки път, когато трябва да актуализираме сайта. Следователно, ние ще отидем по по-динамичен начин и ще настроим разгръщане на дайджест в главния клон.

Идеята е проста: сега образът на нашия уебсайт ще се възстановява всеки път, когато натиснете майстор, и след това автоматично внедряване в Kubernetes.

Нека актуализираме тези две работни места в нашия .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"

Моля, обърнете внимание, че добавихме клон майстор к литератури за работни места build_website и сега използваме $CI_COMMIT_REF_NAME вместо $CI_COMMIT_TAG, което означава, че се отърваваме от таговете в Git и сега ще избутаме изображението с името на комит клона, който инициализира вашия конвейер. Заслужава да се отбележи, че това ще работи и с тагове, което ще ни позволи да запазим моментни снимки на сайта с конкретна версия в докерския регистър.

Когато името на докер маркера за новата версия на сайта може да бъде непроменено, все още трябва да опишем промените за Kubernetes, в противен случай просто няма да преразпредели приложението от новото изображение, тъй като няма да забележи никакви промени в манифест за внедряване.

Вариант --vm:ext-str digest="$DIGEST" за qbec - позволява ви да подадете външна променлива към jsonnet. Искаме нашето приложение да бъде преразпределено в клъстера с всяко издание. Вече не можем да използваме името на маркера, което вече може да бъде непроменено, тъй като трябва да се свържем с конкретна версия на изображението и да задействаме внедряването, когато се промени.

Тук способността на Kaniko да запази дайджеста на изображението във файл ще ни помогне (опция --digest-файл)
След това ще прехвърлим този файл и ще го прочетем по време на внедряването.

Нека актуализираме параметрите за нашия разгръщане/website/environments/base.libsonnet който сега ще изглежда така:

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

Готово, сега всяко ангажиране майстор инициализира изграждането на докер изображение за уебсайти след това го разположете в Kubernetes.

Не забравяйте да извършите нашите промени:

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

Проверете го след това git push трябва да видим нещо подобно:

Екранна снимка на Pipeline за master

По принцип не е необходимо да преразпределяме gitlab-runner с всяко натискане, освен ако, разбира се, нищо не се е променило в неговата конфигурация, нека поправим това в .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/**/*

промени ще следи промените в внедряване/gitlab-runner/ и ще задейства работата ни само ако има такива

Не забравяйте да извършите нашите промени:

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

git push, това е по-добре:

Екранна снимка на актуализирания конвейер

12. Динамични среди

Време е да разнообразим нашата линия с динамични среди.

Първо, нека актуализираме работата build_website в нашата .gitlab-ci.yml, премахвайки блока от него само за лична употреба, което ще принуди Gitlab да го задейства при всяко ангажиране към всеки клон:

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, добавете блок там заобикаляща среда:

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"

Това ще позволи на Gitlab да свърже работата с ръгане среда и покажете правилната връзка към нея.

Сега нека добавим още две работни места:

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

Те ще бъдат задействани чрез натискане към всички клонове с изключение на главния и ще разположат предварителна версия на сайта.

Виждаме нова опция за qbec: --app-tag - позволява ви да маркирате внедрени версии на приложението и да работите само в рамките на този етикет; когато създавате и унищожавате ресурси в Kubernetes, qbec ще работи само върху тях.
По този начин не можем да създадем отделна среда за всеки преглед, а просто да използваме отново същата.

Тук също използваме qbec прилага прегледвместо qbec приложи по подразбиране - точно това е моментът, в който ще се опитаме да опишем разликите за нашите среди (преглед и подразбиране):

Добави Рецензия среда в разгръщане/website/qbec.yaml

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

След това го декларираме в разгръщане/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

И запишете персонализирани параметри за него разгръщане/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',
    },
  },
}

Нека разгледаме по-отблизо и работата стоп_ревю, той ще бъде задействан, когато клонът бъде премахнат и така че gitlab да не се опитва да го провери, се използва GIT_STRATEGY: няма, по-късно клонираме майстор-разклоняване и изтриване на преглед през него.
Малко объркващо, но все още не съм намерил по-красив начин.
Алтернативен вариант би бил разгръщането на всяка рецензия в пространство от имена на хотел, което винаги може да бъде унищожено изцяло.

Не забравяйте да извършите нашите промени:

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

git push, git checkout -b тест, git push източник тест, проверете:

Екранна снимка на създадени среди в Gitlab

Всичко работи ли? - страхотно, изтрийте нашия тестов клон: начало на поръчката, git push origin :test, проверяваме дали заданията за изтриване на средата са работили без грешки.

Тук веднага искам да поясня, че всеки разработчик в проекта може да създава клонове, той също може да променя .gitlab-ci.yml файл и секретни променливи за достъп.
Ето защо е силно препоръчително да се разреши използването им само за защитени клонове, например в майсторили създайте отделен набор от променливи за всяка среда.

13 Преглед на приложения

Преглед на приложенията това е функция на gitlab, която ви позволява да добавите бутон за всеки файл в хранилището, за да го видите бързо в разгърнатата среда.

За да се появят тези бутони, трябва да създадете файл .gitlab/route-map.yml и опишете в него всички трансформации на пътеките, в нашия случай ще бъде много просто:

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

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

Не забравяйте да извършите нашите промени:

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

git pushи проверете:

Екранна снимка на бутона за преглед на приложението

Работата е свършена!

Източници на проекта:

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

Благодаря ви за вниманието, надявам се да ви е харесало

Източник: www.habr.com