Pull to refresh
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. Как собирается фронт в таком подходе?
  1. Можно и руками, только каждый раз писать --user "$(id -u):$(id -g)" довольно утомительно. Поэтому и живут эти штуки в Makefile. CURRENT_USER нужен там, где нужно как-то переопределить пользователя (остальные сервисы должны запускаться от рука, как обычно). Не замечал, чтоб после появления Makefile разработчики что-то делали уже без него, но руками запускать docker-compose никто не запрещает
  2. Рут, рут (надо бы сменить на локального пользователя, да)
  3. ~24 строка в docker-compose.yml
  4. cat ./docker/docker-compose.env | grep HOME
  5. Кэш composer-а (zip / tar) архивы, не сами зависимости, только кэш
  6. Отдельный шудлер, который дергает нужную ручку (резилы + master всегда остаются)
  7. Например: 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 перед сборкой самого приложения (+ кэш и "всё такое"). Но лучше разделять такие штуки
Про схему боевых проэктов тоже было бы интересно узнать, хотя бы в теории. спасибо
Уточните, данную сборку используете dev или на проде тоже?
Если на проде тоже, то у Вас выходит все компоненты в одном образе (и база, и fpm, и nginx). Тогда смысл использовать docker теряется, т.к. подразумевается, что один контейнер используется для бд, другой для fpm и т.д. ИМХО

На проде БД в докер-контейнерах использовать нельзя.


P.S. А я вот подумал, кажется можно, если нормально ФС примонтировать. Хотя всё равно это чревато, имхо.

Знакомый DevOps говорит что это не плохое решение (правильно примонтировав ФС), но… Что на счет достижения консистентности данных в случае, если контейнер с БД на node-1 упадет, а поднимется на node-2 (физически другом сервере) очень быстро — что обеспечит тот факт, что состояние ФС на node-2 будет точно таким-же, какое было на node-1 в момент падения контейнера? Разве что силами Gluster FS. Для БД с не критичными данными, мол, так ещё можно делать. А для инстансов где данные важны — юзать Stolon. Но это же уже не "просто монтировать ФС"

Короче, это можно подытожить тем, что для решений на VDS/VPS — это вполне допустимо. В остальных случаях не стоит. Нет профита запускать БД на сервере, где только БД внутри докера.


Так ведь?

Я являюсь сторонником запуска критичных сервисов (шины данных, БД) на bare-metal, но и знаю ребят, что всё пускают в контейнерах

Как вариант: прибивать базу к конкретной ноде. Везде, где видел-слышал про базу в докере на проде, только водном случае она не была прибит арукми к ноде.

Only those users with full accounts are able to leave comments. Log in, please.