გამარჯობა! ახლახან გამოვიდა მრავალი მაგარი ავტომატიზაციის ინსტრუმენტი, როგორც Docker-ის სურათების შესაქმნელად, ასევე Kubernetes-ში განლაგებისთვის. ამასთან დაკავშირებით, გადავწყვიტე GitLab-თან თამაში, მისი შესაძლებლობების საფუძვლიანად შესწავლა და, რა თქმა უნდა, მილსადენის დაყენება.

ეს ნამუშევარი შექმნილია ვებგვერდის მიერ kubernetes.io, რომელიც წარმოიქმნება წყარო კოდები ავტომატურად და თითოეული გაგზავნილი აუზის მოთხოვნისთვის, რობოტი ავტომატურად ქმნის საიტის გადახედვის ვერსიას თქვენი ცვლილებებით და უზრუნველყოფს ბმულს სანახავად.

მე ვცადე მსგავსი პროცესის შექმნა ნულიდან, მაგრამ მთლიანად აგებული Gitlab CI-ზე და უფასო ინსტრუმენტებზე, რომლებსაც მიჩვეული ვარ Kubernetes-ში აპლიკაციების განსათავსებლად. დღეს ბოლოს და ბოლოს გეტყვით მათ შესახებ.

სტატიაში განხილული იქნება ისეთი ინსტრუმენტები, როგორიცაა:
უგო, qbec, კანიკო, git-crypt и GitLab CI დინამიური გარემოს შექმნით.

შინაარსი

1. გაიცანით ჰიუგო
2. Dockerfile-ის მომზადება
3. კანიკოს გაცნობა
4. qbec-ის გაცნობა
5. Gitlab-Runner-ის მცდელობა Kubernetes-ის შემსრულებელთან ერთად
6. Helm ჩარტების დაყენება qbec-ით
7. წარმოგიდგენთ git-crypt
8. ხელსაწყოთა ყუთის სურათის შექმნა
9. ჩვენი პირველი მილსადენი და სურათების შეკრება ტეგების მიხედვით
10. განლაგების ავტომატიზაცია
11. არტეფაქტები და შეკრება ოსტატობისკენ სწრაფვისას
12. დინამიური გარემო
13. აპების მიმოხილვა

1. ჰიუგოს გაცნობა

როგორც ჩვენი პროექტის მაგალითი, შევეცდებით შევქმნათ ჰიუგოზე აგებული დოკუმენტაციის გამოქვეყნების საიტი. Hugo არის სტატიკური შინაარსის გენერატორი.

მათთვის, ვინც არ იცნობს სტატიკური გენერატორების, ცოტა მეტს გეტყვით მათ შესახებ. ჩვეულებრივი ვებსაიტების ძრავებისგან განსხვავებით, რომლებსაც აქვთ მონაცემთა ბაზა და ზოგიერთი PHP, რომელიც მომხმარებლის მოთხოვნის შემთხვევაში წარმოქმნის გვერდებს პირდაპირ ეთერში, სტატიკური გენერატორები შექმნილია ოდნავ განსხვავებულად. ისინი საშუალებას გაძლევთ აიღოთ წყაროები, როგორც წესი, ფაილების ნაკრები Markdown მარკირებისა და თემების შაბლონებში, შემდეგ კი შეადგინოთ ისინი მთლიანად დასრულებულ ვებსაიტად.

ანუ, შედეგად, თქვენ მიიღებთ დირექტორია სტრუქტურას და გენერირებული HTML ფაილების კომპლექტს, რომელიც შეგიძლიათ უბრალოდ ატვირთოთ ნებისმიერ იაფ ჰოსტინგზე და მიიღოთ სამუშაო ვებსაიტი.

თქვენ შეგიძლიათ დააინსტალიროთ Hugo ადგილობრივად და სცადოთ:

ახალი საიტის ინიცირება:

hugo new site docs.example.org

და ამავე დროს git საცავი:

cd docs.example.org
git init

ჯერჯერობით, ჩვენი საიტი ხელუხლებელია და იმისთვის, რომ მასზე რაღაც გამოჩნდეს, ჯერ უნდა დავაკავშიროთ თემა; თემა არის მხოლოდ შაბლონებისა და წესების ნაკრები, რომლითაც იქმნება ჩვენი საიტი.

თემისთვის ჩვენ გამოვიყენებთ Learn, რომელიც, ჩემი აზრით, იდეალურად შეეფერება დოკუმენტაციის საიტს.

განსაკუთრებული ყურადღება მინდა გავამახვილო იმ ფაქტზე, რომ ჩვენ არ გვჭირდება თემის ფაილების შენახვა ჩვენი პროექტის საცავში; ამის ნაცვლად, ჩვენ შეგვიძლია უბრალოდ დავაკავშიროთ იგი გამოყენებით 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

დირექტორიაში შინაარსი აუდიტორია/ და იქნება თქვენი ვებგვერდი.
დიახ, სხვათა შორის, მაშინვე დავამატოთ .გიტინორე:

echo /public > .gitignore

არ დაგავიწყდეთ ჩვენი ცვლილებების შეტანა:

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

2. Dockerfile-ის მომზადება

დროა განვსაზღვროთ ჩვენი საცავის სტრუქტურა. მე ჩვეულებრივ ვიყენებ რაღაცას:

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

• dockerfiles/ - შეიცავდეს კატალოგებს Dockerfiles-ით და ყველაფერი რაც საჭიროა ჩვენი Docker სურათების შესაქმნელად.
• განლაგება/ — შეიცავს საქაღალდეებს ჩვენი აპლიკაციების 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 შეიცავს ორს FROM, ამ ფუნქციას ე.წ მრავალსაფეხურიანი მშენებლობა და საშუალებას გაძლევთ გამორიცხოთ ყველაფერი არასაჭირო საბოლოო დოკერის სურათიდან.
ამრიგად, საბოლოო სურათი მხოლოდ შეიცავს მუქიhttpd (მსუბუქი HTTP სერვერი) და აუდიტორია/ — ჩვენი სტატიკურად გენერირებული ვებსაიტის შინაარსი.

არ დაგავიწყდეთ ჩვენი ცვლილებების შეტანა:

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

3. კანიკოს გაცნობა

როგორც დოკერის გამოსახულების შემქმნელი, გადავწყვიტე გამოვიყენო კანიკო, ვინაიდან მისი ფუნქციონირება არ საჭიროებს დოკერ დემონს და თავად აწყობა შეიძლება განხორციელდეს ნებისმიერ მანქანაზე და ქეში შეინახოს პირდაპირ რეესტრში, რითაც აღმოფხვრის სრულფასოვანი მუდმივი შენახვის აუცილებლობას.

სურათის ასაგებად, უბრალოდ გაუშვით კონტეინერი კანიკოს შემსრულებელი და გადასცეთ მას მიმდინარე build კონტექსტში; ეს ასევე შეიძლება გაკეთდეს ადგილობრივად, დოკერის საშუალებით:

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, მაგრამ თქვენ შეგიძლიათ მიუთითოთ სხვა გზა პარამეტრის გამოყენებით --ქეში-რეპო.

დოკერ-რეგესტრის სკრინშოტი

4. 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 - ის შეიცავს საერთო პარამეტრებს ყველა გარემოსთვის
• გარემოს/ნაგულისხმევი.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',
    },
  },
}

მოდით ასევე შევქმნათ ჩვენი პირველი კომპონენტი კომპონენტები/ვებგვერდი.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,
                },
              },
            ],
          },
        },
      ],
    },
  },
]

ამ ფაილში ჩვენ აღვწერეთ კუბერნეტის სამი ერთეული ერთდროულად, ესენია: განლაგება, სამსახურის и Ingress. თუ გვინდოდა, შეგვეძლო სხვადასხვა კომპონენტებში ჩავდოთ, მაგრამ ამ ეტაპზე ერთი საკმარისი იქნება ჩვენთვის.

სინტაქსი 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-ის შემსრულებელთან ერთად

ბოლო დრომდე მხოლოდ ჩვეულებრივ ვიყენებდი გიტლაბ-მრბოლი წინასწარ მომზადებულ მანქანაზე (LXC კონტეინერი) ჭურვით ან დოკერ-შემსრულებლით. თავდაპირველად, რამდენიმე ასეთი მორბენალი გვყავდა გლობალურად განსაზღვრული ჩვენს gitlab-ში. მათ შეაგროვეს დოკერის სურათები ყველა პროექტისთვის.

მაგრამ როგორც პრაქტიკამ აჩვენა, ეს ვარიანტი არ არის ყველაზე იდეალური, როგორც პრაქტიკულობის, ასევე უსაფრთხოების თვალსაზრისით. ბევრად უკეთესი და იდეოლოგიურად უფრო სწორია თითოეული პროექტისთვის, ან თუნდაც თითოეული გარემოსთვის ცალკეული მორბენალი იყოს განლაგებული.

საბედნიეროდ, ეს საერთოდ არ არის პრობლემა, რადგან ახლა ჩვენ განვათავსებთ გიტლაბ-მრბოლი პირდაპირ, როგორც ჩვენი პროექტის ნაწილი, სწორედ Kubernetes-ში.

Gitlab გთავაზობთ მზა საჭის სქემას Kubernetes-ში gitlab-runner-ის განსათავსებლად. ასე რომ, ყველაფერი რაც თქვენ უნდა გააკეთოთ არის ამის გარკვევა რეგისტრაციის ნიშანი ჩვენი პროექტისთვის პარამეტრები -> 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=true — აძლევს მორბენალს საჭირო რაოდენობის პრივილეგიებით, რათა შეძლოს შექმნას pods ჩვენი ამოცანების შესასრულებლად kubernetes-executor-ის გამოყენებით.

თუ ყველაფერი სწორად გაკეთდა, განყოფილებაში უნდა ნახოთ რეგისტრირებული მორბენალი Runners, თქვენი პროექტის პარამეტრებში.

დამატებული მორბენის სკრინშოტი

ასე მარტივია? - დიახ, ეს ასე მარტივია! მორბენალთა ხელით რეგისტრაცია აღარ შეგაწუხებთ, ამიერიდან მორბენალი ავტომატურად შეიქმნება და განადგურდება.

6. განათავსეთ Helm სქემები QBEC-ით

მას შემდეგ, რაც გადავწყვიტეთ გავითვალისწინოთ გიტლაბ-მრბოლი ჩვენი პროექტის ნაწილია, დროა აღვწეროთ ის ჩვენს Git საცავში.

ჩვენ შეგვიძლია აღვწეროთ ის, როგორც ცალკეული კომპონენტი ნახვა, მაგრამ სამომავლოდ ვგეგმავთ სხვადასხვა ასლების განთავსებას ნახვა ძალიან ხშირად, განსხვავებით გიტლაბ-მრბოლი, რომელიც განლაგდება მხოლოდ ერთხელ Kubernetes კლასტერზე. მაშ ასე, მოდით შევქმნათ მისთვის ცალკე განაცხადი:

cd deploy
qbec init gitlab-runner
cd gitlab-runner

ამჯერად ჩვენ ხელით არ აღვწერთ Kubernetes-ის ერთეულებს, მაგრამ ავიღებთ მზა Helm სქემას. qbec-ის ერთ-ერთი უპირატესობა არის Helm სქემების გადაცემის შესაძლებლობა პირდაპირ Git საცავიდან.

მოდით დავაკავშიროთ იგი 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,
  }
)

პირველი არგუმენტი expandHelmTemplate ჩვენ გავდივართ გზას სქემისკენ, შემდეგ პარამები.ღირებულებები, რომელსაც ვიღებთ გარემოს პარამეტრებიდან, შემდეგ მოდის ობიექტი

• სახელის შაბლონი - გამოშვების სახელი
• სახელთა სივრცე - სახელთა სივრცე გადაეცა საჭეს
• ამ ფაილს — საჭირო პარამეტრი, რომელიც გადის მიმდინარე ფაილის გზას
• სიტყვიერი - აჩვენებს ბრძანებას საჭის შაბლონი ყველა არგუმენტით სქემის გადმოცემისას

ახლა მოდით აღვწეროთ ჩვენი კომპონენტის პარამეტრები გარემო/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 ვიღებთ გარე ფაილიდან საიდუმლოებები/ბაზა.libsonnet, მოდით შევქმნათ:

{
  runnerRegistrationToken: 'yga8y-jdCusVDn_t4Wxc',
}

მოდით შევამოწმოთ ყველაფერი მუშაობს თუ არა:

qbec show default

თუ ყველაფერი რიგზეა, მაშინ ჩვენ შეგვიძლია წავშალოთ ჩვენი ადრე განლაგებული გამოშვება Helm-ის მეშვეობით:

helm uninstall gitlab-runner

და განათავსეთ იგი იმავე გზით, მაგრამ qbec-ის მეშვეობით:

qbec apply default

7. შესავალი 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/, სადაც ჩვენ გვაქვს დირექტორია საიდუმლოებები/, მოდით დავშიფროთ მასში არსებული ყველა ფაილი, ამისთვის შევქმნით ფაილს საიდუმლოებები/.გიტატრიბუტები შემდეგი შინაარსით:

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

როგორც შინაარსიდან ჩანს, ყველა ფაილი ნიღბიანია * გაივლიან git-crypt, გარდა უმრავლესისა .გიტატრიტები

ამის შემოწმება შეგვიძლია გაშვებით:

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/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-ის მიერ გენერირებული პოდებისთვის.

ამისათვის გადავიდეთ დირექტორიაში gitlab-runner-ით:

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 -- ტეგებიდა მოდით გადავხედოთ ჩვენს პირველ მილსადენს:

პირველი მილსადენის ეკრანის სურათი

ღირს თქვენი ყურადღების მიქცევა იმ ფაქტზე, რომ ტეგებით შეკრება შესაფერისია დოკერის სურათების შესაქმნელად, მაგრამ არ არის შესაფერისი Kubernetes-ზე აპლიკაციის განსათავსებლად. იმის გამო, რომ ახალი ტეგები შეიძლება მიენიჭოს ძველ კომპონენტებს, ამ შემთხვევაში, მათთვის მილსადენის ინიციალიზაცია გამოიწვევს ძველი ვერსიის განთავსებას.

ამ პრობლემის გადასაჭრელად, როგორც წესი, დოკერის სურათების აგება უკავშირდება ტეგებს, ხოლო აპლიკაციის განლაგება ფილიალში. სამაგისტრო, რომელშიც შეგროვებული სურათების ვერსიები მყარი კოდირებულია. ეს არის სადაც შეგიძლიათ ინიციალიზაცია დაბრუნების მარტივი დაბრუნებით სამაგისტრო- ფილიალები.

10. განლაგების ავტომატიზაცია

იმისათვის, რომ Gitlab-runner-მა გააშიფროს ჩვენი საიდუმლოებები, ჩვენ დაგვჭირდება საცავის გასაღების ექსპორტი და მისი დამატება ჩვენს CI გარემოს ცვლადებში:

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

ჩვენ შევინახავთ მიღებულ ხაზს Gitlab-ში; ამისათვის გადავიდეთ ჩვენი პროექტის პარამეტრებზე:
პარამეტრები -> CI / CD -> ცვლადები

და მოდით შევქმნათ ახალი ცვლადი:

ტიპი
ძირითადი
ღირებულება
დაცულია
Masked
სფერო

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-context __incluster__ - ეს არის ჯადოსნური ცვლადი, რომელიც ამბობს, რომ განლაგება მოხდება იმავე კლასტერში, რომელშიც მუშაობს gtilab-runner. ეს აუცილებელია, რადგან წინააღმდეგ შემთხვევაში qbec შეეცდება იპოვოთ შესაფერისი Kubernetes სერვერი თქვენს kubeconfig-ში
• --მოიცადე — აიძულებს qbec-ს დაელოდოს, სანამ მის მიერ შექმნილი რესურსები გადავა Ready-ის მდგომარეობაში და მხოლოდ ამის შემდეგ გამოვიდეს წარმატებული გასასვლელი კოდით.
• -დიახ - უბრალოდ გამორთავს ინტერაქტიულ გარსს Დარწმუნებული ხარ? როდესაც განლაგებულია.

არ დაგავიწყდეთ ჩვენი ცვლილებების შეტანა:

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

Და შემდეგ გიტ ბიძგი ჩვენ ვნახავთ, როგორ განლაგდა ჩვენი აპლიკაციები:

მეორე მილსადენის ეკრანის სურათი

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-ში და ახლა ჩვენ გამოვაყენებთ სურათს იმ ფილიალის სახელწოდებით, რომელმაც მილსადენის ინიციალიზაცია მოახდინა. აღსანიშნავია, რომ ეს ასევე იმუშავებს ტეგებთან, რაც საშუალებას მოგვცემს შევინახოთ საიტის სნეპშოტები კონკრეტული ვერსიით დოკერ-რეგესტრში.

როდესაც საიტის ახალი ვერსიისთვის docker tag-ის სახელი შეიძლება უცვლელი იყოს, ჩვენ კვლავ უნდა აღვწეროთ ცვლილებები Kubernetes-ში, წინააღმდეგ შემთხვევაში ის უბრალოდ არ განათავსებს აპლიკაციას ახალი სურათიდან, რადგან ის ვერ შეამჩნევს რაიმე ცვლილებას განლაგების მანიფესტი.

ვარიანტი —vm:ext-str digest="$DIGEST" qbec-ისთვის - საშუალებას გაძლევთ გადასცეთ გარე ცვლადი jsonnet-ს. ჩვენ გვინდა, რომ ის ხელახლა განთავსდეს კლასტერში ჩვენი აპლიკაციის ყოველი გამოშვებით. ჩვენ აღარ შეგვიძლია გამოვიყენოთ ტეგის სახელი, რომელიც ახლა შეიძლება უცვლელი იყოს, რადგან ჩვენ უნდა ვიყოთ მიბმული სურათის კონკრეტულ ვერსიასთან და გამოვიყენოთ განლაგება, როდესაც ის იცვლება.

აქ ჩვენ დაგვეხმარება კანიკოს უნარი შეინახოს დაიჯესტის სურათი ფაილში (ვარიანტი -- დაიჯესტი-ფაილი)
შემდეგ ჩვენ გადავიტანთ ამ ფაილს და წავიკითხავთ მას განლაგების დროს.

მოდით განვაახლოთ ჩვენი პარამეტრები 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"

მოგვიანებით შევამოწმებთ გიტ ბიძგი ჩვენ უნდა ვნახოთ მსგავსი რამ:

მილსადენის ეკრანის სურათი მასტერისთვის

პრინციპში, ჩვენ არ გვჭირდება 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"

გიტ ბიძგიჯობია:

განახლებული მილსადენის ეკრანის სურათი

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 გამოიყენეთ ნაგულისხმევი - ეს არის ზუსტად ის მომენტი, როდესაც ჩვენ შევეცდებით აღვწეროთ განსხვავებები ჩვენი გარემოსთვის (მიმოხილვა და ნაგულისხმევი):

დავამატოთ განიხილავს გარემოში 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',
    },
  },
}

მოდით ასევე უფრო ახლოს მივხედოთ სამუშაოს გაჩერება_მიმოხილვა, ის გააქტიურდება, როდესაც ფილიალი წაიშლება და ისე, რომ gitlab არ შეეცადოს გადარიცხვა, ის გამოიყენება GIT_STRATEGY: არცერთი, მოგვიანებით ჩვენ კლონირებას ვახდენთ სამაგისტრო- ფილიალი და წაშალე მიმოხილვა მისი მეშვეობით.
ცოტა გაუგებარია, მაგრამ უფრო ლამაზი გზა ჯერ ვერ ვიპოვე.
ალტერნატიული ვარიანტი იქნება თითოეული მიმოხილვის განთავსება სასტუმროს სახელების სივრცეში, რომელიც ყოველთვის შეიძლება მთლიანად დაინგრა.

არ დაგავიწყდეთ ჩვენი ცვლილებების შეტანა:

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

გიტ ბიძგი, git checkout -b ტესტი, git push წარმოშობის ტესტი, ჩეკი:

Gitlab-ში შექმნილი გარემოს სკრინშოტი

ყველაფერი მუშაობს? - კარგი, წაშალეთ ჩვენი სატესტო ფილიალი: git გადახდის ოსტატი, git push origin :ტესტი, ჩვენ ვამოწმებთ, რომ გარემოს წაშლის სამუშაოები მუშაობდა შეცდომების გარეშე.

აქვე მინდა განვმარტო, რომ პროექტში ნებისმიერ დეველოპერს შეუძლია შექმნას ფილიალები, მას ასევე შეუძლია შეცვალოს .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"

გიტ ბიძგიდა შეამოწმეთ:

განხილვის აპლიკაციის ღილაკის ეკრანის სურათი

სამუშაო დასრულებულია!

პროექტის წყაროები:

• Gitlab-ზე: https://gitlab.com/kvaps/docs.example.org
• GitHub-ზე: https://github.com/kvaps/docs.example.org

გმადლობთ ყურადღებისთვის, იმედია მოგეწონათ

წყარო: www.habr.com