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

Transcript

1. AWSとGitHubを使ってみよう勉強会 ~ 第6回 AWS ECS Fargate環境の構築 ~ 株式会社 豆蔵 ビジネスソリューション事業部 updated:2023/9/18
2. 本日の内容 • 前回の課題の解説(60分) ※「前回の課題の回答」は解説の中で一緒に説明します 2 画面キャプチャやコマンド操作等はGitHubのssi- mz-studygroupユーザで行った例となります。キャ プチャやコマンド等の該当部分は自分のユーザIDに 読み替えてください ・ssi:simple server infra ・mz:mamezou
3. 3 前回の課題の解説 ・サンプルアプリの設定による動作変更 ・課題の全体像とECS Fargateとは
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 再掲
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は任意の設定源に設定可能
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した後の操作 ▪ デフォルト設定でのコンテナ起動 ▪ 設定を変更してコンテナ起動
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してないの？
8. latestタグが更新されない理由 8 さっきの答えは ➢ docker pullはリモートリポジトリを常に見に行くがdocker runはローカルリポジトリに該当イメージがないときだけしか リモートリポジトリは見に行かない ➢ よってdocker runでローカルリポジトリにlatestのイメージがある場合、latestが更新されない latestタグを使うとより深刻な問題が 起きる可能性があります。それはなんで しょうか？
9. latestタグの問題（あまり使っちゃダメ） 9 latestタグの対象は移動する。なので ➢ 断面が不定になる • kubernetesやECSなどのコンテナオーケストレーションが持つ指定した断面に環境を戻すrollbackができなくな る ➢ 異なるバージョンが混じる ➢ コンテナオーケストレーションでオートスケールやオートヒーリングされたときのlatestは既にデプロイされているコンテ ナイメージと異なっている可能性がある ➢ これによりクラスタを構成するコンテナインスタンスごとに挙動が変わってしまう恐れがある サンプルではコンテナイメージをピンポイントで指定できるようにタイムスタンプのタグをつけている dockerイメージをリポジトリ管理する際のタグ戦略は非常に重要となる （他のタグ戦略としては通番を振ったりコミットハッシュを使ったりするのが典型）
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が異なっても取得方法は基本的に統一でき ます -Ⅲ 設定-
11. 11 前回の課題の解説 ・サンプルアプリの設定による動作変更 ・課題の全体像とECS Fargateとは
12. これでまでの課題でやってきた全体像 – 振り返り ✓ コンテナの実行環境がEC2からECSに替わっただけ ✓ だがしかし、EC2で行っていたDocker環境の構築やコンテナの起動停止の運用周りは一切不要に 全体として変わっ たのはここだけ ECSが勝手 に取ってきてく れる
13. ECS Fargateとは 13 Amazon Elastic Container Service (Amazon ECS) は、コンテナ化されたアプリケーションのデプロイ、 管理、スケーリングを容易にするフルマネージドコンテナ オーケストレーションサービスです。※AWS公式の完全 引用 ＜ECSとは＞ コントロールプレーン： 必要なリソースを決定し、必要な場所 で実行・管理する基盤 データプレーン： リソースを指示されたとおりに実行す る基盤 AWS Fargate はAmazon ECSで使用できるテクノロジーであり、サーバーやAmazon EC2インスタンスのクラスターを管理することなくコンテナを実行できます。Fargate を使用 すると、コンテナを実行するために仮想マシンのクラスターをプロビジョニング、設定、スケール する必要はありません。 これにより、サーバータイプの選択、クラスターをスケールするタイミングの決定、クラスターの パッキングの最適化を行う必要がなくなります。 ※AWS公式の完全引用 ⇒要はECSのデータプレーンに使えるサーバレス環境。EKSでも利用可 ＜Fargateとは＞ データプレーンにEC2を使った パターン
14. クラスター／サービス／タスク 14 ▪クラスター • ECSリソースを管理するための論理グループ （なだけ） ▪サービス • ECS（コントロールプレーン）の実体 • タスクを監視しサービスで定義された状態を維 持するようにタスクのローリングアップデートや オートスケール、オートヒーリングなど行う ▪タスク定義 • なにを（コンテナイメージ）どのように（割り 当てマシンリースや環境変数など）動作させ るかを定義したもの • 定義は世代ごとに管理される ▪タスク • タスク定義をもとにサービスにより実体化され たもの（サービスにより割り当てられた実行環 境でコンテナが実行されている）
15. 15 実際にやってみる
16. クラウド環境ではログの出力先は標準出力が基本 16 ✓ファイル出力ではなく標準出力に出力させ、ツールで1箇所に集約するようにしましょう。 ✓なぜならスケールイン時に仮想サーバごと消える可能性があることと、環境(OS、IDE、ロー カル/本番)が異なっても標準出力は常に行えるためです。 -Ⅺ.ログ- ⇒そもそもサーバーレスでは基本的にローカルディスクは使えない 引用:Twelve-Factor Appを噛み砕いてみた - Qiita @supreme0110
17. 17 おしまい。お疲れまでした