Azure

Azure Active Directoryで認証するJavaアプリケーションが作れるライブラリ「Spring Cloud Azure」を紹介 はじめに Azureでは「Azure Active Directory (Azure AD) 」とJavaライブラリ「Spring Cloud Azure」を使うことで、Azure ADに登録されているユーザで認証を行うWEBアプリケーションの作成を行うことができます。 この記事では「Spring Cloud Azure」について紹介します。 Spring Cloud Azure Springは、VMwareが開発したJava言語のWEBアプリケーション開発に必要な機能を提供するフレームワークです。 Spring Cloud Azureは、AzureのサービスとSpringのシームレスな統合を提供するオープンソースプロジェクトです。 https://microsoft.github.io/spring-cloud-azure/current/reference/html/index.html#spring-security-support https://docs.microsoft.com/ja-jp/azure/active-directory/develop/quickstart-register-app Spring Cloud AzureでのAD認証 Spring FramworkにはSpring Securityというログイン認証やCSRF対策をフレームワークが含まれています。 Spring Cloud AzureではAzure用に拡張されたSpring SecutiryでOAuth2.0での認証を行います。 以下にAD認証のシーケンスを記載しています。 https://microsoft.github.io/spring-cloud-azure/current/reference/html/index.html#spring-security-support https://spring.pleiades.io/spring-security/site/docs/current/api/org/springframework/security/config/annotation/web/builders/HttpSecurity.html Azure ADへのアプリケーション登録 WEBアプリケーションでAzure ADでの認証を行うには、AzureポータルでAzure ADに対象のアプリケーションの登録と、クライアントシークレットの作成を行います。 アプリケーション登録 Azure ADメニューからAzure ADを選択します。 表示名 : 任意のアプリケーション名を入力 サポートされているアカウントの種類 : 今回は任意の組織ディレクトリ内のアカウントを選択します リダイレクトURI : 省略可能。省略した場合は https://WEBアプリホスト名/login/oauth2/code/azure になります クライアントシークレット登録 Azure ADに登録したアプリの「証明書とシークレット」からクライアントシークレットを追加します。 説明 : 任意 有効期間 : 今回は2年を設定します 作成されたクライアントシークレットの値を控えます。(※再表示はできません) その後、クライアントID(アプリケーションID)および、テナントIDを確認し、控えます。

AzureのOCRサービス「Azure Form Recognizer」入門 はじめに Azureには、Azure Cognitive ServicesとAI機能をWeb APIして提供するサービスがあります。　本記事では、Azure Cognitive Servicesのうち、OCRサービス「Azure Form Recognizer」の使い方について紹介します。　Azure Cognitive Servicesとは Azure Cognitive Servicesは、視覚、音声、言語、決定、検索の5ジャンルからなるAI機能をWeb APIとして利用できるAzureのサービスです。 https://azure.microsoft.com/ja-jp/services/cognitive-services/#overview Azure Form Recognizerとは 請求書、レシート、名刺などのドキュメントから文字情報を取得するAzure Cognitive ServicesのOCR機能の一つです。 Azure Form RecognizerのAPIを実行すると、リクエスト時で渡されたPDFファイルなどのドキュメントのURLを解析し、 解析したテキスト情報をHTTPレスポンスとして返します。 https://docs.microsoft.com/ja-jp/azure/applied-ai-services/form-recognizer/ もう一つのOCRサービス「Azure Computer Vision」 Azure Cognitive ServicesのOCRサービスには、Computer Visionというものもあります。 Computer Visonは画像やビデオのコンテンツを分析するAIサービスです。 こちらもOCRの機能がありますが、画像内のオブジェクトの検出、画像の説明の生成、顔認識などOCR以外にも、画像に対してより幅広いことができます。 PDFファイルの上の表にあるテキストの取得や、指定したテキストを取得したい場合は、Azure Form Recognizerの方が適しています。 https://stackoverflow.com/questions/71071309/ai-form-recognizer-vs-cognitiveservices-computervision https://azure.microsoft.com/ja-jp/services/cognitive-services/computer-vision/#overview https://www.alirookie.com/post/azure-ocr-with-pdf-files Azure Form Recognizerの機能 Azure Form Recognizerは、機能で、次のサービスで構成されています。 Layout API 事前構築済みモデル カスタムモデル Layout API Azure Form RecognizerのAPIを実行することで、ドキュメントから、テキストや、テーブルの構造、テキスト、バウンディングボックスの座標と共にドキュメントから抽出します。 事前構築済みモデル(Prebuilt Model) 事前構築済みモデルは請求書、レシート、名刺などMicrosoftが事前に用意している特定のドキュメント専用のAIモデルを使用して、フォームを解析する機能です。 カスタムモデル カスタムモデルは、ユーザが独自に作成することができるAIモデルです。

はじめに Azure Functionsには、同時に利用できるTCPソケット数に上限数が設定されています。 そのため、同時利用するソケット数を抑えるようにアプリを実装していないと、処理量が増えた際に、 ソケットが枯渇してしまう可能性があります。 この記事では、Functionsが利用しているソケット数をモニタリングする方法を紹介します。 Functionsのソケット数の上限 従量課金プランのFunctionsの場合、送信接続数は、インスタンスあたり600アクティブに設定されています。 上記のように同時接続数に上限があるので、Functionsアプリケーションを開発する際は、 利用後終わったソケットは開き放しにせずに、すぐにクローズするなどベストプラクティスに基づいた実装が必要です。 https://docs.microsoft.com/ja-jp/azure/azure-functions/manage-connections?tabs=csharp https://docs.microsoft.com/ja-jp/azure/azure-functions/functions-best-practices Functionsのソケット数をモニタリング ソケット数は、Azureポータルを使って、Functionsの診断設定や、Azure Monitorのメトリックからモニタリングできます。 取得できる接続数として、以下の2つがあります。 Connections : Functionsごとの接続するの瞬間値 TCP Established ： 仮想マシン単位(App Service Plan)の瞬間値 Connections Connections Azure Monitor の Connectionsから取得できる項目です。 Functionsの関数アプリが利用している接続数をモニタリングできます。 TCP Established App Service Planの接続上限を超過する可能性がございます。 https://docs.microsoft.com/ja-jp/azure/azure-functions/functions-monitoring おわりに 本記事ではAzure Functionsでの同時に利用できるTCPソケット数をモニタリングする方法を紹介しました。 I

Azure FunctionsにLog4Jの脆弱性の暫定対策を実施 はじめに 2021年12月10日に発覚したJavaのログ出力ライブラリ「Apache Log4j」にて、深刻な脆弱性「CVE-2021-44228」があることが発覚しています。 https://milestone-of-se.nesuke.com/sv-advanced/sv-security/cve-2021-44228-log4shell-logjam/ 上記について、暫定的な回避策として、以下の2点が公開されています。 Log4j バージョン 2.10 およびそれ以降 Log4j を実行する Java 仮想マシンを起動時に「log4j2.formatMsgNoLookups」という JVM フラグオプションを指定する 環境変数「LOG4J_FORMAT_MSG_NO_LOOKUPS」を「true」に設定する Log4j バージョン2.10 より前 JndiLookup クラスをクラスパスから削除する https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/ 通常の物理サーバまたは、仮想サーバ上でJavaアプリケーションを動作させているケースと違い、 サーバレスのAzure Functionsの場合、どのように設定すればいいのか分からないという方もいるかと思われます。 本記事では、Azure Functions に対して、上記の1.Log4j バージョン 2.10 およびそれ以降への回避策を設定する方法を紹介します。 Azure Functionsのアプリケーション設定に環境変数を追加 Azure Functionsには、アプリケーション設定という、Functions内で利用することができる環境変数を定義することができる項目があります。 以下のAzure CLIコマンドを実行することで、Azure Functionsのアプリケーション設定に変数を追加することができます。 az webapp config appsettings set -g "リソースグループ名" -n "関数アプリ名" --settings JAVA_OPTS='-Dlog4j2.formatMsgNoLookups=true' az webapp config appsettings set -g "リソースグループ名" -n "関数アプリ名" --settings LOG4J_FORMAT_MSG_NO_LOOKUPS='true' おわりに 本記事では、Azure FunctionsにLog4Jの脆弱性の暫定対策を設定する方法を紹介しました、

Service Bus Queues Triggerのメッセージ処理順がFIFOにならない事 はじめに Service Bus Queues Triggerを用いたAzure Functionsにおいて、メッセージ処理順がキューに送信された順番にならず、FIFOにならないケースがあります。 本記事では、Service Bus Queues Triggerのメッセージ処理順がFIFOにならない事象と対策について、ご紹介します。 Service Bus Queues Triggerのメッセージ処理順がFIFOにならない原因 Service Bus TriggerのFunctionsはPeek&LockというモードでService Busからのメッセージの受信とロックを行います。 https://docs.microsoft.com/ja-jp/azure/service-bus-messaging/message-transfers-locks-settlement#peeklock Service Busを利用していると際に、Service BusとFunctionsからのネットワークが切断されたりすると、 Message processing errorというエラーログが出力されます。 https://stackoverflow.com/questions/65999984/azure-function-v3-net-core-3-1-servicebustrigger-message-processing-error-act Peek&Lockモードの場合、特定のスレッド/プロセスにて受信対象のメッセージのロック中に Message processing errorが発生すると、次回起動時に当該メッセージがロックされたままになっているために、後続のメッセージを先に受信してしまいます。 Service Busのセッションを用いた対策 上記のケースへの対応として、Service Busにはセッションという機能があります。 https://devblogs.microsoft.com/premier-developer/ordering-messages-in-azure-service-bus/ https://docs.microsoft.com/ja-jp/azure/service-bus-messaging/message-sessions 上記のドキュメントの内容を要約すると、以下のような挙動になるものと思われます。 Service Busのキューを作成する際に、セッションを有効にして作成すると、送信側はメッセージをキューに挿入する際に、セッションIDを付与することが可能になります。 受信側のFunctionsでService Bus Triggerの属性 IsSessionsEnabled を有効にすると、セッションが付与されたメッセージを受信することが可能になります。 https://docs.microsoft.com/ja-jp/azure/azure-functions/functions-bindings-service-bus-trigger?tabs=csharp#configuration セッションを有効にするとFunctionsはメッセージ受信時に、セッションIDが同じメッセージを全て、排他ロックします。 Message processing error などエラーが発生した場合は、メッセージのロックを解除して、同じメッセージを受信するため、FIFOを維持することができます。 おわりに この記事では、Service Bus Queues Triggerのメッセージ処理順がFIFOにならない事象と対策について、ご紹介しました。 Azureの各サービスは、多数のオプションが用意されているので、要件に応じて、適切なオプションを設定するようにしましょう。 本サイトへのご意見、お問い合わせなどありましたらこちらからご連絡下さい。 お問合せフォーム I

はじめに 以下のフォーラムの投稿にあるようにAzure Functions(Windows OS)でSDKに用意されているAzure SDK標準のロガーを使用せずに、日本語文字を標準出力するとApplication Insightで文字化けする事象が発生するケースがしたので、本記事では原因について、紹介します。 https://social.msdn.microsoft.com/Forums/ja-JP/9febb20c-f348-4554-af11-93f5dcfb587f/azure?forum=windowsazureja 文字化けの原因 日本語環境に設定された Windows OSの場合では MS932 (Shift-JIS の一種) という文字コードが使われます。 Azure 上では CP1252というラテン文字用のエンコーディングが使われますが、CP1252では日本語が表現できないため、文字化けしてしまいます。 また、AzureポータルのFunctionsの[Debug Console] 、Application Insightsは Shift JIS での表示に対応していないため、日本語をログ出力すると、文字化けしてしまうことになります。

Azure DevOpsのパイプラインからAppServiceへのデプロイ はじめに 本記事では、マイクロソフトから提供されているサンプルWebアプリケーションを使って，Azure DevOpsでのリポジトリの作成～パイプラインの作成からAppServiceの デプロイを行うまでの一連の操作を記載する。 AppServiceにWebアプリケーションを作成 以下の手順で、Webアプリケーションを作成。 DebOpsで組織を作成 DevOps用のプロジェクトの作成 リポジトリの作成 サービスコネクションを作成 サンプルプログラムを取得。 以下のサイトから、サンプルプログラムを取得してZIPダウンロードする。 先程クローンしたローカルリポジトリに展開する。 https://github.com/MicrosoftDocs/pipelines-java コミットを行い、その後リモートリポジトリにPushする。 $ git add . $ git commit -m "Sample WebAppを追加" $ git push パイプラインYAML作成 以下のパイプラインを作成する。 trigger: - master variables: # Azure Resource Manager connection created during pipeline creation azureSubscription: '作成したサービスコネクション名を指定' # Web app Type webAppType : 'webAppLinux' # Web app name webAppName: 'sample-web-application' # Environment name environmentName: 'sample-enviroment' # Agent VM image name vmImageName: 'ubuntu-latest' stages: - stage: Build displayName: 'Build stage' jobs: - job: Debug displayName: 'Show debug message' steps: - script: | echo "Subscription : $(azureSubscription)" echo "Web App Name : $(webAppName)" echo "Environment Name : $(environmentName)" echo "Vm Image Name : $(vmImageName)" echo "Pipeline Workspace Name : $(Pipeline.

Azure Shared Access Signatureのクエリパラメータまとめ はじめに 本記事では、Azure Storageへのアクセス権を付与されたURI(トークン)を発行するShared Access Signature (SAS) において利用される、クエリパラメータについてまとめた。 SASトークンのクエリパラメータ SASトークンに設定できるクエリパラメータは以下になる。 クエリ文字 名称 内容 設定例 備考 sv SignedVersion SAS認証のバージョン sv=2019-02-02 srt SignedResourceType 認可するリソース(アカウント SAS) srt=sco s : サービスレベルのapi c : コンテナーレベルのapi o : オブジェクトレベルのapi sr SignedResource 認可するリソース(サービス SAS) sr=bc b : Blob bs : Blob スナップショット c : コンテナー ss SignedService 認可するサービス(アカウント SASのみ) ss=bqtf b : Blob q : キュー t : テーブル f : ファイル sp SignedPermissions 認可する権限 sp=racwd 認可するサービスごとに、認可できる権限がそれぞれ用意されている spr SignedProtocol 認可するプロトコル spr=https sip SignedIP 認可するIP アドレス sip=168.

Azure Administrator対策「Azure PowerShellの命名規約」 はじめに AZ-103「Azure Administrator」対策として、Azure PowerShellの 各コマンドを記憶しやすくするため、Azure PowerShellの命名規約を記載する。 Azure PowerShellの命名規 https://docs.microsoft.com/ja-jp/powershell/scripting/developer/cmdlet/approved-verbs-for-windows-powershell-commands?view=powershell-7 類似の動詞 NewとSetとUpdate New 新しいリソースを作成するために使用。 # 仮想マシンを作成 New-AzVm ` -ResourceGroupName "myResourceGroup" ` -Name "myVM" ` -Location "East US" ` -VirtualNetworkName "myVnet" ` -SubnetName "mySubnet" ` -SecurityGroupName "myNetworkSecurityGroup" ` -PublicIpAddressName "myPublicIpAddress" ` -OpenPorts 80,3389 Set 対象のリソースが存在しない場合にリソースを作成、 また、既存のリソースを変更するために使用される # VMを一般化(マシンとユーザーの固有の情報を VM から削除する) Set-AzVM -ResourceGroupName "ResourceGroup11" -Name "VirtualMachine07" -Generalized Update 仮想マシンの状態を最新化する。

Azure Administrator対策「オンプレミスのデータの取り込み」 はじめに AZ-103「Azure Administrator」対策として、Microsoft Learnなどを要約したものを記載。 Azure Import/Export 物理ディスクドライブから、Azure Blob Storage と Azure Filesに大量のデータをインポートすることができるサービス。 Azureデータセンターにデータをコピーした物理ディスクドライブを送付することで、インポートが行われる。 逆にAzure Blob Storageから物理ディスクにデータを転送し、オンプレミスの拠点に送付することでエクスポートを行うことも可能。 Microsoft 提供のディスク ドライブを使用してデータを転送する場合は、Azure Data Box Diskを使用してデータをAzureにインポート。 https://docs.microsoft.com/ja-jp/azure/storage/common/storage-import-export-service#how-does-importexport-work ディスクドライブ ソリッドステートドライブ (SSD) またはハードディスクドライブ (HDD)に対応。 https://docs.microsoft.com/ja-jp/azure/storage/common/storage-import-export-requirements#supported-hardware 構成 以下の2つの機能が用意されている。 Import/Exportサービス Azure Portalからインポートジョブとエクスポートジョブを作成するGUIツール。 WAImportExportツール インポート、エクスポートを支援するコマンドラインツール。 以下の機能を提供する。 ディスクドライブの配送準備 データをドライブにコピーする ドライブ上のデータを暗号化 インポート作成中に使用されるドライブのジャーナルファイルを生成 エクスポートジョブに必要なドライブの数を特定 データセットCSV インポート、エクスポート対象のファイル、ディレクトリの一覧と、インポート、エクスポート設定を記載したCSVファイル。 https://docs.microsoft.com/ja-jp/previous-versions/azure/storage/common/storage-import-export-tool-preparing-hard-drives-import ジョブ Import/Exportサービスを利用にする場合、‘ Azure Portalなどでインポート、エクスポートジョブを作成する必要がある。 各ジョブは、1つのストレージアカウントに関連付けられる。 インポートジョブ Azure Blobsまたは Azure Filesにデータをインポートするためのジョブ。 手順は以下の通り。 インポートするデータ、必要ドライブ数、インポート先のBlobの場所を決定 WAImportExportツールで、データをディスクドライブにコピー