Не копировать исходники проекта в базовый образ

[Znack]

Сейчас на нашем проекте столкнулись с неочевидной багой. У нас есть базовый образ в котором мы компилим зависимости, чтобы потом долго не ждать. Ожнако если из проекта удалить файл, но не пересобрать базовый образ, то этот файл останется в базовом образе и докер контейнеры будут пытаться собрать с ним же и будут фейлиться (если не компиляется утсаревший файл этот). Но базовый контейнер по своей задумке должен пересобираться редко, только когда изменились зависимости, тут же надо в голове держать постоянно, что надо его ещё пересобирать после каждого удаления файла.

В итоге решение такое должно быть, что в базовом образе вообще файлов с исходниками быть не должно

[Znack]

@stanislav-az обрати внимание, на что напоролись в проекте :)

[Znack]

@antonkalinin-ml можно ещё вот над этой задачкой интересной подумать :)

[antonkalinin-ml]

Можно удалять все исходники в базовом образе после сборки зависимостей. Можно в производном образе удалять исходники перед копированием новых, чтобы старых не оставалось. Я бы сделал и то, и другое, чтобы вам базовый образ не ребилдить лишний раз.

[Znack]

Ну либо посмотреть как можно элегантно заменить COPY ./ haskell-starter-kit/ чтобы он не копировал всё-всё, а оставлял папку src :)

[antonkalinin-ml]

Чтобы stack build --only-dependencies сработал, должны присутствовать каталоги src, app, test (все пустые) и файлы stack.yaml, stack.yaml.lock, package.yaml, ChangeLog.md и README.md - последние два, потому что упомянуты в package.yaml. Без этого он не сформирует cabal-файл, ему надо прочитать все каталоги с исходниками.

Можно не копировать все, а создавать только нужные каталоги, но это ставит Dockerfile.deps в зависимость от содержимого package.yaml. Раз в год кто-нибудь заведет новую папку, докерфайл забудут обновить, придется терять время на разбирательства, почему не работает. Я бы лучше оставил копирование исходников в базовый образ как есть - это лишние пару секунд, ничто по сравнению с временем сборки зависимостей, зато надежно. В конце сборки зависимостей очистим папку и нормально.

[Znack]

Хм, в целом да, звучит разумно. Да, давай просто после сборки и правда чистить папку src да и всё — дешёво и сердито :)

[antonkalinin-ml]

Вот бы сделать так, чтобы stack сначала загружал базу пакетов, до копирования исходников и запуска stack setup. Большая часть времени при построении deps-образа уходит на базу пакетов и загрузку ghc, одну и ту же работу. База пакетов же не зависит от снапшота? Когда я компилил другой проект с другим снапшотом и версией ghc, он не скачивал базу снова. Докер кеширует часть шагов, но все, что идет после копирования, он не кеширует - видимо, скопированные файлы всегда отличаются.

[antonkalinin-ml]

Открыл ревью #23 .

На будущее можно подумать на тему, как избежать копирования того, что точно не понадобится. Сейчас копируется и папка .git, которая со временем сильно вырастет, и .stack-work (хотя это вряд ли - сервер в докере запускает только фронтенд, у них нет стека локально). Мы могли бы копировать только те файлы, которые есть в гите, при помощи git archive, плюс выбранные локальные конфиги, 3 штуки (а в будущем меньше, если удастся их генерировать при помощи Dhall или скриптов). Безопасный вариант - перед запуском докера создавать скриптом папку, куда копировать все, кроме .git и .stack-work, и эту папку будет забирать докер.

Думаю, нужен скрипт для развертывания проекта - скопировать те же конфиги. Они не требуют правки, проект можно протестировать и так. Правки понадобятся на проде. Это поможет копированию в докер - скрипт можно будет запускать в контейнере, и все конфиги создадутся с рабочей, дефолтной конфигурацией.

Вот бы сделать так, чтобы stack сначала загружал базу пакетов, до копирования исходников и запуска stack setup.

stack update делает то, что надо :). Снапшот и проект не нужны.

[stanislav-az]

как избежать копирования того, что точно не понадобится

есть же файл .dockerignore , то что в нем не будет копироваться, там уже есть .stack-work , можно добавить .git

[antonkalinin-ml]

stack дружит с докером: https://docs.haskellstack.org/en/stable/docker_integration/ .
Для каждого снапшота есть свой образ с предустановленным ghc, и вроде как даже есть образы с предварительно собранными либами в стекедже. Каталог проекта и ~/.stack монтируются внутрь образа, поэтому ничего копировать не надо и результаты билда не теряются. Однако это требует установки стека локально. Без стека на машине мало что можно сделать для экономии времени билда - для начала, чтобы скачать правильный образ с нужным ghc и либами, нужно распарсить stack.yaml. Если бы на машины фронтендеров можно было ставить стек, проблем было бы меньше :).

[stanislav-az]

stack дружит с докером: https://docs.haskellstack.org/en/stable/docker_integration/ .

я пытался это использовать, очень большой образ, обновляется редко, так что там будет даунгрейд lts
использовать не очень удобно, так как все команды stack ... теперь после этого изменяются, чтобы учитывать одну строчку в конфиге стека, делают дополнительную работу связанную с образом. это не очень удобно для разработки бекенда

[stanislav-az]

могут быть еще дополнительные проблемы по настройке образа, так как мы будем использовать существующую систему, это дает меньше свободы, я использовал вот этот гайд https://www.fpcomplete.com/blog/2017/12/building-haskell-apps-with-docker/ , если хочешь попробовать настроить (но это не так хорошо работает как оказалось)

[antonkalinin-ml]

как избежать копирования того, что точно не понадобится

есть же файл .dockerignore , то что в нем не будет копироваться, там уже есть .stack-work , можно добавить .git

Здорово, это самый простой вариант.

Кстати, заметил, что stack.yaml.lock заигнорен в .gitignore и .dockerignore. Локфайлы нельзя игнорить, они важны для воспроизводимости билда и должны быть в системе контроля версий: https://docs.haskellstack.org/en/stable/lock_files/#lock-files . Если не возражаете, я его добавлю в гит и уберу из игнора.