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

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

荻原利雄
September 18, 2023
330

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

荻原利雄

September 18, 2023
Tweet

Transcript

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

    View full-size slide

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

    View full-size slide

  3. 3
    前回の課題の解説
    ・これでまでの課題でやってきた全体像
    ・AWSのユーザと権限
    ・AWSのネットワーク構成
    ・最後にEC2は

    View full-size slide

  4. これでまでの課題でやってきた全体像 – 振り返り
    ✓ 開発からCI/CD、プロダクションでの実行まですべてクラウド環境で実現!
    ✓ プロダクションへのデプロイは手動だがコミットからリポジトリの登録まではすべて自動!

    View full-size slide

  5. 5
    前回の課題の解説
    ・これでまでの課題でやってきた全体像
    ・AWSのユーザと権限
    ・AWSのネットワーク構成
    ・最後にEC2は AWSのユーザと権限、AWSのネットワーク構成は厳密
    性よりも分かりやすさを優先しかなり意訳しているものも
    あります。したがって、100点満点で正確な説明をしてい
    る訳ではありませのでその点は予めご承知おきください
    キャプチャを取得するために利用したAWSリソースはすべ
    て削除しています。
    説明では上記対策を行った上で例を分かりやすくするた
    め一部セキュリティ情報含んだ画面キャプチャを使用して
    います。本来は好ましくないためその点はご留意ください。

    View full-size slide

  6. ルートユーザとIAMユーザ
    6
    最初に作ったのがルートユーザで次に
    作ったのIAMユーザ。
    ログインから分かれてるけど、これって
    なんだ??
    IAMユーザを作るときにはグ
    ループを指定したけど、これって
    いるの?
    アタッチされたポリシーっ
    てなに??

    View full-size slide

  7. ルートユーザとIAMユーザ
    • ルートユーザ
    • AWSアカウント作成時に最初に用意されアカウント
    • 予めすべての権限が付与されてる。これを制限する
    方法はないので、非常に権限の強いユーザとなる
    • AWSからの請求につかうクレジットカード情報が
    紐づいている
    • IAMとは
    • ID と AWS のサービスおよびリソースへのアクセスを
    一元管理するAWS独自の権限管理の仕組み
    • 日本では「アイアム」、英語圏では「アイエーエム」と
    呼ばれることが多い
    • IAMユーザとは
    • IAMで作成したユーザ。ルートユーザは最初からフルアクセス権が付ついているのに対して、IAMユーザで何をする
    には必要な権限を付与する必要がある
    • AWSのユーザの種類にはルートユーザとIAMユーザの2種類しかなく、IAMユーザはLinux等でよく言われる「ルー
    トユーザ」に対する「一般ユーザ」の意味に等しい
    7

    View full-size slide

  8. 権限 – グループとポリシー
    • ポリシー
    • なんの「Resource」をどう「Action」できるかを定義したもので、一般的に言われる「権限」に相当するもの
    • ストレージサービスのS3に対するフルアクセスを表すポリシーの実体イメージとしては次のようになる
    • グループ
    • AWSではポリシーをまとめるための手段としてグループが用意されている
    • グループに所属しているIAMユーザはグループを経由してそのグループに付与されているすべてのポリシーが付与される
    • ポリシーの割り当て
    • ポリシーはIAMユーザに対して直接割り当てることも、グループを経由して割り当てることもできる
    AWSの権限構造 S3のポリシー定義の例

    View full-size slide

  9. 再度見てみる - ルートユーザとIAMユーザ
    9
    ルートユーザとIAMユーザは別物なんだね!
    IAMユーザってヘンテコな名前だけど「一般ユーザ」とい
    うことか
    グループはユーザをグルーピングする目的の他
    にも権限を割り当てる目的もあるんだネ! これはグループを経由して割り当てら
    れる権限なんだネ

    View full-size slide

  10. AWSには「ロール」もある – ややこしい・・
    • サービス
    • EC2やS3などのAWSのサービス。もっと平たく言えば実行プログラム
    • 例えばあるEC2インスタンスからS3を参照する際に該当のEC2インスタンスはS3に対する操作権限が必要となるため、サービスにも
    ポリシー(権限)が必要となる
    • ロール
    • サービスに割り当てるポリシーをグルーピングするもの
    • 一般的に「ロール」というとユーザに割り当てるイメージが強いが、AWSではユーザに割り当てるのがグループで、サービスに割り当てる
    ものがロールとなる。ロールをユーザに割り当てることはできない。
    • (ほんとに最低のネーミングで初めましての人のほとんどが混乱する)
    • ポリシーの割り当て
    • サービスにポリシーを直接割り当てることはできない。よって、必ずロールを作成して付与する必要がある
    ロールの場合の権限構造 ロールを使ったのポリシーの設定例

    View full-size slide

  11. まとめ - AWSのユーザと権限
    • AWSの権限周りは難しく感じるが実はネーミングがヘンなだけ
    ① IAMユーザは要は自分で権限を設定する一般ユーザ
    ② ポリシーは要は権限
    ③ グループはポリシーをまとめてユーザに割り当てるもの
    ④ ロールはユーザではなくサービスにポリシーをまとめて割り当てるもの
    ⑤ ユーザにはポリシーを直接割り当てられるが、サービスには割り当てることができ
    ない
    ⑥ なので、サービスにポリシーを割り当てるには必ずロールを経由する必要がある
    • これがイメージできばどんなサービスを使うことになってもバッチリ(個人の
    感想です)
    11

    View full-size slide

  12. 12
    前回の課題の解説
    ・これでまでの課題でやってきた全体像
    ・AWSのユーザと権限
    ・AWSのネットワーク構成
    ・最後にEC2は

    View full-size slide

  13. 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インスタンスしか使っていませんが、構成が分かりやすくなる
    ようここでは複数の要素を使った例にしています

    View full-size slide

  14. 14
    前回の課題の解説
    ・これでまでの課題でやってきた全体像
    ・AWSのユーザと権限
    ・AWSのネットワーク構成
    ・最後にEC2は

    View full-size slide

  15. 最後にEC2は..
    • 環境を構築して分かったかと思いますが、EC2自体はただのオンプレのサーバとなんら
    変わりません
    • クラウドならではやAWSならではのことはここまでで説明したユーザと権限、ネットワーク
    構成が基本となります
    • ここまでの内容が理解できれば、 ECS Fargetaなど他のサービスもすんなり使うことが
    できるかと思います
    • 重要な内容なので、ネットや書籍などで復習してみましょう
    15

    View full-size slide

  16. 16
    次回までの課題の説明

    View full-size slide

  17. 次回までの課題
    • テーマ
    • GitHub Packgesで公開したコンテナイメージを今度はAWSのECS Fargateで動かす
    • コンテナ化で環境変数は重要な役割を果たすのでそれを使ってみる
    • 今回はちょっと難しいかもしれませんが最後なので頑張りましょう!
    • お題
    • 環境変数の設定でサンプルアプリの動作を変えられるようにする
    • 改変したアプリをEC2で動かして確認してみる
    • ECS Fargateにデプロイしてサンプルアプリを動かしてみる
    • ゴール
    • REST APIで返す値を環境変数で指定できること
    • サンプルアプリがECS Fagateで動作すること
    次回で補足しますがECS Fargateがどのようなものか知り場合は検索すると沢山出てきますので、そちら
    を参照ください
    17

    View full-size slide

  18. 課題の実施手順
    Step1. REST APIで返す値を環境変数で指定できるようにサンプル
    アプリを修正する
    Step2. コンテナをビルドしEC2からpullして動作を確認する
    Step3. ECS Fargateにデプロイして動作を確認する
    Step4. 今回の課題
    18

    View full-size slide

  19. 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

    View full-size slide

  20. Step2. コンテナをビルドしEC2からpullして動作を確認する(1/2)
    • Step1で修正した内容をリポジトリにコミットする
    • 3回目の「GitHub Packagesにコンテナイメージがデプロイする」の課題で作成したワークフロー
    (image-publish.yml)を使って、コンテナイメージをビルドしてGitHub Packages Container
    Registryに登録する
    • イメージのビルドが上手くいっていることを確認できたらEC2へ
    20
    最新になっていること

    View full-size slide

  21. Step2. コンテナをビルドしEC2からpullして動作を確認する(2/2)
    • EC2が停止している場合は起動しSSHでEC2に接続する
    • 4回目資料のp.38-39を参考にビルドしたコンテナを起動し、REST APIを呼び出す
    • 環境変数は設定していないので、デフォルトの“Hello”が返ってくる
    • コンテナを終了させ、次は環境変数を指定(-eオプション)してコンテナを起動し、設定ファイルの値を上
    書きする。起動したらREST APIを呼び出す
    • REST APIのレスポンスに環境変数で指定した値が返ってくればOK!
    • コンテナを終了し、EC2は使わないので停止しておく
    21

    View full-size slide

  22. Step3. ECS Fargateにデプロイして動作を確認する
    • ECS Fargateのデプロイでこれからやること
    ① 事前準備
    • タスク実行ロールの作成(CloudWatchへの書き込みの許可)
    ② クラスターの作成
    ③ タスク定義の作成
    • タスク定義の作成
    • ロググループの作成
    ④ サービスの作成
    22

    View full-size slide

  23. Step3-①. 事前準備(1/4)
    • タスク実行ロールの作成(CloudWatchへの書き込みの許可)
    23
    ①IAMを入力して検索
    ②クリック
    ③ロールをクリック
    ④作成をクリック
    IAMメニューから行う

    View full-size slide

  24. Step3-①. 事前準備(2/4)
    • タスク実行ロールの作成(CloudWatchへの書き込みの許可)
    24
    ①これを選択
    ② Elastic Container Serviceをプルダウンから選択
    ③ Elastic Container Service Taskを選択
    ④次へ

    View full-size slide

  25. Step3-①. 事前準備(3/4)
    • タスク実行ロールの作成(CloudWatchへの書き込みの許可)
    ①ECSを入力してEnterキーで絞り込み実行
    ECSが付くポリシーに絞り込まれる
    ②AmazonECSTaskExecutionRolePolicyをチェック
    ③次へ

    View full-size slide

  26. Step3-①. 事前準備(3/4)
    • タスク実行ロールの作成(CloudWatchへの書き込みの許可)
    ②確認画面なので「ロールを作成」を押して完了
    ここで設定したロールは「③タスク定義の作成」で利用する
    ①キャプチャは見切れているが、この上にロール名を入力するところがあるのでロール名を入
    力する。例はecsTaskExecutionRole2としている(※Role2の2は荻原さんの環境の
    都合なので本来はなくてOK)

    View full-size slide

  27. Step3-②. クラスターの作成(1/2)
    ECSメニューから行う
    ①ECSを入力して検索
    ②クリック
    ①クラスターをクリック
    ②作成をクリック
    ③任意のクラスター名を入力
    例はsample-cluster
    ④EC2と同じものでOK
    ⑤EC2と同じものでOK
    ・・・・
    ⑥後はそのままでOK
    ココの部分はUIが
    [▼インフラストラクチャ]
    変わってます
    『AWS Fargate(サーバーレス)』
    を選択してください

    View full-size slide

  28. Step3-②. クラスターの作成(2/2)
    運が悪いと数分待つので待っていると
    これで作成完了

    View full-size slide

  29. Step3-③. タスク定義の作成(1/2)
    ①タスク定義をクリック
    ②新しいタスク定義の作成をクリック

    View full-size slide

  30. Step3-③. タスク定義の作成(2/2)
    ①任意のタスク名を入力
    例はsample-app-task2
    ②Fargateのみがチェックされていること
    ③.5vCPUと1GBを選択
    ④タスクロールはなし「-」
    ⑤タスク実行ロールは3-①で作成した
    ロールを設定する
    ⑥任意の名前を入力
    例はsample-app
    ⑦イメージURLを入力
    GitHub Packagesのイメージ名を入力
    タグはlatestでよい
    ⑧コンテナポートに7001を指定
    ⑨展開して確認
    ⑩同じような感じになっていることを
    確認
    ⑪あとはデフォルトのままでよいので
    ここまでの入力と確認ができたら
    「作成」ボタンをクリックしてタスク定
    義の作成は完了!

    View full-size slide

  31. Step3-④. サービスの作成(1/6)
    ①クラスターをクリック
    ②Step3-②で作成したクラスターをクリック
    ③サービスタグをクリック
    ④作成をクリック

    View full-size slide

  32. Step3-④. サービスの作成(2/6)
    ①こっちが選択されていること
    ②FARGATEが選択されていること
    ③LATESTが選択されていること
    ④こっちが選択されていること
    ⑤Step3-③で作成したタスク定義を選択
    ⑥任意のサービス名を入力
    例はsamaple-app-service
    ⑦必要なタスクに1を入力

    View full-size slide

  33. Step3-④. サービスの作成(3/6)
    ①クラスターで選択したものと同じもの
    つまり、EC2と同じVPCを選択
    ②EC2と同じサブネットを選択
    ③既存を選択
    ④EC2と同じセキュリティグループを選択
    ⑤オンになっていること
    ⑥後はそのままで作成を実行

    View full-size slide

  34. Step3-④. サービスの作成(4/6)
    進行中と出ていてもタグをクリックしたり、最新に更新を押してると↓のようなサービスの内容が出てくる
    リンクをクリックでサービスの詳細へ

    View full-size slide

  35. Step3-④. サービスの作成(5/6)
    サービスの詳細
    タスクの詳細画面へ
    上手くいかないときはここ(イベントログ)を確認
    外部からはこのアドレスでアクセスする
    アプリのログはここからCloudWatch経由で見れる

    View full-size slide

  36. Step3-④. サービスの作成(6/6)
    正常起動の確認
    必要なタスク分(つまり1つ)が起動して緑状態になったらOK!
    起動できたら前のページ確認したアドレスで
    REST APIが呼び出せるか確認してみる。
    正常に応答が返ってくればOK!

    View full-size slide

  37. タスクの停止
    ECS Fargateには無料枠は付いていません
    ECS FargateはEC2と同様にタスクが起動している時間で課金されます
    ですので、使い終わったらタスクを停止するようにしてください。課金が停止します
    タスクの停止は「必要なタスク」を0にしてサービスを更新するだけです
    重要
    ①対象のサービスをチェック
    ②更新をクリック
    ①ここをチェック
    ②0にする
    ③この状態で更新を実行する
    実行後は0/0件が実行中になり、タスクが起動してないことを確認する

    View full-size slide

  38. Step4. 今回の課題
    • Step2のEC2でやったようにFargateでも環境変数を設定し、環境変数に従った、応
    答が返るようにしましょう
    • ヒント
    • どのコンテナをどのように動かすかを定義してるのはタスク定義
    • タスク定義は世代で管理される
    • 新しいタスク定義で動作させるのはサービスで参照するタスク定義のリビジョンを更新する
    • サービスの実体はコントロールプレーン(コンテナオーケストレーター)でサービスに指定された状態
    を保とうとする
    • タスクは起動するたびに割り当てられるグローバルIPが変わるので、REST APIを呼び出す際は都
    度、IPアドレスを確認すること

    View full-size slide

  39. 39
    次回の予定
    次回は最終回だよ

    View full-size slide

  40. 次回の予定
    • 今回の課題の説明
    • 補足説明と質疑応答
    40

    View full-size slide