Есть ли проблема с запуском в Windows приложения NodeJS, созданного для Linux?
Вот мой sceario:
У меня есть приложение NodeJS, которое подключается к базе данных PostgreSQL, использует множество библиотек Azure для учетной записи хранения, WebPubSub, DataFactory... оно размещено на сервере Windows.
Мой текущий процесс конвейера создает это приложение, затем копирует node_modules из процесса установки в папку dist вместе с другими файлами, а затем упаковывает его. Таким образом, целевому хосту не нужно снова запускать npm install. В настоящее время все это происходит в агенте Windows.
Но теперь мне нужно внедрить самостоятельный агент с Ubuntu. Итак, если предположить, что процесс остается прежним, возникнут ли у меня какие-либо проблемы, если я отправлю node_modules из агента Linux на хост Windows?
Я искал в Интернете, но ничего не нашел о запуске "кросс" встроенного приложения. Я беспокоюсь о бинарных библиотеках, таких как PG. Не будет ли проблем, если я загружу его на Linux, но размещу на Windows?
Пример:
Создайте проект на машине Linux с библиотекой pg. Запустите npm i в этом проекте, затем скопируйте проект, включая node_modules, и вставьте его в файл Windows. Будут ли проблемы с запуском?
Ответы 2
Сценарий, который вы упомянули, будет иметь проблемы, да.
В зависимости от того, что вы используете для сборки/упаковки исполняемого файла, иногда вы можете передать аргумент платформы
то есть
для pkg вы бы сказали это pkg -t node16-win-x64 index.js или 'pkg -t node16-linux-x64`
Таким образом, упаковщик позаботится о том, чтобы все было кросс-компилировано, загружено для нужной платформы...
Короче да, у вас будут проблемы.
Длинный ответ... может быть. Есть несколько вещей, которые я могу быстро придумать, которые имеют значение при запуске приложений Node на разных архитектурах/ОС (и я уверен, что их больше):
- бинарные модули Node, созданные для конкретной версии ОС/узла
- передача переменных среды в сценариях npm, заключенных в двойные кавычки и т. д.
- разделители путей (обратная косая черта в Windows и прямая косая черта в Linux)
- чувствительность пути к регистру (с учетом регистра в Linux).
Ваша проблема первая: перемещение папки node_modules между Windows и Linux. Это может сработать, если у вас нет двоичных файлов, а есть только модули, которые есть required в Node. Однако если у вас есть двоичные файлы, то, как вы правильно заметили, они потерпят неудачу, если они были созданы для одной архитектуры, а вы попытаетесь запустить их на другой.
Реальный пример: старый пакет Node Sass (до Dart Sass) был скомпилирован в бинарный файл. Если вы поменяете среду, вы увидите такие ошибки, как:
Ошибка: отсутствует привязка C:...\node_modules\node-sass\vendor\win32-x64-83\binding.node. Node Sass не удалось найти привязку для вашей текущей среды: 64-разрядная версия Windows с Node.js 14.x
Как исправить
У вас есть несколько способов обойти это:
- сборка и размещение на одной ОС
- собрать в Linux и разместить в Linux в контейнере (например, докере) в Windows через WSL, если у вас есть разрешения
- запустите
npm rebuildпосле развертывания на поле Windows.
npm rebuild (или псевдоним npm rb) перестраивает двоичные файлы, что полезно после того, как вы изменили версию Node или, как в вашем случае, операционную систему.
Дополнительная рекомендация
Я бы порекомендовал дважды проверить правильность установки ваших зависимостей как devDependencies, когда это требуется во время сборки, и зависимостей, если это требуется во время выполнения (или как во время сборки, так и во время выполнения). Затем вы можете запустить команды сборки в Linux, чтобы сгенерировать свой веб-сайт/артефакты, а затем запустить npm prune --production, чтобы удалить devDependencies. Это означает, что ваш пакет будет включать только зависимости времени выполнения.
По моему опыту, зависимости времени выполнения, скорее всего, не будут двоичными, и у вас не будет исходной проблемы и меньшего размера пакета.
Большое спасибо! Вы учили целый класс! Я решил разделить свои конвейерные агенты на два: один для хостов Linux, а другой для хостов Windows. Таким образом, я экономлю свое время, которое мне пришлось бы потратить, пытаясь выяснить, что «вероятно» идет не так, когда приложение развертывается в этом «перекрестном» сценарии.
Спасибо, @JerkoNikolic. За это время я также сделал тест, используя только библиотеку pg, и никаких проблем не было обнаружено. Но то, что вы сказали, верно: я не знаю и не могу знать, вызовет ли какая-либо из моих библиотек проблемы. Я сделаю больше тестов.