.NET Core 2.0のリリースによって、Microsoftは、2016年にリリースした汎用目的、モジュール構造、プラットフォーム不問のオープンソースのプラットフォームの次期メジャーバージョンを手にしました。.NET Coreは、現行の.NET Frameworkで利用可能なAPIの大部分を持つように設計されています。元々はASP.NETソリューションの次世代版を実現するために開発されましたが、現在ではIoTやクラウド、次世代モバイルソリューションなど、まったく違うシナリオを担う、基盤的な存在となっています。.NET Coreを取り上げたこのシリーズの第2回では、.NET Coreのさらなるメリットと、既存の.NET開発者のみならず、堅牢性、パフォーマンス、経済性を兼ね備えたソリューションを市場に投入する必要のあるすべての技術者にとっての価値を探ります。
私は.NET 1.0がベータ版の頃から、長くソフトウェア開発に携わってきました。当時は.NETを使っていて、何かだまされているように思ったのを覚えています。“こんなに簡単で大丈夫なのだろうか？”と私は思いました。“mallocはどうしたんだ？ポインタ計算でキャストを綴る必要はないのだろうか？このFramework Class Libraryというのは何なんだ？”最初の6ヶ月間は、何か巧妙なトリックがあるに違いない、と思いながら過ごしました。
2018年になった今、私たちは.NET Frameworkで快適にコーディングしています。もはやメモリ割り当てに気を使う必要はありません。スレッドはSystemが面倒を見てくれます。Thread、BackgroundWorker、現在はTaskです。FCLクラスはスレッドセーフか、あるいはそうでないか、事前に定義されています。Webアプリケーションを書きたい？完全なフレームワークがあって、道具立ても整っています。私たちが手作りしなければならなかったものは、ほとんど、.NETがお膳立てしてくれています。その結果、私たち開発者は、ビジネス価値を提供するコードを書くために、ますます長い時間働くことになるのです(何てこった！)。アセンブリ/C/C++のヒップスター連中は非難の声を上げて、凡庸な開発者がハードコアなシステムプログラミングに必要な知識を持たなくなった現状を嘆くかも知れません。私個人としては、不満はありませんが。
最初のベータ版リリース以来、.NETは、4つのメジャーバージョンを含む多くのイテレーションをくぐり抜けてきました。その最新イテレーションである.NET Coreは、最も重要なものでもあります。.NET Coreは、真のクロスプラットフォームを目標として、現代的なCLIとビルドシステム、オープンソースライブラリを備えています。ただし、これらはほんの一部に過ぎません。重要ではありますが、.NET Coreの目指すものはさらに先にあって、ソフトウェアの開発やデリバリの方法にまで至っているのです。
私は20年以上ソフトウェアを書いているので、ソース管理が“大規模”チームのためのものであった時代も知っています。“自動化”という言葉は、ユーザ向けのビジネスプロセス自動化に関するものを除けば、私たちの用語集にはありませんでした。ソフトウェアの構築やコンパイルは、皮肉なことに、人手で行う仕事だったのです。“ビルドマネージャ”が、自身のコンピュータを使ってバイナリ(そのマシン上では動作する、というのが常でした)を生成していました。
実行環境へのソフトウェアのデプロイメントは(多くの場合は今でもそうですが)、共有ドライブやFTP、あるいは手作業によるファイルのコピー/ペーストに頼った、危なっかしく複雑なプロセスでした。開発チームの成果を統合する作業は悲惨なデスマーチとなり、リグレッションに次ぐリグレッションのモグラ叩きゲームでした。ソフトウェアが運用レベルに達したかって？やってみなければ分からないよ！
ソフトウェアはあっという間に世界が求める存在になりましたが、TuringやHopperの時代にはまだ、ソフトウェアベースシステムの開発やデプロイ、運用といったプロセスには大きな進歩がありませんでした。そのような中で革命が息吹き、2008年頃に形をなし始めました。それがDevOpsです。
それから今日までの数年間に、 ひとつの運動として盛り上がりました。DevOpsは、それ以前に起きたAgileのムーブメントを包含し、おそらくは取って代わる大きなものです。私がDevOpsを知ったのは2014年、あるカンファレンスでThe Phoenix Projectを受け取った時です。わずか数ページを読んだだけで、私は即座に、それまでの自分の人生を一転させるような、運命的な決断をしました。馬鹿な話です。その日のカンファレンスでの計画は投げ出して、その本を貪るように読みました。その本は、多くのことを私に語りかけてくれました。IT業界に短期間でも身を置いた経験があれば、同じような経験があるのではないでしょうか。分かって頂けると思います。その瞬間からDevOpsは、私のキャリアの中心になったのです。
DevOpsは一般に、3つの大きな“足”を持つと言われます。文化、プロセス、そしてテクノロジです。この記事では、DevOpsのテクノロジを取り上げています。具体的には、.NET Coreが現代のDevOpsプラクティスにもたらすテクノロジについてです。.NET CoreはDevOpsの黎明期に生まれました。Microsoftには、.NET CoreをDevOps時代のプラットフォームにしようという明確な目標があります。この記事では、.NET CoreとDevOpsの主要な3つのトピックについて説明します。
- .NET Core FrameworkとSDK
- ビルドオートメーション
- アプリケーション監視
.NET Core FrameworkとSDK
DevOpsはそれだけで存在しているのではありません。ソフトウェアベースのシステムを作成し提供するテクノロジは、DevOpsプラクティスを支援する場合もあれば、妨げる場合もあります。テクノロジスタックが何であるかに関わらず、DevOpsは追求する価値があります。とは言うものの、スタックとして何を選択するのかが、DevOpsプラクティスに大きな影響を与えることは事実です。
クローズドソースでプロプライエタリなビルドシステムは、DevOpsフレンドリではありません。.NET Coreは完全なオープンソースで、プロジェクトとソリューションの表現に使用されるファイルフォーマットは完全に文書化されています。Node/JavaScript、Ruby、Pythonといった最新の言語やフレームワークは、いくつかの共通的な機能を持って開発されています。
- コンパクトなオープンソースのフレームワーク
- コマンドラインインターフェイス(CLI)
- 文書化されたオープンビルドシステム
- 主要なオペレーティングシステムをすべてサポート
これらの機能や他の機能は、適用や自動化が容易なことから、DevOpsの時代にポピュラーになったものです。.NET CoreのCLIであるdotnetは、.NET Coreアプリケーションのすべてのビルドプロセスに対する唯一のエントリポイントです。dotnet CLIは開発者のワークステーション上で動作し、プラットフォームに依存しないエージェント的な環境を構築します。実を言うと、これから私が説明するすべてのローカル開発作業は、すべてMacBook Pro上で実行しています。わずか3年前には想像もできなかったことです！
.NET Coreの最初のステップは、それをダウンロードすることです。手順に従う場合は、こちらからSDKをダウンロードしてください。サイズは小さく、MBP上で171MBに過ぎません。インストールが終わったら、好みのターミナルウィンドウを開きます(私はWindowsではPowershellをよく使っていますが、MacなのでiTerms2を使用します)。
.NET開発の経験をお持ちならば、大規模なフレームワークのインストールには慣れていると思います。Visual Studioを使って作業することにも慣れているでしょう。.NET Coreを初めて使う場合は、よい意味で、ちょっと奇妙に感じるかも知れません。IDEに触れる前に、この171メガバイトを使ってたくさんのことを行います。
実行:
dotnet
このdotnetは、システム上で.NET Core SDKとのインタラクションを可能にする、新しいCLIコマンドです。ここでの出力は、使用可能なCLIオプションが羅列されるだけです。詳しく見ていきましょう。
実行:
dotnet help
これはCLIがサポートするすべてのコマンドのリストです。長くはありませんし、その必要もありません。ここに表示されたものが、“フレッシュキャンバス”プロジェクトからアプリケーションのデプロイまで、.NET Coreフレームワークで作業する上で必要なすべてのものです。
最初のステップはアプリケーションの新規作成です。オプションを確認しましょう。
実行:
dotnet new
出力は使用可能なテンプレートのリストです。これはVisual StudioでFile-New-Projectをクリックした時の一部で、ここではそれをコマンドラインから実行しているだけです。選択可能なテンプレートはたくさんありますが、私はAngularが好きなので、それから始めることにしましょう。
実行:
dotnet new angular -o dotnet-angular
新しいディレクトリdotnet-angularに、新たなAngularプロジェクトが作られます。ディレクトリを手作業で作ることも可能ですが、dotnet newを実行する時に、そのディレクトリに移動することを忘れないでください。そうでないと、カレントディレクトリにプロジェクトが生成されます(私はこれで失敗しました)。
すでにAngular開発を行っているのであれば、Nodeはインストール済だと思います。そうでなければ、ダウンロードとインストールを行ってください。Nodeのインストールが必要な場合は、インストール後にターミナルを閉じて開き直します。
実行:
dotnet run
このコマンドは、アプリケーションをコンパイルして実行します(dotnet buildで、アプリケーションを実行せずにコンパイルすることも可能です)。数分かかった後、URLを含むアウトプットがあるはずです。
** Content root path: /Users/dswersky/dotnet-angular Now listening on: https://localhost:5001 **
URLをWebブラウザにコピーして開いてみてください。ASP.NET Coreがバックエンド、Angularがフロントエンドで動作する、簡単なアプリケーションが見えるはずです。ここで一息ついて、このエクスペリエンスがこれまでの.NET開発エクスペリエンスとどう違うのか、説明しましょう。
ここまで手順通り行っているのであれば、.NET Coreアプリケーションの生成から実行まで(.NET CoreやNodeのインストールが必要であっても！)ほんの数分であったはずです。ここで、いくつかの疑問が浮かぶかもしれません。
IDEはどこ？
ここまでは必要ありませんでした、そうですよね？当然ですが、このコードを編集したければ、何らかの手段が必要になります。できれば.NETやAngularをある程度理解してくれるツールがよいでしょう。“問題ないさ、”と思うかも知れません。“Visual Studio Professionalを立ち上げて使えばいい。”そして実施にそうする ... あるいは機能的に近い、無償のVisual Studio Codeをダウンロードするかも知れません。同じく無償のVisual Studio Communityを使うという手もあります。ここで重要なのは、.NET Coreで開発を始めるにあたって、もはや何百ドルも投資する必要はない、ということです。小さく始めて、組織的に拡張すればよいのです。
IISはどこ？
“レガシ”(と呼ぶのは早すぎますか？)な.NET WebアプリケーションとASP.NET Coreの大きな違いはここにあります。ASP.NET CoreアプリケーションをIISで実行することは可能ですが、必須ではありません。.NET Coreが真のクロスプラットフォームであることを考えれば、ASP.NET CoreをIISから分離する必要があるのは明白です。ここで紹介したコマンドは、dotnet runも含んで、WindowsでもMacでも、Linuxでも正しく、まったく同じ動作をします(Raspberry Piで実行可能なARMビルドさえあります！)。Angularアプリケーションは、数多くの“Write Once, Run Anywhere”なアプリケーションのひとつなのです。
.NETアプリケーションをIISなしでホストすることは、しばらく前から可能でした。Open Web Interface for .NET(OWN)では何年も前から、ASP.NETアプリケーションの“セルフホスト”がサポートされていたのです。これを可能にしたのは、一般的に“Project Katana”と呼ばれるコードとインフラストラクチャです。.NET CoreではKestrelというHTTPSサーバを使用します。Kestrelは高速で高性能な、.NETアプリケーション用のオープンソースHTTPSサーバです。WindowsやLinux、コンテナオーケストレータ上などのあらゆる場所で動作し、ASP.NET Core WebサイトとRESTfulサービスに対してHTTPを提供します。WindowsベースのHTTPサーバとの外部依存関係を一切持たないことで、ASP.NET Coreアプリケーションを完全に自己完結させます。
DevOpsとの関係は？
オートメーションはDevOpsの基本的な理念でありプラクティスです。.NET Coreによる可搬性、CLI、オープンソースのビルドシステムは、DevOpsプラクティスには欠かせないものです。最も重要なのは、それらがビルドやデプロイメントのプロセスの自動化を容易にすることです。このような自動化は、CLIのスクリプティングや、プログラム的にビルドシステムを直接自動化することによって実現されます。.NET Coreの備えるこうした機能は、複雑なビルドプロセスの自動化を可能にするだけでなく、比較的容易なものにしてくれます。ビルドの自動化と継続的インテグレーションが実現するのです。
.NET Coreのビルド自動化
Visual SourceSafeの時代(“そうさDave、君は時代遅れだよ”)には、チームがリポジトリにプッシュしたコードがそこにあって、いつでもコンパイル可能になっていました。私の心の奥に、ある考えが浮かびました – “そちら側でもできるのに、なぜわざわざ、自分のシステムでビルドしなければならないのだろう？”そう思ったのは私だけではありませんでした。とは言え、私がそれを実現した数少ない人のひとりだと主張するつもりはありません。それを主張できるのは、継続的インテグレーション(CI)システムの開発に着手した、勇敢な心の持ち主たちです。
CIの目的は、言葉にすれば単純ですが、実現は簡単ではありません。
デプロイメント可能なビルドが常に用意されていること。
ソフトウェア開発はチームスポーツです。平均的なアジャイル/スクラムのチームには、コード作成に積極的に貢献する開発者が3～5人います。彼らの仕事は、効率上の理由から分割されていますが、作成したコードは組み合わせてビルドし、ひとつのユニットとしてテストしなければなりません。このようなテストは、開発者がインストールする必要のないシステムを使って自動化されるべきです。ビルドとテストは、新しいコードが対象ブランチ(トランクベースの開発であればマスタ)にマージされる度に実行されるのが理想的です。CIシステムは一般的にソース管理システムに組み込まれていて、CIブランチが変更されると新たなビルドが起動されます。
Roslynは、直接アクセス可能な充実したAPIを備えた、.オープンソースのNET用コンパイラです。CIシステムの開発者は.、NETのビルドプロセスを自動化するプラグインを開発するために、このコンパイラAPIを使用します。Roslynなどの.NET Coreビルドツールは、ビルドプロセスを詳細にコントロールするための機能を提供してくれます。それらを既存のCIシステム機能に適用して拡張することで、考えられるほぼすべてのビルドパイプラインのユースケースをカバーすることができます。一番ありがたいのは、プラグインを開発するためにCIシステム開発者になる必要がない、ということです。CIシステムのメンテナやベンダは、自分たちのシステムを容易に拡張可能にするために、多大な努力を払っているのです。
現在は本当にたくさんのCIシステムがあります。少し挙げてみましたが、もちろんこれだけではありません。
- Jenkins
- TFS/Visual Studio Team Services
- CircleCI
- TeamCity
- GitLab
.NET Coreの提供するフレキシビリティは、あらゆるCIシステムとの連携を可能にします。 連携の方法は、CLIを使ったスクリプトのような単純なものから、コンパイラAPIを使用するようなプラグインまでさまざまです。
現在すでにお気に入りのCIシステムを使っているのでしたら、サンプルプロジェクトで試してみてください。これは先程CLIで作成したものと同じプロジェクトに、少し追加をしたものです。リポジトリにはDockerfileが含まれています。コードをGithubからプルして、ビルドしたイメージをAzure Container RegistryにプッシュするVSTSビルドパイプラインを、10分で作成することができました。JenkinsやGitLabパイプラインの他、AWSあるいはGoogle Cloud内でも動作します。文字通り、可能性はほぼ無限です。
.NET Coreによるアプリケーション監視
ソフトウェアシステムの“お守り”はフルタイムの仕事です – 運用チームの同僚に聞いてみてください。この手のシステムは夜泣きする赤ちゃんのようなもので、常に何らかの手当てをしなければなりません。運用スタッフは困惑する若い親のように、システムがなぜ泣いているのか分からないことが多いのです。システムはなぜ泣くのでしょうか？それはあなたが構ってくれないからです！
システムを監視する上で最悪の方法は、監視しないことです。監視をするかしないか、どちらにせよ、障害が発生すればそれを知ることになります。ユーザが激怒して電話してくるか、サービスの利用を完全に止めてしまえば、その時にはもう手遅れです。アプリケーション監視の目的は、顧客あるいはエンドユーザ(事実上の違いはありません)より先に問題を検知することです。多くの企業が、アプリケーション監視は高価過ぎる、あるいは“よくできたシステムには監視は不要”という、経済的に誤った判断をしています。そうではありません。
最高に安定したシステムでも、 たったひとつの障害や変更で大惨事に陥ることがあります。DevOpsプラクティスは、安全と速度のバランスを取ろうというものです。そうすることで企業は、迅速な行動による革新と安全を両立することが可能になります。このバランスは、システムの運用パラメータを注意深く監視することで維持されます。
.NET Coreのデザインとアーキテクチャは、アプリケーション監視に適しています。その好例がASP.NET Coreです。HTTPモジュールを使用することで、IIS上で動作するASP.NET 3.x/4.xアプリケーションの内部的な要求/応答動作をカスタマイズすることができます。ASP.NET Coreのこのミドルウェアによる機能拡張には、HTTPモジュールのコンセプトに近いものがありますが、実装は大きく違っていて、ミドルウェアのクラスはコード経由で統合されています。構成もずっと単純で、それらがモディファイアの要求/応答パイプラインチェーンを形成して、リクエストに対して応答しているのです。
ASP.NET Coreアプリケーションに監視を行うミドルウェアを注入するのは簡単です。 Azure Application Insightを例に取って説明しましょう。AzureポータルにApplication Insightsリソースを作成した後、リポジトリ内の3つのファイルを正しく編集して、Applcation Insightsによる監視を有効にします。
dotnet-angular.csproj
Application Insightsアセンブリを参照する行を追加します(この手作業が必要なのは、私がVisual Studio for Macを使用しているからです。詳細はこちらを参照してください)。
appsettings.json
Application Insightsの実装キーを追加します。
Startup.cs
Startup.csはミドルウェアを構成する場所です。ここにApplicaton Insightsミドルウェアを追加します。
これらを一度行えば、ローカルでデバッグを開始して、Application Insightsから監視データを収集できるようになります。自分自身で試すことも、appsettings.jsonのサンプルキーを単に自分のキーに置き換えることも可能です。
アプリケーション監視の選択肢はApplication Insightsだけではありません。AppMetricsはオープンソースの監視ライブラリで、Grafanaなどの視覚化ツールと統合して使用します。エンタープライズ機能を備えた有償オプションもベンダから提供されています。
これらの監視オプションはいずれも透過性、すなわちランタイム環境(特に運用環境！)におけるアプリケーションの挙動を確認する機能を提供します。この機能は、システムに実施した変更がパフォーマンスを低下させていないことを具体的な数値で検証可能にする、という意味において、DevOpsには不可欠なものです。その上で、迅速な変更が現行機能を棄損しないという確証を得るために、新たな機能を追加していけばよいのです。
まとめ
.NET CoreはDevOpsプラクティスを想定して構想され、開発されたものです。そのCLIとオープンなビルドシステムとライブラリは、およそ考えられるすべての要件に対して、その自動化とソフトウェアデリバリシステムへの適用を可能にします。ビルドの自動化と継続的インテグレーションはCLIスクリプティングだけでなく、希望とあらば、より複雑なプログラム統合で実現することも可能です。オープンソースあるいは有償の企業向けツールによるアプリケーション監視は、システムをブラックボックスからガラス張りへの変えてくれます。DevOpsプラクティスを使って展開される.NET Coreは、現行のソフトウェアシステムにとって、実に魅力的なプラットフォームなのです。
著者について
Dave Swersky氏はサポートエンジニアからソフトウェア開発者、エンタープライズアーキテクトへと、20年以上にわたってITに携わってきました。さまざまな言語に精通するとともに、DevOpsに関するすべてのものに熱意を持っています。氏はDevOps Enterprise SummitやCodeMash、Stir Trek、KCのローカルミートアップなど、さまざまなカンファレンスでDevOpsについて講演するだけでなく、“DevOps Katas”、“Hands-On DevOps”といったDevOpsに関する著書も持っています。Twitterの@dswerskyで氏の発言を見ることができます。
.NET Core 2.0のリリースによって、Microsoftは、2016年にリリースした汎用目的、モジュール構造、プラットフォーム不問のオープンソースのプラットフォームの次期メジャーバージョンを手にしました。.NET Coreは、現行の.NET Frameworkで利用可能なAPIの大部分を持つように設計されています。元々はASP.NETソリューションの次世代版を実現するために開発されましたが、現在ではIoTやクラウド、次世代モバイルソリューションなど、まったく違うシナリオを担う、基盤的な存在となっています。.NET Coreを取り上げたこのシリーズの第2回では、.NET Coreのさらなるメリットと、既存の.NET開発者のみならず、堅牢性、パフォーマンス、経済性を兼ね備えたソリューションを市場に投入する必要のあるすべての技術者にとっての価値を探ります。