Azureお父さん必見!赤ちゃんのうんち記録アプリで子育てをDX!?

※ この記事は、cloud.config Tech Blog にもマルチポストする予定です

子供が産まれて妻子の入院期間中、体温や授乳回数やおしっこ・うんちの時間を記録する紙があって、そこに毎日記録していました。

退院後もそのフォーマットを Excel で真似て紙に印刷して使っていて、子供の不調が無いか確認していました。

子供が 1 歳になった今も一応、記録内容を減らした紙を運用してはいるものの、ほとんど問題ないのであまり書いていないです。

ただその中で、絶対書いておきたいのが、

うんちの記録です!

便秘だと不機嫌になったり場合によっては病院に行かないといけなくなります。

うちの子は最近は割と快便ですが、最初の頃は便秘でとても心配しました。

また、うんちがあまり出ていない状態でお風呂に入ると・・・ね。。

ということで、うんちの回数を記録するアプリを書いてみましたのでご紹介です。

/baby-info-recording-system/001.png

Screen shot

アプリの概要

カレンダーの中の「+」ボタンを押すと、当日の枠に 💩 マークがつきます。

データは Cosmos DB に保管されます。

アプリコード

Visual Studio 2022 で作成しました。GitHub で見れるようにしています。

https://github.com/hirokimatsueda/baby-info-recording-system

フロントアプリの実装は大目に見てください。。

フロントの作りが微妙ですが・・・赤ちゃん ID を変更すると別々のデータを管理できるので、双子や兄弟のデータも扱えます。

アーキテクチャ概要

インフラとしては Azure の Static Web Apps での動作を想定し、情報を CosmosDB に保存するので、比較的安価に運用できるものになっています。

アプリは ASP.NET Core Blazor での記述です。

インフラもアプリも、ベースとなる考え方は以前ブログでご紹介した下記のコードです。 https://github.com/hirokimatsueda/azure-managed-id-sample

インフラ構築

Api は Static Web Apps のデフォルトの機能で動かすと Managed ID が使えないため、Static Web Apps とは別で構築した Functions を Static Web Apps にリンクする形を取るのがポイントです。

[Read More]

実用性重視!AzureのマネージドID活用のサンプルコード(アプリコード)

下記のサンプル実装のアプリコード部分を解説します。

https://github.com/hirokimatsueda/azure-managed-id-sample

アプリ処理詳細

コードはこちら: https://github.com/hirokimatsueda/azure-managed-id-sample/blob/main/applications/DataApis

詳細と言うほどのものではないですが・・・。

GetData

リクエストパラメータから idcategory を読み取って、対象のデータを Cosmos DB から取得し返却します。

PutData

リクエストボディのデータを Cosmos DB に Upsert します。

実装のポイント

マネージド ID という観点で言うと、CosmosClient に渡すクレデンシャル情報に new DefaultAzureCredential() を指定するくらいです。

private static CosmosClient InitializeCosmosClient()
{
    return new CosmosClient(Environment.GetEnvironmentVariable("COSMOS_ENDPOINT", EnvironmentVariableTarget.Process), new DefaultAzureCredential());
}

これにより Functions 上ではマネージド ID のクレデンシャルが使用されます。

ローカル PC 上で実行する場合は、ローカル PC 上の認証情報を使用してくれるので、例えば az login したユーザーが Cosmos DB のデータへのアクセス権限を持っていればローカル PC でデバッグが可能です。

ほかのポイントとしては、CosmosClient をメソッド呼び出し時に生成するのではなく Static 変数として持っておき、Lazy クラスを活用した初期化を実施しています。

private static Lazy<CosmosClient> lazyClient = new Lazy<CosmosClient>(InitializeCosmosClient);

これにより CosmosClient の初期化というコストの高い処理回数を削減しています。

まとめ

アプリ開発のポイントを整理しました。

[Read More]

実用性重視!AzureのマネージドID活用のサンプルコード(インフラコード)

下記のサンプル実装のインフラコード部分を解説します。

https://github.com/hirokimatsueda/azure-managed-id-sample

インフラ構成詳細

/azure-managed-id-sample-infrastructure/001.png

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 のデータへのアクセス権限を定義します。

これはアクセス権限の定義であり、割り当てではないです。

割り当てには azurerm_cosmosdb_sql_role_assignment を使用しています。

サンプルコードでは 2 回登場しますが、userと名付けた方は terraform を実行した人への権限付与、data_contributorと名付けた方は Functions への権限不要になります。

[Read More]

実用性重視!AzureのマネージドID活用のサンプルコード(概要)

Azure のマネージド ID は分かれば非常に有用な概念なのですが、いざ実装するとなった場合、インフラとアプリケーションが密接に関わっていることもあってハードルが高く思うケースがあると思います。

そんな皆様のために、いつもの当たり障りのない記事ではなく、しっかり実用的に使えるコードを用意しました。

早速全体像をご紹介します。

サンプルコードの概要

コードは下記にあります。

https://github.com/hirokimatsueda/azure-managed-id-sample

何らかのデータを Functions を経由して Cosmos DB に保管・取得するアプリとインフラのコードのサンプルです。

データは少なくとも id と category の値を持つことを想定します。こんな感じで。

{
  "id": "abc123",
  "category": "test",
  "data": "aaaabbbbcccc"
}

category は Cosmos DB 上のパーティションキーとして設定しますので、一定の法則で値が入ると良いことがありそうですね。

アーキテクチャ

/azure-managed-id-sample-summary/001.png

Architecture

ユーザーからのリクエストを Functions で受け取り、Cosmos DB とデータのやり取りをするシンプルな構成です。

Functions の認証は Functions の webbook の API キーを利用します。

Functions から Cosmos DB にアクセスする手段は様々なものがありますが、表題の通りマネージド ID を使用を想定しています。

コードの構成

applications フォルダに Functions 上で動作する C#のアプリケーションがあり、infrastructure フォルダに Azure リソースを構築するための terraform のコードがあります。

infrastructure フォルダの terraform を実行して Azure 上に Functions と Cosmos DB、その他関連リソースを作成した後、applications フォルダのアプリを Functions にデプロイすればアプリにアクセス可能になります。

[Read More]

マネージドIDを使用してRunbookからAzureリソースを操作する

マネージド ID というものを使うと、サービスプリンシパルを用意せずに Azure リソースから Azure リソースの操作を実施することができます。 Runbook を用いてプライベート DNS ゾーンの操作を自動化を実施することを想定してその手順を用意してみました。 料金的にもリーズナブルで、すべて Azure ポータル上の作業で完結するので、一度やってみましょう。

操作対象のリソース(プライベート DNS ゾーン)の用意

Azure ポータルから DNS ゾーンを作成します。 DNS ゾーンの名前は private.example.com 、リソースグループ名は blog で作成してみました。

/control-azure-resources-from-a-runbook-using-a-managed-id/001.png

Screenshot

このまま VNET に接続しなければ宝の持ち腐れですが、今回は説明用ということで。

Runbook の用意

Azure ポータルから Automation アカウントを作成します。 名前は blogaccount とか、任意で大丈夫です。

作成時に詳細設定でマネージド ID の設定ができるので、デフォルトの通り「システム割り当て」をオンにしておいてください。 (Automation アカウントの作成後、アカウント設定 – ID から、システム割り当てマネージド ID を「オン」にしても大丈夫です)

/control-azure-resources-from-a-runbook-using-a-managed-id/002.png

Screenshot

Automation アカウントが作成されたら、Automation アカウントのポータル画面から プロセス オートメーション – Runbook を開き、+ Runbook を作成を選択します。

Runbook の種類に PowerShell を選び、ランタイムバージョンは 5.1 を選んで作成します。 Runbook 名は Add-PrivateDnsRecord にしましょうか。

[Read More]