rakumoコンサルティング部 Tech Blog

GCPの構築ノウハウをそろりと公開 コンサル部によるテックブログ

GAE for Javaのローカル開発環境のGCSエミュレーション

GCS GAE

rakumoビジネス開発部の小山(@koyhoge)です。

社内で組織変更があってコンサルティング部がなくなり、ビジネス開発部の所属になりました。このブログのタイトルどうするんだろ?w

ということで、またもやかなり久しぶりですが良いネタがあったのでブログを更新します。今回の内容は、Google App Engine (GAE) for Javaのローカル開発環境についてです。

GAE for Java のローカル開発環境

GAE は GCP の中でも最も古いサービスです。各サポート言語によって書かれたアプリケーションをアップロードするだけで、実行環境をまるごと面倒見てくれる、内容的には PaaS に分類されるサービスです。

cloud.google.com

GAE の各言語ごとの SDK には、環境をローカルでエミュレートするサンドボックスが含まれていて、本番環境にコードをアップロードしなくても手元でテストできるようになっています。

GAE for Java 開発環境の GCS エミュレーション

GAE プロジェクトでは、静的データの読み書きのために [プロジェクト名].appspot.com という名前の Google Cloud Storage (GCS) バケットが標準で割り当てられます。

GAE から GCS を扱うための以下のドキュメントを読むと、

https://cloud.google.com/appengine/docs/standard/java/googlecloudstorageclient/setting-up-cloud-storage

開発用アプリサーバーでクライアント ライブラリを使用する

クライアント ライブラリは開発用サーバーで使用できます。ただし、Cloud Storage のローカル エミュレーションは行われないため、ファイルの読み取りと書き込みのすべてのリクエストは、インターネット経由で実際の Cloud Storage バケットに送信する必要があります。

という記述があります。しかし実際に試してみたところ、どうやら GCS バケットの読み書きについてもエミュレーションが行われていることが確認できました。

実際に試してみる

上記のリンクでも紹介されているサンプルソースを使って、GAEローカル開発環境で GCS への読み書きを実際に試してみましょう。

このリポジトリを git clone して手元にコピーします。

appengine-gcs-client/java/example に移動して、設定ファイル pom.xml の properties -> app.id を自分のGCPプロジェクトIDに変更します。

    <properties>
        <app.id>koyhoge-project</app.id>
(略)

Maven でビルドとローカル開発環境の起動を行います。

$ mvn appengine:devserver

成功すると開発サーバーが立ち上がりますので、http://localhost:8080/ にアクセスします。

Hello Google Cloud Stroage

ここで

  • Bucket: koyhoge-project.appspot.com
  • File Name: hoge.txt
  • File Contents: 適当な文字列

を入力して「Upload Content」ボタンを押すと、データが GCS に書かれたように見えまが、実際の GCS 管理コンソールを見てもそんなファイルはできていません。画面下半分のフォームで同じバケットとファイル名を指定して「Download Content」を押すと、入力された文字列が表示されるので、どこかには保存されているようです。

ではデータはどこに保存されているのでしょう?

GAE for Java のローカル開発環境では Google Cloud Datastore のエミュレーション機能があることが明示されています。

cloud.google.com

実は GCS のエミュレーションも同じディレクトリ

  • WEB-INF/appengine-generated/

にファイルとして保存されていました。以下のフォーマットのファイル名で、1オブジェクト1ファイルの形で存在しています。

encoded_gs_key:xxxxxxxxxxxxxxxxxxx

以下の URL から確認できるローカル開発環境の管理画面を見ると、

GCS で書かれたデータは Datastore のデータとして確認できるので、GAE for Java のローカル開発環境では、Datastore のエミュレーションを使用して GCS が実装されているようです。

このことは公式ドキュメントには書かれていないので、探すのに苦労しました。

Google Cloud Storage (GCS)にIAMカスタムロールを設定する

GCS Cloud IAM

rakumoコンサルティング部の小山(@koyhoge)です。

しばらくブログの投稿が滞ってしまいすいません。今回は Google Cloud Storage (GCS) で IAM によるアクセス制限をかけようとした際にハマったことを書きます。

GCS のアクセス制限には2種類ある

GCS にはバケット単位やオブジェクト単位でアクセス制限をかける機能があります。

https://cloud.google.com/storage/docs/access-control/iamcloud.google.com

Cloud IAM (Identity and Access Management) と呼ばれる、GCP 上で統一的にアクセス管理をする仕組みを利用するのが現在は通常です。

ただ、かつては GCP に IAM がまだ存在しなかったので、そのために GCS が独自にアクセス制限機能をもっていました。これはレガシー ACL (Access Control Lists) と呼ばれ、現在でも有効になっています。ACL と IAM は同時に使用することが可能ですが、ACL は過去の互換性のためにのみ有効になっているので、現在では IAM のみを使用してアクセス制限を実現することが推奨されています。

複数の権限をグルーピングする「ロール(役割)」

Cloud IAM は特定のアカウントやアカウントのグループに対して、機能ごとにアクセス許可を追加していく形で設定します。

https://cloud.google.com/iam/docs/overviewcloud.google.com

GCP の各サービスに関して、細かく権限を設定することができますが、それらを毎回ひとつずつ設定するのは大変なので、よく使われる基本的な権限をひとまとめにした「ロール(役割)」というものが定義されています。

(GCP のドキュメントでは「役割」という用語に統一されて翻訳されていますが、一般的にはロールと呼ばれることの方が多いように感じるので、この記事では「ロール」を採用します。)

https://cloud.google.com/iam/docs/understanding-rolescloud.google.com

Cloud IAM 以前に存在していた「オーナー」「編集者」「閲覧者」という区分は、現在はロールとして実現されています。他にもサービスによっては、あらかじめ設定されているロールが存在しています。

ユーザが任意の権限を組み合わせてロールを作ることもできます。これは「カスタムロール」と呼ばれます。自分の組織やプロジェクトに特有の、特定の権限のみをピックアップしてカスタムロールを作成することで、権限管理の設定をより楽にすることができます。

ロールを GCS バケットに設定する

ここからようやく本題に入ります。

最初に書いたように、GCS には Cloud IAM によるアクセス管理を設定できるのですが、そこでカスタムロールを指定しようとするとちょっとおかしなことになります。

その前に、まずはプリセットされたロールをを指定する方法を見てみましょう。ロールをセットするのに Web コンソールから行うことは現状ではできなくて、そのかわりに gsutil コマンドを使用する必要があります。

設定するには、以下のコマンドを発行します。

$ gsutil iam ch user:hoge@example.com:objectCreator gs://bucket-name

ここでセットされる「objectCreator」というロール名は GCP 側ですでに用意されているものです。

gsutil iam ch ではカスタムロールを設定できない

それでは同じ方法でカスタムロールを設定してみましょう。

GCP コンソールの IAM 設定画面 → 役割からカスタムロールを作成すると、ID が

projects/<project_name>/roles/<数字>

というフォーマットで作成されます。

この ID を指定して、gsutil iam ch を実行してみると

$ gsutil iam ch user:hoge@example.com:projects/some_project/roles/99 gs://bucket-name 
BadRequestException: 400 Invalid argument

と Invalid argument エラーになってしまいました。いろいろ試してみましたが、gsutil iam ch コマンドでカスタムロールを設定することは、どうやらできないようでした。

JSONを用いてカスタムロールを設定する

一瞬あきらめかけていたのですが、ふと思いついて gsutil iam get/set で JSON ファイル経由でロールを設定してみたらうまくいきました。

まずは gsuilt iam get で権限情報を JSON で取得します。

$ gsutil iam get gs://bucket-name > iam.json

中身は以下のような JSON になっています。

{
  "bindings": [
    {
      "members": [
        "projectEditor:some-project",
        "projectOwner:some-project"
      ],
      "role": "roles/storage.legacyBucketOwner"
    },
    {
      "members": [
        "projectViewer:some-project"
      ],
      "role": "roles/storage.legacyBucketReader"
    }
  ],
  "etag": "CAg="
}

ここにカスタムロールを用いた権限を追加します。

{
  "bindings": [
    {
      "members": [
        "projectEditor:some-project",
        "projectOwner:some-project"
      ],
      "role": "roles/storage.legacyBucketOwner"
    },
    {
      "members": [
        "projectViewer:some-project"
      ],
      "role": "roles/storage.legacyBucketReader"
    },
    {
      "members": [
        "user:hoge@example.com"
      ],
      "role": "projects/some-project/roles/99"
    }
  ],
  "etag": "CAg="
}

「"role": "projects/some-project/roles/99"」の部分が今回追加したカスタムロールですね。

変更した JSON を再びバケットにセットします。

$ gsutil iam set iam.json gs://bucket-name

今度はエラー表示もなく、無事に設定されました。 もう一度 gsutil iam get しても、正しく更新されていることが分かります。

ということで、GCS バケットへのカスタムロールのセットには JSON を使うことで解決できます。

gcs-fuseでマウントしたディレクトリをWebDAVで公開しようとしてハマった話

GCS

rakumoコンサルティング部の小山(@koyhoge)です。

弊社のお客様で、WebDAV サーバのバックエンドとしてGoogle Cloud Storage(GCS)を検討したいという方がいて、こちらでもいろいろ調査を行ったのですが、その時にハマった事を書いておきます。

GCSをファイルシステムとしてマウントするgcs-fuse

GCSのバケット通常のファイルシステムとしてマウントするにはgcs-fuse というツールを使います。ユーザ空間で動作するファイルシステム FUSE の上で GCS APIを呼び出して、あたかも GCS バケットがローカルシステムにマウントされているかのように見せかけるわけですね。

Cloud Storage FUSE  |  Cloud Storage ドキュメント  |  Google Cloud

gcs-fuse のインストールは詳しく書きませんが、上記の記事を参照して下さい。

このブログでも以前に id:ksueki が解説とベンチマークの記事を書いています。

gcsfuse をインストールしたら、/etc/fstab に以下のようなエントリを追加して

gcs-backet /mnt/gcsfuse gcsfuse rw,allow_other,file_mode=777,dir_mode=777,key_file=/root/credentials/gcs-access-key.json

以下のコマンドを実行すれば、無事に /mnt/gcsfuse に目的のバケットがマウントされるわけです。

$ sudo mount /mnt/gcsfuse

SELinux の制限でハマる

さて上でマウントされた /mnt/gcsfuse を WebDAV で公開しようと Apache httpd の設定ファイルとして /etc/httpd/conf.d/gcsfuse.conf を追加しました。

Alias /dav/ "/mnt/gcsfuse/"
<IfModule mod_dav.c> 
  DAVMinTimeout 600
  <Location /dav>
    DAV On
    EnableSendfile off
    AuthType Basic
    AuthName "Login WebDAV"
    AuthUserFile "/etc/httpd/conf/.htpasswd"
    Require valid-user
  </Location>
</IfModule>

ところが httpd を再起動して WebDAV クライアントでつないでみてもアクセスできません。httpd は応答を返しているのでDAVの設定が間違っているように思われました。

結論から言えば、これは SELinux の制限によるものでした。fuse でマウントしたディレクトリをhttpd で公開するなんてことは通常あまり行われないので、標準状態では対応していないわけですね。

SELinux が有効なままなんとかする

そこで SELinux を Permissive モードにしたり Disable したりするのは簡単ですが、正しいやり方を探ってみたくなりました。

まずは httpd からアクセス制限かけられているファイルがどういう状態になっているか確認します。

$ cd /mnt/gcsfuse
$ ls -Z
drwxrwxrwx. root root system_u:object_r:fusefs_t:s0    coldline-folder
drwxrwxrwx. root root system_u:object_r:fusefs_t:s0    nearline-folder
drwxrwxrwx. root root system_u:object_r:fusefs_t:s0    tmp1
drwxrwxrwx. root root system_u:object_r:fusefs_t:s0    tmp2

fuse でマウントしたファイルは fusefs_t というタイプを持っているようです。

SELinux のポリシーを調べるには sepolicy コマンドを使います。環境にインストールされていなかったので yum でインストールします。

$ sudo yum install selinux-policy-devel selinux-policy-doc

httpd に関する設定がスイッチでまとめられているようなので、それをリストアップします。

$ sepolicy booleans -a | grep httpd
<略>
httpd_use_fusefs=_("Allow httpd to access FUSE file systems")
<略>

httpd_use_fusefs というそのものズバリそうな設定が見つかりました。

現在値を確認すると案の定 off になっています。

$ getsebool httpd_use_fusefs
httpd_use_fusefs --> off

これを on にしてやればよさそうです。それには setsebool コマンドを使いますが -P をつけて再起動しても有効にしましょう。

$ sudo setsebool -P httpd_use_fusefs on

値を再度確認するときちんと on になっていました。

$ getsebool httpd_use_fusefs
httpd_use_fusefs --> on

これで SELinux が有効なまま、WebDAV で無事にアクセスできるようになりました。

GCSクライアントとしてMountain Duckを試す

GCS

Mountain Duck

rakumoコンサルティング部の小山(@koyhoge)です。

Google Cloud Storage(GCS)は、GCPにおけるオブジェクトストレージサービスです。AWS でいうところの S3、Azure でいうところの Blob Storage に相当します。

基本はAPIを使ってデータを読み書きしますが、FTP や sFTP のようにリモートディスクとしてアクセスするクライアントアプリが存在します。それを使うことでクラウドの詳しいことは知らなくても、単なるネットワーク外部ディスクのように扱えるわけです。

大抵は Amazon S3対応のものが多く、GCS対応を謳うものはさほど多くありません。今回 Mountain Duckというクライアントアプリを試したので、その使用感を書いてみます。

Mountain Duckとは

Mountain Duckは、スイスの iterate GmbH が開発している有料のネットワークディスククライアントアプリです。1ユーザー $39.00 からで、ユーザー数が増えるとボリュームディスカウントがあります。

mountainduck.io

Mountain Duckが特徴的なのは、アクセスするための独自ウィンドウを表示してそこで作業を行う多くのクライアントアプリと異なり、Windows の場合はエクスプローラーの、MacOSの場合は Finder の機能拡張として動作し、作業はエクスプローラー/Finderそのものを用いる点です。アクセスできる外部のファイルサーバの種類がぐっと増えた感じと書けば分かりやすいでしょうか。

対応しているプロトコル・サービスは現時点で15です。WebDAV, FTP, SFTP などメジャーなファイル転送プロトコルはもちろん、AWS S3、Azure Storage、Rackspace Cloud Files など多くのクラウドサービスにも対応しています。

ちなみに、iterate GmbH では通常のウィンドウ型のクライアントアプリも Cyberduck としてOSSで開発、公開しています。

https://cyberduck.io/cyberduck.io

無料試用版を試す

Mountain Duck は無料試用版があるので、早速試していきます。上記 Moutain DuckのWebページのダウンロードリンクからソフトをダウンロードします。今回は MacOS 版を試します。

MacOS版のダウンロード

ダウンロードが完了して dmg を展開すると、Mountain Duck.app が現れるので、アプリケーションフォルダーにコピーします。

Mountain Duck.app

Mountain Duck.app をダブルクリックで起動すると、まずはログイン時に自動起動するかどうかを尋ねるダイアログが表示されます。

自動起動確認ダイアログ

「続ける」を選択すると、次に接続設定のダイアログが表示されます。

接続設定ダイアログ

最上部のセレクトリストから「Google Cloud Storage」を選択します。

GCSを選択

Username の欄にアクセスしたいGCPプロジェクトの「プロジェクトID」を入力して、「Connect」をクリックします。

プロジェクトIDを入力

するとブラウザでGoogleアカウントの選択画面が表示され、目的のアカウントをクリックして、アプリの権限承認画面になります。

アカウントの選択

「許可」ボタンをクリックすると、認証コードが表示されます。

認証コードの表示

この認証コードをコピーして、Mountain Duckの「OAuth2 Authentication」ダイアログの「Authentication Code」欄にペーストします。

認証ダイアログ

「Login」ボタンをクリックすると、無事にプロジェクトが保持する GCS バケットがマウントされます。

マウントされたGCSバケット

ファイル転送をテスト

さてマウントもできたとことだし、Mountain Duck で実際にファイル転送をやってみます。とは言っても普通に Finder でコピーするだけですけどね。

まずは10.5MBの画像一枚をマウントされているフォルダーにコピーすると、数秒で完了しました。よしよし。

GCSにコピーされたファイル

GCP の管理コンソールで見ても無事に格納されています。

GCSコンソールでも確認

次に 25MBのファイルを10個まとめてコピーしてみたところ、30秒程度で終了したので、パフォーマンスも悪くないようです。

最後に 3300 個の小さいファイルがあるソースコードリポジトリのフォルダーをコピーするという意地悪をしてみたところ、途中でステータスバーが全く進まなくなってしまいました。やはり細かいファイルを大量にコピーするのはちょっとやり過ぎだったようです。

まとめ

Mountain Duck は、OS 標準のツールで様々なネットワークストレージをマウントできるソフトウェアです。アプリ独自の使い方を学習しなくて良い点が素晴らしいです。

GCP にカスタムドメインを登録する

GAE DNS

rakumoコンサルティング部の小山(@koyhoge)です。

以前に掲載した「構築済のWordPressをGoogle App Engineに移行する(4)」で、GAE 上で動作する WordPress にカスタムドメインを設定する方法を解説しましたが、ドメインを登録する手順は記事中では省略していました。

今回は、その「カスタムドメインの登録」にフォーカスして解説したいと思います。

なぜドメイン確認が必要か

GCP や G Suite でカスタムドメインを使用するには、そのドメインが本当にそのアカウントが管理しているものかどうかを確認する必要があります。他人が自分のドメインを勝手に登録できてしまっては大変ですから、何らかの確認の仕組みは必須といえます。

GCP にも Cloud DNS というDNSマネージドサービスがありますので、これに使いたいドメインの管理を移管してしまえば、Google アカウントとドメインの紐付けは可能です。しかしドメイン管理は過去のしがらみから移管できないケースも多く想定され、ドメイン管理方法は従来のままで、その所有者を確認できる方法が求められました。

GCP、G Suite では、そのドメインの TXT レコードに確認コードを設定することで、所有者確認をする手法を取っています。ではそのやり方を順を追って見ていきましょう。

確認コードの取得

今回は GAE でカスタムドメイン使用したいので、GAE の管理メニューから「設定」を選びます。

App Engineメニュー

上部のナビゲーションから「カスタムドメイン」を選択し、その下の「カスタムドメインを追加」ボタンを押す。

GAEカスタムドメインの追加

「使用するドメインを選択する」に現在登録されているドメインのプルダウンメニューが表示されます。この例では前回登録した hoge.org が表示されています。

登録済みドメイン

今回は新しく koyhoge.org を登録したいと思いますので、プルダウンメニューを開いて「新しいドメインを確認…」を選択します。

新しいドメインを確認

するとすぐ下にテキスト入力が現れますので、追加したいドメイン koyhoge.org を入力して「確認」ボタンを押します。

ドメイン名の入力

するとブラウザの別ウィンドウ(タブ)で「ウェブマスターセントラル」が開きます。「ドメインレジストラまたはプロバイダを選択」をクリックすると多数のドメインサービス名が表示されます。

ウェブマスターセントラル

表示されるサービスは海外のドメインサービスが多いので、ご自身の使用しているものはないかもしれません。私の持っている　　koyhoge.org は dotster.com で取得し、AWS Route 53 で管理をしているので「その他」を選びます。TXT レコードの登録の仕方は各ドメイン業者によって異なりますが、とりあえずは確認コードを取得できれば良いので、迷ったら「その他」を選択しておけば良いでしょう。

その他を選択

するとそのドメインの TXT レコードに登録する確認コードが表示されます。

ドメイン確認コード

ドメインのTXTレコードに追加

無事にドメイン確認コードが取得できましたので、今度はそれを DNS に登録していきます。

この作業は使用しているドメイン管理業者によって微妙に異なります。今回は koyhoge.org の管理をしている AWS Route 53 の例を出しますが、TXT レコードに先ほど取得した「ドメイン確認コード」を登録するという基本は変わりません。

まずは AWS のウェブコンソールにログインして、Route 53 の管理画面を開きます。koyhoge.org を選び、上部のメニューから「Create Record Set」ボタンを押します。

AWS Route 53

右部分の設定パネルで以下を行います。

TXTレコードの登録

Value 部分は

"google-site-verification=hZjnujnyfBJ2VOjwviu6Zamo8FcQD25UcvctMpYi1tg"

のようにダブルクォートで括ります。すでに SPF 用のレコード等が登録されている場合は、

"v=spf1 ip4:54.238.55.33 include:_spf.google.com ~all"
"google-site-verification=hZjnujnyfBJ2VOjwviu6Zamo8FcQD25UcvctMpYi1tg"

とダブルクォートで括ったものを、複数行で記述します。

最後に下部の「Save Record Set」ボタンを押して保存します。

確認完了

DNS の変更が反映されたら、先ほどのウェブマスターセントラル の画面に戻って「確認」ボタンを押します。Route 53 はほぼタイムラグなしに登録データが更新されますが、サービスによっては時間がかかるので注意して下さい。

DNSレコードの確認

無事に TXT レコードが登録されていれば、以下の画面が表示されてドメイン所有者の確認ができたことが分かります。

ドメイン所有者の確認

再び GCP の GAE 管理画面に戻って「続行」ボタンを押すと、ドメイン候補の中に登録した「koyhoge.org」が表示されています。

ドメイン追加完了

以上で、カスタムドメインを新たに登録する手順はおしまいです。GAE や Cloud CDN などカスタムドメインを使用できる場面では、登録されたドメインが候補として表示されるようになります。

参考

構築済のWordPressをGoogle App Engineに移行する(費用編)

CloudSQL GAE GCS Cloud CDN

rakumoコンサルティング部の小山(@koyhoge)です。

既存のWordPressをGCPに移行する解説記事を投稿したところ、費用面での質問をいくつかはてブでいただいたので、今回の構成での費用面を解説した番外編をお送りします。

今回の例では月額およそ4,000円

クラウドにアプリケーションをデプロイするということは、使った分だけ支払う従量課金に移行するということですから、例えばブログにアクスセスが死ぬほど殺到すると、もちろんその分金額は上がるわけです。とはいえ、そんなにアクセスのない状態での大体の金額を知りたいという疑問が浮かぶのも理解できます。ということでとりあえず始めてみるにはこのくらいという概算を紹介してみましょう。

今回の構成で、アクセス数によらずどうしても費用がかかるのは Cloud SQL です。東京リージョンで g1-small インスタンスを常時立ち上げた際の費用は、継続利用割引が適用されて $0.0455/時間 x 24 時間 x 30日として $32.76、現在の円ドル換算レートだとおよそ 3,700 円程度になります。

その他のサービスの分、Google Cloud Storage (GCS) や Google App Engine (GAE) の部分は使い方によって値段が変わってくるので一概には言えませんが、通常のブログの使用やアクセス数ならおそらく全部で数百円程度でしょう。ということで今回の GAE + GCS + Cloud SQLの例だと、月額 4,000 円程度でそこそこ負荷に耐えられる WordPress 環境を構築できることが分かりました。

もちろん更なるアクセスに耐えられるようにしたければ、いくつかやりかたがあります。

  • DBアクセスがボトルネックならば Cloud SQLのインスタンスタイプを上位モデルにする
  • ものすごくアクセスが来て GAE の料金が跳ね上がるようなら GCS や GAE で Cloud CDN を利用する

課金額にキャップを設定する

アクセスが来すぎて課金がものすごいことになるのを心配する声も聞かれます。GAE では一日の使用量の上限をドル建てで制限できる機能がありますので、サービスが止まってよいのであればクラウド破産は避けることができます。

月額 4,000 円というのは他社の VPS サービスに比べるとちょっと高めですが、負荷対策に悩む必要がない安心料と考えれば、さほど高くないのではないかと思います。

構築済のWordPressをGoogle App Engineに移行する(4)

CloudSQL GAE GCS

rakumoコンサルティング部の小山(@koyhoge)です。

既存のWordPressをGCPに移行する解説記事の4回目(最終回)です。

前回で Google App Engine (GAE) 上に WordPress をデプロイできましたので、今回はその設定と既存データのインポートを行っていきます。

WordPress のインストール

前回は WordPress のインストール画面で終わっていたと思いますので、インストール作業を続けましょう。ここでいう「インストール」の意味は、ファイルの配置ではなくデータベースに対する各種テーブルの初期化になります。

サイトのタイトルやユーザ名などを入力するのは、通常の WordPress のインストールと同様です。

WordPressインストール画面

ページ下部の「WordPress をインストール」ボタンを押すと、インストール作業が完了しログイン画面になります。先ほど入力したユーザ名/パスワードでログインします。

WordPressログイン

プラグインの有効化

DB がまだ初期状態なので、WPonGAE をはじめとする各種プラグインはまだ有効になっていません。管理画面のプラグインページからそれらを有効化します。

まず WordPress の管理画面から「プラグイン」を選びます。

プラグインメニュー

以前の環境でインストールされていたプラグインが無効の状態でリストアップされていますので、すべて有効にします。今回「Batcache Manager」と「Google App Engine for WordPress」という2つのプラグインが新たに追加されているので、これも忘れずに有効化しておきます。

プラグインページ

データのインポート

いよいよ第1回でエクスポートしたバックアップデータを、新しく設置した WordPress にインポートします。

Google Cloud Storage にデータを置く

GAEプラグインでは、インポートデータを Google Cloud Storage (GCS) から読み込むようになっているので、まずは GCS にファイルをアップロードします。

GCP コンソールの左側メニューから「Storage」を選びます。

Storageメニュー

プロジェクトが管理している GCS バケットがリストで表示されます。その中に xxx.appspot.com という GAE プラグインが自動で作成したバケットがあるはずなので、そこをクリックします。

GCSバケットリスト

バケットブラウザが表示されるので、上部の「ファイルをアップロード」ボタンを押します。

バケットブラウザ

ファイル選択ダイアログが表示されるので、第1回でエクスポートしたXMLファイルを選択し、GCSにアップロードします。

アップロードの完了

インポートの実行

準備は整ったのでインポート作業を行いましょう。WordPress 管理画面の「ツール」から「インポート」を選びます。

インポートメニュー

Import WordPress という画面が表示されます。下部にXMLファイルの場所を入力するフォームがありますので、そこにさきほど GCS にアップロードしたファイル名を入力します。

インポート画面

GCS のデフォルトのバケット名まではすでに入っているので、それに追加する形でファイル名を入れます。

例)

gs://wp-on-gae-187408.appspot.com/

↓

gs://wp-on-gae-187408.appspot.com/wordpresssample.wordpress.2017-11-20.xml

ファイル名を入力したら「Import from specified file」ボタンを押します。

すると既存の WordPress アカウントの移行をどうするかという確認画面が表示されます。デフォルトではアカウント情報もそのままインポートしてくれますので、そのままでかまわないでしょう。

アカウントの移行設定

下部に「Import Attachments」というセクションがあります。これは既存の WordPress にアップロードしているメディアファイルもインポートするかという設定になります。チェックを入れると、既存の WordPress からメディアファイルを GCS 上にコピーして、記事中のリンクをそちらに入れ替えてくれます。

Import Attachments

最後に「Submit」ボタンを押します。作業が進むと無事にインポートが終了し、記事が入った WordPress を確認できると思います。

DNS の切り替え

既存コンテンツの移行漏れがないか十分に確認を行った後、公開サイトを既存のものから GAE に切り替えます。 GAE でカスタムドメインを使用するには、まずそのドメインを GCP に登録の後、GAE の管理画面で設定を行います。

ここではデプロイしたGAEインスタンスに「wpsample.hoge.org」を割り当てる作業を行ってみます。

まず GAE のメニューから「設定」→「カスタムドメイン」を選択し、

GAEのカスタムドメイン設定

「使用するドメイン」に、登録されているドメインが表示されていることを確認して下さい。まだドメインが登録されていない場合は、表示されるガイドに従ってTXTレコードを追加して、ドメインを登録する手順になりますが、ここでは省略します。

使用するドメインの選択

「続行」ボタンを押すと、「hoge.org」と「www.hoge.org」の2つの候補が表れます。今回はこれらには割り当てないので、右端の「☓」を押して削除します。

ホスト名の選択

割り当てたいホスト名「wpsample.hoge.org」を入力して、「マッピングを保存」ボタンを押します。

マッピングの追加

確認画面に変わるので「続行」ボタンを押します。

マッピングの確認

次のフェーズに移り、DNSに登録する内容が表示されます。いくつも表示されていますが、基本的には一番下の CNAME だけ設定すれば良いです。(DNS情報を登録するWeb管理画面によっては、A/AAAAとCNAMEは共存できないものもあります)

DNSの設定

そこで以下の内容に相当する DNS レコードを登録します。これはDNSの管理をどのように行っているかによって違うので省略します。

wpsample.hoge.org IN CNAME ghs.googlehosted.com.

しばらくすると CNAME 設定を GCP 側が認識して、GAEのカスタムドメインとして表示されます。

カスタムドメイン登録完了

GAE の注意点

WordPress 本体やプラグインの更新について

WordPress 本体、テーマやプラグインはけっこう頻繁に更新が行われます。WordPress の管理画面を見ると更新通知が目立つところに表示されので、どうしても更新しなきゃという圧が強まりますね。

ところが GAE ではデプロイした環境に対してファイルの追加や変更はできないので、WordPress 管理画面からの本体やプラグインのバージョンアップは行ってはいけません。というかできません。

ではどうするかというと、第3回で用意した GAE のデプロイ元のファイルを変更して、再度デプロイという流れになります。デプロイ元の WordPress を動作可能にしておいて、そちらの管理画面から本体、テーマ、プラグインの更新を行い、更新が完了したファイルツリーに対して再び

$ glcoud app deploy

を行えば良いわけです。

まとめ

4回にわたって、既存の WordPress を GAE に移行する作業を詳しく解説しました。GAE に環境を移行することには以下のメリットがあります。

VPSや仮想マシン1台で運用している場合には、どちらが運用効率が良いかは判断が難しいところですが、アクセスの規模が大きかったり複数台で運用している場合ほど、GAE のメリットが大きくなってくると思います。