今週、Web サイトの 1 つを ASP.NET Core 2.2 から最新の LTS (Long Term Support) バージョンの ASP.NET Core 3.1 に更新しました。今、ポッドキャスト サイトで同じことを行い、同時に Linux に移行したいと考えています。 Azure App Service for Linux の価格は非常に高く、Standard から Premium v2 プランに移行することができました。これにより、メモリが 2 倍になり、35% オフになります。
私のポッドキャストは、これまで Azure App Service for Windows 上の ASP.NET Core で実行されてきました。 Linux で動作するかどうかはどうすればわかりますか?では、やってみます！
私は WSL (Linux 用 Windows サブシステム) を使用しています。マシンで WSL を使用する準備ができていて、それを有効にしていない可能性が非常に高いです。 WSL (または新しい WSL2) を Windows ターミナルと組み合わせると、どこでも何でも開発できる Windows の素晴らしい場所になります。
まず、既存の ASP.NET Core ポッドキャスト サイト (現在は .NET Core 3.1 に更新されています) を Linux で実行できるかどうかを見てみましょう。 Windows で Ubuntu 18.04 を起動し、 dotnet --version を実行して、既に何かがインストールされているかどうかを確認します。あなたは何も持っていないかもしれません。私は 3.0 を持っているようです:
$ dotnet --version
3.0.100
では、WSL の Ubuntu インスタンスに .NET Core 3.1 をインストールします。 Windows に .NET 3.1 がインストールされているからといって、それが Linux/WSL インスタンスにインストールされているとは限りません。私は自分でそれらを維持する必要があります。それについて考える別の方法は、.NET 3.1 の win-x64 インストールがあり、今は linux-x64 が必要だということです。
- 注: 「
dotnet publish -r linux-x64」できたのは本当です "そして、結果の完全な公開ファイルを Linux/WSL に scp します。責任をどのように分割するかによって異なります。Windows でビルドして Linux/Linux で実行したいですか?それとも、Linux からビルドして実行したいですか?どちらも有効です。それは、選択、忍耐、および親しみやすさに依存します。 - 落とし穴: また、Windows から git clone された WSL の下の /mnt/c にある Windows ファイルにアクセスしている場合、Git for Windows と Git for Ubuntu がインデックス/ファイルに同時にアクセスしている場合は微妙な点があることに注意してください。 WSL/Linux ファイルシステム内で別のコピーを git clone するだけで、より簡単かつ安全で高速になります。
https://dotnet.microsoft.com/download にアクセスして、Ubuntu 用の .NET Core 3.1 を入手します。もしあなたが apt を使っているなら、私はあなたがそうしていると思います.
sudo apt-get install dotnet-sdk-3.1
汗かいていない。 「dotnet build」にしましょう "そして、最高のことを願っています!
驚くかもしれませんが、難しいことや Windows 固有のことをしていなければ、.NET Core アプリは Linux と同じように Windows でもビルドする必要があります。何か興味深いことや OS 固有のことをしている場合、主張するなら栄光への道を #ifdef することができます。
単体テストがある場合はボーナス ポイントです (私もそうです)。次に、単体テストを実行して、その結果を確認します。
<ブロック引用>
オプション: PowerShell は既に Windows にあるので、PowerShell を使用する build.ps1 や test.ps1 などを作成します。次に、Linux に PowerShell をインストールします (シェルではなく、スクリプトのためだけに) .ps1 スクリプトをどこでも使用できるようにします。同じ test.ps1 と build.ps1 と dockertest.ps1 などは、すべてのプラットフォームで機能します。シバン #!/usr/bin/pwsh があることを確認してください ps1ファイルの先頭にあるので、それらを実行できます（chmod +x )
このコマンドを実行する test.ps1 を実行します
dotnet test /p:CollectCoverage=true /p:CoverletOutputFormat=lcov /p:CoverletOutput=./lcov .\hanselminutes.core.tests
コードカバレッジ用のカバーレットを使用すると...動作します!繰り返しますが、これは驚くべきことかもしれませんが、ハード コードされたパスがなく、C:\ ドライブが存在することを想定し、レジストリやその他の Windows 固有のものを避ければ、うまくいきます。
Test Run Successful.
Total tests: 23
Passed: 23
Total time: 9.6340 Seconds
Calculating coverage result...
Generating report './lcov.info'
+--------------------------+--------+--------+--------+
| Module | Line | Branch | Method |
+--------------------------+--------+--------+--------+
| hanselminutes.core.Views | 60.71% | 59.03% | 41.17% |
+--------------------------+--------+--------+--------+
| hanselminutes.core | 82.51% | 81.61% | 85.39% |
+--------------------------+--------+--------+--------+
ビルドもテストもできますが、実行できますか?コンテナーでの実行とテストはどうですか?
システムでWSL2を実行しており、これをすべてUbuntu 18.04で実行しており、Docker WSL Tech Previewを実行しています。自分のテストを Docker でも実行できるか確認してみませんか? Docker for Windows から実験的な WSL2 サポートを有効にし、次に [Resources] メニューの [WSL Integration] から、Ubuntu 18.04 インスタンス内で Docker を有効にします (インスタンスとその名前は独自のものになります)。
WSL の下の「docker info」で動作し、動作中のインスタンスと通信していることを確認できます。 Windows と WSL の両方で "docker info" を実行できるはずです。
$ docker info
Client:
Debug Mode: false
Server:
Containers: 18
Running: 18
Paused: 0
Stopped: 0
Images: 31
Server Version: 19.03.5
Storage Driver: overlay2
Backing Filesystem: extfs
...snip...
涼しい。また、Dockerfile も Docker ハブの 2.2 SDK から Microsoft Container Registry の 3.1 SDK に更新する必要があることを思い出したので、この 1 行を変更します。
#FROM microsoft/dotnet:2.2-sdk AS build
FROM mcr.microsoft.com/dotnet/core/sdk:3.1 as build
Dockerfile の後半にあるアプリの最終的なランタイム バージョンと同様に。基本的に、Dockerfile が正しいバージョンを使用していることを確認してください。
#FROM microsoft/dotnet:2.1-aspnetcore-runtime AS runtime
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1 AS runtime
また、テスト結果をボリューム マウントするので、test.ps1 にこの不快な If ステートメントがあります。はい、すべてのパスに / を付けて相対パスにする必要があることはわかっています。
#!/usr/bin/pwsh
docker build --pull --target testrunner -t podcast:test .
if ($IsWindows)
{
docker run --rm -v d:\github\hanselminutes-core\TestResults:/app/hanselminutes.core.tests/TestResults podcast:test
}
else
{
docker run --rm -v ~/hanselminutes-core/TestResults:/app/hanselminutes.core.tests/TestResults podcast:test
}
とにかく、それは機能し、素晴らしく機能します。これで、Windows と Linux、および WSL2 によって管理される Docker (Linux コンテナー内) でテストを実行できるようになりました。すべてがどこでも機能します。 WSL で問題なく動作するようになったので、Linux 上の Azure でも問題なく動作することがわかりました。
Windows 上の Azure App Service から Linux への移行
これもかなり簡単でした。
次に、Azure DevOps でサイトを構築および展開する方法と、従来の "Wizard Built" DevOps Pipelines を使用した .NET 2.2 から .NET Core 3.1 およびソース管理チェックイン YAML パイプラインに移行した方法について詳しくブログに書きます。
短いバージョンは、Linux App Service プランを作成することです (「App Service プラン」は気にする必要のない VM であることに注意してください。以下の選択で、Linux プランにはペンギンのアイコンがあることを確認してください。また、できることを覚えておいてください。必要な数のアプリを計画内に含めることができます (メモリとリソースに収まります). Azure App Service for Linux 内でアプリの "スタック" を選択すると、Azure が管理する Docker イメージを効果的に選択することになります。あなた。
staging.mydomain.com にデプロイして試してみることから始めました。 Azure Front Door または CloudFlare を使用してトラフィックを管理し、DNS を交換できます。ステージングでしばらくテストした後、DNS を直接変更しました。 Windows ポッドキャスト サイトからトラフィックがなくなるまで数時間待ってから停止しました。 1 日か 2 日トラフィックがなくなった後、削除しました。私の仕事が正しければ、サイトが Windows から Linux に、.NET Core 2.2 から .NET Core 3.1 に移行したことに誰も気付かなかったでしょう。ダウンタイムなしで、同じかそれ以上の速さである必要があります。
これは、私の Azure ポータルのスナップです。今日の時点で、ホーム ページ、血糖値管理ポータル、ポッドキャスト サイトをすべて 1 つの Linux App Service プランに移行しました。それぞれが GitHub でホストされ、それぞれが Azure DevOps で自動的にデプロイされます。
クラウドへの次の大きな移行は、まだ .NET Framework 4.x を実行しているこのブログです。来週、ポッドキャストが GitHub にチェックインされ、Azure DevOps にデプロイされる方法をブログで紹介します。
読者の皆様、最近行ったクールな移行は何ですか?
スポンサー :C# のような？私たちもそうです！そのため、高速でスマートなクロスプラットフォームの .NET IDE を開発しました。これにより、さらに強力なコーディングが可能になります。巧妙なコード分析、豊富なコード補完、即時の検索とナビゲーション、高度なデバッガー... JetBrains Rider を使用すると、必要なものすべてをすぐに利用できます。 Linux、Mac、または Windows で、思考の速度で C# をコーディングします。 JetBrains Rider を今すぐお試しください!