правильно?) через докер файл при его сборке. А контейнеры мы запускаем через оркестрацию docker compose, который по сути запускает их 1:1 как они есть, и отдельно хранятся данные в volumes
И что тебе мешает запустить контейнер на базе собранного образа чтобы посмотреть что там идет не так? Что мешает внутри контейнера отлаживать команду и потом рабочий вариант пихнуть в докерфайл?
ну ща попробую, просто я думал, есть какой-то беспрактиз в части докеризации бутстрапа
А тут не важно что ты докеризуешь, ты как бы образ ОС собираешь, вот и собери проект со стилями. В докере он или не в докере вообще значения не имеет.
ок, вопрос, мне заявзываться на lock файлы? или нет? или просто с нуля пихать? как обычно практика?
Я тебе еще раз говорю что не важно в докер ты пихаешь или нет. Вопрос в том какие файлы ты куда копируешь, что запускаешь и что получается. Если бы ты напрямую на сервер деплоил то ты бы делал схожие шаги по сборке ассетов.
В volumes у тебя что прописано в докер композе?
postgres42: image: postgres:15.0-alpine volumes: - postgres_vol_new:/var/lib/postgresql/data:cached - ./init.sql:/rails/init.sql
Тогда не понимаю проблемы. Собираешь образ, заходишь в контейнер, запускаешь нужную команду и смотришь что не работает.
Понял, окк. Кстати вопрос, а есть ли прием как ускорить сборку образа? 1900 секунд , вроде все cached
Да, COPY/ADD команды сбрасывают кэш всех следующих шагов если в наборе файлов поменялся хоть один.
Обсуждают сегодня