Вы просматриваете документацию Apigee Edge .
Перейдите к документации Apigee X. информация
Apigee Edge предоставляет множество различных типов ресурсов, каждый из которых служит разной цели. Существуют определенные ресурсы, которые можно настроить (то есть создавать, обновлять и/или удалять) только через пользовательский интерфейс Edge, API-интерфейсы управления или инструменты, использующие API-интерфейсы управления, а также пользователями с необходимыми ролями и разрешениями. Например, только администраторы организации, принадлежащие определенной организации, могут настраивать эти ресурсы. Это означает, что эти ресурсы не могут быть настроены конечными пользователями через порталы разработчиков или какими-либо другими способами. Эти ресурсы включают в себя:
- API-прокси
- Общие потоки
- API-продукты
- Тайники
- КВМ
- Хранилища ключей и доверенные хранилища
- Виртуальные хосты
- Целевые серверы
- Файлы ресурсов
Хотя эти ресурсы имеют ограниченный доступ, если в них вносятся какие-либо изменения даже авторизованными пользователями, исторические данные просто перезаписываются новыми данными. Это связано с тем, что эти ресурсы хранятся в Apigee Edge только в соответствии с их текущим состоянием. Основными исключениями из этого правила являются прокси-серверы API и общие потоки.
Прокси API и общие потоки под контролем версий
Прокси-серверы API и общие потоки управляются — другими словами, создаются, обновляются и развертываются — посредством изменений. Редакции имеют последовательную нумерацию, что позволяет добавлять новые изменения и сохранять их как новую редакцию или отменить изменение, развернув предыдущую редакцию прокси-сервера API или общего потока. В любой момент времени в среде может быть развернута только одна версия прокси-сервера API или общего потока, если только версии не имеют другой базовый путь.
Хотя прокси-серверы API и общие потоки управляются посредством версий, если в существующую версию вносятся какие-либо изменения, откат невозможен, поскольку старые изменения просто перезаписываются.
Аудит и история
Apigee Edge предоставляет функции аудита и API, продукта и истории организации , которые могут быть полезны при устранении неполадок. Эти функции позволяют просматривать информацию о том, кто выполнял определенные операции (создание, чтение, обновление, удаление, развертывание и отмена развертывания) и когда операции выполнялись с пограничными ресурсами. Однако если на каком-либо из ресурсов Edge выполняются какие-либо операции обновления или удаления, аудит не может предоставить вам более старые данные.
Антипаттерн
Управление ресурсами Edge (перечисленными выше) напрямую через пользовательский интерфейс Edge или API управления без использования системы контроля версий.
Существует заблуждение, что Apigee Edge сможет восстанавливать ресурсы до их предыдущего состояния после изменений или удалений. Однако Edge Cloud не обеспечивает восстановление ресурсов до прежнего состояния. Таким образом, пользователь несет ответственность за то, чтобы все данные, относящиеся к пограничным ресурсам, управлялись с помощью системы управления исходным кодом, чтобы старые данные можно было быстро восстановить в случае случайного удаления или в ситуациях, когда любое изменение необходимо откатить. Это особенно важно для производственных сред, где эти данные необходимы для трафика во время выполнения.
Давайте объясним это на нескольких примерах и возможные последствия, если данные не управляются через систему контроля версий и изменяются/удаляются сознательно или неосознанно:
Пример 1. Удаление или изменение прокси-сервера API
Когда прокси-сервер API удаляется или в существующей версии развертывается изменение, предыдущий код невозможно восстановить. Если прокси-сервер API содержит код Java, JavaScript, Node.js или Python, который не управляется в системе управления версиями (SCM) за пределами Apigee, большая часть работы и усилий по разработке может быть потеряна.
Пример 2: Определение API-прокси с использованием конкретных виртуальных хостов
Срок действия сертификата виртуального хоста истекает, и этот виртуальный хост нуждается в обновлении. Определить, какие прокси-серверы API используют этот виртуальный хост в целях тестирования, может быть сложно, если имеется много прокси-серверов API. Если прокси-серверы API управляются в системе SCM за пределами Apigee, тогда будет легко выполнить поиск в репозитории.
Пример 3: Удаление хранилища ключей/доверенного хранилища
Если хранилище ключей/хранилище доверенных сертификатов, используемое виртуальным хостом или конфигурацией целевого сервера, будет удалено, восстановить его обратно будет невозможно, если сведения о конфигурации хранилища ключей/хранилища доверенных сертификатов, включая сертификаты и/или закрытые ключи, не будут сохранены в исходном коде. контроль.
Влияние
- Если какой-либо из ресурсов Edge будет удален, восстановить ресурс и его содержимое из Apigee Edge будет невозможно.
- Запросы API могут завершиться неудачей с непредвиденными ошибками, что приведет к сбою в работе, пока ресурс не будет восстановлен в предыдущее состояние.
- В Apigee Edge сложно искать взаимозависимости между прокси API и другими ресурсами.
Лучшая практика
- Используйте любой стандартный SCM в сочетании с конвейером непрерывной интеграции и непрерывного развертывания (CICD) для управления прокси-серверами API и общими потоками.
- Используйте любой стандартный SCM для управления другими ресурсами Edge, включая продукты API, кэши, KVM, целевые серверы, виртуальные хосты и хранилища ключей.
- Если существуют какие-либо ресурсы Edge, используйте API управления, чтобы получить для них сведения о конфигурации в виде полезных данных JSON/XML и сохранить их в системе управления исходным кодом.
- Управляйте всеми новыми обновлениями этих ресурсов в системе управления исходным кодом.
- Если необходимо создать новые ресурсы Edge или обновить существующие ресурсы Edge, используйте соответствующую полезную нагрузку JSON/XML, хранящуюся в системе управления версиями, и обновите конфигурацию в Edge с помощью API управления.
* Зашифрованные KVM нельзя экспортировать в виде обычного текста из API. Пользователь несет ответственность за ведение учета того, какие значения помещаются в зашифрованные KVM.