Azure Blueprints – Azureの環境構築はどう変わる?

最近の楽しみはプロテインゴリラの躍動を観戦する事の木下です。
今回は最近Azure Blueprintsを少し触る機会が有ったのでブログに書いていきます。

Azure Blueprintsとは?

Azure Blueprintsは2018年9月に実施されたMicrosoft Ignite 2018でpreviewが発表されたAzureのサービスです。

設計図によってエンジニアやアーキテクトがプロジェクト設計パラメーターの概略を示すのと同じように、Azure Blueprints によってクラウド アーキテクトや中央の情報技術部門は、組織の標準、パターン、要件を実装および順守した反復可能な一連の Azure リソースを定義できます。 Azure Blueprint を使用すると、開発チームは新しい環境を迅速に構築して立ち上げることができます。新しい環境は組織のコンプライアンスに従って構築され、ネットワークなどの一連の組み込みコンポーネントを含んでいるという確信が得られるため、開発とデリバリーにかかる時間を短縮できます。

https://docs.microsoft.com/ja-jp/azure/governance/blueprints/overview

MSの公式ドキュメントからの引用では中々全貌を把握しにくいですね。
簡単に言うと既存のサブスクリプション全体の環境設定をAzure上で定義し他の環境への構築を容易にするサービスでしょうか。
主に下記の要素のデプロイが可能です。

  • ロールの割り当て(RBAC)
  • ポリシーの割り当て
  • Azure Resource Manager のテンプレート
  • リソース グループ

察しの良い方はお気づきかと思いますが、Blueprintsにて行える事はARMテンプレートでも実行可能です。
Blueprints自体が今までARMで出来なかった様な事を可能とするサービスではなく、Azure Policy等で複雑化する環境設定を容易にするためのサービスです。
また、後段でも書きますがAzure Blueprintsによる環境設定で今までのARMテンプレートを使わなくなるという事はありません。ARMのあのjsonは使う必要が出てきます。
既に有るARMテンプレートを利用してBlueprintの定義を作成する事が可能ですので、資産としてARMテンプレートを活用していきたいですね。

Azure Blueprintsの使い方

Azure Blueprintsの使用方法はPortal上での操作とREST APIを利用した2種類が存在しますが、基本的に環境設定を容易にするという観点で考えるとPortal上から作成する方が良いと思います。
基本的な手順については下記の様な公式ドキュメントに詳しく載っているので、今回はいくつか個人的に気になったポイントだけ解説します。

https://docs.microsoft.com/ja-jp/azure/governance/blueprints/create-blueprint-portal

1.リソースの作成にはARMテンプレートを使用する。
大体下記の様な感じでPortalからARMテンプレートのデプロイを行う様な形で扱います。
リソースの作成に関しては下記の様な形ですね。図ではストレージ1種のみ作成してますが、実際は1テンプレート1リソース等の制限は無いので基本的に使用可能なARMテンプレートなら問題なく使える筈です。

BlueprintsによるARMテンプレートの定義画面

2.ポリシーの割り当てはAzure Policyの操作と大体同じ。
大体と書いたのはAzure Policy操作画面と違い、ポリシー定義とイニシアティブ定義が同一の画面で選択出来るようになっているせいか定義名と詳細が途中で見切れてしまい使い勝手がやや悪いです。
とはいえARMテンプレートやREST APIの様に定義Idを調べて定義して扱うよりは大分楽ですが。

Blueprintsによるポリシー/イニシアティブ定義画面
Azure Policyのポリシー定義画面

3.ブループリントは[所有者]ロールが有る環境について割り当てが可能。
ブループリントの[割り当てる]というのがデプロイに近く、実際にポリシーやロールの割り当て、リソースの作成が行われます。
基本的に構築を行う環境については[共同作成者]のロールが割り振られる事が多いとは思いますが、[共同作成者]ではブループリント定義の作成と保存しか行えません。[所有者]ではないロールで[割り当て]を行うにはカスタムロールの作成が必要となります。

4.ブループリント定義のバージョン管理がAzure内で完結する。
ここら辺がARMとの一番の相違点かなと思います。
今までのARMテンプレートは要はただのjsonだったのでバージョン管理等行うにはgit等のツールで管理する必要が有りました。この辺りの環境設定の定義をある程度Azure内で完結出来る様になったのは、ブループリントを利用する意義があるかなと思います。

まとめ

正直まだプレビューの状態でARMテンプレートと比べて環境構築ががっつり楽になるかというと、正直そこまででも無いかなとも思ってます。
ただARMというかRBACやポリシー周りの定義は確かに容易になるので、属人的要素を減らす余地が多いサービスだと思いました。

個人的には現在のサブスクリプションからブループリント定義をある程度自動的にエクスポートしてくれる様になると扱いやすいかなと感じました。そろそろプレビューから1年経つのでGAに注目ですね。

%d人のブロガーが「いいね」をつけました。