வணக்கம்! சமீபத்தில், பல கூல் ஆட்டோமேஷன் கருவிகள் டோக்கர் படங்களை உருவாக்குவதற்கும் குபெர்னெட்டஸுக்கு பயன்படுத்துவதற்கும் வெளியிடப்பட்டது. இது சம்பந்தமாக, நான் GitLab உடன் விளையாட முடிவு செய்தேன், அதன் திறன்களை முழுமையாக ஆய்வு செய்து, நிச்சயமாக, குழாய் அமைக்கவும்.

இந்த வேலை வலைத்தளத்தால் ஈர்க்கப்பட்டது kubernetes.io, இருந்து உருவாக்கப்படுகிறது மூல குறியீடுகள் தானாகவே, மற்றும் அனுப்பப்படும் ஒவ்வொரு பூல் கோரிக்கைக்கும், ரோபோ தானாகவே உங்கள் மாற்றங்களுடன் தளத்தின் முன்னோட்டப் பதிப்பை உருவாக்குகிறது மற்றும் பார்ப்பதற்கான இணைப்பை வழங்குகிறது.

நான் புதிதாக இதேபோன்ற செயல்முறையை உருவாக்க முயற்சித்தேன், ஆனால் முழுவதுமாக கிட்லாப் சிஐ மற்றும் குபெர்னெட்டஸுக்கு பயன்பாடுகளை வரிசைப்படுத்த நான் பயன்படுத்திய இலவச கருவிகளில் கட்டமைக்கப்பட்டேன். இன்று நான் இறுதியாக அவர்களைப் பற்றி மேலும் கூறுவேன்.

கட்டுரை இது போன்ற கருவிகளைப் பற்றி விவாதிக்கும்:
ஹ்யூகோ, qbec, கனிகோ, git-crypt и கிட்லாப் சி.ஐ. மாறும் சூழல்களின் உருவாக்கத்துடன்.

உள்ளடக்கம்

1. ஹ்யூகோவை சந்திக்கவும்
2. டோக்கர்ஃபைலைத் தயாரித்தல்
3. கனிகோவைப் பற்றி தெரிந்து கொள்வது
4. qbec பற்றி தெரிந்து கொள்வது
5. குபெர்னெட்ஸ்-எக்ஸிகியூட்டருடன் கிட்லாப்-ரன்னர் முயற்சி
6. qbec உடன் ஹெல்ம் விளக்கப்படங்களை வரிசைப்படுத்துகிறது
7. ஜிட்-கிரிப்டை அறிமுகப்படுத்துகிறோம்
8. ஒரு கருவிப்பெட்டி படத்தை உருவாக்குதல்
9. எங்கள் முதல் பைப்லைன் மற்றும் குறிச்சொற்கள் மூலம் படங்களின் அசெம்பிளி
10. வரிசைப்படுத்தல் ஆட்டோமேஷன்
11. மாஸ்டருக்குத் தள்ளும்போது கலைப்பொருட்கள் மற்றும் சட்டசபை
12. டைனமிக் சூழல்கள்
13. பயன்பாடுகளை மதிப்பாய்வு செய்யவும்

1. ஹ்யூகோவை அறிந்து கொள்வது

எங்கள் திட்டத்திற்கு உதாரணமாக, ஹ்யூகோவில் உருவாக்கப்பட்ட ஆவண வெளியீட்டு தளத்தை உருவாக்க முயற்சிப்போம். ஹ்யூகோ ஒரு நிலையான உள்ளடக்க ஜெனரேட்டர்.

நிலையான ஜெனரேட்டர்களைப் பற்றி அறிமுகமில்லாதவர்களுக்கு, அவற்றைப் பற்றி இன்னும் கொஞ்சம் கூறுவேன். ஒரு தரவுத்தளம் மற்றும் சில PHP கொண்ட வழக்கமான இணையதள இயந்திரங்களைப் போலல்லாமல், ஒரு பயனரால் கோரப்படும் போது, ​​பறக்கும்போது பக்கங்களை உருவாக்கும், நிலையான ஜெனரேட்டர்கள் சற்று வித்தியாசமாக வடிவமைக்கப்பட்டுள்ளன. மூலங்களை எடுக்க அவை உங்களை அனுமதிக்கின்றன, பொதுவாக மார்க் டவுன் மார்க்அப் மற்றும் தீம் டெம்ப்ளேட்களில் உள்ள கோப்புகளின் தொகுப்பு, பின்னர் அவற்றை முழுமையாக முடிக்கப்பட்ட இணையதளத்தில் தொகுக்கலாம்.

அதாவது, இதன் விளைவாக, நீங்கள் ஒரு அடைவு அமைப்பு மற்றும் உருவாக்கப்பட்ட HTML கோப்புகளின் தொகுப்பைப் பெறுவீர்கள், அதை நீங்கள் எந்த மலிவான ஹோஸ்டிங்கிலும் பதிவேற்றலாம் மற்றும் வேலை செய்யும் வலைத்தளத்தைப் பெறலாம்.

நீங்கள் ஹ்யூகோவை உள்நாட்டில் நிறுவி முயற்சி செய்யலாம்:

புதிய தளத்தைத் தொடங்குதல்:

hugo new site docs.example.org

அதே நேரத்தில் ஜிட் களஞ்சியம்:

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. Dockerfile தயார் செய்தல்

எங்கள் களஞ்சியத்தின் கட்டமைப்பை வரையறுக்க வேண்டிய நேரம் இது. நான் பொதுவாக இதுபோன்ற ஒன்றைப் பயன்படுத்துகிறேன்:

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

• டாக்கர் கோப்புகள்/ — Dockerfiles கொண்ட கோப்பகங்கள் மற்றும் எங்கள் Docker படங்களை உருவாக்க தேவையான அனைத்தையும் கொண்டுள்ளது.
• வரிசைப்படுத்த/ — எங்கள் பயன்பாடுகளை Kubernetes க்கு அனுப்புவதற்கான கோப்பகங்கள் உள்ளன

எனவே, பாதையில் எங்கள் முதல் டாக்கர்ஃபைலை உருவாக்குவோம் 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 இரண்டு கொண்டுள்ளது இருந்து, இந்த வாய்ப்பு அழைக்கப்படுகிறது பல கட்ட உருவாக்கம் மற்றும் இறுதி டோக்கர் படத்திலிருந்து தேவையற்ற அனைத்தையும் விலக்க அனுமதிக்கிறது.
எனவே, இறுதி படம் மட்டுமே கொண்டிருக்கும் இருண்ட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, ஆனால் நீங்கள் அளவுருவைப் பயன்படுத்தி மற்றொரு பாதையைக் குறிப்பிடலாம் --கேச்-ரெப்போ.

டாக்கர்-ரெஜிஸ்ட்ரியின் ஸ்கிரீன்ஷாட்

4. qbec பற்றி தெரிந்து கொள்வது

Qbec இது ஒரு வரிசைப்படுத்தல் கருவியாகும், இது உங்கள் விண்ணப்ப மேனிஃபெஸ்ட்ஸை விளக்கமாக விவரிக்கவும் அவற்றை குபெர்னெட்டஸில் பயன்படுத்தவும் அனுமதிக்கிறது. Jsonnet ஐ முக்கிய இலக்கணமாகப் பயன்படுத்துவது, பல சூழல்களில் உள்ள வேறுபாடுகளின் விளக்கத்தை பெரிதும் எளிமையாக்க உங்களை அனுமதிக்கிறது, மேலும் குறியீடு மீண்டும் மீண்டும் வருவதையும் முற்றிலும் நீக்குகிறது.

வெவ்வேறு அளவுருக்கள் கொண்ட பல க்ளஸ்டர்களுக்கு நீங்கள் ஒரு பயன்பாட்டைப் பயன்படுத்த வேண்டும் மற்றும் அவற்றை Git இல் விளக்கமாக விவரிக்க விரும்பும் சந்தர்ப்பங்களில் இது குறிப்பாக உண்மையாக இருக்கும்.

தேவையான அளவுருக்களை அனுப்புவதன் மூலம் ஹெல்ம் விளக்கப்படங்களை வழங்குவதற்கு Qbec உங்களை அனுமதிக்கிறது, மேலும் வழக்கமான வெளிப்பாடுகளைப் போலவே அவற்றை இயக்கவும், அவற்றில் பல்வேறு பிறழ்வுகளைப் பயன்படுத்தலாம், மேலும் இது தேவையிலிருந்து விடுபட உங்களை அனுமதிக்கிறது. 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: {}

இங்கே நாம் முதன்மையாக ஆர்வமாக உள்ளோம் spec.சூழல்கள், 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,
                },
              },
            ],
          },
        },
      ],
    },
  },
]

இந்தக் கோப்பில் ஒரே நேரத்தில் மூன்று குபெர்னெட்ஸ் நிறுவனங்களை விவரித்தோம், இவை: பயன்படுத்தல், சேவை и உட்செல்வதை. நாம் விரும்பினால், அவற்றை வெவ்வேறு கூறுகளாக வைக்கலாம், ஆனால் இந்த கட்டத்தில் ஒன்று நமக்கு போதுமானதாக இருக்கும்.

தொடரியல் 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. குபெர்னெட்ஸ்-எக்ஸிகியூட்டருடன் கிட்லாப்-ரன்னர் முயற்சி

சமீப காலம் வரை நான் வழக்கமாக மட்டுமே பயன்படுத்தினேன் கிட்லாப்-ரன்னர் ஷெல் அல்லது டோக்கர்-எக்ஸிகியூட்டர் கொண்ட முன் தயாரிக்கப்பட்ட இயந்திரத்தில் (LXC கொள்கலன்). ஆரம்பத்தில், இதுபோன்ற பல ஓட்டப்பந்தய வீரர்கள் எங்கள் கிட்லாப்பில் உலகளவில் வரையறுக்கப்பட்டிருந்தனர். அவர்கள் அனைத்து திட்டங்களுக்கும் டோக்கர் படங்களை சேகரித்தனர்.

ஆனால் நடைமுறையில் காட்டப்பட்டுள்ளபடி, இந்த விருப்பம் நடைமுறை மற்றும் பாதுகாப்பின் அடிப்படையில் மிகவும் சிறந்தது அல்ல. ஒவ்வொரு திட்டத்திற்கும் அல்லது ஒவ்வொரு சூழலுக்கும் தனித்தனி ஓட்டப்பந்தய வீரர்களை நியமிப்பது மிகவும் சிறந்தது மற்றும் கருத்தியல் ரீதியாக மிகவும் சரியானது.

அதிர்ஷ்டவசமாக, இது ஒரு பிரச்சனையல்ல, இப்போது நாங்கள் வரிசைப்படுத்துவோம் கிட்லாப்-ரன்னர் நேரடியாக 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 உடன் பயன்படுத்தவும்

நாங்கள் பரிசீலிக்க முடிவு செய்ததால் கிட்லாப்-ரன்னர் எங்கள் திட்டத்தின் ஒரு பகுதியாக, அதை எங்கள் Git களஞ்சியத்தில் விவரிக்க வேண்டிய நேரம் இது.

நாம் அதை ஒரு தனி அங்கமாக விவரிக்கலாம் வலைத்தளம், ஆனால் எதிர்காலத்தில் வெவ்வேறு பிரதிகளை வரிசைப்படுத்த திட்டமிட்டுள்ளோம் வலைத்தளம் மிகவும் அடிக்கடி, போலல்லாமல் கிட்லாப்-ரன்னர், இது ஒரு குபெர்னெட்ஸ் கிளஸ்டருக்கு ஒரு முறை மட்டுமே பயன்படுத்தப்படும். எனவே அதற்கு ஒரு தனி பயன்பாட்டை துவக்குவோம்:

cd deploy
qbec init gitlab-runner
cd gitlab-runner

இந்த முறை குபெர்னெட்டஸ் நிறுவனங்களை கைமுறையாக விவரிக்க மாட்டோம், ஆனால் ஆயத்த ஹெல்ம் விளக்கப்படத்தை எடுப்போம். qbec இன் நன்மைகளில் ஒன்று ஹெல்ம் விளக்கப்படங்களை நேரடியாக Git களஞ்சியத்தில் இருந்து வழங்கும் திறன் ஆகும்.

ஜிட் துணைத் தொகுதியைப் பயன்படுத்தி அதை இணைப்போம்:

git submodule add https://gitlab.com/gitlab-org/charts/gitlab-runner vendor/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,
  }
)

முதல் வாதம் விரிவாக்க ஹெல்ம் டெம்ப்ளேட் நாங்கள் விளக்கப்படத்திற்கான பாதையை கடந்து செல்கிறோம் params.values, சுற்றுச்சூழல் அளவுருக்களிலிருந்து நாம் எடுக்கும், பின்னர் பொருள் வருகிறது

• பெயர் வார்ப்புரு - வெளியீட்டு பெயர்
• பெயர்வெளி - பெயர்வெளி தலைமைக்கு மாற்றப்பட்டது
• இந்த கோப்பு — தற்போதைய கோப்பிற்கான பாதையை கடக்கும் தேவையான அளவுரு
• வினைச்சொல் - கட்டளையைக் காட்டுகிறது ஹெல்ம் டெம்ப்ளேட் விளக்கப்படத்தை வழங்கும்போது அனைத்து வாதங்களுடனும்

இப்போது எங்கள் கூறுக்கான அளவுருக்களை விவரிப்போம் சூழல்கள்/base.libsonnet:

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

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

கவனம் செலுத்துங்கள் ரன்னர் பதிவு டோக்கன் வெளிப்புற கோப்பிலிருந்து எடுக்கிறோம் இரகசியங்கள்/base.libsonnet, அதை உருவாக்குவோம்:

{
  runnerRegistrationToken: 'yga8y-jdCusVDn_t4Wxc',
}

எல்லாம் செயல்படுகிறதா என்று பார்ப்போம்:

qbec show default

எல்லாம் ஒழுங்காக இருந்தால், ஹெல்ம் வழியாக நாங்கள் முன்பு பயன்படுத்திய வெளியீட்டை நீக்கலாம்:

helm uninstall gitlab-runner

அதை அதே வழியில் பயன்படுத்தவும், ஆனால் qbec மூலம்:

qbec apply default

7. git-crypt ஐ அறிமுகப்படுத்துகிறது

Git-crypt உங்கள் களஞ்சியத்திற்கான வெளிப்படையான குறியாக்கத்தை அமைக்க உங்களை அனுமதிக்கும் ஒரு கருவியாகும்.

இந்த நேரத்தில், கிட்லாப்-ரன்னருக்கான எங்கள் கோப்பக அமைப்பு இதுபோல் தெரிகிறது:

.
├── 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/, எங்களிடம் ஒரு அடைவு உள்ளது இரகசியங்கள்/, அதில் உள்ள அனைத்து கோப்புகளையும் குறியாக்கம் செய்வோம், இதற்காக ஒரு கோப்பை உருவாக்குவோம் இரகசியங்கள்/.gitatributes பின்வரும் உள்ளடக்கத்துடன்:

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

உள்ளடக்கத்திலிருந்து பார்க்க முடிந்தால், எல்லா கோப்புகளும் மறைக்கப்பட்டுள்ளன * மூலம் இயக்கப்படும் git-crypt, பெரும்பாலானவை தவிர .gitatributes

இதை இயக்குவதன் மூலம் நாம் சரிபார்க்கலாம்:

git crypt status -e

வெளியீடு என்பது குறியாக்கம் இயக்கப்பட்ட களஞ்சியத்தில் உள்ள அனைத்து கோப்புகளின் பட்டியலாகும்

அவ்வளவுதான், இப்போது நாங்கள் எங்கள் மாற்றங்களை பாதுகாப்பாக செய்யலாம்:

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

ஒரு களஞ்சியத்தைத் தடுக்க, இயக்கவும்:

git crypt lock

உடனடியாக அனைத்து மறைகுறியாக்கப்பட்ட கோப்புகளும் பைனரியாக மாறும், அவற்றைப் படிக்க இயலாது.
களஞ்சியத்தை மறைகுறியாக்க, இயக்கவும்:

git crypt unlock

8. கருவிப்பெட்டி படத்தை உருவாக்கவும்

கருவிப்பெட்டி படம் என்பது எங்கள் திட்டத்தை செயல்படுத்துவதற்கு நாம் பயன்படுத்தும் அனைத்து கருவிகளையும் கொண்ட ஒரு படம். வழக்கமான வரிசைப்படுத்தல் பணிகளைச் செய்ய இது கிட்லாப் ரன்னர் மூலம் பயன்படுத்தப்படும்.

இங்கே எல்லாம் எளிது, புதிய ஒன்றை உருவாக்குவோம் 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

நீங்கள் பார்க்க முடியும் என, இந்த படத்தில் நாங்கள் எங்கள் பயன்பாட்டை வரிசைப்படுத்த பயன்படுத்திய அனைத்து பயன்பாடுகளையும் நிறுவுகிறோம். இல்லாவிட்டால் எங்களுக்கு அது இங்கு தேவையில்லை kubectl, ஆனால் பைப்லைன் அமைக்கும் கட்டத்தில் நீங்கள் அதனுடன் விளையாட விரும்பலாம்.

மேலும், குபெர்னெட்டஸுடன் தொடர்பு கொள்ளவும், அதை பயன்படுத்தவும், கிட்லாப்-ரன்னர் மூலம் உருவாக்கப்பட்ட காய்களுக்கு ஒரு பங்கை உள்ளமைக்க வேண்டும்.

இதைச் செய்ய, கிட்லாப்-ரன்னர் உள்ள கோப்பகத்திற்குச் செல்லலாம்:

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

எங்கள் மாற்றங்களை குபெர்னெட்டஸுக்குப் பயன்படுத்தவும்:

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

புதிய பதிப்பை வெளியிட வேண்டிய போதெல்லாம் குறிச்சொற்களைச் சேர்ப்போம். டோக்கர் படங்களில் உள்ள குறிச்சொற்கள் Git குறிச்சொற்களுடன் இணைக்கப்படும். புதிய குறிச்சொல்லுடன் கூடிய ஒவ்வொரு புஷ் இந்த குறிச்சொல்லுடன் படங்களின் உருவாக்கத்தை துவக்கும்.

செய்வோம் git push --tags, மற்றும் எங்கள் முதல் பைப்லைனைப் பார்ப்போம்:

முதல் பைப்லைனின் ஸ்கிரீன்ஷாட்

குறிச்சொற்கள் மூலம் அசெம்பிளி செய்வது டோக்கர் படங்களை உருவாக்க ஏற்றது, ஆனால் குபெர்னெட்டஸுக்கு ஒரு பயன்பாட்டைப் பயன்படுத்துவதற்கு ஏற்றது அல்ல என்பதில் உங்கள் கவனத்தை ஈர்ப்பது மதிப்பு. பழைய கமிட்களுக்கு புதிய குறிச்சொற்கள் ஒதுக்கப்படலாம் என்பதால், இந்த விஷயத்தில், அவற்றுக்கான பைப்லைனை துவக்குவது பழைய பதிப்பின் வரிசைப்படுத்தலுக்கு வழிவகுக்கும்.

இந்தச் சிக்கலைத் தீர்க்க, வழக்கமாக டாக்கர் படங்களின் உருவாக்கம் குறிச்சொற்களுடன் பிணைக்கப்பட்டுள்ளது, மேலும் ஒரு கிளையில் பயன்பாட்டைப் பயன்படுத்துதல் மாஸ்டர், இதில் சேகரிக்கப்பட்ட படங்களின் பதிப்புகள் ஹார்ட்கோட் செய்யப்பட்டுள்ளன. இங்குதான் நீங்கள் ஒரு எளிய மாற்றியமைப்புடன் ரோல்பேக்கைத் தொடங்கலாம் மாஸ்டர்- கிளைகள்.

10. வரிசைப்படுத்தலின் ஆட்டோமேஷன்

கிட்லாப்-ரன்னர் எங்கள் ரகசியங்களை டிக்ரிப்ட் செய்ய, நாம் களஞ்சிய விசையை ஏற்றுமதி செய்து அதை நமது 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 க்கான பல புதிய விருப்பங்களை இயக்கியுள்ளோம்:

• --ரூட் சில/ஆப் - ஒரு குறிப்பிட்ட பயன்பாட்டின் கோப்பகத்தைத் தீர்மானிக்க உங்களை அனுமதிக்கிறது
• --force:k8s-context __incluster__ - இது ஒரு மேஜிக் மாறி, இது gtilab-ரன்னர் இயங்கும் அதே கிளஸ்டரில் வரிசைப்படுத்தல் ஏற்படும் என்று கூறுகிறது. இது அவசியம், இல்லையெனில் qbec உங்கள் kubeconfig இல் பொருத்தமான குபெர்னெட்ஸ் சேவையகத்தைக் கண்டுபிடிக்க முயற்சிக்கும்.
• --காத்திரு — qbec ஐ உருவாக்கும் ஆதாரங்கள் தயார் நிலைக்குச் செல்லும் வரை காத்திருக்கும்படி கட்டாயப்படுத்துகிறது, பின்னர் வெற்றிகரமான வெளியேறும் குறியீட்டுடன் வெளியேறவும்.
• -ஆம் - ஊடாடும் ஷெல்லை வெறுமனே முடக்குகிறது நீங்கள் உறுதியாக இருக்கிறீர்களா? பயன்படுத்தப்படும் போது.

எங்கள் மாற்றங்களைச் செய்ய மறக்காதீர்கள்:

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

மற்றும் பிறகு git push எங்கள் பயன்பாடுகள் எவ்வாறு பயன்படுத்தப்பட்டன என்பதைப் பார்ப்போம்:

இரண்டாவது பைப்லைனின் ஸ்கிரீன்ஷாட்

11. மாஸ்டருக்குத் தள்ளும்போது கலைப்பொருட்கள் மற்றும் சட்டசபை

பொதுவாக, மேலே விவரிக்கப்பட்டுள்ள படிநிலைகள் ஏறக்குறைய எந்தவொரு மைக்ரோ சர்வீஸையும் உருவாக்க மற்றும் வழங்க போதுமானது, ஆனால் ஒவ்வொரு முறையும் நாங்கள் தளத்தைப் புதுப்பிக்க வேண்டியிருக்கும் போது ஒரு குறிச்சொல்லைச் சேர்க்க நாங்கள் விரும்பவில்லை. எனவே, நாங்கள் மிகவும் ஆற்றல்மிக்க வழியை எடுத்து, முதன்மைக் கிளையில் ஒரு டைஜஸ்ட் வரிசைப்படுத்தலை அமைப்போம்.

யோசனை எளிது: இப்போது எங்கள் படம் வலைத்தளம் நீங்கள் தள்ளும் ஒவ்வொரு முறையும் மீண்டும் கட்டப்படும் மாஸ்டர், பின்னர் தானாகவே Kubernetes க்கு அனுப்பப்படும்.

இந்த இரண்டு வேலைகளையும் எங்களில் புதுப்பிப்போம் .gitlab-ci.yml:

build_website:
  extends: .build_docker_image
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  script:
    - mkdir -p $CI_PROJECT_DIR/artifacts
    - /kaniko/executor --cache --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/dockerfiles/website/Dockerfile --destination $CI_REGISTRY_IMAGE/website:$CI_COMMIT_REF_NAME --digest-file $CI_PROJECT_DIR/artifacts/website.digest
  artifacts:
    paths:
      - artifacts/
  only:
    refs:
      - master
      - tags

deploy_website:
  extends: .deploy_qbec_app
  script:
    - DIGEST="$(cat artifacts/website.digest)"
    - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST"

நாங்கள் ஒரு நூலைச் சேர்த்துள்ளோம் என்பதை நினைவில் கொள்ளவும் மாஸ்டர் к refs வேலைகளுக்கு உருவாக்க_இணையதளம் நாங்கள் இப்போது பயன்படுத்துகிறோம் $CI_COMMIT_REF_NAME அதற்கு பதிலாக $CI_COMMIT_TAG, அதாவது, நாம் Git இல் உள்ள குறிச்சொற்களில் இருந்து அவிழ்த்துவிட்டோம், இப்போது பைப்லைனை துவக்கிய கமிட் கிளையின் பெயருடன் ஒரு படத்தைத் தள்ளுவோம். இது குறிச்சொற்களிலும் வேலை செய்யும் என்பது குறிப்பிடத்தக்கது, இது ஒரு குறிப்பிட்ட பதிப்பைக் கொண்ட தளத்தின் ஸ்னாப்ஷாட்களை டோக்கர்-ரெஜிஸ்ட்ரியில் சேமிக்க அனுமதிக்கும்.

தளத்தின் புதிய பதிப்பிற்கான டோக்கர் குறிச்சொல்லின் பெயர் மாறாமல் இருக்கும்போது, ​​​​குபெர்னெட்டஸில் மாற்றங்களை இன்னும் விவரிக்க வேண்டும், இல்லையெனில் அது புதிய படத்திலிருந்து பயன்பாட்டை மீண்டும் வரிசைப்படுத்தாது, ஏனெனில் அது எந்த மாற்றத்தையும் கவனிக்காது. வரிசைப்படுத்தல் வெளிப்பாடு.

விருப்பம் —vm:ext-str digest=”$DIGEST” qbec க்கு - வெளிப்புற மாறியை jsonnet க்கு அனுப்ப உங்களை அனுமதிக்கிறது. எங்கள் பயன்பாட்டின் ஒவ்வொரு வெளியீட்டிலும் இது கிளஸ்டரில் மீண்டும் பயன்படுத்தப்பட வேண்டும் என்று நாங்கள் விரும்புகிறோம். நாம் இனி டேக் பெயரைப் பயன்படுத்த முடியாது, அது இப்போது மாற்ற முடியாததாக இருக்கலாம், ஏனெனில் படத்தின் குறிப்பிட்ட பதிப்போடு நாம் இணைக்கப்பட வேண்டும் மற்றும் அது மாறும் போது வரிசைப்படுத்தலைத் தூண்ட வேண்டும்.

ஒரு கோப்பில் ஒரு டைஜெஸ்ட் படத்தைச் சேமிக்கும் கனிகோவின் திறனால் இங்கே நமக்கு உதவுவோம் (விருப்பம் --digest-file)
பின்னர் இந்த கோப்பை மாற்றுவோம் மற்றும் பயன்படுத்தப்படும் நேரத்தில் அதைப் படிப்போம்.

எங்களுக்கான அளவுருக்களை புதுப்பிப்போம் 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 push இது போன்ற ஒன்றை நாம் பார்க்க வேண்டும்:

மாஸ்டருக்கான பைப்லைனின் ஸ்கிரீன்ஷாட்

கொள்கையளவில், ஒவ்வொரு உந்துதலிலும் கிட்லாப்-ரன்னரை மீண்டும் பயன்படுத்த வேண்டிய அவசியமில்லை, நிச்சயமாக, அதன் உள்ளமைவில் எதுவும் மாறவில்லை என்றால், அதைச் சரிசெய்வோம் .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 push, அது உகந்தது:

புதுப்பிக்கப்பட்ட பைப்லைனின் ஸ்கிரீன்ஷாட்

12. மாறும் சூழல்கள்

டைனமிக் சூழல்களுடன் எங்கள் பைப்லைனைப் பன்முகப்படுத்த வேண்டிய நேரம் இது.

முதலில், வேலையைப் புதுப்பிப்போம் உருவாக்க_இணையதளம் எங்கள் .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/

பின்னர் வேலையை புதுப்பிக்கவும் 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"

இது கிட்லாப் வேலையை இணைக்க அனுமதிக்கும் தயாரிப்பு சூழல் மற்றும் அதற்கான சரியான இணைப்பைக் காண்பிக்கும்.

இப்போது மேலும் இரண்டு வேலைகளைச் சேர்ப்போம்:

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 — இது பயன்பாட்டின் வரிசைப்படுத்தப்பட்ட பதிப்புகளைக் குறிக்கவும், இந்தக் குறிச்சொல்லுக்குள் மட்டுமே வேலை செய்யவும் உங்களை அனுமதிக்கிறது; குபெர்னெட்டஸில் வளங்களை உருவாக்கி அழிக்கும்போது, ​​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 push, git Checkout -b சோதனை, git புஷ் தோற்றம் சோதனை, காசோலை:

கிட்லாப்பில் உருவாக்கப்பட்ட சூழல்களின் ஸ்கிரீன்ஷாட்

எல்லாம் செயல்படுகிறதா? - அருமை, எங்கள் சோதனைக் கிளையை நீக்கவும்: git checkout master, ஜிட் புஷ் தோற்றம்: சோதனை, சூழல் நீக்குதல் வேலைகள் பிழைகள் இல்லாமல் செயல்பட்டதா என்பதை நாங்கள் சரிபார்க்கிறோம்.

ஒரு திட்டத்தில் எந்த டெவலப்பரும் கிளைகளை உருவாக்க முடியும் என்பதை இங்கே நான் உடனடியாக தெளிவுபடுத்த விரும்புகிறேன், அவர் மாற்றவும் முடியும் .gitlab-ci.yml கோப்பு மற்றும் அணுகல் இரகசிய மாறிகள்.
எனவே, பாதுகாக்கப்பட்ட கிளைகளுக்கு மட்டுமே அவற்றின் பயன்பாட்டை அனுமதிக்க கடுமையாக பரிந்துரைக்கப்படுகிறது, எடுத்துக்காட்டாக மாஸ்டர், அல்லது ஒவ்வொரு சூழலுக்கும் தனித்தனியான மாறிகளை உருவாக்கவும்.

13. பயன்பாடுகளை மதிப்பாய்வு செய்யவும்

பயன்பாடுகளை மதிப்பாய்வு செய்யவும் இது ஒரு GitLab அம்சமாகும், இது களஞ்சியத்தில் உள்ள ஒவ்வொரு கோப்பிற்கும் ஒரு பொத்தானைச் சேர்க்க உங்களை அனுமதிக்கும்.

இந்த பொத்தான்கள் தோன்றுவதற்கு, நீங்கள் ஒரு கோப்பை உருவாக்க வேண்டும் .gitlab/route-map.yml மற்றும் அதில் உள்ள அனைத்து பாதை மாற்றங்களையும் விவரிக்கவும்; எங்கள் விஷயத்தில் இது மிகவும் எளிமையானதாக இருக்கும்:

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

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

எங்கள் மாற்றங்களைச் செய்ய மறக்காதீர்கள்:

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

git push, மற்றும் சரிபார்க்கவும்:

மதிப்பாய்வு ஆப் பட்டனின் ஸ்கிரீன்ஷாட்

வேலை முடிந்தது!

திட்ட ஆதாரங்கள்:

• கிட்லாப்பில்: https://gitlab.com/kvaps/docs.example.org
• GitHub இல்: https://github.com/kvaps/docs.example.org

உங்கள் கவனத்திற்கு நன்றி, உங்களுக்கு பிடித்திருந்தது என்று நம்புகிறேன்

ஆதாரம்: www.habr.com