マイクロサービスCI/CDハンズオン · •Dockerの組み込み仮想ネットワークを使用して外部ネットワークと通信(コンテナリンク利用可) •hostモード

© 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

Amazon Web Services Japan K.K.

Amazon ECS

マイクロサービスCI/CDハンズオンAWS DevDay Tokyo 2019 Day2 16:00-17:45


確認

本ワークショップでは

実際にECSを体験していただくためAWSアカウントが必要です


Agenda

• 概要• コンテナ、ECS、CI/CD

• ハンズオン環境作成• VPC及びサブネットの作成

• ECS環境のセットアップ

• AWS Cloud9の構築

• ECSマイクロサービスハンズオン

• ECS CI/CDハンズオン（Blue/Green）


概要


コンテナとは?

「リソースが隔離されたプロセス」• 1つのOS上で複数同時稼働可能なプロセスの実行環境を提供するもの• 各々で独立したルートファイルシステム、CPU・メモリ、プロセス空間等を利用可能

Bins/Libs

App2

Process

Infrastructure

Operating System

Container Engine

Infrastructure

Hypervisor

Guest OS

Bins/Libs

App2

Guest OS

Bins/Libs

App1

VM VM

App1

Bins/Libs

Process

コンテナ仮想マシン


◼リソース効率✓ オーバーヘッドが少ない✓ 粒度を細かく利用率の向上が可能

◼スピード✓ 起動が非常に高速

◼柔軟性✓ 削除や再生成が非常に簡単

◼可搬性✓ 不変な「コンテナイメージ」✓ 「アプリケーションビルド」への組み込みが容易

コンテナの特徴とメリット

Bins/Libs

App2

Process

Infrastructure

Operating System

Container Engine

App1

Bins/Libs

Process

コンテナ


お客様がコンテナを選ばれる理由

◼ビジネス課題の解決

✓ アプリケーションを止めないための仕組み作り✓ 可用性・耐障害性✓ スケーラビリティ

✓ より高速・高頻度なデリバリー✓ CI/CD

✓ マイクロサービスアーキテクチャ✓ より高いリソース効率

✓ 非同期処理(バッチコンピューティング)

✓ SpotFleetとの親和性


AWSのコンテナ関連サービス

コントロールプレーン（オーケストレーション）デプロイ、スケジューリング、スケーリング、クラスタ管理

データプレーン（コンテナ実行基盤）コンテナ実行

イメージレジストリコンテナイメージのリポジトリ

EC2

Container

Registry

Elastic

Container

Service

Elastic

Kubernetes

Service

EC2

(Elastic

Compute

Cloud)

Fargate


イメージレジストリ：ECR

• セキュア(IAM連携、クロスアカウントアクセス、保管イメージの自動的な暗号化)

• スケーラブルかつ高い可用性

• ECS/EKS/Kubernetes等から利用可能

• ライフサイクルポリシーにより、イメージの自動クリーンアップが可能(「タグなしイメージはpush登録からn日経過したものは削除」や「n個以上は削除」といったルールを複数定義可能)コンテナイメージ(群)

◼フルマネージドなコンテナイメージレジストリ


グローバル展開

強力なスケジュールエンジン

オートスケーリング

CloudWatch 連携(ログ/メトリクス/イベント)

ロードバランサ

オーケストレーション：ECS

コンテナレベルのネットワーク構成

高度なタスク配置戦略

他のAWSサービスとの連携

ECS CLI…{ }Linux & Windows

◼コントロールプレーンとしての基盤


Task

ECSの動作イメージ

スケジューリングとオーケストレーション

クラスター管理 / 配置エンジン / エージェント通信サービス

OSDocker engine

ecs-agent

EC2インスタンス EC2インスタンス EC2インスタンス

OSDocker engine

ecs-agent OSDocker engine

ecs-agent

Task

Task

Task

Task

クラスター

Task


ECSの主要な構成要素

Taskはアプリケーションの一部または全部を構成する1つ以上のコンテナから成る実行単位。TaskはTask Definitionの定義を元に開始される。

Task Definition

& Task

Container Instance

Task (コンテナ群) が実際に起動するEC2インスタンス。

Cluster TaskまたはServiceを実行する論理的なグループ。複数のContainer Instanceで構成される。

Service Task DefinitionとClusterを結びつけてTaskを実行し、その数を希望数に維持する。


Service

• Task実行コピー数(n個)を定義

• 起動後、Task実行コピー数を維持

• ELBと連携

• 起動タイプ(後述)を設定

Task Definition, Task, Service, Clusterの関係

Taskを構成するコンテナ群定義：

• コンテナ定義(イメージ場所等)

• 要求CPU & メモリ

• Taskに割当てるIAMロール

• ネットワークモード(後述)etc...

Task DefinitionTask

• Task Definitionに基づき起動されるコンテナ群

• Task内コンテナは同一ホスト上で実行される

参照

Docker

イメージ

Docker

イメージ

参照

Cluster

• 実行環境の境界

• IAM権限の境界(クラスターに対する操作)

• スケジュールされたタスクの実行を設定可能


Task Definition : コンテナ(群)の実行単位定義

タスクとしてのまとまりを所定のJSON書式で定義したもの

• 例：Front-endサービス、Back-endサービス、…

• familyとrevision(1から始まる数)で特定

Taskは直接 or Serviceによって、Task Definition定義から起動される• 1つ以上のコンテナを実行するリソース

• Task内のコンテナ群は必ず同じホスト上で実行

• 1つのTask Definitionは最大10コンテナ指定可能

CPUとメモリの要求量を指定する• それを元にECSが実行ホストをスケジュール

{

"family": “scorekeep",

"containerDefinitions": [

{

"name":“scorekeep-frontend",

"image":"xxx.dkr.ecr.us-east-1.amazonaws.com/fe"

},

{

"name":“scorekeep-api",

"image":"xxx.dkr.ecr.us-east-1.amazonaws.com/api"

}

]

}

Task Definition … scorekeep:10

scorekeep-frontend scorekeep-api

実行 Task


Task Definition : CPUとメモリ定義

{

"family": "scorekeep",

"cpu": 1024,

"memory": 2048,

"containerDefinitions": [

{

"name":“scorekeep-frontend",

"image":"xxx.dkr.ecr.us-east-1.amazonaws.com/fe“,

"cpu": 256,

"memory": 768,

"memoryReservation": 512

},

{

"name":“scorekeep-api",

"image":"xxx.dkr.ecr.us-east-1.amazonaws.com/api",

"cpu": 768,

"memoryReservation": 512

}

]

}

Taskレベルリソース指定

コンテナレベルリソース指定

Task Definitionの抜粋Taskの要求リソース量を指定

• CPU: cpu-unit数を指定

• 1 vCPU = 1,024 cpu-units

• メモリ: MiB単位で指定

“Taskレベルリソース”

• 全コンテナの合計CPU/メモリ

“コンテナレベルリソース”

• コンテナ間でTaskリソースの分配を定義(オプション指定)


Task Definition : タスクのIAMロール設定

IAMロールをTask Definition毎に設定可能

AWS SDKを利用していれば自動的に認証情報が得られる

アクセス鍵等の埋め込み不要

タスクがアクセスできるAWSリソースを制御できる

DynamoDBRole

S3Role


Task Definition : ネットワークモード

• noneモード

• 外部と接続しない

• bridgeモード (EC2タイプのデフォルト)

• Dockerの組み込み仮想ネットワークを使用して外部ネットワークと通信(コンテナリンク利用可)

• hostモード

• Dockerの組み込み仮想ネットワークをバイパスし、コンテナポートがホストEC2インスタンスのNICに直接マッピング

• awsvpcモード

• ECS管理下のENIがタスクにアタッチされる

• セキュリティグループをENIに設定できる

• FARGATEタイプでTaskを起動する場合の前提

EC2インスタンス

Task Definitionの抜粋{

"family": "scorekeep",

...

"networkMode": "(左記4つのいずれか)",

...

}

コンテナネットワーク動作を設定

ENI(awsvpc時)

Task

80nnnn

2222


Service : 長時間実行アプリ用スケジューラー

Service

app:1

app:2

ElasticLoad Balancing

desiredCount: 2maximumPercent: 200minimumHealthyPercent: 100launchType : EC2

ApplicationAuto Scaling

Taskの起動と実行に関連する設定を所定のJSON書式で定義したもの

• 参照先のTask Definitionを指定

• 参照先のClusterを指定

• Task Definitionを新しくするとローリングアップデート

• ELBとの連携設定が可能

• メトリクスに応じた起動するTask数のAutoScalingや、起動場所の条件付けなどが可能

Task Definition(<familyName>:<revision>)

Cluster


EC2をコンテナインスタンスとして用いる時の悩み

• 脆弱性対応のためのパッチ当てやOS アップグレード

• EC2 インスタンス内で動くエージェント類のアップグレード

• 状態異常が発生した EC2 インスタンスの再起動や入れ替え

• インスタンスレベルのスケーリング管理

OSDocker agent

ecs-agent

EC2 インスタンス


アプリケーションの開発と運用に集中したい

• アプリを開発してデプロイ• コンテナのAuto Scaleを設定• コンテナのセキュリティ管理

• OSのプロビジョン• OSのセキュリティ管理• EC2インスタンスのAuto Scale

開発者


実行基盤：Fargate

• EC2 インスタンスの管理なしにコンテナを実行可能

• タスクレベルでのスケーリング

• 使用リソースに対しての秒単位料金

• 各種 AWS サービスとの連携

• SLA 99.99 % (ECSと同じ)

=インスタンス管理不要

タスクネイティブAPI

リソースベース価格

簡素で、使いやすく、強力な新しいリソース消費モデル

(※EC2ベースと共存可能)


Fargateの動作イメージ

スケジューリングとオーケストレーション

クラスター管理 / 配置エンジン / エージェント通信サービス

OSDocker agent

ecs-agent

EC2 Instance EC2 Instance EC2 Instance

OSDocker agent

ecs-agent OSDocker agent

ecs-agent


Fargate :従来のECS(EC2型)との主な違い

Service定義として

• 起動タイプに"FARGATE"を指定(従来型は"EC2")

• 選択可能なネットワークモードは"awsvpc"のみ

• 結果としてタスク毎にENIが利用

• それに伴うメリットや考慮点あり

• CPU やメモリの指定方法が“EC2”型と異なる

• ストレージボリュームの扱い

• 実際にTaskを起動していたvCPUとMemoryに対する秒単位の計算

• ストレージ料金は不要

• データ転送料は標準

• その他に利用するサービスは追加料金が発生

• 例: CloudWatch Logs

利用料金について


Fargate : タスク割り当てCPUとメモリ設定

柔軟な設定の選択肢

50 パターンのCPU/メモリの組み合わせから選択

CPU Memory

256 (0.25 vCPU) 0.5GB, 1GB, 2GB → 3種類

512 (0.5 vCPU) 1GB to 4GB (1GB 刻み) → 4種類

1024 (1 vCPU) 2GB to 8GB (1GB 刻み) → 7種類



1 vCPU/時 = $0.05056

1 GB Mem/時 = $0.00533

https://aws.amazon.com/jp/fargate/pricing/

(※東京リージョン、2019/06/02現在)

https://aws.amazon.com/jp/fargate/pricing/


アプリケーション開発者からみたコンテナ活用

◼必要なこと

✓ コンテナを前提としたアプリケーション設計• アプリのステートレス化

• 設定情報の取得方法

• ログ出力…

✓ アプリケーションとコンテナのビルド環境整備• イメージレジストリ

• CI/CDパイプラインへのイメージビルドの組み込み


コンテナを前提としたアプリケーション設計

The Twelve-factor App ( https://12factor.net/ja/ ) に代表される設計パターン

• 例：設定を環境変数に格納する→ Systems Managerパラメータストア連携機能を利用しよりセキュアに

• 例：コンテナ化するアプリはステートレスで動作するように→コンテナのメリットを最大限活かせる

• 例：永続化が必要なデータはコンテナ外に(バックエンドサービス)→ RDBMSが必要…Amazon RDS、オブジェクトデータ保存…Amazon S3

• 例：ログをファイルで扱わずにストリームとして扱う→アプリケーションログはファイルでなく標準出力/標準エラー出力に→その上で awslogsログドライバーを利用し、CloudWatch Logsへ転送

https://12factor.net/ja/


CI/CDパイプラインへの取り込み

「アプリのコード変更〜コンテナのデプロイ」を管理する自動化することで誰がやっても同じようにデプロイ可能

ビルドはもちろん、単体テストや統合テスト、負荷テストも

カナリアデプロイやリージョンデプロイなども

途中にマニュアルでの承認を挟むこともしたい

→ AWS CodePipeline / AWS CodeBuild

コントロールプレーンの差異を吸収する役割を担うことも例: コンテナをビルド→AWSはECS/Fargate, オンプレはKubernetes


なぜCI/CDパイプラインが重要なのか？

• 誰がやっても同じ様にデプロイできること

• イメージがどうやって作られどこで使われるかを明確化

• アプリ毎に統一された手法を利用

しかし、CI/CDパイプラインの実装やその基盤構築自体は、典型的な“差別化を産まない重労働”

→ AWS CodeCommit / CodeBuild / CodePipeline


AWS CodeCommit

フルネージドなGitリポジトリのサービス

Gitリポジトリの利用ユーザー=IAMユーザーとして、AWS IAMの仕組みと一体化したセキュリティを実現

フック/トリガーでSNS・Lambdaと連携可能

ユースケースIAMポリシー設定やPrivateLinkを利用したセキュアな

Gitリポジトリへのアクセスが必要な場面等


AWS CodeBuild

マネージドなビルド環境

アプリのビルドやテスト等が主な目的

ビルド環境自体もDocker

各種言語対応の環境

Dockerイメージのビルドも可能

CodePipelineと連携

(単体でも利用可能)

version: 0.2

phases:pre_build:commands:- $(aws ecr get-login --region $AWS_DEFAULT_REGION --no-include-email)- REPOSITORY_URI=0123456789.dkr.ecr.us-east-1.amazonaws.com/fargate-demo- IMAGE_TAG=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7)

build:commands:- docker build -t $REPOSITORY_URI:latest .- docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG

post_build:commands:- docker push $REPOSITORY_URI:latest- docker push $REPOSITORY_URI:$IMAGE_TAG- printf '[{"name":"app","imageUri":"%s"}]' $REPOSITORY_URI:$IMAGE_TAG > imageDefinition.json

artifacts: files: imageDefinition.json

buildspec.yaml


AWS CodePipeline

CI/CDパイプラインのフルマネージドサービス

Source, Build, Test, Deployを柔軟に組合せ並列実行や、手動承認も設定可能

Deploy TargetにECS Serviceを指定可能

ユースケーステスト環境にデプロイ後、各種テスト実行

カナリア、リージョンデプロイ


AWSCodePipeline

AWSCodeCommit

AWSCodeBuild ELB (Application

Load Balancer)

Service

パイプライン確認、手動承認

ソースコードのチェックイン

ビルド済イメージの確認

デプロイ後の状態確認

registerTaskDefinition & updateService

docker build & push

S3への成果物(artifact)

ソースコード

AmazonECS

AmazonECR

AWS Fargate

Developer


ハンズオン


これから作るもの


ハンズオン環境作成

VPC及びサブネットの作成

パブリックサブネット-1a10.0.0.0/24

パブリックサブネット-1c10.0.1.0/24

インターネットゲートウェイ

VPC: 10.0.0.0/16

アベイラビリティーゾーン 1c

アベイラビリティーゾーン 1a

VPC の作成

パブリックサブネット-1d10.0.2.0/24

アベイラビリティーゾーン 1d


AWSマネージメントコンソールにログインする

[ホームに戻る] ボタン

AWSの各サービス

AWSサービスの検索ボックス

リージョン

アカウント情報

言語


CloudFormation を開く

2. [サービス] をクリック

3. [CloudFormation] をクリック

1. [東京]リージョンになっていること確認


スタックの作成

[スタックの作成]をクリック


テンプレートを利用する

[Amazon S3 URL] に以下URLを入力して、次へ

https://fnpub.s3-ap-northeast-1.amazonaws.com/step1_vpc.yaml


スタックの詳細を指定し作成する

2. 任意のユーザー名を入力

１.任意のスタック名を入力

[HandsOnName-UserName-vpc] が作成されるので既に同名のVPCが存在している場合、パラメータを調整して同名にならないよう気をつける

3. [次へ] を選択しこの後の画面でも同様に[次へ]を選択最後の画面で[スタックの作成]を選択した後、スタックのステータスが[CREATE_COMPLETE]になるのを確認する


サブネットの確認

[サービス] から [VPC]を選択左のナビゲーションから[サブネット]を選択し３つのサブネットが作成されている事を確認

パブリックサブネット-1a10.0.0.0/24

パブリックサブネット-1c10.0.1.0/24

インターネットゲートウェイ

VPC: 10.0.0.0/16

アベイラビリティーゾーン 1c

アベイラビリティーゾーン 1a

ここまでに作成した構成

パブリックサブネット-1d10.0.2.0/24

アベイラビリティーゾーン 1d


ECS環境セットアップ（補足）

ALB, ECS Cluster, Cloud9の環境をセットアップをしていきますが

これまで作成経験があり、今回のハンズオンではスキップしたい方は

以下CloudFormationのテンプレートをご利用ください。

https://fnpub.s3-ap-northeast-1.amazonaws.com/step2_setup.yaml

尚、スタック完了後の続きは「マイクロサービスハンズオン」からとなります。



ECS環境のセットアップ


ALB用セキュリティグループ作成(1)

セキュリティグループ名に “｛ユーザ名｝-handson-alb-sg”と入力説明にも “｛ユーザ名｝-handson-alb-sg”と入力しVPCはハンズオンで自分で作成したものを選択して[作成]をクリック


ALB用セキュリティグループ作成(2)

作成したALB用SGを選択

HTTPとカスタムTCPルール(9000)を任意の場所(0.0.0.0/0)に開放


ALB(Application Load Balancer)作成

Application Load Balancerを選択

Services -> EC2 へ


基本設定

[インターネット向け] を選択

handsonで作成したvpcを選択

ALBの名称は{ユーザ名}-ecs-albを入力

サブネットにはVPC作成時に作成したパブリックサブネット3つを設定


セキュリティ設定(スキップ)


セキュリティグループ設定

先程作成したALB用のSGとdefaultのSGをどちらもチェック


ルーティング設定(スキップ)

適当な名前を指定（このターゲットグループはあとの手順で削除します）


ターゲットレジスター(スキップ)


ALB作成

アプリケーションのエンドポイントとなるDNS名をメモしておく


リスナー削除リスナーおよびターゲットはECSサービス構成時に再度作成しますので、ALB作成時に自動構成されたものは削除します


ターゲットグループ削除リスナーおよびターゲットはECSサービス構成時に再度作成しますので、ALB作成時に自動構成されたものは削除します


Fargateクラスター作成(1)Services -> ECS へ


Fargateクラスター作成(2)

クラスター名を指定({ユーザ名}-fargate-cluster)


Fargateクラスターの確認



AWS Cloud9の構築


AWS Cloud9環境の構築

AWSサービス検索で”cloud9”と入力し、候補からCloud9を選択

AWSマネジメントコンソールのメニューに移動



Cloud9のコンソールで[Create environment]をクリック

初めてのCloud9環境を構

築する場合は、このような画面が表示される



Environment Nameに “｛ユーザ名｝-handson-env”と入力し[Next step]をクリック



※ docker build 時などでメモリが不足することがあるので、Other Instance typeから

t3.smallを設定



Network settings(advanced)をクリックして詳細画面を開き、メモしておいたVPC IDと最初に作成したパブリックサブネットID（ap-northeast-1a）を指定し、[Next step]をクリック



確認画面で[Create environment]をクリック



しばらくするとAWS Cloud9の環境構築が完了し、IDE画面が表示される


新しくTerminalを開く


ECSマイクロサービスハンズオン


ECSマイクロサービスハンズオン（補足）

これから先、コマンドを入力する箇所が多くありますが

本資料からのコピーの場合正しく動作しない事があります

以下にコマンド集をアップロードしてありますので

ダウンロードし資料で確認後にコマンドをコピーしてご利用ください

https://bit.ly/2nmi4tB

https://bit.ly/2nmi4tB


IAMロール設定(1)CodeDeployが利用するIAMロールを作成します。

Services -> IAM へ


IAMロール設定(2)

Roleタイプで

AWS Service > CodeDeploy > CodeDeploy – ECS を選択してからNext: Permissionを選択



AWSCodeDeployRoleForECSポリシーが表示されていることを確認しNext: Tags



ロール名は{ユーザ名}CodeDeployRoleforECSにして

Create role


Rails Frontendコンテナアプリをデプロイ


Rails-frontend タスク定義作成(1)


Rails-frontendタスク定義作成(2)

タスク定義名を指定({ユーザ名}-ecsdemo-frontend)

タスクに割り当てるメモリ／CPUを0.5GB/0.25vCPUに指定

Fargateのネットワークモードはawsvpcのみ

新しいロールを作成を選択



押下してコンテナの詳細へ



利用するDockerイメージを<ECRのリポジトリURI>:<タグ>の形式で指定(今回のタグはlatest)

今回は以下を指定

449974608116.dkr.ecr.ap-northeast-1.amazonaws.com/devday2019-ecsdemo-frontend:latest

コンテナportを3000に設定

タスク内でのみ利用するのでecsdemo-frontendと記入



バックエンドとなるサービスを環境変数で指定しておくCRYSTAL_URL ：http://{ユーザ名}-ecsdemo-crystal.service:3000/crystalNODEJS_URL ：http://{ユーザ名}-ecsdemo-nodejs.service:3000



ログ出力を設定するためAuto-Configure CloudWatch logsを有効にする

残りはDefaultのままで、追加ボタンを押下




Rails Frontendのサービス作成(1)

作成完了画面から[アクション] → [サービスの作成] を選択



先ほど作成したfrontendタスク定義とクラスターを指定

初期起動タスク数を指定今回は3タスクを起動する

Launch TypeはFARGATEを選択

サービス名は{ユーザ名}-ecsdemo-frontend



Deployment TypeはBlue/green deploymentを選択

Service Roleは作成したCodeDeployRoleforECSを選択



作成したVPCを選択

SecurityGroupを編集する

作成したSubnetを3つ選択

よくある間違いポイント


Rails Frontendのサービス作成(5)既存のセキュリティグループを選択にチェックをつけ、名前がdefaultとなっ

ているセキュリティグループを選択し、保存をクリック



Application Load Balancerを選択

作成したALB名を選択

frontendコンテナが選択されて

いることを確認し、ロードバランサに追加を選択


Rails Frontendのサービス作成(7)Listener portは create new80を入力

blue/green デプロイメント中のテストポートは9000を入力



今回は/healthというページを公開するためこのページをヘルスチェックパスに設定

上記同様、 /healthをヘルスチェックパスに設定

任意の名前例えば {ユーザー名}-ecsdemo-frontend-1 を入力

任意の名前例えば {ユーザー名}-ecsdemo-frontend-2 を入力



名前空間はserviceで検出名は{ユーザ名}-ecsdemo-frontend

その他はデフォルとのまま

ECS Service Discoveryを有効のままにする





サービス作成が完了し、タスクが3つ立ち上がることを確認

:1

:1



ALBのターゲットグループ配下にFargateモードで起動したタスク(に割り当てられたENI)がアタッチされ、StatusがHealthyになっていることを確認

Services -> EC2 へ



ALBのエンドポイントにアクセスし、Railsのアプリケーションページが表示されることを確認


Nodejs Backendコンテナアプリをデプロイ


nodejs backendタスク定義作成(1)



タスク定義名を指定{ユーザ名}-ecsdemo-nodejs



ecsTaskExecutionRole を選択








449974608116.dkr.ecr.ap-northeast-1.amazonaws.com/devday2019-ecsdemo-nodejs:latest


タスク内でのみ利用するのでecsdemo-nodejsと記入








nodejs backendのサービス作成(1)




先ほど作成したnodejsタスク定義とクラスターを指定



サービス名は{ユーザ名}-ecsdemo-nodejs



Deployment Typeはローリングアップデートを選択。Blue/GreeんデプロイメントにはALBが必須となるため、今回はDNSベースでのサービスディスカバリのハンズオンのため、frontend以外はローリングアップデートを選択する








nodejs backendのサービス作成(5)既存のセキュリティグループを選択にチェックをつけ、名前がdefaultとなっ




DNSベースのサービスディスカバリを利用するため、LBはなしを選択



名前空間は先ほどfrontendで作ったservice｜プライベートを選択し、検出名は{ユーザ名}-ecsdemo-nodejs

その他はデフォルとのまま次のステップへ







:1

:1



ALBのエンドポイントにアクセスし、Rails

とNodejsのアプリケーションが連携されていることを

確認


Crysyal Backendコンテナアプリをデプロイ


crystal backendタスク定義作成(1)



タスク定義名を指定{ユーザ名}-ecsdemo-crystal



ecsTaskExecutionRole を選択








449974608116.dkr.ecr.ap-northeast-1.amazonaws.com/devday2019-ecsdemo-crystal:latest


タスク内でのみ利用するのでecsdemo-crystalと記入








crystal backendのサービス作成(1)




先ほど作成したcrystalタスク定義とクラスターを指定



サービス名は{ユーザ名}-ecsdemo-crystal



Deployment Typeはローリングアップデートを選択。Blue/GreeんデプロイメントにはALBが必須となるため、今回はDNSベースでのサービスディスカバリのハンズオンのため、frontend以外はローリングアップデートを選択する








crystal backendのサービス作成(5)既存のセキュリティグループを選択にチェックをつけ、名前がdefaultとなっ




DNSベースのサービスディスカバリを利用するため、LBはなしを選択



名前空間は先ほどfrontendで作ったservice｜プライベートを選択し、検出名は{ユーザ名}-ecsdemo-crystal

その他はデフォルとのまま次のステップへ







:1

:1



ALBのエンドポイントにアクセスしRailsとNodejsの

アプリケーションが連携されていることを確認


ECS CI/CDハンズオン（Blue/Green）


本ハンズオンで作成する継続的デプロイメント構成

Developers

AWS CodeCommit

AWS CodePipeline

AWS CodeBuild

Amazon ECS

Amazon ECR

①git pushでリポジトリを更新

②CodePipeline が更新を検知しパイプラインを開始

④CodeDeployがECRのDockerイメージをECSクラスタにBlue/Greenデプロイメント

③CodeBuildがDockerイメージをビルドしECRへプッシュ

AWS CodeDeploy


ECRリポジトリ作成


ECRリポジトリ作成(frontend)

{ユーザ名}-ecsdemo-frontendのリポジトリ名を指定して

リポジトリを作成


CodeCommit設定


CodeCommitリポジトリServices -> CodeCommit -> Create repository へ

frontendサービスのコードリポジトリを設定します。{ユーザ名}-ecsdemo-frontendと、リポジトリ名を設定例：user1-ecsdemo-frontend


git環境の設定

$ git config --global user.name ”yourname”$ git config --global user.email [email protected]$ git config --global credential.helper '!aws codecommit credential-helper $@' $ git config --global credential.UseHttpPath true

Cloud9を開き、ターミナルにコマンドを入力

mailto:[email protected]


CodeCommitリポジトリのクローン(1)

URLのクローンでHTTPSのクローンをクリックしコピーし、Cloud9のターミナルで git clone $URL を実行する

CodeCommitでの操作後、Cloud9 terminal へ

# ワークディレクトリに移動

$ cd ~/environment

#リポジトリのクローン

$ git clone https://git-codecommit.us-east-1.amazonaws.com/v1/repos/{ユーザ名}-ecsdemo-frontend

Cloning into 'hamashi-ecsdemo-frontend'...

warning: You appear to have cloned an empty repository.

https://git-codecommit.us-east-1.amazonaws.com/v1/repos/%7bユーザ名%7d-ecsdemo-frontend


アプリケーションコードをダウンロード

#マイクロサービスの各ソースコードをダウンロード

$ wget https://amzn.to/ecs-20190913

# 圧縮解凍する

$ tar xzf ecs-20190913

# 右のようなマイクロサービスとなるサービスの

ソースがダウンロードされている


コンテンツ準備

リポジトリ配下に以下のファイルを作成

• ecshandson/ecsdemo-frontend配下のファイルを全て先ほど作成した{ユーザ名}-ecsdemo-frontend/へコピー

• buildspec.ymlを修正

• CodeBuildのビルドプロジェクト定義ファイル

• 内容は次ページ

• 不要なbuildspec-dockerhub.ymlとbuildspec-test.ymlを削除しておく

• appspec.ymlを新規作成

• taskdef.jsonを新規作成

# ソースディレクトリに移動

$ cd ecshandson/ecsdemo-frontend/

# ファイルをコピー

$ cp -pr ./* ~/environment/hamashi-ecsdemo-frontend/

$ cp -pr .dockerignore ~/environment/hamashi-ecsdemo-frontend/

$ cp -pr .gitignore ~/environment/hamashi-ecsdemo-frontend/


buildspec.ymlversion: 0.2phases:pre_build:commands:- $(aws ecr get-login --region $AWS_DEFAULT_REGION --no-include-email)- REPOSITORY_URI=01234567890.dkr.ecr.us-east-1.amazonaws.com/hamashi-ecsdemo-frontend- IMAGE_TAG=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7)

build:commands: - docker build -t $REPOSITORY_URI:latest .- docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG

post_build:commands:- docker push $REPOSITORY_URI:latest- docker push $REPOSITORY_URI:$IMAGE_TAG- printf '{"Version":"1.0","ImageURI":"%s"}' $REPOSITORY_URI:$IMAGE_TAG > imageDetail.json

artifacts:files: imageDetail.json

pre_buildフェーズではECRリポジトリへのログインをおこない、ビルドIDのPrefixをDockerイメージのタグに指定

buildフェーズでは環境変数で指定するリポジトリURIを取得し、Dockerイメージのビルドを実施

post_buildフェーズではビルドしたDockerイメージをECRリポジトリに

Push

CodePipelineで後続のフェーズにタグ情報を渡すため、アウトプットアーティファクトを指定

buildspec.yml の拡大版は次ページを参照

※お急ぎの方は以下をご活用ください。buildspec.yml: http://bit.ly/2ZgYIEd


buildspec.ymlの修正version: 0.2phases:

pre_build:commands:

- $(aws ecr get-login --region $AWS_DEFAULT_REGION --no-include-email)- REPOSITORY_URI=01234567890.dkr.ecr.us-east-1.amazonaws.com/{ユーザ名}-ecsdemo-frontend- IMAGE_TAG=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7)

build:commands:

- docker build -t $REPOSITORY_URI:latest .- docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG

post_build:commands:

- docker push $REPOSITORY_URI:latest- docker push $REPOSITORY_URI:$IMAGE_TAG- printf '{"Version":"1.0","ImageURI":"%s"}' $REPOSITORY_URI:$IMAGE_TAG > imageDetail.json

artifacts:files: imageDetail.json

ご自身のfrontendサービスのECRのリポジトリURIを指定


appspec.yml

version: 0.0Resources:- TargetService:

Type: AWS::ECS::ServiceProperties:TaskDefinition: "<TASK_DEFINITION>"LoadBalancerInfo:

ContainerName: "ecsdemo-frontend" ContainerPort: "3000"

修正せずそのままお使いください

AppSpecファイルはCodeDeployがデプロイを管理するために使用するファイルです

今回の対象はECSなのでECSタスク定義、ロードバランサー情報などを含める必要があります

TASK_DEFINITIONプレースホルダーはPipelineが走ると自動的に置き換わります

※お急ぎの方は以下をご活用ください。appspec.yml: https://amzn.to/2kC4T6X


taskdef.jsonECS -> Task Definition -> {ユーザ名}-ecsdemo-frontend -> 最新のRevisionを表示

Jsonタブを表示し、内容を全てコピー


taskdef.jsonの修正

…"memoryReservation": 128,

"volumesFrom": [],"stopTimeout": null,"image": "<IMAGE1_NAME>","startTimeout": null,"dependsOn": null,"disableNetworking": null,"interactive": null,"healthCheck": null,

…

先ほどコピーした内容を全て貼り付ける

imageを<IMAGE1_NAME>に変更。このプレースホルダーはBuildアクション後に動的にアップデートされます

taskdef.jsonはFargateで起動されるタスクの情報が記載されたファイルです。今回はPipelineがトリガーされると動的にタスク定義を更新します


リポジトリへのpush

#リモートリポジトリへのPush

$ cd ~/environment/{ユーザ名}-ecsdemo-frontend/$ git add -A$ git commit -m "my first commit"$ git push origin master

CodeCommitコンソールからCommit履歴が見えることを確認

https://docs.aws.amazon.com/ja_jp/codecommit/latest/userguide/troubleshooting-ch.html#troubleshooting-macoshttps

https://docs.aws.amazon.com/ja_jp/codecommit/latest/userguide/troubleshooting-ch.html#troubleshooting-macoshttps


CodePipeline設定


パイプライン作成(1)Services -> CodePipeline -> Create pipeline へ

{ユーザ名}-ecsdemo-frontendと入力


パイプライン作成(2)

SourceプロバイダーにCodeCommitのリポジトリとmasterブランチを指定



BuildプロバイダーにCodeBuildを指定



Buildプロジェクト名を指定{ユーザ名}-frontend-build

Build環境を指定- 環境イメージ: マネージド型イメージ- オペレーティングシステム : Ubuntu- ランタイム: Standard- イメージ: aws/codebuild/standard:1.0- イメージのバージョン: aws/codebuild/standard: 1.0-1.8.0- 特権付与の項目にチェックをつける

その他はデフォルトのままにしCodePipeline へ戻り、Nextを選択



デプロイプロバイダーにAmazon ECS (ブルー/グリーン)を指定

タスク定義とAppSpec ファイルのinput artifactにBuildArtifactを選択、これは後ほど修正

AWS CodeDeployアプリケーション名に AppECS-xxx(自分のユーザ名が含まれているもの)を指定

AWS CodeDeployデプロイグループに DgpECS-xxx (自分のユーザ名が含まれているもの)を指定

Reviewページ確認後、Create pipelineを選択


CodeBuildのIAM Role編集 (1)Services -> IAM へ

「ポリシーをアタッチします」を選択

IAM Roleより、codebuildを検索し、先ほど自動作成されたロール codebuild-{ユーザ名}-frontend-build-service-role を選択

今回定義したビルド定義(buildspec.yml)では、ビルド内でECRに対してDockerイメージをPushしているため、CodeBuildに割り当てたIAMロールに対してECRの操作権限を付与する必要があります


CodeBuildのIAM Role編集 (2)

AmazonEC2ContainerRegistryPowerUserをアタッチ


CodePipelineの設定編集 (1)Services -> CodePipeline へ

先ほど作成した {ユーザ名}-ecsdemo-pipeline を選択し Edit

ビルドで失敗しているのは先ほどまでIAMの権限がなかったため


CodePipelineの設定編集 (2)

Deployステージを編集



入力アーティファクトで追加を押し、SourceArtifactを追加する



ECSタスク定義の入力アーティファクトをSourceArtifactとする

CodeDeploy AppSpecファイルの入力アーティファクトを SourceArtifactとする

タスク定義のimageを動的に変更するための情報が記載された入力アーティファクトを BuildArtifactとする

Imageのプレースフォルダー文字をIMAGE1_NAME とする

Pipeline編集のページでSaveする


CodeDeployの設定編集 (1)

CodeDeploy > アプリケーション >AppECS-{ユーザ名}-fargate-cluster- {ユーザ名}-ecsdemo-frontendを選択し、デプロイメントグループを編集

CodeDeploy 選択


CodeDeployの設定編集 (2)blue/greenの検証期間を設けるため「トラフィックを再ルーティングするタイミングを指定します」を選択

再ルーティングされるまでの期間、元のリビジョンの終了までの時間をそれぞれ 0 Days, 0 Hours, 10 Minutesに変更


パイプライン実行

パイプラインのリリースが始まります

CodePipelineからユーザー名-ecsdemo-frontendを選択し [変更をリリースする] をクリック

CodePipeline 選択


デプロイ状況の確認 (1)CodeDeploy -> Deployments へ

Deploymentの進行状況をCodeDeployコンソールより確認します

ステップ３に入ると右上に [トラフィックの再ルーティング] が表示されます

ブラウザで、作成したALBの [ URL:9000 ] で置換タスク（新しいバージョン）での表示を確認し、問題があれば停止、なければ [ トラフィックの再ルーティング ] をクリックして処理を進めます


デプロイ状況の確認 (2)CodeDeploy -> Deployments へ

オリジナルタスクは設定した10分を経過すると削除されます

置換タスク（新しいバージョン）に何か問題があればロールバックしましょう指定した時間分の待機が不要であれば画面右上の[元のタスクセットの終了]から削除も可能です


デプロイ状況の確認 (3)Services -> ECS -> Cluster -> Service へ

ServiceのDeploymentsタブよりBlue/Green Deploymentの状況を確認することもできます

Eventsタブでは、タスクの起動や、Drainingの履歴を確認することができます


継続的デプロイメントパイプライン動作確認


リポジトリへのpush

#アプリのバージョンアップ(ecsdemo-frontendのappのviewを適当に書き変える)

$ vim ~/environment/{ユーザ名}-ecsdemo-frontend/app/views/application/index.html.erb

#リモートリポジトリへのPush

$ git add -A$ git commit -m "pipeline test"$ git push origin master

Services -> Cloud9 へ


継続的デプロイメント動作確認

以下のポイントを確認する

• CodePipelineのパイプラインが自動的に開始され、正常に完了すること



以下のポイントを確認する• CodeDeployでGreen環境が立ち上がったら、ALBのエンドポイントに9000ポートでアクセスして、Green環境を閲覧できることを確認



以下のポイントを確認する• ECSで新しいタスク定義でサービス更新が行われていること



以下のポイントを確認する• [ トラフィックの再ルーティング ]をクリックしGreen環境が本番の80ポートでルーティングされていることを確認



以下のポイントを確認する• 元のタスキセットの終了の待機期間10分が経過すると、もともと残っていたタスクセットが削除されデプロイメントが完全に終了する。(つまりこの期間が終了するまではロールバックを実施が可能）


本セッションで学んだこと

1. ECSを複数タスクで稼働させるアプリケーションのデプロイ

2. タスク間のサービスディスカバリ

3. CodeDeploy、ALBを利用したECSのBlue/Greenデプロイメント

4. CodePipelineを利用したECS環境におけるCI・CDによる自動デプロイ


後始末


ハンズオンで利用したリソースを削除

• CodePipeline パイプライン

• CodeDeploy アプリケーション

• CodeBuild ビルドプロジェクト

• CodeCommit リポジトリ

• S3 バケット

• 各種IAM ロール/ポリシー

• CloudWatch ロググループ

• ECR リポジトリ

• ECS サービス/クラスター

• ECS タスク定義

• ALB リスナー/ターゲットグループ

• ALB

• Cloud Map 名前空間

• Cloud9 環境

• VPC

これから順を追って削除していきます


CodePipeline パイプライン削除

Services -> CodePipeline へ

該当するパイプラインの名前にチェックをつけ[パイプラインを削除する]をクリックして削除します


該当するアプリケーション名をクリックし詳細ページに遷移した後、[アプリケーションの削除]をクリックして削除します

CodeDeploy アプリケーション削除

Services -> CodeDeploy へ


CodeBuild ビルドプロジェクト削除

Services -> CodeBuild へ

該当するビルドプロジェクトの名前にチェックをつけ[Delete build project]をクリックして削除します


CodeCommit リポジトリ削除

Services -> CodeCommit へ

該当するリポジトリの名前にチェックをつけ[リポジトリの削除]をクリックして削除します


codepipeline-ap-northeatst-1から始まるバケットを選択し[削除]をクリックして削除します

S3 バケット削除

Services -> S3 へ


IAM ロールの削除

今回利用したユーザー名で検索し、ハンズオンで利用したロールを選択して[ロールの削除]をクリックし削除します

Services -> IAM へ


IAM ポリシーの削除

Services -> IAM へ

今回利用したユーザー名で検索し、ハンズオンで利用したポリシーを１つずつ選択して [ポリシーのアクション] より[削除]をクリック確認画面でさらに [削除] をクリックして削除します


CloudWatch ロググループの削除

今回のハンズオンで利用したcodebuildのロググループを削除しますチェックをつけて、アクションから [ロググループの削除] を選択確認画面がでるので [はい、削除します] をクリックして削除します

Services -> CloudWatch へ


ECR リポジトリの削除

今回のハンズオンで利用したリポジトリにチェックをつけて[削除] を選択、確認画面がでるのでさらに [削除] をクリックして削除します

Services -> ECR へ


ECS サービスの削除

今回のハンズオンで利用したクラスターの中に入り１つずつサービスにチェックをつけ「削除」をクリック確認画面がでるのでさらに [削除] をクリックして削除します

Services -> ECS へ


ECS クラスターの削除

サービスがなくなったら[クラスターの削除] をクリックします

Services -> ECS へ

「ECS環境のセットアップ」を CloudFormationで作成した方は、このページはスキップ


ECSタスク定義の無効

タスク定義の一覧から、今回作成した定義をクリックし既存のリビジョンを全選択した上で、[アクション] から [登録解除] を選択確認画面がでるのでさらに [登録解除] をクリックしてINACTIVEにします

Services -> ECS へ


ALB リスナーの削除

Services -> EC2 へ

ロードバランサーから今回作成したALBからを選択[リスナー]タブで全リスナーを選択し [削除] をクリック確認画面がでるのでさらに [はい、削除する] をクリックして削除します


ALB ターゲットグループの削除

ターゲットグループで今回作成したターゲットを選択し[アクション] から [削除] をクリックします確認画面がでるのでさらに [はい] をクリックして削除します

Services -> EC2 へ


Cloud Map 名前空間の削除

Services -> AWS Cloud Map へ

今回作成した [service] を選択し、サービスを順番に1つずつ選択し[削除]をクリックして削除していきますその後ページ右上にある [削除] をクリックし名前空間を削除します


Cloud9 環境の削除

Services -> Cloud9 へ

「ECS環境のセットアップ」を CloudFormationで作成した方は、このページはスキップ

今回の環境を選択し [Delete] をクリックします確認画面でさらに [Delete] をクリックし削除します


ECSハンズオン環境の削除

Services -> CloudFormation へ

「ECS環境のセットアップ」を CloudFormationで作成した方のみ実施

ハンズオン環境作成のCloudFormationテンプレートを利用したスタックを選択し [削除] をクリックします確認画面でさらに [スタックの削除] をクリックし削除します画面を更新してスタックが削除されている事をご確認ください


VPC の削除

Services -> CloudFormation へ

VPCのCloudFormationテンプレートを利用したスタックを選択し [削除] をクリックします確認画面でさらに [スタックの削除] をクリックし削除します画面を更新してスタックが削除されている事をご確認ください


お疲れ様でした！

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.

アンケートご協力のお願いお手持ちの受講票のアンケート用QRコードから

アンケートにお答えいただくと、記念品を差し上げております。

※イメージです

プレゼントの引き換えは、神田明神の会場出口付近（屋外）までお越しください

IT情報安全守護

2019 年 10 月 1 日〜11 月 5 日開催amzn.to/AWSInnovateJP

申し込み受付中

AWS 最新アップデート / コンテナ / AIML / AWS アンチパターン /

認定試験対策講座など60セッション

オンラインで参加できるカンファレンス、全 60 セッション

10/9, 10/15 ライブ配信

AWS エキスパートへのQ&A

修了証明書の発行業務時間に視聴

2019 年 10 月 1 日〜11 月 5 日開催amzn.to/AWSInnovateJP

Application Development

Container

Serverless

オンラインで参加できるカンファレンス、全 60 セッション

おすすめセッション


Appendix


Amazon ECSのService Discovery

ECS ではロードバランサベースとDNS ベースの

2種類のサービスディスカバリをネイティブに利用可能

LB-based

service A service B

ALB

DNS-based

service A service B


ECS Service Discovery (DNSベース)

• ECS サービスが Amazon Route 53 のドメイン名で自動登録/管理


ECS Service Discoveryの挙動

VPC

Public subnet Private subnet

Internet gateway ALB

Amazon ECS Service Discovery

Amazon Route 53Service Discovery

ecsfrontend.service

ecsworker.service

ecsauth.service

・・

・・

・・

Task

Task

Task

Task

Task

Task

Documents

マイクロサービスCI/CDハンズオン · •Dockerの組み込み仮想ネットワークを使用して外部 ネットワークと通信(コンテナリンク利用可) •hostモード

マイクロサービスCI/CDハンズオン · •Dockerの組み込み仮想ネットワークを使用して外部ネットワークと通信(コンテナリンク利用可) •hostモード