ASP.NET Core 2.0 × App Service on Linux

NET Core と ASP.NET Core は Linux の Docker 上で素早く実行させるための環境やイメージがあらかじめ用意されています。 Windows で ASP.NET Core を使う場合よりも、環境に自由度がある Docker と App Service on Linux を使って ASP.NET Core 2.0 開発を行う方法を紹介します。みんな気になる CI の話もあります。

Transcript

1. ASP.NET Core 2.0 × App Service on Linux Tatsuro Shibamura (@shibayan) Microsoft MVP / Freelance
2. 今日話す内容 • 最近 ASP.NET Core 2.0 で真面目にアプリを書いている話 • MVC 5 と同じ感覚で書いて致命傷で済んだ、とか • 主に苦労話かも • App Service on Linux で動かそうと思っている話 • Windows 版だとデプロイが不安定な場合がある • Docker でカッコいい感じにしたい（
3. 懺悔 • 最近、やっと真面目に ASP.NET Core 2.0 を触り始めました • 1.1 の時は 1 つ API 作ったぐらいにしか仕事で使ってない • 仕事では大体 ASP.NET MVC 5 で書いていた • やっぱ使い慣れてて楽だった…
4. 仕事で 2.0 を使うことに • お客さん「好きな技術を選んでいいよ」 • 俺「あ、じゃあ ASP.NET Core で」 • お客さん「おｋ。でも 2.0 出たしアップデートしよう」 • 俺「（そういえば ASP.NET Core しっかり触ってない…）」
5. 慢心ドリブンだった • サンプルアプリぐらいは書いていたけど、実案件は違う • 画面数が 60 以上あった • デザイン要素も割とてんこ盛りだった => Razor に感謝 :pray: • 公式ドキュメントと GitHub.com のソースの往復 • Tag Helpers を自作する時にビルトインのやつを参考に • 思ったより手間と時間がかかり、無事に死亡
6. これから使おうとしてる人に • Core MVC で大きく変わったポイントはしっかり理解 • 各種ミドルウェア、パイプラインの仕組み • 認証・認可 • Dependency Injection • Razor 周り • 特に DI (Core MVC では Services に) は重要 • IServiceCollection / FromService / ServiceFilter など
7. 懺悔終わり • 2 日ほどで MVC 5 と同じペースで実装可能に • Core MVC のパターンを理解すれば早い • 新しい Razor は本当に強力 • これだけで Core を使う価値ある • DI の迷宮に迷い込みやすい • 油断すると依存関係が複雑になりやすい、かな？
8. ASP.NET Core 2.0 よもやま話
9. ASP.NET Core 2.0 を使った理由 • 使ってみたかったから！ • Razor というか Tag Helpers が便利そうだったから • Visual Studio で快適に開発したかったから • C# が好きだから
10. Razor が超進化 • さようなら HTML Helper 地獄
11. 新しい Razor の利点 • HTML のマークアップ構造を壊さない • MVC 5 では Visual Studio の lint 機能とよく喧嘩してた • Form タグがないのに input を書いているとか • 貰ったデザイン HTML を Razor に落とす必要がない • A タグを Html.ActionLink にしなくてよい • Input タグを Html.TextFor などにしなくてよい
12. IntelliSense 周りの問題 • たまに IntelliSense やシンタックスハイライトが効かない • Visual Studio の再起動で大体直る • Razor 言語サービスの再インストールが必要かもしれない • ビューを書いていると Visual Studio が凄く重い • 2 core の CPU だと息切れ気味 • 早いマシンを買うしかない（ ＾ω＾）・・・
13. シンプルな Dependency Injection • Startup.ConfigureServices で設定する • 基本はコンストラクタインジェクションのみ
14. DI のスコープに注意 • AddSingleton<T> • 常に 1 つだけインスタンスが作られる • AddScoped<T> • リクエスト単位でインスタンスが作られる • AddTransient<T> • 解決時に都度インスタンスが作られる
15. 例 : DI のエラー地獄
16. HttpContextAccessor は必須 • ASP.NET Core 版の HttpContext.Current 的なもの • DI 経由で HttpContext を受け取ることが出来る • HttpContext.Items にリクエストスコープなデータをキャッシュ • User にアクセスしてログイン情報のチェックなど
17. 例 : DI で受け取って HttpContext を触る
18. 認証はクレームベース • HttpContext.User は ClaimsPrincipal になっている • MVC 5 よりは少し手間がかかる、と思っている • 複数の認証プロバイダで一貫性のある扱いが可能に • 必要な情報は全てクレームに入っている • ユーザーごとにユニークな ID も
19. 例 : 実際のクレーム nameidentifier がユニークな ID これがクレームの実体
20. 雑談 : Core MVC と MVC 5 の互換性は？ • 実際に両方でそれなりの規模のアプリを書いてみた • ASP.NET MVC での開発経験はまあまあ長い方だと思う • あくまでも個人的な主観だと… • 7 割 = 互換性がある（ように見える） • 2 割 = クラス名、プロパティ名の違い（ぐらいに思える） • 1 割 = 完全に互換性がない
21. 実際にはまった例 • 以下のコントローラは Core MVC の場合エラーとなります
22. 答え : FormCollection はバインド不可
23. 別物だと考えよう • Core MVC と MVC 5 は大体似てるけど、細部は結構違う • MVC 5 の経験だけで戦おうとすると無事死亡するかも • ASP.NET Core のノウハウを貯めていきたい • 「MVC 5 だと～だったけど、Core MVC だと～だよ」みたいな • 慢心ドリブン開発ダメ絶対
24. 実行環境とデプロイ
25. ASP.NET Core がサポートする環境 • Windows (IIS / WebListener) • 例えば App Service • Linux (Apache / nginx) • アプリケーションをサービスとして動かす • Docker (Windows / Linux) • アプリイメージを作れば動く
26. おすすめは Docker • Windows では • 正式に対応した環境は App Service ぐらい • Linux では • デプロイ周りの仕組みから作る必要がある • サービスとして起動する設定も • Docker では • 既存の Docker 向け環境、デプロイの仕組みをそのまま使える！
27. コンテナに対する MS の本気度 • Visual Studio 2017 • Docker サポートが超強化、ビルドからデバッグ、デプロイまで • App Service on Linux • Web アプリケーションの実行向け • Azure Container Instances • Linux のコンテナなら秒速で起動する！ • Windows のコンテナにも一応対応
28. Docker サポートを追加する 分かりにくい （MVC でええやろ…） ひっそりWindows にも対応
29. おまけ : 3 大公式 Docker Image • microsoft/dotnet • .NET Core のランタイム • microsoft/aspnetcore • dotnet に ASP.NET Core 向けの設定を追加したもの • microsoft/aspnetcore-build • aspnetcore + よく使う NuGet パッケージをキャッシュ済み
30. おまけ : 間違いやすい Docker Image • microsoft/dotnet-framework • 実質 Windows Server Core イメージの別名 • microsoft/aspnet • Windows Server Core に IIS と ASP.NET をインストールしたもの • 現時点では、ほぼ使い道がない（忘れてても良い）
31. アプリケーションのデプロイ • Visual Studio から直接 App Service へ • Azure Container Registry が必要 • Visual Studio Team Services でビルドして App Service へ • ACR が必要 • CI SaaS でビルドして App Service へ • ACR 無くても頑張れる
32. Visual Studio から App Service
33. CI SaaS を使ってビルド、デプロイ • Docker が使えるサービスの場合 • microsoft/aspnetcore-build イメージをベースに • NuGet パッケージが予めキャッシュされてるので高速 • Visual Studio Team Services なら標準対応 • .NET Core が既にビルドワーカーにインストール済み • Docker も標準で使える
34. App Service on Linux の利点 • 自動的なフェールオーバー • コンテナ入れ替えでのダウンタイム無し • デプロイの仕組みが組み込まれている • ホストのメンテナンス不要
35. 続きは Tech Summit で