「手順書（Excel）」を捨て、「コード」を信じよ。

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
前回は、リモートアクセス環境（RDS/VDI）の構築について学びました。
サーバーの役割が増えるにつれ、構築作業の手間も増えていきます。

Linuxエンジニアの皆さん、サーバー構築はどうやっていますか？
「AnsibleのPlaybookを流すだけ」「Dockerfileをビルドするだけ」ですよね。
でも、Windows Serverの構築になった途端、こんな作業に戻っていませんか？

「手順書.xlsx の15ページ目を開き、チェックボックスAをオンにする。
（注：ウィンドウのレイアウトが変わっている場合は右上の…）」

これでは、100台のサーバーを構築するのに100倍の時間がかかりますし、人為的ミス（オペミス）も防げません。

本記事では、DSCのアーキテクチャ、宣言的な設定ファイルの書き方、設定の適用とドリフト検知、そしてLinuxエンジニアが好む「AnsibleからDSCを利用する方法」までを徹底解説します。

---

第1章：IaCとは？ 命令型から宣言型へ

まずは概念の整理です。
サーバー構築をスクリプト化する方法には、大きく2つのアプローチがあります。

命令型 (Imperative)

「どうするか（How）」を記述します。
従来のPowerShellスクリプトやバッチファイルがこれです。

# 命令型：IISが入っていなければインストールせよ
if ((Get-WindowsFeature Web-Server).Installed -eq $false) {
    Install-WindowsFeature Web-Server
}

欠点： 現在の状態をチェックするロジック（if文）を自分で書く必要があり、コードが複雑になります。
また、何度も実行するとエラーになる可能性があります（冪等性の欠如）。

宣言型 (Declarative)

「どうあるべきか（What）」を記述します。
Ansible、Terraform、Kubernetes、そしてDSCがこれです。

# 宣言型：IISは「インストールされた状態」であるべき
WindowsFeature IIS {
    Name = "Web-Server"
    Ensure = "Present"
}

利点： 現在の状態がどうであれ、最終的にこの状態になります。
インストール済みなら何もしない、未インストールなら入れる。
人間は「ロジック」を書く必要がありません。

---

第2章：DSCのアーキテクチャ。LCMとMOFファイル

DSCがどのように動いているのか、仕組みを理解しましょう。

1. Configuration（構成スクリプト）

人間が書くPowerShellスクリプトです（拡張子 .ps1）。
ここで「あるべき状態」を定義します。

2. MOFファイル（中間ファイル）

Configurationを実行すると生成されるファイルです（拡張子 .mof）。
Managed Object Formatという業界標準のフォーマットで、これがサーバーへの「指示書」になります。
Linuxエンジニアには、AnsibleのYAMLがJSONに変換されてPythonモジュールに渡されるようなもの、とイメージしてください。

3. LCM (Local Configuration Manager)

各Windows Serverの中に常駐しているDSCのエージェント（エンジン）です。
WMIベースで動作し、受け取ったMOFファイルと現在の状態を比較し、差異があれば設定を変更します。
重要： DSCを使うためにエージェントのインストールは不要です。OS標準機能として最初から入っています。

---

第3章：実践！IISサーバーをコードで構築する

それでは実際にコードを書いてみましょう。
以下の要件を満たすWebサーバーを構築します。

• IIS機能 (Web-Server) がインストールされていること。
• ASP.NET 4.5 (Web-Asp-Net45) がインストールされていること。
• C:\Inetpub\wwwroot\index.html の内容が “Hello DSC” であること。
• “W3SVC” (World Wide Web Publishing Service) サービスが起動していること。

Configurationスクリプトの作成

ファイル名：WebServerConfig.ps1

Configuration WebServerConfig {
    # 必要なモジュールをインポート
    Import-DscResource -ModuleName 'PSDesiredStateConfiguration'

    # 適用対象のノード（localhost）
    Node "localhost" {
        
        # 1. IISのインストール
        WindowsFeature IIS {
            Ensure = "Present"          # 存在する状態にする (Absentなら削除)
            Name   = "Web-Server"
        }

        # 2. ASP.NET 4.5のインストール
        WindowsFeature AspNet45 {
            Ensure = "Present"
            Name   = "Web-Asp-Net45"
        }

        # 3. index.htmlの配置
        File IndexHtml {
            Ensure          = "Present"
            DestinationPath = "C:\Inetpub\wwwroot\index.html"
            Contents        = "
Hello DSC
"
            Force           = $true
            DependsOn       = "[WindowsFeature]IIS" # IISが入ってから実行する依存関係
        }

        # 4. サービスの起動確認
        Service W3SVC {
            Name        = "W3SVC"
            State       = "Running"
            StartupType = "Automatic"
            DependsOn   = "[WindowsFeature]IIS"
        }
    }
}

# 構成を実行してMOFファイルを生成する
WebServerConfig

コンパイル（MOF生成）

このスクリプトを実行すると、カレントディレクトリに WebServerConfig フォルダができ、中に localhost.mof が生成されます。

.\WebServerConfig.ps1

---

第4章：設定の適用と「ドリフト」の検知・修復

MOFファイルができたら、それをサーバーに適用します。

設定の適用 (Start-DscConfiguration)

Linuxの ansible-playbook に相当するコマンドです。

# MOFファイルがあるフォルダを指定して適用
# -Wait: 完了まで待つ, -Verbose: 詳細表示, -Force: 強制適用
Start-DscConfiguration -Path .\WebServerConfig -Wait -Verbose -Force

実行すると、プログレスバーが進み、IISのインストールやファイルの作成が自動的に行われます。
もう一度実行してみてください。今度は「変更なし」として即座に終了するはずです（冪等性の確認）。

設定の検証 (Test-DscConfiguration)

「今のサーバーの状態は、定義通りか？」を確認するコマンドです。

Test-DscConfiguration

• True: 定義通り（正常）。
• False: 定義と異なる（ドリフト発生）。

設定のドリフトと自動修復

ここがDSCの真骨頂です。
誰かが手動でIISをアンインストールしたり、index.htmlを書き換えたりしたとします（設定の漂流＝ドリフト）。
DSCのLCMは、定期的に（デフォルト15分）状態をチェックし、設定モードに応じて動作します。

LCMのモード設定:

• ApplyOnly: 適用するだけ。後は関知しない（Ansibleに近い）。
• ApplyAndMonitor: 適用し、ドリフトがあればログに残す。
• ApplyAndAutoCorrect: 適用し、ドリフトがあれば勝手に元に戻す（自動修復）。

ApplyAndAutoCorrect にしておけば、夜中に誰かが勝手に設定を変えても、15分後には自動的に正しい状態に戻されます。
「不滅のインフラ」の完成です。

---

第5章：Push型とPull型。大規模環境での運用

DSCには2つの適用モデルがあります。

Push型 (プッシュ)

管理者が Start-DscConfiguration を実行して、対象サーバーにMOFを送り込む方式。
Ansibleと同じモデルです。
メリット： 即時反映できる。手軽。
デメリット： サーバーの電源が入っていないと適用できない。台数が多いと大変。

Pull型 (プル)

「DSC Pull Server」という中央サーバーを立て、MOFファイルを置いておきます。
各サーバー（ノード）は定期的にPull Serverに問い合わせ、「新しい設定はあるか？」と確認して、あれば自分でダウンロードして適用します。
メリット： ノードが増減しても管理が楽（オートスケーリング対応）。電源が入ったタイミングで勝手に適用される。
デメリット： Pull Serverの構築が必要。

---

第6章：Ansibleとの連携。LinuxからWindowsを管理する

「DSCがすごいのは分かったけど、PowerShellスクリプトを書くのは学習コストが高い……」
「すでにAnsibleでLinuxを管理しているから、ツールを統一したい」

そんなLinuxエンジニアに朗報です。
AnsibleからDSCのリソースを利用することができます。

win_dsc モジュール

Ansibleには win_dsc というモジュールがあります。
これを使うと、AnsibleのYAML形式でDSCのリソースを呼び出せます。
裏側ではAnsibleが動的にMOFを生成し、DSCエンジンに食わせています。

Ansible Playbookの例 (site.yml):

- name: Configure IIS with DSC
  hosts: windows
  tasks:
    - name: Install IIS
      win_dsc:
        resource_name: WindowsFeature
        Name: Web-Server
        Ensure: Present

    - name: Deploy Index.html
      win_dsc:
        resource_name: File
        DestinationPath: C:\Inetpub\wwwroot\index.html
        Contents: "
Managed by Ansible + DSC
"
        Ensure: Present

これなら、PowerShellの構文を覚えなくても、使い慣れたYAMLでWindowsの詳細な設定（レジストリ、ユーザー権限、IIS設定など）が可能になります。
「Ansibleで大枠を管理し、細かいWindows固有設定はDSCリソースを呼ぶ」というのが、現代のクロスプラットフォーム管理の最適解です。

---

まとめ：手作業との決別。コードが支配するインフラへ

お疲れ様でした！
上級編第6回は、PowerShell DSCによる構成管理の自動化について解説しました。

今回の重要ポイント：

• DSCは「手順」ではなく「あるべき状態」を定義する。
• OS標準機能（LCM）が、設定の適用と自動修復（ドリフト対策）を行う。
• Start-DscConfiguration でMOFファイルを適用する。
• Ansibleの win_dsc モジュールを使えば、Linux流儀でWindowsを管理できる。

さて、OSの設定がコード化できたら、次はデータストレージの進化です。
高価なSANストレージ装置を買わずに、汎用サーバーの内蔵ディスクを束ねて巨大な共有ストレージを作る技術があります。

次回、第7回は「Software Defined Storage。記憶域スペースダイレクト (S2D) の構築」です。
Windows版のCephやGlusterFSとも言える、ハイパーコンバージドインフラ（HCI）の基盤技術について解説します。お楽しみに！