Comments 7
Временный файл избыточен, проще сделать так:
--env-file <(printenv)
Сейчас же разработчики docker переписали утилиту на go
А вы в исходники на том самом гитхабе заглядывали? Я вот что-то беглым осмотром не нашёл ничего там про Go, зато там полно питонячих файлов.
Скорее всего те бинарники, которые у них лежат в релизах — это, «запакованный» в один исполняемый файл, Python со всем нужным для запуска docker-compose.
Возможно, что я и ошибся. Я точно знал, что есть проект github.com/docker/libcompose
Поэтому тенденция для переписывания на Go точно есть.
Сам бинарь открыл в hex-редакторе, погонял — да, похоже, что это просто python-скрипт упакованный в исполняемый файл. Нужно будет еще посмотреть внимательно.
Поэтому тенденция для переписывания на Go точно есть.
Сам бинарь открыл в hex-редакторе, погонял — да, похоже, что это просто python-скрипт упакованный в исполняемый файл. Нужно будет еще посмотреть внимательно.
А зачем писать свой скрипт? На странице релизов поставляется ровно такая же обертка над запуском контейнера с docker-compose внутри — run.sh, так сказать от производителя:)
Как минимум две причины.
- выпендриться :-) и сделать самим.
- мы активно пользуемся интерполяцией переменных в docker-compose файлах. Т.е. есть .env, в котором определены переменные и они подставляются в yamlики. Возможно, это неверный подход, т.к. правильнее деплоить уже готовый yaml на целевую машину. В изначальном run.sh, который предоставляли разрабы — эта функция (интерполяция) не работала, поэтому пришлось придумывать способ прокинуть environment с основной машины в контейнер с компоузом
Sign up to leave a comment.
Еще один способ использования docker-compose