Как создать образ докера из проекта nodejs в монорепозитории с рабочими пространствами yarn

Я работал над проектом по структуре, подобной вашей, он выглядел так:

project
├── package.json
├── packages
│   ├── package1
│   │   ├── package.json
│   │   └── src
│   ├── package2
│   │   ├── package.json
│   │   └── src
│   └── package3
│       ├── package.json
│       └── src
├── services
│   ├── service1
│   │   ├── Dockerfile
│   │   ├── package.json
│   │   └── src
│   └── service2
│       ├── Dockerfile
│       ├── package.json
│       └── src
└── yarn.lock

Папка services/ содержит по одной службе на каждую подпапку. Каждая служба написана на node.js и имеет свой собственный package.json и Dockerfile. Обычно это веб-сервер или REST API на основе Express.

Папка packages/ содержит все пакеты, не являющиеся службами, обычно это внутренние библиотеки.

Услуга может зависеть от одного или нескольких пакетов, но не от другой службы. Пакет может зависеть от другого пакета, но не от службы.

Основной package.json (тот, что находится в корневой папке проекта) содержит только некоторые devDependencies, такие как eslint, средство запуска тестов и т. Д.

Индивидуум Dockerfile выглядит так, если предположить, что service1 зависит как от package1, так и package3:

FROM node:8.12.0-alpine AS base

WORKDIR /project

FROM base AS dependencies

# We only copy the dependencies we need
COPY packages/package1 packages/package1
COPY packages/package3 packages/package3

COPY services/services1 services/services1

# The global package.json only contains build dependencies
COPY package.json .

COPY yarn.lock .

RUN yarn install --production --pure-lockfile --non-interactive --cache-folder ./ycache; rm -rf ./ycache

Фактические Dockerfile, которые я использовал, были более сложными, так как им приходилось собирать подпакеты, запускать тесты и т. Д. Но вы должны получить представление об этом примере.

Как видите, хитрость заключалась в том, чтобы скопировать только те пакеты, которые необходимы для конкретной службы. Файл yarn.lock содержит список package @ version с точной версией и разрешенными зависимостями. Скопировать его без всех подпакетов не проблема, yarn будет использовать версию, разрешенную там, при установке зависимостей включенных пакетов.

В вашем случае проект, поддерживающий реакцию, никогда не будет частью какого-либо Dockerfile, поскольку он не зависит ни от одной из служб, что позволяет сэкономить много места.

Для краткости я опустил много деталей в этом ответе, не стесняйтесь спрашивать точность в комментарии, если что-то не совсем понятно.

После множества проб и ошибок я обнаружил, что осторожное использование файла .dockerignore - отличный способ контролировать ваше окончательное изображение. Это отлично работает при работе в монорепозитории для исключения «других» пакетов.

Для каждого пакета у нас есть файл dockerignore с похожим именем, который заменяет действующий файл .dockerignore непосредственно перед сборкой.

e.g., cp admin.dockerignore .dockerignore

Ниже приведен пример admin.dockerignore. Обратите внимание на * в верхней части этого файла, что означает «игнорировать все». Префикс ! означает «не игнорировать», т. Е. Сохранять. Комбинация означает игнорировать все, кроме указанных файлов.

*
# Build specific keep
!packages/admin

# Common Keep
!*.json
!yarn.lock
!.yarnrc
!packages/common

**/.circleci
**/.editorconfig
**/.dockerignore
**/.git
**/.DS_Store
**/.vscode
**/node_modules

Недавно мы поместили наши серверные службы в монорепозиторий, и это был один из немногих вопросов, которые нам нужно было решить. В Yarn нет ничего, что могло бы помочь нам в этом отношении, поэтому нам пришлось искать в другом месте.

Сначала мы попробовали @ zeit / ncc, были некоторые проблемы, но в конце концов нам удалось получить финальные сборки. Он создает один большой файл, который включает весь ваш код, а также весь код ваших зависимостей. Выглядело великолепно. Мне пришлось скопировать в образ докера только несколько файлов (js, исходные карты, статические ресурсы). Изображения были намного меньше, и приложение работало. НО потребление оперативной памяти сильно выросло. Вместо ~ 70 МБ работающий контейнер потреблял ~ 250 МБ. Не уверен, что мы сделали что-то не так, но я не нашел никакого решения, и есть только одна проблема упомянув об этом. Я предполагаю, что Node.js load анализирует и загружает весь код из пакета, хотя большая его часть никогда не используется.

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

Сейчас мы используем fleggal / monopack. Он связывает наш код с Webpack и переносит его в Babel. Таким образом, он также создает один пакет файлов, но он не содержит всех зависимостей, только наш код. Этот шаг нам не нужен, но мы не против, чтобы он там был. Для нас важная часть - Monopack копирует только производственное дерево зависимостей пакета в dist / bundled node_modules. Это именно то, что нам нужно. Образы Docker теперь имеют размер 100–150 МБ вместо 700 МБ.

Есть один способ попроще. Если у вас всего несколько действительно больших модулей npm в вашем node_modules, вы можете использовать nohoist в корне package.json. Таким образом, yarn сохраняет эти модули в локальном node_modules пакета, и его не нужно копировать в образы Docker всех других служб.

eg.:

"nohoist": [
  "**/puppeteer",
  "**/puppeteer/**",
  "**/aws-sdk",
  "**/aws-sdk/**"
]