Consul と Consul Connect の基本概念・メリットと導入手順

Consul と Consul Connect の基本概念とメリット

Consul はサービスディスカバリ・構成管理・ヘルスチェックを統合した分散型カタログです。
その上に実装される Consul Connect がサイドカー方式のサービスメッシュを提供し、マイクロサービス間の通信を暗号化・認可します。本節では、まず Consul の全体像を整理し、続いて Connect がもたらす具体的なメリットを解説します。

Consul の概要

Consul は HashiCorp が開発したオープンソース製品で、以下の機能を中心にサービス基盤を支えます。

• サービスカタログ：DNS と HTTP API を通じて動的にサービス情報を取得可能。
• KV ストア：構成データやフラグを分散保存し、変更時にリアルタイムで反映できる。
• 分散ロック・リーダー選出：Leader election を利用した安全な排他制御が実装されている。

これらにより「データセンターレベルの可視化と自動化」が容易になります。

Consul Connect が提供するサービスメッシュの特徴

Connect は Consul に組み込まれたサイドカープロキシ（既定は Envoy）を活用し、次の価値を提供します。

• 相互認証と暗号化
• トラフィックは TLS (TLS 1.2 以上) で保護され、必要に応じて TLS 1.3 も有効化できる。

• 内蔵 CA が証明書を自動発行し、デフォルトでローテーションが可能（※バージョン ≥ 1.13）。

• 細粒度の認可（Intentions）

• サービス間通信をポリシー単位で許可・拒否でき、Zero‑Trust の実装がシンプルになる。

• 統一された観測性

• Prometheus 形式のメトリクスや Envoy のアクセスログを標準出力に流すことで、Grafana 等への可視化が容易になる。

要点：Consul が基盤機能（ディスカバリ・構成）を提供し、Connect が暗号化・認可・観測性を加えて「安全で可観測な」サービスメッシュを実現します。

前提条件と環境要件

本章では Consul と Connect を本番環境に導入する際の OS・ランタイム・Kubernetes の最低要件を示します。前提条件を満たすことで、公式ドキュメント通りにインストールできることが保証されます。

対応 OS とバージョン

以下は HashiCorp がサポートしている主要プラットフォームです。最新の LTS リリースを使用することを推奨します。

• Ubuntu 22.04 LTS（以降）
• Red Hat Enterprise Linux 9 系列
• macOS Ventura 13 以上（開発・テスト環境向け）

Docker・Kubernetes の推奨バージョン

推奨 Consul バージョンと主要機能

現在（2024 年末時点）で 公式が推奨する安定版 は Consul 1.15.x 系です。バージョン ≥ 1.13 以降では以下の機能がデフォルトまたは簡単に有効化できます。

• ACL v2（トークンベースの細粒度アクセス制御）
• 内蔵 CA の自動ローテーション（証明書更新を手作業で行う必要がない）

※特定機能はバージョンに依存するため、導入前に公式リリースノートをご確認ください。

結論：上記の OS・ランタイム・Kubernetes バージョンを揃えれば、CLI・Docker Compose・Helm のいずれの手法でも公式ガイド通りに Consul クラスタを構築できます。

Consul サーバークラスタの構築手順

この章では CLI インストール → Docker Compose デプロイ → Helm Chart での Kubernetes 展開 の三つのパターンを順に示します。どの方法でも同一の ACL/TLS 設定が共有できる点がポイントです。

CLI でのインストール

まずはローカルマシンや軽量 VM に直接バイナリを展開する手順です。テスト環境や CI パイプラインに適しています。

1. 公式サイトからバイナリ取得（バージョンは 1.15.x 系）
   bash
curl -LO https://releases.hashicorp.com/consul/1.15.4/consul_1.15.4_linux_amd64.zip
unzip consul_1.15.4_linux_amd64.zip
sudo mv consul /usr/local/bin/

2. Bootstrap トークン取得（初回だけ実行）
   bash
consul operator init > bootstrap.json
export CONSUL_HTTP_TOKEN=$(jq -r .SecretID bootstrap.json)

3. サーバーモードで起動（単一ノード例）
   bash
consul agent -server -bootstrap-expect=1 \
-ui -client=0.0.0.0 -bind=$(hostname -I | awk '{print $1}')
-bootstrap-expect=3 とすれば 3 ノード HA が自動的に形成されます。

ポイント：CLI は最小構成で起動でき、後から consul join <peer> によりノード追加が可能です。

Docker Compose によるデプロイ

Docker Compose はローカル開発や CI でのマルチコンテナ環境構築に便利です。公式イメージを利用します。

ポイント：bootstrap-expect=3 により 3 ノードの HA クラスタが自動的に形成され、データ永続化は consul-data ボリュームで確保します。

Helm Chart での Kubernetes 展開

本番環境や大規模クラスターでは Helm が推奨です。以下は公式 Helm リポジトリを利用した最小構成例です。

values.yaml（抜粋）

まとめ：CLI は最小テスト、Docker Compose はローカル・CI、Helm は本番 Kubernetes にそれぞれ適しています。どの手法でも同一の ACL/TLS 設定を共有できる点が Consul の強みです。

ゼロトラスト実装：ACL と TLS 設定

サービス間通信を 認証＋暗号化 で保護するために、まず ACL ポリシーを作成し、続いて内蔵 CA を用いた TLS 設定を行います。以下の手順は Consul 1.13 以降で有効です。

ACL ポリシーの作成と適用

ACL v2 に基づくトークンとポリシーの管理は、Zero‑Trust の根幹となります。

1. Bootstrap トークンで管理者権限取得（前節参照）。
2. サービス別ポリシーを JSON 形式で定義（例：frontend-read.json）
   json
{
"Name": "frontend-read",
"Description": "フロントエンドからバックエンドへの読み取り権限",
"Rules": [
{
"Resource": "service",
"Segment": "",
"Datacenter": "*",
"Namespace": "default",
"Capability": "read"
}
]
}
3. ポリシー登録とトークン生成
   bash
consul acl policy create -name=frontend-read -rules=@frontend-read.json
consul acl token create -description="frontend-token" \
-policy-name=frontend-read > frontend-token.json
export CONSUL_HTTP_TOKEN=$(jq -r .SecretID frontend-token.json)

ポイント：CONSUL_HTTP_TOKEN を環境変数に設定すれば、以降の CLI/HTTP 呼び出しは自動的にこのトークンで認可されます。

内蔵 CA と自動証明書ローテーション

Consul の組み込み CA はデフォルトで有効（バージョン ≥ 1.13）です。手順は次の通りです。

1. CA を作成（既に有効ならスキップ可）
   bash
consul tls ca create -key-size=4096 -days=365
2. 各サーバーノードで証明書を自動生成
   bash
consul tls cert create -server \
-node=$(hostname) \
-address=$(hostname -I | awk '{print $1}')

3. TLS 設定を config.hcl に追記
   hcl
tls {
defaults {
ca_file = "/etc/consul.d/tls/ca.pem"
cert_file = "/etc/consul.d/tls/server.pem"
key_file = "/etc/consul.d/tls/server-key.pem"

   verify_incoming = true
verify_outgoing = true
verify_server_hostname = true
}
}
4. **自動ローテーション有効化**（デフォルトで tls_auto_rotate が true）bash
consul tls ca rotate -incremental
# 各ノードで reload
consul reload


注意点：TLS 1.3 は Go の TLS ライブラリが有効になる環境でのみ自動的に使用されます。TLS 1.2 がデフォルトとなる場合は、tls { defaults { min_version = "tls12" } } で明示的に設定してください。

Kubernetes との統合と運用

Kubernetes 上で Consul Connect を利用すると、Pod に自動的に Envoy サイドカーが注入され、ServiceDefaults / Intentions による細かな通信制御と Prometheus/Grafana での可観測性が実現します。

Consul Connect on K8s のセットアップ

まずは Helm Chart を用いて Consul 本体をデプロイし、Connect 用の注入機能を有効化します。

次に、対象の Namespace へ Connect 注入アノテーション を付与します。

この設定を適用すると、その Namespace にデプロイされる全ての Pod が自動的に Envoy サイドカーと共に起動します。

ServiceDefaults と Intentions の設定例

ServiceDefaults は同一サービス内で共通化したタイムアウトやリトライポリシーを定義できます。

Intentions はサービス間の通信を許可または拒否するポリシーです。以下は frontend 名前空間から orders サービスへの呼び出しだけを許可する例です。

上記設定は consul intention create -name=frontend-to-orders -source-namespace=frontend -destination-service=orders -action=allow と CLI でも作成できます。

可観測性の有効化（Prometheus / Grafana）

Consul は /v1/metrics エンドポイントで Prometheus フォーマットのメトリクスを提供します。Helm の telemetry 設定を有効にすると自動的にエクスポートが開始されます。

values.yaml に追加

Prometheus 側の scrape_config は次のように記述します。

Grafana 用の公式ダッシュボード（ID 11268）をインポートすれば、サービスレイテンシ・TLS エラー・サイドカーのヘルス などが一目で把握できます。

まとめ：Kubernetes に Consul Connect を導入すると、Helm 一回のデプロイですべての Pod が自動的にサイドカー化し、ServiceDefaults / Intentions による細かい通信制御と Prometheus/Grafana での可観測性が同時に得られます。

デバッグ・トラブルシューティング

サービスメッシュ導入後はログ・CLI・典型的な障害パターンを順番に確認することで、迅速に原因特定が可能です。

ログ確認と Envoy のデバッグ

Envoy のログレベルは環境変数 ENVOY_LOG_LEVEL で制御できます。デバッグ時は以下の手順でログ出力を強化します。

debug レベルにすると TLS ハンドシェイク、ルーティング、ヘッダー操作の詳細が標準出力に流れます。問題が再現したら info に戻すことを忘れないでください。

CLI 診断コマンド一覧

典型的な障害パターンと対策

1. TLS ハンドシェイク失敗 (error: TLS handshake failed)
2. 原因：サーバー CA とクライアントが不整合、または verify_server_hostname が有効なのに証明書の CN が一致しない。

3. 対策：最新の ca.pem を全ノードへ配布し、consul reload 後に再接続。必要なら tls { defaults { verify_server_hostname = false } } で一時的に回避。

4. ACL 認可エラー (403 Forbidden)

5. 原因：使用トークンが対象サービスへの read/write 権限を持っていない。

6. 対策：consul acl token update -id <token-id> -policy-name=<適切ポリシー> で権限付与し、再度 API 呼び出し。

7. Sidecar が起動しない

8. 原因：Pod に consul.hashicorp.com/connect-inject=true アノテーションが無い、または Helm の connectInject.enabled が false。
9. 対策：Namespace/Deployment のアノテーションを確認し、Helm 設定で connectInject.enabled: true に修正後再デプロイ。

要点：ログと CLI を組み合わせて状態を可視化すれば、多くの TLS・ACL・Sidecar 関連問題は数分で解決できます。

次のアクション：公式ドキュメントとサンプルリポジトリ

本ガイドは HashiCorp が公開している 公式ドキュメント と GitHub のサンプルリポジトリ に完全準拠しています。以下のリンクから最新版を取得し、ローカル環境やテストクラスターでハンズオンを実施してください。

• インストールガイド（CLI・Docker Compose・Helm）
  https://developer.hashicorp.com/consul/docs/install

• Consul Connect のベストプラクティス（サービスディスカバリ・TLS 設定）
  https://developer.hashicorp.com/consul/docs/connect

• サンプルコード集（GitHub）
  https://github.com/hashicorp/consul-guides

これらの資料を基に、まずは シングルノードで動作確認 → HA クラスタ構築 → Kubernetes 上へのデプロイ の流れで実装を進めてください。Zero‑Trust なサービスメッシュが本番環境でも安定して稼働することを確認したら、段階的にトラフィックシフトやカナリアリリースへ拡張すると効果的です。