Hyperledger Fabric для Чайников
A Blockchain Platform for the Enterprise
Добрый день, дорогие читатели, меня зовут Николай Нефедов, я технический консультант компании IBM, в этой статье я хотел бы познакомить вас с блокчейн платформой – Hyperledger Fabric. Платформа предназначена для построения бизнес приложений уровня предприятия (Enterprise class). Уровень статьи – для неподготовленных читателей, имеющих базовые знания IT технологий.
Hyperledger Fabric это open-source проект, одна из ветвей открытого проекта Hyperledger, консорциума Linux Foundation. Hyperledger Fabric был изначально стартован Digital Assets и IBM. Основной особенностью платформы Hyperledger Fabric является направленность на корпоративное применение. Поэтому платформа разрабатывалась с учетом обеспечения высокой скорости проведения транзакций и их низкой стоимости, а также идентификации всех участников. Данные преимущества достигаются за счет разделения службы проверки транзакций и формирования новых блоков распределенного реестра, а также применения центра сертификации и авторизации участников.
Моя cтатья это часть цикла статей о Hyperledger Fabric в рамках которой мы описываем проект системы по учету студентов, поступающих в ВУЗ.
Общая архитектура Hyperledger Fabric
Hyperledger Fabric — это распределенная блокчейн сеть, состоящая из различных функциональных компонентов, которые устанавливаются на узлы сети. Компоненты Hyperledger Fabric представляют из себя Docker контейнеры, которые можно свободно скачать из DockerHub. Hyperledger Fabric также можно запустить в Kubernetes среде.
Для написания смарт-контрактов (chaincode в контексте Hyperledger Fabric) мы использовали Golang (хотя Hyperledger Fabric позволяет использовать и другие языки). Для разработки пользовательского приложения в нашем случае использовался Node.js с соответствующим Hyperledger Fabric SDK.
На узлах выполняется бизнес логика (смарт-контракт) – chaincode, хранится состояние распределенного реестра (ledger data) и исполняются другие системные службы платформы. Узел – это только логическая единица, разные узлы могут существовать на одном физическом сервере. Гораздо важнее – это как узлы сгруппированы (Trusted domain) и с какими функциями блокчейн сети они ассоциированы.
Общая архитектура выглядит следующим образом:
Picture 1. Общая Архитектура Hyperledger Fabric
Пользовательское приложение (Submitting Client) — приложение, с помощью которого пользователи работают с блокчейн сетью. Для работы необходимо пройти авторизацию и обладать соответствующими правами на разного рода действия в сети.
Peers (Узлы) бывают нескольких ролей:
Endorsement Policy – это политика проверки транзакции на валидность. Данные политики определяют необходимый набор узлов, на которых должен быть выполнен смарт-контракт для того, чтобы транзакция была признана валидной.
Распределенный Реестр — Lerger — состоит из двух частей: WolrldState (также называется — State DataBase) и BlockChain.
BlockChain — это цепочка блоков, которая хранит записи о всех изменениях, произошедших с объектами распределенного реестра.
WolrldState — это компонент распределенного реестра, который хранит текущие (крайние) значения всех объектов распределенного реестра.
WorldState представляет собой базу данных, в базовом варианте — LevelDB или более сложная – CouchDB, которая содержит пары ключ — значение, например: Имя – Иван, Фамилия — Иванов, дата регистрации в системе – 12.12.21, дата рождения — 17.12.1961, и т.д. WorldState и распределенный реестр должны быть консистентны у всех участников данного канала.
Поскольку Hyperledger Fabric это сеть, в которой все участники известны и аутентифицированы, здесь используется выделенный центр сертификации — CA (Certification Authority). CA работает на основе X.509 стандарта и инфраструктуры публичных ключей – PKI.
Membership Service – это служба, через которую участники осуществляют проверку принадлежности объекта к той или иной организации или каналу.
Транзакция – в большинстве случаев, это запись новых данных в распределенный реестр.
Также транзакции бывают на создание каналов или смарт-контрактов. Транзакция инициируется пользовательским приложением и заканчивается записью в распределенный реестр.
Канал (Channel) – это закрытая подсеть, состоящая из двух или более участников блокчейн сети, предназначенная для проведения конфиденциальных транзакций внутри ограниченного, но известного, круга участников. Канал определяется участниками, своим распределённым реестром, смарт-контрактами, Ordering Service, WorldState. Каждый участник канала должен быть авторизован на доступ к каналу и иметь право выполнять разного рода транзакции. Авторизация выполняется с помощью Membership Service.
Типовой сценарий исполнения транзакции
Далее я хотел бы рассказать о типовом сценарии выполнения транзакции на примере нашего проекта.
В рамках нашего внутреннего проекта мы создали Hyperledger Fabric сеть, которая предназначена для регистрации и учета студентов, поступающих в ВУЗы. Наша сеть состоит из двух организаций, принадлежащим ВУЗу A и ВУЗу B. Каждая организация содержит клиентское приложение, а также свои Committing и Endorsing Peer. Также мы используем общие сервисы Ordering Service, Memebership Service и Certification Authority.
1) Инициация Транзакции
Пользовательское приложение, используя Hyperledger Fabric SDK, инициирует запрос на транзакцию и отправляет запрос на узлы со смарт-контрактами. Запрос может быть на изменение или чтение из распределенного реестра (Ledger). Если рассматривать пример нашей тестовой конфигурации системы для учета студентов ВУЗов, то клиентское приложение посылает запрос на транзакцию на узлы вузов A и B, которые включены в Endorsement policy вызываемого смарт-контракта. Узел A — это узел, который находится в ВУЗе, который регистрирует поступающего студента, а узел B — это узел, который находится в другом ВУЗе. Для того чтобы транзакция была сохранена в распределенный реестр, необходимо, чтобы все узлы, которые согласно бизнес логике должны одобрить транзакцию, успешно выполнили смарт-контракты с одинаковым результатом. Пользовательское приложение узла A, используя инструменты Hyperledger Fabric SDK, получает Endorsement policy (политика одобрения) и узнает, на какие узлы нужно отправить запрос на транзакцию. Это запрос на вызов (invoke) определенного смарт-контракта (chaincode function), чтобы прочитать или записать определённые данные в распределенный реестр. Технически, клиентское SDK использует соответствующую функцию, API которой передается некий объект с параметрами транзакции, а также добавляет клиентскую подпись и отправляет эти данные по протоколу protocol buffer over gRPC на соответствующие узлы (endorsing peers).
Picture 2. Инициация Транзакции
2) Выполнение смарт-контракта
Узлы (Endorsing Peers), получив запрос на проведение транзакции, проверяют клиентскую подпись и если все в порядке, то берут объект с данными запроса и запускают симуляцию исполнения смарт-контракта (chaincode function) с этими данными. Смарт-контракт — это бизнес логика транзакции, определённый набор условий и инструкций (в нашем случае это проверка студента, новый это студент, или он уже зарегистрирован, проверка возраста и т.д.). Для исполнения смарт-контракта также понадобятся данные из WorldState. В результате симуляции смарт-контракта на Endorsing peer получается два набора данных – Read Set и Write Set. Read Set и Write Set — это исходные и новые значения WorldState. (новые – в смысле полученные при симуляции смарт-контракта).
Picture 3. Выполнение смарт-контракта
3) Возврат данных клиентскому приложению
После проведения симуляции смарт-контракта Endorsing Peers возвращают клиентскому приложению исходные данные и результат симуляции, а также RW Set, подписанные своим сертификатом. На данном этапе никаких изменений в распределенном реестре не происходит. Клиентское приложение проверяет подпись Endorsing Peer, а также сравнивает исходные данные транзакции, которые были отправлены, и данные, которые вернулись (то есть проверяет не исказились ли исходные данные над которыми проводилась симуляция транзакции). Если транзакция была только на чтение данных из реестра, то клиентское приложение соответственно получает необходимый Read Set и на этом обычно транзакция успешно завершается без изменения распределенного реестра. В случае транзакции, которая должна изменить данные в реестре, клиентское приложение дополнительно проводит проверку выполнения Endorsing policy. Возможна ситуация, когда клиентское приложение не проверяет результат выполнения Endorsement Policy, но платформа Hyperledger Fabric в данном случае предусматривает проверку политик на узлах (Comitting Peers) на стадии добавления транзакции в реестр.
Picture 4. Возврат данных клиентскому приложению
4) Отправка RW sets на Ordering Peers
Клиентское приложение отправляет транзакцию вместе с сопутствующими данными на Ordering service. Сюда включаются RW Set, подписи Endorsing peers, а также идентификатор канала (Channel ID).
Ordering service – исходя из названия, основная функция этого сервиса — построение поступающих транзакций в правильном порядке. А также формирование нового блока распределенного реестра и гарантированную доставку новых сформированных блоков всем Commiting узлам, таким образом обеспечивая консистентность данных на всех узлах содержащих распределенный реестр (Commiting peers). При этом сам Ordering service никак не меняет реестр. Ordering Service это жизненно важный компонент системы, поэтому он представляет из себя кластер из нескольких узлов. Ordering Service не проверяет транзакцию на валидность, он просто принимает транзакцию с определенным идентификатором канала, выстраивает поступающие транзакции в определенном порядке и формирует из них новые блоки распределенного реестра. Один Ordering Service может обслуживать несколько каналов одновременно. В состав Ordering Service входит Kafka кластер, который и поддерживает правильную (неизменную) очередь транзакций (см. Пункт 7).
Picture 5. Отправка RW sets на Ordering Peers
5) Отправка сформированных блоков на Committing Peer
Сформированные в Ordering Service блоки передаются (broadcast) всем узлам сети. Каждый узел, получив новый блок, проверяет его на соответствие Endorsing Policy, проверяет, что все Endorsing Peers получили одинаковый результат (Write Set) в результате симуляции смарт-контракта, а также проверяет, не изменились ли исходные значения (то есть — Read Set — данные прочитанные смарт-контрактом из WorldState) с момента инициации транзакции. Если все условия выполнены – транзакция помечается валидной, в противном случае, транзакция получает статус не валидной.
Picture 6. Отправка сформированных блоков на Committing Peer
6) Добавления блока в реестр
Каждый узел добавляет транзакцию в свою локальную копию распределенного реестра, при этом, если транзакция валидна, то Write Set применяется к WorldState (текущему состоянию), соответственно, записываются новые значения объектов, которые затрагивались транзакцией. В случае если транзакция получила маркер – не валидной (например, произошло две транзакции с одними и теми же объектами в рамках одного блока, то одна из транзакций получится не валидной, поскольку исходные величины уже изменены другой транзакцией). Эта транзакция также добавляется в распределенный реестр с маркером не валидной, но Write Set этой транзакции не применяется к текущему состоянию WorldState и, соответственно, не изменяет объекты, учавствующие в транзакции. После этого пользовательскому приложению отправляется нотификация, что транзакция на веки вечные добавлена в распределенный реестр, а также статус транзакции, то есть валидна она или нет…
Picture 7. Добавления блока в реестр
ORDERING SERVICE
Ordering Service состоит из Kafka кластера с соответсвующими ZooKeeper нодами и Ordering Service Nodes (OSN), которые стоят между клиентами Ordering service и Kafka Кластером. Kafka кластер — это распределенная, отказоустойчивая платформа управления потоками (сообщениями). Каждый канал (топик) в Kafka — это неизменяемая последовательность записей, которая поддерживает только добавление новой записи (удаление существующей невозможно). Иллюстрация структуры топика приведена ниже. Именно это свойство Kafka и используется для построения блокчейн платформы.
взято с сайта kafka.apache.org
Picture 8. Ordering Service Topic Structure
Полезны ссылки
Благодарности
Выражаю огромную благодарность за помощь в подготовке статьи моим коллегам:
Николаю Марину
Игорю Хапову
Дмитрию Горбачеву
Александру Земцову
Екатерине Курденковой
Екатерине Гусевой
Вступление¶
В общих чертах, блокчейн это неизменяемый транзакционный реестр (immutable transaction ledger), поддерживаемый распределенной сетью узлов (пиров, peers, nodes). Каждый из этих узлов поддерживает копию блокчейна, применяя транзакции, подтвержденные протоколом консенсуса и сгруппированные в блоки, включающие в себя хэш, связывающий каждый новый блок с предыдущим.
По мере роста популярности Bitcoin, Ethereum и других, производных от них технологий, растет и интерес к применению технологии блокчейна, распределенного реестра и распределенных платформ для более инновационного промышленного использования. Однако для многих кейсов требуется применение характеристик, которыми permissionless-технологии на данный момент не обладают. Также во многих случаях личность участников имеет большое значение, как, например, в случае финансовых транзакций, где соблюдаются принципы Know-Your-Customer (KYC) и Anti-Money-Laundering (AML).
Для промышленного использования нужно учитывать следующие требования:
В отличие от многих блокчейн-платформ, которые сейчас подстраиваются на ходу под использование в индустрии, Hyperledger Fabric был с самого начала создан для промышленной эксплуатации. Последующие разделы описывают, чем Hyperledger Fabric отличается от других блокчейн платформ, и обосновывают некоторые архитектурные решения.
Hyperledger Fabric¶
Fabric имеет крайне модульную и конфигурабельную архитектуру, предоставляя пространство для инноваций и оптимизаций для большого набора юзкейсов, в том числе для банкинга, финансов, страхования, здравоохранения, HR, логистики и даже цифровой доставки музыки.
Fabric может использовать протоколы консенсуса, которые не требуют встроенной криптовалюты для того, чтобы обеспечивать ей работу ресурсоемкого майнинга или исполнения смартконтрактов на топливе. Отказ от криптовалюты убирает некоторые важные векторы атак и рисков, а отсутствие криптографических операций по майнингу означает, что платформа может быть развернута примерно с такими же операционными затратами, что и любая другая распределенная система.
Совокупность этих отличительных черт делает Fabric одной из лучших действующих платформ по скорости обработки и подтверждения транзакций, также она предоставляет приватность и конфиденциальность транзакций и смартконтрактов (в Fabric “chaincode”).
Давайте более детально рассмотрим эти отличительные черты.
Модульность¶
Fabric состоит из следующих модульных компонентов:
Permissioned vs Permissionless¶
В permissionless-блокчейне участвовать может практически каждый, и каждый участник анонимен. В таком случае не может быть никакого доверия кроме того, который следует из неизменяемости состояния блокчейна. Чтобы восполнить это отсутствие доверия, permissionless-блокчейны вводят встроенную криптовалюту, которую можно майнить, или плату за транзакции, чтобы создать экономический BFT консенус на основе “Proof of Work” (PoW).
С другой стороны, permissioned-блокчейны оперируют блокчейном среди набора известных, идентифицируемых и зачастую проверенных участников, работающих под моделью управления с каким-то уровнем доверия. Permissioned-блокчейны позволяют обезопасить взаимодействия между группой сущностей, преследующих общую цель, но не доверяющих друг другу полностью. Полагаясь на учетные записи участников, permissioned-блокчейн может использовать более традиционные CFT или BFT консенсус-протоколы, которые не нуждаются в ресурсоемком майнинге.
В дополнение к этому, в такой permissioned-модели риск того, что участник умышленно введет вредоносный код через смартконтракт исчезает. Участники знают друг друга и все действия записываются, будь это отправление транзакции, модификация конфигурации сети или развертывание смартконтракта, при этом действия проходят проверку согласно политикам подтверждения, установленным в сети для конкретного типа транзакции. Вместо того, чтобы быть полностью анонимным, виновный участник может быть легко опознан, а инцидент обработан согласно протоколу управляющей модели.
Смартконтракты¶
Существует три ключевых пункта, относящихся к смартконтрактам, особенно существующим на платформе:
Большинство существующих платформ, поддерживающих смарт контракты, следуют архитектуре order-execure (упорядочить-выполнить), в которой консенсус-протокол: валидирует и упорядочивает, а потом распространяет их по всем узлам, каждый узел потом исполняет транзакции в заданном порядке.
Архитектура order-execute может быть обнаружена в практически всех существующих блокчейн-системах, от public permissionless-платформ как Ethereum с PoW консенсусом, до permissioned платформ как Tendermint, Chain, и Quorum.
смартконтракты выполняемые в блокчейне, который действует под архитектурой order-execute должны быть детерминированными, иначе к консенсусу можно никогда так и не прийти.
Чтобы справиться с этой проблемой, многие платформы требуют, чтобы смартконтракты были написаны на нестандартном языке или DSL (как в случае Solidity), чтобы не допустить недетерминированных операций. Такой подход мешает широкому распространению среди разработчиков, так как им требуется выучить новый язык. Также такой подход может привести к многочисленным ошибкам в коде.
Так как все транзакции выполняются последовательно всеми узлами, производительность и масштабируемость ограничены. Факт того, что смартконтракт исполняется на каждом узле требует принятия комплексных мер по обеспечению безопасности всей системы от потенциально вредоносных контрактов.
Новый подход¶
Fabric представляет новую архитектуру для транзакций, которую мы называем execute-order-validate (выполнить-упорядочить-валидировать). Она решает проблемы гибкости, масштабируемости, производительности и конфиденциальности, присутствующие в архитектуре order-execute, разбивая транзакционный поток на три шага:
Такой дизайн радикально отличается от парадигмы order-execute в том, что Fabric выполняет транзакции до определения их конечного порядка.
В Fabric, определенная для каждого типа транзакций политика подтверждения указывает на то, какие узлы и в каком количестве должны поручиться за корректность выполнения определенного смартконтракта. Так, каждая транзакция должна быть выполнена (подтверждена) только на подмножестве узлов, чтобы удовлетворить политике подтверждения. Это позволяет использовать параллельное выполнение, увеличивая общую производительность системы. Эта фаза также убирает весь недетерминизм, так как противоречивые результаты будут отфильтрованы перед ordering’ом.
Приватность и конфиденциальность¶
Как мы уже обсудили, в public permissionless-блокчейнах сети, использующей PoW, транзакции выполняются на каждом узле. Это означает, что невозможна конфиденциальность ни самих контрактов, ни транзакционных данных, которыми они оперируют. Каждая транзакция и код, который ее осуществляет, видны каждому узлу в сети. В этом случае, мы принесли конфиденциальность контрактов и данных на BFT-консенсус, обеспечиваемый PoW.
Как второй пример рассмотрим индустрию ценных бумаг, где продавец, составляющий предложение (или отказывающийся от него) не захочет, чтобы его соперники видели это, иначе они будут стремиться войти в игру, ослабляя гамбит трейдера.
Чтобы решить эту проблему отсутствия конфиденциальности и приватности ради цели достижения требований промышленных юзкейсов, блокчейн платформы пришли к нескольким решениям. Все имеют свои минусы.
В permissioned-модели, в которой возможны альтернативные формы консенсуса, можно обнаружить подходы, которые ограничивают распространение конфиденциальной информации только к авторизованным узлам.
Hyperledger Fabric, будучи permissioned-платформой, предоставляет конфиденциальность через архитектуру каналов (channels) и механизм приватных данных (private data). В каналах, определенные участники Fabric-сети создают подсеть, где каждый участник видит только определенный набор транзакций. Так, только узлы, участвующие в канале, имеют доступ к смартконтрактам (chaincode) и передаваемым данным, сохраняя приватность и конфиденциальность обоих. Приватные данные предоставляют возможность создания коллекций между участниками канала, гарантируя примерно ту же защиту, что и каналы, но без необходимости в создании и поддержке отдельной подсети.
Сменный консенсус¶
Ordering транзакций передан модульному компоненту, чтобы консенсус был логически отделен от пиров, выполняющих транзакции и поддерживающих реестр. Ordering передан компоненту под названием ordering service (ordering-служба). Так как консенсус модульный, он может быть реализован с определенным знанием доверия в конкретной системе. Такая архитектура позволяет платформе использовать хорошо отработанные инструменты для CFT- или BFT-ordering’а.
В текущем состоянии Fabric предоставляет реализацию CFT ordering-службы, базирующуюся на библиотеке etcd протокола Raft. Для информации о доступных на данный момент ordering-службах, смотрите документацию по ordering’у.
Заметьте, что такие службы не являются взаимно-исключающими. Сеть Fabric может иметь несколько ordering-служб, чтобы удовлетворить возможным требованиям приложений.
Производительность и масштабирование¶
Производительность блокчейн-платформ может зависеть от множества факторов: размера транзакции, размера блока, размера сети, от ограничения оборудования, и т.д. Группа по работе над производительностью и масштабированием работает над banchmarking-инструментом Hyperledger Caliper.
Существуют исследовательские публикации, изучающие и тестирующие производительность Hyperledger Fabric. Последняя такая статья: scaled Fabric to 20,000 transactions per second.
Заключение¶
Уникальный набор возможностей Hyperledger Fabric делает ее крайне масштабируемой системой для permissioned-блокчейнов, поддерживающей гибкие формы доверия, которые делают платформу пригодной для широкого спектра промышленных сценариев, начиная государственными службами и кончая финансами, логистикой, здравоохранением и еще многим другим.
Благодарности¶
© Copyright Hyperledger 2020.
Использование kubernetes для разработки блокчейн проектов на Hyperledger Fabric
Добрый день, дорогие хабровчане.
Я являюсь разработчиком научно-технического центра IBM в Москве. Мы ведем разработку продуктов IBM совместно с другими лабораториями по всему миру. Если позволяет время и есть желание, то у нас разрешено использовать часть рабочего времени на проекты, которые не являются основной занятостью. Такой подход расширяет кругозор и поддерживает творческий настрой. Для меня такой областью является разработка блокчейн-решений на Hyperledger Fabric. Тем более, что такие проекты стали востребованы на нашем рынке.
Надеюсь, что статья будет не о блокчейне, а о том, что мы используем для разработки таких решений, но тем не менее стоит все-таки начать с предметной области.
Статья не претендует на полноту и нацелена на создание рабочего облачного окружения для разработки блокчейн-проектов на Hyperledger Composer. В результате наших практических изысканий мы должны получить следующую инфраструктуру:
Немного о Hyperledger Fabric
Существует большое количество блокчейн-платформ, которые можно сравнивать до бесконечности. Скорее всего универсальной платформы не существует, есть выбранная для текущей задачи. Для себя из блокчейн-платформ я выбрал Hyperledger Fabric. С одной стороны потому, что платформа интересна мне с технической точки зрения, с другой — IBM активно участвует в консорциуме Hyperledger.
Hyperledger — это консорциум в рамках проекта Linux Foundation. Hyperledger Fabric (HLF) — реализация технологии блокчейн для построения различных решений. Она является блокчейн-платформой с контролируемым доступом (permissioned). Это означает, что добавление новых участников контролируется. Участники определяются на этапе проектирования сети и могут иметь различные роли. Наиболее понятными сценариями для таких сетей являются цепочки поставок, в которых участвует множество независимых компаний. Для примера можно изучить опыт Walmart, JD.com, IBM и Tsinghua University в организации цепочки поставок продуктов питания.
С технической точки зрения каждый участник имеет развернутый участок сети у себя в организации (или в облачной инфраструктуре), но не имеет доступа к участкам сети, развернутым в других компаниях.
Как видно из схемы — каждый участник имеет:
В приложении пользователи авторизуются с помощью своих ключей или связки логин и пароль и получают доступ к смарт-контракту.
Смарт-контракт – это запрограммированная бизнес-логика и правила взаимодействия с данными, которые размещены в распределенном реестре (ledger). Реестр содержит цепочку блоков транзакций, которые совершили участники сети. Каждый последующий блок хранит хэш предыдущего блока, за счет чего обеспечивается невозможность изменения части информации. Процесс согласования корректности блока и добавления его в распределенный реестр называется консенсусом. Различные блокчейн-платформы имеют различные механизмы консенсуса: proof of work (PoW), proof of stake (PoS), byzantine fault tolerance (BFT) и прочие.
Начиная с версии 1.0 HLF специфична наличием Ordering Service, который является распределенным между участниками кластером и отвечает за очередность транзакций в формирующемся блоке. По сконфигурированным параметрам он собирает транзакции в сети и формирует блок. В случае отказа Ordering Service транзакции в сети перестанут регистрироваться, но сами данные останутся неизменными.
Теперь, разобравшись с основными понятиями, мы можем переходить к практике.
Как развернуть свою собственную HLF сеть
Все компоненты HLF работают в Docker-контейнерах и могут быть развернуты как с помощью Docker Compose, так и с помощью Kubernetes. Кроме того, сами смарт-контракты тоже запускаются в Docker-контейнерах.
Для того, чтобы развернуть HLF можно использовать уже существующую kubernetes-сеть, minikube или воспользоваться одним из облачных Kubernetes as a Service.
В облачной инфраструктуре IBM можно развернуть свою kubernetes-сеть бесплатно.
Как развернуть kubernetes сеть в IBM Cloud.
Для того, чтобы начать пользоваться IBM Cloud необходимо:
После регистрации в IBM Cloud вы получите доступ в графический интерфейс управления вашей инфраструктурой. Вам будут доступны сотни сервисов и десятки подходов для размещения ваших приложений (Cloud Foundry, Kubernetes, OpenWhisk, виртуальные машины и выделенные сервера). Для использования виртуальных машин и выделенных серверов необходимо добавить кредитную карту, а вот небольшой кусочек kubernetes можно получить бесплатно (с купоном выше).
Для этого необходимо в левом верхнем углу нажать на кнопку меню и выбрать Containers.
Перед вами откроется панель управления кластерами kubernetes, Docker registry и helm-чартами.
Выбрав слева в меню пункт Cluster, вы увидите интерфейс создания кластера kubernetes и выбор региона, в котором кластер будет развернут. Вы можете создать бесплатный кластер в каждом регионе.
После нажатия кнопки Create cluster следует выбрать тип кластера Free и придумать ему название.
Создание кластера займет некоторое время, которое вы можете потратить на переход в консоль (заварить кофе вы не успеете). Установив IBM Cloud CLI (bx tool) вам необходимо сконфигурировать его для работы с вашим аккаунтом:
Теперь вы готовы к тому, чтобы начать использовать ваш kubernetes-кластер для любых целей. Кластер является бесплатным, и в его функционале есть некоторые ограничения, которые нам не помешают развернуть свою блокчейн-сеть:
Для тех, кто первый раз использует kubernetes, возможно, стоит поэкспериментировать с разворачиванием первых Deployment и сервисов. Те, кто уже готов окунутся в мир разработки блокчейн-проектов, могут переходить к следующим шагам.
Разворачиваем контейнеры HLF в kubernetes
Для тех, кто не так давно работает с Docker и Kubernetes напомню, что для разворачивания любого приложения в kubernetes нам необходимы 2 вещи:
Open Source сообщество разработчиков Hypeledger Fabric сделало за нас эту работу. Docker Images с HLF уже лежат на DockerHub и автоматически загрузятся в наш кластер. А вся yaml-конфигурация находится в github репозитории. На момент написания статьи репозиторий содержит конфигурацию для Hyperledger Fabric 1.0.3. Возвращаемся в консоль и выполняем следующие команды:
Что такое Hyperledger Composer
Composer является инструментом для разработчиков блокчейн-решений. С его помощью можно повысить скорость разработки блокчейн-решений с месяцев до недель. Существует онлайн-песочница Composer Playground, но вся бизнес-логика, спроектированная в ней, будет запускаться у вас в браузере (эмуляция блокчейн). В нашем случае Composer будет подключен к работающей сети Hyperledger Fabric, развернутой в kubernetes.
Для создания модели в Hyperledger Composer необходимо описать участников (participant), активов (asset) и транзакций (transaction). Данный подход позволяет перевести разработку блокчейн-проекта в термины вашей задачи, а не выбранной платформы или используемого инструмента. Код транзакций (бизнес-логика) пишется на JavaScript, и при запуске нового смарт-контракта не создается новый Docker-контейнер, а код транзакции передается на интерпретацию в существующий контейнер.
Еще одним достоинством Hyperledger Composer является автоматическое создание REST-интерфейсов на основе описанных активов и транзакций, что позволяет вам сразу начинать писать пользовательский интерфейс (и соответственно получить MVP ).
Запуск первого блокчейн проекта
После запуска Hyperledger Composer в IBM Cloud вы сможете зайти в его веб интерфейс по адресу
:31080. По умолчанию все необходимые контейнеры Docker проброшены на публичный доступ по технологии NodePort (мы же не забываем, что разворачиваем окружение для разработчика).
Composer подключен к github-проету, и вы можете развернуть один из существующих проектов или начать разрабатывать свой.
В результате мы получили бесплатное облачное окружение для разработки проектов на базе Hyperledger Fabric.
Как и в любом технически непростом проекте всегда есть много деталей и дополнительных вещей. Данная статья является ознакомительной и призвана помочь в самом начале изучения. Надеюсь, что время и силы позволят мне написать несколько статей с более детальной информацией как по kubernetes в IBM Cloud, так и про разработку для Hyperledger Fabric.
