برنامه Spring Boot Fullstack Blockchain با Hyperledger Fabric در Kubernetes (قسمت 6)

در این سری مقالات، Hyperledger Fabric را با Spring Boot ادغام خواهیم کرد. در این مقاله، سفارش دهنده را بررسی خواهیم کرد. همچنین، نحوه استقرار سرویس سفارش دهنده در Kubernetes را نیز توضیح خواهیم داد.

ادغام Hyperledger Fabric با Spring Boot

سایر مقالات در مورد ادغام Hyperledger Fabric با Spring Boot از لینک های زیر قابل دسترسی هستند.

بخش 1 – مقدمه

قسمت 2 – راه اندازی خوشه Kubernetes

قسمت 3 – Fabric CA Server

بخش 4 – تولید گواهینامه ها و مصنوعات

قسمت پنجم – kafka

قسمت 6- Orderer

Orderer مسئول بسته‌بندی تراکنش‌ها در بلوک‌ها و توزیع آن‌ها در Anchor Peers در سراسر شبکه است.

جریان معاملاتhyperledger fabric دارای مراحل پیشنهاد، بسته بندی و اعتبارسنجی است. order مسئول بسته بندی است و در مرحله اعتبار سنجی برای توزیع بلوک های جدید در شبکه شرکت دارد.

سرویس سفارش یک کانال ارتباطی مشترک برای مشتریان و همتایان فراهم می کند و یک سرویس پخش برای پیام های حاوی تراکنش ها ارائه می دهد. مشتریان به کانال متصل می شوند و ممکن است پیام هایی را در کانال پخش کنند که سپس به همه همتایان ارسال می شود. این کانال از تحویل اتمی همه پیام‌ها، یعنی ارتباط پیام با تحویل سفارش کل و قابلیت اطمینان (ویژه پیاده‌سازی) پشتیبانی می‌کند. به عبارت دیگر، کانال پیام‌های مشابهی را برای همه همتاهای متصل و خروجی آن‌ها را برای همه همتایان به ترتیب منطقی یکسان ارسال می‌کند.

سرویس سفارش قادر به تایید تراکنش نیست، هدف اصلی آن ارائه کل سفارش برای تراکنش های منتشر شده، برش بلوک ها با تراکنش های سفارش شده است.
سفارش اجرای خدمات

در حالی که هر سرویس سفارش در حال حاضر موجود، تراکنش‌ها و به‌روزرسانی‌های پیکربندی را یکسان انجام می‌دهد، با این وجود چندین پیاده‌سازی متفاوت برای دستیابی به اجماع در مورد ترتیب دقیق تراکنش‌ها بین گره‌های سرویس سفارش‌دهنده وجود دارد.
قایق

جدید در نسخه 1.4.1، Raft یک سرویس سفارش با تحمل خطا (CFT) بر اساس اجرای پروتکل Raft در etcd است.

Raft از مدل “رهبر و پیرو” پیروی می کند، که در آن یک گره رهبر (در هر کانال) انتخاب می شود و تصمیمات آن توسط دنبال کنندگان تکرار می شود.

راه‌اندازی و مدیریت سرویس‌های سفارش Raft نسبت به خدمات سفارش مبتنی بر کافکا باید آسان‌تر باشد و طراحی آنها به سازمان‌های مختلف اجازه می‌دهد تا گره‌ها را در یک سرویس سفارش توزیع شده مشارکت دهند.

کافکا

مشابه سفارش مبتنی بر Raft، Apache Kafka یک پیاده سازی CFT است که از پیکربندی گره “رهبر و پیرو” استفاده می کند.

کافکا از یک مجموعه ZooKeeper برای اهداف مدیریتی استفاده می کند. انتقال دارایی projesinde kafka kullanıyoruz. ما از کافکا استفاده خواهیم کرد.
انفرادی (منسوخ شده در نسخه 2.x)

اجرای Solo سرویس سفارش فقط برای آزمایش در نظر گرفته شده است و فقط از یک گره سفارش دهنده تشکیل شده است. منسوخ شده است و ممکن است در نسخه بعدی کاملاً حذف شود.

کاربران موجود Solo باید برای عملکرد معادل به یک شبکه Raft گره واحد منتقل شوند.

نصب Orderer در Kubernetes

برای پروژه انتقال دارایی، کافکا و zookeeper را برای اجرای 5 پاد روی kubernetes راه اندازی می کنیم.

بیایید پروژه ای را که از این لینک دانلود کرده ایم باز کنیم و به دایرکتوری که k8s در آن قرار دارد برویم.


    $ cd deploy/k8s

استقرار kafka و Zookeeper

بیایید یک استقرار برای هر سفارش دهنده ایجاد کنیم.

فایل های yaml که آن را ایجاد می کنند در پوشه زیر در پروژه زیر قرار دارند.

deploy/k8s/orderer/orderer.yaml

deploy/k8s/orderer/orderer2.yaml

deploy/k8s/orderer/orderer3.yaml

deploy/k8s/orderer/orderer4.yaml

deploy/k8s/orderer/orderer5.yaml


    apiVersion: apps/v1
kind: Deployment
metadata:
  name: orderer
  labels: 
    app: orderer

استقرار برای سفارش دهنده 1، به نام order


    apiVersion: apps/v1
kind: Deployment
metadata:
  name: orderer5
  labels: 
    app: orderer5

Deployment برای سفارش دهنده 5، به نام orderer5. در سایر سفارش دهنده ها، این مقدار به orderer2, orderer3, orderer4 اختصاص داده می شود.


    spec:
  selector:
    matchLabels:
      app: orderer
  replicas: 1

Deployment دارای مشخصاتی است که نشان می دهد 1 کپی از کانتینر سفارش دهنده در Pods منحصر به فرد راه اندازی می شود. این مقدار برای هر سفارش دهنده یکسان است.


    volumes:
  - name: fabricfiles
    persistentVolumeClaim:
      claimName: fabricfiles-pvc

volumeClaimTemplates با استفاده از PersistentVolumes ارائه شده توسط PersistentVolume Provisioner، فضای ذخیره سازی پایداری را فراهم می کند. باید با نام فراداده pvc یکسان باشد. این مقدار برای هر سفارش دهنده یکسان است.


    volumeMounts:
  - name:  fabricfiles
    mountPath: /organizations
    subPath: organizations # required for certificates.
  - name: fabricfiles
    mountPath: /system-genesis-block
    subPath: system-genesis-block # It needs a genesis block.
  - name: fabricfiles
    mountPath: /var/hyperledger/production/orderer
    subPath: state/orderer # orderer persistence data

subPath: state/orderer # orderer persistence data

کانتینر Orderer PV را در /organizations برای گواهی ها نصب می کند.

ظرف سفارش دهنده PV را در /system-genesis-block برای بلوک پیدایش نصب می کند. به یک بلوک پیدایش نیاز دارد.

ظرف سفارش دهنده، PV را در /var/hyperledger/production/orderer برای داده های پایداری سفارش دهنده نصب می کند. این داده ها در فهرست فرعی state/orderer در سرور nfs نگهداری می شوند.


    - name: fabricfiles
  mountPath: /var/hyperledger/production/orderer
  subPath: state/orderer5

داده های ماندگاری سایر سفارش دهندگان نیز در زیر شاخه هایی مانند state/orderer2، state/orderer5 در سرور nfs نگهداری می شوند.


    livenessProbe:
  httpGet:
    port: 9444
    path: /healthz
  initialDelaySeconds: 60
  timeoutSeconds: 5
  failureThreshold: 6
readinessProbe:
    httpGet:
      port: 9444
      path: /healthz
    initialDelaySeconds: 5
    timeoutSeconds: 3
    periodSeconds: 5

هنگامی که یک کانتینر در حالت آماده قرار می گیرد، kubernetes شروع به هدایت ترافیک به غلاف مربوطه می کند. اما غلاف موجود در ظرف ممکن است برای پذیرش ترافیک آماده نباشد. بنابراین، ما باید کاوشگرهای «زندگی» و «آمادگی» را برای برنامه‌ها مشخص کنیم تا کوبرنت‌ها این فرآیند را به طور مؤثرتری انجام دهند.

Kubelet با ارسال درخواست‌هایی به مسیر /healthz در پورت 9443، زنده و سالم بودن کانتینر را بررسی می‌کند و انتظار یک کد نتیجه موفقیت‌آمیز را دارد.


    spec:
  containers:
  - name: orderer
    image: hyperledger/fabric-orderer:2.3
    imagePullPolicy: IfNotPresent

2.3 به عنوان نسخه تصویر داکر سفارش دهنده hyperledger fabric اختصاص داده شده است.

imagePullPolicy را روی IfNotPresent یا Never تنظیم کنید و از قبل بکشید: تصاویر را به صورت دستی روی هر گره خوشه بکشید تا آخرین مورد در حافظه پنهان ذخیره شود، سپس یک به روز رسانی چرخشی kubectl یا مشابه راه اندازی مجدد Pods را انجام دهید.

متغیرهای محیطی زیر برای سفارش دهنده اختصاص داده شده است.


    env:
  - name: CONFIGTX_ORDERER_ADDRESSES
    value: "orderer:7050"
  - name: ORDERER_GENERAL_LISTENADDRESS
    value: "0.0.0.0"
  - name: ORDERER_GENERAL_LISTENPORT
    value: "7050"
  - name: ORDERER_GENERAL_LOGLEVEL
    value: debug
  - name: ORDERER_GENERAL_LOCALMSPDIR
    value: /organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp
  - name: ORDERER_GENERAL_LOCALMSPID
    value: OrdererMSP
  - name: ORDERER_GENERAL_GENESISMETHOD
    value: file
  - name: ORDERER_GENERAL_GENESISFILE
    value: /system-genesis-block/genesis.block
  - name: ORDERER_GENERAL_TLS_ENABLED
    value: "true"
  - name: ORDERER_GENERAL_TLS_PRIVATEKEY
    value: /organizations/ordererOrganizations/example.com/orderers/orderer.example.com/tls/server.key
  - name: ORDERER_GENERAL_TLS_CERTIFICATE
    value: /organizations/ordererOrganizations/example.com/orderers/orderer.example.com/tls/server.crt
  - name: ORDERER_GENERAL_TLS_ROOTCAS
    value: /organizations/ordererOrganizations/example.com/orderers/orderer.example.com/tls/ca.crt
  - name:  ORDERER_GENERAL_CLUSTER_CLIENTPRIVATEKEY
    value: /organizations/ordererOrganizations/example.com/orderers/orderer.example.com/tls/server.key
  - name:  ORDERER_GENERAL_CLUSTER_CLIENTCERTIFICATE
    value: /organizations/ordererOrganizations/example.com/orderers/orderer.example.com/tls/server.crt
  - name: ORDERER_OPERATIONS_LISTENADDRESS # metric endpoint
    value: 0.0.0.0:9444
  - name: ORDERER_METRICS_PROVIDER
    value: prometheus
  - name: CONFIGTX_ORDERER_ORDERERTYPE
    value: kafka
  - name: CONFIGTX_ORDERER_KAFKA_BROKERS
    value: "broker-0.broker:9092,broker-1.broker:9092"
  - name: ORDERER_KAFKA_RETRY_SHORTINTERVAL
    value: 1s
  - name: ORDERER_KAFKA_RETRY_SHORTTOTAL
    value: 30s
  - name: ORDERER_KAFKA_VERBOSE
    value: "true"

ORDERER_GENERAL_GENESISFILE: مسیر به مسیر فایل پیدایش

ORDERER_GENERAL_LOCALMSPID: شناسه برای بارگیری تعریف MSP

ORDERER_GENERAL_LOCALMSPDIR: MSPDir مسیر سیستم فایلی است که شامل پیکربندی MSP است.

ORDERER_GENERAL_TLS_ENABLED: TLS را با احراز هویت مشتری فعال کنید.

ORDERER_GENERAL_TLS_PRIVATEKEY: مسیر کاملا واجد شرایط فایل که حاوی کلید خصوصی سرور است

ORDERER_GENERAL_TLS_CERTIFICATE: مسیر کاملا واجد شرایط فایل که حاوی گواهی سرور است

ORDERER_GENERAL_TLS_ROOTCAS: مسیر کاملاً واجد شرایط فایل که حاوی زنجیره گواهی CA است که گواهی سرور TLS را صادر کرده است.

ORDERER_GENERAL_GENESISMETHOD: فایل زمانی استفاده می شود که بخواهید بلوک پیدایش را به عنوان فایل در ظرف ارائه دهید.

ORDERER_GENERAL_TLS_CLIENTROOTCAS: مسیر کاملا واجد شرایط فایل که حاوی زنجیره گواهی CA است که گواهی سرور TLS را صادر کرده است.

CONFIGTX_ORDERER_ORDERERTYPE: اجرای سفارش دهنده برای شروع. انواع موجود انفرادی، کافکا و etcdraft هستند.

ORDERER_KAFKA_RETRY_SHORTINTERVAL: گره سفارش ممکن است در اتصال kafka_ kafka_ RETRY_ Shortentreval فاصله بین تلاش های مجدد است.

ORDERER_KAFKA_RETRY_SHORTTOTAL: تعداد کل تلاش های مجدد.

CONFIGTX_ORDERER_KAFKA_BROKERS: به سفارش دهنده آموزش می دهد که چگونه با کافکا در تماس باشد.

ORDERER_GENERAL_LISTENPORT: این مقدار پورتی است که سفارش دهنده به آن گوش می دهد.

ORDERER_KAFKA_RETRY_SHORTINTERVAL: گره سفارش دهنده ممکن است نتواند به کافکا متصل شود، این مقدار بازه تلاش مجدد است.

broker-0.broker: نام سرویس کافکا

9092: بندر خدمات کافکا

معیارهای سفارش دهنده در پورت زیر ریخته می شود.


    - name: ORDERER_OPERATIONS_LISTENADDRESS # metric endpoint
    value: 0.0.0.0:9444
- name: ORDERER_METRICS_PROVIDER
   value: prometheus

خدمات سفارش دهنده

بیایید یک سرویس برای سفارش دهنده ایجاد کنیم.

فایل های yaml که آن را ایجاد می کنند در پوشه زیر در پروژه زیر قرار دارند.

deploy/orderer/order-svc.yaml

deploy/orderer/order2-svc.yaml

deploy/orderer/order3-svc.yaml

deploy/orderer/order4-svc.yaml

deploy/orderer/order5-svc.yaml


    apiVersion: v1
kind: Service
metadata:
  name: orderer
  labels: 
    app: orderer

این مشخصات یک شیء سرویس جدید به نام “orderer” ایجاد می کند. سرویس برای سفارش دهنده 5 با نام orderer5. در سایر سفارش دهندگان، این مقدار به orderer2, orderer3, orderer4 اختصاص داده می شود.


    ports:
- name: grpc
  protocol: TCP
  targetPort: 7050 
  port: 7050

targetPort: container port.7050 اختصاص داده شده است.

port: kubernetes service port.7050 اختصاص داده شده است.


    apiVersion: v1
kind: Service
metadata:
  name: orderer-metrics
  labels:
    app: orderer
    metrics-service: "true"

یک سرویس جدید با نام “orderer-metrics” برای بازیابی اطلاعات متریک سفارش دهنده ایجاد شده است. سرویس متریک برای سفارش دهنده 5، به نام orderer5-metrics.


    spec:
  type: ClusterIP
  selector:
    app: orderer
  ports:
  - name: "orderer-metrics"
    targetPort: 9444 # container metric port
    port: 9444

پورت هدف 9444 پورت متریک کانتینر است که یک پورت باز 9444 دارد.

سرویس پورت 9444 کانتینر را به IP خارجی گره: پورت برای همه کانتینرها با برچسب app:orderer نگاشت.

استقرار Orderer در Kubernetes

بیایید با دستور Vagrant ssh به ماشین مجازی kubernetes master node متصل شویم.


    $ vagrant ssh k8smaster

بیایید به دایرکتوری برویم که اسکریپت های نصب kubernetes در آن قرار دارند. این دایرکتوری همان پوشه deploy/k8s در پروژه است. با Vagrant، این دایرکتوری با ماشین مجازی همگام سازی می شود.


    $ cd /vagrant/k8s

استقرار استقرارها، خدمات برای سفارش دهنده.


    $ kubectl apply -f orderer/

ایجاد سفارش در انتظار تکمیل است.


    $ kubectl wait --for condition=available --timeout=300s deployment -l "app in (orderer,orderer2,orderer3,orderer4,orderer5)"

سفارش دهنده با موفقیت ایجاد شد.

در نهایت، بیایید شرایط غلاف هایی را که از ایده لنز اجرا می کنیم، بررسی کنیم.

در نهایت، بیایید شرایط غلاف هایی را که از ایده لنز اجرا می کنیم، بررسی کنیم.

به نظر می رسد وضعیت غلاف های سفارش دهنده در حال اجرا است.

در کل Orderer را معرفی کردم و نحوه استقرار این ابزارها را در Kubernetes توضیح دادم.

سعیده بیات

دیدگاه‌ خود را بنویسید لغو پاسخ

آرتا رسانه

دیجیتال مارکتینگ چیست؟

00:00 / 17:32