4.15.07.00 — Примечания к выпуску Apigee Edge для частного облака

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

Во вторник, 8 сентября 2015 г., мы выпустили основной выпуск функций Apigee Edge для частного облака.

Со времени предыдущего ежеквартального выпуска Edge for Private Cloud (4.15.04.00) были выпущены следующие выпуски, которые включены в этот ежеквартальный выпуск:

• Облако: 15.04.15 , 15.04.29 , 15.05.27 , 15.06.10 и 15.06.24.
• Частное облако: 4.15.04.01

Какие версии Edge можно обновить до 4.15.07.00

В зависимости от вашей текущей версии Edge вы можете:

• Непосредственное обновление до 4.15.07.00
• Постепенное обновление означает, что вам необходимо выполнить обновление с текущей версии до другой версии Edge, а затем выполнить обновление до 4.15.07.00.

Дополнительные сведения см. в разделе Какие версии Edge для частного облака можно обновить до 4.15.07.00 .

Перед обновлением с версии 4.15.01.x или предыдущей версии

1. Проверьте версию Cassandra SSTable:
   1. Измените каталог на /<install-root>/apigee4/data/cassandra/data .
   2. Запустите команду поиска,
      > найти. -имя *-ic-*
      Результаты должны возвращать набор файлов .db, если вы используете Cassandra 1.2 SSTable.
   3. Запустите эту команду поиска:
      > найти. -имя *-hf-*
      Результаты должны быть пустыми, что означает отсутствие файлов .db в формате hf . Если вы не видите файлов в формате hf , значит, все готово и можно обновиться до 4.15.07.00.
      
      Формат hf предназначен для SSTables Cassandra 1.0. Если у вас есть файлы *.db в формате hf , вам необходимо обновить SSTable, как описано в оставшейся части этой процедуры.
2. Если вы обнаружите какие-либо файлы *.db в формате hf , обновите SSTable, выполнив следующую команду на каждом узле Cassandra, пока вы не обновите все узлы Cassandra:
   > /<install-root>/apigee4/share/apache-cassandra/bin/nodetool -h localhostupgradesstables -a
3. Повторите шаг 1, чтобы убедиться, что все файлы *.db имеют формат ic для версии Cassandra 1.2.
4. Повторите шаги с 1 по 3 на каждом узле Cassandra в вашей установке Edge.
5. Обновите Edge до версии 4.15.07.00.
6. После обновления 4.15.07.00 проверьте файлы *.db, чтобы убедиться, что все они обновлены до sstable в стиле C* 2.0:
   > cd /<корень-установки>/apigee4/data/cassandra/data
   > найти. -имя *-jb-*
   Эта команда должна вернуть набор файлов .db, если вы используете Cassandra 2.0.

Новые функции и улучшения

Ниже приведены новые функции и улучшения в этом выпуске.

Установка и обновление

Выборочное обновление и удаление компонентов

Скрипты apigee-upgrade.sh и apigee-uninstall.sh теперь позволяют выбирать компоненты Edge для обновления или удаления. Ранее он обновлял или удалял все компоненты на узле. (ОПДК-1377, ОПДК-1175)

Откат обновления

Если во время обновления произойдет сбой файла apigee-upgrade.sh, теперь вы можете использовать сценарий apigee-rollback.sh для отката обновления. После устранения проблем с обновлением вы можете повторить попытку обновления. (ОПДК-1275)

Сокращенные параметры сценария установщика

Сценарии установки больше не принимают длинную форму параметров, таких как --help. Теперь они принимают только однобуквенные варианты, например -h. (ОПДК-1356)

Установка СмартДокс

При установке SmartDocs с помощью сценария setup-smartdocs.sh вам будет предложено ввести организацию, среду и виртуальный хост, что гарантирует установку SmartDocs в ожидаемом месте. Раньше эти значения были жестко запрограммированы в скрипте. (ОПДК-1310)

Запуск update-cass-pwd-in-config.sh без подсказок

Сценарий update-cass-pwd-in-config.sh может работать без запросов, если вы установите переменные среды ENABLE_CASS_AUTH, CASS_USERNAME и CASS_PASSWORD. (ОПДК-1309)

Пограничная платформа

Ниже приведены новые функции платформы Edge, включенные в этот выпуск.

OpenJDK 1.7 поддерживается частным облаком Edge

Этот выпуск Edge поддерживает Oracle JDK 1.7 и OpenJDK 7 и удалена поддержка JDK 1.6. (ОПДК-1187)

Поддержка ОС

Apigee Edge для частного облака расширила поддержку своих операционных систем, включив в нее Red Hat Enterprise Linux 6.6 и 7.0 (64-разрядные версии), CentOS 6.5, 6.6 и 7.0 (64-разрядные версии) и Oracle Linux 6.5.

Кассандра 2.0.15 включена в OPDK 15.07.

В этом выпуске устанавливается Cassandra 2.0.15. Если вы обновляете предыдущую версию, ваша версия Cassandra будет обновлена. (ОПДК-1197)

Поддержка SHA2 для хеширования токена OAuth.

Чтобы лучше защитить токены OAuth в случае нарушения безопасности базы данных, Edge поддерживает алгоритмы SHA2 для хеширования токенов OAuth (в дополнение к SHA1). Благодаря новым свойствам на уровне организации вы можете включить и настроить хеширование для новых токенов, а также сохранить устаревшее хеширование для любых токенов, существовавших до появления этой новой функции. Ранее в Edge для частного облака свойство hash.oauth.tokens.enabled в файле keymanagement.properties (на вашем сервере управления и процессорах сообщений) включало автоматическое хэширование SHA1 токенов OAuth. Это свойство устарело.

Если вы ранее использовали свойство hash.oauth.tokens.enabled для включения хеширования SHA1, сценарий обновления для этого выпуска автоматически создаст для вас новые свойства уровня организации. Чтобы проверить после обновления, выполните GET от имени системного администратора с помощью этого API: https://{host}:{port}/v1/o/{your_org}.

• Информацию о включении хеширования токенов в вашей организации с помощью новых свойств см. в разделе «Хеширование токенов в базе данных» в разделе «Запрос токенов доступа» .
• Информацию о массовом хешировании существующих токенов см. в документе Edge for Private Cloud Operations Guide . (АПИРТ-1389)

Плоская структура каталогов для файлов журналов

Вы можете настроить Edge для хранения файлов журналов в плоской структуре каталогов, установив для нового enable.flat.directory.structure значение true в файле message-logging.properties. Дополнительные сведения см. в разделе Политика ведения журнала сообщений . (АПИРТ-1394)

Производительность кэша среды

Для лучшего управления и использования кэша в памяти параметры «Максимальное количество элементов в памяти» для ресурсов кэша среды устарели. Общее количество элементов, присутствующих во всех ресурсах кэша (включая кэш по умолчанию), зависит от общего объема памяти, выделенной для кэша. По умолчанию общий объем памяти, выделенный для кэширования в памяти на данном процессоре сообщений, составляет 40 % от общей доступной памяти, определяемой настройками свойств кэша в файле кэша обработчика сообщений.properties. Элементы будут удалены из кэша в памяти только в том случае, если кэш-памяти недостаточно или срок действия элементов истек.

Чтобы вернуться к старому поведению использования свойства «Максимальное количество элементов в памяти» для управления кэшем, установите свойство overrideMaxElementsInCacheResource=false в файле кэш.свойства. (АПИРТ-1140)

API-сервисы

Ниже приведены новые функции служб API, включенные в этот выпуск.

Новый редактор прокси по умолчанию

Новый редактор прокси API включен по умолчанию в пользовательском интерфейсе управления. Новый редактор включает в себя множество улучшений удобства использования, в том числе более полное представление условных потоков и конечных точек на странице «Обзор», все настройки на странице «Разработка», более интуитивное добавление условных потоков, конечных точек и политик, более полные представления XML, а не небольшие фрагменты. поиск, который сканирует имена файлов и текст и многое другое. (МГМТ-2279)

Новая политика удаления информации OAuth v2.0

Новая политика «Удалить информацию OAuth v2.0» позволяет удалять токены доступа OAuth v2 и коды авторизации. Эта политика заменяет функциональность, ранее предоставляемую API управления. Дополнительные сведения см. в разделе Удаление политики информации OAuthV2 . (МГМТ-2257)

Новая политика удаления информации OAuth v1.0

Новая политика «Удалить информацию OAuth v1.0» позволяет удалять токены запросов OAuth v1.0, токены доступа и коды проверки. Эта политика заменяет функциональность, ранее предоставляемую API управления. Дополнительную информацию см. в разделе Удаление политики OAuth V1 Info . (АПИРТ-1351)

Политика контроля доступа

Политика контроля доступа была улучшена, чтобы обеспечить более детальную оценку IP-адресов для включения в списки разрешенных и запрещенных, когда IP-адреса содержатся в HTTP-заголовке X-FORWARDED-FOR .

Если в заголовке включена проверка нескольких IP-адресов (обратитесь в службу поддержки, чтобы установить Feature.enableMultipleXForwardCheckForACL), новый элемент <ValidateBasedOn> в политике позволяет проверять первый IP-адрес, последний IP-адрес или все IP-адреса в заголовке. Дополнительные сведения см. в разделе Политика контроля доступа .

Новые сущности в политике Access Entity

Политика Access Entity обеспечивает доступ к следующим новым объектам: области потребительских ключей, код авторизации, токен запроса и верификатор. Дополнительные сведения см. в разделе Политика доступа к объектам .

Политика сборщика статистики: автоматическое преобразование названия статистики в нижний регистр.

При создании коллекции пользовательской аналитики в редакторе прокси API (страница «Разработка» > «Инструменты» > «Коллекция пользовательской аналитики») переменная сборщика (статистика) «Имя» должна быть написана строчными буквами. Если вы вводите имя заглавными буквами, инструмент автоматически преобразует имя статистики в нижний регистр в политике сборщика статистики. (МГМТ-740)

Удаление Classic Trace в редакторе прокси API

Новейшая версия функции Trace в редакторе прокси API перешла из бета-версии в общедоступную. Доступ к «классической трассировке» по ссылке «Доступ к классической версии трассировки» больше недоступен.

Доступ к сообществу Apigee из меню справки пользовательского интерфейса управления.

Вы можете получить доступ к сообществу Apigee из меню справки пользовательского интерфейса управления.

Сообщения об ошибках в пользовательском интерфейсе управления

Ниже приведены улучшения сообщений об ошибках в пользовательском интерфейсе управления:

• Пользовательский интерфейс управления группировал и отображал все сообщения об ошибках в пользовательском интерфейсе за весь сеанс входа в систему, если вы их не закрыли. Благодаря этому обновлению сообщения об ошибках автоматически удаляются при переходе со страницы, на которой они возникли. (МГМТ-2254)
• Пользовательский интерфейс управления больше не подавляет повторяющиеся сообщения об ошибках. (МГМТ-2242)

Улучшения производительности пользовательского интерфейса и ошибок

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

Гиперссылки на роли на странице «Пользователи организации» в пользовательском интерфейсе управления

На странице «Пользователи организации» в пользовательском интерфейсе управления («Администратор» > «Пользователи организации») имена ролей теперь снабжены гиперссылками, что позволяет быстро переходить к страницам ролей. (МГМТ-1055)

Новые целевые переменные в потоке сообщений

Новые переменные в потоках сообщений предоставляют более полную информацию об URL-адресах для целевых конечных точек и целевых серверов:

• TargetEndpoint: request.url заменяет target.basepath.with.query .
• TargetServer: loadbalancing.targetserver заменяет targetserver.name . Кроме того, target.basepath заполняется только тогда, когда элемент <Path> используется в элементе HTTPTargetConnection <LoadBalancer> TargetEndpoint.

Поддержка указания имени сервера (SNI)

Edge поддерживает использование указания имени сервера в южном направлении (от процессора сообщений к целевым конечным точкам). Если вы хотите использовать SNI, обратитесь в службу поддержки Apigee .

Требуется Java 1.7 .

Благодаря SNI, который является расширением TLS/SSL, несколько целей HTTPS могут обслуживаться с одного и того же IP-адреса и порта, не требуя, чтобы все эти цели использовали один и тот же сертификат.

Никакой специальной конфигурации Edge не требуется. Если ваша среда настроена для SNI южного направления (по умолчанию используется облако Edge), Edge поддерживает его.

Edge автоматически извлекает имя хоста из URL-адреса запроса и добавляет его в запрос подтверждения SSL. Например, если целевой хост — https://example.com/request/path , Edge добавляет расширение имя_сервера , как показано ниже:

Для получения дополнительной информации о SNI см. http://en.wikipedia.org/wiki/Server_Name_Indiction .

«Алгоритм подписи» в деталях сертификатов SSL

К сведениям о сертификате SSL было добавлено новое поле «Алгоритм подписи», которое можно просмотреть в пользовательском интерфейсе управления («Администратор» > «Сертификаты SSL») и в API управления ( «Получить сведения о сертификате из хранилища ключей или хранилища доверенных сертификатов »). В поле отображается либо «sha1WithRSAEncryption», либо «sha256WithRSAEncryption», в зависимости от типа алгоритма хеширования, используемого для создания сертификата.

Показаны SSL-сертификаты, срок действия которых истекает

На странице «Сертификаты SSL» в пользовательском интерфейсе управления («Администратор» > «Сертификаты SSL») указано, когда срок действия сертификатов SSL истекает в течение 10, 15, 30 или 90 дней, в зависимости от вашего выбора в новом раскрывающемся поле срока действия.

Конфигурация ошибки защиты от угроз

По умолчанию Edge выдает код состояния внутренней ошибки сервера HTTP 500 и ошибку ExecutionFailed, если сообщение не проходит через политику защиты от угроз JSON или XML. Вы можете изменить это поведение при ошибке с помощью нового свойства уровня организации. При установке для свойства организации features.isPolicyHttpStatusEnabled значения true происходит следующее:

• Запрос: если к любому потоку запросов прикреплена политика защиты от угроз, недопустимые сообщения возвращают код состояния 400 вместе с соответствующим сообщением об ошибке политики.
• Ответ: если к любому потоку ответов прикреплена политика защиты от угроз, недопустимые сообщения по-прежнему возвращают код состояния 500, и выдается одно из соответствующих сообщений об ошибке политики (а не просто ExecutionFailed).

Клиенты облака должны обратиться в службу поддержки Apigee , чтобы настроить свойство организации. Эта функция будет доступна клиентам Edge Private Cloud в следующем ежеквартальном выпуске Private Cloud.

Обновлены схемы для конечных точек, прокси и других объектов.

Справочные схемы были обновлены для объектов, не связанных с политикой, таких как TargetEndpoint, ProxyEndpoint, APIProxy и многих других. См. https://github.com/apigee/api-platform-samples/tree/master/schemas . (АПИРТ-1249)

Услуги для разработчиков

Ниже приведены новые функции Developer Services, включенные в этот выпуск.

Общая доступность SmartDocs

SmartDocs переходит от бета-версии к общедоступной версии. Обновления и новые функции включают в себя:

• Поддержка Swagger 2.0, включая импорт по файлу или URL-адресу, включая поддержку объектов безопасности с собственными именами.
• Улучшения визуального дизайна в шаблонах, генерирующих SmartDocs.
• Улучшения удобства использования и рабочего процесса на портале разработчиков, доступные через меню «Содержимое» > «SmartDocs» в Drupal.
• То, что раньше называлось аутентификацией «Пользовательский токен», теперь называется «Ключ API».
• Объекты «безопасности» аутентификации, определенные на уровне версии.
• Настройка аутентификации клиента на уровне шаблона. Новые версии больше не сбрасывают предварительно настроенные учетные данные клиента SmartDocs.

Дополнительные описания функций см. в этой записи блога .

Документацию SmartDocs см. в разделе «Использование SmartDocs для документирования API» .

Название приложения разработчика отображается в пользовательском интерфейсе управления.

Приложения разработчика в Edge имеют как внутреннее имя, которое не меняется, так и отображаемое имя, которое вы можете изменить. На странице приложения разработчика в пользовательском интерфейсе управления (Публикация > Приложения разработчика > имя приложения) внутреннее «Имя» приложения отображается вместе с «Отображаемым именем», что упрощает визуальную идентификацию приложений по их внутренним именам для устранения неполадок и использования API. управление.

Аналитические услуги

Ниже приведены новые функции служб аналитики, включенные в этот выпуск.

Ограничение по времени сохранения данных

При создании аналитических отчетов с помощью пользовательского интерфейса или API управления данные старше шести месяцев с текущей даты по умолчанию недоступны. Если вы хотите получить доступ к данным старше шести месяцев, обратитесь в службу поддержки Apigee .

Классическая версия пользовательских отчетов удаляется из пользовательского интерфейса управления.

Дополнительная классическая версия пользовательских аналитических отчетов больше не доступна в пользовательском интерфейсе управления.

Производительность виджета Developer Engagement

Виджет воронки на главной панели аналитики (раздел «Взаимодействие с разработчиками») был улучшен для повышения производительности.

Монетизация

Ниже приведены новые функции монетизации, включенные в этот выпуск.

Уведомления о тарифном плане по электронной почте

Новый тип уведомления по электронной почте о тарифном плане позволяет вам уведомлять разработчиков, когда они достигают определенного лимита транзакций или долларов в приобретенных ими тарифных планах с объемным диапазоном или пакетом. Подробности см. в разделе Настройка уведомлений с использованием шаблонов уведомлений .

Синхронизация периодических сборов и периодов агрегирования

В тарифном плане потенциально существовало два разных периода времени:

• Период периодической комиссии, настраиваемый на вкладке «Комиссии» тарифного плана и определяющий, когда с разработчиков взимается регулярная плата.
• Период базиса агрегирования, определенный в прейскуранте для планов Volume Banded или Bundles, который определяет момент сброса использования пакета для разработчиков.

Эти два периода теперь синхронизированы. Если в тарифном плане присутствуют и ненулевая регулярная плата, и тарифная карта Volume Banded или Bundle, период регулярной комиссии используется для обоих. Например, если существует ежемесячная регулярная плата, пакеты прейскурантов также сбрасываются ежемесячно (по умолчанию в начале месяца).

Если периодическая плата не существует, пакеты сбрасываются на основе основы агрегирования, определенной в прейскуранте. Например, если разработчик начинает использовать прейскурант 19-го числа месяца, а основа агрегирования — каждый месяц, то использование пакета сбрасывается через месяц после 19-го числа.

Базис агрегирования устарел и будет удален из монетизации в будущем выпуске. Дополнительную информацию см. в разделе Указание сведений о тарифном плане .

Пользовательские атрибуты в сводных отчетах о доходах

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

Клиенты Apigee Edge для частного облака могут установить флаг с помощью следующего вызова API и учетных данных системного администратора.

curl -u email:password -X PUT -H "Content-type:application/xml" http://host:8080/v1/o/myorg -d \
"<Organization type="trial" name="MyOrganization">
    <Properties>
        <Property name="features.isMonetizationEnabled">true</Property>
        <Property name="MINT.SUMMARY_CUSTOM_ATTRIBUTES">[&quot;my_attribute_1&quot;,&quot;my_attribute_2&quot;]</Property>
        <Property name="features.topLevelDevelopersAreCompanies">false</Property>
    </Properties>
</Organization>"

Обратите внимание, что массив пользовательских атрибутов в вызове API закодирован в URL-адресе.

Процесс обновления SmartDocs

Если вы уже использовали SmartDocs в период бета-тестирования, новые функции и возможности общедоступной версии требуют обновления SmartDocs на портале разработчика.

Любые страницы SmartDocs, которые уже были опубликованы на вашем портале разработчика, продолжат работать, но вы должны следить за процессом обновления, прежде чем редактировать или публиковать какие-либо изменения на существующих или новых страницах.

Имейте в виду, что, хотя вы можете отображать и публиковать SmartDocs на своем портале разработчика, SmartDocs генерируются на основе модели API, которая находится в службах управления API Edge Apigee. Любые изменения, которые вы вносите в модель API в Edge, будут одинаковыми во всех ваших средах Pantheon (аналогично тому, как разработчики существуют в средах Pantheon).

Для обновления бета-версии SmartDocs до общедоступной версии

1. Обновите и протестируйте выпуск 15.05.27 в своей среде разработки или тестирования на Pantheon.
2. Создайте новую модель, чтобы заменить любую существующую модель API, которую вы использовали.
   • Если вы импортировали документы Swagger или WADL, импортируйте их еще раз в новую версию.
   • Если вы поддерживали свою модель API через модуль SmartDocs, экспортируйте ее в формате SmartDocs JSON и импортируйте в новую модель, используя вложение файла.
3. Установите свойства безопасности версии вашей модели. На странице Содержимое > SmartDocs > модель выберите Настройки безопасности .
   
4. Проверьте любую предварительно настроенную аутентификацию на странице настроек модели ( Содержимое > SmartDocs ), нажав «Настройки» в столбце «Операции».
   
5. Обновите все пользовательские шаблоны, чтобы использовать ресурсы CSS и JS версии 6, и внесите изменения, отражающие любые новые имена объектов, такие как authSchemes и apiSchema. Информацию об обновлении шаблонов SmartDocs см. в разделе «Использование SmartDocs для документирования API» .
6. Выполните повторную визуализацию и опубликуйте версию модели.
7. После проверки новой документации обновите рабочий портал до версии 15.05.27.

Если вы являетесь корпоративным клиентом Edge и у вас есть вопросы или сомнения по поводу процесса обновления, отправьте электронное письмо по адресу marsh@apigee.com и cnovak@apigee.com. В противном случае, пожалуйста, используйте сообщество Apigee для получения наилучшего ответа.

Будущие изменения и улучшения функций

В этом разделе представлены ожидаемые будущие изменения и улучшения функций:

Изменение поведения политики кэша ответов

В будущем выпуске (который будет определен позднее) поведение по умолчанию элемента <ExcludeErrorResponse> политики кэша ответов изменится.

Текущее поведение: элемент <ExcludeErrorResponse> в политике кэширования ответов по умолчанию имеет значение false. Это означает, что по умолчанию ответы с любым возможным кодом состояния HTTP (включая 3xx) кэшируются с помощью политики кэширования ответов.

Будущее поведение: элемент <ExcludeErrorResponse> в политике кэша ответов по умолчанию будет иметь значение true. Это означает, что по умолчанию кэшируются только ответы с кодами состояния HTTP от 200 до 205. Чтобы переопределить это поведение и кэшировать ответы для всех кодов состояния, вам необходимо явно установить для элемента <ExcludeErrorResponse> значение true.

Текущее решение: для частного облака 4.15.07.00 и более ранних версий, если вы хотите кэшировать ответы только с кодами состояния от 200 до 205, необходимо явно установить для элемента <ExcludeErrorResponse> значение true.

Исправлены ошибки

В этом выпуске исправлены следующие ошибки.

Известные проблемы

В этом выпуске имеются следующие известные проблемы.

> source /{install-dir}/apigee4/bin/apigee-env.sh 

> VER=`basename $(find $SHARE_DIR/installer/monetization -name "mint-*.zip") | cut -d "-" -f 2,3,4` 

> sed -i "s/^MONETIZATION_VERSION=.*/MONETIZATION_VERSION=$VER/" /install-dir/apigee4/bin/apigee-env.sh 

> rm /install-dir/apigee4/share/monetization 

************************************** 
In order to complete the monetization upgrade please run: 
sudo /opt/apigee4/share/monetization/schema/migration/MOPDK4.15.04.00/
365-create-notification-condition.sh 
************************************** 

connect.ranges.denied=10.0.0.0/8,192.168.0.0/16,127.0.0.1/32

<install_dir>/apigge4/bin/apigee-service message-processor restart