Как упаковать VueJS + NodeJS + MongoDB приложение в Docker

[xkondorx]

Как упаковать VueJS + NodeJS + MongoDB приложение в Docker для среды разработки

[vasyapivo]

Для продакшена такая конфа не подходит, для разработки тоже не очень. Это надо на каждый чих пересобирать всё.
Dockerfile для vue для прода должен выглядеть как-то так:

FROM node:12 as build
WORKDIR /app
ENV PATH /app/node_modules/.bin:$PATH
COPY package.json /app/package.json
RUN npm install --silent
RUN npm install @vue/cli -g
COPY . /app
RUN npm run build

FROM nginx:1.16.0-alpine
COPY --from=build /app/dist /usr/share/nginx/html
RUN rm /etc/nginx/conf.d/default.conf
COPY nginx.conf /etc/nginx/conf.d
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]


[marataziat]

Для разработки можно добавить маппинг к соурс коду

[vasyapivo]

Для разрабоки лучше просто делать
RUN npm run serve

[marataziat]

Как контейнер исходный код получать будет?

[vasyapivo]

Честно говоря, не знаю. Я ещё не дошёл до того, чтобы под докером разрабатывать, пока я только деплоить в прод более/менее умею.
Потому и говорю, что с удовольствием почитал годные IRL конфиги.

[marataziat]

docs.docker.com/storage/bind-mounts/#start-a-container-with-a-bind-mount При помощи биндинга можно чтоб код с локальной машины синхронизировался с контейнером, и docker build каждый раз делать не придется!

[gecube]

Да, согласен. Но в случае с языками типа python ребилд понадобится, когда изменились зависимости (requirements.txt или аналог). Благо это случается не каждый день

[marataziat]

В чем проблема? Можно просто зайти в конейнер через docker exec и сделать pip install -r requirements.txt

[gecube]

1. Лишнее действие. Что ребилд, что екзек — +1 шаг
2. А потом при очередном пересоздания контейнера мы наши переустановленные компоненты потеряем.

Поэтому — ребилд надёжнее и больше рекомендуется

[ReDev1L]

1. docker exec -it container_name pip install -r req.txt |VS| pip install -r req.txt
Не вижу +1 шаг.

2. Что вы потеряете когда результат pip install проброшен на хост?

[gecube]

1. необходимость самого pip install — это плюс один шаг, плюс образ для контейнера какой-то автомагией у Вас появляется? Т.е. в Dockerfile зачастую этот pip install уже есть.
2. зависит от того — как используются volume/bind-mount (ага, их тоже чистить иногда надо, чтобы не плодить конфликтов), ну, и по умолчанию — pip install ставит в системный каталог + ему могут понадобиться системные зависимости, которые вряд ли будете прокидывать на хост. Ну, ок, можно pyenv использовать, но там свои нюансы.

[MikalaiR]

Ваша конфигурация тоже не очень подходит для продакшена. Нужно сохранять package-lock.json и использовать npm ci вместо npm install.

[ReDev1L]

Это гайд для новичков, чтобы потыкать докер.
Я не понимаю как вы будете деплоить свои приложения без env vars при сборке, в разные среды (dev, prod, test, staging).
Чтобы иметь возможность деплоить один и тот же код в разные среды — нужно либо пробрасывать ARGs в докерфайл (+ 1 файл поддерживать для изменения env vars), либо выполнять сборку кода до упаковки в образ (+1 шаг в CI). Ещё есть werf. Остальное — неюзабельно в нормальной разработке.

[vasyapivo]

Да бестолковый гайд на самом деле, даже чтобы потыкать в докер.
Вот реально бы на хороший конфиг посмотреть.
Чтобы всё собралось, потом mongo заполнилась тестовыми данными. Потом тесты прогнались.

[DrrRos]

Это реально рабочий проект уже, таким делятся после окончания NDA, думаю.

[sashavoloh]

Да, вы правы, можно дописать пример с ARGs. Но это петпроект, а не живое приложение пока еще.

[ReDev1L]

А смысл? Таких руководств в сети — море.

[tenhi_shadow]

ну вот для vue heroku без монги как-то так:

Dockerfile

FROM node:lts-alpine AS build
  WORKDIR /build
  COPY . .
  ARG VUE_APP_BASE_DOMAIN
  ARG VUE_APP_ROLLBAR_TOKEN
  ARG VUE_APP_ROLLBAR_ENV
  RUN set -x && \
      yarn install && \
      yarn build

FROM nginx:stable-alpine
  # for local builds; will be overrided by heroku
  ENV PORT="80"
  COPY --from=build /build/dist /usr/share/nginx/html
  COPY nginx.conf /etc/nginx/nginx.conf
  COPY entrypoint.sh /usr/bin/
  RUN chmod +x /usr/bin/entrypoint.sh
  # ignored for heroku
  EXPOSE ${PORT}
  ENTRYPOINT ["entrypoint.sh"]
  CMD [ "nginx","-g", "daemon off;"]   

entrypoint.sh

#!/bin/sh
set -xe

echo "DEBUG: Docker - entrypoint init"
echo "DEBUG: Nginx port is ${PORT}"
echo "DEBUG: changing port in config"
sed -i "s/CHANGEME_NGINX_PORT/${PORT}/" /etc/nginx/nginx.conf

# exec the container's main process (what's set as CMD in the Dockerfile).
exec "$@"

[gecube]

Куча вопросов.

1. Ports и host network mode вместе бессмысленны
2. Links obsoleted. Сам докер предлагает бриджовые сети
3. В dockerfile EXPOSE 8081, в компоузе — 8089. Где Л — логика ?
4. depends_on не ждёт готовности контейнера, а только лишь отрабатывает по факту его создания. Это может давать неприятные эффекты, например, если server валится с эксепшенем или долго стартует
5. Если нет сворма — лучше использовать формат докер-компоуз файла 2.4
6. В инструкции не отмечено, что после пересоздания контейнера с монгой — база будет пустая.

И коли уж такая пьянка, то для локальной разработки лучше DOKKU подходит, чем эти костыли из докер + компоуз