Deploying a production network ============================== このデプロイメントガイドは、ベストプラクティスやデプロイ時に注意すべき多くの考慮事項に加えて、Fabricネットワークコンポーネントをセットアップするための適切なシーケンスの概要を高い水準で説明したものです。このトピックでは、一個人の視点から総合的なプロセスとして「ネットワークの構築」について説明していることに注意してください。どちらかといえば、現実世界の本番用ネットワークは一個人によって設定されるのではなく、複数の人(例えば、それぞれが独自のコンポーネントを設定する銀行の集合)によって指示される共同作業として設定される可能性が高いでしょう。 Fabricネットワークをデプロイするためのプロセスは複雑であり、公開鍵基盤と分散型システムの管理を理解していることが前提です。スマートコントラクトまたはアプリケーション開発者の場合、プロダクションレベルのFabricネットワークのデプロイで、このレベルの専門知識は必要ないはずです。このデプロイメントガイドは、ベストプラクティスやデプロイ時に注意すべき多くの考慮事項に加えて、Fabricネットワークコンポーネントをセットアップするための適切なシーケンスの概要を高い水準で説明したものです。しかし、効果的なスマートコントラクトやアプリケーションを開発するために、ネットワークがどのようにデプロイするされているかを知っておく必要があるかもしれません。 チェーンコード、スマートコントラクト、アプリケーションをテストするための開発環境があれば、 :doc:`test_network` を調べてみてください。デプロイするネットワークには、2つの組織が含まれ、それぞれが1つのピアを所有し、1つのオーダリングサービス組織が1つのオーダリングノードを所有します。**このテストネットワークは、本番用コンポーネントをデプロイするための青写真を提供することを意図したものではありません。本番デプロイでは行わないような仮定や決定を行うため、そのように使用すべきではありません。** このガイドでは、本番コンポーネントと実稼動ネットワークを設定する手順の概要を説明します。 - :ref:`dg-step-one-decide-on-your-network-configuration` - :ref:`dg-step-two-set-up-a-cluster-for-your-resources` - :ref:`dg-step-three-set-up-your-cas` - :ref:`dg-step-four-use-the-ca-to-create-identities-and-msps` - :ref:`dg-step-five-deploy-nodes` - :ref:`dg-create-a-peer` - :ref:`dg-create-an-ordering-node` .. _dg-step-one-decide-on-your-network-configuration: Step one: Decide on your network configuration ---------------------------------------------- ブロックチェーンネットワークの構造は、それが提供するユースケースによって決定されます。すべての点について明確な指針を提供するには選択肢が多すぎますが、いくつかのシナリオを考えてみましょう。 開発環境や概念実証とは対照的に、本番で運用する場合は、セキュリティ、リソース管理、高可用性が優先されます。高可用性を満たすために必要なノードはいくつか、また、ディザスターリカバリとデータレジデンシーの両方のニーズを満たすために、どのデータセンターにそれらをデプロイしたいですか?あなたの秘密鍵と信頼のルートが安全であることをどのように保証しますか? 上記に加えて、コンポーネントをデプロイする前に行う必要がある決定の例を次に示します。 * **認証局設定** ピア(それぞれのチャネルの数など)とオーダリングサービス(ノードの数、それらを所有する人)について、決定しなければならない全体的な決定の一部として、組織のCAをどのように展開するかについても決定する必要があります。本番ネットワークは、Transport Layer Security(TLS)を使用する必要があります。これには、TLS CAを設定し、それを使用してTLS証明書を生成する必要があります。このTLS CAは、登録CAの前にデプロイする必要があります。これについては、 :ref:`dg-step-three-set-up-your-cas` で詳しく説明します。 * **組織単位（OU）を使うかどうか?** いくつかの組織では、特定のアイデンティティと単一のCAによって作成されたMSPとの間に分離を作成するために、組織単位を設置する必要がある場合があります(たとえば、製造業者は、出荷部門に1つの組織単位を、品質管理部門に別のものを必要とする場合があります)。これは"Node OU"の概念とは別のものであることに注意してください。"Node OU"では、アイデンティティは役割をコード化することができます(たとえば、"admin"または"peer")。 * **データベース タイプ** ネットワーク内のチャネルによっては、すべてのデータを :doc:`couchdb_as_state_database` が理解できる方法でモデル化する必要があるかもしれません。一方で、速度を優先する他のネットワークは、すべてのピアがLevelDBを使用することを決定する可能性があります。チャネルは、CouchDBとLevelDBの両方を使用するピアを持つべきではないことに注意してください。なぜなら、CouchDBはキーと値にいくつかのデータ制限を課しているからです。LevelDBの正当なキーや値は、CouchDBでは正当ではないかもしれません。 * **チャネルとプライベートデータ** ネットワークによっては、 :doc:`channels` が特定のトランザクションのプライバシーと隔離を確保する最善の方法であると判断するかもしれません。他の場合は、少ないチャネルで、必要に応じて :doc:`private-data/private-data` コレクションで補完する方が、それらのプライバシーの必要性をより満たすと判断するかもしれません。 * **コンテナオーケストレーション** 異なるユーザーはまた、コンテナオーケストレーションに関して異なる決定を行い、ピアプロセス、ロギング、CouchDB、gRPC通信、およびチェーンコードのために別々のコンテナを作成し、他のユーザーがこれらのプロセスを組み合わせることを決定するかもしれません。 * **チェーンコード デプロイメント メソッド** ユーザーは、組み込みのビルドと実行のサポートを実行するか、カスタマイズされたビルドと :doc:`cc_launcher` を使用して実行するか、または :doc:`cc_service` を使用して、チェーンコードをデプロイすることができます。 * **ファイアウォールの使用** 本番のデプロイでは、ある組織に属するコンポーネントが他の組織のコンポーネントにアクセスする必要があり、ファイアウォールと高度なネットワーク設定を使用する必要があります。たとえば、Fabric SDKを使用するアプリケーションでは、すべての組織からすべてのエンドーシングピアにアクセスし、すべてのチャネルのオーダリングサービスにアクセスする必要があります。同様に、ピアは、新しいブロックを受信しているチャネルのオーダリングサービスにアクセスする必要があります。 しかし、コンポーネントがどこにデプロイされていても、ネットワークを効率的に運用するためには、選択した管理システム(Kubernetesなど)の高度な専門知識が必要です。同様に、ネットワークの構造は、ビジネスユースケース向けや、ネットワークが機能するように設計される業会の関連する法律や規制に適合するように設計されなければなりません。 このデプロイメントガイドでは、すべてのイテレーションと潜在的なネットワーク設定を説明するのではなく、考慮すべき共通のガイドラインとルールを示しています。 .. _dg-step-two-set-up-a-cluster-for-your-resources: Step two: Set up a cluster for your resources --------------------------------------------- 一般的に、Fabricはデプロイに使われている方法やそれを管理する方法に依存していません。たとえば、ラップトップでデプロイやピアを管理することができます。いくつかの理由から、これは望ましくないと思われますが、Fabricにはそれを禁止するものはありません。 ローカル(またはファイアウォールの背後)であれ、クラウド内であれ、コンテナをデプロイするできる限り、コンポーネントを立ち上げて相互に接続することは可能です。しかし、Kubernetesには多くの便利なツールがあり、Fabricネットワークを展開し管理するためのコンテナ管理プラットフォームとして人気があります。Kubernetesの詳細については、 `the Kubernetes documentation `_ を参照してください。このトピックでは、その範囲を主にバイナリに限定し、DockerデプロイメントまたはKubernetesを使用する際に適用できる手順を提供します。 どこにどのようにコンポーネントをデプロイすることを選択するにしても、コンポーネントを効果的に実行するために十分なリソースがあることを確認する必要があります。必要なサイズは、ユースケースによって大きく異なります。1つのピアからいくつかの流量の多いチャネルにジョインすると、1つのチャネルに参加する場合よりもはるかに多くのCPUとメモリが必要になります。大まかな見積もりとして、1つのオーダリングノードに割り当てる計画のリソースの3倍を1つのピアに割り当てるように計画します(以下で説明するように、1つのオーダリングサービスに少なくとも3つ、最適には5つのノードを割り当てることをお勧めします)。同様にCAの場合は、ピアの場合の約10分の1のリソースが必要です。また、クラスタにストレージを追加する必要があります(一部のクラウドプロバイダーは、ストレージを提供している場合があります)。これは、ストレージが最初にクラウドプロバイダーとセットアップされていないと、Persistent Volume(永続ボリューム)とPersistent Volume Claimの設定ができないためです。永続ストレージを使用することで、MSP、台帳、インストールされたチェーンコードなどのデータがコンテナファイルシステムに保存されないようにし、コンテナが破壊されてもそれらが破壊されないようにします。 概念実証ネットワークをデプロイし、負荷をかけてテストすることで、必要となるリソースをよりよく理解できます。 Managing your infrastructure ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ バックエンドの管理に使用する正確な方法とツールは、選択したバックエンドによって異なります。ただし、ここで注意すべき事項がいくつかあります。 * シークレットオブジェクトを使用して、重要な設定ファイルをクラスタに安全に保存します。Kubernetesのシークレットについては、 `Kubernetes secrets `_ を参照してください。また、ハードウェアセキュリティモジュール(HSM)または暗号化された永続ボリューム(PV)を使用するオプションもあります。同様に、Fabricコンポーネントをデプロイした後は、例えば、Docker Hubのようなサービスのプライベートなリポジトリを使用したりなど、自分のバックエンドのコンテナに接続したいと思うでしょう。その場合は、ログイン情報をKubernetesシークレットの形式でコーディングし、コンポーネントをデプロイするときにYAMLファイルに含める必要があります。 * クラスタの考慮事項とノードのサイジング。上記のステップ2では、ノードのサイズをどのように考えるかについての一般的な概要を説明しました。あなたのユースケースは、力強い発展の時期と同様に、ピア、オーダリングノード、そしてCAがどの程度の規模が必要かを本当に知ることができる唯一の方法です。 * ボリュームをマウントする方法の選択。これは、ノードがデプロイされている場所の外部にあるノードに関連するボリュームをマウントするベストプラクティスです。これにより、暗号マテリアルの再デプロイや再生成しなくても、後でこれらのボリュームを参照することができます(例えば、クラッシュしたノードやコンテナの再起動)。 * リソースを監視する方法。個々のノードで使用されるリソースと、一般的にクラスタにデプロイされたリソースを監視するための戦略と方法を確立することが重要です。ピアがより多くのチャネルに参加すると、CPUとメモリの割り当てを増やす必要があります。同様に、ステートデータベースとブロックチェーンのために、十分な保管スペースがあることを確認する必要があります。 .. _dg-step-three-set-up-your-cas: Step three: Set up your CAs --------------------------- Fabricネットワークに最初に配備しなければならないコンポーネントはCAです。これは、ノードに関連付けられた証明書(ノード自体だけでなく、ノードを管理できる人を識別する証明書も)は、ノード自体をデプロイする前に作成する必要があるためです。これらの証明書を作成するためにFabric CAを使用する必要はありませんが、Fabric CAはまた、コンポーネントと組織が適切に定義されるために必要なMSP構造を作成します。ユーザーがFabric CA以外のCAを使用する場合は、MSPフォルダを自分で作成する必要があります。 * 1つのCA(中間CAを使用している場合はそれ以上)は、(「エンロールメント」と呼ばれるプロセスを介して)組織の管理者、その組織のMSP、およびその組織が所有するノードの証明書を生成するために使用されます。このCAは、追加のユーザーの証明書も生成します。「エンローリング」アイデンティティのロールのために、このCAは「エンロールメントCA」または「ECert CA」と呼ばれることがあります。 * もう一方のCAは、Transport Layer Security(TLS)上の通信を保護するために使用される証明書を生成します。このため、このCAはしばしば「TLS CA」と呼ばれます。これらのTLS証明書は、「中間者」攻撃を防止する方法としてアクションに添付されます。TLS CAはノードの証明書の発行にのみ使用され、そのアクティビティが完了したときにシャットダウンできることに注意してください。ユーザーは、片方向（クライアントのみ）のTLSと、双方向（サーバーとクライアント）のTLSを使用することができ、後者は「相互TLS」とも呼ばれます。「エンロールメント」CAをデプロイする前に、ネットワークがTLSを使用するように指定すること(推奨)を決定する必要があるため(このCAの設定を指定するYAMLファイルには、TLSを有効にするためのフィールドがあります)、まずTLS CAをデプロイし、エンロールメントCAをブートストラップするときに、そのルート証明書を使用する必要があります。このTLS証明書は、ユーザーおよびノードのエンロールアイデンティティへのエンロールメントCAに接続する際に、 ``fabric-ca client`` によっても使用されます。 組織に関連付けられたすべての非TLS証明書は、単一の「ルート」CA(つまり、自身の信頼のルートのCA)によって作成できますが、セキュリティを高めるため、組織はルートCA(または最終的にルートCAにつながる別の中間CA)によって証明書が作成される「中間」CAを使用することを決定できます。ルートCAでの侵害は、その信頼ドメイン全体(管理者、ノード、および証明書を生成したCAの証明書)の崩壊につながるため、中間CAはルートCAの公開を制限する有用な方法です。中間CAの利用を選択するかどうかは、ユースケースのニーズによって異なります。必須ではありません。すでにこの実装を持っていて、既存のインフラストラクチャにアイデンティティ管理のレイヤを追加したくないエンタープライズのために、Lightweight Directory Access Protocol(LDAP)を設定して、Fabricネットワーク上のアイデンティティを管理することも可能です。LDAPは、効果的にディレクトリのすべてのメンバーを事前登録し、与えられた基準に基づいてエンロールを許可します。 **本番用ネットワークでは、エンロールメント用とTLS用に、1組織につき少なくとも1つのCAをデプロイすることを推奨します。**たとえば、1つの組織に関連付けられた3つのピアと1つのオーダリング組織に関連付けられたオーダリングノードをデプロイすると、少なくとも4つのCAが必要になります。2つのCAはピア組織用(ピア、管理者、通信、および組織を表すMSPのフォルダ構造用のエンロールメント証明書とTLS証明書を生成)で、残りの2つのCAはオーダリング組織用です。ユーザは通常、エンロールメントCAにのみ登録、エンロールします。一方、ノードは、エンロールメントCA(ノードは、そのアクションを署名しようとするときに識別する署名証明書を取得します)とTLS CA(通信を認証するために使用するTLS証明書を取得します)の両方に登録、エンロールします。 組織CAとTLS CAを設定し、管理者アイデンティティをエンロールする方法の例については、 `Fabric CA Deployment Guide `__ を参照してください。デプロイするガイドは、Fabric CAクライアントを使用して、CAを設定する際に必須であるアイデンティティを登録し、エンロールします。 .. toctree:: :maxdepth: 1 :caption: Deploy a Production CA Planning for a CA Checklist for a production CA server CA deployment steps .. _dg-step-four-use-the-ca-to-create-identities-and-msps: Step four: Use the CA to create identities and MSPs --------------------------------------------------- CAを作成したら、それを使用して、組織(MSPで表される)に関連するアイデンティティとコンポーネントの証明書を作成できます。各組織について、少なくとも次のことが必要です。 * **管理者アイデンティティの登録と登録、MSPの作成** 組織に関連付けられるCAが作成された後、まずユーザーを登録し、次にアイデンティティをエンロールするために使用できます(ネットワーク上のすべてのエンティティによって使用される証明書ペアを生成します)。最初のステップでは、アイデンティティのユーザー名とパスワードがCAの管理者によって割り当てられます。属性と所属をアイデンティティに与えることもできます(例えば、組織管理者に必要な ``admin`` の ``ロール``)。アイデンティティの登録後、ユーザー名とパスワードを使用して登録できます。CAは、このアイデンティティに対して2つの証明書を生成します。1つは、ネットワークの他のメンバーに知られている公開証明書("signcert"または"パブリック証明書"としても知られている)であり、もう1つは秘密鍵( ``keystore`` フォルダに格納されている)であり、アイデンティティが実行したアクションを署名するのに使用されます。CAはまた、"MSP"と呼ばれるフォルダのセットを生成します。これには、証明書を発行するCAの公開証明書とCAの信頼のルートが含まれます(これは同じCAである場合とない場合があります)。このMSPは、管理者のアイデンティティに関連する組織を定義するものと考えることができます。組織の管理者がノードの管理者でもある場合(これは典型的です)、 **ノード管理者の証明書をローカルMSPの作成時に使用する必要があるため、ノードのローカルMSPを作成する前に、組織の管理者アイデンティティを作成する必要があります。** * **ノードアイデンティティのエンロールと登録。** 組織管理者アイデンティティが登録およびエンロールされるのと同様に、ノードのアイデンティティは、エンロールメントCAとTLS CAの両方に登録およびエンロールされる必要があります(後者は通信を保護するために使用される証明書を生成します)。エンロールメントCAに登録する際、ノードに ``admin`` または ``user`` というロールを与える代わりに、 ``peer`` または ``orderer`` のロールを与えます。adminと同様に、このアイデンティティの属性と所属も割り当てることができます。アイデンティティに割り当てられた権限はローカル(ノード)レベルでのみ関連するため、ノードのMSP構造は"ローカルMSP"と呼ばれます。このMSPは、ノードアイデンティティの作成時に生成され、ノードをブートストラップする時に使用されます。 Fabricベースのブロックチェーンネットワークにおけるアイデンティティと許可に関する概念的な情報については、 :doc:`identity/identity` と :doc:`membership/membership` を参照してください。 CAを使用してアイデンティティを登録する方法(サンプルコマンドを含む)の詳細については、 `Registering and enrolling identities with a CA `_ を参照してください。 .. _dg-step-five-deploy-nodes: Step five: Deploy peers and ordering nodes ------------------------------------------ 必要な証明書とMSPをすべて収集したら、ノードを作成する準備はほぼ完了です。前述したように、ノードをデプロイする有効な方法はいくつかあります。 ノードをデプロイするまえに、その設定ファイルをカスタマイズする必要があります。ピアの場合のファイルは ``core.yaml`` と呼ばれ、オーダリングノードの設定ファイルは ``orderer.yaml`` と呼ばれます。 設定を調整するには、主に3つの選択肢があります。 1. バイナリにバンドルされたYAMLファイルを編集する。 2. デプロイ時に環境変数のオーバーライドを使用する。 3. CLIコマンドのフラグを指定する。 選択肢1は、ノードを停止して再起動するたびに変更を保持するという利点があります。欠点は、新しいバイナリバージョンにアップグレードするときに、カスタマイズしたオプションを新しいYAMLに移植する必要があることです(新しいバージョンにアップグレードするときは最新のYAMLを使用する必要があります)。 .. note:: YAMLファイル内のパラメータから環境変数を推定するには、すべて大文字で、関連フレーズ間にアンダースコア、プレフィックスを使用します。例えば、 ``core.yaml`` にあるピアの ``peer.localMSPid`` と呼ばれる設定変数( ``peer`` 設定セクション内の ``localMSPid`` 変数)は、 ``CORE_PEER_LOCALMSPID`` と呼ばれる環境変数としてレンダリングされ、 ``orderer.yaml`` 設定ファイルの ``General`` セクションのオーダリングサービスの環境変数 ``General.LocalMSPID`` は、 ``ORDERER_GENERAL_LOCALMSPID`` と呼ばれる環境変数としてレンダリングされます。 .. _dg-create-a-peer: Creating a peer ~~~~~~~~~~~~~~~ もし :doc:`peers/peers` のキーのコンセプトのトピックを読み終えた方なら、ピアがネットワークで果たす役割と、他のネットワークコンポーネントとのやりとりの性質について良い考えを持つことができるはずです。ピアは、チャネルのメンバーである組織によって所有されます(このため、これらの組織は「ピア組織」と呼ばれることがあります)。ピアはオーダリングサービスや他のピアに接続し、スマートコントラクトがインストールされて、台帳が保存されています。 これらの役割は、カスタマイズやデプロイの決定に影響を与えるため、ピアを作成する前に理解することが重要です。しなければならない様々な決定については、 :doc:`deploypeer/peerplan` をご覧ください。 ピアの ``core.yaml`` ファイル内の設定値は、カスタマイズするか、環境変数で上書きする必要があります。デフォルトの ``core.yaml`` 設定ファイルは、 `Hyperledger Fabricのsampleconfigディレクトリ `_ にあります。この設定ファイルはピアイメージにバンドルされており、ダウンロード可能なバイナリファイルにも含まれています。本番の ``core.yaml`` とピアイメージをダウンロードする方法については、 :doc:`deploypeer/peerdeploy` を参照してください。 デフォルトの ``core.yaml`` には多くのパラメータがありますが、カスタマイズする必要があるのはごく一部です。通常、チューニング値を変更する必要がない場合は、デフォルト値を使用してください。 ``core.yaml`` のパラメータには次のものがあります。 * **Identifiers**: これらには、関連するローカルMSPおよびTransport Layer Security(TLS)証明書へのパスだけでなく、ピアの名前(「peer ID」として知られる)およびピアを所有する組織のMSP IDも含まれます。 * **Addresses and paths**: ピアはそれ自体で独立して動くのではなく、他のピアやコンポーネントとやりとりするため、設定で一連のアドレスを指定する必要があります。これらには、他のコンポーネントがピア自体を検出するためのアドレスや、チェーンコード(外部チェーンコードを使用している場合)などを検出するアドレスが含まれます。同様に、台帳の場所(およびステートデータベースのタイプ)と外部ビルダーへのパスを指定する必要があります(外部チェーンコードを使用する場合も同様)。これらには **Operations and metrics** が含まれます。これにより、エンドポイントの設定を通じて、ピアの健全性とパフォーマンスを監視するための方法を設定できます。 * **Gossip**: Fabricネットワーク内のコンポーネントは、「ゴシップ」プロトコルを使用して相互に通信します。このプロトコルを通じて、それらはディスカバリサービスによって発見され、ブロックとプライベートデータを互いに配布することができます。なお、ゴシップ通信はTLSを利用して保護されています。 ``core.yaml`` とその特定のパラメータの詳細については、 :doc:`deploypeer/peerchecklist` を参照してください。 ピアの設定方法、ボリュームのマウント方法、およびバックエンド設定に問題がなければ、コマンドを実行してピアを起動できます(このコマンドはバックエンド設定によって異なります)。 .. toctree:: :maxdepth: 1 :caption: Deploying a production peer deploypeer/peerplan deploypeer/peerchecklist deploypeer/peerdeploy .. _dg-create-an-ordering-node: Creating an ordering node ~~~~~~~~~~~~~~~~~~~~~~~~~ Note: オーダリングサービスにノードを追加することもできますが、このチュートリアルではオーダリングサービスを作成するためのプロセスのみ説明します。 もし :doc:`orderer/ordering_service` のキーコンセプトトピックを読み終えた方なら、オーダリングサービスがネットワークで果たす役割と、他のネットワークコンポーネントとのやりとりの性質について良い考えを持つことができるはずです。オーダリングサービスは、文字通り、ブロックで承認されたトランザクションを「順序付けする」責任があり、それによってピアは検証し台帳にコミットします。 これらの役割は、カスタマイズやデプロイの決定に影響を与えるため、オーダリングサービスを作成する前に理解することが重要です。ピアとオーダリングサービスの主な違いは、実稼動ネットワークでは複数のオーダリングノードが連携して、チャネルの「オーダリングサービス」を形成することです。これにより、ノードレベルとクラスタレベルの両方で行う必要のある一連の重要な決定が作成されます。これらのクラスタ決定のいくつかは、個々のオーダリングノード ``orderer.yaml`` ファイルで行われるのではなく、システムチャネルのジェネシスブロックを生成するために使用される ``configtx.yaml`` ファイル(オーダリングノードをブートストラップするために使用される)で行われ、アプリケーションチャネルのジェネシスブロックを生成するためにも使用されます。しなければならない様々な決定については、 :doc:`deployorderer/ordererplan` をご覧ください。 オーダリングノードの ``orderer.yaml`` ファイル内の設定値は、カスタマイズするか環境変数で上書きする必要があります。デフォルトの ``orderer.yaml`` 設定ファイルは、 `Hyperledger Fabricのsampleconfigディレクトリ `_ にあります。 この設定ファイルはordererイメージにバンドルされており、ダウンロード可能なバイナリファイルにも含まれています。本番の ``orderer.yaml`` とordererイメージをダウンロードする方法については、 :doc:`deployorderer/ordererdeploy` を参照してください。 デフォルトの ``orderer.yaml`` には多くのパラメータがありますが、カスタマイズする必要があるのはごく一部です。通常、チューニング値を変更する必要がない場合は、デフォルト値を使用してください。 ``orderer.yaml`` のパラメータには次のものがあります。 * **Identifiers**: これらには、関連するローカルMSPおよびTransport Layer Security(TLS)証明書へのパスだけでなく、オーダリングノードを所有する組織のMSP IDも含まれます。 * **Addresses and paths**: オーダリングノードは他のコンポーネントとやり取りするため、設定で一連のアドレスを指定する必要があります。これらには、他のコンポーネントや **Operations and metrics** がオーダリングノード自体を検出するためのアドレスが含まれます。これにより、エンドポイントの設定を通じて、オーダリングノードの健全性とパフォーマンスを監視するための方法を設定できます。 ``orderer.yaml`` とその特定のパラメータの詳細については、 :doc:`deployorderer/ordererchecklist` を参照してください。 オーダリングノードの設定方法、ボリュームのマウント方法、およびバックエンド設定に問題がなければ、コマンドを実行してオーダリングノードを起動できます(このコマンドはバックエンド設定によって異なります)。 .. toctree:: :maxdepth: 1 :caption: Deploying a production ordering node deployorderer/ordererplan deployorderer/ordererchecklist deployorderer/ordererdeploy Next steps ---------- ブロックチェーンのネットワークは接続がすべてなので、ノードをデプロイしたら、他のノードに接続したいと思うのは当然です！ピア組織とピアがある場合は、組織をコンソーシアムに参加させ、または :doc:`channels` に参加することになります。オーダリングノードがある場合は、コンソーシアムにピア組織を追加します。また、チェーンコードの開発についても学びたい場合は、 :doc:`developapps/scenario` と :doc:`chaincode4ade` のトピックで学ぶことができます。 ノードを接続してチャネルを作成するプロセスの一部には、ビジネスネットワークのユースケースに合わせてポリシーを変更することが含まれます。ポリシーの詳細については、 :doc:`policies/policies` を参照してください。 Fabricの一般的なタスクの1つは、既存のチャネルの編集です。そのプロセスのチュートリアルについては、 :doc:`config_update` をご覧ください。人気のあるチャネル更新の1つは、既存のチャネルに組織を追加することです。その特定のプロセスに関するチュートリアルについては、 :doc:`channel_update_tutorial` をご覧ください。デプロイ後のノードのアップグレードについての情報は、 :doc:`upgrading_your_components` を参照してください。 .. Licensed under Creative Commons Attribution 4.0 International License https://creativecommons.org/licenses/by/4.0/