Я недавно начал использовать 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
В этом сценарии в разработке все нормально. Я использую какой-то сервер живой перезагрузки, и символические ссылки работают так, что работают зависимости.
Теперь, допустим, я хочу создать образ докера из бэкэнда.
Я пройдусь по некоторым сценариям:
I ADD package.json в моем Dockerfile, а затем запустите npm install.
Не работает, так как пакеты common и утилит не публикуются.
Я запускаю команду build в бэкенде, ADD / build и / node_modules в файле docker.
Не работает, так как мой встроенный бэкэнд имеет команды require('common') и require('utilities'), они находятся в node_modules (символическая ссылка), но Docker просто игнорирует эти папки с символическими ссылками.
Обходной путь: с использованием cp --dereference для «отмены ссылки» узловых модулей работает. Смотрите этот AskUbuntu вопрос .
Шаг 1, но перед тем, как я собираю свой образ докера, я публикую пакеты npm.
Это работает нормально, но для тех, кто проверяет базу кода и вносит изменения в common или utilities, это не сработает, поскольку у них нет привилегий публиковать пакет npm.
Я настраиваю команду build для backend, чтобы не обрабатывать common или utilities как внешнюю, и common, чтобы не обрабатывать something-specific как внешнюю.
Я думаю, сначала построить something-specific, а затем common, а затем utilities, а затем backend.
Таким образом, когда происходит сборка, и при использовании этой техники с веб-пакетом, пакет будет включать весь код из something-specfic, common и utilities.
Но это неудобно для управления.
Кажется, здесь довольно простая проблема, которую я пытаюсь решить. Код, который в данный момент работает на моей машине, я хочу вытащить и поместить в докер-контейнер.
Помните, что главное, чего мы хотим достичь, - это чтобы кто-то мог проверить кодовую базу, изменить любой из пакетов, а затем создать образ докера, все из среды разработки.
Есть ли очевидная техника lerna, которую я здесь упускаю, или иным образом система отсчета devops, которую я могу использовать, чтобы подумать о решении этой проблемы?