Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

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

荻原利雄
September 18, 2023

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

荻原利雄

September 18, 2023
Tweet

More Decks by 荻原利雄

Other Decks in Programming

Transcript

  1. 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 再掲
  2. 対応後のサンプルアプリ 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は任意の設定源に設定可能
  3. サンプルアプリの設定の上書き実行 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した後の操作 ▪ デフォルト設定でのコンテナ起動 ▪ 設定を変更してコンテナ起動
  4. 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してないの?
  5. latestタグが更新されない理由 8 さっきの答えは ➢ docker pullはリモートリポジトリを常に見に行くがdocker runはローカルリポジトリに該当イメージがないときだけしか リモートリポジトリは見に行かない ➢ よってdocker

    runでローカルリポジトリにlatestのイメージがある場合、latestが更新されない latestタグを使うとより深刻な問題が 起きる可能性があります。それはなんで しょうか?
  6. latestタグの問題(あまり使っちゃダメ) 9 latestタグの対象は移動する。なので ➢ 断面が不定になる • kubernetesやECSなどのコンテナオーケストレーションが持つ指定した断面に環境を戻すrollbackができなくな る ➢ 異なるバージョンが混じる

    ➢ コンテナオーケストレーションでオートスケールやオートヒーリングされたときのlatestは既にデプロイされているコンテ ナイメージと異なっている可能性がある ➢ これによりクラスタを構成するコンテナインスタンスごとに挙動が変わってしまう恐れがある サンプルではコンテナイメージをピンポイントで指定できるようにタイムスタンプのタグをつけている dockerイメージをリポジトリ管理する際のタグ戦略は非常に重要となる (他のタグ戦略としては通番を振ったりコミットハッシュを使ったりするのが典型)
  7. 典型的な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が異なっても取得方法は基本的に統一でき ます -Ⅲ 設定-
  8. ECS Fargateとは 13 Amazon Elastic Container Service (Amazon ECS) は、コンテナ化されたアプリケーションのデプロイ、

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

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