TerraformでACMを作成し、WordPressを設定

higa

3年前

この記事は公開されてから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 証明書をエクスポートすることもできます。

AWS Certificate Manager とは？ PDF RSS

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