明細を見ると、Artifact Registry Storage／Artifact Registry で料金が発生していました。

どうゆこと？

App Engine コンテナ イメージを Artifact Registry に移行する  |  App Engine migration center  |  Google Cloud Documentation

App Engineのコンテナイメージのデプロイに Artifact Registry が使用されるとのこと。そして料金は、

料金  |  Artifact Registry  |  Google Cloud

0.5GBを超えると、1GBごとに約$0.10/月≒15円/月ほど発生します。

初めのころは特にデプロイを試行錯誤していたので、古いコンテナイメージが消されずに残ることで無料枠を超えて課金となったようです

対策

Artifact Registry にはクリーンアップポリシーという条件に合ったイメージを自動で削除してくれる機能がありますので、これを利用することにしました。

稼働中のアプリケーションのイメージは再起動やスケーリングの際に必要になるので削除してはダメなので、最新イメージを保持、それ以外は消していくルールにします。

Artifact Registry > レポジトリ > gae-standard でレポジトリの編集をクリック、そして設定一覧の中に「クリーンアップポリシーを追加」というボタンを押下します。

保持ルール作成

最新イメージには latestタグが付けられているので保持ルールの条件にします。

削除ルール作成

それ以外のイメージを削除するルールを登録します。今回は1日経過したものを対象としてみました。（入力時は 1d としましたが開きなおすと 86400s になっていました）

クリーンアップポリシーは設定してから実際に実行されるまで、数時間から1日くらいかかるとのことです。しばらく経ってから意図通りイメージが削除されているか確認しましょう。

とくにコメント機能が盛り上がっているわけでもないので静的サイトで十分じゃないか、という結論に達しまして。編集作業はローカルで行い、静的サイトとしてエクスポートして公開することにしました。

ローカルでWordPressを稼働させるにあたり、SynologyのNASを活用させることにしました。というわけでそれなりに苦労もしたので手順を残しておきたいと思います。

移行の手順

WordPress

我が家にある SynologyのNASは DS216j です。家庭用の低価格マシンです。

パッケージセンターから WordPressを探してインストールすると、依存関係にある Apache HTTP Server や PHP や MariaDB も自動でインストールされます。これは楽ちんです。やり方を紹介しているサイトもたくさん見つかります。

最新版のWordPressではなく Synology が動作確認したバージョンで固定されたものになります。（私がインストールしたときは、WordPress 6.1.1、Apache HTTP Server 2.4、PHP 8.0、MariaDB 10.3.32 でした。）

インストールが完了したらサイトの移行を行います。WordPress間の移行はエクスポート機能を利用することができるので省略します。

GitHub

まず、GitHub に公開資材を格納するレポジトリ（komina-info-publish）をPrivateで作成しました。任意のディレクトリで git clone して初期資材を作成していきます。

$ git clone https://github.com/komina77/komina-info-publish.git

komina-info-publish
 ├── app.yaml
 └── www/
      └── index.html

runtime: python313       # ランタイム指定（静的でも必須）
instance_class: F1       # 無料枠を使うならF1を指定
automatic_scaling:
  min_instances: 0
  max_instances: 1

handlers:
  # ルートURLの場合 index.html を返す
  - url: /
    static_files: www/index.html
    upload: www/index.html

  # その他のパスは www/ 以下のファイルにマッピング
  - url: /(.*)
    static_files: www/\1
    upload: www/(.*)

<h1>Hello, World!</h1>

App Engine

サイト公開用のプロジェクトの準備ができたら、Google Cloud にログインしプロジェクト（komina-info-publish）を作成、App Engineでアプリ作成します。

• 近場の東京リージョン（asia-northeast1）を選択
• サービスアカウントはデフォルト設定
• 言語は Python、Standard環境を選択。

AppEngine側の準備ができたらプロジェクトを手動でデプロイして動作確認してみます。

$ gcloud app deploy
$ gcloud app browse

ブラウザにテスト用のindex.htmlの内容が表示されていればOKです。

GitHub → AppEngine

そうしたら、GitHub のコミット契機で AppEngine へデプロイされる仕組みを作ります。

Google Cloud Console で IAM サービスアカウント作成します。

1. 権限付与
   • App Engine Deployer(App Engine デプロイ担当者)
   • Storage Admin(Storage オブジェクト管理者)
   • App Engine Admin(App Engine管理者)
   • Cloud Build Service Account(Cloud Build サービスアカウント)
   • Service Account User(サービスアカウントユーザ)
2. 鍵を作成、json形式で保存

GitHub→Settings→Secrets and variables→Actions を開き、新しいSecret作成します（名前は GCP_CREDDENTIALS、内容はjson形式の鍵ファイルの中身を転記）。

GitHub→Settings→Secrets and variables→Actions を開き、新しいRepositoryVariable作成します（名前はGCP_PROJECT_ID、値は komina-info-publish）。

AppEngineへのデプロイ準備が整ったら、mainブランチへのpushをトリガにして AppEngineへデプロイするジョブを作成します。

name: Deploy to App Engine

on:
  push:
    branches: [ main ]   # mainブランチへのpushをトリガー

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout source
        uses: actions/checkout@v3

      - name: Authenticate to Google Cloud
        uses: google-github-actions/auth@v2
        with:
          credentials_json: ${{ secrets.GCP_CREDENTIALS }}

      - name: Deploy to App Engine
        uses: google-github-actions/deploy-appengine@v1
        with:
          project_id: ${{ vars.GCP_PROJECT_ID }}   # リポジトリ変数から取得
          deliverables: app.yaml            # デプロイ対象

      - name: Clean up old versions
        run: |
          # トラフィック割当0%の全バージョンを削除
          gcloud app versions list \
            --project=${{ vars.GCP_PROJECT_ID }} \
            --format="value(version.id)" \
            --filter="traffic_split=0.0" | \
          xargs -r gcloud app versions delete \
            --project=${{ vars.GCP_PROJECT_ID }} --quiet

App Engine Admin APIを有効にします。

main/www 配下に任意のweb資材を置いてpush。App Engine へリリースされていることを確認できればOKです。

WordPress-Staaticプラグイン

静的サイトを出力するプラグインとしては Simply Static というプラグインが有名なようです。残念ながら WordPress 6.1.1 では動作しないということでインストールできなかったので、次点でヒットした Staatic – Static Site Generator をインストールしました。

• GitHub の プロフィールアイコンから、Settings → Developer settings → Personal access tokens→Fine-grained personal access tokens
• 適当な期限を入力。
• レポジトリを指定: komina-info-publish
• 権限の付与: Content: read and write
• 生成されたトークンをGitHubトークン欄へコピペ。
• レポジトリ: komina77/komina-info-publish
• ブランチ: main
• 接頭辞: www (/を付けてはいけない)

WordPress-パーマリンク

WordPressサイトを静的サイトに変換するにあたってパーマリンク設定に注意が必要です。GETパラメータを含むURLや、/ (スラッシュ)で終わらないURLは、htmlのみで再現できないためです。

変換元サイトでは /archives/123 のような数字ベース形式を採用していたのですが、このままでは変換できないので最後に / (スラッシュ)を加えた形式をカスタム構造に設定しました。

リダイレクト設定

変換元サイトで検索エンジンに登録されていた /archives/123 のようなURLへの参照があったときに 404 が返されてしまうと訪問者に不便が生じます。新しい /archives/123/ へ 301リダイレクトするように設定を追加します。

といっても app.yaml の handlers設定ではそこまでできないようなので、Pythonにやってもらうことにしました。

from flask import Flask, redirect

app = Flask(__name__)

@app.route("/archives/<int:num>")
def redirect_archives(num):
    return redirect(f"/archives/{num}/", code=301)

Flask==3.0.0

# handlers以下を抜粋
handlers:
  # アーカイブURL（数値のみ）をスラッシュ付きにリダイレクト（ルート除く）
  - url: /archives/([0-9]+)$
    script: auto  # アプリケーションコードに処理を委ねる

  # スラッシュで終わるURL（任意の深さ）の場合、index.htmlを返す
  - url: /(.*)/$
    static_files: www/\1/index.html
    upload: www/(.*)/index.html

  # ルートURLの場合 index.html を返す
  - url: /
    static_files: www/index.html
    upload: www/index.html

  # その他のパスは www/ 以下のファイルにマッピング
  - url: /(.*)
    static_files: www/\1
    upload: www/(.*)

一連の動作確認

これまでの設定がうまく行われていれば、Staaticプラグインで公開することで、静的サイト資材の作成、GitHubへのPush、AppEngineへのデプロイまで自動で行われるようになります。

私の環境、サイトでは資材の作成の10分強、GitHubへのPushに10分弱、AppEngineへのデプロイに3分弱、と言ったところでしょうか。

カスタムドメイン設定

NASで稼働する WordPressサイトを AppEngineで公開できることが確認できたら、ドメイン設定を行って正式に移行を完了させます。

AppEngineの設定からカスタムドメインを選択。

自分のドメインと対応付けていき、最後に表示されるキーをDNSのレコードに登録します。私の場合は muumuuドメインを利用しているので管理画面からムームーDNSの komina.info の変更へ進みます。

DNS設定が反映されるまでに少し時間がかかります。めでたく https://komina.info/ で静的サイトへアクセスできなっていれば移行は成功です。

考察など

App Engineに静的資材を公開する機能があるのは知っていはいたのですが、ほぼ100%静的サイトとして利用するのは初めての試みでした。

非常にレスポンスも速く、今のところ満足しています。

今回犠牲になったコメント機能ですが、AppEngineということなのでPythonで実装するのもアリかな、とか思ったりしています。手が空いたら考えてみたいと思います。

それに伴い、WordPressをホスト上で動かすのではなくローカルのSynology DS216にインストールして動かすことにしました。投稿するたびに htmlを出力してデプロイするようにセッティングしました。

詳しい方法や構成などは別のポストで紹介できればと思います。

とりあえず1回実行、エラーならリトライ、みたいな処理で便利に使っていたのですが、逆に言うとそれくらいしか用途が無いということなのかも。。

groovyでの書き方ですがクロージャを使うと割とスッキリ書けるようです。

This is the closest it can get to purely language syntax based do-while in Groovy: —
The last statement within curly braces (within closure) is evaluated as a loop exit condition.

loops – Elegant way for do … while in groovy – Stack Overflow

while ({
    x.doIt()
    !x.isFinished()
}()) continue

クロージャの最後の式の評価値が戻り値となるので、繰り返すべきならtrueを返すようにすると。そうすると whileの評価式が true になり contiue、つまり繰り返しになります。

クロージャの中身が多いときはインラインで書かずに別途定義する方法がよさそうですね。

Closure<Boolean> somethingToDo = { foo ->
    foo.doIt()
    !foo.isFinished()
}

while (somethingToDo(x)) continue