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

第5回 AWSとGitHub勉強会 - AWS EC2環境の構築 -

荻原利雄
September 18, 2023
450

第5回 AWSとGitHub勉強会 - AWS EC2環境の構築 -

荻原利雄

September 18, 2023
Tweet

Transcript

  1. 5 前回の課題の解説 ・これでまでの課題でやってきた全体像 ・AWSのユーザと権限 ・AWSのネットワーク構成 ・最後にEC2は AWSのユーザと権限、AWSのネットワーク構成は厳密 性よりも分かりやすさを優先しかなり意訳しているものも あります。したがって、100点満点で正確な説明をしてい る訳ではありませのでその点は予めご承知おきください

    キャプチャを取得するために利用したAWSリソースはすべ て削除しています。 説明では上記対策を行った上で例を分かりやすくするた め一部セキュリティ情報含んだ画面キャプチャを使用して います。本来は好ましくないためその点はご留意ください。
  2. ルートユーザとIAMユーザ • ルートユーザ • AWSアカウント作成時に最初に用意されアカウント • 予めすべての権限が付与されてる。これを制限する 方法はないので、非常に権限の強いユーザとなる • AWSからの請求につかうクレジットカード情報が

    紐づいている • IAMとは • ID と AWS のサービスおよびリソースへのアクセスを 一元管理するAWS独自の権限管理の仕組み • 日本では「アイアム」、英語圏では「アイエーエム」と 呼ばれることが多い • IAMユーザとは • IAMで作成したユーザ。ルートユーザは最初からフルアクセス権が付ついているのに対して、IAMユーザで何をする には必要な権限を付与する必要がある • AWSのユーザの種類にはルートユーザとIAMユーザの2種類しかなく、IAMユーザはLinux等でよく言われる「ルー トユーザ」に対する「一般ユーザ」の意味に等しい 7
  3. 権限 – グループとポリシー • ポリシー • なんの「Resource」をどう「Action」できるかを定義したもので、一般的に言われる「権限」に相当するもの • ストレージサービスのS3に対するフルアクセスを表すポリシーの実体イメージとしては次のようになる •

    グループ • AWSではポリシーをまとめるための手段としてグループが用意されている • グループに所属しているIAMユーザはグループを経由してそのグループに付与されているすべてのポリシーが付与される • ポリシーの割り当て • ポリシーはIAMユーザに対して直接割り当てることも、グループを経由して割り当てることもできる AWSの権限構造 S3のポリシー定義の例
  4. AWSには「ロール」もある – ややこしい・・ • サービス • EC2やS3などのAWSのサービス。もっと平たく言えば実行プログラム • 例えばあるEC2インスタンスからS3を参照する際に該当のEC2インスタンスはS3に対する操作権限が必要となるため、サービスにも ポリシー(権限)が必要となる

    • ロール • サービスに割り当てるポリシーをグルーピングするもの • 一般的に「ロール」というとユーザに割り当てるイメージが強いが、AWSではユーザに割り当てるのがグループで、サービスに割り当てる ものがロールとなる。ロールをユーザに割り当てることはできない。 • (ほんとに最低のネーミングで初めましての人のほとんどが混乱する) • ポリシーの割り当て • サービスにポリシーを直接割り当てることはできない。よって、必ずロールを作成して付与する必要がある ロールの場合の権限構造 ロールを使ったのポリシーの設定例
  5. まとめ - AWSのユーザと権限 • AWSの権限周りは難しく感じるが実はネーミングがヘンなだけ ① IAMユーザは要は自分で権限を設定する一般ユーザ ② ポリシーは要は権限 ③

    グループはポリシーをまとめてユーザに割り当てるもの ④ ロールはユーザではなくサービスにポリシーをまとめて割り当てるもの ⑤ ユーザにはポリシーを直接割り当てられるが、サービスには割り当てることができ ない ⑥ なので、サービスにポリシーを割り当てるには必ずロールを経由する必要がある • これがイメージできばどんなサービスを使うことになってもバッチリ(個人の 感想です) 11
  6. AWSのネットワーク構成 ▪ VPC • AWS上のプライベートな仮想ネットワーク環境 • 実体はCIDRで区切られたプライベートアドレス空間 ▪ インターネットゲートウェイ(IGW) •

    インターネットとVPCを中継するもの • グローバルアドレス空間のインターネットとプライベートアドレス空 間のVPCを繋ぐもので実体はNAT • IGWに繋がっているサービスに割り当てられたグローバルIPとプラ イベートIPを1対1で紐づける。これによりIGWに繋がっている EC2などのサービスは外部からグローバルIPでアクセス可能となる • よって、プライベートアドレス空間内に存在するサービスが直接グ ローバルIPアドレスのインタフェースを持つ訳ではない ▪ セキュリティグループ • EC2などのサービスはいずれかのセキュリティグループに紐づけられ ており、そのセキュリティグループを通してアクセスされる。 • このセキュリティグループは実質的にfirewallの役割となる。よっ て、外部からのアクセスを許可するにはセキュリティグループでポー トを開ける必要がある ▪ ルートテーブル • サブネットには必ず1つのルートテーブルが紐づけられている • サブネット内のルーティングは紐づけられているルートテーブルを参 照して決定される ▪ サブネット • VPCをさらにCIDRで分割したアドレス空間 • publicとprivateの2種類があり違いは内部のサービスをIGW に直接つながるかになる • IGWに直接繋げられる場合、NATの対象となるため、直接外 部とアクセスが可能となる <アドレス範囲> 172.31.16.0/20 → 172.31.16.1~172.31.31.254 172.31.32.0/20 → 172.31.32.1~172.31.47.254 課題は1つのEC2インスタンスしか使っていませんが、構成が分かりやすくなる ようここでは複数の要素を使った例にしています
  7. 次回までの課題 • テーマ • GitHub Packgesで公開したコンテナイメージを今度はAWSのECS Fargateで動かす • コンテナ化で環境変数は重要な役割を果たすのでそれを使ってみる •

    今回はちょっと難しいかもしれませんが最後なので頑張りましょう! • お題 • 環境変数の設定でサンプルアプリの動作を変えられるようにする • 改変したアプリをEC2で動かして確認してみる • ECS Fargateにデプロイしてサンプルアプリを動かしてみる • ゴール • REST APIで返す値を環境変数で指定できること • サンプルアプリがECS Fagateで動作すること 次回で補足しますがECS Fargateがどのようなものか知り場合は検索すると沢山出てきますので、そちら を参照ください 17
  8. 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(変更) 19
  9. Step2. コンテナをビルドしEC2からpullして動作を確認する(2/2) • EC2が停止している場合は起動しSSHでEC2に接続する • 4回目資料のp.38-39を参考にビルドしたコンテナを起動し、REST APIを呼び出す • 環境変数は設定していないので、デフォルトの“Hello”が返ってくる •

    コンテナを終了させ、次は環境変数を指定(-eオプション)してコンテナを起動し、設定ファイルの値を上 書きする。起動したらREST APIを呼び出す • REST APIのレスポンスに環境変数で指定した値が返ってくればOK! • コンテナを終了し、EC2は使わないので停止しておく 21
  10. Step3. ECS Fargateにデプロイして動作を確認する • ECS Fargateのデプロイでこれからやること ① 事前準備 • タスク実行ロールの作成(CloudWatchへの書き込みの許可)

    ② クラスターの作成 ③ タスク定義の作成 • タスク定義の作成 • ロググループの作成 ④ サービスの作成 22
  11. Step3-②. クラスターの作成(1/2) ECSメニューから行う ①ECSを入力して検索 ②クリック ①クラスターをクリック ②作成をクリック ③任意のクラスター名を入力 例はsample-cluster ④EC2と同じものでOK

    ⑤EC2と同じものでOK ・・・・ ⑥後はそのままでOK ココの部分はUIが [▼インフラストラクチャ] 変わってます 『AWS Fargate(サーバーレス)』 を選択してください
  12. Step3-③. タスク定義の作成(2/2) ①任意のタスク名を入力 例はsample-app-task2 ②Fargateのみがチェックされていること ③.5vCPUと1GBを選択 ④タスクロールはなし「-」 ⑤タスク実行ロールは3-①で作成した ロールを設定する ⑥任意の名前を入力

    例はsample-app ⑦イメージURLを入力 GitHub Packagesのイメージ名を入力 タグはlatestでよい ⑧コンテナポートに7001を指定 ⑨展開して確認 ⑩同じような感じになっていることを 確認 ⑪あとはデフォルトのままでよいので ここまでの入力と確認ができたら 「作成」ボタンをクリックしてタスク定 義の作成は完了!
  13. Step4. 今回の課題 • Step2のEC2でやったようにFargateでも環境変数を設定し、環境変数に従った、応 答が返るようにしましょう • ヒント • どのコンテナをどのように動かすかを定義してるのはタスク定義 •

    タスク定義は世代で管理される • 新しいタスク定義で動作させるのはサービスで参照するタスク定義のリビジョンを更新する • サービスの実体はコントロールプレーン(コンテナオーケストレーター)でサービスに指定された状態 を保とうとする • タスクは起動するたびに割り当てられるグローバルIPが変わるので、REST APIを呼び出す際は都 度、IPアドレスを確認すること