Докеризация приложения, построенного на базе React, Express и MongoDB

Автор статьи, перевод которой мы публикуем сегодня, хочет рассказать о том, как упаковывать в контейнеры Docker веб-приложения, основанные на React, Express и MongoDB. Здесь будут рассмотрены особенности формирования структуры файлов и папок таких проектов, создание файлов Dockerfile и использование технологии Docker Compose.

Начало работы

Ради простоты изложения я предполагаю, что у вас уже имеется работающее приложение, представленное клиентской и серверной частями, подключённое к базе данных.

Лучше всего, если клиентский и серверный код будет расположен в одной и той же папке. Код может располагаться в одном репозитории, но он может храниться и в разных репозиториях. В таком случае проекты стоит скомбинировать в одной папке с использованием команды git submodule. Я поступил именно так.


Дерево файлов родительского репозитория

React-приложение

Здесь я использовал проект, созданный с помощью Create React App и настроенный на поддержку TypeScript. Это — простой блог, содержащий несколько визуальных элементов.

Первым делом создадим файл Dockerfile в корневой директории client. Для того чтобы это сделать, достаточно выполнить такую команду:

$ touch Dockerfile

Откроем файл и введём в него команды, представленные ниже. Как уже было сказано, я пользуюсь в своём приложении TypeScript, поэтому мне сначала нужно собрать его. Затем нужно взять то, что получилось, и развернуть это всё в формате статических ресурсов. Для того чтобы этого достичь, я пользуюсь двухступенчатым процессом сборки образа Docker.

Первый шаг работы заключается в использовании Node.js для сборки приложения. Я использую, в качестве базового образа, образ Alpine. Это — весьма компактный образ, что благотворно скажется на размере контейнера.

FROM node:12-alpine as builder
WORKDIR /app
COPY package.json /app/package.json
RUN npm install --only=prod
COPY . /app
RUN npm run build

Так начинается наш Dockerfile. Сначала идёт команда node:12-alpine as builder. Затем мы задаём рабочую директорию — в нашем случае это /app. Благодаря этому в контейнере будет создана новая папка. В эту папку контейнера копируем package.json и устанавливаем зависимости. Затем в /app мы копируем всё из папки /services/client. Работа завершается сборкой проекта.

Теперь надо организовать хостинг для только что созданной сборки. Для того чтобы это сделать, воспользуемся NGINX. И, опять же, это будет Alpine-версия системы. Делаем мы это, как и прежде, ради экономии места.

FROM nginx:1.16.0-alpine
COPY --from=builder /app/build /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

Здесь в папку nginx копируются результаты сборки проекта, полученные на предыдущем шаге. Затем открываем порт 80. Именно на этом порте контейнер будет ожидать подключений. Последняя строка файла используется для запуска NGINX.

Это — всё, что нужно для докеризации клиентской части приложения. Итоговый Dockerfile будет выглядеть так:

FROM node:12-alpine as build
WORKDIR /app
COPY package.json /app/package.json
RUN npm install --only=prod
COPY . /app
RUN npm run build
FROM nginx:1.16.0-alpine
COPY --from=build /app/build /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

Express-API

Наш Express-API тоже довольно прост. Тут, для организации конечных точек, используется технология RESTful. Конечные точки применяются для создания публикаций, для поддержки авторизации и для решения других задач. Начнём работу с создания Dockerfile в корневой директории api. Действовать будем так же, как и прежде.

В ходе разработки серверной части приложения я пользовался возможностями ES6. Поэтому мне, чтобы запустить код, нужно его скомпилировать. Я решил обработать код с помощью Babel. Как вы уже, возможно, догадались, тут снова будет использован многоступенчатый процесс сборки.

FROM node:12-alpine as builder
WORKDIR /app
COPY package.json /app/package.json
RUN apk --no-cache add --virtual builds-deps build-base python
RUN npm install
COPY . /app
RUN npm run build

Здесь всё очень похоже на тот Dockerfile, который мы использовали для клиентской части проекта, поэтому в подробности вдаваться мы не будем. Однако здесь есть одна особенность:

RUN apk --no-cache add --virtual builds-deps build-base python

Я, перед сохранением паролей в базе данных, хэширую их с помощью bcrypt. Это — весьма популярный пакет, но при использовании его в образах, основанных на Alpine, наблюдаются некоторые проблемы. Тут можно столкнуться с примерно такими сообщениями об ошибках:

node-pre-gyp WARN Pre-built binaries not found for bcrypt@3.0.8 and node@12.16.1 (node-v72 ABI, musl) (falling back to source compile with node-gyp)
npm ERR! Failed at the bcrypt@3.0.8 install script.

Это — широко известная проблема. Её решение заключается в установке дополнительных пакетов и Python перед установкой npm-пакетов.

Следующий этап сборки образа, как и в случае с клиентом, заключается в том, чтобы взять то, что было сформировано на предыдущем этапе, и запустить это с помощью Node.js.

FROM node:12-alpine
WORKDIR /app
COPY --from=builder /app/dist /app
COPY package.json /app/package.json
RUN apk --no-cache add --virtual builds-deps build-base python
RUN npm install --only=prod
EXPOSE 8080 
USER node
CMD ["node", "index.js"]

Здесь есть ещё одна особенность, которая заключается в установке только тех пакетов, которые предназначены для работы проекта в продакшне. Babel нам больше не нужен — ведь всё уже было скомпилировано на первом шаге сборки. Далее, мы открываем порт 8080, на котором серверная часть приложения будет ожидать поступления запросов, и запускаем Node.js.

Вот итоговый Dockerfile:

FROM node:12-alpine as builder
WORKDIR /app
COPY package.json /app/package.json
RUN apk --no-cache add --virtual builds-deps build-base python
RUN npm install
COPY . /app
RUN npm run build
FROM node:12-alpine
WORKDIR /app
COPY --from=builder /app/dist /app
COPY package.json /app/package.json
RUN apk --no-cache add --virtual builds-deps build-base python
RUN npm install --only=prod
EXPOSE 8080 
USER node
CMD ["node", "index.js"]

Docker Compose

Последний этап нашей работы заключается в объединении контейнеров api и client с контейнером, содержащим MongoDB. Для того чтобы это сделать, воспользуемся файлом docker-compose.yml, размещённым в корневой директории родительского репозитория. Это делается так из-за того, что из этого места есть доступ к файлам Dockerfile для клиентской и серверной частей проекта.

Создадим файл docker-compose.yml:

$ touch docker-compose.yml

Теперь структура файлов проекта должна выглядеть так, как показано ниже.


Итоговая структура файлов проекта

Теперь внесём в docker-compose.yml следующие команды:

version: "3"
services:
  api:
    build: ./services/api
    ports:
      - "8080:8080"
    depends_on:
      - db
    container_name: blog-api
  client:
    build: ./services/client
    ports:
      - "80:80"
    container_name: blog-client
  db:
    image: mongo
    ports:
      - "27017:27017"
    container_name: blog-db

Тут всё устроено очень просто. У нас имеется три сервиса: client, api и db. Для MongoDB нет выделенного Dockerfile — Docker загрузит соответствующий образ со своего хаба и создаст из него контейнер. Это означает, что наша база данных будет пустой, но нас, для начала, это устроит.

В разделах api и client имеется ключ build, значение которого содержит путь к файлам Dockerfile соответствующих сервисов (к корневым директориям api и client). Порты контейнеров, назначенные в файлах Dockerfile, будут открыты в сети, организуемой Docker Compose. Это позволит приложениям взаимодействовать. При настройке сервиса api, кроме того, используется ключ depends_on. Он сообщает Docker о том, что, прежде чем запускать этот сервис, нужно дождаться полного запуска контейнера db. Благодаря этому мы сможем предотвратить возникновение ошибок в контейнере api.

И — вот ещё одна мелочь, имеющая отношение к MongoDB. В кодовой базе бэкенда нужно обновить строку подключения к базе данных. Обычно она указывает на localhost:

mongodb://localhost:27017/blog

Но, применяя технологию Docker Compose, мы должны сделать так, чтобы она указывала бы на имя контейнера:

mongodb://blog-db:27017/blog

Финальный шаг нашей работы заключается в том, чтобы всё это запустить, выполнив в корневой папке проекта (там, где находится файл docker-compose.yml) следующую команду:

$ docker-compose up

Итоги

Мы рассмотрели несложную методику контейнеризации приложений, основанных на React, Node.js и MongoDB. Полагаем, если вам это понадобится, вы сможете легко адаптировать её для своих проектов.

P.S. Мы запустили маркетплейс на сайте RUVDS. Имеющийся там образ Docker устанавливается в один клик. Проверить работу контейнеров можно на VPS. Новым клиентам бесплатно предоставляются 3 дня для тестов.

Уважаемые читатели! Пользуетесь ли вы Docker Compose?