הכנת אשכול Windows לפריסה

בדף הזה מוסבר איך להכין את אשכול Windows לפריסה.

לפני שמתחילים

בחירה והגדרה של מאגר Docker

כחלק מהפריסה, יוצרים את קובץ האימג' של Docker של הקונטיינר ומעלים אותו למאגר Docker.

למאגר Docker אפשר לבחור להשתמש באחת מהאפשרויות הבאות:

  • Artifact Registry

  • כל מאגר Docker שתומך באימות בסיסי

הפתרון המומלץ הוא להשתמש ב-Artifact Registry באותו פרויקט של אשכול הפריסה. ל-GKE יש גישה למאגר כברירת מחדל. מידע נוסף זמין במאמר בנושא דרישות השילוב עם GKE.

אם רוצים להשתמש במאגר Docker פרטי, אפשר לקרוא איך מגדירים את המאגר.

הגדרת עומסי עבודה שהועברו לשימוש ב-gMSA

עומסי עבודה של אפליקציות Windows IIS הם לרוב חלק מ-Active Directory (AD) ופועלים באמצעות זהויות דומיין. כשמעבירים מכונות וירטואליות כאלה לקונטיינרים, הקונטיינרים עצמם לא מצטרפים לדומיין, אבל הצמתים של אשכול Kubernetes המארח שלהם יכולים להצטרף לדומיין.

כשפורסים את מאגרי התגים שהועברו לאשכול, אפשר להשתמש בחשבון שירות מנוהל על ידי קבוצה (gMSA). משתמשים ב-gMSA כדי להפעיל את הקונטיינר בזהות של חשבון שירות ספציפי. מצרפים gMSA באשכול Kubernetes כחלק מהגדרת ה-Pod, ולא כהגדרת זהות סטטית בתוך קובץ אימג' של קונטיינר.

הכלי Migrate to Containers עוזר לכם בתהליך של שינוי עומסי העבודה. הכלי Migrate to Containers מגלה באופן אוטומטי את ההגדרה של מאגרי האפליקציות של IIS ומוסיף המלצות לתוכנית ההעברה שנוצרת. לאחר מכן תוכלו לבדוק את ההמלצות האלה ולשנות אותן בהתאם לסביבה ולדרישות הספציפיות שלכם.

אם הכלי Migrate to Containers קובע שההגדרה של מאגר אפליקציות לא מחייבת gMSA, הוא שומר על ההגדרה המקורית של מאגר האפליקציות. לדוגמה, כשמשתמשים בסוג חשבון מובנה כמו ApplicationPoolIdentity, NetworkService, LocalSystem או LocalService.

כדי לתמוך ב-gMSA במאגר Windows שהועבר, צריך:

  1. עורכים את תוכנית המיגרציה כדי להגדיר את המאפיינים הנדרשים להגדרת המיכל שהועבר לשימוש בחשבון שירות מנוהל של קבוצת מחשבים (gMSA).

  2. הגדרת אשכול היעד שמארח את מאגר התגים שנפרס

הגדרת אשכול יעד לתמיכה ב-gMSA

מצרפים gMSA באשכול Kubernetes כחלק מהגדרת ה-Pod, ולא כהגדרת זהות סטטית בתוך קובץ אימג' של קונטיינר.

כדי להגדיר אשכול שמארח את מאגר Windows שהועבר כך שיתמוך ב-gMSA, צריך:

  1. הגדרתם Active Directory למכונות וירטואליות כדי שהן יצטרפו אוטומטית לדומיין.

  2. הגדרת gMSA עבור תרמילים ומאגרי תגים של Windows.

למידע נוסף, קראו את המאמרים הבאים:

פריסת קונטיינר כשמאחסנים אישורי SSL כסודות של Kubernetes

מומלץ להשתמש ב-Cloud Load Balancing, ב-Ingress או ב-Cloud Service Mesh כקצה קדמי של HTTPS כדי לאבטח גישה חיצונית לקונטיינר שפרסתם. האפשרות הזו מאפשרת לאבטח תקשורת חיצונית בלי לכלול אישורים בתוך האשכול. מידע נוסף מופיע במאמר בנושא התאמה אישית של תוכנית העברה.

אפשר גם לאחסן אישורי Secure Sockets Layer‏ (SSL) כסודות של Kubernetes ולהטמיע אותם בזמן הריצה בתוך הקונטיינר.

כדי להשתמש בסודות של Kubernetes:

  1. יוצרים קובץ PFX עם האישור והסיסמה.

  2. יוצרים קובץ YAML להגדרת הגישה לאתר:

    sites:
 - sitename: "sitename"
   sslport: 443
   pfxpath: c:\sslconfig\pfx
   password: "password"
   thumbprint: "3e858d0551fc0536f52d411dad92b680a4fad4da"

    כאשר:

    • ‫sitename מציין את שם האתר שהוגדר לשימוש ב-SSL. המאפיין sites יכול להכיל כמה רשומות sitename.

    • ‫sslport מציין את היציאה להאזנה לחיבורי SSL (בדרך כלל 443).

    • ‫pfxpath מציין את הנתיב לקובץ ה-PFX. מגדירים אותו כחלק מvolumeMounts של פריסת ה-Pod.

    • ‫password מציין את הסיסמה של קובץ ה-PFX.

    • ‫thumbprint מציין את טביעת האצבע של קובץ ה-PFX בפורמט SHA-1 שאפשר לאחזר באמצעות פקודת PowerShell:

      Get-PfxCertificate -FilePath "path to pfx"

      או להציג אותו ב-Certificate Manager של Windows.

  3. יוצרים את הסוד של Kubernetes:

    kubectl create secret generic secret-name --from-file=pfx=path-to-pfx --from-file=config=path-to-config

  4. יוצרים את עוצמת הקול ואת נקודת העלייה של עוצמת הקול בפריסה של התמונה:

    apiVersion: v1
kind: Pod
metadata:
 name: iis-pod
 labels:
   app: iis-server-simple
 spec:
   nodeSelector:
     kubernetes.io/os: windows
   containers:
   - name: iis-server
     image: your-image-url
     volumeMounts:
     - name: ssl-secret
       mountPath: c:\sslconfig
     env:
     - name: M4A_CERT_YAML
       value: c:\sslconfig\config
   volumes:
   - name: ssl-secret
     secret:
       secretName: secret-name

    כאשר:

    • ‫mountPath הוא אותו נתיב שצוין על ידי pfxpath בקובץ התצורה שיצרתם בשלב 2.
    • ‫M4A_CERT_YAML הוא משתנה סביבה שמוגדר כנתיב המלא לקובץ ה-YAML של התצורה שיצרתם בשלב 2.
    • ‫secret-name הוא השם של הסוד שיצרתם בשלב 3.

הגדרת SSL

מומלץ לא לאחסן מפתחות פרטיים של אישורי SSL בתוך תמונת קונטיינר, כי כל מי שקורא את התמונה יכול לגשת אליהם. הכלי 'העברה אל Containers' מספק כמה דרכים לטיפול ב-SSL ב-Windows.

שימוש באישור שנוצר באופן אוטומטי עם חתימה עצמית

כברירת מחדל, למאגר Windows עם קישור HTTPS מוקצה אישור בחתימה עצמית שנוצר אוטומטית, ונוצר במהלך האתחול של מאגר Docker. ההגדרה הזו מאפשרת לכם לבדוק את עומס העבודה שהועבר, אבל אי אפשר להשתמש בה בסביבת ייצור. האישור הוא גם בחתימה עצמית וגם נוצר מחדש בכל פעם שהקונטיינר מופעל.

מומלץ – שימוש ב-Cloud Load Balancing, ב-Ingress או ב-Cloud Service Mesh

אפשר להתאים אישית את הקישורים בתוכנית ההעברה כדי להשתמש ב-HTTP. אחר כך משתמשים בCloud Load Balancing, ב-Ingress או ב-Cloud Service Mesh כקצה קדמי של HTTPS כדי לאבטח גישה חיצונית. האפשרות הזו מאפשרת לאבטח תקשורת חיצונית בלי לכלול אישורים באשכול.

  • כדי להתאים אישית את הקישור, עורכים את ההגדרה site בתוכנית ההעברה שמייצגת את ההעברה כדי להגדיר את protocol ל-http:

    sites:
  site:
  - applications:
    - path: /
      virtualdirectories:
        - path: /
          physicalpath: '%SystemDrive%\inetpub\wwwroot'
          bindings:
          - port: 8080
            protocol: http
          name: Default Web Site

לאחר מכן אפשר להעביר בקשות מהקצה הקדמי של HTTPS לנתיב ולפורט של HTTP בעומס העבודה של Windows.

שמירת אישורי SSL כסודות של Kubernetes

מומלץ להשתמש ב-Cloud Load Balancing, ב-Ingress או ב-Cloud Service Mesh כחזית HTTPS כדי לאבטח גישה חיצונית. עם זאת, אפשר גם לאחסן אישורי SSL כסודות של Kubernetes ולהטמיע אותם בזמן הריצה בתוך הקונטיינר.

כדי להשתמש באישורי SSL שמאוחסנים כסודות של Kubernetes, צריך לערוך את קובץ האימג' של הפריסה של הקונטיינר. מידע נוסף זמין במאמר בנושא פריסת קונטיינר כשמאחסנים אישורי SSL כסודות של Kubernetes.

הגדרת רישום ביומן ב-Cloud Logging

הכלי Migrate to Containers משתמש בכלי LogMonitor כדי לחלץ יומנים מקונטיינר של Windows ולהעביר אותם לאשכול GKE. היומנים האלה מועברים אוטומטית אל Cloud Logging, שכולל חבילת כלים למעקב אחרי הקונטיינרים.

כברירת מחדל, כלי Migrate to Containers מפעיל את הרישום ביומן של IIS כדי לעקוב אחרי יומני IIS, וגם מעביר את יומני האירועים של האפליקציה או המערכת אל Cloud Logging.

הגדרת רישום ביומן

הרחבת הקובץ artifacts.zip שנוצר יוצרת כמה ספריות, כולל הספרייה m4a. הספרייה מכילה תיקייה לכל תמונה. בספרייה m4a כלול הקובץ LogMonitorConfig.json שאפשר לערוך כדי לשלוט ברישום ביומן.

מידע נוסף על עריכת LogMonitorConfig.json זמין במאמר יצירת קובץ הגדרה.

הגדרה של רשימות ACL

כדי שאפליקציות מסוימות של IIS יפעלו בצורה תקינה, צריך להגדיר הרשאות ספציפיות של רשימות בקרת גישה (ACL) בקבצים ובתיקיות. במהלך ההעברה, Migrate to Containers סורק באופן אוטומטי את כל האפליקציות של IIS שהועברו, מוסיף את כל ההרשאות הספציפיות שהוגדרו במכונה הווירטואלית של המקור שחלות על חשבונות IIS (החשבון IUSR והקבוצה IIS_IUSRS), ומחיל אותן על הקבצים והספריות שהועתקו בתמונת הקונטיינר שנוצרה.

מכיוון שתמונות של קונטיינרים ב-Windows לא תומכות בהגדרת ACL כחלק מהפקודה COPY של Docker, ה-ACL מוגדר בסקריפט שנקרא set_acls.bat. המעבר ל-Containers יוצר באופן אוטומטי set_acls.bat בספרייה של התמונה שנוצרה עבור אפליקציית Windows הספציפית שלכם. ‫Migrate to Containers מתקשר אל set_acls.bat כשמריצים את הפקודה docker build.

עריכה של set_acls.bat כדי להוסיף או להסיר הרשאות בהתאמה אישית, או עריכה של הרשאות שלא קשורות למשתמשים ספציפיים ב-IIS ולכן לא זוהו על ידי Migrate to Containers.

הסקריפט משתמש בכלי icacls המובנה ב-Windows כדי להגדיר הרשאות.

מידע על מטמון האסמבלי הגלובלי של ‎ .NET

הכלי Migrate to Containers סורק את מטמון ההרכבות הגלובליות (GAC) של .NET בתמונת המקור כדי למצוא משאבי .NET שמותקנים במכונת המקור ולא זמינים כחלק מהתמונות הרשמיות. כל קובץ DLL שמתגלה מועתק להקשר של Docker ומוגדר כחלק מה-build של קובץ האימג' של היעד באמצעות סקריפט של כלי השירות install_gac.ps1.

כל רכיבי ה-‎ .NET מועתקים להקשר של Docker בספרייה m4a\gac. כדי להסיר רכיבים מהתמונה, מוחקים אותם מהספרייה m4a\gac.

רישום של DLL של אובייקט COM

קובצי DLL שחושפים אובייקטים של COM נסרקים ונרשמים באופן אוטומטי. במהלך שלב החילוץ, הקבצים המועתקים נסרקים כדי לאתר קובצי DLL שרשומים כאובייקטים של COM, ואז הם נרשמים במאגר.

התהליך הזה מתבצע ללא קלט של משתמשים. עם זאת, אפשר להשפיע על התהליך הזה על ידי הוספה של עוד קובצי DLL להעתקה. אם צריך, קובצי ה-DLL האלה נבדקים בתורם ונרשמים.

המאמרים הבאים