第6回 AWSとGitHub勉強会 - AWS ECS Fargate環境の構築 -

Transcript

1. AWSとGitHubを使ってみよう勉強会
   ~ 第6回 AWS ECS Fargate環境の構築 ~
   株式会社 豆蔵
   ビジネスソリューション事業部
   updated:2023/9/18
   

   View Slide

2. 本日の内容
   • 前回の課題の解説(60分)
   ※「前回の課題の回答」は解説の中で一緒に説明します
   2
   画面キャプチャやコマンド操作等はGitHubのssi-
   mz-studygroupユーザで行った例となります。キャ
   プチャやコマンド等の該当部分は自分のユーザIDに
   読み替えてください
   ・ssi:simple server infra
   ・mz:mamezou
   

   View Slide

3. 3
   前回の課題の解説
   ・サンプルアプリの設定による動作変更
   ・課題の全体像とECS Fargateとは
   

   View Slide

4. Step1. REST APIで返す値を環境変数で指定できるようにサンプル
   アプリを修正する
   • 変更内容
   • 環境変数CONFIG_VALの設定が
   • ある場合は、その設定値をREST APIで返す
   • ない場合は、デフォルト値として“Hello"
   • 変更方法
   • MicroProfile Configを使って設定ファイルの設定値を環境変数で上書きできるようにする
   • MicroProfile Configについては以下を参照
   • https://developer.mamezou-tech.com/msa/mp/cntrn06-mp-config/
   • ご自身でやってもらう方がいいと思いいますがMicroProfileは目的外なので、ひな形リポジトリに回答例
   をアップしています
   • src/main/java/sample/HelloResource.java(変更)
   • src/main/resources/META-INF/microprofile-config.properties(追加)
   • src/test/java/sample/HelloResourceTest(変更)
   4
   再掲
   

   View Slide

5. 対応後のサンプルアプリ
   5
   import
   org.eclipse.microprofile.config.inject.ConfigProperty;
   …
   @ApplicationScoped
   @Path("hello")
   public class HelloResource {
   @Inject
   @ConfigProperty(name = "config.val")
   private String configValue;
   @Produces(MediaType.TEXT_PLAIN)
   public String hello() {
   return configValue;
   }
   }
   config.val=Hello
   ・/META-INF/microprofile-config.properties
   ・環境変数
   CONFIG_VAL=Chanaged
   override
   injection
   • 同じキーが設定されている場合、優先度が高い設
   定源が優先される
   • 環境変数は英字は小文字、記号は.(ドット)に置
   換した変数としても評価される
   MicroProfile Configの機能を利用
   設定源 優先度
   システムプロパティ 400
   環境変数 300
   /META-INF/microprofile-config.properties 100
   config_ordinalが設定されている設定源 config_ordinalの値
   ※config_ordinalは任意の設定源に設定可能
   

   View Slide

6. サンプルアプリの設定の上書き実行
   6
   # 最新のコンテナイメージの取得
   sudo docker pull ghcr.io/[自分のGitHubユーザ名]/hello-app:latest
   # コンテナの起動
   sudo docker run -d --rm --name hello-app -p 7001:7001 ghcr.io/[自分のGitHubユーザ名]/hello-app:latest
   # 起動ログの確認
   sudo docker logs hello-app
   # レスポンスの確認
   curl localhost:7001/api/hello
   > Helllo
   # コンテナの起動
   sudo docker run -d --rm --name hello-app -p 7001:7001 -e CONFIG_VAL=Changed ghcr.io/[自分のGitHubユーザ名]/hello-
   app:latest
   # 起動ログの確認
   sudo docker logs hello-app
   # レスポンスの確認
   curl localhost:7001/api/hello
   > Changed
   ※GitHub Actionsでサンプルアプリをコンテナイメージにビルドしてコンテナレジストリにpushした後の操作
   ■ デフォルト設定でのコンテナ起動
   ■ 設定を変更してコンテナ起動
   

   View Slide

7. latestタグのpullは意味あるの？
   7
   # 最新のコンテナイメージの取得
   sudo docker pull ghcr.io/[自分のGitHubユーザ名]/hello-app:latest
   # コンテナの起動
   sudo docker run -d --rm --name hello-app -p 7001:7001 ghcr.io/[自分のGitHubユーザ名]/hello-app:latest
   # 起動ログの確認
   sudo docker logs hello-app
   # レスポンスの確認
   curl localhost:7001/api/hello
   > Helllo
   # コンテナの起動
   sudo docker run -d --rm --name hello-app -p 7001:7001 -e CONFIG_VAL=Changed ghcr.io/[自分のGitHubユーザ名]/hello-
   app:latest
   # 起動ログの確認
   sudo docker logs hello-app
   # レスポンスの確認
   curl localhost:7001/api/hello
   > Changed
   ■ デフォルト設定でのコンテナ起動
   ■ 設定を変更してコンテナ起動
   docker runで一緒にpull
   してくれるのにわざわざpullす
   る必要あるの？
   こっちではなんでdocker
   pullしてないの？
   

   View Slide

8. latestタグが更新されない理由
   8
   さっきの答えは
   ➢ docker pullはリモートリポジトリを常に見に行くがdocker runはローカルリポジトリに該当イメージがないときだけしか
   リモートリポジトリは見に行かない
   ➢ よってdocker runでローカルリポジトリにlatestのイメージがある場合、latestが更新されない
   latestタグを使うとより深刻な問題が
   起きる可能性があります。それはなんで
   しょうか？
   

   View Slide

9. latestタグの問題（あまり使っちゃダメ）
   9
   latestタグの対象は移動する。なので
   ➢ 断面が不定になる
   • kubernetesやECSなどのコンテナオーケストレーションが持つ指定した断面に環境を戻すrollbackができなくな
   る
   ➢ 異なるバージョンが混じる
   ➢ コンテナオーケストレーションでオートスケールやオートヒーリングされたときのlatestは既にデプロイされているコンテ
   ナイメージと異なっている可能性がある
   ➢ これによりクラスタを構成するコンテナインスタンスごとに挙動が変わってしまう恐れがある
   サンプルではコンテナイメージをピンポイントで指定できるようにタイムスタンプのタグをつけている
   dockerイメージをリポジトリ管理する際のタグ戦略は非常に重要となる
   （他のタグ戦略としては通番を振ったりコミットハッシュを使ったりするのが典型）
   

   View Slide

10. 典型的なJakartaEEフルスタックなWebアプリ
    JSF(+CDI) CDI JPA(+CDI)
    コンテナで環境変数の利用は定石- MicroProfile Config 登場背景
    • JakartaEEには設定ファイルに対する共通的な仕様が定義されてい
    ない
    • web.xmlやbeans.xml, persistence.xmlなど仕様ごとに必要
    な設定ファイルが存在する（徐々にアノテーションでも定義できるよう
    になってはきてはいる）
    • アプリケーション全体レベルでの設定の見通しが悪く、設定漏れや配
    置漏れも起きやすくハッキリいって不便（Springの
    application.ymlが裏山）
    10
    Configに対する2つのモチベーション
    多すぎる設定ファイル
    CloudNativeへの追従
    • マイクロサービスアーキテクチャのbest practiceとして知られるThe
    Twelve-Factor Appの“Ⅲ 設定”では「設定を環境変数に格納
    する」ことを推奨している
    • これまでJakartaEEの仕様でこれを実現できるものはなかった
    (SpringBootでは普通にできるけど)
    web.xml
    persistence.xml
    beans.xml
    orm.xml
    presentation
    faces-config.xml
    business
    beans.xml
    integration
    beans.xml
    多すぎ、散らばりすぎ、勘弁して・・
    引用:Twelve-Factor Appを噛み砕いてみた - Qiita @supreme0110
    ✓ 設定はコードや設定ファイルに含めず、環境変数で設定するようにし
    ましょう。
    ✓ なぜならコードに含めてしまうと環境ごとにビルドが必要になり、設定
    ファイルの場合は環境ごとにファイルが必要となりスケールしにくくなる
    ためです。
    ✓ 環境変数であればOSが異なっても取得方法は基本的に統一でき
    ます
    -Ⅲ 設定-
    

    View Slide

11. 11
    前回の課題の解説
    ・サンプルアプリの設定による動作変更
    ・課題の全体像とECS Fargateとは
    

    View Slide

12. これでまでの課題でやってきた全体像 – 振り返り
    ✓ コンテナの実行環境がEC2からECSに替わっただけ
    ✓ だがしかし、EC2で行っていたDocker環境の構築やコンテナの起動停止の運用周りは一切不要に
    全体として変わっ
    たのはここだけ
    ECSが勝手
    に取ってきてく
    れる
    

    View Slide

13. ECS Fargateとは
    13
    Amazon Elastic Container Service (Amazon
    ECS) は、コンテナ化されたアプリケーションのデプロイ、
    管理、スケーリングを容易にするフルマネージドコンテナ
    オーケストレーションサービスです。※AWS公式の完全
    引用
    ＜ECSとは＞
    コントロールプレーン：
    必要なリソースを決定し、必要な場所
    で実行・管理する基盤
    データプレーン：
    リソースを指示されたとおりに実行す
    る基盤
    AWS Fargate はAmazon ECSで使用できるテクノロジーであり、サーバーやAmazon
    EC2インスタンスのクラスターを管理することなくコンテナを実行できます。Fargate を使用
    すると、コンテナを実行するために仮想マシンのクラスターをプロビジョニング、設定、スケール
    する必要はありません。
    これにより、サーバータイプの選択、クラスターをスケールするタイミングの決定、クラスターの
    パッキングの最適化を行う必要がなくなります。
    ※AWS公式の完全引用
    ⇒要はECSのデータプレーンに使えるサーバレス環境。EKSでも利用可
    ＜Fargateとは＞
    データプレーンにEC2を使った
    パターン
    

    View Slide

14. クラスター／サービス／タスク
    14
    ■クラスター
    • ECSリソースを管理するための論理グループ
    （なだけ）
    ■サービス
    • ECS（コントロールプレーン）の実体
    • タスクを監視しサービスで定義された状態を維
    持するようにタスクのローリングアップデートや
    オートスケール、オートヒーリングなど行う
    ■タスク定義
    • なにを（コンテナイメージ）どのように（割り
    当てマシンリースや環境変数など）動作させ
    るかを定義したもの
    • 定義は世代ごとに管理される
    ■タスク
    • タスク定義をもとにサービスにより実体化され
    たもの（サービスにより割り当てられた実行環
    境でコンテナが実行されている）
    

    View Slide

15. 15
    実際にやってみる
    

    View Slide

16. クラウド環境ではログの出力先は標準出力が基本
    16
    ✓ファイル出力ではなく標準出力に出力させ、ツールで1箇所に集約するようにしましょう。
    ✓なぜならスケールイン時に仮想サーバごと消える可能性があることと、環境(OS、IDE、ロー
    カル/本番)が異なっても標準出力は常に行えるためです。
    -Ⅺ.ログ-
    ⇒そもそもサーバーレスでは基本的にローカルディスクは使えない
    引用:Twelve-Factor Appを噛み砕いてみた - Qiita @supreme0110
    

    View Slide

17. 17
    おしまい。お疲れまでした
    

    View Slide