コマンドライン (CLI)¶
magic-pocketは pocket コマンドを提供します。
全てのデプロイ関連コマンドは --stage オプションで対象ステージを指定します。
以下の例では dev 環境を操作する場合を示します。
POCKET_DEPLOY_STAGE 環境変数¶
環境変数 POCKET_DEPLOY_STAGE を設定すると、--stage オプションのデフォルト値として使用されます。
export POCKET_DEPLOY_STAGE=dev
# 以下は全て --stage=dev と同等
pocket deploy
pocket status
pocket resource s3 status
--stage を明示的に指定すると、環境変数より優先されます。
POCKET_DEPLOY_STAGE も --stage も未指定の場合は、プロンプトで入力を求められます。
ランタイム用の POCKET_STAGE と別物です
Lambda 上のランタイム環境の判定には POCKET_STAGE という別の環境変数が使われます(実行環境 を参照)。
POCKET_DEPLOY_STAGE は ローカル側でデプロイ対象を指定する用途専用 で、ローカル実行プロセスの runtime 動作には影響しません。
これにより、ローカルで POCKET_DEPLOY_STAGE=prod を設定して pocket deploy を実行しつつ、manage.py shell などの runtime helper は AWS リソースを参照しない、という運用が可能です。
基本コマンド¶
pocket version¶
バージョンを表示します。
pocket deploy¶
全リソースをデプロイします。
pocket.toml の設定に応じて、以下の処理が行われます。
- Neonへのデータベース作成(
[neon]設定時) - TiDB クラスターの作成(
[tidb]設定時) - Upstash Redis データベースの作成(
[upstash]設定時) - RDS Aurora クラスターの作成(
[rds]設定時) - Secrets Managerへのシークレット登録
- S3バケットの作成と権限設定
- コンテナイメージの作成とECRへのアップロード
- CloudFormationによるLambda関連リソースの作成・更新
- CloudFormationによるCloudFront関連リソースの作成・更新
- フロントエンドのビルドとS3アップロード(
build/upload_dirが設定されたルートがある場合。ビルドを実行するのはbuildのみ)
| オプション | 説明 |
|---|---|
--stage |
対象ステージ |
--openpath |
デプロイ後にブラウザで開くパス |
--skip-frontend |
フロントエンドのビルド・アップロードをスキップ |
--yes, -y |
確認プロンプトをスキップ(非対話実行用) |
--skip-check-existing |
neon/tidb/upstash の存在確認 API をスキップ |
pocket promote¶
ビルド済みのコンテナイメージへステージを向けてデプロイします(再ビルドなし)。
pocket django build で push した :<commit hash> イメージに
:<stage> タグを付け替え、インフラ / Lambda を更新します。イメージのビルドは行いません。
指定した commit hash のイメージが ECR に存在しない場合はエラーになります(勝手にビルドしません)。
一度ビルドした同一イメージを複数ステージへ昇格させる build once 運用に使います。 詳細は「build once と昇格」を参照してください。
| オプション | 説明 |
|---|---|
--stage |
対象ステージ |
--commit-hash |
昇格するイメージの git commit hash(必須) |
--openpath |
デプロイ後にブラウザで開くパス |
--skip-frontend |
フロントエンドのビルド・アップロードをスキップ |
--yes, -y |
確認プロンプトをスキップ(非対話実行用) |
--skip-check-existing |
neon/tidb/upstash の存在確認 API をスキップ |
pocket status¶
全リソースの状態を確認します。
pocket destroy¶
ステージの全リソースを一括削除します。
| オプション | 説明 |
|---|---|
--stage |
対象ステージ |
--without-secrets |
pocket管理シークレットを削除せずに残す |
--with-state-bucket |
ステートバケットも削除 |
--yes, -y |
確認プロンプトをスキップ |
--skip-migrate |
migrate を実行しない(確認も出さない)。-y と併用可 |
デフォルトでpocket管理シークレット(SSM / Secrets Manager)も削除されます。
残したい場合は --without-secrets を指定してください。
削除は以下の順序(デプロイの逆順)で行われます:
- CloudFront(CFNスタック + バケットポリシー)+ ACM 証明書
- AwsContainer(CFNスタック + ECR + CodeBuild + CloudWatch Logs + secrets)+ VPC(CFNスタック + EFS)
- AWS Backup plan / selection(DSQL / RDS の cluster 削除より先。recovery point と vault は残す)
- DSQL クラスター
- RDS Aurora クラスター(Final Snapshot 付き)
- CloudFront 署名鍵(
signing_key設定時) - S3 バケット
- TiDB クラスタ
- Upstash Redis
- Neon ブランチ(root branch は Neon 仕様で単体削除できないため、project 内に 他の branch がなければ project ごと削除。他の branch が残っている場合は 巻き添えを避けるため警告してスキップ)
- ステートバケット(
--with-state-bucket指定時のみ)
ECR リポジトリの扱い
[container.main].ecr_name を明示指定している場合、
ECR リポジトリは他ステージと共有されている可能性があるため削除されません(警告を表示してスキップ)。
バックアップデータの扱い
バックアップデータ(recovery point)は既定では削除されず、残る場合は件数が警告表示されます。[backup] の deletable = true を宣言している場合のみ、destroy 実行中に [y/N] で削除するか確認されます(既定 No。--yes による一括承認ではデータ削除は行いません)。
実行前に削除対象の一覧が表示され、確認プロンプトが出ます。
pocket backup cleanup¶
ステージのバックアップデータ(AWS Backup の recovery point)を削除します。誤操作でデータを失わないため、[backup] の deletable = true を宣言している場合のみ実行できます(削除する時だけ宣言するのが推奨です)。
| オプション | 説明 |
|---|---|
--stage |
対象ステージ |
--yes, -y |
確認プロンプトをスキップ |
--skip-migrate |
migrate を実行しない(確認も出さない)。-y と併用可 |
削除対象は pocket 管理 vault(pocket-backup)にある、現存する対象 DB(dsql / managed rds)の recovery point です。plan(スケジュール)には触りません。--vault で利用者の vault に取ったオンデマンドバックアップは利用者の管理物とみなし削除しません。削除済み cluster の recovery point は ARN で引けないため対象外です(AWS Backup コンソールから削除してください)。
pocket runtime-config¶
Lambda ランタイム用の pocket.runtime.toml を生成します。ビルド専用設定(dockerfile_path, managed_assets, build, upload_dir 等)が除外されます。
詳細は「設定ファイル - pocket runtime-config」を参照してください。
Django コマンド¶
pocket django init¶
Djangoプロジェクトの初期設定ファイルを生成します。
以下のファイルが生成されます。
| ファイル | 説明 |
|---|---|
pocket.toml |
デプロイ設定 |
pocket.Dockerfile |
Lambda用Dockerfile |
settings.py |
環境変数対応に書き換え(django-environが必要) |
.env |
ローカル開発用の環境変数 |
pocket django deploy¶
デプロイ + マイグレーション + 静的ファイルをまとめて実行する便利コマンドです。
| オプション | 説明 |
|---|---|
--stage |
対象ステージ |
--openpath |
デプロイ後にブラウザで開くパス |
--yes, -y |
確認プロンプトをスキップ |
--skip-migrate |
migrate を実行しない(確認も出さない)。-y と併用可 |
--skip-check-existing |
neon/tidb/upstash の存在確認 API をスキップ |
pocket deploy との違い
pocket deploy はインフラのデプロイのみ行います。
pocket django deploy はインフラデプロイに加え、ローカルでの collectstatic + S3アップロード、Lambda上での migrate も対話形式で実行します。
DB に繋がらない状態でデプロイしたいとき
migrate は Lambda 経由で実際に DB へ接続するため、DB が停止・制限中だと
そこで失敗します。-y は「聞かれたことに全部 yes」なので migrate も走ります。
インフラ更新だけ通したい場合は --skip-migrate を付けてください
(pocket deploy に切り替えると collectstatic も行われない点に注意)。
pocket django build¶
現在の作業ツリーからコンテナイメージをビルドし、git commit hash(full)をタグにして ECR へ push します。デプロイは行いません。
- タグは
COMMIT_HASH環境変数があればそれを、なければgit rev-parse HEADを使います (CI ではCOMMIT_HASH=${{ github.sha }}のように渡せます) - commit hash とイメージ内容の一致が前提のため、作業ツリーに未コミットの変更がある
場合はエラーになります(
--allow-dirtyで回避できますが、そのイメージの昇格は 推奨しません)
| オプション | 説明 |
|---|---|
--stage |
対象ステージ |
--allow-dirty |
作業ツリーが dirty でもビルドする(ローカル検証用) |
pocket django promote¶
pocket promote に加え、ローカルでの collectstatic + S3アップロード、
Lambda 上での migrate も対話形式で実行します(pocket django deploy の昇格版)。
| オプション | 説明 |
|---|---|
--stage |
対象ステージ |
--commit-hash |
昇格するイメージの git commit hash(必須) |
--openpath |
デプロイ後にブラウザで開くパス |
--yes, -y |
確認プロンプトをスキップ |
--skip-migrate |
migrate を実行しない(確認も出さない)。-y と併用可 |
--skip-check-existing |
neon/tidb/upstash の存在確認 API をスキップ |
build once と昇格¶
pocket django deploy は実行のたびにイメージをビルドしますが、build + promote を
使うと 一度ビルドした同一イメージを複数ステージへ再ビルドなしで昇格できます
(build once)。
# 1. 一度だけビルド(:<full-sha> タグで push)
pocket django build --stage=dev
# 2. 同じイメージを各ステージへ昇格(再ビルドなし)
pocket django promote --stage=dev --commit-hash=<full-sha>
pocket django promote --stage=stg --commit-hash=<full-sha>
- イメージはステージ非依存です。
pocket.runtime.tomlは全ステージの設定を含んで イメージに焼き込まれ、ステージは Lambda のPOCKET_STAGE環境変数で実行時に解決 されます。build --stage=devの--stageは ECR リポジトリ等の対象を決めるだけで、 生成されるイメージ自体はどのステージでも動きます。 - ステージ間で ECR リポジトリを共有するには
[container.main].ecr_nameを設定します。デフォルトでは ECR リポジトリ名にステージ名が含まれるため、 ステージごとに別リポジトリになり昇格が成立しません。同一 AWS アカウント内の ステージで同じecr_nameを指定すると、昇格がタグの付け替えだけで完結します。 - 静的アセット(SPA ビルド + collectstatic)は昇格時も再ビルドされます。 build once の対象はコンテナイメージのみです。
- 通常の
pocket django deployの挙動は変わりません(commit hash タグも付きません)。 開発ループでは従来どおりdeployを、リリースフローではbuild+promoteを 使い分けてください。
pocket django manage¶
Lambda上でDjangoマネジメントコマンドを実行します。
# マイグレーション
pocket django manage migrate --stage=dev
# 静的ファイル収集
pocket django manage collectstatic --noinput --stage=dev
# スーパーユーザー作成
pocket django manage createsuperuser --username=admin --email=admin@example.com --noinput --stage=dev
| オプション | 説明 |
|---|---|
--stage |
対象ステージ |
--timeout-seconds |
ログ表示のタイムアウト(秒) |
pocket django resetdb¶
データベースの public スキーマをリセットします。
Lambda 経由で DROP SCHEMA public CASCADE; CREATE SCHEMA public; を実行し、全テーブルを削除します。
| オプション | 説明 |
|---|---|
--stage |
対象ステージ |
--yes, -y |
確認プロンプトをスキップ |
--skip-migrate |
migrate を実行しない(確認も出さない)。-y と併用可 |
リセット後は pocket django manage migrate --stage=dev でマイグレーションをやり直してください。
破壊的操作
全テーブルとデータが削除されます。本番環境での実行には十分注意してください。
pocket django deploystatic¶
静的ファイルのみをデプロイします(ローカルで collectstatic → S3にアップロード)。
| オプション | 説明 |
|---|---|
--stage |
対象ステージ |
--skip-collectstatic |
collectstaticをスキップしてアップロードのみ実行 |
--delete |
collectstatic 出力に無い S3 上のファイルを削除する (aws s3 sync --delete) |
--link / --no-link |
collectstatic に --link を渡す (大容量資産の複製コスト削減)。省略時は staticfiles 宣言の link に従う |
--delete は opt-in
デフォルトではアップロードのみで、S3 上の既存ファイルは削除しません。
削除すると、旧デプロイのアセットを参照中のリクエスト (キャッシュ済み HTML や
切替前の Lambda が返すページ) や過去 commit への rollback が壊れる可能性が
あるためです。不要ファイルの掃除をしたいときだけ --delete を付けてください。
静的ファイルの publish を deploy / promote から切り離したい場合
(CI と資産更新で publish 経路を分ける等) は、staticfiles 宣言に
publish = "command" を指定します (Django ストレージ設定 参照)。
link を常用する場合は、フラグではなく staticfiles 宣言に link = true を
指定してください。deploy / promote 内の collectstatic にも適用され、
link 有効時はビルド先を collectstatic 前に毎回クリアします
(非 link 実体との混在と壊れ symlink の残留を避けるため。同ドキュメント参照)。
pocket django storage upload¶
ローカルのファイルをデプロイ先のS3にアップロードします。
| オプション | 説明 |
|---|---|
--stage |
対象ステージ |
--delete |
S3側の不要ファイルを削除 |
--dryrun |
実行内容を表示するのみ |
ローカル側は filesystem、デプロイ先は s3 で定義されている必要があります。
使い方の例
pocket.toml でローカルとリモートのストレージを対応付けます。
[general.django_fallback.storages]
management = { store = "filesystem", location = "data/management" }
[container.main.django.storages]
management = { store = "s3", location = "management" }
ローカルの data/management/ にファイルを置き、以下でアップロードします。
リモートでも storages['management'] で同じファイルにアクセスできます。
リソースコマンド¶
個別リソースの状態確認や管理を行います。
container¶
# Lambda環境の状態確認
pocket resource container status --stage=dev
# wsgiエンドポイントのURLを表示
pocket resource container url --stage=dev
# CloudFormation YAMLを表示
pocket resource container yaml --stage=dev
# CloudFormation YAMLの差分を確認
pocket resource container yaml-diff --stage=dev
# CFNスタックの作成 / 更新(通常は pocket deploy 経由で実行)
pocket resource container create --stage=dev
pocket resource container update --stage=dev
# SSM/Secrets Manager の最新値で Lambda 環境変数を即時更新(CFNを介さない)
pocket resource container reload-env --stage=dev
# Lambda の現在の環境変数と SSM/Secrets Manager 上の宣言値の差分を表示
pocket resource container status-env --stage=dev
# リソース削除(CFNスタック + ECRリポジトリ)
pocket resource container destroy --stage=dev
# シークレットも含めて削除
pocket resource container destroy --stage=dev --with-secrets
secrets サブコマンド¶
# シークレットの一覧表示
pocket resource container secrets list --stage=dev
# 値も表示
pocket resource container secrets list --stage=dev --show-values
# pocket管理シークレットの作成
pocket resource container secrets create-pocket-managed --stage=dev
# pocket管理シークレットの削除
pocket resource container secrets delete-pocket-managed --stage=dev
image¶
pocket がビルド・デプロイしたコンテナイメージの参照情報を出力します。外部ツール
(pocket と併走するデプロイ系)が pocket の内部命名を再実装せずにイメージを参照
するための導線です。stdout には値のみが出るため $(...) でスクリプトから使えます。
# ECR リポジトリ名(ecr_name 上書きを含め pocket.toml 準拠)
pocket resource image repo --stage=sandbox
# deploy 済み実イメージの URI({repo_uri}@{digest}。以後の deploy でタグが動いても壊れない)
pocket resource image uri --stage=sandbox
toml を読まない静的導出には Python API の pocket.naming.ecr_repo_name() /
pocket.naming.ecr_image_tag() も利用できます(ecr_name や prefix_template を
上書きしている構成では引数で渡す必要があります。詳細は docstring 参照)。
neon¶
# Neon ブランチの状態確認
pocket resource neon status --stage=dev
# コンテキスト(テンプレートに渡される変数)を表示
pocket resource neon context --stage=dev
# ブランチの作成(通常は pocket deploy 経由で実行)
pocket resource neon create --stage=dev
# データベースの削除 + 再作成
pocket resource neon reset-database --stage=dev
# 別ステージのブランチから分岐して作成
pocket resource neon branch-out --stage=feature1 --base-stage=dev
# ブランチの削除
# (root branch は Neon 仕様で単体削除できないため、project 内に他の branch が
# なければ再確認のうえ project ごと削除。他の branch が残る場合はエラーで中断)
pocket resource neon delete --stage=dev
# provisioning="command" 用: branch/role/db を ensure し DATABASE_URL を stored user
# secret に保存(既存があれば --force で上書き)
pocket resource neon store-url --stage=dev
store-url は保存前に、解決した接続先を表示します(pocket.toml の意図と目視照合
できます)。この実行で branch を新規作成した場合(= 空の branch に接続する)は
警告が添えられるため、既存データへ接続するつもりで意図しない branch 名を焼いた
ことに気づけます:
stage=dev → project=dev-myapp → branch=main → endpoint=ep-misty-cherry-xxxx.ap-southeast-1.aws.neon.tech
Neon URL を DATABASE_URL (/dev-myapp-pocket-user/neon_database_url) に保存しました。
tidb¶
# TiDB クラスターの状態確認
pocket resource tidb status --stage=dev
# コンテキストを表示
pocket resource tidb context --stage=dev
# クラスターの作成(通常は pocket deploy 経由で実行)
pocket resource tidb create --stage=dev
# データベースの削除 + 再作成
pocket resource tidb reset-database --stage=dev
# クラスターの削除
pocket resource tidb delete --stage=dev
# provisioning="command" 用: cluster/db を ensure し DATABASE_URL を stored user secret に
# 保存(既存があれば --force で上書き。TiDB は実行ごとに root password をローテーション)
pocket resource tidb store-url --stage=dev
upstash¶
# provisioning="command" 用: database を ensure し REDIS_URL を stored user secret に保存
# (既存があれば --force で上書き)
pocket resource upstash store-url --stage=dev
dsql¶
# DSQL クラスターの状態確認
pocket resource dsql status --stage=dev
# 接続情報の表示(endpoint, region, port)
pocket resource dsql endpoint --stage=dev
# 機械可読な JSON で stdout に出力(スクリプト / CI 向け。クラスター不在時は exit 1)
pocket resource dsql endpoint --stage=dev --format=json
# => {"endpoint": "xxxxx.dsql.ap-northeast-1.on.aws", "region": "ap-northeast-1", "port": 5432}
# オンデマンドバックアップの開始(AWS Backup。DSQL に組み込みの自動バックアップは
# 無いため、これが唯一のバックアップ手段。--watch で完了まで待機)
# 前提リソース(vault "pocket-backup" とサービスロール "forge-pocket-backup-role")は
# 初回実行時に冪等に自動作成される
pocket resource dsql backup --stage=dev
pocket resource dsql backup --stage=dev --watch
# 既存の vault・サービスロールを使う場合や保持日数の指定(指定したものは存在確認しない)
pocket resource dsql backup --stage=dev --vault=my-vault \
--iam-role-arn=arn:aws:iam::123456789012:role/my-backup-role --retention-days=35
# 明示的に無期限で残す(pocket からは削除できなくなるため警告が出る)
pocket resource dsql backup --stage=dev --retention-days=0
# バックアップ job の状態確認(--job-id 省略時はこのクラスターの最新 job。
# --watch で終端状態まで待機。aws CLI 直接でも可:
# aws backup describe-backup-job --backup-job-id <id> --region <region>)
pocket resource dsql backup-status --stage=dev
pocket resource dsql backup-status --stage=dev --job-id=<id> --watch
# バックアップからの復元(新しいクラスターを作成して現用に切り替える)
# 復元前に現用クラスターのバックアップを取るか確認する(--skip-backup で省略、
# --yes で自動承認)。restore job の完了まで待機する
pocket resource dsql restore --stage=dev --latest
pocket resource dsql restore --stage=dev <recovery-point-arn>
# 待機が中断された場合に、切り替えを再開・完了させる(冪等)
pocket resource dsql restore-status --stage=dev --job-id=<id>
# クラスターの削除(確認プロンプト付き)
pocket resource dsql destroy --stage=dev
オンデマンドバックアップの保持日数
--retention-days を省略した場合の保持日数は [backup.dsql] の最長階層(monthly)の delete_after_days(既定 1095 日 = 3 年)→ 宣言が無ければ 1095 日 の順で決まります。解決結果は実行時に Retention: 1095 days (from [backup.dsql] monthly) のように表示されます。復元前に取られる現用クラスターのバックアップも同じ解決を通ります。
保持日数を渡さないと AWS Backup の recovery point は無期限に残ります。pocket がバックアップデータを削除するのは [backup] の deletable = true 宣言 + 明示確認の経路だけのため(設定ファイルの「backup」節を参照)、無期限の recovery point は放置すると残り続けます。既定で失効日を付けているのはこのためです。
意図して無期限にする場合は --retention-days=0 を明示してください(警告を出したうえで Lifecycle を付けずに実行します)。
定期バックアップの job が一覧に出るまでのラグ
[backup.dsql] の plan 由来の job は、スケジュール時刻を過ぎても backup-status(AWS Backup の ListBackupJobs)やコンソールの一覧にすぐには現れません。実測で 30 分ほど遅れて CREATED として見え始めた例があります(CreationDate はスケジュール時刻のまま)。
さらに AWS Backup は指定時刻ちょうどではなく start window 内で開始するため、一覧に出ない = 実行されなかった、ではありません。定期実行の確認は時間に余裕を持って行ってください。
復元後は deploy が必要です
復元は常に新しいクラスターを作成します(AWS Backup は既存クラスターを上書きしません)。restore は Name タグの付け替えと SSM の endpoint 更新まで行いますが、Lambda の POCKET_DSQL_ENDPOINT と dsql:DbConnectAdmin の対象 ARN は CloudFormation 管理のため、pocket deploy を実行するまでアプリは旧クラスターに書き込み続けます。
旧クラスターは削除しません(復元結果が期待どおりでなかったときの戻り先)。Name タグを <tag_name>-replaced-<identifier> へ退避するだけなので、明示的に削除するまで課金され続けます。
マルチリージョンクラスターの復元には witness / peer リージョンの指定が必要で、pocket は対応していません(AWS Backup のコンソールまたは CLI を使用してください)。
rds¶
# RDS Aurora クラスターの状態確認
pocket resource rds status --stage=dev
# 接続情報の表示(endpoint, port, database, username)
pocket resource rds endpoint --stage=dev
# 機械可読な JSON で stdout に出力(スクリプト / CI 向け。クラスター不在時は exit 1)
pocket resource rds endpoint --stage=dev --format=json
# クラスターの削除(確認プロンプト付き、Final Snapshot 作成)
pocket resource rds destroy --stage=dev
s3¶
# S3バケットの状態確認
pocket resource s3 status --stage=dev
# コンテキストを表示
pocket resource s3 context --stage=dev
# バケットの作成(通常は pocket deploy 経由で実行)
pocket resource s3 create --stage=dev
# S3バケットを中身ごと削除
pocket resource s3 destroy --stage=dev
cloudfront¶
# CloudFrontの状態確認
pocket resource cloudfront status --stage=dev
# CloudFormation YAMLを表示
pocket resource cloudfront yaml --stage=dev
# CloudFormation YAMLの差分を確認
pocket resource cloudfront yaml-diff --stage=dev
# コンテキスト(テンプレートに渡される変数)を表示
pocket resource cloudfront context --stage=dev
# 特定のディストリビューションのみ
pocket resource cloudfront yaml --stage=dev --name=main
# CFNスタックの作成 / 更新 / 削除(通常は pocket deploy / destroy 経由で実行)
pocket resource cloudfront create --stage=dev
pocket resource cloudfront update --stage=dev
pocket resource cloudfront destroy --stage=dev
# フロントエンドのビルド・S3アップロード・キャッシュ無効化
pocket resource cloudfront upload --stage=dev
# ビルドをスキップしてアップロードのみ
pocket resource cloudfront upload --stage=dev --skip-build
# 特定のディストリビューションのみ
pocket resource cloudfront upload --stage=dev --name=main
upload は build / upload_dir が設定されたルートに対して、ビルド(build のルートのみ)→ S3アップロード → CloudFrontキャッシュ無効化を実行します。
pocket deploy 実行時にも自動的に呼ばれます(--skip-frontend で抑制可能)。
アップロードは差分のみです。S3 上のオブジェクトと内容が一致するファイルはスキップされるため、数千ファイル規模のアセットを upload_dir に置いても deploy 時間は伸びません(判定は ETag。詳細は routes を参照)。
キャッシュ無効化も変更があったルートの path_pattern に限定され、変更が無ければ invalidation 自体を発行しません。
cloudfront_keys¶
CloudFront 署名付き URL 用の鍵リソースを管理します。signing_key が設定されたディストリビューションのみ対象です。
# CloudFormation YAMLを表示
pocket resource cloudfront-keys yaml --stage=dev
# CloudFormation YAMLの差分を確認
pocket resource cloudfront-keys yaml-diff --stage=dev
# 状態確認
pocket resource cloudfront-keys status --stage=dev
# 鍵リソースの削除
pocket resource cloudfront-keys destroy --stage=dev
# 特定のディストリビューションのみ
pocket resource cloudfront-keys yaml --stage=dev --name=media
cloudfront_waf¶
CloudFront にアタッチする WAFv2 (IP allowlist) リソースを管理します。waf が設定されたディストリビューションのみ対象です。
# 状態確認
pocket resource cloudfront-waf status --stage=dev
# CloudFormation YAMLを表示
pocket resource cloudfront-waf yaml --stage=dev
# CloudFormation YAMLの差分を確認
pocket resource cloudfront-waf yaml-diff --stage=dev
# WAFリソースの削除
pocket resource cloudfront-waf destroy --stage=dev
vpc¶
# VPCの状態確認
pocket resource vpc status
# CloudFormation YAMLを表示
pocket resource vpc yaml
# CloudFormation YAMLの差分を確認
pocket resource vpc yaml-diff
# CFNスタックの作成 / 更新(通常は pocket deploy 経由で実行)
pocket resource vpc create
pocket resource vpc update
# VPCを削除(CFNスタック + EFS)
pocket resource vpc destroy
VPCコマンド
VPC は pocket.toml の [vpc] セクションから自動的に読み込まれます。
外部 VPC(manage = false)の場合、create / update / destroy は実行できません。
consumer がいる managed VPC は削除できません。
CloudFormation テンプレートの確認¶
各リソースの yaml サブコマンドで、デプロイ時に使われる CloudFormation テンプレートを標準出力で確認できます。
AWS にアクセスせずにテンプレートの内容を確認したい場合に便利です。
# container(Lambda関連)
pocket resource container yaml --stage=dev
# cloudfront
pocket resource cloudfront yaml --stage=dev
# cloudfront_keys(署名付きURL用鍵)
pocket resource cloudfront-keys yaml --stage=dev
# vpc
pocket resource vpc yaml
yaml-diff サブコマンドでは、デプロイ済みのテンプレートとの差分を JSON で表示します。
デプロイ前に変更内容を確認する際に使います。