はじめに
こんにちは、エンジニアの川上と申します。
AWS Fargateが東京リージョンでローンチされたこともあり、これを機にEC2 + IIS + C#(ASP.Net) で構築されたアプリケーションをECS(Fargate) + APS.NET Coreで動かそうと試みています。
このような構成のアプリケーションを実装するにあたり、ローカルでデバックする環境として、Visual Studio 2017のdockerサポートを利用してデバック環境を作成しました。
前提
- ローカルのOSとして、WIndows を想定しています。
- Visual Studio 2017のdockerサポートを利用するためには、前提としてDocker for Windowsのインストールが必要です。
なぜdockerサポートを利用するのか
実際のアプリケーションはdocker コンテナで動作するため、実行環境にできるだけ近いデバック環境を用意することで、デプロイ後に初めて気付く問題をできるだけ少なくできるメリットがあります。
注意点
ECSはタスク定義(どのコンテナイメージをどのくらいのリソースで動かすか等の定義)毎にIAM Roleを設定することができるため、AWSの他のサービスを利用する場合はタスクに割り当てられたIAM Roleを利用してアクセスすることができます。
しかし、ローカルデバック時には実行環境がローカルマシン上となるためIAM Roleが利用できません。
そのため、ローカルデバック時にAWSのサービスを利用するためには、自分のIAMアカウントを利用して実行するための仕組みが必要となります。
どうやって使うのか
Visual Studioを開き、「 デバック対象のプロジェクトを選択して右クリック > 追加 > コンテナーオーケストレーター 」とクリックします。
以下のファイルが生成され、デバック対象として「docker」が選択できるようになります。
- docker-compose.yml
- docker-compose.override.yml
- docker-compose.dcproj
ローカルデバック時にAWSクレデンシャルをコンテナから読み取れるようにする
前提としてクレデンシャルは流出すると大変なことになるため、設定ファイルにキーをべた書きすることは避けます。
また、各人の環境に実行前にキーを書いてもらうのも避けます。(間違ってリポジトリにアップするリスクを避ける。また、手間を増やしたくない)
AWSのクレデンシャル情報は通常「C:/Users/%USERNAME%/.aws」にあるので、これをコンテナ内で利用できるようマウントしてあげるのが今のところいいかなと考えています。
具体的な方法としては、以下のように設定を追加する形になります。
「.env」ファイルを編集
Windowsのパス記載ルールの差を吸収
COMPOSE_CONVERT_WINDOWS_PATHS=1
「docker-compose.override.yml」ファイルを編集
コンテナがクレデンシャルファイルをマウントした状態で実行されるため、コンテナ内からAWSのサービスを利用できるようになる
version: '3.4' # 「xxxxxxxxx」 は各自の環境に合わせて書き換えること services: xxxxxxxxx: environment: - ASPNETCORE_ENVIRONMENT=Development ports: - "80" volumes: - "/C/Users/${USERNAME}/.aws:/root/.aws"
ECSへデプロイするときはどうする?
ローカルデバックに必要な情報は「docker-compose.override.yml」に集約した形になりますので、ECSへデプロイするためのイメージを作成する場合は、このファイルを読み込ませないようにします。
具体的には以下のコマンドでイメージを作成します。
docker-compose -f docker-compose.yml build
-f を指定し忘れてアッとならにようCodeBuild等を利用するとなおよいかと思います。