WordPress Application

WordPress を作成し、Load Balancer から配信して、最初の管理者を作るまでの手順です。新しい Application は非公開で作られ、一般公開は最後に明示的に行います。

流れ

Application を作成し、Runtime の準備を待つ
Load Balancer の Edge Service へ公開を設定し、DNS を追加する
WordPress の初期設定画面を開き、最初の管理者を作る
必要なら、アクセス制限を外して誰でも閲覧できるようにする

以下の例では、Application ID を blog、ドメインを blog.example.com、論理 Load Balancer を public-entry、Edge Service を blog-edge とします。

始める前に

Project で server が有効で、server.wordpressApplications の上限が設定されていること（Project と権限）
作成する人に roles/application.creator があること
運用者が、この Project の WordPress の配置を承認していること
公開に使う論理 Load Balancer があること（Load Balancer）
使うドメインの DNS を変更できること

1. 作成する

Console では Project の「資源」から「WordPress を作成」を開きます。CLI では次のとおりです。

acloud server applications create blog --display-name "Blog" --domain blog.example.com

サブディレクトリで配信する場合は --base-path /PATH を付けます。
表示名、ドメイン、パス、公開方式は後から変更できません。
応答が返らなかった場合は、同じコマンドをもう一度実行します。最初の要求で作られたものが返ります。

作成が受け付けられても、WordPress はまだ使えません。Runtime の準備ができたかを確かめます。

acloud server applications runtime describe blog

Runtime が READY になると、WordPress のファイルとデータベースがそろった状態です。初期設定（管理者の作成）は済んでおらず、ドメインでの配信もまだ始まっていません。

2. 公開を設定する

公開には Application の roles/application.publisher と、Load Balancer で Edge Service を作成・変更する役割（roles/edge.creator、roles/edge.operator）が必要です。Console では Application の概要にある「公開設定を開始」から進めます。

acloud server applications publication start blog blog-edge --load-balancer public-entry
acloud server applications publication describe blog

describe は、いまの段階と、次に誰が何をするかを返します。指示された DNS レコードを追加してから進めます。

acloud server applications publication advance blog

advance は、その時点で進められるところまで進め、配信経路を確認します。DNS の反映や証明書の発行を待つ間は、時間をおいて繰り返します。Console では「公開を進める・再確認」です。

段階	意味と次の作業
`RESERVATION_REQUIRED`	運用者の作業待ちです
`EDGE_SERVICE_REQUIRED`	`advance` で Edge Service を作ります。拒否された場合は表示された理由を確認します
`HOST_REQUIRED`	ドメインの所有確認の TXT レコード（`_arc-platform-verification.blog.example.com`）を追加し、`advance` を実行します
`HOST_PENDING`	証明書の DNS 認証用の CNAME レコードを追加し、配信の準備を待ちます
`VERIFICATION_REQUIRED`	配信先の A レコードを追加し、`advance` で経路を確認します
`VERIFIED`	最後の確認ですべての段階を通りました

配信していると言えるのは、VERIFIED の間だけです。作成や公開の要求が受け付けられたことは、配信の開始を意味しません。後の確認で失敗した場合は、その結果が表示されます。

3. WordPress を初期設定する

ドメインが HTTPS で Runtime に届くようになってから行います。初期設定画面を開くには roles/application.setupAdmin が必要です。この役割は作成者や Owner には含まれません。

Console では Application の概要で「WordPress の初期設定を開く」を選びます。初期設定画面が新しいタブで開きます。ポップアップが止められた場合は、Console のポップアップを許可してやり直します。CLI では次のとおりです。

acloud server applications setup-sessions create blog

表示された URL を開き、WordPress の初期設定画面で最初の管理者を作成します。応答は Application のアクセス制限によって 2 通りあります。

期限が表示されない場合：開くと ArcID でのログインを求められます。初期設定の権限を持つアカウントでログインします。権限とアカウントの状態は、要求のたびに確かめられます。
期限（Expires）が表示された場合：URL そのものが初期設定の権限になります。期限が切れたら、もう一度発行します。URL を開いた人が最初の管理者を作れるため、他の人に渡したり保存したりしないでください。初期設定を終える browser で開きます。

初期設定が済んだ Application には発行されません。

4. 誰でも閲覧できるようにする

新しい Application は、アクセス制限（IAP）が有効な状態で作られます。この間は、その Application の閲覧権限を持つ ArcID アカウントだけがサイトを開けます。初期設定が済んでも、制限は自動では外れません。

一般公開するときは、roles/application.publisher を持つ人が明示的に制限を外します。

Console：Application の概要の「アクセス制限（IAP）」で「IAP を無効にして公開する」を選び、確認の表示で「IAP を無効にする」を選びます。
CLI：誤操作を防ぐため、--confirm に Application ID を指定します。

acloud server applications iap describe blog
acloud server applications iap disable blog --confirm blog

公開中の Application では、設定の変更に続けて配信への反映が実行されます。反映が終わったかは iap describe の observed.state で確かめます。

`observed.state`	意味
`PROTECTED`	IAP が応答していることを観測した。保護されていると言えるのはこの時だけです
`PUBLIC_BACKEND`	誰でも閲覧できる経路で配信している
`NOT_OBSERVED`	変更後の配信をまだ観測していない。`publication advance` を実行します
`IAP_NOT_OBSERVED`	保護の経路を選んでいるが、IAP の応答を確認できなかった

もう一度制限するときは acloud server applications iap enable blog を実行するか、Console で「IAP を有効にする」を選びます。

運用中の操作

操作	`acloud` に続けるコマンド	役割
構成を読む	`server applications configuration describe blog`	`roles/application.viewer`
ログを読む	`server applications logs list blog --source request --period 24h`	`roles/application.logViewer`
使用量を読む	`server applications usage describe blog --month 2026-10`	`roles/application.usageViewer`
バックアップの一覧	`server applications backups list blog`	`roles/application.backupViewer`
バックアップから戻す	`server applications backups restore BACKUP --application blog --confirm BACKUP`	`roles/application.backupRestorer`

ログには訪問者の IP アドレスが含まれるため、閲覧の役割とは別に付与します。バックアップからの復元は、データベースとファイルを置き換えます。

削除と復元

削除と復元には roles/application.lifecycleOperator が必要です。配信中の Application は、先に公開を解除してから削除します。

acloud server applications publication unpublish blog
acloud server applications delete blog
acloud server applications restore blog

削除後も、表示される期限（PURGE_TIME）までは復元できます。
削除後に publication retire blog を実行すると公開設定を廃止します。廃止した Application は復元できません。

ヘッドレス配信

WordPress を別の公開 Application の配下で origin として使う方式（--publishing-mode headless）は、作成時にだけ指定できます。運用者が有効にするまでは作成が拒否されます。