Рекомендации по сборке и производству контейнеров Node Docker - PullRequest
Новая
       12

Рекомендации по сборке и производству контейнеров Node Docker

0 голосов
/ 11 июля 2019

У меня есть проект Node, который использует MongoDB.Для автоматического тестирования мы используем Сервер памяти Mongo

Для сервера памяти Mongo Alpine не поддерживается моим Mongo, поэтому он не может работать на изображениях Alpine

ОтДокументы:

На данный момент нет официального релиза MongoDB для Alpine Linux.Это означает, что мы не можем извлекать двоичные файлы для Alpine (или любой другой платформы, которая официально не поддерживается MongoDB), но вы можете использовать образ Docker, в который уже встроен mongod, а затем установить переменную MONGOMS_SYSTEM_BINARY так, чтобы она указывала на этот двоичный файл.,Это должно позволить вам использовать mongodb-memory-server в любой системе, на которой вы можете установить mongod.

Я могу запустить все свои тесты в контейнере Docker, используя базовый образ Node, но для производстваЯ хочу использовать изображение Alpine для экономии памяти.

, поэтому мой Dockerfile выглядит примерно так. 

FROM node:x.x.x as test

WORKDIR /app

COPY . /app

npm install
npm run build # we use Typescript, this runs the transpilation
npm test # runs our automated tests

FROM node:x.x.x-alpine

WORKDIR /app

COPY --from=test /app/src /app/src
COPY --from=test /app/package.json /app/package.json
COPY --from=test /app/package-lock.json /app/package-lock.json
COPY --from=test /app/config /app/config
COPY --from=test /app/scripts /app/scripts

RUN npm install --production

RUN npm run build

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

Мне интересно, это лучший метод?Есть ли лучший способ сделать что-то подобное?То есть, в частности, для Node безопасно иметь большой тестовый контейнер и маленький производственный контейнер.

1 Ответ

0 голосов
/ 11 июля 2019

Несколько баллов

  1. Если вы строите дважды, в чем смысл многоступенчатой ​​сборки. Я не делаю много node вещей. Но причина, по которой вам нужно многоэтапное построение, заключается в том, что вы создаете свое приложение с npm build, которое берет эти артефакты и копирует их в образ и обслуживает / запускает их каким-то образом. В мире go это было бы что-то вроде сборки на этапе сборки, а затем просто запуска двоичного кода.
  2. Вы всегда хотите, чтобы в верхней части объединенной файловой системы были самые изменяющиеся вещи. Это означает, что вместо того, чтобы копировать весь код приложения и запускать npm install, вы должны скопировать только package.json и запустить на нем npm install. Таким образом, docker может кэшировать результат установки npm и сохранять при загрузке файлов узлов, если ничего не изменилось сверху. Код вашего приложения изменяется намного больше, чем package.json
  3. На втором этапе та же идея. Если вам нужно - сначала скопировать package.json и запустить npm install, затем скопируйте оставшуюся часть.
  4. Вы можете иметь больше этапов, если хотите. Название игры состоит в том, чтобы получить самое чистое и чистое изображение финальной стадии. Это тот, который идет на реестр. Все остальное можно и нужно убрать.

Надеюсь, это поможет.

...