BLOGAzureブログ

皆さまこんにちは、SB C&Sの八釼（やつるぎ）です。
Azureのリソースはさまざまな方法でデプロイできますし権限さえあれば誰でも変更なども可能なわけです。しかし特に本番環境の場合にはこれは困りますよね。Azureのリソースというのはシステムのコンポーネントですので、無秩序な状態はよろしくありません。統制度合はさておき、ざっくりとでも管理できている状態にしたいものです。

そこで基本的に有効とされていたのがAzure Blueprintsでしたが・・・

【関連記事】そろそろ正式に提供開始されるのか？してほしい！Azure Blueprints

なんとマイクロソフト社は非推奨にする方針を打ち出してきました。

2026 年 7 月 11 日に、Blueprints (プレビュー) は非推奨になります。

公式ドキュメント「Azure Blueprints (プレビュー) とは」より引用

まあ長年プレビューでしたしこの仕組みでは有用なサービスとはなり得ないと判断したのでしょう。

では何が推奨になったのか？
それは
Azureデプロイスタック（Azure Deployment Stacks）
です。

AWSの知見がある方でしたら何となくイメージが湧くかもしれません。AWS CloudFormationとテンプレートによってプロビジョニングしたAWSリソースの集まりを『スタック』と言いますね。ただメチャクチャざっくり同じというだけで、結構違うのであくまで大枠のイメージとして似てる程度に思ってください。

Azureデプロイスタックがどのようなものかは以下の公式のドキュメントをご確認いただければと思いますが、ひとまずはざっくりリソースの集まりと覚えていただければと思います。

公式ドキュメント | デプロイ スタック

ということで、今回はこのデプロイスタックについての簡単な検証結果を共有します。

• ＜目次＞
• 検証環境の準備
•  ∟ Bicepコード記述
•  ∟ リソースのデプロイ
• 動作を確認
•  ∟ Azure portalからVM削除を試みる
•  ∟ Azure portalからNSG受信規則追加/削除を試みる
• 最後に

環境準備

Bicepコード記述

本記事では、以下のようにGitHubで公開されているquickstarts/microsoft.compute/vm-simple-linux の main.bicep のコードを linuxvmModule としてモジュールにしました。

                        
                            .
                            ├── main.bicep
                            ├── main.bicepparam
                            └── nested
                                └── LinuxVM.bicep
                        
                    

本記事における、main.bicepには以下のように記述しました。
なんてことはないです。Ubuntu仮想マシン関連のリソースの他に以下を記述しているだけです。

・スコープをサブスクリプションに設定
・リソースグループを新規作成

                        
                            targetScope = 'subscription'
                            
                            param resourceGroupName string

                            @description('Location for all resources.')
                            @allowed([
                            'japaneast'
                            'japanwest'
                            'westus'
                            ])
                            param resourceGroupLocation string

                            @secure()
                            param adminPasswordOrKey string

                            param adminUsername string

                            resource newRG 'Microsoft.Resources/resourceGroups@2021-04-01' = {
                              name: resourceGroupName
                              location: resourceGroupLocation
                            }

                            module containerappModule 'nested/LinuxVM.bicep' = {
                              scope: newRG
                              name: 'LinuxVM-deploy'
                              params: {
                                adminPasswordOrKey: adminPasswordOrKey
                                adminUsername: adminUsername
                              }
                            }
                        
                    

リソースのデプロイ

以下のコマンドを実行し、デプロイスタック: deployment-stack-demo1を作成しました。

                        
                            $ az stack sub create \
                            --deny-settings-mode denyWriteAndDelete \
                            --action-on-unmanage deleteAll \
                            --name deployment-stack-demo1 \
                            --location japaneast \
                            --template-file main.bicep \
                            --parameters main.bicepparam
                        
                    

なお、このコマンドの詳細については以下のリファレンスをご確認ください。

リファレンス | az stack sub

Azure portalで確認してみると問題なく作成できたことが確認できました。

ちなみに、デプロイスタックによって管理されるAzure リソースは"マネージドリソース"と呼ばれます。緑枠で囲った部分です。これらのリソースは、スタックの作成に使用されるテンプレートファイル内の先に示したようなコードで定義されます。

動作を確認

Azure portalからVM削除を試みる

以下のメッセージが出力され削除できませんでした。これは然るべき結果で、デプロイ時に
--deny-settings-mode denyWriteAndDelete
としたためです。つまりマネージドリソースに対する削除は拒否されるのです。

                        
                            仮想マシン 'simpleLinuxVM' またはそれに関連付けられている
                            選択されたリソース (あるいはその両方) を削除しているときにエラーが発生しました。
                            （中略）
                            クライアント 'yusuke.yatsurugi@xxxxxxxx.xxx' には、
                            （中略）
                            アクション 'Microsoft.Compute/virtualMachines/delete' を実行するアクセス許可がありますが、
                            （中略）
                            拒否の割り当てが原因で、アクセスが拒否されました。
                        
                    

Azure portalからNSG受信規則追加/削除を試みる

NSG（ネットワークセキュリティグループ）にはまずは受信規則を追加してみます。HTTP: 80番ポートを空けてみました。

できました！
ちなみに、本来はソースコードを修正して追加すべきです。参考まで以下のコードを追記してデプロイすれば80番ポートを許可できます。

                    
                        {
                            name: 'HTTP'
                            properties: {
                            priority: 1010
                            protocol: 'Tcp'
                            access: 'Allow'
                            direction: 'Inbound'
                            sourceAddressPrefix: '*'
                            sourcePortRange: '*'
                            destinationAddressPrefix: '*'
                            destinationPortRange: '80'
                            }
                        }
                    
                    
                

では削除を試みると、VMの時と同様に拒否の割り当てが原因でアクセスが拒否されました。

ということで、削除はできませんでしたがNSGのセキュリティ規則の追加作成やタグの付与など、あくまでNSG自体の設定以外の操作は実施できることが確認できました。

ではリソース（この場合には受信セキュリティ規則）を削除するにはどうすれば良いのかですが、前述したとおりマネージドリソースはコードで管理されます。よって、Bicepコードファイルから記述を削除してデプロイすれば良いのです。本記事の場合linuxvmModuleのコードを再度デプロイすれば良いのです（この規則は記述されていないので）。そうすれば元々のデプロイの状態に戻るわけですね。

最後に

Azure BlueprintsのようにGAを待たずして非推奨になるかもしれませんので、長年プレビュー状態のままのサービスは注意したほうが良いかもしれません。既にBlueprintsをお使いの方はデプロイスタックへの移行をぜひご検討ください。

なお今回の記事ではデプロイスタックについての一例をざっくりご紹介しましたが、--action-on-unmanageや--deny-settings-modeの引数を変えることでまた違った挙動を示しますので、皆様の組織に合う管理方法になるよう適切なものを指定してください。

Azureリソースのライフサイクルを管理については色々とお困りごとが出てくるかもしれませんが、その際にはぜひとも法人でのAzure導入前の相談窓口であるAzure相談センターまでお気軽にお問い合わせいただけますと幸いです。弊社では、ユーザー様のご状況やご要望を踏まえて最適な形でのAzureの導入のご支援を提供しており、Azure に精通したスタッフが丁寧にご回答させていただきます。