Oracle Cloud InfrastructureでAlways FreeのARMインスタンスを作ってUbuntu20.04LTSにWordPressを移行するまでのメモ

あらすじ

OsakaリージョンにてA1インスタンス争奪戦に勝利したのでCentOS7で稼働している当ブログ(WordPress)を運用しているサーバーより引っ越ししてみた。
一応、他インスタンス用に余裕をもたせるためAlways Freeのリソース上限一杯ではなく 3OCPU,18GB 構成のシェイプで作成。
CentOSの雲行きが怪しいためイメージはUbuntu 20.04を選択。

参考

スペック確認

ssh接続してスペック確認しておきましょう。
ちなみにUbuntuイメージの場合、初期で使用するユーザーは opc では無くなぜか ubuntu となっています。

free -h

              total        used        free      shared  buff/cache   available
Mem:           17Gi       279Mi        15Gi       5.0Mi       1.4Gi        16Gi
Swap:            0B          0B          0B

lscpu

Architecture:                    aarch64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
CPU(s):                          3
On-line CPU(s) list:             0-2
Thread(s) per core:              1
Core(s) per socket:              3
Socket(s):                       1
NUMA node(s):                    1
Vendor ID:                       ARM
Model:                           1
Model name:                      Neoverse-N1
Stepping:                        r3p1
BogoMIPS:                        50.00
NUMA node0 CPU(s):               0-2
Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1:        Mitigation; __user pointer sanitization
Vulnerability Spectre v2:        Not affected
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected
Flags:                           fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc
                                  dcpop asimddp ssbs

これが無料…！？

下準備

root切り替え

何かとめんどくさいのでrootで作業しましょう。

sudo su -

タイムゾーン変更

timedatectl set-timezone Asia/Tokyo

パッケージ更新

apt -y update
apt -y upgrade

SELinux無効

ユーティリティインストール。

apt install selinux-utils

getenforce

初めから無効になってた。

Disabled

Apache導入

インストールと動作確認

インストールして有効化

apt -y install apache2
systemctl enable apache2
systemctl start apache2

htmlディレクトリ権限設定
Ubuntuの場合apacheで使用するユーザーは www-data

chown -R www-data:www-data /var/www/html
chmod -R 755 /var/www/html

グローバルIP確認

curl ifconfig.io

出力例

140.83.83.216

外部から http://140.83.83.216 にWebブラウザでアクセスしてデフォルトページを確認…。出ない！なぜ…。
80ポートが開放されてないようなのでサーベイ開始。

ファイアウォール設定

詳細は省きますが、素直にufwを使って80とついでに443ポートをLISTEN設定してもダメでした。
調べてみるとOCIでのUbuntuインスタンスの場合はufwが機能しない既知の問題があるようなのでiptablesを使ってポート開放設定をしていきます。

既知の問題

Ubuntuインスタンスが、Uncomplicated Firewall (UFW)を有効にした後で再起動に失敗します
詳細: Ubuntuを実行しているコンピュート・インスタンスでUFWを有効にすると、インスタンスが正常に再起動されません。
回避策: UFWを使用してファイアウォール・ルールを編集しないでください。プラットフォーム・イメージは、インスタンスがそのブート・ボリュームとブロック・ボリュームに発信接続できるように、ファイアウォール・ルールで事前構成されています。詳細は、「必須のファイアウォール・ルール」を参照してください。UFWがこれらのルールを削除すると、再起動中にインスタンスがブート・ボリュームとブロック・ボリュームに接続できなくなります。

まずは念の為ufwは使えないので無効にしておきます。

ufw disable
systemctl stop ufw
systemctl disable ufw

/etc/iptables/rules.v4 を編集してポート80と443の開放設定を追加。

-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT

更新設定を適用。

1	iptables-restore < /etc/iptables/rules.v4

仮想クラウドネットワーク(VCN)のイングレス設定

VCNのポート開放設定をまだしていない場合はこちらも忘れずにHTTPとHTTPS用のポートの開放設定を追加します。

再度Webブラウザでアクセスしてデフォルトページが表示されたら成功です。

WordPress引っ越し

WordPress用ディレクトリ作成

任意ですが今回は /srv/d0web/www/blog に配置します。

mkdir -p /srv/d0web/www/blog
chown 755 /srv/d0web/www/blog

旧サーバーで配置していたwordpress用ディレクトリの中身をすべて上記のディレクトリにコピー。
コピー後はオーナーを www-data に設定。

chown -R www-data:www-data /srv/d0web/www/blog

PHPとMariaDBをインストール

apt -y install php7.4 php7.4-mysql

apt -y install mariadb-server mariadb-client
systemctl start mariadb
systemctl enable mariadb

WordPressに必要なモジュールもインストール

apt -y install php-gd

データベース移行

旧サーバーで使用していたWordPressのデータベースのバックアップを取ります。旧サーバーもMariaDBという前提です。

1	mysqldump --add-drop-table -h localhost -u ユーザ名 -p データベース名 \| bzip2 -c > d0web_db.bz2

d0web_db.bz2 というファイル名でバックアップが出力されます。

次に移行先のARMインスタンスの方で、データベースを作成します。
以下コマンドでMariaDB起動

mysql

旧サーバーと同じデータベース名でデータベース作成。

CREATE DATABASE データベース名 DEFAULT CHARACTER SET utf8;

旧サーバーと同じユーザーとパスワードでユーザー作成。

GRANT ALL ON データベース名.* TO ユーザー名@localhost IDENTIFIED BY 'パスワード';
FLUSH PRIVILEGES;

MariaDBを終了

exit

バックアップしておいた d0web_db.bz2 を作成したデータベースにインポート。

1 2	bzip2 -d d0web_db.bz2 mysql データベース名 < d0web_db

公開設定

配置したWordPressにアクセスできるようにするための設定を行います。

まずApacheのデフォルトページ設定を無効化。

a2dissite 000-default.conf

配置したWordPressを表示するための設定を追加します。

以下内容のファイル 任意の名前.conf(d0web.com.conf など) で作成して /etc/apache2/sites-available に配置。
記載のディレクトリ場所等は適宜変更して下さい。

DocumentRoot /srv/d0web/www/blog

AllowOverride All

Require all granted

</Directory>

</VirtualHost>

設定を適用

a2ensite d0web.com.conf

apacheを再起動して外部からWebブラウザでアクセスして確認。

systemctl restart apache2

1	http://140.83.83.216/

移行したWordPressサイトが表示されたら成功。
各記事へのアクセスや、画像が出ない等はこの段階では無視しておく。（後ほどのドメイン設定で解決予定）
データベース確立エラーなどが表示される場合は手順を見直し。

ドメイン設定

使用している独自ドメインのIP割当を新サーバーのIPに割り当てる必要がありますが状況によって手順が異なります。

今回は旧サーバーがOCIのインスタンスで予約済みパブリックIPを割り当てており、
かつドメインはそのIPを割り当てている前提の手順とします。

予約済みIPの割当を変更

OCIコンソールより、
旧インスタンスのインスタンスの詳細 -> アタッチされたVNIC -> VNICの詳細 -> IPv4 アドレスにて編集を開きます。

一旦 “パブリックIPがありません” に設定してから、”エフェメラル・パブリックIP” に設定変更。

次は新インスタンス(ARM)のインスタンスの詳細 -> アタッチされたVNIC -> VNICの詳細 -> IPv4 アドレスの編集にて、
同様に一度パブリックIPを解除してから、既存の予約済みIPアドレスを選択します。

独自ドメインにて新インスタンスにSSH接続できるかやってみましょう。

VirtualHost設定

一つのサーバーで複数ドメインを使用して複数サイトを運用するなどが可能なVirtualHost設定をしておきましょう。

www.d0web.com または d0web.com でアクセスされた時のみ /srv/d0web/www/blog 配置されたコンテンツを表示する場合は、
/etc/apache2/sites-available に配置した d0web.com.conf を以下のように編集します。

ServerName www.d0web.com # 追加

ServerAlias d0web.com # 追加

DocumentRoot /srv/d0web/www/blog

AllowOverride All

Require all granted

</Directory>

</VirtualHost>

設定反映

systemctl reload apache2

独自ドメインでWebブラウザにアクセスしてWordPressサイトが表示されるかどうかチェックしましょう。

1	http://www.ドメイン/

トップページ以外のリンク切れ修正

WordPress引越し後に記事ページが404になって表示されないことがあり、
その場合Apacheにてmod_rewriteが有効になっていない可能が高いので以下のコマンドで有効化します。

a2enmod rewrite
systemctl restart apache2

それでも直らない場合はWordPressの管理画面のパーマリンク設定で、何も変更を加えず保存をすると直る可能性があります。

Apacheのセキュリティ設定

ディレクトリ一覧表示を無効

a2dismod --force autoindex

Webサーバーのバージョン情報等を非表示

404ページ等の下部に表示されるサーバーの情報を非表示に設定。
/etc/apache2/conf-available/security.conf を以下のように編集。

ServerTokens Prod # OS から Prod に変更
ServerSignature Off # On から Off に変更

未定義ホストやIPアドレスでのアクセス禁止

未定義ホスト名でのアクセスを拒否する設定を行います。
以下のファイルを 任意の名前.conf(000-undefhost.conf 等) で作成して /etc/apache2/sites-available に配置。

ServerName any

Order deny,allow

Deny from all

</Location>

</VirtualHost>

設定の有効化

a2ensite 000-undefhost.conf

注意点として、UbuntuのApacheのホスト設定ファイル(.conf)は名前順に設定を読むこむ仕様のようで、
今回のアクセス禁止設定は最初に読み込まれないと効果がないため、
000- などを先頭につけて必ず他の設定ファイルより早く読み込まれるようにする必要があります。

SSL化

ついでにサイトのSSL化もずっとしてなかったのでいい機会かと思いcertbotを使ってLet’s Encryptします。これも無料なのでありがたいですね。
以下のcertbot公式の手順通りにやっておしまいです。

Certbot – Ubuntufocal Apache

Apacheのホスト設定も自動的に更新され、httpでアクセスした際のhttpsへのリダイレクト設定もやってくれます。

あと、certbotでのSSL化と同時にsystemdのタイマーに証明書更新コマンドが自動的に登録されるので期限切れの心配も無いですね。

タイマー確認

systemctl list-timers

Thu 2021-09-16 08:50:00 JST 6h left       n/a                         n/a          snap.certbot.renew.timer     snap.certbot.renew.service

http, https両方でアクセスしてSSLが有効になっているかどうか確認しておきましょう。

1 2	http://www.ドメイン/ https://www.ドメイン/

トライアル期間終了後にA1インスタンスも終了

OCIコンソールで気になってたのは作成したA1インスタンスのところに Always Free の表記が無いこと。

引っ越し前に使っていたE2.1.Microインスタンスには Always Free 表記があるので本当に無料なのか気になるところ。

聞いた話によるとA1インスタンスはトライアル期間終了後に強制停止されるようなので、この仕様があるためわざと Always Free が表示されないようになっている…？

まだ１ヶ月弱トライアルが残ってるので終了次第以下と同様の対応を予定。
またリソース争奪戦が予想されますが…。

Oracle Cloud Always Free A1インスタンスがトライアル終了後に強制停止 – Fun Scripting 2.0

再度インスタンス取得時に Always Free 表記が出れば安心なのですが果たして。

[11/10追記] 2ヶ月後にA1インスタンスが強制終了しました。

11/6付でA1インスタンスがお亡くなりになりました。

A1インスタンスが強制終了する時期としては、
1ヶ月の30000円分チケット無料期間のあとにさらに1ヶ月の執行猶予期間があり、
その間に有料アカウントに切り替えずに１ヶ月経過すると強制終了となるようです。

といういことで、以下の記事を参考にA1インスタンスを復活させてみました。

Oracle Cloud Always Free A1インスタンスがトライアル終了後に強制停止 – Fun Scripting 2.0

手順的には、

ブートボリュームを残してA1インスタンスを終了
ブートボリュームからインスタンスを再度生成
ここでA1リソースに空きがあればそのままA1インスタンスが復活

と、なりますが案の定A1リソースに空きが無く争奪戦に参加することになりました。
争奪戦に勝利するには以下の記事が役に立ちます。

TerraformでOCIのA1インスタンス無料枠争奪戦を戦う

現状のドを運用しているE2インスタンスにTerraformを入れてA1インスタンス生成ジョブをスクリプトで実行することにします。

ジョブのTerraform設定ファイルであるmain.tfに記載する設定にいくつか分かりにくい部分があったので補足を入れておきます。

private_key_pathには、Oracle Cloudのユーザーに設定してあるAPIキーに紐づく秘密鍵へのパスを設定します。
APIキーを登録していない場合はユーザー設定から登録する必要があります。

ユーザー設定から、

APIキー -> APIキーの追加より .pemファイルをアップロードする。

fingerprintには上記に表示されているフィンガープリントをそのまま記載します。

regionにはリージョン識別子を入れます。

リージョンおよび可用性ドメイン

大阪の場合は、ap-osaka-1となります。

main.tfのprovider “oci”の値はこんな感じになりました。

provider "oci" {

tenancy_ocid = "ocid1.tenancy.oc1..**********************************"

user_ocid = "ocid1.user.oc1..********************************"

fingerprint = "***************************"

private_key_path = "/home/ubuntu/.ssh/id_rsa.pem"

region = "ap-osaka-1"

}

main.tfがあるディレクトリをカレントディレクトリにして以下を実行。

terraform init

terraform plan

terraform apply -auto-approve

plan実行時に以下のエラーが出る場合は、private_key_pathに公開鍵を設定している可能性が高いです。
僕は参考サイトを鵜呑みにしてそのまま .pem ファイルのパスを設定していたのですが、.pemは公開鍵で、ペアの秘密鍵は.pemではないファイルでした。

Error: can not create client, bad configuration: did not find a proper configuration for private key

│

│ with provider["registry.terraform.io/hashicorp/oci"],

│ on main.tf line 1, in provider "oci":

│ 1: provider "oci" {

terraform applyを実行するとジョブが実行されますが、以下のエラーが発生しています。

Error: 500-InternalError

│ Provider version: 4.51.0, released on 2021-11-03.

│ Service: Core Instance

│ Error Message: Out of host capacity.

ジョブの実行には成功していますが、A1インスタンスを確保するためのリソースが不足しているということなので、ここからが争奪戦の始まりです。成功するまで何回も実行しましょう。

手動で実行するのはアレなので、以下のような感じでシェルスクリプトを作成します。10秒毎にA1インスタンスの生成を試み、成功したら終了します。

#!/bin/sh

COUNT=0

while true;

COUNT=$((COUNT+1))

echo "Count : $COUNT" > a1ins.log

terraform apply -auto-approve >> a1ins.log

if [ $? -neq 1 ]; then

break

sleep 10

done

ssh経由でシェルスクリプトを実行する場合はnohupを使ってバックグラウンドで実行すればssh切断後もスクリプトが実行され続けます。

1	nohup ./a1ins.sh &

２ヶ月前は20000回ほどのリクエストで作成成功したのですが、今回は4000回ほどで済みました。

復活したA1インスタンスにSSHアクセスを行うと、そっくり死亡前のインスタンスが復活していました。よかったです。

ちなみに懸念していたAlways Free表記ですが、A1インスタンスだとやっぱり表記は無いままです。

これは、Free Tierアカウントの場合、月時間で無料稼働できるCPUとメモリに制限あり、A1シェイプでの4OCPUと24GBメモリの場合はその無料枠に収まるということで無料で使えるが、設定次第では無料制限枠を超えるのでA1インスタンス自体がAlways Freeではないっぽいので表記が無いと考えられます。

どのテナンシでも、ひと月の最初の3,000OCPU時間と18,000GB時間は無料で、VM.Standard.A1.Flexシェイプ(4OCPU、メモリー24GBに相当)を使用してAmpere A1 Computeインスタンスを作成できます。また、VM.Standard.E2.1.Microインスタンス2つも無料です。Always Freeのリソースの詳細

なので、4OCPU、24GBメモリ設定に収めていれば無料であることは間違い無いので心配しなくても良さそうです。

おわい

祭りに乗っかって試しにA1インスタンスを取ってみてWordPressを引っ越して見ましたが見違えるほどのレスポンスになって満足しか無いです。ありがとうOracle。

2021.09.16現在当ブログはA1インスタンスで稼働してますが何も問題なさそうです。
Vultr $5コース -> E2.1.Micro -> A1.Flex と引っ越しをしまして、無料になりスペックもアップして言うこと無しです。

VultrのVPSは一旦停止しましたが、あっちはあっちで既に AlmaLinux と Rocky Linux と新しめなOSに対応するなどのおもしろ要素があるのでまた必要になれば使おうと思います。

かと言って只より高いものはないというぐらいなので、何かあった時を見据えて避難先の目処は立てておいたほうが良さそうです。

おわい

カテゴリー:メモ

タグ:Apache Oracle Cloud Ubuntu WordPress

ド

あらすじ

参考

スペック確認

下準備

root切り替え

タイムゾーン変更

パッケージ更新

SELinux無効

Apache導入

インストールと動作確認

ファイアウォール設定

仮想クラウドネットワーク(VCN)のイングレス設定

WordPress引っ越し

WordPress用ディレクトリ作成

PHPとMariaDBをインストール

データベース移行

公開設定

ドメイン設定

予約済みIPの割当を変更

VirtualHost設定

トップページ以外のリンク切れ修正

Apacheのセキュリティ設定

ディレクトリ一覧表示を無効

Webサーバーのバージョン情報等を非表示

未定義ホストやIPアドレスでのアクセス禁止

SSL化

トライアル期間終了後にA1インスタンスも終了

[11/10追記] 2ヶ月後にA1インスタンスが強制終了しました。

おわい

シェアする

関連投稿

[WordPress] アンケートプラグイン “YOP Poll” で投票後にページ上部にスクロールしてしまう問題の対処

WordPressのoptions.phpの設定が反映されない時の対処

[WordPress] Googleフォトと連携すると”Invalid/missing request nonce.”と出て連携できない時の対処メモ

[WordPress] Gutenbergを使うとEasy FancyBoxが有効にならない時の対処

PowerShellで外部プロセスを実行して終了コードを取得する方法

[Visual Studio Code] ver1.54.0以降でbackgroundプラグインで背景画像が表示されない問題の対処

コメントを残す コメントをキャンセル

コメントを残すコメントをキャンセル