Сайн уу? Саяхан Docker-ийн зургийг бүтээх, Kubernetes-д байршуулах зорилгоор олон гайхалтай автоматжуулалтын хэрэгслүүд гарсан. Үүнтэй холбогдуулан би GitLab-тай тоглож, түүний чадавхийг сайтар судалж, мэдээжийн хэрэг дамжуулах хоолойг тохируулахаар шийдсэн.

Энэ ажлыг вэб сайтаас санаа авсан kubernetes.io-аас үүссэн эх кодууд автоматаар, илгээсэн сан хүсэлт бүрийн хувьд робот автоматаар таны өөрчлөлтийн хамт сайтын урьдчилан харах хувилбарыг үүсгэж, үзэх холбоосыг өгдөг.

Би үүнтэй төстэй үйл явцыг эхнээс нь бүтээхийг оролдсон боловч Gitlab CI болон Kubernetes-д аппликешн байршуулахад ашигладаг үнэгүй хэрэгслүүд дээр бүрэн суурилагдсан. Өнөөдөр би эцэст нь тэдний талаар илүү ихийг хэлэх болно.

Нийтлэлд дараахь хэрэгслүүдийг авч үзэх болно.
Хюго, qbec, Канико, git-crypt и GitLab CI динамик орчныг бий болгосноор.

Агуулга

1. Хюготой танилц
2. Докер файлыг бэлтгэж байна
3. Каникотой танилцаж байна
4. Qbec-тэй танилцаж байна
5. Gitlab-гүйгчийг Kubernetes-гүйцэтгэгчтэй туршиж байна
6. Helm диаграмыг qbec-ээр байрлуулж байна
7. Git-crypt програмыг танилцуулж байна
8. Хэрэгслийн хайрцагны дүрс үүсгэх
9. Бидний анхны шугам хоолой, шошгон дээрх зургуудыг угсрах
10. Байршуулах автоматжуулалт
11. Мастер руу түлхэх үед олдвор, угсралт
12. Динамик орчин
13. Аппликешнүүдийг шалгах

1. Хюготой танилцах

Төслийн жишээ болгон бид Хюго дээр баригдсан баримт бичгийг нийтлэх сайтыг бий болгохыг хичээх болно. Хюго бол статик контент үүсгэгч юм.

Статик генераторын талаар сайн мэдэхгүй хүмүүст би тэдний талаар бага зэрэг ярих болно. Хэрэглэгчийн хүсэлтээр шууд хуудас үүсгэдэг мэдээллийн сан, зарим 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. Докер файлыг бэлтгэх

Манай репозиторын бүтцийг тодорхойлох цаг болжээ. Би ихэвчлэн иймэрхүү зүйлийг ашигладаг:

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

• докер файлууд/ — Dockerfiles бүхий сангууд болон манай Docker зургуудыг бүтээхэд шаардлагатай бүх зүйлийг агуулсан.
• байрлуулах/ — манай программуудыг Kubernetes-д байршуулах лавлахуудыг агуулсан

Тиймээс бид зам дагуу анхны Dockerfile-ээ үүсгэх болно dockerfiles/website/Dockerfile

FROM alpine:3.11 as builder
ARG HUGO_VERSION=0.62.0
RUN wget -O- https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_${HUGO_VERSION}_linux-64bit.tar.gz | tar -xz -C /usr/local/bin
ADD . /src
RUN hugo -s /src

FROM alpine:3.11
RUN apk add --no-cache darkhttpd
COPY --from=builder /src/public /var/www
ENTRYPOINT [ "/usr/bin/darkhttpd" ]
CMD [ "/var/www" ]

Таны харж байгаагаар Dockerfile нь хоёрыг агуулна FROM, энэ боломжийг гэж нэрлэдэг олон үе шаттай барилга ба эцсийн докерын дүрсээс шаардлагагүй бүх зүйлийг хасах боломжийг танд олгоно.
Тиймээс эцсийн зураг нь зөвхөн агуулагдах болно харанхуйhttpd (хөнгөн HTTP сервер) болон үзэгчид/ — манай статикаар үүсгэгдсэн вэбсайтын агуулга.

Бидний өөрчлөлтийг хийхээ бүү мартаарай:

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

Хаана 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 байгууллагыг нэг дор дүрсэлсэн бөгөөд эдгээр нь: байрлуулалт, үйлчилгээ и Ingress. Хэрэв бид хүсвэл тэдгээрийг өөр өөр бүрэлдэхүүн хэсгүүдэд оруулж болох боловч энэ үе шатанд нэг нь бидэнд хангалттай байх болно.

синтакс jsonnet Энэ нь ердийн json-той маш төстэй, зарчмын хувьд ердийн json нь аль хэдийн хүчинтэй jsonnet тул та эхлээд онлайн үйлчилгээг ашиглахад хялбар байх болно. yaml2json ердийн yaml-ээ json болгон хөрвүүлэх, эсвэл хэрэв таны бүрэлдэхүүн хэсгүүдэд хувьсагч байхгүй бол тэдгээрийг ердийн ямл хэлбэрээр дүрсэлж болно.

Хамт ажиллаж байхдаа jsonnet Би засварлагчдаа залгаас суулгахыг зөвлөж байна

Жишээлбэл, vim-д зориулсан залгаас байдаг vim-jsonnet, энэ нь синтакс тодруулахыг идэвхжүүлж, автоматаар гүйцэтгэнэ jsonnet fmt хадгалах бүртээ (jsonnet суулгасан байх шаардлагатай).

Бүх зүйл бэлэн боллоо, одоо бид суулгаж эхэлж болно:

Бидэнд юу байгааг харахын тулд гүйцгээе:

qbec show default

Гаралт дээр та анхдагч кластерт хэрэглэгдэх ямл манифестуудыг харах болно.

Гайхалтай, одоо өргөдөл гарга:

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 контейнер) дээр. Эхэндээ бид gitlab дээр дэлхий даяар тодорхойлогдсон ийм төрлийн хэд хэдэн гүйгчтэй байсан. Тэд бүх төслүүдэд зориулж докерын зургийг цуглуулсан.

Гэхдээ практикээс харахад энэ сонголт нь практик, аюулгүй байдлын хувьд хамгийн тохиромжтой биш юм. Төсөл бүр, бүр орчин бүрд тус тусад нь гүйгчдийг байрлуулах нь илүү сайн бөгөөд үзэл суртлын хувьд илүү зөв юм.

Аз болоход, энэ нь огт асуудал биш, учир нь бид одоо байрлуулах болно gitlab-гүйгч шууд Кубернетес дэх манай төслийн нэг хэсэг.

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 ашиглан даалгавраа биелүүлэхийн тулд pods үүсгэх боломжтой шаардлагатай хэмжээний давуу эрхээр хангадаг.

Хэрэв бүх зүйл зөв хийгдсэн бол та хэсэгт бүртгэгдсэн гүйгчийг харах ёстой Онгоцнууд, таны төслийн тохиргоонд.

Нэмэгдсэн гүйгчийн дэлгэцийн агшин

Ийм энгийн гэж үү? - Тийм ээ, энэ маш энгийн! Гүйгчдийг гараар бүртгэхэд бэрхшээл гарахгүй, одооноос эхлэн гүйгчдийг автоматаар үүсгэж устгана.

6. QBEC-тэй Helm диаграммуудыг байрлуул

Бид авч үзэхээр шийдсэн тул gitlab-гүйгч Манай төслийн нэг хэсэг бол үүнийг Git репозитор дээр тайлбарлах цаг болжээ.

Бид үүнийг тусдаа бүрэлдэхүүн хэсэг гэж тодорхойлж болно вэб сайт, гэхдээ ирээдүйд бид өөр өөр хуулбаруудыг байрлуулахаар төлөвлөж байна вэб сайт маш олон удаа, ялгаатай gitlab-гүйгч, үүнийг Кубернетес кластер бүрт нэг л удаа байршуулах болно. Тиймээс тусдаа програмыг эхлүүлье:

cd deploy
qbec init gitlab-runner
cd gitlab-runner

Энэ удаад бид Kubernetes аж ахуйн нэгжүүдийг гараар дүрслэхгүй, харин бэлэн Helm диаграмыг авах болно. Qbec-ийн нэг давуу тал бол Git репозитороос Helm диаграммуудыг шууд гаргах чадвар юм.

Үүнийг git дэд модулийг ашиглан холбож үзье:

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

Эхний аргумент HelmTemplate-г өргөтгөх дараа нь бид диаграмын замыг дамжуулна параметр.утгууд, бид орчны параметрүүдээс авдаг бөгөөд дараа нь объект ирдэг

• нэр Загвар - хувилбарын нэр
• нэрийн орон зай - нэрийн орон зайг жолоодлого руу шилжүүлсэн
• энэ Файл - одоогийн файл руу орох замыг дамжуулдаг шаардлагатай параметр
• дэлгэрэнгүй - командыг харуулна жолооны загвар диаграмыг үзүүлэх үед бүх аргументуудтай

Одоо бүрэлдэхүүн хэсгийнхээ параметрүүдийг тайлбарлая орчин/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-crypt.

git-crypt Энэ нь нууцын түүхийг бүхэлд нь хадгалах, мөн Git-ийн хувьд бидний ашигладаг шиг зөрчилдөөнийг харьцуулах, нэгтгэх, шийдвэрлэх боломжийг олгодог тул тохиромжтой.

Суулгасны дараа хийх хамгийн эхний зүйл git-crypt Бид репозиторынхоо түлхүүрүүдийг үүсгэх хэрэгтэй:

git crypt init

Хэрэв танд PGP түлхүүр байгаа бол та өөрийгөө энэ төслийн хамтрагчаар нэн даруй нэмж болно:

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

Ингэснээр та хувийн түлхүүрээ ашиглан энэ агуулахын шифрийг тайлах боломжтой.

Хэрэв танд PGP түлхүүр байхгүй бөгөөд үүнийг хүлээхгүй байгаа бол та өөр замаар явж, төслийн түлхүүрийг экспортлох боломжтой.

git crypt export-key /path/to/keyfile

Тиймээс хэн ч экспортолсон түлхүүр файл таны агуулахын шифрийг тайлах боломжтой болно.

Бидний анхны нууцыг тогтоох цаг болжээ.
Бид лавлахад хэвээр байгааг сануулъя deploy/gitlab-runner/, бидэнд лавлах байдаг нууц/, доторх бүх файлыг шифрлэцгээе, үүний тулд бид файл үүсгэх болно нууцууд/.gitattributes дараах агуулгатай:

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

Контентоос харахад бүх файлууд далдлагдсан байна * дамжуулан жолоодох болно git-crypt, ихэнхийг эс тооцвол .gitattributes

Бид үүнийг ажиллуулснаар шалгаж болно:

git crypt status -e

Гаралт нь шифрлэлтийг идэвхжүүлсэн репозиторын бүх файлуудын жагсаалт байх болно

Ингээд л бид өөрчлөлтөө аюулгүй хийж болно:

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

Хадгалах газрыг хаахын тулд:

git crypt lock

нэн даруй бүх шифрлэгдсэн файлууд хоёртын файл болж хувирах тул тэдгээрийг унших боломжгүй болно.
Хадгалах сангийн шифрийг тайлахын тулд:

git crypt unlock

8. Хэрэгслийн хайрцагны дүрсийг үүсгэ

Хэрэгслийн хайрцагны дүрс нь бидний төслийг хэрэгжүүлэхэд ашиглах бүх хэрэгслийг агуулсан зураг юм. Үүнийг Gitlab гүйгч ердийн байршуулах ажлыг гүйцэтгэхэд ашиглах болно.

Энд бүх зүйл энгийн, шинээр бий болгоё dockerfiles/toolbox/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

Таны харж байгаагаар энэ зураг дээр бид програмаа байрлуулахад ашигладаг бүх хэрэгслийг суулгаж байна. Эндээс өөр зүйл бидэнд хэрэггүй кубектл, гэхдээ та дамжуулах хоолойг тохируулах үе шатанд үүнтэй тоглохыг хүсч магадгүй юм.

Түүнчлэн, Kubernetes-тэй холбогдож, түүнийг ашиглахын тулд бид gitlab-runner-ийн үүсгэсэн pod-д зориулсан үүргийг тохируулах хэрэгтэй.

Үүнийг хийхийн тулд gitlab-runner-тай лавлах руу орцгооё:

cd deploy/gitlab-runner

болон шинэ бүрэлдэхүүн хэсэг нэмнэ components/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 some/app — тодорхой програмын лавлахыг тодорхойлох боломжийг танд олгоно
• --force:k8s-контекст __incluster__ - энэ нь gtilab-runner ажиллаж байгаа кластерт байршуулалт хийгдэнэ гэсэн шидэт хувьсагч юм. Үгүй бол qbec таны kubeconfig дотроос тохирох Kubernetes сервер олохыг оролдох тул энэ нь зайлшгүй шаардлагатай.
• --хүлээгээрэй — qbec-ийг үүсгэсэн нөөцүүд нь Бэлэн төлөвт шилжих хүртэл хүлээх хэрэгтэй бөгөөд дараа нь амжилттай гарах кодоор гарна.
• -тийм ээ - зүгээр л интерактив бүрхүүлийг идэвхгүй болгодог Чи итгэлтэй байна уу? байрлуулсан үед.

Бидний өөрчлөлтийг хийхээ бүү мартаарай:

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

Тэгээд дараа нь git түлхэх Манай програмууд хэрхэн тавигдсаныг бид харах болно:

Хоёр дахь дамжуулах хоолойн дэлгэцийн агшин

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"

Бид хэлхээ нэмсэнийг анхаарна уу мастер к refs ажлын хувьд вэбсайт бүтээх мөн бид одоо ашиглаж байна $CI_COMMIT_REF_NAME оронд нь $CI_COMMIT_TAG, өөрөөр хэлбэл, бид Git дэх хаягуудаас салсан бөгөөд одоо дамжуулах хоолойг эхлүүлсэн commit салбарын нэр бүхий зургийг түлхэх болно. Энэ нь шошготой ажиллах бөгөөд энэ нь бидэнд тодорхой хувилбар бүхий сайтын агшин агшинг докер-регистрт хадгалах боломжийг олгоно гэдгийг тэмдэглэх нь зүйтэй.

Сайтын шинэ хувилбарын докерын шошгоны нэрийг өөрчлөх боломжгүй үед бид Kubernetes-д хийсэн өөрчлөлтийг тайлбарлах шаардлагатай хэвээр байх болно, эс тэгвээс энэ нь програмыг шинэ зургаас дахин байршуулахгүй, учир нь энэ нь ямар ч өөрчлөлтийг анзаарахгүй байх болно. байршуулалтын манифест.

Сонголт —vm:ext-str digest=”$DIGEST” for qbec - jsonnet-д гадаад хувьсагчийг дамжуулах боломжийг танд олгоно. Бид үүнийг програмынхаа хувилбар бүрээр кластерт дахин байршуулахыг хүсч байна. Бид зургийн тодорхой хувилбартай холбогдож, өөрчлөгдөх үед байршуулалтыг эхлүүлэх шаардлагатай тул одоо өөрчлөх боломжгүй шошгын нэрийг ашиглах боломжгүй болсон.

Энд бидэнд Каникогийн дүрсийг файлд хадгалах чадвар туслах болно (сонголт --digest-файл)
Дараа нь бид энэ файлыг шилжүүлж, байршуулах үед унших болно.

Бидэнд зориулсан параметрүүдийг шинэчилье deploy/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 түлхэх Бид иймэрхүү зүйлийг харах ёстой:

Мастерт зориулсан дамжуулах хоолойн дэлгэцийн агшин

Зарчмын хувьд бид 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/**/*

өөрчлөлтүүд өөрчлөлтийг хянах боломжийг танд олгоно deploy/gitlab-runner/ байгаа тохиолдолд л бидний ажлыг эхлүүлэх болно

Бидний өөрчлөлтийг хийхээ бүү мартаарай:

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

git түлхэх, ингэх нь дээр:

Шинэчлэгдсэн дамжуулах хоолойн дэлгэцийн агшин

12. Динамик орчин

Дамжуулах хоолойгоо динамик орчинд төрөлжүүлэх цаг болжээ.

Эхлээд ажлаа шинэчилье вэбсайт бүтээх д манай .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:
  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 өгөгдмөл тохируулна - яг энэ мөчид бид хүрээлэн буй орчны ялгааг тайлбарлахыг хичээх болно (хяналт ба анхдагч):

Нэмье тойм дахь орчин deploy/website/qbec.yaml

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

Дараа нь бид үүнийг тунхаглах болно 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

Мөн түүнд зориулсан тусгай параметрүүдийг бичнэ үү 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',
    },
  },
}

Мөн jobu-г нарийвчлан авч үзье хянан_зогсоох, энэ нь салбарыг устгах үед идэвхжих бөгөөд gitlab үүнийг шалгахыг оролдохгүйн тулд үүнийг ашигладаг. GIT_STRATEGY: байхгүй, дараа нь бид клон хийдэг мастер-салбар болон түүгээр дамжуулан хянан устгах.
Энэ нь жаахан ойлгомжгүй байна, гэхдээ би илүү сайхан арга хараахан олоогүй байна.
Альтернатив сонголт бол тойм бүрийг бүхэлд нь нурааж болох зочид буудлын нэрийн орон зайд байрлуулах явдал юм.

Бидний өөрчлөлтийг хийхээ бүү мартаарай:

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

git түлхэх, git checkout -b тест, git түлхэх гарал үүслийн тест, шалгах:

Gitlab дээр үүсгэсэн орчны дэлгэцийн агшин

Бүх зүйл ажиллаж байна уу? - гайхалтай, манай туршилтын салбарыг устгана уу: git checkout мастер, git түлхэх эх сурвалж: тест, бид байгаль орчныг устгах ажил алдаагүй ажилласан эсэхийг шалгана.

Энд би төслийн аль ч хөгжүүлэгч салбар үүсгэж болно гэдгийг нэн даруй тодруулахыг хүсч байна, тэр бас өөрчлөгдөж болно .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 түлхэх, мөн шалгах:

Аппликешн шалгах товчны дэлгэцийн агшин

Ажил дууссан!

Төслийн эх сурвалжууд:

• Gitlab дээр: https://gitlab.com/kvaps/docs.example.org
• GitHub дээр: https://github.com/kvaps/docs.example.org

Анхаарал тавьсанд баярлалаа, таалагдсан гэж найдаж байна

Эх сурвалж: www.habr.com