Azureの構成をIaCしたいとなると、おおむね選択肢は次の3つになりそうです。 ARM Template Terraform Pulumi TerraformとPulumiはおおむね同じ性質ですが、PulumiはAzureに対しては他のクラウドよりも優先的に機能が入るのでちょっと面白いです。 とはいえ、世の中的にはAzureの構成はARM Templateが一番合ってるといわれるとかいわれないとか。 ARM Templateは人間が使うフォーマットじゃないので一ミリも興味がでなかったのですが、Azure BicepがDSLとして出てきたこともあり、ここしばらくはAzureでBicepを使って構成してみたので設計メモを書いておきます。 tl;dr; Bicep と ARM Template Stateless デプロイのスコープ デプロイモード デプロイによる一致保障 デプロイ方法と適用
はじめに Azure環境作ったら最初にやるべきこと（2021年版）と題して一記事書いてみたいと思います。 ※補足事項 「Azure環境作ったら最初にやるべきこと」の定義 この場では「どんなサービス／リソースを使うかに関わらず、誰もが全環境でやるべき最初のステップ」という主旨ととらえていただければと思います。 Azure環境運用していくうえで、「SQL Databaseのベストプラクティスは何？」とか「Web Appsだったらこうやって使うよね」とか細かい設定を挙げると色々あるのですが、今回は対象外。 なので、基本的には「Azureを使うすべて人」にとって意味のある記事になってるはずです。 先駆者たちの情報を探す AWSだと個人のブログもいっぱいあるし、かの有名なClassmethodさんのブログでもこういった記事がまとめられています。 初心者に優しいというか、いろんな情報が転がっていて、「
はじめに ある新サービスの環境構築中、Azure DevOpsのPipelineからApp Serviceをデプロイしたところ、 Azure SQL Databaseへの接続で Login failed for user '{ユーザー ID}'. というエラーが発生し、調査に時間を要しました。 結果として、パスワード間違いのログイン試行を繰り返したためにSQL DatabaseにApp ServiceのIPアドレスがBANされていたのですが、調査の流れについてまとめておきます。 状況 SQL Databaseの設定状況 開発期間等の関係から、ID/Passwordを使ったSQL Server認証を利用（いずれAzure Active Directory認証を利用したい・・・） [Azureサービスを許可する]をオン、追加で開発するオフィスとVPN回線のIPアドレスを許可 エラーの発生条件
ここ数年は Azure Functions をフルに活用したアプリケーションを実装することが多かったのですが、同時に Azure Functions を失敗しないように使う方法も分かってくるので、ここらでちゃんと言語化しておきます。 最近は特に Azure Light-up というハッカソンを行うことが多いのですが、Azure Functions を使う場合には必ずこの辺りは毎回説明するようにしています。要するに Azure Functions の利点・特性を理解して賢く使いこなそうという話です。 Binding / Trigger で実現出来ないか考える Function の実装は出来る限り小さく保つ リトライのしやすい実装を重視する 最新の .NET での作法に沿ったコードを書く Graceful Shutdown に対応したコードを書く 機能単位で Function App プロジェ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Azure Virtual Machine Scale Sets (VMSS) は、VM イメージからオートスケール可能な VM 群を作成し、管理してくれる便利なサービスです。 VMSS を運用していくに当たって、更新したアプリケーションを VMSS にデプロイしたい、オートスケールで新たに起動した VM で最新のアプリケーションが稼働することを保証したい、OS やミドルウェアのバージョンを定期的に更新したい、といったニーズが出てくると思います。 本記事では、こういったニーズに応えるための VMSS の更新方法について整理しま
いわさです。 結構前で、気づいていなかったのですが、 Azure App Service にて、カスタムドメインSSL証明書の無料作成機能がプレビュー提供されていましたので使ってみました。 従来であれば、自分で用意するか、以下の画面にてAzure上で購入する必要がありました。 無料って、すごい。 App Serviceインスタンスの作成 まずは、App Serviceを作ります。 FreeやSharedは対象外らしく、プランはB1にて作成しました。 作成直後はデフォルトドメインが設定されています。 デフォルトでページも作成されていて、Azure管理のSSL証明書がバインドされています。 カスタムドメインを設定 AppServiceにカスタムドメインを設定していくため、まずはDNSゾーンにCNAMEレコードを作成します。 AppServiceメニューのカスタムドメインから、カスタムドメインの
Azure の日本リージョン 7 周年の日に Japan East のストレージ障害が発生するという、なんともアレな出来事がありましたが、障害発生後はアーキテクチャを見直すいい機会だと思うので色々書きます。 まだ RCA は公開されていないですが、おそらくぶちぞう RD がブログに書くのでリンクを貼ります。 4 年前の同じような時期にも Japan East で大規模なストレージ障害が発生したので、同じようなものを書きましたが流石にいろいろと進化しているので古さを感じます。 今回の障害は影響範囲はさほど大きくなかったようで、主に Azure Storage と Virtual Machines がステータスには上がってきていました。実際には Application Insights や Log Analytics にも影響がありましたが、Azure Storage は全ての基本なので仕方な
エラー調査のために Kudu 周りを調べていたら、Wiki に Web Apps のタイムゾーン設定が追加されていたのに気が付いたので、実際に設定して試してみました。 Kudu の Wiki はちょいちょい更新されているので、ちゃんと確認しておかないといけないですね。 Configurable settings · projectkudu/kudu Wiki · GitHub 基本的に Azure のサービスは UTC がデフォルトの設定になっていて、Cloud Services では Startup Task などを使ったタイムゾーンの変更が非推奨となっていました。 But I would strongly advice against it. The Fabric Controller maintains operating system time synchronization fo
既に Azure Pipelines などを使って自動デプロイの環境を構築している場合は、ほぼ全てで Zip Deploy が使われているはずですが、App Service には FTP と Web Deploy がデプロイ方法として提供されているので、塞いでおかないと Visual Studio から手動デプロイされてしまい壊れることがあります。 まだ Visual Studio から本番環境へのデプロイを行っている場合は、速やかに自動デプロイに切り替えましょう。デプロイの安定化とパフォーマンスのために Run From Package を利用するのも良いです。 今の時代、開発中はともかく本番向けデプロイを Visual Studio から行うのは、履歴もバージョン管理も出来ないので速攻で詰みます。 そろそろ Azure Pipelines の Multi-stage pipelines
リソースに適切な名前を付けると、その種類、関連付けられたワークロード、環境、リソースが実行されている Azure リージョンをすばやく識別できます。 そのためには、名前は一貫性のある形式 ("名前付け規則") に従い、各リソースに関する重要な情報で構成される必要があります。 名前には、リソースの特定のインスタンスを識別するために必要なすべての情報が含まれていることが理想的です。 たとえば、米国西部リージョンにある運用 SharePoint ワークロードのパブリック IP アドレス (PIP) は pip-sharepoint-prod-westus-001 になります。 図 1:Azure リソース名のコンポーネント。 推奨される名前付けコンポーネント 名前付け規則を制定する場合は、リソース名で把握したい主要な情報を識別します。 リソースの種類によって関連する情報は異なり、確立されているす
Azure Kubernetes Service (AKS) は、クラスターをすばやくデプロイおよび管理することができる、マネージド Kubernetes サービスです。 この記事では、Azure CLI を使用して Windows Server コンテナーを実行する AKS クラスターをデプロイします。 また、Windows Server コンテナー内の ASP.NET サンプル アプリケーションをクラスターにデプロイします。 開始する前に このクイックスタートは、Kubernetes の基本的な概念を理解していることを前提としています。 詳細については、「Azure Kubernetes Services (AKS) における Kubernetes の中心概念」を参照してください。 Azure サブスクリプションをお持ちでない場合は、開始する前に Azure 無料アカウントを作成してく
今回はチュートリアル:Azure Kubernetes Service (AKS) でのアプリケーションのスケーリングの深堀をしていきます。 このチュートリアルでは手動および自動でのスケールを行っています。それぞれの手順で何が起きているか見ていきます。 ポッドの手動でのスケール まずはポッド数を明示的に指定した手動でのスケールです。 チュートリアルの手順 1. 現在のポッドを確認。 > kubectl get pods NAME READY STATUS RESTARTS AGE azure-vote-back-847fc9bcb9-p7m9x 1/1 Running 0 6h45m azure-vote-front-c857778b-ttlx2 1/1 Running 0 6h45m
今回はチュートリアル:Azure Kubernetes Service (AKS) でのアプリケーションの実行の深堀をしていきます。 このチュートリアルでは作成した AKS クラスタに ACR よりアプリケーションを展開して実行します。 このチュートリアルではマニフェストを適用する事しか説明していませんが、この記事ではその結果どのようなリソースが作成されるか k8s の観点からも詳しく見ていきます。 デプロイマニフェストの確認と変更 AKS に対する展開はマニフェストを k8s 渡すことで実行します。今回利用するマニフェストはサンプルの azure-vote-all-in-one-redis.yaml です。 このマニフェストは「---」で仕切られた 4 つのセクションから構成されています。 1 つ目のセクション このセクションはアプリのバックエンドである Redis の展開です。 api
今回はチュートリアル:Azure Kubernetes Service (AKS) クラスターのデプロイの深堀をしていきます。 このチュートリアルでようやく AKS を作成します。また深堀では作成したクラスタの詳細を見ることで k8s の操作についても触れていきます。 kubectl kubectl は k8s を操作する CLI ツールであり、今後のチュートリアルのメインとなるツールです。 Azure AD サービスプリンシパル AKS クラスターが他の Azure リソースと対話できるようにするために、Azure AD (Active Directory) のサービスプリンシパル作成して使用します。サービスプリンシパルはアプリケーション専用のユーザーアカウントのようなもので、各種権限の設定が柔軟に行えます。 前回作成した ACR に対するアクセスについてもサービスプリンシパルを使ってい
今回はチュートリアル:Azure Container Registry をデプロイして使用するの深堀をしていきます。 このチュートリアルでは、前回ダウンロードしたアプリケーションのイメージを作成して、レジストリに登録するところまでをやっています。 イメージとコンテナ OS などの実行環境と実行するアプリケーションを含んだものをとイメージと呼び、インスタンス化されてコンテナランタイムで実行されているものをコンテナと呼びます。コンテナというキーワードは技術全体をさす場合もあるため状況に応じて理解しましょう。 タグ イメージのバージョニングはタグで行います。タグは以下のようにイメージの後につきます。 azure-vote-front:v1 azure-vote-front:v2 azure-vote-front:latest タグを省略した場合、latest タグが自動的に付与され、最新のイメー
詳細の確認 今回は、今後作成する AKS に展開するためのアプリケーションをまずローカルにダウンロードして動かしてみるところまでの手順となっています。早速詳細を見ていきましょう。 アプリケーションの中身 ダウンロードした投票アプリは、Web フロントエンドとなる Python アプリとバックエンドとなる Redis で構成されています。 docker-compose 複数のコンテナからなるアプリケーションのビルドや実行に docker-compose が使えます。手順 2 で指定しているファイルの中身を見てみましょう。 services: 起動するコンテナ。ここでは 2 つのイメージを指定。 azure-vote-back: image として redis を指定しポート 6379 (Redis の既定) を開放。 azure-vote-front: build で azure-vote
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
