Xa falamos máis dunha vez da nosa ferramenta GitOps. , e nesta ocasión gustaríanos compartir a nosa experiencia na montaxe do xacemento coa documentación do propio proxecto - (a súa versión rusa é ). Este é un sitio estático común, pero a súa montaxe é interesante porque está construído utilizando un número dinámico de artefactos.
Entra nos matices da estrutura do sitio: xerando un menú común para todas as versións, páxinas con información sobre lanzamentos, etc. - non o faremos. En vez diso, centrémonos nos problemas e características da montaxe dinámica e un pouco nos procesos CI/CD que o acompañan.
Introdución: como funciona o sitio
Para comezar, a documentación de werf almacénase xunto co seu código. Isto impón certos requisitos de desenvolvemento que en xeral están fóra do ámbito deste artigo, pero como mínimo pódese dicir que:
- As novas funcións de werf non se deben lanzar sen actualizar a documentación e, pola contra, calquera cambio na documentación implica o lanzamento dunha nova versión de werf;
- O proxecto ten un desenvolvemento bastante intenso: pódense lanzar novas versións varias veces ao día;
- Calquera operación manual para despregar un sitio cunha nova versión da documentación é polo menos tediosa;
- O proxecto adopta un enfoque semántico , con 5 canles de estabilidade. O proceso de lanzamento implica o paso secuencial de versións a través de canles en orde crecente de estabilidade: de alfa a sólido como rocha;
- O sitio ten unha versión en ruso, que "vive e se desenvolve" (é dicir, cuxo contido se actualiza) en paralelo coa versión principal (é dicir, en inglés).
Para ocultarlle ao usuario toda esta "cociña interior", ofrecéndolle algo que "simplemente funciona", fixemos ferramenta separada de instalación e actualización de werf - É . Só tes que especificar o número de versión e a canle de estabilidade que estás preparado para usar, e multiwerf comprobará se hai unha nova versión na canle e descargala se é necesario.
No menú de selección de versións do sitio web, as últimas versións de werf están dispoñibles en cada canle. Por defecto, por enderezo ábrese a versión da canle máis estable para a última versión; tamén está indexada polos buscadores. A documentación para a canle está dispoñible en enderezos separados (por exemplo, para a versión beta 1.0).
En total, o sitio ten dispoñibles as seguintes versións:
- root (abre por defecto),
- para cada canle de actualización activa de cada versión (por exemplo, ).
Para xerar unha versión específica dun sitio, en xeral, abonda con compilalo usando executando no directorio /docs comando correspondente do repositorio werf (jekyll build), despois de cambiar á etiqueta Git da versión requirida.
Só queda engadir que:
- a propia utilidade (werf) úsase para a montaxe;
- Os procesos CI/CD constrúense en base a GitLab CI;
- e todo isto, por suposto, corre en Kubernetes.
tarefas
Agora imos formular tarefas que teñan en conta todas as especificacións descritas:
- Despois de cambiar a versión de werf en calquera canle de actualización a documentación do sitio debe actualizarse automaticamente.
- Para o desenvolvemento cómpre ser capaz ás veces ver versións previas do sitio.
O sitio debe recompilarse despois de cambiar a versión en calquera canle das etiquetas Git correspondentes, pero no proceso de construción da imaxe obteremos as seguintes características:
- Dado que a lista de versións das canles cambia, só é necesario reconstruír a documentación das canles onde a versión cambiou. Despois de todo, reconstruír todo de novo non é moi agradable.
- O conxunto de canles para os lanzamentos pode cambiar. Nalgún momento, por exemplo, pode que non haxa unha versión nas canles máis estable que a versión 1.1 de acceso anticipado, pero co paso do tempo aparecerán; neste caso, non deberías cambiar a montaxe manualmente?
Acontece que a montaxe depende de cambiar os datos externos.
Implantación
Elixindo un enfoque
Como alternativa, pode executar cada versión necesaria como un pod separado en Kubernetes. Esta opción implica un maior número de obxectos no clúster, que crecerá co aumento do número de lanzamentos de werf estables. E isto, á súa vez, implica un mantemento máis complexo: cada versión ten o seu propio servidor HTTP, e cunha pequena carga. Por suposto, isto tamén implica un maior custo de recursos.
Tomamos o mesmo camiño reunindo todas as versións necesarias nunha soa imaxe. As estáticas compiladas de todas as versións do sitio están situadas nun contedor con NGINX, e o tráfico á implementación correspondente chega a través de NGINX Ingress. Unha estrutura sinxela (unha aplicación sen estado) permítelle escalar facilmente a implementación (dependendo da carga) usando o propio Kubernetes.
Para ser máis precisos, recollemos dúas imaxes: unha para o circuíto de produción, a segunda é outra adicional para o circuíto de desenvolvemento. A imaxe adicional utilízase (lanzada) só no circuíto de desenvolvemento xunto co principal e contén a versión do sitio do commit de revisión, e o enrutamento entre eles realízase mediante recursos de Ingress.
werf vs git clon e artefactos
Como xa se mencionou, para xerar estática do sitio para unha versión específica da documentación, cómpre compilar cambiando á etiqueta de repositorio adecuada. Tamén podes facelo clonando o repositorio cada vez que creas, seleccionando as etiquetas adecuadas dunha lista. Non obstante, esta é unha operación bastante intensiva en recursos e, ademais, require escribir instrucións non triviais... Outra desvantaxe grave é que con este enfoque non hai forma de almacenar algo na caché durante a montaxe.
Aquí a propia utilidade werf vén na nosa axuda, implementando caché intelixente e permítelle usar . Usar werf para engadir código do repositorio acelerará significativamente a compilación, porque werf clona esencialmente o repositorio unha vez e despois execútase só fetch Se é necesario. Ademais, ao engadir datos do repositorio, podemos seleccionar só os directorios necesarios (no noso caso este é o directorio docs), o que reducirá significativamente a cantidade de datos engadidos.
Dado que Jekyll é unha ferramenta deseñada para compilar datos estáticos e non é necesaria na imaxe final, sería lóxico compilar en , e na imaxe final importa só o resultado da compilación.
Escribimos werf.yaml
Entón, decidimos que compilaríamos cada versión nun artefacto werf separado. Sen embargo nós non sabemos cantos destes artefactos haberá durante a montaxe, polo que non podemos escribir unha configuración de compilación fixa (en rigor, aínda podemos, pero non será totalmente eficaz).
werf permítelle usar no teu ficheiro de configuración (werf.yaml), e iso fai posible xerar configuración sobre a marcha dependendo dos datos externos (o que necesitas!). Os datos externos no noso caso son información sobre versións e lanzamentos, sobre a base dos cales recollemos o número necesario de artefactos e, como resultado, obtemos dúas imaxes: werf-doc и werf-dev para correr en diferentes circuítos.
Os datos externos pásanse a través de variables de ambiente. Velaquí a súa composición:
-
RELEASES- unha liña cunha lista de versións e a correspondente versión actual de werf, en forma de lista de valores separados por espazos no formato<НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>. Un exemplo:1.0%v1.0.4-beta.20 -
CHANNELS- unha liña cunha lista de canles e a correspondente versión actual de werf, en forma de lista de valores separados por espazos no formato<КАНАЛ>%<НОМЕР_ВЕРСИИ>. Un exemplo:1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22 -
ROOT_VERSION— Versión de versión de werf que se mostrará por defecto no sitio (non sempre é necesario mostrar a documentación polo número de versión máis alto). Exemplo:v1.0.4-beta.20 -
REVIEW_SHA— hash da confirmación de revisión a partir do que precisa crear a versión para o bucle de proba.
Estas variables encheranse na canalización de GitLab CI, e como se escribe exactamente a continuación.
En primeiro lugar, por comodidade, definimos en werf.yaml Vai ás variables do modelo, asignándolles valores das variables de ambiente:
{{ $_ := set . "WerfVersions" (cat (env "CHANNELS") (env "RELEASES") | splitList " ") }}
{{ $Root := . }}
{{ $_ := set . "WerfRootVersion" (env "ROOT_VERSION") }}
{{ $_ := set . "WerfReviewCommit" (env "REVIEW_SHA") }}
A descrición do artefacto para compilar a versión estática do sitio é xeralmente a mesma para todos os casos que necesitamos (incluída a xeración da versión raíz, así como a versión para o circuíto de desenvolvemento). Polo tanto, moverémolo a un bloque separado mediante a función define - para a súa posterior reutilización include. Pasaremos os seguintes argumentos ao modelo:
-
Version— versión xerada (nome da etiqueta); -
Channel— o nome da canle de actualización para a que se xera o artefacto; -
Commit— commit hash, se o artefacto se xera para un commit de revisión; - contexto.
Descrición do modelo de artefacto
{{- 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 }}
O nome do artefacto debe ser único. Podemos logralo, por exemplo, engadindo o nome da canle (o valor da variable .Channel) como sufixo para o nome do artefacto: artifact: doc-{{ .Channel }}. Pero cómpre entender que ao importar artefactos, terás que facer referencia aos mesmos nomes.
Ao describir un artefacto, utilízase a seguinte función de werf: . Montaxe indicando o directorio de servizos build_dir permítelle gardar a caché de Jekyll entre execucións de pipeline, o que acelera significativamente a montaxe.
Tamén pode ter notado o uso do ficheiro releases.yml é un ficheiro YAML con datos de versión solicitados (un artefacto obtido ao executar unha canalización). É necesario ao compilar o sitio, pero no contexto do artigo é interesante para nós porque depende do seu estado remontaxe dun só artefacto — un artefacto da versión raíz do sitio (non é necesario noutros artefactos).
Isto implícase mediante a instrución condicional if Vaia modelos e deseños {{ $Root.Files.Get "releases.yml" | sha256sum }} en etapa . Funciona do seguinte xeito: ao construír un artefacto para a versión raíz (variable .Channel é igual a root) ficheiro hash releases.yml afecta á sinatura de toda a etapa, xa que forma parte do nome da tarefa Ansible (parámetro name). Así, ao cambiar contido arquivo releases.yml volverase a montar o artefacto correspondente.
Tamén preste atención a traballar cun repositorio externo. Na imaxe dun artefacto de , só se engade o directorio /docs, e dependendo dos parámetros pasados, engádense inmediatamente os datos da etiqueta requirida ou do compromiso de revisión.
Para utilizar o modelo de artefacto para xerar unha descrición do artefacto das versións transferidas de canles e lanzamentos, organizamos un bucle na variable .WerfVersions в werf.yaml:
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ dict "Version" $VersionsDict._1 "Channel" $VersionsDict._0 "Root" $Root | include "doc_artifact" }}
---
{{ end -}}
Porque o bucle xerará varios artefactos (agardamos que si), é necesario ter en conta o separador entre eles: a secuencia --- (Para obter máis información sobre a sintaxe do ficheiro de configuración, consulte ). Como se definiu anteriormente, ao chamar un modelo nun bucle, pasamos os parámetros da versión, o URL e o contexto raíz.
Do mesmo xeito, pero sen bucle, chamamos ao modelo de artefacto para "casos especiais": para a versión raíz, así como a versión do commit de revisión:
{{ 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 }}
Teña en conta que o artefacto para o compromiso de revisión só se construirá se a variable está definida .WerfReviewCommit.
Os artefactos están listos: é hora de comezar a importar.
A imaxe final, deseñada para executarse en Kubernetes, é un NGINX normal cun ficheiro de configuración do servidor engadido nginx.conf e estática dos artefactos. Ademais do artefacto da versión raíz do sitio, necesitamos repetir o bucle na variable .WerfVersions para importar artefactos de versións de canle e lanzamento + siga a regra de nomeamento de artefactos que adoptamos anteriormente. Dado que cada artefacto almacena versións do sitio para dous idiomas, importámolas aos lugares proporcionados pola configuración.
Descrición da imaxe final 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 -}}A imaxe adicional, que, xunto coa principal, lánzase no circuíto de desenvolvemento, contén só dúas versións do sitio: a versión do commit de revisión e a versión raíz do sitio (hai recursos xerais e, se lembras, , datos de publicación). Así, a imaxe adicional diferirá da principal só na sección de importación (e, por suposto, no nome):
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 }}
Como se indicou anteriormente, o artefacto para o compromiso de revisión xerarase só cando se execute a variable de ambiente establecida REVIEW_SHA. Sería posible non xerar a imaxe werf-dev se non hai unha variable de ambiente REVIEW_SHA, pero para As imaxes Docker en werf funcionaron para a imaxe werf-dev, deixarémola construír só co artefacto da versión raíz (xa está construída de todos os xeitos), para simplificar a estrutura da canalización.
A montaxe está lista! Pasemos a CI/CD e matices importantes.
Pipeline en GitLab CI e características de compilación dinámica
Ao executar a compilación, necesitamos establecer as variables de ambiente utilizadas werf.yaml. Isto non se aplica á variable REVIEW_SHA, que estableceremos cando chamemos a canalización desde o gancho de GitHub.
Xeraremos os datos externos necesarios nun script Bash generate_artifacts, que xerará dous artefactos de pipeline de GitLab:
- файл
releases.ymlcon datos de publicación, - файл
common_envs.sh, que contén as variables de ambiente que se van exportar.
Contidos do ficheiro generate_artifacts atoparás na nosa . A recepción dos datos en si non é o tema do artigo, senón o arquivo common_envs.sh é importante para nós, porque diso depende o traballo de werf. Un exemplo do seu contido:
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'
Podes usar a saída deste script, por exemplo, usando a función Bash source.
Agora vén a parte divertida. Para que tanto a creación como a implantación da aplicación funcionen correctamente, é necesario asegurarse de que werf.yaml foi o mesmo menos dentro dunha canalización. Se non se cumpre esta condición, as sinaturas das etapas que werf calcula durante a montaxe e, por exemplo, o despregamento, serán diferentes. Isto levará a un erro de implantación, porque... faltará a imaxe necesaria para o despregamento.
Noutras palabras, se durante a montaxe da imaxe do sitio a información sobre lanzamentos e versións é a mesma, e no momento da implantación lánzase unha nova versión e as variables de ambiente teñen valores diferentes, a implantación fallará cun erro: despois de todo, o artefacto da nova versión aínda non foi construído.
Se xeración werf.yaml depende de datos externos (por exemplo, unha lista de versións actuais, como no noso caso), entón a composición e os valores destes datos deberían rexistrarse dentro da canalización. Isto é especialmente importante se os parámetros externos cambian con bastante frecuencia.
Iremos recibir e rexistrar datos externos na primeira etapa do pipeline en GitLab (Preconstrución) e transmíteos máis adiante na forma Artefacto de GitLab CI. Isto permitirache executar e reiniciar traballos de canalización (construción, implantación, limpeza) coa mesma configuración werf.yaml.
Contidos da etapa Preconstrución arquivo .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 weekDespois de capturar os datos externos no artefacto, podes construír e implementar usando as fases estándar de pipeline de GitLab CI: Construír e implementar. Lanzamos a canalización en si usando ganchos desde o repositorio de GitHub werf (é dicir, cando hai cambios no repositorio de GitHub). Os datos para eles pódense atopar nas propiedades do proxecto GitLab na sección Configuración de CI/CD -> Activadores de pipeline, e despois cree o Webhook correspondente en GitHub (Configuración -> Webhooks).
A fase de construción terá o seguinte aspecto:
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 engadirá dous artefactos desde o escenario ata a fase de construción Preconstrución, polo que exportamos variables cos datos de entrada preparados mediante a construción source common_envs.sh. Comezamos a fase de construción en todos os casos, excepto para o lanzamento do gasoduto segundo un calendario. Segundo o calendario, executaremos unha canalización para a limpeza, neste caso non é necesario realizar a montaxe.
Na fase de implantación, describiremos dúas tarefas, por separado para a implantación en circuítos de produción e desenvolvemento, utilizando un modelo 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
As tarefas difiren esencialmente só ao indicar o contexto do clúster no que werf debería realizar a implantación (WERF_KUBE_CONTEXT), e establecendo as variables de entorno do bucle (environment.name и environment.url), que despois se usan nos modelos de gráficos Helm. Non proporcionaremos o contido dos modelos, porque... non hai nada interesante para o tema en cuestión, pero podes atopalos en .
Preme final
Dado que as versións de werf se lanzan con bastante frecuencia, crearanse novas imaxes con frecuencia e o Rexistro Docker crecerá constantemente. Polo tanto, é imprescindible configurar a limpeza automática de imaxes en función das políticas. É moi doado de facer.
Para implementar necesitarás:
- Engade un paso de limpeza a
.gitlab-ci.yml; - Engadir a execución periódica dunha tarefa de limpeza;
- Configure unha variable de ambiente cun token de acceso de escritura.
Engadindo unha fase de limpeza a .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
Xa vimos case todo isto xusto arriba; só para limpalo, primeiro cómpre iniciar sesión no Rexistro de Docker cun token que teña dereitos para eliminar imaxes no Rexistro de Docker (o token de tarefas CI de GitLab emitido automaticamente non ten tales dereitos). O token debe crearse previamente en GitLab e o seu valor debe especificarse na variable de ambiente WERF_IMAGES_CLEANUP_PASSWORD o proxecto (Configuración CI/CD -> Variables).
Engadir unha tarefa de limpeza co horario necesario realízase en CI/CD ->
Horarios.
Iso é todo: un proxecto no Rexistro Docker xa non crecerá constantemente a partir de imaxes non utilizadas.
Ao final da parte práctica, permíteme recordarche que as listaxes completas do artigo están dispoñibles en :
- ;
- .
Resultado
- Recibimos unha estrutura de montaxe lóxica: un artefacto por versión.
- A montaxe é universal e non require cambios manuais cando se lanzan novas versións de werf: a documentación da páxina web actualízase automaticamente.
- Reúnense dúas imaxes para diferentes contornos.
- Funciona rapidamente, porque O caché utilízase na medida do posible: cando se lanza unha nova versión de werf ou se chama a un gancho de GitHub para unha revisión, só se reconstruírá o artefacto correspondente coa versión modificada.
- Non hai que pensar en eliminar imaxes non utilizadas: a limpeza segundo as políticas de werf manterá o Rexistro Docker en orde.
Descubrimentos
- Usar werf permite que o conxunto funcione rapidamente debido ao almacenamento en caché tanto do conxunto como do caché cando se traballa con repositorios externos.
- Traballar con repositorios Git externos elimina a necesidade de clonar todo o repositorio cada vez ou reinventar a roda cunha lóxica de optimización complicada. werf usa unha caché e fai a clonación só unha vez, e despois usa
fetche só cando sexa necesario. - Capacidade de usar modelos de Go no ficheiro de configuración de compilación
werf.yamlpermite describir un conxunto cuxo resultado depende de datos externos. - O uso de mount in werf acelera significativamente a recollida de artefactos, debido á caché, que é común a todas as canalizacións.
- werf facilita a configuración da limpeza, o que é especialmente importante cando se constrúe de forma dinámica.
PS
Lea tamén no noso blog:
- «»;
- «»;
- «»;
- «».
Fonte: www.habr.com