Contents
Consul Service Mesh (Connect) の概要
Consul Connect は HashiCorp が提供する Service Mesh ソリューションで、サービス間の通信を Zero‑Trust に保ちつつ可観測性を確保します。
本稿では 2024 年時点で公開されている最新安定版 (Consul 1.15.x) と、2025 年に予定されている 1.16 系リリース情報（HashiCorp のロードマップ）を踏まえて、主要機能と実装手順を解説します。
ポイント は「Intentions による細粒度アクセス制御」「内部 CA／外部 PKI を用いた mTLS」「Envoy サイドカープロキシの自動注入」の 3 本柱です。
前提条件と環境準備
このセクションでは、Consul の導入に必要な OS・ランタイム・ネットワーク要件をまとめます。事前に要件を満たすことで、オンプレミス・パブリッククラウド間で一貫した Mesh が構築できます。
推奨 Consul バージョンと対応プラットフォーム
| 項目 | 推奨バージョン / 条件 |
|---|---|
| Consul 本体 | 1.15.x（2024‑12 リリース）※1 |
| OS | Ubuntu 22.04 LTS、Amazon Linux 2023、RHEL 9 系列 |
| コンテナランタイム | Docker 24.x、containerd 1.7 以上 |
| オーケストレータ | Nomad 1.6.x、Kubernetes 1.29（EKS/GKE/AKS） |
※ HashiCorp の公式ロードマップ (2025‑Q2) にて 1.16 系がリリース予定と記載されています。実際のリリース日は未確定ですので、導入時は公式サイトを確認してください。HashiCorp Roadmap
ネットワーク要件とクラウド／オンプレの前提
- TLS 用ポート：
8500(HTTP API)、8301(Serf LAN)、8600(DNS) を内部ファイアウォールで開放。 - サブネット設計：各リージョンごとに
/24のプライベートサブネットを確保し、VPC ピアリングまたは Direct Connect／Interconnect で相互接続。 - ロードバランサー：Consul UI への外部アクセスは TLS 終端せず、ALB/NLB（AWS）や Cloud Load Balancer（GCP）をそのまま通過させる構成が推奨されます。
まとめ：上記 OS・コンテナ・ネットワーク要件を満たすことで、マルチクラウド環境でも一貫した Consul Service Mesh が構築できます。
Consul エージェントのインストール方法と基本設定
Consul ノードは サーバーモード と クライアントモード に分かれます。ここではバイナリ、Docker コンテナ、Kubernetes Operator の 3 パターンをコード例とともに示します。
バイナリインストール手順
まず公式リポジトリから対象 OS 用の zip を取得し、/usr/local/bin に配置します。
|
1 2 3 |
curl -L https://releases.hashicorp.com/consul/1.15.4/consul_1.15.4_linux_amd64.zip -o consul.zip unzip consul.zip && sudo mv consul /usr/local/bin/ |
続いてサーバーモード用の設定ファイル consul.hcl を作成します（HCL 形式に統一）。
|
1 2 3 4 5 6 7 |
datacenter = "dc-main" data_dir = "/opt/consul" server = true bootstrap_expect = 3 bind_addr = "{{ GetInterfaceIP \"eth0\" }}" encrypt = "<gossip-key>" |
systemd サービスとして登録し、起動します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
sudo tee /etc/systemd/system/consul.service <<'EOF' [Unit] Description=Consul Agent After=network-online.target [Service] ExecStart=/usr/local/bin/consul agent -config-dir=/etc/consul.d Restart=on-failure LimitNOFILE=65536 [Install] WantedBy=multi-user.target EOF sudo systemctl enable --now consul |
Docker コンテナでのデプロイ
Docker でも同様に公式イメージ hashicorp/consul:1.15 を利用します。ポートマッピングと永続ボリュームを明示的に設定してください。
|
1 2 3 4 5 6 7 8 |
docker run -d \ --name consul-server \ -p 8500:8500 -p 8600:8600/udp \ -v /opt/consul/data:/consul/data \ -e CONSUL_BIND_INTERFACE=eth0 \ hashicorp/consul:1.15 agent -server -bootstrap-expect=3 \ -client=0.0.0.0 -ui |
Kubernetes Operator の利用
HashiCorp が提供する Consul K8s Operator は Helm で簡単にインストールできます。connectInject.enabled: true を設定すると自動サイドカー注入が有効になります。
|
1 2 3 4 5 6 7 |
helm repo add hashicorp https://helm.releases.hashicorp.com helm install consul hashicorp/consul \ --set global.name=consul \ --set server.replicas=3 \ --set client.enabled=true \ --set connectInject.enabled=true |
ポイント：バイナリ・Docker・Operator のいずれでも
consul.hcl（または Helm values）で server と client を明示すれば、同一設定を複数環境で再利用できます。
Connect の有効化とサービス登録
Connect を有効にしたら、対象アプリケーションを Service Definition でカタログに登録し、Envoy サイドカー用のプロキシ設定を行います。ここでは HCL 形式だけを使用してコード例を統一します。
Service Definition とヘルスチェック（HCL）
以下は HTTP アプリケーション web の定義です。connect.sidecar_service {} を記述するだけで Envoy が自動的に注入されます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
service { name = "web" port = 8080 connect { sidecar_service {} } check { id = "web-health" http = "http://localhost:8080/health" interval = "10s" timeout = "2s" } } |
CLI または HTTP API で登録します。
|
1 2 3 4 |
consul services register web-service.hcl # or via API curl -X PUT --data @web-service.hcl http://localhost:8500/v1/agent/service/register |
Proxy Stanza（上流サービス設定）
api サービスが内部データベース db へ接続する際の Envoy 設定例です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
service { name = "api" port = 9090 connect { sidecar_service {} } proxy { upstreams = [ { destination_name = "db" local_bind_port = 5432 } ] } } |
まとめ：
connect.sidecar_service {}を入れるだけで Connect が有効化され、ヘルスチェックと upstream 設定を合わせることでマイクロサービス間の通信が自動的にプロキシ経由になります。
アクセス制御ポリシー（Intentions）と mTLS の設定
Zero‑Trust を実現するためのコアは Intentions でアクセス許可を細かく管理し、全トラフィックに mTLS を適用することです。
Intentions の作成例（HCL）
|
1 2 3 4 5 6 7 8 9 10 11 12 |
intentions { source_name = "web" destination_name = "api" action = "allow" } intentions { source_name = "*" destination_name = "db" action = "deny" } |
ファイル intentions.hcl に保存し、CLI で適用します。
|
1 2 |
consul intention apply -file=intentions.hcl |
適用結果は次のコマンドで確認できます。
|
1 2 3 |
consul intention check -source=web -dest=api # => allowed consul intention check -source=frontend -dest=db # => denied |
公式ドキュメント：Intentions の詳細は HashiCorp のガイドを参照してください → https://developer.hashicorp.com/consul/docs/connect/intention
証明書管理の選択肢
| 方法 | 特徴 |
|---|---|
| Consul 内蔵 CA | 手軽に自己署名証明書が生成でき、consul tls ca create で初期化。自動ローテーションもサポート。 |
| Vault PKI | 組織の既存 PKI と統合可能。Vault の pki シークレットエンジンから CSR を発行し、Consul が取得。 |
| 外部 CA（例：Let’s Encrypt） | 公開サービス向き。ただし ACME クライアントを別途導入する必要あり。 |
Consul 内蔵 CA の作成と TLS 設定例
|
1 2 3 4 5 6 7 8 9 10 11 12 |
# 1. CA 作成 (初回のみ) consul tls ca create -domain=example.internal # 2. エージェント設定に TLS を有効化（consul.hcl に追記） tls { defaults { verify_incoming = true verify_outgoing = true verify_server_hostname = true } } |
設定を反映させたらエージェントを再起動し、全ノードで自動的に証明書が取得・更新されます。
公式ドキュメント：TLS/CA の設定は https://developer.hashicorp.com/consul/docs/connect/ca を参照してください。
Zero‑Trust mTLS の有効化手順（要点）
- すべてのエージェントで上記
tls {}ブロックを有効にする。 connect.sidecar_serviceが設定されたサービスは起動時に Consul CA から証明書を取得し、Envoy が mTLS を使用して通信。- ポリシー変更後は
consul intention checkで許可/拒否を検証し、必要に応じてcurl --cacert等で手動クライアントからの接続も確認。
Terraform によるマルチクラウドデプロイとサイドカー自動注入
インフラは Terraform でコード化し、AWS・GCP・Azure に同一モジュールを展開します。その上で Nomad ジョブまたは Kubernetes マニフェストにサイドカー注入設定を加えます。
Terraform モジュールの共通化例
公式モジュール hashicorp/consul を利用し、クラウドごとにソースだけ差し替える構成です。以下は AWS 用の例です（GCP・Azure は同様に gcp / azurerm に変更）。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
module "consul" { source = "hashicorp/consul/aws" version = "~> 0.7" # 共通パラメータ datacenter = var.datacenter servers = 3 client_enabled = true # AWS 固有 vpc_id = var.vpc_id subnet_ids = var.subnet_ids } |
変数定義（variables.tf）
|
1 2 3 4 5 6 7 8 9 10 11 |
variable "cloud_provider" { description = "aws | gcp | azure" type = string } variable "datacenter" {} variable "vpc_id" {} variable "subnet_ids" { type = list(string) } |
terraform apply -var-file=prod.tfvars とすれば、選択したクラウドに Consul クラスタが自動デプロイされます。
Nomad ジョブでのサイドカー注入パターン
Nomad の service ブロック内に connect { sidecar_service {} } を記述すると、Envoy が同一タスクグループ内で起動します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
job "web" { datacenters = ["dc-main"] group "app" { task "service" { driver = "docker" config { image = "myorg/web:latest" ports = ["http"] } service { name = "web" port = "http" connect { sidecar_service {} } } resources { cpu = 500 memory = 256 } } } } |
Kubernetes での自動サイドカー注入
Consul Helm Chart の connectInject.enabled を有効化した上で、Pod にアノテーションを付与します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
apiVersion: apps/v1 kind: Deployment metadata: name: api spec: replicas: 3 selector: matchLabels: app: api template: metadata: annotations: consul.hashicorp.com/connect-inject: "true" spec: containers: - name: api image: myorg/api:1.2 ports: - containerPort: 9090 |
公式ガイド：Kubernetes での Connect 注入は https://developer.hashicorp.com/consul/docs/k8s/connect-inject を参照してください。
Observability の設定
| コンポーネント | 設定ポイント |
|---|---|
| Prometheus | Consul と Envoy が /metrics を公開。Helm で prometheusScrape.enabled: true にすると自動収集。 |
| Grafana | HashiCorp 提供のテンプレート（ID 15813）をインポートすれば、レイテンシ・TLS エラーなどが可視化できる。 |
| Envoy Admin API | http://<pod-ip>:9901/servers でサイドカー状態確認。CLI consul proxy config write と組み合わせてリアルタイムに設定変更可能。 |
ベリフィケーション手順（簡易表）
| 手順 | コマンド例 |
|---|---|
| カタログ確認 | consul catalog services |
| プロキシステータス | consul connect proxy list -service=web |
| Intentions 監査 | consul intention list -verbose |
| 証明書有効期限 | consul tls cert list -service=api |
まとめ
- Consul Connect は Intentions、Zero‑Trust mTLS、Envoy による三位一体のアーキテクチャで、2024 年時点でもマルチクラウドに最適化された Service Mesh を提供します。
- 導入前に OS・ランタイム・ネットワーク要件を統一し、サーバーモードとクライアントモードの役割を明確化することが成功の鍵です。
- バイナリ、Docker、Kubernetes Operator のいずれでも
consul.hclに設定を集約すれば、環境間で同一構成を再利用できます。 - Service Definition に
connect.sidecar_service {}を記述するだけで Connect が有効化され、Envoy サイドカーが自動注入・管理されます。 - Intentions で細粒度アクセス制御、内部 CA または外部 PKI（Vault/Let’s Encrypt）で証明書自動発行し、全トラフィックに mTLS を適用すれば Zero‑Trust が実現できます。
- Terraform モジュールを使えば AWS・GCP・Azure に同一コードで Consul クラスタをデプロイでき、Nomad と Kubernetes の両方でサイドカー注入が可能です。
- Observability は Prometheus + Grafana + Envoy Admin API で網羅し、
consul catalog・proxy list・intention list等の CLI 検証コマンドで運用状態を定期的に確認してください。
これらの手順とベストプラクティスを踏むことで、オンプレミス・パブリッククラウド・ハイブリッド環境すべてで 安全かつ可観測なマイクロサービス基盤 を構築できます。