ഹലോ! അടുത്തിടെ, ഡോക്കർ ഇമേജുകൾ നിർമ്മിക്കുന്നതിനും കുബർനെറ്റിലേക്ക് വിന്യാസത്തിനുമായി നിരവധി രസകരമായ ഓട്ടോമേഷൻ ടൂളുകൾ പുറത്തിറക്കിയിട്ടുണ്ട്. ഇക്കാര്യത്തിൽ, ഞാൻ 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

അതേ സമയം git ശേഖരം:

cd docs.example.org
git init

ഇതുവരെ, ഞങ്ങളുടെ സൈറ്റ് പ്രാകൃതമാണ്, അതിൽ എന്തെങ്കിലും ദൃശ്യമാകുന്നതിന്, ഞങ്ങൾ ആദ്യം ഒരു തീം കണക്റ്റുചെയ്യേണ്ടതുണ്ട്; ഒരു തീം എന്നത് ഞങ്ങളുടെ സൈറ്റ് സൃഷ്ടിക്കുന്ന ടെംപ്ലേറ്റുകളുടെയും നിർദ്ദിഷ്ട നിയമങ്ങളുടെയും ഒരു കൂട്ടം മാത്രമാണ്.

തീമിനായി ഞങ്ങൾ ഉപയോഗിക്കും അറിയുക, ഇത്, എന്റെ അഭിപ്രായത്തിൽ, ഒരു ഡോക്യുമെന്റേഷൻ സൈറ്റിന് തികച്ചും അനുയോജ്യമാണ്.

ഞങ്ങളുടെ പ്രോജക്റ്റിന്റെ റിപ്പോസിറ്ററിയിൽ തീം ഫയലുകൾ സംരക്ഷിക്കേണ്ടതില്ല എന്ന വസ്തുത പ്രത്യേകം ശ്രദ്ധിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു; പകരം, നമുക്ക് ഇത് ഉപയോഗിച്ച് കണക്ട് ചെയ്യാം git സബ്മോഡ്യൂൾ:

git submodule add https://github.com/matcornic/hugo-theme-learn themes/learn

അതിനാൽ, ഞങ്ങളുടെ ശേഖരത്തിൽ ഞങ്ങളുടെ പ്രോജക്റ്റുമായി നേരിട്ട് ബന്ധപ്പെട്ട ഫയലുകൾ മാത്രമേ അടങ്ങിയിട്ടുള്ളൂ, കൂടാതെ കണക്റ്റുചെയ്‌ത തീം ഒരു നിർദ്ദിഷ്‌ട ശേഖരത്തിലേക്കുള്ള ലിങ്കായും അതിലെ പ്രതിബദ്ധതയായും നിലനിൽക്കും, അതായത്, ഇത് എല്ലായ്പ്പോഴും യഥാർത്ഥ ഉറവിടത്തിൽ നിന്ന് പിൻവലിക്കാം, ഭയപ്പെടരുത്. പൊരുത്തപ്പെടാത്ത മാറ്റങ്ങൾ.

നമുക്ക് കോൺഫിഗറേഷൻ ശരിയാക്കാം config.toml:

baseURL = "http://docs.example.org/"
languageCode = "en-us"
title = "My Docs Site"
theme = "learn"

ഇതിനകം ഈ ഘട്ടത്തിൽ നിങ്ങൾക്ക് പ്രവർത്തിപ്പിക്കാൻ കഴിയും:

hugo server

ഒപ്പം വിലാസത്തിലും http://localhost:1313/ ഞങ്ങളുടെ പുതുതായി സൃഷ്‌ടിച്ച വെബ്‌സൈറ്റ് പരിശോധിക്കുക, ഡയറക്‌ടറിയിൽ വരുത്തിയ എല്ലാ മാറ്റങ്ങളും ബ്രൗസറിലെ തുറന്ന പേജ് യാന്ത്രികമായി അപ്‌ഡേറ്റ് ചെയ്യുക, വളരെ സൗകര്യപ്രദമാണ്!

ഒരു കവർ പേജ് സൃഷ്ടിക്കാൻ ശ്രമിക്കാം ഉള്ളടക്കം/_index.md:

# My docs site

## Welcome to the docs!

You will be very smart :-)

പുതുതായി സൃഷ്ടിച്ച പേജിന്റെ സ്ക്രീൻഷോട്ട്

ഒരു സൈറ്റ് സൃഷ്ടിക്കാൻ, പ്രവർത്തിപ്പിക്കുക:

hugo

ഡയറക്ടറി ഉള്ളടക്കം പൊതു/ നിങ്ങളുടെ വെബ്സൈറ്റ് ആയിരിക്കും.
അതെ, വഴിയിൽ, നമുക്ക് ഇത് ഉടൻ ചേർക്കാം .ജിറ്റിഗ്നോർ:

echo /public > .gitignore

ഞങ്ങളുടെ മാറ്റങ്ങൾ വരുത്താൻ മറക്കരുത്:

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

2. ഡോക്കർഫയൽ തയ്യാറാക്കുന്നു

ഞങ്ങളുടെ ശേഖരണത്തിന്റെ ഘടന നിർവചിക്കാനുള്ള സമയമാണിത്. ഞാൻ സാധാരണയായി ഇതുപോലുള്ള ഒന്ന് ഉപയോഗിക്കുന്നു:

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

• ഡോക്കർ ഫയലുകൾ/ — ഡോക്കർ ഫയലുകളുള്ള ഡയറക്‌ടറികളും ഞങ്ങളുടെ ഡോക്കർ ഇമേജുകൾ നിർമ്മിക്കാൻ ആവശ്യമായ എല്ലാം അടങ്ങിയിരിക്കുന്നു.
• വിന്യസിക്കുക/ — കുബർനെറ്റസിലേക്ക് ഞങ്ങളുടെ ആപ്ലിക്കേഷനുകൾ വിന്യസിക്കുന്നതിനുള്ള ഡയറക്ടറികൾ അടങ്ങിയിരിക്കുന്നു

അങ്ങനെ, പാതയിലൂടെ ഞങ്ങൾ ഞങ്ങളുടെ ആദ്യത്തെ ഡോക്കർഫയൽ സൃഷ്ടിക്കും 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" ]

നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, ഡോക്കർഫയലിൽ രണ്ടെണ്ണം അടങ്ങിയിരിക്കുന്നു FROM, ഈ സവിശേഷതയെ വിളിക്കുന്നു മൾട്ടി-സ്റ്റേജ് ബിൽഡ് അവസാന ഡോക്കർ ഇമേജിൽ നിന്ന് അനാവശ്യമായ എല്ലാം ഒഴിവാക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു.
അതിനാൽ, അന്തിമ ചിത്രത്തിൽ മാത്രമേ അടങ്ങിയിരിക്കൂ ഇരുണ്ട httpd (കനംകുറഞ്ഞ HTTP സെർവർ) കൂടാതെ പൊതു/ — സ്ഥിരമായി സൃഷ്ടിച്ച ഞങ്ങളുടെ വെബ്സൈറ്റിന്റെ ഉള്ളടക്കം.

ഞങ്ങളുടെ മാറ്റങ്ങൾ വരുത്താൻ മറക്കരുത്:

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

3. കനിക്കോയെ അറിയുക

ഒരു ഡോക്കർ ഇമേജ് ബിൽഡർ എന്ന നിലയിൽ, ഞാൻ ഉപയോഗിക്കാൻ തീരുമാനിച്ചു കാണിക്കോ, അതിന്റെ പ്രവർത്തനത്തിന് ഒരു ഡോക്കർ ഡെമൺ ആവശ്യമില്ലാത്തതിനാൽ, ബിൽഡ് തന്നെ ഏത് മെഷീനിലും നടപ്പിലാക്കാനും കാഷെ നേരിട്ട് രജിസ്ട്രിയിൽ സൂക്ഷിക്കാനും കഴിയും, അതുവഴി ഒരു പൂർണ്ണമായ സ്ഥിരമായ സംഭരണത്തിന്റെ ആവശ്യകത ഇല്ലാതാക്കുന്നു.

ചിത്രം നിർമ്മിക്കാൻ, കണ്ടെയ്നർ പ്രവർത്തിപ്പിക്കുക കനിക്കോ എക്സിക്യൂട്ടർ നിലവിലെ ബിൽഡ് സന്ദർഭത്തിൽ ഇത് കൈമാറുക; ഇത് ഡോക്കർ വഴി പ്രാദേശികമായും ചെയ്യാവുന്നതാണ്:

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

എവിടെയാണ് registry.gitlab.com/kvaps/docs.example.org/website - നിങ്ങളുടെ ഡോക്കർ ഇമേജിന്റെ പേര്; നിർമ്മിച്ചതിന് ശേഷം, അത് ഡോക്കർ രജിസ്ട്രിയിലേക്ക് സ്വയമേവ ലോഞ്ച് ചെയ്യും.

പാരാമീറ്റർ --കാഷെ ഡോക്കർ രജിസ്ട്രിയിൽ ലെയറുകൾ കാഷെ ചെയ്യാൻ നിങ്ങളെ അനുവദിക്കുന്നു; നൽകിയിരിക്കുന്ന ഉദാഹരണത്തിന്, അവ സംരക്ഷിക്കപ്പെടും registry.gitlab.com/kvaps/docs.example.org/website/cache, എന്നാൽ പരാമീറ്റർ ഉപയോഗിച്ച് നിങ്ങൾക്ക് മറ്റൊരു പാത വ്യക്തമാക്കാം --കാഷെ-റിപ്പോ.

ഡോക്കർ രജിസ്ട്രിയുടെ സ്ക്രീൻഷോട്ട്

4. qbec-നെ അറിയുക

Qbec നിങ്ങളുടെ ആപ്ലിക്കേഷൻ മാനിഫെസ്റ്റുകളെ ഡിക്ലറേറ്റീവ് ആയി വിവരിക്കാനും അവയെ കുബർനെറ്റിലേക്ക് വിന്യസിക്കാനും നിങ്ങളെ അനുവദിക്കുന്ന ഒരു വിന്യാസ ഉപകരണമാണ്. Jsonnet പ്രധാന വാക്യഘടനയായി ഉപയോഗിക്കുന്നത് ഒന്നിലധികം പരിതസ്ഥിതികളിലെ വ്യത്യാസങ്ങളുടെ വിവരണം വളരെ ലളിതമാക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു, കൂടാതെ കോഡ് ആവർത്തനത്തെ ഏതാണ്ട് പൂർണ്ണമായും ഇല്ലാതാക്കുന്നു.

വ്യത്യസ്‌ത പാരാമീറ്ററുകളുള്ള നിരവധി ക്ലസ്റ്ററുകളിലേക്ക് നിങ്ങൾ ഒരു ആപ്ലിക്കേഷൻ വിന്യസിക്കേണ്ടതും അവ Git-ൽ പ്രഖ്യാപനപരമായി വിവരിക്കാൻ ആഗ്രഹിക്കുന്നതുമായ സന്ദർഭങ്ങളിൽ ഇത് പ്രത്യേകിച്ചും സത്യമായിരിക്കും.

ആവശ്യമായ പാരാമീറ്ററുകൾ പാസാക്കി ഹെൽം ചാർട്ടുകൾ റെൻഡർ ചെയ്യാനും തുടർന്ന് അവയെ സാധാരണ മാനിഫെസ്റ്റുകളുടെ അതേ രീതിയിൽ പ്രവർത്തിപ്പിക്കാനും 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 എല്ലായ്‌പ്പോഴും നിർദ്ദിഷ്‌ട കുബർനെറ്റസ് ക്ലസ്റ്ററിലേക്കും നിർദ്ദിഷ്ട നെയിംസ്‌പെയ്‌സിലേക്കും മാത്രമേ വിന്യസിക്കൂ, അതായത്, ഒരു വിന്യാസം നടത്താൻ നിങ്ങൾ ഇനി സന്ദർഭങ്ങൾക്കും നെയിംസ്‌പെയ്‌സിനും ഇടയിൽ മാറേണ്ടതില്ല.
ആവശ്യമെങ്കിൽ, ഈ ഫയലിലെ ക്രമീകരണങ്ങൾ നിങ്ങൾക്ക് എല്ലായ്പ്പോഴും അപ്ഡേറ്റ് ചെയ്യാം.

നിങ്ങളുടെ എല്ലാ പരിതസ്ഥിതികളും വിവരിച്ചിരിക്കുന്നു 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 നിങ്ങളുടെ സാധാരണ യാമിനെ json ആക്കി മാറ്റാൻ, അല്ലെങ്കിൽ, നിങ്ങളുടെ ഘടകങ്ങളിൽ വേരിയബിളുകളൊന്നും അടങ്ങിയിട്ടില്ലെങ്കിൽ, അവ സാധാരണ യാമിന്റെ രൂപത്തിൽ വിവരിക്കാം.

കൂടെ ജോലി ചെയ്യുമ്പോൾ jsonnet നിങ്ങളുടെ എഡിറ്ററിനായി ഒരു പ്ലഗിൻ ഇൻസ്റ്റാൾ ചെയ്യാൻ ഞാൻ വളരെ ശുപാർശ ചെയ്യുന്നു

ഉദാഹരണത്തിന്, വിമ്മിനായി ഒരു പ്ലഗിൻ ഉണ്ട് 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 കണ്ടെയ്നർ). തുടക്കത്തിൽ, ഞങ്ങളുടെ ഗിറ്റ്‌ലാബിൽ ആഗോളതലത്തിൽ നിർവചിക്കപ്പെട്ട അത്തരം നിരവധി ഓട്ടക്കാർ ഉണ്ടായിരുന്നു. എല്ലാ പ്രോജക്ടുകൾക്കുമായി അവർ ഡോക്കർ ചിത്രങ്ങൾ ശേഖരിച്ചു.

എന്നാൽ പ്രാക്ടീസ് കാണിച്ചിരിക്കുന്നതുപോലെ, പ്രായോഗികതയുടെയും സുരക്ഷയുടെയും കാര്യത്തിൽ ഈ ഓപ്ഷൻ ഏറ്റവും അനുയോജ്യമല്ല. ഓരോ പ്രോജക്റ്റിനും അല്ലെങ്കിൽ ഓരോ പരിതസ്ഥിതിക്കും പോലും പ്രത്യേക റണ്ണേഴ്സിനെ വിന്യസിക്കുന്നത് വളരെ മികച്ചതും പ്രത്യയശാസ്ത്രപരമായി കൂടുതൽ ശരിയുമാണ്.

ഭാഗ്യവശാൽ, ഇത് ഒരു പ്രശ്നമല്ല, കാരണം ഇപ്പോൾ ഞങ്ങൾ വിന്യസിക്കും ഗിറ്റ്ലാബ്-റണ്ണർ ഞങ്ങളുടെ പ്രോജക്റ്റിന്റെ ഭാഗമായി നേരിട്ട് കുബർനെറ്റസിൽ.

കുബർനെറ്റസിലേക്ക് ഗിറ്റ്‌ലാബ്-റണ്ണറെ വിന്യസിക്കുന്നതിന് 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 — നിങ്ങളുടെ Gitlab സെർവറിന്റെ വിലാസം.
• yga8y-jdCusVDn_t4Wxc - നിങ്ങളുടെ പ്രോജക്റ്റിനായുള്ള രജിസ്ട്രേഷൻ ടോക്കൺ.
• rbac.create=true - kubernetes-executor ഉപയോഗിച്ച് ഞങ്ങളുടെ ടാസ്‌ക്കുകൾ നിർവഹിക്കുന്നതിന് പോഡുകൾ സൃഷ്‌ടിക്കാൻ ആവശ്യമായ പ്രത്യേകാവകാശങ്ങൾ റണ്ണറിന് നൽകുന്നു.

എല്ലാം ശരിയായി ചെയ്തുവെങ്കിൽ, വിഭാഗത്തിൽ നിങ്ങൾ ഒരു രജിസ്റ്റർ ചെയ്ത റണ്ണറെ കാണണം റണ്ണേഴ്സ്, നിങ്ങളുടെ പ്രോജക്റ്റ് ക്രമീകരണങ്ങളിൽ.

ചേർത്ത റണ്ണറുടെ സ്ക്രീൻഷോട്ട്

ഇത് അത്ര ലളിതമാണോ? - അതെ, ഇത് വളരെ ലളിതമാണ്! റണ്ണേഴ്‌സിനെ സ്വമേധയാ രജിസ്റ്റർ ചെയ്യുന്നതിൽ കൂടുതൽ പ്രശ്‌നമില്ല, ഇനി മുതൽ റണ്ണേഴ്‌സ് സ്വയമേവ സൃഷ്ടിക്കപ്പെടുകയും നശിപ്പിക്കപ്പെടുകയും ചെയ്യും.

6. ക്യുബിഇസിയിൽ ഹെൽം ചാർട്ടുകൾ വിന്യസിക്കുക

ഞങ്ങൾ പരിഗണിക്കാൻ തീരുമാനിച്ചതിനാൽ ഗിറ്റ്ലാബ്-റണ്ണർ ഞങ്ങളുടെ പ്രോജക്റ്റിന്റെ ഭാഗം, ഞങ്ങളുടെ Git ശേഖരത്തിൽ ഇത് വിവരിക്കാനുള്ള സമയമാണിത്.

നമുക്ക് അതിനെ ഒരു പ്രത്യേക ഘടകമായി വിശേഷിപ്പിക്കാം വെബ്സൈറ്റ്, എന്നാൽ ഭാവിയിൽ വ്യത്യസ്ത പകർപ്പുകൾ വിന്യസിക്കാൻ ഞങ്ങൾ പദ്ധതിയിടുന്നു വെബ്സൈറ്റ് പലപ്പോഴും, വ്യത്യസ്തമായി ഗിറ്റ്ലാബ്-റണ്ണർ, ഓരോ കുബർനെറ്റസ് ക്ലസ്റ്ററിനും ഒരിക്കൽ മാത്രം വിന്യസിക്കപ്പെടും. അതിനാൽ, അതിനായി ഒരു പ്രത്യേക ആപ്ലിക്കേഷൻ ആരംഭിക്കാം:

cd deploy
qbec init gitlab-runner
cd gitlab-runner

ഇത്തവണ ഞങ്ങൾ കുബർനെറ്റസ് എന്റിറ്റികളെ സ്വമേധയാ വിവരിക്കുന്നില്ല, മറിച്ച് ഒരു റെഡിമെയ്ഡ് ഹെൽം ചാർട്ട് എടുക്കും. ഒരു Git റിപ്പോസിറ്ററിയിൽ നിന്ന് നേരിട്ട് ഹെൽം ചാർട്ടുകൾ റെൻഡർ ചെയ്യാനുള്ള കഴിവാണ് qbec-ന്റെ ഒരു ഗുണം.

ജിറ്റ് സബ്മോഡ്യൂൾ ഉപയോഗിച്ച് നമുക്ക് ഇത് ബന്ധിപ്പിക്കാം:

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

ആദ്യ വാദം ExpandHelmTemplate ഞങ്ങൾ ചാർട്ടിലേക്കുള്ള പാത കടന്നുപോകുന്നു, തുടർന്ന് 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. ജിറ്റ്-ക്രിപ്റ്റിലേക്കുള്ള ആമുഖം

ജിറ്റ്-ക്രിപ്റ്റ് നിങ്ങളുടെ റിപ്പോസിറ്ററിക്കായി സുതാര്യമായ എൻക്രിപ്ഷൻ സജ്ജീകരിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന ഒരു ഉപകരണമാണ്.

ഇപ്പോൾ, 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

അങ്ങനെ, ഒരു കയറ്റുമതി ഉള്ള ആർക്കും കീഫയൽ നിങ്ങളുടെ റിപ്പോസിറ്ററി ഡീക്രിപ്റ്റ് ചെയ്യാൻ കഴിയും.

ഞങ്ങളുടെ ആദ്യ രഹസ്യം സ്ഥാപിക്കാനുള്ള സമയമാണിത്.
ഞങ്ങൾ ഇപ്പോഴും ഡയറക്ടറിയിലാണെന്ന് ഞാൻ നിങ്ങളെ ഓർമ്മിപ്പിക്കട്ടെ വിന്യസിക്കുക/gitlab-runner/, ഇവിടെ നമുക്ക് ഒരു ഡയറക്ടറി ഉണ്ട് രഹസ്യങ്ങൾ/, അതിലെ എല്ലാ ഫയലുകളും എൻക്രിപ്റ്റ് ചെയ്യാം, ഇതിനായി നമ്മൾ ഒരു ഫയൽ ഉണ്ടാക്കും രഹസ്യങ്ങൾ/.ഗിറ്റാട്രിബ്യൂട്ടുകൾ ഇനിപ്പറയുന്ന ഉള്ളടക്കത്തോടൊപ്പം:

* 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. ഒരു ടൂൾബോക്സ് ഇമേജ് സൃഷ്ടിക്കുക

ടൂൾബോക്സ് ഇമേജ് എന്നത് ഞങ്ങളുടെ പ്രോജക്റ്റ് വിന്യസിക്കാൻ ഉപയോഗിക്കുന്ന എല്ലാ ടൂളുകളുമുള്ള ഒരു ചിത്രമാണ്. സാധാരണ വിന്യാസ ജോലികൾ ചെയ്യാൻ 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

കൂടാതെ ഒരു പുതിയ ഘടകം ചേർക്കുക ഘടകങ്ങൾ/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. വിന്യാസത്തിന്റെ ഓട്ടോമേഷൻ

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-നുള്ള നിരവധി പുതിയ ഓപ്ഷനുകൾ ഞങ്ങൾ ഇവിടെ പ്രവർത്തനക്ഷമമാക്കിയിട്ടുണ്ട്:

• --റൂട്ട് ചിലത്/ആപ്പ് - ഒരു നിർദ്ദിഷ്ട ആപ്ലിക്കേഷന്റെ ഡയറക്ടറി നിർണ്ണയിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു
• --force:k8s-context __incluster__ - ജിടിലാബ്-റണ്ണർ പ്രവർത്തിക്കുന്ന അതേ ക്ലസ്റ്ററിൽ വിന്യാസം സംഭവിക്കുമെന്ന് പറയുന്ന ഒരു മാജിക് വേരിയബിളാണിത്. ഇത് ആവശ്യമാണ്, അല്ലാത്തപക്ഷം നിങ്ങളുടെ kubeconfig-ൽ അനുയോജ്യമായ ഒരു Kubernetes സെർവർ കണ്ടെത്താൻ qbec ശ്രമിക്കും.
• --കാത്തിരിക്കുക — qbec സൃഷ്ടിക്കുന്ന ഉറവിടങ്ങൾ റെഡി സ്റ്റേറ്റിലേക്ക് പോകുന്നതുവരെ കാത്തിരിക്കാൻ qbec-നെ നിർബന്ധിക്കുന്നു, അതിനുശേഷം മാത്രമേ വിജയകരമായ എക്സിറ്റ്-കോഡ് ഉപയോഗിച്ച് പുറത്തുകടക്കുക.
• - അതെ - ഇന്ററാക്ടീവ് ഷെൽ കേവലം പ്രവർത്തനരഹിതമാക്കുന്നു നിങ്ങള്ക്ക് ഉറപ്പാണോ? വിന്യസിച്ചപ്പോൾ.

ഞങ്ങളുടെ മാറ്റങ്ങൾ വരുത്താൻ മറക്കരുത്:

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

പിന്നെ git push ഞങ്ങളുടെ ആപ്ലിക്കേഷനുകൾ എങ്ങനെയാണ് വിന്യസിച്ചിരിക്കുന്നതെന്ന് ഞങ്ങൾ കാണും:

രണ്ടാമത്തെ പൈപ്പ്ലൈനിന്റെ സ്ക്രീൻഷോട്ട്

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"

ഞങ്ങൾ ഒരു ത്രെഡ് ചേർത്തുവെന്നത് ശ്രദ്ധിക്കുക യജമാനന് к 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',
    },
  },
}

ചെയ്തു, ഇപ്പോൾ എന്തെങ്കിലും പ്രതിജ്ഞാബദ്ധത യജമാനന് എന്നതിനായുള്ള ഡോക്കർ ഇമേജിന്റെ നിർമ്മാണം ആരംഭിക്കുന്നു വെബ്സൈറ്റ്, തുടർന്ന് അത് കുബർനെറ്റസിലേക്ക് വിന്യസിക്കുക.

ഞങ്ങളുടെ മാറ്റങ്ങൾ വരുത്താൻ മറക്കരുത്:

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/**/*

മാറ്റങ്ങൾ മാറ്റങ്ങൾ നിരീക്ഷിക്കാൻ നിങ്ങളെ അനുവദിക്കും വിന്യസിക്കുക/gitlab-runner/ എന്തെങ്കിലും ഉണ്ടെങ്കിൽ മാത്രമേ ഞങ്ങളുടെ ജോലി ട്രിഗർ ചെയ്യുകയുള്ളൂ

ഞങ്ങളുടെ മാറ്റങ്ങൾ വരുത്താൻ മറക്കരുത്:

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

git push, അതാണ് നല്ലത്:

അപ്ഡേറ്റ് ചെയ്ത പൈപ്പ്ലൈനിന്റെ സ്ക്രീൻഷോട്ട്

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-tag - ആപ്ലിക്കേഷന്റെ വിന്യസിച്ചിരിക്കുന്ന പതിപ്പുകൾ ടാഗുചെയ്യാനും ഈ ടാഗിൽ മാത്രം പ്രവർത്തിക്കാനും ഇത് നിങ്ങളെ അനുവദിക്കുന്നു; Kubernetes-ൽ വിഭവങ്ങൾ സൃഷ്ടിക്കുകയും നശിപ്പിക്കുകയും ചെയ്യുമ്പോൾ, qbec അവയ്‌ക്കൊപ്പം മാത്രമേ പ്രവർത്തിക്കൂ.
ഈ രീതിയിൽ, ഓരോ അവലോകനത്തിനും ഒരു പ്രത്യേക അന്തരീക്ഷം സൃഷ്ടിക്കാൻ ഞങ്ങൾക്ക് കഴിയില്ല, എന്നാൽ അതേ ഒന്ന് വീണ്ടും ഉപയോഗിക്കുക.

ഇവിടെയും ഞങ്ങൾ ഉപയോഗിക്കുന്നു qbec അവലോകനം പ്രയോഗിക്കുക, ഇതിനുപകരമായി qbec സ്ഥിരസ്ഥിതിയായി പ്രയോഗിക്കുക - നമ്മുടെ പരിതസ്ഥിതികൾക്കുള്ള വ്യത്യാസങ്ങൾ വിവരിക്കാൻ ശ്രമിക്കുന്ന നിമിഷം ഇതാണ് (അവലോകനവും സ്ഥിരസ്ഥിതിയും):

നമുക്ക് കൂട്ടിച്ചേർക്കാം അവലോകനം പരിസ്ഥിതിയിൽ deploy/website/qbec.yaml

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

അപ്പോൾ ഞങ്ങൾ അത് പ്രഖ്യാപിക്കും deploy/website/params.libsonnet:

local env = std.extVar('qbec.io/env');
local paramsMap = {
  _: import './environments/base.libsonnet',
  default: import './environments/default.libsonnet',
  review: import './environments/review.libsonnet',
};

if std.objectHas(paramsMap, env) then paramsMap[env] else error 'environment ' + env + ' not defined in ' + std.thisFile

അതിനുള്ള ഇഷ്‌ടാനുസൃത പാരാമീറ്ററുകൾ എഴുതുക deploy/website/environments/review.libsonnet:

// this file has the param overrides for the default environment
local base = import './base.libsonnet';
local slug = std.extVar('qbec.io/tag');
local subdomain = std.extVar('subdomain');

base {
  components+: {
    website+: {
      name: 'example-docs-' + slug,
      domain: subdomain + '.docs.example.org',
    },
  },
}

നമുക്ക് ജോബുവിനെ അടുത്ത് നോക്കാം stop_review, ബ്രാഞ്ച് ഇല്ലാതാക്കുമ്പോൾ അത് പ്രവർത്തനക്ഷമമാകും, അതിനാൽ gitlab അത് ചെക്ക്ഔട്ട് ചെയ്യാൻ ശ്രമിക്കില്ല. GIT_STRATEGY: ഒന്നുമില്ല, പിന്നീട് ഞങ്ങൾ ക്ലോൺ ചെയ്യുന്നു യജമാനന്- ബ്രാഞ്ച് ചെയ്ത് അതിലൂടെ അവലോകനം ഇല്ലാതാക്കുക.
ഇത് അൽപ്പം ആശയക്കുഴപ്പമുണ്ടാക്കുന്നു, പക്ഷേ കൂടുതൽ മനോഹരമായ ഒരു വഴി ഞാൻ ഇതുവരെ കണ്ടെത്തിയിട്ടില്ല.
ഒരു ഹോട്ടൽ നെയിംസ്പേസിലേക്ക് ഓരോ അവലോകനവും വിന്യസിക്കുക എന്നതാണ് മറ്റൊരു ഓപ്ഷൻ, അത് എല്ലായ്പ്പോഴും പൂർണ്ണമായും പൊളിക്കാവുന്നതാണ്.

ഞങ്ങളുടെ മാറ്റങ്ങൾ വരുത്താൻ മറക്കരുത്:

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

git push, git ചെക്ക്ഔട്ട് -b ടെസ്റ്റ്, git പുഷ് ഒറിജിൻ ടെസ്റ്റ്, ചെക്ക്:

Gitlab-ൽ സൃഷ്ടിച്ച പരിതസ്ഥിതികളുടെ സ്ക്രീൻഷോട്ട്

എല്ലാം പ്രവർത്തിക്കുന്നുണ്ടോ? - കൊള്ളാം, ഞങ്ങളുടെ ടെസ്റ്റ് ബ്രാഞ്ച് ഇല്ലാതാക്കുക: git ചെക്ക് out ട്ട് മാസ്റ്റർ, git പുഷ് ഉത്ഭവം:ടെസ്റ്റ്, പരിസ്ഥിതി ഇല്ലാതാക്കൽ ജോലികൾ പിശകുകളില്ലാതെ പ്രവർത്തിക്കുന്നുണ്ടെന്ന് ഞങ്ങൾ പരിശോധിക്കുന്നു.

ഒരു പ്രോജക്റ്റിലെ ഏത് ഡവലപ്പർക്കും ശാഖകൾ സൃഷ്ടിക്കാൻ കഴിയുമെന്ന് ഇവിടെ ഉടനടി വ്യക്തമാക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു, അവനും മാറ്റാൻ കഴിയും .gitlab-ci.yml ഫയൽ, രഹസ്യ വേരിയബിളുകൾ ആക്സസ് ചെയ്യുക.
അതിനാൽ, സംരക്ഷിത ശാഖകൾക്ക് മാത്രം അവയുടെ ഉപയോഗം അനുവദിക്കാൻ ശക്തമായി ശുപാർശ ചെയ്യുന്നു, ഉദാഹരണത്തിന് യജമാനന്, അല്ലെങ്കിൽ ഓരോ പരിതസ്ഥിതിക്കും വേരിയബിളുകളുടെ ഒരു പ്രത്യേക സെറ്റ് സൃഷ്ടിക്കുക.

13. ആപ്പുകൾ അവലോകനം ചെയ്യുക

ആപ്പുകൾ അവലോകനം ചെയ്യുക വിന്യസിച്ചിരിക്കുന്ന പരിതസ്ഥിതിയിൽ വേഗത്തിൽ കാണുന്നതിന് ശേഖരത്തിലെ ഓരോ ഫയലിനും ഒരു ബട്ടൺ ചേർക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന ഒരു GitLab സവിശേഷതയാണിത്.

ഈ ബട്ടണുകൾ ദൃശ്യമാകുന്നതിന്, നിങ്ങൾ ഒരു ഫയൽ സൃഷ്ടിക്കേണ്ടതുണ്ട് .gitlab/route-map.yml അതിലെ എല്ലാ പാത്ത് പരിവർത്തനങ്ങളും വിവരിക്കുക; ഞങ്ങളുടെ കാര്യത്തിൽ ഇത് വളരെ ലളിതമായിരിക്കും:

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

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

ഞങ്ങളുടെ മാറ്റങ്ങൾ വരുത്താൻ മറക്കരുത്:

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

git push, കൂടാതെ പരിശോധിക്കുക:

റിവ്യൂ ആപ്പ് ബട്ടണിന്റെ സ്ക്രീൻഷോട്ട്

ജോലി കഴിഞ്ഞു!

പ്രോജക്റ്റ് ഉറവിടങ്ങൾ:

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

നിങ്ങളുടെ ശ്രദ്ധയ്ക്ക് നന്ദി, നിങ്ങൾക്കത് ഇഷ്ടപ്പെട്ടുവെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു

അവലംബം: www.habr.com