Japan Azure PaaS Support Blog https://docs.microsoft.com/archive/blogs/jpcie/feed.xml Azure 開発全般をサポートする、Azure PaaS サポートチームのブログです。 Wed, 17 Apr 2019 01:09:50 GMT ja hourly 1 Japan Azure PaaS Support Blog 終了のお知らせ https://docs.microsoft.com/archive/blogs/jpcie/%E3%80%90%E3%81%8A%E7%9F%A5%E3%82%89%E3%81%9B%E3%80%91japan-azure-paas-support-blog-%E7%A7%BB%E5%8B%95%E3%81%AE%E3%81%8A%E7%9F%A5%E3%82%89%E3%81%9B Wed, 17 Apr 2019 09:59:23 GMT https://blogs.msdn.microsoft.com/jpcie/?p=2795 Japan Azure PaaS Support Team フォーラム  ]]> Azure Web Apps / Azure Functions から同じリージョンの Azure Storage Account へ接続する時の注意点 https://docs.microsoft.com/archive/blogs/jpcie/azure-web-apps-azure-functions-%E3%81%8B%E3%82%89%E5%90%8C%E3%81%98%E3%83%AA%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3%E3%81%AE-azure-storage-account-%E3%81%B8%E6%8E%A5%E7%B6%9A%E3%81%99%E3%82%8B%E6%99%82 Tue, 30 Oct 2018 13:00:52 GMT https://blogs.msdn.microsoft.com/jpcie/?p=2745 同じリージョン内での通信の場合、Firewall を設定すると通信ができなくなる
Azure Web Apps / Azure Functions から同リージョンの Azure Storage Account へ接続する際は、Azure ポータル上の、Web App -> [プロパティ] に記載されている送信 IP ではなく、Azure Web Apps / Azure Functions のプラットフォーム内部で利用されているプライベート IP 経由で通信を行います。 このため、Firewall に下記のような Azure Web Apps や Azure Functions の [プロパティ]に記載されているパブリック IP を設定すると、同じリージョン の Azure Web Apps/ Azure Functions から Storage Account  に接続することができなくなります。 ちなみに、Storage Account のログを有効化して、接続に失敗した時のログを見ると、10.72.196.80:50062; のように、クライアントの IP としてプライベート IP が記載されます。

1.0;2018-10-29T08:50:00.3251459Z;CreateContainer;IpAuthorizationError;403;2;2;authenticated;kemurastorage;kemurastorage;blob;"https://kemurastorage.blob.core.windows.net:443/firewalltestcont?restype=container";"/";cb846703-501e-006d-1864-6f7cee000000;0;10.72.196.80:50062;2017-04-17;448;0;95;246;0;;;;;;"Azure-Storage/0.36.0 (Python CPython 3.6.4; Windows 10)";;"9e659d00-db57-11e8-9c95-0003ffec138c"

  このプライベート IP の範囲は公開されていないため、恐れ入りますが現状では下記のいずれかが対象方法となります。
  • Firewall を解除して Azure Storage Account と通信する
  • App Service Environment を利用して、サービス エンドポイントと連携する
  もしくは、通常の VNET 統合機能ではサービス エンドポイントと連携することはできませんが、新しい VNET 統合の機能 (プレビュー) であればサービス エンドポイントとの連携が可能です。  

別リージョンであれば問題なく設定できる

Azure Web Apps / Azure Functions と、Azure Storage Account が東日本と西日本などそれぞれ別リージョンにある場合は、Firewall の設定が可能です。   お手数をおかけしますが、通常の Azure Web Apps を使いつつ Storage Account の Firewall を利用する場合は、Azure Web Apps / Azure Functions と、Azure Storage Account のリージョンを分けていただきますようお願い申し上げます。   ※ 本記事の内容は予告なく変更される場合がございますので予めご了承ください。        ]]> Azure Functions での App Service 認証/承認 https://docs.microsoft.com/archive/blogs/jpcie/azure-functions-%E3%81%A7%E3%81%AE-app-service-%E8%AA%8D%E8%A8%BC-%E6%89%BF%E8%AA%8D Fri, 14 Sep 2018 10:44:55 GMT https://blogs.msdn.microsoft.com/jpcie/?p=2445 Azure App Service での認証および承認

この機能は、Azure Functions でも利用することができ、HTTP トリガーで起動する Function に、任意の認証プロバイダーによる認証機能を付加することができます。 これにより、認証されたクライアントのみを Function にアクセスできるようにさせることができます。 今回は、認証プロバイダーとして Azure Active Directory を利用する場合の手順をご紹介します。  

概要

認証/承認機能が有効化された Function App にアクセスするためには、認証プロバイダーから取得した認証トークンを Function App に提示します。 このため、Function App へのアクセス前に、認証プロバイダーから認証トークンを取得する必要があります。 以下より、認証トークンを取得するための構成と、認証トークンの取得、使用方法を記載します。  

Function App で認証/承認を構成する

Function App を作成し、プラットフォーム機能の [認証/承認] をクリックします。   App Service 認証をオンにして "Azure Active Directory でのログイン" を選択し、認証プロバイダーとして Azure Active Directory を選択します。 管理モードを "簡易" とし、新しい AD アプリを作成します。

  作成完了後、管理モードを "詳細" に切り替えると、作成された AD アプリの詳細を参照することができます。 ここで、"クライアント ID" はこの AD アプリのリソースを表す ID となります。この ID を控えておきます。   [関数の URL の取得] をクリックして、実行したい Function の URL を控えておきます。
なお、HTTP トリガーで起動する Function は、既定では要求を承認するために API キーを必要とします(上図の code 値)。 この設定は function.json で変更可能であり、authLevel プロパティを anonymous に設定すると、API キー無しでアクセス可能になります。 API キーによる承認は Function ごとであるのに対して、本稿でご案内している Azure AD トークンによる承認は Function App 全体に対して適用されるという違いがあります。セキュリティ要件にあわせてそれぞれご利用ください。

Azure Functions における HTTP と Webhook のバインド - トリガー - 構成

   

Azure Active Directory にアプリケーションを登録する

Function にアクセスするクライアント アプリケーションの定義を Azure AD に登録します。 Azure AD アプリケーションは、Azure AD を利用するアプリケーションの定義です。Azure AD アプリケーションを登録することで、アプリケーションに対してトークンを発行する方法を定義します。   Azure AD テナントで、[アプリの登録] - [新しいアプリケーションの登録] をクリックします。     以下、ネイティブ アプリケーション、Web アプリ/API のそれぞれを登録した場合について記載します。 # 2018/09/19 アクセス許可の設定を追記しました。    

ネイティブ アプリケーション

ネイティブ アプリケーションでは、クライアントに配布されるようなアプリケーションが想定されます。トークンを取得するために、基本的にユーザーが対話形式でサインインして、資格情報を提供します。   アプリケーションの種類を "ネイティブ" とします。リダイレクト URI は物理的に存在するものである必要はありませんが、アプリケーションに固有の値を設定しておきます。 次に、アクセス許可の設定を追加します。この設定により、このアプリケーションで発行されるトークンが、Function App に対するアクセス許可を持つことを定義します。 [必要なアクセス許可] で [追加] をクリックします。   API として、Function App で簡易作成した Azure AD アプリケーションを指定します。 その Azure AD アプリケーションへのアクセスを許可するように設定し、完了します。   最後に、登録したアプリケーションのアプリケーション  ID を控えておきます。    

Web アプリ/API アプリケーション

Web アプリ/API アプリケーションでは、サーバーでホストされるようなアプリケーションが想定されます。アプリケーション コードがユーザーからは機密となるため、トークンを取得するために、シークレット キーを使用して資格情報を提供することができます。   アプリケーションの種類を "Web アプリ/API" とします。サインオン URL は物理的に存在するものである必要はありませんが、アプリケーションに固有の値を設定しておきます。 次に、ネイティブ アプリケーションと同様に、アクセス許可の設定を追加します。   キーを生成します。"説明" と "有効期限" を設定後、[保存] をクリックすると、キー値が表示されます。 キー値が表示されるのは保存後のみですので、このタイミングで必ずキー値を控えておきます。   最後に、登録したアプリケーションのアプリケーション  ID を控えておきます。       以上で Azure AD アプリケーションの登録は完了です。最後に、Azure AD テナントのプロパティからディレクトリ ID を控えておきます。    

クライアント アプリケーションを実装する

以下は、PowerShell スクリプトと C# アプリケーションで、 Function を実行する場合のサンプルです。 Azure AD からトークンを取得するために ADAL.NET を使用していますので、適宜ダウンロードしてください。 # 2018/09/19 コードを一部修正しました。

ネイティブ アプリケーション

[PowerShell] [powershell] ### ADAL.NET をロード ### $adal = "C:\ADAL\Microsoft.IdentityModel.Clients.ActiveDirectory.dll" [System.Reflection.Assembly]::LoadFrom($adal) ### Azure AD テナントの設定 ### # Azure AD テナントのディレクトリ ID $adId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" # トークン発行元 $authority = "https://login.microsoftonline.com/$adId" ### Function App で作成した AD アプリ ### # クライアント ID $resourceApplicationId = "11f15836-8e45-4fb9-b9f8-b66611b21f8b" ### クライアント用に作成した AD アプリ ### # アプリケーション ID $clientApplicationId = "dbcb7ba3-c667-4323-a310-a5e834b32675" # リダイレクト URI $redirectUri = "https://jpciesample/MyNativeApp" ### トークン生成 ### # ADAL の AuthenticationContext オブジェクト $authContext = New-Object Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext -ArgumentList $authority # トークン要求 (資格情報がキャッシュされていない場合、資格情報プロンプトが起動します) $platformParameters = New-Object "Microsoft.IdentityModel.Clients.ActiveDirectory.PlatformParameters" -ArgumentList "Auto" $authResult = $authContext.AcquireTokenAsync($resourceApplicationId, $clientApplicationId, $redirectUri, $platformParameters) # Bearer トークン $bearerToken = $authResult.Result.CreateAuthorizationHeader() ### Function の呼び出し### # Function の URL $functionUri = "https://jpcieauthtest.azurewebsites.net/api/HttpTriggerCSharp1?code=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" # 要求 Body $body="{'name': 'Azure'}" # HTTP 要求ヘッダの Authorization ヘッダに Bearerトークンを設定 $requestHeader = @{ "Authorization" = $bearerToken } # HTTPS のセキュリティ プロトコルを TLS 1.2 に設定 [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 # Function に HTTP 要求を送信 try{ $response = Invoke-RestMethod -Uri $functionUri -Method Post -Headers $requestHeader -Body $body -ContentType "application/json" echo $response }catch{ Write-Error($_.Exception); } [/powershell]
[C#] [csharp] /* Azure AD テナントの設定 */ // Azure AD テナントのディレクトリ ID string adId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"; // トークン発行元 string authority = "https://login.microsoftonline.com/" + adId; /* Function App で作成した AD アプリ */ // クライアント ID string resourceApplicationId = "11f15836-8e45-4fb9-b9f8-b66611b21f8b"; /* クライアント用に作成した AD アプリ */ // アプリケーション ID string clientApplicationId = "dbcb7ba3-c667-4323-a310-a5e834b32675"; // リダイレクト URI string redirectUri = "https://jpciesample/MyNativeApp"; /* トークン生成 */ // ADAL の AuthenticationContext オブジェクト AuthenticationContext authContext = new AuthenticationContext(authority); // トークン要求 (資格情報がキャッシュされていない場合、資格情報プロンプトが起動します) var authResult = authContext.AcquireTokenAsync(resourceApplicationId, clientApplicationId, new Uri(redirectUri), new PlatformParameters(PromptBehavior.Auto, null)); // Bearer トークン string bearerToken = authResult.Result.CreateAuthorizationHeader(); /* Function の呼び出し */ // Function の URL string functionUri = "https://jpcieauthtest.azurewebsites.net/api/HttpTriggerCSharp1?code=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"; // 要求 Body string bodydata = "{\"name\": \"Azure\"}"; // Function に HTTP 要求を送信 HttpWebRequest request = WebRequest.Create(functionUri) as HttpWebRequest; request.Method = "POST"; request.Headers["Authorization"] = bearerToken; request.ContentType = "application/json"; Stream reqstr = request.GetRequestStream(); reqstr.Write(Encoding.ASCII.GetBytes(bodydata), 0, bodydata.Length); reqstr.Close(); HttpWebResponse response = request.GetResponse() as HttpWebResponse; Stream resstr = response.GetResponseStream(); StreamReader sr = new StreamReader(resstr); string resresult = sr.ReadToEnd(); Console.WriteLine(resresult); [/csharp]
   

Web アプリ/API アプリケーション

[PowerShell] [powershell] ### ADAL.NET をロード ### $adal = "C:\ADAL\Microsoft.IdentityModel.Clients.ActiveDirectory.dll" [System.Reflection.Assembly]::LoadFrom($adal) ### Azure AD テナントの設定 ### # Azure AD テナントのディレクトリ ID $adId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" # トークン発行元 $authority = "https://login.microsoftonline.com/$adId" ### Function App で作成した AD アプリ ### # クライアント ID $resourceApplicationId = "11f15836-8e45-4fb9-b9f8-b66611b21f8b" ### クライアント用に作成した AD アプリ ### # アプリケーション ID $clientApplicationId = "3cd3551e-fc68-4510-b236-64c207b353fb" # リダイレクト URI $redirectUri = "https://jpciesample/MyNativeApp" # シークレット キー $secretKey = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" ### トークン生成 ### # ADAL の AuthenticationContext オブジェクト $authContext = New-Object Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext -ArgumentList $authority # クライアント資格情報 $clientCredential = New-Object -TypeName Microsoft.IdentityModel.Clients.ActiveDirectory.ClientCredential ($clientApplicationId, $secretKey) # トークン要求 $authResult = $authContext.AcquireTokenAsync($resourceApplicationId, $clientCredential) # Bearer トークン $bearerToken = $authResult.Result.CreateAuthorizationHeader() ### Function の呼び出し### # Function の URL $functionUri = "https://jpcieauthtest.azurewebsites.net/api/HttpTriggerCSharp1?code=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" # 要求 Body $body="{'name': 'Azure'}" # HTTP 要求ヘッダの Authorization ヘッダに Bearerトークンを設定 $requestHeader = @{ "Authorization" = $bearerToken } # HTTPS のセキュリティ プロトコルを TLS 1.2 に設定 [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 # Function に HTTP 要求を送信 try{ $response = Invoke-RestMethod -Uri $functionUri -Method Post -Headers $requestHeader -Body $body -ContentType "application/json" echo $response }catch{ Write-Error($_.Exception); } [/powershell]
[C#] [csharp] /* Azure AD テナントの設定 */ // Azure AD テナントのディレクトリ ID string adId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"; // トークン発行元 string authority = "https://login.microsoftonline.com/" + adId; /* Function App で作成した AD アプリ */ // クライアント ID string resourceApplicationId = "11f15836-8e45-4fb9-b9f8-b66611b21f8b"; /* クライアント用に作成した AD アプリ */ // アプリケーション ID string clientApplicationId = "3cd3551e-fc68-4510-b236-64c207b353fb"; // シークレット キー string secretKey = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"; /* トークン生成 */ // ADAL の AuthenticationContext オブジェクト AuthenticationContext authContext = new AuthenticationContext(authority); // クライアント資格情報 var clientCredential = new ClientCredential(clientApplicationId, secretKey); // トークン要求 var authResult = authContext.AcquireTokenAsync(resourceApplicationId, clientCredential); // Bearer トークン string bearerToken = authResult.Result.CreateAuthorizationHeader(); /* Function の呼び出し */ // Function の URL string functionUri = "https://jpcieauthtest.azurewebsites.net/api/HttpTriggerCSharp1?code=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"; // 要求 Body string bodydata = "{\"name\": \"Azure\"}"; // Function に HTTP 要求を送信 HttpWebRequest request = WebRequest.Create(functionUri) as HttpWebRequest; request.Method = "POST"; request.Headers["Authorization"] = bearerToken; request.ContentType = "application/json"; Stream reqstr = request.GetRequestStream(); reqstr.Write(Encoding.ASCII.GetBytes(bodydata), 0, bodydata.Length); reqstr.Close(); HttpWebResponse response = request.GetResponse() as HttpWebResponse; Stream resstr = response.GetResponseStream(); StreamReader sr = new StreamReader(resstr); string resresult = sr.ReadToEnd(); Console.WriteLine(resresult); [/csharp]
今回は、Azure Functions を例としてご案内しましたが、同じ方法で Azure Web Apps、Azure API Apps で公開する API に対して認証/承認アクセスを行うこともできます。 実行する API をパブリック アクセスから制限したいような場合に、有効なソリューションとなりますので、ご参考ください。]]> Azure Web Apps / Azure Functions で利用可能なネットワーク関連のツール https://docs.microsoft.com/archive/blogs/jpcie/azure-web-apps-azure-functions-%E3%81%A7%E5%88%A9%E7%94%A8%E5%8F%AF%E8%83%BD%E3%81%AA%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E9%96%A2%E9%80%A3%E3%81%AE%E3%83%84%E3%83%BC%E3%83%AB Wed, 29 Aug 2018 19:41:29 GMT https://blogs.msdn.microsoft.com/jpcie/?p=2185 海外のブログではすでに紹介されているのですが、Azure Web Apps や Azure Functions で、SQL Database など別サービスのエンドポイントと疎通確認をするときや、VNET 統合を利用して仮想ネットワークと接続後、仮想ネットワーク内のリソースとの接続を確認をする場合によく使うコマンドなどを紹介します。   

Azure Web Apps / Azure Functions で Ping は利用できない 

最初に Azure Web Apps や Azure Functions 上では、Ping の実行が許可されていません。 また、Azure Load Balancer は、ICMP プロトコルの通過を許可していないので、Azure  Web Apps / Azure Functions への Ping もできません。  なお、ping がタイムアウトする話の詳細はこちらのブログに書かれています。  このため、Azure  ポータル上から Web Apps を選択後、[コンソール] などで Ping を実行しようとすると画像のようにエラーが発生します。 Kudu のコンソール (https://yourwebapp.scm.azurewebsites.net/DebugConsole) 上で実行した場合も結果は同様です。     では、どうすればよいでしょうか？ tcpping と呼ばれるツールがあるのでこちらを利用しましょう。  

tcpping を実行する

tcpping を コンソール上で実行するとこんな感じになります。      Web Apps でエンドポイントへの接続確認をする場合は、Ping の代わりに tcpping を利用してください。   例えば、Web Apps から Azure SQL Database を利用する際の接続確認として利用されます。SQL Database へ接続する場合は、ポート 1433 を指定してください。     また、Azure Web Apps では VNET 統合と呼ばれる機能を利用することで、仮想ネットワーク内に配置されている VM に接続できるようになります。 VNET 統合の設定後、Web Apps から仮想マシンのプライベート IP に接続できているかどうか確認する場合は、tcpping が役に立ちます。 なお、仮想ネットワーク内の VM に対して tcpping を実行する際は、仮想マシン側で開放しているポートを指定してください。 下記画像は、仮想ネットワーク内に配置した VM に割り当てられたプライベート IP に対して tcpping で接続確認をしている例になります。     ※ VNET 統合を利用することで、Web Apps から仮想マシンへは接続できますが、仮想マシンから Web Apps へのプライベートな接続はできません。費用が高額になりますが、ILB ASE と呼ばれるサービスを使ってください。  VNET 統合の機能の紹介はこちらのドキュメントになります。 また、弊ブログのこちらの記事で ASE (App Service Environment)の紹介もしています。  

nameresolver を利用する 

VNET 統合後や、ASE 利用時に、仮想ネットワーク側で自前の DNS を指定している場合、その DNS できちんと名前解決ができるか確認するコマンドとして nameresolver が利用可能です。 nameresolver では VNET 側で構成した DNS サーバーを指定可能です。 こちらはサンプルとして DNS を指定せずに nameresolver を利用した結果です。     

Network Traceも収集できる 

App Service の通信に関しては、[問題の診断と解決] から Network Trace を利用することでパケットをキャプチャできるようになりました。(Basic プラン以上)   収集したトレースは Network Monitor や、Wireshark 、Message Analyzer を使って解析が可能です。なお HTTPS などの TLS/SSL での通信は暗号化されますのでご注意ください。 ※ VNET 統合を設定している App Service Plan や、従量課金プランの Azure Functions ではこの機能は利用できません。       "Collect Network Trace" を押下して Network Trace を収集します。    

TCP Connections からコネクションの状況を確認することもできる

[問題の診断と解決] ブレードにある、"TCP Connections" では、自分の Web App の TCP コネクションの状況も確認することができます。 接続数の増減や、TIME_WAIT が発生しているかどうかなど、1 か月前までさかのぼって確認できます。  

おまけ

curl コマンドも利用することが可能です。オプションをつける際は Kudu 上でしかうまく動作しなかったので、画像では、Kudu 上で実行しています。  

まとめ 

Azure Web Apps / Azure Functions 上で実行可能なコマンドを紹介しました。 次回は、VNET 統合設定時のトラブルを例にとって実際にどのように利用するのかご紹介しようと思います。   ※ 記事の内容は予告なく変更される可能性がございます。  ]]> Azure Web App for Containers をご利用のお客様へのお知らせ (Docker Hub のメンテナンスについて) https://docs.microsoft.com/archive/blogs/jpcie/azure-web-app-for-containers-%E3%82%92%E3%81%94%E5%88%A9%E7%94%A8%E3%81%AE%E3%81%8A%E5%AE%A2%E6%A7%98%E3%81%B8%E3%81%AE%E3%81%8A%E7%9F%A5%E3%82%89%E3%81%9B-docker-hub-%E3%81%AE%E3%83%A1%E3%83%B3 Tue, 21 Aug 2018 20:45:44 GMT https://blogs.msdn.microsoft.com/jpcie/?p=2135 ※本投稿は、https://aka.ms/dockerhub に投稿された内容を補足する内容になっています。

 
先日 Docker 社より、2018 年 8 月 25 日 11:00 AM (PST) から、Docker 各サービスについて 15 分から 45 分のアップグレード作業が実施されることがアナウンスされました。以下、アナウンス情報をご確認ください。

Planned Downtime on Docker Hub, Docker Cloud, and Docker Store on August 25th, 2018

  このアップグレード作業の実施中には、Docker Hub について、Docker イメージの Push および Docker イメージの Pull ができなくなるとのことです。したがいまして、日本時間の 8 月 26 日 (日) 4:00 AM から、一時的に Docker Hub からの Docker イメージの Pull ができない状態になる可能性があります。 Azure Web App for Containers では、アプリケーションをホストするインスタンスの初期化処理において、Docker イメージを Pull し、Docker コンテナを起動します。このため、Docker イメージを Pull できない場合、インスタンスの初期化に失敗します。 そして、インスタンスの初期化に失敗したインスタンスに対して要求が転送されることで、HTTP エラーが応答される動作となる場合があります。
なお、本件は Web App for Containers でカスタム Docker イメージを利用している場合が対象となります。App Service on Linux で組み込みのランタイム スタックを利用している場合には、Docker Hub へのアクセスは発生しませんので、本件による影響はありません。
    以上の理由により、Azure Web App for Containers のカスタム Docker イメージ ソースとして Docker Hub を設定している場合、Docker Hub 側でのアップグレード作業実施中に、Web App 側で以下のような動作が発生すると、サービス稼働に影響が及ぶ可能性があります。
  • Web App の再起動

Web App の再起動により、Docker イメージの再展開が行われるため、影響を受ける場合があります。これには、手動による再起動の他、Azure プラットフォーム側でサービス品質の低下を検知したことによる自動再起動も含まれます。 この場合、再起動が行われたインスタンスが影響を受けることになります。

  • インスタンスのスケール アップ

インスタンス サイズを変更することにより、新規サイズのインスタンスへの Docker イメージの展開が行われるため、影響を受ける場合があります。 この場合、全インスタンスが影響を受けることになります。

  • インスタンスのスケール アウト

インスタンス数を増加させることにより、新規インスタンスへの Docker イメージの展開が行われるため、影響を受ける場合があります。 この場合、増加分のインスタンスが影響を受けることになります。

    現時点では、Azure Web App for Containers では、Docker Hub にアクセスできないという状況についての対策方法がございません。 このため、上記のような問題を回避するために、現状では、Azure Container Registry あるいはその他のプライベート レジストリを利用するということが対策案となります。 該当の時間帯に影響を受ける可能性のあるアプリケーションをホストしている場合、前述のような動作が発生した場合にサービス稼働に影響が及ぶ可能性がありますので、何卒対応をご検討ください。]]> Azure サポート エンジニア募集中！ https://docs.microsoft.com/archive/blogs/jpcie/azure-%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88-%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E5%8B%9F%E9%9B%86%E4%B8%AD%EF%BC%81 Wed, 30 May 2018 11:58:22 GMT https://blogs.msdn.microsoft.com/jpcie/?p=2125 Azure サポートでは、Azure のお客様を日々支えるサポート エンジニアを募集しています！ 未曾有の成長・変革のまっただ中であるパブリック クラウドに携わる刺激的な毎日になります。お客様を支えるという最も大事な業務を通じて、Azure の未来を一緒に作り上げていきませんか。   また、マイクロソフトのサポートエンジニアのお仕事内容について、なかなか外からではわかりにくいところもありますし、コールセンターのようなイメージを持たれる方もよくいらっしゃいます。 そんな疑問にお答えするために、詳しいお仕事の内容を説明会でご紹介いたします。説明会にご参加いただければ、マイクロソフトのサポートエンジニアのイメージが大きく変わると思います。 さらに、現場のエンジニアと直接話ができるキャリア相談会も同時に開催いたしますので、マイクロソフトやAzureに興味がある方はぜひご参加ください。   参加希望の方は、下記リンクよりお申し込みください。   【6/13(水)&6/23(土)開催！エンジニア向けAzure説明会&1Day選考会】 Support Engineer- Azure team https://forms.office.com/Pages/ResponsePage.aspx?id=v4j5cvGGr0GRqy180BHbR7DJYxPXmhFBj1KAJfGnkL5URUpKRlFNQjBIWENUOUpRQjBYUkJRSkYwTi4u     <募集中の職種> ・Support Engineer Azure IaaS Platform / Networking : https://aka.ms/Guosrk ・Support Engineer Azure PaaS : https://aka.ms/Ljd5lx ・Support Engineer Azure Stack : https://aka.ms/Ht6tvq   レバテック社様の「スキルアップ記事」においても、今回対象のポジションについてご紹介いただいております！興味のある方はぜひご一読ください。 https://career.levtech.jp/guide/knowhow/article/416/     サポート エンジニア直伝 FAQ  
  1. 英語は必須ですか？
  技術文書のリーディングと、海外エンジニアとの連携にあたってのライティングが必須となります。会話力は日本のお客様対応にあたっては必須ではありませんが、入社後も英語を前向きに学んでいけることが重要です。   日々の業務では、日本のお客様に応対することとなります。 かたや、Azure データセンター開発部門との連携、世界中のエンジニア間のディスカッションにおいては、英語を使う機会が無数にあります。このような機会を自分のものにし、お客様への対応に活かしていくための勉強は欠かせません。    
  1. マイクロソフト製品の知識は必須ですか？
  マイクロソフト製品の知識は必須ではありません。何らかの技術的なバックグラウンドに自信がある方は大歓迎です。   マイクロソフトはオープン ソース テクノロジにも大きく舵を切っており、多くの製品が Linux でも動作しています。 これまでの Windows をはじめとするマイクロソフト製品だけでなく、Linux などのオープンソースに携わる技術者や、Web やインフラ系のデベロッパー、ネットワーク系のエキスパートに至るまで様々なテクノロジーのバックグラウンドが活躍できます。   Azure では 100 を超えるサービスが存在し、もはや一人のエンジニアが全てを知るということは不可能です。 様々な技術的・文化的バックグラウンドを持つエンジニアが集い、お互いを尊敬しあい、相談をしながらひとつの問題を解決していくというチームワークが求められます。    ]]> Azure App Service の VNET 統合とサービス エンドポイント https://docs.microsoft.com/archive/blogs/jpcie/azure-app-service-%E3%81%AE-vnet-%E7%B5%B1%E5%90%88%E3%81%A8%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9-%E3%82%A8%E3%83%B3%E3%83%89%E3%83%9D%E3%82%A4%E3%83%B3%E3%83%88 Thu, 19 Apr 2018 17:00:50 GMT https://blogs.msdn.microsoft.com/jpcie/?p=2055 こんにちは。Azure Dev サポートの村山です。

 

今日は App Service の VNET 統合とサービス エンドポイントの連携についてお話します。

 

仮想ネットワークのサービス エンドポイントと呼ばれる機能を利用すると、 Azure SQL Database や、Azure Storage Account へのアクセスを仮想ネットワーク内からのみに限定することが可能です。

 

最近この機能と、Azure App Service の VNET 統合の機能を組み合わせて、Azure App Service から仮想ネットワーク経由で、Azure SQL Database や、Azure Storage Account へアクセスできるかというお問い合わせをいただきます。

 

残念ですが、Azure App Service と VNET 統合の機能を組み合わせて、プライベートに Azure SQL Database や Azure Storage Account へ接続することはできません。

※ Web Apps だけではなく、App Service Plan 上にホストされたFunction App や、API App の場合も同様です。

 

一方、App Service Environment (以下 ASE) であれば、サービス エンドポイントが有効化された Azure  SQL Database や、Azure Storage Account へアクセスすることができます。

 

下記画像は、Azure SQL Database でサービスエンドポイントを有効化した例になります。

ASE に関しては、以前の記事で紹介しておりますので、こちらもご覧ください。

   

なお、ASE とオンプレミスのネットワーク間で VPN や ExpressRoute を利用している場合、インターネットへ向かうトラフィックを VPN や仮想アプライアンスにリダイレクトさせて、 "強制トンネリング" と呼ばれる構成を取るお客様もいらっしゃいます。

 

そのシナリオの場合は、こちらのドキュメントにてサービスエンドポイントを設定する方法が紹介されています。

 

セキュリティ要件が厳しい案件の場合には、ASE の利用をご検討ください。

 

※ 記事の内容は予告なく変更される場合がございますのでご了承ください。

     ]]> HTTP/2 が Azure App Service でサポートされます https://docs.microsoft.com/archive/blogs/jpcie/http2-%E3%81%8C-azure-app-service-%E3%81%A7%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88%E3%81%95%E3%82%8C%E3%81%BE%E3%81%99 Tue, 17 Apr 2018 12:11:42 GMT https://blogs.msdn.microsoft.com/jpcie/?p=2025 このポストは、2018 年 4 月 13 日に投稿された Announcing HTTP/2 support in Azure App Service の翻訳です。   Azure App Service チームは、App ServiceでホストされているすべてのアプリケーションのHTTP/2 プロトコルのサポートのグローバル展開を発表します。 HTTP/2 は最も多かったカスタマー リクエストであり、私たちはサポートを提供することに興奮しています！  

HTTP/2とは何ですか？

HTTP/2は、TCP の接続で HTTP セマンティクス フローを再検討したものであり、現在 Windows 10 と Windows Server 2016 でサポートされています。HTTP/2 は、20年近く使用された HTTP / 1.1 のメジャーアップグレードであり、 Webサーバ上の待ち時間と接続負荷を軽減します。   HTTP/1.1 の主な利点は、並行して複数の要求を連続して処理するために、複数の接続を使用することでした。 HTTP/2 では、永続的な一つの接続を使用して複数の要求を同時に処理できます。 このプロセスでは、HTTP/2 には、ネットワーク上の HTTP の効率を向上させるいくつかの追加機能が導入されています。

複数のリクエストに対する 1 つの接続

すべての TCP 接続は、セットアップのために往復が必要です。暗号化を使用している場合、TLS ハンドシェイクにはさらに 1〜2 回の往復が必要です。これは、最初の応答の最初のバイトが送信される前に全ての接続で発生します。新しい接続を設定する代わりに既存の接続を再利用することによって、このオーバーヘッドを多くの要求で共有することができます。 HTTP/2 は、新しい接続が確立されている間の待機する、もしくは既存の接続がアイドル状態になるまで待機する必要性を大幅に減らします。単一の接続が多数の要求の間で多重化されているため、他の要求が完了するのを待つことなく、要求をすぐに送信できます。  

HPACK によるヘッダー圧縮

HTTP は、何年もの間データの圧縮をサポートしています。ただし、ヘッダは圧縮されていないテキストとして送信され、要求間には多くの冗長性があります。（最も長いヘッダーの多くは、リクエストごとに同じ値で送信されます）HTTP/2 では、HTTP ヘッダーの圧縮方式であるHPACKが導入され、要求間の冗長性が低減されています。   要求がより小さくなるので、圧縮は多重化にも役立ちます。これにより、TCPフロー制御ウィンドウは小さい一方、クライアントは接続上の最初のパケットで多くの要求を行うことができます。  

HTTP / 1.xとの主な違いは何ですか？

 
  • HTTP/2はバイナリです
  • 順序付けされ、ブロックされるのではなく、完全に多重化されています
  • 1つの接続で並列性を実現することができます
  • 1つの TCP/IP 接続を保持しています
  • ヘッダー圧縮を使用してオーバーヘッドを削減します
 

App Service ユーザはどのようなアクションを取る必要がありますか？

Azure Portal の機能を使用できるようにする UI がすぐに提供される予定ですが、今のところは単純な設定変更を行う必要があります！ HTTP/2 は、すべての顧客に対して既定で無効になっていますが、サイトにオプトインして HTTP/2 を適用する場合は、次の手順を実行します。   次のいずれかの手順を使用して Azure リソースエクスプローラー を参照します。(https://resources.azure.com/)   Azure Portal で、App Service のメニューで「リソースエクスプローラー」を選択します。   次に、[移動]を選択します。     または、リソースエクスプローラー（https://resources.azure.com/）に直接アクセスしてください。 Azure Portal から利用する利点は、ブラウザがリクエストされたアプリの設定に自動的に移動することです。 リソースエクスプローラー に直接アクセスする場合は、次のパスを使用してツリー階層をサイトにドリル ダウンします。 サブスクリプション > リソースグループ > サイト名 > プロバイダー > Microsoft.Web > サイト > サイト名 > config > web   ページの一番上が、 "read/write" モードになっていることを確認してください： 編集を選択してください： HTTP/2のパラメータを検索してください：   'false'の代わりに 'true'と入力します。 上部にある「PUT」を選択します。 設定完了です！  
  • Appサービス環境とAzure National Clouds での HTTP/2 のサポートはすぐに開始されます。
 

HTTP / 2ブラウザのサポートにはSSLが必要

最新のブラウザでは、SSL  経由の HTTP/2 プロトコルのみをサポートしており、非 SSL トラフィックは引き続き HTTP/1.1 を使用しています。 App Serviceを使用すると、SSL を使用して簡単に稼動させることができます。アプリに新しいSSL証明書を設定する方法、または既存のSSL証明書をアプリにバインドする方法を確認してください。 Appサービスは、* .azurewebsites.net ドメインにバインドされた共通のワイルドカードSSL証明書を使用して、すべてのアプリに対してデフォルトのSSL機能を提供しています。どんなアプローチの場合も、最新のブラウザで HTTP/2 のメリットを享受するためには、アプリをSSL上で実行する必要があります。  

問題が発生したらどうなりますか？

HTTP / 2の更新に起因すると思われる問題が見つかった場合は、次の方法で警告できます。   ]]> Azure App Service の Service Management APIs が廃止されます https://docs.microsoft.com/archive/blogs/jpcie/azure-app-service-%E3%81%AE-service-management-apis-%E3%81%8C%E5%BB%83%E6%AD%A2%E3%81%95%E3%82%8C%E3%81%BE%E3%81%99 Wed, 21 Mar 2018 00:00:14 GMT https://blogs.msdn.microsoft.com/jpcie/?p=1995 Deprecating Service Management APIs support for Azure App Services の翻訳です。   Build 2014 にて、Azureは、呼ばれるリソース管理用の RESTful API である Azure  Resource Manager と新しい Azure Portal を発表しました。 Azure App Service が Azure Resource Manager のサポートを実装して以来、すでに数年がたっています。ポータルや、REST API 、その他の SDK やクライアント ツールを通してApp Service のリソースを管理や自動化をする場合や、デプロイ用のテンプレートを使用してリソースをデプロイを行う際には、すでにAzure Resource Manager が利用されております。 一方、従来のAzure Service Management API を利用して自動化のためのスクリプトが構築されている場合は、このアナウンスが影響します。   Azure App Service のリソース管理は、Azure Resource Managerを介してのみサポートされるようになります。 Azure Service Management のサポートは 2018 年 6 月 30 日に廃止されます。 Service Management の API は古く、現代のクラウドにはあまり適していません。 Service Management API を利用したままでは、優れた開発者エクスペリエンスが提供できず、 プレーン スケールの操作もできなくなります。 現在Service Management APIを使用しているお客様は、Resource Managerに移行してください。 Azure Resource Managerには、堅牢な導入モデル、ロールベースのアクセス、既存の機能や新しい機能のAPIサポートなど、サービス管理に比べて多くの利点があります。 詳細については、Azure Service ManagerとAzure Resource Managerの違いを参照してください。  
認証
  Service Management では、Azure Active Directoryまたは管理証明書を使用した認証がサポートされています。 リソースマネージャの認証は、Azure Active Directoryアプリケーションと対話型ユーザーアクセスを中心に構築されています。 詳細については、Resource Manager API Authentication を参照してください。 オートメーションで管理用の証明書を使用する必要がある場合は、Authenticating to Azure Resource Manager using AAD and certificates を使用して自動化することができます。  
リソースのデプロイメント
  リソースマネージャには、宣言的なリソース記述を持つ堅牢なデプロイメントエンジンがあります。 両者のリソース デプロイメントの違いを理解するには、Resource Manager Deployment Model を参照してください。 リソースマネージャは、デプロイ用のテンプレートによるリソースのデプロイをサポートします。 また、Microsoft 2. Azure SDK for .NET 2.9以降、Visual Studioを使用したリソースの展開もサポートされています。 詳細については、Visual Studioを使用したリソースとコードの展開を参照してください。  
API の呼び出し
  Resource Manager REST APIを直接コーディングする場合は、Azure App Service REST APIのドキュメントを参照してください。 ARMClientとAzure Resource Explorerは、App Service Resource Manager API がどのようになっているのか調べるための素晴らしいツールです。 ARMClientの詳細については、ARMClient: a command line tool for the Azure API を参照してください。  
SDKとツール
  Resource Managerは、SDK やツールを多数の言語、フレームワーク、プラットフォームで提供します。 これらには、.NET、Node、Java、Ruby、Python、Go、PowerShell、Azure CLIが含まれますが、これだけではありません。 詳細なドキュメント、チュートリアル、サンプルがここにあります。  
Appサービスリソースメトリック
  自動化のためのスクリプトなどが App Service Resource Metrics API  を使用していた場合は、Azure Resource Manager Monitoring  API に切り替えることをお勧めします。 App Service 固有のメトリックAPIは引き続き提供していますが、間もなくその API を廃止にする予定です。 Resource Manager Monitoring API は、Azure 内の任意のサービス上の任意のリソースでメトリックとやりとりする共通的な方法です。 詳細については、Azure Monitor でサポートされているメトリックを参照してください。   2018 年 6 月 30 日より前に、すべての自動化ツールとデプロイメントツールを新しいAPIを使用するように移行すれば、サービスの中断を防ぎ、やAzure Resource Manager の優れたデプロイメントと管理機能の恩恵を受けるようにしましょう。   補足:
Service Management API を利用している例としては、Azure Service Management PowerShell Module 内のコマンドレットが挙げられます。 Get-AzureWebsite など、こちらに記載されております Web Apps に関連するコマンドレットは利用できなくなる可能性がございますのでご注意ください。          ]]> [API Management] 2018年6月1日に管理エンドポイントのポートが変更されます https://docs.microsoft.com/archive/blogs/jpcie/api-management-2018%E5%B9%B46%E6%9C%881%E6%97%A5%E3%81%AB%E7%AE%A1%E7%90%86%E3%82%A8%E3%83%B3%E3%83%89%E3%83%9D%E3%82%A4%E3%83%B3%E3%83%88%E3%81%AE%E3%83%9D%E3%83%BC%E3%83%88%E3%81%8C%E5%A4%89 Tue, 13 Mar 2018 13:34:26 GMT https://blogs.msdn.microsoft.com/jpcie/?p=1935 Upcoming change to management endpoint port on June 1 の翻訳です。   もし仮想ネットワーク上に API Management サービスインスタンスを展開していましたら、下記ご確認ください。   Azure Portal および PowerShell 用の管理エンドポイント向けのポートを 443 ポートから 3443 ポートに変更します。(こちらのページまたは下記の表をご覧ください。) 今回の変更はお客様が受信管理トラフィックを分離したり、受信管理トラフィックを制御できるようにするために実施されます。6月1日に、今まで管理エンドポイントで使っていた 443 ポートの利用を停止します。よって、6月1日以降も引き続き確実にサービスをご利用いただくために、NSG の受信ルールにおいて、3443 ポートへのアクセスを許可してください。 ご質問や懸念点等がありましたら API Management forum または Stack Overflow を通じてご連絡ください。   ]]>