„Hyperledger Fabric“ tinklo sąrankos problemos sprendimas „Nerasta lygiaverčių dvejetainių ir konfigūracijos failų“

Kovojate su konfigūravimo problemomis naudojant Hyperledger Fabric v3.0?

Kai dirbate su sudėtingomis blokų grandinės sistemomis, pvz „Hyperledger“ audinys (HLF), netikėtos klaidos gali paversti sąrankos procesus daug laiko reikalaujančiais galvosūkiais. Neseniai, atnaujindamas iš HLF 2.5 į naują v3.0, susidūriau su problema, kuri visiškai sustabdė tinklo diegimą – klaida, nurodanti, kad lygiaverčių dvejetainių failų ir konfigūracijos failų nerasta. 🛑

Ši klaida atsirado nepaisant to, kad aplinkos kintamieji buvo nustatyti taip pat, kaip ir ankstesnėse versijose, ir įsitikinus, kad visi keliai buvo tinkamai sukonfigūruoti. Anksčiau be kliūčių sukonfigūravus HLF ankstesnėse versijose, ši v3.0 problema atrodė neįprasta, ypač todėl, kad identiški veiksmai senesnėse sąrankose veikė nepriekaištingai.

Iššūkis pasisuko giliau, kai pirmieji bandymai atnaujinti būtinas bibliotekas problemos neišsprendė. Nors laikiausi visų įprastų trikčių šalinimo būdų, problema išliko. Tai sustabdė pažangą ir užsiminė, kad naujesnėje versijoje reikia kažko kito, nei ankstesnėse versijose.

Šiame straipsnyje paaiškinsiu, kaip išsprendžiau problemą atnaujindamas savo sistemos versiją – tai detalė, kuri, stebėtinai, nebuvo įtraukta į tipinius HLF sąrankos išteklius. Pasinerkime ir išnagrinėkime sprendimą, kad neprarastumėte laiko susidūrę su panašia kliūtimi. 🚀

„Hyperledger Fabric v3.0“ aplinkos sąrankos scenarijų supratimas

Pateikti scenarijai skirti išspręsti suderinamumo problemas, iškilusias nustatant „Hyperledger Fabric“ (HLF) tinklą, ypač 3.0. Dažnai atnaujinant „Hyperledger Fabric“ atsiranda naujų priklausomybių arba šiek tiek kitokių sąrankų, dėl kurių gali kilti problemų, kaip buvo patirta pereinant iš 2.5 versijos į 3.0. Vienas iš pagrindinių iššūkių yra užtikrinti, kad aplinkos kintamieji ir reikalingi failai, pvz lygiaverčių dvejetainių failų, yra tinkamai sukonfigūruoti ir pasiekiami. Pirmasis scenarijus nustato šiuos kelius sklandžiam tinklo funkcionalumui ir patvirtina, kad reikiami failai ir katalogai yra vietoje, prieš bandant iškviesti tinklą. Ji taip pat atlieka preliminarų patikrinimą, ar kritinė priklausomybė GLIBC yra suderinama su dvejetainiais 3.0 versijos failais.

Pirmasis scenarijus pradedamas eksportuojant pagrindinius aplinkos kintamuosius, kurie nurodo vietas, kuriose saugomi „Hyperledger Fabric“ dvejetainiai failai ir konfigūracijos. Pavyzdžiui, nustatant FABRIC_CFG_PATH kintamasis yra būtinas, nes jis nurodo sistemai, kur ieškoti Fabric konfigūracijos failų tinklo inicijavimo metu. Tada scenarijus patikrina, ar reikalingi aplankai, pvz šiukšliadėžė ir configtx, egzistuoja siekiant užtikrinti, kad jos būtų tinkamos tinklo komandoms vykdyti. Jei trūksta kurio nors aplanko, scenarijus sustoja ir pateikia klaidos pranešimą, užtikrinantį, kad būsite įspėtas prieš skiriant nereikalingą laiką kitų galimų problemų šalinimui. Anksti sustabdžius scenarijų, išvengiama pakopinių klaidų, dėl kurių vėliau gali būti sunku derinti.

Antrasis scenarijus yra a „Docker Compose“. failą, kuris leidžia sudėti visą „Hyperledger Fabric“ sąranką. Šis metodas yra naudingas tiems, kurie gali susidurti su sistemos priklausomybės konfliktais, pvz., GLIBC versijos problemomis, nes jis izoliuoja aplinką, reikalingą Fabric v3.0 paleidimui. Paleidus „Fabric“ programoje „Docker“, galima išvengti suderinamumo problemų pačiame pagrindiniame kompiuteryje. Pavyzdžiui, jei naudojate Ubuntu 18.04, kuriam gali trūkti reikiamos GLIBC versijos, „Docker Compose“ suteikia valdomą aplinką, kurioje priklausomybės nepriklauso nuo pagrindinio kompiuterio konfigūracijos. Dėl šio lankstumo „Docker“ yra populiarus pasirinkimas kuriant sudėtingas programinės įrangos aplinkas, pvz., „blockchain“ tinklus.

Galiausiai, trečiasis scenarijus yra paprastas vieneto bandymo scenarijus, parašytas Bash kalba. Šis scenarijus patikrina, ar aplinka tinkamai nustatyta, prieš paleidžiant tinklą, patvirtindamas dvejetainių failų ir esminių kintamųjų prieinamumą. Pavyzdžiui, ji patikrina, ar bendraamžis dvejetainis yra pasiekiamas sistemos PATH, kuris gali užkirsti kelią vykdymo klaidoms. Šis scenarijus yra vertingas, nes leidžia kūrėjams greitai patikrinti, ar jie turi reikiamą sąranką, taip sutaupo laiko ir sumažina nusivylimą paleidžiant tinklą. Tokie patikrinimai prieš skrydį yra įprasti sudėtingose ​​aplinkose, siekiant užtikrinti, kad visi komponentai būtų pasiekiami ir sukonfigūruoti taip, kaip tikėtasi. ⚙️

# This script sets up environment variables for Hyperledger Fabric v3.0 compatibility
# Tested on Ubuntu 22.04. The script configures paths and starts the network
# It also includes error handling for missing binaries

#!/bin/bash
# Set the bin and configtx folders for Hyperledger Fabric
export PATH=$PWD/fabric-samples/bin:$PATH
export FABRIC_CFG_PATH=$PWD/fabric-samples/configtx

# Validate if environment variables are correctly set
if [ -d "$PWD/fabric-samples/bin" ] && [ -d "$PWD/fabric-samples/configtx" ]; then
  echo "Environment variables successfully set."
else
  echo "Error: Required directories for fabric binaries or configtx not found."
  exit 1
fi

# Try bringing up the network with network.sh script
cd fabric-samples/test-network || exit
./network.sh up

# Check for GLIBC compatibility if network fails
if ! ./peer version; then
  echo "GLIBC version incompatible. Updating GLIBC or Ubuntu recommended."
fi

# Docker Compose file for Hyperledger Fabric v3.0 setup
# Use this file to avoid system dependency issues like GLIBC errors

version: '3.7'
services:
  peer:
    image: hyperledger/fabric-peer:3.0
    container_name: fabric-peer
    environment:
      - CORE_PEER_ID=peer0.org1.example.com
      - FABRIC_CFG_PATH=/etc/hyperledger/fabric
    volumes:
      - ./configtx:/etc/hyperledger/fabric/configtx
      - ./bin:/opt/hyperledger/fabric/bin
    command: /bin/bash -c "./network.sh up"
    ports:
      - "7051:7051"

#!/bin/bash
# This unit test checks if required binaries and environment variables are set correctly
# Run this test before executing ./network.sh up in the Fabric setup

echo "Starting environment validation tests..."

# Check for peer binary
if ! [ -x "$(command -v peer)" ]; then
  echo "Test Failed: 'peer' binary is not available in PATH."
  exit 1
else
  echo "Test Passed: 'peer' binary is available in PATH."
fi

# Check for FABRIC_CFG_PATH
if [ -z "$FABRIC_CFG_PATH" ]; then
  echo "Test Failed: FABRIC_CFG_PATH is not set."
  exit 1
else
  echo "Test Passed: FABRIC_CFG_PATH is set to $FABRIC_CFG_PATH."
fi

„Hyperledger Fabric v3.0“ priklausomybės suderinamumo tyrimas

Naujovinimas į Hyperledger Fabric v3.0 pateikia naujus priklausomybės reikalavimus, kurie gali būti ne iš karto suderinami su tam tikromis sistemomis, ypač senesnėmis Linux versijomis. Vienas iš svarbiausių aspektų, kurių kūrėjai dažnai nepastebi, yra suderinamų bibliotekų versijų, pvz., GLIBC, poreikis, dėl kurio gali atsirasti sistemos klaidų, jei jos nesutampa. Šiuo atveju 3.0 versijoje yra GLIBC 2.34 reikalavimas, kuris nėra lengvai pasiekiamas Ubuntu 18.04 versijoje. Atnaujinus į Ubuntu 22.04, kuriame iš pradžių yra GLIBC 2.34, ši problema išsprendžiama suderinus operacinės sistemos priklausomybes su programinės įrangos reikalavimais. Tai rodo, kaip svarbu užtikrinti, kad sistemos bibliotekos atitiktų atnaujintos programinės įrangos lūkesčius, kad būtų išvengta klaidų blockchain tinklas sąranka.

„Hyperledger Fabric“ paleidimas „Docker“ konteineryje yra dar vienas veiksmingas būdas išvengti priklausomybės konfliktų, nes „Docker“ aplinka leidžia visas būtinas priklausomybes įtraukti į kontroliuojamą, izoliuotą erdvę. Apibrėždami Docker konteinerio specifikacijas, įskaitant teisingą GLIBC versiją, apeinate pagrindinio kompiuterio apribojimus. Šis metodas ypač naudingas, jei negalite atnaujinti pagrindinės sistemos arba norite palaikyti standartizuotą aplinką keliuose įrenginiuose. „Docker“ užtikrina, kad bendraamžių dvejetainis veikia taip, kaip tikėtasi, nepaveikdami pagrindinės sistemos konfigūracijos arba priklausomai nuo jos.

Norint išvengti panašių problemų būsimuose atnaujinimuose, naudinga reguliariai atlikti sistemos auditą, kad būtų užtikrinta, jog svarbios bibliotekos ir programinės įrangos priklausomybės būtų atnaujintos. Be to, norint išspręsti bet kokias suderinamumo klaidas, kurios gali būti nepakankamai dokumentuotos, labai svarbu susipažinti su atnaujinta dokumentacija ir bendruomenės forumais dėl kitų vartotojų sprendimų. Tokie įrankiai kaip „Docker“ ir dažni OS naujinimai yra gyvybiškai svarbūs veiksmai, padedantys išlaikyti suderinamumą ir supaprastinti „Hyperledger Fabric“ sąranką įvairiose programinės įrangos versijose, užtikrinant sklandesnį perėjimą tarp naujinimų 🚀.