Развертывание производственной сети

Это руководство является высокоуровневым обзором последовательности настройки компонентов производственной среды Fabric, а также лучших практик и некоторых деталей, о которых нужно помнить при развертывании. Обратите внимание, что в этой статье «настройка сети» рассматривается как целостный процесс с точки зрения одного человека. Скорее всего в реальном мире производственные сети будут настраиваться не одним человеком, а совместными усилиями нескольких человек (например, группой банков, каждый из которых устанавливает и настраивает свои собственные компоненты).

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

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

Данное руководство даст вам общее представление об этапах настройки компонентов производственной сети:

Шаг 1: определение конфигурации сети

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

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

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

  • Конфигурация удостоверяющего центра. В рамках общих решений, которые требуется принять относительно одноранговых узлов (их количество, их количество в каждом канале т.д.) и службы упорядочения (количество узлов, кто будет владеть узлами), необходимо решить, как будут развернуты центры сертификации вашей организации. В производственных сетях должен использоваться протокол TLS, что потребует установки удостоверяющих центров TLS и их использования для создания сертификатов TLS. Удостоверяющий центр TLS должен быть развернут до развертывания удостоверяющего центра организации. Обсудим это подробнее в Шаг 3: настройка удостоверяющих центров.
  • Указание подразделений организаций. Для некоторых организаций может оказаться необходимым указание их структурных подразделений для разделения идентификационных данных и MSP, созданных одним и тем же удостоверяющим центром.
  • Тип базы данных. В некоторых каналах в сети структура данных может смоделирована для работы с CouchDB (см. База данных состояний на основе CouchDB), в то время как в других сетях, где более важна скорость работы, на одноранговых узлах используется LevelDB. Обратите внимание, что в канале не могут одновременно присутствовать узлы, использующие CouchDB и LevelDB, потому что эти два типа баз данных используют различную модель данных.
  • Каналы и частные данные. В некоторых сетях в качестве обеспечения конфиденциальности и изоляции для определенных транзакций могут использоваться Каналы. В других - Конфиденциальные данные обрабатывается в одном канале.
  • Управление контейнерами. Некоторые пользователи могут создавать отдельные контейнеры для процессов одноранговых узлов, журналирования узлов, процессов CouchDB, gRPC-коммуникаций и чейнкода. А другие могут объединить некоторые из этих процессов.
  • Метод развертывания чейнкода. У пользователей есть возможность развертывания чейнкода с использованием встроенных механизмов сборки и запуска или использовать собственную сборку и запускать его, используя внешние сборщики (см. Внешние модули сборки и запуска), или использовать чейнкод как внешнюю службу (см. Чейнкод как внешняя служба).
  • Использование брандмауэров. В производственной среде компонентам, принадлежащим одной организации, может быть необходим доступ к компонентам других организаций, что требует использование брандмауэров и дополнительной конфигурации сети. Например, приложениям, использующим Fabric SDK, требуется доступ ко всем одобряющим узлам всех организаций и службам упорядочения всех каналов. Точно так же одноранговым узлам нужен доступ к службе упорядочения каналов, к которым они подключены.

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

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

Шаг 2: создание кластера для ваших ресурсов

Вообще говоря, Fabric не зависит от метода развертывания и управления. Например, можно развернуть и управлять одноранговым узлом с ноутбука. По ряду причин этого делать не рекомендуется, но в Fabric нет ничего, что запрещало бы это делать.

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

Как бы и где бы вы ни решили развернуть свои компоненты, вам необходимо убедиться, что у вас достаточно ресурсов для их эффективной работы. Объемы, которые вам понадобятся, будут в значительной степени зависеть от сценария использования. Если планируется подключение одного однорангового узла к нескольким каналам с большим объемом трафика, ему потребуется гораздо более мощный процессор и больший объем памяти, чем узлу, который будет подключен только к одному каналу. По грубой оценке на каждый одноранговый узел нужно выделять в три раза больше ресурсов, чем на упорядочивающий узел (рекомендуется развертывать не менее трех, а оптимально - пять узлов в службе упорядочения). Аналогично для удостоверяющего центра требуется примерно десятая часть ресурсов однорангового узла. Также в кластер требуется добавить хранилище (некоторые облачные провайдеры предоставляют хранилище), поскольку нельзя настроить постоянные тома (Persistent Volumes) и запросы на их использование (Persistent Volume Claims) без предварительной настройки хранилища у облачного провайдера.

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

Управление инфраструктурой

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

  • Использование секретов для безопасного хранения важных конфигурационных файлов в кластере. Информацию о секретах Kubernetes можно найти в документации Kubernetes. Также для этих целей можно использовать аппаратные модули безопасности (HSM) или зашифрованные постоянные тома (PV). После развертывания компонентов Fabric вы, вероятно, захотите запустить в контейнере свое собственное приложение, используя, например, частный репозиторий сервиса типа Docker Hub. В этом случае необходимо закодировать информацию, необходимую для входа в этот репозиторий в виде секрета Kubernetes и включить его в YAML-файл при развертывании компонентов.
  • Вопрос о кластере и размере узлов. В шаге 2 выше мы обсудили общие принципы определения вычислительной мощности узлов. Конкретный сценарий использования, а также продолжительный период разработки - это единственный путь точно определить, насколько производительными должны быть одноранговые узлы, узлы службы упорядочения и удостоверяющий центр.
  • Выбор способа монтирования томов. Лучшей практикой является монтирование томов, используемых узлами, за пределами места, где эти узлы развернуты. Это позволит ссылаться на эти тома позже (например, при перезапуске узла или контейнера, который аварийно прекратил работу) без необходимости повторного развертывания или пересоздания криптографических материалов.
  • Мониторинг ресурсов. Очень важно разработать стратегию и метод мониторинга ресурсов, используемых отдельными узлами, и ресурсов, выделенных всему кластеру. По мере подключения одноранговых узлов к большему числу каналов скорее всего потребуется увеличить производительность процессора и объем памяти. И нужно убедиться в том, что на узлах имеется достаточно места для хранения базы данных состояния и блокчейна.

Шаг 3: настройка удостоверяющих центров

Первый компонент, который должен быть развернут в сети Fabric, это удостоверяющий центр (УЦ). Это необходимо потому, что сертификаты, связанные с узлом (не только сертификаты самого узла, но и сертификаты, идентифицирующие администраторов этого узла), должны быть созданы до развертывания самого узла. Реализация удостоверяющего центра Fabric CA создает структуры MSP, необходимые для правильного определения компонентов и организаций, но использовать именно Fabric CA не обязательно. Если пользователь решит использовать другой вариант УЦ, отличный от Fabric CA, ему придется создавать папки MSP самостоятельно.

  • Один УЦ (или больше, если вы используете промежуточные УЦ: об этом ниже) используется для создания сертификатов администратора организации, MSP этой организации и узлов, принадлежащих этой организации. Этот УЦ также генерирует сертификаты для всех пользователей. В английской терминологии процесс регистрации и выпуска сертификатов называется «enrollment», а УЦ, выполняющий эту регистрацию, называется «регистрационный УЦ» («enrollment CA» или «ecert CA»).
  • Другой УЦ генерирует сертификаты, используемые для защиты соединений на транспортном уровне (TLS). По этой причине такой УЦ называется «УЦ TLS» («TLS CA»). Эти сертификаты используются при совершении различных действий для предотвращения атак с участием человека («man in the middle»). Обратите внимание, что УЦ TLS используется только для выдачи сертификатов узлов и может быть отключен после выполнения этой задачи. У пользователей есть возможность использовать односторонний (только со стороны клиента) или двухсторонний (и со стороны клиента, и со стороны сервера) TLS. Последний известен как «взаимный TLS». Поскольку решение об использовании TLS в сети (что рекомендуется) должно быть принято до того, как регистрационный УЦ будет развернут (в его YAML-конфигурации есть поле, определяющее использование TLS), сначала необходимо развернуть УЦ TLS и использовать его корневой сертификат при запуске регистрационного УЦ. Этот сертификат TLS будет также использоваться клиентом fabric-ca при подключении к регистрационному УЦ для создания регистрации новых пользователей и узлов.

Хотя все не-TLS сертификаты, связанные с организацией, могут быть выпущены одним «корневым» удостоверяющим центром (т.е. УЦ, который является собственным корнем доверия), для дополнительной безопасности организации могут использовать «промежуточные» удостоверяющие центры, сертификаты которых выпускаются корневым УЦ (или другим промежуточным УЦ, который в конечном итоге ведет к корневому УЦ). Поскольку компрометация корневого УЦ приводит к утрате доверия на всех уровнях (сертификаты администраторов, узлов и любых УЦ, выпущенные корневым УЦ), промежуточные удостоверяющие центры являются хорошим способом уменьшения уязвимости корневого удостоверяющего центра. Необходимость использования промежуточных УЦ зависит от конкретного сценария. Их использование не является обязательным. Стоит обратить внимание на то, что для управления идентификационными данными в сети Fabric можно использовать LDAP. Этот вариант удобен для организаций, которые уже используют этот протокол и не хотят добавлять еще один уровень управления идентификационными данными к существующей инфраструктуре. LDAP фактически предварительно регистрирует всех членов каталога и позволяет им регистрироваться на основе заданных критериев.

В производственной сети рекомендуется развертывать как минимум один удостоверяющий центр для регистрации и еще один для выпуска TSL-сертификатов. Например, если в сети разворачивается три одноранговых узла, принадлежащих одной организации, и упорядочивающий узел, принадлежащий другой организации, то потребуется как минимум четыре УЦ. Два из них будут предназначены для организации, владеющей одноранговыми узлами (выпускающие регистрационные сертификаты и сертификаты TLS для одноранговых узлов, администраторов, соединений, а также структуры папок MSP организации), а два других - для организации упорядочивающего узла. Обратите внимание, что пользователи обычно регистрируются только в регистрационном УЦ, а узлы - и в регистрационном УЦ, где они получают сертификаты, идентифицирующие его при подписи его действий, и в УЦ TLS, где они получают сертификаты для аутентификации при установке соединений.

Пример настройки удостоверяющего центра организации и удостоверяющего центра TLS, а также регистрации идентификаторов их администраторов, можно найти в руководстве по развертыванию Fabric CA. В нем показано использование клиента Fabric CA для выпуска и регистрации идентификаторов, которые требуются при настройке УЦ.

Шаг 4: создание идентификационных данных и MSP с помощью УЦ

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

  • Зарегистрировать и выпустить идентификатор администратора и создать MSP. После создания УЦ, связанного с организацией, его можно использовать сначала для регистрации идентификатора, а затем для выпуска сертификатов для этого идентификатора. На первом этапе администратор УЦ назначает имя пользователя и пароль для идентификатора. Также идентификатору могут быть присвоены атрибуты и принадлежность организации (например, роль admin, которая необходима для администраторов организации). После регистрации идентификатора для него можно выпустить криптографические материалы, используя имя пользователя и пароль, полученные при регистрации. УЦ создаст два сертификата для этого идентификатора: публичный сертификат (также известный как «signcert» или «public cert»), известный другим членам сети, и закрытый ключ (хранящийся в папке keystore), используемый для подписи действий, выполняемых этим идентификатором. УЦ также создает набор папок, называемый «MSP», содержащих открытых сертификат УЦ, выпустившего сертификат идентификатора и корень доверия для УЦ (это может быть как тот же УЦ, так и другой). Эту структуру MSP можно рассматривать как определение организации, с которой связан идентификатор администратора. В случаях, когда администратор организации является также и администратором узла (что обычно и бывает), необходимо создать идентификатор администратора организации до создания локальной структуры MSP узла, поскольку при ее создании используется сертификат администратора узла.
  • Зарегистрировать и выпустить идентификаторы узлов. Так же, как регистрируются и выпускаются идентификаторы администратора организации, должны быть зарегистрированы и выпущены идентификаторы узлов, как в регистрационном УЦ, так и в УЦ TLS (последний выпускает сертификаты для защиты соединений). Здесь нужно вместо роли admin или user указать роль peer или orderer. Как и для администратора, идентификаторам узлов могут быть назначены различные атрибуты и принадлежности организациям. Структура MSP для узла известна как «локальный MSP», поскольку разрешения, назначенные идентификаторами, имеют значение только на локальном (узловом) уровне. Этот MSP создается при создании идентификатора узла и используется при загрузке этого узла.

Более подробно об идентификаторах и разрешениях в блокчейн-сетях на основе Fabric можно узнать из статей Identity и Membership Service Provider (MSP).

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

Шаг 5: развертывание узлов

Как только вы получили все необходимые сертификаты и MSP, вы почти готовы к запуску узла. Как говорилось выше, есть несколько способов развертывания узлов.

Создание однорангового узла

Прежде чем создавать одноранговый узел, необходимо подготовить конфигурационный файл для него. В Fabric он называется core.yaml. Пример содержимого конфигурационного файла core.yaml можно найти в каталоге sampleconfig репозитория Hyperledger Fabric

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

Существует три основных варианта настройки конфигурации.

  1. Отредактировать файл YAML, поставляемый вместе с бинарными файлами.
  2. Переопределить значения переменных окружения при развертывании.
  3. Указать флаги команд командной строки.

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

В любом случае следующие значения в core.yaml должны быть проверены.

  • peer.localMspID: это имя локального MSP организации, владеющей одноранговым узлом. В этом MSP будут перечислены администраторы организации узла, а также корневые сертификаты УЦ организации и УЦ TLS.
  • peer.mspConfigPath: месторасположение локального MSP однорангового узла. Лучше всего монтировать этот том снаружи контейнера. Это гарантирует, что в случае остановки контейнера (например, для обслуживания) MSP не будут потеряны и их не придется создавать заново.
  • peer.address: представляет конечную точку для других одноранговых узлов в той же организации, что является важным при установки gossip-соединений внутри организации.
  • peer.tls: при установке значения параметра enabled в true (как это и должно быть сделано в производственной сети) необходимо указать месторасположение соответствующих сертификатов TLS. Обратите внимание, что все узлы в сети (и одноранговые, и упорядочивающие) должны либо использовать TLS, либо нет. Для производственных сетей настоятельно рекомендуется включить использование TLS. Как и в случае с локальным MSP этот том лучше монтировать снаружи контейнера.
  • ledger: пользователям необходимо принять несколько решений относительно реестра, включая тип базы данных состояния (LevelDB или CouchDB, например) и ее расположение (указанное в fileSystemPath). Обратите внимание, что для CouchDB предпочтительна работа вне однорангового узла (например, в отдельном контейнере), так как в этом случае у вас будет больше возможности по управлению ресурсами для базы данных. Для минимизации задержек при обмене данными и большей безопасности лучше всего располагать контейнер CouchDB на том же сервере, что и одноранговый узел. Доступ к контейнеру CouchDB должен быть только у контейнера однорангового узла.
  • gossip: при настройке gossip-соединений (см. Протокол распространения данных gossip) необходимо продумать несколько параметров в конфигурации, включая externalEndpoint (для возможности обнаружения однорангового узла узлами других организаций), а также адрес bootstrap (для идентификации однорангового узла в собственной организации).
  • chaincode.externalBuilders: это поле важно установить при использовании чейнкода как внешней службы (см. Чейнкод как внешняя служба).

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

Создание упорядочивающего узла

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

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

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

Существует три основных варианта настройки конфигурации.

  1. Отредактировать файл YAML, поставляемый вместе с бинарными файлами.
  2. Переопределить значения переменных окружения при развертывании.
  3. Указать флаги команд командной строки.

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

В любом случае следующие значения в orderer.yaml должны быть проверены. Вы заметите, что некоторые из этих полей такие же, как и в файле core.yaml, только с другими названиями.

  • General.LocalMSPID: имя локального MSP, созданного УЦ организации упорядочивающего узла.
  • General.LocalMSPDir: месторасположение локального MSP упорядочивающего узла. Лучше всего монтировать этот том снаружи контейнера.
  • General.ListenAddress и General.ListenPort: представляют собой конечную точку узла для других упорядочивающих узлов той же организации
  • FileLedger: хотя у упорядочивающих узлов нет базы данных состояния, они все же хранят копию цепочки блоков, поскольку это позволяет им проверять разрешения, используя последний конфигурационный блок. Поэтому в полях реестра должен быть указан верный путь к файлу.
  • Cluster: эти значения важны для упорядочивающих узлов, которые общаются с другими упорядочивающими узлами, например, в службе упорядочения на основе Raft.
  • General.BootstrapFile: имя файла с конфигурационным блоком, используемым при запуске упорядочивающего узла. Если этот узел является первым, созданным в службе упорядочения, этот файл должен быть создан и называется «начальным блоком».
  • General.BootstrapMethod: метод, которым передается блок для начальной загрузки. Сейчас есть только метод file, а путь к файлу определяется в BootstrapFile. Начиная с версии 2.0, можно указать значение none, чтобы запустить упорядочивающий узел без начальной загрузки.
  • Consensus: определяет пары ключ-значение, разрешенные плагином консенсуса (поддерживается и рекомендуется к использованию сервис упорядочения на основе Raft) для опережающего ведения журнала (WALDir) и сохранения образов (SnapDir).

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

Следующие шаги

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

Часть процесса соединения узлов и создания каналов включает в себя изменение политик в соответствии со сценариями использования бизнес-сетей. Более подробную информацию о политиках можно найти в статье Policies.

Одной из распространенных задач в Fabric является редактирование существующих каналов. Руководство по этому процессу можно найти в статье Обновление конфигурации канала. Одним из самых частых случаев обновления канала является добавление организации в существующий канал. Руководство по этому процессу ищите в статье Adding an Org to a Channel. Информацию об обновлении узлов после их развертывания можно найти в статье Обновление компонентов.

Развертывание производственного УЦ