使用版本化文档的示例站点使用werf动态组装和部署Docker映像

简介：网站的布置方式

• 在不更新文档的情况下，不应发布新的werf函数，相反，文档中的任何更改都意味着将发布新版本的werf；
• 该项目的开发相当密集：新版本可能一天要发布几次；
• 使用新版本的文档对网站进行的任何手动部署至少都是乏味的；
• 该项目采用语义版本控制的方法，具有5个稳定通道。 释放过程涉及版本通过通道的顺序传递，以增加稳定性：从alpha到坚如磐石；
• 该网站有俄语版本，与主要版本（即英语版本）并行“实时发展”（即其内容已更新）。

1. 根（默认情况下打开）
2. 每个发行版的每个活动更新通道（例如werf.io/v1.0-beta ）。

• 实用程序本身（werf）用于组装；
• CI / CD流程基于GitLab CI；
• 当然，所有这些都可以在Kubernetes中使用。

任务

1. 在任何更新渠道上更改werf版本之后， 应自动更新站点上的文档 。
2. 为了进行开发，您有时需要能够预览站点的初步版本 。

• 随着通道上版本列表的更改，仅需要重新组装版本已更改的通道的文档。 毕竟，重新组装一切并不是一件很漂亮的事情。
• 发布渠道的集合可能会有所不同。 例如，在某个时间点上，通道上的版本可能不会比早期访问的1.1版本更稳定，但是随着时间的流逝它们会出现-在这种情况下不手动更改组件吗？

实作

方法的选择

werf vs git克隆和工件

编写werf.yaml

• RELEASES-包含发行版列表和对应的werf当前版本的行，以列表的形式，以空格分隔，格式为<_>%<_> 。 示例： 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您需要从中收集测试循环版本的审阅提交的哈希值。

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

• 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 }} 

 {{ 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 }} 

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

GitLab CI中的管道和动态装配的功能

• 带有发布数据的releases.yml文件，
• 包含要导出的环境变量的文件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' 

 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 

 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 

 .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 

最后一点

• 在.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.yml ;
• werf.yaml 。

结果

1. 我们得到了一个合理的构建结构：每个版本一个工件。
2. 程序集是通用的，发布新版本的werf时不需要手动更改：站点上的文档会自动更新。
3. 针对不同的轮廓收集了两个图像。
4. 它工作很快，因为 最大限度地利用了缓存-当发布新版本的werf或调用GitHub钩子进行审阅提交时，仅会重建具有修改版本的相应工件。
5. 无需考虑删除未使用的映像：werf策略清理将维护Docker Registry中的顺序。

结论

• 使用werf可以使程序集快速运行，这要归功于程序集本身的缓存和使用外部存储库时的缓存。
• 使用外部Git存储库无需每次都完全克隆存储库，也无需使用棘手的优化逻辑重新发明轮子。werf使用缓存并且仅克隆一次，然后fetch仅在必要时使用它。
• 在程序集配置文件中使用Go模板的werf.yaml功能使您能够描述程序集，其结果取决于外部数据。
• 在werf中使用挂载可显着加快工件的收集速度，这是由于高速缓存是所有管道所共有的。
• werf使清洁变得容易，对于动态构建尤其如此。

聚苯乙烯

• « Kubernetes »;
• « werf GitLab CI »;
• « werf Helm- »;
• « werf 1.0 stable: GitOps, ».