C#による.NET Core入門（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の利用についても言及する。
先日公開した、.NET Core連載第1回目の「開発環境の準備」の節でRed Hat Enterprise Linux（以下、RHEL）は「対象外」と書いた。本記事では、なぜRHELを対象外としたのかを、レッドハットが提供している.NET Core（以下、rh-dotnetcore）とマイクロソフトが提供している.NET Core（以下、ms-dotnetcore）の違いから説明したい。なお本記事は執筆時点での公開情報のみを基に記述している。
レッドハット提供 .NET Coreの違い
RHEL環境の準備
もし、本記事に興味のある方で実際にRHELの環境で試してみたいという場合には、この節で説明する準備を参考にしてほしい。環境を用意しない場合は次の節まで読み飛ばしてもらって構わない。なお、本稿で以降に示すリンク先は全て英語となっている。
Red Hat製品はサブスクリプションという形態で購入することができる。が、開発者向けには無償でRed Hat Enterprise Linux Developer Programが利用可能である。興味のある方は、上記のリンク先から利用してもらいたい（※途中でdevelopers.redhat.comへの開発者登録が要求される）。具体的な手順を簡単に紹介しておくと、上記のリンク先を開き、冒頭にある「Red Hat® Enterprise Linux® 開発者プログラム」リンクをクリックする。これにより表示されるページ上の［GET STARTED］ボタンをクリックして、次のページで［Bare Metal］／［Hyper-V］／［KVM］／［VirtualBox］／［VMware］タブから1つを選択し、あとは説明・指示に従って実行していけばよい（※参考：RHEL Server 7.3の.isoファイルのダウンロードは、こちらのリンク先からも行える）。
なお、Developer Programで入手できるOSのイメージはベアメタル（Bare Metal： 仮想化されていない物理マシン）、もしくはHyper-VやVirtual Boxをはじめとした仮想マシン上での利用を想定しており、今のところクラウド上ではこのProgramは利用できない。例えばMicrosoft Azure上で利用したい場合は、Azure Marketplaceで提供している時間課金制の仮想マシンイメージ、もしくはDeveloper Programではない通常のRHELのサブスクリプションをCloud Accessという仕組みで持ち込んでの利用が必要となっている。さらに、Azure上でMarketplaceのRHELイメージを利用する場合の追加の注意事項として、MSDNなど一定額のAzure利用権を持っている場合、MarketplaceのRHELイメージは通常のAzure仮想マシンの利用料金に加えて、レッドハットのソフトウェア利用料（サブスクリプションに相当）がAzureの利用料金として課金される。仮想マシンの利用料金はAzure利用権から差し引かれるが、レッドハットのソフトウェア利用料の部分は差し引かれないため、別途請求されることになる。特に利用制限をかけている場合、MarketplaceのRHELのVMを起動することによりアカウント全体がいったん停止する可能性もあるので注意してほしい。
以上を踏まえて、まずはRHEL 7.3の環境を準備する。
準備できたところで、rh-dotnetcoreをインストールする。今回は.NET Core 1.1をインストールする。
参考までに、手元の環境でのインストール手順はリスト1にまとめているが、実際のインストール時には最新のドキュメントを参考にしてほしい。
|
# subscription-manager register
//Developer Programなどに登録したアカウントのユーザーとパスワードを入力する
# subscription-manager list --available
//登録したアカウントで利用可能なプールID一覧が表示される
# subscription-manager attach --pool=<appropriate pool ID from the above step>
//上記のコマンドで表示したプールIDを指定してアタッチする
# subscription-manager repos --enable=rhel-7-server-dotnet-rpms
# subscription-manager repos --enable=rhel-7-workstation-dotnet-rpms
# subscription-manager repos --enable=rhel-7-hpc-node-dotnet-rpms
//上記3つのコマンドのうち、マシンが該当するリポジトリを追加する。サーバーであればserver、ワークステーションであればworkstationとついているものをいずれか1つ指定する
# yum install scl-utils
# yum install rh-dotnetcore11
$ scl enable rh-dotnetcore11 bash
|
//以下は、インタラクティブな操作が必要な場合などのコメントである。#で始まるコマンド行はいずれもroot権限が必要。
※subscription-manager registerコマンドで「ユニット Consumer [……] の作成に問題があります。」というエラーが発生する場合は、こちらの公式ページの説明を参考にexport LC_ALL="en_US.UTF-8"を実行すると問題が解消する可能性がある。なお、このページを閲覧する際にはログインが必要であるので、最初に登録したDeveloper Programや既存のサブスクリプションがあるアカウントでログインしてほしい。
リスト1に掲載した一連のコマンドでは、RHEL環境にサブスクリプションを登録し、rh-dotnetcoreのリポジトリを有効にし、yumパッケージマネージャー経由で.NET Core 1.1の最新版をインストールしている。RHEL特有のコマンドとして、subscription-managerコマンドとsclコマンドが使われている点に注目してほしい。
subscription-managerコマンドは、その名の通りサブスクリプションの管理を行うコマンドで、リスト1では.NET Coreのリポジトリを有効にするために登録を行っている。Developer Programを利用している場合は、その際に作成したアカウントを指定すればよい。
また、sclコマンドはRed Hat Software Collections（以下、RHSCL）を管理するコマンドだ。RHELのOSそのものが長い期間サポートするのに対し、RHSCLはRHEL上でも更新が頻繁なプログラミング言語や開発ツールをサポートするために作られた機能だ。OS上に複数のバージョンの同じ言語やツールをインストールして切り替えるための機能を持っている。実際にRHEL上に.NET Coreの1.0と1.1を同時にインストールして切り替えることができる。切り替えるために、パッケージをインストールしただけではPATH環境変数にdotnetコマンドが追加されていないため、リスト1ではsclコマンドを実行し、PATH環境変数に追加している。なお、RHSCLは.NET Core以外にも多くの開発言語やツールをサポートしている。具体的なリストとそれぞれのサポート期間についてはこちらのドキュメントを参考にしてほしい。
.NET Core 1.xにおける大きな違い
本節で説明する違いは、.NET Core 2.0では解消される見込みであるが、現時点では非常に大きな違いとなっている。.NET Core連載で「対象外扱い」としたのもこれが理由である。
その違いとは、rh-dotnetcoreの1.0と1.1ではビルドツールがプレビュー版の1.0.0-preview2のままであることだ。つまり、.csprojファイル形式ではなく.NET Coreリリース当初のproject.jsonファイル形式であり、dotnetコマンドも従来のままである。実例を示すために、リスト2にプロジェクトを作成してビルドする一連の流れを載せている。
|
$ which dotnet
/opt/rh/rh-dotnetcore11/root/usr/bin/dotnet
$ dotnet --version
1.0.0-preview2-1-003177
$ dotnet --info
.NET Command Line Tools (1.0.0-preview2-1-003177)
Product Information:
Version: 1.0.0-preview2-1-003177
Commit SHA-1 hash: 124f278eb9
Runtime Environment:
OS Name: rhel
OS Version: 7.3
OS Platform: Linux
RID: rhel.7.3-x64
$ mkdir hwapp
$ cd hwapp
$ dotnet new
Created new C# project in /home/usr1/hwapp.
$ ls
Program.cs ▲project.json
$ dotnet restore
log : Restoring packages for /home/usr1/hwapp/project.json...
log : Writing lock file to disk. Path: /home/usr1/hwapp/project.lock.json
log : /home/usr1/hwapp/project.json
log : Restore completed in 5446ms.
$ dotnet run
Project hwapp (.NETCoreApp,Version=v1.1) will be compiled because expected outputs are missing
Compiling hwapp for .NETCoreApp,Version=v1.1
Compilation succeeded.
0 Warning(s)
0 Error(s)
Time elapsed 00:00:01.1433261
Hello World!
|
この点に関してはレッドハットのリリースノートにも記載がある。ちなみに、このような対応となっている背景には、以下のような事情があった。
ms-dotnetcoreが.NET Core SDKの正式版を導入したのに対し、rh-dotnetcoreが見送ったため、両者には大きな違いが出てしまった。しかし、.NET Core 1.xの途中での.NET Core SDKの正式版導入が破壊的変更だったのも事実であり、rh-dotnetcoreは破壊的変更の導入を見送った。
上記のリリースノートにも記載があるが、レッドハット版の.NET Core 1.x向けに開発する環境はどのように準備すればよいだろうか。
（1）まず、開発環境・ビルド環境・実行環境の全てがRHELでレッドハット版.NET Core（rh-dotnetcore）を利用する場合は、project.jsonファイル形式で開発およびビルドすればよいだろう。Visual Studio Codeは引き続きproject.json形式のプロジェクトもサポートしている。
（2）一方、開発環境やビルド環境がRHELでない場合は注意が必要だ。ビルド環境でdotnet publishまで行って、本番環境ではdotnetコマンドで実行、もしくはself-containedスタイルで実行ファイルを直接実行する場合は、開発環境およびビルド環境は.csprojファイルによる新しいビルド形式を利用していても問題ない。.dllファイルや実行（.exe）ファイルのバイナリ形式はproject.jsonファイルによる古いビルド形式から変わっていないからである。
（3）ただし、ビルド環境および実行環境がレッドハット版.NET Core（rh-dotnetcore）の場合は、開発環境もproject.json形式のビルドツールでなければならない。その場合はリリースノートに記載のある通り、Windowsであればproject.json形式のビルドツールのインストールが必要だ。Visual Studioで開発する場合は、project.jsonをサポートしているVisual Studio 2015を利用することをお勧めする。Linuxであれば手順に従いバージョンを指定して.NET Core SDKをインストールする方法を取ってほしい。
.NET Core 2.x以降も続くであろう違い
先ほどのリリースノートにある通り、rh-dotnetcoreも.NET Core 2.0のリリースで新しい.csproj形式のビルドツールに移行する予定である。これにより現状のような開発環境に注意が必要な大きな違いは解消されるはずだ。では、.NET Core 2.x以降ではrh-dotnetcoreとms-dotnetcoreは同一であるか、といわれれば答えはNOである。
rh-dotnetcoreは、ベースとなるGitHub上の.NET Coreに加えて、レッドハットが管理しているBugzillaで報告された問題の対応も取り込むことがある。一例として以下の2つのリンク先を見てほしい。
レポートされた問題の概要を示すと、これは「Linux上の.NET Core 1.0で、NFSファイル共有をマウントしたディレクトリ以下のファイルに対して、実行ユーザーに十分な権限があるにもかかわらず、File.WriteTextAllメソッドでテキストを書き込むと例外が発生する」という問題の報告である。issueをレポートした時点ですでに.NET Core 1.1ではこの問題は修正されており、「その修正を.NET Core 1.0にバックポートしてほしい」という依頼を行っている。結果としては、.NET Coreプロジェクトとしては1.0へのバックポートは「重大なバグのみ実施する」という指針で、「このバグは該当しない」と見なされ執筆時点で対応の予定は決まっていない。しかし、レッドハット側のBugzillaでは対応が行われ、rh-dotnetcore 1.0.4としてリリース済みである。
これは一例であるが、レッドハットは要望に応じてこのような修正を行うことがあるため、同じバージョンでも完全には同一のものとはならないわけである。なおこれに近い形の修正は、.NET Coreに限ったことではなく、レッドハットが提供している他のソフトウェアに対するセキュリティ修正としても見られる（なお、.NET Coreの修正はこのポリシーに該当するものではない）。「Backporting Security Fixes」というドキュメントが提供されているので参考にしてほしい。
OpenShiftとの関連
さて、RHEL上で.NET Coreを利用する場合、もちろんRHELサーバー上で直接.NET CoreのコンソールアプリケーションやASP.NET CoreのWebアプリケーションを動かすこともできるが、OpenShift上で動かすことの方が多いのではないだろうか。そこで本記事では、OpenShiftにおける.NET Coreサポートについても説明したい。
まず、OpenShiftについて説明しよう。OpenShiftは、正式にはRed Hat OpenShift Container Platformと呼んでいる通り、コンテナーを中心に考えたアプリケーションプラットフォームである。コンテナー技術の中でも現時点ではDockerを採用しており、さらにDockerコンテナーのオーケストレーション技術であるKubernetesを内包している。余談ながら、GitHub上で開発しているKubernetesはもともとグーグルの技術者が開発していたが、現在ではグーグルの技術者だけでなく、上位のコミッターにレッドハットとマイクロソフトの技術者も加わっている。
OpenShiftは、OpenShift Originと呼ばれるGitHubで公開されているupstreamプロジェクト（＝より上流で開発されている起源となるプロジェクト）と、OpenShift Enterpriseと呼ばれる商用サポート付きのものがある。Originの方は、CentOSを使って構築できるため、レッドハットの製品を購入することなく利用することが可能となっている。
このOpenShiftにおける.NET Coreのサポートの一つに、.NET Coreを動かすためのDockerイメージのサポートが挙げられる。OpenShiftはコンテナープラットフォームであるが、そのプラットフォームで動かすコンテナーについてもレッドハットがサポート付きでDockerイメージを提供している（なお、レッドハット提供以外のコンテナーイメージも動かすことができる）。複数の言語やミドルウェアをサポートしているが、その中に.NET Coreのイメージも含まれている。つまり、OpenShift Enterpriseで.NET Coreのアプリを動かす場合、自分でコンテナーイメージを作る必要はなく、しかもサポート付きのコンテナーイメージを利用することができる。
次に、s2iにおける、.NET CoreやASP.NET Coreのサポートが挙げられる。s2iというのはSource to Imageのことで、開発しているアプリケーションのソースコードからOpenShift上で（正確にはOpenShiftに限定されずDockerホスト上で）動作可能なDockerイメージを作成する技術である。アプリケーションをDockerとして動かす場合、コードが変更されるたびにDockerイメージを作成する必要があるが、OpenShiftの場合、GitリポジトリのWebhookや手動での操作をトリガーにして、リポジトリからコードを取得してs2iによるDockerイメージの作成およびOpenShiftへのデプロイまでを行うことができる。
このs2iでもいくつかの言語とフレームワークがサポートされているが、その中にASP.NET Coreが含まれている。そのためs2iを利用することで、利用者は通常のASP.NET Coreのプロジェクトを用意するだけで、あとはOpenShiftがDockerイメージを作成し、OpenShift上に展開するところまでを行ってくれる。
これらに加え、.NET Core on OpenShift Enterpriseの環境は、OpenShiftをホストするOSからOpenShiftそのもの、元となるDockerイメージやアプリケーションのDockerイメージの作成までを一貫してサポートしていることも特徴である。
■
以上、レッドハットが提供している.NET Core（rh-dotnetcore）とマイクロソフト提供版（ms-dotnetcore）との違いについて説明し、併せて、違うだけではなくレッドハットならではの価値としてOpenShiftにおけるサポートを説明した。
RHELサーバーでの.NET Coreの利用に興味を持った場合は、ぜひDeveloper Programを利用してほしい。
OpenShiftに関しては、SaaS形式で提供しているOnlineのpreview版が限定公開中であるが、アカウント作成待ちになることもあり、すぐに利用できないかもしれない。OpenShiftに興味を持った方は、OpenShift OriginやAzure上に一時的に無償で環境を作れるTestDriveなどで試してみてほしい。
※以下では、本稿の前後を合わせて5回分（第1回～第5回）のみ表示しています。
連載の全タイトルを参照するには、［この記事の連載 INDEX］を参照してください。
1. .NET Coreとは？ 開発環境（SDKとVisual Studio Code）のインストール
クロスプラットフォームで開発できる.NET Coreの基礎から開発実践までが学べる入門連載スタート。初回は.NET Coreの歴史／立ち位置／特徴を紹介し、開発環境の準備方法を説明する。
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の利用についても言及する。
3. .NET Coreでプロジェクトを作成して開発してみよう
クロスプラットフォームで開発できる.NET Coreの基礎から開発実践までが学べる入門連載。3回目は実際にプロジェクトを新規に作成して、Visual Studio Codeを使って開発するフローを説明する。
4. .NET Coreでコンソールアプリを配置する
クロスプラットフォームで開発できる.NET Coreの基礎から開発実践までが学べる入門連載。4回目は作成したコンソールアプリのプロジェクトをビルドして配置する手順を説明する。
5. .NET Standardなライブラリプロジェクトを作成して参照する
クロスプラットフォームで開発できる.NET Coreの基礎から開発実践までが学べる入門連載。5回目は.NET Standardなクラスライブラリなプロジェクトを作成し、別のコンソールプロジェクトから参照する方法を説明する。
