App Service

TerraformでWeb Appsにカスタムドメイン名を設定したい

/ buchizo / コメントする

TerraformでAzure App ServiceのWeb Appsにカスタムドメイン名（特にネイキッドドメイン）を設定したい場合、AレコードにIPアドレスを設定する必要がありますが、App Serviceの受信IPアドレスを簡単にとれません。

Azure Resource Manager（ARM）上は一応 inbound_ip_address があるんですけどTerraform上で扱えないんですよね。以前は無理やりoutbound_ip_address （送信IPアドレス）の最初の要素を使ったりしてましたが（受信IPアドレスが最初に入ってた）不確かで実際最近はそんなことはないのでうまく設定できない状況でした。

で、どうしたものか悩んでたら ‘web apps名’.azurewebsites.net を正引きしてIPアドレスを取得すれば確実、ということらしく hashicorp/dns で取得したIPアドレスを使えばいいようです。

resource "azurerm_linux_web_app" "example" {
  name                = "example"
  resource_group_name = azurerm_resource_group.example.name
  location            = azurerm_service_plan.example.location
  service_plan_id     = azurerm_service_plan.example.id

  site_config {}
}

data "dns_a_record_set" "app_ip_address" {
  host = azurerm_linux_web_app.example.default_hostname
}

resource "azurerm_dns_a_record" "dns_a" {
  # ...
  target_resource_id  = data.dns_a_record_set.app_ip_address.addrs[0]
}

他にはTraffic ManagerのAzureリソースのエンドポイントでApp Serviceが使えたらそもそもこんな苦労しなくていいのに、とか思いますけど。。
たまにTerraform触るたびにいろいろ嵌りますね。

追記

しばやん氏からのタレコミによるとそもそもAzure REST API Specからしてinbound IP addressは欠落してるぽい。(resource Explorerとかで見るとちゃんとあるのでSpec側のミス）

APIの実装って大変ですね

Azure Key Vault で.NET Coreから証明書を扱う

/ buchizo / コメントする

Azure Key Vaultは安全に保管したいキーや証明書などをREST APIでアクセスすることができるAzure上のサービスです。
キーにアクセスするための権限を細かく管理したり、そもそもキーや証明書の管理操作を開発者などから分離して集中管理することができるようになります。監査などもあるので便利です。

このエントリでは .NET Core 2.0 / ASP.NET Core 2.0 でKey Vaultの証明書を利用する方法を簡単にまとめます。

続きを読む →

Azure App Service on Linux と Web Apps for Containers が GA

/ buchizo / コメントする

いつくるかなーと待ってたApp Service on Linux と Web Apps for Containers が GAしました。

概要はこちらも参照。

App Service on LinuxのほうはCI/CDやスロットなどもろもろApp Serviceの機能はもちろん、SSHサポートとかもあります。詳しくはしばやん雑記を参照。日本の東西リージョンでも使えるしすぐに本番で使えますね。

なおApp Service on Linux と Web Apps for ContainersはFree/Sharedプランでは使えないようです。

今後もいろいろ楽しみです。

App Service の CI/CDでビルドエラー

/ buchizo / コメントする

ちょっとはまったのでメモ。（そのうち改善されると思われる）

はまった環境: Visual Studio 2017 で .NET Framework 4.6.2 なクラスライブラリでNuGetなパッケージを使用しているC#プロジェクト（NuGetはPackageReferenceを参照する）と、それを参照するASP.NETなアプリ（1つのソリューションにASP.NETとクラスライブラリなプロジェクトがある状態）
はまった理由:  App Service上（Kudu上）で msbuild 15.x がないから（たぶん）

普通にApp Service上でCI/CDを使って（今回はLocal Git）上記なプロジェクトをデプロイ（git push）すると以下のようにNuGetで取得するパッケージに含まれるアセンブリが見つからない旨のエラーがでてビルドに失敗します。（nuget restoreやdonet restoreしてるにも関わらず）

省略
:
remote: D:\Program Files (x86)\dotnet\sdk\2.0.0-preview1-005977\Microsoft.Common.CurrentVersion.targets(1964,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "Newtonsoft.Json, Version=10.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [D:\home\site\repository\web1\Shared\Shared.csproj]
:
以下略

カスタムデプロイスクリプトを使用するようにして、dotnet build や dotnet msbuild を使ってもダメです。
※Kudu上に現状Previewなmsbuildがありますがそちらを使ってもダメ
※ちなみにプロジェクトがPackage.configを参照するようになってたら問題なくビルドできます。PackageReferenceの場合のみおかしい。

回避策: クラスライブラリなプロジェクトファイル（.csproj）を新しい形式に変換する

変換は以下のURLを参考に。

最低限Project要素の属性を新しくして TargetFrameworkVersion を TargetFrameworkにしてv.4.6.2 とかを net462 とかにします。あとは不要な要素はバスバスけして、AssemblyInfo.csも消したりしました。
修正後、Visual Studio 2017上でちゃんとプロジェクトがロードできてビルドできればひとまず大丈夫かと思います。（Minなcsprojにしてから後でNuGetパッケージ追加したりもろもろいじってもよいかと思います。

変換後は dotnet build や dotnet publish で問題なくビルドできます。（つら）

過渡期な問題だと思いますが、もし嵌った人がいれば参考にしてもらえると。

App Service on Linux (Preview)

/ buchizo / 1件のコメント

そろそろ移動＆寝ようと思ってた矢先に我らが帝国兵殿から矢文が届きました。

ということでApp ServiceのLinux版がPreview公開されました。さっそくしばやん先生が触ってるのでそっちもどうぞ。

でも良い子のみんなはちゃんと公式ドキュメントをまず見ましょう。

続きを読む →

App Serviceのトラブルシューティング用ツールがよくなりました

/ buchizo / 1件のコメント

もともと Azure App Service Support (Preview)  で見れていたものがAzure Portal上でも見えるようになった感じです。
Azure App Service Support (Preview)については以前書いたのでそちらも参照ください。

またAzure App Service Web AppsなどをStandardで使ってる場合にVM毎のメトリックも見えるようになりました。

最初にサイト単体のところはこんな感じで見えます。これは前からかな？
image

ちゃんとVM単位でも見れますね。
imageimage

※たまたま途中でVMが入れ替わったようす

CPU時間と平均メモリワーキングセットも参照できますよ
image

ではApp Serviceプラン全体ではどうかというと「App Service plan Metrics per Instance」で見ることができます。
image

プラン全体の概要

image

（そのプランに含まれる）サイト単位でのCPU・メモリ、HTTPの状態やネットワークの状態など
image
image
image

緑色のサイト名のところでOn/Offできるので、どのサイトに負荷が掛かってるか（圧迫してるか）などを簡単に把握できますね。もちろん上部のVM名のタブで複数インスタンスある場合にどのVMが、というのも調べられます。

その他ライブモニターや診断ログの取得などもポータルでできるのでApp Serviceについてはかなりのことがポータル単体で把握でき、対処できるようになりました。いい感じです。

App Service Certificate

/ buchizo / 1件のコメント

App Service Certificate というのが増えてました。Azure 上でApp Service用のSSL証明書をGoDaddyから簡単に購入して利用することができます。

わかりにくいですが、S1だとネイキッドドメインとwww. に対応した証明書のみ、W1でワイルドカード証明書が発行されます。
（後述）
ドメインの確認が必要とはいえAzure上で証明書の購入プロセスが完了して、Azure Key Vaultで安全に保管しながら利用できるのは便利ですね。

続きを読む →

App Service Environmentでバックエンドと通信できない

/ buchizo / コメントする

App Service Environment（日本語名：App Service 環境）を使うとVNET（v1）※現状 に接続することができます。
普通のApp Serviceと違ってClosedな環境にしたり、VNETにつなげられるということはVPNであれこれしたりできるわけです。

なので内部用で外には公開したくないSQL Serverな仮想マシンとかVNET参加させたRedis（Premium）とかと合わせて完全VNETオンリーな環境が作れるわけですが、VNETの注意点として以下のように記載されています。

App Service 環境からバックエンド リソースへの安全な接続
App Service 環境から仮想ネットワーク内のエンドポイントへの送信トラフィックには、注意すべき点が 1 つあります。App Service 環境から、App Service 環境と同じサブネットにある仮想マシンのエンドポイントに到達することはできません。App Service 環境が、App Service 環境専用として予約されているサブネットにデプロイされていれば、通常、これは問題にはなりません。

クラシックなVNET（v1）の制限なのかNSGの制限なのか、はっきりとわかりませんでしたがApp Service Environmentと同じサブネット上の他の機器とうまく通信できないようです。

なので教訓としてApp Service Environmentは専用Subnetに配置しましょう。（作るのが大変なのでこちらを専用化したほうが楽でしょう。CIDRの都合もあるかもしれないし）

さてさて、そうは言ってもそこを何とかならないですか？というのが世の常ですね。
一応泥臭い回避策はないことはないのですが、、、

簡単に言うとApp Service EnvironmentのWorkerPoolであるWeb Appsの設定で明示的にVNETに参加させるという感じです。
この機能そのものは通常のApp Serviceでもある機能で、VNETにPoint to Site接続でVPN接続する機能です。
image

同じVNETにいるくせにVPNを張らないといけないとは！ｗ（おまけにPoint to Siteの設定がVNET側にも必要です）
ということで結局大変でしかも余計な口ができてしまうので、あきらめて作り直したほうがいいかと思います。

まとめ

ネットワークの設計は慎重に。ドキュメントは穴があくほど見まくりましょう。

Azure App Service に.NET Framework 4.6がロールアウトされました

/ buchizo / 1件のコメント

以前のPostで8月中にAzure App Serviceで.NET Framework 4.6が使えるように～という話がありましたが、今日ロールアウトされて利用できるようになりました。

image

これで安心して（？）.NET Framework 4.6使えますね。ちなみにRyuJITは今のところ無効化されてるようです。

安定して利用できるようになるのを待ちましょう。