この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
しばたです。
年末年始のお勉強の一環で.NET on AWSの無料のセルフペースデジタルコースにチャレンジしていました。
コース中のハンズオンを試すにあたり「そもそもどの環境で実行しようか？」で悩むことになり結構ハマりました。
本記事ではハマりポイントのうちAWS Cloud9で.NETの開発環境を作る手順を共有します。
AWS Cloud9の.NET対応状況
前掲のハンズオンでは開発環境として「ローカルPC」か「Cloud9インスタンス」のどちらかを選ぶ形となっています。
このため「ハンズオンだしローカル環境を汚さないCloud9で良いな。」と考えたのですが、この判断はあまり良い結果にはなりませんでした...
残念ながらCloud9の.NETに対する状況は良いとは言えないのが率直なところです。
.NET開発の主力言語はC#ですが、Cloud9 IDEにおけるC#の対応状況は
- コードハイライトは可能
- コード補完は一部のみ可能
- デバッグ実行不可
といった状況です。
とりあえずコードを参照する分には問題ないですがこれで開発を継続するとなると厳しさを隠せません。
また、組み込みのビルド設定が無いためその辺は自分で設定の仕込みが必要です。
こちらは大した手間ではないのですが、できれば組み込みの設定が欲しいところです。
あと、これは.NETとは全然関係なく私個人の嗜好ではあるのですが、Cloud9インスタンス内ではマネジメントコンソールにログインしているユーザーの権限 *1を持つ一時クレデンシャルであるAWS Managed Temporary Credentialsが使われます。
私個人としてはEC2インスタンスではアプリケーションの動作に必要最小限の権限を持ったIAM Roleを使い「アプリケーションの権限が透過的になっている」方が嬉しく「人間の権限は明示的に制御したい」感じです。
AWS Managed Temporary Credentialsはお手軽でそれは大きなメリットなのですがちょっと私の用途には合わなかったです。
設定でAWS Managed Temporary Credentialsの自動更新を無効にすることは可能ですが、それをしてしまうとせっかくのお手軽さというメリットが消えてしまうので悩ましいですね。
私的推奨環境
ちょっと否定的な話をしてしまいましたが、私個人としては.NET on AWSの開発環境には「EC2でVS Code Remote Developmentを使う」のがベストだと考えています。
こちらはEC2にVS Codeをインストールしサーバーとして動作させクライアントからSSH接続で扱うものとなりますが、SSH接続はSSM Session Managerのポートフォワードでも良くTCP 22番ポートを公開しないで大丈夫です。
クライアントのVS Codeから透過的にサーバー上のリソースを扱えC#のデバッグも問題なくできます。
また、通常のEC2を使うのでIAM Roleも自分の好きな様にできます。(その代わり自分自身で権限周りを設計し設定する必要がありますが...ここはトレードオフです)
こちらの詳細は後日記事にするつもりです。
追記 : 記事にしました
構築手順
前置きが長くなってしまいましたが、今回はCloud9のはなしですのでここから実際に環境を作っていきます。
Cloud9インスタンスの作成
マネジメントコンソールからCloud9のサービス画面に移動し新規環境の作成を行います。
今回は下図の様な感じでdotnet-dev-envという名前の環境を新規に作ります。
ディストリビューションはAmazon Linux 2にしています。
その他設定は環境に応じて行ってください。
今回は既存のVPC環境のPublicサブネットにインスタンスを配備しSSMを使った接続を選んでいます。
環境の作成はあっさり完了します。
初期状態の確認
Cloud9 IDEに接続するとこんな感じです。
今回の環境にインストールされているソフトウェアのバージョンは以下の通りでした。
# AWS CLI
$ aws --version
aws-cli/1.19.112 Python/2.7.18 Linux/4.14.301-224.520.amzn2.x86_64 botocore/1.20.112
# Node.js
$ nvm --version
0.39.0
$ node --version
v16.19.0
# Docker
$ docker version
Client:
Version: 20.10.17
API version: 1.41
Go version: go1.18.6
Git commit: 100c701
Built: Wed Sep 28 23:10:17 2022
OS/Arch: linux/amd64
Context: default
Experimental: true
Server:
Engine:
Version: 20.10.17
API version: 1.41 (minimum version 1.12)
Go version: go1.18.6
Git commit: a89b842
Built: Wed Sep 28 23:10:55 2022
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.8
GitCommit: 9cd3357b7fd7218e4aec3eae239db1f68a5a6ec6
runc:
Version: 1.1.4
GitCommit: 5fd4c4d144137e991c4acebb2146ab1483a97925
docker-init:
Version: 0.19.0
GitCommit: de40ad0.NET SDKのインストール
Cloud9環境には.NET関連のソフトウェアは初期導入されていません。
このため一般的なLinux環境と同じ手順で.NET SDKを導入してやる必要があります。
# Install .NET SDK
sudo rpm -Uvh https://packages.microsoft.com/config/centos/7/packages-microsoft-prod.rpm
sudo yum -y update
# 今回はLTSバージョンである.NET 6 SDKをインストール
sudo yum -y install dotnet-sdk-6.0今回はVer.6.0.404がインストールされました。
$ dotnet --version
6.0.404あとdotnetコマンドの入力補完のため.bashrcに以下の記述を追加しておきます。
~/.bashrc
# bash parameter completion for the dotnet CLI
function _dotnet_bash_complete()
{
local cur="${COMP_WORDS[COMP_CWORD]}" IFS=$'\n'
local candidates
read -d '' -ra candidates < <(dotnet complete --position "${COMP_POINT}" "${COMP_LINE}" 2>/dev/null)
read -d '' -ra COMPREPLY < <(compgen -W "${candidates[*]:-}" -- "$cur")
}
complete -f -F _dotnet_bash_complete dotnet(Optional) AWS Deploy Tool for .NETのインストール
こちらの作業は任意なのですが、デジタルコースで使うのでインストールしておきます。
dotnet tool install -g aws.deploy.tools今回はこんな感じでVer.1.9.4がインストールされています。
$ dotnet tool install -g aws.deploy.tools
You can invoke the tool using the following command: dotnet-aws
Tool 'aws.deploy.tools' (version '1.9.4') was successfully installed.
$ dotnet tool list -g
Package Id Version Commands
---------------------------------------------
aws.deploy.tools 1.9.4 dotnet-awsツール自体はdotnet aws [サブコマンド]で利用します。
実体が$HOME/.dotnet/tools/dotnet-awsにあるため$HOME/.dotnet/toolsにPATHを通しておく必要があり、PATHを通すのは手動です。
今回は.bashrcの設定を変えPATHを通しています。
~/.bashrc
# 設定例
export PATH="$PATH:$HOME/.dotnet/tools"(Optional) .NET CLI extension for Lambda functionsのインストール
こちらは今回の趣旨とはまったく異なるのですが、以前に弊社にしざわによる記事がDevelopersIOで公開されていたので、その最新版として補記しておきます。
といってもコマンド一つ実行するだけですが...この手順は従来通り変更ありません。
# .NET CLI extension for Lambda functionsのインストール
dotnet tool install -g Amazon.Lambda.Tools結果はこんな感じでです。
$ dotnet tool install -g Amazon.Lambda.Tools
You can invoke the tool using the following command: dotnet-lambda
Tool 'amazon.lambda.tools' (version '5.6.2') was successfully installed.
$ dotnet tool list -g
Package Id Version Commands
---------------------------------------------------
amazon.lambda.tools 5.6.2 dotnet-lambda
aws.deploy.tools 1.9.4 dotnet-awsCloud 9 IDEビルド設定
ここまでの手順で最低限.NETアプリケーションの開発は可能です。
せっかくなのでCloud9 IDEのビルド設定を変更しもう少し「らしく」します。
Cloud9 IDEのメニューから「Run → Build System → New Build System」の順に選び独自のビルド設定を追加します。
記載内容は以下の様にします。
// Build dotnet
{
"cmd" : ["dotnet", "build"],
"info" : "Building .NET Application..."
}
このファイルを.NET Core.buildという名前で/.c9/buildersディレクトリに保存します。
続けてメニューから「Run → Run With → New Runner」の順に選択し新しいRunnerを作成します。
Runnerの内容は以下の様にします。
こちらは一応AWSのサンプルに倣っているのですが、必要に応じてカスタマイズした方が良さそうです。
// Run dotnet
{
"cmd" : ["dotnet", "run", "$args"],
"working_dir": "$file_path",
"info" : "Run .NET application..."
}
このファイルを.NET Core.runと言う名前で/.c9/runnersに保存します。
これで.NET用のビルド設定とRunnerができました。
動作確認
環境構築が終わりましたので簡単に動作確認をしてみます。
今回は~/environment/srcディレクトリを用意し、そこにWEB APIアプリケーションを作ってみます。
# srcディレクトリを用意
mkdir src
cd src/
# WEB APIアプリケーションを新規作成
dotnet new webapi -n WeatherAPI
# ディレクトリ移動
cd WeatherAPI/ここで直接dotnet runコマンドを打つかRunnerからdotnet runしてやればローカルサーバーを起動できます。
ただ、Cloud9ではローカルサーバーは8080 - 8082番ポートで起動しないと参照できないためlaunchSetting.jsonあたりの設定を適宜変えておいてください。
この状態でプレビュー表示ができるはずなのですが、なぜか私の環境ではできませんでした...
根本原因は不明なのですが、ユーザーガイドによればこの様な場合はhttps:// 環境ID .vfs.cloud9. リージョン名 .amazonaws.com/にアクセスすれば良いとのことで、確かにそうしたらアクセスできました。
環境IDはCloud9の詳細画面から参照可能です。
最後にCloud9 IDEの全体像はこんな感じになります。
良さげな雰囲気は出ています。デバッグ実行できませんが...
終わりに
以上となります。
Cloud9はお手軽に環境が用意できるのが非常に便利ですが.NETの開発にはちょっと厳しいかな？というのが率直な気持ちです。
まずは試すだけ試してCloud9を採用するか他の環境にするかを検討すると良いでしょう。
脚注
- 厳密には一部制約付き ↩
3
