વર્ઝન્ડ ડોક્યુમેન્ટેશન સાઇટના ઉદાહરણનો ઉપયોગ કરીને ડાઈનેમિક એસેમ્બલી અને વર્ફ સાથે ડોકર ઈમેજીસની જમાવટ

અમે અમારા GitOps ટૂલ વિશે એક કરતા વધુ વાર વાત કરી ચૂક્યા છીએ. વર્ફ, અને આ વખતે અમે પ્રોજેક્ટના દસ્તાવેજીકરણ સાથે સાઇટને એસેમ્બલ કરવાના અમારા અનુભવને શેર કરવા માંગીએ છીએ - werf.io (તેનું રશિયન સંસ્કરણ છે en.werf.io). આ એક સામાન્ય સ્થિર સાઇટ છે, પરંતુ તેની એસેમ્બલી રસપ્રદ છે કે તે કલાકૃતિઓની ગતિશીલ સંખ્યાનો ઉપયોગ કરીને બનાવવામાં આવી છે.

સાઇટ સ્ટ્રક્ચરની ઘોંઘાટમાં જાઓ: બધા સંસ્કરણો, પ્રકાશનો વિશેની માહિતી સાથેના પૃષ્ઠો વગેરે માટે એક સામાન્ય મેનૂ બનાવવું. - અમે નહીં કરીએ. તેના બદલે, ચાલો ગતિશીલ એસેમ્બલીના મુદ્દાઓ અને લક્ષણો પર ધ્યાન કેન્દ્રિત કરીએ અને સાથેની CI/CD પ્રક્રિયાઓ પર થોડું ધ્યાન આપીએ.

પરિચય: સાઇટ કેવી રીતે કાર્ય કરે છે

શરૂ કરવા માટે, werf દસ્તાવેજીકરણ તેના કોડ સાથે સંગ્રહિત છે. આ અમુક વિકાસ જરૂરિયાતો લાદે છે જે સામાન્ય રીતે આ લેખના અવકાશની બહાર હોય છે, પરંતુ ઓછામાં ઓછું એવું કહી શકાય કે:

• દસ્તાવેજીકરણને અપડેટ કર્યા વિના નવા werf ફંક્શન્સ રિલીઝ ન કરવા જોઈએ અને તેનાથી વિપરિત, દસ્તાવેજીકરણમાં કોઈપણ ફેરફારો વર્ફના નવા સંસ્કરણના પ્રકાશનને સૂચિત કરે છે;
• પ્રોજેક્ટમાં એકદમ સઘન વિકાસ છે: નવા સંસ્કરણો દિવસમાં ઘણી વખત પ્રકાશિત કરી શકાય છે;
• દસ્તાવેજોના નવા સંસ્કરણ સાથે સાઇટને જમાવવા માટે કોઈપણ મેન્યુઅલ કામગીરી ઓછામાં ઓછી કંટાળાજનક છે;
• પ્રોજેક્ટ સિમેન્ટીક અભિગમ અપનાવે છે સંસ્કરણ, 5 સ્થિરતા ચેનલો સાથે. પ્રકાશન પ્રક્રિયામાં સ્થિરતા વધારવા માટે ચેનલો દ્વારા આવૃત્તિઓના ક્રમિક માર્ગનો સમાવેશ થાય છે: આલ્ફાથી રોક-સોલિડ સુધી;
• સાઇટમાં રશિયન-ભાષાનું સંસ્કરણ છે, જે મુખ્ય (એટલે ​​​​કે, અંગ્રેજી-ભાષા) સંસ્કરણની સમાંતરમાં "જીવંત અને વિકાસ કરે છે" (એટલે ​​​​કે, જેની સામગ્રી અપડેટ કરવામાં આવે છે).

વપરાશકર્તા પાસેથી આ બધું "આંતરિક રસોડું" છુપાવવા માટે, તેને "ફક્ત કાર્ય કરે છે" એવી કંઈક ઓફર કરી, અમે કર્યું અલગ વેર્ફ ઇન્સ્ટોલેશન અને અપડેટ ટૂલ છે multiwerf. તમારે ફક્ત પ્રકાશન નંબર અને સ્થિરતા ચેનલનો ઉલ્લેખ કરવાની જરૂર છે જેનો તમે ઉપયોગ કરવા માટે તૈયાર છો, અને મલ્ટિવર્ફ ચૅનલ પર નવું સંસ્કરણ છે કે કેમ તે તપાસશે અને જો જરૂરી હોય તો તેને ડાઉનલોડ કરશે.

વેબસાઈટ પર વર્ઝન સિલેક્શન મેનૂમાં, દરેક ચેનલમાં werf ના નવીનતમ સંસ્કરણો ઉપલબ્ધ છે. મૂળભૂત રીતે, સરનામા દ્વારા werf.io/documentation નવીનતમ પ્રકાશન માટે સૌથી સ્થિર ચેનલનું સંસ્કરણ ખુલે છે - તે સર્ચ એન્જિન દ્વારા પણ અનુક્રમિત છે. ચેનલ માટે દસ્તાવેજીકરણ અલગ સરનામાં પર ઉપલબ્ધ છે (ઉદાહરણ તરીકે, werf.io/v1.0-beta/documentation બીટા રિલીઝ 1.0 માટે).

કુલમાં, સાઇટમાં નીચેના સંસ્કરણો ઉપલબ્ધ છે:

1. રુટ (ડિફૉલ્ટ રૂપે ખુલે છે),
2. દરેક પ્રકાશનની દરેક સક્રિય અપડેટ ચેનલ માટે (ઉદાહરણ તરીકે, werf.io/v1.0-beta).

સાઇટનું વિશિષ્ટ સંસ્કરણ જનરેટ કરવા માટે, સામાન્ય રીતે, તેનો ઉપયોગ કરીને કમ્પાઇલ કરવા માટે તે પૂરતું છે જેકિલડિરેક્ટરીમાં ચલાવીને /docs werf રીપોઝીટરી અનુરૂપ આદેશ (jekyll build), જરૂરી સંસ્કરણના Git ટેગ પર સ્વિચ કર્યા પછી.

તે ફક્ત ઉમેરવાનું બાકી છે:

• ઉપયોગિતા પોતે (werf) એસેમ્બલી માટે વપરાય છે;
• CI/CD પ્રક્રિયાઓ GitLab CI ના આધારે બનાવવામાં આવી છે;
• અને આ બધું, અલબત્ત, કુબરનેટ્સમાં ચાલે છે.

કાર્યો

હવે ચાલો એવા કાર્યોની રચના કરીએ જે વર્ણવેલ તમામ વિશિષ્ટતાઓને ધ્યાનમાં લે છે:

1. કોઈપણ અપડેટ ચેનલ પર werf સંસ્કરણ બદલ્યા પછી સાઇટ પર દસ્તાવેજીકરણ આપમેળે અપડેટ થવું જોઈએ.
2. વિકાસ માટે તમારે ક્યારેક સક્ષમ હોવું જરૂરી છે સાઇટના પૂર્વાવલોકન સંસ્કરણો જુઓ.

સંબંધિત ગિટ ટૅગ્સમાંથી કોઈપણ ચેનલ પર સંસ્કરણ બદલ્યા પછી સાઇટને ફરીથી કમ્પાઇલ કરવી આવશ્યક છે, પરંતુ છબી બનાવવાની પ્રક્રિયામાં અમને નીચેની સુવિધાઓ મળશે:

• ચેનલો પરના સંસ્કરણોની સૂચિ બદલાતી હોવાથી, જ્યાં સંસ્કરણ બદલાયું છે તે ચેનલો માટેના દસ્તાવેજીકરણને ફરીથી બનાવવું જરૂરી છે. છેવટે, બધું ફરીથી બનાવવું એ ખૂબ સરસ નથી.
• રિલીઝ માટે ચેનલોનો સેટ બદલાઈ શકે છે. અમુક સમયે, ઉદાહરણ તરીકે, ચેનલો પર પ્રારંભિક-એક્સેસ 1.1 પ્રકાશન કરતાં વધુ સ્થિર સંસ્કરણ ન હોઈ શકે, પરંતુ સમય જતાં તે દેખાશે - આ કિસ્સામાં, તમારે એસેમ્બલી જાતે જ બદલવી ન જોઈએ?

તે તારણ આપે છે કે એસેમ્બલી બાહ્ય ડેટા બદલવા પર આધાર રાખે છે.

Реализация

એક અભિગમ પસંદ કરી રહ્યા છીએ

વૈકલ્પિક રીતે, તમે કુબરનેટ્સમાં દરેક જરૂરી સંસ્કરણને અલગ પોડ તરીકે ચલાવી શકો છો. આ વિકલ્પ ક્લસ્ટરમાં મોટી સંખ્યામાં ઑબ્જેક્ટ સૂચવે છે, જે સ્થિર વર્ફ રિલીઝની સંખ્યામાં વધારો સાથે વધશે. અને આ, બદલામાં, વધુ જટિલ જાળવણી સૂચવે છે: દરેક સંસ્કરણનું પોતાનું HTTP સર્વર હોય છે, અને નાના લોડ સાથે. અલબત્ત, આમાં વધુ સંસાધન ખર્ચ પણ સામેલ છે.

અમે એ જ રસ્તો અપનાવ્યો બધા જરૂરી વર્ઝનને એક ઈમેજમાં એસેમ્બલ કરવું. સાઇટના તમામ સંસ્કરણોના સંકલિત સ્ટેટિક્સ NGINX સાથેના કન્ટેનરમાં સ્થિત છે, અને અનુરૂપ ડિપ્લોયમેન્ટ પર ટ્રાફિક NGINX ઇન્ગ્રેસ દ્વારા આવે છે. એક સરળ માળખું - એક સ્ટેટલેસ એપ્લિકેશન - તમને કુબરનેટ્સનો ઉપયોગ કરીને સરળતાથી જમાવટ (લોડ પર આધાર રાખીને) માપવા માટે પરવાનગી આપે છે.

વધુ ચોક્કસ થવા માટે, અમે બે છબીઓ એકત્રિત કરી રહ્યા છીએ: એક ઉત્પાદન સર્કિટ માટે, બીજી દેવ સર્કિટ માટે વધારાની છે. વધારાની ઇમેજનો ઉપયોગ મુખ્ય સાથે માત્ર ડેવ સર્કિટ પર થાય છે (લોન્ચ કરવામાં આવે છે) અને તેમાં રિવ્યુ કમિટમાંથી સાઇટનું વર્ઝન હોય છે, અને તેમની વચ્ચે રૂટીંગ ઇન્ગ્રેસ સંસાધનોનો ઉપયોગ કરીને કરવામાં આવે છે.

werf vs git ક્લોન અને આર્ટિફેક્ટ્સ

પહેલેથી જ ઉલ્લેખ કર્યો છે તેમ, દસ્તાવેજોના ચોક્કસ સંસ્કરણ માટે સાઇટ સ્ટેટિક્સ જનરેટ કરવા માટે, તમારે યોગ્ય રીપોઝીટરી ટેગ પર સ્વિચ કરીને બિલ્ડ કરવાની જરૂર છે. તમે દરેક વખતે જ્યારે તમે બિલ્ડ કરો ત્યારે રીપોઝીટરીને ક્લોન કરીને પણ કરી શકો છો, યાદીમાંથી યોગ્ય ટૅગ્સ પસંદ કરીને. જો કે, આ એક જગ્યાએ સંસાધન-સઘન કામગીરી છે અને વધુમાં, બિન-તુચ્છ સૂચનાઓ લખવાની જરૂર છે... બીજો ગંભીર ગેરલાભ એ છે કે આ અભિગમ સાથે એસેમ્બલી દરમિયાન કંઈક કેશ કરવાની કોઈ રીત નથી.

અહીં werf ઉપયોગિતા પોતે જ અમારી સહાય માટે આવે છે, અમલીકરણ કરે છે સ્માર્ટ કેશીંગ અને તમને ઉપયોગ કરવાની મંજૂરી આપે છે બાહ્ય ભંડાર. રીપોઝીટરીમાંથી કોડ ઉમેરવા માટે werf નો ઉપયોગ કરવાથી બિલ્ડને નોંધપાત્ર રીતે વેગ મળશે, કારણ કે werf આવશ્યકપણે રિપોઝીટરીને એકવાર ક્લોન કરે છે અને પછી એક્ઝિક્યુટ કરે છે માત્ર fetch જો જરૂરી હોય તો. વધુમાં, રીપોઝીટરીમાંથી ડેટા ઉમેરતી વખતે, અમે ફક્ત જરૂરી ડિરેક્ટરીઓ જ પસંદ કરી શકીએ છીએ (અમારા કિસ્સામાં આ ડિરેક્ટરી છે. docs), જે ઉમેરાયેલ ડેટાની માત્રામાં નોંધપાત્ર ઘટાડો કરશે.

જેકિલ એ સ્ટેટિક ડેટાને કમ્પાઈલ કરવા માટે રચાયેલ એક સાધન છે અને અંતિમ ઈમેજમાં તેની જરૂર નથી, તેથી તેમાં કમ્પાઈલ કરવું તાર્કિક રહેશે. werf આર્ટિફેક્ટ, અને અંતિમ છબીમાં માત્ર સંકલન પરિણામ આયાત કરો.

અમે werf.yaml લખીએ છીએ

તેથી, અમે નક્કી કર્યું કે અમે દરેક વર્ઝનને એક અલગ વર્ફ આર્ટિફેક્ટમાં કમ્પાઈલ કરીશું. જો કે અમે અમને ખબર નથી કે એસેમ્બલી દરમિયાન આમાંથી કેટલી કલાકૃતિઓ હશે, તેથી અમે નિશ્ચિત બિલ્ડ રૂપરેખાંકન લખી શકતા નથી (સખત રીતે કહીએ તો, અમે હજી પણ કરી શકીએ છીએ, પરંતુ તે સંપૂર્ણપણે અસરકારક રહેશે નહીં).

werf તમને ઉપયોગ કરવાની મંજૂરી આપે છે નમૂનાઓ પર જાઓ તમારી રૂપરેખાંકન ફાઈલમાં (werf.yaml), અને આ તે શક્ય બનાવે છે ફ્લાય પર રૂપરેખા બનાવો બાહ્ય ડેટા પર આધાર રાખીને (તમને શું જોઈએ છે!). અમારા કિસ્સામાં બાહ્ય ડેટા એ સંસ્કરણો અને પ્રકાશનો વિશેની માહિતી છે, જેના આધારે અમે જરૂરી સંખ્યામાં આર્ટિફેક્ટ્સ એકત્રિત કરીએ છીએ અને પરિણામે અમે બે છબીઓ મેળવીએ છીએ: werf-doc и werf-dev વિવિધ સર્કિટ પર ચલાવવા માટે.

બાહ્ય ડેટા પર્યાવરણ ચલો દ્વારા પસાર થાય છે. અહીં તેમની રચના છે:

• RELEASES - ફોર્મેટમાં મૂલ્યોની જગ્યા-વિભાજિત સૂચિના સ્વરૂપમાં, પ્રકાશનોની સૂચિ અને વર્ફના અનુરૂપ વર્તમાન સંસ્કરણ સાથેની એક રેખા <НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>. ઉદાહરણ: 1.0%v1.0.4-beta.20
• CHANNELS - ચેનલોની સૂચિ અને werf ના અનુરૂપ વર્તમાન સંસ્કરણ સાથેની એક રેખા, ફોર્મેટમાં મૂલ્યોની જગ્યા-વિભાજિત સૂચિના સ્વરૂપમાં <КАНАЛ>%<НОМЕР_ВЕРСИИ>. ઉદાહરણ: 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. જો ત્યાં કોઈ પર્યાવરણ ચલ ન હોય તો વર્ફ-દેવ ઈમેજ બિલકુલ જનરેટ ન કરવું શક્ય બનશે REVIEW_SHA, પરંતુ ક્રમમાં નીતિઓ દ્વારા સફાઈ werf માં ડોકર ઇમેજોએ werf-dev ઇમેજ માટે કામ કર્યું હતું, અમે તેને ફક્ત રૂટ વર્ઝન આર્ટિફેક્ટ (તે પહેલેથી જ કોઈપણ રીતે બનેલ છે) સાથે બાંધવા માટે છોડીશું, જેથી પાઇપલાઇન સ્ટ્રક્ચરને સરળ બનાવી શકાય.

એસેમ્બલી તૈયાર છે! ચાલો CI/CD અને મહત્વપૂર્ણ ઘોંઘાટ તરફ આગળ વધીએ.

GitLab CI માં પાઇપલાઇન અને ડાયનેમિક બિલ્ડની સુવિધાઓ

બિલ્ડ ચલાવતી વખતે આપણે ઉપયોગમાં લેવાતા પર્યાવરણ ચલોને સેટ કરવાની જરૂર છે 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 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 માં અનુરૂપ વેબહૂક બનાવો (સેટિંગ્સ -> વેબહુક્સ).

બિલ્ડ સ્ટેજ આના જેવો દેખાશે:

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

ગિટલેબ સ્ટેજથી બિલ્ડ સ્ટેજ પર બે આર્ટિફેક્ટ ઉમેરશે પૂર્વનિર્માણ, તેથી અમે કન્સ્ટ્રક્ટનો ઉપયોગ કરીને તૈયાર ઇનપુટ ડેટા સાથે ચલોની નિકાસ કરીએ છીએ 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 એ જમાવટ કરવી જોઈએ (WERF_KUBE_CONTEXT), અને લૂપ એન્વાયર્નમેન્ટ વેરિયેબલ સેટ કરી રહ્યા છે (environment.name и environment.url), જે પછી હેલ્મ ચાર્ટ ટેમ્પલેટ્સમાં વપરાય છે. અમે નમૂનાઓની સામગ્રી પ્રદાન કરીશું નહીં, કારણ કે... પ્રશ્નમાં વિષય માટે ત્યાં કંઈ રસપ્રદ નથી, પરંતુ તમે તેને તેમાં શોધી શકો છો લેખ માટે ભંડાર.

અંતિમ સ્પર્શ

werf આવૃત્તિઓ ઘણી વાર બહાર પાડવામાં આવતી હોવાથી, નવી છબીઓ વારંવાર બનાવવામાં આવશે, અને ડોકર રજિસ્ટ્રી સતત વધશે. તેથી, નીતિઓના આધારે સ્વચાલિત ઇમેજ ક્લિનઅપને ગોઠવવું હિતાવહ છે. તે કરવું ખૂબ જ સરળ છે.

અમલ કરવા માટે તમારે આની જરૂર પડશે:

• માં સફાઈ પગલું ઉમેરો .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 ->
શેડ્યુલ્સ.

બસ આટલું જ: ડોકર રજિસ્ટ્રીમાંનો પ્રોજેક્ટ હવે બિનઉપયોગી ઈમેજોથી સતત વધશે નહીં.

વ્યવહારુ ભાગના અંતે, હું તમને યાદ અપાવી દઉં કે લેખમાંથી સંપૂર્ણ સૂચિઓ આમાં ઉપલબ્ધ છે ગિટ:

• .gitlab-ci.yml;
• werf.yaml.

પરિણામ

1. અમને લોજિકલ એસેમ્બલી માળખું પ્રાપ્ત થયું: સંસ્કરણ દીઠ એક આર્ટિફેક્ટ.
2. એસેમ્બલી સાર્વત્રિક છે અને જ્યારે werf ના નવા સંસ્કરણો બહાર પાડવામાં આવે ત્યારે મેન્યુઅલ ફેરફારોની જરૂર નથી: વેબસાઇટ પરના દસ્તાવેજો આપમેળે અપડેટ થાય છે.
3. બે છબીઓ વિવિધ રૂપરેખા માટે એસેમ્બલ કરવામાં આવે છે.
4. તે ઝડપથી કામ કરે છે, કારણ કે કેશીંગનો શક્ય તેટલો ઉપયોગ કરવામાં આવે છે - જ્યારે werf નું નવું સંસ્કરણ બહાર પાડવામાં આવે છે અથવા GitHub હૂકને સમીક્ષા કમિટ માટે બોલાવવામાં આવે છે, ત્યારે માત્ર બદલાયેલ સંસ્કરણ સાથે અનુરૂપ આર્ટિફેક્ટ ફરીથી બનાવવામાં આવે છે.
5. બિનઉપયોગી છબીઓ કાઢી નાખવા વિશે વિચારવાની જરૂર નથી: werf નીતિઓ અનુસાર સફાઈ ડોકર રજિસ્ટ્રીને વ્યવસ્થિત રાખશે.

તારણો

• werf નો ઉપયોગ કરવાથી એસેમ્બલીની કેશીંગ અને બાહ્ય રીપોઝીટરીઓ સાથે કામ કરતી વખતે કેશીંગ બંનેને કારણે એસેમ્બલી ઝડપથી કામ કરવા દે છે.
• બાહ્ય ગિટ રિપોઝીટરીઝ સાથે કામ કરવાથી દરેક વખતે સમગ્ર રીપોઝીટરીને ક્લોન કરવાની અથવા મુશ્કેલ ઓપ્ટિમાઇઝેશન લોજીક સાથે વ્હીલને ફરીથી શોધવાની જરૂરિયાતને દૂર કરે છે. werf કેશનો ઉપયોગ કરે છે અને માત્ર એક જ વાર ક્લોનિંગ કરે છે, અને પછી ઉપયોગ કરે છે fetch અને જ્યારે જરૂરી હોય ત્યારે જ.
• બિલ્ડ રૂપરેખાંકન ફાઇલમાં ગો નમૂનાઓનો ઉપયોગ કરવાની ક્ષમતા werf.yaml તમને એસેમ્બલીનું વર્ણન કરવાની મંજૂરી આપે છે જેનું પરિણામ બાહ્ય ડેટા પર આધારિત છે.
• માઉન્ટ ઇન વેર્ફનો ઉપયોગ નોંધપાત્ર રીતે કલાકૃતિઓના સંગ્રહને ઝડપી બનાવે છે - કેશને કારણે, જે બધી પાઇપલાઇન્સ માટે સામાન્ય છે.
• werf સફાઈને રૂપરેખાંકિત કરવાનું સરળ બનાવે છે, જે ગતિશીલ રીતે નિર્માણ કરતી વખતે ખાસ કરીને મહત્વપૂર્ણ છે.

PS

અમારા બ્લોગ પર પણ વાંચો:

• «કુબરનેટ્સને નવી એપ્લિકેશન રીલીઝ વિતરિત કરતી વખતે આદેશો ચલાવી રહ્યા છે»;
• «werf અને GitLab CI સાથે સમાન પ્રકારની માઇક્રોસર્વિસિસ બનાવો અને તેનો ઉપયોગ કરો»;
• «જટિલ હેલ્મ ચાર્ટ બનાવવા માટે werf નો ઉપયોગ કરવો»;
• «werf 1.0 stable નો પરિચય: GitOps ને તેની સાથે શું લેવાદેવા છે, સ્થિતિ અને યોજનાઓ».

સોર્સ: www.habr.com