ECSをハンズオンで作成してみる
今回はECS環境をハンズオンで作成していく。 ゴールとしてはVPCやサブネットを作成し、その上でECSを作成していく。 コンテナは最小構成であるため、デプロイするコンテナはnginxのみとする。 ブラウザからIPアドレスにアクセスして、nginxの画面が表示されることをゴールとする。
VPCとSubnetを作成する
VPCを10.0.0.0/20 (10,0.0.0~10.0.12.255)
Subnet-1 10.0.0.0/24(10.0.0.0~10.0.0.0.255)
Subnet-2 10.0.1.0/24(10.0.1.0~10.0.0.1.255)
の範囲で作成していく
リージョンはAsia/Tokyoとする(ap-northeast-1)
Step1.AWSマネジメントコンソールからVPCを作成する
AWSマネジメントコンソールにログインし、VPCを検索して選択する。
初めての利用の場合はデフォルトのVPCが存在するため、削除する(放っておいても良い)
右上からVPCの作成を選択して新規作成画面へ遷移する
作成するリソースは今回はVPCのみとする(VPCなどは関連するリソースも作成可能なため、こちらの方が楽ではある)
名前タグにはmy-vpcを入力
IPv4 CIDRブロックは手動入力。IPv4 CIDRに、10.0.0.0/20を入力
IPv6は今回不要
テナンシーはデフォルトとする
テナンシーはシングルテナント専用のハードウェアであり、ハードウェアを専有してしてVPCを構築することなる。よって、ハードウェアの利用料も支払い対象となる。セキュリティ的にハードウェアを他のユーザーと共有したくない場合やオンプレ向けなライセンスを持ち込みたい時などで使用する
VPCが作成されたため、次はSubnetの作成を行なっていく
Step.2 Subnetの作成
publicサブネットとprivateサブネットを作成していく
VPCダッシュボードのサブネットを選択する
VPCを削除していない場合はここにデフォルトのサブネットがあるが、別で作成していく。(デフォルトのVPCを削除していれば何もないはず。あっても更新すれば消えるか、再度削除してみればエラーになり、再更新すると消える)
まずはprivateサブネットを作成していく
サブネットの作成からVPC IDで先ほど、作成したVPCを選択
サブネット名にmy-subnet-app-private1-a
アベイラビリティゾーン(AZ)はap-northeast-1a
IPv4 VPC CIDRブロックは10.0.0.0/20
IPv4サブネット CIDRブロックは 10.0.0.0/24とする(サブネットはVPCに内包されるため、VPCのIPアドレスの範囲内のみ選択可能)
サブネットを作成を選択
次はpublicサブネットを作成していく
サブネットの作成からVPC IDで先ほど、作成したVPCを選択
サブネット名にmy-subnet-app-public1-a
アベイラビリティゾーン(AZ)はap-northeast-1a
IPv4 VPC CIDRブロックは10.0.0.0/20
IPv4サブネット CIDRブロックは 10.0.1.0/24とする(サブネットはVPCに内包されるため、VPCのIPアドレスの範囲内のみ選択可能)
サブネットを作成を選択
本来は、アベイラビリティーゾーンを変更して冗長性を考慮してサブネットを作成することが望ましい。(publicをAZ跨いで2つ作成。privateも然り。)
今回はpublicとprivateで役割の違うサブネットを1のAZで作成した。
これでサブネットの作成は完了である。
Step3 ルートテーブルとIGWの作成
ルートテーブルは基本的にサブネットに紐つけて作成されることとなり、通信のルートを定義しているものとなる。
インターネットゲートウェイはサブネット内で発生した通信の内、自身のサブネット内の機器ではなく、インターネットへの接続が必要な場合に使用する。今回で言うとpublicなサブネットを先ほど作成したので、そこへアタッチすることとなる。
早速、VPCダッシュボードのルートテーブルを選択し、新規作成を選択する
ルートテーブルの作成を選択し、まずはprivateサブネットにアタッチするルートテーブルを作成する。
名前:my-route-table-private1-a
VPC: 先ほど作成したVPC(my-vpc)
でルートテーブルを作成する
続いて、同様にpublicサブネットにアタッチするルートテーブルを作成する。
名前:my-route-table-public1-a
VPC: 先ほど作成したVPC(my-vpc)
でルートテーブルを作成する
pulicルートテーブル向けにインターネットゲートウェイを作成する
VPCダッシュボードからインターネットゲートウェイを選択する
インターネットゲートウェイの作成を選択し、名前を入力して作成をする
名前タグ: my-igw
インターネットゲートウェイの一覧に戻ると、状態がDetachedになっているはずです。
なのでここからアタッチしていきます。
先ほど作成したmy-igwを選択して、VPCにアタッチを選択する。
設定画面からアタッチが完了すると、VPCはインターネットゲートウェイを通じて外の通信が可能となる状態を作成できるようになる。
では実際に、ルートテーブルを編集し、インターネットゲートウェイを選択していく。
VPCダッシュボードからルートテーブルに戻り、my-subnet-app-public1-aを選択し、画面下部に出る、メニューからルートテーブルを選択する。
ルートを編集を選択して、ルートを追加する。 送信先: 全ての通信を意味する 0.0.0.0/0(全てが該当する場合は一致しているものが優先される->10.0.0.0/20はlocalが優先される)
ターゲット: インターネットゲートウェイと先ほど作成したインターネットゲートウェイを選択する。
これで、ルートテーブルにインターネットゲートウェイが関連付けされた。
あとはここからサブネットにルートテーブルを設定して、準備は完了となる。
まずはpublicなサブネットに対し、ルートテーブルを設定していく
VPCダッシュボードからサブネットを選択し、my-subnet-app-public1-aを選択する。
画面下部のメニューからルートテーブルを選択して、ルートテーブルの関連付けを編集を選択
ルートテーブルID: my-route-table-public1-a
保存する。
同様にprivateなサブネットに対してもルートテーブルを設定していく。
セキュリティーグループについて
セキュリティーグループとはVPC内のサーバーなどに関連付けをして、通信の制御を行う。(仮想的なファイヤーウォールである)
外部から入ってくる通信をインバウンドルールに設定
内部から出ていく通信をアウトバウンドルールに設定
IN/OUTのルールを定義してアクセス管理を行っていく。
許可ポートと許可するIPアドレス(CIDR)を設定していく。
注意事項としてはアウトバウンドの通信に対するレスポンスについては、インバウンドの設定は適応されない。
アウトバウンドに対するレスポンスは常に許可となる。
またセキュリティグループはホワイトリストのため、ルールに記載がないものは全て不許可となる。
ルール変更時は関連する全てのインスタンスに設定が即時反映される。
ECSのクラスター作成
検索バーからECSを検索し、Elastic Container Serviceを選択する
サイドメニューからクラスターを選択し、クラスターの作成をクリックする
大きく分けて
- クラスター設定
- インフラストラクチャオプション
- モニタリングオプション(今回は設定なし)
- 暗号化オプション(今回は設定なし)
- タグオプション(今回は設定なし)
が存在する。
まずはクラスター設定から入力していく。
-
クラスター設定
- クラスター名にmy-app-clusterを入力
- ServiceConnectのデフォルトは今回はからでOK
- ※ ECSの「Service Connectのデフォルト – オプション」は、サービス間通信を簡素化する機能を有効化する設定。 有効にすると、Cloud Map を使った名前解決や安全な接続が自動で行えるようになる。 マイクロサービス構成でサービス同士が通信する場合に有効化がおすすめ。
- ※ Cloud MapはAWSのサービスディスカバリ機能で、サービスに名前を付けて動的に解決できるようにするもの。 DNSやAPI経由で他サービスの場所を取得し、IPやポートの変化に強い設計が可能。 マイクロサービス構成でのサービス間通信を簡素化・安定化するためによく使われる。
-
インフラストラクチャオプション
- AWS Fargateにチェック
これで作成を行う。
注意点としてすぐにリフレッシュを行うと作成が失敗していつまでも、一覧に表示されない状態になる。同じ名称のクラスターを再度作成できない場合は、CloudFormation内のタスクを消せば、再度作成できるようになる
タスクの作成
クラスターが正常に作成された後に今度はタスクの作成を行う。
本来はサービスの作成を行う必要があるが、今回は最小構成のため、タスクを直接クラスター内に配置することとする。
サイドメニューからタスク定義を選択する。
新しいタスクを作成で、新しいタスクの定義を作成を選択(今回はJsonは使用しない)
まずは
- タスク定義の設定
- タスク定義ファミリーでmy-app-nginxを入力
- インフラストラクチャの要件(Fargateが実行されるサーバーのスペックを設定する)
- 起動タイプはFargateを選択
- OSはLinux/X86_64を選択
- CPUは.25vCPUの最小仮想CPUを選択
- メモリは.5GBの最小を選択
- タスクロールはなし(今回はコンテナから他のAWSサービスにアクセスしないため権限が不要)
- タスク実行ロールは新しいロールの作成とする(ECRからイメージをpullするなど起動に必要なロールを設定してあげる必要がある。新しいロールの作成を選択するとAWSがロールの作成を自動で行ってくれる)
- コンテナ定義(複数コンテナを使用する場合は、コンテナ定義の枠の下にあるコンテナを追加を押下->タスクは最小実行単位のためあまり大きくしない方がいい)今回は入力する部分のみ抜粋する。
- 名前にnginxを入力
- イメージURIは今回Amazon ECR Public Galleryからイメージを取得するため、nginxを検索してimage tagsから最新安定版のイメージを取得する(画面は下の画像を参照してください)
- 必須コンテナは「はい」を選択
- ログ収集(基本はチェックを入れておく)
これで作成を行う
ECR Public Galleryのnginx選択画面でimage tagsから一覧を見て、stable-perlを選択し、上部のCopyからURIをコピーする
作成が完了したらタスク定義一覧に戻って、作成されたタスクの名前をクリックし、タスク詳細を確認する。
詳細を見てみると、my-app-nginx:1とコロンと1が付与されていることが分かる。
これはタスク定義のバージョンとなっており、今後、このタスクを変更する度にインクリメントされていく。
タスクはタスク定義に基づいて作成される。デプロイの際にコンテナの差し替えや環境変数の追加などが必要な場合は、タスク定義をアップデートする必要があるため、バージョン情報が付与されている。アップデートの際は変更したいタスク定義をチェックして新しいリビジョンの作成をクリックすればよい。
Fargateのデプロイ
Fargateのデプロイを行っていく。
サイドメニューからクラスターを選択して、my-app-clusterを選択。
画面下部のメニューでサービスに当たっているタブをタスクに切り替えて、新しいタスクの実行を選択する
タスク実行の設定画面から
タスク詳細
- タスク定義ファミリーでmy-app_nginxを選択
- タスク定義のリビジョンは1(最新)を選択(バージョン指定ができるが今は1しかない)
- 必要なタスクは1とする(2を選べばタスクは2つ実行され、AWS側のアルゴリズムにより、複数サブネットが存在する場合は振り分けられる→任意で振り分けはできないので注意)
環境
- コンピューティングレベルは起動タイプを選択(キャパシティープロバイダー戦略はどの割合でどのリソースに振り分けるかを決定できる。Fargate 70% EC2 30%みたいなイメージ。一方、起動タイプはFargateかEC2と実行基盤そのものを指定する)
- 起動タイプはFARGATE
- プラットフォームバージョンはLATEST
ネットワーキング
- VPCはmy-vpcを選択
- サブネットはデフォルトでprivateもpublicも選択されているため、privateを外す(my-subnet-app-public1-aのみ選択)
- セキュリティグループはまだFargate向けのセキュリティグループを作成していないため、新しいセキュリティグループの作成を選択
- セキュリティグループ名はmy-app_nginx-sgとする
- セキュリティグループの説明はアルファベットで適当に入力(空白だとエラーになるはず)
- セキュリティグループのインバウンドルールを設定
- タイプ HTTP
- ソース Anywere(今回はnginxのみなので本来はここはちゃんと設定すること)
- パブリックIPはONとする
これで作成をクリックする
タスク一覧に遷移し、ステータスがRunningになればデプロイは完了となる。
タスクを選択し、パブリックIPにアクセスしてnginxの画面が表示されれば正常にデプロイが完了した形となる。
下記画面が表示されるはずである
ここまででハンズオンは完了です。
最後にタスクは実行されていると課金されてしまうため、停止をしてください。
停止を押して、クラスターから画面下部のメニュー→タスクを確認し、停止済みならOKです。