zuntan02のはてなブログ

備忘録的なものです。時々職場の技術者ブログにも転記してますが、メインはこちらで。

さくらのレンタルサーバにむけていたネームサーバをお名前に戻した

【経緯】

  • 1)お名前で取得したexample.comををさくらのレンタルサーバに持ち込み、サイトとメールを運用していた。 ※この際ネームサーバはさくらのものを指定

  • 2)このexample.comにTXTレコードを追加する必要が出てきた。さくらのレンタルサーバのみの契約の場合、ゾーンファイルの編集は出来ない。 ※「ネームサーバー（オプションサービス）」を申し込めば変更可能となる模様（月額1100円…）

  • 3)ネームサーバをお名前に戻して解決

【さくらに聞いたこと】

  • 1)現在契約しているさくらのレンタルサーバのIPアドレスは変動しないか？ →変動しない（ただし、今後、大規模なメンテナンス等で変更される場合もあるので案内を見てねとのこと）

  • 2)ネームサーバを外部で管理する場合の設定内容について

    ウェブサーバ・メールサーバを引き続き弊社サーバで運用される場合、[A/MX/およびwww.のCNAME]とTXTレコードの設定を推奨しております。 恐れ入りますが、それ以外の項目については、お客様のメールソフトやFTPソフトの設定内容によりますため、弊社では判断いたしかねます。 なお、MXレコードは下記のとおり、初期ドメインで設定していただけますでしょうか。

参照：

help.sakura.ad.jp

【ハマりポイント】

さくらはメールクライアントに設定するメールサーバを「example.sakura.ne.jp」のような初期ドメインにしてねと言っているが、 メールサーバー名としてmail.example.comが利用されている可能性があるため、mail.のCNAMEを忘れないようにする。

あとなにげにお名前のメンテナンスが1日あったりして作業がができなかった。

【やったこと】

1)現在のさくらのNSで設定されているものをdigで拾う

example.com.           3600    IN      TXT     "v=spf1 a:wwwxxxx.sakura.ne.jp mx ~all"
example.com.           3600    IN      A       xx.xx.xx.xx
example.com.           3600    IN      MX      10 example.sakura.ne.jp.
www.example.com.       3600    IN      CNAME   example.com.
mail.example.com.      3600    IN      CNAME   example.com.

2)お名前のゾーンファイルに転記したうえでネームサーバをお名前のものに戻す

以上

エックスサーバー構築中のメール送信について

別のレンサバで動作中のサイトをエックスサーバに移管しようとした場合に、構築中の新環境からのメールが届かないということがありエックスサーバーのサポートに問い合わせた回答をメモ

【問い合わせ内容】

別サイトで運用中のドメイン　example.com　を移管しようと、エックスサーバ上に環境を作成しております。 ドメイン設定でドメイン「example.com」を追加した状態で、まだNSは向けておりません。

このサーバから username@example.comにメールを送ると、現在利用中（非エックスサーバ） のメールサーバにはメールは届かず、エックスサーバ上のメールボックス（username@example.com） にメールが届いているようですが、これは仕様でしょうか？ （該当サーバ内から送るとlocalhostあてに届く？）

【サポートより回答】

サーバーパネル上に対象ドメインのメールアドレスが 作成されておりますと、同じエックスサーバーのサーバーから 送信されたメールが、DNS情報に関わらず、エックスサーバーの サーバーへと【内部配送】されます。

仕様っぽい

エックスサーバーのアカウント間でのサイト移管での注意点

エックスサーバー上で動作中のサイトを、別アカウントのエックスサーバーに移管した際の注意点

【ハマったパターン】

入力されたドメイン「example.com」は既に設定されています。

となり作成できない……

【結論】

引っ越しが完了するまではDNSの向き先を変えずに、hosts書き換えで確認しようと思ったけど、上記問題があってできなかった。 旧エックスサーバーアカウントでexample.comを削除すると即座に新エックスサーバーでexample.comが作成できるようになるが、切り替え時はサイト断を避けられなかった。

エックスサーバーにWordpress＋Laravel環境構築

ゴールイメージ

【参照】

https://reffect.co.jp/laravel/xserver-laravel8#i https://www.xserver.ne.jp/manual/man_program_soft.php https://kinokomarket.com/web/deploy-webservice-to-xserver/ https://miya-system-works.com/blog/detail/server-xserver-laravel/

【WPとLaravel相乗りの構造】

/home/userdir
│  
├──ドメイン用ディレクトリ
│        ├──laravel
│        │      └──app(Laravelプロジェクト) 
│        │
│        └──public_html(Wordpress）
│                └──app(上記Laravelプロジェクトへのシンボリックリンク)

【上記構成の理由】

当初/home/userdir直下にlaravelアプリを配置し、ドメイン用ディレクトリよりシンボリックリンクで参照させたがLaravel側の.htaccessが解釈されなかった。 Xserverで用意された”ドメイン”（ドキュメントルートを含むディレクトリ）以下でないと.htaccessが正常に動作しないものと思われた （間違ってたらご指摘ください。。。）

事前準備

1)SSHの設定 [SSH有効化]

  • SSH設定:ONにする

  • 公開鍵認証用鍵ペアの生成：パスフレーズなしで作成、取得

ssh hogehoge@hogehoge.xsrv.jp -p 10022 -i hogehoge.key

で接続して以下の作業ができるようにする

2)Wordpressが利用しているPHPのバージョン変更 WPの利用バージョンがLaravelで利用する予定のPHPとズレてる場合はあわせとく

例）[PHP ver.切替]-[hogehoge.xsrv.jp]-[選択する] PHP7.4.33（推奨）→ PHP8.1.12 で[変更]

Laravelのインストール

STEP. 1 CLI版のPHPバージョンを切り替える

# シンボリックリンクを作成する
cd ~
mkdir bin
ln -s /usr/bin/php8.1 $HOME/bin/php
ls -la $HOME/bin/
# lrwxrwxrwx 1 hogehoge members  15 May  8 21:27 php -> /usr/bin/php8.1


# .bash_profileを編集する
vi .bash_profile
=============
# .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
        . ~/.bashrc
fi

# User specific environment and startup programs

#PATH=$PATH:$HOME/bin ←1.コメントアウト
PATH=$HOME/bin:$PATH ←2.新たに記述します

export PATH
=============

# 再読み込み
source .bash_profile

# バージョン確認
php -v
# PHP 8.1.12 (cli) (built: Oct 31 2022 09:40:07) (NTS)
# Copyright (c) The PHP Group
# Zend Engine v4.1.12, Copyright (c) Zend Technologies

STEP.2 Composerをインストールする

# composer -V
# Composer version 1.10.22 2021-04-27 13:10:45
# 初期状態でもV1.10が入っていた
# 最新化するため以下の手順を実施
# 

# Composer公式手順：https://getcomposer.org/download/
#＝＝＝＝＝＝＝＝＝
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php -r "if (hash_file('sha384', 'composer-setup.php') === '55ce33d7678c5a611085589f1f3ddf8b3c52d662cd01d4ba75c0ee0459970c2200a51f492d557530c71c15d8dba01eae') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
php composer-setup.php
php -r "unlink('composer-setup.php');"
# ＝＝＝＝＝＝＝＝＝
# composer.phar がダウンロードされるので、composer のコマンドで実行できるように、PATHが通っている場所へ移動させます。
# →composer.pharをcomposerという名前にして.config/composer/vendor/bin/の下に保存します。
cd ~
mkdir -p .config/composer/vendor/bin/
mv composer.phar .config/composer/vendor/bin/composer

# .bash_profileに新たなパスの追加
vi .bash_profile
=============
#PATH=$HOME/bin:$PATH  ←1.コメントアウト
PATH=$HOME/.config/composer/vendor/bin:$HOME/bin:$PATH ←2.新たに記述します
=============

# 再読み込み
source .bash_profile

# 確認
composer -V
# Composer version 2.5.5 2023-03-21 11:50:05

STEP.3 Laravelをインストールする

# composerコマンドでLaravelインストーラをグローバルインストールします
composer global require laravel/installer

STEP.4 Laravelプロジェクトを構築する

cd ~/hogehoge.xsrv.jp
mkdir laravel

cd ~/hogehoge.xsrv.jp/laravel
composer create-project --prefer-dist laravel/laravel app

# 確認
cd ~/hogehoge.xsrv.jp/laravel/app/
php artisan -V
# Laravel Framework 10.9.0

STEP.5 Laravelのプロジェクトを公開する

#シンボリックリンクを作成する
ln -s ~/hogehoge.xsrv.jp/laravel/app/public ~/hogehoge.xsrv.jp/public_html/app

# .htaccess修正
vi /home/hogehoge/hogehoge.xsrv.jp/public_html/.htaccess
==========
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

# rewrite to laravel app
RewriteRule ^app/(.*)$ app/$1 [QSA,L]

RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
==========
> RewriteRule ^app/(.*)$ app/$1 [QSA,L]
を追記

以上

AWSのOSイメージをDVDに焼いて納品してねと言われたら

【概要】

どこかの世界線でAWSのOSイメージをDVDに焼いて納品してねと言われたときに備えてメモ （まさかですよね）

【参照】

docs.aws.amazon.com

【例えばこんな感じ】

AMI→.bin

aws ec2 create-store-image-task \
    --image-id ami-ID \
    --bucket S3バケット名

進捗確認

aws ec2 describe-store-image-tasks

aws ec2 describe-store-image-tasks
{
    "StoreImageTaskResults": [
        {
略
            "S3objectKey": "ami-ID.bin", 
            "StoreTaskState": "Completed", 
            "ProgressPercentage": 100
        }
    ]
}

→S3バケットに上記.binファイルができている →これをDLして納品すれば……いいのかな……

ちなみに戻し方

.bin→AMI化

aws ec2 create-restore-image-task \
    --object-key ami-ID.bin \
    --bucket S3バケット名 \
    --name "New AMI Name"

尚RDSについては、スナップショットより[AmazonS3へのエクスポート]機能が存在する https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_ExportSnapshot.html ただし： https://dev.classmethod.jp/articles/rds-snapshot-s3-export/ https://dev.classmethod.jp/articles/tsnote-rds-to-s3-and-restore/

S3 へエクスポートした DB スナップショットデータから DB インスタンスへの復元は行えません

とのことなのであくまで上記目的の場合のみ。

【AWS】AuroraMySQLのバージョンアップをBlue/Greenデプロイを利用して実施してみた

【概要】

Aurora1.22.2（MySQL5.6互換）についてAurora2（MySQL5.7）世代への強制アップグレード予告が来た。
対象のスナップショットから検証環境を立て、単純にインプレースアップグレードをしたところ5時間弱かかった。
2022年末に公開されたAuroraのBlue/Greenデプロイで対応できないか検証したところ、停止時間は5分と大幅に短縮された。
※停止があるのは最初のbinlogを有効にする際の瞬断（1分未満）およびスイッチオーバー（切り替え）時の4分だった

■参照サイト

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments-overview.html
https://tech.connehito.com/entry/2023/01/10/181131
https://speakerdeck.com/hmatsu47/green-depuroiwoshi-sitemita
https://dev.classmethod.jp/articles/enable-aurora-binary-logs/
https://dev.classmethod.jp/articles/rds-bg-deploy/
https://qiita.com/hmatsu47/items/cb69c0a4f0042b7666e7
https://www.sunnycloud.jp/column/20221229-01/

■用語

  • Blue:変更前、ここでいうとAurora1環境
  • Green:変更後、ここではAurora2になった環境
  • Switchover：BlueへのトラフィックをGreenに切り替える

※スイッチオーバーするまでの間はDBはBlueからGreenにレプリケーションし続ける必要がある。

【概要理解】
Auroraに対して「ブルー/グリーンデプロイ」を実行すると、裏側ではbinlogを出してBlue→Greenへのレプリケーションを開始する。そのうえでクローンをインプレースアップグレードし、その後レプリケーションを再開していると思われる。これまで手作業でやっていたもの（例：https://dev.classmethod.jp/articles/enable-aurora-binary-logs/）でやってることを自動でやっているものと推察される。楽ちん。

■ハマリポイント

作業としては既存のAuroraクラスタを選択してブルー/グリーンデプロイの作成を行うだけだが以下2点のハマりポイントがある。

  • 1)Blue側のクラスタ用パラメータグループでバイナリログを出す設定にして反映しておく必要がある（binlog_format MIXEDにして再起動）
  • 2)ブルー/グリーンデプロイ設定前にBlue側でバイナリログを発生させておく必要がある

■ハマリポイント回避のための事前準備

1)Blue側のクラスタ用パラメータグループでバイナリログを出す設定にして反映しておく

binlog_formatがOFFの状態でB/Gデプロイを作成しようとすると

Blue Green Deployments requires cluster parameter group has binlog enabled.

というエラーになってしまう。メッセージにある通りbinlogが有効になっている必要があるため、クラスタのパラメータグループでbinlog_formatを有効にする必要がある。

パラメータグループの変更

Blue環境にアタッチされているクラスタ用パラメータグループを編集し

binlog_format	OFF
↓
binlog_format	MIXED

とする

★インスタンス再起動で反映★

上記のままだとDBクラスターのパラメータグループが「再起動を保留中」のままで反映されていないため、インスタンスを再起動する。
[アクション]-[再起動]→「同期中」となったら作業を進める。或いは以下で確認してもよい。

SHOW VARIABLES LIKE 'binlog_format';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | MIXED |
+---------------+-------+
2)ブルー/グリーンデプロイ設定前にBlue側でバイナリログを発生させておく

Green環境の作成前に、Blue環境で何かしらの書き込み処理を行わなければ、下記のエラーが発生する。

Read Replica Replication Error - IOError: 1236, reason: Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'

既知の問題として、バイナリログの出力を有効にしたのち、Green環境作成前にBlue側のデータベースに対して何かしらの書き込み処理を行う必要があるとのこと。
（参照：https://tech.connehito.com/entry/2023/01/10/181131）

show master status;
+----------------------------+----------+--------------+------------------+-------------------+
| File                       | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+----------------------------+----------+--------------+------------------+-------------------+
| mysql-bin-changelog.000003 |      120 |              |                  |                   |
+----------------------------+----------+--------------+------------------+-------------------+

Insertなどを行い、show master statusでPositionが増えていることを確認する。

■ブルー/グリーンデプロイの設定

ここまでできたら、クラスタを選択してB/Gデプロイの設定を進める
[アクション▲]-[ブルー/グリーンデプロイの作成-新規]

ブルーデータベース識別子
（規定値）

ブルー/グリーンデプロイ識別子
stg-hogehogeなど。一時的な識別子なのでなんかわかるようにつける

ブルー/グリーンデプロイ設定
・グリーンデータベースのエンジンバージョン：5.7.mysql.aurora-mysql5.7（推奨/最新）
→今回バージョンアップが目的だったのでこれでいく
・グリーンデータベースの DB クラスターパラメータグループ：あらかじめ用意しておいたクラスタ用パラメータグループ
・グリーンデータベースの DB パラメータグループ：あらかじめ用意しておいたパラメータグループ

を設定したら
[ステージング環境の作成]
を実施

ブルー/グリーンデプロイ設定ができたらGreen側のバージョンを確認

  • エンジンバージョン： 5.7.mysql_aurora.2.11.1
  • DB クラスターのパラメータグループ： [再起動を保留中]になっている！→再起動を実施

※Green側再起動後のタイミングでもBlueからのレプリケーションが行えていることを念の為確認。OK。

■切り替え

ロール：ブルー/グリーンデプロイ を選択し[アクション]-[切り替え]
→4分ほどで終了
Blueのエンドポイントで接続し、バージョン確認

mysql> select @@aurora_version;
+------------------+
| @@aurora_version |
+------------------+
| 2.11.1           |
+------------------+
1 row in set (0.00 sec)

→スイッチオーバー中にエンドポイント名が変わる
Green環境のエンドポイント名がBlueのものに変更され、旧Blue環境は「-oldn」付きに変更される

■後片付け

切り替えが終わっても旧インスタンスは稼働しているので削除する。
併せてブルー/グリーンデプロイも削除する。
「ブルー/グリーンデプロイを削除しても、ブルー環境に影響はありません。」
（https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments-deleting.html）

  • ロール：ブルー/グリーンデプロイ を削除
  • 旧ｄｂ(-oldn）クラスタを削除