ניהול תצורה הצהרתי של Windows עם DSC — מתחילים IaC עם dsc.exe

“רוצים לבנות מחדש מחשב סטנדרטי”, “רוצים להריץ שוב setup שנכשל באמצע”, “רוצים למצוא הגדרה שמישהו שינה ידנית”. כשמנהלים לקוחות ושרתים של Windows עם runbooks וסקריפטים, הקשה היא לשחזר את אותן הגדרות ולשמור עליהן.

runbook מתחיל להיסחף מהמציאות ברגע שהוא רץ, אלא אם ממשיכים לעדכן אותו אחרי כל שינוי. גם ב-BAT וגם ב-PowerShell, כדי שהרצה שנייה לא תעשה apply כפול ולא תיעצר בשגיאה, צריך לכתוב בעצמכם בדיקות קיום ופיצולים. DSC (Desired State Configuration) מעביר את העומס הזה מניהול “צעדים” לניהול “מצב רצוי”.

המאמר הזה עוסק ב-Microsoft DSC v3 (dsc.exe), שהופיע ב-2025 ככלי שורת פקודה בלי תלות ב-PowerShell. זו נקודת הכניסה לניהול לקוחות ושרתים של Windows עצמם כ-IaC הצהרתי (Infrastructure as Code), באותו ראש שבו משתמשים ב-Terraform וב-Ansible ב-Linux ובענן.¹

הקהל הוא מפתחים ואנשי IT שרוצים להעביר את ניהול התצורה של Windows מ-runbooks וסקריפטים. הבסיס הוא Windows 10/11, DSC 3.0 ואילך, ופעולת PowerShell בסיסית, ורמת הקושי היא בינונית. שמות ה-adapters מ-DSC 3.2 ואילך, וגרסת WinGet הנדרשת, מוסברים בנפרד במקומות הרלוונטיים.

1. קודם המסקנה — כותבים מצב, בודקים, ורק אז מחילים

אם מתחילים עכשיו ניהול תצורה הצהרתי ל-Windows, בוחרים ב-Microsoft DSC v3 (dsc.exe). כותבים את “המצב הרצוי” ב-YAML/JSON, ואת ההשוואה למצב הנוכחי ואת ההחלה משאירים ל-DSC ול-resources. גם כשמחילים את אותה תצורה שוב ושוב, פריטים שכבר במצב הרצוי לא נגעים. זה ניהול אידמפוטנטי בבסיסו.²³

עם זאת, “אפשר להחיל כמה פעמים שרוצים” ו”מותר להחיל את התוכן הזה” הם שני דברים שונים. קודם קוראים את המצב, בודקים את ההפרש ואת התחזית, ורק אז מחילים. בנוסף, DSC v3 אינו agent תושב, ולכן audit ותיקון תקופתיים מתכננים בנפרד.⁴¹

סדר הקריאה הוא כזה:

flowchart TB
    accTitle: מניהול צעדים לניהול מצב
    accDescr: בסקריפט runbook מממשים בעצמכם בדיקת קיום ופיצולים כדי שאפשר יהיה להריץ שוב, ואילו ב-DSC מצהירים על המצב הרצוי ו-DSC וה-resources לוקחים על עצמם את ההשוואה ואת ההחלה
    imp["כותבים צעדים (BAT, PowerShell)"] --> guard["מממשים בעצמכם בדיקת קיום ופיצולים"]
    dec["כותבים מצב (DSC)"] --> test["משווים למצב הנוכחי"]
    test --> set["מחילים רק מה שצריך"]

איור 1: האחריות על הרצה חוזרת עוברת מכתיבת ענפים בצעדים, להצהרה על מצב ולשימוש ב-resources.

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 17, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

2. מזהים איזה DSC משתמשים בו — ארבעה קווים, ומה שאין ב-v3

2.1. הגיבור של המאמר הזה הוא dsc.exe עצמאי

חיפוש “DSC” מחזיר מידע מארבעה קווים שנבדלים גם בכתיבה וגם בהרצה. קודם בודקים על איזה מהם מדבר המסמך שקוראים.⁵

Microsoft DSC v3 אינו עדכון פשוט של מודול PowerShell DSC (PSDSC). זה מוצר נפרד, שנכתב מחדש אחרי שחתכו את התלות ב-PowerShell. התצורה נכתבת כנתוני JSON/YAML, ו-resources אפשר לממש בכל שפה. DSC עצמו רץ על Linux, macOS ו-Windows.¹

flowchart TB
    accTitle: ייחוס ארבעת דורות DSC
    accDescr: מ-PSDSC v1.1 שמובנה ב-Windows PowerShell 5.1 נגזרים PSDSC v2 ל-PowerShell 7 ו-PSDSC v3 preview ל-Machine Configuration, ואילו Microsoft DSC v3, שנכתב מחדש בנפרד בלי תלות ב-PowerShell, הוא הקו הראשי הנוכחי
    v11["PSDSC v1.1 (מובנה ב-WinPS 5.1)"] --> v2["PSDSC v2 (PowerShell 7)"]
    v2 --> v3ps["PSDSC v3 preview"]
    v11 -.->|"כתיבה מחדש"| dsc3["Microsoft DSC v3 (dsc.exe)"]
    v3ps --> mc["Azure Machine Configuration"]
    dsc3 --> now["נושא המאמר"]

איור 2: גם כשהשם הוא DSC, מבחינים בין דורות של מודול PowerShell לבין dsc.exe עצמאי.

מכאן ואילך, “DSC” במאמר הזה פירושו Microsoft DSC v3. בחיפוש, הוספת “DSC v3” או “dsc.exe” מקלה להפריד מחומר של דורות ישנים. איך קוראים ל-PSDSC resources קיימים מכוסה בפרק 6.

2.2. v3 אינו שירות תושב שזוכר תצורה ומתקן לבד

ה-LCM (Local Configuration Manager) של PSDSC v1.1 היה agent תושב שהחזיק את התצורה וביצע החלה תקופתית ותיקון אוטומטי. ב-DSC v3 אין LCM; זו פקודה שרצה רק כשקוראים לה. התקנת dsc.exe והחלה חד-פעמית לא מתקנות שינויים שיגיעו אחר כך מעצמן.¹

flowchart TB
    accTitle: LCM התושב של v1.1 מול מודל הפקודה של v3
    accDescr: ב-PSDSC v1.1 LCM תושב החזיק את התצורה וטיפל ב-pull תקופתי ובתיקון אוטומטי, ואילו DSC v3 מופעל רק כפקודה, ולכן את תשתית התזמון בוחרים ומכינים בעצמכם מ-Task Scheduler, CI ו-Machine Configuration
    v1["PSDSC v1.1: LCM תושב"] --> pull["מחזיק את התצורה, pull תקופתי, תיקון אוטומטי"]
    v3["DSC v3: הפעלת פקודה בלבד"] --> push["את תשתית ההרצה מכינים בעצמכם"]
    push -.-> ex["Task Scheduler, CI, Machine Configuration"]

איור 3: ב-v3 מפרידים בין “איך מגדירים” לבין “מתי זה רץ”, ואת השני משאירים ל-Task Scheduler או לשכבת ניהול גבוהה יותר.

זו לא נסיגה של יכולת, אלא שינוי תכנון שפותח את אופן ההרצה לכלים מודרניים. ועדיין, מי שמגיע עם הראש של תפעול pull server ב-v1.1 מתבלבל. אם צריך אכיפה מתמשכת, בוחרים תשתית הרצה כמו Task Scheduler, CI או Machine Configuration. התפעול עצמו בפרק 7.

3. מבינים תצורה הצהרתית — משווים צעדים למצב

3.1. מוציאים בדיקת קיום ופיצולים מתוך ההצהרה

לדוגמה, שומרים ב-Registry את מצב ההפעלה של אפליקציה. ב-PowerShell אימפרטיבי בודקים אם המפתח קיים, יוצרים אותו אם צריך, ואז מגדירים את הערך. את הצעדים שמאפשרים הרצה חוזרת מנהלים בעצמכם.

# אימפרטיבי: כותבים את ה"צעדים". מנהלים כל פיצול וכל סדר בעצמכם
$path = 'HKCU:\Software\MyCompany\App'
if (-not (Test-Path $path)) {
    New-Item -Path $path -Force | Out-Null
}
Set-ItemProperty -Path $path -Name 'Mode' -Value 'standard'

ב-DSC כותבים את אותה דרישה כהצהרה על מצב. בדיקת קיום ופיצול היצירה לא מופיעים אצל מי שמצהיר. דוגמה מלאה שמכניסה את הקטע הזה ל-resources של configuration document מופיעה בפרק 5.

# הצהרתי: כותבים את ה"מצב". יצירה ותיקון הם העבודה של ה-resource
- name: מצב ההפעלה של האפליקציה
  type: Microsoft.Windows/Registry
  properties:
    keyPath: HKCU\Software\MyCompany\App
    valueName: Mode
    valueData:
      String: standard

ההבדל אינו ש-PowerShell לא יכול להיות אידמפוטנטי. את הבדיקה ואת ההחלה שכתבתם בסקריפט משאירים ל-resource. גם מכונה שנכשלה באמצע וגם מכונה שכבר מוגדרת יכולות לקבל מחדש את אותו “מצב רצוי” כבסיס.²

3.2. ה-resource לוקח על עצמו get, test ו-set

במרכז DSC נמצא ה-resource. הוא מספק את הפעולות ליעד תצורה מסוג מסוים, כמו ערך Registry, Windows feature או משתנה סביבה. המשתמש כותב “מה צריך להיות באיזה מצב”, ומשאיר את “איך מגדירים” ל-resource.⁶

כשמחילים תצורה שלמה ב-dsc config set, DSC קודם עושה test לכל instance וקורא ל-set רק לאלה שאינם במצב הרצוי. זה המנגנון שמאפשר להחיל את אותה תצורה שוב ושוב.³

flowchart TB
    accTitle: לולאת ההתכנסות של get, test ו-set
    accDescr: test משווה את המצב הרצוי שנכתב ב-configuration document למצב הנוכחי, לא קורה כלום אם אין הפרש, ואם יש, set מחיל רק את ההפרש ו-get מאשר את התוצאה, זרימת התכנסות אידמפוטנטית
    doc["configuration document (מצב רצוי)"] --> test["test: השוואה למצב הנוכחי"]
    test -->|"אין הפרש"| ok["לא עושים כלום (אידמפוטנטי)"]
    test -->|"יש הפרש"| set["set: מחילים רק את ההפרש"]
    set --> get["get: מאשרים את המצב שנוצר"]

איור 4: בהחלת תצורה שלמה קודם משווים, ואז משנים רק את ה-resource instances שצריך.

3.3. לא מערבבים resource set בודד עם config set של התצורה כולה

dsc resource set תמיד קורא ל-set של ה-resource שצוין. האם רץ test מראש תלוי במימוש של ה-resource וב-implementsPretest במניפסט. חשוב לא להניח ש-pre-test ש-config set עושה קיים גם ב-resource set.³

flowchart TB
    accTitle: ההבדל ב-pre-test בין החלת תצורה שלמה לקריאה בודדת
    accDescr: config set בודק כל instance וקורא ל-set רק כשצריך, ואילו resource set תמיד קורא ל-set של ה-resource, ו-pre-test שם תלוי במימוש ובמניפסט
    config["config set"] --> test["בודקים כל instance"]
    test --> needed{"במצב הרצוי?"}
    needed -->|"כן"| skip["לא קוראים ל-set"]
    needed -->|"לא"| apply["קוראים ל-set"]
    single["resource set"] --> direct["קוראים ל-set של ה-resource"]
    direct -.-> impl["pre-test תלוי במימוש"]

איור 5: גם כשהשם הוא set, מבחינים בין פעולת תצורה שלמה ש-DSC בודק מראש לבין פעולה בודדת שמועברת ישר ל-resource.

בתחלה צופים עם get ו-test בודדים, ורק כשמנהלים כמה מצבים יחד מאחדים ל-configuration document. כך קל יותר להבין. idempotency היא תכונה להרצה חוזרת; היא לא מבטלת מחסור בהרשאות או שגיאות הרצה של resource.

4. הפעולות הראשונות — מתקינים וצופים עם get ו-test

4.1. מכינים dsc.exe ובודקים אילו resources זמינים

יש שתי דרכי התקנה: מחלצים ארכיון מ-GitHub release ומוסיפים ל-PATH, או, ב-Windows, מתקינים עם winget ממקור Microsoft Store.¹

# חיפוש והתקנה של מהדורת stable ממקור Microsoft Store
winget search DesiredStateConfiguration --source msstore
winget install --id 9NVTPZWRC6KQ --source msstore

אחרי ההתקנה, מציגים את ה-resources הזמינים במכונה המקומית.

dsc resource list

מפרידים בין “DSC עצמו מותקן” לבין “אפשר להשתמש ב-resource שרוצים”. כאן מוצאים את שם ה-type, ואז מציינים את ה-properties לקלט. אם משתמשים ב-PSDSC resources של דור ישן, בודקים גם את ה-adapters בפרק 6.

4.2. בהתחלה קוראים Registry תחת המשתמש

גם בלי לכתוב configuration document אפשר לקרוא ל-resources אחד-אחד. הדוגמה הבאה קוראת ערך תחת HKCU עם get, ובודקת עם test אם הוא במצב הרצוי. אף אחת מהפעולות האלה אינה משנה ערך.⁷

# שולפים את המצב הנוכחי (get)
dsc resource get --resource Microsoft.Windows/Registry `
  --input '{"keyPath":"HKCU\\Software\\MyCompany\\App","valueName":"Mode"}'

# בודקים אם זה במצב הרצוי (test) — בלי שום שינוי
dsc resource test --resource Microsoft.Windows/Registry `
  --input '{"keyPath":"HKCU\\Software\\MyCompany\\App","valueName":"Mode","valueData":{"String":"standard"}}'

flowchart TB
    accTitle: ארבע הפעולות של פקודת dsc resource
    accDescr: תחת פקודת dsc resource תלויות ארבע פעולות, list למנות resources, get לשלוף את המצב הנוכחי, test להעריך את המצב הרצוי בלי שינויים, ו-set להחיל את המצב (רק ל-resources שמממשים Set)
    cli["פקודת dsc resource"] --> l["list: מנות resources"]
    cli --> g["get: שולפים את המצב הנוכחי"]
    cli --> t["test: הערכה בלבד, בלי שינויים"]
    cli --> s["set: החלה (resources שתומכים ב-Set)"]

איור 6: מחפשים resource ב-list, קוראים את הערך הנוכחי ב-get, בודקים את ההפרש מההצהרה ב-test, ורק אז עוברים ל-set.

set שמשנה את כל המכונה, כמו HKLM או הגדרות מערכת, דורש הרשאות admin. את הניסיונות הראשונים מתחילים מדוגמאות בהיקף המשתמש (כמו HKCU), ובפעולות שמשנות בודקים את היעד ואת ההרשאות. גם שימוש ב-adapter ל-Windows PowerShell PSDSC resources מניח הרצה כ-administrator.⁷ איך מפרידים בין משתמש הרצה לבין התצורה מכוסה בפרק 8.

5. ה-configuration document — מההצהרה עד אישור אחרי ההחלה

5.1. מרכזים ב-YAML “מה צריך להיות באיזה מצב”

configuration document הוא קובץ YAML/JSON שמצהיר על כמה resource instances יחד. לפחות מגדירים $schema ו-resources, ולכל instance כותבים name (שם תצוגה ייחודי במסמך), type (השם המלא של ה-resource) ו-properties (המצב הרצוי).²

# standard-pc.dsc.config.yaml — המצב הרצוי של מחשב סטנדרטי
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
parameters:
  appMode:
    type: string
    defaultValue: standard
resources:
  - name: מצב ההפעלה של האפליקציה
    type: Microsoft.Windows/Registry
    properties:
      keyPath: HKCU\Software\MyCompany\App
      valueName: Mode
      valueData:
        String: "[parameters('appMode')]"

בדוגמה הזו אורזים את ההצהרה מפרק 3 לקובץ, ומעבירים את מצב ההפעלה לפרמטר appMode. ערכים שמשתנים לפי מחלקה או סביבה אפשר להפריד מגוף התצורה. עם parameters ו-variables מצמצמים הגדרות כפולות ומבטאים גם ערכים דינמיים. הביטויים הם תת-קבוצה של פונקציות ARM template.²

flowchart TB
    accTitle: מבנה של configuration document
    accDescr: configuration document מורכב מ-schema שמזהה את סכמת המסמך, מ-parameters ומ-variables שסופגים הבדלי סביבה, וממערך resources של resource instances, שלכל אחד מהם יש name, type ו-properties
    docroot["configuration document (YAML / JSON)"] --> sch["$schema: URI של סכמת המסמך"]
    docroot --> par["parameters / variables"]
    docroot --> res["resources: מערך instances"]
    res --> inst["name, type, properties"]
    par -.-> inst

איור 7: כשמפרידים את סכמת המסמך, את הערכים לפי סביבה ואת הצהרות ה-resources, אפשר לקרוא את כוונת ההגדרה כנתונים.

היתרון בכך שהתצורה הופכת לנתונים הוא שאפשר לסקור ב-diff של YAML “מה צריך להיות מוגדר במכונה הזו”. זה לא אומר שהנתונים חסרי סיכון. ה-resources שמפנים אליהם משנים את המערכת, ולכן גם אימות האמינות בפרק 8 נחוץ.⁸

5.2. מתקדמים בסדר test, what-if, set, get

לפני ההחלה תמיד שמים תצפית. dsc config test מדווח אם יש הפרש מהמצב הרצוי, ו-dsc config set --what-if מציג תחזית בלי לשנות.⁴

flowchart TB
    accTitle: ארבעת הצעדים של החלה בטוחה
    accDescr: בודקים הפרשים עם dsc config test, שלא מבצע שינויים, צופים מראש את השינויים עם אפשרות what-if של dsc config set, מחילים עם set אחרי ששוכנעתם, ומאשרים את התוצאה עם get, בסדר הבטוח הזה
    t["dsc config test (יש הפרש או אין)"] --> w["set --what-if (תחזית השינוי)"]
    w --> s["dsc config set (החלה)"]
    s --> g["dsc config get (אישור התוצאה)"]

איור 8: קודם רואים את ההפרש, אחר כך את תחזית השינוי, ורק כשמרוצים מחילים. בסוף קוראים שוב את המצב בפועל.

# 1. בודקים אם יש הפרשים (בלי שינויים)
dsc config test --file .\standard-pc.dsc.config.yaml

# 2. מציגים תחזית של מה שההחלה תשנה (בלי שינויים)
dsc config set --file .\standard-pc.dsc.config.yaml --what-if

# 3. מחילים אחרי ששוכנעתם
dsc config set --file .\standard-pc.dsc.config.yaml

# 4. מאשרים את המצב אחרי ההחלה
dsc config get --file .\standard-pc.dsc.config.yaml

כל שלב מראה דבר אחר. test הוא הכרעה אם יש התאמה, what-if הוא תחזית שינוי, ו-get הוא שליפת המצב בפועל. אם ה-resource לא מממש what-if ישירות, התחזית מסונתזת מתוצאת test, ולכן לא מבלבלים תחזית עם מדידה אחרי ההחלה.⁴

הסדר הזה הופך שינוי הגדרה מהימור חד-פעמי לשרשרת החלטות לפי שלב. אימות הרשאות בהחלה ואמינות ה-resource לא מוחלפים ב-idempotency או ב-what-if.

5.3. אם מתחילים מסביבה קיימת, עושים export ל-resources שתומכים בזה

dsc config export הוא כניסה הפוכה, שכותבת את הסביבה הנוכחית. מעבירים ב---file מסמך קלט שמנה resources שתומכים ב-export, ומקבלים בפלט הסטנדרטי configuration document שמכיל את כל ה-instances הקיימים שלהם.⁹

# מעבירים מסמך קלט שמנה את ה-resources היעד ושומרים את ה-configuration document הנוכחי
dsc config export --file .\export-targets.dsc.config.yaml > .\current-state.dsc.config.yaml

לא כל resource ניתן לייצוא, וכל סוג resource במסמך הקלט מוצהר פעם אחת בלבד. את המצב הנוכחי שמתקבל לוקחים כנקודת התחלה, ואז מחליטים מה לנהל כסטנדרט. export כותב את המצב הנוכחי; ההחלטה שזה המצב הרצוי שייכת לתפעול.⁹

flowchart TB
    accTitle: מהמצב הנוכחי בונים את ההצהרה שרוצים לנהל
    accDescr: כשמנים במסמך הקלט resources שתומכים ב-export מתקבל configuration document עם ה-instances הקיימים, ואחרי בדיקת התוכן התפעול מחליט איזה מצב לנהל כסטנדרט
    input["מנים resources שתומכים ב-export"] --> export["dsc config export"]
    export --> current["מסמך תצורה של instances קיימים"]
    current --> review["בודקים את התוכן ומחליטים על סטנדרט"]
    review --> desired["הצהרה על המצב שרוצים לנהל"]

איור 9: כתיבת המצב הנוכחי וההחלטה מה לאמץ כסטנדרט הם שני שלבים נפרדים.

6. מנצלים נכסים קיימים — adapters ו-WinGet Configuration

6.1. ל-PSDSC resources קוראים ב-adapter שמתאים לסביבת ההרצה

גם אם v3 הוא מוצר נפרד, PSDSC resources קיימים לא מתבזבזים. אפשר לקרוא להם מ-configuration document של v3 דרך adapter resources. ב-DSC 3.2 השמות השתנו, לכן משווים את גרסת ההתקנה לשמות במסמכים.¹⁰

גם כש-DSC עצמו לא תלוי ב-PowerShell, resource קיים שנקרא דרך adapter רץ בסביבת PowerShell המתאימה. בצד Windows PowerShell משתמשים ב-PSDesiredStateConfiguration 1.1 המובנה, ומטפלים ב-resources תואמים מסוג סקריפט, class ו-binary.¹⁰

flowchart TB
    accTitle: מבנה השכבות סביב DSC v3
    accDescr: שכבות orchestration כמו winget configure ו-Azure Machine Configuration קוראות ל-DSC v3, ו-DSC v3 קורא ל-native resources ישירות ול-PSDSC resources קיימים דרך adapter resources
    orch["winget configure, Machine Configuration"] --> dsc["dsc.exe (DSC v3)"]
    dsc --> native["native resources (Registry וכו')"]
    dsc --> adapter["adapter resources"]
    adapter --> psdsc["PSDSC resources קיימים (נכסי PowerShell)"]

איור 10: DSC v3 קורא ל-native resources ישירות, ונכסי PowerShell קיימים עוברים דרך adapter.

6.2. בסכמת v3 של WinGet מציינים את DSC v3 כמעבד

נקודת החיבור האחרת היא WinGet Configuration. גם קבצי .winget שהוצגו ב-מאמר על kitting של מחשבים משתמשים, בסכמת v3, ב-DSC v3 כמעבד. נדרשים WinGet 1.11 ואילך ומעבד dscv3.¹¹

ב-metadata.winget.processor.identifier של קובץ התצורה מציינים dscv3, וכותבים resources ישירות בשורש המסמך. הגוף הוא configuration document של DSC v3.

# WinGet Configuration v3 — הגוף הוא configuration document של DSC v3
$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json
metadata:
  winget:
    processor:
      identifier: dscv3
resources:
  - name: מצב ההפעלה של האפליקציה
    type: Microsoft.Windows/Registry
    properties:
      keyPath: HKCU\Software\MyCompany\App
      valueName: Mode
      valueData:
        String: standard

אי אפשר להעביר פורמט v2 קיים כמו שהוא ל-dscv3. קובץ v2 עם properties.configurationVersion: 0.2.0 ועם ה-resources מתחת ל-properties ממשיך לרוץ על המעבד הקודם. כדי להעלות אותו ל-DSC v3 מעבירים את הפורמט לפי “Convert to v3” במאגר הדוגמאות הרשמי.¹¹

כלומר, מפרידים מה עושים reuse. ב-PSDSC מדובר בקריאה ל-resource דרך adapter; ב-WinGet מדובר בהתאמת פורמט הקובץ והמעבד. הצהרת המצב שלומדים ב-DSC v3 היא בסיס משותף שמחבר את dsc.exe המקומי, את winget configure ב-kitting, ואת שכבות ניהול גבוהות כמו Machine Configuration.¹

7. תפעול מתמשך — Git כמקור האמת, וזיהוי drift

7.1. קודם מאוטמטים רק זיהוי, ומפרידים אותו מתיקון

configuration documents שמים ב-מאגר Git. אם שינויים עוברים סקירה ב-pull request, מיזוג, ואז החלה, התצורה הרצויה והיסטוריית השינויים שלה יושבות באותו מקום. עוברים מניהול שבו ממשיכים לעדכן runbook בנפרד, לניהול שבו ההצהרה הבר-הרצה היא מקור האמת.

אחרי ההחלה, אם מישהו משנה הגדרה ידנית והמכונה זזה מהמצב שהוצהר, זה configuration drift. הזיהוי הוא הרצה מתוזמנת של dsc config test. test לא משנה כלום, ולכן אפשר להפריד זיהוי מתיקון. קודם מאוטמטים רק זיהוי, ותיקון ב-set עושים אחרי שבדקים את ההפרש.

flowchart TB
    accTitle: מחזור התפעול של ניהול תצורה שמתחיל מ-Git
    accDescr: configuration documents שנשמרים במאגר Git עוברים סקירה ב-pull request לפני ההחלה, הרצות test תקופתיות מ-Task Scheduler או CI מזהות drift, ואחרי בדיקת ההפרש המחזור חוזר לתיקון או לעדכון התצורה
    git["מאגר Git (configuration documents)"] --> pr["שינויים נסקרים ב-pull request"]
    pr --> apply["מחילים עם dsc config set"]
    apply --> sched["הרצה מתוזמנת: dsc config test"]
    sched -->|"זוהה drift"| judge["בודקים את ההפרש ומחליטים איך לטפל"]
    judge -.->|"התצורה נכונה"| fix["מתקנים עם set"]
    judge -.->|"המציאות נכונה"| git

איור 11: סוקרים את ההצהרה ומחילים אותה, ומזהים הפרש ב-test תקופתי. האם לתקן או לעדכן את ההצהרה מחליטים לפי התוכן.

drift אינו תמיד טעות. אם השינוי היה נחוץ בשטח, לא מחזירים את המכונה אלא מעדכנים את ה-configuration document, סוקרים וממזגים. אם ההצהרה נכונה, מתקנים ב-set. בשני המקרים המשמעת זהה: מקור האמת נשאר בתוך Git.

7.2. מבחינים בין “לא הצלחנו לבדוק” לבין “יש סטייה”

בהרצה מתוזמנת חשוב לא לדווח הצלחה רק כי הפקודה הופעלה. הדוגמה הבאה מבחינה בין כשל הרצה של DSC, שגיאת בדיקה בחלק מה-resources, ו-drift, ומסיימת ב-non-zero בכל אחד מהם.

# להרצה מתוזמנת: מבחינים בין כשל של test עצמו, שגיאות לפי resource, ו-drift, ומסיימים ב-non-zero לכולם
$json = dsc config test --file C:\config\standard-pc.dsc.config.yaml
if ($LASTEXITCODE -ne 0 -or -not $json) {
    Write-Error "ההרצה של dsc config test עצמה נכשלה (קוד יציאה: $LASTEXITCODE)"
    exit 2
}
$result = $json | ConvertFrom-Json
if ($result.hadErrors) {
    # אימות המסמך נכשל או ש-resource כלשהו יצא ב-non-zero. הבדיקה לא הושלמה, לכן לא מדווחים healthy
    Write-Error "בדיקת חלק מה-resources הסתיימה בשגיאות. בודקים את messages"
    exit 2
}
if ($result.results.result.inDesiredState -contains $false) {
    Write-Error "זוהה configuration drift"
    exit 1
}

flowchart TB
    accTitle: מבחינים בין כשל בדיקה תקופתית לבין drift
    accDescr: בדוגמת הבדיקה התקופתית בודקים את קוד היציאה ואת הפלט של DSC, אחר כך בודקים שגיאות בדיקה ב-hadErrors, ואם inDesiredState בתוצאה הוא false מדווחים drift
    run["קוד היציאה והפלט של DSC"] --> q1{"ההרצה נכשלה או אין פלט?"}
    q1 -->|"כן"| error["כשל בדיקה (יציאה 2)"]
    q1 -->|"לא"| q2{"hadErrors?"}
    q2 -->|"כן"| error
    q2 -->|"לא"| q3{"inDesiredState הוא false?"}
    q3 -->|"כן"| drift["זוהה drift (יציאה 1)"]
    q3 -->|"לא"| ok["בבדיקה הזו אין הפרש"]

איור 12: לא מדווחים על שגיאת בדיקה כאילו “אין הפרש”. drift הוא תוצאה שבה הבדיקה הושלמה והמצב לא תואם.

הדוגמה הזו היא הצורה הבסיסית של תצורה שמנה ישירות, כמו בפרק 5, resource instances רגילים. לפני שמכניסים לניטור, מאשרים את צורת התוצאה ואת הטיפול בשגיאות מול התצורה וה-resources שאימצתם. כשל אימות מסמך או שגיאת resource ש-hadErrors מסמן אסור לסווג כמצב תקין.

7.3. את תשתית ההרצה המתוזמנת בוחרים לפי איך מנהלים את המכונה ואת הארגון

ב-DSC v3 אין LCM, ולכן מתי ומי מפעיל test מחליטים בנפרד. בלקוחות אפשר להשתמש ב-Task Scheduler, ובציי שרתים ב-CI runners. תכנון הרצה unattended מכוסה במאמר נפרד.

בארגונים שריכזו את הניהול ב-Azure, Machine Configuration הוא המעטפת המנוהלת שעושה audit ומחילה הגדרות OS על Azure VM, ודרך Azure Arc גם על שרתים on-premises.¹² בוחרים אם להריץ את הפקודה המקומית לפי לוח זמנים, או להעלות לשכבת ניהול גבוהה יותר.

8. מה לבדוק לפני ההחלה — הרשאות הרצה, secrets ואמינות

8.1. מפרידים הגדרות משתמש מהגדרות מכונה כבר בשלב התצורה

set שנוגע לכל המכונה, כמו HKLM או Windows features, דורש elevation. גם שימוש ב-Windows PowerShell PSDSC resources דרך adapter מניח הרצה כ-administrator.⁷

אם מפרידים הגדרות לפי משתמש מהגדרות לפי מכונה כבר ב-configuration document, קל יותר לתכנן את ה-execution context. לא מספיק שהרצה אינטראקטיבית עבדה; מאשרים גם את המשתמש ואת ההרשאות כשזה רץ מ-Task Scheduler וכדומה.

flowchart TB
    accTitle: מפרידים את ה-execution context לפי יעד התצורה
    accDescr: מפרידים הגדרות לפי משתמש והגדרות לפי מכונה ב-configuration document, מאשרים את המשתמש היעד ואת ההרשאות הנדרשות, ואז מעבירים להרצה אינטראקטיבית או להרצה מתוזמנת
    config["ההגדרות שרוצים לנהל"] --> user["תצורה לפי משתמש"]
    config --> machine["תצורה לפי מכונה"]
    user --> check["מאשרים משתמש יעד והרשאות"]
    machine --> check
    check --> exec["הרצה אינטראקטיבית או מתוזמנת"]

איור 13: לא מפיצים YAML באותו אופן לכולם בלי להחליט גם באיזה משתמש ובאילו הרשאות מחילים את התצורה.

8.2. לא מכניסים secrets ל-Git, ובודקים גם את ה-resources שאליהם מפנים

configuration document הוא נתונים שנכנסים ל-Git. סיסמאות ומפתחות API לא נכתבים ישירות; עושים parameterization ומעבירים בזמן הריצה. הפרמטרים בפרק 5 הם דוגמה להפרדת הבדלי סביבה, אבל גם ניתוק secrets מגוף התצורה חשוב.

קבצי .winget ו-configuration documents שהתקבלו ממאגר ציבורי קוראים לפני שמריצים. בודקים לא רק את תוכן הקובץ, אלא גם אם אפשר לסמוך על ה-resources שאליהם הוא מפנה. ל-configuration document יש כוח לשנות את המערכת דרך resources. זו חובה תפעולית שהתיעוד הרשמי מזהיר עליה במפורש.⁸

9. סיכום — מקומץ הגדרות בונים מקור אמת בר-הרצה

אם מתחילים עכשיו IaC הצהרתי ל-Windows, זה Microsoft DSC v3 (dsc.exe). אחרי שמבחינים בין ארבעת קווי ה-DSC, קודם צופים עם get ו-test בודדים, ואז מאחדים לתצורה ב-YAML/JSON. בהחלה שומרים על הסדר test, what-if, set, get, ומפרידים הכרעה, תחזית, החלה ואישור.⁵⁴

אפשר להחיל שוב ושוב כי כותבים “מצב רצוי” ולא “צעדים”, ו-DSC וה-resources לוקחים על עצמם את ההשוואה ואת ההחלה הנדרשת. PSDSC resources קיימים עושים reuse דרך adapters, ונכסי WinGet מתחברים אחרי שמעבירים את הפורמט לסכמת v3.³¹⁰¹¹

בתפעול מתמשך יוצאים מכך של-v3 עצמו אין LCM. מקור האמת של התצורה יושב ב-Git, מזהים drift ב-test תקופתי, מתקנים אם התצורה נכונה, ומעדכנים את התצורה אם המציאות נכונה.¹ הרשאות הרצה, secrets ואמינות היעד שאליו מפנים מתכננים יחד עם סדר ההחלה.

אין צורך לשאת סטייה בין runbook למציאות בלי יכולת למצוא אותה. מתחילים בכך שכותבים קומץ הגדרות של המכונה שלכם ל-configuration document ומריצים test, והופכים את הסטייה להפרש שאפשר לזהות.

מאמרים קשורים

• אוטומציה של kitting מחשבים עם winget + PowerShell — הופכים את ה-runbook לבר-הרצה
• האם לעבור מ-BAT ל-PowerShell — קריטריונים להחלטה והמעבר בפועל
• כשמשימות Task Scheduler לא רצות או יוצאות עם 0x1 — בידוד הסיבה ותכנון תפעול בטוח
• מדריך מעבר מ-GPO ל-Intune — הפתרון המעשי ל-SMB
• ניהול Windows Update אחרי ש-WSUS הפך ל-deprecated

תחומי ייעוץ קשורים

KomuraSoft LLC מסייעת במעבר של תצורת לקוחות ושרתים של Windows לניהול הצהרתי, באוטומציה של kitting ושל סביבת סטנדרט פנימית, ובהפיכת runbooks שתלויים באדם אחד לבר-הרצה.

• ייעוץ טכני וסקירת תכנון
• שינוי ותחזוקה של תוכנה קיימת ל-Windows
• שימוש חוזר בנכסים קיימים והעברתם
• יצירת קשר

קישורים

מאמרים קשורים

מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

נראה שיש כמה גרסאות של DSC. באיזו להשתמש?

אם מתחילים עכשיו ניהול תצורה הצהרתי, משתמשים ב-Microsoft DSC v3 (dsc.exe). ל-DSC יש ארבעה קווים: PSDSC v1.1 שמובנה ב-Windows PowerShell 5.1, PSDSC v2 כמודול ל-PowerShell 7, PSDSC v3 (preview) שמשמש לתמיכת Linux של Azure Machine Configuration, ו-Microsoft DSC v3 שנכתב מחדש כפקודה עצמאית בלי תלות ב-PowerShell. v3 הוא cross-platform, כותב תצורה כנתוני YAML/JSON במקום סקריפטי PowerShell, ויכול לעשות reuse ל-PSDSC resources קיימים דרך adapters. בחיפוש, הוספת "DSC v3" או "dsc.exe" מקלה להפריד את התוצאות מחומר של דורות ישנים.

מה ההבדל בין DSC v3 לבין סקריפט runbook (BAT או PowerShell)?

סקריפט runbook מתאר "את הצעדים להרצה", ולכן צריך לבנות idempotency בעצמכם כדי למנוע apply כפול או שגיאות בהרצה השנייה. DSC כותב את "המצב הרצוי" כנתונים, וה-resources לוקחים על עצמם את ההשוואה למצב הנוכחי (test) ואת החלת ההפרש (set). לא משנה כמה פעמים מריצים את אותו configuration document, הוא לא נוגע בפריטים שכבר במצב הרצוי, ולכן אפשר להפיץ ולהריץ שוב בלי לדאוג למספר ההרצות. ומכיוון שהתצורה היא נתוני YAML, סקירות diff וניהול גרסאות ב-Git קלות בהרבה מאשר עם סקריפטים.

האם נכסי PowerShell DSC ו-WinGet Configuration הקיימים יתבזבזו?

לא. DSC v3 יכול לקרוא ל-PSDSC resources קיימים מבוססי class ומבוססי MOF דרך adapter resources (Microsoft.Adapter/PowerShell ו-Microsoft.Adapter/WindowsPowerShell ב-DSC 3.2 ואילך; Microsoft.DSC/PowerShell ו-Microsoft.Windows/WindowsPowerShell לפני כן). WinGet Configuration, מסכמת v3 שלו (WinGet 1.11 ואילך), משתמש ב-DSC v3 כמעבד. קבצי .winget בפורמט v2 ממשיכים לרוץ על המעבד הקודם, אבל כדי להעלות אותם למעבד DSC v3 צריך להמיר אותם לפורמט v3 לפי מדריך ההמרה הרשמי.

איך אוכפים תצורה "ברציפות" עם DSC v3?

DSC v3 עצמו הוא כלי שמופעל כפקודה; אין לו agent תושב או מנגנון תיקון אוטומטי כמו ה-LCM (Local Configuration Manager) של v1.1. אם צריך apply ו-audit מתמשכים, או שבונים זיהוי drift משלכם בהרצת dsc config test מ-Task Scheduler או מ-CI, או שמעלים את זה לשכבת orchestration כמו Azure Machine Configuration (שיכולה לכסות גם שרתים on-premises דרך Azure Arc).

מפחיד להריץ dsc config set ישר. אפשר לבדוק את ההשפעה מראש?

כן. הרצת dsc config test מראה אילו resource instances אינם במצב הרצוי, בלי לבצע שינויים. בנוסף, ל-dsc config set יש אפשרות --what-if שמציגה תחזית של "מה היה משתנה, ואיך, אילו זה היה רץ" בלי לשנות בפועל. בודקים קודם את ההפרשים עם test ועם --what-if, ומריצים set רק כשמרוצים; הסדר הזה בטוח.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.