🌟
本番環境の爆速切り戻しに向けて方法検討した
検討に検討を重ねる
やりたいこと
- リリース後に問題が起きた場合に、最速でリリース前の状態に戻せるようにしておきたい
- サーバーに直接入らずとも、コマンドの実行で切り戻しされるようにしたい
やろうとしたこと
- deployシェルの変更
- デプロイ時に作成されるディレクトリ名をタグ名に変更
- 元々はデプロイ日時がディレクトリ名になっていた
- 日時だと切り戻しする際に切り戻し先のディレクトリ名が分からないので、明確に分かるタグ名を使用する
- デプロイ時に作成されるディレクトリ名をタグ名に変更
- 切り戻しシェルの作成
- 切り戻し先のディレクトリ名(つまりタグ名)を指定して、指定されたディレクトリに変更されるシェルを作成(指定されたディレクトリに切り戻すコマンドたちは既に作成されていたのでそれを流用)
- コマンドの作成(jenkins)
- 上記のシェルを実行するコマンド作成
ええやんええやんってなってたけどなんかCodeDeployでデプロイ時にgitのタグ名取得するの意外と手間っぽい😢
重めのタスクとして起票しなおして改めて着手した方が良さそう...(ちょろ対応で終わるつもりだったので軽微のタスク扱いだった)
検討した案
- 切り戻しシェルを各サーバー内に直接作成(deployシェルの変更不要)
- 懸念
- サーバーに直接入らないといけない
- 3つのサーバーで実行が必要
- 懸念
- デプロイシェル内でgitコマンドで最新のタグ名を取得
- 懸念
- gitコマンドを入れる必要あり(懸念か?)
- デプロイ時に常に最新のタグ名を取得してしまう
- 空デプロイすると同じディレクトリ名になってエラーになる?
- 懸念
- codeBuildを変更してgitのタグでリリースを管理するようにする
- 懸念
- がっつりcodeBuildの修正が必要(IAMロールとかも)
- terraformの修正も必要になるし結構大きめの改修になる
- がっつりcodeBuildの修正が必要(IAMロールとかも)
- 参照記事
- 懸念
その他懸念
- マイグレーション実行があった場合の切り戻しは大丈夫?
Discussion