Жизненный цикл разработки API

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

У каждой организации свой уникальный жизненный цикл разработки программного обеспечения (SDLC). Зачастую необходимо синхронизировать и согласовать развертывание API-прокси с теми же процессами, которые вы используете сегодня для разработки, тестирования и развертывания других приложений.

API Services предоставляет инструменты и RESTful API, позволяющие интегрировать развертывание и управление API-прокси в жизненный цикл разработки программного обеспечения вашей организации. Распространенный способ использования RESTful API — написание скриптов или кода, которые программно развертывают API-прокси или переносят их из одной среды в другую в рамках более крупного автоматизированного процесса, который также развертывает или переносит другие приложения. API Services не делает никаких предположений о вашем жизненном цикле разработки программного обеспечения (или о чьем-либо еще). Вместо этого он предоставляет атомарные функции, которые могут координироваться вашей командой разработчиков для автоматизации и оптимизации жизненного цикла разработки API.

API-сервисы. API-интерфейсы описаны в справочнике API. См. раздел «Начало работы со справочником API» .

Посмотрите это видео, чтобы ознакомиться с средами API и жизненным циклом разработки API.

Окружающая среда

Каждая организация, использующая Apigee Edge, имеет как минимум две среды развертывания, доступные для API-прокси: «test» и «prod». Различие между этими двумя средами условно — каждая среда просто идентифицируется разным набором сетевых адресов (URL). Цель состоит в том, чтобы предоставить вам домен, в котором вы можете создавать и проверять API-прокси до того, как API станет доступен внешним разработчикам.

Вы можете использовать эти среды для синхронизации разработки API-прокси с вашим жизненным циклом разработки программного обеспечения (SDLC). Каждая среда определяется сетевым адресом, что позволяет разделять трафик между API-прокси, над которыми вы работаете, и теми, к которым обращаются приложения во время выполнения. Доступные сетевые адреса для каждой среды определяются в наборе виртуальных хостов (VirtualHosts), доступных в этой среде.

Входящие соединения, протокол TLS/SSL на сервере автоматически включаются для каждой среды. В каждой среде предварительно определены два виртуальных хоста: default и secure . Default определяет HTTP-адрес, а secure — HTTP/S-адрес с предварительно настроенным серверным TLS/SSL. В конфигурации API-прокси вы указываете, на каких виртуальных хостах должен прослушивать ProxyEndpoint. При переходе в продакшн обычно отключают HTTP, удаляя виртуальный хост default из конфигурации API-прокси.

Например, следующий ProxyEndpoint прослушивает протоколы HTTP и HTTPS.

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>default</VirtualHost>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

Удалив параметр VirtualHost default из конфигурации ProxyEndpoint, вы создадите API-прокси, который будет прослушивать только HTTPS, а не HTTP.

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

Чтобы посмотреть, какие виртуальные хосты доступны в среде, выберите пункт «Среды» в главном меню пользовательского интерфейса управления.

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

Развертывание API-прокси в средах

При создании API-прокси вам нужно будет определиться с рабочей средой. Вы можете создать новый API-прокси в продакшене, но это не рекомендуется, так как вы можете сделать API доступным для разработчиков до того, как он будет готов. Как правило, начните с создания API-прокси в test , который после тестирования перенесите в prod .

Для получения более подробной информации см. раздел «Понимание развертывания» .

Итеративная разработка в тестировании

При работе с API-прокси API Services сохраняет итерации вашей конфигурации в виде ревизий . При развертывании API-прокси вы выбираете конкретную ревизию для развертывания. Как правило, вы развертываете самую последнюю ревизию и, при необходимости, возвращаетесь к предыдущему номеру ревизии. Вы можете выбрать, куда развертывать эти ревизии. Например, вы можете перевести ревизию в продакшн, чтобы разработчики могли начать работать с вашим API. В то же время вы можете одновременно работать с несколькими ревизиями в тестовой среде, добавляя функции или настраивая политики. Затем, когда вы будете готовы, вы можете развернуть новую ревизию в продакшн, перезаписав существующую ревизию в этой среде. Используя этот метод, вы всегда можете иметь доступную разработчикам актуальную версию вашего API во время разработки.

Продвижение к производству

Когда API-прокси будет полностью реализован и протестирован, он готов к переносу в «производственную» среду. Версия API-прокси из тестовой среды будет использована для перезаписи версии API-прокси, развернутого в производственной среде.

API Services предоставляет возможности для обеспечения бесперебойного развертывания API-прокси, минимизируя влияние на приложения и конечных пользователей в процессе развертывания.

развертывание скриптов

Пользовательский интерфейс управления Apigee Edge позволяет развертывать API-прокси в продакшн непосредственно из конструктора API-прокси. Однако во многих ситуациях требования к безопасности, надежности и согласованности потребуют от команд разработчиков написания скриптов для процедур развертывания. Для этого можно писать код и скрипты, которые вызывают RESTful API, предоставляемый API Services.

Экологические ресурсы

Для дополнительного контроля в процессе продвижения рекомендуется вносить изменения в API-прокси только в тестовой среде и минимизировать изменения в API-прокси, развернутых в производственной среде.

Для этого необходимо убедиться, что определенные ресурсы, связанные с каждой средой, настроены таким образом, чтобы они оставались неизменными в конфигурации API-прокси.

  • Целевые URL-адреса: В процессе тестирования и в производственной среде API-прокси часто обращаются к разным URL-адресам бэкэндов. Вы можете использовать конфигурации TargetServer для создания независимых от среды конфигураций TargetEndpoint. См. раздел «Балансировка нагрузки между бэкэнд-серверами» .
  • Кэши и карты ключ/значение: Оба ресурса для хранения данных ограничены средой. Необходимо убедиться, что используются соглашения об именовании, позволяющие прокси-серверам API хранить данные без необходимости изменения конфигурации во время повышения уровня доступа. См. раздел «Создание и редактирование кэша среды» .
  • Целевые объекты ServiceCallout: В зависимости от среды вызовы сервисов могут использовать разные целевые объекты, например, если вызов ServiceCallout в тестовой среде использует демонстрационный сервис. См. Политику вызовов сервисов .

Чтобы сделать конфигурации API-прокси независимыми от среды, можно также использовать условные операторы. Условный оператор, созданный с использованием переменной environment.name может использоваться для оценки текущей среды перед применением политики или перед маршрутизацией на URL-адрес в бэкэнде.

Для получения более подробной информации см. раздел «Понимание развертывания» .