ブルー グリーン デプロイ。 CloudFormationとAWS CLIで作るCodeDeploy（Blue/Green）環境

CodeBuild,CodeDeploy,CodePipeline３つ使ってCI/CDの環境構築してみた

先日、 に初めて参加してきました。 広いジャンルのセッションがあって大変勉強になったんですが、 その中でも一際興味を惹かれたのが、このセッションでした。 聞いたことすらない・・・状態だったので聞いてきました。 結果よかった。 簡単にセッション内容をまとめてみました。 CIとは？ 継続的インテグレーションのこと（Continuous Integration） 主にプログラマーのアプリケーション作成時の品質改善や納期の短縮のための習慣のこと 狭義にはビルドやテスト、インスペクションなどを継続的に実行していくことを意味する。 （wikipedia） 今回はこの意味で使ってます。 狭義にはビルドやテスト、インスペクションなどを継続的に実行していくことを意味する。 ・テストがあるけど実行し忘れた 変更の度にテストを回すことで解決 ・昔書いたテストが壊れて動かない 毎回回しているのですぐに気づいて修正ができる。 ・テスト結果が環境依存 CIを唯一のテスト環境にする docker等を使って毎回コンテナを構築し、毎回同じテスト環境かつまっさらな状態でテストを実行できる。 便利な機能 可視化• ステータスバッチ（テストの成否が分かる）• ダッシュボード（テスト実行履歴や実行中のものを確認できる）• メール・チャットへの通知（slackへも可） マージブロック• githubの機能でCIがokでないとマージできないようにできる。 参考 CIの種類 オンプレミス型• Jenkins• Concourse CI• Drone クラウド版もあり） ・クラウド型• Travis CI• CircleCI• Wercker• Codeship• AWS CodeBuild• GCP Cloud Build• （ごめんなさい 色々と読んでいると、料金・使いやすさ・速さ・規模が重要なファクターになっていて、 流行りはCircleCIっぽいですね。 触ってみての感想ですが、AWS CodeBuildも流行りそうな気がしますが。 詳しい方選び方について教えてくださると嬉しいです。 読んでみた記事 ここの記事が良さげ。 使ってみての感想を書いてるのと、メリットデメリット書いてくれてる。 継続的デリバリーは人の意思が介在する。 コード変更の度にデプロイされると困るケースもあると思うので、途中に承認フローを挟んでいるところは多そうですね。 こういった場合は継続的デリバリーに分類されます。 画像参照元（ 何ができるの？ テスト以降のリリースの作業を自動化することができる。 何が嬉しい？ rollbackが自動化 ヒューマンエラーが発生しなくなる。 フィードバックループが回る。 よくある問題と解決 検証環境で見つからなかったバグ 仕様と違う動きをする そもそも仕様が間違ってた。 フィードバックを得て、カイゼンを繰り返す。 高度な使い方 本番環境でテストする ・ブルーグリーンデプロイで片方のインスタンスでテストできる ・カナリーリリースで部分デプロイし、本番でテストする。 hands-onに参加してみた さて、では実際に作ってみたいと思います。 このセッションの話をしたら、弊社の高木さんが過去にハンズオンに参加したとのことで、教えてもらいました。 ありがとうございます。 興味ある方はぜひ参加してみてください。 参加したハンズオン DevOps Hands-on vol. 使用したAWSの機能• CloudFormation• CodePipeline CD• CodeBuild CI• リソース管理に割く時間を減らし、AWS で実行するアプリケーションにさらに注力できるようになります。 使用するすべての AWS リソース Amazon EC2 インスタンスや Amazon RDS DB インスタンスなど を記述するテンプレートを作成すれば、AWS CloudFormation がお客様に代わってこれらのリソースのプロビジョニングや設定を受け持ちます。 AWS リソースを個別に作成、設計して、それぞれの依存関係を考える必要はありません。 AWS CloudFormation がすべてを処理します。 次のシナリオは AWS CloudFormation がどのように役立つかを示します。 要は、設計図の役割のようです。 楽でいいですね。 CodePipeline は、お客様が定義したリリースモデルに基づき、コードチェンジがあった場合のフェーズの構築、テスト、デプロイを自動化します。 これにより、機能とアップデートを素早く、信頼性の高い方法で配信できます。 GitHub やお好みのカスタムプラグインなどのサードパーティ製のサービスと、AWS CodePipeline を簡単に統合することができます。 AWS CodePipeline ならば、お支払いいただくのは実際に使用した分のみです。 初期費用や長期契約は不要です。 読んだままですが、継続的デリバリーサービスです。 sourceの変更の感知からデプロイまでをマネジメントしてくれます。 今回の構成は以下でやっています• github source• CodeBuild により、ビルドサーバーのプロビジョニング、管理、スケーリングが不要になります。 CodeBuild は連続的にスケールされ、複数のビルドが同時に処理されるので、ビルドが待機状態でキュー内に残されることがありません。 パッケージ済みのビルド環境で、すぐに開始できます。 自分のビルドツールを使用するために、カスタムビルド環境を作成することもできます。 CodeBuild では、コンピューティングリソースの使用に対して、分単位で料金が発生します。 CI 継続的インテグレーション ですね。 テスト環境のビルドと実行両方やってくれます。 buildspec. （コマンドでも可な模様） CodeDeploy AWS CodeDeploy は、Amazon EC2、AWS Fargate、AWS Lambda、オンプレミスで実行されるサーバーなど、さまざまなコンピューティングサービスへのソフトウェアのデプロイを自動化する、フルマネージド型のサービスです。 AWS CodeDeploy を使用すると、新しい機能をすばやく簡単にリリースできます。 また、アプリケーションのデプロイ時のダウンタイムを回避し、アプリケーションの複雑なアップデート処理にも対応します。 さらに、ソフトウェアのデプロイを自動化できるため、ミスが起こりやすい手動操作の必要がなくなります。 このサービスでは、デプロイのニーズに応じてスケールできます。 CD 継続的デプロイ ですね。 デプロイ時に必要な作業を自動化できます。 yamlという設定ファイルを置いておくことで自動的にデプロイが可能。 masterブランチのソースコードが変わった時にCodePipelineが検知しCodeBuildにてビルドを行います。 ビルドのテストが通ると次はCodeDeployが動き、EC2インスタンス１台ずつにデプロイする。 といった流れになります。 次に、スタック名を決めて、IAMを同時に作成するかどうか聞かれるのでチェックを入れてつくってしまいます。 すると、作成中のステータスになるので、出来上がるまで待ちます。 （5分くらい待ちました できたので、サンプルアプリケーションが置かれる場所を確認しに行きます。 まだデプロイされていないのんでnginxのエラーが表示されます 作ってみる（CodeDeploy編） さて、下準備ができたのでDeploy環境から作っていきます アプリケーションの作成を押して、設定していきます アプリケーションメイトコンピューティングプラットフォームを決めます 今回はEC2にアップロードするのでこちらを選択します。 次にデプロイグループ名を決めます。 サービスロールは、先ほどcloudformationで自動生成されているので、そちらを選択します デプロイタイプ、環境設定、ロードバランサーを選択して、デプロイグループの作成を行います。 作ってみる（CodePipeline,CodeBuild編） 次にCodePipelineの設定をしていきます。 この過程で、CodeBuildも同時に作成します。 パイプライン名をつけて、rollは作成済みのものを選択します 次にソースステージを選択します。 今回はgithubなので、githubと連携させます。 連携終了後リポジトリを選択し、コードが変わった時に見て欲しいブランチを選択。 今回はデプロイまでして欲しいのでmasterになります。 ソースの選択が終わったら、次にビルドの設定をしていきます。 今回はCodeBuildを使って欲しいので、選択すると同時に別窓でCodeBuildの設定をします。 （選択すると勝手に開きます。 ） プロジェクトに合わせて選択 今回は、OperationSystemはUbuntu。 RuntimeはNode. jsを選択しました。 任意のversionを選択し、（常に最新を使う設定もあります） 作成済みのサービスロールを選択。 ここでCodePipelineに戻ってくるので、次へを選択。 デプロイの設定は、先ほど作ったCodeDeployのアプリケーションをそのまま使います。 これで設定完了です！！！ 使ってみる 最初は自動的に動くようになっています。 動いているかどうかの確認はCodePipelineで確認できます ということでビルドが通って、デプロイが完了しました。 先ほどのエラーページが出た画面を確認してみます。 デプロイできてる！！！！ テストをわざと落としてみる では、テストが落ちた時にどんな挙動をするのか確認します。 5行目を変えています） 落ちました！！デプロイはされないようになっています！！！ ということで、以上がハンズオンの内容でした。 一回やってしまうと理解は深まりますが、その１回目が辛いだろうなとやってて感じました。 おまけ１ プルリクエスト毎にビルドテストする 新しく作る必要があります。

次の

チュートリアル

けっこう曖昧なので調べてみました。 ABテスト• サイト・アプリを改善する際に、どっちのやり方がいいか両方本番にデプロイして調べる方法です• アクセスしたユーザーに対してランダムに表示する機能を切り替え、コンバージョン等の結果を測定します• 試したい複数の機能に加え、「ユーザーを振り分ける機能」、「振り分けたユーザーから結果を測定する機能」が必要になります• 改善案が間違っていた場合、一部の本番のユーザーが離脱するなどの悪影響にもなりかねます• 振り分けをしているので全ユーザーにはなりませんが、意識する必要があります• カナリアリリース• 新機能リリース等の際に一気にリリースするのではなく、一部ユーザーに振り分けて様子見しながら徐々に新機能に移行する方法です• ABテストとの違いは、別に機能を試して調査したいのではなく、リリースに関わるトラブルのリスク軽減が目的であることです• 負荷等の問題が発覚したらロールバックする。 振り分けしているので全ユーザーには影響しないで済むこともある• 「ユーザーを振り分ける機能」が必要です ブルー・グリーンデプロイ• リリースの際に、稼働中の本番と同じ構成のシステムを構築し、そちらにリリースします• リリースが完了した際に、本番の向き先をリリース済み環境に切り替えます• これは、リリースに関わるトラブルのリスク軽減が目的です• 停止時間• リリース作業の複雑さ等• 本番と同等規模の環境と、アクセス先切り替え機能（ロードバランサ等）が必要です• 特にデータベースをどう扱うかはかなり難しいと思います•

次の

今さら聞けないデプロイの基本。押さえておきたい用語や定番サービス

は、リリースにおける6つの課題をブルーグリーンデプロイメントの手法によって解決できること、そして、ユニアデックスの開発したソリューションを例に、OpenStack上に構築したブルーグリーンデプロイメントの仕組みを説明しました。 今回はこれを踏まえて、OpenStackを基板とするブルーグリーンデプロイメントの効果と、導入における課題を具体的な導入を考える管理者に向けて考察していきます。 「リリース工数の削減」と「リスク低減」の効果を考察する ブルーグリーンデプロイメントは、「リリース工数の削減」と「リスクの低減」に効果があることを説明しました。 まず、リリースにかかる時間がどれだけ削減できるかを考察してみます。 以下は、あるWebアプリケーションシステム（以下、従来システム）を想定した、リリースにおける2時間のサービス停止を伴うメンテナンスタイムテーブル例です。 従来システムのメンテナンスタイムテーブル 時刻 作業内容 備考 23:00 リリース作業開始 本番系停止 強制ログアウト処理5分 アクセス停止処置5分 バックアップ20分 22:30 本番系適用作業開始 適用作業30分 24:00 本番系適用確認テスト開始 テスト可能時間30分 24:30 切り戻し判断期限時刻 切り戻し所要時間20分 24:55 本番系サービス再開準備 アクセス開始処置5分 25:00 メンテナンスタイム終了 本番系サービス再開 リリース作業における「2時間」は、あっという間です。 上記のように個々の作業に時間を割り振っていくと、適用自体の作業に使える時間とテストに使える時間は、それぞれ30分しかありません。 この例では、バックアップとリストアの時間にそれぞれ20分を取っていますが、大きな規模のデータベースを扱うシステムならば、もっと時間が必要かもしれません。 それに対して、このシステムへブルーグリーンデプロイメントの仕組みを導入すると、こうなります。 しかもほとんど焦る必要がない、余裕のある15分です。 もっとも、ブルーグリーンデプロイメントでは設定済みの環境をあらかじめ準備しておくので、プロジェクト全体の時間は変わらないのでは？ と思う人はいるでしょう。 しかし、 作業タイミングが違うことに大きな意義があります。 まず、圧倒的に すべきことが減ります。 従来システムでは、限られた時間内に多くの工程を迅速かつ正確に実行する必要があります。 そのために、前もって入念な計画を行い、作業をこなす人員を確保して作業を並列化しなければなりません。 併せて、臨時で確保した人員については対象のシステムに関する事前教育が必要ですし、作業前のリハーサルを行うことなども考察しなければなりません。 それに対してブルーグリーンデプロイメントならば、入念な作業計画を立てる時間とリリース時の追加人員はずっと少なくて済むでしょう。 つまり、リリースにかかる時間だけではなく、工数を削減できることになります。 また、仮にプロジェクト全体の所要時間や工数には大きな差がなかったとしても、ブルーグリーンデプロイメントにはもう1つ大きなメリットがあります。 それは「 作業時間を平準化できること」です。 例えば、リリースに向けて新たな人員が必要なのに、それを確保できなかったらどうするか、原価が想定以上に掛かったらどうするか、新たな人員を確保したはいいがスキルが低かったらどうなるか、などの不確定要素も考慮する必要があります。 ブルーグリーンデプロイメントを適用すれば、そのような不安定性の影響を受けにくく、かつ、作業が集中してしまうことで生じるリスクを避けることができます。 関連記事• スピーディなビジネス展開が収益向上の鍵となっている今、システム整備にも一層のスピードと柔軟性が求められている。 こうした中、なぜOpenStackが企業の注目を集めているのか？ 今あらためてOpenStackのエキスパートに聞く。 日本OpenStackユーザ会の全面協力を得て、OpenStackを徹底的に深掘りする本特集。 第2回はレッドハット クラウドエバンジェリストの中井悦司氏が「OpenStackでできること」「OpenStackを使う上で必要なこと」を分かりやすく解説する。 最近さまざまなイベントやブログエントリで見かける「DevOps」。 この言葉をひもとき、なぜ「Dev」と「Ops」が衝突するのか、その解決に必要な要素とは何かを分かりやすく解説します。 バージョン管理や継続的インテグレーションとも密接に関わる継続的デリバリ／デプロイメントの概要や主なツール、経緯、実践事例を紹介。 実践手法として「ブルーグリーン・デプロイメント」「Immutable Infrastructure」が注目だ。 「DevOps」という言葉にもあるように、ソフトウェア構成管理は、インフラ運用に取り入れられるなど、変わりつつある時代だ。 本連載では、そのトレンドにフォーカスして、現在のソフトウェア開発に有効な構成管理のノウハウをお伝えする.

次の