сбой приложения узла js через облачный литейный завод, так как узел oracledb dep не загружается за брандмауэром - PullRequest
Новая
       8

сбой приложения узла js через облачный литейный завод, так как узел oracledb dep не загружается за брандмауэром

0 голосов
/ 07 сентября 2018

У меня есть приложение js-узла, которое нужно отправить в облачный литейный цех. Загрузка двоичного файла oracle блокируется брандмауэром, поэтому при установке npm не удается загрузить зависимость oracledb узла. Я вручную установил его в локальной папке node_modules. Теперь, когда я помещаю свое приложение в CF, оно снова пытается загрузить зависимость узла oracledb, которая уже присутствует в локальной папке node_modules. Мой вопрос заключается в том, как я могу упомянуть об этом в package.json или package-lock.json, чтобы CF не загружал узел oracledb при каждом нажатии. Я хочу использовать только связанную зависимость. Добавление прокси-сервера P.S здесь не будет работать, так как этот бинарный файл для конкретной платформы размещен на S3.AWS в Интернете и заблокирован нашей организацией.

Ответы [ 2 ]

0 голосов
/ 19 сентября 2018

После долгих исследований и экспериментов я смог добиться этого без изображения докера.В package.json - 

 "dependencies": {
    "crypto": "^1.0.1",
    "express": "^4.16.3",
    "morgan": "^1.9.0",
    "nan": "^2.11.0",
    "oracledb": "file:oracledb_build",
    "typeorm": "^0.2.7"
  }

, если мы упомянем относительное местоположение файла в проекте, откуда npm должен искать зависимость oracledb вместо перехода в Интернет, это решает эту проблему.если мы упомянем - "oracledb": "^ 2.3.0" - он всегда переходит в Интернет для загрузки двоичного файла для конкретной платформы, даже если вы вручную копируете oracledb в node_modules и предоставляете двоичный файл с соответствующей архитектурой.Я наблюдал это поведение с oracledb 2.3.0.Моя проблема была решена, когда я предоставил oracledb 2.0.15 локально.

0 голосов
/ 12 сентября 2018

В автономных средах вам необходимо «продавать» свои зависимости. Акт "вендоринга" означает, что вы загружаете их заранее и cf push как ваше приложение, так и зависимости. Когда вы сделаете это, buildpack-пакету не нужно ничего скачивать, потому что все это уже существует.

Процесс для приложений Node.js здесь -> https://docs.cloudfoundry.org/buildpacks/node/index.html#vendoring

Для неродного кода это легко, но для нативного кода есть сложность. Чтобы продавать свои зависимости, вам необходимо убедиться, что архитектура вашего локального компьютера соответствует архитектуре целевой системы (т. Е. Вашего стека Cloud Foundry). Если архитектура не совпадает, двоичные файлы не будут работать на CF, и buildpack должен будет попытаться загрузить и собрать эти ресурсы для вас (это не удастся в автономной среде).

На момент написания этой статьи для Cloud Foundry было доступно два стека. Чаще всего используется cflinuxfs2. Это в основном Ubuntu Trusty 14.04. Существует также cflinuxfs3, который является в основном Ubuntu Bionic 18.04. Пока я пишу это, последний довольно новый и может быть доступен не во всех средах. Существуют также стеки Windows, но это не имеет значения, потому что сборка Node.js работает только со стеками Linux. Вы можете запустить cf stacks, чтобы увидеть, какие стеки доступны в вашей среде.

Чтобы выбрать нужный стек, запустите cf push -s <stack>, однако это обычно не требуется, поскольку в большинстве сред по умолчанию используется один из стеков Linux.

Чтобы вернуть это к продаже ваших зависимостей Node.js, вам нужно выполнить локальные операции по продаже в среде, которая соответствует стеку. Если вы используете Windows или MacOS, это означает использование виртуальной машины или образа Docker. У вас есть несколько вариантов с точки зрения образа вашей виртуальной машины или Docker.

  • Стеки, также называемые rootfs, доступны как образы Docker. Вы можете работать над этим, запустив docker run -w /app -v pwd :/app -it cloudfoundry/cflinuxfs2 bash или docker run -w /app -v pwd :/app -it cloudfoundry/cflinuxfs2 bash. Это даст вам оболочку в соответствующем контейнере, где вы сможете запустить процесс вендоринга.
  • Сделайте то же самое, но используйте базовый образ Ubuntu Trusty 14.04 или Ubuntu Bionic 18.04. Это в основном то же самое, что и образы cflinuxfsX, они просто поставляются со стандартным набором пакетов. Если вам нужно apt установить dev-пакеты так, чтобы ваш собственный код был собран, это нормально.
  • Создайте виртуальную машину Ubuntu Trusty 14.04 или Ubuntu Bionic 18.04. Это то же самое, что и предыдущий вариант, но вы используете виртуальную машину вместо Docker.

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

...