අපි දැනටමත් අපගේ GitOps මෙවලම ගැන කිහිප වතාවක් කතා කර ඇත්තෙමු.
අඩවි ව්යුහයේ සූක්ෂ්ම කරුණු වෙත යන්න: සියලුම අනුවාද සඳහා පොදු මෙනුවක් ජනනය කිරීම, නිකුතු පිළිබඳ තොරතුරු සහිත පිටු ආදිය. - අපි කරන්නේ නැහැ. ඒ වෙනුවට, ගතික එකලස් කිරීමේ ගැටළු සහ විශේෂාංග සහ ඒ සමඟ ඇති CI/CD ක්රියාවලීන් කෙරෙහි මඳක් අවධානය යොමු කරමු.
හැඳින්වීම: වෙබ් අඩවිය ක්රියා කරන ආකාරය
ආරම්භ කිරීම සඳහා, werf ලේඛන එහි කේතය සමඟ ගබඩා කර ඇත. මෙය සාමාන්යයෙන් මෙම ලිපියේ විෂය පථයෙන් ඔබ්බට ගිය ඇතැම් සංවර්ධන අවශ්යතා පනවයි, නමුත් අවම වශයෙන් එය පැවසිය හැකිය:
- ලේඛන යාවත්කාලීන කිරීමකින් තොරව නව werf ශ්රිත නිකුත් නොකළ යුතු අතර, ප්රතිලෝමව, ලේඛනගත කිරීමේ යම් වෙනස්කමක් වර්ෆ් හි නව අනුවාදයක් නිකුත් කිරීමක් අදහස් කරයි;
- ව්යාපෘතියට තරමක් දැඩි සංවර්ධනයක් ඇත: නව අනුවාදයන් දිනකට කිහිප වතාවක් නිකුත් කළ හැකිය;
- ලේඛනවල නව අනුවාදයක් සහිත වෙබ් අඩවියක් යෙදවීමට ඕනෑම අතින් සිදුකරන මෙහෙයුම් අවම වශයෙන් වෙහෙසකර වේ;
- ව්යාපෘතිය අර්ථකථන ප්රවේශයක් අනුගමනය කරයි
අනුවාදනය , ස්ථායීතා නාලිකා 5 ක් සමඟ. මුදා හැරීමේ ක්රියාවලියට ස්ථායීතාවය වැඩි කිරීම සඳහා නාලිකා හරහා අනුවාද අනුක්රමයෙන් ගමන් කිරීම ඇතුළත් වේ: ඇල්ෆා සිට පාෂාණ-ඝන දක්වා; - වෙබ් අඩවියේ රුසියානු භාෂා අනුවාදයක් ඇත, එය "ජීවත් වන සහ සංවර්ධනය" (එනම්, එහි අන්තර්ගතය යාවත්කාලීන කරන ලද) ප්රධාන (එනම්, ඉංග්රීසි භාෂා) අනුවාදයට සමාන්තරව ඇත.
මෙම සියලු "අභ්යන්තර කුස්සිය" පරිශීලකයාගෙන් සැඟවීමට, "යන්තම් වැඩ කරන" යමක් ඔහුට පිරිනැමීම, අපි කළා වෙනම werf ස්ථාපනය සහ යාවත්කාලීන මෙවලම - මෙය
වෙබ් අඩවියේ අනුවාද තේරීමේ මෙනුවේ, එක් එක් නාලිකාව තුළ werf හි නවතම අනුවාද තිබේ. පෙරනිමියෙන්, ලිපිනයෙන්
සමස්තයක් වශයෙන්, වෙබ් අඩවියට පහත අනුවාද තිබේ:
- root (පෙරනිමියෙන් විවෘත වේ),
- එක් එක් නිකුතුවේ එක් එක් සක්රිය යාවත්කාලීන නාලිකාව සඳහා (උදාහරණයක් ලෙස,
werf.io/v1.0-beta ).
වෙබ් අඩවියක නිශ්චිත අනුවාදයක් උත්පාදනය කිරීම සඳහා, සාමාන්යයෙන්, එය භාවිතයෙන් එය සම්පාදනය කිරීමට ප්රමාණවත් වේ /docs
werf repository අනුරූප විධානය (jekyll build
), අවශ්ය අනුවාදයේ Git ටැගය වෙත මාරු වීමෙන් පසුව.
එය එකතු කිරීමට පමණක් ඉතිරිව ඇත:
- එකලස් කිරීම සඳහා උපයෝගීතාව (වර්ෆ්) භාවිතා කරනු ලැබේ;
- CI/CD ක්රියාවලි GitLab CI පදනම මත ගොඩනගා ඇත;
- සහ මේ සියල්ල, ඇත්ත වශයෙන්ම, Kubernetes හි ක්රියාත්මක වේ.
කාර්යයන්
දැන් අපි විස්තර කර ඇති සියලුම විශේෂතා සැලකිල්ලට ගන්නා කාර්යයන් සකස් කරමු:
- ඕනෑම යාවත්කාලීන නාලිකාවක werf අනුවාදය වෙනස් කිරීමෙන් පසු වෙබ් අඩවියේ ලේඛන ස්වයංක්රීයව යාවත්කාලීන කළ යුතුය.
- සංවර්ධනය සඳහා ඔබට සමහර විට හැකි විය යුතුය අඩවියේ පෙරදසුන් අනුවාද බලන්න.
අනුරූප Git ටැග් වලින් ඕනෑම නාලිකාවක අනුවාදය වෙනස් කිරීමෙන් පසු වෙබ් අඩවිය නැවත සම්පාදනය කළ යුතුය, නමුත් රූපය ගොඩනැගීමේ ක්රියාවලියේදී අපට පහත විශේෂාංග ලැබෙනු ඇත:
- නාලිකා වල අනුවාද ලැයිස්තුව වෙනස් වන බැවින්, අනුවාදය වෙනස් වී ඇති නාලිකා සඳහා ලේඛන නැවත ගොඩ නැගීම පමණක් අවශ්ය වේ. සියල්ලට පසු, සියල්ල නැවත ගොඩ නැගීම ඉතා හොඳ නැත.
- නිකුතු සඳහා නාලිකා කට්ටලය වෙනස් විය හැක. යම් අවස්ථාවක දී, උදාහරණයක් ලෙස, මුල් ප්රවේශ 1.1 නිකුතුවට වඩා ස්ථායී අනුවාදයක් නාලිකාවල නොතිබිය හැකිය, නමුත් කාලයත් සමඟ ඒවා දිස්වනු ඇත - මෙම අවස්ථාවේදී, ඔබ එකලස් කිරීම අතින් වෙනස් නොකළ යුතුද?
එය එවැන්නකි එකලස් කිරීම බාහිර දත්ත වෙනස් කිරීම මත රඳා පවතී.
Реализация
ප්රවේශයක් තෝරා ගැනීම
විකල්පයක් ලෙස, ඔබට අවශ්ය සෑම අනුවාදයක්ම වෙනම පොඩ් එකක් ලෙස Kubernetes හි ධාවනය කළ හැකිය. මෙම විකල්පය පොකුරේ ඇති වස්තූන් විශාල සංඛ්යාවක් ඇඟවුම් කරයි, එය ස්ථායී වර්ෆ් නිකුතු ගණන වැඩි වීමත් සමඟ වර්ධනය වේ. මෙය වඩාත් සංකීර්ණ නඩත්තු කිරීමක් අදහස් කරයි: සෑම අනුවාදයකටම තමන්ගේම HTTP සේවාදායකයක් ඇති අතර කුඩා බරක් ඇත. ඇත්ත වශයෙන්ම, මෙය වැඩි සම්පත් පිරිවැයක් දරයි.
අපිත් ඒ මාර්ගයම ගත්තා අවශ්ය සියලුම අනුවාද එක් රූපයක එකලස් කිරීම. වෙබ් අඩවියේ සියලුම අනුවාද වල සම්පාදනය කරන ලද ස්ථිතික NGINX සහිත කන්ටේනරයක පිහිටා ඇති අතර, අනුරූප යෙදවීම වෙත ගමනාගමනය පැමිණෙන්නේ NGINX Ingress හරහාය. සරල ව්යුහයක් - අස්ථායී යෙදුමක් - Kubernetes භාවිතා කරමින් පහසුවෙන් යෙදවීම (භාරය මත පදනම්ව) පරිමාණය කිරීමට ඔබට ඉඩ සලසයි.
වඩාත් නිවැරදිව කිවහොත්, අපි පින්තූර දෙකක් එකතු කරමු: එකක් නිෂ්පාදන පරිපථය සඳහා, දෙවැන්න dev පරිපථය සඳහා අතිරේක එකකි. අතිරේක රූපය භාවිතා කරනු ලබන්නේ (දියත් කරන ලද) ප්රධාන එක සමඟ dev පරිපථයේ පමණක් වන අතර සමාලෝචන කැපවීමෙන් වෙබ් අඩවියේ අනුවාදය අඩංගු වන අතර ඒවා අතර මාර්ගගත කිරීම Ingress සම්පත් භාවිතයෙන් සිදු කෙරේ.
werf vs git ක්ලෝනය සහ පුරාවස්තු
දැනටමත් සඳහන් කර ඇති පරිදි, ලේඛනවල නිශ්චිත අනුවාදයක් සඳහා අඩවි ස්ථිතික උත්පාදනය කිරීම සඳහා, ඔබ සුදුසු ගබඩා ටැගය වෙත මාරු වීමෙන් ගොඩනගා ගත යුතුය. ඔබ ගොඩනඟන සෑම අවස්ථාවකම ගබඩාව ක්ලෝන කිරීමෙන්, ලැයිස්තුවකින් සුදුසු ටැග් තෝරා ගැනීමෙන් ඔබට මෙය කළ හැකිය. කෙසේ වෙතත්, මෙය තරමක් සම්පත්-දැඩි මෙහෙයුමක් වන අතර, එපමනක් නොව, සුළු නොවන උපදෙස් ලිවීම අවශ්ය වේ ... තවත් බරපතල අවාසියක් නම්, මෙම ප්රවේශය සමඟ එකලස් කිරීමේදී යමක් හැඹිලිගත කිරීමට ක්රමයක් නොමැති වීමයි.
මෙහිදී වර්ෆ් උපයෝගීතාවම ක්රියාත්මක කරමින් අපගේ ආධාරයට පැමිණේ ස්මාර්ට් හැඹිලිගත කිරීම සහ ඔබට භාවිතා කිරීමට ඉඩ සලසයි fetch
අවශ්ය නම්. ඊට අමතරව, ගබඩාවෙන් දත්ත එකතු කිරීමේදී, අපට අවශ්ය නාමාවලි පමණක් තෝරා ගත හැකිය (අපගේ නඩුවේදී මෙය නාමාවලියයි. docs
), එකතු කරන ලද දත්ත ප්රමාණය සැලකිය යුතු ලෙස අඩු කරනු ඇත.
Jekyll යනු ස්ථිතික දත්ත සම්පාදනය කිරීම සඳහා නිර්මාණය කර ඇති මෙවලමක් වන අතර අවසාන රූපයේ අවශ්ය නොවන බැවින්, එය සම්පාදනය කිරීම තාර්කික වනු ඇත.
අපි ලියන්නේ werf.yaml
එබැවින්, අපි එක් එක් අනුවාදය වෙනම වර්ෆ් කෞතුක වස්තුවක සම්පාදනය කිරීමට තීරණය කළෙමු. කෙසේ වෙතත් අපි එකලස් කිරීමේදී මෙම පුරාවස්තු කීයක් තිබේදැයි අපි නොදනිමු, එබැවින් අපට ස්ථාවර ගොඩනැගීමේ වින්යාසයක් ලිවිය නොහැක (දැඩි ලෙස කථා කිරීම, අපට තවමත් හැකිය, නමුත් එය සම්පූර්ණයෙන්ම ඵලදායී නොවනු ඇත).
werf ඔබට භාවිතා කිරීමට ඉඩ සලසයි werf.yaml
), සහ මෙය හැකි වේ පියාසර වින්යාසය ජනනය කරන්න බාහිර දත්ත මත පදනම්ව (ඔබට අවශ්ය දේ!). අපගේ නඩුවේ බාහිර දත්ත යනු අනුවාද සහ නිකුතු පිළිබඳ තොරතුරු වන අතර, එහි පදනම මත අපි අවශ්ය කෞතුක වස්තු සංඛ්යාව එකතු කරන අතර ප්රති result ලයක් ලෙස අපි පින්තූර දෙකක් ලබා ගනිමු: 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") }}
වෙබ් අඩවියේ ස්ථිතික අනුවාදය සම්පාදනය කිරීම සඳහා කෞතුක වස්තුවේ විස්තරය සාමාන්යයෙන් අපට අවශ්ය සියලුම අවස්ථා සඳහා සමාන වේ (මූල අනුවාදය උත්පාදනය කිරීම මෙන්ම dev පරිපථයේ අනුවාදය ද ඇතුළුව). එමනිසා, අපි එය ශ්රිතය භාවිතයෙන් වෙනම බ්ලොක් එකකට ගෙන යන්නෙමු 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
නල මාර්ග ධාවන අතර Jekyll හැඹිලිය සුරැකීමට ඔබට ඉඩ සලසයි නැවත එකලස් කිරීම සැලකිය යුතු ලෙස වේගවත් කරයි.
ගොනුව භාවිතා කරන ආකාරය ඔබ ද දැක ඇති releases.yml
යනු YAML ගොනුවක් වන මුදා හැරීමේ දත්ත ඉල්ලා ඇත
කොන්දේසි සහිත ප්රකාශය භාවිතයෙන් මෙය ක්රියාත්මක වේ if
සැකිලි සහ මෝස්තර යන්න {{ $Root.Files.Get "releases.yml" | sha256sum }}
වේදිකාවේ .Channel
සමානයි root
) ගොනු හැෂ් releases.yml
එය Ansible කාර්යයේ (පරාමිතිය) නමේ කොටසක් වන බැවින්, සම්පූර්ණ අදියරෙහි අත්සනට බලපායි name
) මේ අනුව, වෙනස් වන විට අන්තර්ගතය ගොනුව releases.yml
අනුරූප කෞතුක වස්තුව නැවත එකලස් කරනු ලැබේ.
කරුණාකර බාහිර ගබඩාවක් සමඟ වැඩ කිරීමට ද අවධානය යොමු කරන්න. කෞතුක වස්තුවක රූපයේ /docs
, සහ සම්මත කරන ලද පරාමිති මත පදනම්ව, අවශ්ය ටැගය හෝ සමාලෝචන කැපවීමේ දත්ත වහාම එකතු වේ.
නාලිකා සහ නිකුතුවල මාරු කළ අනුවාදවල කෞතුක වස්තු පිළිබඳ විස්තරයක් ජනනය කිරීමට පුරාවස්තු අච්චුව භාවිතා කිරීමට, අපි විචල්යයේ ලූපයක් සංවිධානය කරමු .WerfVersions
в werf.yaml
:
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ dict "Version" $VersionsDict._1 "Channel" $VersionsDict._0 "Root" $Root | include "doc_artifact" }}
---
{{ end -}}
නිසා ලූපය කෞතුක වස්තු කිහිපයක් ජනනය කරනු ඇත (අපි එසේ බලාපොරොත්තු වෙමු), ඒවා අතර බෙදුම්කරු සැලකිල්ලට ගැනීම අවශ්ය වේ - අනුපිළිවෙල ---
(වින්යාස ගොනු සින්ටැක්ස් පිළිබඳ වැඩි විස්තර සඳහා, බලන්න
ඒ හා සමානව, නමුත් ලූපයක් නොමැතිව, අපි “විශේෂ අවස්ථා” සඳහා කෞතුක වස්තු අච්චුව ලෙස හඳුන්වමු: මූල අනුවාදය සඳහා මෙන්ම සමාලෝචන කැපවීමෙන් ලැබෙන අනුවාදය:
{{ 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
.
පුරාවස්තු සූදානම් - ආනයනය ආරම්භ කිරීමට කාලයයි!
අවසාන රූපය, Kubernetes මත ධාවනය කිරීමට නිර්මාණය කර ඇති අතර, සේවාදායක වින්යාස ගොනුවක් එක් කළ සාමාන්ය 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 -}}
ප්රධාන එක සමඟින් dev පරිපථයේ දියත් කර ඇති අතිරේක රූපයේ අඩංගු වන්නේ වෙබ් අඩවියේ අනුවාද දෙකක් පමණි: සමාලෝචන කැපවීමේ අනුවාදය සහ වෙබ් අඩවියේ මූල අනුවාදය (සාමාන්ය වත්කම් ඇත සහ ඔබට මතක නම් , දත්ත නිකුත් කරන්න). මේ අනුව, අතිරේක රූපය ප්රධාන එකට වඩා වෙනස් වන්නේ ආනයන අංශයේ පමණි (සහ, ඇත්ත වශයෙන්ම, නමෙන්):
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
, නමුත් පිණිස
සභාව සූදානම්! අපි CI/CD සහ වැදගත් සූක්ෂ්ම කරුණු වෙත යමු.
GitLab CI හි නල මාර්ගය සහ ගතික ගොඩනැගීමේ විශේෂාංග
Build එක Run කරනකොට අපි පාවිච්චි කරන environment variables set කරන්න ඕන werf.yaml
. මෙය REVIEW_SHA විචල්යයට අදාළ නොවේ, GitHub කොක්කෙන් නල මාර්ගය ඇමතීමේ දී අපි සකසන්නෙමු.
අපි අවශ්ය බාහිර දත්ත Bash ස්ක්රිප්ට් එකක ජනනය කරන්නෙමු 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'
ඔබට එවැනි ස්ක්රිප්ට් එකක ප්රතිදානය භාවිතා කළ හැකිය, උදාහරණයක් ලෙස, Bash ශ්රිතය භාවිතා කිරීම 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 නල මාර්ග අදියර භාවිතයෙන් ගොඩ නැගීමට සහ යෙදවීමට හැකිය: ගොඩනැගීම සහ යෙදවීම. අපි werf GitHub ගබඩාවෙන් (එනම්, GitHub ගබඩාවේ වෙනස්කම් ඇති විට) කොකු භාවිතයෙන් නල මාර්ගයම දියත් කරන්නෙමු. ඒවා සඳහා දත්ත කොටසේ 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 අච්චුවක් භාවිතා කරමින් නිෂ්පාදන සහ dev පරිපථ සඳහා යෙදවීම සඳහා වෙන වෙනම:
.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
අපි දැනටමත් මේ සියල්ලම පාහේ තරමක් ඉහළින් දැක ඇත්තෙමු - එය පිරිසිදු කිරීමට පමණක් ඔබ මුලින්ම Docker Registry හි පින්තූර මකා දැමීමේ අයිතිය ඇති ටෝකනයක් සමඟ Docker Registry වෙත ලොග් විය යුතුය (ස්වයංක්රීයව නිකුත් කරන GitLab CI කාර්ය ටෝකනය එසේ නොවේ. එවැනි අයිතිවාසිකම් ඇත). ටෝකනය GitLab හි කල්තියා නිර්මාණය කළ යුතු අතර එහි අගය පරිසර විචල්යයේ සඳහන් කළ යුතුය. WERF_IMAGES_CLEANUP_PASSWORD
ව්යාපෘතියකි (CI/CD සිටුවම් -> විචල්ය).
අවශ්ය කාලසටහන සමඟ පිරිසිදු කිරීමේ කාර්යයක් එකතු කිරීම සිදු කෙරේ CI/CD ->
උපලේඛන.
එපමණයි: Docker Registry හි ව්යාපෘතියක් තවදුරටත් භාවිතයට නොගත් පින්තූර වලින් නිරන්තරයෙන් වර්ධනය නොවේ.
ප්රායෝගික කොටස අවසානයේ, ලිපියේ සම්පූර්ණ ලැයිස්තුගත කිරීම් ලබා ගත හැකි බව මම ඔබට මතක් කරමි
ප්රතිඵලය
- අපට තාර්කික එකලස් කිරීමේ ව්යුහයක් ලැබුණි: එක් අනුවාදයකට එක් පුරාවස්තුවක්.
- එකලස් කිරීම විශ්වීය වන අතර werf හි නව අනුවාදයන් නිකුත් කරන විට අතින් වෙනස්කම් අවශ්ය නොවේ: වෙබ් අඩවියේ ලේඛන ස්වයංක්රීයව යාවත්කාලීන වේ.
- විවිධ සමෝච්ඡයන් සඳහා පින්තූර දෙකක් එකලස් කර ඇත.
- එය ඉක්මනින් ක්රියා කරයි, මන්ද හැඹිලිගත කිරීම හැකිතාක් භාවිතා කරයි - werf හි නව අනුවාදයක් නිකුත් කළ විට හෝ GitHub කොක්කක් සමාලෝචන කැපවීමක් සඳහා කැඳවන විට, වෙනස් කළ අනුවාදය සමඟ අනුරූප පුරාවස්තුව පමණක් නැවත ගොඩනඟනු ලැබේ.
- භාවිතයට නොගත් පින්තූර මකා දැමීම ගැන සිතීමට අවශ්ය නැත: werf ප්රතිපත්තිවලට අනුව පිරිසිදු කිරීම Docker Registry එක පිළිවෙලට තබා ගනී.
සොයා ගැනීම්
- werf භාවිතා කිරීමෙන් එකලස්කිරීම් දෙකම හැඹිලිගත වීම සහ බාහිර ගබඩාවන් සමඟ වැඩ කිරීමේදී හැඹිලිගත වීම හේතුවෙන් එකලස් කිරීම ඉක්මනින් ක්රියා කිරීමට ඉඩ සලසයි.
- බාහිර Git ගබඩාවන් සමඟ වැඩ කිරීම සෑම අවස්ථාවකම සම්පූර්ණ ගබඩාව ක්ලෝන කිරීමට හෝ උපක්රමශීලී ප්රශස්තිකරණ තර්කනය සමඟ රෝදය ප්රතිනිර්මාණය කිරීමේ අවශ්යතාවය ඉවත් කරයි. werf හැඹිලියක් භාවිතා කර ක්ලෝන කිරීම එක් වරක් පමණක් සිදු කරයි, පසුව භාවිතා කරයි
fetch
සහ අවශ්ය විට පමණි. - ගොඩනැගීමේ වින්යාස ගොනුවේ Go සැකිලි භාවිතා කිරීමේ හැකියාව
werf.yaml
බාහිර දත්ත මත රඳා පවතින එකලස් කිරීමක් විස්තර කිරීමට ඔබට ඉඩ සලසයි. - werf හි මවුන්ට් භාවිතා කිරීම කෞතුක වස්තු එකතු කිරීම සැලකිය යුතු ලෙස වේගවත් කරයි - හැඹිලිය හේතුවෙන්, එය සියලුම නල මාර්ග සඳහා පොදු වේ.
- werf පිරිසිදු කිරීම වින්යාස කිරීම පහසු කරයි, එය ගතිකව ගොඩනැගීමේදී විශේෂයෙන් වැදගත් වේ.
ප්රාදේශීය සභා
අපගේ බ්ලොග් අඩවියේ ද කියවන්න:
- «
Kubernetes වෙත නව යෙදුම් නිකුතුවක් ලබා දෙන අතරතුර විධාන ක්රියාත්මක කිරීම »; - «
werf සහ GitLab CI සමඟ එකම වර්ගයේ ක්ෂුද්ර සේවා තැනීම සහ යෙදවීම »; - «
සංකීර්ණ හෙල්ම් ප්රස්ථාර පෙරළීමට werf භාවිතා කිරීම »; - «
werf 1.0 ස්ථායී හඳුන්වාදීම: GitOps එයට කුමක් කළ යුතුද, තත්ත්වය සහ සැලසුම් ".
මූලාශ්රය: www.habr.com