Tweet
Tweet

Slide 1

Slide 1 text

あなたの組織に最適な コンテナデプロイ⽅法とは︖ 濱⽥孝治（ハマコー） 〜ECSにおけるデプロイ最新機能てんこ盛り〜

Slide 2

Slide 2 text

#devio2020 2 @hamako9999 ハマコー

Slide 3

Slide 3 text

#devio2020 3 #devio2020 常にでてるよ︕

Slide 4

Slide 4 text

#devio2020 4

Slide 5

Slide 5 text

5 いまこの動画をみている みなさんに伝えたいこと

Slide 6

Slide 6 text

#devio2020 6 AWSのコンテナ開発において検討が必要な事柄 AWS上でコンテナ開発するとき検討すべき事は多岐に渡る • ネットワーク設計 • コンテナ設計 • 監視設計 • ロギング設計 • セキュリティ設計 • デプロイ設計

Slide 7

Slide 7 text

#devio2020 7 AWSのコンテナ開発において検討が必要な事柄 AWS上でコンテナ開発するとき検討すべき事は多岐に渡る • ネットワーク設計 • コンテナ設計 • 監視設計 • ロギング設計 • セキュリティ設計 • デプロイ設計 最初に検討してほしい

Slide 8

Slide 8 text

8 なぜ優先順位が⾼いのか アプリケーション基盤の ⼀番基礎となる部分なので 将来にわたって投資対効果が⾼い 開発〜テスト〜リリース〜改善プロセスまで

Slide 9

Slide 9 text

9 結論 を節約 できる

Slide 10

Slide 10 text

10 このセッションで伝えたいこと この45分間で 将来にわたりあなたの組織の TCOを削減するヒントを つかんでください

Slide 11

Slide 11 text

#devio2020 11 ECSデプロイを極めるまで ECSデプロイの構造を理解する ECSデプロイのアンチパターンを理解する 開発環境にデプロイしてみる 本番環境にデプロイしてみる GitHub Actionsを使ってデプロイする IaC管理するリソースとの⽭盾に⽴ち向かう 基礎 必須 応⽤

Slide 12

Slide 12 text

12 みなさんのECSアプリケーションの さらなる進化を願って

Slide 13

Slide 13 text

#devio2020 13 ECSデプロイを極めるまで ECSデプロイの構造を理解する ECSデプロイのアンチパターンを理解する 開発環境にデプロイしてみる 本番環境にデプロイしてみる GitHub Actionsを使ってデプロイする IaC管理するリソースとの⽭盾に⽴ち向かう 基礎 必須 応⽤

Slide 14

Slide 14 text

14 最初に ECSの構造について振返り

Slide 15

Slide 15 text

#devio2020 15 AWSのコンテナ関連サービスをまとめた図 データ プレーン 実際にコンテナが稼働する場所 コントロール プレーン コンテナの管理をする場所 ECS EKS EC2 Fargate

Slide 16

Slide 16 text

#devio2020 16 今回喋る範囲 データ プレーン 実際にコンテナが稼働する場所 コントロール プレーン コンテナの管理をする場所 ECS EC2 Fargate

Slide 17

Slide 17 text

#devio2020 タスク定義 17 ECSの構造解説（タスク定義、コンテナ定義） EC2 Fargate タスクメモリ タスクCPU or ⽣成 コンテナ定義 イメージのURI ポートマッピング ヘルスチェック エントリポイント コマンド 作業ディレクトリ 環境変数 ログ設定 docker runで利⽤す るコマンドは⼀通り 利⽤可能

Slide 18

Slide 18 text

#devio2020 クラスター サービス定義 サービス定義 サービス 18 ECSの構造解説（クラスター、サービス） 元ネタのタスク定義 タスクの数 デプロイ定義 VPC、サブネット セキュリティグループ ALB（or NLB）定義 オートスケール設定 タスク タスク タスク タスク ・ ・ ・ ・ Application Load Balancer Amazon ECS タスク 定義 起動

Slide 19

Slide 19 text

19 そもそも ECSへのデプロイとは

Slide 20

Slide 20 text

#devio2020 20 ECSへのデプロイ⽅法 ECS上でコンテナを実⾏する⽅法は⼤きく２つ ①タスク実⾏ • 主にFargateだと定期バッチ処理などで利⽤

Slide 21

Slide 21 text

#devio2020 21 ECSへのデプロイ⽅法 ECS上でコンテナを実⾏する⽅法は⼤きく２つ ①タスク実⾏ • 主にFargateだと定期バッチ処理などで利⽤ ②ECSサービスの利⽤ • 常駐サービス（WebやAPIサーバなどで利⽤）

Slide 22

Slide 22 text

#devio2020 22 ECSへのデプロイ⽅法 ECS上でコンテナを実⾏する⽅法は⼤きく２つ ①タスク実⾏ • 主にFargateだと定期バッチ処理などで利⽤ ②ECSサービスの利⽤ • 常駐サービス（WebやAPIサーバなどで利⽤）

Slide 23

Slide 23 text

#devio2020 23 ECSへのデプロイのながれ タスク定義のイメージURIと、サービス定義のタスク定 義バージョンが変更されデプロイされる タスク定義 タスクメモリ タスクCPU コンテナ１ イメージのURI ポートマッピング ログ設定 コンテナ２ イメージのURI ポートマッピング ログ設定 サービス定義 ネットワーク VPC タスク定義 タスク定義バージョン オートスケール設定 新コンテナで デプロイ起動 ECR

Slide 24

Slide 24 text

24 ここまでで ECSデプロイの共通認識を 得ました

Slide 25

Slide 25 text

#devio2020 25 ECSデプロイを極めるまで ECSデプロイの構造を理解する ECSデプロイのアンチパターンを理解する 開発環境にデプロイしてみる 本番環境にデプロイしてみる GitHub Actionsを使ってデプロイする IaC管理するリソースとの⽭盾に⽴ち向かう 基礎 必須 応⽤

Slide 26

Slide 26 text

26 ⼀⾔ latest運⽤は やめましょう

Slide 27

Slide 27 text

#devio2020 27 latest運⽤のメリット・デメリット メリット • デプロイにおいてタスク定義、サービス定義の更新が不要 • サービスの「新バージョンの強制デプロイ」で全て完結

Slide 28

Slide 28 text

#devio2020 28 latest運⽤のメリット・デメリット メリット • デプロイにおいてタスク定義、サービス定義の更新が不要 • サービスの「新バージョンの強制デプロイ」で全て完結 デメリット • コンテナでエラー発⽣時、ソースコードとのトレーサビリ ティがとれない • どのバージョンが今本番環境で動いているのか確証がとれ ない • 適切なロールバック対処ができない

Slide 29

Slide 29 text

#devio2020 29 推奨設定 https://dev.classmethod.jp/articles/ecr-immutable-image-tags/

Slide 30

Slide 30 text

#devio2020 30 ECSデプロイを極めるまで ECSデプロイの構造を理解する ECSデプロイのアンチパターンを理解する 開発環境にデプロイしてみる 本番環境にデプロイしてみる GitHub Actionsを使ってデプロイする IaC管理するリソースとの⽭盾に⽴ち向かう 基礎 必須 応⽤

Slide 31

Slide 31 text

31 開発環境へのデプロイ 開発環境へのデプロイで ECSデプロイの 基本的な流れをおさえましょう

Slide 32

Slide 32 text

#devio2020 32 開発環境デプロイの構成 開発環境の前提条件 • AWSアカウントは⼀つ • デプロイ先のECSは同じ環境 • デプロイ⽅法はローリングアップデート • 承認ステージは無し

Slide 33

Slide 33 text

#devio2020 33 開発環境デプロイの構成

Slide 34

Slide 34 text

#devio2020 34 開発環境デプロイのパイプライン

Slide 35

Slide 35 text

#devio2020 35 ビルド部分の詳細

Slide 36

Slide 36 text

#devio2020 36 ビルド部分の構成（Buildspec.yml） build: commands: - REPOSITORY_URI=${ECR_URI} - IMAGE_TAG=${CODEBUILD_RESOLVED_SOURCE_VERSION} - docker build -t $REPOSITORY_URI:$IMAGE_TAG . post_build: commands: - docker push $REPOSITORY_URI:$IMAGE_TAG - echo "[{¥"name¥":¥"${CONTAINER_NAME}¥",¥"imageUri¥":¥"${REPOSITORY_U RI}:${IMAGE_TAG}¥"}]" > imagedefinitions.json artifacts: files: imagedefinitions.json

Slide 37

Slide 37 text

#devio2020 37 ビルド部分の構成（Buildspec.yml） build: commands: - REPOSITORY_URI=${ECR_URI} - IMAGE_TAG=${CODEBUILD_RESOLVED_SOURCE_VERSION} - docker build -t $REPOSITORY_URI:$IMAGE_TAG . ${ECR_URI} • プッシュ先ECRのURI。CodeBuildの環境変数で⾃分で設定 ${CODEBUILD_RESOLVED_SOURCE_VERSION} • CodeBuildのソースがGitリポジトリの場合に⾃動的に設定される 環境変数 • ソースコードリポジトリのコミットIDが格納される

Slide 38

Slide 38 text

#devio2020 38 ビルド部分の構成（Buildspec.yml） post_build: commands: - docker push $REPOSITORY_URI:$IMAGE_TAG 前段で設定したURIとイメージタグ（ソースリポジトリのコ ミットタグ）をつけて、ECRにプッシュ

Slide 39

Slide 39 text

#devio2020 39 ビルド部分の構成（Buildspec.yml） - echo "[{¥"name¥":¥"${CONTAINER_NAME}¥",¥"imageUri¥":¥"${REPOSITORY_U RI}:${IMAGE_TAG}¥"}]" > imagedefinitions.json artifacts: files: imagedefinitions.json イメージ定義ファイル（imagedefinitions.json）の作成 ECSのタスク定義中のコンテナとECRのURIをマッピングする 情報 キー 値 例 name コンテナ名 php-container ImageURI imageUri 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/php- container:b5649704b0

Slide 40

Slide 40 text

#devio2020 40 デプロイ部分の詳細

Slide 41

Slide 41 text

#devio2020 41 デプロイ部分の詳細 CodePipelineのデプロイステージで以下を設定 • Action provider︓ECS • Input artifacts︓BuildArtifact • デプロイ対象のECSクラスター、ECSサービス • イメージ定義ファイル名 キー 値 例 name コンテナ名 php-container ImageURI imageUri 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/php- container:b5649704b0

Slide 42

Slide 42 text

#devio2020 42 デプロイ時の挙動 デプロイ設定とイメージ定義ファイルの内容で⾚字部分 だけが更新される タスク定義 タスクメモリ タスクCPU コンテナ１ イメージのURI ポートマッピング ログ設定 コンテナ２ イメージのURI ポートマッピング ログ設定 サービス定義 ネットワーク VPC タスク定義 タスク定義バージョン オートスケール設定 新コンテナで ローリングデプ ロイ起動 CodePipeline

Slide 43

Slide 43 text

#devio2020 43 全体の振返り

Slide 44

Slide 44 text

#devio2020 44 TIPS１︓BuildKitの有効化 Buildspec.yml内で、環境変数 「DOCKER_BUILDKIT」を1に設定しよう︕ これにより、DockerのBuildKitが有効化され、ビルド の短縮化が⾒込める env: variables: DOCKER_BUILDKIT: "1"

Slide 45

Slide 45 text

#devio2020 45 TIPS１︓BuildKitの有効化 https://dev.classmethod.jp/articles/codebuild-buildkit/

Slide 46

Slide 46 text

#devio2020 46 TIPS2︓CodeBuildのローカルキャッシュ利⽤ CodeBuild内でのDockerレイヤーのローカルキャッ シュ機能を利⽤することで、ビルド時間の短縮化が⾒込 める

Slide 47

Slide 47 text

#devio2020 47 TIPS2︓CodeBuildのローカルキャッシュ利⽤ https://dev.classmethod.jp/articles/codebuild-local-cache/

Slide 48

Slide 48 text

#devio2020 48 リファレンス • イメージ定義ファイルのリファレンス • https://docs.aws.amazon.com/ja_jp/codepipeline/lat est/userguide/file-reference.html#pipelines-create- image-definitions • CodeBuildのビルド仕様に関するリファレンス • https://docs.aws.amazon.com/ja_jp/codebuild/latest /userguide/build-spec-ref.html

Slide 49

Slide 49 text

49 開発環境へのデプロイ 今あなたは ECSデプロイの 基本パターンを把握しました

Slide 50

Slide 50 text

#devio2020 50 ECSデプロイを極めるまで ECSデプロイの構造を理解する ECSデプロイのアンチパターンを理解する 開発環境にデプロイしてみる 本番環境にデプロイしてみる GitHub Actionsを使ってデプロイする IaC管理するリソースとの⽭盾に⽴ち向かう 基礎 必須 応⽤

Slide 51

Slide 51 text

51 本番環境へのデプロイ 本番環境へのデプロイで さらなる実践的な デプロイ⽅法を模索しましょう

Slide 52

Slide 52 text

#devio2020 52 本番環境デプロイの構成 本番環境の前提条件 • AWSアカウントは開発環境のアカウントとわける • テスト済みのコンテナイメージを利⽤する • デプロイ⽅法としてBlue/Greenデプロイを採⽤する • 承認ステージを設置する

Slide 53

Slide 53 text

#devio2020 53 本番環境デプロイの構成

Slide 54

Slide 54 text

54 本番環境へのデプロイ 本番環境でつかうイメージの 元ネタについて

Slide 55

Slide 55 text

55 別環境でのデプロイテストにおいて 流派が異なる２つの 考え⽅があります︕

Slide 56

Slide 56 text

#devio2020 56 本番環境デプロイの構成 本番環境の前提条件 • AWSアカウントは開発環境のアカウントとわける • テスト済みのコンテナイメージを利⽤する • デプロイ⽅法としてBlue/Greenデプロイを採⽤する • 承認ステージを設置する ここ

Slide 57

Slide 57 text

#devio2020 57 別の環境にコンテナをデプロイする⽅法２種 ①コードベースを同じにして再度ビルドする⽅法 • 開発環境にデプロイしたブランチから、ステージング、本 番環境⽤ブランチへマージしてプッシュ • 各環境⽤ブランチのプッシュをトリガーに対応する環境へ デプロイする⽅式 ②テスト済みイメージを使い回す • 開発環境でテストしたイメージを使ってステージング環境、 本番環境にデプロイする

Slide 58

Slide 58 text

#devio2020 58 別の環境にコンテナをデプロイする⽅法２種 ①コードベースを同じにして再度ビルドする⽅法 • 開発環境にデプロイしたブランチから、ステージング、本 番環境⽤ブランチへマージしてプッシュ • 各環境⽤ブランチのプッシュをトリガーに対応する環境へ デプロイする⽅式 ②テスト済みイメージを使い回す • 開発環境でテストしたイメージを使ってステージング環境、 本番環境にデプロイする ビルドするタイミングにより異なった イメージがビルドされる可能性有

Slide 59

Slide 59 text

#devio2020 59 Dockerfileにおけるイメージの同⼀性について Dockerfileのベースイメージは例えタグが同じでも中 ⾝が完全に同⼀という保証はない • タグの運⽤は各ベースイメージを提供している組織のポリ シーに依存 • 緊急性が⾼いセキュリティパッチなどはタグが変わらない 場合も • そもそもlatestのみ提供のベースイメージもある FROM alpine:3.12.0

Slide 60

Slide 60 text

#devio2020 60 別の環境にコンテナをデプロイする⽅法２種 ①コードベースを同じにして再度ビルドする⽅法 • 開発環境にデプロイしたブランチから、ステージング、本 番環境⽤ブランチへマージしてプッシュ • 各環境⽤ブランチのプッシュをトリガーに対応する環境へ デプロイする⽅式 ②テスト済みイメージを使い回す • 開発環境でテストしたイメージを使ってステージング環境、 本番環境にデプロイする こちらの⽅法を推奨

Slide 61

Slide 61 text

61 本番環境へのデプロイ ECSのBlue/Greenデプロイって 実際なにがどう便利なのか︖

Slide 62

Slide 62 text

#devio2020 62 本番環境デプロイの構成 本番環境の前提条件 • AWSアカウントは開発環境のアカウントとわける • テスト済みのコンテナイメージを利⽤する • デプロイ⽅法としてBlue/Greenデプロイを採⽤する • 承認ステージを設置する ここも重要な点

Slide 63

Slide 63 text

#devio2020 63 ECS（Blue/Green）デプロイの素敵なところ① テストリスナーにより本番環境でリリース対象タスクの 動作確認が可能 • テストリスナーに任意のポート（例︓8080）を設定 • ALBのセキュリティグループでソースIPを限定 • 本番トラフィックはオリジナル・バージョンに流しつつ、 同じデータと環境で、新バージョンの動作確認が可能

Slide 64

Slide 64 text

#devio2020 64 ECS（Blue/Green）デプロイの素敵なところ② ルーティング切替の⽅法を柔軟に設定可能 • CodeDeployデプロイ設定で事前定義されたルーティング の切替設定を利⽤可能。またカスタム定義もOK

Slide 65

Slide 65 text

#devio2020 65 ECS（Blue/Green）デプロイの素敵なところ③ 事故ったときの切り戻しが楽 • ロールバックがCodeDeployのコンソールから1クリック • ローリングデプロイ時のサービス定義更新、git revertし てからの再デプロイといった⼿間が不要 事故った時ボタン 正式リリースボタン

Slide 66

Slide 66 text

66 本番環境へのデプロイ 各ステージの詳細の説明

Slide 67

Slide 67 text

#devio2020 67 ソース部分の詳細

Slide 68

Slide 68 text

#devio2020 version: 0.0 Resources: - TargetService: Type: AWS::ECS::Service Properties: TaskDefinition: LoadBalancerInfo: ContainerName: "sample-website" ContainerPort: 80 68 ソース部分の構成（appspec.yml） • プレースホルダ。デプロイステージで⾃動的に対象のタスク定義 のバージョンに書き換わる

Slide 69

Slide 69 text

#devio2020 69 ソース部分の構成（taskdef.json） ECSのタスク定義 • 最初にタスク定義を登録 したのち、イメージURI をプレースホルダとして おく • CodePipelineの中のデ プロイステージで⾃動的 にURIが変更されタスク 定義が更新される { "executionRoleArn": "arn:aws:iam::629895769338:role/ecsTas kExecutionRole", "containerDefinitions": [ { "name": "sample-website", "image": "", "essential": true, "portMappings": [ { "hostPort": 80, "protocol": "tcp", "containerPort": 80 〜〜以下略〜〜

Slide 70

Slide 70 text

#devio2020 70 承認部分の詳細

Slide 71

Slide 71 text

#devio2020 71 承認部分の詳細 CodePipelineの承認ステージを利⽤して、デプロイパ イプラインを⽌める • 開発環境、ステージング環境、本番環境でアカウントをわけ る⼤きなメリットとして、権限管理が容易さがある • 承認の履歴やメッセージも残る • 承認プロセスはこの本番アカウントに対してアクセスするポ リシーを持った⼈のみが実施可能なため、⾃然とガバナンス が効く仕組みとなる

Slide 72

Slide 72 text

#devio2020 72 デプロイ部分の詳細

Slide 73

Slide 73 text

#devio2020 73 デプロイ部分の詳細 CodePipelineのデプロイステージで以下を設定 • Action provider︓ECS（Blue/Green） • 利⽤するCodeDeployのApplication Nameと deployment group • task def SourceArtifact︓taskdef.json • AppSpec SourceArtifact︓appspec.yaml • Input artifact︓ソースステージのECRイメージ名 • Placeholder text in task definition︓IMAGE1_NAME

Slide 74

Slide 74 text

#devio2020 74 ECRイメージの更新トリガーにデプロイが動く︕

Slide 75

Slide 75 text

#devio2020 75 リファレンス https://docs.aws.amazon.com/ja_jp/codepipeline/latest/userguide/tutorials-ecs-ecr-codedeploy.html

Slide 76

Slide 76 text

76 超素敵なBlue/Greenデプロイだけど ECS Blue/Greenデプロイには 制約もある

Slide 77

Slide 77 text

#devio2020 77 必ず事前に⽬をとおしておく https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/userguide/deployment-type- bluegreen.html#deployment-type-bluegreen-considerations

Slide 78

Slide 78 text

#devio2020 78 ECS（Blue/Green）デプロイの制約① Blue/Greenデプロイを使⽤する場合、Auto Scaling はサポートされない • Blue/Greenでのデプロイ中にスケーリングしたとき、 ルーティングができるイメージが沸かない… • 回避策として、サービスのデプロイ前後で、Auto Scaling グループのスケーリングプロセスを停⽌〜再開させる⽅法 あり • パイプラインのデプロイ前後でCodeBuildなどで application-autoscalingのregister-scalable-target、 APIを叩く

Slide 79

Slide 79 text

#devio2020 79 ECS（Blue/Green）デプロイの制約② キャパシティプロバイダーはサポートされない Fargate起動タイプ、またはCODE_DEPLOYデプロイ コントローラータイプのタスクは、DAEMONスケ ジューリング戦略をサポートしない

Slide 80

Slide 80 text

80 本番環境へのデプロイ もうあなたは ECSデプロイを思うがままに 操ることができます

Slide 81

Slide 81 text

#devio2020 81 ECSデプロイを極めるまで ECSデプロイの構造を理解する ECSデプロイのアンチパターンを理解する 開発環境にデプロイしてみる 本番環境にデプロイしてみる GitHub Actionsを使ってデプロイする IaC管理するリソースとの⽭盾に⽴ち向かう 基礎 必須 応⽤

Slide 82

Slide 82 text

82 GitHub Actionsを使ってデプロイする 最近流⾏りのGitHub Actions みなさんつかってますか︖ めっちゃ魅⼒的です︕︕

Slide 83

Slide 83 text

#devio2020 83 ECSデプロイにおけるGitHub Actionsの魅⼒ AWS公式ActionsにECS関連のものが多い • configure-aws-credentials • AWSへアクセスするときの権限管理が簡単。最⾼ • amazon-ecr-login • ECRにログイン • amazon-ecs-render-task-definition • タスク定義にイメージURIを挿⼊ • amazon-ecs-deploy-task-definition • タスク定義をデプロイ

Slide 84

Slide 84 text

#devio2020 84 amazon-ecs-render-task-definition デプロイ時に頻出するタスク定義のイメージURIの書き換えを Actionsで持っている。⾮常に便利

Slide 85

Slide 85 text

#devio2020 85 amazon-ecs-deploy-task-definition タスク定義のデプロイ⇢サービス定義の更新が可能。また、 CodeDeployにも対応しているのでappspec.jsonを使った ECSデプロイ（Blue/Green）もできる

Slide 86

Slide 86 text

86 GitHub Actionsを使ってデプロイする 承認フローがなかったりするけれど 仕組みでカバーできるので ⼗分にプロダクションでも 検討の余地あり

Slide 87

Slide 87 text

#devio2020 87 ECSデプロイを極めるまで ECSデプロイの構造を理解する ECSデプロイのアンチパターンを理解する 開発環境にデプロイしてみる 本番環境にデプロイしてみる GitHub Actionsを使ってデプロイする IaC管理するリソースとの⽭盾に⽴ち向かう 基礎 必須 応⽤

Slide 88

Slide 88 text

88 IaC管理している場合 ECSのタスク定義やサービスを IaC（Infrastructure as Code）で 管理している⼈ こんな悩みありますよね︖

Slide 89

Slide 89 text

#devio2020 89 IaCにおけるよくある事故 • CloudFormationでリソースを作る • なにかの拍⼦に誰かがWebコンソールから変更する • 次のスタック更新が正常に動かない（もしくは⼿動変 更分が巻き戻る） AWS CloudFormation template （JSON/YAML） Stack （リソース） Amazon EC2 変更するよ。ｷﾘｯ あれ、何この差分︖ エラーになるねんけど

Slide 90

Slide 90 text

#devio2020 90 ECSのデプロイでも同様のことがおこる • IaCで定義したサービス、タスク定義とアプリケー ションデプロイのライフサイクルは異なる • IaCのコードと整合性がとれない AWS CloudFormation template （JSON/YAML） Stack （リソース） ECS ⾃動デプロイやで タスク定義の イメージURI違うやん CodePipeline

Slide 91

Slide 91 text

91 結論 銀の弾丸はない

Slide 92

Slide 92 text

#devio2020 92 解決案 解決案①︓IaCでの全管理を諦める 解決案②︓タスク定義はプレースホルダを利⽤して管理 し、アプリケーションデプロイサイクルにのせる 解決案③︓Terraformのlifecycleブロックを使ってリ ソース差分を無視する

Slide 93

Slide 93 text

#devio2020 93 解決案① IaCでの全⾃動管理を諦める • 最初のプロビジョニングでのみ利⽤ • 更新はGUIを使うか変更点を⾃前で都度吸収

Slide 94

Slide 94 text

#devio2020 94 解決案② タスク定義はプレースホルダを利⽤して管理し、アプリ ケーションデプロイサイクルにのせる • GitHub Actionsのamazon-ecs-render-task-definitionや、 CodeDeployのtaskdef.jsonを使うと、リポジトリにあるタ スク定義を元にして、デプロイサイクルのなかでイメージ URIを埋めることが可能 • イメージURI以外のタスク定義プロパティ（CPU、メモリ、 環境変数等）の変更も、アプリケーションデプロイと同じラ イフサイクルで本番環境にデプロイしていく

Slide 95

Slide 95 text

#devio2020 95 解決案③ Terraformのlifecycleブロックを使ってリソース差分 を無視する • タスク定義のイメージURIや、サービスのタスクリビジョン のリソース差分を無視する設定にする • デプロイによりそれらプロパティが変わっても変更検知され ないし、TerraformでApplyできる︕ • CloudFormationではおそらくできない…

Slide 96

Slide 96 text

96 まとめ

Slide 97

Slide 97 text

#devio2020 97 まとめ 各組織がもつポリシーやアプリケーション特性により ECSデプロイの理想の形は様々

Slide 98

Slide 98 text

#devio2020 98 まとめ 各組織がもつポリシーやアプリケーション特性により ECSデプロイの理想の形は様々 コンテナ運⽤の原則におけるアンチパターンはある

Slide 99

Slide 99 text

#devio2020 99 まとめ 各組織がもつポリシーやアプリケーション特性により ECSデプロイの理想の形は様々 コンテナ運⽤の原則におけるアンチパターンはある アンチパターンをさけつつ、効率良いデプロイパターン を構築するための参考にしていただければ幸いです

Slide 100

Slide 100 text

100 One more thing...

Slide 101

Slide 101 text

#devio2020 101 ⾃⼰紹介 濱⽥孝治（ハマコー） •2017年9⽉⼊社（元独⽴系SIer） •AWS事業本部コンサルティング部 →New! CX事業本部 MADチーム

Slide 102

Slide 102 text

#devio2020 102 まとめ

Slide 103

Slide 103 text

#devio2020 103 まとめ

Slide 104

Slide 104 text

#devio2020 104 まとめ サーバーレス コンテナ専⾨の 開発集団

Slide 105

Slide 105 text

#devio2020 105 気になったらどうぞ クラスメソッド MAD

Slide 106

Slide 106 text

セッション後はアンケートへのご協力をよろしくお願いします。 ご回答いただいた方には後日、資料を送付いたします。 SNS投稿にはこちらをお使いください。 #devio2020 イベントのポータルサイトはこちら https://classmethod.jp/m/devio_2020_connect/ ライブセッション録画もこちらから 視聴できます。 https://forms.gle/WeMoFinWLLzbGrA37 14:00〜14:45 「あなたの組織に最適なコンテナデプロイ方法とは？ 〜ECSにおけるデプロイ最新機能てんこ盛り〜」 のアンケートはこちらからお願いします。 Q&A Q&A