AI は誤ることがあります。原文をご確認ください 専用ページで開く
ドキュメントに質問
目次

腾讯云 EdgeOne + COS 導入ガイド

11 分で読了
このページの目次

本稿では、2つの一般的な導入パターンを整理しています。

  1. API 加速⁠：クライアントは EdgeOne エッジノードで TLS を終端し、EdgeOne は HTTPS 経由でロードバランサまたはオリジンサーバーに戻し元接続を行います。
  2. 静的サイト⁠：ビルド成果物を COS にアップロードし、EdgeOne がカスタムドメイン、HTTPS、キャッシュおよび削除機能を提供します。

すべての例ではプレースホルダーを使用しており、実際のアカウント、ドメイン、バケット、ゾーン、ロードバランサまたは認証情報は含まれていません。本番環境における SecretId、SecretKey および一時的トークンは、環境変数、シークレット管理サービスまたは CI のシークレットストアから取得する必要があります。リポジトリや公開ドキュメントに書き込むことはできません。

1. 変数とセキュリティの境界

以降のコマンドでは、環境変数を統一して使用します。

export TENCENTCLOUD_SECRET_ID='<secret-id>'
export TENCENTCLOUD_SECRET_KEY='<secret-key>'

export EO_ZONE_ID='<edgeone-zone-id>'
export API_DOMAIN='api.example.com'
export STATIC_DOMAIN='www.example.com'
export ORIGIN_DOMAIN='origin.example.internal'

export COS_BUCKET='example-web-<appid>'
export COS_REGION='ap-guangzhou'

セキュリティの原則：

  • 管理アカウントはインフラストラクチャの作成にのみ使用し、デプロイパイプラインでは独立したサブアカウントまたは短期間の認証情報を使用します。
  • IAM/CAM ポリシーは、具体的なバケットおよび必要なアクションに対して権限付与を行い、アカウントレベルの cos:* は使用しません。
  • ログ、シェル履歴、CI 出力には SecretKey または署名後の完全なリクエストヘッダーを出力しないでください。
  • 公開ドキュメントではプレースホルダーのみを表示し、実際のリソース一覧はプライベートな運用管理システムに格納してください。

2. パターン A：EdgeOne HTTPS 戻し元 API

2. パターン A：EdgeOne HTTPS 戻し元 API HTTPS HTTPS origin fetch Client EdgeOne Edge Load Balancer / Reverse Proxy Application

推奨順序は「戻し元設定 → 証明書 → DNS」です。これにより、本番トラフィックの切替前に検証を完了でき、証明書がデプロイされていないことや、戻し元の Host が一致しないことによる 5xx エラーを回避できます。

2.1 加速ドメインの作成

tccli teo CreateAccelerationDomain \
  --region ap-guangzhou \
  --endpoint teo.tencentcloudapi.com \
  --ZoneId "$EO_ZONE_ID" \
  --DomainName "$API_DOMAIN" \
  --OriginInfo '{"OriginType":"IP_DOMAIN","Origin":"'"$ORIGIN_DOMAIN"'","PrivateAccess":"off"}' \
  --OriginProtocol HTTPS \
  --HttpsOriginPort 443

以下の設定を確認してください。

  • オリジンサーバーの証明書が ORIGIN_DOMAIN をカバーしており、証明書チェーンが完全で期限が切れていないこと。
  • 戻し元の Host がロードバランサのレイヤー7ルーティングルールと一致していること。
  • オリジンサーバーの 443 ポートが EdgeOne の戻し元接続を許可しており、管理ポートが意図せず公開されていないこと。
  • HTTP から HTTPS へのリダイレクトが期待されるレイヤーで処理されており、戻し元のリダイレクトループが発生していないこと。

2.2 エッジ証明書のデプロイ

tccli teo ModifyHostsCertificate \
  --region ap-guangzhou \
  --endpoint teo.tencentcloudapi.com \
  --ZoneId "$EO_ZONE_ID" \
  --Hosts '["'"$API_DOMAIN"'"]' \
  --Mode eofreecert

ドメインと証明書の状態をポーリングし、両方が準備完了であることを確認してから DNS を変更してください。

tccli teo DescribeAccelerationDomains \
  --region ap-guangzhou \
  --endpoint teo.tencentcloudapi.com \
  --ZoneId "$EO_ZONE_ID"

2.3 切替前の検証

まず、EdgeOne が割り当てたアクセスドメインへ解決し、curl --resolve を使用してリクエストをエッジノードにヒットさせ、正しい SNI と Host を保持します。

EO_CNAME="${API_DOMAIN}.eo.dnse1.com"
EO_IP=$(dig +short "$EO_CNAME" A | awk '/^[0-9.]+$/ {print; exit}')

curl --fail --show-error --silent \
  --resolve "${API_DOMAIN}:443:${EO_IP}" \
  -o /dev/null \
  -w 'HTTP %{http_code} TLS %{ssl_verify_result}\n' \
  "https://${API_DOMAIN}/health"

TLS 検証が 0 で、ヘルスチェックが期待されるステータスを返し、戻し元ログに異常がない場合に限り、ビジネスドメインの CNAME を EdgeOne に向けてください。

2.4 DNS の切替

tccli dnspod ModifyRecord \
  --endpoint dnspod.tencentcloudapi.com \
  --Domain example.com \
  --RecordId '<record-id>' \
  --SubDomain api \
  --RecordType CNAME \
  --RecordLine Default \
  --Value "${API_DOMAIN}.eo.dnse1.com" \
  --TTL 600

切替前に TTL を短く設定し、安定稼働後に通常の TTL に戻してください。元のレコード値を保持し、異常発生時に迅速にロールバックできるようにしてください。

3. パターン B：COS 静的サイト + EdgeOne

3. パターン B：COS 静的サイト + EdgeOne HTTPS Origin fetch Browser EdgeOne Edge COS static website endpoint

3.1 バケットの準備

静的サイトホスティングには通常以下が必要です。

  • 指定されたリージョンにバケットを作成する。
  • index.html および静的アセットをアップロードする。
  • 静的サイトのトップページとエラーページを設定する。
  • ビジネスの要件に応じて、公開読み取り、プライベート戻し元または署名アクセスを選択し、バケット全体に書き込み権限を無条件に付与しないこと。

COS 静的サイトエンドポイントは通常以下の形式になります。

<bucket>.cos-website.<region>.myqcloud.com

3.2 静的サイト加速ドメインの作成

COS_WEBSITE_ENDPOINT="${COS_BUCKET}.cos-website.${COS_REGION}.myqcloud.com"

tccli teo CreateAccelerationDomain \
  --region ap-guangzhou \
  --endpoint teo.tencentcloudapi.com \
  --ZoneId "$EO_ZONE_ID" \
  --DomainName "$STATIC_DOMAIN" \
  --OriginInfo '{"OriginType":"COS","Origin":"'"$COS_WEBSITE_ENDPOINT"'","PrivateAccess":"off"}' \
  --OriginProtocol FOLLOW \
  --HttpOriginPort 80 \
  --HttpsOriginPort 443

OriginType=COS の場合、HostHeader を追加で設定しないでください。プラットフォームが COS オリジンタイプに基づいて処理します。その後、パターン A の順序に従ってエッジ証明書をデプロイし、事前検証を行ってから DNS を切替えます。

3.3 アップロードとキャッシュ削除

coscli sync ./dist "cos://${COS_BUCKET}/" \
  --region "$COS_REGION" \
  --delete

tccli teo CreatePurgeTask \
  --region ap-guangzhou \
  --endpoint teo.tencentcloudapi.com \
  --ZoneId "$EO_ZONE_ID" \
  --Type purge_host \
  --Targets '["'"$STATIC_DOMAIN"'"]'

--delete はターゲットエンドポイントに余分なオブジェクトを削除するため、ビルドディレクトリとターゲットバケットのプレフィックスが確認されている場合にのみ使用してください。公開プロセスでこれを保証できない場合は、不変のファイル名を使用し、新規リソースのみをアップロードしてください。

4. 最小権限

デプロイアカウントは、ターゲットバケットおよびキャッシュ削除に必要な権限のみを取得する必要があります。以下は構造の例であり、そのまま適用できる完全なポリシーではありません。

{
  "version": "2.0",
  "statement": [
    {
      "effect": "allow",
      "action": [
        "cos:PutObject",
        "cos:DeleteObject",
        "cos:GetObject",
        "cos:GetBucket"
      ],
      "resource": [
        "qcs::cos:<region>:uid/<appid>:<bucket>/*"
      ]
    },
    {
      "effect": "allow",
      "action": ["teo:CreatePurgeTask"],
      "resource": ["<edgeone-resource-scope>"]
    }
  ]
}

実際のアクション名およびリソース形式は、現在の腾讯云 CAM ドキュメントおよび API のレスポンスに基づいてください。本番公開前に独立したテストアカウントを使用して、「公開は可能だが、他のバケットの管理はできない」ことを検証してください。

5. 公開チェックリスト

  • EdgeOne ドメインの状態が正常であること。
  • エッジ証明書がビジネスドメインをカバーしており、証明書チェーンと有効期限が正常であること。
  • API 戻し元が HTTPS を使用しており、オリジンサーバーの証明書と Host ルーティングが正しいこと。
  • curl --resolve による事前検証が通過していること。
  • DNS の元の値が記録されており、障害時にロールバックできること。
  • 静的アセットがコンテンツハッシュまたは明確なキャッシュバージョン戦略を使用していること。
  • HTML のキャッシュ時間が、ハッシュ付きの JS/CSS/画像よりも短く設定されていること。
  • デプロイアカウントがターゲットリソースに対して最小権限のみを持っていること。
  • ログ、スクリプト、ドキュメントに実際の秘密鍵またはアカウントレベルのリソース一覧が含まれていないこと。

6. 一般的な障害

症状一般的な原因トラブルシューティング方法
teo.intl... のタイムアウトCLI が国際サイトエンドポイントを使用している--endpoint teo.tencentcloudapi.com を明示的に指定する
TLS 接続失敗エッジ証明書がデプロイ中である、または SNI/ドメインが一致しない証明書状態を確認し、openssl s_client -servername で検証する
EdgeOne が 5xx を返すオリジンサーバーに到達できない、戻し元の Host が誤っている、またはオリジンサーバーの証明書失敗戻し元ログを確認し、オリジンサーバーの HTTPS を直接検証する
COS 戻し元設定が HostHeader を拒否するCOS オリジンタイプはカスタム HostHeader を許可していない該設定を削除し、プラットフォームに自動処理させる
アップロードが 403 AccessDenied で返るサブアカウントがターゲットバケットのアクションまたはリソース範囲の権限を欠いているCAM ポリシーの action と resource を確認する
公開後も古いページが表示されるHTML のキャッシュが削除されていない、またはキャッシュキーが期待通りではないキャッシュ状態を確認し、ドメイン/URL で削除を行う
DNS 切替後、一部の地域でまだ古いソースにアクセスするTTL が期限切れになっていない、または再帰ネームサーバーがキャッシュしている複数のパブリック DNS でクエリを実行し、伝播を待つ

7. ロールバック

証明書、戻し元またはキャッシュに異常が発生した場合：

  1. DNS を切替前のレコードに戻す。
  2. オリジンサーバーへのダイレクト接続が利用可能であることを確認する。
  3. EdgeOne の設定を保持し、オフラインでのトラブルシューティングに使用する。障害中に連続して変更を加えないこと。
  4. 修正後、再度 curl --resolve による事前検証を行い、次の切替を行う。

証明書デプロイ、事前検証、DNS 切替、およびロールバックを明確に分離することは、「ドメイン作成後に直ちに DNS を変更する」よりもはるかに信頼性が高くなります。

リンクプレビュー

新しいタブで開く