WindowsServer 2025 総合ガイド 第12回
DSC v3 入門 ― 宣言的構成管理の世界へ
基礎編(第1回〜第11回)では、Windows Server 2025の環境構築からPowerShellの基本操作、サービス管理、ネットワーク設定、ファイアウォール、イベントログ、リモート管理、役割と機能の追加、セキュリティ設定まで、サーバー管理に必要な基本スキルを手動で習得してきました。応用編となる今回からは、これらの手動設定を「コード」で自動化する方法を学んでいきます。第12回では、構成管理ツール「DSC v3(Desired State Configuration version 3)」の概念と基本操作を理解しましょう。
12.1 この記事で学ぶこと
- Infrastructure as Code(IaC)の概念と利点を理解する
- DSCの「宣言的」アプローチと「冪等性」の概念を理解する
- DSC v3をインストールし、基本コマンドを実行できる
- DSCリソースの概念を理解し、リソースの状態を確認できる
12.2 前提条件
- 基礎編完了(第1回〜第11回)
- PowerShellスクリプティングの基礎を理解していること(第4回)
- Windows Server 2025にリモートデスクトップ接続できる状態
- PowerShell 7.4を管理者として起動できる状態
12.3 Infrastructure as Code(IaC)とは
応用編の最初のテーマは「Infrastructure as Code(IaC)」です。まず、この概念を理解することから始めましょう。
12.3.1 IaCの概念
Infrastructure as Code(IaC)とは、サーバーやネットワークなどのインフラ構成を、手作業ではなく「コード(設定ファイル)」として定義・管理する手法です。
基礎編では、PowerShellのコマンドを1つずつ実行してサーバーを設定してきました。たとえば、第5回で学んだサービスの設定は以下のような手順でした。
[実行環境: PowerShell 7.4 (管理者)]
# 手動での設定手順(命令的アプローチ)
# 1. サービスの状態を確認する
Get-Service -Name "W32Time"
# 2. サービスが停止していたら起動する
Start-Service -Name "W32Time"
# 3. スタートアップの種類を「自動」に変更する
Set-Service -Name "W32Time" -StartupType Automatic
この方法は、手順を1つずつ実行するため直感的でわかりやすい反面、以下のような課題があります。
- 再現性の問題:手順書通りに実行しても、人によって微妙な差異が生まれることがある
- スケーラビリティの問題:サーバーが10台、100台と増えた場合、すべてに同じ設定を手動で適用するのは現実的ではない
- ドキュメントとの乖離:手順書と実際の設定が時間とともにずれていく
IaCでは、サーバーの「あるべき状態」を設定ファイルとして記述します。この設定ファイル自体がインフラの「ドキュメント」となり、そのままシステムに適用することで、何台のサーバーに対しても同一の設定を確実に展開できます。
12.3.2 IaCのメリット
IaCを導入することで、以下のようなメリットが得られます。
| メリット | 説明 | 具体例 |
|---|---|---|
| 手作業によるミスの削減 | 設定内容がコードとして定義されるため、手順の抜け漏れや誤入力が起こりにくい | ファイアウォールのポート番号を間違えるリスクが減る |
| 環境の一貫性 | 同じ設定ファイルを使えば、どのサーバーにも同一の構成を適用できる | 開発環境と本番環境の設定差異をなくせる |
| バージョン管理が可能 | 設定ファイルをGit等で管理することで、変更履歴の追跡や以前の状態への復元が容易になる | 「いつ、誰が、何を変更したか」を記録できる |
| ドキュメントとしての役割 | 設定ファイル自体が「現在のインフラ構成」のドキュメントになる | 手順書と実態の乖離が発生しない |
| 再現性の確保 | 同じコードを実行すれば、何度でも同じ結果が得られる | 障害時の環境再構築が迅速に行える |
基礎編との関連: 第11回で学んだセキュリティテンプレート(INFファイル)を思い出してください。セキュリティ設定をファイルにエクスポートし、別のサーバーにインポートするアプローチは、IaCの考え方に近いものでした。IaCはこの考え方をさらに体系化・発展させたものです。
12.3.3 構成管理ツールの種類
IaCを実現するためのツールは複数存在します。代表的なものを簡単に紹介します。
| ツール | 開発元 | 特徴 |
|---|---|---|
| DSC v3 | Microsoft | Windows Server / PowerShellとの親和性が高い。本シリーズで使用 |
| Ansible | Red Hat | エージェントレス。Linux環境で広く普及。YAMLで記述 |
| Chef | Progress Software | Rubyベースのレシピで構成を定義 |
| Puppet | Perforce | 独自DSLで構成を定義。大規模環境向け |
本シリーズでは、Windows Server環境との親和性が最も高いDSC v3を使用します。DSC v3はMicrosoftが開発した構成管理ツールで、PowerShellとの統合が優れており、Windows Serverの管理に最適です。他のツールとの詳細な比較は本シリーズの範囲外ですが、DSCで学ぶ「宣言的な構成管理」の概念は、他のツールにも共通するものです。
12.4 DSC(Desired State Configuration)とは
DSCは「Desired State Configuration」の略で、日本語にすると「望ましい状態の構成」です。その名の通り、システムの「あるべき状態(Desired State)」を定義し、システムをその状態に維持するためのツールです。
12.4.1 DSCの概念
DSCの基本的な考え方は非常にシンプルです。
- 「あるべき状態」を定義する:構成ファイル(YAML形式)に「サーバーがどうあるべきか」を記述する
- 現在の状態と比較する:DSCが現在のサーバーの状態と、定義した「あるべき状態」を比較する
- 差異があれば修正する:差異が見つかった場合、DSCが自動的にサーバーを「あるべき状態」に変更する
たとえば、「W32Time(Windows Time)サービスは常に起動していて、スタートアップの種類は『自動』であるべき」という状態を定義しておけば、DSCはその状態を実現し、維持します。
12.4.2 宣言的(Declarative)と命令的(Imperative)
DSCを理解するうえで最も重要な概念が、「宣言的」と「命令的」の違いです。基礎編で書いてきたPowerShellスクリプトと比較して説明します。
命令的(Imperative)アプローチ ― 「どうやるか」を記述する
基礎編で学んだPowerShellスクリプトは「命令的」なアプローチです。「何をするか」の手順を1つずつ記述します。
[実行環境: PowerShell 7.4 (管理者)]
# 命令的アプローチ:手順を1つずつ記述する
# 「どのように(How)」サービスを設定するかを書く
# 手順1: サービスの現在の状態を取得する
$service = Get-Service -Name "W32Time"
# 手順2: サービスが停止していたら起動する
if ($service.Status -ne "Running") {
Start-Service -Name "W32Time"
Write-Host "W32Timeサービスを起動しました" -ForegroundColor Green
}
# 手順3: スタートアップの種類を確認し、「自動」でなければ変更する
if ($service.StartType -ne "Automatic") {
Set-Service -Name "W32Time" -StartupType Automatic
Write-Host "スタートアップの種類を「自動」に変更しました" -ForegroundColor Green
}
宣言的(Declarative)アプローチ ― 「何を達成したいか」を記述する
DSCでは「宣言的」なアプローチを取ります。「最終的にどうなっていてほしいか(What)」だけを記述し、「どうやってその状態にするか(How)」はDSCに任せます。
# 宣言的アプローチ:「あるべき状態」だけを記述する
# 「何を(What)」達成したいかだけを書く
$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2024/04/config/document.json
resources:
- name: W32Timeサービスの設定
type: Microsoft.Windows/WindowsPowerShell
properties:
resources:
- name: Ensure W32Time is running
type: PSDesiredStateConfiguration/Service
properties:
Name: W32Time
State: Running
StartupType: Automatic
両者の違いを表にまとめます。
| 観点 | 命令的(Imperative) | 宣言的(Declarative) |
|---|---|---|
| 記述する内容 | 手順(How) | 目標状態(What) |
| 例え | 料理のレシピ(手順を1つずつ記述) | 料理の完成写真(最終形を示す) |
| 状態の判断 | 自分で条件分岐を書く必要がある | DSCが自動的に判断する |
| 代表的なツール | PowerShellスクリプト、バッチファイル | DSC、Ansible、Terraform |
| 基礎編での例 | Start-Service、Set-Serviceを順番に実行 |
「このサービスはRunningであるべき」と定義 |
ポイント: 宣言的アプローチでは、「サービスが既に起動しているかどうか」の判断をDSCが行います。命令的アプローチのように
if文で条件分岐を書く必要がありません。これにより、構成ファイルがシンプルで読みやすくなります。
12.4.3 冪等性(Idempotent)
DSCのもう1つの重要な概念が「冪等性(べきとうせい)」です。冪等性とは、同じ操作を何度実行しても結果が変わらない性質のことです。
命令的アプローチの場合、同じスクリプトを2回実行すると問題が起きることがあります。
[実行環境: PowerShell 7.4 (管理者)]
# 命令的アプローチの問題:冪等性がない例
# ファイアウォール規則を追加するスクリプト(第7回の内容)
# 1回目の実行:規則が作成される → OK
New-NetFirewallRule -DisplayName "Allow HTTP" -Direction Inbound -Protocol TCP -LocalPort 80 -Action Allow
# 2回目の実行:同名の規則が既に存在するためエラーになる → NG
# エラー: New-NetFirewallRule: Cannot create a file when that file already exists.
この問題を回避するには、「既に存在するか確認してから作成する」という条件分岐を追加する必要があります。
# 冪等性を自分で実装する場合
$existingRule = Get-NetFirewallRule -DisplayName "Allow HTTP" -ErrorAction SilentlyContinue
if (-not $existingRule) {
New-NetFirewallRule -DisplayName "Allow HTTP" -Direction Inbound -Protocol TCP -LocalPort 80 -Action Allow
}
DSCの宣言的アプローチでは、この冪等性が自動的に保証されます。「HTTP通信を許可するファイアウォール規則が存在すべき」と定義しておけば、DSCは以下のように動作します。
- 規則が存在しない場合:規則を作成する
- 規則が既に存在する場合:何もしない(既に「あるべき状態」のため)
- 規則の設定が異なる場合:正しい設定に修正する
つまり、DSCの構成を何度適用しても、サーバーは常に同じ「あるべき状態」に収束します。これにより、安心して繰り返し構成を適用できます。
12.5 DSC v3の特徴
DSCには複数のバージョンが存在します。本シリーズでは最新のDSC v3を使用します。ここでは、DSC v3の特徴と、従来バージョンとの違いを説明します。
12.5.1 DSC v2からDSC v3への進化
DSC v3は2025年3月にバージョン3.0.0がGA(General Availability:一般提供)となり、その後2025年6月にバージョン3.1.0がリリースされました。従来のDSC v2(PowerShell Desired State Configuration v1.1およびv2)から大幅にアーキテクチャが変更されています。
| 項目 | DSC v2(従来版) | DSC v3 |
|---|---|---|
| 依存関係 | Windows PowerShell 5.1が必須 | PowerShell 7.2以降(本シリーズでは7.4以降を使用) |
| 実行方式 | LCM(Local Configuration Manager)というサービスが常駐 | スタンドアロンのコマンドとして実行。サービス不要 |
| 構成ファイル形式 | MOF(Managed Object Format)ファイル | YAML / JSON形式 |
| プラットフォーム | Windowsのみ | Windows / Linux / macOS(クロスプラットフォーム) |
| 実装言語 | PowerShellベース | Rust製の単一実行ファイル。PowerShellがなくても動作可能 |
| リソースの互換性 | ― | 既存のPowerShell DSCリソースをアダプター経由で利用可能 |
12.5.2 DSC v3の主要な変更点
LCM(Local Configuration Manager)が不要に
DSC v2では、LCM(Local Configuration Manager)と呼ばれるサービスがWindows上で常駐し、構成の適用や監視を行っていました。DSC v3ではLCMが廃止され、dscコマンドを直接実行する方式に変わりました。これにより、以下のメリットが生まれます。
- シンプルな実行モデル:コマンドを実行するだけで構成を適用できる
- 統合の容易さ:タスクスケジューラやCI/CDパイプラインなど、コマンドを実行できるツールなら何でもDSCを呼び出せる
- リソース消費の削減:常駐サービスが不要なため、システムリソースの消費が少ない
YAML / JSON形式の構成ファイル
DSC v2ではMOF(Managed Object Format)という独自形式のファイルを使用していましたが、DSC v3ではYAMLまたはJSON形式で構成を記述します。YAMLは人間が読み書きしやすいデータ形式で、多くの構成管理ツールで採用されています。YAML構文の詳細は次回(第13回)で学びます。
クロスプラットフォーム対応
DSC v3はRust言語で実装された単一の実行ファイル(dsc / dsc.exe)として動作します。Windows、Linux、macOSで利用可能です。本シリーズではWindows Server 2025での使用に焦点を当てますが、学んだ概念はLinux環境でも応用できます。
重要: 本シリーズではDSC v3のみを扱います。DSC v2(LCM、MOFファイル中心のアプローチ)は扱いません。インターネット上でDSCに関する情報を検索する際は、DSC v3の情報であることを確認してください。DSC v2の情報をDSC v3に適用するとエラーが発生する場合があります。
12.5.3 DSC v3の現状と注意点
DSC v3は2025年にGA(一般提供)されたばかりの比較的新しいツールです。以下の点を認識しておきましょう。
- 急速に発展中:DSC v3.0.0が2025年3月にGA、v3.1.0が2025年6月にリリースされ、開発が活発に続いています。バージョンアップに伴いコマンドや仕様が変更される可能性があります
- 組み込みリソースは限定的:DSC v3にネイティブで組み込まれているリソースは、レジストリ管理やOS情報取得など基本的なものに限られます。ただし、アダプター機能を通じて既存のPowerShell DSCリソース(PSDesiredStateConfiguration モジュール等)を利用できます
- ドキュメントの整備は進行中:公式ドキュメントは継続的に拡充されていますが、従来のDSC v2と比較するとまだ発展途上の部分があります
これらの点を踏まえたうえで、DSC v3は「構成管理の概念を学ぶ」「基本的な自動化を実践する」という目的には十分に活用できます。
12.6 DSC v3のインストール
ここからは実際にDSC v3をインストールし、使い始める準備を行います。
12.6.1 前提条件の確認
DSC v3をインストールする前に、前提条件が満たされていることを確認します。
[実行環境: PowerShell 7.4 (管理者)]
# PowerShellのバージョンを確認(7.4以降であること)
$PSVersionTable.PSVersion
実行結果の例:
Major Minor Patch PreReleaseLabel BuildLabel
----- ----- ----- --------------- ----------
7 4 6
PowerShell 7.4以降がインストールされていない場合は、第2回の手順に従ってインストールしてください。
# wingetが利用可能か確認
winget --version
実行結果の例:
v1.9.25200
注意: wingetはWindows Server 2025のDesktop Experienceに標準搭載されています。Server Coreではwingetが利用できないため、DSC v3のインストール方法が異なります(GitHubリリースページからの手動ダウンロードが必要)。本シリーズではDesktop Experienceを前提としています。
12.6.2 wingetによるインストール
DSC v3は、Microsoft Storeを通じてwingetでインストールできます。以下のコマンドを実行してください。
[実行環境: PowerShell 7.4 (管理者)]
# DSC v3のインストール
# Microsoft Store経由でインストールすると、自動更新が有効になります
winget install --id 9NVTPZWRC6KQ --source msstore --accept-package-agreements --accept-source-agreements
実行結果の例:
Found DesiredStateConfiguration [9NVTPZWRC6KQ] Version Unknown
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Successfully installed
Tips:
winget search DesiredStateConfigurationを実行すると、利用可能なパッケージを確認できます。「DesiredStateConfiguration」が安定版、「DesiredStateConfiguration-Preview」がプレビュー版です。本シリーズでは安定版を使用します。
12.6.3 インストール確認
インストールが完了したら、dscコマンドが使えることを確認します。
[実行環境: PowerShell 7.4 (管理者)]
# DSCのバージョンを確認
dsc --version
実行結果の例:
3.1.0
注意:
dscコマンドが見つからない場合は、PowerShellを一度閉じて再起動してください。インストール時にPATH環境変数が更新されますが、既存のセッションには反映されないことがあります。
dscコマンドのヘルプを表示して、利用可能なサブコマンドを確認しましょう。
# DSCコマンドのヘルプを表示
dsc --help
実行結果の例:
DSC v3.1.0
Desired State Configuration
Usage: dsc [OPTIONS] <COMMAND>
Commands:
config Apply a configuration document
resource Invoke a specific DSC Resource
schema Get the JSON schema for a DSC type
help Print this message or the help of the given subcommand(s)
Options:
-t, --trace-level <TRACE_LEVEL> Trace level [possible values: error, warn, info, debug, trace]
-o, --output-format <OUTPUT_FORMAT> Output format [possible values: json, pretty-json, yaml, json-array, pass-through]
-h, --help Print help
-V, --version Print version
主要なサブコマンドは2つです。
| サブコマンド | 説明 |
|---|---|
dsc config |
構成ファイル(YAMLやJSON)を使って、複数のリソースをまとめて操作する |
dsc resource |
個別のDSCリソースを直接操作する |
12.6.4 PSDesiredStateConfigurationモジュールのインストール
DSC v3の組み込みリソースだけでなく、従来のPowerShell DSCリソース(サービス管理、Windows機能の管理など)を使用するために、PSDesiredStateConfigurationモジュールをインストールします。
[実行環境: PowerShell 7.4 (管理者)]
# PSDesiredStateConfigurationモジュールのインストール
Install-Module -Name PSDesiredStateConfiguration -Repository PSGallery -Force
実行結果の例:
Installing package 'PSDesiredStateConfiguration'
Downloaded 0.00 MB out of 0.37 MB.
# インストールされたモジュールを確認
Get-Module -Name PSDesiredStateConfiguration -ListAvailable |
Select-Object -Property Name, Version, ModuleBase
実行結果の例:
Name Version ModuleBase
---- ------- ----------
PSDesiredStateConfiguration 2.0.7 C:\Program Files\PowerShell\Modules\PSDesiredStateConfiguration\2.0.7
解説: PSDesiredStateConfigurationモジュールは、DSC v3のアダプター機能を通じて利用されます。このモジュールにはService(サービス管理)、WindowsFeature(Windows機能の管理)、File(ファイル管理)、Environment(環境変数管理)など、Windows Serverの管理に便利なリソースが含まれています。
12.7 基本コマンドの理解
DSC v3の基本コマンドを学んでいきましょう。DSC v3のコマンドは、dsc resource(個別リソースの操作)とdsc config(構成ファイルによる一括操作)の2つに大別されます。今回はdsc resourceコマンドを中心に学びます。
12.7.1 dsc resource list ― 利用可能なリソースの一覧
dsc resource list は、システムにインストールされているDSCリソースの一覧を表示するコマンドです。まず、DSC v3に組み込まれているリソースを確認しましょう。
[実行環境: PowerShell 7.4 (管理者)]
# 利用可能なDSCリソースの一覧を表示
dsc resource list
実行結果の例:
Type Kind Version Caps RequireAdapter Description
---- ---- ------- ---- -------------- -----------
Microsoft.DSC.Transitional/RunCommandOnSet Resource 0.1.0 gs------ …
Microsoft.DSC/Assertion Group 0.1.0 gs--t--- …
Microsoft.DSC/Group Group 0.1.0 gs--t--- …
Microsoft.DSC/PowerShell Adapter 0.1.0 gs--t-e- …
Microsoft.Windows/RebootPending Resource 0.1.0 g------- …
Microsoft.Windows/Registry Resource 0.1.0 gs-w-d-- …
Microsoft.Windows/WMI Adapter 0.1.0 g------- …
Microsoft/OSInfo Resource 0.1.0 g------e …
表示されるリソースの情報を理解しましょう。
| 列名 | 説明 |
|---|---|
| Type | リソースの完全修飾名。所有者/名前の形式(例:Microsoft.Windows/Registry) |
| Kind | リソースの種別。Resource(通常のリソース)、Group(グループ)、Adapter(アダプター) |
| Version | リソースのバージョン |
| Caps | リソースの機能(g=get, s=set, w=whatIf, t=test, d=delete, e=export) |
上記はDSC v3に組み込まれているリソースです。PowerShell DSCリソース(PSDesiredStateConfigurationモジュール)を使用するには、アダプターを指定してリソースを一覧表示します。
# PowerShellアダプター経由のリソースを一覧表示
dsc resource list --adapter Microsoft.DSC/PowerShell
実行結果の例(一部抜粋):
Type Kind Version Caps RequireAdapter
---- ---- ------- ---- --------------
PSDesiredStateConfiguration/Archive Resource 1.1 gs--t--- Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/Environment Resource 1.1 gs--t--- Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/File Resource 1.0.0 gs--t--- Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/Group Resource 1.1 gs--t--- Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/Log Resource 1.1 gs--t--- Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/MsftDscPackage Resource 1.0.0.0 gs--t--- Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/ProcessSet Resource 1.1 gs--t--- Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/Registry Resource 1.1 gs--t--- Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/Script Resource 1.1 gs--t--- Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/Service Resource 1.1 gs--t--- Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/ServiceSet Resource 1.1 gs--t--- Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/User Resource 1.1 gs--t--- Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/WindowsFeature Resource 1.1 gs--t--- Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/WindowsFeatureSet Resource 1.1 gs--t--- Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/WindowsOptionalFeature Resource 1.0 gs--t--- Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/WindowsOptionalFeatureSet Resource 1.0 gs--t--- Microsoft.DSC/PowerShell
PSDesiredStateConfiguration/WindowsProcess Resource 1.1 gs--t--- Microsoft.DSC/PowerShell
解説:
RequireAdapter列にMicrosoft.DSC/PowerShellと表示されているリソースは、PowerShellアダプター経由で呼び出されるリソースです。基礎編で学んだサービス管理(PSDesiredStateConfiguration/Service)やWindows機能の管理(PSDesiredStateConfiguration/WindowsFeature)など、実用的なリソースが豊富に用意されています。
注意: アダプター経由のリソース一覧を初めて表示する際は、リソースの検出に時間がかかることがあります(数十秒程度)。これはDSCがPowerShellモジュールを検索してキャッシュを構築するためです。2回目以降はキャッシュが利用されるため高速になります。
12.7.2 dsc resource get ― リソースの現在の状態を取得
dsc resource get は、指定したリソースの現在の状態を取得するコマンドです。「今、サーバーがどういう状態にあるか」を確認できます。
組み込みリソースの場合
まず、組み込みリソースのMicrosoft/OSInfoを使ってOS情報を取得してみましょう。
[実行環境: PowerShell 7.4 (管理者)]
# OS情報を取得する
dsc resource get --resource Microsoft/OSInfo
実行結果の例:
actualState:
$id: https://developer.microsoft.com/json-schemas/dsc/os_info/20230303/Microsoft.DSC.OS_Info.schema.json
family: Windows
version: 10.0.26100
edition: Windows Server 2025 Datacenter
bitness: "64"
architecture: x86_64
このコマンドは入力(--input)を必要としません。Microsoft/OSInfoリソースはシステム情報を取得するだけの読み取り専用リソースです。
入力が必要なリソースの場合
多くのリソースでは、「どのリソースインスタンスの状態を取得するか」を指定するための入力が必要です。たとえば、レジストリリソースでは「どのレジストリキーの状態を取得するか」を指定します。
# レジストリの状態を取得する(キーパスを入力として指定)
dsc resource get --resource Microsoft.Windows/Registry --input "keyPath: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion"
実行結果の例:
actualState:
keyPath: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion
_exist: true
入力の指定方法には以下のオプションがあります。
| オプション | 短縮形 | 説明 |
|---|---|---|
--resource |
-r |
リソースの完全修飾名(必須) |
--input |
-i |
入力をYAMLまたはJSON文字列で直接指定 |
--file |
-f |
入力をYAMLまたはJSONファイルで指定 |
Tips: DSC v3はコンソールに直接出力する場合はYAML形式で、パイプラインに出力する場合はJSON形式をデフォルトで使用します。出力形式を明示的に指定するには
--output-format(-o)オプションを使用します(例:-o json、-o yaml、-o pretty-json)。
12.7.3 dsc resource test ― 現在の状態と目標状態の比較
dsc resource test は、リソースの現在の状態と、指定した目標状態を比較するコマンドです。実際に変更は行わず、「差異があるかどうか」だけを確認します。
[実行環境: PowerShell 7.4 (管理者)]
# レジストリキーの存在をテストする
dsc resource test --resource Microsoft.Windows/Registry --input "keyPath: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion"
実行結果の例:
desiredState:
keyPath: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion
actualState:
keyPath: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion
_exist: true
inDesiredState: true
differingProperties: []
テスト結果の読み方を確認しましょう。
| フィールド | 説明 |
|---|---|
desiredState |
指定した目標状態(入力として渡した内容) |
actualState |
現在のシステムの実際の状態 |
inDesiredState |
true = 既に目標状態、false = 変更が必要 |
differingProperties |
目標状態と異なるプロパティの一覧(差異がない場合は空配列) |
存在しないレジストリキーをテストすると、差異が検出されます。
# 存在しないレジストリキーをテストする
dsc resource test --resource Microsoft.Windows/Registry --input "keyPath: HKLM\SOFTWARE\DSCTest\NonExistent"
実行結果の例:
desiredState:
keyPath: HKLM\SOFTWARE\DSCTest\NonExistent
actualState:
keyPath: HKLM\SOFTWARE\DSCTest\NonExistent
_exist: false
inDesiredState: false
differingProperties:
- _exist
inDesiredState: false は「目標状態ではない(変更が必要)」を意味し、differingProperties に _exist が表示されていることから、「キーが存在しない」ことが差異の原因であることがわかります。
12.7.4 dsc resource set ― リソースの状態を設定
dsc resource set は、リソースを指定した目標状態に設定するコマンドです。実際にシステムに変更を加えます。
[実行環境: PowerShell 7.4 (管理者)]
# テスト用のレジストリキーを作成する
dsc resource set --resource Microsoft.Windows/Registry --input "keyPath: HKLM\SOFTWARE\DSCTest"
実行結果の例:
beforeState:
keyPath: HKLM\SOFTWARE\DSCTest
_exist: false
afterState:
keyPath: HKLM\SOFTWARE\DSCTest
_exist: true
changedProperties:
- _exist
set コマンドの出力は以下の情報を含みます。
| フィールド | 説明 |
|---|---|
beforeState |
変更前の状態 |
afterState |
変更後の状態 |
changedProperties |
実際に変更されたプロパティの一覧 |
冪等性を確認するために、同じコマンドをもう一度実行してみましょう。
# 同じコマンドを再度実行する(冪等性の確認)
dsc resource set --resource Microsoft.Windows/Registry --input "keyPath: HKLM\SOFTWARE\DSCTest"
実行結果の例:
beforeState:
keyPath: HKLM\SOFTWARE\DSCTest
_exist: true
afterState:
keyPath: HKLM\SOFTWARE\DSCTest
_exist: true
changedProperties: []
2回目の実行では、beforeStateが既に_exist: trueであるため、何も変更されません(changedPropertiesが空配列)。これが冪等性です。
# テスト用に作成したレジストリキーを削除する(PowerShellで)
Remove-Item -Path "HKLM:\SOFTWARE\DSCTest" -Force
重要:
dsc resource setはシステムに実際の変更を加えます。本番環境では、必ずdsc resource testで事前に差異を確認してからsetを実行する習慣をつけてください。これは第13回以降で学ぶ「テストファースト」の原則に通じます。
12.7.5 基本コマンドのまとめ
ここまで学んだDSC v3の基本コマンドをまとめます。
| コマンド | 操作 | 変更の有無 | 用途 |
|---|---|---|---|
dsc resource list |
リソース一覧を表示 | なし | 利用可能なリソースの確認 |
dsc resource get -r <type> |
現在の状態を取得 | なし | 現状把握 |
dsc resource test -r <type> -i <input> |
目標との差異を確認 | なし | 事前確認 |
dsc resource set -r <type> -i <input> |
目標状態に設定 | あり | 状態の適用 |
また、構成ファイル(YAML/JSON)を使って複数のリソースをまとめて操作するコマンドもあります。こちらは第13回で詳しく学びます。
| コマンド | 操作 | 変更の有無 |
|---|---|---|
dsc config get -f <file> |
構成ファイルの現在状態を取得 | なし |
dsc config test -f <file> |
構成ファイルと現在状態の差異を確認 | なし |
dsc config set -f <file> |
構成ファイルの内容を適用 | あり |
12.8 リソースの概念
DSCを使いこなすためには、「リソース」の概念をしっかり理解する必要があります。
12.8.1 リソースとは
DSCにおけるリソース(Resource)とは、管理対象の単位です。たとえば、以下のようなものがリソースとして定義されています。
| リソース | 管理対象 | 基礎編での対応 |
|---|---|---|
Microsoft.Windows/Registry |
Windowsレジストリ | 第11回:セキュリティ設定 |
PSDesiredStateConfiguration/Service |
Windowsサービス | 第5回:サービス管理 |
PSDesiredStateConfiguration/WindowsFeature |
Windowsの役割と機能 | 第10回:役割と機能の追加 |
PSDesiredStateConfiguration/File |
ファイルとディレクトリ | 第3回:ファイルシステム管理 |
PSDesiredStateConfiguration/Environment |
環境変数 | ― |
PSDesiredStateConfiguration/User |
ローカルユーザー | 第3回:ユーザー管理 |
各リソースは、対象の「状態を取得する(get)」「状態をテストする(test)」「状態を設定する(set)」といった操作を持っています。リソースの内部で、実際にどのようなPowerShellコマンドやAPIが実行されるかは、リソースの実装に隠蔽されています。利用者は「あるべき状態」を宣言するだけで済みます。
12.8.2 リソースの種別
DSC v3には、以下の3種類のリソースがあります。
| 種別(Kind) | 説明 | 例 |
|---|---|---|
| Resource | 通常のリソース。特定の管理対象に対する操作を提供する | Microsoft.Windows/Registry、Microsoft/OSInfo |
| Adapter | 外部のリソースプロバイダーとDSC v3を橋渡しする | Microsoft.DSC/PowerShell、Microsoft.Windows/WindowsPowerShell |
| Group | 複数のリソースをグループ化して扱う | Microsoft.DSC/Group、Microsoft.DSC/Assertion |
特に重要なのがAdapterです。DSC v3はRust製のツールですが、アダプターを通じてPowerShellベースの既存DSCリソースを呼び出すことができます。
- Microsoft.DSC/PowerShell:PowerShell 7.x用のDSCリソースを呼び出すアダプター
- Microsoft.Windows/WindowsPowerShell:Windows PowerShell 5.1用のDSCリソースを呼び出すアダプター
本シリーズでは、構成ファイルの中でPowerShellアダプターを通じてPSDesiredStateConfigurationモジュールのリソースを利用する方法を、次回以降で学びます。
12.8.3 リソースプロバイダーの仕組み
DSC v3のリソースは、以下のような仕組みで動作しています。
- DSC v3コマンド(
dsc)が構成ファイルまたはコマンドライン引数を受け取る - 指定されたリソースタイプに応じて、リソースプロバイダー(実行ファイルやPowerShellモジュール)を呼び出す
- リソースプロバイダーが実際のシステム操作(レジストリの読み書き、サービスの起動・停止など)を実行する
- 結果がJSON形式でDSC v3に返される
リソースプロバイダーの実装方法は多様です。組み込みリソース(Microsoft.Windows/Registryなど)はDSC v3の実行ファイルに含まれていますが、PowerShellモジュールとして実装されたリソースはアダプター経由で呼び出されます。また、bash、Python、C#、Goなど、さまざまな言語で独自のリソースを作成することも可能です。
12.9 実践:リソースの状態確認
ここまでの知識を活用して、実際にDSCでリソースの状態を確認してみましょう。基礎編で手動管理していた対象を、DSCで確認する方法を実践します。
12.9.1 OS情報の確認
まず、Microsoft/OSInfoリソースでOS情報を取得します。
[実行環境: PowerShell 7.4 (管理者)]
# OS情報を取得する
dsc resource get --resource Microsoft/OSInfo
実行結果の例:
actualState:
$id: https://developer.microsoft.com/json-schemas/dsc/os_info/20230303/Microsoft.DSC.OS_Info.schema.json
family: Windows
version: 10.0.26100
edition: Windows Server 2025 Datacenter
bitness: "64"
architecture: x86_64
これは第1回で Get-ComputerInfo コマンドレットで確認した情報と同等のものです。DSCリソースを通じて同じ情報を取得できることがわかります。
12.9.2 レジストリの確認
第11回でセキュリティ設定に使用したレジストリの状態を、DSCで確認してみましょう。
[実行環境: PowerShell 7.4 (管理者)]
# Windows Updateの設定に関するレジストリキーを確認
dsc resource get --resource Microsoft.Windows/Registry --input "keyPath: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate"
実行結果の例:
actualState:
keyPath: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate
_exist: true
特定のレジストリ値を含めて確認するには、valueNameを指定します。
# レジストリ値まで指定して確認
dsc resource get --resource Microsoft.Windows/Registry --input '{"keyPath": "HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion", "valueName": "ProductName"}'
実行結果の例:
actualState:
keyPath: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion
valueName: ProductName
valueData:
String: Windows Server 2025 Datacenter
_exist: true
Tips:
--inputに渡す値はYAML形式でもJSON形式でも構いません。JSONの場合はバックスラッシュのエスケープ(\\)が必要になるため、シンプルな入力ならYAML形式のほうが読みやすくなります。
12.9.3 再起動保留状態の確認
サーバー管理でよく遭遇する「再起動保留中」の状態も、DSCリソースで確認できます。
[実行環境: PowerShell 7.4 (管理者)]
# 再起動が保留されているかを確認
dsc resource get --resource Microsoft.Windows/RebootPending
実行結果の例:
actualState:
rebootPending: false
rebootPending: false であれば、再起動は不要です。Windows Updateの適用後やWindows機能の追加後に true になることがあります。
12.9.4 手動管理とDSCの対応関係
ここまでの実践を通じて、基礎編の手動管理とDSCの対応関係を整理しましょう。
| 確認したい情報 | 手動管理(基礎編) | DSC v3 |
|---|---|---|
| OS情報 | Get-ComputerInfo |
dsc resource get -r Microsoft/OSInfo |
| レジストリの値 | Get-ItemProperty |
dsc resource get -r Microsoft.Windows/Registry -i "..." |
| 再起動保留状態 | 複数のレジストリキーを手動で確認 | dsc resource get -r Microsoft.Windows/RebootPending |
現時点では「DSCでも同じ情報が取得できる」ことを確認しただけですが、次回以降で構成ファイルを使った本格的な自動化を学ぶことで、DSCの真価が発揮されます。
12.10 よくあるエラーと対処法
| エラー | 原因 | 対処法 |
|---|---|---|
dsc: The term 'dsc' is not recognized |
DSC v3がインストールされていない、またはPATHが通っていない | インストールを実行し、PowerShellを再起動する |
Error: Resource not found |
指定したリソースタイプが存在しない | dsc resource list でリソース名を確認する。アダプター経由のリソースは --adapter オプションで確認 |
Error: Input validation failed |
入力のプロパティ名や値が正しくない | dsc resource schema -r <type> でリソースのスキーマを確認し、正しいプロパティ名・値を使用する |
| リソース一覧が空、または非常に少ない | PSDesiredStateConfigurationモジュールがインストールされていない | Install-Module -Name PSDesiredStateConfiguration でモジュールをインストールする |
| アダプター経由のリソース一覧に時間がかかる | 初回実行時のキャッシュ構築 | 初回は待つ必要がある。2回目以降は高速化する |
Access is denied |
管理者権限で実行していない | 管理者としてPowerShellを起動し直す |
トラブルシューティングのヒント: DSCコマンドの詳細な実行ログを確認するには、
--trace-level traceオプションを使用します。たとえばdsc --trace-level trace resource get -r Microsoft/OSInfoのように指定すると、DSCの内部動作の詳細なログが表示されます。
12.11 まとめ
第12回では、応用編の最初のステップとして、DSC v3(Desired State Configuration v3)の概念と基本操作を学びました。
- Infrastructure as Code(IaC)
- インフラの構成をコードとして定義・管理する手法
- 手作業によるミスの削減、環境の一貫性、バージョン管理が主なメリット
- 宣言的アプローチ
- DSCは「何を達成したいか(What)」を記述する宣言的アプローチ
- 基礎編で学んだPowerShellスクリプトの「どのように実現するか(How)」を記述する命令的アプローチと対比される
- 冪等性(Idempotent)
- 同じ操作を何度実行しても結果が変わらない性質
- DSCでは冪等性が自動的に保証され、安全に繰り返し適用できる
- DSC v3の特徴
- スタンドアロンのコマンドとして動作(LCM不要)
- YAML / JSON形式の構成ファイル
- クロスプラットフォーム対応
- 既存のPowerShell DSCリソースをアダプター経由で利用可能
- 基本コマンド
dsc resource list:利用可能なリソースの確認dsc resource get:リソースの現在の状態を取得dsc resource test:現在の状態と目標状態の比較dsc resource set:リソースの状態を設定
基礎編で手動で行ってきたサーバー設定を、DSCを使って「宣言的」に管理するための第一歩を踏み出しました。次回からは、構成ファイル(YAML)を使った本格的な構成管理を学んでいきます。
12.12 次回予告
第13回では「DSC構成ファイルの作成 ― YAMLの基本とリソース定義」と題して、YAML構文の基礎を学び、実際に構成ファイルを作成してテスト・適用する方法を学びます。環境変数やレジストリの設定を例に、dsc config test と dsc config set コマンドの使い方を実践します。構成ファイルを通じて、複数のリソースをまとめて管理する方法を身につけましょう。
12.13 参考リンク
- Announcing Microsoft Desired State Configuration v3.0.0 – PowerShell Team
- Get started with Microsoft Desired State Configuration v3.0.0 – PowerShell Team
- DSC v3 ドキュメント – Microsoft Learn
- DSC v3 GitHub リポジトリ – PowerShell/DSC
- PSDesiredStateConfiguration モジュール – GitHub
- dsc resource コマンドリファレンス – Microsoft Learn
- Using DSC v3 on Windows Server 2025 – Microsoft Tech Community
