月別アーカイブ: 2018年7月

www.aoboshi.orgも常時SSL化

前回、Let’s encryptで本ブログを常時SSL化したことをお伝えしましたが、
本ブログは、https://aoboshi.orgだけではなく、サブドメイン付きのhttps://aoboshi.orgでも接続できるのですが、

https://aoboshi.orgで接続しようとすると、

「接続としているドメインと証明書のドメインが合ってない」と警告メッセージが表示されるようになってしまいました。

前回証明書を取得した際に、aoboshi.orgしか指定しておらず、www.aoboshi.orgを指定していなかったのが原因のようです。

前回、httpで接続してきたらhttpsにリダイレクトするように設定した設定に、
www.aoboshi.orgで接続してきたらaoboshi.orgにリダイレクトする条件を追加しましたが、
/etc/apache2/sites-available/wordpress.conf

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R,L]

↓太字部分を追加

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.aoboshi.org$ [OR]
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R,L]

状態は変わりませんでした。

そこで、www.aoboshi.org用に証明書を取り直し、バーチャルホストの設定を追加することにしました。

1.証明書取得
www.aoboshi.org用の証明書を取得します。

まずapacheを停止。

$ systemctl stop apache2

下記コマンドで証明書を取得します。

$ sudo certbot certonly –webroot -w /var/www/html -d www.aoboshi.org
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for www.aoboshi.org
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification…
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0001_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0001_csr-certbot.pem

IMPORTANT NOTES:
– Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/www.aoboshi.org/fullchain.pem. Your cert will
expire on 2018-10-27. To obtain a new or tweaked version of this
certificate in the future, simply run certbot again. To
non-interactively renew *all* of your certificates, run “certbot
renew”
– If you like Certbot, please consider supporting our work by:

Donating to ISRG / Let’s Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le

2.バーチャルホストの設定
前回https用にバーチャルホストを設定したdefault-ssl.confに、www.aoboshi.org用のバーチャルホストを設定しようと思ったのですが、1ファイルに混在していると分かりにくいので、コピーして該当箇所のみ変更しました。

www.aoboshi.org用にwwwdefault-ssl.confを作成

$ pwd
/etc/apache2/sites-available
$ cp -ip default-ssl.conf wwwdefault-ssl.conf
vi wwwdefault-ssl.conf

ServerNameとSSL証明書の置き場所のみ変更する。

$ diff default-ssl.conf wwwdefault-ssl.conf
3c3
< ServerName aoboshi.org --- > ServerName www.aoboshi.org
33,34c33,34
< SSLCertificateFile /etc/letsencrypt/live/aoboshi.org/fullchain.pem < SSLCertificateKeyFile /etc/letsencrypt/live/aoboshi.org/privkey.pem --- > SSLCertificateFile /etc/letsencrypt/live/www.aoboshi.org/fullchain.pem
> SSLCertificateKeyFile /etc/letsencrypt/live/www.aoboshi.org/privkey.pem
naoto70@wordpress-1-vm:/etc/apache2/sites-available$

wwwdefault-ssl.confを下記コマンドで有効化します。

$ sudo a2ensite wwwdefault-ssl.conf
Enabling site wwwdefault-ssl.
To activate the new configuration, you need to run:
service apache2 reload

最後にapacheを起動すれば完了です。

$ systemctl start apache2

これで、www.aoboshi.orgで接続が出来るようになりました。

【2018/9/23追記】

aoboshi.orgまたはwww.aoboshi.org以外のサブドメイン以外の、SSL証明書の存在しない存在しないサブドメインでhttp://〜をhttps://〜にリダイレクトしないよう、wordpress.confのリダイレクトの設定を下記に書き換えました。
(太字が変更場所)

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.aoboshi.org$ [OR]
RewriteCond %{HTTP_HOST} ^aoboshi.org$
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R,L]

[どうにか完了]Let’s Encrypt導入に悪戦苦闘

最近ブログを更新しようとWordpressにログインしようとするとSafariのURL表示のところに「Webサイトが安全ではありません」と表示されるようになってしまいました。

http接続のためだそうですが、いくら自分のサイトだからといって正直気になります。

また、最近はChromeがhttp接続の場合はログイン時に限らず警告を表示するようになるなど、

「Google Chrome 68」公開、HTTPサイトには容赦なく警告を表示する仕様に – INTERNET Watch

httpsが標準になりつつある時代になってきたこともあり、

当ブログでもLet’s Encryptを使用して常時https化してみました。

Wikipediaに
「LinuxのWebサーバーでは、HTTPSの暗号化の設定および証明書の取得・更新がわずか2つのコマンドによって可能である。」
と書いてあるなど、結構簡単にできると書いている方が多かったですが、自分の場合は結構手間取ったので、作業履歴を書いていきたいと思います。

1.certbotのインストール

Let’s Encryptでhttps化に必要な証明書を取得し設定するのにcertbotというソフトを入れる必要があるので、インストールをします。
基本的にdebianはapt-getでインストールできるらしいのですが、
Debian 8 (jessie)では、リポジトリの追加が必要との情報があり、確認してみたところ、

$ cat /etc/os-release
PRETTY_NAME=”Debian GNU/Linux 8 (jessie)”
NAME=”Debian GNU/Linux”
VERSION_ID=”8″
VERSION=”8 (jessie)”
ID=debian
HOME_URL=”http://www.debian.org/”
SUPPORT_URL=”http://www.debian.org/support”
BUG_REPORT_URL=”https://bugs.debian.org/”
$

私が使用していたのもDebian 8 (jessie)でしたので、まずリポジトリの追加を行いました。

$ cd /etc/apt/sources.list.d/
$ sudo vi backports.list

下記の1行を追加

deb http://ftp.debian.org/debian jessie-backports main

certbotのインストール

$ sudo apt-get update
$ sudo apt-get install python-certbot-apache -t jessie-backports

2-1.certbotの起動・設定(失敗)

certbotを入れた終わったらcertbotを起動し、設定します。

$ sudo certbot –apache
Saving debug log to /var/log/letsencrypt/letsencrypt.log
No names were found in your configuration files. Please enter in your domain
name(s) (comma and/or space separated) (Enter ‘c’ to cancel):aoboshi.org ←ドメイン名を入れる
Enter email address (used for urgent renewal and security notices) (Enter ‘c’ to
cancel):xxxxxx@gmail.com←自分のメールアドレスを入れる
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org

——————————————————————————-
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v01.api.letsencrypt.org/directory
——————————————————————————-
(A)gree/(C)ancel:

(A)gree/(C)ancel: A←同意する
Obtaining a new certificate
Performing the following challenges:
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.

IMPORTANT NOTES:
– If you lose your account credentials, you can recover through
e-mails sent to xxxxxxx@gmail.com.
– Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Certbot so
making regular backups of this folder is ideal.
$

なぜかエラーを吐いて落ちました。
やり直しても同じでした。

2-1.certbotの起動・設定・復旧

調べたところ別のコマンドで代用できるそうでしたのでやってみました。
apacheを止める必要があるので、止めます。

$ sudo systemctl stop apache2

standaloneモードでcertbotを起動。-d オプションの後に自分のドメイン名を指定します。

$ sudo certbot –authenticator standalone –installer apache -d aoboshi.org

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Cert not yet due for renewal

You have an existing certificate that has exactly the same domains or certificate name you requested and isn’t clos
e to expiry.
(ref: /etc/letsencrypt/renewal/aoboshi.org.conf)

What would you like to do?
——————————————————————————-
1: Attempt to reinstall this existing certificate
2: Renew & replace the cert (limit ~5 per 7 days)
——————————————————————————-
Select the appropriate number [1-2] then [enter] (press ‘c’ to cancel): 1 ←中途半端に入ってしまったみたいなので入れ直す
Keeping the existing certificate

We were unable to find a vhost with a ServerName or Address of aoboshi.org.
Which virtual host would you like to choose?
(note: conf files with multiple vhosts are not yet supported)
——————————————————————————-
1: 000-default.conf | | |

2: default-ssl.conf | | HTTPS |
3: wordpress.conf | | | Enabled
——————————————————————————-
Select the appropriate number [1-3] then [enter] (press ‘c’ to cancel): 2 ←https用のバーチャルホストの設定をどのファイルに入れるのかを指定する。とりあえずそれっぽいのを指定
Enabled Apache socache_shmcb module
Enabled Apache ssl module
Deploying Certificate to VirtualHost /etc/apache2/sites-available/default-ssl.conf
Enabling available site: /etc/apache2/sites-available/default-ssl.conf

Please choose whether HTTPS access is required or optional.
——————————————————————————-
1: Easy – Allow both HTTP and HTTPS access to these sites
2: Secure – Make all requests redirect to secure HTTPS access
——————————————————————————-
Select the appropriate number [1-2] then [enter] (press ‘c’ to cancel): 2 ←httpでアクセスしてきたらhttpsにリダイレクトさせる
Created redirect file: le-redirect-aoboshi.org.conf
Rollback checkpoint is empty (no changes made?)

——————————————————————————-
Congratulations! You have successfully enabled https://aoboshi.org

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=aoboshi.org
——————————————————————————-
$

apacheを立ち上げて、さあ確認。

$ sudo systemctl start apache2

…ブログに繋がらない状態になりました。httpsはおろかhttpsでも…。

試行錯誤した結果、/etc/hostsにホスト名とIPアドレスを入れたら復旧しました。

$ cd /etc
$ vi hosts

35.185.230.144 aoboshi.org

一応URLをhttpsにしても繋がるようになりました。

3.仕上げ
【リンクの修正】
https://aoboshi.org

で繋がるようになったのはいいのですが、SafariのURLバーに南京錠アイコンがつきません。
Firefoxで見てみたところ、

どうやら、画像指定がhttpで書いているため、httpsとhttpが混在していたようです。
以前も使用したSearch Regexで一括置換します。

置換後、Safari、Firefoxともにhttps接続である表示がされるようになりました。
  

WordPressのアドレス設定もhttpsに変えます。

【httpで接続してきたらhttpsにリダイレクトするようにする】
上記にも書いていますがcertbotで設定した際に

Please choose whether HTTPS access is required or optional.
——————————————————————————-
1: Easy – Allow both HTTP and HTTPS access to these sites
2: Secure – Make all requests redirect to secure HTTPS access
——————————————————————————-
Select the appropriate number [1-2] then [enter] (press ‘c’ to cancel):2

httpで接続してきたらhttpsにリダイレクトするようにする設定をしたはずなのに、httpでアクセスしてもhttpsになりません。
いろいろ調べた結果、バーチャルホストの設定が正常に入っていないのが原因であるようだとわかりました。
certbotも「We were unable to find a vhost with a ServerName or Address of aoboshi.org.」と言ってましたし。

/etc/apache2/sites-available/wordpress.conf
には、

と、http用の設定が入っているようなので、

に下記4行を追加してapacheを再起動したところ、

ServerName aoboshi.org
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R,L]

httpで接続してきたらhttpsにリダイレクトするようにするようになりました。

ついでに、

とhttps用の設定が入っている
/etc/apache2/sites-available/default-ssl.conf
にも
ServerName aoboshi.org
の1行が入ってなかったので入れました。

長々と書きましたが、なんとかhttps化することが出来ました。

4.その他、更新について
Let’s encryptで取得した証明書の期限は90日なので定期的に更新が必要です。
certbot renewコマンドで更新できるようなので、やってみようとしましたが、

$ sudo certbot renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log

——————————————————————————-
Processing /etc/letsencrypt/renewal/aoboshi.org.conf
——————————————————————————-
Cert not yet due for renewal

The following certs are not due for renewal yet:
/etc/letsencrypt/live/aoboshi.org/fullchain.pem (skipped)
No renewals were attempted.

まだ期限じゃないから必要ないですよとスキップされます(まだ導入して数日ですし)。

systemdの設定を見ると、定期的に更新する設定が入っているようなので、静観です。

$ cd /lib/systemd/system/
$ cat certbot.timer
[Unit]
Description=Run certbot twice daily
[Timer]
OnCalendar=*-*-* 00,12:00:00
Persistent=true
[Install]
WantedBy=timers.target

$ cat /lib/systemd/system/certbot.service
[Unit]
Description=Certbot
Documentation=file:///usr/share/doc/python-certbot-doc/html/index.html
Documentation=https://letsencrypt.readthedocs.io/en/latest/
[Service]
Type=oneshot
ExecStartPre=/usr/bin/perl -e ‘sleep int(rand(3600))’
ExecStart=/usr/bin/certbot -q renew
PrivateTmp=true

fuzzbuzz.sh微調整(最大値を引数化、引数チェック)

以前作成した、fizzbuzz.shを微調整しました。
前回はfizzbuzzを終了させる最大値をベタ書きしていましたが、引数化しました。
また、引数が入っていなかったり、数字以外のものが入っていた場合を想定し、引数のチェックを行う処理を最初に入れています。
(引数が複数入ってる状態については、最初の引数しか参照せず動作に問題ないため、今回は考慮していません。)

#!/bin/sh
expr 1 + $1 >/dev/null 2>&1
if [ $? -ne 0 ]; then
echo “Please enter a correct parameter by number!”
exit 3
else
max=$1
fi

num=1
while :
do
fizz=`expr ${num} % 3`
buzz=`expr ${num} % 5`
if [ ${fizz} = 0 -a ${buzz} = 0 ]; then
echo “FizzBuzz”
elif [ ${fizz} = 0 ]; then
echo “Fizz”
elif [ ${buzz} = 0 ]; then
echo “Buzz”
else
echo ${num}
fi
num=`expr ${num} + 1`
if [ ${num} -gt ${max} ]; then
exit
fi
done
変更場所を太字で記載しています。(インデントが表示されないのはご愛嬌…)

【変更場所の説明】
[変更箇所1]
expr 1 + $1 >/dev/null 2>&1
if [ $? -ne 0 ]; then
echo “Please enter a parameter !”
exit 3
else
max=$1
fi

exprで1+引数をする処理を行います。
exprは数式を計算するコマンドですが、
正しい数式を計算した場合は、返値は0、数式が抜けていたり、数字以外のものを計算しようとした場合は返値は2を返します。

pi@raspberrypi:~ $ expr 1 + 1
2
pi@raspberrypi:~ $ echo $?
0
pi@raspberrypi:~ $ expr 1 + a
expr: non-integer argument
pi@raspberrypi:~ $ echo $?
2
pi@raspberrypi:~ $ expr 1 +
expr: syntax error
pi@raspberrypi:~ $ echo $?
2
pi@raspberrypi:~ $

これを利用し、exprで1+引数を計算し、(出力は要らないので/dev/nullに捨てて)
返値は0なら、正しい引数、2なら異常な引数が指定されていると判断します。
引数が異常な場合は「Please enter a parameter !」と出力して返値が3で終了します。

そうでない場合は正常な引数であるとみなし、引数を変数「max」に代入します。

[変更箇所2]
if [ ${num} -gt ${max} ]; then
ベタ書きしていた最大値を変数「max」に置き換えています。

以上の修正で、安全に最大値を引数化することができました。
もう少し改善すべきことがありましたら、また改良してみようと思います。

[GCP]VMインスタンスの落とし上げ

GCPコンソール画面の「Compute Engine」「VMインスタンス」を見ると「インスタンスが過剰に使用されている」と警告が出るようになってしまいました。

どうやらメモリ不足らしく、

SSHで入ってTopを叩いてみたところ、スワップはしていないようでしたが、freeが少なかったので、とりあえず再起動することにしました。
せっかくなのでVMインスタンスの落とし上げでやってみることにしました。

【停止】
GCPコンソール画面の「Compute Engine」「VMインスタンス」の点々アイコンから「停止」を選択、

警告が出るが「停止」を選択

左側のアイコンが灰色になるまで待つ

【起動】
GCPコンソール画面の「Compute Engine」→「VMインスタンス」の点々アイコンから「開始」を選択、

警告が出るが「起動」を選択

左側のアイコンが緑色になるまで待つ

以上で、再起動は完了です(先にOS側でshutdown -h nowしたほうがよかったかもしれませんが)

再起動後はfree容量が再起動前より増えてます。

「インスタンスが過剰に使われています」表示はそのままですが、様子見です。

【追記2018/7/23】

本日、再度コンソール画面の「Compute Engine」→「VMインスタンス」を確認してみたところ、「インスタンスが過剰に使われています」
表記が消えていました。

どうやら、昨日サーバ移転で、サーバへアップロード、WordPressへのインポートなどを大量に行ったりしたのがよくなかったみたいです。
今は落ち着いているみたいなので、良かったです。

[GCP]課金対象国からのアクセスを抑止する


GCPフリートライアルでもらえる300ドル分のクレジットが目減りしているような気がしたので、
確認してみたところ、


「Network Internet Egress from Americas to China」で課金された事がわかりました。

なんだこれと思って調べたところ、

1 GB の北米から全リージョン宛て下りネットワーク(1 か月あたり、中国およびオーストラリアを除く)

Always Free の使用制限  |  Google Cloud Platform の無料枠  |  Google Cloud

中国やオーストラリアからのアクセスは課金対象で、今回は中国からアクセスがあったため課金された模様です。

別に中国の方には恨みもないし、額も極わずかですが、それでも目減りするのは気分のいいものではないし、今後アクセス量が増加したら怖いので、
取り急ぎ、実際にアクセスのあった中国からのアクセスを抑止することにしました。对不起…

検索したら、既にやっている方がいたので、同じことをします。
Google Cloud Platformで中国からの通信をブロック

1.まず中国のIPアドレス一覧をここからダウンロードします。
「アクセス制御用ひな形」から「nginx」を選択、

「deny 1.0.1.0/24;」のことろだけ取り出して
「deny 」を「”」、「;」を「”,」に置換するなどして、
「”1.0.1.0/24″,」の形式にします。

2.コンソール画面から「VPCネットワーク」→「ファイアウォールルール」→「ファイアウォール ルールを作成」を選択します。

3.ファイアウォールルールを作成します。

名前→任意
優先度→他のファイアウォールルールより低いものを指定
トラフィックの方向→上り
一致したときのアクション→拒否
ターゲット→ネットワーク上のすべてのインスタンス
ソースフィルタ→IP範囲
ソースIPの範囲→あとで入れるので適当でいいですが、CIDR表記(x.x.x.x/x)の形式にしてください。
入力が終わったら「作成」を選択し、作成されたことを確認します。

4.IPアドレスを入力します。
まず「プロジェクトID」が必要なため、確認をします。
GCPコンソール画面上部青帯のプロジェクト名を選択するとプロジェクトIDが出てくるので控えます。

次にIPアドレスを入力するAPIのページに行きます。

右側に入力画面が出てくるので、
「project」に先ほど控えたプロジェクトID、「firewall」に3で作成したファイアウォールルールの「名前」に入力した名前を
入力し、「Add request body parameters」を選択、

「sourceRange」を選択、

「sourceRange」の下に、1で作成したIPアドレス表を、最大255までにわけて貼り付けます。

一番下の行のIPアドレスには「,」(カンマ)が入らないようにしてください。
入力が終わったら、「EXECUTE」を選択します。

Google APIs ExplorerがGoogleアカウントへのアクセスをリクエストしています と出たら「許可」を選択します。

緑地で「200」と出れば成功です。一回エラーが出てももう一度「EXECUTE」を選択すれば通ることが多いです。

コンソール画面の「VPCネットワーク」→「ファイアウォールルール」にもどり、「更新」を選択します。
「ソースフィルタ」の欄にIPアドレスが反映されたことを確認します。

上位を20回ほど繰り返せば、完了です。

非常に疲れました。

GoogleFormsでフォームを再作成しました

以前、WordPressのプラグインで作成したブログのお問い合わせフォームですが、

GCPに移行後、使えなくなってしまいました。
お問い合わせを受け取ったら、その内容をメール送信するのですが、
送られてこないのです。
調べたところ、

Google Compute Engine では、ポート 25、465、587 での送信接続は許可されません。これらの送信 SMTP ポートは、不正使用に利用されることが多いため、デフォルトでブロックされています。

インスタンスからのメールの送信  |  Compute Engine ドキュメント  |  Google Cloud

どうやら、これに引っかかっているみたいでした。

以前フォームからお問い合わせをいただいたこともあり、
フォームの廃止は出来ないので、検討した結果、GoogleFormsで作り直しました。

お問い合わせ | 青星総合研究所

今後とも当ブログをよろしくお願いいたします。

[GCP]SSH画面でファイル送信

昨日、SSHでGCP上のサーバにログインしましたが、ファイルの送受信もそこから出来ます。

【アップロード】
SSHでログインをしたら、


右上の歯車アイコンから「アップロード」を選択、


ファイルを選択し、


完了するまで待ちます。


ファイルは
/home/ユーザ名
に置かれます。

【ダウンロード】


ダウンロードも同様に、右上の歯車アイコンから「ダウンロード」を選択、


ダウンロードしたいファイルを絶対パスで入力すると、


ダウンロードが出来ます。

[GCP]スナップショット取得

スナップショットを取得でバックアップを作成しました。


コンソール画面の「Compute Engine」から「スナップショット」を選択し、「スナップショットを作成」を選択、


「名前」と「説明」は適当で、「ソースディスク」はサーバのディスクを選択し、「作成」を選択すると。


数分程度でスナップショットが取得できます。

GCPでブラウザからSSH

GCPでブラウザからサーバにSSH接続することが出来ます。


コンソール画面から、「Compute Engine」→「VMインスタンス」を選択し、


「SSH」を選択すると、


ウィンドウが開いて、

操作が出来るようになります。root権限が必要な作業はsudoでできます。

とりあえず、
/etc/apache2/apache2.confに
「ServerTokens Prod」を追加するなど、セキュリティ対策を実施中です。

【さくら→Google移行作戦 後半】GCP設定・WordPress移行

前半に引き続き、サーバ移行です。
旧サーバから情報を抜きだし、GCP上にサーバをデプロイし、DNSの設定変更を行います。

1.旧サーバ作業
Wordpressの移行は初めてなので、ツールに頼ります。


移行元のさくらサーバのWordpress上に移動し、プラグイン「All-in-One WP Migration」をインストールします。


「All-in-One WP Migration」メニューから「エクスポート」を選択します。

 
「エクスポート先」をクリックし、「ファイル」を選択すると

エクスポートが始まります。


「DOWNLOAD」をボタンが出たら、それをクリックするとダウンロードが始まります。

2. GCP登録、サーバ設定

Google Cloudのサイトへ行き、「無料トライアル」を選択します。


住所や支払い登録をして、登録します。


出てきたページの「一般的なソリューション」「WordPress」を選択します。


「COMPUTE ENGINE上で起動」を選択します。

デプロイするサーバの設定値を聞かれるので、GCPの無料範囲内に収まるよう設定します。

Deployment name→適当に(たしかデフォルトそのままだった気が)
Zone→「us」を入っているものを選択。


Machine Type
「micro」を選択

Administrator Email→自分のものを入力
Disk size in GB→30 GB

後はデフォルトのまま「デプロイ」を選択します。


「〜をデプロイしました。」と表示され、


右側にユーザ名、パスワード等が表示されることを確認します。ユーザ名、パスワードは後で使用するのでメモしてください。

Site addressのURLを開くと、

WordPressが使える状態になっています。

3.旧サーバの情報インポート
1で旧サーバからエクスポートした情報をGCP上のサーバにインポートさせます。

先ほどメモした「WordPress administrator username」「WordPress admin password」を使用し、GCP上のWordPressにログインします。

GCP上のWordPressにもプラグイン「All-in-One WP Migration」をインストールします。


「All-in-One WP Migration」メニューから「インポート」を選択します。

旧サーバからダウンロードしたファイルを指定します。


旧サーバの情報で上書きしても大丈夫か聞かれるので「PROCEED(続行)」を選択します。


インポートが終わったら、


旧サーバの情報が引き継がれた事を確認します。
※これ以降WordPressにログインする場合は、旧サーバで使用していたユーザ名、パスワードを使用します。

4.ネットワーク、DNS周りの設定
サーバに割り当てられているIPアドレスを静的なものにして、DNSの向きを旧サーバからGCPに向けます。


GCPのコンソール画面から「VCPネットワーク」「外部IPアドレス」を選択します。

 
タイプが「エフェメラル」になっているので「静的」に変更します。その際にIPアドレスもメモします。

 

Google Domainsページを開き、
「ウェブサイト」を選択し、


「転送」を選択し、メモした「IPアドレス」を入力し、「転送」を選択します。


「ウェブのレコード」をクリアしますか?と表示されたら「OK」を選択します。


転送の設定はとりあえずこうしました。

これで、DNSの向きが新サーバ切り替わります。

ただ、DNSの設定がインターネット上に反映されていく(いわゆる「DNS浸透」)のは数時間ほどかかります。
すぐ確認したいという方は、自PCのDNSサーバの設定を、Googleが公開している「8.8.8.8」に変更すると、

同じGoogle上のためか、すぐ反映されています。





また、ブログのインポート時にURLがドメイン名からIPアドレスに置き換わってしまっているため、
Search RegexというWordpressの置換プラグインで、置換をします。


最後に、WordPressでURLの設定をすれば移行は完了です。

——————-
正直、数日前に急に思い立って移行したので手間取るのかと不安でしたが、
正直なところ、やったことをブログにまとめるほうが時間かかるくらいスムーズにできました。