この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので十分ご注意ください。
皆様こんにちは。
Terraformを利用して、AWSで高可用性アーキテクトの作成をしていきます。
今回はACMを作成していきます。
1.高可用性アーキテクト構築目次
2.ACMの概要
AWS Certificate Manager (ACM) は、 ウェブサイトやアプリケーションを保護するパブリックおよびプライベート SSL/TLS X.509 証明書およびキーの作成、保存、更新に伴うAWS複雑さに対処します。統合 AWS サービスの証明書は、ACM で直接発行するか、サードパーティーの証明書を ACM 管理システムにインポートすることで提供できます。ACM 証明書は、単一のドメイン名、複数の特定のドメイン名、ワイルドカードドメイン、またはこれらの組み合わせを保護できます。ACM ワイルドカード 証明書は、無制限の数のサブドメインを保護できます。また、内部 PKI の任意の場所で使用するために、ACM Private CA によって署名された ACM 証明書をエクスポートすることもできます。
ACMを利用できるのはAWSのサービスのみですが、ACMは無料で使えるというメリットがあります。ACMの初期設定時には、ドメインの所有の確認が必要です。ドメインの所有の証明には、メール送信もしくはDNSを利用します。
今回はDNSを利用します。
類似サービスとして、GCPの「Certificate Manager」、Azureの「App Service Certificates」等があげられます。
3.フロー図
- ACMで証明書を作成します。
- DNSのドメイン検証確認を行うため、Route53にACMのドメイン検証用レコード(CNAMEレコード)を作成して追加します。
- ALBにHTTPSリスナー設定を追加します。
- EC2内のWordpressにhttps設定をするために必要なプラグインを導入します。
4.ACM証明書を作成してALBに関連付ける
ACMを作成していきます。
4-1.証明書作成
httpsでアクセスできるようにするため、ACMを利用して証明書を作成します。
ソースコードは下記の通りです。
# 1.証明書作成
resource "aws_acm_certificate" "cert" {
domain_name = "higa.test.cloud5.jp"
validation_method = "DNS"
lifecycle {
create_before_destroy = true
}
tags = {
Name = "higa-ACM"
}
}
設定値は下記の通りです。
使用するオプション | 設定値 | 説明 |
---|---|---|
domain_name | higa.test.cloud5.jp | 証明書を発行するドメイン名 |
validation_method | DNS | ドメインの所有の証明に利用するものを選択。DNSかメールが有効 |
lifecycle | create_before_destroy = true | ※1で説明 |
tags | Name = "higa-ACM" | タグのNameキーを設定 |
※1.現在使用中の証明書(ALBのリスナー等)を置き換える場合、ライフサイクルブロックでcreate_before_destroy = true
を指定することが推奨されています。
上記より、証明書の作成ができました。
4-2.Route53にACMのドメイン検証用レコードを追加
Route53にACMのドメイン検証用レコードを追加するためにCNAMEを作成します。
ソースコードは下記の通りです。
# 2.Route53にACMのドメイン検証用レコードを追加
// CNAMEレコードを作成
resource "aws_route53_record" "cert_validation" {
for_each = {
for dvo in aws_acm_certificate.cert.domain_validation_options : dvo.domain_name => {
name = dvo.resource_record_name
record = dvo.resource_record_value
type = dvo.resource_record_type
}
}
allow_overwrite = true
name = each.value.name
records = [each.value.record]
ttl = 300
type = each.value.type
zone_id = "Z01000061EWXXK1FTAO6J"
}
上記はDNSのドメイン検証確認のために必要です。
domain_validation_options
は、証明書の検証を完了するために使用できるドメイン検証オブジェクトのセットです。
4-3.HTTPSにリスナー設定(ALB)
作成した証明書を使ってhttpsでアクセスできるようにしていきます。
# HTTPSにリスナー設定
resource "aws_lb_listener" "higa-listener_https" {
load_balancer_arn = aws_lb.higa-ALB.arn
port = "443"
protocol = "HTTPS"
//SSLのバージョン指定
ssl_policy = "ELBSecurityPolicy-2016-08"
//ACM証明書をHTTPSリスナーに関連づけ
certificate_arn = aws_acm_certificate.cert.arn
default_action {
type = "forward"
target_group_arn = aws_lb_target_group.higa-TGN.arn
}
}
設定項目は下記の通りです。
使用するオプション | 設定値 | 説明 |
---|---|---|
load_balancer_arn | aws_lb.higa-ALB.arn | ALBのARNを指定 |
port | 80 | ポートを設定 |
protocol | HTTP | プロトコルを設定 |
ssl_policy | ELBSecurityPolicy-2016-08 | SSLのバージョン指定 |
certificate_arn | aws_acm_certificate.cert.arn | ACM証明書をHTTPSリスナーに関連づけ |
default_action | type = "forward" target_group_arn = aws_lb_target_group.higa-TGN.arn |
ALBのTGNのARNを指定 |
ALBとACM証明書の紐付けは、aws_lb_listener
のcertificate_arn
に証明書のARNを代入することでできます。
5.WordPressの設定とHTTPSプラグイン導入
5-1. WordPressの初期設定
WordPressの初期設定を行います。
①http://https://higa.test.cloud5.jp//wp-admin/install.php
にアクセスします。
②RDS作成時に設定した項目を入力し、インストールします。「データベースのホスト名」にはRDSのエンドポイントを入力します。
③必要情報を入力して「インストール」をクリックします。
④WordPressの管理画面にログインします。
WordPressの管理画面にログインすることができました。
5-2.Wordpressにhttpsプラグインを導入
下記の手順でWordpressにhttpsプラグインを導入し、HTTPSの設定を行います。
①「Really Simple SSL」プラグインをインストールし、有効化します。「Really Simple SSL」はWordPressをすぐにHTTPS化できるプラグインです。
プラグイン→新規追加をクリックします
「http」と検索→「Really Simple SSL」プラグインをインストールします
有効化をクリックします
SSLを有効化をクリックします
②再度WordPress管理画面にログインし、HTTPS接続できるか確認します。
HTTPS化できていることが確認できました。
これでhttpsの設定は完了です。
6.ALBの設定変更(http)
6-1.httpのリスナールールを削除
「aws_higa_alb.tf」ファイルから下記のソースコードを削除します。
// リスナー設定
# HTTPにリスナー設定
resource "aws_lb_listener" "higa-listener" {
load_balancer_arn = aws_lb.higa-ALB.arn
port = "80"
protocol = "HTTP"
default_action {
type = "forward"
target_group_arn = aws_lb_target_group.higa-TGN.arn
}
}
上記より、ALBから不要になったhttpのリスナールールを削除しました。
6-2.セキュリティグループからhttpのものを削除
「aws_higa_sg.tf」ファイルから下記のソースコードを削除します。
//http
ingress {
from_port = 80
to_port = 80
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
egress {
from_port = 0
to_port = 0
#protocol = "-1" は "all" と同等
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
上記より、ALBから不要になったhttpのセキュリティグループを削除しました。
7.検証
ALBの疎通確認をします。
HTTPS通信は成功し、HTTP通信は失敗すれば設定に問題ないです。
疎通確認はPowerShellでTest-NetConnection
コマンドで行います。
①HTTPSの疎通確認
Test-NetConnection higa-ALB-985017257.ap-southeast-1.elb.amazonaws.com -port 443
で疎通確認をします。
ComputerName : higa-ALB-985017257.ap-southeast-1.elb.amazonaws.com
RemoteAddress : 52.74.48.96
RemotePort : 443
InterfaceAlias : Wi-Fi
SourceAddress : 192.168.0.8
TcpTestSucceeded : True
HTTPSの検証は問題ありませんでした。
②HTTPの疎通確認
Test-NetConnection higa-ALB-985017257.ap-southeast-1.elb.amazonaws.com -port 80
で疎通確認をします。
ComputerName : higa-ALB-985017257.ap-southeast-1.elb.amazonaws.com RemoteAddress : 52.74.48.96
RemotePort : 80
InterfaceAlias : Wi-Fi
SourceAddress : 192.168.0.8
PingSucceeded : False
PingReplyDetails (RTT) : 0 ms
TcpTestSucceeded : False
HTTPの通信は失敗したので、検証は問題ありませんでした。
以上で、疎通確認の結果、設定に問題ないことが確認できました。
8.まとめ
TerraformでACMの証明書作成からHTTPSのリスナー設定をする中、エラーが何度か発生しましたが、
①ACMで証明書の作成 ②Route53にACMのドメイン検証用レコードを追加(CNAMEレコードを作成) ③HTTPSにリスナー設定(ALB)
という風に細分化することで、対応することができました。
9.参考文献
- terraformの公式ドキュメント
Docs overview | hashicorp/aws | Terraform Registry