Ja hem parlat més d'una vegada de la nostra eina GitOps. , i aquesta vegada ens agradaria compartir la nostra experiència en el muntatge del solar amb la documentació del projecte en si - (la seva versió russa és ). Aquest és un lloc estàtic normal, però el seu muntatge és interessant perquè es construeix utilitzant un nombre dinàmic d'artefactes.
Entreu en els matisos de l'estructura del lloc: generació d'un menú comú per a totes les versions, pàgines amb informació sobre llançaments, etc. - no ho farem. En lloc d'això, centrem-nos en els problemes i les característiques del muntatge dinàmic i una mica en els processos CI/CD que l'acompanyen.
Introducció: com funciona el lloc
Per començar, la documentació werf s'emmagatzema juntament amb el seu codi. Això imposa certs requisits de desenvolupament que generalment estan fora de l'abast d'aquest article, però com a mínim es pot dir que:
- No s'han d'alliberar noves funcions de werf sense actualitzar la documentació i, per contra, qualsevol canvi en la documentació implica el llançament d'una nova versió de werf;
- El projecte té un desenvolupament força intensiu: es poden llançar noves versions diverses vegades al dia;
- Qualsevol operació manual per desplegar un lloc amb una nova versió de la documentació és almenys tediosa;
- El projecte adopta un enfocament semàntic , amb 5 canals d'estabilitat. El procés de llançament implica el pas seqüencial de versions a través de canals per ordre d'estabilitat creixent: d'alfa a sòlid com a roca;
- El lloc té una versió en rus, que "viu i es desenvolupa" (és a dir, el contingut de la qual s'actualitza) paral·lelament a la versió principal (és a dir, en anglès).
Per amagar tota aquesta "cuina interior" a l'usuari, oferint-li una cosa que "només funciona", vam fer eina separada d'instal·lació i actualització de werf - És . Només cal que especifiqueu el número de llançament i el canal d'estabilitat que esteu preparat per utilitzar, i multiwerf comprovarà si hi ha una versió nova al canal i la descarregarà si cal.
Al menú de selecció de versions del lloc web, les últimes versions de werf estan disponibles a cada canal. Per defecte, per adreça s'obre la versió del canal més estable per a la darrera versió; també està indexada pels motors de cerca. La documentació del canal està disponible en adreces separades (per exemple, per a la versió beta 1.0).
En total, el lloc té les següents versions disponibles:
- root (obre per defecte),
- per a cada canal d'actualització actiu de cada llançament (per exemple, ).
Per generar una versió específica d'un lloc, en general, n'hi ha prou de compilar-la utilitzant executant-se al directori /docs ordre corresponent al repositori werf (jekyll build), després de canviar a l'etiqueta Git de la versió requerida.
Només queda afegir que:
- la pròpia utilitat (werf) s'utilitza per al muntatge;
- Els processos CI/CD es construeixen sobre la base de GitLab CI;
- i tot això, per descomptat, funciona a Kubernetes.
tasques
Ara formulem tasques que tinguin en compte tots els detalls descrits:
- Després de canviar la versió werf en qualsevol canal d'actualització La documentació del lloc s'ha d'actualitzar automàticament.
- Per al desenvolupament cal ser capaç de vegades veure versions de vista prèvia del lloc.
El lloc s'ha de recompilar després de canviar la versió de qualsevol canal a partir de les etiquetes Git corresponents, però en el procés de creació de la imatge obtindrem les següents característiques:
- Com que la llista de versions dels canals canvia, només cal reconstruir la documentació dels canals on la versió ha canviat. Després de tot, reconstruir-ho tot de nou no és molt agradable.
- El conjunt de canals per als llançaments pot canviar. En algun moment, per exemple, pot ser que no hi hagi una versió als canals més estable que la versió 1.1 d'accés anticipat, però amb el temps apareixeran; en aquest cas, no hauríeu de canviar el muntatge manualment?
Resulta que El muntatge depèn del canvi de dades externes.
Implementació
L'elecció d'un enfocament
Alternativament, podeu executar cada versió necessària com a pod independent a Kubernetes. Aquesta opció implica un nombre més gran d'objectes al clúster, que creixerà amb l'augment del nombre de llançaments estables de werf. I això, al seu torn, implica un manteniment més complex: cada versió té el seu propi servidor HTTP, i amb una petita càrrega. Per descomptat, això també comporta majors costos de recursos.
Hem agafat el mateix camí reunint totes les versions necessàries en una imatge. L'estàtica compilada de totes les versions del lloc es troba en un contenidor amb NGINX i el trànsit al desplegament corresponent arriba a través de NGINX Ingress. Una estructura senzilla, una aplicació sense estat, us permet escalar fàcilment el desplegament (segons la càrrega) mitjançant el mateix Kubernetes.
Per ser més precisos, estem recopilant dues imatges: una per al circuit de producció, la segona és una altra addicional per al circuit de desenvolupament. La imatge addicional s'utilitza (llança) només al circuit de desenvolupament juntament amb el principal i conté la versió del lloc del commit de revisió, i l'encaminament entre ells es realitza mitjançant recursos d'entrada.
werf vs git clon i artefactes
Com ja s'ha esmentat, per generar estàtica del lloc per a una versió específica de la documentació, heu de crear canviant a l'etiqueta de repositori adequada. També podeu fer-ho clonant el dipòsit cada vegada que creeu, seleccionant les etiquetes adequades d'una llista. Tanmateix, es tracta d'una operació força intensiva en recursos i, a més, requereix escriure instruccions no trivials... Un altre desavantatge greu és que amb aquest enfocament no hi ha manera de guardar alguna cosa a la memòria cau durant el muntatge.
Aquí la pròpia utilitat werf ve en la nostra ajuda, implementant-la memòria cau intel·ligent i que us permet fer servir . L'ús de werf per afegir codi del repositori accelerarà significativament la compilació, perquè werf bàsicament clona el dipòsit una vegada i després s'executa només fetch si és necessari. A més, en afegir dades del repositori, només podem seleccionar els directoris necessaris (en el nostre cas aquest és el directori docs), que reduirà significativament la quantitat de dades afegides.
Com que Jekyll és una eina dissenyada per compilar dades estàtiques i no és necessària a la imatge final, seria lògic compilar en , i a la imatge final importa només el resultat de la compilació.
Escrivim werf.yaml
Per tant, vam decidir que compilaríem cada versió en un artefacte werf independent. Tanmateix nosaltres no sabem quants d'aquests artefactes hi haurà durant el muntatge, de manera que no podem escriure una configuració de construcció fixa (en sentit estricte, encara podem, però no serà del tot eficaç).
werf us permet utilitzar al vostre fitxer de configuració (werf.yaml), i això ho fa possible genera la configuració sobre la marxa en funció de les dades externes (el que necessiteu!). Les dades externes en el nostre cas són informació sobre versions i llançaments, sobre la base de les quals recollim el nombre d'artefactes requerits i com a resultat obtenim dues imatges: werf-doc и werf-dev per córrer en diferents circuits.
Les dades externes es passen a través de variables d'entorn. Aquí teniu la seva composició:
-
RELEASES— una línia amb una llista de versions i la versió actual corresponent de werf, en forma de llista de valors separats per espais en el format<НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>... Exemple:1.0%v1.0.4-beta.20 -
CHANNELS— una línia amb una llista de canals i la versió actual corresponent de werf, en forma de llista de valors separats per espais en el format<КАНАЛ>%<НОМЕР_ВЕРСИИ>... Exemple:1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22 -
ROOT_VERSION— La versió de la versió werf es mostrarà per defecte al lloc (no sempre és necessari mostrar la documentació pel número de llançament més alt). Exemple:v1.0.4-beta.20 -
REVIEW_SHA— hash de la confirmació de revisió a partir del qual heu de crear la versió per al bucle de prova.
Aquestes variables s'ompliran al pipeline de GitLab CI i com s'escriu exactament a continuació.
En primer lloc, per comoditat, definim en werf.yaml Vés a les variables de plantilla, assignant-los valors a partir de variables d'entorn:
{{ $_ := set . "WerfVersions" (cat (env "CHANNELS") (env "RELEASES") | splitList " ") }}
{{ $Root := . }}
{{ $_ := set . "WerfRootVersion" (env "ROOT_VERSION") }}
{{ $_ := set . "WerfReviewCommit" (env "REVIEW_SHA") }} La descripció de l'artefacte per compilar la versió estàtica del lloc és generalment la mateixa per a tots els casos que necessitem (inclosa la generació de la versió arrel, així com la versió per al circuit de desenvolupament). Per tant, el mourem a un bloc separat mitjançant la funció define - per a la seva posterior reutilització include. Passarem els següents arguments a la plantilla:
-
Version— versió generada (nom de l'etiqueta); -
Channel— el nom del canal d'actualització per al qual es genera l'artefacte; -
Commit— commit hash, si l'artefacte es genera per a una commit de revisió; - context.
Descripció de la plantilla d'artefacte
{{- 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 }} El nom de l'artefacte ha de ser únic. Ho podem aconseguir, per exemple, afegint el nom del canal (el valor de la variable .Channel) com a sufix del nom de l'artefacte: artifact: doc-{{ .Channel }}. Però heu d'entendre que quan importeu des d'artefactes, haureu de fer referència als mateixos noms.
Quan es descriu un artefacte, s'utilitza la funció de werf següent: . Muntatge indicant el directori de serveis build_dir us permet desar la memòria cau Jekyll entre execucions de pipeline, que accelera significativament el muntatge.
És possible que també hagis notat l'ús del fitxer releases.yml és un fitxer YAML amb dades de llançament sol·licitades (un artefacte obtingut en executar una canalització). És necessari a l'hora de compilar el lloc, però en el context de l'article ens interessa perquè depèn del seu estat remuntatge d'un sol artefacte — un artefacte de la versió arrel del lloc (no és necessari en altres artefactes).
Això s'implementa mitjançant la declaració condicional if Go de plantilles i dissenys {{ $Root.Files.Get "releases.yml" | sha256sum }} en etapa . Funciona de la següent manera: quan es construeix un artefacte per a la versió arrel (variable .Channel igual a root) hash del fitxer releases.yml afecta la signatura de tota l'etapa, ja que forma part del nom de la tasca Ansible (paràmetre name). Així, quan es canvia contingut dossier releases.yml es tornarà a muntar l'artefacte corresponent.
Si us plau, també pareu atenció a treballar amb un repositori extern. A la imatge d'un artefacte de , només s'afegeix el directori /docs, i en funció dels paràmetres passats, s'afegeixen immediatament les dades de l'etiqueta o la confirmació de revisió necessària.
Per utilitzar la plantilla d'artefacte per generar una descripció de l'artefacte de les versions transferides de canals i llançaments, organitzem un bucle a la variable .WerfVersions в werf.yaml:
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ dict "Version" $VersionsDict._1 "Channel" $VersionsDict._0 "Root" $Root | include "doc_artifact" }}
---
{{ end -}} Perquè el bucle generarà diversos artefactes (esperem que sí), cal tenir en compte el separador entre ells: la seqüència --- (Per obtenir més informació sobre la sintaxi del fitxer de configuració, vegeu ). Tal com s'ha definit anteriorment, quan cridem una plantilla en un bucle, passem els paràmetres de la versió, l'URL i el context arrel.
De la mateixa manera, però sense bucle, anomenem la plantilla d'artefacte per a "casos especials": per a la versió arrel, així com la versió de la confirmació de revisió:
{{ 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 }} Tingueu en compte que l'artefacte per al commit de revisió només es construirà si la variable està establerta .WerfReviewCommit.
Els artefactes estan preparats: és hora de començar a importar!
La imatge final, dissenyada per executar-se a Kubernetes, és un NGINX normal amb un fitxer de configuració del servidor afegit nginx.conf i estàtica dels artefactes. A més de l'artefacte de la versió arrel del lloc, hem de repetir el bucle a la variable .WerfVersions per importar artefactes de versions de canal i llançament + seguiu la regla de denominació d'artefactes que vam adoptar anteriorment. Com que cada artefacte emmagatzema versions del lloc per a dos idiomes, les importem als llocs proporcionats per la configuració.
Descripció de la imatge 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 -}}La imatge addicional, que, juntament amb la principal, es llança al circuit de desenvolupament, conté només dues versions del lloc: la versió del commit de revisió i la versió arrel del lloc (hi ha actius generals i, si recordeu, , dades de publicació). Així, la imatge addicional diferirà de la principal només a la secció d'importació (i, per descomptat, al nom):
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 }} Com s'ha indicat anteriorment, l'artefacte per al commit de revisió només es generarà quan s'executi la variable d'entorn establerta REVIEW_SHA. Seria possible no generar la imatge werf-dev en absolut si no hi ha cap variable d'entorn REVIEW_SHA, però per tal de Les imatges Docker a werf van funcionar per a la imatge werf-dev, la deixarem construir només amb l'artefacte de la versió arrel (ja està construïda de totes maneres), per simplificar l'estructura de la canalització.
El muntatge està llest! Passem al CI/CD i als matisos importants.
Pipeline a GitLab CI i característiques de la construcció dinàmica
Quan executem la compilació, hem d'establir les variables d'entorn que s'utilitzen werf.yaml. Això no s'aplica a la variable REVIEW_SHA, que establirem quan cridem a la canalització des del ganxo de GitHub.
Generarem les dades externes necessàries en un script Bash generate_artifacts, que generarà dos artefactes de pipeline de GitLab:
- arxiu
releases.ymlamb dades de llançament, - arxiu
common_envs.sh, que conté les variables d'entorn que s'han d'exportar.
Contingut del fitxer generate_artifacts trobareu al nostre . La recepció de les dades en si no és l'objecte de l'article, sinó el fitxer common_envs.sh és important per a nosaltres, perquè la feina de werf en depèn. Un exemple del seu contingut:
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' Podeu utilitzar la sortida d'aquest script, per exemple, utilitzant la funció Bash source.
Ara ve la part divertida. Per tal que tant la creació com el desplegament de l'aplicació funcionin correctament, cal garantir-ho werf.yaml era el mateix almenys dins d'una canonada. Si no es compleix aquesta condició, les signatures de les etapes que werf calcula durant el muntatge i, per exemple, el desplegament, seran diferents. Això provocarà un error de desplegament, perquè... faltarà la imatge necessària per al desplegament.
És a dir, si durant el muntatge de la imatge del lloc la informació sobre les versions i versions és la mateixa, i en el moment del desplegament es publica una nova versió i les variables d'entorn tenen valors diferents, el desplegament fallarà amb un error: després de tot, l'artefacte de la nova versió encara no s'ha construït.
Si generació werf.yaml depèn de dades externes (per exemple, una llista de versions actuals, com en el nostre cas), llavors la composició i els valors d'aquestes dades s'han d'enregistrar dins de la canalització. Això és especialment important si els paràmetres externs canvien amb força freqüència.
Nosaltres rebre i registrar dades externes a la primera etapa del gasoducte a GitLab (Construcció prèvia) i transmetre'ls més endavant en la forma Artefacte GitLab CI. Això us permetrà executar i reiniciar tasques de canalització (creació, implementació, neteja) amb la mateixa configuració werf.yaml.
Continguts de l'escenari Construcció prèvia dossier .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 weekDesprés d'haver capturat les dades externes a l'artefacte, podeu crear i desplegar mitjançant les etapes estàndard del pipeline de GitLab CI: Construir i desplegar. Llancem el pipeline en si mitjançant ganxos des del dipòsit de GitHub werf (és a dir, quan hi ha canvis al dipòsit de GitHub). Les dades es poden trobar a les propietats del projecte GitLab a la secció Configuració CI/CD -> Activadors de la canalització, i després creeu el webhook corresponent a GitHub (Configuració -> Webhooks).
L'etapa de construcció serà així:
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 afegirà dos artefactes des de l'etapa fins a l'etapa de construcció Construcció prèvia, de manera que exportem variables amb dades d'entrada preparades mitjançant la construcció source common_envs.sh. Comencem l'etapa de construcció en tots els casos, excepte en el llançament del gasoducte segons un calendari. Segons el calendari, executarem una canonada per a la neteja; en aquest cas, no cal fer el muntatge.
En l'etapa de desplegament, descriurem dues tasques, per separat per al desplegament als circuits de producció i de desenvolupament, utilitzant una plantilla 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 Les tasques difereixen essencialment només en indicar el context del clúster en el qual werf hauria de realitzar el desplegament (WERF_KUBE_CONTEXT), i establint les variables d'entorn del bucle (environment.name и environment.url), que s'utilitzen a les plantilles de gràfics Helm. No facilitarem el contingut de les plantilles, perquè... no hi ha res interessant per al tema en qüestió, però els podeu trobar .
Tacte final
Com que les versions werf es publiquen amb força freqüència, es crearan noves imatges amb freqüència i el registre Docker creixerà constantment. Per tant, és imprescindible configurar la neteja automàtica d'imatges en funció de les polítiques. És molt fàcil de fer.
Per implementar-lo necessitareu:
- Afegiu un pas de neteja a
.gitlab-ci.yml; - Afegiu l'execució periòdica d'una tasca de neteja;
- Configureu una variable d'entorn amb un testimoni d'accés d'escriptura.
Afegir una etapa de neteja 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
Ja hem vist gairebé tot això una mica més alt; només per netejar-lo, primer cal que inicieu sessió al registre Docker amb un testimoni que tingui els drets per suprimir imatges al registre Docker (el testimoni de tasca CI de GitLab emès automàticament no tenen aquests drets). El testimoni s'ha de crear prèviament a GitLab i el seu valor s'ha d'especificar a la variable d'entorn WERF_IMAGES_CLEANUP_PASSWORD projecte (Configuració CI/CD -> Variables).
Afegir una tasca de neteja amb el calendari requerit es fa a CI/CD ->
Horaris.
Això és tot: un projecte al registre Docker ja no creixerà constantment a partir d'imatges no utilitzades.
Al final de la part pràctica, permeteu-me recordar-vos que els llistats complets de l'article estan disponibles a :
- ;
- .
Resultat
- Hem rebut una estructura de muntatge lògic: un artefacte per versió.
- El muntatge és universal i no requereix canvis manuals quan es publiquen noves versions de werf: la documentació del lloc web s'actualitza automàticament.
- Es munten dues imatges per a diferents contorns.
- Funciona ràpidament, perquè La memòria cau s'utilitza tant com sigui possible: quan s'allibera una nova versió de werf o es demana un ganxo de GitHub per a una commissió de revisió, només es reconstrueix l'artefacte corresponent amb la versió canviada.
- No cal pensar en esborrar imatges no utilitzades: la neteja d'acord amb les polítiques de werf mantindrà el registre Docker en ordre.
Troballes
- L'ús de werf permet que el conjunt funcioni ràpidament a causa de la memòria cau tant del conjunt com de la memòria cau quan es treballa amb repositoris externs.
- Treballar amb repositoris Git externs elimina la necessitat de clonar tot el dipòsit cada vegada o reinventar la roda amb una lògica d'optimització complicada. werf utilitza una memòria cau i fa la clonació només una vegada, i després utilitza
fetchi només quan sigui necessari. - Possibilitat d'utilitzar les plantilles Go al fitxer de configuració de compilació
werf.yamlpermet descriure un conjunt el resultat del qual depèn de dades externes. - L'ús de mount in werf accelera significativament la recollida d'artefactes, a causa de la memòria cau, que és comú a totes les canonades.
- werf facilita la configuració de la neteja, que és especialment important quan es construeix de manera dinàmica.
PS
Llegeix també al nostre blog:
- «»;
- «»;
- «»;
- «».
Font: www.habr.com
