zuntan02のはてなブログ

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

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分だった

■用語

  • 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

  • ロール:ブルー/グリーンデプロイ を削除
  • 旧db(-oldn)クラスタを削除

【GWS】SMTPサーバー:smtp.gmail.com を利用したメール送信

【概要】

1)自前で運用しているツール(BitwardenとかMattermostとか)のシステムメール送信を、サーバ腹持ちのSMTPサーバ(Postfixとか)ではなくsmtp.gmail.comを利用して送信したい。
2)送信時のfromアドレスがGWSのユーザ名になってしまうので、no-reply@からの送信としたい。

【やったこと】

1)アプリパスワードの作成

SMTPを利用するGoogleアカウント(hogehoge@example.com)にて
[Google アカウントを管理]-[セキュリティ]-[アプリパスワード]で
サービス名を入力して「生成」→16桁の文字列が得られます。
メール送信だけであれば、

で送信可能ですが、このまま使うとメール送信時にhogehoge@example.comからの送信となってしまう(※)ため、よくあるno-reply@example.comからの送信とするため以下の作業を追加で行いました。

※各アプリケーションのシステムメールの設定でReplyToAddressなどにno-reply@example.comを設定すると、メールヘッダのX-Google-Original-From にno-reply@example.comが入って届くようになりますが、この時点ではメールのFromはhogehoge@example.comのままです。

2)GWS管理アカウントでSMTP利用ユーザに対し「予備のメールアドレス」を追加

AdminユーザでGoogleWorkspaceを開き、「予備のメールアドレスを追加」
でユーザー(今回はhogehoge@example.com)を指定して続行

今回は予備のメールとして
no-reply@example.com
を登録。

3)SMTP利用ユーザ自身のアカウントに予備のメールアドレスを「他のメールアドレスを追加」として追加する

ユーザー(hogehoge@example.com)のGmailの設定ページに行き、
「アカウント」タブのところで[他のメールアドレスを追加]として上記で追加した
no-reply@example.com
を追加します(この時名前はブランクとしています。また「エイリアスとして扱います」はONのままとします)

これで送信されたメールのFromがno-reply@example.comとなりました。

[アプリケーション側設定例]

■Bitwarden
global.override.env

globalSettings__mail__replyToEmail=no-reply@example.com
globalSettings__mail__smtp__host=smtp.gmail.com
globalSettings__mail__smtp__port=587
globalSettings__mail__smtp__username=hogehoge@example.com
globalSettings__mail__smtp__password=<アプリパスワード>

■Mattermost
config.json

"FeedbackEmail": "no-reply@example.com",
"ReplyToAddress": "no-reply@example.com",
"FeedbackOrganization": "",
"EnableSMTPAuth": true,
"SMTPUsername": "hogehoge@example.com",
"SMTPPassword": "<アプリパスワード>",
"SMTPServer": "smtp.gmail.com",
"SMTPPort": "587",
"SMTPServerTimeout": 10,
"ConnectionSecurity": "STARTTLS",

■事後的なメリット

hotehoge@example.comアカウントのGmail[送信済み]に各種システムメールの送信ログがまとめて入るため、管理が簡単になりました。

【P2V】デスクトップPCをVM化してみた2022

【サマリ】

Windows11マシンをvmdk化してVMware Workstation Playerで動かしてみた。

【本メモの経緯】

以前はメジャーだったVMware vCenter Converter Standaloneは
2022年02月にretireになってた
https://blogs.vmware.com/vsphere/2022/02/vcenter-converter-unavailable-for-download.html
ので、他のP2Vソフトを探したところ、お馴染みEaseUS Todo Backup WorkstationのP2V機能でVMDKに変換できるようだ。
※ライセンスの再認証等については別問題なのでここでは触れません。

【ダウンロード】

EaseUS Todo Backup Workstation
https://down.easeus.com/product/tb_enterprise_trial
→無料で30日間利用できる。上記URLよりtb_enterprise_trialをインストール。

VMware Workstation Player
https://www.vmware.com/jp/products/workstation-player.html
→最新版取得してインストール。

【やってみた】

1)vmdk化
EaseUS Todo Backup Workstationを起動、
[ツール]-[P2Vコピー]で対象のディスクを選択、出力先に外付けHDDなど指定して実行
※500GBで数時間かかってたがvmdkが作成できた。

2)VMWare Workstation Playerで実行
上記で作成したvmdkを指定して開く→動く。

【残念な点】

UEFI/GPTベースシステム(例えばmacのBootCamp領域など)の場合、上記手順では仮想化できなかった。
以下の手順が参考となると思われるが、未検証。メモのみ残しておきます。

Windows10の初期化を設定の[回復]から実施する手順

【参考】
https://tanweb.net/2018/12/17/24529/
https://aonasuzutsuki.hatenablog.jp/entry/2016/10/23/175343


[設定]-[更新とセキュリティ]-[回復]-[このPCを初期状態に戻す]-[開始する]

この際以下のオプション選択

  • アプリとファイルを削除する
  • ドライブのクリーニングを実施する(詳細でONにすることが可能)
  • Windowsをダウンロードして再インストール

■BootCampでインストールされているWindows10について
macにBootCampでインストールされていたWindows10についても上記で初期化が可能(macOS側を破壊せずにWindows側の初期化が可能)だったが、インストール後にWindowsサポートソフトウェアのインストールを行ってもmacOSでの起動ができない(電源再起動時にoptionを押してパーティションを選ぶことで起動できる)ため、BootCampの場合はmacOS側からクリーンインストールしたほうが最終的な初期化コストは低いと思われる。


以上メモまで。

【CloudWatchLogs】特定の文字列が出たらアラートメールするメモ

【ゴール】

ログに"ERROR"という文字列が出たらSNS経由でメールが飛ぶようにします

【やったこと】

1)ロググループにメトリクスフィルターを追加する


ロググループを選択-[アクション]-[メトリクスフィルターを作成]

フィルターパターン:"ERROR"
メトリクスの割り当て
フィルター名:hogehoge_filter
メトリクス名:hogehoge_error
メトリクス名前空間:hogehogeApp
メトリクス値:1
デフォルト値:0
Unit:-

2)メトリクスフィルターによる値を記録するためにテストログを出す

https://dev.classmethod.jp/articles/metrics-filter-missing/CloudWatch Logs メトリクスフィルターは 継続的にデフォルト値をメトリクスに発行しているわけではない | DevelopersIO
によれば
「メトリクスフィルターがメトリクスに値を発行するのは、フィルターパターンに一致するにせよしないにせよ、ログイベントが発生した場合のみ」らしいので手動でテストログを追記する

[2022-xx-xx xx:xx:00] hoge.ERROR: this is test log. please igonre me.

→メトリクスにカスタム名前空間として先ほど作成した
> メトリクス名前空間:hogehogeApp
が出ているはずなので、その中のメトリクス「hogehoge_error」が出ていることを確認する

3)アラームの作成

SNSトピック「test-user」(スタンダード、サブスクリプションのエンドポイントが対象のメールアドレス)は既に存在している前提
[アラーム]-[アラームの作成]

メトリクスと条件の指定

メトリクス:2)で確認したメトリクスを選択
しきい値の種類:静的
アラーム条件 0より大きい
(5 分内の1データポイントのhogehoge_error > 0)

アクションの設定

通知:通知の送信先に作成済みのSNSトピック「test-user」を指定

名前と説明を追加

アラーム名:[testApp]hogehoge_error
アラームの説明:
testApp_hogehogeで"ERROR"を含むログが出力されました。
詳細はCloudwatchLogsのロググループ:****.log をご確認ください。

4)テスト

再度テストログを出力
→メールが届けばOK

AWS SESからのメールがGmailからはじかれるのでやったこと(DKIM/DMARC)

■前提

ネームサーバがRoute53管理じゃなかったので生成されたレコードを登録担当に連絡して登録してもらう流れ。

1)DKIM

参照:https://docs.aws.amazon.com/ja_jp/ses/latest/dg/creating-identities.html#verify-domain-procedure

[Amazon SES]-[Create identity]
Identity type : Domain
Domain : <ドメイン名>
オプションのチェックボックスは選択せず
その他はデフォルトのママで
[Create Identity]

→生成されたDKIMDNSレコードを先方に渡して設定してもらう
→CNAMEレコードが返るようになったら、再度認証し、
DomainKeys Identified Mail (DKIM)のDKIM configurationが「Successful」となることを確認

上記ができたら続いていDMARCの設定を進めます。

2)DMARC

2)-1 カスタムの MAIL FROM ドメインを使用する

参照:
https://docs.aws.amazon.com/ja_jp/ses/latest/dg/mail-from.html
[Amazon SES]-[Configuration: Verified identities]-[Authentication]

Custom MAIL FROM domain
AWSの推奨する形で mail from ドメインとして
mail.<ドメイン名>
を作成(既存のレコードと衝突する場合は調整すること)。

出力されたDNSレコードを登録担当に連絡して登録してもらう

2)-2 ドメインの DMARC ポリシーのセットアップ

参照:
https://docs.aws.amazon.com/ja_jp/ses/latest/dg/send-email-authentication-dmarc.html
AWSの推奨するポリシーで作成したTXTレコードを登録担当に連絡して登録してもらう

_dmarc.example.com	TXT	"v=DMARC1;p=quarantine;pct=25;rua=mailto:dmarcreports@example.com"

3)確認

Custom MAIL FROM domain の MAIL FROM configuration が「Successful」になっていることを確認

GMAILのメッセージのソースを表示で確認

■参照
https://dev.classmethod.jp/articles/ses-send-mail-best-practices-summary/#toc-13



以上