下記のサンプル実装のインフラコード部分を解説します。
https://github.com/hirokimatsueda/azure-managed-id-sample
インフラ構成詳細
Architecture
概要記事で「シンプル」と表現しましたが、構築されるリソースを明記すると若干インパクトがあるかもしれません。 しかしかなり最低限だと思いますのでどうかお付き合いを・・・。
本質的に必要なのは、中央の Functions と Cosmos DB です。
Cosmos DB の中にはデータベースやコンテナーの概念があるので、これらもインフラ構築時に作成してしまいます。
Azure のリソースは「診断設定」を設定するとリソースの状態が観測できるので、Functions と Cosmos DB に対して設定しておきます。診断ログの保管先として Log Analytics を指定しています。
Functions のアプリの状態の観測のため、Application Insights と接続しています。
Functions ではシステム割り当てマネージド ID を有効にして、Cosmos DB の権限設定でこのマネージド ID が Cosmos DB 内のデータを操作することを許可します。
terraform を用いた構築 コードはこちら: https://github.com/hirokimatsueda/azure-managed-id-sample/tree/main/infrastructure/terraform
Azure のインフラ構築には terraform を利用しています。
terraform についての説明は割愛させていただき、どのような方針で実装しているかを記載します。
module への処理の分割 terraform は、カレントディレクトリ配下（サブディレクトリを除く）の tf ファイルをすべて確認してインフラ構築をしてくれますが、リソース数が多い場合はコードの見通しが悪くなりがちです。
この時、modules という概念を使用すると処理の詳細を別フォルダに整理できるので見通しが良くなります。
マネージド ID への権限付与 下記の実装で権限付与を行っています。
https://github.com/hirokimatsueda/azure-managed-id-sample/blob/main/infrastructure/terraform/modules/cosmos_db_sql/main.tf
azurerm_cosmosdb_sql_role_definition を使用し、Cosmos DB のデータへのアクセス権限を定義します。
これはアクセス権限の定義であり、割り当てではないです。...
Azure のマネージド ID は分かれば非常に有用な概念なのですが、いざ実装するとなった場合、インフラとアプリケーションが密接に関わっていることもあってハードルが高く思うケースがあると思います。
そんな皆様のために、いつもの当たり障りのない記事ではなく、しっかり実用的に使えるコードを用意しました。
早速全体像をご紹介します。
サンプルコードの概要 コードは下記にあります。
https://github.com/hirokimatsueda/azure-managed-id-sample
何らかのデータを Functions を経由して Cosmos DB に保管・取得するアプリとインフラのコードのサンプルです。
データは少なくとも id と category の値を持つことを想定します。こんな感じで。
{ "id": "abc123", "category": "test", "data": "aaaabbbbcccc" } category は Cosmos DB 上のパーティションキーとして設定しますので、一定の法則で値が入ると良いことがありそうですね。
アーキテクチャ
Architecture
ユーザーからのリクエストを Functions で受け取り、Cosmos DB とデータのやり取りをするシンプルな構成です。
Functions の認証は Functions の webbook の API キーを利用します。
Functions から Cosmos DB にアクセスする手段は様々なものがありますが、表題の通りマネージド ID を使用を想定しています。
コードの構成 applications フォルダに Functions 上で動作する C#のアプリケーションがあり、infrastructure フォルダに Azure リソースを構築するための terraform のコードがあります。...
今年も非常に優秀な新卒入社社員の皆さんと出会えてうれしい限りです。 この季節になると、なんとなく自分の過去を振り返っているように思います。
なぜ自分はエンジニアになったか？を説明する時に、「10 歳からプログラミングを始めたから」と普段答えているのですが、3 つのパソコンとの関りが大きく関係していると思っています。
ちなみに私が小学校 1 年生くらいの時に Windows 95 が出ました。
Windows 95 のパソコン Windows 3.1 のパソコンに Windows 95 の CD-ROM でアップグレードインストールしたものです。
ブルースクリーンが頻発したりハードディスクがガリガリ音を立てたり、本当に不安定なパソコンでした。メモリは確か 8MB・・・GB じゃないですよ？
ハードディスクも 700MB くらいだった記憶があります。
メモリは後で 40MB に増設した記憶があります。
ゲームをやるくらいでしか使っていませんでしたが、Windows という、その後爆発的に普及する OS に幼少期から触れられたのは大きいです。
NEC PC9801（たぶん） こちらは CLI ベースで動くパソコンですね。
フロッピーディスクでアプリケーションを読み込んだりして使えるものです。
このパソコンで父が趣味でオセロのプログラムを書いていて、そのソースコードの LINE 文を書き替えたら、オセロの盤面の線が斜めになったのが、プログラミングを始める本当の最初の点だと思います。
これが無ければプログラミングは始めていなかったと思います。
当時このパソコンが大好きでした。
画面全体の表示を全て制御できるので、パソコンを全部コントロールしているような感覚になりました。
高専の入試面接のときに「OS を作れるようになりたいです」などと無謀なことを言ったのもこちらがきっかけです。 （結局 OS の開発には１ミリも手を出しませんでした・・・）
SHARP MZ-731（たぶん） こちらは機械語で動くパソコンです。
祖父がパソコンを勉強するために購入したと聞いています。
家庭用テレビに繋ぐと画面表示ができて、メモリが確か 64KB、ハードディスクは無く、カセットテープでデータの読み書きができました。
例えば 3 分くらいかけてカセットテープを読み込ませると BASIC が使えるようになります。
私個人としてはあんまり活用していなかったですが、メモリ空間の一部がディスプレイの表示に繋がっていて間違えて書き換えると画面の色が変わったりとか、マシンが「暴走」して応答しなくなるとかを経験して、純粋にコンピュータがどういうものかを理解することに役立ったと思います。
まとめ メモリ容量とか具体的な数字で覚えているのが怖いですね。
その後、パソコンは買い替えられて Windows Me とインターネット接続を手に入れ、Visual Basic 6....
Static Web Apps はお手軽に静的な Web サイトを提供するだけでなく、API もデプロイできます。
API をデプロイした場合、Azure の他のリソースにアクセスする処理が必要なケースが多いと思います。
API から他のリソースにアクセスするには接続情報を環境変数に持たせる手もありますが、マネージド ID を使用するとより安全でスマートなコードが組めるので良いですよね。
Static Web Apps の API は 2 種類 Static Web Apps の API は マネージド関数 と 独自の関数 の使用という 2 つの構成が存在します。 マネージド関数の方がお手軽に使えますが、下記の表にあるようにマネージド ID（現状の和訳だと「管理対象 ID」になっている）が使えません。
https://docs.microsoft.com/ja-jp/azure/static-web-apps/apis
このため、 独自の関数の使用 を選択する必要があります。
・・・とキレイに書いてみましたが、実際はこの仕様を知らず、Static Web Apps のマネージド ID を有効化して IAM 設定をして「動かないなぁ。。」と悩んでいました。 マネージド関数でマネージド ID を使おうとして、169.254.169.254:80 にアクセスできない旨のエラーを見て気づきました。 上記 IP アドレスは下記のドキュメント等に登場しますが、Azure に対する何らかの問い合わせに使われる IP アドレスです。
https://docs.microsoft.com/ja-jp/azure/active-directory/managed-identities-azure-resources/how-to-use-vm-token
独自の関数の使用 下記のドキュメントを参考に、Azure ポータルからポチポチ設定すれば連携できます。
https://docs.microsoft.com/ja-jp/azure/static-web-apps/functions-bring-your-own
ドキュメントを見なくてもできちゃうくらい簡単です。 まずはマネージド ID を有効化した Functions を用意し、その後 Static Web Apps の「関数」のところからリンクすれば OK です。...
Static Web Apps (静的 Web アプリ) って便利ですよね！ 単品のリソース構築で、CDN、Web サーバー、API サーバー、カスタムドメイン with HTTPS、アプリの自動デプロイが一気に実現できるので、これからどんどん活用したいです。
ただ私はまだ慣れていないので、アプリを検証用の GitHub リポジトリで用意してインフラを作り、後から参照する GitHub リポジトリを差し替えたくなりました。 その手順が簡単に分からなかったので、本記事で整理したいと思います。
概要 az staticwebapp disconnect してから az staticwebapp update しましょう。
手順 Azure CLI で対応できました。 まずはいつも通り、Azure CLI で Azure にログインします。
az login -t tenant-id az account set -s subscription-id 続いて、az staticwebapp disconnect を使用して Static Web Apps を GitHub リポジトリから切断します。
az staticwebapp disconnect --name static-web-app-name この状態で Azure ポータルから Static Web Apps の概要画面を眺めると、確かに GitHub リポジトリとの関連が無くなっていることが分かります。
最後に az staticwebapp update を実行して、目的の GitHub リポジトリと接続してあげましょう。 GitHub の Personal Access Token が必要です。 (記事執筆時点では –login-with-github のオプションは指定できませんでした)...
AKS(Azure Kubernetes Services)は簡単な設定を入れるだけでクラスタのオートスケールが可能で便利ですが、あまり詳細なコントロールができない認識です。
OpenShift だとマニフェストファイルでオートスケールを調整できるように見えるので、ちょっと調べてみました。
OpenShift 環境の構築トライ 実物を知らずして進めるのも良くないと思い、構築の方もトライしました。
色々試したポイントとして、OpenShift の 4 系は VM サイズが最低でも D8s_v3、最低 4 台立つようなので、サブスクリプションのクォータの調整をしてから対応を進めましょう。オートスケールを踏まえると、「Standard DSv3 ファミリ vCPUs」を 48 以上くらいにしておきたいです。「リージョンの vCPU の合計」の方もご確認を。
サブスクリプションの準備が整ったら下記 URL の記事に従い、OpenShift 環境を構築します。
https://docs.microsoft.com/ja-jp/azure/openshift/tutorial-create-cluster
手順内で（省略可能）となっている部分については今回は省略してみました。
クラスターが作成されるまでに通常約 35 分かかります。とのことです。気長に待ちましょう。
下記を見るとクラスタへの接続方法が確認できます。
https://docs.microsoft.com/ja-jp/azure/openshift/tutorial-connect-cluster#connect-to-the-cluster
いろいろなビューがあって便利そうなので、こちらの画面も見つつ、ドキュメントを追ってみることにします。
ClusterAutoscaler の設定確認 下記を参考に、ClusterAutoscaler の設定を見てみます。
https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.8/html/machine_management/configuring-clusterautoscaler
コマンドで設定する手順になっていますが、クラスターコンソールの「管理」→「クラスター設定」から、「Cluster Autoscaler」のところで設定することもできそうです。
GPU ノードはお財布が辛いので、例えばこれくらいですかね？
apiVersion: "autoscaling.openshift.io/v1" kind: "ClusterAutoscaler" metadata: name: "default" spec: podPriorityThreshold: -10 resourceLimits: maxNodesTotal: 24 cores: min: 8 max: 128 memory: min: 4 max: 256 scaleDown: enabled: true delayAfterAdd: 10m delayAfterDelete: 5m delayAfterFailure: 30s unneededTime: 60s resourceLimits で記載している値は AKS でも設定できなく無いかなと思うのですが、scaleDown の定義は気になりますね。...
マネージド ID というものを使うと、サービスプリンシパルを用意せずに Azure リソースから Azure リソースの操作を実施することができます。 Runbook を用いてプライベート DNS ゾーンの操作を自動化を実施することを想定してその手順を用意してみました。 料金的にもリーズナブルで、すべて Azure ポータル上の作業で完結するので、一度やってみましょう。
操作対象のリソース（プライベート DNS ゾーン）の用意 Azure ポータルから DNS ゾーンを作成します。 DNS ゾーンの名前は private.example.com 、リソースグループ名は blog で作成してみました。
Screenshot
このまま VNET に接続しなければ宝の持ち腐れですが、今回は説明用ということで。
Runbook の用意 Azure ポータルから Automation アカウントを作成します。 名前は blogaccount とか、任意で大丈夫です。
作成時に詳細設定でマネージド ID の設定ができるので、デフォルトの通り「システム割り当て」をオンにしておいてください。 （Automation アカウントの作成後、アカウント設定 – ID から、システム割り当てマネージド ID を「オン」にしても大丈夫です）
Screenshot
Automation アカウントが作成されたら、Automation アカウントのポータル画面から プロセス オートメーション – Runbook を開き、＋ Runbook を作成を選択します。
Runbook の種類に PowerShell を選び、ランタイムバージョンは 5....
Kubernetes をやり始めたころ、登場する言葉の多さに絶望したことを覚えています。 特にこの「Taint」はびっくりしました、「汚す」ってどういうこと？ ちょっと解説してみます。
ノードを汚すという行為 kubectl taint のようなコマンドを使うと、ノードに Taint をつける、つまりノードを汚すことになります。
なんだかネガティブな感じですよね。
ここで大事なことは、「Pod はキレイ好き！」ということです。
Taint が設定されたノードでは、普通の Pod は「こんな汚い場所で立ち上がりたくない！」となります。
Taint を活用するコマンドで
kubectl drain というのがありますが、これを使うと Taint の作用等により Pod をノードから安全に追い出すことができ、ノードのメンテナンスが可能な状態になります。
汚れを許容する Toleration 通常の Pod は完璧主義というか、あらゆる Taint を拒否します（たぶん）。
でも、いつもすべてを清潔に保てるとは限りませんよね、例えば家の窓の掃除は結構妥協してたり・・・
こういう、一部の Taint は気にしない、といった振る舞いを Pod にさせるために Toleration という概念があります。
例えば Windows コンテナの Pod は Windows のノードでしか起動できないので、ノードに Windows 限定にする Taint をつけておき、Windows の Pod で Toleration を設定すれば良いことがありそうですね。
（急にニッチな話題に・・・）
まとめ 詳しいコマンドは解説しませんでしたが、「Taint」という概念については「Pod はキレイ好きだから汚れた場所にはいきたくない」という性格を覚えておくと、関連するドキュメントが一気に読みやすくなります。
是非覚えておいてください。
Azure にはクォータ上限という概念があり、リソース作成はクォータ範囲内でしかできず、ただしクォータ上限の引き上げが要求が可能です。
vCPU に関しては上限の引き上げが可能ですが、上限の引き上げが不可能なリソースも存在します。
CDN プロファイルは上限の引き上げが不可能 CDN プロファイルは、サブスクリプション単位に 25 個までしか作成できません。
https://docs.microsoft.com/ja-jp/azure/azure-resource-manager/management/azure-subscription-service-limits#content-delivery-network-limits
クォータ上限の引き上げを要求したところ、上限増加はサポートされていないとのことでした。 1 つの CDN プロファイルに複数の CDN エンドポイントを作成可能なので、CDN エンドポイントを大量に作成する場合は計画的に設計する必要があります。
1 つの CDN プロファイルに含められる CDN エンドポイントの数は 25 となっているので、大規模な仕組みを作る際はこちらも注意が必要です。
まとめ 大規模な Azure インフラを構築する際は、クォータ上限の引き上げが可能かの確認も含め、クォータ上限に関する設計が必要です。 特に同一サブスクリプションに動的にリソースを作成する場合、リソースのスケールアウトを大幅に計画する場合は要注意です。 必要に応じてサブスクリプションを分割するなどして対応しましょう。
最近はスクリプト言語を使う時に何を使うのが良いか迷います。
いや、もともと大して選んでいないんですが、Azure 関連の操作がメインだったので PowerShell をよく使っています。
PowerShell は C#っぽく書けるので悪くないんですが、改めて、OS 関係なく軽快に動いてくれる言語として go に注目しています。
プログラミングのリハビリを兼ねて go で Grafana を扱うコードを書いていたんですが、json を扱うところで苦労したのでノウハウをメモしておこうと思います。
encoding/json を使用する場合のお話になります。
1. 礼儀正しく扱う json の構造をすべて把握している場合は、その構造を表現した type を宣言し、json.Unmarshal で変換された値を突っ込むことができます。
一部定義するだけでも良いようです。
例えば Grafana で GET /api/search/ を実行した結果の json を処理したい場合を考えます。
https://grafana.com/docs/grafana/latest/http_api/folder_dashboard_search/
得られる json には、id、uid、title、・・・といくつかの値が得られますが、例えばその中で title と uid の値だけ拾いたいときは下記のような感じです。
package main import ( "encoding/json" "fmt" "log" ) type DashboardOverview struct { Title string `json:"title"` Uid string `json:"uid"` } func main() { dashboardJson := 【Grafanaからjsonを取得する処理】 var dashboards []DashboardOverview if err := json....