この記事は、Hyperledger Fabricという企業向けのブロックチェーン基盤を、Kubernetes上に構築していく開発日記の4日目の記録です。
タイトルだけ見るとかなり硬そうですが、内容はむしろ「地味で面倒なところを、どうやって本番運用に耐える形へ持っていったか」という実践寄りの話です。
ここが面白いところで、ブロックチェーンって「未来っぽい」響きがありますが、実際に動かすとなると、かなり泥臭いインフラ作業になるんですよね。この記事はその現実をちゃんと見せています。
まず前提として、Hyperledger Fabricは許可型ブロックチェーンです。
ざっくり言うと、「誰でも参加できる公開チェーン」ではなく、参加者を管理できる企業向けの仕組みです。サプライチェーン、金融、医療のような場面で使われやすい、と記事では説明されています。
一方のKubernetesは、コンテナをまとめて管理するための仕組みです。
簡単に言えば、壊れたら自動で立て直す、必要なら増やす、設定をコードで管理するための土台ですね。
この2つを組み合わせると、
がやりやすくなります。
ただし、記事でもはっきり書かれている通り、便利だけど学習コストは高いです。これは本当にその通りで、私も「ブロックチェーンをKubernetesで」と聞くと、かっこよさの裏で相当な苦労があるだろうなと思います。
ネットワークは主に次の要素で構成されています。
Orderer
トランザクションの順番を決めて、ブロックを作る役目。
ここでは RAFT consensus を使っています。これは複数のOrdererで合意を取る方式で、古いSolo modeは使っていません。
Peers
トランザクションの承認（endorse）や記録（commit）を担当し、台帳を持つノード。
CA（Certificate Authority）
参加者のIDや証明書を発行する役目。
つまり「この人は誰か」を証明する係です。
Kubernetes Jobs
チャネル作成やchaincodeインストールなど、一回きりの作業を実行するための仕組み。
加えて、これらは専用の fabric namespace に置かれ、通信はNetworkPolicyで制限されています。
要するに、「同じKubernetesクラスタの中でも、Fabric用の閉じた区画を作って運用している」ということです。これはかなり筋がいい設計だと思います。
記事ではディレクトリ構成も紹介されています。
manifests/scripts/config/configtx.yaml などのネットワーク設定.env.exampleこの構成の良さは、「人間が頑張る運用」から「再現できる運用」へ寄せている点です。
インフラは、手で1回動かせることより、同じ手順を何度でも安全に繰り返せることのほうがずっと大事です。ここは地味ですが、かなり重要です。
記事で特に印象的なのが、kubectl apply をただ並べるのではなく、デプロイ用スクリプトをちゃんと作り込んでいる点です。
たとえば、
といった工夫があります。
これ、派手さはないですが、現場ではとても効きます。
深夜2時に障害対応する側の気持ちになれば、「失敗したら直近のログを出してくれる」だけでだいぶ救われます。かなり親切です。
kubectl rollout status を使って、Deploymentがちゃんと立ち上がるまで待っています。
これは「作ったつもり」ではなく「実際に起動した」と確認するための大事な処理です。
チャネル作成やchaincodeインストールはKubernetes Jobsで実行し、その完了を待ちます。
もしタイムアウトしたら、関連ログの最後の50行を出してから失敗扱いにしています。
このあたりは、運用の現実感があります。
「動かなかったら人間が見に行く」のではなく、「スクリプトが先回りして情報を出す」。こういう設計は本当に強いです。
この記事では、セキュリティ面の判断もかなり丁寧です。
securityContext で、次のような設定をしています。
runAsNonRoot: truerunAsUser: 1000readOnlyRootFilesystem: trueallowPrivilegeEscalation: falsecapabilities.drop: ["ALL"]要するに、「もし壊れても被害を広げにくい」ように、権限をかなり絞っているわけです。
個人的には、これは「本番を意識しているかどうか」が一目でわかるポイントだと思います。雑なPoCだとここが甘くなりがちです。
Ordererには、必要なpeerだけが通信できるようにしています。
Kubernetesは便利ですが、何もしないとクラスタ内の通信がゆるくなりがちです。だからこそ、「誰が誰に話せるか」を明示するのは大事です。
証明書や鍵、パスワードは、環境変数やKubernetes Secretsから読み込む設計です。
.env.example だけを置いておくのも、協力者に必要な項目を伝えつつ、本物の秘密は守れるので良いやり方です。
kubectl があるか、クラスタに接続できるかを最初に確認しています。
これも地味ですが大事で、「そもそも接続先がないのにデプロイして失敗する」という無駄を防げます。まさに fail fast, fail loud です。
Fabricで特に厄介なのが、crypto material management です。
これは証明書や秘密鍵などの管理のことですが、Fabricではこれが大量に出てきます。
記事では、cryptogen が大量の証明書と鍵を生成し、それらがどのコンポーネントでどれと対応しているかを追うのに、かなり苦労したと書かれています。
これは本当に想像がつきます。証明書周りは、1つでもズレると通信が全部こけるので、デバッグがとにかく面倒です。
ここは「ブロックチェーンだから難しい」というより、分散システムと暗号の面倒さが合体している感じですね。そりゃ大変です。
もうひとつの学びとして、RAFT leader election の話があります。
RAFTは複数ノードの合意形成で使う仕組みですが、初期起動時に orderer のPodが揃わないと、election timeout の間にまとまらず、ネットワークが立ち上がらないことがあります。
ここで効いたのが、
waitDeployment() のタイムアウト制御です。
つまり、「立ち上がっていることをちゃんと確認しながら次へ進む」ことが、ただの親切ではなく、ネットワーク全体の起動条件になっていたわけです。これもかなり実践的な話です。
記事の中で、Kubernetes Jobsを使ってチャネル作成やanchor peer更新をしている点も紹介されています。
これは面白いです。
なぜなら、こういう作業って「起動時に一度だけやりたい」ものが多いからです。
Jobsにすると、
という利点があります。
私も、こういう「一度きりの操作をちゃんと一級市民として扱う」設計はかなり好きです。スクリプトの闇鍋よりずっと健全です。
記事では次の展開も挙げられています。
ここを見ると、まだ「完成」ではなく、本番運用に向けた土台作りの途中だとわかります。
逆に言えば、この記事は「デプロイできた！」で終わらず、監視・秘密管理・自動化まで見据えているのが良いです。インフラは動かして終わりではなく、見守れて初めて本物ですからね。
正直、この記事でいちばん面白いのは、ブロックチェーンそのものより、ブロックチェーンを“運用できる形”に落とし込んでいることです。
世の中には「ブロックチェーンを作った」で止まる話が多いですが、この記事はそこから一歩進んで、
まで踏み込んでいます。
この視点があると、話が一気に現実味を帯びます。私はこういう「キラキラ技術の裏にある地味な実装」が好きです。
この記事は、Hyperledger FabricをKubernetes上で運用するための、かなり実践的なメモです。
派手なデモというより、本番に近い形で安全に動かすには何が必要かを丁寧に積み上げているのが魅力です。
特に重要なのは、
あたりです。
ブロックチェーンとKubernetesは、どちらも単体で難しいのに、組み合わせるとさらに難しい。
でもそのぶん、ちゃんと設計できたときの価値は大きいはずです。この記事は、その「しんどいけど、やる価値はある」感じをうまく伝えていると思います。