Отметим, что Hyperledger Fabric — это не компания, не криптовалюта, а проект с открытым исходным кодом, организованный сообществом Linux Foundation, который был создан для продвижения блокчейн-технологии. Это нечто, похожее на хаб для открытой разработки отраслевых блокчейнов. Hyperledger Fabric дает широкие возможности, позволяя разработчикам сконцентрироваться на запуске блокчейн-проекта с собственной бизнес-логикой.
Взгляд изнутри
Суть утилиты Blockchain on vSphere заключается в возможности развернуть несколько узлов кластера Hyperledger Fabric, так называемых Pods, причем максимально просто. При этом в Blockchain-сервисе используются три учетные записи:
Каждая из них имеет соответствующие полномочия на разных уровнях системы: Cloud Admin может мониторить и работать с инфраструктурой на базе vSphere, Blockchain Admin — управлять платформой blockchain (Hyperledger Fabric), а разработчик Blockchain фокусируется на разработке приложений с использованием платформы blockchain.
Градация полномочий на разных уровнях системы
Hyperledger Fabric — это распределенная система, реализованная с использованием контейнеров. Она может быть развернута на платформе, которая поддерживает контейнерный стандарт OCI. При этом для управления контейнерами Fabric используется система Kubernetes. В основе рассматриваемого примера для Fabric v1.0 лежит следующая архитектура:
Архитектура решения
Инструкция по развертыванию
Для реализации блокчейн-проекта с использованием Hyperledger Fabric необходимо выполнить ряд предварительных требований, включающих наличие:
После того как выполнена загрузка пакета BoV, можно приступать к установке Fabric 1.0 на vSphere. Начнем с vCenter, где потребуется выполнить следующие шаги:
Развертывание Kubernetes
Выполним развертывание Kubernetes, используя проект с открытым исходным кодом Kubernetes Anywhere (https://github.com/kubernetes/kubernetes-anywhere). Для этого:
Шаблон ВМ
Теперь необходимо дождаться момента, когда будет создан кластер Kubernetes. Для проверки состояния используйте следующую команду:
Как видно на рисунке, сервисы находятся в запущенном состоянии. Далее копируем содержимое файла phase1 / vsphere /.tmp / kubeconfig.json на Linux-машину, сохраняя содержимое в каталоге ~ /.kube / config. При отсутствии каталога на Linux-машине его необходимо создать:
Выходим из контейнера и возвращаемся к хосту Linux, запустив на нем следующую команду:
Команда снова выведет информацию о кластере. Далее настраиваем DNS, используемый Docker-ом на всех рабочих узлах Kubernetes. Дело в том, что Fabric создает контейнер Docker для запуска цепочки кода, который находится вне зоны контроля Kubernetes. Поэтому демону Docker необходимо использовать корректную DNS-информацию в сети Kubernetes. В связи с этим вносим изменения на узлах Kubernetes. В нашем примере это узлы node1, node2, node3 и node4.
Первым делом редактируем файл /etc/default/docker:
Обратите внимание, что используемые здесь IP-адреса рассматриваются в качестве примера, в случае продакшен-конфигурации их необходимо заменить на действительные. Если дополнительно используется Proxy-сервер, информацию о нем следует отразить в файле /etc/default/docker:
Чтобы внесенные изменения вступили в силу, перезапустите службу Docker:
Следующий шаг — развертывание блокчейн-платформы (Fabric)
Здесь потребуется настроить службу NFS, экспортировать общий каталог (в нашем примере — /opt/share) и проверить настройки на NFS-сервере с тестовым IP-адресом 10.112.122.9. Для этого выполняются следующие шаги:
Обратите внимание, что клиент NFS должен иметь доступ для чтения/записи к каталогу /opt/share. Если же используется анонимный доступ, в таком случае не требуется владелец и в свойствах группы папок следует использовать элемент nogroup. В противном случае можно столкнуться с ошибкой в разрешениях. Поэтому стоит запустить следующую команду на узле NFS:
Далее монтируем каталог к Linux-хосту:
Загружаем файл пакета BoV BaaS.tar, извлекаем файлы и меняем текущий каталог на ./baas. После чего запускаем команду для загрузки инструментов, требуемых Fabric. При этом cryptogen и configtxgen должны быть сохранены в каталоге./bin.
Затем в каталоге setupCluster/templates/ обновляем два файла шаблонов, внося изменения в параметры NFS-сервера.
Примечательно, что файл setupCluster/cluster-config.yaml содержит определение топологии службы blockchain, которую необходимо изменить. Ниже приведен возможный вариант:
Файл setupCluster/cluster-config.yaml
Теперь необходимо изменить каталог на baas/setupCluster и запустить скрипт generateAll.sh, чтобы создать все файлы конфигурации Fabric и файлы определения файлов Kubernetes для службы blockchain.
Изменяем каталог на baas/setupCluster/transform и запускаем команду для развертывания Fabric как контейнер на Kubernetes:
Проверяем созданную блокчейн-группу:
Аналогичную проверку можно выполнить через пользовательский интерфейс панели Kubernetes:
Пользовательский интерфейс панели Kubernetes
Дальше выполняем проверку окружения путем запуска примерной цепочки кода и меняем working path на baas/setupCluster/:
Создаем mychannel, используя configtxgen:
Создаем транзакцию конфигурации для обновления peer0.org1 как якорный одноранговый канал mychannel, аналогичное выполняем и для peer0.org2.
Копируем каталог ./channel-artifacts в /opt/share/:
Загружаем пример сетевого кода из проекта Hyperledger Fabric, затем копируем каталог chaincode_example02 в /opt/share/channel-aritfacts/. В приведенных ниже командах сначала создается канал, затем соединяется с peer0 Org1. Далее устанавливается и создается код цепи с двумя парами ключ/значение: a = 100 и b = 200. После чего peer0 Org2 добавляется к каналу и устанавливается «цепочный» код. Затем создается транзакция для передачи значения 10 от a до b. Запрашивается значение a, которое должно отображаться как 90. Команда для Org1:
Как показано на рисунке, cli org1 был назван cli-1569835662–01c5z. Запускаем команду cli org1:
И в cli pod создаем канал с именем mychannel:
После создания канала возвращается файл mychannel.block из orderer. Он будет использоваться для присоединения к каналу. На рисунке ниже показан вывод команды создания канала:
Теперь копируем mychannel.block в общую папку NFS, чтобы другой cli мог ее использовать:
В результате должны получить следующее:
Обновляем peer0 Org1 в качестве якорной точки mychannel:
Устанавливаем chaincode mycc на peer0:
Результат ниже говорит о том, что цепочный код был успешно установлен:
Создаем chaincode mycc:
Итак, контейнер цепи создан. Однако он не управляется Kubenetes из-за дизайна Fabric. В приведенной выше команде используется pee0.org1 (который назначается узлу 3) для создания цепи. Контейнер цепного кода можно найти, запустив «docker ps» в узле 3, как показано на рисунке:
Запрашиваем chaincode:
Проверяем состояние chaincode, где значение «a» должно быть равно 100 в качестве определенного экземпляра:
Аналогичное используем в Org2:
Как показано на рисунке, cli org2 был назван cli-2586364563-vclmr. Вводим команду cli org2 для командной строки Fabric:
В cli pod org2 Peer0 org2 соединяет канал:
Обновляем Peer0 org2 как привязку:
Устанавливаем chaincode:
Запрашиваем chaincode:
Так как экземпляр chaincode mycc был создан, эта команда возвращает значение «a», равное 100:
Вызываем цепочный код для обновления регистратора канала. Это создает транзакцию для передачи значения 10 от a до b:
При этом Query Result снова должен быть равен 90:
Заключение
В этой статье мы познакомили вас с утилитой Blockchain on vSphere, позволяющей администраторам разворачивать блокчейн-платформу на базе гипервизора ESXi. А также в деталях рассмотрели процесс развертывания Hyperledger Fabric с помощью BoV. Следите за новыми материалами первого блога о корпоративном IaaS, в них мы продолжим знакомить вас с актуальными и востребованными решениями из мира блокчейн и облачных технологий.
С оригиналом текста можно ознакомиться на сайте VMware
