C#による.NET Core入門（4）

.NET Coreでコンソールアプリを配置する

Language .NET Core

2017年9月29日

クロスプラットフォームで開発できる.NET Coreの基礎から開発実践までが学べる入門連載。4回目は作成したコンソールアプリのプロジェクトをビルドして配置する手順を説明する。

レッドハット株式会社　田中 孝佳

• ← 前回
• 連載 INDEX
• 次回 →

.NET Core 2.0 SDKインストール方法の変更［対象： Linux］

　CentOSをはじめ、以前はtar.gz形式の圧縮ファイルを解凍してインストールしていたLinuxディストリビューションについても、rpmなどのパッケージとして配布されたものをインストールする方法が紹介されるように公式ページでのインストール方法の記載が変更されている。

　必ずしも再インストールする必要はないが、今回の後半でLinuxサーバーに配置する際に、ログインシェルを持たないdotnetuserでdotnetプロセスを実行している部分が、従来のインストール方法だとそのままでは実行できなくなる。rpmパッケージによるインストールでは実行可能である。

　そのため、インストールし直したい場合は、PATH環境変数から~/dotnetを削除し、rm -rf ~/dotnetコマンドで解凍したフォルダーを削除した後、公式ページの手順でインストールし直してほしい。

　従来のユーザーディレクトリに展開している状態のまま、Linuxサーバーへの展開の節を読み進める場合は、実行ユーザーを.NET Core SDKをインストールしたユーザーにし、dotnetコマンドのフルパスを解凍先のディレクトリに読み替えて試してほしい。

.NET Core アプリケーションの配置

2種類の配置方法

　前回の記事で説明した通り、作成したプロジェクトはdotnet runコマンドでアプリケーションを実行できる。しかし、この方法では実行環境にソースコードを含めたプロジェクトが存在している必要があり、かつコマンド実行のたびにビルドが実行される。

　そこで.NET Coreでは、.NET Framework同様にアプリを事前にビルドしておき、ビルド成果物であるバイナリファイルを配置してアプリを実行する方法が用意されている。具体的には、フレームワークに依存する展開（Framework-dependent deployment、FDD）と自己完結型の展開（Self-contained deployment、SFD）という2種類の方法が利用可能である。

　フレームワークに依存する展開は、アプリケーションが動作するOSに.NET Coreのランタイムがインストールされていることを前提としている。.NET Frameworkでの配置と同様の仕組みだ。

　この方式の利点としては、ビルド成果物のバイナリがOSによらず同一であるためビルドの実行や配置が容易になること、ビルド成果物が軽量になること、複数のアプリを同じOSで実行する場合に.NET Coreランタイムは共通であるためディスク使用量が削減されること、といった3点が挙げられる。

　一方、欠点としては、事前に.NET Coreランタイムのインストールが必要であること、.NET Coreランタイム側のバージョンアップでまれではあるがアプリの動作に変更が生じる可能性があること、の2点が挙げられる。

　自己完結型の展開は、.NET CoreのランタイムがサポートしているOSかつ必要なネイティブパッケージが利用可能であれば事前にランタイムのインストールをすることなく、配置するバイナリのみで実行可能な形式である。OSにランタイムがインストールされていても利用することはなく、あくまで配置するバイナリに含まれるランタイムを利用する。

　事前のランタイムインストールが不要ということと、利用するランタイムを完全に固定できるのが利点だ。

　欠点としては、OSごとにビルドを行ってバイナリを生成しないといけないこと、ランタイムが含まれるので配置するバイナリのサイズが大きくなること、配置先のマシンで占めるディスク容量が増えることが挙げられる。

　それでは前回作成したアプリを使って2種類の配置方法を試してみよう。作成していない人は前回の記事を読んで作成するか、任意のコンソールアプリを使って試してほしい。その場合、プロジェクト名やファイル名などは適宜読み替える必要がある。

フレームワークに依存する展開

　フレームワークに依存する展開は、dotnet newコマンドで作成したデフォルトのプロジェクトファイルを利用してdotnet publishコマンドでバイナリを生成できる。

　引数は指定しなくてもデフォルト値が使われるが、リスト1では2つ指定している。

-fオプション： フレームワーク

　最初の-fオプションは実行時に利用するフレームワークを指定している。フレームワークはアプリケーションが利用できるAPIの一覧を定義しており、フレームワークに依存する展開の場合は、実行時に指定したフレームワークをサポートするランタイムがインストールされている必要がある。netcoreapp2.0というのは.NET Core 2.0に対応している。他にはnetstandard2.0（.NET Standard 2.0）、netcoreapp1.1（.NET Core 1.1）、net47（.NET Framework 4.7）などがある。このページにターゲットフレームワークの詳細な説明がある。このうち、netstandard2.0はクラスライブラリを開発する次回で詳細に説明する予定である。

　フレームワークはプロジェクトファイル側でも指定する必要があり、デフォルトで作成されたファイルではリスト2のように1つだけ指定されている。

　また同一のソースコードファイルで複数のターゲットフレームワークを指定することもできる。その場合、リスト2の<TargetFramework>要素を消して<TargetFrameworks>要素（複数形になっていることに注意）を追加して、;区切りで複数のフレームワークを指定する（リスト3）。

　publishコマンド実行時にはここで指定したフレームワークのうち1つを選んで-fオプションに指定することになる。

-cオプション： ビルド構成

　次に-cオプションで指定したReleaseだが、これはビルド構成を指定している。ビルド構成は多くの場合DebugとReleaseの2種類があらかじめ想定されているが、任意の文字列で好きな構成を指定できる。構成ごとに参照するライブラリを切り替えたり、#ifディレクティブを利用してビルド対象とするソースコードを切り替えたりできる。Debugビルド時はより詳細にログを出力するようにコーディングするといったことに利用できる。

　なおDebugビルドでバイナリを生成することもできるし、Releaseビルドでdotnet runコマンドを実行することもできる。ともに-cオプションで指定すればよい。

アプリケーションの配置方法と実行方法

　さて、dotnet publishコマンドで生成したバイナリはデフォルトでは、bin/＜ビルド構成＞/＜ターゲットフレームワーク＞/publishディレクトリ以下に出力される。つまりリスト1のコマンドであればbin/Release/netcoreapp2.0/publishだ。

　.NET Coreアプリを実行するためには、このディレクトリ内の全ファイルを単純にコピーして、実行するOS上の任意のディレクトリに配置すればよい。なお、配置先のディレクトリは、dotnetコマンドを実行するユーザーがアクセスできる必要がある。

　ちなみに、このディレクトリの中には、拡張子が.pdbのファイルがある。この.pdbファイルはデバッグ時に役に立つ情報が含まれているが、配置時に含める必要はない。

　配置したアプリを実行する場合は、アプリ名.dllをdotnetコマンドの引数に指定すればよい（リスト4）。

　また、前回のサンプルアプリを利用している場合、NuGetからライブラリを追加した状態でpublishを実行している。この場合、ライブラリのうち実行に必要なバイナリもpublishディレクトリに配置されている。

自己完結型の展開

　フレームワークに依存する展開と異なり、自己完結型の展開はまず、プロジェクトファイルに実行先のOSを指定する必要がある。実行先のOS、より正確にはプラットフォームごとにランタイム識別子（RID）が用意されており、一覧はこのページで確認できる。

　例えばLinuxであればポータブル（共通化）としてlinux-x64が用意されている。.NET Core 1.1までは各ディストリビューションのRIDを指定する必要があったが、.NET Core 2.0からは追加したライブラリが特定のRIDのみをサポートしてない限りは、このポータブルなRIDが利用できる。

　今回はリスト5のようにWindows、Linux、macOS（全て64bit OS）を指定した。

　プロジェクトファイルでRIDを指定したら、RIDごとにバイナリを生成する。-rオプションでRIDを指定する。

　すると、bin/＜ビルド構成＞/＜ターゲットフレームワーク＞/＜RID＞/publishディレクトリに、配置用のファイル群が出力されているはずだ。さて、それぞれのプラットフォームごとの出力結果を見てみよう。

図1　自己完結型の展開で生成した実行可能バイナリのファイル形式

　Windowsなら.exe、LinuxやmacOSなら拡張子なしと、プラットフォームごとに実行可能なファイル形式が異なっている。そして、注目してもらいたいのが、このビルドを行ったのはLinux（筆者の環境ではCentOS 7.2）であるということだ。LinuxでLinux向けはもちろん、WindowsやmacOS向けの実行可能形式なバイナリファイルを出力可能である。

　あとは、publishディレクトリ以下のファイルをサブディレクトリも含めて実行先のOSにコピーし、実行すればよい。最初に説明したように、そのときOSに.NET Coreがインストールされている必要はない。ただ、WindowsでLinux向けのバイナリをビルドしてLinuxにコピーした場合、実行可能権限がつかない点に注意してほしい。

Linuxサーバーへ配置する

　配置したバイナリはコンソールやターミナルからコマンドで実行可能ではあるが、実際のシステムでは異なる実行方法が必要になることが多いだろう。WindowsであればWindowsサービスにしたり、タスクスケジューラーでスケジュール実行したりできる。

　この節では、Linuxについて、かつ紹介するソフトウェアが利用できるディストリビューション限定ではあるが、バックグラウンドプロセスとして実行する方法や、スケジュール実行する方法を紹介する。

systemdを使いバックグランドプロセスとして実行する

　systemdはLinuxの起動処理に使われているが、プロセス管理にも使うことができ、カスタムユニットを定義することで.NET Coreアプリを管理できる。今回は単純なカスタムユニットファイルを作成して、systemctlコマンドで実行させてみよう。なお、systemdはその性質上、多くのLinuxではすでにインストールされているはずである。

　まずサーバー側の事前準備として、配置したアプリを実行する専用のユーザーを作成する。

　リスト7ではdotnetuserという名前を指定している。そしてアプリを配置するディレクトリを用意し、cpコマンドでコピーしている。これは同一マシンで配置しているが、リモートのマシンで実行する場合は、適当な方法で転送を行えばよい。配置したディレクトリの所有者を実行するユーザーに変えて事前準備は完了である。

　次にsystemdのカスタムユニットファイルを指定する。

　カスタムユニットファイルは/etc/systemd/system/＜ユニット名＞.＜ユニットタイプ＞に作成する。今回作成するユニットタイプはserviceであり、ユニット名は任意の名前でよい。netcore-example03.serviceという名前でリスト8のようなユニットファイルを作成した。

　Type=oneshotとRemainAfterExit=noを指定することで、サービスが起動されたらコンソールアプリが実行され、実行完了したらサービスも停止するようにした。ExecStartで実行するコマンドを指定しているが、ここではdotnetコマンドはフルパスで指定する必要がある。引数のExample03.dllが相対パスとなっているが、基準はWorkingDirectoryで指定したディレクトリである。UserとGroupでプロセスを実行するユーザーとグループを指定する。このファイルを保存したら、daemon-reloadした後、起動してみよう。リスト9に実行結果と合わせてコマンドを記載した。

　journalctlコマンドで-uオプションにユニット名を指定することで、systemdのユニットのログを確認できる。これでバックグラウンドプロセスとして実行できた。

cronを使いスケジュール実行する

　次にスケジュール実行するためにcronを利用してみよう。

　cronも最初からインストールされていることが多いと思われるが、入っていない場合、例えばCentOS 7であればsudo yum install cronieでインストールできる。

　cronは、cron書式と呼ばれる形式で指定したコマンドを、指定したタイミングで定期的に実行できる。今回はcronの詳細の説明は割愛するが、必要な場合は適宜検索して調べてほしい。

　systemctlコマンド経由でcronから実行したいため、rootユーザーのcronを編集する必要がある。そのためリスト10のようにsudo crontabで編集画面を呼び出し、適宜入力する。リスト10では毎分実行するように指定している。

　登録後、1分以上待つと、実行結果をjournalctlで確認できるはずだ（リスト11）。

Dockerコンテナーを作成する

　最近ではコンテナーの利用が進んでおり、.NET Coreで作成したアプリも、直接、Linuxのホストで動かすよりDockerや他のコンテナーで動かすケースの方が多いかもしれない。

　Dockerを使った.NET Coreアプリの配置やデプロイは、よりユースケースが多いであろうASP.NET Coreのところでも詳しく説明する予定だが、今回はDockerfileを書いて、シンプルなコンソールアプリを含んだDockerコンテナーを作成する方法を紹介する。

　なお、コンテナーを中心に置いたContainer as a Service、Platform as a Serviceのソフトウェアやサービスでは、Dockerfileをユーザーに記述させることなく、ソースコードのリポジトリやいくつかのビルド設定を指定するだけでアプリケーションのコンテナーを作成する機能が備わってきている。今後、Dockerfileそのものを記述することは少なくなる可能性もあるため、Dockerfileそのものの詳細な記述方法については省略する。

　まずはDockerをインストールして、有効化、起動しておく（リスト12）。

　Dockerコンテナーのイメージは、ベースとなるコンテナーを基に必要な操作をDockerfileに記述し、ビルドして生成する。.NET Core向けにはDocker Hub上でマイクロソフトが目的に合わせて何種類かのコンテナーイメージを公開している。また、マイクロソフト以外で.NET Coreをサポートしているレッドハットもレッドハットがサポートする.NET Coreのコンテナーイメージを公開している。

　今回はDocker Hubで公開されているLinuxコンテナーを利用する。用意されているタグ（TAG）とその利用目的は公式ドキュメントにも記載されているが、改訂中で情報が古くなっているので、以下でも簡単に説明しておこう。

　コンテナー内にソースコードを配置してビルドできるコンテナーもあるが、そのためには.NET Core SDKがインストールされている必要があり、コンテナーの容量が大きくなる。そこで、実行するためだけのコンテナーとして、.NET Coreランタイムのみをインストールしたものをベースに使い、バイナリファイルをコピーしてイメージを作成する。.NET Core 2.0でこの目的のために公開されているコンテナーイメージが、microsoft/dotnet:2.0-runtime（＜リポジトリ＞:＜タグ＞）である。

　また自己完結型の展開の場合は、.NET Coreのランタイムは不要だが、必要なネイティブパッケージが利用可能になっていなければならない。その準備が整ったコンテナーイメージがmicrosoft/dotnet:2.0-runtime-depsである。

　次にDockerfileを記述する。

　まずは.NET Coreランタイムがインストールされているコンテナーを使って、フレームワークに依存する展開をしたバイナリを配置してみよう。今回はバイナリと同じディレクトリにリスト13のようなDockerfileを記述し、リスト14のようにビルド、実行を行った。特に指定しない場合、docker buildコマンドの最後にイメージ名が表示されるので、そのイメージ名を指定して実行している。

　今度は、.NET Coreランタイムが含まれていないコンテナーに自己完結型の展開をしたバイナリを配置してみよう。Dockerfileがリスト15、ビルドと実行した例をリスト16に載せた。

　ベースとなるイメージと起動コマンドが異なるだけでリスト13とほとんど同じである。さて、それぞれのdockerイメージのサイズを確認したのが図2である。

図2　リスト14やリスト16で利用・作成したイメージの容量

［IMAGE ID］＝6b8b05e03c41がフレームワークに依存する展開、0056283e768aが自己完結型の展開をそれぞれ配置したイメージである。

　.NET Coreランタイムがインストールされていない分、2.0-runtime-depsの方が当然2.0-runtimeより軽量であるが、どちらも.NET Coreランタイムとアプリのバイナリが配置されるため、作成したコンテナーの容量は同程度になっていることが分かる。

■

　今回は2種類の配置方法とそれぞれのバイナリの生成方法を説明し、実際の配置例として、Linuxホスト上でのsystemdやcronによる管理、さらに.NET Coreアプリを配置したDockerコンテナーの作成までを行った。

　次回はクラスライブラリプロジェクトの作成を依存関係のある複数のプロジェクトを利用しつつ説明する予定だ。

• ← 前回
• ▼ この記事の連載 INDEX ▼ 連載 RSS
• 次回 →

※以下では、本稿の前後を合わせて5回分（第1回～第5回）のみ表示しています。
　連載の全タイトルを参照するには、［この記事の連載 INDEX］を参照してください。

1. .NET Coreとは？ 開発環境（SDKとVisual Studio Code）のインストール

クロスプラットフォームで開発できる.NET Coreの基礎から開発実践までが学べる入門連載スタート。初回は.NET Coreの歴史／立ち位置／特徴を紹介し、開発環境の準備方法を説明する。

2017年6月6日(火曜日)

2. レッドハット版.NET Coreとマイクロソフト版.NET Coreの違い

.NET CoreのMicrosoft提供版とRed Hat提供版には違いがある。Red Hat Enterprise Linux上でのNET Core環境の構築方法を紹介したうえで、.NET Core 1.xと2.x以降での違いを示す。さらにOpenShiftでの.NET Coreの利用についても言及する。

2017年7月5日(水曜日)

3. .NET Coreでプロジェクトを作成して開発してみよう

クロスプラットフォームで開発できる.NET Coreの基礎から開発実践までが学べる入門連載。3回目は実際にプロジェクトを新規に作成して、Visual Studio Codeを使って開発するフローを説明する。

2017年9月5日(火曜日)

4. 【現在、表示中】≫ .NET Coreでコンソールアプリを配置する

クロスプラットフォームで開発できる.NET Coreの基礎から開発実践までが学べる入門連載。4回目は作成したコンソールアプリのプロジェクトをビルドして配置する手順を説明する。

2017年9月29日(金曜日)

5. .NET Standardなライブラリプロジェクトを作成して参照する

クロスプラットフォームで開発できる.NET Coreの基礎から開発実践までが学べる入門連載。5回目は.NET Standardなクラスライブラリなプロジェクトを作成し、別のコンソールプロジェクトから参照する方法を説明する。

2017年12月7日(木曜日)