Задачи размещенных целей

Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee
X.info

Удаление прокси-сервера Hosted Targets

При удалении прокси-сервера Edge, включающего приложение Hosted Targets, связанное с ним приложение Hosted Targets удаляется, но базовый образ приложения не удаляется. Если прокси-сервер развертывается повторно, приложение Hosted Targets развертывается повторно.

Удаление прокси-сервера Hosted Targets

После удаления прокси-сервера Hosted Targets работа базовых экземпляров среды выполнения прекратится через некоторое время. Однако код приложения сохранится.

Доступ к файлам журналов

Журналы событий полезны для отладки и устранения неполадок. Для развертывания Hosted Targets можно просмотреть два типа журналов событий:

  • Журнал сборки — отображает результаты развертывания и сборки приложения Hosted Targets.
  • Журнал выполнения — отображает вывод, относящийся к запущенному приложению Hosted Targets. Журналы выполнения ограничены средой и отображают информацию о текущей развернутой версии прокси-сервера.

Доступ к журналам из пользовательского интерфейса Edge

  1. Перейдите по ссылке: apigee.com/edge
  2. Введите свои учетные данные и нажмите «Войти» .
  3. В боковом навигационном меню выберите «Разработка» > «API-прокси» .
  4. Выберите прокси-сервер, для которого вы хотите просмотреть журналы.
  5. Нажмите вкладку «Разработка» .
  6. Чтобы просмотреть журнал сборки, нажмите «Журналы сборки» .
  7. Чтобы просмотреть журнал выполнения, нажмите «Журналы выполнения» .

Доступ к журналам через API

Вы также можете использовать API Edge для получения журналов размещенных целевых объектов. Подробнее см. в разделе «Получение кэшированных журналов Node.js» .

Использование частного репозитория npm

В этом разделе объясняется, как развернуть прокси-сервер Node.js на размещенных целевых серверах в случаях, когда в вашей среде разработки используется частный репозиторий NPM .

Что нужно знать об использовании частного репозитория

При развертывании приложения Node.js в Edge все зависимости вашего проекта импортируются автоматически в рамках процесса развертывания. По сути, Hosted Targets запускает npm install для вашего кода при его развертывании. Однако, если вы используете частный репозиторий NPM в своей среде разработки, частные зависимости не могут быть разрешены в облаке. В этом случае решение состоит в использовании параметра --bundled-dependencies при использовании утилиты развертывания apigeetool . См. также Развертывание Node.js из вашей системы в Edge.

При использовании флага --bundled-dependencies в apigeetool ваше приложение Node.js будет загружено в Hosted Targets, а все локальные/приватные файлы, перечисленные в массиве bundledDependencies в package.json , будут заархивированы и загружены вместе с пакетом.

Хотя это и нечастая ситуация, имейте в виду, что если вы используете внутреннее зеркалирование общедоступного репозитория NPM, развертывание завершится неудачей, если ваш пакет развертывания содержит файл .npmrc или package-lock.json , указывающий на ваше частное зеркало. В этом случае обязательно исключите файлы .npmrc или package-lock.json из пакета прокси, который вы собираетесь развернуть.

Развертывание с использованием частного репозитория NPM.

Для использования модулей, предоставляемых из частного репозитория NPM, выполните следующие действия:

  1. Войдите в npm:
    npm login
  2. Получите токен аутентификации npm:
    1. Найдите свой файл .npmrc (он должен находиться в ~/.npmrc ).
    2. В вашем файле .npmrc обратите внимание на токен в конце строки, который выглядит следующим образом:

      //registry.npmjs.org/:_authToken=****
    3. Или используйте команды npm token <list | create | revoke> для получения списка, создания или отзыва токенов аутентификации. Более подробную информацию см. в документации npm-token .
  3. Перейдите на страницу настройки сопоставления ключей и значений, как описано ниже.

    Край

    Чтобы получить доступ к странице конфигурации сопоставления ключей и значений с помощью пользовательского интерфейса Edge:

    1. Войдите на сайт apigee.com/edge .
    2. В левой панели навигации выберите Администрирование > Среды > Сопоставление ключей и значений .

    Классический Edge (частное облако)

    Чтобы получить доступ к странице конфигурации сопоставления ключей и значений с помощью классического пользовательского интерфейса Edge:

    1. Войдите в систему по http:// ms-ip :9000 , где ms-ip — это IP-адрес или DNS-имя узла сервера управления.
    2. В верхней панели навигации выберите API > Конфигурация среды > Сопоставление ключей и значений .
  4. Click + Key Value Map .
  5. В диалоговом окне «Создать новую карту ключ-значение» введите имя и выберите «Зашифровано» .
  6. Нажмите «Добавить» .
  7. Добавьте ранее найденный или созданный токен аутентификации в качестве новой записи в каждый из только что созданных KVM-серверов.
  8. В файл app.yaml добавьте запись, которая ссылается на KVM и ключ, связанные с токеном аутентификации npm. Она должна выглядеть примерно так:
  9. env:
    - name: NPM_TOKEN
     valueRef:
       name: npm_store
       key: private_token

    Где:

    • Атрибут имени верхнего уровня соответствует имени переменной среды, которая будет создана.
    • Имя в поле valueRef соответствует KVM-модулю, который вы создали ранее.
    • Атрибут key соответствует ключу, который сопоставляется с токеном npm, добавленным вами в KVM.
  10. Создайте файл .npmrc в той же директории, что и ваш файл package.json. Этот файл должен выглядеть примерно так:
    //registry.npmjs.org/:_authToken=${NPM_TOKEN}
    Или, если вы не используете registry.npmjs.org вы можете установить область видимости в файле .npmrc, добавив строку примерно такого вида @myscope:registry=https://mycustomregistry.example.org См. также документацию по npmrc .
  11. Загрузите или обновите свой прокси-сервер Node.js, используя файлы .npmrc и app.yaml .
  12. Убедитесь, что ваш новый или обновленный прокси-сервер развертывается и работает с нужным модулем частного репозитория.
  13. Если прокси-сервер не развертывается, проверьте журналы сборки, чтобы узнать, не произошла ли ошибка при установке частного модуля npm. Если да:
    1. На вкладке "Разработка" убедитесь, что файл .npmrc присутствует.
    2. Убедитесь, что ваш токен действителен (попробуйте установить модуль локально, используя токен, присутствующий в KVM).
    3. Если вы используете пользовательскую область видимости, убедитесь, что она задана.

Указание версии NPM для включенных в пакет зависимостей

По умолчанию для установки зависимостей в среде Hosted Targets используется NPM версии 4. Однако, если вы хотите использовать другую версию NPM, вы можете указать её в переменной среды NPM_VERSION . Эту переменную можно задать в файле манифеста приложения. Подробнее см. в разделе «Элементы файла манифеста» .

Если вы используете встроенные зависимости и не указываете NPM_VERSION , Hosted Targets по умолчанию использует NPM версии 4. Если вы не используете встроенные зависимости, используется версия NPM, включенная в указанную вами среду выполнения Node.js.

Пример пакетных зависимостей

Пример, демонстрирующий функцию встроенных зависимостей в Hosted Targets, см. в статье «Как создать приложение Node.js с Hosted Functions, используя пользовательские модули» .

Добавить конечную точку проверки состояния

У вас есть возможность реализовать конечную точку проверки работоспособности для вашего приложения Node.js. Apigee использует эту конечную точку при запуске вашего приложения Node.js, чтобы убедиться, что приложение запущено и работает в контейнере.

По умолчанию Apigee ожидает конечную точку /health . Вы можете изменить конечную точку по умолчанию, указав ее в переменной среды с именем HOSTED_TARGET_HEALTH_CHECK_PATH . Эту переменную можно установить в файле манифеста приложения. Подробнее см. в разделе «Элементы файла манифеста» .

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

  • Если ваше приложение завершает работу, когда Apigee обращается к конечной точке, оно не запустится должным образом.
  • Допустимо, если ваш конечный пункт возвращает HTTP-статус 404 Not Found. Параметр /health или HOSTED_TARGET_HEALTH_CHECK_PATH используется только для проверки того, запущено ли ваше приложение. Фактический ответ игнорируется.

Измените местоположение кэша NPM.

В более новых версиях Node.js используется версия NPM, которая использует /root/.npm для кэширования NPM. Это расположение создает проблему для Hosted Targets, поскольку этот каталог доступен только для чтения, так как среда выполнения Hosted Target использует файловую систему tmpfs, где запись доступна только /tmp . Чтобы обойти эту проблему, вы можете установить переменную среды npm_config_cache в файле app.yaml вашего приложения (файле манифеста) на каталог внутри /tmp . Например:

  runtime: node
  application: my-express-app
  env:
    - name: npm_config_cache
      value: /tmp/.npm
    - name: NODE_ENV
      value: production
    - name: LOG_LEVEL
      value: 3
  

Запускайте своё приложение без NPM.

По умолчанию Hosted Targets использует npm start для запуска вашего приложения Hosted Target. Однако в предыдущем задании мы обсуждали проблему использования NPM, поскольку более новые версии пытаются использовать /root/.npm для кэша NPM, который недоступен для записи и приводит к сбою запуска вашего Hosted Target. Хотя предыдущее задание решает эту проблему, другой вариант — запустить ваше приложение без NPM. Для этого вы можете использовать значения command и args в файле app.yaml вашего приложения (файле манифеста) для запуска вашего Hosted Target напрямую с помощью node index.js . Например:

  runtime: node
  application: my-express-app
  command: node
  args:
    - index.js
  env:
    - name: NODE_ENV
      value: production
    - name: LOG_LEVEL
      value: 3
  
Конечно, вы можете использовать любую команду, которую сочтете подходящей, а node index.js — это всего лишь пример.