Azure Automation State Configuration とは何ですか?

完了

Azure Automation State Configuration を使用して、クラスター領域内の仮想マシン (VM) を、同じソフトウェアがインストールされ、同じ構成を持つ、一貫した状態にすることができます。

このユニットでは、Azure Automation の特徴と機能について学習し、PowerShell の Desired State Configuration (DSC) の宣言型モデルについて詳しく取り上げ、その利点を探ります。

Azure Automation State Configuration は、PowerShell に基づいて構築された Azure サービスです。 これにより、一貫したデプロイを行い、確実に監視し、自動的にすべてのリソースを最新の望ましい状態に更新することができます。 Azure Automation には、構成を定義し、それらを実際のマシンおよび仮想マシンに適用するためのツールが用意されています。

Azure Automation State Configuration を使用する理由

サービスの実行サーバーを適切で一貫性のある構成に、手動で維持することは困難で、エラーが発生しやすくなります。 Azure Automation State Configuration では、これらの課題に対処するために PowerShell DSC が使用されます。 DSC の成果物と DSC のプロセスが一元的に管理されます。

Azure Automation State Configuration には、組み込みのプル サーバーがあります。 ノードをターゲットにして、このプル サーバーから自動的に構成を受信し、必要な状態に適合させ、その準拠の状態に関するレポートを返すようにすることができます。 クラウドまたはオンプレミスの Windows または Linux の仮想マシンまたは物理マシンをターゲットにすることができます。

Azure Monitor ログを使用して、このデータを送信するように Azure Automation State Configuration を構成することで、ノードの遵守状況を確認できます。

PowerShell DSC とは

PowerShell DSC は、システムの構成、デプロイ、および制御を行うために Azure Automation State Configuration によって使用される宣言型の管理プラットフォームです。 宣言型プログラミング言語では、意図 (行うこと) が実行 (行う方法) から分離されます。 ユーザーは必要な状態を指定し、その状態になるための作業は DSC に任せます。 DSC リソースが使用可能な場合は、機能を実装またはデプロイする方法を知る必要はありません。 代わりに、デプロイの構造体にフォーカスすることができます。

既に PowerShell を使用している場合は、なぜ DSC が必要なのか不思議に思うかもしれません。 次の例を考えてみます。

Windows サーバーで共有を作成する場合は、次の PowerShell コマンドを使用できます。

# Create a file share
New-SmbShare -Name MyFileShare -Path C:\Shared -FullAccess User1 -ReadAccess User2

これは簡単でわかりやすいスクリプトです。 ただし、運用環境でこのスクリプトを使用すると、いくつかの問題が発生します。 このスクリプトを複数回実行する場合、または User2 が読み取り専用アクセスではなく、すでにフル アクセスを持っている場合に、どうなるかを考えてみましょう。

このアプローチは "べき等" ではありません。 べき等は、1 回実行しても 10,001 回実行しても同じ効果を持つ操作を表します。 PowerShell でべき等を実現するには、ロジックとエラー処理を追加する必要があります。 ファイル共有が存在しない場合は、それを作成します。 共有が存在する場合は、それを作成する必要はありません。 User2 が存在しても読み取りアクセス権がない場合は、読み取りアクセス権を追加します。

PowerShell スクリプトは次のようになります。

$shareExists = $false
$smbShare = Get-SmbShare -Name $Name -ErrorAction SilentlyContinue
if($smbShare -ne $null)
{
    Write-Verbose -Message "Share with name $Name exists"
    $shareExists = $true
}

if ($shareExists -eq $false)
{
    Write-Verbose "Creating share $Name to ensure it is Present"
    New-SmbShare @psboundparameters
}
else
{
    # Need to call either Set-SmbShare or *ShareAccess cmdlets
    if ($psboundparameters.ContainsKey("ChangeAccess"))
    {
       #...etc., etc., etc
    }
}

検討していないその他の特殊なケースは、問題が発生した場合にのみ明らかになります。 DSC では、予期しないケースが自動的に処理されます。 DSC では、結果を実現するためのプロセスではなく、結果を記述します。

次の DSC コード スニペットに例を示します。

Configuration Create_Share
{
   Import-DscResource -Module xSmbShare
   # A node describes the VM to be configured

   Node $NodeName
   {
      # A node definition contains one or more resource blocks
      # A resource block describes the resource to be configured on the node
      xSmbShare MySMBShare
      {
          Ensure      = "Present"
          Name        = "MyFileShare"
          Path        = "C:\Shared"
          ReadAccess  = "User1"
          FullAccess  = "User2"
          Description = "This is an updated description for this share"
      }
   }
}

前の例では、ファイル共有の状態を確認する方法を DSC に指示する xSmbShare モジュールを使用しています。 DSC リソース キットには、100 を超えるリソース モジュールがあり、その中には IIS サイトのインストール用モジュールもあります。 このモジュールの最後にある「まとめ」ユニットに、DSC リソース キットへのリンクがあります。

PowerShell DSC コードの構造の詳細については、次のユニットで学習します。

LCM とは

ローカル構成マネージャー (LCM) は、Windows オペレーティング システム上の Windows Management Framework (WMF) のコンポーネントです。 LCM は、必要な状態と一致するようにノードの状態 (VM など) を更新する役割を担います。 LCM では、実行するたびに次の手順が行われます。

  1. 取得: ノードの現在の状態を取得します。
  2. テスト: コンパイル済みの DSC スクリプト (.mof ファイル) を使用して、ノードの現在の状態を望ましいと比較します。
  3. 設定: .mof ファイルに記述されている望ましい状態と一致するようにノードを更新します。

Azure Automation で VM を登録するときに、LCM を構成することになります。

DSC でのプッシュおよびプル アーキテクチャ

各ノードの LCM は、2 つのモードで動作できます。

  • プッシュ モード: 管理者は、1 つ以上のノードに対して構成を手動で送信 ("プッシュ") します。 LCM により、各ノードの状態が構成で指定されているものと確実に一致するようになります。

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

  • プル モード: 構成情報は "プル サーバー" に保持されます。 各ノード上の LCM はプル サーバーに定期的 (既定では 15 分ごと) にポーリングを行い、最新の構成情報を取得します。 この要求は、次の図のステップ 1 で示されています。 ステップ 2 では、構成の変更に関する詳細を、プル サーバーが各ノードに返信しています。

    プル モードでは、各ノードをプル サービスに登録する必要があります。

    DSC のプル アーキテクチャを示す図。

どちらのモードにも利点があります。

  • プッシュ モードは簡単に設定できます。 独自の専用インフラストラクチャは必要なく、ノート PC で実行できます。 プッシュ モードは、DSC の機能をテストするのに役立ちます。 プッシュ モードを使用して、新しくイメージ化されたマシンをベースラインの必要な状態にすることもできます。
  • プル モードは、多数のマシンにまたがるエンタープライズ デプロイの場合に便利です。 LCM によりプル サーバーが定期的にポーリングされ、ノードが必要な状態になっていることが確認されます。 外部のツールまたはチームによって適用された修正プログラムにより、個々のマシンの構成に違いが発生した場合、それらのマシンは設定されている構成と一致するように直ちに戻されます。 このプロセスは、セキュリティと規制の義務への継続的なコンプライアンスの状態を実現するのに役立ちます。

サポートされているプラットフォームとオペレーティング システム

Azure Automation DSC は、Azure Cloud Services および他のクラウド プロバイダー、オンプレミスのインフラストラクチャ、またはこれらすべての環境のハイブリッドでサポートされています。

Azure Automation DSC では、次のオペレーティング システムがサポートされています。

  • Windows
    • Server 2022
    • Server 2019
    • Server 2016
    • Server 2012 R2
    • Server 2012
    • Server 2008 R2 SP1
    • 11
    • 10
    • 8.1
    • 7
  • Linux

PowerShell DSC は Azure Automation DSC でサポートされているすべての Linux マシンにインストールされます。

Windows の DSC 要件

Windows マシンの場合、Azure Desired State Configuration (DSC) VM 拡張機能で、WMF を使用して、Windows PowerShell DSC や Windows リモート管理 (WinRM) などの Windows 機能のバージョンが管理されます。 Azure DSC でサポートされているのは WMF 4.0 以降であるため、Windows マシンは Windows Server 2008 R2 SP1、Windows 7 以降を実行している必要があります。

初めて Azure DSC 拡張機能を呼び出すときに、OS と互換性のある WMF のバージョンが、Windows Server 2016 以降を除くすべての Windows バージョンにインストールされます。 Windows Server 2016 以降のバージョンには、WMF の最新バージョンが既にインストールされています。 WMF のインストール後に、マシンを再起動する必要があります。

WinRM は、Windows Server 2012 以降、および Windows 7 以降が実行されているマシン ノードで有効になっています。

DSC エージェントのプロキシは、Windows ビルド 1809 以降でサポートされます。 以前のバージョンの Windows に対する DSC では、プロキシはサポートされません。

その他の DSC 要件

ノードがプライベート ネットワークにある場合、DSC が Azure Automation と通信するには、次のポートと URL が必要です。

  • ポート: 送信インターネット アクセスには TCP 443 のみが要求されます
  • グローバル URL: *.azure-automation.net
  • US Gov バージニアのグローバル URL: *.azure automation.us
  • エージェント サービス: https://<workspaceId>.agentsvc.azure-automation.net

自分の知識をチェックする

1.

Azure Automation State Configuration とは何ですか?

2.

PowerShell DSC スクリプトの説明で正しいものはどれですか?

3.

DSC にプッシュ モードではなくプル モードを使用する必要があるのはなぜですか?