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....
Azure Kubernetes Service(以降、AKS)は Windows コンテナの使用できる構成を作成することができます。
（記事公開時点ではパブリックプレビュー）
Windows コンテナが使える AKS を用意して、アプリを動かしてみましょう。
アプリの作成からインフラの作成まで一通り必要な手順を書いてみましたので、この記事をベースに Windows コンテナの世界に入門していただけたらと思います。
また、アプリ開発、コンテナ作成、AKS 作成を一通り記載しているので、例えばアプリ開発は知識があるけどインフラはちょっと・・・という場合に部分的に参照していただけると嬉しいです。
Azure Cloud Shell とはなんぞや？などの細かい説明は省いていますので、適宜調べながら読み進めていただけたらと思います。
概要 （Windows 環境でしか動作しない）アプリケーションを作成します アプリケーションを載せたコンテナイメージを作成します コンテナイメージをコンテナレジストリ（ACR）に格納します Windows コンテナが動作する AKS を作成します マニフェストファイルを使用して、AKS 上でコンテナを動かします Web アプリの作成 【作業環境の想定：手元の Windows PC】
Web 上に公開されているサンプルアプリを使っても良いんですが、現実は自社で作成したアプリなどを使用すると思うので、Web アプリの作成からサラッと見てみましょう。
Windows コンテナが必要なケースは、Windows でしか動作しないアプリ、例えば.NET Framework のアプリを使用している場合だと思われます。.NET Framework の ASP.NET MVC アプリを作っておきましょう。
下記サイトから Visual Studio のインストーラをダウンロードします。 https://visualstudio.microsoft.com/ja/downloads/
インストーラを起動し、「ASP.NET と Web 開発」を選択してインストールします。
インストールが成功したら、新規プロジェクトを起動して、C#の ASP.NET MVC アプリを作成しましょう。
ちょっと古めのアプリを載せる想定だと思いますので、.NET Framework は「4.5.2」辺りが良いでしょうか。プロジェクト名は適当で良いので、「MVC」のアプリを作成してください。
アプリが作成されたら、Visual Studio のソリューションエクスプローラーから、Views/Home/Index.cshtml を開き、適当な加工を加えて実行してみてください。例えば下記のような感じでザックリいきましょう。...
Dockerfile の基本的な書き方 皆様、Windows コンテナで遊んでいますか？
Dockerfile に書く内容は、誤解を恐れず表現すると、だいたい下記のような流れですよね。
ベースイメージ ミドルウェアのインストール、セットアップの処理 アプリケーションのコピー アプリケーションの起動を監視するために ENTRYPOINT を記載 これだけ認識していれば、例えば単発実行や無限ループで処理待機するコンソールアプリケーションのコンテナ化なんてのは、（細かいことを無視すれば）すぐにできてしまうと思います。
謎の exe 、ServiceMonitor しかし、例えば下記の Dockerfile を見てください。
https://github.com/microsoft/dotnet-framework-docker/blob/7d120a3da56ea5279e1b54a8185530af056c7b33/4.8/aspnet/windowsservercore-ltsc2019/Dockerfile
これは IIS で動く Web アプリを動かすときに使える Dockerfile になるんですが、 ENTRYPOINT に ServiceMonitor.exe なるものが指定されています。
「なにこれ」と思いませんでしたか？
私は思いました。
そもそも ENTRYPOINT って何だっけ ENTRYPOINT は「コンテナが実行するファイルを設定します。」とのことです。
http://docs.docker.jp/v1.11/engine/reference/builder.html#entrypoint
そして、その「実行するファイル」が終了すると共に、コンテナが終了します。
これを IIS で動かすアプリに当てはめるとどうなるでしょうか？
IIS で動かすアプリは exe ファイルでは無いので、それ単体で実行することはできませんよね。IIS の上に載せてあげることで初めて動作します。
ということは、IIS が ENTRYPOINT に記載すべきものとなります。
しかし、 IIS 自体はサービスなので、「コンテナが実行するファイル」とは違う概念になります。
「サービスの起動状態を監視するアプリ」が欲しい 例えば、「コンテナが実行するファイル」が IIS というサービスの起動状態を監視してくれて、そのサービスの状態に従って終了してくれたら良さそうに思いませんか？
そんな役割を担ってくれるのが ServiceMonitor.exe です。
よって、IIS のようなサービスの状態がコンテナの起動状態を左右する場合は、 ServiceMonitor.exe を ENTRYPOINT に指定してあげればコンテナが実現できそうですね。...
スピーディーに仕事がしたい！ 先月は docker から始まるコマンドを何度も何度も実行していた気がします。
私の今の仕事は検証がメインで、何度も似たようなコマンドを実行したり、何かをダウンロードしたりという作業を実施しています。
検証作業は先が見えにくいので、できるだけスピーディーにやるべきことを繰り返して知見を増やしたいですよね。
検証に限らずスピーディーに仕事をすることは大切だと思いますので、私が実践している仕事の高速化手法を書いてみます。
同じことをダラダラ何度も書かない ([ctrl] + [R]の活用) コマンドを実行する時のお話です。
例えば、 docker build のコマンドって何度も同じ内容で実行するのに長くなりがちですよね。
docker build . -t cloudconfig/blog 上記で「いや、それくらいなら短いのでは？」と思った方、書いた文字の正しさを検証する時間を無視していませんか？
例えば、 docker を dokcer と書き間違えちゃったとして、実行する前に気付けますか？
できれば前回実行したコマンドをそのまま書いたことを書きたいですよね。
そんな時、[ctrl] + [R] が使えます。
Linux 環境で Bash を使用している場合や、Windows 環境で PowerShell を使用している場合に押してみてください。
そして、build とキーボードから入力すると、前に実行した docker build の履歴が表示されると思います。
reverse-i-search とか bck-i-search とか呼ばれるみたいですね。
使いたい候補が出たら [Enter] を押してそのまま実行したり、 [→] を押すなりして一部を修正して実行したりできるので、過去に成功したコマンドラインを流用できます。とても便利ですね！
ただ、失敗したコマンドも出ますし、検索文字列が短すぎたりすると意図しない実行履歴が出る場合もありますので注意してください。
VM を活用する 例えば、Docker を使用する時、どこで動かしていますか？
自分の PC で動かしていませんか？
自分の PC 上で動かすと便利なこともありますが、下記のようなリスクがあります。
PC のリソースを食いつぶしてしまう ベースイメージのダウンロードに時間がかかる ミドルウェアの状態を把握しきれず、自分の PC でしか実行できない Dockerfile が出来上がる可能性がある 上記のようなリスクは、VM を使用することで改善できます。...
10 歳からプログラミングやってます、と、プレゼン内で笑いを取ろうと喋ったら、喋りが下手すぎてリアクションがもらえず焦った松枝です。
仕事でプログラミングをするようになった新卒の人に対して伝えたいことがあります。今年の弊社の新卒の皆さんにはお伝えしたのですが、こちらのブログにも書いてみようと思います。
背景（読み飛ばし推奨） 前述の通り 10 歳からプログラミングを始め、高専専攻科を卒業するまでの約 12 年間、趣味または研究でプログラミングをやっていました。 当時はまだ Windows 98 SE とかの時代で、小中学校の同級生でプログラミングができる人は皆無で、高専に入ってようやくまともに会話できる人が数人いる、というような状態でした。
そんな状態の人が社会人になったので、自分の力はどこでも通用するんじゃね？という気持ちが半分、いやいや世の中にはもっとすごい人が必ずいるだろうついていけるかな？という気持ちが半分で、配属になりました。
そこで出会ったチームリーダーさんの技術に圧倒されました。 力試しで与えられた課題を解いてレビューして頂いた結果、自分のコードの汚さ、詰めの甘さに気づくことができました。同時に、とても恵まれた環境に配属されたのだとワクワクしてきました。
聞けばそのリーダーさんは当時 30 歳くらいで、プログラミングに初めて触れたのは大学生の頃ということでした。つまり、「プログラムを書く」というキャリア年数は私と同じくらいです。 しかし技術力は雲泥の差でした。私は間違ったものを積み重ねていたのだなという後悔の気持ちが襲ってきました。 若い人が同じような後悔を抱えずに過ごせるよう、仕事としてのプログラミングを始める人に最初に知ってほしい、いくつかのポイントを伝授します。
人が読みやすいコードを追求する 半年後には何をやっているか分からないコードにしない 変数名は分かりやすい単語を使う できるだけ日本語のローマ字表記ではなく英語で書きましょう。 コーディング規約を遵守する、フォーマッタを活用する if( a== b){ c++;} とか書いてあったら、私は(心の中で)キレます。 コメントを適宜書く。ただし書きすぎない // a を b に代入する みたいなプログラムの説明は要りません。 そのコードで何をしたいのか伝わりにくい時にコメントを書いてください。 伝わりにくいときはきっとコードを見直したほうが良いです。 既存コードのフィーリングを尊重する 勝手にログ出力を端折ったりとかしないでください。せめてプルリクエスト上げるまでには戻して… 車輪の再開発を避ける クイックソートとかを自分で作らずライブラリを活用しましょう。品質確保って大変ですよ？ 自分の理解したコードを書く ネット上の Stack Overflow や teratail などに記載しているコードをそのままコピペしない 友達に直接コードを書いてもらわない 参考にした、教えてもらった情報は何なのか、自分の知識に落とし込んでから、改めて今回のケースはどうすればよいのか考えて実装する。 まとめ 上記をまとめると、要は「美しいコードを書いてください」ということです。 音楽でいえば、例えばクラシックの音楽は何百年も昔に作られたにも関わらず、現代の私たちが聴いても良い曲だと感じますよね？...