Amazon Web Services は、.NET 開発者を自社のクラウド サービスに引き付けるための売り込みの一環として、「.NET 向けの独自のデプロイメント ツール」をプレビューしました。
AWS ソフトウェア エンジニアの Norm Johanson (.NET Foundation で AWS を代表) と Philip Pittle によると、.NET 開発者は「自分のアプリケーションに適したサービスは何か?」や「学習曲線を短縮するにはどうすればよいか?」といった疑問に悩まされているそうです。
AWS にアプリケーションをデプロイするためのさまざまなオプションの数を考えると、これは驚くことではありませんが、おそらくこれらの質問に答える最善の方法は、ツールを信頼するのではなく、調査と実験を行うことです。
AWS の考え方は異なります。ヨハンソン氏とピトル氏は、「このフィードバックを参考に、AWS にデプロイする .NET 開発者に対する考え方を根本から変えることにしました。各コンピューティング サービスに膨大なツールを提供するのではなく、.NET アプリケーションを基盤とした単一のツールを用意したいと考えています。このツールは、ユーザーに対して適切なサービスを提案し、最適なサービスへと導いてくれるものです」と述べています。
AWSデプロイメントツールはEC2とElastic Beanstalkを推奨しましたが、より興味深いECSオプションを選択しました。
.NET は Microsoft のテクノロジーであり、Visual Studio には組み込みのデプロイメントツールが搭載されています。これらのツールを使えば、Windows または Linux 向けの Azure App Service、Azure 仮想マシン、あるいは Azure Container Registry のコンテナーとしてパッケージ化することで、Azure クラウド上でプロジェクトを稼働させることができます。公開ウィザードは必ずしも最適なオプションを提示するとは限りませんが、デプロイメントを開始するために役立ち、後から調整することも可能です。開発者の最初の選択が、後日、重要なデプロイメントへと発展するケースが多いことから、AWS は Visual Studio を羨んでいるのかもしれません。
AWSは.NETアプリケーションも含めLinuxに注力しているため、新しい.NETデプロイメントツールは、WindowsではなくLinux向けの、以前は.NET Core（現在は.NET）と呼ばれていたアプリケーションのみを対象としています。.NET Lambda（サーバーレス）関数のサポートも予定されていますが、現時点では別ツールとして提供されています。将来的にはこの2つを統合する予定です。デプロイメントツールのコードはGitHubで公開されており、Node.jsに依存しています。コンテナ化されたデプロイメントにはDockerも必要です。
サンプルの.NET 5.0プロジェクトを用意し、新しいAWSツールを簡単に試してみました。セットアップはAWS認証情報を設定し、dotnetコマンドラインでツールをインストールするだけで済みました。プロジェクトはVisual Studio Codeを使用してC#で開発され、SQL Serverデータベースを使用しています。これは.NETプロジェクトでは一般的な組み合わせです。VS Codeでターミナルを開き、「dotnet aws deploy」と入力しました。
AWSが追い求めているのはこれでしょうか？Visual StudioのMicrosoftの公開ウィザードは、Azureの展開における複数のオプションを開発者に案内し、データベースサービスなどのアプリケーションの依存関係を賢く処理します。
最初の試みは、プロジェクトのトップレベルでコマンドを実行したため失敗しました。このレベルでは、アプリケーションを構成する複数のプロジェクトを結び付けるソリューションファイルが存在していました。ツールはこれをうまく処理できず、ソリューションファイルではなく、.csproj プロジェクトファイルのみを認識できました。メインプロジェクトのプロジェクトフォルダに移動し、そこでツールを実行する必要がありました。他のプロジェクトへの依存関係はここから参照されていたため、まだうまくいく可能性はありました。AWSは「将来的にはVisual StudioなどのIDEとの統合を計画している」と述べていましたが、その時点ではソリューション全体を解析する必要があると推測されます。
このツールは2つの選択肢を提示しました。Linux上のElastic Beanstalk（推奨）、またはコンテナ実行用のAWSサービスであるFargateを使用してASP.NET CoreアプリをAmazon ECS（Elastic Container Service）に接続するというものです。なぜBeanstalkが推奨されたのでしょうか？どうやらこのツールは、Dockerコンテナを定義するDockerfileがあるかどうかを確認しているだけのようです。Dockerfileがある場合はECSを推奨し、ない場合はElastic Beanstalkで管理される従来のEC2 VMを推奨します。これは、特にDockerfileがないにもかかわらず、通常はこのアプリをコンテナにパッケージ化することから、賢明な推奨とは言えないようです。
これら2つの高レベルの選択肢から、さらなる疑問が浮かび上がりました。Elastic BeanstalkはどのEC2インスタンスタイプを使用すべきでしょうか？あるいは、ECSを使用する場合、各コンテナに割り当てるCPUとメモリの量を定義するタスク仕様はどうあるべきでしょうか？タスクはいくつ割り当てるべきでしょうか？ECSがCPUとメモリをどのように管理しているかを注意深く検討することをお勧めします。
デプロイツールは、かなり恣意的に思える選択肢を提示しました。デフォルトではすべての詳細が表示されませんでしたが、「詳細」をクリックすると追加情報が表示されました。Elastic BeanstalkのEC2インスタンスタイプは空白で、環境はSingleInstanceに設定されていました。ECSの場合、ツールは256CPUユニットと512MBのRAMを持つ3つのタスクを提案しました。ツールはアプリケーションを実行して必要なRAM容量を特定しなかったため、これは単なるデフォルト設定であると推測されます。
このツールはECS仕様についていくつかの決定を下しますが、アプリケーションの実行方法に関するメトリクスは考慮しません。
デプロイメント ツールによって提供される仕様は、ほとんど当てずっぽうのようでしたが、ECS クラスターの作成やそれを実行するための IAM ロールの作成などのジョブは処理できました。
質問が「AWS 上で動作するものをどのように入手するか」である場合、いくつかの注意事項はあるものの、このツールでそれが可能になるようです。
注意点は何でしょうか？MicrosoftのVisual Studio公開ウィザードは非常に賢く、データベースが必要かどうかを確認し、データベースに接続し、.NETオブジェクトリレーショナルモデリングツールを使用している場合は、Entity Frameworkの移行を実行してデータベーススキーマを最新バージョンに更新するといった処理を実行します。AWSデプロイメントツールは、まだ最初のプレビュー段階ですが、このような処理は行いません。Johanson氏とPittle氏は次のように述べています。「新しい.NETデプロイメントエクスペリエンスはまだ初期段階です。ツールを試用してフィードバックを得る絶好の機会です。」
このツールを使用した展開は、AWS 上に SQL Server をセットアップするための追加の作業なしでは機能しなかったでしょう。
もう一つの疑問は、この取り組みが一般的なDevOpsパイプラインにどのように適合するかということです。MicrosoftのVisual Studio公開ウィザードの場合、小規模なプロジェクトには便利ですが、多くの場合、テストやその他の予防措置や機能強化を含むスクリプト化されたソリューションが優先され、利用は見送られます。本番環境のアプリケーションも、一般的にステージング環境にデプロイされます。
このデプロイメントツールは、インフラストラクチャをコードとして定義するAWS CloudFormationを内部的に使用しています。つまり、ツールの出力は原理的にはGitHub ActionsやAWS CodePipelineに組み込むことができます。また、このツールには、1つのコマンドでデプロイメントの一覧表示と削除を行う機能も備わっているため、開発者による実験のクリーンアップも容易です。さらに、更新されたアプリケーションの再デプロイも可能なため、テストやその他のアクションを実行するスクリプトにこのツールを組み込むことも可能です。
ドキュメントによると、サポートされるアプリケーションの種類はASP.NET Coreウェブアプリケーションだけでなく、Blazor WebAssembly、長時間実行サービスアプリケーション、スケジュールタスクも含まれます。これらの後者の2つのタイプはコンテナ化され、必要に応じてツールが自動的にコンテナ化を行います。
このツールによって提起された 2 つの大きな疑問は、1 つ目は、コード エディターからクラウド展開までの迅速なパスを提供するという点で AWS が Microsoft に追いつくことができるかどうか、2 つ目は、アプリケーションに適切かつコスト効率の高いクラウド インフラストラクチャを選択する方法という複雑な問題に関して、ウィザード型ツールがどの程度まで賢明な判断を下せるか、という点です。
現状では、AWS .NET デプロイメントツールはどちらの目標にも程遠いですが、今後改善されるのは間違いありません。簡単なドキュメントはこちらにあります。®
