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