Комментарии 20
Как упаковать VueJS + NodeJS + MongoDB приложение в Docker для среды разработки
Для продакшена такая конфа не подходит, для разработки тоже не очень. Это надо на каждый чих пересобирать всё.
Dockerfile для vue для прода должен выглядеть как-то так:
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;"]
Для разработки можно добавить маппинг к соурс коду
Для разрабоки лучше просто делать
RUN npm run serve
RUN npm run serve
Как контейнер исходный код получать будет?
Честно говоря, не знаю. Я ещё не дошёл до того, чтобы под докером разрабатывать, пока я только деплоить в прод более/менее умею.
Потому и говорю, что с удовольствием почитал годные IRL конфиги.
Потому и говорю, что с удовольствием почитал годные IRL конфиги.
docs.docker.com/storage/bind-mounts/#start-a-container-with-a-bind-mount При помощи биндинга можно чтоб код с локальной машины синхронизировался с контейнером, и docker build каждый раз делать не придется!
Да, согласен. Но в случае с языками типа python ребилд понадобится, когда изменились зависимости (requirements.txt или аналог). Благо это случается не каждый день
В чем проблема? Можно просто зайти в конейнер через docker exec и сделать pip install -r requirements.txt
- Лишнее действие. Что ребилд, что екзек — +1 шаг
- А потом при очередном пересоздания контейнера мы наши переустановленные компоненты потеряем.
Поэтому — ребилд надёжнее и больше рекомендуется
1. docker exec -it container_name pip install -r req.txt |VS| pip install -r req.txt
Не вижу +1 шаг.
2. Что вы потеряете когда результат pip install проброшен на хост?
Не вижу +1 шаг.
2. Что вы потеряете когда результат pip install проброшен на хост?
- необходимость самого pip install — это плюс один шаг, плюс образ для контейнера какой-то автомагией у Вас появляется? Т.е. в Dockerfile зачастую этот pip install уже есть.
- зависит от того — как используются volume/bind-mount (ага, их тоже чистить иногда надо, чтобы не плодить конфликтов), ну, и по умолчанию — pip install ставит в системный каталог + ему могут понадобиться системные зависимости, которые вряд ли будете прокидывать на хост. Ну, ок, можно pyenv использовать, но там свои нюансы.
Ваша конфигурация тоже не очень подходит для продакшена. Нужно сохранять package-lock.json и использовать npm ci вместо npm install.
Это гайд для новичков, чтобы потыкать докер.
Я не понимаю как вы будете деплоить свои приложения без env vars при сборке, в разные среды (dev, prod, test, staging).
Чтобы иметь возможность деплоить один и тот же код в разные среды — нужно либо пробрасывать ARGs в докерфайл (+ 1 файл поддерживать для изменения env vars), либо выполнять сборку кода до упаковки в образ (+1 шаг в CI). Ещё есть werf. Остальное — неюзабельно в нормальной разработке.
Я не понимаю как вы будете деплоить свои приложения без env vars при сборке, в разные среды (dev, prod, test, staging).
Чтобы иметь возможность деплоить один и тот же код в разные среды — нужно либо пробрасывать ARGs в докерфайл (+ 1 файл поддерживать для изменения env vars), либо выполнять сборку кода до упаковки в образ (+1 шаг в CI). Ещё есть werf. Остальное — неюзабельно в нормальной разработке.
ну вот для vue heroku без монги как-то так:
Dockerfile
entrypoint.sh
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 "$@"
Куча вопросов.
- Ports и host network mode вместе бессмысленны
- Links obsoleted. Сам докер предлагает бриджовые сети
- В dockerfile EXPOSE 8081, в компоузе — 8089. Где Л — логика ?
- depends_on не ждёт готовности контейнера, а только лишь отрабатывает по факту его создания. Это может давать неприятные эффекты, например, если server валится с эксепшенем или долго стартует
- Если нет сворма — лучше использовать формат докер-компоуз файла 2.4
- В инструкции не отмечено, что после пересоздания контейнера с монгой — база будет пустая.
И коли уж такая пьянка, то для локальной разработки лучше DOKKU подходит, чем эти костыли из докер + компоуз
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как упаковать VueJS + NodeJS + MongoDB приложение в Docker