Contents
前提条件と推奨環境
Consul を安定して運用するには、OS・コンテナランタイム・オーケストレータの組み合わせが重要です。本セクションでは 「何を」 用意すべきか、 「なぜ」 それらが必須になるのかを簡潔に説明し、最終的に推奨構成を示します。
Ubuntu 22.04 LTS または AlmaLinux 9 をベースとした Linux 環境 が公式バイナリ・Helm Chart の両方でテスト済みです。Docker Engine は 24.0 系列（例: 24.0.7）、Kubernetes は 1.28 以上（1.27〜1.29 がサポート対象）、Helm は 3.14 系列 を使用します。これらは HashiCorp が公開している Helm Chart の “Tested Versions” に明記されており、2026 年 7 月時点でも公式ドキュメントで確認できます（helm‑releases Hashicorp/consul）。
| ツール | 推奨バージョン (2026年7月現在) | 入手・インストール方法 |
|---|---|---|
| OS | Ubuntu 22.04 LTS / AlmaLinux 9 | 公式 ISO またはクラウドイメージ |
| Docker Engine | 24.0.7 以上 | apt-get install docker-ce（Ubuntu）または dnf install docker-ce（AlmaLinux） |
| Kubernetes | v1.28 以上 (v1.27‑v1.29 推奨) | kubeadm init --kubernetes-version=v1.28.x |
| Helm | 3.14.4 以上 | curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash |
ポイント：macOS や Windows は CLI 開発時の補助ツールとしては有用ですが、サーバー本体のデプロイ対象外です。ここでは 「本番に必要な」 基盤だけを取り上げます。
Consul のインストール方法（バイナリ・Helm）
この章では 公式バイナリ と 公式 Helm Chart の二通りの導入手順を比較し、どちらが自社の運用方針に合うか判断できるようにします。まずは全体像と選択基準を示した後、各手順を具体的に解説します。
バイナリ方式が向いているケース
- 単一ノードやテスト環境で軽量に動作させたい
- 手動でバージョンロックやパッチ適用を行う必要がある
Helm Chart 方式が向いているケース
- Kubernetes 上のマルチノードクラスターで HA を実現したい
values.yamlによる一元管理と自動アップグレードが重要
結論：本番環境は Helm Chart 推奨です。バイナリは開発・検証向けに残しておくと柔軟性が高まります。
1. バイナリによる手動インストール
以下の手順は Consul 1.17.0（2026 年 4 月リリース）を例にしています。バージョン番号は公式サイトで随時確認してください。
|
1 2 3 4 5 6 7 8 9 |
# 公式リリースページから最新版 zip を取得 curl -LO https://releases.hashicorp.com/consul/1.17.0/consul_1.17.0_linux_amd64.zip unzip consul_1.17.0_linux_amd64.zip sudo mv consul /usr/local/bin/ chmod +x /usr/local/bin/consul # バージョン確認 consul version |
consul agent -dev でローカルデーモンが起動すれば、インストールは完了です。
2. Helm Chart による本番デプロイ
a. Chart のバージョンとテスト範囲の根拠
HashiCorp が提供する Consul Helm Chart（現在 v0.45.0）は、以下の組み合わせで CI テストが実行されています。
- Consul 1.16 – 1.17
- Kubernetes 1.27 – 1.29
(出典: https://github.com/hashicorp/consul-helm/blob/main/.github/workflows/ci.yml)
b. デプロイ手順
|
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 28 |
# リポジトリ追加と最新 Chart の取得 helm repo add hashicorp https://helm.releases.hashicorp.com helm repo update # values.yaml（抜粋）を作成 cat > values.yaml <<'EOF' global: name: consul server: replicas: 3 # HA 用のサーバー数 bootstrapExpect: 3 # Raft 初期化に必要なノード数 tls: enabled: true # mTLS を有効化（後述参照） client: enabled: true ui: enabled: true connectInject: enabled: true default: true # 全 Pod に自動 sidecar 注入 EOF # デプロイ実行 helm install consul hashicorp/consul \ --namespace consul-system \ --create-namespace \ -f values.yaml |
デプロイ完了後は kubectl -n consul-system get pods でサーバー・クライアント Pod が立ち上がっていることを確認してください。
HA クラスタ設計と Connect の有効化
このセクションでは、Raft による 3 ノード サーバークラスタの構築手順と、サービスメッシュ基盤として Consul Connect を有効にする具体的設定を示します。まずは設計上の要点とリスク軽減策を整理し、その後に HCL 設定例へ移ります。
1. HA クラスタの基本方針
- サーバー数は奇数（3）：過半数 (2) が残っていればリーダーが存続できるため、単一障害でサービス停止を防げます。
- TLS 必須化：内部通信を暗号化し、認証済みノードのみがクラスタに参加可能です。
2. Consul Connect の全体像
Connect は Envoy sidecar と連携して L7 のプロキシ機能と mTLS を提供します。Helm Chart の connectInject.enabled: true に加えて、各ノードの設定ファイルに以下ブロックを追加することで有効化できます。
|
1 2 3 4 5 6 7 8 |
# 共通 config.hcl（全ノードで使用） connect { enabled = true # Connect 機能全体を有効化 proxy { allow_managed_sidecar = true # Helm が自動注入した sidecar を許可 } } |
ポイント：
proxy.allow_managed_sidecarは Helm による自動 sidecar 注入と整合性を取るために必須です。
3. サーバー側設定（server.hcl）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
datacenter = "dc1" data_dir = "/opt/consul" server = true bootstrap_expect = 3 tls { https = true # HTTPS (mTLS) を有効化 ca_file = "/etc/consul/tls/ca.pem" cert_file = "/etc/consul/tls/server.pem" key_file = "/etc/consul/tls/server-key.pem" } connect { enabled = true } |
4. クライアント側設定（client.hcl）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
datacenter = "dc1" data_dir = "/opt/consul" server = false retry_join { provider = "aws" # AWS のタグ検索例 tag_key = "ConsulServer" tag_value= "true" } tls { https = true ca_file = "/etc/consul/tls/ca.pem" cert_file = "/etc/consul/tls/client.pem" key_file = "/etc/consul/tls/client-key.pem" } |
5. systemd サービス化
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
[Unit] Description=Consul Agent After=network-online.target Wants=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 |
systemctl enable --now consul で自動起動し、journalctl -u consul -f でログを追跡できます。
セキュリティ設定（ACL・Intentions・mTLS）
本章では ゼロトラスト に近いセキュリティレベルを実現するための三大要素を順に解説します。まずは ACL と Intentions の役割、次に mTLS 設定の完全な例、最後に Kubernetes での自動サイドカー注入との整合性について触れます。
1. ACL ポリシーとトークン管理
HashiCorp が提供する ACL トークン は API アクセスや Envoy プロキシの認可に必須です。以下は mesh‑policy と呼ばれる最小権限ポリシーの例です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
{ "Name": "mesh-policy", "Description": "最低限のサービスメッシュ操作を許可", "Rules": [ { "Resource": "service", "Segment": "", "Capabilities": ["read", "list"] }, { "Resource": "connect-proxy", "Segment": "", "Capabilities": ["write"] } ] } |
ポリシーは consul acl policy create -name mesh-policy -rules @policy.json で登録し、トークンは consul acl token create -description "mesh-token" -policy-name mesh-policy として生成します。取得したトークンは環境変数 CONSUL_HTTP_TOKEN に設定してください。
2. Intentions（サービス間許可ルール）
Intentions は L7 の サービス名ベース で許可／拒否を定義します。以下は「frontend」から「backend」への呼び出しだけを許可し、その他はデフォルトで拒否する例です。
|
1 2 3 4 5 6 7 8 |
# intentions.hcl service "frontend" { intention = "allow" } service "backend" { intention = "deny" } |
consul intention create -name allow-frontend-to-backend -source-service frontend -destination-service backend -action allow のように CLI でも作成可能です。
3. mTLS 完全設定例
Helm Chart の server.tls.enabled: true と同時に、各ノードの config.hcl に以下ブロックを必ず追加します。これにより内部通信だけでなく、Connect が生成する Envoy sidecar 同士も自動的に TLS で保護されます。
|
1 2 3 4 5 6 7 8 9 10 11 |
tls { defaults { ca_file = "/etc/consul/tls/ca.pem" cert_file = "/etc/consul/tls/{{node_name}}.pem" key_file = "/etc/consul/tls/{{node_name}}-key.pem" verify_incoming = true verify_outgoing = true verify_server_hostname = true } } |
注意点
-{{node_name}}は systemd の環境変数や Kubernetes の Pod 名から展開できます。
-verify_server_hostnameを有効にすると、証明書の CN/SAN がノード名と一致していることを検証し、MITM 攻撃リスクが低減します。
4. Kubernetes での自動 sidecar 注入設定
先ほど作成した values.yaml の connectInject セクションに以下項目を追加すると、全 Pod に Envoy が自動的に注入され、TLS 設定も同期されます。
|
1 2 3 4 5 6 7 8 9 |
connectInject: enabled: true default: true # 全 Pod に sidecar 注入 centralConfig: enabled: true # Central Config API を有効化し、ACL と Intentions を動的に反映 proxyDefaults: envoyExtraArgs: - "--log-level=info" |
サービス登録・ヘルスチェック・モニタリング
最後の章では、実際にアプリケーションを Consul に 登録し、ヘルスチェックと 可視化 を行うまでのフローをまとめます。まずは登録方法の選択肢を概観し、その後に Prometheus/Grafana でのモニタリング設定例を示します。
1. 登録手段の比較
| 手段 | 用途・メリット | 実装例 |
|---|---|---|
| CLI / HTTP API | スクリプトや CI/CD パイプラインから直接登録可能 | consul services register -name=api -port=8080 -check='{"http":"http://localhost:8080/health","interval":"10s"}' |
| Kubernetes Annotation | K8s の Service 定義に付与するだけで自動登録（consul-k8s が検出） |
annotations:\n "consul.hashicorp.com/connect-service": "true" |
| Consul DNS | レガシーアプリが DNS 名でサービス探索できる | /etc/resolv.conf に 127.0.0.1:8600 を追加 |
結論：Kubernetes 環境では Annotation が最も手軽です。非 K8s の VM やオンプレミス環境では API 登録を推奨します。
2. ヘルスチェック設定例（HCL）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
service { name = "api" port = 8080 check { id = "http-health" name = "HTTP Health Check" http = "http://127.0.0.1:8080/health" interval = "10s" timeout = "2s" } } |
このファイルを /etc/consul.d/api.hcl に配置し、systemctl restart consul で反映させます。
3. Prometheus Exporter と Grafana ダッシュボード
Consul のメトリクスは -metrics-address=0.0.0.0:9107 オプションで有効化できます。Helm Chart では次のように設定します。
|
1 2 3 4 5 |
# values.yaml に追記 metrics: enabled: true prometheusPort: 9107 |
Prometheus 側は以下の scrape_config を追加してください。
|
1 2 3 4 5 |
scrape_configs: - job_name: 'consul' static_configs: - targets: ['consul-server-0.consul-system.svc.cluster.local:9107'] |
Grafana の公式ダッシュボード ID 2475（「Consul Overview」）をインポートすれば、リーダー選出状況やサービスヘルスが一目で確認できます。
4. トラブルシューティングの基本コマンド
| コマンド | 主な用途 |
|---|---|
consul monitor |
ライブログストリームでイベントをリアルタイムに把握 |
consul members -wan |
WAN クラスタメンバーとステータスを確認 |
consul kv get <key> |
KV ストアの内容取得（設定ミス検出） |
kubectl -n consul-system logs deploy/consul-connect-injector |
sidecar 注入コントローラのデバッグログ |
ヒント：問題が発生したらまず
consul monitorでエラーコードやタイムアウトを確認し、続いて Prometheus の指標（例:consul_raft_leader）をチェックすると原因特定が早まります。
まとめ
- 推奨環境：Ubuntu 22.04／AlmaLinux 9 + Docker 24.0 + Kubernetes 1.28+ + Helm 3.14+
- インストール手段はバイナリ（開発/テスト）と Helm Chart（本番）の二本柱で選択可能
- HA クラスタは 3 ノード Raft と TLS 必須化で高可用性を実現
- セキュリティは ACL、Intentions、mTLS の三層防御でゼロトラストに近づく
- 監視・運用は Consul API／Annotation＋Prometheus/Grafana で一元管理
この手順通りに構築すれば、2026 年以降も安定したサービスメッシュ基盤として Consul を活用できるでしょう。質問や環境固有の調整が必要な場合は、公式ドキュメント（Consul Docs）を随時参照してください。