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

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

Во вторник, 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 for Private Cloud можно обновиться до 4.15.07.00» .

Перед обновлением с версии 4.15.01.x или с более ранней версии

1. Проверьте версию Cassandra SSTable:
   1. Перейдите в каталог /<install-root>/apigee4/data/cassandra/data .
   2. Выполните команду find,
      > find . -name *-ic-*
      В результате выполнения запроса должны быть получены файлы с расширением .db, если вы используете Cassandra 1.2 SSTable.
   3. Выполните следующую команду поиска:
      > find . -name *-hf-*
      Результаты должны быть пустыми, это означает, что файлов .db в формате hf не обнаружено. Если вы не видите файлов в формате hf , значит, обновление завершено, и вы можете обновиться до версии 4.15.07.00.
      
      Формат hf предназначен для SSTable-файлов Cassandra 1.0. Если у вас есть файлы *.db в формате hf , вам необходимо обновить SSTable, как описано в остальной части этой процедуры.
2. Если вы обнаружите файлы *.db в формате hf , обновите SSTable, выполнив следующую команду на каждом узле Cassandra, пока не обновите все узлы Cassandra:
   > /<install-root>/apigee4/share/apache-cassandra/bin/nodetool -h localhost upgradesstables -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 /<install-root>/apigee4/data/cassandra/data
   > find . -name *-jb-*
   Если вы используете Cassandra 2.0, эта команда должна вернуть набор файлов .db.

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

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

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

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

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

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

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

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

Скрипты установки больше не принимают полные варианты параметров, такие как --help. Теперь они принимают только однобуквенные параметры, например -h. (OPDK-1356)

установка SmartDocs

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

Запуск скрипта update-cass-pwd-in-config.sh без запроса командной строки.

Скрипт update-cass-pwd-in-config.sh может запускаться без запроса пароля, если заданы переменные среды ENABLE_CASS_AUTH, CASS_USERNAME и CASS_PASSWORD. (OPDK-1309)

Краевая платформа

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

Поддержка OpenJDK 1.7 в Edge Private Cloud

В этой версии Edge поддерживаются Oracle JDK 1.7 и OpenJDK 7, а поддержка JDK 1.6 удалена. (OPDK-1187)

Поддержка ОС

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

Cassandra 2.0.15 включена в OPDK 15.07

В этом релизе устанавливается Cassandra 2.0.15. Если вы обновляетесь до предыдущей версии, ваша версия Cassandra будет обновлена. (OPDK-1197)

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

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

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

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

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

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

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

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

Чтобы вернуться к старому поведению, использующему свойство "Максимальное количество элементов в памяти" для управления кэшем, установите свойство overrideMaxElementsInCacheResource=false в файле cache.properties. (APIRT-1140)

API-сервисы

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

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

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

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

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

Новая политика удаления OAuth v1.0 Info

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

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

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

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

Новые сущности в политике доступа к сущностям

Политика доступа к сущностям предоставляет доступ к следующим новым сущностям: consumerkey-scopes, authorizationcode, requesttoken и verifier. Для получения дополнительной информации см. раздел «Политика доступа к сущностям» .

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

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

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

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

Доступ к Apigee Community через меню «Справка» в пользовательском интерфейсе управления.

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

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

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

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

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

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

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

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

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

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

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

Поддержка Server Name Direction (SNI)

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

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

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

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

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

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

«Алгоритм подписи» в описании SSL-сертификатов.

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

Отображение SSL-сертификатов, срок действия которых близок к истечению.

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

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

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

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

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

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

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

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

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

SmartDocs доступен для общего использования.

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

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

Более подробное описание функций см. в этой записи блога .

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

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

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

Аналитические сервисы

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

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

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

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

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

Производительность виджета «Взаимодействие с разработчиками»

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

Монетизация

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

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

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

Синхронизация периодов регулярных платежей и агрегирования.

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

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

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

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

Функция Aggregation Basis устарела и будет исключена из монетизации в одном из будущих релизов. Для получения дополнительной информации см. раздел «Указание деталей тарифного плана» .

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

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

Клиенты Apigee Edge for Private Cloud могут установить этот флаг с помощью следующего вызова 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, экспортируйте ее в формате JSON SmartDocs и импортируйте в новую модель, прикрепив файл.
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.

Временное решение: для Private Cloud 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