# Рекомендации по обновлению до версии 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 — это процесс, который позволяет нескольким организациям согласовывать особенности работы чейнкода перед его использованием в канале. Для получения дополнительной информации о новом жизненном цикле чейнкода ознакомьтесь с разделом [Жизненный цикл чейнкода](./chaincode_lifecycle.html). Рекомендуется обновить все одноранговые узлы в канале перед включением функциональных возможностей `Channel` и `Application`, которые включают новый жизненный цикл чейнкода (использование функциональной возможности `Channel` не является строго обязательным, однако имеет смысл ее обновить). Обратите внимание, что любые одноранговые узлы, не обновленные до версии 2.x, перестанут работать после включения любой из функциональных возможностей, в то время как любые узлы службы упорядочивания с версией, отличной от 2.x, перестанут работать после включения возможности `Channel`. Такой механизм предусмотрен, так как одноранговые узлы или узлы службы упорядочения не смогут безопасно работать в канале, если в нем не поддерживаются требуемые функциональные возможности. После обновления функциональной возможности `Application` до версии `V2_0` в канале следует использовать процедуры жизненного цикла версии 2.x для упаковки, установки, одобрения и записи новых чейнкодов в канале. Поэтому, прежде чем обновлять функциональные возможности, убедитесь, что всё готово к новому жизненному циклу. В новом жизненном цикле по умолчанию используется политика одобрения, указанная в конфигурации канала (например, `MAJORITY` — большинство организаций). Поэтому эту политику одобрения следует добавить в конфигурацию канала при включении новых функциональных возможностей канала. Подробнее о том, как отредактировать соответствующие конфигурации каналов для включения нового жизненного цикла путем добавления политики одобрения для каждой организации, описано в разделе [Включение новой версии жизненного цикла чейнкода](./enable_cc_lifecycle.html). ### Изменение оболочки чейнкода (только для чейнкода Go) Рекомендуется импортировать (`vendor`) оболочку в ваш чейнкод версии 1.4 на Go перед обновлением одноранговых узлов и каналов. В таком случае не потребуется внесения дополнительных изменений в чейнкод. Если оболочка чейнкода версии 1.4 не импортирована, старые образы чейнкода версии 1.4 будут технически работать после обновления, однако такая ситуация нежелательна. Если образ чейнкода по какой-либо причине удален из среды, при следующем вызове чейнкода на узле версии 2.x будет произведена попытка повторной сборки образа чейнкода с сообщением об ошибке, что оболочка не может быть найдена. Существует два варианта действий: 1. Если весь канал готов к обновлению чейнкода, можно обновить чейнкод на всех одноранговых узлах и в канале (используя старый или новый жизненный цикл в зависимости от используемого уровня функциональных возможностей `Application`). На этом этапе наилучшим решением является импортирование оболочки чейнкода Go с использованием модулей. 2. Если еще не весь канал готов к обновлению чейнкода, можно воспользоваться переменными среды однорангового узла и указать версию 1.4 для среды чейнкода `ccenv`, которая будет использоваться для повторной сборки образов чейнкода. Среда `ccenv` версии 1.4 должна по-прежнему работать с одноранговыми узлами версии 2.x. ### Журналирование (логирование) чейнкодов (только для чейнкодов на Go) Была удалена поддержка инструмента журналирования оболочки чейнкода с помощью `NewLogger()` для пользовательских чейнкодов. Для чейнкодов, использующих функцию оболочки `NewLogger()`, теперь следует использовать другой механизм журналирования. Для получения дополнительной информации смотрите раздел [Управление логированием](./logging-control.html#chaincode). ### Обновление баз данных одноранговых узлов Описание процесса обновления одноранговых узлов приводится в документации по [обновлению компонентов](./upgrading_your_components.html). В процессе [обновления одноранговых узлов](./upgrading_your_components.html#upgrade-the-peers) потребуется выполнить один дополнительный шаг для обновления баз данных одноранговых узлов. Базы данных всех одноранговых узлов (которые включают не только базу данных состояний, но и базу данных истории и другие внутренние базы данных) должны быть собраны с использованием формата данных версии 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.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.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`: включает новый жизненный цикл чейнкода, как описано в разделе [Жизненный цикл чейнкода](./chaincode_lifecycle.html). * **Channel** `V2_0`: эта возможность не изменилась, и используется для согласованности с уровнями возможностей приложения и службы упорядочения. * **Orderer** `V2_0`: управляет параметром `UseChannelCreationPolicyAsAdmins`, изменяя способ проверки транзакций создания каналов. При использовании параметра `-baseProfile` инструмента configtxgen теперь можно переопределить значения, которые ранее были унаследованы от системного канала службы упорядочения. Как и при любом обновлении уровней возможностей, обязательно обновите двоичные файлы одноранговых узлов перед обновлением возможностей `Application` и `Channel`, а также обновите двоичные файлы узлов службы упорядочения перед обновлением возможностей `Orderer` и `Channel`. Для получения информации о том, как установить новые функциональные возможности, ознакомьтесь с разделом [Обновление уровня функциональных возможностей канала](./updating_capabilities.html). ### Определение конечных точек узлов службы упорядочения для каждой организации (рекомендуется) Начиная с версии 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: Считывание и конвертация конфигурации](./config_update.html#step-1-pull-and-translate-the-config). Затем добавьте политику организации жизненного цикла (как указано в файле `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: Повторная конвертация и запись конфигурации](./config_update.html#step-3-re-encode-and-submit-the-config). Если организация службы упорядочения вносит изменения в конфигурацию канала, она может редактировать конфигурацию без дополнительных подписей (по умолчанию единственная подпись, необходимая для редактирования параметров в рамках организации, — это подпись администратора этой организации). Если другая организация предлагает обновление, то организация, которая подвергается изменениям, должна подписать запрос на обновление канала.