The Operations Service¶
ピアとOrdererは、RESTfulな「運用 (Operations)」APIを提供するHTTPサーバーをホストします。 このAPIはFabricネットワークサービスとは無関係であり、ネットワークの管理者や「ユーザー」ではなく、運用者が使用することを意図しています。
API は以下の機能を公開しています。
- ログレベル管理
- ヘルスチェック
- 運用メトリクスのPrometheusのターゲット (設定されている場合)
- バージョン情報を取得するためのエンドポイント
Configuring the Operations Service¶
運用サービスには、次の2つの基本設定が必要です。
- Listenする アドレス および ポート 。
- 認証と暗号化に使用する TLS証明書 と 鍵。 注:これらの証明書は、個別の専用のCAによって生成される必要があります。 すべてのチャネル・組織のための証明書を発行するような (単一の) CAを使わないでください。
Peer¶
ピアごとに、運用 (API) サーバーは core.yaml
の operations
セクションで設定することができます:
operations:
# 運用サーバーのホストとポート
listenAddress: 127.0.0.1:9443
# 運用サービスエンドポイントのTLS設定
tls:
# TLSが有効かどうか
enabled: true
# 運用サーバー用のPEMエンコードされたサーバー証明書へのパス
cert:
file: tls/server.crt
# 運用サーバのPEMエンコードされたサーバ秘密鍵へのパス
key:
file: tls/server.key
# TLSが有効になっている場合、ほとんどの運用サービスエンドポイントではクライアント認証が必要です。
# clientAuthRequiredを有効にすると、すべてのリソースにアクセスするためにTLS層でクライアント証明書認証を必要とするようになります。
clientAuthRequired: false
# クライアント認証のために信頼する、PEMエンコードされたCA証明書へのパス
clientRootCAs:
files: []
listenAddress
キーは、運用サーバーがListenするホストとポートを定義します。サーバーがすべてのアドレスをListenする必要がある場合は、ホスト部分を省略できます。
tls
セクションは、運用サービスでTLSが有効になっているかどうか、サービスの証明書と秘密鍵の場所、
およびクライアント認証で信頼される認証局のルート証明書の場所を示すために使用されます。 enabled
がtrueの場合、
ほとんどの運用サービスエンドポイントはクライアント認証を必要とするため、
clientRootCAs.files
を設定する必要があります。clientAuthRequired
が true
の場合、
TLS層はクライアントがすべてのリクエストで認証用の証明書を提供することを要求します。
詳細については、以下のOperations Securityセクションを参照してください。
Orderer¶
Ordererごとに、運用サーバーは orderer.yaml
の Operations セクションで設定することができます:
Operations:
# 運用サーバーのホストとポート
ListenAddress: 127.0.0.1:8443
# 運用サービスエンドポイントのTLS設定
TLS:
# TLSが有効かどうか
Enabled: true
# PrivateKey: 運用エンドポイントのPEMエンコードされたTLS秘密鍵
PrivateKey: tls/server.key
# 証明書は、サーバーのTLS証明書のファイルの場所を管理します
Certificate: tls/server.crt
# クライアント認証のために信頼する、PEMエンコードされたCA証明書へのパス
ClientRootCAs: []
# TLSが有効になっている場合、ほとんどの運用サービスエンドポイントではクライアント認証が必要です。
# ClientAuthRequiredを有効にすると、すべてのリソースにアクセスするためにTLS層でクライアント証明書認証を必要とするようになります。
ClientAuthRequired: false
listenAddress
キーは、運用サーバーがListenするホストとポートを定義します。サーバーがすべてのアドレスをListenする必要がある場合は、ホスト部分を省略できます。
TLS
セクション は、運用サービスでTLSが有効になっているかどうか、サービスの証明書と秘密鍵の場所、
およびクライアント認証で信頼される認証局のルート証明書の場所を示すために使用されます。 Enabled
がtrueの場合、
ほとんどの運用サービスエンドポイントはクライアント認証を必要とするため、
RootCAs
を設定する必要があります。ClientAuthRequired
が true
の場合、
TLS層はクライアントがすべてのリクエストで認証用の証明書を提供することを要求します。
詳細については、以下のOperations Securityセクションを参照してください。
Operations Security¶
運用サービスは運用に特化しており、 意図的にFabricネットワークとは無関係であるため、 アクセス制御にメンバーシップサービスプロバイダ (MSP) を使用しません。 代わりに、運用サービスはクライアント証明書認証による相互TLSに完全に依存しています。
TLSを無効にすると、認証がバイパスされ、運用エンドポイントに接続できるすべてのクライアントがAPIを使用できるようになります。
TLSが有効になっている場合、以下で特に明記がない限りすべてのリソースにアクセスするために、有効なクライアント証明書を提供する必要があります。
clientAuthRequiredも有効になっている場合、アクセスされるリソースに関係なく、TLS層は有効なクライアント証明書を要求します。
Log Level Management¶
運用サービスは、運用者がピアまたはOrdererのアクティブなロギングスペック (logging spec) を管理するために使用できる /logspec
リソースを提供します。
リソースは従来のRESTリソースであり、 GET
および PUT
リクエストをサポートします。
運用サービスが GET /logspec
リクエストを受け取ると、現在のロギング仕様を含むJSONペイロードを返します:
{"spec":"info"}
運用サービスが PUT /logspec
リクエストを受け取ると、ボディをJSONペイロードとして読み取ります。
ペイロードは、 spec
という名前の単一の属性で構成されている必要があります。
{"spec":"chaincode=debug:info"}
スペックが正常にアクティブ化された場合、
サービスは 204 "No Content"
レスポンスを返します。
エラーが発生した場合、サービスは 400 "Bad Request"
とエラーペイロードを返します:
{"error":"error message"}
Health Checks¶
運用サービスは、運用者がピアやOrdererの生死と健康状態を判断するのに役立つ /healthz
リソースを提供します。
リソースは、GETリクエストをサポートする従来のRESTリソースです。
この実装は、Kubernetesで使用されるliveness probeとの互換性を意図としていますが、他のコンテキストでも使用できます。
GET /healthz
リクエストを受け取ると、
運用サービスはプロセスに登録されているすべてのヘルスチェッカーを呼び出します。
すべてのヘルスチェッカーから成功が返ってきたら、運用サービスは 200 "OK"
と以下のようなJSONボディを返します:
{
"status": "OK",
"time": "2009-11-10T23:00:00Z"
}
1つ以上のヘルスチェッカーがエラーを返した場合、
運用サービスは 503 "Service Unavailable"
と、どのヘルスチェッカーが失敗したかに関する情報を含むJSONボディで応答します。
{
"status": "Service Unavailable",
"time": "2009-11-10T23:00:00Z",
"failed_checks": [
{
"component": "docker",
"reason": "failed to connect to Docker daemon: invalid endpoint"
}
]
}
現在のバージョンでは、登録されているヘルスチェックはDockerのみです。 将来のバージョンでは、他のヘルスチェックが追加できるように拡張される予定です。
TLSが有効な場合、 clientAuthRequired
が true
に設定されていない限り、
このサービスを使用するために有効なクライアント証明書は必要ありません。
Metrics¶
FabricのピアおよびOrdererの一部のコンポーネントは、 システムの動作に関する洞察を提供するのに役立つメトリクスを公開します。 運用者と管理者は、この情報を使用して、システムが時間経過とともにどのように動いているかをよりよく理解できます。
Configuring Metrics¶
Fabricは、Prometheusをベースにした プル型 (pull) モデルとStatsDをベースにした プッシュ型 (push) モデルの2つの方法でメトリクスを提供します。
Prometheus¶
典型的なPrometheusデプロイメントは、 インストルメント化されたターゲットによって公開されたHTTPエンドポイントからメトリックスを要求することにより、 メトリックスをスクレイピングします。 Prometheusがメトリクスの要求をするため、プル型システムと見なされます。
設定されている場合、FabricのピアまたはOrdererは運用サービス上に /metrics
リソースを提示します。
Peer¶
ピアは、 core.yaml
の metrics
セクションでメトリックプロバイダを prometheus
に設定することで、
Prometheusが metrics
エンドポイントを公開してスクレイピングするように設定できます。
metrics:
provider: prometheus
Orderer¶
Ordererは、 orderer.yaml
の metrics
セクションでメトリクスプロバイダを prometheus
に設定することで、
Prometheusが metrics
エンドポイントを公開してスクレイピングするように設定できます。
Metrics:
Provider: prometheus
StatsD¶
StatsDはシンプルな統計情報集約デーモンです。
メトリクスは statsd
デーモンに送信され、
そこで収集、集約され、視覚化とアラートのためにバックエンドにプッシュされます。
このモデルでは、メトリックスデータをStatsDに送信するためにインストルメント化されたプロセスが必要であるため、
これはプッシュ型システムと見なされます。
Peer¶
ピアは、 core.yaml
の metrics
セクションでメトリクスプロバイダを statsd
に設定することにより、
メトリックスをStatsDに送信するように設定できます。
statsd
サブセクションはStatsDデーモンのアドレス、使用するネットワークタイプ ( tcp
または udp
)、
およびメトリックスを送信する頻度で構成する必要もあります。
オプションの prefix
を指定して、メトリックスのソースを区別することができます (たとえば、別のピアからのメトリックスと区別)。
このプレフィックスは生成されたすべてのメトリックスの前に付加されます。
metrics:
provider: statsd
statsd:
network: udp
address: 127.0.0.1:8125
writeInterval: 10s
prefix: peer-0
Orderer¶
Ordererは、 orderer.yaml
の metrics
セクションでメトリクスプロバイダを statsd
に設定することにより、
メトリックスをStatsDに送信するように設定できます。
statsd
サブセクションはStatsDデーモンのアドレス、使用するネットワークタイプ ( tcp
または udp
)、
およびメトリックスを送信する頻度で構成する必要もあります。
オプションの prefix
を指定して、メトリックスのソースを区別することができます。
Metrics:
Provider: statsd
Statsd:
Network: udp
Address: 127.0.0.1:8125
WriteInterval: 30s
Prefix: org-orderer
生成されるさまざまなメトリックスについては、 Metrics Reference を参照してください。
Version¶
Ordererとピアの両方が /version
エンドポイントを公開します。
このエンドポイントは、Ordererまたはピアのバージョンと、リリースが作成されたコミットSHAを含むJSONドキュメントを提供します。