Здравствуйте, ·, Вы писали:

·>В общем да, обычно не нужно. С другой стороны, отсутствие повторяемости создаёт очень неявные и тонкие проблемы, которые приходится героически решать. Когда возникают всякие невоспроизводимые баги, когда что-то где-то поломалось и повторить не получается. Надо как-то вручную описывать зависимости, контролировать это всё. Т.е. переизобретать хотя бы частично всё то, что докер предоставляет из коробки.

Ну как бы да, но вот я с такими проблемами никогда не сталкивался, чтобы у меня был баг от того, что там что-то где-то в зависимости поменялось, если они адекватно прописаны.

·>Это заблуждение. Имадж докера это Merkle Tree. Т.е. там нелья подменить никакой байтик вообще никак, без взлома криптографии. Другое дело, что типичный hello-world скрипт сборки ссылается на какие-нибудь latest-теги и поэтому собирается свежак. Но, во-первых, пересобирать имаджи не надо. Их можно просто хранить готовыми. Во-вторых, в скриптах можно прописывать явные ревизии зависимостей, так что сборка имаджа тоже станет повторяемой.

Типичный скрипт сборки может ссылаться и на версии 3.2.0, которые по сути теги, такие же как :latest, которые так же можно изменить в будущем. Чтобы нельзя было изменить — нужно прописывать хеши, а не ревизии. Но кто это делает (кроме меня, лол).

Если "пересобирать имаджи не надо", то это уже не повторяемая сборка. Так же можно сказать про то, что пересобирать программу не надо. Докер дает зафиксированное окружение, если мы не пересобираем контейнер. Но это не совсем та повторяемость, которую имеют в виду, когда говорят про repeatable builds. В общем вопрос терминологии.

vsb>>Повторяемость может быть важна для некоторых проектов. К примеру для публичных проектов, связанных с безопасностью. Если я скачиваю бинарник того же signal-а, я хочу быть уверенным, что этот бинарник соответствует опубликованным исходникам. И для этого signal поддерживает повторяемость билдов. И даже если я сам это не проверяю, я примерно представляю, что среди тысяч программистов, пользующихся им, хотя бы пара гиков найдётся, которые это проверят за меня и поднимут хай-вай, если что не так.
·>Для упомянутых мною сценариев — тестировать имадж и отправлять ровно его в прод. Воспроизводить прод в тестовом енве для поиска багов ровно в той ревизии, в которой баги возникли в проде.

Ну вот у меня в тестовом окружении то, что собирается из HEAD тестовой ветки, а когда надо релизить, я делаю пару отдельных коммитов, которые меняют версию в pom.xml и на этот коммит вешается git-тег, по которому контейнер пересобирается. В исходниках из отличий только 1.2.0-SNAPSHOT меняется на 1.2.0, но формально образ пересоберётся другой. И вот не было пока с этой схемой проблем, чтобы я захотел это как-то исправить.

Здравствуйте, ·, Вы писали:

·>В общем да, обычно не нужно. С другой стороны, отсутствие повторяемости создаёт очень неявные и тонкие проблемы, которые приходится героически решать. Когда возникают всякие невоспроизводимые баги, когда что-то где-то поломалось и повторить не получается. Надо как-то вручную описывать зависимости, контролировать это всё. Т.е. переизобретать хотя бы частично всё то, что докер предоставляет из коробки.

Ну как бы да, но вот я с такими проблемами никогда не сталкивался, чтобы у меня был баг от того, что там что-то где-то в зависимости поменялось, если они адекватно прописаны.

·>Это заблуждение. Имадж докера это Merkle Tree. Т.е. там нелья подменить никакой байтик вообще никак, без взлома криптографии. Другое дело, что типичный hello-world скрипт сборки ссылается на какие-нибудь latest-теги и поэтому собирается свежак. Но, во-первых, пересобирать имаджи не надо. Их можно просто хранить готовыми. Во-вторых, в скриптах можно прописывать явные ревизии зависимостей, так что сборка имаджа тоже станет повторяемой.

Типичный скрипт сборки может ссылаться и на версии 3.2.0, которые по сути теги, такие же как :latest, которые так же можно изменить в будущем. Чтобы нельзя было изменить — нужно прописывать хеши, а не ревизии. Но кто это делает (кроме меня, лол).

Если "пересобирать имаджи не надо", то это уже не повторяемая сборка. Так же можно сказать про то, что пересобирать программу не надо. Докер дает зафиксированное окружение, если мы не пересобираем контейнер. Но это не совсем та повторяемость, которую я имею в виду, когда говорю про repeatable builds. В общем вопрос терминологии.

vsb>>Повторяемость может быть важна для некоторых проектов. К примеру для публичных проектов, связанных с безопасностью. Если я скачиваю бинарник того же signal-а, я хочу быть уверенным, что этот бинарник соответствует опубликованным исходникам. И для этого signal поддерживает повторяемость билдов. И даже если я сам это не проверяю, я примерно представляю, что среди тысяч программистов, пользующихся им, хотя бы пара гиков найдётся, которые это проверят за меня и поднимут хай-вай, если что не так.
·>Для упомянутых мною сценариев — тестировать имадж и отправлять ровно его в прод. Воспроизводить прод в тестовом енве для поиска багов ровно в той ревизии, в которой баги возникли в проде.

Ну вот у меня в тестовом окружении то, что собирается из HEAD тестовой ветки, а когда надо релизить, я делаю пару отдельных коммитов, которые меняют версию в pom.xml и на этот коммит вешается git-тег, по которому контейнер пересобирается. В исходниках из отличий только 1.2.0-SNAPSHOT меняется на 1.2.0, но формально образ пересоберётся другой. И вот не было пока с этой схемой проблем, чтобы я захотел это как-то исправить.