ഹായ്! ഡോക്കർ ഇമേജുകൾ നിർമ്മിക്കുന്നതിനും കുബേർനെറ്റസിലേക്ക് വിന്യസിക്കുന്നതിനുമായി നിരവധി മികച്ച ഓട്ടോമേഷൻ ഉപകരണങ്ങൾ അടുത്തിടെ പുറത്തിറക്കിയിട്ടുണ്ട്. അതിനാൽ, ഞാൻ GitLab-മായി കളിക്കാനും അതിന്റെ കഴിവുകൾ സമഗ്രമായി പര്യവേക്ഷണം ചെയ്യാനും തീർച്ചയായും ഒരു പൈപ്പ്‌ലൈൻ സ്ഥാപിക്കാനും തീരുമാനിച്ചു.

ഈ കൃതിയുടെ പ്രചോദനം വെബ്സൈറ്റ് ആയിരുന്നു kubernetes.io ആപ്പ്, ഇതിൽ നിന്ന് ജനറേറ്റ് ചെയ്യുന്നത് സോഴ്സ് കോഡുകൾ സ്വയമേവ, അയയ്ക്കുന്ന ഓരോ പുൾ അഭ്യർത്ഥനയ്ക്കും, റോബോട്ട് നിങ്ങളുടെ മാറ്റങ്ങളോടൊപ്പം സൈറ്റിന്റെ ഒരു പ്രിവ്യൂ പതിപ്പ് യാന്ത്രികമായി സൃഷ്ടിക്കുകയും കാണുന്നതിനായി ഒരു ലിങ്ക് നൽകുകയും ചെയ്യുന്നു.

സമാനമായ ഒരു പ്രക്രിയ ഞാൻ ആദ്യം മുതൽ നിർമ്മിക്കാൻ ശ്രമിച്ചു, പക്ഷേ പൂർണ്ണമായും Gitlab CI യിലും Kubernetes-ലേക്ക് ആപ്ലിക്കേഷനുകൾ വിന്യസിക്കാൻ ഞാൻ ഉപയോഗിക്കുന്ന ഓപ്പൺ സോഴ്‌സ് ഉപകരണങ്ങളിലും അധിഷ്ഠിതമായാണ് ഇത് നിർമ്മിച്ചിരിക്കുന്നത്. ഇന്ന്, അവയെക്കുറിച്ച് കൂടുതൽ വിശദമായി ഞാൻ നിങ്ങളോട് പറയും.

ലേഖനം ഇനിപ്പറയുന്നതുപോലുള്ള ഉപകരണങ്ങൾ ഉൾക്കൊള്ളും:
ഹ്യൂഗോ, qbec, കാണിക്കോ, git-crypt и ജിറ്റ്‌ലാബ് സി.ഐ ചലനാത്മകമായ പരിതസ്ഥിതികളുടെ സൃഷ്ടിയോടെ.

ഉള്ളടക്കം

1. ഹ്യൂഗോയെ അറിയുന്നു
2. ഡോക്കർ ഫയൽ തയ്യാറാക്കുന്നു
3. കണികയെ അറിയൽ
4. ക്യുബിഇസിയെ അറിയുക
5. കുബേർനെറ്റസ്-എക്സിക്യൂട്ടറുമായി ചേർന്ന് Gitlab-റണ്ണറെ പരീക്ഷിക്കുന്നു
6. qbec ഉപയോഗിച്ച് ഹെൽം ചാർട്ടുകൾ വിന്യസിക്കുന്നു
7. Git-Crypt ഉപയോഗിച്ച് ആരംഭിക്കുന്നു
8. ഒരു ടൂൾബോക്സ് ചിത്രം സൃഷ്ടിക്കുക
9. ടാഗുകൾ പ്രകാരം ഞങ്ങളുടെ ആദ്യത്തെ പൈപ്പ്‌ലൈനും ഇമേജ് അസംബ്ലിയും
10. വിന്യാസ ഓട്ടോമേഷൻ
11. പ്രാവീണ്യം നേടാൻ ശ്രമിക്കുമ്പോൾ പുരാവസ്തുക്കളും അസംബ്ലിയും
12. ചലനാത്മക പരിതസ്ഥിതികൾ
13. ആപ്പുകൾ അവലോകനം ചെയ്യുക

1. ഹ്യൂഗോയെ അറിയുക

ഞങ്ങളുടെ പ്രോജക്റ്റിന്റെ ഒരു ഉദാഹരണമായി, ഹ്യൂഗോയിൽ നിർമ്മിച്ച ഒരു ഡോക്യുമെന്റേഷൻ പബ്ലിഷിംഗ് വെബ്‌സൈറ്റ് ഞങ്ങൾ സൃഷ്ടിക്കും. ഹ്യൂഗോ ഒരു സ്റ്റാറ്റിക് കണ്ടന്റ് ജനറേറ്ററാണ്.

സ്റ്റാറ്റിക് ജനറേറ്ററുകളെ കുറിച്ച് പരിചയമില്ലാത്തവർക്കായി, ഞാൻ അവ കുറച്ചുകൂടി വിശദമായി വിശദീകരിക്കാം. ഡാറ്റാബേസും ചില PHP-യും ഉള്ള പരമ്പരാഗത വെബ്‌സൈറ്റ് എഞ്ചിനുകളിൽ നിന്ന് വ്യത്യസ്തമായി, ഉപയോക്താവിന്റെ അഭ്യർത്ഥന പ്രകാരം പെട്ടെന്ന് പേജുകൾ സൃഷ്ടിക്കുന്നവ, സ്റ്റാറ്റിക് ജനറേറ്ററുകൾ അല്പം വ്യത്യസ്തമായി രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്നു. സോഴ്‌സ് കോഡ്, സാധാരണയായി ഒരു കൂട്ടം മാർക്ക്ഡൗൺ ഫയലുകളും തീം ടെംപ്ലേറ്റുകളും എടുത്ത് പൂർണ്ണമായും പൂർത്തിയായ ഒരു വെബ്‌സൈറ്റിലേക്ക് കംപൈൽ ചെയ്യാൻ അവ നിങ്ങളെ അനുവദിക്കുന്നു.

ഇതിനർത്ഥം ഔട്ട്‌പുട്ട് ഒരു ഡയറക്‌ടറി ഘടനയും ജനറേറ്റുചെയ്‌ത HTML ഫയലുകളുടെ ഒരു കൂട്ടവുമായിരിക്കും, അത് നിങ്ങൾക്ക് വിലകുറഞ്ഞ ഒരു ഹോസ്റ്റിംഗ് സേവനത്തിലേക്ക് അപ്‌ലോഡ് ചെയ്‌ത് പ്രവർത്തിക്കുന്ന ഒരു വെബ്‌സൈറ്റ് സൃഷ്‌ടിക്കാൻ കഴിയും.

നിങ്ങൾക്ക് ഹ്യൂഗോ ലോക്കലായി ഇൻസ്റ്റാൾ ചെയ്ത് പരീക്ഷിച്ചുനോക്കാം:

ഒരു പുതിയ സൈറ്റ് ആരംഭിക്കുന്നു:

hugo new site docs.example.org

കൂടാതെ ഒരു ജിറ്റ് റിപ്പോസിറ്ററിയും:

cd docs.example.org
git init

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

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

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

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

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

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

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

ഈ ഘട്ടത്തിൽ തന്നെ നിങ്ങൾക്ക് സമാരംഭിക്കാൻ കഴിയും:

hugo server

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

ഒരു തലക്കെട്ട് പേജ് സൃഷ്ടിക്കാൻ ശ്രമിക്കാം ഉള്ളടക്കം/_ഇൻഡെക്സ്.എംഡി:

# 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

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

അപ്പോൾ നമ്മൾ നമ്മുടെ ആദ്യത്തെ ഡോക്കർ ഫയൽ പാതയിലൂടെ സൃഷ്ടിക്കും. ഡോക്കർഫയലുകൾ/വെബ്‌സൈറ്റ്/ഡോക്കർഫയൽ

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/വെബ്‌സൈറ്റ് — നിങ്ങളുടെ ഡോക്കർ ഇമേജിന്റെ പേര്; നിർമ്മിച്ചുകഴിഞ്ഞാൽ, അത് ഡോക്കർ രജിസ്ട്രിയിലേക്ക് യാന്ത്രികമായി ലോഞ്ച് ചെയ്യപ്പെടും.

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

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

4. ക്യുബിഇസിയെ അറിയുക

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

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

ഹെൽം ചാർട്ടുകൾക്ക് ആവശ്യമായ പാരാമീറ്ററുകൾ നൽകിക്കൊണ്ട് അവ റെൻഡർ ചെയ്യാനും, തുടർന്ന് അവയിൽ വിവിധ മ്യൂട്ടേഷനുകൾ പ്രയോഗിക്കുന്നത് ഉൾപ്പെടെ, പതിവ് മാനിഫെസ്റ്റുകൾ പോലെ അവയെ കൈകാര്യം ചെയ്യാനും Qbec നിങ്ങളെ അനുവദിക്കുന്നു. ഇത് ചാർട്ട് മ്യൂസിയത്തിന്റെ ആവശ്യകത ഇല്ലാതാക്കുന്നു. അതായത്, ചാർട്ടുകൾ ഉൾപ്പെടുന്ന Git-ൽ നിന്ന് നേരിട്ട് സംഭരിക്കാനും റെൻഡർ ചെയ്യാനും നിങ്ങൾക്ക് കഴിയും.

ഞാൻ മുമ്പ് പറഞ്ഞതുപോലെ, ഞങ്ങൾ എല്ലാ വിന്യാസങ്ങളും ഒരു ഡയറക്ടറിയിൽ സൂക്ഷിക്കും. വിന്യസിക്കുക/:

mkdir deploy
cd deploy

നമ്മുടെ ആദ്യ ആപ്ലിക്കേഷൻ ഇനിഷ്യലൈസ് ചെയ്യാം:

qbec init website
cd website

നിലവിൽ, ഞങ്ങളുടെ ആപ്ലിക്കേഷന്റെ ഘടന ഇതുപോലെയാണ് കാണപ്പെടുന്നത്:

.
├── components
├── environments
│   ├── base.libsonnet
│   └── default.libsonnet
├── params.libsonnet
└── qbec.yaml

നമുക്ക് ഫയൽ നോക്കാം. ക്യുബെക്.യാമൽ:

apiVersion: qbec.io/v1alpha1
kind: App
metadata:
  name: website
spec:
  environments:
    default:
      defaultNamespace: docs
      server: https://kubernetes.example.org:8443
  vars: {}

ഇവിടെ നമുക്ക് താൽപ്പര്യമുള്ളത് പ്രാഥമികമായി സ്പെക്.പരിസ്ഥിതികൾ, qbec നമുക്കായി ഒരു ഡിഫോൾട്ട് എൻവയോൺമെന്റ് സൃഷ്ടിച്ചു കഴിഞ്ഞു, കൂടാതെ നമ്മുടെ നിലവിലുള്ള kubeconfig-ൽ നിന്ന് സെർവർ വിലാസവും നെയിംസ്‌പെയ്‌സും എടുത്തു.
ഇപ്പോൾ വിന്യസിക്കുമ്പോൾ സ്ഥിരസ്ഥിതി environment-ൽ, qbec എല്ലായ്‌പ്പോഴും നിർദ്ദിഷ്ട Kubernetes ക്ലസ്റ്ററിലേക്കും നിർദ്ദിഷ്ട നെയിംസ്‌പെയ്‌സിലേക്കും മാത്രമേ വിന്യസിക്കൂ, അതായത് ഒരു വിന്യാസം നടത്താൻ നിങ്ങൾ ഇനി കോൺടെക്‌സ്റ്റുകൾക്കും നെയിംസ്‌പെയ്‌സുകൾക്കും ഇടയിൽ മാറേണ്ടതില്ല.
ആവശ്യമെങ്കിൽ, നിങ്ങൾക്ക് ഈ ഫയലിലെ ക്രമീകരണങ്ങൾ എല്ലായ്പ്പോഴും അപ്ഡേറ്റ് ചെയ്യാൻ കഴിയും.

നിങ്ങളുടെ എല്ലാ പരിതസ്ഥിതികളും ഇതിൽ വിവരിച്ചിരിക്കുന്നു ക്യുബെക്.യാമൽ, ഫയലിലും params.libsonnet - ക്ലൗഡിൽ ഓൺലൈനിൽ, അവയ്ക്കുള്ള പാരാമീറ്ററുകൾ എവിടെ നിന്ന് ലഭിക്കുമെന്ന് അതിൽ പറയുന്നു.

അടുത്തതായി നമ്മൾ രണ്ട് ഡയറക്ടറികൾ കാണുന്നു:

• ഘടകങ്ങൾ/ — ഞങ്ങളുടെ ആപ്ലിക്കേഷനായുള്ള എല്ലാ മാനിഫെസ്റ്റുകളും ഇവിടെ സൂക്ഷിക്കും; അവ jsonnet അല്ലെങ്കിൽ സാധാരണ yaml ഫയലുകളിൽ വിവരിക്കാം.
• പരിസ്ഥിതി/ — ഇവിടെ നമ്മുടെ പരിതസ്ഥിതികൾക്കായുള്ള എല്ലാ വേരിയബിളുകളും (പാരാമീറ്ററുകൾ) വിവരിക്കും.

സ്ഥിരസ്ഥിതിയായി നമുക്ക് രണ്ട് ഫയലുകൾ ഉണ്ട്:

• എൻവയോൺമെന്റുകൾ/base.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',
    },
  },
}

നമുക്ക് നമ്മുടെ ആദ്യത്തെ ഘടകം സൃഷ്ടിക്കാം. ഘടകങ്ങൾ/വെബ്‌സൈറ്റ്.ജെസോണെറ്റ്:

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

ഈ ഫയലിൽ, ഞങ്ങൾ ഒരേസമയം മൂന്ന് കുബേർനെറ്റ്സ് എന്റിറ്റികളെക്കുറിച്ച് വിവരിച്ചു: വിന്യാസ, സേവനം и തുടരുകനമുക്ക് വേണമെങ്കിൽ അവയെ വ്യത്യസ്ത ഘടകങ്ങളായി വേർതിരിക്കാം, എന്നാൽ ഈ ഘട്ടത്തിൽ ഒന്ന് മതിയാകും.

വാക്യഘടന ജെസോണെറ്റ് ഇത് സാധാരണ JSON-നോട് വളരെ സാമ്യമുള്ളതാണ്, വാസ്തവത്തിൽ, സാധാരണ JSON ഇതിനകം തന്നെ സാധുവായ ഒരു JSONnet ആണ്, അതിനാൽ ആദ്യം നിങ്ങൾക്ക് ഓൺലൈൻ സേവനങ്ങൾ ഉപയോഗിക്കുന്നത് എളുപ്പമായിരിക്കും, yaml2json (ആൻഡ്രോയിഡ്) നിങ്ങളുടെ സാധാരണ YAML-നെ JSON-ലേക്ക് പരിവർത്തനം ചെയ്യാൻ, അല്ലെങ്കിൽ, നിങ്ങളുടെ ഘടകങ്ങളിൽ വേരിയബിളുകളൊന്നും അടങ്ങിയിട്ടില്ലെങ്കിൽ, അവയെ സാധാരണ YAML എന്ന് വിശേഷിപ്പിക്കാം.

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

ഉദാഹരണത്തിന്, vim-ന് ഒരു പ്ലഗിൻ ഉണ്ട്. വിം-ജോണറ്റ്, ഇത് വാക്യഘടന ഹൈലൈറ്റിംഗ് പ്രാപ്തമാക്കുകയും യാന്ത്രികമായി പ്രവർത്തിക്കുകയും ചെയ്യുന്നു ജെസോണെറ്റ് എഫ്എംടി ഓരോ സേവിലും (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-ൽ ആഗോളതലത്തിൽ നിർവചിക്കപ്പെട്ട അത്തരം നിരവധി റണ്ണറുകൾ ഉണ്ടായിരുന്നു. എല്ലാ പ്രോജക്റ്റുകൾക്കുമായി അവർ ഡോക്കർ ഇമേജുകൾ നിർമ്മിച്ചു.

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

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

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

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

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

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

6. QBEC ഉപയോഗിച്ച് ഹെൽം ചാർട്ടുകൾ വിന്യസിക്കൽ

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

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

cd deploy
qbec init gitlab-runner
cd gitlab-runner

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

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

git submodule add https://gitlab.com/gitlab-org/charts/gitlab-runner vendor/gitlab-runner

ഇപ്പോൾ ഡയറക്ടറി വെണ്ടർ/ഗിറ്റ്ലാബ്-റണ്ണർ gitlab-runner-നുള്ള ഒരു ചാർട്ട് ഉള്ള ഒരു റിപ്പോസിറ്ററി അടങ്ങിയിരിക്കുന്നു.

നിങ്ങൾക്ക് മറ്റ് റിപ്പോസിറ്ററികളെയും സമാനമായ രീതിയിൽ ബന്ധിപ്പിക്കാൻ കഴിയും, ഉദാഹരണത്തിന് മുഴുവൻ റിപ്പോസിറ്ററിയും ഔദ്യോഗിക ചാർട്ടുകൾ ഉപയോഗിച്ച് ബന്ധിപ്പിക്കാം. https://github.com/helm/charts

നമുക്ക് ഘടകം വിവരിക്കാം ഘടകങ്ങൾ/gitlab-runner.jsonnet:

local env = {
  name: std.extVar('qbec.io/env'),
  namespace: std.extVar('qbec.io/defaultNs'),
};
local p = import '../params.libsonnet';
local params = p.components.gitlabRunner;

std.native('expandHelmTemplate')(
  '../vendor/gitlab-runner',
  params.values,
  {
    nameTemplate: params.name,
    namespace: env.namespace,
    thisFile: std.thisFile,
    verbose: true,
  }
)

ആദ്യ വാദം ഹെൽംടെംപ്ലേറ്റ് വികസിപ്പിക്കുക നമ്മൾ ചാർട്ടിലേക്കുള്ള പാതയിലൂടെ കടന്നുപോകുന്നു, തുടർന്ന് പാരാമുകൾ.മൂല്യങ്ങൾപരിസ്ഥിതി പാരാമീറ്ററുകളിൽ നിന്ന് നമ്മൾ എടുക്കുന്ന , തുടർന്ന് ഒബ്ജക്റ്റ് വരുന്നത്

• പേര്ടെംപ്ലേറ്റ് — റിലീസ് ശീർഷകം
• നെയിംസ്പേസ് — നെയിംസ്‌പെയ്‌സ് ഹെൽമിലേക്ക് കൈമാറി
• ഈ ഫയൽ — നിലവിലെ ഫയലിലേക്കുള്ള പാത കടന്നുപോകുന്ന ഒരു ആവശ്യമായ പാരാമീറ്റർ
• വെർബോസ് - കമാൻഡ് കാണിക്കുന്നു ഹെൽം ടെംപ്ലേറ്റ് ചാർട്ട് റെൻഡർ ചെയ്യുമ്പോൾ എല്ലാ ആർഗ്യുമെന്റുകളും ഉപയോഗിച്ച്

ഇനി നമ്മുടെ ഘടകത്തിന്റെ പാരാമീറ്ററുകൾ വിവരിക്കാം എൻവയോൺമെന്റുകൾ/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 വഴി ഇല്ലാതാക്കാം:

helm uninstall gitlab-runner

വീണ്ടും വിന്യസിക്കുക, പക്ഷേ qbec വഴി:

qbec apply default

7. git-crypt-ന്റെ ആമുഖം

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

ഇപ്പോൾ, gitlab-runner-നുള്ള ഞങ്ങളുടെ ഡയറക്ടറി ഘടന ഇതുപോലെയാണ് കാണപ്പെടുന്നത്:

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

പക്ഷേ Git-ൽ രഹസ്യങ്ങൾ സൂക്ഷിക്കുന്നത് സുരക്ഷിതമല്ല, അല്ലേ? അതിനാൽ നമ്മൾ അവ ശരിയായി എൻക്രിപ്റ്റ് ചെയ്യേണ്ടതുണ്ട്.

സാധാരണയായി, ഒരു വേരിയബിളിനു വേണ്ടി, അത് എല്ലായ്പ്പോഴും അർത്ഥവത്താകണമെന്നില്ല. നിങ്ങൾക്ക് രഹസ്യങ്ങൾ കൈമാറാൻ കഴിയും qbec നിങ്ങളുടെ CI സിസ്റ്റത്തിന്റെ പരിസ്ഥിതി വേരിയബിളുകളിലൂടെയും.
എന്നാൽ കൂടുതൽ രഹസ്യങ്ങൾ ഉൾക്കൊള്ളാൻ കഴിയുന്ന കൂടുതൽ സങ്കീർണ്ണമായ പ്രോജക്ടുകൾ ഉണ്ടെന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്; അവയെല്ലാം പരിസ്ഥിതി വേരിയബിളുകളിലൂടെ കടത്തിവിടുന്നത് വളരെ ബുദ്ധിമുട്ടായിരിക്കും.

കൂടാതെ, അങ്ങനെയെങ്കിൽ ഇത്രയും അത്ഭുതകരമായ ഒരു ഉപകരണത്തെക്കുറിച്ച് എനിക്ക് നിങ്ങളോട് പറയാൻ കഴിയില്ല git-crypt.

git-crypt ഇത് സൗകര്യപ്രദമാണ്, കാരണം ഇത് രഹസ്യങ്ങളുടെ മുഴുവൻ ചരിത്രവും സംരക്ഷിക്കാനും, Git-ൽ നമ്മൾ പതിവുള്ളതുപോലെ താരതമ്യം ചെയ്യാനും, ലയിപ്പിക്കാനും, സംഘർഷങ്ങൾ പരിഹരിക്കാനും നിങ്ങളെ അനുവദിക്കുന്നു.

ഇൻസ്റ്റാളേഷന് ശേഷം ആദ്യം ചെയ്യേണ്ടത് git-crypt നമ്മുടെ റിപ്പോസിറ്ററിക്ക് വേണ്ടി നമുക്ക് കീകൾ ജനറേറ്റ് ചെയ്യേണ്ടതുണ്ട്:

git crypt init

നിങ്ങൾക്ക് ഒരു PGP കീ ഉണ്ടെങ്കിൽ, ഈ പ്രോജക്റ്റിനായി നിങ്ങൾക്ക് ഉടൻ തന്നെ നിങ്ങളെ സഹകാരിയായി ചേർക്കാവുന്നതാണ്:

git-crypt add-gpg-user kvapss@gmail.com

ഈ രീതിയിൽ, നിങ്ങളുടെ സ്വകാര്യ കീ ഉപയോഗിച്ച് നിങ്ങൾക്ക് എല്ലായ്പ്പോഴും ഈ ശേഖരം ഡീക്രിപ്റ്റ് ചെയ്യാൻ കഴിയും.

നിങ്ങളുടെ കൈവശം ഒരു PGP കീ ഇല്ലെങ്കിലും പ്രതീക്ഷിക്കുന്നില്ലെങ്കിൽ, നിങ്ങൾക്ക് വ്യത്യസ്തമായ ഒരു സമീപനം സ്വീകരിച്ച് പ്രോജക്റ്റ് കീ കയറ്റുമതി ചെയ്യാൻ കഴിയും:

git crypt export-key /path/to/keyfile

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

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

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

നമ്മുടെ പ്രോജക്റ്റ് വിന്യസിക്കാൻ ഉപയോഗിക്കുന്ന എല്ലാ ഉപകരണങ്ങളും അടങ്ങിയ ഒരു ചിത്രമാണ് ടൂൾബോക്സ് ഇമേജ്. സാധാരണ വിന്യാസ ജോലികൾ ചെയ്യാൻ GitLabRunner ഇത് ഉപയോഗിക്കും.

ഇവിടെ എല്ലാം ലളിതമാണ്, നമുക്ക് പുതിയൊരെണ്ണം സൃഷ്ടിക്കാം. ഡോക്കർഫയലുകൾ/ടൂൾബോക്സ്/ഡോക്കർഫയൽ ഇനിപ്പറയുന്ന ഉള്ളടക്കത്തോടെ:

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

നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, ഈ ചിത്രത്തിൽ ഞങ്ങളുടെ ആപ്ലിക്കേഷൻ വിന്യസിക്കാൻ ഉപയോഗിച്ച എല്ലാ യൂട്ടിലിറ്റികളും ഞങ്ങൾ ഇൻസ്റ്റാൾ ചെയ്യുന്നു. ഇവിടെ ഞങ്ങൾക്ക് ഇനിപ്പറയുന്നവ ആവശ്യമില്ല: കുബെക്ലി, പക്ഷേ നിങ്ങളുടെ പൈപ്പ്‌ലൈൻ സജ്ജീകരിക്കുമ്പോൾ നിങ്ങൾ അത് ഉപയോഗിച്ച് കളിക്കാൻ ആഗ്രഹിച്ചേക്കാം.

കൂടാതെ, കുബേർനെറ്റസുമായി ആശയവിനിമയം നടത്താനും അതിലേക്ക് വിന്യസിക്കാനും കഴിയണമെങ്കിൽ, ഗിറ്റ്ലാബ്-റണ്ണർ സൃഷ്ടിക്കുന്ന പോഡുകൾക്കായി ഒരു റോൾ കോൺഫിഗർ ചെയ്യേണ്ടതുണ്ട്.

ഇത് ചെയ്യുന്നതിന്, 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 സൂചിപ്പിക്കുന്നു പേര് ഘടകത്തിന് ആർബിഎസി

എന്താണ് മാറിയതെന്ന് നമുക്ക് പരിശോധിക്കാം:

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 ടാഗുകളുമായി ലിങ്ക് ചെയ്യപ്പെടും. പുതിയ ടാഗ് ഉപയോഗിച്ചുള്ള ഓരോ പുഷും ആ ടാഗ് ഉപയോഗിച്ചുള്ള ഇമേജുകളുടെ ഒരു ബിൽഡിന് തുടക്കമിടും.

നമ്മളത് ചെയ്യും. ജിറ്റ് പുഷ് --ടാഗുകൾ, നമുക്ക് നമ്മുടെ ആദ്യത്തെ പൈപ്പ്‌ലൈൻ നോക്കാം:

ആദ്യത്തെ പൈപ്പ്ലൈനിന്റെ സ്ക്രീൻഷോട്ട്

ടാഗ് അധിഷ്ഠിത ബിൽഡുകൾ ഡോക്കർ ഇമേജുകൾ നിർമ്മിക്കുന്നതിന് അനുയോജ്യമാണ്, പക്ഷേ കുബേർനെറ്റസിലേക്ക് ആപ്ലിക്കേഷനുകൾ വിന്യസിക്കുന്നതിന് അനുയോജ്യമല്ല എന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്. പഴയ കമ്മിറ്റുകളിലേക്ക് പുതിയ ടാഗുകൾ നിയോഗിക്കാൻ കഴിയുന്നതിനാൽ, അവയ്‌ക്കായി പൈപ്പ്‌ലൈൻ ഇനീഷ്യലൈസ് ചെയ്യുന്നത് പഴയ പതിപ്പ് വിന്യസിക്കുന്നതിന് കാരണമാകും.

ഈ പ്രശ്നം പരിഹരിക്കുന്നതിന്, ഡോക്കർ ഇമേജ് ബിൽഡുകൾ സാധാരണയായി ടാഗുകളുമായി ലിങ്ക് ചെയ്തിരിക്കുന്നു, കൂടാതെ ആപ്ലിക്കേഷൻ വിന്യാസം ഒരു ബ്രാഞ്ചുമായി ലിങ്ക് ചെയ്തിരിക്കുന്നു. യജമാനന്, ഇതിൽ കംപൈൽ ചെയ്ത ചിത്രങ്ങളുടെ പതിപ്പുകൾ ഹാർഡ്‌കോഡ് ചെയ്തിരിക്കുന്നു. ഈ സാഹചര്യത്തിൽ, ഒരു ലളിതമായ റിവേർട്ട് ഉപയോഗിച്ച് നിങ്ങൾക്ക് റോൾബാക്ക് ആരംഭിക്കാൻ കഴിയും. യജമാനന്-ശാഖകൾ.

10. വിന്യാസത്തിന്റെ ഓട്ടോമേഷൻ

Gitlab-runner നമ്മുടെ രഹസ്യങ്ങൾ ഡീക്രിപ്റ്റ് ചെയ്യുന്നതിന്, നമ്മൾ repository കീ എക്സ്പോർട്ട് ചെയ്ത് നമ്മുടെ 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-നുള്ള നിരവധി പുതിയ ഓപ്ഷനുകൾ പ്രാപ്തമാക്കിയിട്ടുണ്ട്:

• —ഏതെങ്കിലും/ആപ്പ് റൂട്ട് ചെയ്യുക — ഒരു പ്രത്യേക ആപ്ലിക്കേഷന്റെ ഡയറക്ടറി നിർവചിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു.
• --ഫോഴ്‌സ്:k8s-സന്ദർഭം __ഇൻക്ലസ്റ്റർ__ — gtilab-runner പ്രവർത്തിക്കുന്ന അതേ ക്ലസ്റ്ററിലേക്ക് വിന്യാസം നടക്കുമെന്ന് വ്യക്തമാക്കുന്ന ഒരു മാജിക് വേരിയബിളാണിത്. ഇത് ആവശ്യമാണ്, അല്ലാത്തപക്ഷം qbec നിങ്ങളുടെ kubeconfig-ൽ അനുയോജ്യമായ ഒരു Kubernetes സെർവർ കണ്ടെത്താൻ ശ്രമിക്കും.
• —കാത്തിരിക്കുക — സൃഷ്ടിക്കുന്ന ഉറവിടങ്ങൾ റെഡി അവസ്ഥയിലേക്ക് പ്രവേശിക്കുന്നതുവരെ കാത്തിരിക്കാൻ 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"

ദയവായി ശ്രദ്ധിക്കുക, ഞങ്ങൾ ഒരു ശാഖ ചേർത്തിട്ടുണ്ട്. യജമാനന് к റഫറൻസുകൾ ജോലിക്ക് വേണ്ടി ബിൽഡ്_വെബ്‌സൈറ്റ് നമ്മൾ ഇപ്പോൾ ഉപയോഗിക്കുന്നത് $CI_COMMIT_REF_NAME പകരം $CI_COMMIT_TAG, അതായത് നമ്മൾ Git ടാഗുകളിൽ നിന്ന് വേർപിരിയുകയാണ്, പൈപ്പ്‌ലൈൻ ഇനീഷ്യലൈസ് ചെയ്ത കമ്മിറ്റിന്റെ ബ്രാഞ്ച് നാമമുള്ള ഒരു ഇമേജ് ഇപ്പോൾ പുഷ് ചെയ്യും. ഇത് ടാഗുകളിലും പ്രവർത്തിക്കുമെന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്, ഇത് ഡോക്കർ രജിസ്ട്രിയിൽ ഒരു പ്രത്യേക പതിപ്പുള്ള സൈറ്റ് സ്നാപ്പ്ഷോട്ടുകൾ സംരക്ഷിക്കാൻ ഞങ്ങളെ അനുവദിക്കുന്നു.

ഒരു സൈറ്റിന്റെ പുതിയ പതിപ്പിനുള്ള ഡോക്കർ ടാഗ് നാമത്തിൽ മാറ്റമുണ്ടാകില്ലെങ്കിലും, നമ്മൾ ഇപ്പോഴും മാറ്റങ്ങൾ കുബേർനെറ്റസിലേക്ക് വിവരിക്കേണ്ടതുണ്ട്, അല്ലാത്തപക്ഷം വിന്യാസ മാനിഫെസ്റ്റിൽ മാറ്റങ്ങളൊന്നും ശ്രദ്ധിക്കാത്തതിനാൽ പുതിയ ഇമേജിൽ നിന്ന് ആപ്ലിക്കേഷൻ വീണ്ടും വിന്യസിക്കില്ല.

ഓപ്ഷൻ —vm:ext-str ഡൈജസ്റ്റ്=”$DIGEST” qbec-നെ സംബന്ധിച്ചിടത്തോളം, jsonnet-ലേക്ക് ഒരു ബാഹ്യ വേരിയബിൾ കൈമാറാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു. ഓരോ റിലീസിലും ഞങ്ങളുടെ ആപ്ലിക്കേഷൻ ക്ലസ്റ്ററിലുടനീളം വീണ്ടും വിന്യസിക്കണമെന്ന് ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. ഒരു പ്രത്യേക ഇമേജ് പതിപ്പിലേക്ക് ലോക്ക് ചെയ്യുകയും അത് മാറുമ്പോൾ ഒരു വിന്യാസം ട്രിഗർ ചെയ്യുകയും ചെയ്യേണ്ടതിനാൽ, ഇപ്പോൾ മാറ്റാൻ കഴിയാത്ത ടാഗ് നാമം ഇവിടെ ഉപയോഗിക്കാൻ കഴിയില്ല.

ഇവിടെ, ഒരു ഡൈജസ്റ്റ് ഇമേജ് ഒരു ഫയലിലേക്ക് സേവ് ചെയ്യാനുള്ള കണിക്കോയുടെ കഴിവ് നമ്മെ സഹായിക്കും (ഓപ്ഷൻ —ഡൈജസ്റ്റ്-ഫയൽ)
തുടർന്ന് നമ്മൾ ഈ ഫയൽ ട്രാൻസ്ഫർ ചെയ്യുകയും വിന്യാസ സമയത്ത് അത് വായിക്കുകയും ചെയ്യും.

നമ്മുടെ പാരാമീറ്ററുകൾ അപ്ഡേറ്റ് ചെയ്യാം ഡിപ്ലോയ്/വെബ്‌സൈറ്റ്/എൻവയോൺമെന്റ്‌സ്/ബേസ്.ലിബ്‌സണെറ്റ് അത് ഇപ്പോൾ ഇതുപോലെ കാണപ്പെടും:

{
  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-runner വീണ്ടും വിന്യസിക്കേണ്ടതില്ല, തീർച്ചയായും, അതിന്റെ കോൺഫിഗറേഷനിൽ ഒന്നും മാറിയിട്ടില്ലെങ്കിൽ, നമുക്ക് ഇത് പരിഹരിക്കാം .gitlab-ci.yml:

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

മാറ്റങ്ങൾ മാറ്റങ്ങൾ നിരീക്ഷിക്കാൻ നിങ്ങളെ അനുവദിക്കും ഡിപ്ലോയ്/ജിറ്റ്ലാബ്-റണ്ണർ/ അങ്ങനെയുള്ളവ ഉണ്ടെങ്കിൽ മാത്രമേ ഞങ്ങളുടെ ജോലി ആരംഭിക്കുകയുള്ളൂ

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

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:
  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 സ്ഥിരസ്ഥിതി പ്രയോഗിക്കുക — നമ്മുടെ പരിതസ്ഥിതികൾക്കുള്ള വ്യത്യാസങ്ങൾ വിവരിക്കാൻ ശ്രമിക്കുന്ന നിമിഷം ഇതാണ് (അവലോകനവും സ്ഥിരസ്ഥിതിയും):

ചേർക്കാം അവലോകനം പരിസ്ഥിതി ഡിപ്ലോയ്/വെബ്‌സൈറ്റ്/qbec.yaml

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

പിന്നെ ഞങ്ങൾ അത് പ്രഖ്യാപിക്കും ഡിപ്ലോയ്/വെബ്‌സൈറ്റ്/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

അതിനായി നമ്മൾ ഇഷ്ടാനുസൃത പാരാമീറ്ററുകൾ എഴുതും ഡിപ്ലോയ്/വെബ്‌സൈറ്റ്/എൻവയോൺമെന്റ്‌സ്/റിവ്യൂ.ലിബ്‌സണെറ്റ്:

// 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 ചെക്ക്ഔട്ട് -b ടെസ്റ്റ്, ജിറ്റ് പുഷ് ഒറിജിൻ ടെസ്റ്റ്, ഞങ്ങൾ പരിശോധിക്കുന്നു:

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

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

പ്രോജക്റ്റിലെ ഏതൊരു ഡവലപ്പർക്കും ശാഖകൾ സൃഷ്ടിക്കാൻ കഴിയുമെന്ന് ഞാൻ ഇവിടെ വ്യക്തമാക്കാൻ ആഗ്രഹിക്കുന്നു, അയാൾക്ക് മാറാനും കഴിയും. .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