Oracle Cloud InfrastructureでAlways FreeのARMインスタンスを作ってUbuntu20.04LTSにWordPressを移行するまでのメモ
あらすじ
OsakaリージョンにてA1インスタンス争奪戦に勝利したのでCentOS7で稼働している当ブログ(WordPress)を運用しているサーバーより引っ越ししてみた。
一応、他インスタンス用に余裕をもたせるためAlways Freeのリソース上限一杯ではなく 3OCPU,18GB 構成のシェイプで作成。
CentOSの雲行きが怪しいためイメージはUbuntu 20.04を選択。
参考
- Ubuntu 20.04 LTS に WordPress 5.7 をインストール – Qiita
- Ubuntu 20.04にApache Webサーバーをインストールする方法 | DigitalOcean
- WordPressサイトの移行手順まとめ(mysqldumpから別環境移行まで) | 73spica’s Blog
- Oracle Cloudでポートを開放されない問題の解決策
- Ubuntu標準のapacheでVirtualHostが読まれる順番 – kariaの日記 @ Alice::Diary
スペック確認
ssh接続してスペック確認しておきましょう。
ちなみにUbuntuイメージの場合、初期で使用するユーザーは opc では無くなぜか ubuntu となっています。
|
1 |
free -h |
|
1 2 3 |
total used free shared buff/cache available Mem: 17Gi 279Mi 15Gi 5.0Mi 1.4Gi 16Gi Swap: 0B 0B 0B |
|
1 |
lscpu |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
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で作業しましょう。
|
1 |
sudo su - |
タイムゾーン変更
|
1 |
timedatectl set-timezone Asia/Tokyo |
パッケージ更新
|
1 2 |
apt -y update apt -y upgrade |
SELinux無効
ユーティリティインストール。
|
1 |
apt install selinux-utils |
|
1 |
getenforce |
初めから無効になってた。
|
1 |
Disabled |
Apache導入
インストールと動作確認
インストールして有効化
|
1 2 3 |
apt -y install apache2 systemctl enable apache2 systemctl start apache2 |
htmlディレクトリ権限設定
Ubuntuの場合apacheで使用するユーザーは www-data
|
1 2 |
chown -R www-data:www-data /var/www/html chmod -R 755 /var/www/html |
グローバルIP確認
|
1 |
curl ifconfig.io |
出力例
|
1 |
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は使えないので無効にしておきます。
|
1 2 3 |
ufw disable systemctl stop ufw systemctl disable ufw |
/etc/iptables/rules.v4 を編集してポート80と443の開放設定を追加。
|
1 2 |
-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 に配置します。
|
1 2 |
mkdir -p /srv/d0web/www/blog chown 755 /srv/d0web/www/blog |
旧サーバーで配置していたwordpress用ディレクトリの中身をすべて上記のディレクトリにコピー。
コピー後はオーナーを www-data に設定。
|
1 |
chown -R www-data:www-data /srv/d0web/www/blog |
PHPとMariaDBをインストール
|
1 |
apt -y install php7.4 php7.4-mysql |
|
1 2 3 |
apt -y install mariadb-server mariadb-client systemctl start mariadb systemctl enable mariadb |
WordPressに必要なモジュールもインストール
|
1 |
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起動
|
1 |
mysql |
旧サーバーと同じデータベース名でデータベース作成。
|
1 |
CREATE DATABASE データベース名 DEFAULT CHARACTER SET utf8; |
旧サーバーと同じユーザーとパスワードでユーザー作成。
|
1 2 |
GRANT ALL ON データベース名.* TO ユーザー名@localhost IDENTIFIED BY 'パスワード'; FLUSH PRIVILEGES; |
MariaDBを終了
|
1 |
exit |
バックアップしておいた d0web_db.bz2 を作成したデータベースにインポート。
|
1 2 |
bzip2 -d d0web_db.bz2 mysql データベース名 < d0web_db |
公開設定
配置したWordPressにアクセスできるようにするための設定を行います。
まずApacheのデフォルトページ設定を無効化。
|
1 |
a2dissite 000-default.conf |
配置したWordPressを表示するための設定を追加します。
以下内容のファイル 任意の名前.conf(d0web.com.conf など) で作成して /etc/apache2/sites-available に配置。
記載のディレクトリ場所等は適宜変更して下さい。
|
1 2 3 4 5 6 7 8 |
<virtualHost *:80> DocumentRoot /srv/d0web/www/blog <Directory "/srv/d0web/www/blog"> AllowOverride All Require all granted </Directory> </VirtualHost> |
設定を適用
|
1 |
a2ensite d0web.com.conf |
apacheを再起動して外部からWebブラウザでアクセスして確認。
|
1 |
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 を以下のように編集します。
|
1 2 3 4 5 6 7 8 9 10 11 |
<virtualHost *:80> ServerName www.d0web.com # 追加 ServerAlias d0web.com # 追加 DocumentRoot /srv/d0web/www/blog <Directory "/srv/d0web/www/blog"> AllowOverride All Require all granted </Directory> </VirtualHost> |
設定反映
|
1 |
systemctl reload apache2 |
独自ドメインでWebブラウザにアクセスしてWordPressサイトが表示されるかどうかチェックしましょう。
|
1 |
http://www.ドメイン/ |
トップページ以外のリンク切れ修正
WordPress引越し後に記事ページが404になって表示されないことがあり、
その場合Apacheにてmod_rewriteが有効になっていない可能が高いので以下のコマンドで有効化します。
|
1 2 |
a2enmod rewrite systemctl restart apache2 |
それでも直らない場合はWordPressの管理画面のパーマリンク設定で、何も変更を加えず保存をすると直る可能性があります。
Apacheのセキュリティ設定
ディレクトリ一覧表示を無効
|
1 |
a2dismod --force autoindex |
Webサーバーのバージョン情報等を非表示
404ページ等の下部に表示されるサーバーの情報を非表示に設定。/etc/apache2/conf-available/security.conf を以下のように編集。
|
1 2 |
ServerTokens Prod # OS から Prod に変更 ServerSignature Off # On から Off に変更 |
未定義ホストやIPアドレスでのアクセス禁止
未定義ホスト名でのアクセスを拒否する設定を行います。
以下のファイルを 任意の名前.conf(000-undefhost.conf 等) で作成して /etc/apache2/sites-available に配置。
|
1 2 3 4 5 6 7 |
<VirtualHost *:80> ServerName any <Location /> Order deny,allow Deny from all </Location> </VirtualHost> |
設定の有効化
|
1 |
a2ensite 000-undefhost.conf |
注意点として、UbuntuのApacheのホスト設定ファイル(.conf)は名前順に設定を読むこむ仕様のようで、
今回のアクセス禁止設定は最初に読み込まれないと効果がないため、000- などを先頭につけて必ず他の設定ファイルより早く読み込まれるようにする必要があります。
SSL化
ついでにサイトのSSL化もずっとしてなかったのでいい機会かと思いcertbotを使ってLet’s Encryptします。これも無料なのでありがたいですね。
以下のcertbot公式の手順通りにやっておしまいです。
Apacheのホスト設定も自動的に更新され、httpでアクセスした際のhttpsへのリダイレクト設定もやってくれます。
あと、certbotでのSSL化と同時にsystemdのタイマーに証明書更新コマンドが自動的に登録されるので期限切れの心配も無いですね。
タイマー確認
|
1 |
systemctl list-timers |
|
1 |
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 が表示されないようになっている…？
まだ１ヶ月弱トライアルが残ってるので終了次第以下と同様の対応を予定。
またリソース争奪戦が予想されますが…。
再度インスタンス取得時に Always Free 表記が出れば安心なのですが果たして。
[11/10追記] 2ヶ月後にA1インスタンスが強制終了しました。
11/6付でA1インスタンスがお亡くなりになりました。
A1インスタンスが強制終了する時期としては、
1ヶ月の30000円分チケット無料期間のあとにさらに1ヶ月の執行猶予期間があり、
その間に有料アカウントに切り替えずに１ヶ月経過すると強制終了となるようです。
といういことで、以下の記事を参考にA1インスタンスを復活させてみました。
手順的には、
- ブートボリュームを残してA1インスタンスを終了
- ブートボリュームからインスタンスを再度生成
- ここでA1リソースに空きがあればそのままA1インスタンスが復活
と、なりますが案の定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”の値はこんな感じになりました。
|
1 2 3 4 5 6 7 |
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があるディレクトリをカレントディレクトリにして以下を実行。
|
1 2 3 |
terraform init terraform plan terraform apply -auto-approve |
plan実行時に以下のエラーが出る場合は、private_key_pathに公開鍵を設定している可能性が高いです。
僕は参考サイトを鵜呑みにしてそのまま .pem ファイルのパスを設定していたのですが、.pemは公開鍵で、ペアの秘密鍵は.pemではないファイルでした。
|
1 2 3 4 5 |
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を実行するとジョブが実行されますが、以下のエラーが発生しています。
|
1 2 3 4 |
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インスタンスの生成を試み、成功したら終了します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
#!/bin/sh COUNT=0 while true; do COUNT=$((COUNT+1)) echo "Count : $COUNT" > a1ins.log terraform apply -auto-approve >> a1ins.log if [ $? -neq 1 ]; then break fi 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に対応するなどのおもしろ要素があるのでまた必要になれば使おうと思います。
かと言って只より高いものはないというぐらいなので、何かあった時を見据えて避難先の目処は立てておいたほうが良さそうです。
おわい
