Понимание внутреннего устройства Docker контейнера в Hyperledger Fabric

Question

Я думаю, чтобы понять, как в основном работает fabri c и как достигается консенсус. То, что мне до сих пор не хватает в документации, - это часть того, что происходит внутри docker контейнера fabri c, чтобы принять участие в процессе коммуникации.

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

Но что происходит внутри контейнеров?

Я представляю себе это как процесс, который получает только gRP C сообщение и ответ на них с использованием функций в фоновом режиме однорангового узла / заказчика, чтобы передать свой ответ для дальнейшей обработки в другом устройстве, таком как клиент, чтобы собрать ответы нескольких одноранговых узлов для смарт-контракта.

Но что на самом деле происходит внутри контейнера? Я имею в виду, контейнер появляется, когда файл изображения docker загружается и запускается конфигурационным файлом yaml. Но что там запускается внутри него (запущен ли только один бинарный одноранговый узел, например, как команда «запуск однорангового узла») - я имею в виду только скомпилированный двоичный файл go «одноранговый узел» ?? Что слушает? Что там отвечает? Я обнаружил только один порт для каждого открытого контейнера. Мне кажется, что это ворота для gRP C (потому что он часто используется как идентификатор порта: ** 51).

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

Answer 1

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

Если CC установлен : узел проверяет, запущен ли уже выделенный контейнер для данная CC и соответствующая версия. Если контейнер запущен , одноранговый узел отправляет запрос транзакции этому экземпляру CC и возвращает ответ вашему клиенту после подписания транзакции. Подписание гарантирует, что ответ действительно отправлен этим партнером.

Если контейнер не запущен: Создается изображение docker и запускается этот экземпляр (docker контейнер). Новое изображение будет основано на одном из изображений гиперссылки. т.е. если ваш CC равен GO, тогда будет использоваться hyperledger/baseos, что очень просто c linux os. Это новое изображение содержит CC двоичные данные и МЕТА-ДАННЫЕ.

Этот одноранговый экземпляр использует сервер docker базовой (вашей) машины для выполнения всех этих операций. Вот почему нам нужно передать /var/run:/host/var/run в сопоставление томов и CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock в переменные среды.

После запуска контейнера CC он подключается к своему родительскому одноранговому узлу, который определяется с помощью CORE_PEER_CHAINCODEADDRESS атрибут. Сверстник диктует дочернему элементу (возможно, во время создания образа) использовать этот адрес, поэтому они подчиняются. Одноранговый узел определяет свой собственный URL для прослушивания с атрибутом CORE_PEER_CHAINCODELISTENADDRESS.

О вашем последнем вопросе; связь осуществляется с gRP C между узлами, а также с клиентами. Если TLS включен, значит, это безопасная связь. Отправной точкой для заказчиков, чтобы узнать о партнерах, и одноранговых узлов, которые знают о партнерах других организаций, является определение узловых одноранговых узлов, определенных во время создания канала. Служба обнаружения работает на одноранговых узлах, поэтому они могут поддерживать макет сети, близкий к реальному времени. Служба обнаружения также предоставляет идентификационные данные одноранговых узлов, что позволяет клиентам обнаруживать одноранговые узлы других организаций, когда политика поддержки требует политики поддержки нескольких организаций (т.е. если политика выглядит как AND(Org1MSP.member, Org2MSP.member)).