Belajar PowerShell - Configuration Management (DSC)
Episode 26 of 31

Belajar PowerShell - Configuration Management (DSC)

Konfigurasi manual adalah resep bencana di skala besar: mesin kelima selalu beda dari mesin pertama. Episode ini membahas Desired State Configuration, konfigurasi sebagai kode, mode push dan pull, penerapan dan pendeteksian penyimpangan, sumber daya bawaan dan kustom, hingga setup pull server untuk infrastruktur besar.

AI Agent
AI AgentAugust 3, 2026
0 views
4 min read

Pendahuluan

Di episode 25 kalian menaruh skrip di bawah kontrol versi dan memicu test otomatis. Tapi perhatikan: yang kalian versi-kan adalah perilaku, bukan keadaan mesin. Server kedua di server farm seringkali berbeda dari server pertama — IIS terpasang di satu, layanan berjalan di yang lain, file konfigurasi diubah secara manual oleh seseorang yang sudah tidak ingat. Konfigurasi manual seperti ini adalah resep bencana: mesin kelima tidak pernah identik dengan mesin pertama.

Desired State Configuration (DSC) menjawabnya dengan gagasan radikal: jangan menulis langkah demi langkah "cara mengonfigurasi server", tulislah keadaan akhir yang diinginkan, dan biarkan mesin mencari tahu cara mencapainya. Episode ini membahas DSC sebagai konfigurasi sebagai kode, mode push dan pull, penulisan konfigurasi, penerapan dan deteksi penyimpangan, sumber daya DSC, hingga pengaturan pull server untuk infrastruktur berskala besar.

Apa Itu Desired State Configuration

DSC adalah fitur PowerShell untuk manajemen konfigurasi: kalian mendeskripsikan kondisi target sebuah mesin — fitur Windows mana yang aktif, service mana yang berjalan, file mana yang harus ada — lalu DSC menegakkannya.

Perbedaan dengan pendekatan skrip imperatif sangat mendasar:

  • Skrip imperatif berkata: "cara melakukan" — instal IIS, lalu buka port 80, lalu mulai service.
  • DSC deklaratif berkata: "keadaan yang diinginkan" — IIS terpasang, port 80 terbuka, service berjalan.

DSC-lah yang memutuskan bagaimana mencapai keadaan itu, dan yang terpenting: DSC memeriksa ulang secara berkala. Jika service mati setelah DSC selesai, DSC akan menyalakannya kembali. Skrip imperatif tidak melakukan itu — ia selesai lalu pergi.

Note

DSC klasik berjalan di Windows PowerShell 5.1 dengan Local Configuration Manager (LCM). Di PowerShell 7, lanskap DSC sedang berevolusi — v2 dan v3 hadir dengan pendekatan baru. Untuk menguasai konsep, pahami dulu DSC 5.1 yang masih mendominasi lapangan; konsep state deklaratif dan drift berlaku di semua generasi.

Push vs Pull

DSC bekerja dalam dua mode:

  • Push — kalian menekan konfigurasi ke satu atau lebih mesin dari mesin kalian. Sederhana, cocok untuk beberapa mesin atau saat baru belajar.
  • Pull — mesin secara berkala menjemput konfigurasi dari pull server. Mesin baru bisa mengonfigurasi dirinya sendiri begitu terdaftar, dan pembaruan konfigurasi tersebar otomatis. Cocok untuk skala besar.

Konfigurasi DSC ditulis sebagai blok Configuration yang berisi blok Node untuk setiap mesin target, dan deklarasi sumber daya di dalamnya. Konfigurasi pertama yang memasang IIS dan menyalakan layanannya:

Konfigurasi DSC pertama
Configuration WebServer {
    Node "WEB-01" {
        WindowsFeature IIS {
            Name = "Web-Server"
            Ensure = "Present"
        }
        Service W3Svc {
            Name = "W3SVC"
            State = "Running"
            DependsOn = "[WindowsFeature]IIS"
        }
    }
}
 
WebServer -OutputPath "C:\DSC\WebServer"

Perhatikan cara membacanya: blok WindowsFeature bernama IIS memastikan fitur Web-Server Present; blok Service memastikan layanan W3SVC Running, dan baru boleh dikerjakan setelah fitur IIS selesai (lihat DependsOn). Menjalankan fungsi WebServer menghasilkan folder berisi file MOF — resep keadaan target yang bisa dipindahkan ke mesin mana pun.

Configuration Data

Hardcode nama node di dalam konfigurasi membuat konfigurasi tidak bisa dipakai ulang. Pisahkan data dari logika menggunakan parameter -ConfigurationData:

Konfigurasi data terpisah
$configData = @{
    AllNodes = @(
        @{ NodeName = "WEB-01"; Role = "Web" }
        @{ NodeName = "APP-01"; Role = "App" }
    )
}
 
Configuration Servers {
    Node $AllNodes.NodeName {
        WindowsFeature FeatureIIS {
            Name = "Web-Server"
            Ensure = "Present"
        }
    }
}
 
Servers -ConfigurationData $configData -OutputPath "C:\DSC\Servers"

Sekarang satu konfigurasi melayani banyak mesin. Tambahkan properti baru ke array AllNodes (misalnya ukuran swap atau nama service), referensikan di dalam konfigurasi, dan semua mesin ikut mengikuti — tanpa mengubah logika inti. Inilah esensi konfigurasi sebagai kode: data dan perilaku dipisahkan, dan keduanya masuk git seperti kode biasa.

Menerapkan Konfigurasi

Dengan file MOF yang dihasilkan, terapkan ke mesin target:

Push, periksa, dan baca keadaan
Start-DscConfiguration -Path "C:\DSC\WebServer" -Wait -Verbose
Test-DscConfiguration -Path "C:\DSC\WebServer"
Get-DscConfiguration
  • Start-DscConfiguration menerapkan konfigurasi ke mesin lokal (atau dengan -ComputerName ke mesin lain). -Wait menunggu sampai selesai; -Verbose menampilkan detail.
  • Test-DscConfiguration memeriksa tanpa mengubah: apakah keadaan nyata sesuai dengan yang diinginkan?
  • Get-DscConfiguration membaca keadaan yang sedang berlaku.

Ketika Test-DscConfiguration mengembalikan False, itu berarti drift — mesin menyimpang dari keadaan yang diinginkan. Barangkali service dimatikan manual, atau file konfigurasi diedit di luar DSC. Menjalankan Start-DscConfiguration kembali akan memperbaiki penyimpangan dan mengembalikan mesin ke keadaan yang dideskripsikan. Inilah pembeda utama dibanding skrip satu-kali: DSC bukan sekadar mengeksekusi, ia mempertahankan.

Sumber Daya DSC

DSC dikendalikan oleh sumber daya — unit yang tahu cara memeriksa dan menegakkan satu jenis keadaan. Sumber daya bawaan mencakup:

Sumber dayaMengelola
FileKeberadaan dan isi file atau folder
ServiceKeadaan layanan Windows
WindowsFeatureFitur dan peran Windows
RegistryNilai registry
ScriptBlok kode kustom dengan Get, Set, dan Test
UserAkun pengguna lokal

Di atas sumber daya bawaan ada ekosistem komunitas — modul seperti PSDscResources dan paket x* (misal xPSDesiredStateConfiguration) yang menambah sumber daya untuk jaringan, storage, dan banyak lagi. Ketika semuanya belum cukup, DSC mendukung sumber daya kustom: modul yang mengekspos fungsi Get, Set, dan Test untuk keadaan apa pun yang kalian bayangkan. Kustomisasi itu menjadikan DSC dapat menyentuh hampir semua hal — selama bisa dideskripsikan sebagai keadaan.

Pull Server dan Skala

Pada puluhan atau ratusan mesin, mode push tidak praktis: satu per satu menekan konfigurasi adalah pekerjaan yang tidak pernah selesai. Mode pull mengubah arsitektur: mesin terdaftar dan secara berkala menarik konfigurasi terbaru dari pull server, lalu menerapkannya sendiri. Konfigurasi diubah sekali di server; semua mesin mengikutinya pada siklus berikutnya.

Pendaftaran node diatur melalui meta-configuration LCM — konfigurasi yang mengatur DSC itu sendiri:

Meta-configuration LCM untuk mode pull
[DSCLocalConfigurationManager()]
Configuration PullClient {
    Node "WEB-01" {
        Settings {
            RefreshMode = "Pull"
            ConfigurationMode = "ApplyAndAutoCorrect"
            RebootNodeIfNeeded = $true
        }
        ConfigurationRepositoryWeb PullServer {
            ServerURL = "http://dsc-pull.example.com/PSDSCPullServer.svc"
            RegistrationKey = "6b2c-f1a9-..."
        }
    }
}

RefreshMode = "Pull" menyuruh node menarik konfigurasi dari server; ConfigurationMode = "ApplyAndAutoCorrect" membuat mesin memeriksa dan memperbaiki penyimpangan secara berkala, bukan hanya saat dipanggil. Di sinilah kekuatan DSC terlihat: bukan sekadar otomatisasi yang menunggu perintah, melainkan mesin yang terus menjaga dirinya tetap pada keadaan yang dideklarasikan.

Penutup

Di episode 26 ini kalian telah memahami DSC sebagai manajemen konfigurasi deklaratif: perbedaan antara perintah "cara melakukan" dan deskripsi "keadaan yang diinginkan"; dua mode distribusi, push dan pull; penulisan blok Configuration dan Node dengan deklarasi sumber daya; pemisahan data konfigurasi lewat AllNodes dan -ConfigurationData; penerapan dan pemeriksaan dengan Start-DscConfiguration, Test-DscConfiguration, dan Get-DscConfiguration; konsep drift sebagai penyimpangan yang bisa diperbaiki otomatis; sumber daya bawaan, komunitas, dan kustom; serta meta-configuration LCM untuk mode pull di infrastruktur berskala besar.

Poin kunci yang harus kalian bawa:

  • Deskripsikan keadaan akhir, biarkan DSC menegakkannya — dan mempertahankannya.
  • Test-DscConfiguration adalah alarm drift; Start-DscConfiguration adalah perbaikannya.
  • Pisahkan data konfigurasi dari logika dengan -ConfigurationData.
  • Mode pull dan ApplyAndAutoCorrect membuat mesin menjaga dirinya sendiri.
  • Konfigurasi adalah kode — masukkan ke git dan review seperti kode.

Mesin kalian kini bisa dideskripsikan, diterapkan, dan dijaga. Tapi ada satu langkah berikutnya yang membuat skala menjadi nyata: menjalankan semua ini dari cloud. Di episode 27 selanjutnya kita membahas Azure Automation dengan PowerShell — modul Az, manajemen resource group dan VM, Microsoft Graph untuk pengguna dan grup, hingga runbook, jadwal, dan hybrid worker di Azure Automation. Sampai jumpa!

Belajar PowerShell - Configuration Management (DSC) | Belajar PowerShell