Должен ли разработчик создавать артефакт докера из lerna monorepo в своей среде разработки? - PullRequest
2 голосов
/ 24 мая 2019

Я недавно начал использовать lerna для управления монорепо, и в разработке он работает нормально.

Lerna создает символические ссылки между моими различными пакетами, поэтому такие инструменты, как 'tsc --watch' или nodemon, отлично работают для обнаружения изменений в других пакетах.

Но я столкнулся с проблемой при создании образов докера в этой среде.

Допустим, у нас есть проект с такой структурой:

root
  packages
     common → artifact is a private npm package, this depends on utilities, something-specific
     utilities → artifact is a public npm package
     something-specific -> artifact is a public npm package
     frontend → artifact is a docker image, depends on common
     backend → artifact is a docker image, depends on common and utilities

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

Теперь, допустим, я хочу создать образ докера из бэкэнда.

Я пройдусь по некоторым сценариям:

  1. I ADD package.json в моем Dockerfile, а затем запустите npm install.

    Не работает, так как пакеты common и утилит не публикуются.

  2. Я запускаю команду build в бэкенде, ADD / build и / node_modules в файле docker.

    Не работает, так как мой встроенный бэкэнд имеет команды require('common') и require('utilities'), они находятся в node_modules (символическая ссылка), но Docker просто игнорирует эти папки с символическими ссылками.

    Обходной путь: с использованием cp --dereference для «отмены ссылки» узловых модулей работает. Смотрите этот AskUbuntu вопрос .

  3. Шаг 1, но перед тем, как я собираю свой образ докера, я публикую пакеты npm.

    Это работает нормально, но для тех, кто проверяет базу кода и вносит изменения в common или utilities, это не сработает, поскольку у них нет привилегий публиковать пакет npm.

  4. Я настраиваю команду build для backend, чтобы не обрабатывать common или utilities как внешнюю, и common, чтобы не обрабатывать something-specific как внешнюю.

    Я думаю, сначала построить something-specific, а затем common, а затем utilities, а затем backend.

    Таким образом, когда происходит сборка, и при использовании этой техники с веб-пакетом, пакет будет включать весь код из something-specfic, common и utilities.

    Но это неудобно для управления.

Кажется, здесь довольно простая проблема, которую я пытаюсь решить. Код, который в данный момент работает на моей машине, я хочу вытащить и поместить в докер-контейнер.

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

Есть ли очевидная техника lerna, которую я здесь упускаю, или иным образом система отсчета devops, которую я могу использовать, чтобы подумать о решении этой проблемы?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...