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

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

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

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