Организация блокчейн на VMware vSphere: от теории к практике

Организация блокчейн на VMware vSphere: от теории к практике

Blockchain — это принципиально новая технология, которая в последнее время приковывает к себе все больше внимания. Специалисты из таких отраслей, как финансы, экономика, медицина, логистика, IoT, активно работают над исследовательскими и экспериментальными проектами с использованием блокчейн, поскольку эта технология заточена не только на криптовалюты.

Blockchain на vSphere или BoV — это инструмент для развертывания Hyperledger Fabric v1.0 на платформе vSphere, или, другими словами, проект VMware, который помогает администраторам развернуть блокчейн-платформу для разработчиков на базе гипервизора ESXi. Используя всего несколько команд, можно с легкостью запустить кластер на vSphere, а блокчейн-разработчикам сосредоточиться на реализации бизнес-логики.

Отметим, что Hyperledger Fabric — это не компания, не криптовалюта, а проект с открытым исходным кодом, организованный сообществом Linux Foundation, который был создан для продвижения блокчейн-технологии. Это нечто, похожее на хаб для открытой разработки отраслевых блокчейнов. Hyperledger Fabric дает широкие возможности, позволяя разработчикам сконцентрироваться на запуске блокчейн-проекта с собственной бизнес-логикой.

Взгляд изнутри

Суть утилиты Blockchain on vSphere заключается в возможности развернуть несколько узлов кластера Hyperledger Fabric, так называемых Pods, причем максимально просто. При этом в Blockchain-сервисе используются три учетные записи:

  • Cloud Admin,
  • Blockchain Admin,
  • Blockchain Developer.

Каждая из них имеет соответствующие полномочия на разных уровнях системы: Cloud Admin может мониторить и работать с инфраструктурой на базе vSphere, Blockchain Admin — управлять платформой blockchain (Hyperledger Fabric), а разработчик Blockchain фокусируется на разработке приложений с использованием платформы blockchain.

Градация полномочий на разных уровнях системы

Градация полномочий на разных уровнях системы

Hyperledger Fabric — это распределенная система, реализованная с использованием контейнеров. Она может быть развернута на платформе, которая поддерживает контейнерный стандарт OCI. При этом для управления контейнерами Fabric используется система Kubernetes. В основе рассматриваемого примера для Fabric v1.0 лежит следующая архитектура:

  • Используются пространства имен для поддержки различных организаций Fabric.
  • Используется настраиваемое количество одноранговых узлов в организации.
  • Организуется изоляция через Persistent Volume.

Архитектура решения

Архитектура решения

Инструкция по развертыванию

Для реализации блокчейн-проекта с использованием Hyperledger Fabric необходимо выполнить ряд предварительных требований, включающих наличие:

  • vCenter 6.0+ как минимум с одним хостом ESXi;
  • сервера NFS для хранения конфигурационных файлов кластера Fabric;
  • интернет-подключения, которое потребуется в ходе установки;
  • хоста Linux с Docker 1.11+ установленным для запуска команд;
  • 5, установленный на хост Linux (с модулем PyYAML).

После того как выполнена загрузка пакета BoV, можно приступать к установке Fabric 1.0 на vSphere. Начнем с vCenter, где потребуется выполнить следующие шаги:

  • Создать пул ресурсов для Kubernetes, например kub-pool.
  • Выбрать хранилище данных, используемое Kubernetes, например datastore1.
  • Выбрать сеть для узлов Kubernetes, причем в сети должен быть развернут сервис DHCP, обеспечивающий динамическую IP-адресацию с возможностью выхода в Интернет.

Развертывание Kubernetes

Выполним развертывание Kubernetes, используя проект с открытым исходным кодом Kubernetes Anywhere (https://github.com/kubernetes/kubernetes-anywhere). Для этого:

  • Загружаем OVA-шаблон и импортируем в vCenter. Таким образом получаем шаблон виртуальной машины с именем KubernetesAnywhereTemplatePhotonOS. Более подробную информацию об импорте OVA можно получить по ссылке: https://github.com/kubernetes/kubernetesanywhere/blob/master/phase1/vsphere/README.md

Шаблон ВМ

Шаблон ВМ

  • На Linux-хосте запускаем развертывание контейнера Kubernetes Anywhere:

Развертывание Kubernetes 1

  • Внутри контейнера запускаем развертывание Kubernetes:

Развертывание Kubernetes - 2

  • После задаем параметры согласно подсказкам. Ниже указаны возможные варианты:

Развертывание Kubernetes - 3

Развертывание Kubernetes - 4

Развертывание Kubernetes - 5

Теперь необходимо дождаться момента, когда будет создан кластер Kubernetes. Для проверки состояния используйте следующую команду:

Развертывание Kubernetes - 5

Как видно на рисунке, сервисы находятся в запущенном состоянии. Далее копируем содержимое файла phase1 / vsphere /.tmp / kubeconfig.json на Linux-машину, сохраняя содержимое в каталоге ~ /.kube / config. При отсутствии каталога на Linux-машине его необходимо создать:

Развертывание Kubernetes - 6

Выходим из контейнера и возвращаемся к хосту Linux, запустив на нем следующую команду:

Развертывание Kubernetes - 8

Команда снова выведет информацию о кластере. Далее настраиваем DNS, используемый Docker-ом на всех рабочих узлах Kubernetes. Дело в том, что Fabric создает контейнер Docker для запуска цепочки кода, который находится вне зоны контроля Kubernetes. Поэтому демону Docker необходимо использовать корректную DNS-информацию в сети Kubernetes. В связи с этим вносим изменения на узлах Kubernetes. В нашем примере это узлы node1, node2, node3 и node4.

Первым делом редактируем файл /etc/default/docker:

Развертывание Kubernetes - 9

Обратите внимание, что используемые здесь IP-адреса рассматриваются в качестве примера, в случае продакшен-конфигурации их необходимо заменить на действительные. Если дополнительно используется Proxy-сервер, информацию о нем следует отразить в файле /etc/default/docker:

Развертывание Kubernetes - 10

Чтобы внесенные изменения вступили в силу, перезапустите службу Docker:

Развертывание Kubernetes - 11

Следующий шаг — развертывание блокчейн-платформы (Fabric)

Здесь потребуется настроить службу NFS, экспортировать общий каталог (в нашем примере — /opt/share) и проверить настройки на NFS-сервере с тестовым IP-адресом 10.112.122.9. Для этого выполняются следующие шаги:

Развертывание Kubernetes - 12Развертывание Kubernetes - 13

Обратите внимание, что клиент NFS должен иметь доступ для чтения/записи к каталогу /opt/share. Если же используется анонимный доступ, в таком случае не требуется владелец и в свойствах группы папок следует использовать элемент nogroup. В противном случае можно столкнуться с ошибкой в разрешениях. Поэтому стоит запустить следующую команду на узле NFS:

Развертывание Kubernetes - 14

Далее монтируем каталог к Linux-хосту:

Развертывание Kubernetes - 15

Загружаем файл пакета BoV BaaS.tar, извлекаем файлы и меняем текущий каталог на ./baas. После чего запускаем команду для загрузки инструментов, требуемых Fabric. При этом cryptogen и configtxgen должны быть сохранены в каталоге./bin.

Развертывание Kubernetes - 16

Затем в каталоге setupCluster/templates/ обновляем два файла шаблонов, внося изменения в параметры NFS-сервера.

Файл
fabric_1_0_template_pod_cli.yaml
Файл
fabric_1_0_template_pod_namespace.yaml
Развертывание Kubernetes - 17 Развертывание Kubernetes - 18

Примечательно, что файл setupCluster/cluster-config.yaml содержит определение топологии службы blockchain, которую необходимо изменить. Ниже приведен возможный вариант:

Файл setupCluster/cluster-config.yaml

Файл setupCluster/cluster-config.yaml

Теперь необходимо изменить каталог на baas/setupCluster и запустить скрипт generateAll.sh, чтобы создать все файлы конфигурации Fabric и файлы определения файлов Kubernetes для службы blockchain.

Развертывание Kubernetes - 17

Изменяем каталог на baas/setupCluster/transform и запускаем команду для развертывания Fabric как контейнер на Kubernetes:

Развертывание Kubernetes - 18

Проверяем созданную блокчейн-группу:

Развертывание Kubernetes - 19

Аналогичную проверку можно выполнить через пользовательский интерфейс панели Kubernetes:

Пользовательский интерфейс панели Kubernetes

Пользовательский интерфейс панели Kubernetes

Дальше выполняем проверку окружения путем запуска примерной цепочки кода и меняем working path на baas/setupCluster/:

Развертывание Kubernetes - 20

Создаем mychannel, используя configtxgen:

Развертывание Kubernetes - 21

Создаем транзакцию конфигурации для обновления peer0.org1 как якорный одноранговый канал mychannel, аналогичное выполняем и для peer0.org2.

Развертывание Kubernetes - 22

Копируем каталог ./channel-artifacts в /opt/share/: Развертывание Kubernetes - 23

Загружаем пример сетевого кода из проекта Hyperledger Fabric, затем копируем каталог chaincode_example02 в /opt/share/channel-aritfacts/. В приведенных ниже командах сначала создается канал, затем соединяется с peer0 Org1. Далее устанавливается и создается код цепи с двумя парами ключ/значение: a = 100 и b = 200. После чего peer0 Org2 добавляется к каналу и устанавливается «цепочный» код. Затем создается транзакция для передачи значения 10 от a до b. Запрашивается значение a, которое должно отображаться как 90. Команда для Org1:

Развертывание Kubernetes - 24

Как показано на рисунке, cli org1 был назван cli-1569835662–01c5z. Запускаем команду cli org1:

Развертывание Kubernetes - 25

И в cli pod создаем канал с именем mychannel:

Развертывание Kubernetes - 26

После создания канала возвращается файл mychannel.block из orderer. Он будет использоваться для присоединения к каналу. На рисунке ниже показан вывод команды создания канала:

Развертывание Kubernetes - 27

Теперь копируем mychannel.block в общую папку NFS, чтобы другой cli мог ее использовать:

Развертывание Kubernetes - 28

В результате должны получить следующее:

Развертывание Kubernetes - 29

Обновляем peer0 Org1 в качестве якорной точки mychannel:

Развертывание Kubernetes - 30

Устанавливаем chaincode mycc на peer0:

Развертывание Kubernetes - 31

Результат ниже говорит о том, что цепочный код был успешно установлен:

Развертывание Kubernetes - 32

Создаем chaincode mycc:

Развертывание Kubernetes - 33

Итак, контейнер цепи создан. Однако он не управляется Kubenetes из-за дизайна Fabric. В приведенной выше команде используется pee0.org1 (который назначается узлу 3) для создания цепи. Контейнер цепного кода можно найти, запустив «docker ps» в узле 3, как показано на рисунке:

Развертывание Kubernetes - 34

Запрашиваем chaincode:

Развертывание Kubernetes - 35

Проверяем состояние chaincode, где значение «a» должно быть равно 100 в качестве определенного экземпляра:

Развертывание Kubernetes - 36

Аналогичное используем в Org2:

Развертывание Kubernetes - 37

Как показано на рисунке, cli org2 был назван cli-2586364563-vclmr. Вводим команду cli org2 для командной строки Fabric:

Развертывание Kubernetes - 38

В cli pod org2 Peer0 org2 соединяет канал:

Развертывание Kubernetes - 39

Обновляем Peer0 org2 как привязку:

Развертывание Kubernetes - 40

Устанавливаем chaincode:

Развертывание Kubernetes - 41

Запрашиваем chaincode:

Развертывание Kubernetes - 42

Так как экземпляр chaincode mycc был создан, эта команда возвращает значение «a», равное 100:

Развертывание Kubernetes - 43

Вызываем цепочный код для обновления регистратора канала. Это создает транзакцию для передачи значения 10 от a до b:

Развертывание Kubernetes - 44

При этом Query Result снова должен быть равен 90:

Развертывание Kubernetes - 45

Заключение

В этой статье мы познакомили вас с утилитой Blockchain on vSphere, позволяющей администраторам разворачивать блокчейн-платформу на базе гипервизора ESXi. А также в деталях рассмотрели процесс развертывания Hyperledger Fabric с помощью BoV. Следите за новыми материалами первого блога о корпоративном IaaS, в них мы продолжим знакомить вас с актуальными и востребованными решениями из мира блокчейн и облачных технологий.

С оригиналом текста можно ознакомиться на сайте VMware


1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (5 оценок, среднее: 5,00 из 5)
Загрузка...