Knowledge Base

お知らせや身辺のことを綴っています。
目次
yokkin.comの運用環境を移行した

yokkin.comの運用環境を移行した

報告です。

本ウェブサイトの開始となる2014年から約10年弱の間、ホスト先としてレンタルサーバーであるスターサーバーを利用していましたが、2024/9/15にOracle Cloud Infrastructure上のインスタンスに移行しました。

なんで?

スターサーバーは、PHPのバージョンに限っては新しいものに追従してくれます。ただし、それ以外のミドルウェア(PythonやRuby等)、特に、MySQLのバージョンはずっとアップデートされていません。自分で作ったアプリの中で用いた比較的新しいSQLの構文が利用できず、不便に感じていたところでした。

たとえば、スターサーバーを提供するネットオウルさんは、2024/9/10に以下のような記事をリリースし、PHPの新バージョン導入を告知しました。

『スターサーバー/スタードメイン』PHP 8.3 導入のお知らせ
https://www.netowl.jp/news_detail.php?view_id=3610

他方、同じようなレンタルサーバーを営んでいるさくらのインターネットさんは同時期の2024/9/6にMySQL 5.7以下の足切りを行う旨の記事をリリースしました。

【さくらのレンタルサーバ】データベース機能における「MySQL 8.0」提供予定に関するお知らせ
https://www.sakura.ad.jp/corporate/information/announcements/2024/09/06/1968216999/

不満に感じていた、ちょうど2点を刺激するような記事が同時期にリリースされてしまい、移行を決意した次第です。

どうやった?

どんなことをやったのかを後日思い出しながら書いているので、説明が不足している部分があるかもしれません。想定環境としては、以下のようになります。

  • Ubuntu noble 24.04 aarch64
  • Podman 4.9.3
  • Podman Compose 1.2.0
  • ネットワークスタック: Netavark
  • Tailscaleが設定されている

スターサーバーから利用できるphpMyAdminにログインして、WordPressのデータを保存しているテーブルをダンプします。wp-content以下もローカルに持っていきます。

OCIインスタンス上で、Podman Composeを使って、少なくともWordPressとMariaDBの両方のサービスが動くサービスを構成します。構成方法については、Docker Hub上に親切に設定例が書いてあるので、少し改変してcomposeファイル(docker-compose.yml)を書いていきます。

設定例
services:
  db:
    image: mariadb:10.6.4-focal
    platform: linux/arm64
    command: '--default-authentication-plugin=mysql_native_password'
    volumes:
      - type: bind
        source: ./dbdata
        target: /var/lib/mysql
    restart: always
    environment:
      - MYSQL_ROOT_PASSWORD=somewordpress
      - MYSQL_DATABASE=wordpress
      - MYSQL_USER=wordpress
      - MYSQL_PASSWORD=wordpress
    expose:
      - 3306
      - 33060

  wordpress:
    image: wordpress:latest
    platform: linux/arm64
    ports:
      - 0.0.0.0:9000:80
    restart: always
    environment:
      - WORDPRESS_DB_HOST=db
      - WORDPRESS_DB_USER=wordpress
      - WORDPRESS_DB_PASSWORD=wordpress
      - WORDPRESS_DB_NAME=wordpress
    volumes:
      - type: bind
        source: ./wpdata
        target: /var/www/html

  phpmyadmin:
    image: phpmyadmin
    platform: linux/arm64
    links:
      - db
    environment:
      PMA_HOST: db
      PMA_PORT: 3306
      PMA_ARBITRARY: 1
      UPLOAD_LIMIT: 1G
    restart: always
    ports:
      - 0.0.0.0:9001:80

筆者の場合、データーベース周りの設定を簡単にしたり、ホストから色々ファイルを操作できるようにしたりしたい意図があったため、phpMyAdminをサービスに加えるほか、ボリュームを作成するのではなく、諸々のディレクトリを既存のディレクトリにバインドマウントするようにしています。

コンテナを立ち上げます。ブラウザからデーターベース操作ができるように、あらかじめ張っておいたVPN(Tailscaleで構成)を使って、phpMyAdminにログインして、先ほどダンプしたSQLをテーブルにインポートします。この時点では、サイトをHTTP化していないので、wp_optionsテーブルのそれぞれsiteurlhomeのカラムの値をhttp://で始まるように書き換えておきます。

次にwordpressサービスにバインドしているwpdata/wp-contentの中身を、先ほどレンタルサーバーから落としてきたwp-contentの中身に差し替えます。

次に、Cloudflare上でDNSのAレコードを書き直しました。具体的には、yokkin.comがスターサーバーのIPアドレスから、OCI上のインスタンスのIPアドレスに変換されるように書き換えます。

次はインスタンス上にインストールしているApacheの設定をします。設定ファイルを好きな名前で作成し、VirtualHostを設定し、リバースプロキシの宛先を、コンテナがフォワードしているポート番号に向けます。

<VirtualHost *:80>
ProxyRequests Off
KeepAlive Off
<Proxy *>
    Require all granted
</Proxy>

ProxyPass / http://localhost:9000/
ProxyPassReverse / http://localhost:9000/
ProxyPreserveHost On
</VirtualHost>

この時点でHTTPから一応アクセスできるので、CertbotでLet’s EncryptのSSL証明書を発行しておきます。発行すると、自動的に<先ほどの設定ファイル名の拡張子を除くファイル名>-le-ssl.confという名前のApacheのコンフィグが自動生成されるので、今度はこちらををいじります。

X-Forwarded-ProtoとX-Forwarded-Portというリクエストヘッダーを設定してあげます。筆者の場合は、これを設定しないと、サイト内リンクをクリックするとlocalhostにリダイレクトされてしまうという不具合が出てしまい、すこし困りました。解決には以下のStack OverFlow上の投稿が役立ちました。

https://stackoverflow.com/questions/65640780

...
ProxyRequests Off
KeepAlive Off
<Proxy *>
    Require all granted
</Proxy>

RequestHeader set X-Forwarded-Proto "https"  # 追加
RequestHeader set X-Forwarded-Port "443"  # 追加

ProxyPass / http://localhost:9000/
ProxyPassReverse / http://localhost:9000/
ProxyPreserveHost On
...

Apacheを再起動し、phpMyAdminにログインし、先ほど設定したwp_optionsテーブルのそれぞれsiteurlhomeのカラムの値をhttps://で始まるように再度置換しておきます。

余計なリソースを食わせたくないので、composeファイルからphpMyAdminのサービスをコメントアウトして、podman-compose restartします。

以上…だと思います。

追記:パフォーマンス面について。

レンタルサーバーを利用している時と比べて、ページの応答時間が早くなりました。

今回の環境ではページ読み込みが悪くて200ms以内に収まります!さらにキャッシュが効くと20msくらいにまで短縮されます。恥ずかしながら、どこがボトルネックになってるかとかはあまり興味がなくて、深くプロファイルをとることはしなかったのですが、往年の悩みが解決しちゃって満足です。

たぶん、Docker Image自体が、いい感じにチューニングされているのだと思います。その辺の工夫については、今度自分でアプリを作るときに応用できるかもしれないので、ちゃんと見ておこうと思います。

前の記事

コマンドを実行する際の心がけ

次の記事

Podmanで同一ネットワーク内の他のコンテナのドメイン名を解決できるようにする

コメント

0

コメントはありません。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

関連投稿

日記
「Podmanで同一ネットワーク内の他のコンテナのドメイン名を解決できるようにする」のサムネイル画像

Podmanで同一ネットワーク内の他のコンテナのドメイン名を解決できるようにする

Podmanで、ネットワークスタックをNetavarkに変更して、同一ネットワーク内の他のコンテナのドメイン名を解決できるようにします。 続きを読む

日記
「6月を振り返ってみる」のサムネイル画像

6月を振り返ってみる

2024年6月にあったことを振り返る記事です。 続きを読む

日記
「検索エンジンのBotについて考える」のサムネイル画像

検索エンジンのBotについて考える

このサイトに訪れているクローラの種類と数を集計して、ダウンタイムの謎を暴きます。 続きを読む

日記
「デジタル金庫環境の整備とPowerShell」のサムネイル画像

デジタル金庫環境の整備とPowerShell

PowerShellを書いて上手に暗号化ドライブを管理するソリューションを開発しました。 続きを読む