Azure Provider に限った話ではないと思うのですが、正直 Azure Provider はリソースの非推奨化が多い気がするので書いています。きっかけとしては直近の Azure Provider の更新で azurerm_static_site は非推奨になって azurerm_static_web_app が追加されたことにあります。 追加された時から正直命名をミスっているなと思っていましたが、このバージョンから他の App Service に合わせる形で新しい名前のリソースが追加されました。機能としては変わっていないので、今回の場合は本当に名前が変わっただけです。 これまでにも Azure Provider では同じようなリソース変更があり、代表的かつ影響範囲の広いものとして App Service / Azure Functions があります。v3 のリリースタイミングで

ASP.NET Core 2.2 から Health Checks API が実装されました。最近の Container や Microservices の流れでは必須機能と言えるので、シンプルな API として実装されたのは良い感じです。 ドキュメントがありますが重要な機能だからかとても長いです。過去最長ぐらいのレベルで。 API はシンプルな割に行えることがとても多いので、実際に自分で触ってみておくことにします。 ちなみに Health Check に関係するデザインパターンやアーキテクチャのドキュメントも、Microsoft Docs にて公開されています。使ってる技術は古いですが、こういうのは考え方が重要なので問題ありません。 目を通しておくと、何故 Health Check が今必要なのかが理解できると思います。 以下に実際に自分が触って動作を確認したり、試してみて気になったこと

今や必須となっている https 対応のために App Service に SSL 証明書をバインドする場合、ほとんどの場合は PFX を作成してアップロードしていると思いますが、割とこの辺りの手順は面倒ですよね。アップロードしたはずの証明書が思ったように出てこない場合もあります。 調べた限りでは App Service にアップロードした証明書の挙動は以下のようになっています。 App Service の証明書は Webspace に関連付く 証明書と App Service が同じ Webspace 上にある場合のみ利用可能 こういった条件があるため複数リージョンに Traffic Manager などで分散している場合には、それぞれの App Service に対して証明書のアップロードを行う必要があるので、正直なところ凄く手間がかかります。 なので後から Key Vault に保存

Twitter で世界のやまさが Azure Front Door を試していて、Key Vault 向けにも Let's Encrypt の証明書を自動でいい感じに出来れば良いみたいなオーラを感じ取ったので、前に作った App Service 向けのものからコピペで新しく Key Vault 向けを作ってみました。 鍵は Key Vault に保存されているので安全です。てか公式で欲しい Integration でした。 ちなみに Key Vault は単に証明書をストアする機能だけではなく、新しく CSR を作成したり、その後認証局で署名して貰った証明書をマージする機能もあるので、実装自体は非常に簡単でした。 統合された CA の場合は簡単なんですが Let's Encrypt は対応していないので、例によって Managed Service Identity を有効にした Azure

Ignite 2018 の前から Azure DNS を弄ってたら気づいた Alias Record Set が GA しました。*1 Traffic Manager か Public IP Address の場合のみ利用可能という制約がありますが、長らく Zone Apex なドメインは使えなかったという問題が解消です。 これまでは www を付けて CNAME という方法しかなかったので嬉しいです。 早速 App Service を Traffic Manager に追加し、世界中のリージョンに App Service をデプロイして負荷分散を試そうかと思ったのですが、Alias として Traffic Manager を追加しようとするとエラーになりました。 今のところ Traffic Manager に IP アドレスで追加していないと、Zone Apex なドメインに Alias

Visual Studio 2017 の 15.8 で Azure Functions の Zip Deploy と Run-From-Zip に対応したので、そろそろちゃんとブログにまとめておこうかと思いました。 デプロイのタスク定義は Azure Functions の SDK に含まれているので、他のプロジェクトでは Zip Deploy は使えないので注意。 Zip Deploy は名前の通り zip ファイルを渡すと、それをそのままデプロイしてくれる機能です。これまでは Web Deploy 形式として作成しないといけなかったのですが、zip ならどの環境でも簡単です。 特に CI/CD を使う場合には有用ですね。MS Deploy はオプションが少し複雑です。 そして Run-From-Zip は zip ファイルをそのまま wwwroot 以下にマウントして実行に使ってしまう

ASP.NET Core 2.0 から導入された必要なパッケージを一通り参照するメタパッケージですが、あまりにも参照が多いので何となく嫌な感じがする人はいると思いますが、絶対に使うべきなので理由を書いておきます。 メタパッケージに関しては公式ドキュメントにあるので、基本的な方針に関しては参照してください。 共有フレームワークとしてメタパッケージはインストールされる点が非常に大きい特徴です。 このドキュメントにはちゃんとメタパッケージを使うべき理由が書いてあります。 Applications that use the Microsoft.AspNetCore.App metapackage automatically take advantage of the ASP.NET Core shared framework. When you use the Microsoft.AspNetCo

ぶちぞう RD 曰く、6 年ぐらい待ったという Azure CDN のカスタムドメインでの HTTPS 対応を早速試しました。ドメイン承認プロセスがあるので、ちゃんとドキュメントには予め目を通しておきましょう。 前提条件として Azure CDN エンドポイントを作成して、カスタムドメインを追加しておく必要があります。わかりやすいように CDN エンドポイントが有効になるまで待った方が良さそうです。 カスタムドメインを追加すると、HTTPS を有効にする設定が出てきます。 設定を On にして保存すると、ドメイン承認用のメールが admin@domain というアドレスに送信されます。最初はドキュメントをちゃんと読まなかったので、受信できないドメインを追加していました。 しばらくすると DigiCert からメールが届きます。載っているリンクをブラウザで開きます。 リンク先は以下のような画

今年もあっという間に大晦日になってしまったので、今年やったことや印象深いことを書き出します。脳内の整理としても、書き出しておくのは良いと考えています。 2 年目も無事生き延びることが出来た 2017 年は割と 1 年を通して忙しくしてました。少し予定がずれてしまって、途中からは週休 0 日になってしまったケースもありましたが、2017 年内にやらないといけない仕事は全て終わらせた気がします。 今年は Azure と ASP.NET Core をよく使った気がします。技術的には以下のよう感じ。 App Service / App Service on Linux への移行 ASP.NET MVC 5 を使ったプロトタイプ実装 ASP.NET Core を使った B2C アプリ開発の助っ人 ASP.NET Core 2.0 / Cosmos DB / AAD B2C を使った B2C サービス

GitHub の Issue を眺めていたら、West Central US の App Service には Windows Server 2016 をデプロイしたと書いてあったので、早速新しく Web App をデプロイして試していました。 中の人曰く、West Central US をテストの場として使っているみたいです。ちゃんと 2016 です。 軽く触ってみましたが、当然ながら構成は全く同じです。なので互換性を気にする程ではないです。 Kudu API に OS の名称とビルド番号を返す機能が追加されたので、それを使って使われているバージョンを詳細に取ってきました。この辺りは予告通りですね。 14393.1794.amd64fre.rs1_release(bryant).171110-1651 ちまちま確認するのはアレなので、GitHub に置いてあるバージョンなどをいい感じに表

ちょっと前に次の Semi-Annual Channel 向けの Windows Server Inside Preview がリリースされてました。ぶちぞう RD が空リプしてましたが、6 時とか完全に寝てるので気が付きません。 Announcing Windows Server Insider Preview Build 17035 https://t.co/LXoJNaqhDE しばやん向け— こすもす.えび (@kosmosebi) 2017年11月15日 S2D とか個人的にはどうでもよくて、やっぱり注目はずっと WinNAT 周りの制約と言い続けてきた、ループバックアドレスでコンテナにアクセスできない点が解消されたことです。 Developers can now use localhost or loopback (127.0.0.1) to access services r

Twitter でおーみさんに Cosmos DB についていろいろ聞いたので、忘れないようにメモっておきます。kyrt.in に書いてあればみんな幸せになりそうなんですが、いつ書いてくれるかわからないので。 HTTP GW ではなく TCP Direct を使う デフォルト設定のまま Cosmos DB を使っていると、どうも遅いような気がしたので聞いたところ、TCP Direct を使うように設定を変えるのが良いと教えて貰いました。 デフォルトって、HTTP GW だっけ。TCP DIRECTがお勧めされている。実際、2から３割はレイテンシが小さいと思う。— Takekazu Omi (@takekazuomi) 2017年10月9日 DocumentClient を作るときに ConnectionPolicy を渡してやればよいです。 var connectionPolicy = n

以前に書いたことがある Web Apps の Local Cache について、やっと公式ドキュメントが用意されていることを Azure 界の抱かれたい男 No.1 に教えてもらいました。 Azure App Service Local Cache Overview https://t.co/fFVhBPT3mh しばやんさんんへ— こすもす.えび (@kosmosebi) 2016年3月8日 typo しているのは大人なのでスルーしました。 さて、肝心の Local Cache は Web Apps の弱点の一つである、共有ストレージに起因する問題を解決するものです。機能の説明だけではなく、仕組みもドキュメントに書いてありました。 Web Apps は複数のインスタンス間で D:\home 以下を共有しているため、WordPress などのアプリケーションをそのままスケールアウトさせるこ

Hyper.sh - Clusterless Docker Hosting Hyper.sh の特徴とメリット 個人的にはクラスタ不要で Docker が使えるというだけでかなりのメリットになるのですが、それ以外にもいろいろと特徴とメリットがあったので少しだけ書いておきます。 Docker と同じコマンド体系で利用できる Hyper.sh が提供している CLI は Docker とほぼ同じコマンドが使えるようになっています。具体的には docker を hyper に置き換えるだけで使い始めることが出来ます。 # docker の場合 docker pull shibayan/decode-demo:v5 docker run -d -p 80:80 -it shibayan/decode-demo:v5 # hyper の場合 hyper pull shibayan/decode-de

先月開催された de:code 2017 の担当セッションの動画が Channel 9 に公開されていました。今日までに App Service on Linux は大きなアップデートが行われていないので、セッション内容はまだ最新のままです。 デモは 3 回やっているので、是非動画で確認いただければと思います。 App Service Plan から作って、最後に CircleCI を使ったデプロイまで行っています。 スライドも公式には SlideShare で上がっていますが、Speaker Deck でも最新かつ不要なスライドを除去したものを公開しているので、こちらも参照していただければと思います。 表紙が違うのは、後からテンプレートが更新されていたらしくこうなってます。最新のテンプレートをちゃんと事前に共有して欲しかったですね。 当日のセッションに関するツイートもまとめてあります。当

久し振りに de:code で話をしてきました。周りの人からはアニメタイトルセッションと茶化されましたが、ちゃんと意味があって付けているのです。多分。 おかげさまで、今回は前回よりも広い部屋が割り当てられ、想像以上の大勢の方に参加していただくことが出来ました。App Service on Linux について知ってもらえたなら幸いです。 危うく私のセッションによって、デプロイ優先順位が左右される展開になるとこでした。 しばやん先生のセッションの入り具合は、日本リージョンへのデプロイの優先順位の参考にするかも— 帝国兵 (@superriver) 2017年5月24日 まだプレビューのサービスなので、当日までいろいろとアップデートがあるのではないかとか、スピーカー控室のネット回線が不調でテザリングをする羽目になったとかいろいろありますが、当日のデモは全て上手くいきました。App Servic

3/8 に Azure の Japan East で久し振りに大規模な障害が発生しました。既に RCA が上がってきていて、ぶちぞう RD がブログで書いているので、原因についてはそっちを参照で。 2017.03.08 の Azure障害 | ブチザッキ そして今年も 3/11 を過ぎたことですし、ちゃんとアーキテクチャと運用を最新のサービスや仕組みでリフレッシュしていかないといけないですね。ちょっとポエム臭くなってきたけど、割と中身は真面目に。 さて、障害の継続時間は 2 時間ぐらいでしたが、例によって Storage 周りの障害だったため、数多くの Azure サービスが影響を受けました。障害発生中の Azure Status はこんな感じでした。 Azure の Storage はご存知のように Blob / Table / Queue / Disk / File といった、各サービ

以前にぶちぞう RD が試した時にはまだまだ初期実装で、一度アセンブリを読み込むとロックされて更新できなくなってましたが、今朝 Azure Functions のランタイムがアップデートされて解消したみたいです。 App Service を確認すると、既に最新のバージョンがインストールされていました。すぐに試せます。 New #AzureFunctions release with improved support for precompiled assemblies. See more in release notes! https://t.co/5nv7UpQJ2p— Donna Malayeri (@lindydonna) 2017年2月15日 ブラウザだけで開発できる手軽さは素敵ですが、やはり俺達には Visual Studio のエディターが必要でした。csx はまだまだ発展途上

2017 年だし、ホログラフィック（自称）と名乗ってるし、このゲームは遊んでおかないといけないと思ったので、蛎殻町に放置されていた HoloLens を整備して試しました。 プレイ中 pic.twitter.com/QtKIPsxFpy— しばやん (@shibayan) 2017年2月14日 UWP 版の Remote Desktop アプリケーションを使って、ゲームをインストール済みのマシンに接続しました。Clicker が見つからなかったので、全ての操作をエアタップで行ったので腕がつりそうでした。 画面サイズはドラッグで自由に大きく出来るので、下の画像は 100 インチは超えてる気がします。 2017 年感が凄くあってよい pic.twitter.com/Yw5t0bLfE4— しばやん (@shibayan) 2017年2月14日 ちゃんと Remote Desktop でも音が出

昨日の時点で気が付いてましたが、中の人から Twitter で発表されてたので App Service on Linux の Ruby 対応を試してみました。結果としては動かすことが出来なかったです。 Now you can deploy your Ruby App on #AzureAppService on #Linux pic.twitter.com/KhgfTRwn74— Ahmed Elnably (@elnably) 2017年2月13日 2,3 時間を検証に使ってしまったので、試した内容をメモしておくことにします。 元々 Docker Image をビルドしてカスタムイメージとして登録すれば、Ruby に限らずどんなイメージでも実行できますが、ランタイムスタックとして Ruby を選択して試しました。 空っぽの状態で Ruby 2.3 を選択すると、よく見るデフォルトサイトが