Обновление уровня функциональных возможностей канала

Целевая аудитория: сетевые администраторы, администраторы узлов

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

Дополнительная информация о новых уровнях функциональных возможностей в последней версии Fabric приводится в разделе Обновление компонентов.

Примечание. При использовании термина «обновление» в контексте Hyperledger Fabric имеется в виду изменение версии компонента (например, переход от одной версии двоичных файлов к следующей версии). С другой стороны, термин «обновление» подразумевает не только изменение версии, а также изменения конфигурации, например, при обновлении конфигурации канала или сценария развертывания. Поскольку с технической точки зрения в Fabric не предусмотрена миграция данных, термин «миграция» в этом разделе не используется.

Предварительные требования и рекомендации

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

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

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

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

Общая информация

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

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

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

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

  1. Получение текущей конфигурации канала.
  2. Создание измененной конфигурации канала.
  3. Создание транзакции обновления конфигурации.

Функциональные возможности включаются в следующем порядке:

  1. Системный канал службы упорядочения
  • Группа Orderer
  • Группа Channel
  1. Каналы приложений
  • Группа Orderer
  • Группа Channel
  • Группа Application

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

Следует обратить внимание, что в работающих сетях будет невозможным или нежелательным для одного пользователя иметь возможность самостоятельно обновлять все эти каналы (и разделы конфигураций). Системный канал, например, должен администрироваться исключительно администраторами службы упорядочения (хотя можно добавить организации с одноранговыми узлами в качестве организаций службы упорядочения). Аналогичным образом, обновление групп Orderer или Channel конфигурации канала требует подписи организации службы упорядочения, в дополнение к организациям с одноранговыми узлами. Распределенные системы требуют совместного управления.

Создание файла конфигурации функциональных возможностей

Следует отметить, что в этом учебном примере предполагается, что файл с именем capabilities.json уже создан и содержит обновления функциональных возможностей, которые необходимо внести в различные разделы конфигурации. Также здесь используется инструмент jq для применения изменений к измененному файлу конфигурации.

Обратите внимание, что не обязательно создавать файл capabilities.json или использовать инструмент jq. Измененную конфигурацию также можно отредактировать вручную (после считывания, конвертации и очистки от лишних данных). Для дополнительной информации смотрите образец конфигурации канала.

Однако описанный здесь процесс (с использованием файла JSON и инструмента jq) может быть оформлен в виде сценария, что делает его удобным для обновления конфигураций большого количества каналов. Вот почему это рекомендуемый способ обновления каналов.

В этом примере файл capabilities.json выглядит следующим образом (если вы обновляете канал согласно разделу Обновление до последней версии Fabric, нужно установить уровень функциональных возможностей, соответствующий этой версии):

   {
     "channel": {
         "mod_policy": "Admins",
             "value": {
                 "capabilities": {
                     "V2_0": {}
                 }
             },
         "version": "0"
     },
     "orderer": {
         "mod_policy": "Admins",
             "value": {
                 "capabilities": {
                     "V2_0": {}
                 }
             },
         "version": "0"
     },
     "application": {
         "mod_policy": "Admins",
             "value": {
                 "capabilities": {
                     "V2_0": {}
                 }
             },
         "version": "0"
     }
   }

Обратите внимание, что по умолчанию организации с одноранговыми узлами не являются администраторами системного канала службы упорядочения и поэтому не могут предлагать обновления конфигурации для этого канала. Администратору организации службы упорядочения необходимо создать такой файл (без функциональной возможности группы Application, которой нет в системном канале), чтобы предложить обновление конфигурации системного канала. Следует отметить, что поскольку канал приложения по умолчанию копирует конфигурацию системного канала, при отсутствии другого профиля канала, который определяет уровни функциональных возможностей, возможности групп Channel и Orderer для канала приложения будут такими же, как и в системном канале.

Функциональные возможности системного канала службы упорядочения

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

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

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

Задание переменных среды

Нужно установить следующие переменные окружения:

  • CH_NAME: имя обновляемого системного канала.
  • CORE_PEER_LOCALMSPID: идентификатор провайдера службы членства организации, предлагающей обновление канала. Это провайдер службы членства одной из организаций службы упорядочения.
  • TLS_ROOT_CA: полный путь к TLS-сертификату узла(ов) службы упорядочения.
  • CORE_PEER_MSPCONFIGPATH: полный путь к провайдеру службы членства, соответствующий организации.
  • ORDERER_CONTAINER: имя контейнера узла службы упорядочения. Обратите внимание, что при указании службы упорядочения, можно указывать любой узел службы упорядочения. Запросы автоматически передаются узлу-лидеру.

Группа Orderer

Чтобы узнать, как считывать, конвертировать и очищать конфигурацию канала, перейдите к подразделу Шаг 1: считывание и конвертация конфигурации. После создания файла modified_config.json, добавьте функциональные возможности в группу Orderer конфигурации (согласно capabilities.json) с помощью следующей команды:

jq -s '.[0] * {"channel_group":{"groups":{"Orderer": {"values": {"Capabilities": .[1].orderer}}}}}' config.json ./capabilities.json > modified_config.json

Затем выполните действия, описанные в подразделе Шаг 3: перекодирование и запись обновленной конфигурации.

Следует заметить, что при обновлении системного канала, правила обновления mod_policy системного канала требуют подписи только администраторов организации службы упорядочения.

Группа Channel

Еще раз вернитесь к подразделу Шаг 1: считывание и конвертация конфигурации. После создания файла modified_config.json, добавьте функциональные возможности в группу Channel конфигурации (согласно capabilities.json) с помощью следующей команды:

jq -s '.[0] * {"channel_group":{"values": {"Capabilities": .[1].channel}}}' config.json ./capabilities.json > modified_config.json

Затем выполните действия, описанные в подразделе Шаг 3: перекодирование и запись обновленной конфигурации.

Следует заметить, что при обновлении системного канала, правила обновления mod_policy системного канала требуют подписи только администраторов организации службы упорядочения. Как можно видеть, для канала приложения обычно необходимо удовлетворение правил большинства Admins группы Application (включающей провайдеров службы членства организаций с одноранговыми узлами) и группы Orderer (включающей организации службы упорядочения), при условии, что используются значения по умолчанию.

Включение функциональных возможностей в существующих каналах

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

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

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

Задание переменных среды

Нужно установить следующие переменные окружения:

  • CH_NAME: имя обновляемого канала приложения. Значение этой переменной следует менять для каждого обновляемого канала.
  • CORE_PEER_LOCALMSPID: идентификатор провайдера службы членства организации, предлагающей обновление канала. Это провайдер службы членства организации с одноранговыми узлами.
  • TLS_ROOT_CA: полный путь к TLS-сертификату узла организации с одноранговыми узлами.
  • CORE_PEER_MSPCONFIGPATH: полный путь к провайдеру службы членства, соответствующий организации.
  • ORDERER_CONTAINER: имя контейнера узла службы упорядочения. Обратите внимание, что при указании службы упорядочения, можно указывать любой узел службы упорядочения. Запросы автоматически передаются узлу-лидеру.

Группа Orderer

Перейдите к подразделу Шаг 1: считывание и конвертация конфигурации. После создания файла modified_config.json, добавьте функциональные возможности в группу Orderer конфигурации (согласно capabilities.json) с помощью следующей команды:

jq -s '.[0] * {"channel_group":{"groups":{"Orderer": {"values": {"Capabilities": .[1].orderer}}}}}' config.json ./capabilities.json > modified_config.json

Затем выполните действия, описанные в подразделе Шаг 3: перекодирование и запись обновленной конфигурации.

Обратите внимание, что правила обновления mod_policy для этих функциональных возможностей по умолчанию имеет значение большинства Admins группы Orderer (другими словами, большинство администраторов службы упорядочения). Организации с одноранговыми узлами могут предложить обновление функциональных возможностей, однако их подписи не будут соответствовать требованиям правил в этом случае.

Группа Channel

Перейдите к подразделу Шаг 1: считывание и конвертация конфигурации. После создания файла modified_config.json, добавьте функциональные возможности в группу Channel конфигурации (согласно capabilities.json) с помощью следующей команды:

jq -s '.[0] * {"channel_group":{"values": {"Capabilities": .[1].channel}}}' config.json ./capabilities.json > modified_config.json

Затем выполните действия, описанные в подразделе Шаг 3: перекодирование и запись обновленной конфигурации.

Обратите внимание, что правила обновления mod_policyпо умолчанию для этих функциональных возможностей требуют подписей большинства Admins групп Application и Orderer. Другими словами, этот запрос должно подписать большинство администраторов организаций с одноранговыми узлами, а также большинство администраторов организации службы упорядочения.

Группа Application

Перейдите к подразделу Шаг 1: считывание и конвертация конфигурации. После создания файла modified_config.json, добавьте функциональные возможности в группу Application конфигурации (согласно capabilities.json) с помощью следующей команды:

jq -s '.[0] * {"channel_group":{"groups":{"Application": {"values": {"Capabilities": .[1].application}}}}}' config.json ./capabilities.json > modified_config.json

Затем выполните действия, описанные в подразделе Шаг 3: перекодирование и запись обновленной конфигурации.

Обратите внимание, что правила обновления mod_policy по умолчанию для этих функциональных возможностей требуют подписей большинства Admins группы Application. Другими словами, это потребует одобрения большинства организаций c одноранговыми узлами. Администраторы службы упорядочения не имеют права голоса при обновлении этих функциональных возможностей.

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

Это одна из причин, по которой может пригодиться файл capabilities.json. Он помогает предотвратить человеческие ошибки. Например, установку функциональных возможностей уровня V20 для группы Application, когда необходимо установить уровень V2_0, что может привести к тому, что канал станет непригодным для использования с невозможностью восстановления.

Подтверждение транзакции после включения функциональных возможностей

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