こんにちは。クルーズ株式会社CTOの鈴木です。
SHOPLISTの脱レガシ―システムの話も10回目となりました。
今回はSHOPLISTのデプロイ方法を変更した話です。
今までのデプロイ方法
今までのデプロイ方法はかなり古典的で以下のやり方をしていました。
検証環境へのデプロイ
検証環境にSSHログインし、gitのコマンド操作でリリース対象のブランチやタグを指定し、GitLab上からcheckout
本番環境へのデプロイ
検証環境にSSHログインし、対象のソースコードを本番にrsync
課題
今回デプロイ方法の変更を行うきっかけになる課題がいくつかありました。
⓵リリースのロールバックが手間であること
リリース直後に不具合が出て切り戻そうとした時に、まず、検証環境にSSHログインをし、前回リリース時点のタグを指定してソースコードをcheckout後、本番環境にrsyncを行う。実際にはrsyncのオプションで除外するためのソースコードを指定するファイルを指定して実行しているため、その除外ファイルのリストの確認などがリリースたびに発生するので、切り戻しの意思決定をしてからロールバックを実行するまでの時間が長い状態になっている。
②リポジトリ上の特定リリースタグで指定されるコードの状態と実際に本番環境で動いているコードの状態が違うケースがある。
今までのデプロイ方法はrsyncを実行する際にrsync対象に含めないコードをまとめたファイルを指定して実行していたため、そのファイルに含まれるパスのソースコードについては本番サーバにrsyncが実行されない。結果としてリポジトリ上のリリースタグで指定される状態と、本番のコード状態に差異が生まれてしまうケースがあった。
③EC2インスタンスの追加・縮退の都度rsync先のIPアドレスのメンテナンスを行う必要があり管理が煩雑
各種セールでEC2インスタンスの台数が変更される都度IPアドレスのメンテナンスを行う必要がある。
GitLab CI/CDで自動デプロイを実現する設計
Git上のブランチとして検証環境のソースコードに対応するブランチ、本番環境のソースコードに対応するブランチを作成しておき、それぞれのブランチに対してマージがされたタイミングでGitLabRunnerが起動し、Pipelineの各stageに定義されているジョブを実行します。
各ジョブ（dryrun、deploy、post_deploy）にはデプロイにおける必要な定義が記載されていて、各処理の実行を待ってソースコードのデプロイが完了する形です。
実際の開発はGitLab-Flowに従って実施されているため、
検証環境へのデプロイの場合は、featureブランチから検証用ブランチにMerge Requestが申請され、承認されたタイミングでマージが実行され、検証環境デプロイ用のパイプラインが実行。
本番環境へのデプロイの場合はfeatureブランチもしくはHotFixブランチから本番用ブランチにMerge Requestが申請され、承認されたタイミングでマージが実行され、本番環境デプロイ用のパイプラインが実行。
切り戻す際は切り戻す時点のコミットハッシュ値からHotFixブランチを作成し、あとは上記に記載する本番環境へのデプロイの流れと同じです。
デプロイ対象のEC2インスタンスの特定は、ansibleがEC2インスタンス構築時に、用途に応じてタグをつける仕様となっており、そのタグに紐づくリストをAWS のAPIを利用して取得しています。
デプロイ方法を変更してみて
変更直後については、デプロイの仕方が大きく変わったため技術統括部への問い合わせが若干発生していましたが、その後問題なく運用できています。
また実際にリリース作業を行う現場のサーバサイドエンジニア数名にヒアリングしたところ、概ね上々だったのでデプロイ方法変更としてはうまくいったと思っています。
当初懸念として、rsyncから比べるとデプロイ開始から完了までのトータル時間がかかるので、デプロイ時間が延びることで何か良くないこと（リリース中に不具合が発生した場合に中止できないとか、デプロイ中に、デプロイが完了しているインスタンスと未完了のインスタンスができ、両方にALBが振り分けてくるので大丈夫なのかとか）が起こるんじゃないかという漠然とした不安があったのですが、特段今のところは問題が出ていません。
この件については漠然とした不安レベルなので、具体的に問題が発生したら回避策を考えていきたいと思います。
ちなみに切り替えて約5カ月が経過していますが今のところ問題の発生はないです。
-------------------------------------------------------------------------------------------------
※2020年の内容を記事にしており、2020年11月以降PHP7サポート切れをはじめとした脆弱性リスクへの対処は完了しております。
