AWS Fargateとは
AWS re:Invent2017でAWSが発表したコンテナホスト(インスタンス)を意識せずにコンテナを管理できるオーケストレーションサービスです。
現時点ではバージニア(us-east-1)リージョンのみでGAとなっています。
ちなみに、re:Inventに参加したので、現地でキーノートを聞いていましたが、同時にEKSも発表され待望のサービスが来た!という感じで私も会場もめちゃくちゃ興奮してました。
やってみる
クラスタの作成
リージョンはバージニアを選択し、Elastic Container Serviceの画面を開きます。
クラスターの作成ボタンを押してクラスタの作成を始めます。
(私の環境は元々別のクラスタが作成してあったので初めての場合表示が違うかもしれません)

クラスタテンプレートの選択
以下の3つのクラスタテンプレートが選択できます。
- Network only
- EC2 Linux + Networking
- EC2 Windows + Networking
Network onlyがFargateのようなので、こちらを選択して次のステップへ進みます。

クラスタの設定
ここではクラスタ名とネットワークの設定をします。
クラスタ名はFargateTestにしてみました。
また、このクラスタ用にVPCも合わせて作ってくれるオプションがあったので選択しました。
値はデフォルトのままで作成。

起動ステータスの確認
作成が始まるとCloudFormationスタックが走ります。
しばらくするとイイ感じにクラスタができあがります。

クラスタの状態を確認
タスク定義作成
新しくNginxを起動するタスクを定義します。
(私の環境は元々別のタスクが登録してあったので初めての場合表示が違うかもしれません)

ローンチタイプの選択
FARGATEとEC2が選択できるので、当然FARGATEを選んで次のステップに進みます。

タスク定義の設定
適当にタスク定義に名前をつけます。ここではTestNginxとしました。
タスクのサイズ指定でメモリとvCPUを選択できます。
メモリは0.5GBと1GB~30GBまで1GB刻みで調整できるようです。
CPUは0.25、0.5、1、2、4から選択します。
ここではどちらも最小値の0.5GB、0.25vCPUを選択しました。
続いてコンテナの追加を行います。

コンテナの追加
コンテナ名を適当に定義します。ここではTestNginxにしました。
また、使用するコンテナイメージを指定します。DockerHubで公開されているNginxイメージをそのまま指定しました。
Nginxコンテナはポート80でListenするのでポートマッピングの設定は80となります。
その他は特に変更せずに追加し、そのまま作成します。

ローンチステータスの確認
サービスの作成
クラスタの一覧から今回作成したFargateTestを選択します。

サービスの作成
サービスの設定
Launch Typeは当然FARGATEを選択します。
また、タスク定義は先程作成したTestNginxを指定します。
サービス名には適当な名前をつけます。ここではTestNginxとしました。

ネットワーク構成の設定
参加するVPCを指定します。たぶん最初に作ったVPC IDが指定されていると思います。
コンテナが起動するサブネットを追加します。AZごとに別れていると思います。
また、セキュリティグループを編集することで既存のセキュリティグループを指定したり新規作成の内容を微調整できるようです。デフォルトのままだとポート80をAnyで公開します。
今回はELBを使用せずに直接コンテナに接続してみたいのでELBタイプはなしを選択しました。
このまま次のステップに進みます。

オートスケールの設定
オートスケールの設定ができますが、今回は実施しないのでそのまま次のステップに進みます。

サービスの確認
作成ステータスの確認
動作確認
タスクのステータス確認
クラスタ内のタスクタブでステータスがRUNNINGになっていることを確認します。少し時間がかかる場合があります。
起動中のタスクIDを選択して詳細を確認します。

タスクの詳細確認
Networkの部分を見ると、ENI idがアタッチされていることが確認できます。
コンテナは外部に対してこのENIで通信します。
ENI IDを選択するとENIの画面に遷移します。

ENIの確認
ENIの画面に遷移したら、IPv4パブリックIPの部分を参照します。
ここに表示されているIPアドレスでコンテナと通信できます。

Nginxにアクセス
ブラウザで先程確認したIPアドレスにアクセスしてみます。

無事Nginxが起動していました。
後片付け
作成したクラスタを削除します。
...と言いたいところですが、単純に削除したところ途中でエラーが出ました。
サービスを作成した際にできたセキュリティグループが残ってしまうので、CloudFormationStackが削除できないことが原因でした。
おそらく正しい手順はサービスの削除 -> セキュリティグループの削除 -> クラスタの削除となります。
まさか最後にアンチパターンにぶつかるとは。。。

最後に
インスタンスを意識する必要がないので保守範囲が減り、期待通りかなり魅力あるサービスだと感じました。
運用面では監視に課題が出てきそうなのかなーと思いました。
なんにせよ、Terraformへの組み込みと、東京リージョンでのサービス開始が待ち遠しいです。




