Amazon Web Services ブログ

Category: DevOps

階層とタグによるパラメータの組織化及びAmazon EC2 Systems Manager パラメータ ストアのAmazon CloudWatchイベント

このポストはアマゾンウェブサービスのソフトウェア デベロッパーエンジニアであるLusha Zhang によって書かれました。   Amazon EC2 Sysmtes Mangager の一部であるパラメータストアは、平文データ(データベース文字列)または秘密情報データ(パスワード、APIキーなど)を問わず、設定データを管理するための集中化された暗号化ストアを提供します。パラメータストアはAWS CLI、API、およびSDKを介して利用できるため、AWSラムダやAmazon ECSなどのAWSサービス間でパラメータを簡単に参照できます。   パラメータストアのその他の記事については、以下を参照してください: Managing Secrets for Amazon ECS Applications Using Parameter Store and IAM Roles for Tasks Use Parameter Store to Securely Access Secrets and Config Data in AWS CodeDeploy   パラメータストアは最近、階層化サポートとパラメータのタグ付け、及びCloudWatchイベント サポートをローンチしました。これらの機能によって大規模にパラメータを組織化し、管理することが可能になりました。このポストでは、これらの新しい機能を使ってセキュリティ機能を拡張し改善する方法を示します。   階層化パラメータ パラメータストアの階層化サポートによって、組織構造に基づいたパラータの構造化が可能となります。これはパラメータの編成、クエリ、および権限管理のための強力なツールを提供します。   一般的なDevOpsのシナリオでは、開発、ベータ、本番の異なる環境に対してソフトウェアの展開を自動化します。例えば、デプロイメント設定を作成する時に、設定を保存するためにパラメータストアを利用できます。おそらく各デプロイメント環境に最低限の健全なホスト数やパーセンテージを設定しなければならず、それらを環境ごとに異なる値でパラメータストアに保存したいと思うでしょう。   Step1. デプロイメント設定のパスを作成する 次のコマンドを使用して、保存するパスとパラメータを作成します: aws ssm […]

Read More

EC2 Container ServiceのBlue/Greenデプロイメント

この投稿と付随するコードの作成には、下記3名による多大な貢献がありました。 Jeremy Cowan Solutions Architect Anuj Sharma DevOps Cloud Architect Peter Dalbhanjan Solutions Architect コンテナ化されていないトラディショナルな環境にソフトウェアアップデートを展開するのは難しく、リスクを伴います。デプロイパッケージまたはスクリプトを記述するときは、ターゲットマシンが特定の状態にあると仮定する必要があります。ステージング環境が本番環境の正確なミラーイメージでない場合、デプロイは失敗する可能性があります。デプロイが失敗すると、アプリケーションの最後の正常なバージョンを再デプロイするまでサービス停止が起きることがあります。あなたが運用管理者だとしたら、サービス停止があると夜間に起きていなければいけないでしょう。 リリース内容の審査が終わるまでユーザーに新しいバージョンをさらすことなく、本番環境でテストをおこないたいと考えているお客様が増えています。人によっては、新機能が多くの人たちに公開される前に少数の顧客に対してのみ公開し、フィードバックを集めることもあるでしょう。これは、カナリア分析またはカナリアテストと呼ばれる手法です。この記事では、Application Load Balancersとtarget groupsを使用してBlue/Greenとカナリアデプロイを実装するパターンを紹介します。 もし実際にこのアプローチを試したい場合、オープンソースのコードとAWS CloudFormationテンプレートをecs-blue-green-deployment GitHubリポジトリに公開しています。 このワークフローでは、サービスをECSクラスタにデプロイする自動化されたCI / CDパイプラインが構築され、コードの最新バージョンを本番環境に昇格する準備が整ったらターゲットグループをスワップする制御されたプロセスが提供されます。環境は3つのステップで簡単に設定でき、Blue/Greenのスワップが動作することを確認できます。ぜひ試してみてフィードバックを送ってください!   Blue/Greenの利点 Blue/Greenデプロイメントは、ソフトウェア更新を低リスクでおこなうことができるイミュータブルデプロイメントの1つのパターンです。現在の実行中の “Blue”バージョンのアプリケーションと新しい “Green”バージョンのアプリケーションを別々の環境で作成することで、リスクが軽減されます。 このデプロイメント方法では、アプリケーションの現在の実行中のバージョンに影響を与えずに、Greenの環境で機能をテストすることができます。Greenバージョンが正常に動作していることが確認できたら、DNSを変更して古いBlue環境から新しい環境にトラフィックを徐々にルーティングすることができます。この方法に従うことで、ほぼゼロダウンタイムで機能更新とロールバックをおこなうことができます。 2つの異なる環境感でトラフィックをシフトする典型的なBlue/Greenデプロイメント このように運用中のBlue環境に素早くトラフィックを戻すことできることは、Blue/Greenデプロイメントの主要メリットの1つです。Blue/Greenデプロイメントでは、デプロイメントプロセスのどのタイミングでもBlue環境にロールバックすることが可能です。ダウンタイムはGreen環境に問題があることを認識してから、Blue環境にトラフィックを切り戻すまでの時間に制限されます。さらに、停止の影響はすべてのトラフィックではなく、Green環境に振り分けられたトラフィックに限定されます。デプロイエラーの規模が縮小されると、全体的なデプロイのリスクも低下します。 コンテナでBlue/Greenをシンプルに実現する 複数環境の管理およびプロビジョニングの複雑さとコストのために、従来のオンプレミスでのソフトウェア更新にはBlue/Greenデプロイメントはあまり導入されていませんでした。代わりに、アプリケーションはin-placeでアップグレードされていました。 このアプローチは有効でしたが、障害時のロールバックの迅速性などいくつかの欠陥がありました。ロールバックには通常、以前のバージョンのアプリケーションの再デプロイメントをおこなっていましたが、再デプロイメントは良くないリリースがあった場合の停止時間を長期化させる可能性があります。 コンテナは、簡単にパッケージ化でき、環境間を移動しても一貫して動作するため、Blue/Greenデプロイメントの導入を容易にします。この一貫性のひとつの要因は、コンテナのもつ不変性です。コンテナの設定を変更するには、In-Placeでソフトウェアを更新するのではなく、Dockerfileを更新してコンテナを再構築、再デプロイする必要があります。 コンテナは、アプリケーションのプロセスと名前空間の分離も提供します。これにより、複数のバージョンのアプリケーションを同じDockerホスト上で競合することなく並行して実行できます。仮想マシンに比べてサイズが小さいため、ホストあたりにVMに比べて多くのコンテナを詰め込むことができます。これにより、コンピューティングリソースをより効率的に使用できるようになり、Blue/Greenデプロイメントのコストを削減できます。 Amazon ECSのフルマネージド更新 Amazon EC2 Container Service (ECS) は、既存のAmazon ECSサービスを更新すると、ローリングアップデートを実行します。ローリングアップデートでは、現在実行中のバージョンのコンテナを最新バージョンに置き換えます。ローリングアップデート中にAmazon ECSがサービスに追加または削除するコンテナの数は、サービスのデプロイ時に許可される健全なタスクの最小数と最大数を調整することによって制御されます。 最新バージョンのコンテナイメージを利用するようにサービスのタスク定義を更新すると、Amazon ECSによってコンテナの古いバージョンが自動的に最新バージョンに置き換えられます。デプロイメント中、Amazon ECSは現在実行中のバージョンから接続を切断し、新しいコンテナがオンラインになるとApplication Load Balancer に登録します。 Target groups […]

Read More