Сәлеметсіз бе! Жақында 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. Гюгомен танысу

Біздің жобаның мысалы ретінде біз 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/ біздің жаңадан құрылған веб-сайтты тексеріңіз, каталогта жасалған барлық өзгерістер браузердегі ашық бетті автоматты түрде жаңартады, өте ыңғайлы!

Мұқаба бетін жасауға тырысайық content/_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

• докер файлдары/ — Docker файлдары бар каталогтарды және біздің Docker кескіндерін құруға қажеттінің барлығын қамтиды.
• орналастыру/ — біздің қолданбаларымызды Kubernetes-ке орналастыруға арналған каталогтарды қамтиды

Осылайша, біз жол бойымен бірінші Docker-файлымызды жасаймыз 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, бұл мүмкіндік деп аталады көп сатылы құрылыс және соңғы докер кескінінен қажет емес нәрселерді алып тастауға мүмкіндік береді.
Осылайша, соңғы кескінде тек болады darkhttpd (жеңіл 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, бірақ параметрді пайдаланып басқа жолды көрсетуге болады --кэш-репо.

Docker-registry скриншоты

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

Сонымен қатар бірінші құрамдасымызды жасайық komponents/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-орындаушымен сынап көру

Соңғы уақытқа дейін мен әдеттегідей ғана қолдандым gitlab жүгірушісі қабықпен немесе докер-орындаушымен алдын ала дайындалған машинада (LXC контейнері). Бастапқыда біздің gitlab жүйесінде жаһандық деңгейде анықталған бірнеше жүгірушілер болды. Олар барлық жобалар үшін докер кескіндерін жинады.

Бірақ тәжірибе көрсеткендей, бұл опция практикалық және қауіпсіздік тұрғысынан ең идеалды емес. Әрбір жоба үшін, тіпті әрбір орта үшін бөлек жүгірушілер орналастырылған әлдеқайда жақсы және идеологиялық тұрғыдан дұрысырақ.

Бақытымызға орай, бұл мүлдем проблема емес, өйткені біз енді орналастырамыз gitlab жүгірушісі тікелей Кубернетестегі жобамыздың бөлігі ретінде.

Gitlab gitlab-жүгіргішін Kubernetes жүйесіне орналастыру үшін дайын руль диаграммасын ұсынады. Сондықтан сізге бар болғаны білу керек тіркеу белгісі біздің жобамыз үшін Параметрлер -> CI / CD -> Жүгірушілер және оны рульге беріңіз:

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 — жүгірушіге kubernetes-executor көмегімен тапсырмаларды орындау үшін подкаст жасай алу үшін қажетті артықшылықтар көлемін береді.

Егер бәрі дұрыс орындалса, бөлімде тіркелген жүгірушіні көру керек Жүгірушілер, жоба параметрлерінде.

Қосылған жүгіргінің скриншоты

Бұл қарапайым ма? - иә, өте қарапайым! Жүгірушілерді қолмен тіркеу қиын болмайды, енді жүгірушілер автоматты түрде құрылады және жойылады.

6. QBEC көмегімен Helm диаграммаларын орналастырыңыз

Біз қарастыруды шешкендіктен gitlab жүгірушісі жобамыздың бір бөлігі, оны Git репозиторийінде сипаттайтын кез келді.

Біз оны жеке құрамдас ретінде сипаттай аламыз сайтқа, бірақ болашақта біз әртүрлі көшірмелерді орналастыруды жоспарлап отырмыз сайтқа айырмашылығы өте жиі gitlab жүгірушісі, ол әр 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-қондырғышы Бізде gitlab-runner үшін диаграммасы бар репозиторий бар.

Сол сияқты, сіз басқа репозиторийлерді, мысалы, бүкіл репозиторийді ресми диаграммалармен байланыстыра аласыз. https://github.com/helm/charts

Компонентті сипаттайық components/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/құралдар жинағы/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

және жаңа компонент қосыңыз komponents/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 -> Айнымалылар

Жаңа айнымалыны жасайық:

түрі
кілт
құн
Қорғалған
киген
Қолдану аясы

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"

Кейін ит итеріңіз қолданбаларымыз қалай орналастырылғанын көреміз:

Екінші құбырдың скриншоты

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-тегі тегтерден босатылдық, енді біз құбырды инициализациялаған міндеттеме тармағының атымен суретті итереміз. Айта кету керек, бұл тегтермен де жұмыс істейді, бұл бізге белгілі бір нұсқасы бар сайттың суреттерін докер-тізілімде сақтауға мүмкіндік береді.

Сайттың жаңа нұсқасы үшін докерлік тегтің атауын өзгертуге болатын кезде, біз әлі де Kubernetes-ке өзгерістерді сипаттауымыз керек, әйтпесе ол жай ғана жаңа кескіннен қолданбаны қайта орналастыра алмайды, өйткені ол файлда ешқандай өзгерістерді байқамайды. орналастыру манифесті.

Опция —vm:ext-str дайджест=”$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. Динамикалық орталар

Құбырымызды динамикалық орталармен әртараптандырудың уақыты келді.

Алдымен жұмысты жаңартайық құрастыру_веб-сайты Біздің .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-teg — ол қолданбаның орналастырылған нұсқаларын белгілеуге және тек осы тегте жұмыс істеуге мүмкіндік береді; 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 checkout -b сынағы, git push бастау сынағы, тексеріңіз:

Gitlab жүйесінде жасалған орталардың скриншоты

Барлығы жұмыс істейді? - тамаша, біздің сынақ бөлімшесін жойыңыз: git checkout master, git push бастау: сынақ, біз ортаны жою жұмыстары қатесіз жұмыс істегенін тексереміз.

Мұнда жобадағы кез келген әзірлеуші ​​филиалдар жасай алатынын бірден түсіндіргім келеді, ол да өзгерте алады .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