Tag: Amazon ECS

By: Alexandr Moroz, Sr. Product Manager, Amazon Route 53; Madhuri Peri, Sr. IoT Architect, AWS Professional Services; Aaron Molitor, Sr. Infrastructure Architect, AWS Professional Services; and Sarma Palli, Sr. DevOps Architect, AWS Professional Services AWS Cloud Mapを利用するとクラウドをマッピングすることができます。Amazon S3のバケットやAmazon DynamoDBのテーブル、Amazon SQSのキュー Amazon EC2やAmazon ECS、Amazon EKSやAWS Lambda上で構成されたカスタムクラウドサービスの様な任意のリソースに対しても分かりやすい名前を定義できます。AWS SDKと認証されたAPIクエリを使って分かりやすい名前にてリソースの場所やメタデータを検出することができます。 デプロイメントステージやバージョンの様なカスタム属性によって、リソースをさらにフィルターし、検出することができます。

AWS Fargate と Amazon Elastic Container Service (Amazon ECS) 上で稼働するサービスでの Blue/Green デプロイメントがサポートされます。 AWS CodeDeploy を利用し、 Blue/Green デプロイメントを行うことでアプリケーションの更新時のダウンタイムを最小限に抑えることが出来るようになります。 Blue/Green デプロイメントは、古いバージョンと新しいバージョンのアプリケーションを同時に起動し、新しいバージョンをテストしてからトラフィックをルーティングします。デプロイ状況を監視し、問題が発生した場合はすぐにロールバックすることも出来ます。 この新しい機能により、デプロイメント、テスト、トラフィックのカットオーバーが管理されたサービスを、AWS Fargate または Amazon ECS で作成することが出来ます。 サービスを更新すると、AWS CodeDeploy によってデプロイメントがトリガーされます。 このデプロイメントは、Amazon ECSと連携して、新しいバージョンのサービスを Green 環境用のターゲットグループにデプロイし、ロードバランサのリスナーを更新してこの新しいバージョンをテストできるようにし、ヘルスチェックが成功した場合にカットオーバーを実行します。

こんにちは。ソリューションアーキテクトの有岡です。2018年2月のAWS Black Belt オンラインセミナーの配信についてご案内をさせて頂きます。 re:invent 2017の振り返りを終え、2018年2月のBlackBeltセミナーでは、ソリューションカットとしてAWS上での位置情報と動画配信ソリューション、Amazonのコンテナサービスをご紹介します。 サービスカットでは、クラウド型仮想デスクトップサービスのAmazon Workspaces、同じくBIツールのAmazon QuickSight、AWS Lambdaをエッジロケーションで活用する方法、エンタープライズのお客様でお使いになるケースの多いAWS Organizationsなど、盛り沢山でお送りします。   2月の開催予定 ソリューションカット 2月6日(火) 12:00～13:00 AWS における位置情報 2月13日(火) 12:00～13:00 動画配信 on AWS 2月20日(火) 12:00～13:00 Amazon Container Services サービスカット 2月7日(水) 18:00～19:00 Amazon Workspaces 2月14日(水) 18:00～19:00 AWS Organizations 2月21日(水) 18:00～19:00 AWS Lambda @ Edge 2月28日(水) 18:00～19:00 Amazon QuickSight お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。Speaker、Staff 一同、みなさまのご参加をお待ちしております。    

【日本語訳】日本時間 2018年02月14日19:30 関連する CVE: CVE-2017-5715, CVE-2017-5753, CVE-2017-5754 日本時間 2018年02月06日09:30 以下は本件に関するアップデートです。 Amazon Linux 用の更新されたカーネルは、Amazon Linux のリポジトリにて入手できます。2018年1月13日以降にデフォルトの Amazon Linux 設定で起動された EC2 インスタンスには自動的に最新のパッケージが含まれています。 最新のパッケージでは、 CVE-2017-5715 に対処するための安定版オープンソース Linux セキュリティの改善がカーネル内に組み込まれています。また 以前取り込まれた CVE-2017-5754 に対処するカーネルページテーブルアイソレーション（KPTI）にもとづいて作成されています。インスタンス内の CVE-2017-5715 のプロセスープロセス間の問題と CVE-2017-5754 のプロセスーカーネル間の問題を効果的に軽減するには、最新の Amazon Linux カーネルまたは AMI にアップグレードする必要があります。詳細は「プロセッサの投機的実行 – オペレーティングシステムの更新」を参照してください。 para-virtualized（PV）インスタンスについては、以下の「PV インスタンスガイダンス」の情報を参照してください。   Amazon EC2   Amazon EC2 のすべてのインスタンスは、CVE-2017-5715、CVE-2017-5753、および CVE-2017-5754 に記載されたインスタンス間の既知の問題すべてから保護されています。インスタンス間での問題は、インスタンスまたは AWS ハイパーバイザーのメモリを近隣の別のインスタンスから読み取ることができると想定しています。この問題は AWS ハイパーバイザーでは解決されており、インスタンスは別のインスタンスのメモリを読み取ることも、AWS ハイパーバイザーのメモリを読み取ることもできません。 […]

この記事はAWS Senior Technical EvangelistのAbby Fullerの投稿です。 2017年12月12日に、AWSはAWS CodePipelineのターゲットとしてAmazon Elastic Container Service (ECS)をAWS Fargateも含めてサポートしたことをアナウンスしました。このサポートにより、コンテナベースのアプリケーションやマイクロサービスを継続的デリバリするパイプラインを作成するのがより簡単になりました。 コンテナ化したサービスを手動で構築しデプロイするのは、時間がかかりますしエラーを起こしがちです。自動化されたビルドとテスト機構と組み合わせた継続的デリバリは、早期にエラーを発見し時間を短縮することを助け、失敗を減らしてくれるので、アプリケーションのデプロイモデルとして一般的なものとなってきています。以前は、ECSでコンテナワークフローを自動化するには、AWS CloudFormationを使った自前のソリューションを構築する必要がありました。これからは、わずか数ステップでCodePipelineとCodeBuildをECSと連携させてワークフローを自動かすることができます。 CodePipeline、CodeBuild、そしてECSを使った典型的な継続的デリバリのワークフローは、以下のようなものです: ソースを選択する プロジェクトをビルドする コードをデプロイする GitHub上にこのワークフローのための継続的デプロイのリファレンスアーキテクチャも公開しています。 はじめてみよう 最初に、CodePipelineで新規プロジェクトを作成し、例として”demo”というプロジェクト名を設定します。 次に、コードが保管されているソースの場所を選択します。ここには、AWS CodeCommit、GitHub、またはAmazon S3が選択できます。この例では、GitHubを入力し、CodePipelineにレポジトリへのアクセス権を与えます。 次に、ビルドステップを追加します。JenkinsサーバURLやCodeBuildプロジェクトの様に既存のビルドを持ってくることもできますし、CodeBuildで新しいステップを作成することもできます。もし既存のCodeBuildのプロジェクトがなければ、以下の様に選択してCodePipelineから新しいものを作成しましょう: Build provider: AWS CodeBuild Configure your project: Create a new build project Environment image: Use an image managed by AWS CodeBuild Operating system: Ubuntu Runtime: Docker Version: aws/codebuild/docker:1.12.1 Build specification: […]

Amazon Web Services (AWS) が提供しているAmazon Linuxに新世代のAmazon Linux 2がリリースされました。他のサービスがそうであるようにAmazon Linux 2ではお客様からいただいた多くのフィードバックを元に作成されています。この新しいAmazon Linuxの特長をみていきましょう。 LTS（Long Term Support)の提供 これまでのAmazon Linuxはローリングアップグレードで定期的に新しいバージョンのパッケージが提供され続けることにより、常に最新の状態を維持できる環境として提供されていました。Amazon Linux 2でもこれは変わりませんが、加えてLTS (Long Term Support: 長期サポート）を提供する予定です。LTSでは５年間に渡りコアオペレーティングシステムにセキュリティパッチとバグフィックスを提供し続け、その間のユーザ空間のABI(Application Binary Interface)とAPI(Application Programming Interface)の互換性を維持します。互換性を維持しつつ安全なLinux環境を提供するのが目的であり、新しい環境に更新されることより互換性のある環境を長期に渡って使い続けることの方を望むお客様からのリクエストに応えるものです。 またコアオペレーティングシステムには無い、もしくは新しいバージョンのパッケージについてはAmazon Linux Extrasリポジトリから入手可能です。詳しくはamazon-linux-extrasコマンドのマニュアルを御確認ください。 LTSビルドは現在リリース候補（Release candidate）の状態として提供されており、評価を開始いただける状態です。 オンプレミス環境でのテストや開発が容易に Amazon Linux はAmazon EC2やAmazon ECS (コンテナ環境)上で容易に利用いただけるディストリビューションですが、Amazon Linux 2ではこれらに加えて、VMware、Microsoft Hyper-V、Oracle VM VirtualBoxの仮想イメージを提供します。これによりオンプレミス環境でのテストや開発が容易になります。Amazon Linux 2を稼働させるには最小で512MBのメモリが必要です。 新しい環境とセキュリティの強化 Kernel 4.9やSystemdのサポート等、OS環境全体が刷新されています。またセキュリティ面でも必須パッケージを厳選することによりリスクを減らし、重要度が高いセキュリティパッチについてはOS起動時に自動的に適用する等、高いセキュリティレベルを保つための仕組みが組み込まれています。 今からご利用いただけます！ 全ての商用リージョンでAMIが選択可能になっていますので、ぜひ御利用ください。HVMをサポートする全てのインスタンスタイプで御利用いただけます。Amazon LinuxをEC2上で利用する上で追加の費用は不要です（通常のAmazon EC2費用で利用可能）。DockerリポジトリにもAmazon Linux 2のベースイメージが準備済です。またフォーラムでは新しい告知に加えてみなさまからの利用のフィードバックをお待ちしております。   […]

この記事はECSのSr. Software Dev EngineerのAnirudh Aithalの寄稿です。 2017年11月14日に、AWSはコンテナにElastic Network InterfaceをアタッチできるようにするAmazon ECSのTask Networkingを発表しました。 この記事では、ECSが管理するインスタンス(コンテナインスタンスと呼ばれます)上でContainer Networking Interfaceプラグインを使って、この新しいコンテナネイティブなawsvpcネットワークモードがどのように実装されているかを詳しくご紹介したいと思います。 こちらはAmazon ECSでタスクネットワークが動作するかにdeep diveしたものです。もし自身のコンテナ化したアプリケーションでどうやってタスクネットワークを使い始めれば良いかについて学びたい時には、Amazon ECSコンテナにCloud Native Networkingが登場をご覧下さい。Cloud Native Computing Foundation (CNCF)がContainer Networking Interface (CNI)プロジェクトをホストしており、Linuxコンテナでネットワークインターフェースを設定するためのプラグインを書くための仕様やライブラリが含まれています。AWSのクラウドネイティブコンピューティングについての詳細は、Adrian CockcroftのCloud Native Computingについての投稿をご覧下さい。 コンテナインスタンスのセットアップ コンテナインスタンス上でのタスクネットワーク有効化の詳細をご説明する前に、ECSの典型的なインスタンスがどのようになっているかを見てみましょう。 上の図は典型的なコンテナインスタンスを示しています。ECS agentは自身もコンテナとして実行されているのですが、以下のような責任を負っています: EC2インスタンスをECSのバックエンドに登録 コンテナインスタンスに対してECSバックエンドが発生させたタスク状態の変化を、正しく適応 Dockerデーモンと会話しながら、コンテナの作成、開始、停止、監視 コンテナの状態とタスクの状態の遷移をECSバックエンドにリレー ECS agentはその管理下のコンテナのスーパーバイザーの様に動作するので、Dockerデーモン(Dockerのデフォルトネットワークモードで設定されたコンテナ用)、又はCNIプラグイン達(ネットワークモードがawsvpcで設定されたタスク内のコンテナ)のための、ネットワーク設定をする難しさをオフロードしてくれます。 いずれの場合にも、コンテナのネットワークスタックは、ネットワークのnamespaceを通じて設定されます。ip-netns(8)のマニュアルによると「ネットワークnamespaceは論理的なネットワークスタックのコピーで、自身のルーティング、ファイアウォールルール、ネットワークデバイスを持っています。」 とあります。ネットワークnamespaceの構成によって、ホスト上で動いているプロセスやコンテナ間でのネットワークスタックの隔離を可能としてくれます。 ネットワークnamespaceとCNIプラグイン CNIプラグインとは、CNI仕様を満たしコンテナのネットワーク接続性の設定を行う実行ファイル群です。CNIプロジェクトではプラグインの仕様を定義し、プラグインが利用するライブラリを提供することで、一貫していて信頼でき、かつ簡素なプラグイン用のインタフェースを提供してくれます。 コンテナやネットワークnamespaceを指定してプラグインを呼び出す時に、ADDコマンドでコンテナにネットワークインターフェースを追加したり、DELコマンドでそれを落としたりします。例えばリファレンスのBridgeプラグインは、ホストネットワークnamespaceの中にいるブリッジに対してホスト上の全てのコンテナを追加します。 このプラグインのモデルはECS agentの「コンテナのライフサイクルへの最小限の介入」というモデルと相性が良く、agentはコンテナのネットワーク設定の詳細について考慮する必要がなくなります。また拡張性の高いモデルなので、将来必要になった時には、agentが異なるプラグイン群を利用できるようにスイッチさせることもできます。最後に、これらプラグインは必要な時に呼び出されるだけなので、その死活監視をECS agentがする必要はありません。 ECS agentからCNIプラグインを呼び出す ECSがElastic Network Interfaceをインスタンスにアタッチし、agentに対しそのElastic Network Interfaceをタスク内のコンテナに対してプロビジョンするようにメッセージを送った時には、(任意のネットワークデバイスを使う) そのElastic […]

この記事はECSのSr. Software Dev EngineerのAnirudh Aithalの寄稿です。 2017年11月14日に、AWSはAmazon ECSのTask Networkingを発表しました。これによって、Elastic Network Interfaceを使ったAmazon EC2のネットワーク機能をタスクに持ち込むことができるようになります。 Elastic Network InterfaceはVPC内のインスタンスにアタッチすることができる仮想的なネットワークインタフェースです。EC2の仮想マシンを起動する時には、インスタンスにネットワークの機能を提供するために自動的に1つのElastic Network Interfaceがプロビジョンされます。 タスクは実行されるコンテナの論理的なグループです。これまでは、Amazon ECSで実行されるタスクはそれが動くEC2ホストのElastic Network Interfaceを共有していました。これからは、新しいawsvpcというネットワークモードを使うことで、Elastic Network Interfaceが直接タスクにアタッチされます。 これによってネットワークの設定を簡略化することができ、VPCが持っているネットワークの全機能、隔離性、そしてセキュリティの制御を各コンテナにEC2インスタンスと同様のレベルで利用することができます。 この記事では、awsvpcモードがどのように動作し、ECSのタスクでどのようにElastic Network Interfaceを使い始めることができるかをご紹介します。 背景: EC2のElastic Network Interface VPC内にEC2インスタンスを起動する時には、各インスタンスが互いに通信できるようにするために、追加のオーバーレイネットワークを設定する必要はありません。標準で、VPCのルーティングテーブルがインスタンスや他のエンドポイント間での通信をシームレスに実現してくれます。これは、Elastic Network Interfaceと呼ばれるVPC内の仮想的なネットワーク・インタフェースによって可能となっています。全ての起動されるEC2インスタンスは自動的に1つのElastic Network Interface(プライマリネットワークインタフェース)がアサインされます。サブネット、セキュリティグループといった全てのネットワークパラメータは、このプライマリネットワークインタフェースの属性として扱われます。 さらに、各Elastic Network Interfaceは作成時にVPCによってIPv4アドレス(プライマリIPv4アドレス)が割当られます。このプライマリアドレスはユニークでVPC内でルーティング可能なものです。これによって、VPCは実際はフラットなネットワークとなり、ネットワークトポロジを簡潔なものとしてくれます。 Elastic Network InterfaceはVPC上で多様なエンドポイントとの接続を実現するための基本的なビルディングブロックとみなすことができ、そのうえでより高レベルな抽象レイヤを構築することができます。これによってElastic Network Interfacdeは以下の機能を利用することが可能となっています: VPCネイティブなIPv4アドレスとルーティング (VPC上でのインスタンス間や他のエンドポイントとの間) ネットワークトラフィックの隔離 ACLとファイアウォールルール(セキュリティグループ)を使ったネットワークポリシーの強制 (サブネットのCIDRを通じた)IPv4アドレスレンジの強制 なぜawsvpcを使うのか？ 以前はECSはDockerが提供する標準のネットワークの挙動が提供するネットワーク機能に依存した形でコンテナ向けのネットワークスタックを構成していました。デフォルトのBridgeネットワークモードでは、インスタンス上のコンテナ達はdocker0ブリッジを使って互いにつながっています。インスタンス外のエンドポイントと通信する時には、コンテナはこのブリッジを利用し、それが実行されているインスタンスのプライマリネットワークインタフェースを使います。コンテナは、ファイアウォールルール(セキュリティグループ)やIPアドレスは、そのプライマリElastic Network Interfaceのネットワーク属性を共有しまた依存しています。 これは、Dockerによって割当られたIPアドレス(ローカルスコープのアドレスプールから割当られます)を使ってもこれらのコンテナに到達できないことと、細かいNetwork ACLやファイアウォールルールを強制できないことを意味します。代わりに、VPCからはインスタンスのプライマリElastic Network […]

SA岩永です。AWS上にシステムを構築する際に、アプリケーションのデプロイをどのように行うか？については多様なやり方が考えられますが、今日はを使ったデプロイをご紹介したいと思います。CloudFormationはインフラ構築のツールとして考えられている方も多いと思いますが、最近は特にやといったComputeサービスへのアプリケーションデプロイツールとしての活用が進んでいます。AWSのリソースはやSDK等での操作が可能なので自作のツール等を使われるのはもちろん1つの選択肢ですが、もしCloudFormationを検討されたことのない方は、ぜひこの投稿を参考にして頂けるとありがたいです。 デプロイツールとしてのCloudFormationのメリット 最初に結論をまとめておきます。CloudFormationを使ったデプロイには以下の様なメリットがあります。 デプロイツール自体のインストールが不要、YAML/JSONを書くだけ、ブラウザからでもデプロイ可能 宣言的にデプロイが定義・実行できる アプリケーションに関連する他のAWSリソースも合わせて管理可能 現在お使いのデプロイツールで、逆に上記の様な観点で困ったことのある方は、この投稿をじっくり読んで頂くと良いと思います。 デプロイツール自体のインストールが不要、YAML/JSONを書くだけ、ブラウザからでもデプロイ可能 例えばCLIで行う様なデプロイツールの場合、そのツール自体のインストール等が必要になりますが、CloudFormationであればブラウザからテンプレートを指定するだけでデプロイできます。CloudFormationの一番のメリットはここです。アプリケーションの構成を記述したYAML or JSONのテンプレートファイルを用意するだけで、すぐにデプロイが可能です。 CloudFormationも実態はAWSのAPIを実行しながらリソースを作成・更新しますが、CloudFormationの場合にはAPIの実行そのものをCloudFormationのサービス側でやってくれます。例えばECSのデプロイで新しいTask Definitionを作成した後でそれを指定してServiceを更新するという依存関係のある2回のAPI操作を順番に実行する必要がありますが、CloudFormationに1回命令を送るだけで後のAPI操作はCloudFormationのサービスが代わりにやってくれます。なので、デプロイが終わるまで実行プロセスが待っている必要もないですし、複数人の排他的実行も実現できますし、さらに現在の状態と過去の履歴というデータの保存までもやってくれます。 もちろん、CloudFormation自体もAWSのサービスなので、CLI/SDKでの操作は可能です。もしもデプロイをCLIで実行して終わるまで待ちたい、ということであれば、aws cloudformation deployというコマンドを使うと更新が終わるまでポーリングしながら待ってくれます。この場合に必要なものはAWS CLIのインストールのみなので、そこまでハードルの高いものではありません。 宣言的にデプロイが定義・実行できる AWSのAPIを利用しながらデプロイツールを自作する場合には、リソースの作成順序に気を払いながら、かつ途中で失敗した場合のエラーハンドリング等も考慮しつつ手続き的に実装する必要があります。これはシンプルな構成であればそこまで難しくはないのですが、対応したい機能が徐々に増えてくるとだんだんと実装が複雑化してきてしまいます。 CloudFormationで使うテンプレートは、手続きを記述するのではなく、希望する状態を宣言的に定義するものです。そのため、複雑な構成であっても簡潔さを保って記述することができますし、多くのケースで各リソース間の依存関係も自動で判断されるので、実行順序を考えて記述する必要もありません。もちろん、テンプレートにはパラメータを設定することも可能なので、例えばECSであれば新しく作成したコンテナイメージ名をパラメータにしておくと、デプロイはそのパラメータを更新するだけで済みます。 アプリケーションに関連する他のAWSリソースも合わせて管理可能 ECSやLambdaは、それ単体だけで利用するケースよりも、他のAWSのサービスも合わせて利用されることが多いと思います。例えば、のRoleは良く使われますし、データベースとしてを使ったり、ECSのコンテナへの負荷分散にを使うことは非常に多く、場合によってはアプリケーションのデプロイ時にそれらのリソースの更新も行いたいケースもあります。 CloudFormationでは他のリソースも合わせて定義して操作させられるので、そういったケースに非常に強力なツールとなります。アプリケーションと同じテンプレートで作成することもできますし、昨年リリースされたCross Stack Referenceという機能を使うと、先に作成しておいたリソースをアプリケーション側から参照するといった使い方もできます。 CloudFormationを使ったECSのデプロイ例 こちらは、ECSへの継続的デプロイメントについて紹介した以下のブログをご参照頂くのが良いです。 AWS CodePipeline, AWS CodeBuild, Amazon ECR, AWS CloudFormationを利用したAmazon ECSへの継続的デプロイメント ブログで紹介されている構成では、GitHubへのコードのpushをトリガーにして、イメージのビルドからECSのServiceの更新まで一貫したものを紹介していますが、Service更新部分はCloudFormationテンプレートを使って実施しています。また、がデプロイ方式としてCloudFormationに対応しているので、簡単に設定することが可能です。 参考のために、Task DefinitionとServiceとIAM Roleを定義するYAMLテンプレート例を貼り付けておきます。 https://github.com/awslabs/ecs-refarch-continuous-deployment/blob/master/templates/service.yaml Resources: ECSServiceRole: Type: AWS::IAM::Role Properties: Path: / AssumeRolePolicyDocument: | { “Statement”: [{ “Effect”: “Allow”, […]

この投稿と付随するコードの作成には、下記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デプロイメントは、ソフトウェア更新を低リスクでおこなうことができるイミュータブルデプロイメントの１つのパターンです。現在の実行中の “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 […]