Comments 10
1. В docker-compose.yml используется переменная `CURRENT_USER`, которая прокидыавется только из Makefile. Т.е. руками не предполагается работа с docker-compose?
2. Под каким пользователем работает RR на проде и локальнов в контейнере?
3. В docker-compose.yml указан volume `home-dir`, но нигде не описан. Предполагается, что пользователь сам отдельно его создаст?
4. Директория в контейнере /home/user — как она становится домашней для текущего пользователя в контейнере?
5. В образ для прода попадают dev-зависимости composer?
6. Происходит ли и как происходит удаление устаревших образов из docker registry?
7. Как собирается фронт в таком подходе?
- Можно и руками, только каждый раз писать
--user "$(id -u):$(id -g)"довольно утомительно. Поэтому и живут эти штуки в Makefile.CURRENT_USERнужен там, где нужно как-то переопределить пользователя (остальные сервисы должны запускаться от рука, как обычно). Не замечал, чтоб после появления Makefile разработчики что-то делали уже без него, но руками запускать docker-compose никто не запрещает - Рут, рут (надо бы сменить на локального пользователя, да)
- ~24 строка в
docker-compose.yml cat ./docker/docker-compose.env | grep HOME- Кэш composer-а (zip / tar) архивы, не сами зависимости, только кэш
- Отдельный шудлер, который дергает нужную ручку (резилы +
masterвсегда остаются) - Например:
docker run --rm -v "$(pwd):/app:rw" --workdir "/app" "$NODE_IMAGE" npm install && docker run --rm -v "$(pwd):/app:rw" --workdir "/app" -e "NODE_ENV=production" "$NODE_IMAGE" npm run prodперед сборкой самого приложения (+ кэш и "всё такое"). Но лучше разделять такие штуки
Если на проде тоже, то у Вас выходит все компоненты в одном образе (и база, и fpm, и nginx). Тогда смысл использовать docker теряется, т.к. подразумевается, что один контейнер используется для бд, другой для fpm и т.д. ИМХО
На проде БД в докер-контейнерах использовать нельзя.
P.S. А я вот подумал, кажется можно, если нормально ФС примонтировать. Хотя всё равно это чревато, имхо.
Знакомый DevOps говорит что это не плохое решение (правильно примонтировав ФС), но… Что на счет достижения консистентности данных в случае, если контейнер с БД на node-1 упадет, а поднимется на node-2 (физически другом сервере) очень быстро — что обеспечит тот факт, что состояние ФС на node-2 будет точно таким-же, какое было на node-1 в момент падения контейнера? Разве что силами Gluster FS. Для БД с не критичными данными, мол, так ещё можно делать. А для инстансов где данные важны — юзать Stolon. Но это же уже не "просто монтировать ФС"
Короче, это можно подытожить тем, что для решений на VDS/VPS — это вполне допустимо. В остальных случаях не стоит. Нет профита запускать БД на сервере, где только БД внутри докера.
Так ведь?
Как вариант: прибивать базу к конкретной ноде. Везде, где видел-слышал про базу в докере на проде, только водном случае она не была прибит арукми к ноде.
Docker + Laravel + RoadRunner = ❤