
.NET 7でビルトインコンテナサポートが導入され、制約はありますがDockerfileを記載することなく、.NET のプロジェクトファイル(csproj)とdotnetコマンドのみでコンテナイメージのビルドまでできるようになりました。
さて、New Relicの.NET AgentをDocker環境にインストールする場合、ドキュメントの記載されているようにDockerfileにインストール処理を記述します。Dockerfileがなくなったビルトインコンテナサポートの場合、どのように.NET Agentをインストールすればよいのでしょうか。
Microsoftの公式ブログにもある通り、このような場合はビルトインコンテナサポートが利用するベースとなるコンテナイメージをカスタマイズします。あらかじめ.NET Agentをインストールしたイメージをベースとして指定することができます。
例えば、ASP.NET 向けのベースイメージであれば次のようなDockerfileでベースとなるコンテナイメージを作成します。
そしてビルドします。ビルトインコンテナサポートは現時点ではLinux amd64イメージしかサポートしていないのと、Windows上でビルドしているためプラットフォームを明示しています。リポジトリは利用するものを、イメージ名は任意です。
そしてリポジトリにプッシュします。ビルトインコンテナサポートが参照するベースイメージはリポジトリにあるものを完全修飾名でしか指定できないため同じマシンでテストするときもプッシュする必要があります。
ビルトインコンテナサポートを使う側では、プロジェクトファイルは次のようになります。
ContainerBaseImageで先ほどプッシュしたベースイメージを完全修飾名で指定します。また、元のイメージではライセンスキーとアプリ名を指定していません。コンテナ起動時に指定する方法もありますが、今回はアプリケーションのコンテナイメージの環境変数に指定することにし、ContainerEnvironmentVariableで指定しています。
これでdotnet publish --os linux --arch x64 -c Release -p:PublishProfile=DefaultContainer
のように実行するとNew Relic Agentを含んだコンテナイメージを作成できます。

本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。