Azure App ServiceへのAzure Storageマウント機能がGAされていたらしいのでためしてみた | DevelopersIO
いわさです。 知らなかったのですが、Azure App Service on LinuxにてAzureストレージコンテナをマウント出来るらしいです。 カスタムコンテナーでも対応しているようなので、通常のマウントと同じ感じであれば永続ストレージとして気軽に使えそうです。 少し触って確認してみました。 ためしてみた Blobコンテナーをマウント。ポータルから設定するのみで簡単 アプリ構成->パスのマッピングから、マウントの設定を行うことが出来ます。 マウント後、Web SSHでアクセスして確認してみます。 _____ / _ \ __________ _________ ____ / /_\ \___ / | \_ __ \_/ __ \ / | \/ /| | /| | \/\ ___/ \____|__ /_____ \____/ |__| \___ > \/ \/ \/ A P P S
後悔しないための Azure App Service 設計パターン (2020 年版) - しばやん雑記
Azure App Service (Web Apps) がリリースされて 6 年、情報のアップデートを行いつつ気になった情報は適当にブログに書くという日々ですが、Regional VNET Integration や Service Endpoins が使えるようになって設計に大きな変化が出るようになったのでまとめます。 最近は Microsoft で HackFest を行うことも多いのですが、App Service をこれから使い始めたいという場合に、失敗しない構成を共有したい、知ってほしいという意図もあります。多いですが中身は単純です。 基本設定 64bit Worker は必要な場合のみ利用する FTP / Web Deploy をオフにする Always on を有効化する ARR affinity をオフにする HTTP/2 の有効化を検討する Health Checks の
Overview on Web App for Containers and Azure App Service on Linux | Microsoft Azure Blog
Explore Azure Get to know Azure Discover secure, future-ready cloud solutions—on-premises, hybrid, multicloud, or at the edge Global infrastructure Learn about sustainable, trusted cloud infrastructure with more regions than any other provider Cloud economics Build your business case for the cloud with key financial and technical guidance from Azure Customer enablement Plan a clear path forward fo
Postfixで「queue file size limit exceeded」のメッセージが出た場合の対処 – Cloud Steady | パーソルプロセス＆テクノロジー株式会社
TOP > 技術FAQ > Postfixで「queue file size limit exceeded」のメッセージが出た場合の対処 「queue file size limit exceeded」はPostfixで受け取ったメールのサイズが設定値を超過していることを示しています。 Postfixのメールサイズの上限設定は下記コマンドで確認できます。 postconf -d | grep message_size_limit 設定値以上のメールデータの送信が必要な場合は、Postfixの設定変更が必要となります。 /etc/postfix/main.cf 内「message_size_limit」の値を変更します。 変更後、設定を再読み込みするためPostfixをリロードします。 変更が難しい場合は、メールデータのサイズが設定値を超えないように分割して送付する等の対応が必要です。
Azure での自動スケールの使用 - Azure Monitor
自動スケーリングを使用すると、要求量に基づいてアプリケーションまたはリソースを自動的にスケーリングできます。 自動スケーリングを使用して、過剰なプロビジョニングや不要なコストを発生させずに、アプリケーションの要求に十分に対応できるリソースをプロビジョニングします。 この記事では、Azure portal でリソースの自動スケーリング設定を構成する方法について説明します。 Azure 自動スケーリングでは、多くのリソースの種類がサポートされています。 サポートされているリソースの詳細については、サポートされているリソースの自動スケーリングに関するセクションを参照してください。 サブスクリプションの自動スケーリング設定を検出する 自動スケーリングできるリソースを確認するには、次の手順に従います。 Azure portal を開きます。 ページの上部にある検索バーを使用して、Azure Moni
Terraform を使用して Azure デプロイ スロットでインフラストラクチャをプロビジョニングする
Terraform を使用すると、クラウド インフラストラクチャの定義、プレビュー、およびデプロイを行うことができます。 Terraform を使用する際は、HCL 構文を使って構成ファイルを作成します。 HCL 構文では、Azure などのクラウド プロバイダーと、クラウド インフラストラクチャを構成する要素を指定できます。 構成ファイルを作成したら、"実行プラン" を作成します。これにより、インフラストラクチャの変更をデプロイ前にプレビューすることができます。 変更を確認したら、実行プランを適用してインフラストラクチャをデプロイします。 Azure デプロイ スロットを使用し、アプリの異なるバージョン間をスワップできます。 この機能によって、デプロイ分断の影響が最小限に抑えられます。 この記事では、GitHub と Azure を使用して 2 つのアプリをデプロイする方法を説明しながら
デプロイのベスト プラクティス - Azure App Service
開発チームごとに独自の要件があり、それによって、クラウド サービスで効率的なデプロイ パイプラインの実装が困難になる可能性があります。 この記事では、App Service へのデプロイにおける 3 つの主要なコンポーネントである、デプロイ ソース、ビルド パイプライン、およびデプロイ メカニズムについて説明します。 この記事では、特定の言語スタックのベスト プラクティスとヒントについても紹介します。 デプロイ コンポーネント デプロイ ソース デプロイ ソースは、アプリケーション コードの場所です。 運用アプリの場合、デプロイ ソースは通常、GitHub、BitBucket、Azure Repos などのバージョン管理ソフトウェアによってホストされるリポジトリです。 開発とテストのシナリオでは、デプロイ ソースはローカル コンピューター上のプロジェクトである可能性があります。 ビルド パ
Azure App Services からオンプレミスの Linux 環境へハイブリッド接続 - Qiita
概要 Azure App Service のハイブリッド接続は、Service Bus を仲介 (Relay) としてファイアウォールの後ろにあるオンプレミスのリソースに簡単に接続する便利な方法を提供します。 オンプレミス側には、ハイブリッド接続マネージャー (HCM) と呼ばれるリレーエージェントをインストールする必要がありますが、このエージェントがインストールできる環境が Windows Server 2012 以降となっているためオンプレミス側にある Linux 環境には接続できないと勘違いされている節があります。 実際には、ハイブリッド接続マネージャー (HCM) はオンプレミスのエンドポイントに対する仲介 (Relay) の役割をしており、HCM をインストールした Windows Server からエンドポイントのサービスにアクセス出来れば良い事となります。以下の構成では Wi
Azure Active Directory B2C を使って WebとAPIを保護するTips
ちょっと必要に駆られたのでメモ書きです。Azure App Service（Web Apps/Functions）には通称EasyAuth（Authentication/Authorization）という便利な機能がありますが、今のところ簡単に設定できるのはAzure ADやTwitterなどのソーシャル系のみです。 このPostではEasyAuthでAzure ADではなくAzure AD B2Cを指定して、かつフロントエンドのWeb Appsと裏側のAPIとなるFunctionsをそれぞれ保護するためのTipsを纏めておきます。 想定環境としては以下のような感じ。 認証・認可はAzure AD B2C側で行うようにWeb AppsとFunctionsのEasyAuthを構成します。 Web Appsで提供されるWebアプリはJavaScriptとかで直接Functionsに通信するけど
Azure App Service の Authentication 徹底解説
こんにちは。 Azure App Service に Built-in されている Authentication / Authorization は、簡単な認証・認可を実装したい場合、プログラム コードをいっさい変えずに対処できるため、通称「Easy Auth」とも呼ばれていて、この仕組みをより深く理解しておくと、さまざまな応用が可能になります。(例えば、Mobile App で使用している Backend にカスタム コードからアクセスする、など) そこで本投稿では、この機能を 敢えて Easy でない領域まで徹底的に解説し、理解を深めたいと思います。(よくご質問もいただくので。。。) なお、あまりこの仕組みに拘って、無理矢理、高度な使い方をする必要はありません。認証用のコードを直接組み込むなど、従来の手法でプログラミングしても 勿論 OK ですので、適材適所で活用してください。 補足
認証と権限承認 - Azure App Service
Note 2024 年 6 月 1 日より、新しく作成されたすべての App Service アプリには、名前付け規則 <app-name>-<random-hash>.<region>.azurewebsites.net で一意の既定のホスト名を作成するオプションがあります。既存のアプリの名前は変更されません。 例: myapp-ds27dh7271aah175.westus-01.azurewebsites.net 詳細については、App Service リソースの一意の既定のホスト名に関する記事を参照してください。 Azure App Service は組み込みの認証と認可の機能 (Easy Auth (簡単認証) と呼ばれることもあります) を提供するので、Web アプリ、RESTful API、モバイル バックエンド、さらには Azure Functions でも、最小限のコード
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Web Server Logs on Azure
Health Check is now Generally Available