మేము ఇప్పటికే మా GitOps సాధనం గురించి ఒకటి కంటే ఎక్కువసార్లు మాట్లాడాము. , మరియు ఈసారి మేము ప్రాజెక్ట్ యొక్క డాక్యుమెంటేషన్తో సైట్ను సమీకరించడంలో మా అనుభవాన్ని పంచుకోవాలనుకుంటున్నాము - (దాని రష్యన్ వెర్షన్ ) ఇది సాధారణ స్టాటిక్ సైట్, కానీ దాని అసెంబ్లీ ఆసక్తికరంగా ఉంటుంది, ఇది డైనమిక్ సంఖ్యలో కళాఖండాలను ఉపయోగించి నిర్మించబడింది.
సైట్ నిర్మాణం యొక్క సూక్ష్మ నైపుణ్యాలలోకి వెళ్లండి: అన్ని వెర్షన్ల కోసం సాధారణ మెనుని రూపొందించడం, విడుదలల గురించి సమాచారంతో పేజీలు మొదలైనవి. - మా కు అక్కరలేదు. బదులుగా, డైనమిక్ అసెంబ్లీ యొక్క సమస్యలు మరియు లక్షణాలపై మరియు దానితో పాటుగా ఉన్న CI/CD ప్రక్రియలపై కొంచెం దృష్టి పెడదాం.
పరిచయం: సైట్ ఎలా పని చేస్తుంది
ప్రారంభించడానికి, werf డాక్యుమెంటేషన్ దాని కోడ్తో పాటు నిల్వ చేయబడుతుంది. ఇది సాధారణంగా ఈ కథనం యొక్క పరిధికి మించిన కొన్ని అభివృద్ధి అవసరాలను విధిస్తుంది, కానీ కనీసం ఇలా చెప్పవచ్చు:
- డాక్యుమెంటేషన్ను అప్డేట్ చేయకుండా కొత్త వెర్ఫ్ ఫంక్షన్లు విడుదల చేయకూడదు మరియు దీనికి విరుద్ధంగా, డాక్యుమెంటేషన్లో ఏవైనా మార్పులు వెర్ఫ్ యొక్క కొత్త వెర్షన్ విడుదలను సూచిస్తాయి;
- ప్రాజెక్ట్ చాలా ఇంటెన్సివ్ అభివృద్ధిని కలిగి ఉంది: కొత్త సంస్కరణలు రోజుకు చాలా సార్లు విడుదల చేయబడతాయి;
- డాక్యుమెంటేషన్ యొక్క కొత్త వెర్షన్తో సైట్ని అమలు చేయడానికి ఏదైనా మాన్యువల్ ఆపరేషన్లు కనీసం శ్రమతో కూడుకున్నవి;
- ప్రాజెక్ట్ సెమాంటిక్ విధానాన్ని అవలంబిస్తుంది , 5 స్థిరత్వ ఛానెల్లతో. విడుదల ప్రక్రియలో స్థిరత్వాన్ని పెంచే క్రమంలో ఛానెల్ల ద్వారా సంస్కరణల సీక్వెన్షియల్ పాసేజ్ ఉంటుంది: ఆల్ఫా నుండి రాక్-సాలిడ్ వరకు;
- సైట్ రష్యన్ భాషా సంస్కరణను కలిగి ఉంది, ఇది ప్రధాన (అంటే, ఆంగ్ల భాష) సంస్కరణకు సమాంతరంగా "జీవిస్తుంది మరియు అభివృద్ధి చెందుతుంది" (అంటే, దాని కంటెంట్ నవీకరించబడింది).
వినియోగదారు నుండి ఈ “లోపలి వంటగది” మొత్తాన్ని దాచడానికి, అతనికి “కేవలం పని చేసే” దాన్ని అందించాము ప్రత్యేక werf సంస్థాపన మరియు నవీకరణ సాధనం అది - . మీరు ఉపయోగించడానికి సిద్ధంగా ఉన్న విడుదల సంఖ్య మరియు స్థిరత్వ ఛానెల్ని మీరు పేర్కొనాలి మరియు మల్టీవెర్ఫ్ ఛానెల్లో కొత్త వెర్షన్ ఉందో లేదో తనిఖీ చేస్తుంది మరియు అవసరమైతే దాన్ని డౌన్లోడ్ చేస్తుంది.
వెబ్సైట్లోని సంస్కరణ ఎంపిక మెనులో, ప్రతి ఛానెల్లో werf యొక్క తాజా వెర్షన్లు అందుబాటులో ఉన్నాయి. డిఫాల్ట్గా, చిరునామా ద్వారా తాజా విడుదల కోసం అత్యంత స్థిరమైన ఛానెల్ యొక్క సంస్కరణ తెరవబడుతుంది - ఇది శోధన ఇంజిన్ల ద్వారా కూడా సూచిక చేయబడింది. ఛానెల్ కోసం డాక్యుమెంటేషన్ ప్రత్యేక చిరునామాలలో అందుబాటులో ఉంది (ఉదాహరణకు, బీటా విడుదల కోసం 1.0).
మొత్తంగా, సైట్ కింది సంస్కరణలు అందుబాటులో ఉన్నాయి:
- రూట్ (డిఫాల్ట్గా తెరవబడుతుంది),
- ప్రతి విడుదల యొక్క ప్రతి క్రియాశీల నవీకరణ ఛానెల్ కోసం (ఉదాహరణకు, ).
సైట్ యొక్క నిర్దిష్ట సంస్కరణను రూపొందించడానికి, సాధారణంగా, దాన్ని ఉపయోగించి కంపైల్ చేయడానికి సరిపోతుంది డైరెక్టరీలో అమలు చేయడం ద్వారా /docs werf రిపోజిటరీ సంబంధిత కమాండ్ (jekyll build), అవసరమైన సంస్కరణ యొక్క Git ట్యాగ్కి మారిన తర్వాత.
ఇది జోడించడానికి మాత్రమే మిగిలి ఉంది:
- యుటిలిటీ (వెర్ఫ్) అసెంబ్లీ కోసం ఉపయోగించబడుతుంది;
- CI/CD ప్రక్రియలు GitLab CI ఆధారంగా నిర్మించబడ్డాయి;
- మరియు ఇవన్నీ కుబెర్నెట్స్లో నడుస్తాయి.
పనులు
ఇప్పుడు వివరించిన అన్ని ప్రత్యేకతలను పరిగణనలోకి తీసుకునే పనులను రూపొందిద్దాం:
- ఏదైనా నవీకరణ ఛానెల్లో werf సంస్కరణను మార్చిన తర్వాత సైట్లోని డాక్యుమెంటేషన్ స్వయంచాలకంగా నవీకరించబడాలి.
- అభివృద్ధి కోసం మీరు కొన్నిసార్లు చేయగలరు సైట్ యొక్క ప్రివ్యూ సంస్కరణలను వీక్షించండి.
సంబంధిత Git ట్యాగ్ల నుండి ఏదైనా ఛానెల్లో సంస్కరణను మార్చిన తర్వాత సైట్ తప్పనిసరిగా తిరిగి కంపైల్ చేయబడాలి, అయితే చిత్రాన్ని నిర్మించే ప్రక్రియలో మేము ఈ క్రింది లక్షణాలను పొందుతాము:
- ఛానెల్లలోని సంస్కరణల జాబితా మారినందున, సంస్కరణ మారిన ఛానెల్ల కోసం డాక్యుమెంటేషన్ను పునర్నిర్మించడం మాత్రమే అవసరం. అన్ని తరువాత, మళ్ళీ ప్రతిదీ పునర్నిర్మాణం చాలా బాగుంది కాదు.
- విడుదలల కోసం ఛానెల్ల సెట్ మారవచ్చు. ఏదో ఒక సమయంలో, ఉదాహరణకు, ఛానెల్లలో ప్రారంభ యాక్సెస్ 1.1 విడుదల కంటే స్థిరమైన సంస్కరణ ఉండకపోవచ్చు, కానీ కాలక్రమేణా అవి కనిపిస్తాయి - ఈ సందర్భంలో, మీరు అసెంబ్లీని మాన్యువల్గా మార్చకూడదా?
అది మారుతుంది అసెంబ్లీ బాహ్య డేటాను మార్చడంపై ఆధారపడి ఉంటుంది.
అమలు
ఒక విధానాన్ని ఎంచుకోవడం
ప్రత్యామ్నాయంగా, మీరు Kubernetesలో ప్రత్యేక పాడ్గా అవసరమైన ప్రతి సంస్కరణను అమలు చేయవచ్చు. ఈ ఐచ్ఛికం క్లస్టర్లోని పెద్ద సంఖ్యలో వస్తువులను సూచిస్తుంది, ఇది స్థిరమైన వెర్ఫ్ విడుదలల సంఖ్య పెరుగుదలతో పెరుగుతుంది. మరియు ఇది మరింత సంక్లిష్టమైన నిర్వహణను సూచిస్తుంది: ప్రతి సంస్కరణకు దాని స్వంత HTTP సర్వర్ మరియు చిన్న లోడ్ ఉంటుంది. వాస్తవానికి, ఇది ఎక్కువ వనరుల ఖర్చులను కూడా కలిగి ఉంటుంది.
అదే బాట పట్టాం ఒక చిత్రంలో అవసరమైన అన్ని సంస్కరణలను సమీకరించడం. సైట్ యొక్క అన్ని సంస్కరణల యొక్క సంకలనం చేయబడిన స్టాటిక్స్ NGINXతో కూడిన కంటైనర్లో ఉన్నాయి మరియు సంబంధిత విస్తరణకు ట్రాఫిక్ NGINX ప్రవేశం ద్వారా వస్తుంది. ఒక సాధారణ నిర్మాణం - స్థితిలేని అప్లికేషన్ - కుబెర్నెటెస్ని ఉపయోగించి విస్తరణను (లోడ్ను బట్టి) సులభంగా స్కేల్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది.
మరింత ఖచ్చితంగా చెప్పాలంటే, మేము రెండు చిత్రాలను సేకరిస్తున్నాము: ఒకటి ప్రొడక్షన్ సర్క్యూట్ కోసం, రెండవది డెవ్ సర్క్యూట్ కోసం అదనపు ఒకటి. అదనపు చిత్రం ప్రధాన చిత్రంతో పాటు dev సర్క్యూట్లో మాత్రమే ఉపయోగించబడుతుంది మరియు సమీక్ష కమిట్ నుండి సైట్ యొక్క సంస్కరణను కలిగి ఉంటుంది మరియు వాటి మధ్య రూటింగ్ ఇన్గ్రెస్ వనరులను ఉపయోగించి నిర్వహించబడుతుంది.
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") }} సైట్ యొక్క స్టాటిక్ వెర్షన్ను కంపైల్ చేయడానికి ఆర్టిఫ్యాక్ట్ యొక్క వివరణ సాధారణంగా మనకు అవసరమైన అన్ని సందర్భాల్లో ఒకే విధంగా ఉంటుంది (రూట్ వెర్షన్ను రూపొందించడంతో పాటు అలాగే 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 పైప్లైన్ పరుగుల మధ్య జెకిల్ కాష్ను సేవ్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది గణనీయంగా పునర్వ్యవస్థీకరణను వేగవంతం చేస్తుంది.
మీరు ఫైల్ వినియోగాన్ని కూడా గమనించి ఉండవచ్చు releases.yml నుండి అభ్యర్థించబడిన విడుదల డేటాతో YAML ఫైల్ (పైప్లైన్ను అమలు చేస్తున్నప్పుడు పొందిన కళాఖండం). సైట్ను కంపైల్ చేసేటప్పుడు ఇది అవసరం, కానీ వ్యాసం యొక్క సందర్భంలో ఇది మాకు ఆసక్తికరంగా ఉంటుంది ఎందుకంటే ఇది దాని స్థితిపై ఆధారపడి ఉంటుంది ఒకే ఒక కళాఖండాన్ని తిరిగి కలపడం — సైట్ యొక్క రూట్ వెర్షన్ యొక్క కళాఖండం (ఇతర కళాఖండాలలో ఇది అవసరం లేదు).
ఇది షరతులతో కూడిన ప్రకటనను ఉపయోగించి అమలు చేయబడుతుంది if టెంప్లేట్లు మరియు డిజైన్లను చూడండి {{ $Root.Files.Get "releases.yml" | sha256sum }} దశలో . ఇది క్రింది విధంగా పనిచేస్తుంది: రూట్ వెర్షన్ కోసం ఒక కళాఖండాన్ని నిర్మించేటప్పుడు (వేరియబుల్ .Channel సమానంగా root) ఫైల్ హాష్ releases.yml మొత్తం దశ సంతకాన్ని ప్రభావితం చేస్తుంది, ఎందుకంటే ఇది అన్సిబుల్ టాస్క్ (పారామితి) పేరులో భాగం 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 -}} ఎందుకంటే లూప్ అనేక కళాఖండాలను ఉత్పత్తి చేస్తుంది (మేము అలా ఆశిస్తున్నాము), వాటి మధ్య విభజనను పరిగణనలోకి తీసుకోవడం అవసరం - క్రమం --- (కాన్ఫిగరేషన్ ఫైల్ సింటాక్స్ గురించి మరింత సమాచారం కోసం, చూడండి ) ముందుగా నిర్వచించినట్లుగా, లూప్లో టెంప్లేట్ని కాల్ చేస్తున్నప్పుడు, మేము వెర్షన్ పారామితులు, 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 -}}ప్రధాన చిత్రంతో పాటుగా 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, కానీ క్రమంలో 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 పైప్లైన్ దశలను ఉపయోగించి నిర్మించవచ్చు మరియు అమలు చేయవచ్చు: బిల్డ్ మరియు డిప్లాయ్. మేము GitHub werf రిపోజిటరీ (అంటే, GitHubలో రిపోజిటరీలో మార్పులు వచ్చినప్పుడు) నుండి hookలను ఉపయోగించి పైప్లైన్ను ప్రారంభించాము. విభాగంలోని GitLab ప్రాజెక్ట్ లక్షణాలలో వాటి కోసం డేటాను కనుగొనవచ్చు CI/CD సెట్టింగ్లు -> పైప్లైన్ ట్రిగ్గర్లు, ఆపై GitHubలో సంబంధిత Webhookని సృష్టించండి (సెట్టింగ్లు -> వెబ్హుక్స్).
నిర్మాణ దశ ఇలా ఉంటుంది:
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), తరువాత హెల్మ్ చార్ట్ టెంప్లేట్లలో ఉపయోగించబడతాయి. మేము టెంప్లేట్ల కంటెంట్లను అందించము, ఎందుకంటే... సందేహాస్పద అంశం కోసం ఆసక్తికరమైన ఏమీ లేదు, కానీ మీరు వాటిని కనుగొనవచ్చు .
చివరి టచ్
వెర్ఫ్ సంస్కరణలు చాలా తరచుగా విడుదలవుతాయి కాబట్టి, కొత్త చిత్రాలు తరచుగా నిర్మించబడతాయి మరియు డాకర్ రిజిస్ట్రీ నిరంతరం అభివృద్ధి చెందుతుంది. అందువల్ల, విధానాల ఆధారంగా ఆటోమేటిక్ ఇమేజ్ క్లీనప్ను కాన్ఫిగర్ చేయడం అత్యవసరం. ఇది చేయడం చాలా సులభం.
అమలు చేయడానికి మీకు ఇది అవసరం:
- దీనికి శుభ్రపరిచే దశను జోడించండి
.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 ->
సర్వీసు షెడ్యూల్స్.
అంతే: డాకర్ రిజిస్ట్రీలోని ప్రాజెక్ట్ ఉపయోగించని చిత్రాల నుండి నిరంతరం పెరగదు.
ఆచరణాత్మక భాగం ముగింపులో, వ్యాసం నుండి పూర్తి జాబితాలు అందుబాటులో ఉన్నాయని నేను మీకు గుర్తు చేస్తాను :
- ;
- .
ఫలితంగా
- మేము లాజికల్ అసెంబ్లీ నిర్మాణాన్ని అందుకున్నాము: ప్రతి సంస్కరణకు ఒక కళాఖండం.
- అసెంబ్లీ సార్వత్రికమైనది మరియు వెర్ఫ్ యొక్క కొత్త సంస్కరణలు విడుదలైనప్పుడు మాన్యువల్ మార్పులు అవసరం లేదు: వెబ్సైట్లోని డాక్యుమెంటేషన్ స్వయంచాలకంగా నవీకరించబడుతుంది.
- వేర్వేరు ఆకృతుల కోసం రెండు చిత్రాలు సమావేశమయ్యాయి.
- ఇది త్వరగా పని చేస్తుంది, ఎందుకంటే కాషింగ్ సాధ్యమైనంత ఎక్కువగా ఉపయోగించబడుతుంది - werf యొక్క కొత్త వెర్షన్ విడుదల చేయబడినప్పుడు లేదా GitHub హుక్ రివ్యూ కమిట్ కోసం పిలిచినప్పుడు, మార్చబడిన సంస్కరణతో సంబంధిత కళాకృతి మాత్రమే పునర్నిర్మించబడుతుంది.
- ఉపయోగించని చిత్రాలను తొలగించడం గురించి ఆలోచించాల్సిన అవసరం లేదు: వెర్ఫ్ విధానాల ప్రకారం శుభ్రపరచడం డాకర్ రిజిస్ట్రీని క్రమంలో ఉంచుతుంది.
కనుగొన్న
- werfని ఉపయోగించడం వలన అసెంబ్లీ కూడా కాషింగ్ మరియు బాహ్య రిపోజిటరీలతో పని చేస్తున్నప్పుడు కాషింగ్ కారణంగా అసెంబ్లీ త్వరగా పని చేస్తుంది.
- బాహ్య Git రిపోజిటరీలతో పని చేయడం వలన ప్రతిసారీ మొత్తం రిపోజిటరీని క్లోన్ చేయడం లేదా గమ్మత్తైన ఆప్టిమైజేషన్ లాజిక్తో చక్రాన్ని తిరిగి ఆవిష్కరించడం అవసరం లేదు. werf కాష్ని ఉపయోగిస్తుంది మరియు క్లోనింగ్ను ఒక్కసారి మాత్రమే చేస్తుంది, ఆపై ఉపయోగిస్తుంది
fetchమరియు అవసరమైనప్పుడు మాత్రమే. - బిల్డ్ కాన్ఫిగరేషన్ ఫైల్లో గో టెంప్లేట్లను ఉపయోగించగల సామర్థ్యం
werf.yamlబాహ్య డేటాపై ఆధారపడి ఉండే అసెంబ్లీని వివరించడానికి మిమ్మల్ని అనుమతిస్తుంది. - వెర్ఫ్లో మౌంట్ ఉపయోగించడం కళాఖండాల సేకరణను గణనీయంగా వేగవంతం చేస్తుంది - కాష్ కారణంగా, ఇది అన్ని పైప్లైన్లకు సాధారణం.
- werf క్లీనప్ని కాన్ఫిగర్ చేయడాన్ని సులభతరం చేస్తుంది, ఇది డైనమిక్గా నిర్మించేటప్పుడు చాలా ముఖ్యమైనది.
PS
మా బ్లాగులో కూడా చదవండి:
- «";
- «";
- «";
- «".
మూలం: www.habr.com
