Tweet
Tweet

Slide 1

Slide 1 text

ASP.NET Core 2.0 × App Service on Linux Tatsuro Shibamura (@shibayan) Microsoft MVP / Freelance

Slide 2

Slide 2 text

今日話す内容 • 最近 ASP.NET Core 2.0 で真面目にアプリを書いている話 • MVC 5 と同じ感覚で書いて致命傷で済んだ、とか • 主に苦労話かも • App Service on Linux で動かそうと思っている話 • Windows 版だとデプロイが不安定な場合がある • Docker でカッコいい感じにしたい（

Slide 3

Slide 3 text

懺悔 • 最近、やっと真面目に ASP.NET Core 2.0 を触り始めました • 1.1 の時は 1 つ API 作ったぐらいにしか仕事で使ってない • 仕事では大体 ASP.NET MVC 5 で書いていた • やっぱ使い慣れてて楽だった…

Slide 4

Slide 4 text

仕事で 2.0 を使うことに • お客さん「好きな技術を選んでいいよ」 • 俺「あ、じゃあ ASP.NET Core で」 • お客さん「おｋ。でも 2.0 出たしアップデートしよう」 • 俺「（そういえば ASP.NET Core しっかり触ってない…）」

Slide 5

Slide 5 text

慢心ドリブンだった • サンプルアプリぐらいは書いていたけど、実案件は違う • 画面数が 60 以上あった • デザイン要素も割とてんこ盛りだった => Razor に感謝 :pray: • 公式ドキュメントと GitHub.com のソースの往復 • Tag Helpers を自作する時にビルトインのやつを参考に • 思ったより手間と時間がかかり、無事に死亡

Slide 6

Slide 6 text

これから使おうとしてる人に • Core MVC で大きく変わったポイントはしっかり理解 • 各種ミドルウェア、パイプラインの仕組み • 認証・認可 • Dependency Injection • Razor 周り • 特に DI (Core MVC では Services に) は重要 • IServiceCollection / FromService / ServiceFilter など

Slide 7

Slide 7 text

懺悔終わり • 2 日ほどで MVC 5 と同じペースで実装可能に • Core MVC のパターンを理解すれば早い • 新しい Razor は本当に強力 • これだけで Core を使う価値ある • DI の迷宮に迷い込みやすい • 油断すると依存関係が複雑になりやすい、かな？

Slide 8

Slide 8 text

ASP.NET Core 2.0 よもやま話

Slide 9

Slide 9 text

ASP.NET Core 2.0 を使った理由 • 使ってみたかったから！ • Razor というか Tag Helpers が便利そうだったから • Visual Studio で快適に開発したかったから • C# が好きだから

Slide 10

Slide 10 text

Razor が超進化 • さようなら HTML Helper 地獄

Slide 11

Slide 11 text

新しい Razor の利点 • HTML のマークアップ構造を壊さない • MVC 5 では Visual Studio の lint 機能とよく喧嘩してた • Form タグがないのに input を書いているとか • 貰ったデザイン HTML を Razor に落とす必要がない • A タグを Html.ActionLink にしなくてよい • Input タグを Html.TextFor などにしなくてよい

Slide 12

Slide 12 text

IntelliSense 周りの問題 • たまに IntelliSense やシンタックスハイライトが効かない • Visual Studio の再起動で大体直る • Razor 言語サービスの再インストールが必要かもしれない • ビューを書いていると Visual Studio が凄く重い • 2 core の CPU だと息切れ気味 • 早いマシンを買うしかない（ ＾ω＾）・・・

Slide 13

Slide 13 text

シンプルな Dependency Injection • Startup.ConfigureServices で設定する • 基本はコンストラクタインジェクションのみ

Slide 14

Slide 14 text

DI のスコープに注意 • AddSingleton • 常に 1 つだけインスタンスが作られる • AddScoped • リクエスト単位でインスタンスが作られる • AddTransient • 解決時に都度インスタンスが作られる

Slide 15

Slide 15 text

例 : DI のエラー地獄

Slide 16

Slide 16 text

HttpContextAccessor は必須 • ASP.NET Core 版の HttpContext.Current 的なもの • DI 経由で HttpContext を受け取ることが出来る • HttpContext.Items にリクエストスコープなデータをキャッシュ • User にアクセスしてログイン情報のチェックなど

Slide 17

Slide 17 text

例 : DI で受け取って HttpContext を触る

Slide 18

Slide 18 text

認証はクレームベース • HttpContext.User は ClaimsPrincipal になっている • MVC 5 よりは少し手間がかかる、と思っている • 複数の認証プロバイダで一貫性のある扱いが可能に • 必要な情報は全てクレームに入っている • ユーザーごとにユニークな ID も

Slide 19

Slide 19 text

例 : 実際のクレーム nameidentifier がユニークな ID これがクレームの実体

Slide 20

Slide 20 text

雑談 : Core MVC と MVC 5 の互換性は？ • 実際に両方でそれなりの規模のアプリを書いてみた • ASP.NET MVC での開発経験はまあまあ長い方だと思う • あくまでも個人的な主観だと… • 7 割 = 互換性がある（ように見える） • 2 割 = クラス名、プロパティ名の違い（ぐらいに思える） • 1 割 = 完全に互換性がない

Slide 21

Slide 21 text

実際にはまった例 • 以下のコントローラは Core MVC の場合エラーとなります

Slide 22

Slide 22 text

答え : FormCollection はバインド不可

Slide 23

Slide 23 text

別物だと考えよう • Core MVC と MVC 5 は大体似てるけど、細部は結構違う • MVC 5 の経験だけで戦おうとすると無事死亡するかも • ASP.NET Core のノウハウを貯めていきたい • 「MVC 5 だと～だったけど、Core MVC だと～だよ」みたいな • 慢心ドリブン開発ダメ絶対

Slide 24

Slide 24 text

実行環境とデプロイ

Slide 25

Slide 25 text

ASP.NET Core がサポートする環境 • Windows (IIS / WebListener) • 例えば App Service • Linux (Apache / nginx) • アプリケーションをサービスとして動かす • Docker (Windows / Linux) • アプリイメージを作れば動く

Slide 26

Slide 26 text

おすすめは Docker • Windows では • 正式に対応した環境は App Service ぐらい • Linux では • デプロイ周りの仕組みから作る必要がある • サービスとして起動する設定も • Docker では • 既存の Docker 向け環境、デプロイの仕組みをそのまま使える！

Slide 27

Slide 27 text

コンテナに対する MS の本気度 • Visual Studio 2017 • Docker サポートが超強化、ビルドからデバッグ、デプロイまで • App Service on Linux • Web アプリケーションの実行向け • Azure Container Instances • Linux のコンテナなら秒速で起動する！ • Windows のコンテナにも一応対応

Slide 28

Slide 28 text

Docker サポートを追加する 分かりにくい （MVC でええやろ…） ひっそりWindows にも対応

Slide 29

Slide 29 text

おまけ : 3 大公式 Docker Image • microsoft/dotnet • .NET Core のランタイム • microsoft/aspnetcore • dotnet に ASP.NET Core 向けの設定を追加したもの • microsoft/aspnetcore-build • aspnetcore + よく使う NuGet パッケージをキャッシュ済み

Slide 30

Slide 30 text

おまけ : 間違いやすい Docker Image • microsoft/dotnet-framework • 実質 Windows Server Core イメージの別名 • microsoft/aspnet • Windows Server Core に IIS と ASP.NET をインストールしたもの • 現時点では、ほぼ使い道がない（忘れてても良い）

Slide 31

Slide 31 text

アプリケーションのデプロイ • Visual Studio から直接 App Service へ • Azure Container Registry が必要 • Visual Studio Team Services でビルドして App Service へ • ACR が必要 • CI SaaS でビルドして App Service へ • ACR 無くても頑張れる

Slide 32

Slide 32 text

Visual Studio から App Service

Slide 33

Slide 33 text

CI SaaS を使ってビルド、デプロイ • Docker が使えるサービスの場合 • microsoft/aspnetcore-build イメージをベースに • NuGet パッケージが予めキャッシュされてるので高速 • Visual Studio Team Services なら標準対応 • .NET Core が既にビルドワーカーにインストール済み • Docker も標準で使える

Slide 34

Slide 34 text

App Service on Linux の利点 • 自動的なフェールオーバー • コンテナ入れ替えでのダウンタイム無し • デプロイの仕組みが組み込まれている • ホストのメンテナンス不要

Slide 35

Slide 35 text

続きは Tech Summit で