# Использование файла configtx.yaml для создания конфигурации канала

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

Несмотря на то, что файл транзакции создания канала можно создать вручную, легче создавать канал с помощью файла 
`configtx.yaml` и инструмента [configtxgen](../commands/configtxgen.html). Файл `configtx.yaml` содержит информацию, 
которая требуется для создания конфигурации канала, в удобном для чтения и редактирования формате. Инструмент 
`configtxgen` считывает данные из файла `configtx.yaml` и сохраняет их в [формате protobuf](https://developers.google.com/protocol-buffers), 
который считывается сетью Fabric.

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

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

- [Организации](#organizations)
- [Функциональные возможности](#capabilities)
- [Приложение](#application)
- [Служба упорядочения](#orderer)
- [Канал](#channel)
- [Профили](#profiles)

Поскольку разные разделы файла используются совместно для формирования правил, регулирующих работу канала, 
рассмотрению правил канала выделен [отдельный раздел](channel_policies.html).

Основываясь на примере из [руководства по созданию каналу](create_channel.html), воспользуемся файлом `configtx.yaml`
для развертывания примера сети Fabric. Откройте терминал на локальном компьютере и перейдите к каталогу `test-network` 
в локальной копии примера сети Fabric:
```
cd fabric-samples/test-network
```

Используемый в примере сети Fabric файл `configtx.yaml` расположен в каталоге `configtx`. Откройте файл в текстовом
редакторе. Далее в этом разделе мы будем многократно возвращаться к этому файлу. Более подробно файл `configtx.yaml`
рассматривается в [примере конфигурации Fabric](https://github.com/hyperledger/fabric/blob/{BRANCH}/sampleconfig/configtx.yaml).

## Организации

Наиболее важная информация конфигурации канала — это данные об организациях, которые являются членами канала.
Каждая организация идентифицируется с помощью идентификатора провайдера службы членства и [провайдера службы членства канала](../membership/membership.html).
Провайдер службы членства канала указан в конфигурации канала и содержит сертификаты, которые используются для
идентификации узлов, приложений и администраторов организации. Раздел **Organizations** файла `configtx.yaml` 
используется при создании провайдера службы членства канала, а также соответствующих идентификаторов провайдера 
службы членства для каждого члена канала.

Файл `configtx.yaml` конфигурации примера сети Fabric содержит три организации. Две организации, Org1 и Org2, владеют 
одноранговыми узлами, которые могут быть добавлены в каналы приложений. Организация OrdererOrg является администратором
службы упорядочения. Поскольку для развертывания одноранговых узлов и узлов службы упорядочения рекомендуется 
использовать разные удостоверяющие центры, организации часто разделяют на организации с одноранговыми узлами и
организации службы упорядочения, даже если они на самом деле являются частью одной компании.

Ниже показан раздел файла `configtx.yaml`, содержащий определение организации Org1 в примере сети:
  ```yaml
  - &Org1
      # DefaultOrg defines the organization which is used in the sampleconfig
      # of the fabric.git development environment
      Name: Org1MSP

      # ID to load the MSP definition as
      ID: Org1MSP

      MSPDir: ../organizations/peerOrganizations/org1.example.com/msp

      # Policies defines the set of policies at this level of the config tree
      # For organization policies, their canonical path is usually
      #   /Channel/<Application|Orderer>/<OrgName>/<PolicyName>
      Policies:
          Readers:
              Type: Signature
              Rule: "OR('Org1MSP.admin', 'Org1MSP.peer', 'Org1MSP.client')"
          Writers:
              Type: Signature
              Rule: "OR('Org1MSP.admin', 'Org1MSP.client')"
          Admins:
              Type: Signature
              Rule: "OR('Org1MSP.admin')"
          Endorsement:
              Type: Signature
              Rule: "OR('Org1MSP.peer')"
  ```  

  - Поле `Name` — это неформальное название, используемое для идентификации организации.

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

  - Поле `MSPDir` содержит путь к каталогу провайдера службы членства, который был создан организацией. 
    Инструмент `configtxgen` будет использовать этот каталог при создании провайдера службы членства канала. 
    Этот каталог должен содержать следующую информацию, которая будет передана провайдеру службы членства канала 
    и сохранена в конфигурации канала:
    - Корневой сертификат удостоверяющего центра, который является корнем доверия в организации. Этот сертификат 
      используется для проверки принадлежности приложений, узлов или администраторов к определенному члену канала.
    - Корневой сертификат от удостоверяющего центра TLS, который выпускает сертификаты TLS для одноранговых узлов или
      узлов службы упорядочения. Корневой сертификат TLS используется для идентификации организаций протоколом gossip.
    - При включенной опции организационных подразделений узлов, каталог провайдера службы членства должен содержать
      файл `config.yaml`, который идентифицирует администраторов, узлы и клиентов на основе организационных
      подразделений из сертификатов X509.
    - Если опция организационных подразделений узлов не включена, в каталоге провайдера службы членства (MSP)
      должен находится подкаталог admincerts c сертификатами для идентификаторов администраторов организаций.

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

  - Раздел `Policies` используется для определения набора правил подписи, которые ссылаются на члена канала. 
    Эти правила более подробно описываются в разделе [правила канала](channel_policies.html).
    
## Функциональные возможности

К каналам в сети Fabric могут присоединяться одноранговые узлы и узлы службы упорядочения, которые используют разные
версии Hyperledger Fabric. Функциональные возможности канала позволяют организациям в канале использовать различные
версии исполняемых файлов Fabric с помощью включения определенных опций. Например, организации, использующие
версию Fabric 1.4, а также организации, использующие версию 2.x, могут присоединиться к одному и тому же каналу,
если для функциональных возможностей канала указана версия 1_4_X или более старая. В таком случае участники канала
не смогут использовать возможности, добавленные в версии Fabric 2.0.

Посмотрев файл `configtx.yaml`, можно увидеть три группы функциональных возможностей:

- В группе **Application** указываются возможности для одноранговых узлов, например, жизненный цикл чейнкода,
  а также задается минимальная версия исполняемых файлов Fabric, которые могут выполняться на одноранговых узлах в канале.

- В группе **Orderer** указываются возможности для узлов службы упорядочения, включая алгоритм достижения консенсуса
  Raft, а также задается минимальная версия исполняемых файлов Fabric, которые могут выполняться узлами службы
  упорядочения, входящих в состав выборщиков канала.

- В группе **Channel** задается минимальная версия Fabric, которая может использоваться узлами службы упорядочения и одноранговыми узлами.

Поскольку одноранговые узлы и узлы службы упорядочения примера сети Fabric используют версию 2.x, во всех группах 
указана версия `v2_0`. В результате к этой сети не могут подключаться узлы, которые используют версию Fabric, 
ниже версии 2.0. Дополнительная информация о функциональных возможностях приведена в [отдельном разделе](../capabilities_concept.html).  

## Приложение

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

В примере сети используются правила приложений по умолчанию, которые предусмотрены в Hyperledger Fabric. При
использовании правил по умолчанию все организации с одноранговыми узлами могут считывать и записывать данные в реестр.
Правила по умолчанию также требуют подписи обновления конфигурации большинством членов канала, а также одобрения 
определения чейнкода большинством перед тем, как чейнкод может быть развернут в канале. Более подробно это обсуждается 
в руководстве [Правила канала](channel_policies.html).

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

В конфигурации канала указываются узлы службы упорядочения, входящие в [состав выборщиков канала](../glossary.html#consenter-set). 
В состав выборщиков входят узлы службы упорядочения, которые имеют возможность создавать новые блоки и распределять их
среди одноранговых узлов в канале. Данные конечной точки каждого узла службы упорядочения, который входит в состав
выборщиков, хранятся в конфигурации канала.

 В примере сети раздел **Orderer** файла `configtx.yaml` используется для создания одного узла службы упорядочения Raft.

- Поле `OrdererType` используется для выбора алгоритма Raft для достижения консенсуса:
  ```
  OrdererType: etcdraft
  ```

  Служба упорядочения Raft определяется набором выборщиков, которые могут участвовать в процессе достижения консенсуса. 
  Так как в примере сети используется только один узел службы упорядочения, набор выборщиков содержит только одну конечную точку:
  ```yaml
  EtcdRaft:
      Consenters:
      - Host: orderer.example.com
        Port: 7050
        ClientTLSCert: ../organizations/ordererOrganizations/example.com/orderers/orderer.example.com/tls/server.crt
        ServerTLSCert: ../organizations/ordererOrganizations/example.com/orderers/orderer.example.com/tls/server.crt
      Addresses:
      - orderer.example.com:7050
  ```

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

- Поля `BatchTimeout` и `BatchSize` позволяют указать задержку и пропускную способность канала путем изменения 
  максимального размера каждого блока и частоты создания новых блоков.

- Раздел `Policies` позволяет указать правила, которые будут управлять составом выборщиков канала. В примере сети
  используются предусмотренные в Fabric правила по умолчанию, которые требуют, чтобы большинство администраторов 
  службы упорядочения одобряли добавление или удаление узлов, организаций, а также изменение параметров разделения блоков.

Поскольку пример сети используется для разработки и тестирования, служба упорядочения содержит только один узел.
В реальных сетях следует использовать большее количество узлов службы упорядочения для обеспечения безопасности и доступности. Дополнительная информация указана в разделе [Настройка и использование службы упорядочения Raft](../raft_configuration.html).  

## Канал

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

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

## Профили

Инструмент `configtxgen` считывает профили канала из раздела **Profiles** для построения конфигурации канала.
В каждом профиле используется синтаксис YAML для сбора данных из других разделов файла. Инструмент `configtxgen`
использует эту конфигурацию для создания транзакции создания канала для канала приложения или для записи первичного 
блока для системного канала. Обзор синтаксиса YAML можно прочитать в [Wikipedia](https://en.wikipedia.org/wiki/YAML).

Используемый в примере сети Fabric файл `configtx.yaml` содержит два профиля канала — `TwoOrgsOrdererGenesis` и `TwoOrgsChannel`:

### Профиль TwoOrgsOrdererGenesis

Профиль `TwoOrgsOrdererGenesis` используется для создания первичного блока системного канала:
```yaml
TwoOrgsOrdererGenesis:
    <<: *ChannelDefaults
    Orderer:
        <<: *OrdererDefaults
        Organizations:
            - *OrdererOrg
        Capabilities:
            <<: *OrdererCapabilities
    Consortiums:
        SampleConsortium:
            Organizations:
                - *Org1
                - *Org2
```

В системном канале указываются узлы службы упорядочения, а также набор организаций, которые являются администраторами 
службы упорядочения. Системный канал также включает в себя набор организаций с одноранговыми узлами, принадлежащих к
[консорциуму](../glossary.html#consortium) блокчейна. Провайдеры службы членства канала каждого члена консорциума 
включаются в системный канал, позволяя создавать новые каналы приложений и добавлять членов консорциума в новый канал.

Этот профиль создает консорциум с названием `SampleConsortium`, который содержит две одноранговые организации
Org1 и Org2, в файле `configtx.yaml`. В разделе `Orderer` профиля указан один узел службы упорядочения Raft, 
определенный в разделе **Orderer:**. Организация OrdererOrg в разделе **Organizations:** является единственным 
администратором службы упорядочения. Поскольку единственный узел службы упорядочения использует версию Fabric 2.x,
можно указать версию `V2_0` функциональных возможностей системного канала службы упорядочения. В системном канале
используются правила по умолчанию из раздела **Channel**, а также версия `V2_0` функциональных возможностей канала.

### Профиль TwoOrgsChannel

В примере сети профиль `TwoOrgsChannel` используется для создания каналов приложений:
```yaml
TwoOrgsChannel:
    Consortium: SampleConsortium
    <<: *ChannelDefaults
    Application:
        <<: *ApplicationDefaults
        Organizations:
            - *Org1
            - *Org2
        Capabilities:
            <<: *ApplicationCapabilities
```

Системный канал используется службой упорядочения в качестве шаблона для создания каналов приложений. Узлы службы 
упорядочения, которые определены в системном канале, становятся набором выборщиков по умолчанию для новых каналов,
в то время как администраторы службы упорядочения становятся администраторами службы упорядочения канала. Провайдеры
службы членства канала организаций в канале передаются в новый канал из системного канала. После создания канала узлы службы
упорядочения могут быть добавлены или удалены из канала путем обновления конфигурации канала. Также конфигурацию канала
можно изменить для возможности [добавления других организаций в качестве членов канала](../channel_update_tutorial.html).

В профиле `TwoOrgsChannel` указывается название консорциума `SampleConsortium`, который входит в состав системного 
канала примера сети. В результате узлы службы упорядочения, определенной в профиле `TwoOrgsOrdererGenesis`, становятся
набором выборщиков канала. В разделе `Application` обе организации консорциума Org1 и Org2 указываются в качестве 
членов канала. В канале используется версия `V2_0` функциональных возможностей приложений, а также правила по умолчанию
из раздела **Application** для управления взаимодействием организаций, содержащих одноранговые узлы, с каналом. В канале
приложения также используются правила по умолчанию из раздела **Channel**, а также указана версия `V2_0` функциональных
возможностей канала.