Обновление компонентов

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

Подробнее об особенностях процесса обновления в новой версии Fabric рассказано в разделе Обновление до последней версии Fabric.

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

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

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

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

  1. Создание резервной копии реестра и провайдера службы членства.
  2. Обновление двоичных файлов до последней версии.

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

В этом разделе предполагается, что все шаги будут выполняться с помощью команд интерфейса командной строки Docker. Если вы используете другой метод развертывания (Rancher, Kubernetes, OpenShift и т.д.), см. соответствующую документацию об использовании интерфейса командной строки для этих инструментов.

Обратите внимание, что в случае развертывания с помощью Docker также потребуется заменить файл конфигурации формата YAML узлов (например, файл orderer.yaml) на файл из артефактов новой версии.

Для этого сделайте резервную копию файла orderer.yaml или core.yaml (для одноранговых узлов) и замените его файлом orderer.yaml или core.yaml из артефактов новой версии. Затем перенесите все измененные переменные из резервной копии orderer.yaml или core.yaml в новый файл. Для такой цели удобно использовать такой инструмент как diff. Обратите внимание, что замена файла YAML файлом из новой версии, а не обновление старого файла YAML, является рекомендуемым способом обновления файлов YAML для узлов, так как это снижает вероятность ошибок.

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

Переменные среды для двоичных файлов

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

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

CORE_PEER_TLS_ENABLED=true
CORE_PEER_GOSSIP_USELEADERELECTION=true
CORE_PEER_GOSSIP_ORGLEADER=false
CORE_PEER_PROFILE_ENABLED=true
CORE_PEER_TLS_CERT_FILE=/etc/hyperledger/fabric/tls/server.crt
CORE_PEER_TLS_KEY_FILE=/etc/hyperledger/fabric/tls/server.key
CORE_PEER_TLS_ROOTCERT_FILE=/etc/hyperledger/fabric/tls/ca.crt
CORE_PEER_ID=peer0.org1.example.com
CORE_PEER_ADDRESS=peer0.org1.example.com:7051
CORE_PEER_LISTENADDRESS=0.0.0.0:7051
CORE_PEER_CHAINCODEADDRESS=peer0.org1.example.com:7052
CORE_PEER_CHAINCODELISTENADDRESS=0.0.0.0:7052
CORE_PEER_GOSSIP_BOOTSTRAP=peer0.org1.example.com:7051
CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer0.org1.example.com:7051
CORE_PEER_LOCALMSPID=Org1MSP

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

ORDERER_GENERAL_LISTENADDRESS=0.0.0.0
ORDERER_GENERAL_GENESISMETHOD=file
ORDERER_GENERAL_GENESISFILE=/var/hyperledger/orderer/orderer.genesis.block
ORDERER_GENERAL_LOCALMSPID=OrdererMSP
ORDERER_GENERAL_LOCALMSPDIR=/var/hyperledger/orderer/msp
ORDERER_GENERAL_TLS_ENABLED=true
ORDERER_GENERAL_TLS_PRIVATEKEY=/var/hyperledger/orderer/tls/server.key
ORDERER_GENERAL_TLS_CERTIFICATE=/var/hyperledger/orderer/tls/server.crt
ORDERER_GENERAL_TLS_ROOTCAS=[/var/hyperledger/orderer/tls/ca.crt]
ORDERER_GENERAL_CLUSTER_CLIENTCERTIFICATE=/var/hyperledger/orderer/tls/server.crt
ORDERER_GENERAL_CLUSTER_CLIENTPRIVATEKEY=/var/hyperledger/orderer/tls/server.key
ORDERER_GENERAL_CLUSTER_ROOTCAS=[/var/hyperledger/orderer/tls/ca.crt]

Независимо от способа задания переменных среды, они должны быть указаны для каждого узла, который необходимо обновить.

Создание резервной копии и восстановление реестра

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

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

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

Обратите внимание, что в указанном каталоге будут храниться данные как реестра, так и чейнкода. Хотя рекомендуется создавать резервные копии обоих, можно пропустить подкаталоги stateLeveldb, historyLeveldb, chains/index в каталоге /var/hyperledger/production/ledgersData. Несмотря на то, что отсутствие этих подкаталогов уменьшает размер резервной копии, восстановление однорангового узла из такой резервной копии может занять больше времени, поскольку эти артефакты реестра будут воссозданы при запуске однорангового узла.

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

Обновление узлов службы упорядочения

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

  1. Остановка узла службы упорядочения.
  2. Создание резервной копии реестра и провайдера службы членства узла службы упорядочения.
  3. Удаление контейнера узла службы упорядочения.
  4. Запуск нового контейнера узла службы упорядочения с соответствующим тегом образа.

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

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

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

  • ORDERER_CONTAINER: название контейнера узла службы упорядочения. Обратите внимание, что при обновлении эту переменную необходимо установить для каждого узла.
  • LEDGERS_BACKUP: каталог в локальной файловой системе, где будет храниться резервная копия реестра. Как будет показано далее, при резервном копировании для каждого узла будет создаваться отдельный каталог, содержащий копию реестра этого узла. Эти каталоги нужно создать самостоятельно.
  • IMAGE_TAG: версия Fabric, до которой производится обновление. Например, 2.0.

Обратите внимание, что тег образа необходимо установить, чтобы убедиться в использовании образов правильной версии. Тег образа устанавливается разными способами в зависимости от выбранного метода развертывания.

Обновление контейнеров

Перед началом процесса обновления остановим узел службы упорядочения:

docker stop $ORDERER_CONTAINER

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

docker cp $ORDERER_CONTAINER:/var/hyperledger/production/orderer/ ./$LEDGERS_BACKUP/$ORDERER_CONTAINER

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

docker rm -f $ORDERER_CONTAINER

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

docker run -d -v /opt/backup/$ORDERER_CONTAINER/:/var/hyperledger/production/orderer/ \
            -v /opt/msp/:/etc/hyperledger/fabric/msp/ \
            --env-file ./env<name of node>.list \
            --name $ORDERER_CONTAINER \
            hyperledger/fabric-orderer:$IMAGE_TAG orderer

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

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

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

  1. Остановка однорангового узла.
  2. Создание резервной копии реестра и провайдера службы членства узла.
  3. Удаление контейнеров и изображений чейнкода.
  4. Удаление контейнера однорангового узла.
  5. Запуск нового контейнера однорангового узла с использованием соответствующего тега образа.

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

Перед обновлением одноранговых узлов установите следующие переменные среды.

  • PEER_CONTAINER: название контейнера однорангового узла. Обратите внимание, что эту переменную нужно задать для каждого узла.
  • LEDGERS_BACKUP: каталог в локальной файловой системе, где будет храниться резервная копия реестра. Как будет показано далее, при резервном копировании для каждого узла будет создаваться отдельный каталог, содержащий копию реестра этого узла. Эти каталоги нужно создать самостоятельно.
  • IMAGE_TAG: версия Fabric, до которой производится обновление. Например, 2.0.

Обратите внимание, что тег образа необходимо установить, чтобы убедиться в использовании образов правильной версии. Тег образа устанавливается разными способами в зависимости от выбранного метода развертывания.

Повторите этот процесс для всех одноранговых узлов, пока все узлы не будут обновлены.

Обновление контейнеров

Остановим первый узел с помощью следующей команды:

docker stop $PEER_CONTAINER

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

docker cp $PEER_CONTAINER:/var/hyperledger/production ./$LEDGERS_BACKUP/$PEER_CONTAINER

После остановки однорангового узла и создания резервной копии реестра, удалите контейнеры чейнкода однорангового узла:

CC_CONTAINERS=$(docker ps | grep dev-$PEER_CONTAINER | awk '{print $1}')
if [ -n "$CC_CONTAINERS" ] ; then docker rm -f $CC_CONTAINERS ; fi

А также образы чейнкода однорангового узла:

CC_IMAGES=$(docker images | grep dev-$PEER | awk '{print $1}')
if [ -n "$CC_IMAGES" ] ; then docker rmi -f $CC_IMAGES ; fi

После этого удалите контейнер однорангового узла (поскольку новому контейнеру присваивается имя старого):

docker rm -f $PEER_CONTAINER

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

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:$IMAGE_TAG peer node start

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

Проверка успешности обновления одноранговых узлов

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

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

Обновление удостоверяющих центров

Описание процесса обновления сервера удостоверяющих центров Fabric CA приводится в разделе документации, посвященном удостоверяющим центрам.

Обновление клиентов Node SDK

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

Используйте NPM для обновления любых клиентов Node.js, выполнив следующие команды из корневого каталога приложения:

npm install fabric-client@latest

npm install fabric-ca-client@latest

Эти команды позволяют установить новую версию клиентов Fabric и Fabric-CA, а также записать новые версии в файл package.json.

Обновление CouchDB

В случае использования CouchDB в качестве базы данных состояний следует обновить CouchDB однорангового узла во время обновления самого узла.

Для обновления базы данных CouchDB:

  1. Остановите CouchDB.
  2. Создайте резервную копию каталога базы данных CouchDB.
  3. Установите последние двоичные файлы CouchDB или укажите новый образ Docker в сценариях развертывания.
  4. Повторно запустите CouchDB.

Обновление оболочки Node чейнкода

Чтобы перейти на новую версию оболочки Node чейнкода:

  1. Измените версию fabric-shim в файле package.json чейнкода.
  2. Повторно упакуйте новый пакет чейнкода и установите на всех одноранговых узлах в канале, поддерживающих этот чейнкод.
  3. Выполните обновление до новой версии чейнкода. Описание этого процесса приводится в разделе Команды чейнкода одноранговых узлов.

Обновление чейнкода с помощью сторонней оболочки

Описание процесса обновления оболочки Go чейнкода до версии 2.0 приводится в разделе Изменение оболочки чейнкода.

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

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