「SE の 35 歳定年説」みたいなのを気にしながら生き方を考えていたかもしれません。
35 歳になってみて、プログラムを書くことに対してどうだったかな？と振り返ってみました。
10 歳～小学生 Excel VBA を使ってました。
ナンバープレイス（数独と言った方が伝わる？）の答え合わせツールを作ったなぁ、程度ですが・・・いや、勝手に答えを出してくれるわけではなく、別シートに書いてある回答と If 文で比較しただけです。
中学生 Visual Basic 6.0（VB6）を使っていました。
「のんびりゆっくり Visual Basic」という書籍が愛読書でした。
夏休みの自由研究で毎年ゲームを作っていました。
中 2 の時にシューティングゲームを作るために Windows API にも手を出しました。
高専生 専攻科まで行ったので 7 年間ですね。
授業で習った C 言語や Java などが使えるようになりました。
研究で C++と OpenGL で毛筆シミュレーションを作ったり、同じく C++と OpenGL で高専プロコンのために金魚すくいシミュレーターを作ったりしました。
ただ趣味のプログラミングとしては相変わらず VB6 が好きでした。
社会人（1 社目、2 社目） Ruby に手を出したり、古の言語に触れてみたり、幅広い言語を使うことになりました。 その中でも Java や.NET 系のオブジェクト指向言語（C#、VB.NET）が主力だったと思います。
チーム開発の経験が進むにつ入れて、VB6 との距離は遠ざかっていきました・・・
社会人になってからは C#が一番好きな言語になりました。
社会人（3 社目） 最初の頃は C#の技術力を武器に働きました。
その後、Docker や PowerShell など、言語のカテゴリで書くか微妙なところですが、次第にインフラに寄った知識が増えていきました。
いつの間にか terraform を覚え、Kubernetes のマニフェストファイル(yaml)も読み書きできるようになっていきました。...
下記のサンプル実装のアプリコード部分を解説します。
https://github.com/hirokimatsueda/azure-managed-id-sample
アプリ処理詳細 コードはこちら: https://github.com/hirokimatsueda/azure-managed-id-sample/blob/main/applications/DataApis
詳細と言うほどのものではないですが・・・。
GetData リクエストパラメータから id と category を読み取って、対象のデータを 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 の初期化というコストの高い処理回数を削減しています。...
下記のサンプル実装のインフラコード部分を解説します。
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 はキレイ好きだから汚れた場所にはいきたくない」という性格を覚えておくと、関連するドキュメントが一気に読みやすくなります。
是非覚えておいてください。