Включение нового жизненного цикла чейнкода

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

Обратите внимание, что функциональные возможности групп Channel и Application конфигураций каналов приложений должны быть обновлены до уровня V2_0, чтобы новый жизненный цикл чейнкода заработал. Для получения дополнительной информации ознакомьтесь с разделом Рекомендации по переходу на версию v2.0.

Обновление конфигурации канала состоит из трех этапов (для каждого канала):

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

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

Создание файла enable_lifecycle.json

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

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

Следует отметить, что в файле enable_lifecycle.json используются примеры значений, такие как org1Policies и Org1ExampleCom, которые следует заменить для конкретного развертывания:

{
  "org1Policies": {
      "Endorsement": {
           "mod_policy": "Admins",
           "policy": {
               "type": 1,
               "value": {
               "identities": [
                  {
	                 "principal": {
	           	         "msp_identifier": "Org1ExampleCom",
	           	         "role": "PEER"
	                 },
	                 "principal_classification": "ROLE"
	              }
              	],
              	"rule": {
                  "n_out_of": {
			           "n": 1,
			           "rules": [
			           	{
			           		"signed_by": 0
			           	}
			           ]
			       }
              	},
              	"version": 0
              }
           },
           "version": "0"
      }
   },
  "org2Policies": {
      "Endorsement": {
           "mod_policy": "Admins",
           "policy": {
               "type": 1,
               "value": {
               "identities": [
                  {
	                 "principal": {
	           	         "msp_identifier": "Org2ExampleCom",
	           	         "role": "PEER"
	                 },
	                 "principal_classification": "ROLE"
	              }
              	],
              	"rule": {
                  "n_out_of": {
			           "n": 1,
			           "rules": [
			           	{
			           		"signed_by": 0
			           	}
			           ]
			       }
              	},
              	"version": 0
              }
           },
           "version": "0"
      }
   },
   "appPolicies": {
 		"Endorsement": {
			"mod_policy": "Admins",
			"policy": {
				"type": 3,
				"value": {
					"rule": "MAJORITY",
					"sub_policy": "Endorsement"
				}
			},
			"version": "0"
		},
		"LifecycleEndorsement": {
			"mod_policy": "Admins",
			"policy": {
				"type": 3,
				"value": {
					"rule": "MAJORITY",
					"sub_policy": "Endorsement"
				}
			},
			"version": "0"
		}
   },
   "acls": {
		"_lifecycle/CheckCommitReadiness": {
			"policy_ref": "/Channel/Application/Writers"
		},
		"_lifecycle/CommitChaincodeDefinition": {
			"policy_ref": "/Channel/Application/Writers"
		},
		"_lifecycle/QueryChaincodeDefinition": {
			"policy_ref": "/Channel/Application/Readers"
		},
		"_lifecycle/QueryChaincodeDefinitions": {
			"policy_ref": "/Channel/Application/Readers"
		}
   }
}

Примечание. В поле role этих новых правил должно быть указано PEER, если для организации включен NodeOUs, и MEMBER в ином случае.

Изменение конфигурации канала

Обновление системного канала

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

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

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

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

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

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

jq -s ".[0] * {\"channel_group\":{\"groups\":{\"Consortiums\":{\"groups\": {\"$CONSORTIUM_NAME\": {\"groups\": {\"$ORGNAME\": {\"policies\": .[1].${ORGNAME}Policies}}}}}}}}" config.json ./enable_lifecycle.json > modified_config.json

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

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

Обновление канала приложений

Редактирование организаций с одноранговыми узлами

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

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

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

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

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

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

jq -s ".[0] * {\"channel_group\":{\"groups\":{\"Application\": {\"groups\": {\"$ORGNAME\": {\"policies\": .[1].${ORGNAME}Policies}}}}}}" config.json ./enable_lifecycle.json > modified_config.json

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

Редактирование каналов приложений

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

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

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

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

jq -s '.[0] * {"channel_group":{"groups":{"Application": {"policies": .[1].appPolicies}}}}' config.json ./enable_lifecycle.json > modified_config.json

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

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

Редактирование списков контроля доступа каналов (необязательно)

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

"acls": {
 "_lifecycle/CheckCommitReadiness": {
   "policy_ref": "/Channel/Application/Writers"
 },
 "_lifecycle/CommitChaincodeDefinition": {
   "policy_ref": "/Channel/Application/Writers"
 },
 "_lifecycle/QueryChaincodeDefinition": {
   "policy_ref": "/Channel/Application/Readers"
 },
 "_lifecycle/QueryChaincodeDefinitions": {
   "policy_ref": "/Channel/Application/Readers"

Можно оставить те же переменные среды, что и при редактировании каналов приложений ранее.

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

Затем добавьте списки контроля доступа (как указано в файле enable_lifecycle.json) и создайте файл с названием modified_config.json с помощью команды:

jq -s '.[0] * {"channel_group":{"groups":{"Application": {"values": {"ACLs": {"value": {"acls": .[1].acls}}}}}}}' config.json ./enable_lifecycle.json > modified_config.json

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

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

Включение нового жизненного цикла в core.yaml

Если вы следуете рекомендуемому методу использования такого инструмента типа diff, для сравнения новой версии файла core.yaml, упакованной вместе с двоичными файлами, со старой версией, вам не потребуется добавлять _lifecycle: enable в список включенных системных чейнкодов, потому что в новом core.yaml он уже добавлен в разделе chaincode/system.

Однако, при непосредственном обновлении старой версии YAML-файла узла придется добавить _lifecycle: enable в список включенных системных чейнкодов.

Дополнительные сведения об обновлении узлов приводятся в разделе Обновление компонентов.