નમસ્તે! તાજેતરમાં, ડોકર ઈમેજીસ બનાવવા અને કુબરનેટ્સ પર જમાવટ માટે બંને માટે ઘણા શાનદાર ઓટોમેશન ટૂલ્સ બહાર પાડવામાં આવ્યા છે. આ સંદર્ભે, મેં ગિટલેબ સાથે રમવાનું નક્કી કર્યું, તેની ક્ષમતાઓનો સંપૂર્ણ અભ્યાસ કર્યો અને, અલબત્ત, પાઇપલાઇન સેટ કરી.

આ કાર્ય વેબસાઇટ દ્વારા પ્રેરિત હતું kubernetes.io, જેમાંથી પેદા થાય છે સ્ત્રોત કોડ્સ આપમેળે, અને દરેક પૂલ વિનંતી મોકલવા માટે, રોબોટ આપમેળે તમારા ફેરફારો સાથે સાઇટનું પૂર્વાવલોકન સંસ્કરણ જનરેટ કરે છે અને જોવા માટે એક લિંક પ્રદાન કરે છે.

મેં શરૂઆતથી સમાન પ્રક્રિયા બનાવવાનો પ્રયાસ કર્યો, પરંતુ સંપૂર્ણ રીતે Gitlab CI અને મફત ટૂલ્સ પર બનેલ છે જેનો ઉપયોગ હું કુબરનેટ્સ પર એપ્લિકેશન્સ જમાવવા માટે ઉપયોગ કરવા માટે ઉપયોગ કરું છું. આજે હું તમને આખરે તેમના વિશે વધુ જણાવીશ.

આ લેખ સાધનોની ચર્ચા કરશે જેમ કે:
હ્યુગો, qbec, કનિકો, git-ક્રિપ્ટ и ગિટલેબ સી.આઈ. ગતિશીલ વાતાવરણની રચના સાથે.

સામગ્રી

1. હ્યુગોને મળો
2. ડોકરફાઇલ તૈયાર કરી રહ્યા છીએ
3. કનિકોને ઓળખવા
4. qbec ને જાણવું
5. કુબરનેટ્સ-એક્ઝિક્યુટર સાથે ગિટલેબ-રનરનો પ્રયાસ કરી રહ્યાં છીએ
6. qbec સાથે હેલ્મ ચાર્ટ ગોઠવી રહ્યા છીએ
7. ગિટ-ક્રિપ્ટનો પરિચય
8. ટૂલબોક્સ ઇમેજ બનાવી રહ્યા છીએ
9. અમારી પ્રથમ પાઇપલાઇન અને ટૅગ્સ દ્વારા છબીઓની એસેમ્બલી
10. જમાવટ ઓટોમેશન
11. માસ્ટર પર દબાણ કરતી વખતે કલાકૃતિઓ અને એસેમ્બલી
12. ગતિશીલ વાતાવરણ
13. એપ્લિકેશનોની સમીક્ષા કરો

1. હ્યુગોને જાણવું

અમારા પ્રોજેક્ટના ઉદાહરણ તરીકે, અમે હ્યુગો પર બનેલ દસ્તાવેજીકરણ પ્રકાશન સાઇટ બનાવવાનો પ્રયાસ કરીશું. હ્યુગો એ સ્ટેટિક કન્ટેન્ટ જનરેટર છે.

જેઓ સ્ટેટિક જનરેટર્સથી પરિચિત નથી, હું તમને તેમના વિશે થોડું વધુ કહીશ. ડેટાબેઝ અને કેટલાક PHP સાથેના પરંપરાગત વેબસાઇટ એન્જિનથી વિપરીત, જે વપરાશકર્તા દ્વારા વિનંતી કરવામાં આવે ત્યારે, ફ્લાય પર પૃષ્ઠો જનરેટ કરે છે, સ્ટેટિક જનરેટર્સ થોડી અલગ રીતે ડિઝાઇન કરવામાં આવે છે. તેઓ તમને સ્ત્રોતો લેવાની મંજૂરી આપે છે, સામાન્ય રીતે માર્કડાઉન માર્કઅપ અને થીમ ટેમ્પલેટ્સમાં ફાઇલોનો સમૂહ, પછી તેમને સંપૂર્ણ રીતે સમાપ્ત વેબસાઇટમાં કમ્પાઇલ કરો.

એટલે કે, પરિણામે, તમને એક ડિરેક્ટરી માળખું અને જનરેટ કરેલી HTML ફાઇલોનો સમૂહ પ્રાપ્ત થશે, જેને તમે કોઈપણ સસ્તા હોસ્ટિંગ પર અપલોડ કરી શકો છો અને કાર્યકારી વેબસાઇટ મેળવી શકો છો.

તમે હ્યુગોને સ્થાનિક રીતે ઇન્સ્ટોલ કરી શકો છો અને તેને અજમાવી શકો છો:

નવી સાઇટ શરૂ કરી રહ્યા છીએ:

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

• ડોકરફાઈલ્સ/ - ડોકરફાઈલ્સ સાથેની ડિરેક્ટરીઓ અને અમારી ડોકર ઈમેજીસ બનાવવા માટે જરૂરી બધું સમાવે છે.
• જમાવવું/ — કુબરનેટ્સ પર અમારી એપ્લિકેશનો જમાવવા માટેની ડિરેક્ટરીઓ ધરાવે છે

આમ, અમે પાથ સાથે અમારી પ્રથમ ડોકરફાઇલ બનાવીશું ડોકરફાઈલ્સ/વેબસાઈટ/ડોકરફાઈલ

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" ]

જેમ તમે જોઈ શકો છો, ડોકરફાઈલમાં બે છે થી, આ લક્ષણ કહેવાય છે મલ્ટિ-સ્ટેજ બિલ્ડ અને તમને અંતિમ ડોકર ઈમેજમાંથી બિનજરૂરી દરેક વસ્તુને બાકાત રાખવા દે છે.
આમ, અંતિમ છબી ફક્ત સમાવશે શ્યામhttpd (હળવા HTTP સર્વર) અને જાહેર/ - અમારી સ્ટેટિકલી જનરેટ કરેલી વેબસાઇટની સામગ્રી.

અમારા ફેરફારો કરવાનું ભૂલશો નહીં:

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

3. કનિકોને જાણવું

ડોકર ઇમેજ બિલ્ડર તરીકે, મેં ઉપયોગ કરવાનું નક્કી કર્યું કનિકો, કારણ કે તેના ઓપરેશન માટે ડોકર ડિમનની જરૂર નથી, અને બિલ્ડ પોતે કોઈપણ મશીન પર હાથ ધરવામાં આવી શકે છે અને કેશને સીધી રજિસ્ટ્રીમાં સંગ્રહિત કરી શકાય છે, ત્યાં સંપૂર્ણ સુવિધાયુક્ત સતત સ્ટોરેજની જરૂરિયાતને દૂર કરે છે.

છબી બનાવવા માટે, ફક્ત કન્ટેનર સાથે ચલાવો kaniko વહીવટકર્તા અને તેને વર્તમાન બિલ્ડ સંદર્ભમાં પસાર કરો; આ ડોકર દ્વારા સ્થાનિક રીતે પણ કરી શકાય છે:

docker run -ti --rm 
  -v $PWD:/workspace 
  -v ~/.docker/config.json:/kaniko/.docker/config.json:ro 
  gcr.io/kaniko-project/executor:v0.15.0 
  --cache 
  --dockerfile=dockerfiles/website/Dockerfile 
  --destination=registry.gitlab.com/kvaps/docs.example.org/website:v0.0.1

ક્યાં registry.gitlab.com/kvaps/docs.example.org/website - તમારી ડોકર ઇમેજનું નામ; બનાવ્યા પછી, તે આપમેળે ડોકર રજિસ્ટ્રીમાં લોંચ થશે.

પેરામીટર --કેશ તમને ડોકર રજિસ્ટ્રીમાં સ્તરો કેશ કરવાની મંજૂરી આપે છે; આપેલ ઉદાહરણ માટે, તેઓ આમાં સાચવવામાં આવશે registry.gitlab.com/kvaps/docs.example.org/website/cache, પરંતુ તમે પેરામીટરનો ઉપયોગ કરીને અન્ય પાથનો ઉલ્લેખ કરી શકો છો --cache-repo.

ડોકર-રજિસ્ટ્રીનો સ્ક્રીનશોટ

4. qbec ને જાણવું

Qbec ડિપ્લોયમેન્ટ ટૂલ છે જે તમને તમારી એપ્લિકેશન મેનિફેસ્ટને ઘોષણાત્મક રીતે વર્ણવવા અને તેમને કુબરનેટ્સ પર જમાવટ કરવાની મંજૂરી આપે છે. મુખ્ય વાક્યરચના તરીકે Jsonnet નો ઉપયોગ કરવાથી તમે બહુવિધ વાતાવરણમાં તફાવતોના વર્ણનને મોટા પ્રમાણમાં સરળ બનાવી શકો છો, અને કોડ પુનરાવર્તનને લગભગ સંપૂર્ણપણે દૂર કરે છે.

આ ખાસ કરીને એવા કિસ્સાઓમાં સાચું હોઈ શકે છે કે જ્યાં તમારે વિવિધ પરિમાણો સાથે કેટલાક ક્લસ્ટરોમાં એપ્લિકેશન જમાવવાની જરૂર હોય અને ગિટમાં ઘોષણાત્મક રીતે તેનું વર્ણન કરવા માંગતા હો.

Qbec તમને જરૂરી પરિમાણો પસાર કરીને હેલ્મ ચાર્ટને રેન્ડર કરવાની પણ પરવાનગી આપે છે અને પછી તેને નિયમિત મેનિફેસ્ટની જેમ સંચાલિત કરે છે, જેમાં તમે તેના પર વિવિધ પરિવર્તનો લાગુ કરી શકો છો, અને આ બદલામાં, તમને જરૂરિયાતથી છુટકારો મેળવવાની મંજૂરી આપે છે. ચાર્ટ મ્યુઝિયમનો ઉપયોગ કરો. એટલે કે, તમે ચાર્ટ્સને સીધા જ ગિટમાંથી સ્ટોર અને રેન્ડર કરી શકો છો, જ્યાં તેઓ સંબંધિત છે.

મેં અગાઉ કહ્યું તેમ, અમે તમામ જમાવટને ડિરેક્ટરીમાં સંગ્રહિત કરીશું જમાવવું/:

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.Environments, qbec એ પહેલાથી જ અમારા માટે ડિફોલ્ટ એન્વાયર્નમેન્ટ બનાવ્યું છે અને સર્વર સરનામું, તેમજ અમારી વર્તમાન kubeconfig માંથી નેમસ્પેસ લીધું છે.
હવે જ્યારે તૈનાત મૂળભૂત પર્યાવરણ, qbec હંમેશા માત્ર ઉલ્લેખિત Kubernetes ક્લસ્ટર અને ઉલ્લેખિત નેમસ્પેસમાં જ જમાવટ કરશે, એટલે કે, જમાવટ કરવા માટે તમારે સંદર્ભો અને નેમસ્પેસ વચ્ચે સ્વિચ કરવાની જરૂર નથી.
જો જરૂરી હોય, તો તમે હંમેશા આ ફાઇલમાં સેટિંગ્સ અપડેટ કરી શકો છો.

તમારા બધા વાતાવરણમાં વર્ણવેલ છે qbec.yaml, અને ફાઇલમાં params.libsonnet, જ્યાં તે કહે છે કે તેમના માટે પરિમાણો ક્યાંથી મેળવવું.

આગળ આપણે બે ડિરેક્ટરીઓ જોઈએ છીએ:

• ઘટકો/ - અમારી એપ્લિકેશન માટેના તમામ મેનિફેસ્ટ્સ અહીં સંગ્રહિત કરવામાં આવશે; તેનું વર્ણન jsonnet અને નિયમિત yaml ફાઇલો બંનેમાં કરી શકાય છે
• વાતાવરણ/ — અહીં આપણે આપણા વાતાવરણ માટેના તમામ ચલ (પેરામીટર્સ)નું વર્ણન કરીશું.

મૂળભૂત રીતે અમારી પાસે બે ફાઇલો છે:

• Environments/base.libsonnet - તેમાં તમામ વાતાવરણ માટે સામાન્ય પરિમાણો હશે
• Environments/default.libsonnet — પર્યાવરણ માટે ઓવરરાઇડ કરેલા પરિમાણો સમાવે છે મૂળભૂત

ચાલો ખોલીએ Environments/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',
    },
  },
}

ચાલો આપણો પ્રથમ ઘટક પણ બનાવીએ components/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-jsonnet, જે સિન્ટેક્સ હાઇલાઇટિંગ ચાલુ કરે છે અને આપમેળે એક્ઝિક્યુટ થાય છે jsonnet fmt જ્યારે પણ તમે સાચવો છો (જેસોનેટ ઇન્સ્ટોલ કરવું જરૂરી છે).

બધું તૈયાર છે, હવે અમે જમાવવાનું શરૂ કરી શકીએ છીએ:

અમને શું મળ્યું તે જોવા માટે, ચાલો ચલાવીએ:

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-રનર શેલ અથવા ડોકર-એક્ઝિક્યુટર સાથે પૂર્વ-તૈયાર મશીન (LXC કન્ટેનર) પર. શરૂઆતમાં, અમારી ગિટલેબમાં વૈશ્વિક સ્તરે વ્યાખ્યાયિત એવા ઘણા દોડવીરો હતા. તેઓએ તમામ પ્રોજેક્ટ્સ માટે ડોકર છબીઓ એકત્રિત કરી.

પરંતુ પ્રેક્ટિસ બતાવે છે તેમ, આ વિકલ્પ વ્યવહારિકતા અને સલામતી બંનેની દ્રષ્ટિએ સૌથી આદર્શ નથી. દરેક પ્રોજેક્ટ માટે અથવા તો દરેક પર્યાવરણ માટે અલગ દોડવીરો તૈનાત કરવા તે વધુ સારું અને વૈચારિક રીતે વધુ યોગ્ય છે.

સદનસીબે, આ કોઈ સમસ્યા નથી, કારણ કે હવે અમે જમાવશું gitlab-રનર સીધા કુબરનેટ્સમાં અમારા પ્રોજેક્ટના ભાગ રૂપે.

ગિટલેબ કુબરનેટીસને ગિટલેબ-રનરને તૈનાત કરવા માટે તૈયાર હેલ્મ ચાર્ટ પ્રદાન કરે છે. તેથી તમારે ફક્ત શોધવાની જરૂર છે નોંધણી ટોકન માં અમારા પ્રોજેક્ટ માટે સેટિંગ્સ -> 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 - તમારા ગિટલેબ સર્વરનું સરનામું.
• yga8y-jdCusVDn_t4Wxc - તમારા પ્રોજેક્ટ માટે નોંધણી ટોકન.
• rbac.create=true — kubernetes-executor નો ઉપયોગ કરીને અમારા કાર્યો કરવા માટે પોડ્સ બનાવવા માટે સક્ષમ થવા માટે રનરને જરૂરી વિશેષાધિકારો પ્રદાન કરે છે.

જો બધું યોગ્ય રીતે કરવામાં આવ્યું હોય, તો તમારે વિભાગમાં નોંધાયેલ રનર જોવો જોઈએ દોડવીરો, તમારા પ્રોજેક્ટ સેટિંગ્સમાં.

ઉમેરાયેલ રનરનો સ્ક્રીનશોટ

તે સરળ છે? - હા, તે ખૂબ સરળ છે! મેન્યુઅલી દોડવીરોની નોંધણી કરવામાં હવે કોઈ તકલીફ નહીં પડે, હવેથી દોડવીરો આપોઆપ બનાવવામાં આવશે અને નાશ પામશે.

6. QBEC સાથે હેલ્મ ચાર્ટ ગોઠવો

કારણ કે અમે ધ્યાનમાં લેવાનું નક્કી કર્યું gitlab-રનર અમારા પ્રોજેક્ટનો એક ભાગ છે, તે અમારા ગિટ રિપોઝીટરીમાં તેનું વર્ણન કરવાનો સમય છે.

અમે તેને એક અલગ ઘટક તરીકે વર્ણવી શકીએ છીએ વેબસાઇટ, પરંતુ ભવિષ્યમાં અમે વિવિધ નકલો જમાવવાની યોજના બનાવીએ છીએ વેબસાઇટ ઘણી વાર, વિપરીત gitlab-રનર, જે કુબરનેટ્સ ક્લસ્ટર દીઠ માત્ર એક જ વાર જમાવવામાં આવશે. તો ચાલો તેના માટે એક અલગ એપ્લિકેશન શરૂ કરીએ:

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

ચાલો ઘટકનું વર્ણન કરીએ 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,
  }
)

માટે પ્રથમ દલીલ expandHelmTemplate અમે ચાર્ટ પર પાથ પસાર કરીએ છીએ, પછી params.values, જે આપણે પર્યાવરણ પરિમાણોમાંથી લઈએ છીએ, તે પછી ઑબ્જેક્ટ આવે છે

• નામનો ઢાંચો - પ્રકાશન નામ
• નામસ્થળ - નેમસ્પેસ સુકાન પર સ્થાનાંતરિત
• આ ફાઇલ — જરૂરી પરિમાણ કે જે વર્તમાન ફાઇલનો પાથ પસાર કરે છે
• વર્બોઝ - આદેશ બતાવે છે સુકાન નમૂનો ચાર્ટ રેન્ડર કરતી વખતે તમામ દલીલો સાથે

હવે ચાલો માં આપણા ઘટક માટેના પરિમાણોનું વર્ણન કરીએ Environments/base.libsonnet:

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

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

ધ્યાન આપો દોડવીર નોંધણી ટોકન અમે બાહ્ય ફાઇલમાંથી લઈએ છીએ secrets/base.libsonnet, ચાલો તેને બનાવીએ:

{
  runnerRegistrationToken: 'yga8y-jdCusVDn_t4Wxc',
}

ચાલો તપાસીએ કે બધું કામ કરે છે કે નહીં:

qbec show default

જો બધું વ્યવસ્થિત હોય, તો અમે હેલ્મ દ્વારા અમારી અગાઉ જમાવવામાં આવેલ પ્રકાશન કાઢી નાખી શકીએ છીએ:

helm uninstall gitlab-runner

અને તે જ રીતે જમાવવા, પરંતુ qbec દ્વારા:

qbec apply default

7. ગિટ-ક્રિપ્ટનો પરિચય

ગિટ-ક્રિપ્ટ એક સાધન છે જે તમને તમારી રીપોઝીટરી માટે પારદર્શક એન્ક્રિપ્શન સેટ કરવા દે છે.

આ ક્ષણે, ગિટલેબ-રનર માટેની અમારી ડિરેક્ટરી માળખું આના જેવું દેખાય છે:

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

પરંતુ ગિટમાં રહસ્યો સંગ્રહિત કરવું સલામત નથી, શું તે છે? તેથી આપણે તેમને યોગ્ય રીતે એન્ક્રિપ્ટ કરવાની જરૂર છે.

સામાન્ય રીતે, એક ચલ ખાતર, આ હંમેશા અર્થમાં નથી. તમે રહસ્યો ટ્રાન્સફર કરી શકો છો qbec અને તમારી CI સિસ્ટમના પર્યાવરણ ચલો દ્વારા.
પરંતુ તે નોંધવું યોગ્ય છે કે ત્યાં વધુ જટિલ પ્રોજેક્ટ્સ પણ છે જેમાં ઘણા વધુ રહસ્યો હોઈ શકે છે; તે બધાને પર્યાવરણ ચલ દ્વારા સ્થાનાંતરિત કરવું અત્યંત મુશ્કેલ હશે.

તદુપરાંત, આ કિસ્સામાં હું તમને આવા અદ્ભુત સાધન વિશે કહી શકતો નથી git-ક્રિપ્ટ.

git-ક્રિપ્ટ તે પણ અનુકૂળ છે કે તે તમને રહસ્યોના સમગ્ર ઇતિહાસને સાચવવાની મંજૂરી આપે છે, સાથે સાથે સરખામણી, મર્જ અને તકરારને તે જ રીતે ઉકેલવા દે છે જે રીતે આપણે ગિટના કિસ્સામાં કરવા માટે ટેવાયેલા છીએ.

સ્થાપન પછી પ્રથમ વસ્તુ git-ક્રિપ્ટ આપણે આપણી રીપોઝીટરી માટે કી જનરેટ કરવાની જરૂર છે:

git crypt init

જો તમારી પાસે PGP કી છે, તો તમે તરત જ આ પ્રોજેક્ટ માટે સહયોગી તરીકે તમારી જાતને ઉમેરી શકો છો:

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

આ રીતે તમે હંમેશા તમારી ખાનગી કીનો ઉપયોગ કરીને આ રીપોઝીટરીને ડિક્રિપ્ટ કરી શકો છો.

જો તમારી પાસે PGP કી નથી અને તેની અપેક્ષા નથી, તો તમે બીજી રીતે જઈને પ્રોજેક્ટ કી નિકાસ કરી શકો છો:

git crypt export-key /path/to/keyfile

આમ, જે કોઈ નિકાસ કરે છે કીફાઈલ તમારા રીપોઝીટરીને ડિક્રિપ્ટ કરવામાં સક્ષમ હશે.

આ અમારું પ્રથમ રહસ્ય સેટ કરવાનો સમય છે.
ચાલો હું તમને યાદ કરાવું કે અમે હજી પણ ડિરેક્ટરીમાં છીએ જમાવટ/gitlab-runner/, જ્યાં અમારી પાસે ડિરેક્ટરી છે રહસ્યો/, ચાલો તેમાંની બધી ફાઈલોને એન્ક્રિપ્ટ કરીએ, આ માટે આપણે એક ફાઈલ બનાવીશું રહસ્યો/.gitattributes નીચેની સામગ્રી સાથે:

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

સામગ્રીમાંથી જોઈ શકાય છે તેમ, બધી ફાઇલો માસ્ક કરેલી છે * દ્વારા ચલાવવામાં આવશે git-ક્રિપ્ટ, સૌથી સિવાય .gitaattributes

અમે તેને ચલાવીને ચકાસી શકીએ છીએ:

git crypt status -e

આઉટપુટ એ રીપોઝીટરીમાંની બધી ફાઈલોની યાદી હશે જેના માટે એન્ક્રિપ્શન સક્ષમ છે

બસ, હવે અમે સુરક્ષિત રીતે અમારા ફેરફારો કરી શકીએ છીએ:

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

રીપોઝીટરીને અવરોધિત કરવા માટે, ફક્ત ચલાવો:

git crypt lock

અને તરત જ બધી એન્ક્રિપ્ટેડ ફાઇલો બાઈનરી કંઈકમાં ફેરવાઈ જશે, તેમને વાંચવું અશક્ય હશે.
રીપોઝીટરીને ડિક્રિપ્ટ કરવા માટે, ચલાવો:

git crypt unlock

8. ટૂલબોક્સ ઈમેજ બનાવો

ટૂલબોક્સ ઇમેજ એ તમામ સાધનો સાથેની એક ઇમેજ છે જેનો ઉપયોગ અમે અમારા પ્રોજેક્ટને જમાવવા માટે કરીશું. તેનો ઉપયોગ ગિટલેબ રનર દ્વારા લાક્ષણિક જમાવટ કાર્યો કરવા માટે કરવામાં આવશે.

અહીં બધું સરળ છે, ચાલો એક નવું બનાવીએ ડોકરફાઈલ્સ/ટૂલબોક્સ/ડોકરફાઈલ નીચેની સામગ્રી સાથે:

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, પરંતુ તમે પાઇપલાઇન સેટઅપ તબક્કા દરમિયાન તેની સાથે રમવા માગી શકો છો.

ઉપરાંત, કુબરનેટ્સ સાથે વાતચીત કરવા અને તેને જમાવવામાં સક્ષમ થવા માટે, અમારે ગિટલેબ-રનર દ્વારા જનરેટ કરેલા પોડ્સ માટે ભૂમિકા ગોઠવવાની જરૂર છે.

આ કરવા માટે, ચાલો 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,
      },
    ],
  },
]

અમે નવા પરિમાણોનું પણ વર્ણન કરીશું Environments/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 ઉલ્લેખ કરે નામ ઘટક માટે આરબીએસી

ચાલો તપાસીએ કે શું બદલાયું છે:

qbec diff default

અને કુબરનેટ્સ પર અમારા ફેરફારો લાગુ કરો:

qbec apply default

ઉપરાંત, ગિટમાં અમારા ફેરફારો કરવાનું ભૂલશો નહીં:

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 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 માટે ઘણા નવા વિકલ્પો સક્રિય કર્યા છે:

• --root some/app — તમને ચોક્કસ એપ્લિકેશનની ડિરેક્ટરી નક્કી કરવા દે છે
• --ફોર્સ:k8s-સંદર્ભ __ સમાવેશ__ - આ એક જાદુઈ ચલ છે જે કહે છે કે જમાવટ એ જ ક્લસ્ટરમાં થશે જેમાં gtilab-runner ચાલી રહ્યું છે. આ જરૂરી છે કારણ કે અન્યથા qbec તમારા kubeconfig માં યોગ્ય Kubernetes સર્વર શોધવાનો પ્રયત્ન કરશે.
• -- રાહ જુઓ — qbec ને ત્યાં સુધી રાહ જોવા માટે દબાણ કરે છે જ્યાં સુધી તે બનાવેલ સંસાધનો તૈયાર સ્થિતિમાં ન જાય અને માત્ર ત્યારે જ સફળ એક્ઝિટ-કોડ સાથે બહાર નીકળો.
• -હા - ફક્ત ઇન્ટરેક્ટિવ શેલને અક્ષમ કરે છે શું તમને ખાતરી છે? જ્યારે તૈનાત.

અમારા ફેરફારો કરવાનું ભૂલશો નહીં:

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

અને પછી ગીટ દબાણ અમે જોઈશું કે અમારી એપ્લિકેશનો કેવી રીતે જમાવવામાં આવી છે:

બીજી પાઇપલાઇનનો સ્ક્રીનશોટ

11. માસ્ટર પર દબાણ કરતી વખતે કલાકૃતિઓ અને એસેમ્બલી

સામાન્ય રીતે, ઉપર વર્ણવેલ પગલાં લગભગ કોઈપણ માઇક્રોસર્વિસ બનાવવા અને વિતરિત કરવા માટે પૂરતા છે, પરંતુ અમે દર વખતે સાઇટને અપડેટ કરવાની જરૂર હોય ત્યારે ટેગ ઉમેરવા માંગતા નથી. તેથી, અમે વધુ ગતિશીલ માર્ગ અપનાવીશું અને મુખ્ય શાખામાં ડાયજેસ્ટ જમાવટ ગોઠવીશું.

વિચાર સરળ છે: હવે અમારી છબી વેબસાઇટ જ્યારે પણ તમે દબાણ કરશો ત્યારે ફરીથી બનાવવામાં આવશે માસ્ટર, અને પછી આપમેળે કુબરનેટ્સ પર જમાવટ કરો.

ચાલો આપણામાં આ બે નોકરીઓ અપડેટ કરીએ .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"

મહેરબાની કરીને નોંધ કરો કે અમે એક થ્રેડ ઉમેર્યો છે માસ્ટર к ref. નોકરીઓ માટે બિલ્ડ_વેબસાઇટ અને અમે હવે ઉપયોગ કરીએ છીએ $CI_COMMIT_REF_NAME вместо $CI_COMMIT_TAG, એટલે કે, અમે Git માં ટૅગ્સથી છૂટી ગયા છીએ અને હવે અમે કમિટ બ્રાન્ચના નામ સાથે એક ઇમેજને દબાણ કરીશું જેણે પાઇપલાઇન શરૂ કરી છે. તે નોંધવું યોગ્ય છે કે આ ટૅગ્સ સાથે પણ કામ કરશે, જે અમને ડોકર-રજિસ્ટ્રીમાં ચોક્કસ સંસ્કરણ સાથે સાઇટના સ્નેપશોટને સાચવવાની મંજૂરી આપશે.

જ્યારે સાઇટના નવા સંસ્કરણ માટે ડોકર ટેગનું નામ અપરિવર્તિત થઈ શકે છે, ત્યારે અમારે હજી પણ કુબરનેટ્સમાં ફેરફારોનું વર્ણન કરવું પડશે, અન્યથા તે ફક્ત નવી છબીમાંથી એપ્લિકેશનને ફરીથી ગોઠવશે નહીં, કારણ કે તે કોઈપણ ફેરફારોની નોંધ લેશે નહીં. જમાવટ મેનિફેસ્ટ.

વિકલ્પ —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',
    },
  },
}

થઈ ગયું, હવે કોઈપણ કમિટ ઇન કરો માસ્ટર માટે ડોકર ઈમેજનું બિલ્ડ આરંભ કરે છે વેબસાઇટ, અને પછી તેને કુબરનેટ્સ પર જમાવો.

અમારા ફેરફારો કરવાનું ભૂલશો નહીં:

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

અમે પછીથી તપાસ કરીશું ગીટ દબાણ આપણે આના જેવું કંઈક જોવું જોઈએ:

માસ્ટર માટે પાઇપલાઇનનો સ્ક્રીનશોટ

સૈદ્ધાંતિક રીતે, આપણે દરેક પુશ સાથે ગિટલેબ-રનરને ફરીથી ગોઠવવાની જરૂર નથી, સિવાય કે, અલબત્ત, તેના રૂપરેખાંકનમાં કંઈ બદલાયું નથી, ચાલો તેને ઠીક કરીએ. .gitlab-ci.yml:

deploy_gitlab_runner:
  extends: .deploy_qbec_app
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  before_script:
    - base64 -d "$GITCRYPT_KEY" | git-crypt unlock -
  script:
    - qbec apply default --root deploy/gitlab-runner --force:k8s-context __incluster__ --wait --yes
  only:
    changes:
      - deploy/gitlab-runner/**/*

ફેરફારો માં ફેરફારોનું નિરીક્ષણ કરવાની મંજૂરી આપશે જમાવટ/gitlab-runner/ અને જો કોઈ હોય તો જ અમારી નોકરીને ટ્રિગર કરશે

અમારા ફેરફારો કરવાનું ભૂલશો નહીં:

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

ગીટ દબાણ, સરસ:

અપડેટ કરેલ પાઇપલાઇનનો સ્ક્રીનશોટ

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:
  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 માટે નવો વિકલ્પ જોઈએ છીએ: --એપ-ટેગ — તે તમને એપ્લિકેશનના તૈનાત વર્ઝનને ટેગ કરવાની પરવાનગી આપે છે અને ફક્ત આ ટેગની અંદર જ કામ કરે છે; જ્યારે કુબરનેટ્સમાં સંસાધનો બનાવતી અને નાશ કરતી વખતે, 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',
    },
  },
}

ચાલો જોબ્યુ પર પણ નજીકથી નજર કરીએ રોકો_સમીક્ષા, જ્યારે શાખા કાઢી નાખવામાં આવશે ત્યારે તે ટ્રિગર થશે અને જેથી ગિટલેબ ચેકઆઉટ કરવાનો પ્રયાસ ન કરે તે માટે તેનો ઉપયોગ કરવામાં આવે છે GIT_STRATEGY: કોઈ નહીં, પછીથી અમે ક્લોન કરીએ છીએ માસ્ટર- તેના દ્વારા રિવ્યુને શાખા અને કાઢી નાખો.
તે થોડું ગૂંચવણભર્યું છે, પરંતુ મને હજી સુધી વધુ સુંદર રસ્તો મળ્યો નથી.
એક વૈકલ્પિક વિકલ્પ દરેક સમીક્ષાને હોટેલ નેમસ્પેસમાં જમાવવાનો હશે, જે હંમેશા સંપૂર્ણપણે તોડી શકાય છે.

અમારા ફેરફારો કરવાનું ભૂલશો નહીં:

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

ગીટ દબાણ, git Checkout -b ટેસ્ટ, git પુશ ઓરિજિન ટેસ્ટ, તપાસો:

ગિટલેબમાં બનાવેલા વાતાવરણનો સ્ક્રીનશોટ

બધું કામ કરે છે? - સરસ, અમારી પરીક્ષણ શાખા કાઢી નાખો: જીટ ચેકઆઉટ માસ્ટર, git પુશ મૂળ: પરીક્ષણ, અમે તપાસીએ છીએ કે પર્યાવરણ કાઢી નાખવાની જોબ્સ ભૂલો વિના કામ કરે છે.

અહીં હું તરત જ સ્પષ્ટ કરવા માંગુ છું કે પ્રોજેક્ટમાં કોઈપણ વિકાસકર્તા શાખાઓ બનાવી શકે છે, તે બદલી પણ શકે છે .gitlab-ci.yml ફાઇલ અને એક્સેસ ગુપ્ત ચલો.
તેથી, ફક્ત સંરક્ષિત શાખાઓ માટે જ તેમના ઉપયોગને મંજૂરી આપવાની ભારપૂર્વક ભલામણ કરવામાં આવે છે, ઉદાહરણ તરીકે માં માસ્ટર, અથવા દરેક પર્યાવરણ માટે ચલોનો એક અલગ સેટ બનાવો.

13. એપ્સની સમીક્ષા કરો

એપ્લિકેશનોની સમીક્ષા કરો આ એક GitLab સુવિધા છે જે તમને તૈનાત વાતાવરણમાં ઝડપથી જોવા માટે રીપોઝીટરીમાં દરેક ફાઇલ માટે એક બટન ઉમેરવાની મંજૂરી આપે છે.

આ બટનો દેખાવા માટે, તમારે ફાઇલ બનાવવાની જરૂર છે .gitlab/route-map.yml અને તેમાંના તમામ પાથ પરિવર્તનોનું વર્ણન કરો; અમારા કિસ્સામાં તે ખૂબ જ સરળ હશે:

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

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

અમારા ફેરફારો કરવાનું ભૂલશો નહીં:

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

ગીટ દબાણ, અને તપાસો:

સમીક્ષા એપ્લિકેશન બટનનો સ્ક્રીનશોટ

કામ થઈ ગયું!

પ્રોજેક્ટ સ્ત્રોતો:

• ગિટલેબ પર: https://gitlab.com/kvaps/docs.example.org
• GitHub પર: https://github.com/kvaps/docs.example.org

તમારા ધ્યાન બદલ આભાર, મને આશા છે કે તમને તે ગમ્યું હશે

સોર્સ: www.habr.com