このブログについて

ソース: https://github.com/hMatoba/tetsujin

 ブログのバックエンドを作るのが趣味になっているような気がする。
 はじめはPython on GoogleAppEngineで作って、それのデータベースをNoSQLにしてみたらどうだとか始めた。そのあとでTornadoやFlask、BottleといったPythonのフレームワークをいろいろやってみて、Node.jsはasync,awaitが入る前にやってちょっときついと思ってストップした。
 その後WPFで好きだったC#で作ってみたくなって、.NET Coreのリリース直後にAzureに乗るものを作った。そして今回、.NET Core 2.0のリリースがあったのを契機にDocker運用するものに作り直した。

 ASP.NET Core MVCを使ってみた感想。モデル、ビュー(Razor)、コントローラのみを使うような、SinatraやFlaskのような、うっすい使い方もできる。スキャフォルディングとかあるけど無理に使う必要はない。フレームワークに縛られてるような感覚は強くない。その点、うまくやれるかは書き手次第。


 このブログはタグに並べた要素が全部盛りで実装されている。
 C#が好きなので、それがオープンソースになったのがうれしかった。だからほかのオープンソース技術をメインに組み合わせて、C#はMSの用意したセット(WindowsOSでIISとかSQLServerとかって構成)じゃないと使えないなんてことはないというのを実践してみたかった。DebianでNginx、MongoDBなどって構成。
 使用サービスの構成としては、Github、TravisCI、Docker Hub、Hyper.shが主なところ。
・Github→バージョン管理
・TravisCI→CIサービス
・Docker Hub→ビルドしたコンテナイメージの置き場所
・Hyper.sh→Docker開発者が「これほぼDockerやんけ」と言うぐらいにDockerライクなコンテナホスティングサービス。もちろんDockerで作ったコンテナをホスティングできる
 使用サービスの構成はシンプルなほうがいいという一般論も存在するだろうけど、これはこれで楽をするための構成を敷いている。Dockerを使ったサーバの構成管理、自動テスト、CIサービス上での自動テストからの自動デプロイなどなど。アプリの開発継続に注力できる。

 Githubへのプッシュで、TravisCIでのビルド、テストが行われる。テストにパスしてなおかつブランチがmasterだったらならDocker Hubへビルドされたコンテナイメージがアップされる。そののち、Hyper.shでそのコンテナイメージをプル、デプロイまでのコマンドが自動で流れる。Docker Hubを経由しているので、コンテナイメージがビルドの産物として残るようになっている。


・運用お値段
 VPSは安い。でもOSの管理が必要だからヤダ。AWSとかAzureのイカしたPaasを使いたいけど高い。
 DockerコンテナホスティングをしてくれるHyper.shというサービスがあり、これで月2000円以下で運用できている。リバースプロキシコンテナ+アプリコンテナの2コンテナをランニングさせるコスト1000円に加え、個人的にいろんなアプリで使うMongoDBを仕方なくVPSで運用しているコスト600円程度となっている。VPSとメジャーどころのPaasの中間あたりのお値段。
 問題としてHyper.shが日本にもアジアにもリージョンがないことによるレイテンシがががというのがあるけども妥協。


・構成
 ファイルはAzureStorage
 ↑にも書いたけどコンテナホスティングで運用していて、走っているコンテナはリバースプロキシ用一台とアプリ用一台
 証明書はLet's Encrypt
 コンテナのOSは、リバースプロキシのほうがAlpine、アプリはDebian
 テストはxUnitによる単体テストが実行できるようにしてある
 それに加えてSeleniumでのE2Eテストも用意してある。Seleniumは、一度C#で動かしたらきつかったのでPythonで動かしている
 バージョン管理はGithub
 Githubへのデプロイで、TravisCIでのデプロイが走る
 TravisCIではとりあえずSeleniumでE2Eテストをやっている
 TravisCIでテストに成功したら、そこからHyper.shへ自動デプロイが始まる
 ただし自動デプロイが始まるのはmasterブランチへのコミット時のみ


 いろいろ構成していて半分は趣味で試したかったものであるが、同時にデプロイの自動化という一年前から突き詰めたかった課題への挑戦もしている。これのおかげで、今後このブログエンジンを改良していくのにせっせと手作業でデプロイをする必要がなくなった。


・なおしたい点
 dotnetコマンドが現状docker composeを使ったプロジェクトをビルドしてくれない。だから一部プロジェクトでCI環境でのビルドができず、開発環境でビルドしたものをDocker Hub経由で使っている。CI環境でビルドができないのはSDKの不足が原因。そのSDKはVisualStudio Communityに用意されているのだが、SDKがオープンソースになっていないという理由でdotnet CLIに入れるかどうかもたついている。
'17/9/28追記
docker composeが入っているプロジェクトのビルド方法を変えて対応完了

comment: 0

.NET CoreのクラスライブラリをNuGetパッケージにする

 ASP.NET Core MVC(.NET Core)なプロジェクトで、DLL化してあるライブラリを参照で加えて使ったら、ビルド後にエラーが出た。
An unhandled exception occurred while processing the request.

FileNotFoundException: Could not load file or assembly 'Mango, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified


 メッセージに従って実行ディレクトリを見に行ったらしっかりそのDLLはあった。DLLをローカルにコピーとかやっても解決しない…どうやら.NET Coreは参照をNuGetで解決するものらしい。だから自作ライブラリを使いたければそれをNuGetパッケージにしろということ。
How do I import a .NET Core project to another .NET Core project in Visual Studio?

 ちなみにプロジェクトの参照で解決するならわざわざNuGetパッケージ化しなくてもOK。プロジェクトの参照がダメならテスト作るのもわざわざNuGetパッケージからってことになってアレだったのでここはセーフ。





 今回は.NET CoreターゲットのライブラリをNuGetパッケージ化して、パブリックなNuGetリポジトリに上げてみるところまで。

 そもそもパッケージのターゲットをどうするかというのがある。.NET Frameworkか、.NET Coreか、はたまた.NET Standardか。
 .NET Frameworkは従来のものでもはや語るのもアレなので省略。
 .NET Coreは.NET系でクロスプラットフォームを推進するアレ。
 .NET Standardはすべての.NETランタイムで動くものを作りましょうというときのアレ。
 .NET Standardがターゲットなら、ランタイムが.NET Frameworkでも.NET Coreでも実行できるものになる。ただしもちろん、どっちかに依存のあるライブラリを使っているなら、そっちにターゲットを絞らなければならない。今回ぼくが作ったライブラリが.NET Core依存のライブラリを含んでいたので、今回は.NET Coreに絞ったわけである。
 ちなみに”ASP.NET Coreが.NET Frameworkサポートを終了”というアナウンスがあったので、ASP.NET Coreで使うライブラリならこの先は.NET Core一択で迷わなくてよくなるかもしれない。これまで.NET FrameworkでASP.NET Coreを使っていた人にはだいぶ酷なアナウンスだとも思うが。

 .NET Core向けのライブラリを作る。今ならVS2017を開いて、プロジェクトで自分の使いたい言語から.NET Coreがターゲットになっているクラスライブラリの作成を選ぶ。そしてコードを書く。ライブラリができた。ここからNuGetパッケージ化である。

 先に必要な道具を入れておく。
NuGet Package Explorer

 道具を入れたらパッケージを作る。作ってあるプロジェクトのディレクトリでPowerShellを開く。パックする。
dotnet pack --configuration release



 成功したことをメッセージで確認したら出力ディレクトリへ。.nupkgがあるのでダブルクリックすると、GUIのパッケージマネージャが立ち上がる。
 Authorなど必要情報を編集する。次にAPI KeyをNuGetウェブサイトの管理画面で取得する。パッケージマネージャにもどって「ファイル」メニューからPublishを選び、Publish Keyの欄に入れてあとはPublishボタン。


 Publishが済んだらあとは必要になったときに下記コマンド。
Install-Package [Package Name]
comment: 0

.NET Core +xUnit + MongoDBなテストをTravisCIでCIする

 .NET CoreによるMSの積極的なLinux参入。VisualStudioで.NET Coreのテストを作ろうとするならxUnitを使ったテストを選べる。これをTravisCI上でのUbuntu(trusty)で走らせるところまで持っていく。

 VisualStudioで.NET CoreのxUnitテストを作る。それをコマンドラインで走らせるところから。
 ソリューションの真下の.slnのあるディレクトリで、restoreとbuildを行う。
dotnet restore

dotnet build

 そんでテスト。テストはテストプロジェクトのあるディレクトリに移動して行う。
dotnet test



 テストが済んだことを確認したら、それをTravisCIで行えるようにする。.travis.ymlの用意。今回はMongoDBを使うのでその設定も。
.travis.yml

sudo: false
language: csharp
mono: none
dotnet: 1.0.1
dist: trusty
services:
- mongodb
addons:
apt:
sources:
- mongodb-upstart
- mongodb-3.0-precise
packages:
- mongodb-org-server
- mongodb-org-shell

install:
- dotnet restore
script:
- dotnet build
- cd FoobarTests
- dotnet test


 上記のものを利用してじっさいにTravisCIに上げてみたのが↓のプロジェクト。



https://travis-ci.org/hMatoba/Mango
comment: 0

ASP.NET MVC: ユニットテストを用意してみる

 ASP.NET MVCでユニットテストを作成してみる。訳を作ったMSのドキュメントを参考にしながら。
https://github.com/hMatoba/ASP.NET-Core-doc/blob/master/ユニットテスト.rst

 まずVisualStudioでWebアプリのソリューションを作っておく。そしてルートの下にsrcとtestというディレクトリがあることを確認する。


 testディレクトリに入り、下記のコマンドを実行する。
dotnet new -t xunittest


 するとtestディレクトリ下に二つのファイルが生成される。このうちのproject.jsonを、VisualStudioのソリューションエクスプローラから、ソリューションに既存の項目として追加する。するとVisualStudioがファイルをさらに追加してくれる。これでテストプロジェクトがソリューションに加わったことになる。


 あとはガリガリとテストを追加していくだけ。テストはテストエクスプローラから実行できる。


comment: 0

Azure: GithubからWeb Appsへデプロイ

 このブログはAzureで運用している。これまでコードのデプロイはVisualStudioを使って行っていたが、Githubでバージョン管理を行っているので、Githubにデプロイまでを一括して行ってもらうことにする。

 まずAzureの管理者コンソールを開いて、デプロイオプションを開く。さまざまなデプロイ方法が出てくる。

--------------

 Githubを選んでGithubへとび、認証を済ませてAzure→Githubのアクセス許可を与える。

--------------

 以上で設定は終わり。あとはGithubへデプロイすればデプロイまで自動で行われる。

--------------

 Azureコンソールではデプロイ履歴を追うこともできる。
comment: 0