ShifterでWordPressをサブディレクトリで公開する場合、AWS/Cloudfrontの場合は考慮する必要がある。
- Shifterのドメインから関連付け(CNAME)と紐づけをcliで行う
https://www.npmjs.com/package/@shifter/cli
https://ja.getshifter.io/shifter-support-documents/trouble-shooting/avoiding-cname-already-exist-error
既にCloudFrontにカスタムドメインが設定されている場合、Shifter 側のCDN に同じカスタムドメインを適用することはできない。このようなケースでは、Shifterで生成された静的コンテンツのみを対象に、CloudFront 経由でカスタムドメイン配下のサブディレクトリに公開する必要がある。/blog のようにサブディレクトリでの公開が必要な場合、shifter-cli を使って –no-shifter-cdn オプションを指定することで、ShifterのCDN配信を無効化し、自前のCloudFront経由でのホスティングが可能。
|
1 2 |
$ npm install -g @shifter/cli $ shifter domain:attach --username xxxxx --password xxxxxxx --site-id xxxx --domain hoge.com --no-shifter-cdn |
- terraform/cloudfront.tf
|
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 29 30 31 32 33 34 35 36 37 38 39 |
data "aws_cloudfront_cache_policy" "caching_disabled" { name = "Managed-CachingDisabled" } resource "aws_cloudfront_distribution" "hoge" { provider = aws.us-east-1 origin { domain_name = "hoge.cloudfront.net" origin_id = "blog" origin_path = "" custom_origin_config { http_port = 80 https_port = 443 origin_protocol_policy = "https-only" origin_ssl_protocols = ["TLSv1.2"] } ordered_cache_behavior { allowed_methods = ["DELETE", "GET", "HEAD", "OPTIONS", "PATCH", "POST", "PUT"] cache_policy_id = data.aws_cloudfront_cache_policy.caching_disabled.id cached_methods = ["GET", "HEAD"] compress = true path_pattern = "blog/*" target_origin_id = "blog" viewer_protocol_policy = "https-only" } ordered_cache_behavior { allowed_methods = ["DELETE", "GET", "HEAD", "OPTIONS", "PATCH", "POST", "PUT"] cache_policy_id = data.aws_cloudfront_cache_policy.caching_disabled.id cached_methods = ["GET", "HEAD"] compress = true path_pattern = "blog/" target_origin_id = "blog" viewer_protocol_policy = "https-only" } } |
CloudFrontでオリジンドメインをShifterのCloudfront URLにし、behaviorをキャッシュなしにすれば公開ができる。
- Shifterからデプロイ
ハマったが、最後にShifterからデプロイすれば、シェアボタンなどのリンクがShifterドメインになることはない。
Was this helpful?
0 / 0
1989年生まれのFindy/SRE。ホスティングから大規模なアドテクなどのインフラエンジニアとして携わる。現在はサービスの信頼性向上、DevOps、可用性、レイテンシ、パフォーマンス、モニタリング、オブザーバビリティ、緊急対応、AWSでのインフラ構築、Docker開発環境の提供、IaC、新技術の検証、リファクタリング、セキュリティ強化、分析基盤の運用などを担当している。個人事業主では数社サーバー保守とベンチャー企業のインフラコンサルティングを行うほか、TechBull創業と未経験者にSREのコーチング、コミュニティ運営、Members 会員管理システムの開発をリードしている。過去には脆弱性スキャナVulsのOSS活動にも貢献。