Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Introduction to Amazon ECS and AWS Copilot for Container Beginners on AKIBA.AWS ONLINE #2

Introduction to Amazon ECS and AWS Copilot for Container Beginners on AKIBA.AWS ONLINE #2

クラスメソッド株式会社が主催するAWSのオンライン勉強会 AKIBA.AWS #2 ONLINE で発表された「今すぐコンテナを使い始めたい人のためのAmazon ECSとAWS Copilot」の登壇資料です。

"Introduction to Amazon ECS and AWS Copilot for Container Beginners" on AKIBA.AWS ONLINE #2.

2f73f93f91c4401b0baf12029226a681?s=128

TERAOKA Keisuke

April 22, 2021
Tweet

Transcript

  1. 今すぐコンテナを使い始めたい人のための
 Amazon ECSとAWS Copilot
 2021/4/21(水)
 AWS事業本部コンサルティング部 寺岡慶佑
 1

  2. 2 本発表の目標 コンテナを初めて触る人が Amazon ECSとAWS Copilotを通じて コンテナの本番運用を始められるようにする

  3. 3 本発表の目標 想定する対象者 • アプリケーションを開発しているが、コンテナは使ったことがない • AWSでインフラの構築や運用をしているが、コンテナは使ったこと がない • アプリケーションをコンテナで開発しているが、コンテナの本番運

    用はできていない
  4. 4 本発表の目標 想定する対象者 • 「docker run」から「コンテナの本番利用」までの間に距離を感じて いる ◦ コンテナやDockerについてなんとなく知っている ◦

    docker build / docker run など基本的なコマンドは触ったことがある ◦ しかし、本番稼働するアプリケーションをコンテナで動かすためのステッ プがイメージできていない人
  5. 5 本発表で話さないこと

  6. 6 本発表で話さないこと • コンテナ技術やDockerの詳細 • Amazon ECS と Amazon EKS(Kubernetes)の比較

    • AWS Copilot と他のECSデプロイツールの比較 ◦ ecs-deploy、ecspressoなど ◦ 下記の資料が参考になります ▪ https://speakerdeck.com/toricls/the-easiest-deployment-championship-2020-find-your- winner-for-aws-fargate ▪ https://dev.classmethod.jp/articles/awsdevday2020-deploy-fargate-easily/
  7. 7 発表者紹介 寺岡 慶佑(TERAOKA Keisuke) • 2020年11月入社 • 好きなAWSサービス ◦

    AWS App Mesh ◦ Amazon EKS • 趣味 ◦ 紅茶 ◦ ビール @toda_kk(とばち) @tobachi
  8. 8 アジェンダ 1. コンテナを動かしてみる 2. コンテナオーケストレーション 3. AWS Copilotを用いたECS構築 4.

    AWS Copilotの活用例
  9. 9 1. コンテナを動かしてみる

  10. 10 まず前提として コンテナ利用 ≠ コンテナオーケストレーション利用

  11. 11 さらに言えば コンテナ利用 ≠ マイクロサービスアーキテクチャ構築

  12. 12 コンテナを動かしてみる コンテナを動かすだけならEC2インスタンスでもできる • ECSもKubernetesも必要ない • Fargateも必要ない $ docker pull

    nginx:latest $ docker run -it -p 80:80 nginx:latest $ curl http://localhost:80
  13. 13 EC2インスタンスでコンテナを動かしてみる $ docker pull nginx:latest $ docker run -d

    -p 80:80 nginx:latest
  14. 冪等性・可搬性 • 同じコンポーネントをすぐに配れる ◦ 異なる環境で動かせる 14 改めて、コンテナのメリット Docker Hub Elastic

    Container Registory (ECR) d
  15. 隔離性 • コンテナはプロセスとして独立して起動する ◦ プロセスごとにコンピューターリソースを隔離することで、柔軟に割り当 てることができる 15 改めて、コンテナのメリット Container Process

    01 vCPU: 256 Memory: 512MB Container Process 02 vCPU: 512 Memory: 512MB Container Process 03 vCPU: 512 Memory: 1024MB
  16. コンテナ利用によって得られる効果 • 開発効率の向上 • デプロイフローの自動化 ◦ インフラのコード化(IaC)やCI/CD構築が容易になる • インフラコストの削減 など

    16 改めて、コンテナのメリット
  17. 17 コンテナ利用のその先へ その次の段階として、 コンテナオーケストレーションや マイクロサービスアーキテクチャが 登場する

  18. 18 2. コンテナオーケストレーション

  19. コンテナ利用に特化した形でシステムを構築するための サービスおよびツール群 • コンピューターリソースの割り当て • オートスケーリング • コンテナの自動復旧 • コンテナ間の通信

    • デプロイ戦略の実装 • ログ、メトリクスの取得 など 19 コンテナオーケストレーションとは?
  20. いくつかのサービスがある • Amazon ECS • Kubernetes ◦ Amazon Elastic Kubernetes

    Service(EKS) ◦ Google Kubernetes Engine(GKE) ◦ Azure Kubernetes Service(AKS) • Red Hat OpenShift? • Docker Swarm?? 20 コンテナオーケストレーションとは?
  21. Amazon ECSのメリット • オーケストレーションサービスそのものの運用をAWS側でやってく れる ◦ アップデートなどを考えなくて済む • コンテナに関連するECS以外のAWSリソースの利用が容易 ◦

    Elastic Load Balancing ◦ IAMロール ◦ セキュリティグループ など 21 今回はAmazon ECSを紹介
  22. 22 3. AWS Copilotを用いたECS構築

  23. ECSの概念を抽象化し構築を容易にするツール • ECSの概念をあまり理解していなくても利用できる ◦ インフラを構築しないアプリケーション開発者にとって環境構築が容易 になる ▪ もちろん、インフラ構築・運用者はある程度は理解しておくべき ▪ アプリケーション開発者が全く理解しなくて良い、ということでもない

    • Application/Environment/Service という直感的に理解しやすい形 で抽象化している ◦ ECSの概念は Cluster/Service/Task という構造になっている ◦ それぞれ設定が必要になるが、初めはハマりやすい ▪ VPCやサブネットやセキュリティグループの指定 ▪ IAMロールやログの設定 ▪ サービス定義、タスク定義...... 23 ECS構築を容易にするAWS Copilot
  24. ECSに関連するAWSリソースを作成するツール • ECSリソースを作成するだけでなく、関連するAWSリソースも同時 に作成してくれる ◦ VPC、サブネット、NATゲートウェイ、ルートテーブル ◦ Application Load Balancer

    ◦ Elastic Container Registory • CI/CDパイプライン構築やスケジュールタスク実行の設定も容易 に実現できる 24 ECS構築を容易にするAWS Copilot
  25. 直感的に理解しやすい構造 • Application ◦ 構築するシステム全体をグルーピングした概念 ◦ FrontendサービスとAPIサービスを複数もつようなマイクロサービス群の 単位 ▪ e.g.

    ECサイト用のApplication • 顧客向け画面を描画するサービス • 管理者向け画面を描画するサービス • 商品情報を検索して取得するサービス • 会員情報を更新するサービス • ...といったサービス群で構成される ◦ EnvironmentとServiceを内包している 25 Copilotの基本的な概念
  26. 直感的に理解しやすい構造 • Environment ◦ サービス群を起動する環境 ▪ e.g. Production / Staging

    / Development ... ◦ AWSアカウントやVPCといった単位でEnvironmentを分割し、作成するリ ソースを環境ごとに隔離できる 26 Copilotの基本的な概念
  27. 直感的に理解しやすい構造 • Service ◦ Applicationの個々の構成要素としてのサービス ◦ タイプ1: Load Balanced Web

    Service ▪ インターネット経由でアクセスできるサービス ▪ Application Load Balancer(internet-facing)の後段に配置される ◦ タイプ2: Backend Service ▪ インターネットから直接アクセスできず、VPC内部の通信で利用するサービス ◦ Serviceを作成することで、ECSリソースだけでなく関連する他のAWSリ ソースも同時に作成できる ▪ Load Balanced Web Serviceの初回実行時にALBが作成される ▪ Backend Serviceをプライベートサブネットで実行するとNATゲートウェイが作成される など 27 Copilotの基本的な概念
  28. 28 CopilotでECSを構築してみる

  29. 29 構築するサービス構成 VPC private subnet group public subnet group Application

    Load Balancer ECS Internet GW NAT GW web (Load Balanced Web Service) backend (Backend Service) ECR VPC private subnet group public subnet group Application Load Balancer ECS Internet GW NAT GW backend (Backend Service) production (Environment) staging (Environment) web (Load Balanced Web Service) sample-app (Application)
  30. サンプルサービス • https://github.com/tobachi/aws-copilot-sample-service 30 CopilotでECSを構築してみる $ cat nginx/Dockerfile FROM nginx:latest

    RUN rm /etc/nginx/conf.d/*.conf COPY conf.d/*.conf /etc/nginx/conf.d/ CMD nginx -g "daemon off;" $ cat nginx/conf.d/app.conf server { location /actuator/health { proxy_pass http://backend.sample-app.local:80; } location / { return 200 "OK"; add_header Content-Type text/plain; } } Nginx (Load Balanced Web Service) backendを指定
  31. サンプルサービス • https://github.com/tobachi/aws-copilot-sample-service 31 CopilotでECSを構築してみる $ cat app/Dockerfile FROM amazoncorretto:11-alpine

    VOLUME /tmp COPY build/libs/*.jar app.jar ENTRYPOINT ["java","-jar","/app.jar"] $ cd app/ $ ./gradlew build $ docker build -t aws-copilot-sample-service/app . $ docker run -d -p 80:80 aws-copilot-sample-service/app $ curl http://localhost:80/actuator/health {"status":"UP"} Spring Boot Application (Backend Service) ヘルスチェック用の パスを用意
  32. copilot init • Copilotのメタデータを管理するためのAWSアカウント(プロファイル)を指定 し、ApplicationとServiceを設定する 32 CopilotでECSを構築してみる $ copilot init

    Application name: sample-app Workload type: Backend Service Service name: backend Dockerfile: app/Dockerfile no EXPOSE statements in Dockerfile app/Dockerfile $ tree copilot copilot └── backend └── manifest.yml manifest.yml ファイルが作成される ここでは Backend Serviceを指定
  33. copilot env init • Environmentを指定する 33 CopilotでECSを構築してみる $ copilot env

    init --name staging Which credentials would you like to use to create staging? [profile default] Would you like to use the default configuration for a new environment? - A new VPC with 2 AZs, 2 public subnets and 2 private subnets - A new ECS Cluster - New IAM Roles to manage services and jobs in your environment Yes, use default. ✔ Linked account 123456789012 and region ap-northeast-1 to application sample-app. ✔ Proposing infrastructure changes for the sample-app-staging environment. ✔ Created environment staging in region ap-northeast-1 under application sample-app. AWSリソース作成 • VPC、サブネット • ECSクラスター • IAMロール
  34. copilot svc deploy • EnvironmentとServiceを指定してECS環境にデプロイする 34 CopilotでECSを構築してみる $ copilot svc

    deploy --name backend --env staging [+] Building 3.5s (8/8) FINISHED Login Succeeded The push refers to repository [123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/sample-app/backend] ✔ Proposing infrastructure changes for stack sample-app-staging-backend - Creating the infrastructure for stack sample-app-staging-backend - Service discovery for your services to communicate within the VPC - Update your environment's shared resources - An IAM Role for the Fargate agent to make AWS API calls on your behalf - A CloudWatch log group to hold your service logs - An ECS service to run and maintain your tasks in the environment cluster - An ECS task definition to group your containers and run them on ECS - An IAM role to control permissions for the containers in your tasks ✔ Deployed backend. コンテナイメージを buildしてECRにpush AWSリソースを更新 • Service discovery(Cloud Map、Route 53) • CloudWatch Logs • ECSサービス、タスク
  35. copilot svc status • 起動中のServiceを確認する 35 CopilotでECSを構築してみる $ copilot svc

    status --name backend --app sample-app --env staging Service Status ACTIVE 1 / 1 running tasks (0 pending) Last Deployment Updated At xx minutes ago Task Definition arn:aws:ecs:ap-northeast-1:123456789012:task-definition/sample-app-staging-backend:1 Task Status ID Image Digest Last Status Started At Stopped At Health Status -- ------------ ----------- ---------- ---------- ------------- 1234abcde abcd1234 RUNNING xx minutes ago - UNKNOWN Alarms Name Condition Last Updated Health ---- --------- ------------ ------ タスク定義を作成、 タスクを1つ起動
  36. 36 構築できたサービス構成 ECR VPC private subnet group public subnet group

    ECS Internet GW staging (Environment) backend (Backend Service) sample-app (Application)
  37. manifest.ymlの更新(オプション) • Backend ServiceのService Discoveryを有効にする $ vi copilot/backend/manifest.yml name: backend

    type: Backend Service image: build: app/Dockerfile port: 80 cpu: 256 # Number of CPU units for the task. memory: 512 # Amount of memory in MiB used by the task. count: 1 # Number of tasks that should be running in your service. exec: true # Enable running commands in your container. 37 CopilotでECSを構築してみる コンテナイメージの 起動ポートを明示的に 指定する必要がある
  38. manifest.ymlの更新(オプション) • Backend Serviceをプライベートサブネットに配置する $ vi copilot/backend/manifest.yml name: backend type:

    Backend Service image: build: app/Dockerfile port: 80 cpu: 256 # Number of CPU units for the task. memory: 512 # Amount of memory in MiB used by the task. count: 1 # Number of tasks that should be running in your service. exec: true # Enable running commands in your container. network: vpc: placement: 'private' 38 CopilotでECSを構築してみる network.vpc.placement 設定を追加
  39. manifest.ymlの更新(オプション) • 再度 copilot svc deploy を実行するとECSサービスに反映される $ copilot svc

    deploy --name backend --app sample-app --env staging - Updating the infrastructure for stack sample-app-staging-backend - Update your environment's shared resources - NAT Gateway 2 enabling workloads placed in private subnet 2 to reach the internet - NAT Gateway 1 enabling workloads placed in private subnet 1 to reach the internet ✔ Deployed backend, its service discovery endpoint is backend.sample-app.local:80. 39 CopilotでECSを構築してみる
  40. 40 構築できたサービス構成 ECR VPC private subnet group public subnet group

    ECS Internet GW NAT GW backend (Backend Service) staging (Environment) sample-app (Application)
  41. Load Balanced Web Serviceの作成 • copilot svc init でLoad Balanced

    Web Serviceを指定する 41 CopilotでECSを構築してみる $ copilot svc init --name web --app sample-app Workload type: Load Balanced Web Service Dockerfile: nginx/Dockerfile no EXPOSE statements in Dockerfile nginx/Dockerfile Port: 80 $ tree copilot copilot └── backend └── manifest.yml └── web └── manifest.yml manifest.yml ファイルが作成される Load Balanced Web Service ではデフォルトで ポート80が指定される
  42. Load Balanced Web Serviceの作成 • copilot svc deploy でサービス名を指定して実行 42

    CopilotでECSを構築してみる $ copilot svc deploy --name web --app sample-app --env staging ✔ Deployed web, you can access it at http://sampl-Publi-0ABCDEFGHIJKL-1234567890.ap-northeast-1.elb.amazonaws.com. $ curl http://sampl-Publi-0ABCDEFGHIJKL-1234567890.ap-northeast-1.elb.amazonaws.com OK $ curl http://sampl-Publi-0ABCDEFGHIJKL-1234567890.ap-northeast-1.elb.amazonaws.com/actuator/health {"status":"UP"} ALB -> web -> backend 接続確認 ALB -> web 接続確認
  43. 43 構築できたサービス構成 ECR VPC private subnet group public subnet group

    Application Load Balancer ECS Internet GW NAT GW backend (Backend Service) staging (Environment) web (Load Balanced Web Service) sample-app (Application)
  44. Environmentの追加作成 • copilot env init でproductionを追加してServiceをデプロイ 44 CopilotでECSを構築してみる $ copilot

    env init --name production --app sample-app $ copilot env ls staging production $ copilot svc deploy --name backend --app sample-app --env production $ copilot svc deploy --name web --app sample-app --env production
  45. 45 構築できたサービス構成 VPC private subnet group public subnet group Application

    Load Balancer ECS Internet GW NAT GW web (Load Balanced Web Service) backend (Backend Service) ECR VPC private subnet group public subnet group Application Load Balancer ECS Internet GW NAT GW backend (Backend Service) production (Environment) staging (Environment) web (Load Balanced Web Service) sample-app (Application)
  46. Copilotは、実態としてはCloudFormationテンプレートを作成 して実行している • 実際にServiceを作成するテンプレートについては copilot svc package で内容を確認できる 46 Copilotによって作成されるリソース

    $ copilot svc package --name web --app sample-app --env staging --output-dir ./infrastructure $ tree infrastructure infrastructure ├── web-staging.params.json └── web-staging.stack.yml テンプレートと パラメーターを ファイルに出力できる
  47. CopilotのメタデータはSystems Manager Parameter Storeに 保存される • /copilot/applications/${app_name} にJSON形式で保存される 47 Copilotによって作成されるリソース

  48. 48 4. AWS Copilotの活用例

  49. できること • Pipelineを利用したCI/CDパイプライン構築 ◦ AWS CodePipelineを容易に構築できる ◦ GitソースとしてGitHub、Bitbucket、CodeCommitに対応 ◦ Environmentごとに異なる操作を設定できる

    • Jobを利用したFargateのタスクスケジュール実行 • クロスアカウント対応 ◦ 環境構築するAWSアカウントをEnvironmentごとに設定できる • CloudFormationテンプレートを利用したリソース作成 ◦ Copilotで直接作成できないAWSリソースでも、addonsという形で CloudFormationテンプレートを利用してCopilotと連携できる ▪ https://aws.github.io/copilot-cli/docs/developing/additional-aws-resources/ 49 Copilotの機能で実現できること
  50. ケース1: AWSインフラに詳しくないアプリケーション開発者 に、開発用の環境を自由に構築してもらう • 各EnvironmentがどのようなAWSリソース上に配置されているの か、あまり意識しなくて良い ◦ Copilotで作成されるリソースは命名規則が決まっているため、IAMポリ シーで操作を許可するリソースを指定しやすい ◦

    開発者やチームごとで利用できるEnvironmentを決めておき、適切な権 限を付与することで、環境を自由に構築してもらう • Fargateの docker exec 対応により、コンテナ実行におけるトラブル シュートが容易になった ◦ copilot svc exec でコマンド実行可能 50 Copilotの活用例
  51. ケース2: PoCやMVPアプリケーションの構築 • ECSを容易に導入できることで、検証や開発をスピーディに実施で きる ◦ IaCツールの利用は、ツールそのものやAWSサービスについてある程度 の知見が必要になってしまう ▪ 既にインフラリソースがコード化されており流用できるなら問題ない

    • Pipelineの利用によりCI/CD構築が容易になり改善サイクルをス ピーティに回せる • Copilotの設定からCloudFormationテンプレートが作成されるた め、アプリケーションの成熟後にデプロイツールを変更したい場 合でも容易に対応できる 51 Copilotの活用例
  52. 52 Copilotの活用例 もちろん、銀の弾丸ではない

  53. できないこと • EC2インスタンスを利用できない(Fargateのみ) • 既存のECSクラスター/サービス/タスク定義をCopilotでは利用でき ない ◦ 既にECSで起動しているアプリケーションをCopilotで管理するためには 工夫が必要 •

    Load Balanced Web Serviceで既存のALBを利用できない • NLBや内部通信のALBに対応していない • CloudFormationと連携できるが、複雑なことをやろうとすると CloudFormationの知見がどうしても必要になる など 53 Copilotの機能で実現できないこと
  54. CopilotだけでECSの全てを解決することはできない • 既存/新規アプリケーションの本番運用をCopilotだけで実現す るべきかどうか、検討が必要になる • ユースケースに合わせて適切なツールを選定し利用することが 重要 ◦ Copilot以外のECSデプロイツールやCI/CDサービス、IaCツール、独自ス クリプト

    など ◦ それぞれメリット/デメリットを理解した上で、Copilotと組み合わせたり、 Copilotを代替することを検討する 54 Copilotと他ツールを組み合わせる
  55. 55 本発表のまとめ

  56. • コンテナ利用の最初のステップとして、EC2でコンテナを起動する ことを目指す ◦ その次のステップとして、コンテナオーケストレーションの導入を検討す る • Copilotを利用することでECS構築を容易にすることができる ◦ ECSの概念を

    Application/Environment/Service として直感的に理解しや すい形で抽象化している • Copilotの活用例として、適切な権限設定による開発者体験の向 上や、スピーディな改善サイクルの実現が考えられる • ユースケースに合わせて、他のツールと組み合わせることを検討 する 56 本発表のまとめ
  57. 57 本発表のまとめ AWS Copilotで 良きコンテナライフを

  58. 58 参考資料 • AWS Copilot公式ドキュメント ◦ https://aws.github.io/copilot-cli/docs/overview/ • これから始めるコンテナワークロード -

    コンテナ化ベストプラクティ ス ◦ https://www.slideshare.net/AmazonWebServicesJapan/20190521 • Copilotによるお手軽3分ECSクッキング ◦ https://jawssonic2020.jaws-ug.jp/2020/08/17/post-175/ • 基礎から応用までじっくり学ぶECS Fargateを利用したコンテナ環 境構築 ◦ https://dev.classmethod.jp/articles/developers-io-2020-connect-kaji-ecs -fargate/
  59. 59