Чтобы мигрировать ваш проект с werf v1.1 на werf v1.2 следуйте приведенным ниже шагам.
ВНИМАНИЕ! Существуют такие конфигурации v1.1, которые используют директивы mount from build_dir
и mount fromPath
для кеширования внешних зависимостей приложения (зависимости, описываемые в таких файлах, как Gemfile
, package.json
, go.mod
и т.п.). Такие директивы mount
всё ещё поддерживаются в werf v1.2, однако не рекомендуются к использованию и по умолчанию выключены режимом гитерминизма (за исключением mount from tmp_dir
— данная директива не ограничена к использованию), потому что использование этих директив может привести к ненадёжным, недетерминированным сборкам, зависимым от сборочных хостов. Для таких конфигураций планируется добавление новой возможности хранения такого кеша в Docker-образах. Данная фича планируется к добавлению в v1.2, но еще не реализована.
Поэтому, если ваша конфигурация использует такие mounts
, то предлагаются следующие варианты:
- Продолжить использование версии v1.1, пока данная улучшенная возможность кеширования не будет добавлена в werf v1.2.
- Удалить использование таких
mounts
и подождать добавления улучшенной возможности кеширования в werf v1.2. - Включить используемые
mounts
в werf v1.2 с помощью конфигурационного файлаwerf-giterminism.yaml
(не рекомендуется).
Ключевые моменты
1. Используйте стратегию тегирования content-based
Стратегия тегирования content-based — это выбор по умолчанию и единственно доступный вариант, используемый в werf во время процесса деплоя.
- Удалите параметр
--tagging-strategy
командыwerf ci-env
. - Удалите опции
--tag-custom
,--tag-git-tag
,--tag-git-branch
, и--tag-by-stages-signature
.
В случае, если требуется, чтобы определённый Docker-тег для собранного образа существовал в container registry для использования вне werf, тогда допустимо использование параметра --save-build-report
(и, опционально, --build-report-path
) следующим образом:
werf build/converge --save-build-report --repo REPO
;docker pull $(cat .werf-build-report.json | jq -r .Images.IMAGE_NAME_FROM_WERF_YAML.DockerImageName)
;docker tag $(cat .werf-build-report.json | jq -r .Images.IMAGE_NAME_FROM_WERF_YAML.DockerImageName) REPO:mytag
;docker push REPO:mytag
.
2. Используйте команду converge
вместо команды build-and-publish
Теперь вместо werf deploy
должна использоваться команда werf converge
. Она используется сразу для сборки, публикации и деплоя приложения в Kubernetes и поддерживает те же параметры, что и werf deploy
.
Изменения в командах (для справки):
- Команда
werf build-and-publish
удалена. - Добавлена команда
werf build
, использование которой опционально. werf converge
самостоятельно собирает и публикует в container registry недостающие образы.werf build
также может быть использована на стадииprebuild
в CI/CD pipeline вместоwerf build-and-publish
.
3. Используйте параметр --repo
вместо параметров --stages-storage
и --images-repo
Команда werf converge
хранит и собираемые образы и их стадии в container registry. Для указания хранилища, которое будет использоваться для хранения образов и стадий, теперь необходимо указать один параметр --repo
вместо двух используемых ранее в v1.1 --stages-storage
и --images-repo
.
Аналогично и с переменными окружения, используемыми ранее: вместо WERF_STAGES_STORAGE
и WERF_IMAGES_REPO
теперь используется одна переменная WERF_REPO
.
4. Измените Helm-шаблоны
Вместо werf_container_image
используйте .Values.werf.image.IMAGE_NAME
:
spec:
template:
spec:
containers:
- name: main
image: {{ .Values.werf.image.myimage }}
ВАЖНО! Убедитесь, что используете
apiVersion: v2
! Это необходимо, чтобы разрешить описание зависимостей непосредственно в.helm/Chart.yaml
вместо.helm/dependencies.yaml
.
Изменения в Helm-шаблонах (для справки):
- Полностью удалена шаблонная функция
werf_container_env
. - Необходимо использовать
.Values.werf.env
вместо.Values.global.env
. - Необходимо использовать
.Values.werf.namespace
вместо.Values.global.namespace
. - Если в имени образа содержится дефис (
-
), то запись должна быть такого вида:image: '{{ index .Values.werf.image "IMAGE-NAME" }}'
. - Необходимо использовать
"werf.io/replicas-on-creation": "NUM"
вместо"werf.io/set-replicas-only-on-creation": "true"
.ВАЖНО!
"NUM"
должно быть указано строкой, а не как числоNUM
, иначе аннотация будет проигнорирована.ВАЖНО! При использовании данной аннотации необходимо удалить явное определение поля
spec.replicas
, больше информации в changelog.
5. Используйте .helm/Chart.lock
для сабчартов
В соответствии с режимом гитерминизма werf не позволяет держать некоммитнутую директорию .helm/charts/
. Для использования сабчартов необходимо определить dependencies
в .helm/Chart.yaml
следующим способом:
# .helm/Chart.yaml
apiVersion: v2
dependencies:
- name: redis
version: "12.7.4"
repository: "https://charts.bitnami.com/bitnami"
ВАЖНО! Убедитесь, что используете
apiVersion: v2
! Это необходимо, чтобы разрешить описание зависимостей непосредственно в.helm/Chart.yaml
вместо.helm/dependencies.yaml
.
Далее выполните следующие шаги:
- Добавьте директорию
.helm/charts/
в.gitignore
. - Запустите
werf helm dependency update .helm
для создания файла.helm/Chart.lock
и директории.helm/charts/
в локальной файловой системе. - Коммитните
.helm/Chart.lock
в Git-репозиторий проекта.
werf автоматически скачает указанные сабчарты в кеш и загрузит файлы сабчартов во время команды werf converge
(и других высокоуровневых командах, которые используют Helm-чарт).
6. Используйте очистку на основе истории Git
Удалите опцию --git-history-based-cleanup-v1.2 — теперь поведение werf cleanup по умолчанию совпадает с поведением v1.1 с данной опцией. Больше информации по изменению [в changelog](#очистка |
true_relative_url }}) и в статье про cleanup. |
7. Определите используемые переменные окружения в werf-giterminism.yaml
ЗАМЕЧАНИЕ! На самом деле использование переменных окружения в
werf.yaml
не рекомендуется (за исключением редких случаев), больше информации в статье.
Если в werf.yaml
используются, например, переменные окружения ENV_VAR1
и ENV_VAR2
, то необходимо добавить следующее описание в werf-giterminism.yaml
:
# werf-giterminism.yaml
giterminismConfigVersion: 1
config:
goTemplateRendering:
allowEnvVariables:
- ENV_VAR1
- ENV_VAR2
8. Скоректируйте конфигурационный файл werf.yaml
- Замените относительные пути для включения дополнительных шаблонов с {{ include “.werf/templates/1.tmpl” . }} на {{ include “templates/1.tmpl” . }}.
- Переименуйте
fromImageArtifact
вfromArtifact
.ЗАМЕЧАНИЕ! Не обязательно, но желательно заменить
artifact
иfromArtifact
наimage
иfromImage
в данном случае. Заметка про запрет использованияfromArtifact
в changelog.
9. Исправьте определение нестандартной директории чарта .helm
в werf.yaml
Вместо опции --helm-chart-dir
используйте директиву deploy.helmChartDir
файла werf.yaml
следующим образом:
configVersion: 1
deploy:
helmChartDir: .helm2
Следует рассмотреть другой вариант расположения конфигурации для вашего проекта: werf v1.2 поддерживает несколько werf.yaml
в едином Git-репозитории.
- Вместо переопределения нескольких разных
deploy.helmChartDir
вwerf.yaml
создаётся несколькоwerf.yaml
в разных директориях проекта. - Каждая такая директория содержит свою директорию
.helm
соответственно. - werf необходимо запускать из каждой директории.
- Все относительные пути, указанные в
werf.yaml
, будут рассчитаны относительно той директории, где лежитwerf.yaml
. - Абсолютные пути, указанные в директиве
git.add
, так и остаются абсолютными путями относительно корня Git-репозитория независимо от положенияwerf.yaml
внутри этого репозитория.
10. Мигрируйте на Helm 3
werf v1.2 осуществляет автоматическую миграцию существующего релиза с Helm 2 на Helm 3.
Релиз Helm 2 должен иметь то же самое имя, как и вновь создаваемый релиз Helm 3.
Перед запуском процесса миграции werf проверит, что текущие шаблоны из .helm/templates
рендерятся и валидируются корректно, и только после успешного рендеринга миграция будет начата.
ВАЖНО! Как только проект переехал на Helm 3 – не существует обратного пути на werf v1.1 и Helm 2.
Changelog
Данная статья содержит полный список изменений с версии v1.1.
Гитерминизм
werf вводит так называемый режим гитерминизма. Название происходит от слов git и детерминизм, что означает “детерминированный git’ом”.
Все конфигурационные файлы werf, конфигурация helm и файлы приложения werf будет читать из текущего коммита git репозитория проекта. Существует также режим разработки для упрощения локальной разработки конфигурации werf и локальной разработки приложения с использованием werf.
Больше информации о режиме доступно на странице документации.
Для конфигурации гитерминизма в werf также был добавлен новый конфигурационный файл werf-giterminism.yaml
.
Локальная разработка
Follow и dev
Все высокоуровневые команды: werf converge
, werf run
, werf bundle publish
, werf render
и werf build
— имеют 2 основных флага --follow
и --dev
для локальной разработки.
По умолчанию каждая из этих команд читает все требуемые файлы из текущего коммита git репозиторию проекта. С флагом --dev
команда будет использовать все файлы из рабочей директории git проекта, включая неотслеживаемые (untracked) файлы. werf игнорирует изменения с учётом правил, описанных в .gitignore
, а также правил, заданных пользователем опцией --dev-ignore=<glob>
(может использоваться несколько раз).
Команда с флагом --follow
будет работать в цикле, в котором:
- новый коммит в рабочую директорию git проекта вызовет перезапуск команды — по умолчанию;
- изменения в рабочей директории git, включая неотслеживаемые (untracked) файлы, вызовут перезапуск команды — когда флаг
--follow
совмещён с флагом--dev
.
Внутри werf создаёт специальные коммиты для modified/tracked и staged файлов из git-индекса в ветке werf-dev-<commmit>
. Кеш в режиме разработки будет привязан к этим временным коммитам и тем самым отделён от основного сборочного кеша (когда не указано флага --dev
).
Поддержка composer
werf поддерживает основные команды composer. При запуске этих команд werf автоматом установит специальные переменные окружения, в которых доступны полные имена docker-образов для образов, описанных в werf.yaml
:
WERF_<FORMATTED_WERF_IMAGE_NAME>_DOCKER_IMAGE_NAME=application:45f03bdd90c844eb2e61e7e01dae491588d2bdadbd195881b25be9b0-1613371915351
Например, если имеется следующий werf.yaml
:
# werf.yaml
project: myproj
configVersion: 1
---
image: myimage
from: alpine
Полное имя docker-образа для myimage
может быть использовано в docker-compose.yml
следующим образом:
version: '3'
services:
web:
image: "${WERF_MYIMAGE_DOCKER_IMAGE_NAME}"
werf предоставляет следующие команды compose:
werf compose config
— запуск командыdocker-compose config
с прокинутыми именами образов изwerf.yaml
;werf compose down
— запуск командыdocker-compose down
с прокинутыми именами образов изwerf.yaml
;werf compose up
— запуск командыdocker-compose up
с прокинутыми именами образов изwerf.yaml
;
Бандлы
- Бандлы позволяют разделить процесс создания нового релиза кода приложения и процесс деплоя этого релиза в кластер kubernetes.
- Бандлы хранятся в container registry.
- Работа с бандлами предполагает 2 основных шага: 1) публикация бандла для приложения из рабочей директории git проекта в container registry; 2) деплой ранее опубликованного бандла из container registry в кластер kubernetes.
- Больше информации в документации.
Переработка основного командного интерфейса и поведения команд
Переработка интерфейса
- Единая команда
werf converge
для сборки и публикации требуемых образов в container registry и деплоя приложения в kubernetes. - Single
werf converge
command to build and publish needed images and deploy application into the kubernetes.- Вызов команды с опцией
werf converge --skip-build
эмулирует поведение ранее существующей командыwerf deploy
.- werf упадёт с ошибкой если требуемые образы не будут найдены в container registry, так же как падал с ошибкой
werf deploy
.
- werf упадёт с ошибкой если требуемые образы не будут найдены в container registry, так же как падал с ошибкой
- Вызов команды с опцией
- Удалены команды
werf stages *
,werf images *
иwerf host project *
. - Более нет команды
werf publish
, потому что командаwerf build
с параметром--repo
загрузит образы и все стадии, из которых они состоят, в container registry автоматически. - Более нет флагов тегирования:
--tag-by-stages-signature
,--tag-git-branch
,--tag-git-commit
,--tag-git-tag
и--tag-custom
, werf всегда использует поведение ранее включаемое флагом--tag-by-stages-signature
.- Принудительное использование произвольных тегов пока не поддерживается в v1.2.
- Команда
werf ci-env
принимает скрытый параметр--tagging-strategy
по соображениям совместимости для следующего варианта вызова:werf ci-env --tagging-strategy
без опции--as-file
.- Использование данного флага должно быть удалено из всех вызовов команды
werf ci-env
. - Указанный параметр не влияет на поведение werf, поведение соответствующее ранее существовавшему флагу
--tag-by-stages-signature
будет использовано в любом случае.
- Использование данного флага должно быть удалено из всех вызовов команды
Поведение команд werf-build и werf-converge
- По умолчанию команда
werf build
не требует никаких аргументов и будет собирать образы используя локальный docker server в качестве хранилища. - При запуске
werf build
с флагом--repo registry.mydomain.org/project
werf будет искать локально собранные образы и если найдёт, то загрузит их в указанный repo (лишней пересборки не будет). - Команда
werf converge
требует параметр--repo
для работы, и, так же какwerf build
, автоматически загрузит в repo локально существующие образы.
Поведение команд очистки
- Команды
werf cleanup/purge
используются только для чистки сontainer registry. - Команда
werf host purge --project=<project-name>
может использоваться для удаления образов проекта из локального Docker (ранее для этого можно было использовать командуwerf purge
).
Автоматическая сборка образов в командах верхнего уровня
- Команды
werf converge
,werf run
,werf bundle publish
иwerf render
автоматически соберут недостающие образы, которые не существуют в container registry. - Команда
werf render
будет собирать образы только при передаче опционального параметра--repo
.
Хранение образов в CI/CD системах
В качестве параметра --repo
предполагается использование container registry привязанного к проекту.
- Команда
werf ci-env
для GitLab CI/CD, например, сгенерирует следующий параметр:WERF_REPO=$CI_REGISTRY_IMAGE
. - Указанный репозиторий
--repo
будет использован для хранения как собранных промежуточных стадий образа, так и финального образа (внутри эти слои переиспользуются и публикация промежуточных стадий не создаёт накладных расходов).
werf всегда хранит стадии в container registry
- Команда
werf converge
всегда хранит образы и стадии, из которых они состоят, в container registry. - Единый параметр
--repo
используется для указания хранилища образов и стадий этих образов (ранее в v1.1 было 2 параметра--stages-storage
и--images-repo
). - Благодаря использованию content-based тегирования финальный образ совпадает с последней сборочной стадией этого образа.
- Т.к. образы состоят из набора слоёв, все эти слои всё равно хранятся в container registry.
- Поэтому хранение промежуточных стадий в container registry вместе с image не создаёт накладных расходов.
- Это делает процесс сборки образов в werf независимым от сборочного хоста, потому что в процессе сборки промежуточные стадии будут переиспользованы из container registry в качестве сборочного кеша.
- Т.к. образы состоят из набора слоёв, все эти слои всё равно хранятся в container registry.
Изменения сигнатур
- Сигнатуры переименованы в дайджесты (signature => digest).
- Все дайджесты уже собранных образов изменились.
- Образы собранные через сборщик как Dockerfile, так и stapel, будут пересобраны.
- Другими словами сборочный кеш из v1.1 более не валиден.
Сборщик stapel
- Удалена возможность кеширования каждой сборочной инструкции из
werf.yaml
по отдельным слоям с помощью директивыasLayers
.
Опциональный параметр env
- Для команд
werf converge
,werf render
andwerf bundle publish
существует параметр--env
. --env
влияет на имя helm релиза и kubernetes namespace также как в v1.1.- При указании параметра
--env
имя helm релиза будет сгенерировано по шаблону[[ project ]]-[[ env ]]
и namespace в kubernetes будет сгенерирован по такому же шаблону[[ project ]]-[[ env ]]
— так же как в версии v1.1. - Когда параметр
--env
не указан, werf будет использовать шаблон[[ project ]]
для генерации имени helm релиза и такой же шаблон[[ project ]]
для генерации namespace в kubernetes.
- При указании параметра
Новая команда werf-render
- Команда
werf render
автоматически соберёт недостающие образы в container registry. - Данная команда позволяет воспроизвести шаблоны в точно таком же виде, как они будут сгенерированы в команде
werf converge
. - Команда
werf render
работает в режиме гитерминизма.
Helm
Helm 3
- Helm 3 используется по умолчанию, и это единственная версия helm доступная для использования в v1.2.
- Уже существующие релизы helm 3 будут смигрированы на helm 3 автоматически в команде
werf converge
при условии, что имя релиза helm 2 совпадает с именем нового релиза helm 3.- ПРЕДУПРЕЖДЕНИЕ. Как только релиз helm 2 конвертирован в helm 3 пути назад нет.
- Прежде чем мигрировать релиз helm 2 в helm 3, команда
werf converge
проверит, что текущие шаблоны корректно рендерятся и валидируются.
Конфигурация
.Values.werf.image.IMAGE_NAME
вместо шаблонаwerf_image
.- Удалена функция шаблонов
werf_container_env
. - Загрузка всех конфигурационных файлов чарта происходит в режиме гитерминизма.
- Данный режим используется только для высокоуровневых команд вроде
werf converge
иwerf render
. - Низкоуровневые helm-команды
werf helm *
работают в обычном режиме и загружают файлы из локальной файловой системы.
- Данный режим используется только для высокоуровневых команд вроде
- Окружение, переданное опцией
--env
, доступно для использования через.Values.werf.env
. - Целевой namespace доступен для использования через
.Values.werf.namespace
. - Исправлен подход к использованию файла
.helm/Chart.yaml
. Файл.helm/Chart.yaml
опционален, однако werf будет его использовать, если он существует следующим образом:- Файл
.helm/Chart.yaml
берётся из git репозитория проекта, если он существует. - Поле
metadata.name
перезаписывается именем проекта изwerf.yaml
. - Поле
metadata.version
устанавливается в1.0.0
, если оно явно не определено.
- Файл
- Добавлено сервисное значение
.Values.werf.version
с версией утилиты werf, которая используется. - Поддерживается установка начального количества реплик, когда активен режим HPA для Deployment и других типов ресурсов. Необходимо установить аннотацию
"werf.io/replicas-on-creation": NUM
и убрать явное определениеspec.replicas
в шаблонах в таком случае.spec.replicas
переопределяетwerf.io/replicas-on-creation
.- Данная аннотация особенно полезна при использовании HPA, в данной статье описано почему.
Работа с сабчартами
- Лок-файл с зависимостями
.helm/Chart.lock
должен быть коммитнут в git репозиторий проекта. - werf автоматически скачает все зависимости определённые в лок-файле.
- Обычно директория
.helm/charts/
должна быть добавлена в.gitignore
. - Однако werf позволяет хранить зависимые чарты и в директории
.helm/charts
.- Данные чарты перезапишут автоматически загруженные по
.helm/Chart.lock
чарты.
- Данные чарты перезапишут автоматически загруженные по
- См. больше информации по зависимым чартам.
Удалена команда werf-helm-deploy-chart
Вместо команды werf helm deploy-chart
можно использовать команды werf helm install
и werf helm upgrade
.
Лучшая интеграция с командами werf-helm-*
- Команда
werf helm template
может быть использована для рендера локальных чартов даже при использовании секретов (функции шаблоновwerf_secret_file
). - Файлы секретов полностью поддерживаются командами
werf helm *
. - Дополнительные аннотации и лейблы полностью поддерживаются командами
werf helm *
(опции--add-annotation
и--add-label
).
Изменён формат сервисных значений
Удалено сервисное значение .Values.global.werf.image
, вместо него используется .Values.werf.image
.
Процесс деплоя
- Добавлено полноценное ожидание удаления ресурсов перед выходом в командах
werf dismiss
иwerf helm uninstall
. - Wait until all release resources terminated in the
werf dismiss
command before exiting.
werf.yaml
- Директива
fromImageArtifact
переименована вfromArtifact
.- ПРЕДУПРЕЖДЕНИЕ. Директива
fromImageArtifact/fromArtifact
не рекомендована к использованию и будет удалена в v1.3 из-за неочевидной работы механизма наложения патчей в получившейся конфигурации. Рекомендуется уже сейчас перейти наimage
иfromImage
вместоartifact
иfromArtifact
.
- ПРЕДУПРЕЖДЕНИЕ. Директива
- Директивы
herebyIAdmitThatFromLatestMightBreakReproducibility
иherebyIAdmitThatBranchMightBreakReproducibility
удалены. Теперь при использовании директивfromLatest
иgit.branch
необходимо ослаблять правила гитерминизма, используя соответствующие директивы в werf-giterminism.yaml. -
Удалена опция
--helm-chart-dir
, директория helm-чарта определяется вwerf.yaml
:configVersion: 1 deploy: helmChartDir: .helm
- Опции
--allow-git-shallow-clone
,--git-unshallow
и--git-history-synchronization
превращены в директивыwerf.yaml
, добавлена новая мета-секцияgitWorktree
. Выключено использование этих опций в командеwerf ci-env
: unshallow git clone происходит всегда. - Использование sprig v3 вместо v2: http://masterminds.github.io/sprig/.
- Новая страница документации, описывающая движок шаблонов
werf.yaml
. - Пофикшено именование пользовательских шаблонов. Имя шаблона — это относительный путь в директории
.werf
. {{ include “.werf/templates/1.tmpl” . }} => {{ include “templates/1.tmpl” . }}. - Определение безымянного образа в
werf.yaml
с помощьюimage: ~
не рекомендовано к использованию и будет удалено в v1.3. Лучше всегда выставлять явные имена образам, даже если образ один. - Функция
env "ENVIRONMENT_VARIABLE_NAME"
теперь требует наличия переменнойENVIRONMENT_VARIABLE_NAME
(переменная может содержать пустое значение, но она должна быть явно определена). -
Новая функция
required
даёт разработчикам возможность определить значение, которое требуется для рендера конфига. Если это значение пустое, то рендер сообщит об ошибке с помощью текста указанного в директивеrequired
:{{ required "A valid <anything> value required!" <anything> }}
Стратегия тегирования
- Доступна только стратегия тегирования на основе контента.
- Возможность экспорта собранных образов в произвольный container registry будет добавлено позже.
- Принудительное использование произвольных тегов для собранных образов будет добавлено позже.
Очистка
- Очистка на основе истории git по умолчанию.
- В v1.1 такой режим работы включался опцией
--git-history-based-cleanup-v1.2
(в v1.2 опция удалена).
- В v1.1 такой режим работы включался опцией
- Полностью удалены алгоритмы очистки на основе различных стратегий тегирования.
- Опция
--keep-stages-built-within-last-n-hours
для сохранения образов, которые были собраны в указанный период до текущего момента (по умолчанию 2 часа). - Улучшения алгоритма очистки на основе истории git:
- Политика сохранения образов по директиве
imagesPerReference.last
учитывает, что может существовать несколько стадий образа, основанных на одном и том же коммите. Эти образы сохраняются и засчитываются как один для директивыimagesPerReference.last
. Другими словами:imagesPerReference.last
— это про количество коммитом, для одного коммита может существовать несколько образов.
- Политика сохранения образов по директиве
Кеширование импортов из artifact/image по контрольной сумме
- Представим, что имеется артефакт, который собирает некоторые файлы.
- Данный артефакт имеет stage-dependency в
werf.yaml
для пересборки этих файлов, когда исходные зависимые файлы поменялись. - При очередном изменении исходных файлов вызывает пересборку артефакта.
- Т.к. изменился stage-dependency, то последняя стадия артефакта будет иметь другой дайджест.
- Однако после пересборки артефакта фактическая контрольная сумма файлов, которые были собраны не поменялась — получились точно такие же файлы.
- В версии v1.1 werf всё равно выполнит переимпорт этих файлов в целевой образ.
- Как последствие целевой образ будет пересобран и перевыкачен.
- В версии v1.2 werf проверит контрольную сумму файлов, которые импортятся и перевыполнит импорт только при изменении этой контрольной суммы.
- В версии v1.1 werf всё равно выполнит переимпорт этих файлов в целевой образ.
Поддержка первичного и вторичного хранилища образов
- Автоматическая загрузка собранных локально образов в указанный container registry в
--repo
. - Использование стадий из read-only вторичного хранилища указанного опциями
--secondary-repo
(опция может быть указана несколько раз).- Подходящие стадии из вторичного хранилища
--secondary-repo
будут скопированы в первичное хранилище--repo
.
- Подходящие стадии из вторичного хранилища
Built images report format changes
Команды werf converge
, werf build
, werf run
, werf bundle publish
и werf render
имеют опции --save-build-report
и --build-report-path
. --save-build-report
включает генерацию в следующем формате:
$ werf build --save-build-report
{
"Images": {
"result": {
"WerfImageName": "result",
"DockerRepo": "quickstart-application",
"DockerTag": "32e88a6a19a425c9254374ee2899b365876de31ac7d6857b523696a1-1613371915843",
"DockerImageID": "sha256:fa6445196bc8ed44e4d2842eeb068aab4e627112d504334f2e56d235993ba4f0",
"DockerImageName": "quickstart-application:32e88a6a19a425c9254374ee2899b365876de31ac7d6857b523696a1-1613371915843"
},
"vote": {
"WerfImageName": "vote",
"DockerRepo": "quickstart-application",
"DockerTag": "45f03bdd90c844eb2e61e7e01dae491588d2bdadbd195881b25be9b0-1613371915351",
"DockerImageID": "sha256:a6845bbc7912e45c601b0291170f9f503722efceb9e3cc98a5701ea4d26b017e",
"DockerImageName": "quickstart-application:45f03bdd90c844eb2e61e7e01dae491588d2bdadbd195881b25be9b0-1613371915351"
},
"worker": {
"WerfImageName": "worker",
"DockerRepo": "quickstart-application",
"DockerTag": "1b16118e7d5c67aa3c61fc0f8d49b3eccf8f72810f01c33a40290418-1613371916044",
"DockerImageID": "sha256:546af94bd73dc20a7ab1f49562f42c547ee388fb75cf480eae9fde02b48ad6ad",
"DockerImageName": "quickstart-application:1b16118e7d5c67aa3c61fc0f8d49b3eccf8f72810f01c33a40290418-1613371916044"
}
}
}
или
$ werf build --save-build-report --build-report-path=.werf-build-report.env
WERF_RESULT_DOCKER_IMAGE_NAME=quickstart-application:32e88a6a19a425c9254374ee2899b365876de31ac7d6857b523696a1-1613371915843
WERF_WORKER_DOCKER_IMAGE_NAME=quickstart-application:1b16118e7d5c67aa3c61fc0f8d49b3eccf8f72810f01c33a40290418-1613371916044
WERF_VOTE_DOCKER_IMAGE_NAME=quickstart-application:45f03bdd90c844eb2e61e7e01dae491588d2bdadbd195881b25be9b0-1613371915351
Поддержка нескольких werf.yaml в одном git репозитории проекта
Пользователь может создать несколько werf.yaml
(и .helm
соответственно) в одном git репозитории проекта.
- Все относительные пути в
werf.yaml
будут рассчитаны относительно текущей рабочей директории процесса werf или параметра--dir
. - Обычно пользователь запускает werf прямо из директории, в которой расположен
werf.yaml
. - Также существует опция
--config
для передачи кастомногоwerf.yaml
, все относительные пути в таком случае также будут рассчитаны относительно текущей рабочей директории процесса werf или параметра--dir
. - Добавлен параметр
--git-work-tree
(и переменнаяWERF_GIT_WORK_TREE
) для указания директории, которая содержит.git
для случая, когда автодетектор этой директории не смог её найти, или когда мы хотим явно указать другую рабочую директорию git проекта.- Например когда werf запускается из сабмодуля пользователь может захотеть использовать корневой git репозиторий проекта вместо git репозитория сабмодуля.
- Чтобы сборочный кеш был связан с коммитами в главном репозитории.
- Например когда werf запускается из сабмодуля пользователь может захотеть использовать корневой git репозиторий проекта вместо git репозитория сабмодуля.
Разное и внутренности
- Добавлен кеш git-архивов и git-патчей в
~/.werf/local_cache/
по аналогии с уже существующем кешом git-worktree. Патчи и архивы более не создаются в/tmp/
(и--tmp-dir
соответственно). - Удалена блокировка
stages_and_images
во время сборочного процесса.stages_and_images
— это вспомогательная блокировка, которая ранее предотвращала одновременный запускwerf cleanup
иwerf build
.- В текущей версии данная блокировка может быть проигнорирована без последствий.
- Данная блокировка создаёт излишнюю нагрузку на сервер синхронизации, потому что она активна во время всего процесса сборки.
- Также удалена неиспользуемая более блокировка
image
(legacy из v1.1). - Также переименованы блокировки связанные с использованием kubernetes в качестве lock-storage (сделано для большей корректности, несовместимое с v1.1 изменение).
Переработка документации
- Вся документация разделена на секции по глубине погружения:
- главная страница;
- введение;
- быстрый старт;
- гайды/руководства;
- справочник;
- документация продвинутого уровня;
- внутренности.
- Новая секция с руководствами.