Hyperledger-Fabric-Test-Netzwerk mit Ansible auf AWS aufsetzen

Aus Unzufriedenheit mit bisherigen Cloud-basierten Lösungen zum Thema Hyperledger möchte ich in diesem Artikel das automatisierte Aufsetzen einer Testumgebung für Fabric (ein Fabric-Test-Netzwerk) motivieren und erläutern.

Vorsicht: Dieser Artikel stammt aus 2018 und befasst sich mit der veralteten Fabric Version 1.2 sowie anderen veralteten Komponenten wie Hyperledger Composer. Seit diesem Artikel hat sich rund um Hyperledger vieles verändert, sodass Informationen in diesem Artikel mit Vorsicht behandelt werden sollten.

Fabric ist aktuell die aktivste und am stärksten unterstützte Implementierung des Projekts Hyperledger der ASF (Apache Software Foundation). Version 1.2 hat die großen Ambitionen hinter Fabric und seinem Ökosystem bestätigt. Mit Fabric können Private-/Permissioned-/Konsortium-Blockchain-Netzwerke konstruiert, betrieben und entwickelt werden. Primär ist Fabric jedoch nur die Plattform für solche Netzwerke und für die Konfiguration, das kryptographische Material und die Basis-Funktionen des Distributed Ledgers zuständig. Zur Entwicklung empfiehlt es sich meistens, auf das Framework Hyperledger Composer zurückzugreifen, da es die Entwicklung und Verwaltung von sogenannten Business Networks stark vereinfacht. Ein Beispiel der Entwicklung einer Anwendung mit Fabric und Composer habe ich vor einiger Zeit veröffentlicht: Implementierung einer Blockchain-Anwendung mit Hyperledger Fabric und Composer .

Distributed Ledgers in der Cloud – Bleeding Edge oder Servicewüste?

Auch Cloud Service Provider wie AWS (Amazon Web Services), Azure und IBM Cloud wollen im Geschäft der Private-Blockchain-Technologien mitmischen und bieten bereits öffentlich erste Services an. Es werden bisher vor allem einfache Templates für die jeweiligen Plattformen angeboten, z. B. für Fabric und Ethereum. Mit diesen kann man oft nur eine minimale Kombination von Hyperledger-Fabric-Knoten als Docker-Container in einer einzelnen virtuellen Maschine hochfahren. Die Setups sind also nur für Test-Umgebungen gedacht und noch weit von einer produktionsreifen Implementierung der Fabric-Ziel-Architektur entfernt.

Glücklicherweise wollen wir uns in diesem Artikel nur um eine Test-Umgebung kümmern. Dafür nutzen wir aber kein vorgefertiges Template eines Cloud Providers, da deren Eigenschaften nicht immer zufriedenstellend sind. Außerdem lassen sie sich nur mit den jeweiligen Template-Sprachen erweitern, wenn uns plötzlich Komponenten fehlen sollten. Zur Provisionierung nutzen wir daher lieber Ansible, um theoretisch jeden Linux-Server damit bespielen zu können. Als Cloud Provider verwenden wir der Einfachheit halber AWS. Falls wir nur Zugriff auf das Angebot eines anderen Cloud Providers hätten, sollten wir trotzdem ein Ubuntu 16.04 Image verwenden, da das Setup bisher nur hiermit getestet wurde.

Der Aufbau eines Hyperledger-Fabric-Netzwerkes

Um Fabric-Netzwerke zu konstruieren, hat man verschiedene Knoten-Typen zur Verfügung, die für unterschiedliche Aufgaben gedacht sind. Hier müssen wir Peer-, Orderer- und Certificate Authority-Knoten kennen. (Non-)Endorsing Peer-Knoten werden von jeder teilnehmenden Organisation zum Netzwerk hinzugesteuert und bilden den für die Organisation hauptsächlich zu betreibenden Teil der Infrastruktur. Hiermit wird sichergestellt, dass eine Organisation technisch gesehen im Netzwerk „mitkontrolliert“. CAs (Certificate Authorities) dienen zur Erstellung, Authentifizierung und Authorisieren der Identitäten im Netzwerk und kapseln das Schlüssel-Management der Teilnehmer. Neben einer Root-CA kann auch jede teilnehmende Organisation eine eigene CA betreiben, um Anforderungen an Identitäten für ihre Akteure am Netzwerk individuell zu beantworten. Die Orderer-Knoten sorgen dafür, dass vom Netzwerk akzeptierte Transaktionen korrekt und konsistent in Blöcken angeordnet und dem Rest des Netzwerkes zurückgespielt werden. Der Orderer-Service bildet also einen kritischen Teil des konfigurierbaren Konsens-Mechanismus ab.

Das minimale Entwicklungs-Setup in Fabric sieht optimalerweise einen Peer-Knoten einer Organisation, eine CA für die Organisation und einen Orderer-Knoten (im nicht für produktive Einsätze vorgesehenen Solo-Modus) vor. Inklusive der CouchDB für den Peer-Knoten beinhaltet solch ein Netzwerk in Docker abgebildet also vier Container. Es bietet sich daher an, auf das Tool fabric-dev-servers aus den Repositories von Hyperledger Composer zurückzugreifen. Es bietet dieses Setup bereits mittels Docker-Compose an und enthält leicht bedienbare Skripte zum Starten, Stoppen und Zurücksetzen des Netzwerkes. Fabric-dev-servers ist darauf spezialisiert, dass mit Composer die Anwendungsschicht entwickelt wird. Zusätzlich ist in der Test-Umgebung noch jeweils eine Instanz von composer-playground und composer-rest-server nützlich, um Anwendungen zu demonstrieren, gegen sie zu integrieren und sie an Stakeholder auszuliefern. Composer-REST-Server benötigt allerdings eine Composer Card, die für ein konkretes Business-Network ausgestellt wurde. Daher kann ohne installierte Composer-Anwendung auch kein funktionierender REST-Server konfiguriert werden.

Eine produktionsreife Architektur zu entwerfen, zu erläutern und automatisiert zu erstellen, würde den Rahmen dieses Artikels sprengen und ist erst für einen späteren Zeitpunkt vorgesehen.

Los geht’s – Erstellung, Start und Provisionierung des Netzwerkes

Nach ausführlicher Einleitung kann es nun losgehen. Was benötigen wir dafür?

1. Einen AWS IAM Account mit ausreichenden Rechten zur Erstellung einer EC2-Instanz mit EBS (Elastic Block Storage), einem Keypair und einer neuen Security Group.
2. Eine aktuelle Ansible-Installation auf der lokalen Maschine
3. Git und SSH

EC2-Instanz erstellen und Einstellungen vornehmen

Zuerst starten wir eine frische EC2-Instanz mit dem Amazon Machine Image (AMI) „Ubuntu Server 16.04 LTS (HVM), SSD Volume Type“. Der Instanz-Typ „l2.medium“ sollte mehr als ausreichend sein. Während des Einrichtungs-Assistenten von AWS erstellen wir am besten ein neues Keypair mit einem aussagekräftigen Namen, verschieben es nach dem Herunterladen in den Pfad unserer Wahl (z.B. ~/.ssh/keys/my-new-key.pem) und passen die Berechtigungen mit chmod 400 ~/.ssh/keys/my-new-key.pem so an, dass nur der aktuelle Benutzer die Datei lesen darf.

Zur komfortablen Verbindung mit der Instanz können wir noch einen Eintrag in ~/.ssh/config erstellen:

Host my-host
    Hostname (host-of-the-instance).compute.amazonaws.com
    User ec2-user
    IdentityFile ~/.ssh/keys/my-new-key.pem

Dann ist es uns möglich, die SSH-Verbindung ohne Angabe aller Parameter aufzubauen (ssh my-host) und auch mit Ansible zu arbeiten wird dadurch später einfacher. Bei der Frage des Assistenten nach SSD-Speicher für die Instanz können wir gut und gerne 16 GB konfigurieren. Mit den voreingestellten 8 GB sind wir in der Vergangenheit schnell an die Grenzen gestoßen.

Auch eine neue Security Group sollte für die EC2-Instanz erstellt werden. Darin konfigurieren wir den zugelassenen Traffic zwischen dem Internet und der Instanz und bemühen uns, nur benötigte TCP Ports in die Instanz („INBOUND“) freizugeben:

• 7051 für den Peer-Knoten von org1
• 7050 für den Orderer-Knoten
• 7054 für die Certificate Authority
• Mindestens einen Port für composer-playground sowie später folgende composer-rest-server , z.B. 8080 und 3000

Nun können wir bis zum Ende des Wizards klicken und die Instanz starten lassen. An diesem Punkt haben wir AWS-seitig schon die Grundlage für das Fabric Test-Netzwerk geschaffen. Weiter geht’s mit Ansible.

Provisionierung des Fabric-Test-Netzwerks mit einem Ansible Playbook

Ab jetzt möchten wir die Instanz möglichst nur noch reproduzierbar und versionierbar über Ansible Playbooks oder Roles verändern. Die Vorteile dieser Variante gegenüber einer komplett manuellen Installation dürften auf der Hand liegen. Wir erstellen keinen weiteren Snowflake-Server, der schwer zu aktualisieren, zu patchen und zu erweitern ist. Außerdem können wir viel Zeit und Nerven dabei sparen, wenn wir nicht alles von Hand installieren. Zudem habe ich schon ein Repository angelegt, das die Tasks für die Provisionierung definiert und implementiert .

Dieses laden wir uns nun herunter: git clone git@github.com:jverhoelen/hyperledger-fabric-dev-ansible.git && cd hyperledger-fabric-dev-ansible. Es beinhaltet im Wesentlichen das Playbook, das mehrere modularisierte Roles abarbeitet, sowie konfigurierbare Variablen, die währenddessen genutzt werden. Eine dritte Datei fehlt noch, diese legen wir als nächstes an.

Die fehlende Datei heißt hosts und kann im selben Ordner erstellt werden. Ihr Inhalt ist sehr einfach, da wir nur einen Host provisionieren wollen:

[remote]
my-host # Name des Hosts, den wir in der SSH-config verwendet haben

Vor der Ausführung des Playbooks können wir bei Bedarf noch die Standard-Variablen in variables.yml anpassen. Dann können wir das Feuer auf die Instanz eröffnen und Ansible (und Cowsay) bei der Anwendung des Playbooks zusehen:

ansible-playbook -i ./hosts playbook.yml

Am Ende sollten wir eine positiv wirkende Zusammenfassung sehen, die uns den Erfolg der Operation bestätigt.

Lokale Provisionierung auf Ubuntu 16.04 mit Vagrant

Wenn gerade kein AWS-Konto für einen schnellen Test zur Hand sein sollte oder das Setup einfach erstmal nur verprobt werden soll, können wir das auch mit einer Vagrant VM tun. Im genutzten Repository liegt ein Vagrantfile bei – mit vagrant up können wir also schnell lokal eine Ubuntu-Instanz starten. Nach dem Start der Instanz generieren wir uns mit vagrant ssh-config > ~/.ssh/config die SSH-Einstellungen und übernehmen sie in unsere SSH-Konfiguration.

Zusammenfassung und Ausblick

Wir haben nun eine frische EC2-Instanz mit allen nötigen Voraussetzungen für ein Docker-basiertes Setup von Fabric sowie Composer erstellt. Auf der Instanz laufen alle benötigten Container, composer-cli ist installiert und die PeerAdmin-Card für das Netzwerk wurde in die Card-List von composer-cli importiert.
Außerdem läuft eine Instanz von composer-playground auf Port 8080, die jeder Zeit auf die Cards auf dem Host zugreifen kann. Im Browser kann man die URI des Playgrounds bequem ansteuern und das Netzwerk sowie später installierte Composer Business Network Definitions bedienen.

Da wir mit diesem Setup noch kein Composer Business Network auf dem Fabric Test-Netzwerk betreiben, kann leider noch kein composer-rest-server installiert werden, da dieser immer nur einen berechtigten Proxy herstellt.
Für einen spezifischen Anwendungsfall nötige Komponenten sollten jeweils über selbstgeschriebene Automatisierungen, zum Beispiel über Ansible, installiert werden. Somit kann die grundlegende Provisionierung für Fabric und Composer vom allgemeinen Playbook übernommen werden und spezielle Komponenten können in eigenen Playbooks gewartet und versioniert werden. Hiermit sind beispielsweise mehrere unterschiedliche REST-Server-Installationen auf bereits deployten Business Networks gemeint.

Erwähnt werden sollte zu diesem Setup noch der Aspekt der Security. Es sieht bisher keinen Mechanismus vor, die resultierende Umgebung zu schützen. Wenn die Umgebung längerfristig und im Rahmen eines echten Projektes genutzt werden soll, sollte beispielsweise der Einsatz eines privaten Netzwerkes mit VPN angestrebt werden.

Im nächsten Artikel zum Thema Hyperledger Fabric und Composer wird es darum gehen, wie eine komfortable Continuous Delivery Pipeline für unsere Composer Business Network Definition auf GitlabCI erstellt werden kann.