Introduction
La technologie blockchain a changé la donne dans plein de secteurs, en offrant des capacités de conservation des données décentralisées et immuables qui résolvent des problèmes de longue date dans le domaine de l'intégrité et de la confiance des données.
Parmi les nombreux cadres blockchain disponibles, Hyperledger Fabric s'est imposé comme l'une des meilleures implémentations de blockchain autorisée, particulièrement appréciée pour sa modularité, sa flexibilité et son adaptation aux entreprises.
Ce guide détaillé explique en profondeur le processus complexe de création d'une configuration multi-clusters Hyperledger Fabric, pour construire un réseau Hyperledger Fabric multi-clusters et multi-organisations.
En répartissant les composants du réseau entre différents clusters et organisations, on obtient une meilleure tolérance aux pannes, des capacités d'évolutivité et une autonomie organisationnelle accrues.
Chaque étape a été soigneusement détaillée pour donner à la fois des infos techniques approfondies et des conseils pratiques pour la mise en œuvre.
Comprendre l'architecture multi-clusters Hyperledger Fabric
Avant de se lancer dans la mise en œuvre, il est super important de bien comprendre les bases architecturales présentées dans ce guide sur l'architecture Hyperledger Fabric.
La conception multi-clusters est une conception sophistiquée pour le déploiement de réseaux blockchain qui combine collaboration et indépendance organisationnelle.
Dans ce modèle architectural, on a affaire à deux organisations différentes, chacune ayant sa propre autorité de certification chargée de gérer les identités cryptographiques et d'assurer une authentification sécurisée.
Ces organisations fonctionnent de manière indépendante, leurs ressources tournant dans différents clusters Kubernetes Hyperledger Fabric.
Cette séparation offre des avantages importants tels que la tolérance aux pannes, l'isolation des ressources et le fait que chaque organisation peut garder le contrôle de son infrastructure.
La configuration du cluster est telle que chaque organisation héberge son propre groupe de pairs et son autorité de certification dans ses propres environnements dédiés.
Ce choix de conception garantit qu'il n'y a pas de conflit de ressources et permet aussi aux organisations d'adapter leur infrastructure en fonction de leurs besoins spécifiques sans affecter les autres participants au réseau.
Le service de commande, qui sert de mécanisme de consensus pour le réseau, est stratégiquement réparti entre différentes organisations.
En mettant deux ordonnanceurs dans des clusters séparés, l'architecture est redondante et super fiable.
Si un client a des problèmes, le réseau continue de fonctionner via l'autre client afin de ne jamais s'arrêter.
Ce type d'architecture permet à chaque organisation de garder le contrôle total de ses ressources tout en offrant un moyen de communication interorganisationnelle via des canaux partagés et des contrats intelligents.
Outils utilisés
La mise en œuvre utilise des outils soigneusement sélectionnés qui facilitent le déploiement de systèmes complexes et ajoutent des capacités de gestion robustes.
EKS facilite le déploiement, la gestion et la mise à l'échelle des clusters Kubernetes sur l'infrastructure Amazon Web Services, offrant une plateforme fiable et éprouvée pour héberger les composants réseau Fabric.
La nature gérée d'EKS permet de réduire les frais généraux liés au fonctionnement du système tout en offrant une fiabilité de niveau entreprise.
Hlf-Operator, c'est un opérateur Kubernetes spécial qui a été conçu pour gérer le déploiement du réseau Hyperledger Fabric et les opérations courantes pour les réseaux Hyperledger Fabric.
Cet opérateur simplifie plein de tâches complexes de déploiement et de gestion liées aux réseaux Fabric et propose un ensemble d'options de configuration déclaratives qui facilitent beaucoup l'administration du réseau et réduisent les risques d'erreurs de configuration.
Étapes pour configurer le réseau
Une fois qu'on a compris l'architecture et les outils, le processus de mise en place suit une série d'étapes structurées qui s'enchaînent pour créer un réseau qui marche bien.
Étape 1 : Configurer le cluster EKS
La première étape de la mise en place consiste à créer les clusters Kubernetes où les composants du réseau Fabric seront installés.
Cette étape fondamentale nécessite une planification minutieuse pour s'assurer que les clusters sont bien configurés pour les charges de travail de la blockchain.
La configuration du cluster commence par définir les paramètres qui vont régir le comportement et la capacité du cluster.
Ces paramètres comprennent :
- •Choisis les types d'instances en fonction des caractéristiques attendues de la charge de travail.
- •Nombre d'instances nécessaires pour gérer les volumes de transactions prévus
- •Choisis les zones de disponibilité pour maximiser la résilience et minimiser la latence.
Avec eksctl, un outil spécial en ligne de commande conçu pour gérer les clusters EKS, les clusters sont créés selon les spécifications définies.
Cet outil automatise une grande partie de la complexité liée à l'approvisionnement des clusters tout en garantissant le respect des meilleures pratiques.
Après avoir créé les clusters, des fichiers kubeconfig sont générés pour permettre un accès sécurisé aux nouveaux clusters.
Ces fichiers de configuration contiennent les informations d'authentification et de connexion nécessaires pour les prochaines étapes du déploiement.
Étape 2 : Installez Hlf-Operator et Istio
Une fois les clusters opérationnels, l'étape suivante consiste à installer les outils de gestion qui seront utilisés pour faciliter le déploiement des composants Fabric et la communication entre les services.
L'installation de Hlf-Operator commence par l'ajout du référentiel Helm qui contient les graphiques de l'opérateur.
Une fois le référentiel disponible, l'opérateur est installé sur les deux clusters, fournissant les définitions de ressources personnalisées et les contrôleurs nécessaires à la gestion des composants Fabric.
L'installation d'Istio suit, apportant les capacités du maillage de services aux clusters.
Istio offre des fonctionnalités avancées de gestion du trafic, d'équilibrage de charge et d'observabilité qui sont super utiles dans les réseaux blockchain distribués où il est super important d'avoir une communication fiable entre les composants.
Après avoir installé Istio, c'est important de récupérer l'URL externe fournie par la passerelle d'entrée Istio. Cette URL, qui est indiquée dans la colonne EXTERNAL-IP de la requête des services Istio, est le point de terminaison public du cluster et sera largement utilisée dans la configuration DNS.
Étape 3 : Configurer le DNS
La configuration du système de noms de domaine définit la structure de nommage qui permet une communication facile entre les composants réseau répartis sur différents clusters.
La configuration DNS nécessite la création d'une zone hébergée dans AWS Route 53 pour que le domaine soit associé au réseau Fabric.
Dans cette zone hébergée, des enregistrements individuels sont configurés pour chaque composant de service qui mappe les noms de domaine lisibles par l'utilisateur au point de terminaison du cluster.
Pour chaque pair, autorité de certification et commanditaire, un enregistrement CNAME est défini pour pointer vers l'URL externe du cluster approprié.
Cette configuration permet aux composants d'un cluster de trouver et de communiquer avec les composants d'autres clusters en utilisant des noms de domaine cohérents et prévisibles.
Structure des enregistrements DNS :
- •Pour la première organisation, des enregistrements sont créés pour l'autorité de certification et les pairs.
- •La deuxième organisation doit avoir son propre ensemble de documents.
- •L'organisation qui passe la commande a besoin de dossiers pour son autorité de certification et pour plusieurs commanditaires qui pointent vers leurs points de terminaison de cluster respectifs.
Étape 4 : Configurer les CA et les pairs de l'organisation
Une fois l'infrastructure et le réseau en place, le déploiement des composants Fabric proprement dits commence par les autorités de certification et les pairs de chaque organisation.
Les autorités de certification sont les points d'ancrage de confiance pour leurs organisations respectives et délivrent les identités cryptographiques que les participants utilisent pour s'authentifier et autoriser des actions au sein du réseau.
Chaque organisation met en place son autorité de certification en suivant des spécifications qui incluent les informations d'identification d'inscription, la configuration TLS et d'autres paramètres de sécurité.
Les pairs sont les nœuds de traitement des transactions au sein de chaque organisation.
Ces composants gardent des copies du grand livre, exécutent le code de chaîne et approuvent les transactions en fonction des politiques d'approbation du réseau.
Prêt à déployer votre réseau blockchain ?
Commence à créer ton réseau Hyperledger Fabric multi-clusters avec nos conseils et notre aide d'experts.
Détails du déploiement par les pairs
Déploiement par les pairs - Pour déployer une CA, il faut préciser les besoins en stockage, l'allocation des ressources et les paramètres de connectivité.
Pour la première organisation :
- •La CA est déployée en premier, puis les nœuds pairs.
- •Les fichiers de configuration indiquent les paramètres spécifiques à chaque composant, comme les identités bootstrap, les classes de stockage et les types de service.
- •Une fois ces configurations appliquées, les composants sont surveillés jusqu'à ce qu'ils soient prêts.
La deuxième organisation a un modèle de déploiement similaire, avec son autorité de certification et ses pairs configurés selon les besoins spécifiques de l'organisation.
Même si le processus général est similaire à celui de la première organisation, certaines valeurs de configuration diffèrent pour représenter les configurations distinctes du cluster et du domaine.
Étape 5 : Créer l'organisation du commanditaire
L'organisation qui passe la commande a un rôle spécial dans le réseau, car elle fournit le mécanisme de consensus utilisé pour séquencer les transactions et créer des blocs à distribuer aux pairs.
La création de l'autorité de certification Orderer CA permet de créer l'autorité de certification qui sera chargée de délivrer des identités aux nœuds Orderer.
Cette autorité de certification est indépendante des autorités de certification de l'organisation et renforce la séparation entre la commande de services et l'approbation des transactions.
Le premier ordonnanceur est déployé avec la configuration suivante :
- •Son lien avec l'autorité de certification commanditaire
- •Exigences en matière de stockage
- •Paramètres du bloc Genesis
Cet ordonnateur est le premier point d'ancrage du service de commande.
Déployer le deuxième ordonnanceur, ça ajoute un peu plus de complexité à cause de l'emplacement de cet ordonnanceur dans un cluster séparé.
Une solution de contournement est utilisée pour créer la configuration requise avec une autorité de certification existante ; des modifications manuelles sont apportées pour s'assurer que le demandeur est connecté à la bonne autorité de certification.
Détails de configuration de l'acheteur
Des changements spécifiques sont faits :
- •Les références d'hôte CA doivent pointer vers le domaine CA de l'acheteur.
- •L'hôte CA est ajouté à la demande de signature de certificat.
- •Les certificats TLS CA sont copiés à partir de la configuration du premier client.
Ces ajustements sont faits pour que le deuxième commanditaire puisse s'authentifier correctement et communiquer avec l'autorité de certification du service de commande.
Une fois les réglages de configuration faits, le deuxième ordonnanceur est déployé et surveillé jusqu'à ce qu'il soit opérationnel.
À ce stade, le réseau a un ensemble complet de composants d'infrastructure de base avec toutes les autorités de certification, tous les pairs et tous les ordonnateurs opérationnels et accessibles.
Étape 6 : Créez un canal
Les canaux dans Hyperledger Fabric offrent des voies de communication privées entre certains participants du réseau, ce qui permet des flux de transactions confidentiels et un partage sélectif des données.
La création d'un canal commence par l'enregistrement et l'inscription des identités administratives de chaque organisation et de l'organisation commanditaire.
Ces identités ont les privilèges nécessaires pour gérer les canaux.
Pour s'inscrire, il faut :
- •Se connecter à l'autorité de certification appropriée
- •Créer des comptes utilisateurs avec des attributs administratifs
Une fois enregistrée, l'inscription crée les éléments cryptographiques pour chacune des identités (certificats de signature et clés privées).
Une fois que toutes les identités administratives sont prêtes, elles sont compilées dans un secret Kubernetes, qui sera utilisé pendant les opérations du canal.
Ce secret regroupe les éléments cryptographiques nécessaires à la gouvernance du canal.
Le canal principal est configuré avec des spécifications qui définissent :
- •Organisations participantes
- •Les commanditaires sont responsables du canal.
- •Politiques qui régissent le fonctionnement et les modifications des canaux
Ce processus d'initialisation crée le bloc genesis pour le canal et configure ce dernier.
Les collègues des deux organisations rejoignent le canal en se référant à la configuration du canal principal et en fournissant les identifiants de leur organisation.
Ce processus de connexion rend le canal visible pour les pairs et leur permet de recevoir des blocs contenant des transactions du canal.
Des canaux de suivi sont créés pour chaque organisation afin d'établir la connexion entre les pairs et le canal.
Ces configurations indiquent quel pair doit suivre quel canal et permettent de finir de configurer l'appartenance à la chaîne.
Étape 7 : Installe le chaincode
Le chaincode, c'est l'implémentation du contrat intelligent dans Hyperledger Fabric. C'est la logique métier qui décrit le traitement des transactions et la gestion de l'état sur la blockchain.
Le cycle de vie du chaincode commence par le packaging du chaincode en tant qu'artefact déployable.
Dans cette implémentation, le chaincode est déployé comme un service qui a besoin de :
- •Créer une image Docker avec le chaincode.
- •Préparer les métadonnées de connexion qui expliquent comment les pairs doivent se connecter au service chaincode.
Pour la première organisation :
- •Le chaincode packagé est installé sur le pair, ce qui rend le package chaincode disponible pour le déploiement.
- •Un fichier de configuration de connexion est préparé, avec l'adresse et les détails de connexion TLS pour le service chaincode.
- •Le chaincode est ensuite déployé en tant que service Kubernetes dans le cluster de l'organisation, le rendant accessible aux pairs de l'organisation.
Une fois la définition du code de chaîne déployée, l'organisation l'approuve, ce qui veut dire qu'elle est prête à utiliser cette version du code de chaîne sur le canal.
Une fois que toutes les organisations ont approuvé la définition du chaincode, celle-ci est validée dans le canal, ce qui la rend active et prête à être invoquée.
Ce processus d'engagement crée le conteneur chaincode et en fait l'implémentation officielle pour le canal.
La deuxième organisation suit un processus d'installation similaire et installe le même package chaincode sur ses pairs, puis déploie le service chaincode dans son cluster.
Une fois installé et déployé, le chaincode est prêt à être utilisé sur le réseau.
Étape 8 : Vérifier le bon fonctionnement du réseau
Une fois tous les composants déployés et configurés, la vérification permet de s'assurer que le réseau fonctionne comme prévu et peut traiter correctement les transactions.
Les tests de transaction consistent à lancer des transactions types qui testent la logique du code de chaîne.
Ces transactions sont les suivantes :
- •Soumis à des pairs, qui simulent l'exécution de la transaction, et renvoient des approbations à la transaction
- •Envoyé au service de commande qui les met en ordre dans des blocs et les envoie à tous les membres du canal
Pour que les transactions soient traitées correctement, il faut que :
- •La communication entre pairs marche bien
- •Les politiques de recommandation sont bien respectées.
- •Le service de commande met les transactions dans le bon ordre.
- •Les changements d'état sont bien reflétés chez tous les pairs.
Conclusion
Créer un réseau Hyperledger Fabric multi-clusters et multi-organisations demande une planification soignée, une configuration minutieuse et la coordination de plein de composants et d'outils.
Le processus comprend :
- •Construire une infrastructure isolée mais connectée
- •Mettre en place des éléments blockchain spécialisés
- •Mettre en place des canaux de communication sécurisés
- •Vérifiez que tout marche bien en testant les transactions.
Cette approche de l'architecture offre les avantages suivants :
- •Amélioration de la tolérance aux pannes grâce à la répartition des composants sur le réseau
- •Meilleure évolutivité grâce à la séparation des ressources organisationnelles
- •Meilleur contrôle de l'organisation sur l'infrastructure et les opérations
- •Plus de flexibilité pour adapter le réseau au fur et à mesure que les besoins changent
L'infrastructure blockchain qui en résulte est une base solide qui peut être utilisée pour plein de cas d'utilisation dans différents secteurs, du suivi de la chaîne d'approvisionnement aux règlements financiers en passant par la gestion des dossiers médicaux.
La nature autorisée d'Hyperledger Fabric, combinée à l'architecture multi-clusters, offre une plateforme qui équilibre la transparence et l'immuabilité de la blockchain avec les exigences de confidentialité et de contrôle des applications d'entreprise.
Travaux futurs
Plusieurs améliorations pourraient être apportées pour optimiser encore davantage le processus de déploiement et étendre les capacités de l'architecture réseau.
L'automatisation, c'est une super occasion de s'améliorer.
Développer des scripts et des modèles d'infrastructure en tant que code pourrait servir à :
- •Simplifiez le processus de configuration.
- •Réduis au minimum le nombre d'étapes de configuration manuelle.
- •Réduis au minimum les risques d'erreurs humaines.
Une telle automatisation permettrait de déployer le réseau de manière plus reproductible et de le rendre accessible à des organisations ayant différents niveaux de familiarité avec la blockchain.
Un meilleur support pour les déploiements multi-cloud rendrait le réseau plus solide et flexible.
Déployer différentes organisations sur différents fournisseurs de cloud, par exemple une organisation sur AWS, une autre sur Google Cloud Platform et une troisième sur Microsoft Azure, permettrait de s'assurer qu'il n'y a pas de dépendances entre les différents clouds, mais que les organisations peuvent utiliser leurs environnements cloud préférés tout en participant à un réseau blockchain unifié.
Ces améliorations s'appuieraient sur les bases solides de la version actuelle, élargissant les capacités du réseau et le rendant encore plus adapté aux déploiements en entreprise.
