ProHoster > பிளாக் > நிர்வாகம் > டைனமிக் அசெம்பிளி மற்றும் வெர்ஃப் உடன் டோக்கர் படங்களின் வரிசைப்படுத்தல் ஒரு பதிப்பு ஆவண தளத்தின் உதாரணத்தைப் பயன்படுத்தி

டைனமிக் அசெம்பிளி மற்றும் வெர்ஃப் உடன் டோக்கர் படங்களின் வரிசைப்படுத்தல் ஒரு பதிப்பு ஆவண தளத்தின் உதாரணத்தைப் பயன்படுத்தி

நாங்கள் ஏற்கனவே எங்கள் GitOps கருவியைப் பற்றி ஒன்றுக்கு மேற்பட்ட முறை பேசியுள்ளோம். வெர்ஃப், மற்றும் இந்த நேரத்தில் திட்டத்தின் ஆவணங்களுடன் தளத்தை இணைப்பதில் எங்கள் அனுபவத்தைப் பகிர்ந்து கொள்ள விரும்புகிறோம் - werf.io (அதன் ரஷ்ய பதிப்பு en.werf.io) இது ஒரு சாதாரண நிலையான தளம், ஆனால் அதன் அசெம்பிளி சுவாரஸ்யமானது, இது ஒரு மாறும் எண்ணிக்கையிலான கலைப்பொருட்களைப் பயன்படுத்தி கட்டப்பட்டுள்ளது.

டைனமிக் அசெம்பிளி மற்றும் வெர்ஃப் உடன் டோக்கர் படங்களின் வரிசைப்படுத்தல் ஒரு பதிப்பு ஆவண தளத்தின் உதாரணத்தைப் பயன்படுத்தி

தள கட்டமைப்பின் நுணுக்கங்களுக்குச் செல்லவும்: அனைத்து பதிப்புகளுக்கும் பொதுவான மெனுவை உருவாக்குதல், வெளியீடுகள் பற்றிய தகவல்களைக் கொண்ட பக்கங்கள் போன்றவை. - நாங்கள் மாட்டோம். அதற்கு பதிலாக, டைனமிக் அசெம்பிளியின் சிக்கல்கள் மற்றும் அம்சங்கள் மற்றும் அதனுடன் இணைந்த CI/CD செயல்முறைகளில் சிறிது கவனம் செலுத்துவோம்.

அறிமுகம்: தளம் எவ்வாறு செயல்படுகிறது

தொடங்குவதற்கு, வெர்ஃப் ஆவணங்கள் அதன் குறியீட்டுடன் சேமிக்கப்படும். இது பொதுவாக இந்தக் கட்டுரையின் எல்லைக்கு அப்பாற்பட்ட சில மேம்பாட்டுத் தேவைகளை விதிக்கிறது, ஆனால் குறைந்தபட்சம் இதைக் கூறலாம்:

  • புதிய வெர்ஃப் செயல்பாடுகள் ஆவணங்களைப் புதுப்பிக்காமல் வெளியிடப்படக்கூடாது, மாறாக, ஆவணத்தில் ஏதேனும் மாற்றங்கள் இருந்தால் வெர்ஃப் இன் புதிய பதிப்பின் வெளியீட்டைக் குறிக்கிறது;
  • திட்டம் மிகவும் தீவிரமான வளர்ச்சியைக் கொண்டுள்ளது: புதிய பதிப்புகள் ஒரு நாளைக்கு பல முறை வெளியிடப்படலாம்;
  • ஆவணத்தின் புதிய பதிப்புடன் தளத்தை வரிசைப்படுத்துவதற்கான எந்தவொரு கையேடு செயல்பாடுகளும் குறைந்தபட்சம் கடினமானவை;
  • திட்டம் ஒரு சொற்பொருள் அணுகுமுறையை ஏற்றுக்கொள்கிறது பதிப்பு5 நிலைத்தன்மை சேனல்களுடன். வெளியீட்டு செயல்முறையானது நிலைத்தன்மையை அதிகரிக்கும் பொருட்டு சேனல்கள் மூலம் பதிப்புகளை வரிசையாக அனுப்புவதை உள்ளடக்கியது: ஆல்பாவிலிருந்து ராக்-சாலிட் வரை;
  • தளத்தில் ரஷ்ய மொழி பதிப்பு உள்ளது, இது முக்கிய (அதாவது ஆங்கில மொழி) பதிப்பிற்கு இணையாக "வாழ்கிறது மற்றும் வளர்கிறது" (அதாவது, புதுப்பிக்கப்பட்ட உள்ளடக்கம்).

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

இணையதளத்தில் உள்ள பதிப்புத் தேர்வு மெனுவில், ஒவ்வொரு சேனலிலும் werf இன் சமீபத்திய பதிப்புகள் கிடைக்கும். இயல்பாக, முகவரி மூலம் werf.io/documentation சமீபத்திய வெளியீட்டிற்கான மிகவும் நிலையான சேனலின் பதிப்பு திறக்கிறது - இது தேடுபொறிகளால் குறியிடப்படுகிறது. சேனலுக்கான ஆவணங்கள் தனித்தனி முகவரிகளில் கிடைக்கும் (எடுத்துக்காட்டாக, werf.io/v1.0-beta/documentation பீட்டா வெளியீடு 1.0).

மொத்தத்தில், தளத்தில் பின்வரும் பதிப்புகள் உள்ளன:

  1. ரூட் (இயல்புநிலையாக திறக்கும்),
  2. ஒவ்வொரு வெளியீட்டின் ஒவ்வொரு செயலில் உள்ள புதுப்பிப்பு சேனலுக்கும் (எடுத்துக்காட்டாக, werf.io/v1.0-beta).

ஒரு தளத்தின் குறிப்பிட்ட பதிப்பை உருவாக்க, பொதுவாக, அதைப் பயன்படுத்தி தொகுத்தால் போதும் ஜெகில்கோப்பகத்தில் இயங்குவதன் மூலம் /docs werf களஞ்சியத்துடன் தொடர்புடைய கட்டளை (jekyll build), தேவையான பதிப்பின் Git குறிச்சொல்லுக்கு மாறிய பிறகு.

அதைச் சேர்ப்பது மட்டுமே உள்ளது:

  • பயன்பாடு (வேர்ஃப்) சட்டசபைக்கு பயன்படுத்தப்படுகிறது;
  • CI/CD செயல்முறைகள் GitLab CI இன் அடிப்படையில் கட்டமைக்கப்படுகின்றன;
  • மற்றும் இவை அனைத்தும், நிச்சயமாக, குபெர்னெட்டஸில் இயங்குகின்றன.

பணிகளை

இப்போது விவரிக்கப்பட்ட அனைத்து விவரங்களையும் கணக்கில் எடுத்துக் கொள்ளும் பணிகளை உருவாக்குவோம்:

  1. எந்த புதுப்பிப்பு சேனலிலும் வெர்ஃப் பதிப்பை மாற்றிய பிறகு தளத்தில் உள்ள ஆவணங்கள் தானாகவே புதுப்பிக்கப்பட வேண்டும்.
  2. வளர்ச்சிக்கு நீங்கள் சில நேரங்களில் முடியும் தளத்தின் முன்னோட்ட பதிப்புகளைப் பார்க்கவும்.

தொடர்புடைய Git குறிச்சொற்களிலிருந்து எந்த சேனலிலும் பதிப்பை மாற்றிய பின் தளம் மீண்டும் தொகுக்கப்பட வேண்டும், ஆனால் படத்தை உருவாக்கும் செயல்பாட்டில் பின்வரும் அம்சங்களைப் பெறுவோம்:

  • சேனல்களில் உள்ள பதிப்புகளின் பட்டியல் மாறுவதால், பதிப்பு மாறிய சேனல்களுக்கான ஆவணங்களை மீண்டும் உருவாக்குவது மட்டுமே அவசியம். எல்லாவற்றிற்கும் மேலாக, எல்லாவற்றையும் மீண்டும் உருவாக்குவது மிகவும் நன்றாக இல்லை.
  • வெளியீடுகளுக்கான சேனல்களின் தொகுப்பு மாறலாம். ஒரு கட்டத்தில், எடுத்துக்காட்டாக, முந்தைய அணுகல் 1.1 வெளியீட்டை விட நிலையான பதிப்பு சேனல்களில் இருக்காது, ஆனால் காலப்போக்கில் அவை தோன்றும் - இந்த விஷயத்தில், நீங்கள் சட்டசபையை கைமுறையாக மாற்ற வேண்டாமா?

அது மாறிவிடும் சட்டசபை வெளிப்புறத் தரவை மாற்றுவதைப் பொறுத்தது.

Реализация

ஒரு அணுகுமுறையைத் தேர்ந்தெடுப்பது

மாற்றாக, குபெர்னெட்டஸில் தேவையான ஒவ்வொரு பதிப்பையும் தனித்தனியாக இயக்கலாம். இந்த விருப்பம் கிளஸ்டரில் அதிக எண்ணிக்கையிலான பொருட்களைக் குறிக்கிறது, இது நிலையான வெர்ஃப் வெளியீடுகளின் எண்ணிக்கையின் அதிகரிப்புடன் வளரும். மேலும் இது மிகவும் சிக்கலான பராமரிப்பைக் குறிக்கிறது: ஒவ்வொரு பதிப்பிற்கும் அதன் சொந்த HTTP சேவையகம் உள்ளது, மேலும் ஒரு சிறிய சுமை உள்ளது. நிச்சயமாக, இது அதிக வள செலவுகளை ஏற்படுத்துகிறது.

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

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

werf vs git குளோன் மற்றும் கலைப்பொருட்கள்

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

இங்கே வெர்ஃப் பயன்பாடு தானே நம் உதவிக்கு வருகிறது, செயல்படுத்துகிறது ஸ்மார்ட் கேச்சிங் மற்றும் நீங்கள் பயன்படுத்த அனுமதிக்கிறது வெளிப்புற களஞ்சியங்கள். களஞ்சியத்திலிருந்து குறியீட்டைச் சேர்க்க werf ஐப் பயன்படுத்துவது, உருவாக்கத்தை கணிசமாக துரிதப்படுத்தும், ஏனெனில் werf அடிப்படையில் களஞ்சியத்தை ஒரு முறை குளோன் செய்து பின்னர் இயக்குகிறது மட்டுமே fetch அவசியமென்றால். கூடுதலாக, களஞ்சியத்திலிருந்து தரவைச் சேர்க்கும்போது, ​​தேவையான கோப்பகங்களை மட்டுமே தேர்ந்தெடுக்க முடியும் (எங்கள் விஷயத்தில் இது அடைவு docs), இது சேர்க்கப்பட்ட தரவுகளின் அளவைக் கணிசமாகக் குறைக்கும்.

ஜெகில் நிலையான தரவை தொகுக்க வடிவமைக்கப்பட்ட ஒரு கருவி மற்றும் இறுதி படத்தில் தேவையில்லை என்பதால், தொகுக்க தர்க்கரீதியானதாக இருக்கும். வெர்ஃப் கலைப்பொருள், மற்றும் இறுதிப் படத்தில் தொகுக்கப்பட்ட முடிவை மட்டும் இறக்குமதி செய்யவும்.

நாங்கள் werf.yaml என்று எழுதுகிறோம்

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

werf நீங்கள் பயன்படுத்த அனுமதிக்கிறது வார்ப்புருக்களுக்குச் செல்லவும் உங்கள் கட்டமைப்பு கோப்பில் (werf.yaml), இது சாத்தியமாக்குகிறது பறக்கும்போது கட்டமைப்பை உருவாக்கவும் வெளிப்புறத் தரவைப் பொறுத்து (உங்களுக்கு என்ன தேவை!). எங்கள் விஷயத்தில் வெளிப்புற தரவு என்பது பதிப்புகள் மற்றும் வெளியீடுகள் பற்றிய தகவலாகும், அதன் அடிப்படையில் தேவையான எண்ணிக்கையிலான கலைப்பொருட்களை நாங்கள் சேகரிக்கிறோம், இதன் விளைவாக இரண்டு படங்களைப் பெறுகிறோம்: werf-doc и werf-dev வெவ்வேறு சுற்றுகளில் இயக்க.

வெளிப்புற தரவு சுற்றுச்சூழல் மாறிகள் மூலம் அனுப்பப்படுகிறது. அவற்றின் கலவை இங்கே:

  • RELEASES - வெளியீட்டுகளின் பட்டியல் மற்றும் அதனுடன் தொடர்புடைய தற்போதைய வெர்ஃப் பதிப்பு, வடிவத்தில் இடம் பிரிக்கப்பட்ட மதிப்புகளின் பட்டியலின் வடிவத்தில் ஒரு வரி <НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>. ஒரு எடுத்துக்காட்டு: 1.0%v1.0.4-beta.20
  • CHANNELS - சேனல்களின் பட்டியலைக் கொண்ட ஒரு வரி மற்றும் அதனுடன் தொடர்புடைய தற்போதைய வெர்ஃப் பதிப்பு, வடிவத்தில் உள்ள இடத்தால் பிரிக்கப்பட்ட மதிப்புகளின் பட்டியலின் வடிவத்தில் <КАНАЛ>%<НОМЕР_ВЕРСИИ>. ஒரு எடுத்துக்காட்டு: 1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22
  • ROOT_VERSION — werf வெளியீட்டு பதிப்பு இயல்பாகவே தளத்தில் காட்டப்படும் (அதிக வெளியீட்டு எண்ணின் மூலம் ஆவணங்களை எப்போதும் காட்ட வேண்டிய அவசியமில்லை). உதாரணமாக: v1.0.4-beta.20
  • REVIEW_SHA - சோதனை வளையத்திற்கான பதிப்பை நீங்கள் உருவாக்க வேண்டிய மதிப்பாய்வு கமிட்டின் ஹாஷ்.

இந்த மாறிகள் GitLab CI பைப்லைனில் நிரப்பப்படும், மேலும் எப்படி சரியாக கீழே எழுதப்பட்டுள்ளது.

முதலில், வசதிக்காக, நாங்கள் வரையறுக்கிறோம் werf.yaml டெம்ப்ளேட் மாறிகளுக்குச் செல்லவும், சூழல் மாறிகளிலிருந்து அவற்றின் மதிப்புகளை ஒதுக்கவும்:

{{ $_ := set . "WerfVersions" (cat (env "CHANNELS") (env "RELEASES") | splitList " ") }}
{{ $Root := . }}
{{ $_ := set . "WerfRootVersion" (env "ROOT_VERSION") }}
{{ $_ := set . "WerfReviewCommit" (env "REVIEW_SHA") }}

தளத்தின் நிலையான பதிப்பைத் தொகுப்பதற்கான கலைப்பொருளின் விளக்கம் பொதுவாக நமக்குத் தேவைப்படும் எல்லா நிகழ்வுகளுக்கும் ஒரே மாதிரியாக இருக்கும் (ரூட் பதிப்பை உருவாக்குவதும், டெவ் சர்க்யூட்டின் பதிப்பும் உட்பட). எனவே, செயல்பாட்டைப் பயன்படுத்தி அதை ஒரு தனி தொகுதிக்கு நகர்த்துவோம் define - அடுத்தடுத்த மறுபயன்பாட்டிற்கு include. பின்வரும் வாதங்களை டெம்ப்ளேட்டிற்கு அனுப்புவோம்:

  • Version - உருவாக்கப்பட்ட பதிப்பு (குறிச்சொல் பெயர்);
  • Channel - கலைப்பொருள் உருவாக்கப்படும் புதுப்பிப்பு சேனலின் பெயர்;
  • Commit - கமிட் ஹாஷ், கலைப்பொருள் மறுஆய்வு உறுதிக்காக உருவாக்கப்பட்டால்;
  • சூழல்.

கலைப்பொருள் டெம்ப்ளேட் விளக்கம்

{{- define "doc_artifact" -}}
{{- $Root := index . "Root" -}}
artifact: doc-{{ .Channel }}
from: jekyll/builder:3
mount:
- from: build_dir
  to: /usr/local/bundle
ansible:
  install:
  - shell: |
      export PATH=/usr/jekyll/bin/:$PATH
  - name: "Install Dependencies"
    shell: bundle install
    args:
      executable: /bin/bash
      chdir: /app/docs
  beforeSetup:
{{- if .Commit }}
  - shell: echo "Review SHA - {{ .Commit }}."
{{- end }}
{{- if eq .Channel "root" }}
  - name: "releases.yml HASH: {{ $Root.Files.Get "releases.yml" | sha256sum }}"
    copy:
      content: |
{{ $Root.Files.Get "releases.yml" | indent 8 }}
      dest:  /app/docs/_data/releases.yml
{{- else }}
  - file:
      path: /app/docs/_data/releases.yml
      state: touch
{{- end }}
  - file:
      path: "{{`{{ item }}`}}"
      state: directory
      mode: 0777
    with_items:
    - /app/main_site/
    - /app/ru_site/
  - file:
      dest: /app/docs/pages_ru/cli
      state: link
      src: /app/docs/pages/cli
  - shell: |
      echo -e "werfVersion: {{ .Version }}nwerfChannel: {{ .Channel }}" > /tmp/_config_additional.yml
      export PATH=/usr/jekyll/bin/:$PATH
{{- if and (ne .Version "review") (ne .Channel "root") }}
{{- $_ := set . "BaseURL" ( printf "v%s" .Channel ) }}
{{- else if ne .Channel "root" }}
{{- $_ := set . "BaseURL" .Channel }}
{{- end }}
      jekyll build -s /app/docs  -d /app/_main_site/{{ if .BaseURL }} --baseurl /{{ .BaseURL }}{{ end }} --config /app/docs/_config.yml,/tmp/_config_additional.yml
      jekyll build -s /app/docs  -d /app/_ru_site/{{ if .BaseURL }} --baseurl /{{ .BaseURL }}{{ end }} --config /app/docs/_config.yml,/app/docs/_config_ru.yml,/tmp/_config_additional.yml
    args:
      executable: /bin/bash
      chdir: /app/docs
git:
- url: https://github.com/flant/werf.git
  to: /app/
  owner: jekyll
  group: jekyll
{{- if .Commit }}
  commit: {{ .Commit }}
{{- else }}
  tag: {{ .Version }}
{{- end }}
  stageDependencies:
    install: ['docs/Gemfile','docs/Gemfile.lock']
    beforeSetup: '**/*'
  includePaths: 'docs'
  excludePaths: '**/*.sh'
{{- end }}

கலைப்பொருளின் பெயர் தனிப்பட்டதாக இருக்க வேண்டும். எடுத்துக்காட்டாக, சேனல் பெயரைச் சேர்ப்பதன் மூலம் இதை நாம் அடையலாம் (மாறியின் மதிப்பு .Channel) கலைப்பொருளின் பெயரின் பின்னொட்டாக: artifact: doc-{{ .Channel }}. ஆனால் கலைப்பொருட்களிலிருந்து இறக்குமதி செய்யும் போது, ​​நீங்கள் அதே பெயர்களைக் குறிப்பிட வேண்டும் என்பதை நீங்கள் புரிந்து கொள்ள வேண்டும்.

ஒரு கலைப்பொருளை விவரிக்கும் போது, ​​பின்வரும் வெர்ஃப் அம்சம் பயன்படுத்தப்படுகிறது: பெருகிவரும். சேவை கோப்பகத்தைக் குறிக்கும் ஏற்றம் build_dir பைப்லைன் ரன்களுக்கு இடையில் ஜெகில் கேச் சேமிக்க உங்களை அனுமதிக்கிறது கணிசமாக மறுசீரமைப்பை துரிதப்படுத்துகிறது.

கோப்பைப் பயன்படுத்துவதையும் நீங்கள் கவனித்திருக்கலாம் releases.yml YAML கோப்பாகும், வெளியீட்டுத் தரவு கோரப்பட்டது github.com (ஒரு பைப்லைனை இயக்கும் போது பெறப்பட்ட ஒரு கலைப்பொருள்). தளத்தைத் தொகுக்கும்போது இது தேவைப்படுகிறது, ஆனால் கட்டுரையின் சூழலில் அது எங்களுக்கு சுவாரஸ்யமானது, ஏனெனில் அது அதன் நிலையைப் பொறுத்தது ஒரே ஒரு கலைப்பொருளின் மறுசீரமைப்பு - தளத்தின் ரூட் பதிப்பின் ஒரு கலைப்பொருள் (பிற கலைப்பொருட்களில் இது தேவையில்லை).

நிபந்தனை அறிக்கையைப் பயன்படுத்தி இது செயல்படுத்தப்படுகிறது if வார்ப்புருக்கள் மற்றும் வடிவமைப்புகளுக்குச் செல்லவும் {{ $Root.Files.Get "releases.yml" | sha256sum }} கட்டத்தில் நிலைகள். இது பின்வருமாறு செயல்படுகிறது: ரூட் பதிப்பிற்கான ஒரு கலைப்பொருளை உருவாக்கும்போது (மாறி .Channel சமம் root) கோப்பு ஹாஷ் releases.yml முழு கட்டத்தின் கையொப்பத்தையும் பாதிக்கிறது, ஏனெனில் இது அன்சிபிள் பணியின் பெயரின் ஒரு பகுதியாகும் (அளவுரு name) இவ்வாறு, மாறும் போது உள்ளடக்கம் கோப்பு releases.yml தொடர்புடைய கலைப்பொருள் மீண்டும் இணைக்கப்படும்.

வெளிப்புற களஞ்சியத்துடன் வேலை செய்வதிலும் கவனம் செலுத்தவும். ஒரு கலைப்பொருளின் படத்தில் werf களஞ்சியம், அடைவு மட்டும் சேர்க்கப்பட்டது /docs, மற்றும் அனுப்பப்பட்ட அளவுருக்களைப் பொறுத்து, தேவையான டேக் அல்லது மறுஆய்வு உறுதிப்பாட்டின் தரவு உடனடியாக சேர்க்கப்படும்.

சேனல்கள் மற்றும் வெளியீடுகளின் மாற்றப்பட்ட பதிப்புகளின் கலைப்பொருளின் விளக்கத்தை உருவாக்க கலைப்பொருள் டெம்ப்ளேட்டைப் பயன்படுத்த, மாறியில் ஒரு வளையத்தை ஒழுங்கமைக்கிறோம் .WerfVersions в werf.yaml:

{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ dict "Version" $VersionsDict._1 "Channel" $VersionsDict._0 "Root" $Root | include "doc_artifact" }}
---
{{ end -}}

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

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

{{ dict "Version" .WerfRootVersion "Channel" "root" "Root" $Root  | include "doc_artifact" }}
---
{{- if .WerfReviewCommit }}
{{ dict "Version" "review" "Channel" "review" "Commit" .WerfReviewCommit "Root" $Root  | include "doc_artifact" }}
{{- end }}

மதிப்பாய்வு உறுதிப்பாட்டிற்கான கலைப்பொருள் மாறி அமைக்கப்பட்டால் மட்டுமே உருவாக்கப்படும் என்பதை நினைவில் கொள்ளவும் .WerfReviewCommit.

கலைப்பொருட்கள் தயாராக உள்ளன - இறக்குமதியைத் தொடங்குவதற்கான நேரம் இது!

இறுதிப் படம், குபெர்னெட்டஸில் இயங்க வடிவமைக்கப்பட்டுள்ளது, இது சர்வர் உள்ளமைவு கோப்பு சேர்க்கப்பட்டுள்ள வழக்கமான NGINX ஆகும். nginx.conf மற்றும் கலைப்பொருட்களிலிருந்து நிலையானது. தளத்தின் ரூட் பதிப்பின் கலைப்பொருளுக்கு கூடுதலாக, மாறியில் சுழற்சியை மீண்டும் செய்ய வேண்டும் .WerfVersions சேனலின் கலைப்பொருட்களை இறக்குமதி செய்வதற்கும் பதிப்புகளை வெளியிடுவதற்கும் + நாங்கள் முன்பு ஏற்றுக்கொண்ட கலைப்பொருள் பெயரிடும் விதியைப் பின்பற்றவும். ஒவ்வொரு கலைப்பொருளும் இரண்டு மொழிகளுக்கான தளத்தின் பதிப்புகளைச் சேமித்து வைப்பதால், உள்ளமைவு வழங்கிய இடங்களில் அவற்றை இறக்குமதி செய்கிறோம்.

இறுதிப் படத்தின் விளக்கம் werf-doc

image: werf-doc
from: nginx:stable-alpine
ansible:
  setup:
  - name: "Setup /etc/nginx/nginx.conf"
    copy:
      content: |
{{ .Files.Get ".werf/nginx.conf" | indent 8 }}
      dest: /etc/nginx/nginx.conf
  - file:
      path: "{{`{{ item }}`}}"
      state: directory
      mode: 0777
    with_items:
    - /app/main_site/assets
    - /app/ru_site/assets
import:
- artifact: doc-root
  add: /app/_main_site
  to: /app/main_site
  before: setup
- artifact: doc-root
  add: /app/_ru_site
  to: /app/ru_site
  before: setup
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ $Channel := $VersionsDict._0 -}}
{{ $Version := $VersionsDict._1 -}}
- artifact: doc-{{ $Channel }}
  add: /app/_main_site
  to: /app/main_site/v{{ $Channel }}
  before: setup
{{ end -}}
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ $Channel := $VersionsDict._0 -}}
{{ $Version := $VersionsDict._1 -}}
- artifact: doc-{{ $Channel }}
  add: /app/_ru_site
  to: /app/ru_site/v{{ $Channel }}
  before: setup
{{ end -}}

முக்கிய படத்துடன் சேர்ந்து, டெவ் சர்க்யூட்டில் தொடங்கப்பட்ட கூடுதல் படம், தளத்தின் இரண்டு பதிப்புகளை மட்டுமே கொண்டுள்ளது: மறுஆய்வு கமிட்டின் பதிப்பு மற்றும் தளத்தின் ரூட் பதிப்பு (பொது சொத்துக்கள் உள்ளன மற்றும் நீங்கள் நினைவில் வைத்திருந்தால் , வெளியீடு தரவு). எனவே, கூடுதல் படம் முக்கிய படத்திலிருந்து இறக்குமதி பிரிவில் மட்டுமே வேறுபடும் (மற்றும், நிச்சயமாக, பெயரில்):

image: werf-dev
...
import:
- artifact: doc-root
  add: /app/_main_site
  to: /app/main_site
  before: setup
- artifact: doc-root
  add: /app/_ru_site
  to: /app/ru_site
  before: setup
{{- if .WerfReviewCommit  }}
- artifact: doc-review
  add: /app/_main_site
  to: /app/main_site/review
  before: setup
- artifact: doc-review
  add: /app/_ru_site
  to: /app/ru_site/review
  before: setup
{{- end }}

மேலே குறிப்பிட்டுள்ளபடி, செட் சூழல் மாறி இயக்கப்படும் போது மட்டுமே மதிப்பாய்வு உறுதிப்பாட்டிற்கான கலைப்பொருள் உருவாக்கப்படும் REVIEW_SHA. சூழல் மாறி இல்லை என்றால் werf-dev படத்தை உருவாக்காமல் இருக்க முடியும் REVIEW_SHA, ஆனால் பொருட்டு கொள்கைகள் மூலம் சுத்தம் werf-ல் உள்ள டோக்கர் படங்கள் werf-dev படத்திற்காக வேலை செய்தன, பைப்லைன் கட்டமைப்பை எளிமைப்படுத்த ரூட் பதிப்பு கலைப்பொருளுடன் (எப்படியும் ஏற்கனவே கட்டப்பட்டுள்ளது) அதை உருவாக்க விடுவோம்.

சட்டசபை தயாராக உள்ளது! CI/CD மற்றும் முக்கியமான நுணுக்கங்களுக்கு செல்லலாம்.

GitLab CI இல் பைப்லைன் மற்றும் டைனமிக் கட்டமைப்பின் அம்சங்கள்

கட்டமைப்பை இயக்கும் போது, ​​பயன்படுத்தப்படும் சூழல் மாறிகளை அமைக்க வேண்டும் werf.yaml. இது REVIEW_SHA மாறிக்கு பொருந்தாது, GitHub ஹூக்கிலிருந்து பைப்லைனை அழைக்கும் போது நாம் அமைப்போம்.

பாஷ் ஸ்கிரிப்ட்டில் தேவையான வெளிப்புறத் தரவை உருவாக்குவோம் generate_artifacts, இது இரண்டு GitLab பைப்லைன் கலைப்பொருட்களை உருவாக்கும்:

  • файл releases.yml வெளியீட்டுத் தரவுகளுடன்,
  • файл common_envs.sh, ஏற்றுமதி செய்வதற்கான சூழல் மாறிகளைக் கொண்டுள்ளது.

கோப்பு உள்ளடக்கங்கள் generate_artifacts நீங்கள் எங்களில் காணலாம் எடுத்துக்காட்டுகளுடன் களஞ்சியங்கள். தரவைப் பெறுவது கட்டுரையின் பொருள் அல்ல, ஆனால் கோப்பு common_envs.sh நமக்கு முக்கியமானது, ஏனென்றால் வெர்ஃப் வேலை அதைப் பொறுத்தது. அதன் உள்ளடக்கத்தின் எடுத்துக்காட்டு:

export RELEASES='1.0%v1.0.6-4'
export CHANNELS='1.0-alpha%v1.0.7-1 1.0-beta%v1.0.7-1 1.0-ea%v1.0.6-4 1.0-stable%v1.0.6-4 1.0-rock-solid%v1.0.6-4'
export ROOT_VERSION='v1.0.6-4'

அத்தகைய ஸ்கிரிப்ட்டின் வெளியீட்டை நீங்கள் பயன்படுத்தலாம், எடுத்துக்காட்டாக, பாஷ் செயல்பாட்டைப் பயன்படுத்தி source.

இப்போது வேடிக்கையான பகுதி வருகிறது. பயன்பாட்டின் உருவாக்கம் மற்றும் வரிசைப்படுத்தல் இரண்டும் சரியாக வேலை செய்ய, அதை உறுதி செய்வது அவசியம் werf.yaml அது இருந்தது அதே குறைந்தது ஒரு குழாய்க்குள். இந்த நிபந்தனை பூர்த்தி செய்யப்படாவிட்டால், சட்டசபையின் போது வெர்ஃப் கணக்கிடும் நிலைகளின் கையொப்பங்கள் மற்றும் எடுத்துக்காட்டாக, வரிசைப்படுத்தல் வேறுபட்டதாக இருக்கும். இது வரிசைப்படுத்தல் பிழைக்கு வழிவகுக்கும், ஏனெனில்... வரிசைப்படுத்துவதற்குத் தேவையான படம் விடுபட்டிருக்கும்.

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

தலைமுறை என்றால் werf.yaml வெளிப்புறத் தரவைப் பொறுத்தது (எடுத்துக்காட்டாக, தற்போதைய பதிப்புகளின் பட்டியல், எங்கள் விஷயத்தில் உள்ளது), பின்னர் அத்தகைய தரவின் கலவை மற்றும் மதிப்புகள் குழாய்க்குள் பதிவு செய்யப்பட வேண்டும். வெளிப்புற அளவுருக்கள் அடிக்கடி மாறினால் இது மிகவும் முக்கியமானது.

நாங்கள் செய்வோம் வெளிப்புற தரவைப் பெறுதல் மற்றும் பதிவு செய்தல் GitLab இல் குழாய்த்திட்டத்தின் முதல் கட்டத்தில் (முன்கட்டமைக்கவும்) மற்றும் படிவத்தில் அவற்றை மேலும் அனுப்பவும் GitLab CI கலைப்பொருள். இது அதே உள்ளமைவுடன் பைப்லைன் வேலைகளை (கட்டமைத்தல், வரிசைப்படுத்துதல், சுத்தம் செய்தல்) இயக்க மற்றும் மறுதொடக்கம் செய்ய உங்களை அனுமதிக்கும். werf.yaml.

மேடையின் உள்ளடக்கம் முன்கட்டமைக்கவும் கோப்பு .gitlab-ci.yml:

Prebuild:
  stage: prebuild
  script:
    - bash ./generate_artifacts 1> common_envs.sh
    - cat ./common_envs.sh
  artifacts:
    paths:
      - releases.yml
      - common_envs.sh
    expire_in: 2 week

கலைப்பொருளில் வெளிப்புறத் தரவைப் படம்பிடித்த பிறகு, நிலையான GitLab CI பைப்லைன் நிலைகளைப் பயன்படுத்தி உருவாக்கலாம் மற்றும் வரிசைப்படுத்தலாம்: உருவாக்குதல் மற்றும் வரிசைப்படுத்துதல். வெர்ஃப் கிட்ஹப் களஞ்சியத்திலிருந்து (அதாவது, கிட்ஹப் களஞ்சியத்தில் மாற்றங்கள் இருக்கும்போது) கொக்கிகளைப் பயன்படுத்தி பைப்லைனைத் தொடங்குகிறோம். அவற்றுக்கான தரவை GitLab திட்ட பண்புகளில் பிரிவில் காணலாம் CI/CD அமைப்புகள் -> பைப்லைன் தூண்டுதல்கள், பின்னர் GitHub இல் தொடர்புடைய Webhook ஐ உருவாக்கவும் (அமைப்புகள் -> Webhooks).

உருவாக்க நிலை இப்படி இருக்கும்:

Build:
  stage: build
  script:
    - type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - source common_envs.sh
    - werf build-and-publish --stages-storage :local
  except:
    refs:
      - schedules
  dependencies:
    - Prebuild

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

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

.base_deploy: &base_deploy
  stage: deploy
  script:
    - type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - source common_envs.sh
    - werf deploy --stages-storage :local
  dependencies:
    - Prebuild
  except:
    refs:
      - schedules

Deploy to Production:
  <<: *base_deploy
  variables:
    WERF_KUBE_CONTEXT: prod
  environment:
    name: production
    url: werf.io
  only:
    refs:
      - master
  except:
    variables:
      - $REVIEW_SHA
    refs:
      - schedules

Deploy to Test:
  <<: *base_deploy
  variables:
    WERF_KUBE_CONTEXT: dev
  environment:
    name: test
    url: werf.test.flant.com
  except:
    refs:
      - schedules
  only:
    variables:
      - $REVIEW_SHA

வெர்ஃப் வரிசைப்படுத்தலைச் செய்ய வேண்டிய கிளஸ்டர் சூழலைக் குறிப்பதில் மட்டுமே பணிகள் அடிப்படையில் வேறுபடுகின்றன (WERF_KUBE_CONTEXT), மற்றும் லூப் சூழல் மாறிகளை அமைத்தல் (environment.name и environment.url), பின்னர் அவை ஹெல்ம் விளக்கப்பட வார்ப்புருக்களில் பயன்படுத்தப்படுகின்றன. டெம்ப்ளேட்களின் உள்ளடக்கங்களை நாங்கள் வழங்க மாட்டோம், ஏனெனில்... கேள்விக்குரிய தலைப்புக்கு சுவாரஸ்யமான எதுவும் இல்லை, ஆனால் நீங்கள் அவற்றைக் காணலாம் கட்டுரைக்கான களஞ்சியங்கள்.

இறுதித் தொடர்பு

werf பதிப்புகள் அடிக்கடி வெளியிடப்படுவதால், புதிய படங்கள் அடிக்கடி உருவாக்கப்படும், மேலும் Docker Registry தொடர்ந்து வளரும். எனவே, கொள்கைகளின் அடிப்படையில் தானியங்கி படத்தை சுத்தம் செய்வதை உள்ளமைக்க வேண்டியது அவசியம். செய்வது மிகவும் எளிது.

செயல்படுத்த உங்களுக்கு இது தேவைப்படும்:

  • சுத்தம் செய்யும் படியைச் சேர்க்கவும் .gitlab-ci.yml;
  • துப்புரவு பணியை அவ்வப்போது நிறைவேற்றுவதைச் சேர்க்கவும்;
  • எழுதும் அணுகல் டோக்கனுடன் சூழல் மாறியை அமைக்கவும்.

ஒரு துப்புரவு நிலை சேர்க்கிறது .gitlab-ci.yml:

Cleanup:
  stage: cleanup
  script:
    - type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - source common_envs.sh
    - docker login -u nobody -p ${WERF_IMAGES_CLEANUP_PASSWORD} ${WERF_IMAGES_REPO}
    - werf cleanup --stages-storage :local
  only:
    refs:
      - schedules

இவை அனைத்தையும் நாங்கள் ஏற்கனவே கொஞ்சம் அதிகமாகப் பார்த்திருக்கிறோம் - அதைச் சுத்தம் செய்ய மட்டுமே நீங்கள் முதலில் டோக்கர் பதிவேட்டில் உள்ள படங்களை நீக்கும் உரிமையைக் கொண்ட டோக்கனுடன் டோக்கர் பதிவேட்டில் உள்நுழைய வேண்டும் (தானாக வழங்கப்படும் GitLab CI பணி டோக்கன் இல்லை. அத்தகைய உரிமைகள் உள்ளன). டோக்கன் முன்கூட்டியே GitLab இல் உருவாக்கப்பட வேண்டும் மற்றும் அதன் மதிப்பு சூழல் மாறியில் குறிப்பிடப்பட வேண்டும் WERF_IMAGES_CLEANUP_PASSWORD திட்டம் (CI/CD அமைப்புகள் -> மாறிகள்).

தேவையான அட்டவணையுடன் ஒரு துப்புரவு பணியைச் சேர்த்தல் செய்யப்படுகிறது CI/CD ->
அட்டவணை.

அவ்வளவுதான்: டோக்கர் ரெஜிஸ்ட்ரியில் உள்ள ஒரு திட்டம் பயன்படுத்தப்படாத படங்களிலிருந்து தொடர்ந்து வளராது.

நடைமுறை பகுதியின் முடிவில், கட்டுரையின் முழு பட்டியல்களும் கிடைக்கின்றன என்பதை உங்களுக்கு நினைவூட்டுகிறேன் Git தகவல்:

விளைவாக

  1. தர்க்கரீதியான அசெம்பிளி கட்டமைப்பைப் பெற்றோம்: ஒரு பதிப்பிற்கு ஒரு கலைப்பொருள்.
  2. அசெம்பிளி உலகளாவியது மற்றும் werf இன் புதிய பதிப்புகள் வெளியிடப்படும் போது கைமுறை மாற்றங்கள் தேவையில்லை: இணையதளத்தில் உள்ள ஆவணங்கள் தானாகவே புதுப்பிக்கப்படும்.
  3. வெவ்வேறு வரையறைகளுக்கு இரண்டு படங்கள் கூடியிருக்கின்றன.
  4. இது விரைவாக வேலை செய்கிறது, ஏனெனில் கேச்சிங் முடிந்தவரை பயன்படுத்தப்படுகிறது - werf இன் புதிய பதிப்பு வெளியிடப்படும் போது அல்லது GitHub ஹூக் மறுபரிசீலனை செய்ய அழைக்கப்படும் போது, ​​மாற்றப்பட்ட பதிப்போடு தொடர்புடைய கலைப்பொருள் மட்டுமே மீண்டும் கட்டமைக்கப்படும்.
  5. பயன்படுத்தப்படாத படங்களை நீக்குவது பற்றி யோசிக்க வேண்டிய அவசியமில்லை: வெர்ஃப் கொள்கைகளின்படி சுத்தம் செய்வது டோக்கர் ரெஜிஸ்ட்ரியை ஒழுங்காக வைத்திருக்கும்.

கண்டுபிடிப்புகள்

  • werf ஐப் பயன்படுத்துவது, அசெம்பிளியின் கேச்சிங் மற்றும் வெளிப்புற களஞ்சியங்களுடன் பணிபுரியும் போது கேச்சிங் ஆகிய இரண்டின் காரணமாகவும் விரைவாக வேலை செய்ய அனுமதிக்கிறது.
  • வெளிப்புற Git களஞ்சியங்களுடன் பணிபுரிவது, ஒவ்வொரு முறையும் முழு களஞ்சியத்தையும் குளோன் செய்ய வேண்டிய தேவையை நீக்குகிறது அல்லது தந்திரமான தேர்வுமுறை தர்க்கத்துடன் சக்கரத்தை மீண்டும் கண்டுபிடிப்பது. werf ஒரு தற்காலிக சேமிப்பைப் பயன்படுத்துகிறது மற்றும் குளோனிங்கை ஒரு முறை மட்டுமே செய்கிறது, பின்னர் பயன்படுத்துகிறது fetch மற்றும் தேவைப்படும் போது மட்டுமே.
  • கட்டமைவு கோப்பில் Go டெம்ப்ளேட்களைப் பயன்படுத்தும் திறன் werf.yaml வெளிப்புறத் தரவைப் பொறுத்து ஒரு சட்டசபையை விவரிக்க உங்களை அனுமதிக்கிறது.
  • வெர்ஃபில் மவுண்ட்டைப் பயன்படுத்துவது கலைப்பொருட்களின் சேகரிப்பை கணிசமாக துரிதப்படுத்துகிறது - கேச் காரணமாக, இது அனைத்து பைப்லைன்களுக்கும் பொதுவானது.
  • werf சுத்தம் செய்வதை உள்ளமைப்பதை எளிதாக்குகிறது, இது மாறும் வகையில் கட்டமைக்கப்படும் போது மிகவும் முக்கியமானது.

சோசலிஸ்ட் கட்சி

எங்கள் வலைப்பதிவிலும் படிக்கவும்:

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

DDoS பாதுகாப்பு, VPS VDS சர்வர்கள் கொண்ட தளங்களுக்கு நம்பகமான ஹோஸ்டிங் வாங்கவும் 🔥 DDoS பாதுகாப்புடன் கூடிய நம்பகமான இணையதள ஹோஸ்டிங், VPS, VDS சர்வர்களை வாங்குங்கள் | ProHoster