ARMテンプレートとAutomation DSCを用いた構成管理(概要編)

概要

Azure上で多大な数のリソースを継続的に管理およびデプロイする際、それらのリソースやサービスに関する構成や管理手順を組織で一貫して維持するのは一般に困難です。

この課題に対し、下記のMicrosoftドキュメント引用に見られるように、ARM(Azure Resource Manager)テンプレートとAutomation DSC(Desired State Configration) によって「望ましい状態の構成」を宣言することで、デプロイに関する手順的なロジックの実装なしに自動的に構成を実現・管理することができ、さらにレポートによって構成の一貫性を監視することができます。

“継続的展開” という概念の重要性が高まりつつあります。(中略)…こうした展開の目的は修正ではなく、公開されたものを迅速に取得することにあります。 クラウド コンピューティングへの移行に伴い、最終状態の環境をテキストとして宣言し展開エンジンに公開する、”宣言” テンプレート モデルを活用した展開ソリューションが必要とされています。 この展開方法では、展開をいつでも継続的に繰り返して最終状態を確保できるため、エラーの脅威に対する復元性を持ちながら急速な変更を大規模に行うことができます。 こうした変化への対応として、このような作業のスタイルを自動化によりサポートするツールやサービスが作成されました。

エンジニア向けのDesired State Configurationの概要(Microsoft docs)

本稿ではAutomation DSCについてはじめに主な用語を説明した後、DSC構成の例としてWindows Virtual Desktopのテンプレートを参照しながら概要を解説します。

Azure Resource Managerの概要、移行については以下の記事をご参照ください。

Azure Resource Manager (ARM) のメリット

クラシックリソースからAzure Resource Managerリソースへの移行の流れ

Automation DSCとは

Automation DSC は、Powershell DSC に基づくAzure サービスです。

システムの構成・制御、デプロイを行う宣言型のプラットフォームであるPowershell DSC とAzure Automationの機能によって、リソースの幅広い範囲の一貫したデプロイ・監視・更新を行うことができます。
Azure Automationがプルサーバーの役割を果たし、リソースの状況把握およびその状態と望む構成とのギャップを自動的に埋めることができます。

プロセスの実装部分はLCM(Local Configuration Manager)と呼ばれるエンジンが実現するため、ユーザーおよび管理者は配置の構成に集中することができます。

DSCを用いることで通常のPowershell スクリプトでの操作に比べ、べき等(何度動作を反復しても同じ結果を得ること)を容易に実現できます。また実装のプロセスを記述しないため、手動での実装に比べてエラーの発生を低く抑えることができます。

Automation DSC はMicrosoftがサポートするWindows製品のみならず、ほとんどのバリュエーションのLinux OSをサポートします。

(参考: Linux用 DSC の概要

Automation DSCの概要図を下に記載します。

以下、Automation DSC に関わるPowershell DSCについての簡単な用語説明を行います。

LCM(Local Configuration Manager)

LCM(ローカル構成マネージャー) はWindows OS上のWMF( Windows Management Framework )のコンポーネントであり、ノードの状態の取得・ 必要な状態との比較、構成の実現といった役割を担います。

Automation DSCで用いるVM拡張機能がはじめて呼び出される際、OSに適合したバージョンのWMFがインストールされます。Windows Server 2016以降のOSでは既に最新バージョンのWMFがインストールされているためこの工程はスキップされます。

Linuxの場合はWMFの代わりにOMI(Open Management Infrastructure)をインストールすることでLCMが使用できます。

Azure Automation にVM を登録するときに LCM の構成を行います。

DSC構成・コンパイル

構成の定義はDSC構成と呼ばれる特殊なPowershell スクリプトによって行います。これはJSONのように入れ子状のブロック構造で、外側からConfigurationブロック、Nodeブロック、そしてリソースブロックによって構成されます。構成の詳細については後ほど例を参照しながら解説します。

構成をノードに適用するには、DSC構成のps1ファイルのコンパイルを行い、MOF ファイルを出力する必要があります。出力されたMOFファイルのノード構成がLCMによって各ノードに適用されます。

プッシュモード/プルモード

LCMはプッシュ/プルという2つのモードによって構成を取得します。

プッシュモード

プッシュモードではPowershell コマンドレットによって指定されたノードにすぐに構成を適用します。多くの場合、構成のテストや新規イメージの作成時に用います。

DSC のプッシュ アーキテクチャを示す図

プルモード

プルモードでは、各ノードのLCMが構成情報が保存されたプルサーバーから定期的に構成情報を取得し、検証後に構成が各ノードに適用されます。

Automation DSC ではAzure Automationがプルサーバーの役割を果たし、さらに 管理とレポートをグラフィカルに一元化します。

DSC のプル アーキテクチャを示す図
(画像はMicrosoft learnから引用)

LCMがノードに構成を適用する方法はさらに3つのモードに分かれます。

・ApplyOnly:適用後は何も行われない

・ApplyAndMonitor:適用後にノードの状態とDSC構成との不一致を監視

・ApplyAndAutoCorrect:適用後にノードの状態がDSC構成からずれた場合に自動で構成を再度適用する

DSC構成詳細とARMテンプレートでの使用

Azure VMのAutomation DSC への登録にはAzureポータルやVM拡張機能など様々な方法がありますが、ARMテンプレートを用いることで新規VMのデプロイと同時にAutomationへ登録することができます。

下記Microsoft のページにVMのデプロイとAutomationのオンボード(登録)のためのARMテンプレートサンプルがあります。

Server managed by Desired State Configuration service

このテンプレートはAutomationアカウントやDSC構成の作成からVMのデプロイとそのAutomationへのオンボードまでをワンストップで行います。
以下ではこのテンプレートの内容を参考にしながら、DSCを使用する際のARMテンプレートと具体的なDSC構成について解説します。

ページ上の「Githubで参照する」をクリックするとARMテンプレートが見られます。
メインテンプレートである [azuredeploy.json] の中に[nested]フォルダ内のテンプレートが入れ子に配置されています。
[nested]フォルダ内の[provisionConfiguration.json]がAutomation DSCの使用のためのテンプレートであり、その中で用いられるDSC構成ファイルが[dscConfigurations]フォルダに存在します。

DSC構成詳細

それでは実際にDSC構成ファイルの構造を確認していきます。

DomainControllerConfig.ps1

前述したように、DSC構成はConfigurationブロック・Nodeブロック・Resourceブロックが入れ子になって構成されます。
Configurationブロック(赤)には一つ以上のNodeブロックとResourceブロックが含まれ、通常Powershell関数内 で実行可能なすべてを実行できます。
下の例ではDomainControllerConfigという名前の構成の中でパラメータの指定とリソースの使用に必要なモジュールのインポートを行っています。
Nodeブロック(青)でノード(コンピュータ)名を指定します。配列表記で複数のノードを指定することもできます。既定値は[‘localhost’]です。
このノード名によって構成のコンパイル時に作成されるMOFファイル名が決まります。複数ノードを指定した場合はその数だけMOFファイルが作成されます。例では、後述するconfigurationData(構成データ)の中で定義されたノード名を指定しています。
Resourceブロック (黄)で構成するリソースとその状態を指定します。
Windows FeatureリソースではWindows サーバーの機能追加を行っています。例ではADDS機能を追加しています。
xWaitforDiskリソースとxDiskリソースでは使用可能状態を待ってからディスクのフォーマットとボリュームの指定を行っています。
xADDomainリソースではActive Directoryで用いるドメインデータベースのディレクトリパス、書き込まれるログファイルとSysvolのパスを指定しています。[DomainName]プロパティでは構成データで定義したノード名と対応する値を[$Node.domainName]という形で指定しています。[DependsOn]プロパティはリソース間の依存関係を指し、ここではADDS機能のインストールの終了を待つよう指定しています。

リソース詳細

上記のように、 リソースブロックによってDSCのロジック部分が構成されます。
リソースブロックで使用するDSCリソースには、サーバー機能の追加やサービスのインストールだけでなく、幅広い範囲に活用できる様々な選択肢があります。
次の表はその一部です。

リソース 説明
File ノード上のファイルとフォルダーを管理する
Archive .zip 形式のアーカイブを圧縮解除する
Environment システム環境変数を管理する
Log DSC イベント ログにメッセージを書き込む
Package パッケージをインストールまたは削除する
Registry ノードのレジストリ キーを管理する (HKEY ユーザーを除く)
Script ノードで PowerShell コマンドを実行する
Service Windows サービスを管理する
User ノードのローカル ユーザーを管理する
WindowsFeature ノードの役割または機能を追加または削除する
WindowsOptionalFeature ノードのオプションの役割または機能を追加または削除する
WindowsProcess Windows プロセスを管理する

また下記Powershell コマンドレットによって組み込みのPowershell DSCリソース一覧を確認できます。

Get-DscResource | select Name,Module,Properties

(参考:Azure Automation State Configuration とは(Microsoft Learn)

ARMテンプレート

最後にDSC構成をAzure Automation上で使用するためのARMテンプレートについて解説します。
なお、Automation DSCのためのARMテンプレートの使用について、サンプルでは構造の簡単のために入れ子状の構成を取っていますが、必ずしも同様の入れ子のテンプレートを構成する必要はありません。

azuredeploy.json

メインテンプレートの[azuredeploy.json]を確認します。
パラメータセクション・変数セクションの後のリソースセクションにおいて、変数セクションに記載した[provisonConfiguration]テンプレートのURLを [templatelink]プロパティに指定しています。

provisonConfiguration.json

Automation DSC用テンプレート[provisonConfiguration.json]を確認します。


パラメータセクションの後に変数セクションでDSC構成ファイルとリソース用モジュールの場所を変数に指定しています。

そしてリソースセクションではまずAutomationアカウントを作成し、その下の入れ子のリソースセクションにおいて一連のDSC構成のオンボードを行っています。
この中で使用するAzure Automationのリソースタイプについては以下のドキュメントをご参照ください。
Microsoft. Automation resource types
ここではDSCリソースで使用するモジュールのインストールを行い、(続く)

(続き)パラメータから取得した権限をセットし、DSC構成ファイルを登録・コンパイルしています。
complirationタイプリソースでコンパイルを構成する際、パラメータでconfigurationData(構成データ)を構成しています。構成データはコンパイル時にDSC構成に渡されるハッシュテーブルで、ノード名と各ノードに対応するキー(例ではドメイン名)を定義し配置することでDSC構成の書式をシンプルにすることができます。
構成データについて詳しくは下記ドキュメントをご参照ください。
構成データと環境データの分離

まとめ

DSC自体はそれほど新しい技術ではありませんが、 Azure Resource Managerとの組み合わせによってべき等かつ管理・実装が飛躍的に容易なソリューションとなり得ます。

現在ホットな話題であるWindows Virtual DesktopのデプロイテンプレートにもDSCが使われているように、Azureサービス内部の仕組みを読み解く上でもDSCの理解は大きな助けになるでしょう。

本ブログでは実践編として、日本語化の自動化などARM&DSC構成の可能性を検証していく予定です。引き続きお付き合いいただければ幸いです。

いいね (この記事が参考になった人の数:2)
(↑参考になった場合はハートマークを押して評価お願いします)
読み込み中...

注意事項・免責事項

※技術情報につきましては投稿日時点の情報となります。投稿日以降に仕様等が変更されていることがありますのでご了承ください。

※公式な技術情報の紹介の他、当社による検証結果および経験に基づく独自の見解が含まれている場合がございます。

※これらの技術情報によって被ったいかなる損害についても、当社は一切責任を負わないものといたします。十分な確認・検証の上、ご活用お願いたします。

※当サイトはマイクロソフト社によるサポートページではございません。パーソルプロセス&テクノロジー株式会社が運営しているサイトのため、マイクロソフト社によるサポートを希望される方は適切な問い合わせ先にご確認ください。
 【重要】マイクロソフト社のサポートをお求めの方は、問い合わせ窓口をご確認ください