Рекомендации по обновлению до версии 2.x¶

В этом разделе рассматриваются рекомендации по обновлению с предыдущей версии до последней версии, а также с последней версии с долгосрочной поддержкой (LTS).

Обновление с версии 2.1 до 2.2¶

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

Обновление до версии 2.2 с версии 1.4.x с долгосрочной поддержкой¶

Перед обновлением с версии 1.4.x до версии 2.2 обязательно учтите следующее:

Жизненный цикл чейнкода¶

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

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

После обновления функциональной возможности Application до версии V2_0 в канале следует использовать процедуры жизненного цикла версии 2.x для упаковки, установки, одобрения и записи новых чейнкодов в канале. Поэтому, прежде чем обновлять функциональные возможности, убедитесь, что всё готово к новому жизненному циклу.

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

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

Изменение оболочки чейнкода (только для чейнкода Go)¶

Рекомендуется импортировать (vendor) оболочку в ваш чейнкод версии 1.4 на Go перед обновлением одноранговых узлов и каналов. В таком случае не потребуется внесения дополнительных изменений в чейнкод.

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

Существует два варианта действий:

Если весь канал готов к обновлению чейнкода, можно обновить чейнкод на всех одноранговых узлах и в канале (используя старый или новый жизненный цикл в зависимости от используемого уровня функциональных возможностей Application). На этом этапе наилучшим решением является импортирование оболочки чейнкода Go с использованием модулей.
Если еще не весь канал готов к обновлению чейнкода, можно воспользоваться переменными среды однорангового узла и указать версию 1.4 для среды чейнкода ccenv, которая будет использоваться для повторной сборки образов чейнкода. Среда ccenv версии 1.4 должна по-прежнему работать с одноранговыми узлами версии 2.x.

Журналирование (логирование) чейнкодов (только для чейнкодов на Go)¶

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

Для получения дополнительной информации смотрите раздел Управление логированием.

Обновление баз данных одноранговых узлов¶

Описание процесса обновления одноранговых узлов приводится в документации по обновлению компонентов. В процессе обновления одноранговых узлов потребуется выполнить один дополнительный шаг для обновления баз данных одноранговых узлов. Базы данных всех одноранговых узлов (которые включают не только базу данных состояний, но и базу данных истории и другие внутренние базы данных) должны быть собраны с использованием формата данных версии 2.x в рамках обновления до версии 2.x. Чтобы запустить повторную сборку, базы данных следует сперва удалить (drop) перед запуском однорангового узла. В приведенных ниже инструкциях используется команда peer node upgrade-dbs для удаления локальных баз данных однорангового узла, и подготовки их к обновлению для возможности восстановления при первом запуске однорангового узла под версией 2.x. При использовании CouchDB в качестве базы данных состояний, одноранговые узлы поддерживают автоматическое удаление базы данных, начиная с версии 2.2. Чтобы воспользоваться этой возможностью, для однорангового узла в качестве базы данных состояний следует настроить CouchDB, а также запустить CouchDB перед запуском команды upgrade-dbs. В версиях 2.0 и 2.1 одноранговые узлы не удаляют базы данных состояний CouchDB автоматически. Эта операция выполняется вручную.

Используйте последовательность команд для обновления однорангового узла до команды docker run для запуска нового контейнера однорангового узла (этот шаг можно пропустить, если задано значение IMAGE_TAG, поскольку команда upgrade-dbs предназначена только для версии 2.x Fabric, однако, в таком случае, следует установить переменные среды PEER_CONTAINER и LEDGERS_BACKUP). Вместо команды docker run для запуска однорангового узла выполните следующую команду, чтобы удалить и подготовить локальные базы данных однорангового узла (замените 2.1 на 2.0 в этих командах при обновлении версии двоичных файлов с версии 1.4.x LTS):

docker run --rm -v /opt/backup/$PEER_CONTAINER/:/var/hyperledger/production/ \
            -v /opt/msp/:/etc/hyperledger/fabric/msp/ \
            --env-file ./env<name of node>.list \
            --name $PEER_CONTAINER \
            hyperledger/fabric-peer:2.0 peer node upgrade-dbs

В версиях 2.0 и 2.1 при использовании CouchDB в качестве базы данных состояний также следует удалить базу данных CouchDB. Это можно сделать, удалив каталог тома CouchDB/data.

Затем выполните следующую команду, чтобы запустить одноранговый узел с тегом 2.0:

docker run -d -v /opt/backup/$PEER_CONTAINER/:/var/hyperledger/production/ \
            -v /opt/msp/:/etc/hyperledger/fabric/msp/ \
            --env-file ./env<name of node>.list \
            --name $PEER_CONTAINER \
            hyperledger/fabric-peer:2.0 peer node start

При первом запуске одноранговый узел повторно соберет базы данных в формате данных версии 2.x. Поскольку повторная сборка баз данных может занять много времени (несколько часов, в зависимости от размера баз данных), следите за журналами одноранговых узлов, чтобы быть в курсе состояния процесса восстановления. При обработке каждого 1000-го блока будет выводиться сообщение типа [lockbasedtxmgr] CommitLostBlock -> INFO 041 Recommitting block [1000] to state database, что указывает на продолжение процесса повторной сборки.

Если база данных не удаляется в процессе обновления, при запуске однорангового узла появится сообщение о том, что базы данных узла находятся в старом формате и должны быть удалены с помощью приведенной выше команды peer node upgrade-dbs (или вручную при использовании базы данных состояний CouchDB). Затем будет необходимо повторно перезапустить узел.

Функциональные возможности¶

В версии 2.0 появились три новые функциональные возможности.

Application V2_0: включает новый жизненный цикл чейнкода, как описано в разделе Жизненный цикл чейнкода.
Channel V2_0: эта возможность не изменилась, и используется для согласованности с уровнями возможностей приложения и службы упорядочения.
Orderer V2_0: управляет параметром UseChannelCreationPolicyAsAdmins, изменяя способ проверки транзакций создания каналов. При использовании параметра -baseProfile инструмента configtxgen теперь можно переопределить значения, которые ранее были унаследованы от системного канала службы упорядочения.

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

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

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

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

На уровне организации конечные точки необходимы для работы службы обнаружения в случае предоставления узлов службы упорядочения несколькими организациями. Это позволяет клиентам предоставлять правильные TLS-сертификаты организации.

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

В этом примере мы создадим раздел для отдельной организации под названием OrdererOrg. Если в службе упорядочения вашей сети несколько организаций, все они должны иметь конечные точки. Назовем файл JSON как orglevelEndpoints.json.

{
  "OrdererOrgEndpoint": {
      "Endpoints": {
          "mod_policy": "Admins",
          "value": {
              "addresses": [
                 "127.0.0.1:30000"
              ]
          }
      }
   }
}

После этого следует экспортировать следующие переменные среды:

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

После установки переменных среды перейдите к подразделу Шаг 1: Считывание и конвертация конфигурации.

Затем добавьте политику организации жизненного цикла (как указано в файле orglevelEndpoints.json) в файл с названием modified_config.json, используя команду:

jq -s ".[0] * {\"channel_group\":{\"groups\":{\"Orderer\": {\"groups\": {\"$ORGNAME\": {\"values\": .[1].${ORGNAME}Endpoint}}}}}}" config.json ./orglevelEndpoints.json > modified_config.json

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

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