Сообщение Re[4]: а зачем это разработчику? от 02.11.2023 12:18
Изменено 02.11.2023 12:20 vsb
Re[4]: а зачем это разработчику?
Здравствуйте, sergey2b, Вы писали:
N>>Жизнь такая штука... люди приходят и уходят, репозитории меняются, код переносится, сервера падают, и в один день остаёшься без понимания, как развернуть проект тк все, что есть в документации: используйте докер компоуз, а он не работает. А ещё есть мильён непонятных зависимостей и столько же срочных задач по разработке.
N>>Результат: нигде не поднять кроме прода, тестировать там же.
S>через год полтора image не собираеться тк не доступны зависимости
Такая проблема, конечно, может быть, но вообще это плохой image, если не собирается.
Во-первых, если стоит такая задача — собирать образ через полгода — надо указывать точные базовые образы, вплоть до хешей.
Во-вторых вытаскивать эти базовые образы и на целевой системе загружать (docker save/docker load вроде) перед сборкой.
В-третьих всё, что хочется скачать — надо скачивать заранее и класть рядом с докерфайлом.
В-четвёртых тестировать сборку на оффлайн машине.
В-пятых всё вышеописанное хранить наряду с остальными артекактами.
Очень много организаций требуют сборки приложения в оффлайн-окружении, в этом нет ничего особенного и все популярные технологии это позволяют тем или иным образом.
Но таки — да, про это надо думать заранее.
N>>Жизнь такая штука... люди приходят и уходят, репозитории меняются, код переносится, сервера падают, и в один день остаёшься без понимания, как развернуть проект тк все, что есть в документации: используйте докер компоуз, а он не работает. А ещё есть мильён непонятных зависимостей и столько же срочных задач по разработке.
N>>Результат: нигде не поднять кроме прода, тестировать там же.
S>через год полтора image не собираеться тк не доступны зависимости
Такая проблема, конечно, может быть, но вообще это плохой image, если не собирается.
Во-первых, если стоит такая задача — собирать образ через полгода — надо указывать точные базовые образы, вплоть до хешей.
Во-вторых вытаскивать эти базовые образы и на целевой системе загружать (docker save/docker load вроде) перед сборкой.
В-третьих всё, что хочется скачать — надо скачивать заранее и класть рядом с докерфайлом.
В-четвёртых тестировать сборку на оффлайн машине.
В-пятых всё вышеописанное хранить наряду с остальными артекактами.
Очень много организаций требуют сборки приложения в оффлайн-окружении, в этом нет ничего особенного и все популярные технологии это позволяют тем или иным образом.
Но таки — да, про это надо думать заранее.
Re[4]: а зачем это разработчику?
Здравствуйте, sergey2b, Вы писали:
N>>Жизнь такая штука... люди приходят и уходят, репозитории меняются, код переносится, сервера падают, и в один день остаёшься без понимания, как развернуть проект тк все, что есть в документации: используйте докер компоуз, а он не работает. А ещё есть мильён непонятных зависимостей и столько же срочных задач по разработке.
N>>Результат: нигде не поднять кроме прода, тестировать там же.
S>через год полтора image не собираеться тк не доступны зависимости
Такая проблема, конечно, может быть, но вообще это плохой image, если не собирается.
Во-первых, если стоит такая задача — собирать образ через полгода — надо указывать точные базовые образы, вплоть до хешей.
Во-вторых вытаскивать эти базовые образы и на целевой системе загружать (docker save/docker load вроде) перед сборкой.
В-третьих всё, что хочется скачать — надо скачивать заранее и класть рядом с докерфайлом.
В-четвёртых тестировать сборку на оффлайн машине.
В-пятых всё вышеописанное хранить наряду с остальными артефактами.
Очень много организаций требуют сборки приложения в оффлайн-окружении, в этом нет ничего особенного и все популярные технологии это позволяют тем или иным образом.
Но таки — да, про это надо думать заранее.
N>>Жизнь такая штука... люди приходят и уходят, репозитории меняются, код переносится, сервера падают, и в один день остаёшься без понимания, как развернуть проект тк все, что есть в документации: используйте докер компоуз, а он не работает. А ещё есть мильён непонятных зависимостей и столько же срочных задач по разработке.
N>>Результат: нигде не поднять кроме прода, тестировать там же.
S>через год полтора image не собираеться тк не доступны зависимости
Такая проблема, конечно, может быть, но вообще это плохой image, если не собирается.
Во-первых, если стоит такая задача — собирать образ через полгода — надо указывать точные базовые образы, вплоть до хешей.
Во-вторых вытаскивать эти базовые образы и на целевой системе загружать (docker save/docker load вроде) перед сборкой.
В-третьих всё, что хочется скачать — надо скачивать заранее и класть рядом с докерфайлом.
В-четвёртых тестировать сборку на оффлайн машине.
В-пятых всё вышеописанное хранить наряду с остальными артефактами.
Очень много организаций требуют сборки приложения в оффлайн-окружении, в этом нет ничего особенного и все популярные технологии это позволяют тем или иным образом.
Но таки — да, про это надо думать заранее.