ARM template 大量のNSG/ルールをCSVから一括登録する
今回は(NSG)Network Security GroupのARM templateに関する記事です。
NSGはMicrosoft Azureが提供するファイアウォールちっくなサービスです。
基本仕様はとりあえずおいておいて、ポイントとなる以下の点をまず押さえておきましょう。
〇NSGの適用対象
サブネットかNiCのどちらかになります。
vNETに対して適用はできませんので注意してください。
〇Quota(制限)
NSG名は1サブスクリプション内のリージョン毎に100個が上限
1個のNSG内は200個のルールが適用可能
※足らない場合はSR(Support Requestを上げてSubscription Idを伝えることで
上記個数の倍の制限値上げることができるようです。
さて、このようなNSGですが1つ2つぐらいならAzure Portalから手作業でやることも苦にはなりません。でも一括で100個も500個も必要になってくるとそういうわけにはいかなくなります。
お試しやPoCならよいですが、エンタープライズなお客様は既にオンプレで秘伝のタレ的なFW定義といったひな型があると思いますので、その規模のものをどうやって効率よくAzureへ適用し管理できるか、というのが課題になります。
また、多くの方々は100個以上のNSGを登録する際に、パラメータシート(大抵Excel)で管理されていると思いますので、CSV形式に落とし込んでからPowerShellやAzure CLIを使って1行ずつ読み込んで対応することが一般的かと思います。
ここではARM templateを使った「あえて違うやり方」を紹介します。コマンドレットやコマンドラインから1つずつ実行(おそらく再帰的に処理される)することと何が違うのか、そこを最後に記載したいと思います。
ではARM templateで行うやり方について記載します。
〇必要な環境
CentOS 7.2の仮想マシンでAzure CLIがインストール済であること。
ない場合はこのブログの前の記事を見て作成してみてください。
〇用意するもの
1)インプットファイルとなるCSV形式のファイル
⇒ インプットファイルのひな型とスクリプトは以下からwget/curl等でダウンロード
してください。
・インプットファイルのひな型
〇事前準備
上記インプットファイルのサンプル記載を参考に100行でも200行でも適用したい
数だけ自社用・自分用に全て埋めましょう。
〇開始
事前準備が終わった後の確認画面です。(azureコマンドを打てる状態で)
more input.csvで中身を確認してみてください。
※項目と順序、記載文字列が合っていれば、先ほど記載してもらったエクセル
ファイルを上記形式を変えずにCSVへエクスポートし、Linux側へSCPして
ください。
次にmakeNSGjson.shをvi/vimで開きます。
下にあるように作業するPATHを自分のローカルパスに変更してwqしてください。
⇒BASE_DIR_PATHの場所を自分の環境に合わせて修正
ではコマンドを実行します。
特にエラーもなく終われば、実行したその配下にoutput.jsonというファイルが1つ作成されています。
中身を見るとわかりますが、CSV形式をNSGのARM template用に変換かけたJSONファイルとなっています。
JSON形式ですので、合っているようで合ってないないような、よくわからない状況かと思いますので、templateのvalidationとdeployを試してみましょう。
まずはmany-nsg-rgという名前のResource Groupを作成します。(お試し用として)
[azure01@centostest01 blog-sample]$ azure group create many-nsg-rg japaneast
info: Executing command group create
+ Getting resource group many-nsg-rg
+ Updating resource group many-nsg-rg
info: Updated resource group many-nsg-rg
data: Id: /subscriptions/***/resourceGroups/many-nsg-rg
data: Name: many-nsg-rg
data: Location: japaneast
data: Provisioning State: Succeeded
data: Tags: null
data:
info: group create command OK
[azure01@centostest01 blog-sample]$
作成できたので、このmany-nsg-rgへデプロイする前のvalidationをかけてみます。
ちゃんとOKって返ってきていますが、このvalidateion、過度の期待は禁物です。。
デプロイしてPortalから確認してみましょう。
info:でRunningからSucceedがバラバラ出てきたと思います。
Runningは既存リソースと確認してプロビジョニング対象を探しているようですね。また、Succeedの部分は既にポータルで部分的にデプロイが確認できていることから、デプロイステータスを指しているようです。
こんな画面で終わっていれば成功です。
ではポータルで確認してみましょう。
ちゃんと作成されていますね。
ではもう1つ。
test-nsgの宛先アドレスをJSONファイル内を変更して、再度テンプレートデプロイしました。引数を指定しないデプロイは全て増分デプロイになります。
はい、既存のリソースはそのままで、修正した部分だけがプロビジョニングされていることがわかりました。
以上がテンプレートからNSGを一括登録するやり方です。
既にお気づきの方もいるかもしれませんが、コマンドラインやコマンドレットから操作するやり方と比べて、結果は同じだと思います。注目したいのはその管理の主体と履歴です。
shellでもpowershellでもperlでもjavaでもC#でも、実行した時のプログラムやログ等は保管・バージョン管理されていると思いますが、その時にどの定義を当てはめて、現状との差異を追うのは大変です。結局今回の例でいうExcelかCSVで管理する、というやり方が徹底されてしまいます。つまり人が安易に触れる媒体が管理の主体になる、ということはミスが起きやすくなるということです。
ARM templateを使うことで、JSONファイルそのものを履歴で管理すればよい、というお手軽さがわかったでしょうか。今回適用したJSONファイルと既存のResource GroupからエクスポートしたJSONファイルの突合・diffをすれば、何が変わったかは簡単にわかります。既存リソースからCSVを起こす、とか、過去のCSVのバージョン管理方法で既存リソースは「これのハズ」という運用からより確実なやり方に変わると思います。
また、今回紹介していませんが、JSONファイルそのものをgithubで管理することでJSONファイルそのものの更新管理がより楽になります。
1000行のNSGや2000行のNSGといった大規模な環境になると、整形するスクリプトが必要にはなりますが、このようなやり方で新たな運用方法をお試し頂くのもアリではないでしょうか。