Pull to refresh

Comments 13

Непонятно про влияние истории гитв на тег. Как он влияет и, главное, зачем?

Цель: изоляция кеша стадий и итоговых образов собранных для разных веток в git. Кеш, собранный для какой-либо ветки от master не будет доступен в master до тех пор, пока эта ветка не будет смержена в master.

Итоговый образ точно также как и кеш стадий будет изолирован за счет создания разных тегов. Вот в этом и заключается влияние истории гита на тег.


Другими словами: вот есть у нас 2 образа одинаковых по контенту, но собранных для разных гит-веток. Верф изолирует эти 2 образа: создаст для каждого свой идентификатор.


При этом в рамках одной ветки образы с общим контентом будут иметь одинаковый идентификатор.

А зачем такая изоляция? Вот сделал я ветку от мастера, что-то в ней делал, подмержил мастер в итоге, сделал билд, получио образ, прогнал его по тестам. Вмерживаю в мастер, делаю билд, но кэш недоступен, всё опять с нуля.

Не так. При мерже собранный кеш становится доступен для всех остальных точно также как и изменения которые были сделаны в ветке становятся доступны всем только после merge. Если мерж был не fast-forward, то возможно произойдет пересборка связанная со слиянием изменений мастера и ветки, но опять же уже собранный кеш будет учавствовать в сборке.


Если для ветки сделать rebase, то кеш, собранный для старого коммита потеряется и более не будет использоваться, также как теряется родительская связь между коммитами при rebase — произойдет пересборка. При дальнейшем merge кеш не теряется.


Такая изоляция — это отчасти переложение логики гита на собираемые образы.

Можно сказать по-другому: мы выстраиваем content-based файловую систему на основе docker-образов, новое состояние в этой фс создается на основе кеша stages путем сборки новых образов, идентификаторы и пересборка тесно связаны с историей правок в git.

А как по этому тегу потом понять, какая версия кода выполняется (какой коммит конкретно был собран)?

werf deploy добавляет аннотации:


apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    ci.werf.io/commit: bedee28e358378b2e20c406628f751499f15d2e3
    gitlab.ci.werf.io/job-url: https://gitlab.com/group/project/-/jobs/54301
    gitlab.ci.werf.io/pipeline-url: https://gitlab.com/group/project/pipelines/25574
    project.werf.io/env: env
    project.werf.io/git: https://gitlab.com/group/project
    project.werf.io/name: app
    service.werf.io/owner-release: app-env
    werf.io/version: v1.1.8.4
spec:
  template:
    spec:
      containers:
      - name: pod
        image: registry.gitlab.com/group/project/image:781a2fa1c6d299fe1f6d5cfa44dfcf0c7e2c6de3eec4d10fbe314523

Как вариант — запоминать версию кода на этапе сборки образа. Но опять же commit-id — это неидеальный идентификатор кода, потому что его изменение не означает что код в образе изменился. При этом мог быть сделан какой-то нерелевантный коммит и сборщик не стал лишний раз пересобирать образ без надобности — в этом случае образ остался связан со старым коммитом.


Другой вариант — не встраивать информацию о коммите в образы вообще. Зачем добавлять в образ изменчивую инфу, тем более, что commit-id не отражает его содержимое. А добавлять инфу о коммите куда-то в рантайм — Kubernetes — в процессе выката приложения. При выкате werf, например, через values может передать commit-id в шаблоны. Дальше его можно положить в какой-нибудь ConfigMap, приложение же может доставать commit-id в рантайме — читать его из ConfigMap. Тут получается и овцы сыты, и волки целы: лишних пересборок нету, приложение может получить инфу о гите.

Да, отличная идея. Спасибо за совет, пошёл пилить))

Я тут подумал, что можно по аналогии с helm3 в oci images хранить информацию о релизе, т.е. прямо в том же реестре где и контейнеры с сервисами.

Парни, круто! Тоже сражался с этой проблемой и пришёл к выводу использовать дайджесты образов в виде тэгов. НО, как потом быстро соотнести такой тэг с ревизией vcs?

Only those users with full accounts are able to leave comments. Log in, please.