כיצד ליצור זרימות עבודה היברידיות של Windows-Linux בסביבות מודרניות

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

כשמשלבים Windows ו-Linux, יחד עם מספר עננים, צריך יותר מסתם סקריפטים טובים. צריך אסטרטגיה ברורה עבור... צור זרימות עבודה היברידיות של Windows-Linux שמשלבים אוטומציה, תזמור, אבטחה וניטור באמצעות החלקים הנכונים: Azure Automation ו-Hybrid Runbook Worker, Logic Apps במצב היברידי, Ansible, AWS Systems Manager, כלי שולחן עבודה כמו WinApps, וכל שכבת הפיתוח והשיתוף המודרנית ב-Microsoft 365 ו-Windows.

מדוע זרימות עבודה היברידיות של Windows-Linux אינן עוד אופציונליות?

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

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

בהקשר זה, עולים מספר חלקים מרכזיים: Azure Automation עם Hybrid Runbook Worker כדי להביא אוטומציה לרשת שלך, אפליקציות לוגיקה במצב היברידי לשילוב מערכות מבוזרותAnsible כשפה משותפת בין לינוקס לחלונות, AWS Systems Manager עבור צמתים היברידיים, וכלים כמו WinApps המאפשרים להשתמש ביישומי חלונות משולחנות עבודה של לינוקס בצורה חלקה.

אוטומציה היברידית עם Azure Automation ו-Hybrid Runbook Worker

עמוד תווך ראשון ליצירת זרימות עבודה היברידיות הוא הבא ספרי ריצה של Azure Automation לשרתי Windows ו-Linux המקומיים שלך או לסביבות ענן אחרות.כאן נכנסת לתמונה התכונה Hybrid Runbook Worker, המאפשרת להריץ runbooks ישירות על המכונות המארחות תפקיד זה.

ספרי הריצה ממשיכים מאוחסן ומנוהל ב-Azure Automationעם זאת, הם מועברים לצוות אחד או יותר הרשומים כ-Hybrid Runbook Workers. זה מאפשר לך להפוך משאבים לאוטומטיים מקומיים או בעננים אחרים מבלי לחשוף אותם ישירות לאינטרנט או שתצטרך לכתוב מחדש את כל האוטומציה שלך מחוץ ל-Azure.

הרחבות לעומת סוכן קלאסי: שתי דרכים להתקנת Hybrid Runbook Worker

כיום ניתן לפרוס את תפקיד המשתמש Hybrid Runbook Worker על ידי שתי פלטפורמות התקנה נפרדות: מבוססות הרחבות ומבוססת סוכןלאחר ההתקנה, אופן ביצוע ה-runbook זהה, אך גישת ההרחבות מפשטת באופן קיצוני את תהליך ההטמעה והתחזוקה.

האפשרות הקלאסית הייתה תלויה ב- סוכן Log Analyticsכתוצאה מכך, תהליך ארוך יותר ומועד יותר לשגיאות. המודל המבוסס על הרחבות משתלב באופן טבעי עם מסגרת ההרחבות של מכונות וירטואליות של Azure, תוך שימוש בסוכן Azure VM עבור מכונות וירטואליות של Azure ובסוכן Azure Connected Machine עבור מכונות שאינן Azure, כולל שרתי Azure Arc ושרתים התומכים ב-VMware vSphere עבור Arc.

שני סוגי ה-Hybrid Runbook Worker יכולים לחיות באותה מכונהוההתקנה מבוססת ההרחבה אינה מפריעה למופעים שכבר פרסתם באמצעות הסוכן המסורתי, מה שמאפשר העברות חלקות ומצטברות.

יתרונות עיקריים של הגישה המבוססת על הרחבה

המודל מבוסס ההרחבות מפחית משמעותית את החיכוך התפעולי בעת פריסת Hybrid Runbook Worker של משתמש על ידי ביטול תלות מיותרות. היתרונות העיקריים כוללים:

• קליטה חלקה הרבה יותראינך תלוי עוד בסוכן Log Analytics כדי לרשום עובדים, ובכך נמנע מתהליכים מרובי שלבים ומשגיאות נפוצות בהתקנות ידניות.
• ניהול מרכזי כבר ניתן להרחבהאינטגרציה ישירה עם זהות Azure Resource Manager (ARM), המאפשרת ניהול פריסה בקנה מידה גדול באמצעות מדיניות, תבניות ARM, Bicep, PowerShell או CRI.
• אימות באמצעות מזהה כניסה של מיקרוסופטזהויות מנוהלות שהוקצו על ידי המערכת מנוצלות במכונות וירטואליות, כך ש אישורים מנוהלים בצורה מאוחדת ובלי לאחסן אותם בטקסט רגיל בסקריפטים או בתצורות.
• אותו מודל עבור Azure ו-Azure Arcהן מכונות בתוך Azure והן שרתים פיזיים או מכונות וירטואליות בספקים אחרים (דרך Azure Arc) מנוהלות. עם אותה חוויהזה מפשט מאוד סביבות היברידיות וסביבות מרובות עננים.
• נתיבי כניסה מרוביםניתן להתקין את התפקיד מתוך Azure Portal, PowerShell, Bicep, תבניות ARM, Azure REST או CLI, או ישירות מהכרטיסייה של הרחבות של כל מכונה או שרת וירטואליים התומכים ב-Arc.
• עדכונים אוטומטיים של גרסאות משניותכברירת מחדל, Workers מבוססי הרחבות מתעדכנים אוטומטית לגרסאות משניות חדשות, מה שמפחית את נטל התחזוקה הכרוכה בשמירה על עדכניות. תיקוני אבטחה ושיפוריםעם זאת, הגרסאות העיקריות עדיין דורשות עדכונים ידניים.

מגבלות וארגון של עובדי Runbook היברידיים

מבחינת קיבולת, עבור כל חשבון אוטומציה ניתן להכיל עד 4000 מערכת Runbook Workers היברידית ו-4000 משתמשיםאם עליך לנהל יותר מ-4000 מכונות, מומלץ ליצור חשבון אוטומציה חדש כדי לחלק את העומס.

כל משתמש Hybrid Runbook Worker שייך ל- קבוצת עובדים שאתה מגדיר בעת התקנתו. קבוצה יכולה לארח מופע יחיד או מספר מופעים לצורך זמינות גבוהה. מכונה יחידה יכולה לשלוח פעימות לב רק אל חשבון אוטומציהכלומר, אינך יכול להיות רשום כעובד במספר חשבונות בו זמנית.

הקבוצות נועדו להציע זמינות גבוהה ואיזון עומסים באמצעות חלוקת עבודות בין חבריה. עובדים משתמשים במנגנון סקר: כל עובד פעיל מבצע שאילתה לשירות כל 30 שניות ויכול לאסוף עד 4 עבודות לכל "פינג". אם קצב הגעת העבודות עולה על הקיבולת המשולבת של העובדים, חלקם עלולים להיות מושעים עם שגיאה.

אם אף עובד בקבוצה לא ביצע פינג לשירות ב-30 הדקות האחרונות, Azure מחשיב את הקבוצה כפעילה. אין לה עובדים פעיליםבמקרה כזה, מתבצע ניסיון חוזר של משימות שלוש פעמים ולאחר מכן מושעות. התנהגות זו היא המפתח לקביעת גודל נכון של מספר העובדים בהתבסס על עומס העבודה הצפוי.

יכולות ומגבלות ביצוע ב-Hybrid Runbook Worker

פרט חשוב הוא שמופע של Hybrid Runbook Worker זה לא מוגבל על ידי המגבלות של ארגז החול של Azure בנוגע לשטח דיסק, זיכרון או שקעי רשת, המגבלות האמיתיות נקבעות על ידי המשאבים הפיזיים של השרת, החיוניים להפעלת אוטומציות ארוכות טווח או אינטנסיביות מאוד.

אם מחשב המארח של Hybrid Runbook Worker מופעל מחדש בזמן ש-runbook פועל, המשימה תופעל מחדש מההתחלה או מה- נקודת הביקורת האחרונה במקרה של ספרי ריצה של PowerShell Workflow, אם אותה משימה מופעלת מחדש יותר משלוש פעמים, היא מושעית כדי למנוע לולאות אינסופיות.

ב-Windows, משימות רצות ב- חשבון מערכת מקומיתובלינוקס תחת החשבון nxautomationמכיוון שמחשבי ריצה אלה ניגשים לעתים קרובות למשאבים מחוץ ל-Azure, הם אינם יכולים להסתמך אך ורק על מנגנון האימות הטיפוסי של ספרי ריצה של Azure; הם זקוקים אימות ספציפי עבור משאבים מקומיים או להשתמש בזהויות מנוהלות וחשבונות ביצוע שתצורתם נקבעה כראוי.

כדי לארגן טוב יותר את זרימות העבודה, ניתן לרשום את אותה מכונה ב מספר קבוצות Hybrid Runbook Worker בתוך אותו חשבון, הפניית runbooks שונים לכל קבוצה בהתאם לסוג העומס, לוחות הזמנים או הקריטיות.

תרחישים אופייניים עם Hybrid Runbook Worker

מקרי השימוש הנפוצים ביותר עבור Hybrid Runbook Worker משלבים משאבי Windows ו-Linux בתוך Azure ומחוצה לו, ויוצרים זרימות עבודה היברידיות באמת:

• ניהול מכונות אורחהפעלת runbooks ישירות על מכונות וירטואליות של Azure או על שרתים מחוץ ל-Azure הרשומים ב-Azure Arc (כולל VMware התומכת ב-Arc), בין אם מדובר ב-Windows או ב-Linux.
• התגברות על מגבלות ארגז החולעבור פעולות שחורגות ממגבלת העבודה בענן של שלוש שעות, צורכות משאבים רבים או דורשות הרשאות מוגברות, עובדים היברידיים מספקים סביבה. גמיש יותר וללא המגבלות הללו.
• דרישות ריבונות וביטחוןבארגונים שבהם עיבוד נתונים מסוימים בענן אינו מותר, ניתן לשמור אותם ב מכונות מקומיות הומרו לעובדים היברידיים וכך לעמוד בתקנות הפנימיות והחיצוניות.
• אוטומציה בסביבות מרובות עננים וסביבות מקומיותפשוט הוסיפו מכונה כמו Worker כדי להפעיל אוטומציה למכונות אחרות ברשת המקומית או בעננים שונים, הן ב-Windows והן ב-Linux.
• גישה פרטית לשירותים מרשתות VNהפעלת runbooks על Workers המחוברים לרשת וירטואלית של Azure, תוך גישה לשירותים אחרים באופן פרטי. בלי לפתוח חיבורי אינטרנט.

כדי לפרוס מופע של Hybrid Runbook Worker ב-Windows או Linux באמצעות גישת ההרחבות החדשה, פשוט עקוב אחר המדריך ב יישום באמצעות הרחבות ב-Azure Automation, אשר מפרט את השימוש בהרחבות VM ו-Azure Arc עבור שרתים.

תכנון רשת ותוויות שירות עבור Hybrid Runbook Worker

לפני פתיחת פורטים באופן כושל, מומלץ לבדוק את תצורת רשת Azure Automation, מכיוון שהוא מציין את הפורטים, כתובות ה-URL ודרישות אחרות עבור עובדים כדי לתקשר בצורה תקינה עם השירות.

תומך ב-Azure Automation תוויות שירות רשת וירטואליתהחל מהתג GuestAndHybridManagement. במקום לפרט טווחי IP ספציפיים בכללי NSG או Azure Firewall, ניתן להשתמש בתג זה ישירות במקור או ביעד של הכללים כדי לאפשר או לדחות תעבורה לשירות האוטומציה.

התג GuestAndHybridManagement מכסה כתובות IP המשמשות, לדוגמה, עבור הפעלת webhooks מתוך VNet או לאפשר לסוכני Hybrid Runbook Worker ו-State Configuration לתקשר עם Azure Automation. זה לא מאפשר הגבלות מבוססות אזור, אבל זה מפשט מאוד את ניהול אבטחת הרשת.

תמיכה במטענים של IL5 ב-Azure Government

אם אתם עובדים עם דרישות אבטחה גבוהות מאוד, Azure Automation תומך עומסי עבודה בעלי השפעה ברמה 5 (IL5) ב-Azure Government שימוש ב-Hybrid Runbook Worker בשתי תצורות:

• מכונות וירטואליות מבודדות אשר צורכים מארח פיזי שלם, ומספקים את רמת הבידוד הנדרשת על ידי IL5.
• מארח ייעודי של Azureכאשר מכונה וירטואלית אחת או יותר פועלות על שרתים פיזיים המוקדשים למנוי שלך, מה שמבטיח בידוד ברמת החומרה.

אפליקציות לוגיקה של Azure (סטנדרטיות) במצב היברידי עבור זרימות Windows-Linux

מרכיב מפתח נוסף ליצירת זרימות עבודה היברידיות של Windows-Linux הוא המודל של יישום היברידי של Azure Logic Apps (סטנדרטי)אפשרות זו מאפשרת לך לבנות ולארח פתרונות אינטגרציה בסביבות מחוברות חלקית הדורשות עיבוד ואחסון מקומיים יחד עם גישה לרשת פנימית.

במודל זה, זמן הריצה של Logic Apps מתארח בתשתית שלך כחלק מהרחבת Azure Container Apps, המסוגלת להימצא במערכות מקומיות, עננים פרטיים או עננים ציבוריים, ולהתחבר לשרתי Windows ו-Linux או לשירותי SaaS.

המגבלות הנוכחיות של המודל ההיברידי של Logic Apps

בעת עבודה במצב היברידי עם Logic Apps Standard, יש לקחת בחשבון מספר מגבלות:

• זה זמין רק ב אזורים מסוימים של Azure (מרכז ומזרח ארה"ב, מזרח אסיה, דרום מזרח אסיה, מרכז שבדיה, דרום בריטניה, מערב אירופה, מערב ארה"ב, בין היתר המפורטים בתיעוד הרשמי).
• במצב מחובר חלקית, זמן הריצה עשוי להישאר מנותק עד 24 שעות תוך שמירה על יומני נתוניםמעבר לתקופה זו, יומני רישום עלולים ללכת לאיבוד.
• מספר תכונות של תקן Logic Apps לדייר יחיד אינן נתמכות בהיברידי, כגון משבצות יישום, מעקב אחר תהליכים עסקיים, תקינות משאבים בפורטל או אימות עם זהויות מנוהלות עבור פעולות מחבר מסוימות באשכולות Kubernetes התומכים ב-Azure Arc.
• טריגרים מסוימים מבוססי פונקציה (כגון Blob, Cosmos DB או Event Hubs) דורשים הגדרת מחרוזת החיבור של חשבון האחסון במשתנה היישום AzureWebJobsStorageאו בפורטל Azure או בקובץ local.settings.json של פרויקט Logic Apps ב-VS Code.

דרישות מוקדמות ליישום היברידי

כדי להגדיר זרימת עבודה היברידית עם Logic Apps Standard, תזדקק, בנוסף למנוי Azure, לסדרה של משאבים מקומיים באותה רשת:

• Un אשכול שירות Kubernetes של Azure מחובר ל-Azure Arc, אשר ישמש כפלטפורמת הביצוע עבור מכולות Logic Apps.
• א מסד נתונים SQL מקומי לאחסון היסטוריית הביצועים, הקלטים והפלטים של זרימות העבודה.
• Un שיתוף קבצים של SMB כדי לאחסן את הארטיפקטים המשמשים את הזרימות.

כדי לפתח ולפרוס זרימות עבודה אלו, מקובל להשתמש בקוד Visual Studio עם הרחבת Azure Logic Apps (סטנדרטית)אשר מאפשר עריכה, בדיקה ופרסום בסביבה ההיברידית שהקמת.

ניהול גרסאות, טלמטריה וקנה מידה באפליקציות לוגיקה היברידיות

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

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

מבחינת משאבים, ניתן להתאים את ההגדרות דרך Azure Portal זיכרון ומעבד vCPU מוקצה למכולה של אפליקציית לוגיקה סטנדרטית. מותר לשנות את ליבות המעבד (לדוגמה, מ-0,25 עד 2 vCPU) ואת הזיכרון (לדוגמה, מ-0,1 עד 4 GiB), עם השפעה ישירה הן על ביצועי הזרימה והן על החיוב.

ניתן גם להגדיר את קנה מידה רפליקה אשר נוצר בתגובה לאירועי טריגר. מספר מינימלי ומקסימלי של עותקים משוכפלים (עד 1000) מוגדר, וכללי קנה מידה מתקדמים יותר מנוהלים מ-Azure Container Apps, מה שמאפשר התאמה דינמית לקפיצות עומס בזרימות אינטגרציה המשפיעות על מערכות Windows ו-Linux.

כניסה, אימות וסודות בסביבות היברידיות

ניתן לחשוף את Logic Apps Standard לאינטרנט הציבורי, לרשת VNet, או אפליקציות לוגיקה אחרות מאותה סביבה על ידי הגדרת אפשרות ה-ingress, Azure מטפל בהחלת כללים לניתוב תעבורת HTTP או TCP נכנסת מבלי שתצטרך להקצות באופן ידני מאזני עומסים נוספים או כתובות IP ציבוריות.

באשכולות Kubernetes התומכים ב-Azure Arc, אימות חיבור API מנוהל אינו יכול להשתמש בזהויות מנוהלות באופן טבעי. במקום זאת, עליך ליצור רישום אפליקציית מיקרוסופט הזן מזהה ולהשתמש בו כבסיס לחיבורים:

• מתוך Azure Portal או Azure CLI אתה יוצר יישום ואוסף מזהה לקוח, מזהה דייר, מזהה אובייקט וסוד לקוח.
• לאחר מכן אתה מוסיף את הערכים האלה כ משתני סביבה במשאב הסטנדרטי של Logic Apps (לדוגמה, WORKFLOWAPP_AAD_CLIENTID, WORKFLOWAPP_AAD_OBJECTID, WORKFLOWAPP_AAD_TENANTID, WORKFLOWAPP_AAD_CLIENTSECRET).
• באופן אופציונלי, ניתן לאחסן clientId ו- clientSecret כ- סודות המשאב עצמו ולאחר מכן להפנות אליהם ממשתני סביבה לצורך אבטחה רבה יותר.

לוגיקת האימות שתצורתה מוגדרת בדרך זו מאפשרת לזרימות היברידיות לתקשר עם ממשקי API של Azure ושירותים מוגנים אחרים, תוך שמירה על מודל אישורים חזק.

בעיות נפוצות ופתרונות באפליקציות לוגיקה היברידיות

בסביבות היברידיות, תמיד יכולות לצוץ הפתעות. כדי לאבחן בעיות בתצורת הסביבה או פריסות כושלות מהפורטל, מיקרוסופט מפרסמת... פתרון בעיות בסקריפט PowerShell.ps1 במאגר הרשמי של Logic Apps שסוקר נקודות כשל אופייניות.

באשכולות Kubernetes המחוברים ל-Azure Arc, דפוסים של שימוש גבוה בזיכרוןבמקרים אלה, ההמלצה היא לשנות את קנה המידה של קבוצות הצמתים אופקית או לאפשר מדרגיות אוטומטית של אשכולות.

אם אפליקציית הלוגיקה אינה מתחילה כראוי, מומלץ לבדוק את מצב המשאב מפורטל Azure, ואם יש שגיאה, למשוך אותו מ... kubectl כדי לבדוק את התרמיליםהודעות כמו "יותר מדי פודים" מצביעות על קיבולת לא מספקת של צומת, בעוד שאזהרות לגבי PersistentVolumeClaims לא מקושרים בדרך כלל מצביעות על בעיות ב- מנהל התקן CSI של SMBבמקרה כזה, התקנת מנהל ההתקן smb.csi.k8s.io באמצעות Helm היא הצעד ההכרחי לפני שתמשיך.

אוטומציה מאוחדת עם Ansible עבור Windows ו- Linux

מעבר למערכת האקולוגית של Azure, גישה רבת עוצמה מאוד לזרימות עבודה היברידיות של Windows-Linux היא להשתמש Red Hat Ansible Automation Platform (AAP) כשפה מאוחדת. Ansible מפרקת את ההפרדה ההיסטורית בין סקריפטי bash בלינוקס לבין PowerShell או משימות מתוזמנות ב-Windows.

עם אותו ספר משחקים שנכתב ב-YAML אתה יכול הגדרה, פריסה ותחזוקה של שרתי Windows ו- Linuxל-Ansible יש מודולים מקוריים לשני העולמות, המכסים הכל, החל מהתקנת חבילות ועד תצורת שירות, יצירת משתמשים ופריסת יישומים.

לדוגמה, בספר משחקים יחיד ניתן להתקין את Apache על שרתי Red Hat ו- IIS על מכונות Windowsהפעל את השירותים והפעל אותם בעת האתחול, תוך שימוש בתנאים המבוססים על משפחת מערכות ההפעלה. הביצוע כרוך בעיקרו בהפעלת Ansible playbook כנגד המלאי המשלב את שני סוגי השרתים.

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

מנהל מערכות AWS בסביבות לינוקס-חלונות היברידיות ורב-ענניות

אם חלק מהסביבה ההיברידית שלכם נמצאת על AWS, Systems Manager הוא חלק נוסף שכדאי לשקול. לתזמר זרימות עבודה בין צמתי Windows ו- Linux אשר אינם בהכרח מופעי EC2. המפתח הוא סוכן SSM, שניתן להתקין על מכונות לינוקס ו-Windows מחוץ ל-EC2 באמצעות תהליך הפעלה היברידי.

במהלך ההפעלה, א מזהה הפעלה וקוד המשויכים לחשבון AWS שלך, אשר משמשים לאחר מכן לרישום כל מכונה כצומת מנוהל. בלינוקס, הפקודה ssm-setup-cli מורידה ומתקינה את הסוכן, עוצרת אותו ורושמת את המופע; מכאן ואילך, הוא הופך לצומת מנוהל, עם מזהה שבדרך כלל מתחיל ב-"my-" כדי להבדיל אותו ממופעי EC2.

לאחר האינטגרציה, תוכלו לבצע פקודות מרחוק, לפרוס תיקונים, להחיל תצורות או אפילו להשתמש במנהל השינויים וביכולות אחרות (תוך קחו בחשבון שחלקן, כמו לוח המחוונים של CloudWatch עבור מנהל המערכות, הודיעו על תאריכי פרישה).

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

אם צריך לבטל רישום ולרשום מחדש צומת לינוקס, יש את הפעולה DeregisterManagedInstance ב-AWS CLI, ולאחר מכן מומלץ לנקות ערכים כגון זהותצריכתסדר ב- amazon-ssm-agent.json והפעילו את האפשרות -register -clear של הסוכן בהתאם לסוג ההתקנה.

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

יישומי Windows משולבים בשולחנות עבודה של לינוקס עם WinApps

לא הכל מסתכם בתהליכים אחוריים: זרימות עבודה היברידיות רבות של Windows-Linux משפיעות ישירות על חוויית המשתמש. WinApps הוא כלי קוד פתוח המאפשר... הפעלת יישומי Windows מקוריים משולחנות עבודה של GNU/Linux (KDE, GNOME, XFCE) כאילו היו יישומים מקומיים.

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

הדרך הפשוטה ביותר לפרוס את WinApps היא באמצעות סַוָרבאמצעות התמונה הזמינה לציבור, וניצול התוסף WorkflowUIPlugin ב-ComfyUI בעת שילוב אינטגרציה זו עם זרימות עבודה של יצירת תוכן או בינה מלאכותית, חברות מתמחות יכולות לסייע בהגדרת ארכיטקטורות שבהן שולחנות עבודה של לינוקס צורכים יישומי Windows המתארחים בענן (AWS, Azure) תוך שמירה על בקרות גישה מרכזיות, אבטחת סייבר וניטור.

עבודה היברידית, שיתוף פעולה ופיתוח מודרני ב-Microsoft 365 וב-Windows

זרימות עבודה היברידיות של Windows-Linux אינן קיימות בנפרד מאנשים; הן קשורות קשר הדוק ל... כיצד הצוות משתף פעולה, משתף מידע ומפתח יישומיםמיקרוסופט 365, ובפרט Teams, הפכו ל"שכבה הארגונית" עבור חברות רבות, עם מיליוני משתמשים שעובדים מרחוק ובמצב היברידי.

מיקרוסופט מתייחסת לרבים מהפתרונות הללו יישומי שיתוף פעולהאפליקציות שנותנות עדיפות לשיתוף פעולה סינכרוני ואסינכרוני עם פגישות, צ'אט, עריכה משותפת של מסמכים ואוטומציה של תהליכים עסקיים, הכל משולב בממשק יחיד. עבור מפתחים, זה פותח הזדמנות ליצור אפליקציות שעובדות באופן עקבי ב-Windows, macOS, אינטרנט, iOS, אנדרואיד ו-Linux.

Teams מציע ממשקי API ונקודות הרחבה עבור יישומי פגישות משופרים (שילוב פאזה משותפת, אירועי התחלה/סיום של פגישות, סצנות מותאמות אישית במצב ועידה, ממשקי API של מדיה עם הסכמה ספציפית למשאבים) ומשתלב עם Azure Communication Services כדי לאפשר למשתמשי Teams לקיים אינטראקציה עם לקוחות חיצוניים באמצעות יישומי קול, וידאו וצ'אט מותאמים אישית.

יתר על כן, שיתוף פעולה רב-פלטפורמתי מקודם עם רכיבי Fluid ב-Teams (טבלאות, רשימות ובלוקים הניתנים לעריכה בזמן אמת וגם משותפים עם Outlook ו-Office), ותוספי הודעות רב פעמיים ב-Outlook וב-Teams. Power Platform (Power Apps, Power Automate, Power Virtual Agents) משלימה את המערכת האקולוגית הזו עם בוטים וזרימות low-code שניתן לפרוס ב-Teams.

כדי להקל על המפתחים, מיקרוסופט מציעה ערכת כלים של Teams עבור Visual Studio ו-VS Codeעם אימות פשוט ושימוש ב-Graph, אינטגרציה עם Azure Functions ו-SPFx, ופורטל המפתחים של Teams שבו ניתן לרשום, להגדיר ולנהל יישומים בקונסולה מרכזית, כולל היבטים כגון תוכניות SaaS וניתוח שימוש.

נתונים, אבטחה ויכולת הרחבה עם Microsoft Graph ו-Windows מודרני

ברקע, רבות מחוויות שיתופיות אלו מבוססות על גרף של מיקרוסופטאשר חושפת נתוני תקשורת, תוכן ואנשים עם בקרות פרטיות ואבטחה המופעלות על ידי Azure AD. יכולות חדשות כגון הערכת גישה רציפה הם מאפשרים ביטול טוקנים מיידית יותר לנוכח אירועים קריטיים, ושיטות האימות וממשקי ה-API של זהויות חיצוניות מספקים שליטה רבה יותר על מי ניגש למה.

עבור אלו שצריכים להביא נתונים ל-Microsoft 365, ה- מחברי Microsoft Graph הם מאפשרים אינדוקס של מקורות חיצוניים כמו Jira או Confluence, העשרת פרופילי משתמשים והשתתפות בחוויות כמו Microsoft Search או eDiscovery. חיבור הנתונים של Microsoft Graph, בינתיים, מאפשר ייצוא של מערכי נתוני פרודוקטיביות ל-Azure לצורך ניתוח מתקדם או אימון מודלים של בינה מלאכותית.

בתחום יישומי שולחן העבודה, פרויקט ריוניון (כיום חלק מהאסטרטגיה של מודרניזציה של אפליקציות Windowsעם WinUI 3 ו-WebView 2, תמיכה ב-.NET 5 ו-Windows 10 משנת 1809, זה עוזר לאפליקציות חדשות וקיימות לנצל טוב יותר את מכשירי Windows, תוך שילוב עם שירותי ענן.

כלים כמו מסוף Windows (ניתן להגדרה כטרמינל ברירת מחדל, עם מצבים כמו Quake) ותת-המערכת של Windows עבור לינוקס עם תמיכה ביישומי GUI הופכים את הפיתוח והניהול של סביבות היברידיות מ-Windows לנוחים הרבה יותר, על ידי שילוב של ממשק שורת פקודה קלאסית, קליפות לינוקס וכלים גרפיים באותה זרימת עבודה.

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

מצד שני, Power Automate Desktop ויכולות כגון יועץ לתהליכים הם מציגים RPA ​​ללא קוד ב-Windows 10, המאפשר זיהוי צווארי בקבוק ומשימות חוזרות ונשנות שניתן להפוך אותן לאוטומטיות בקלות, לעתים קרובות בשילוב עם מערכות back-end של לינוקס או שירותי ענן.

על ידי שילוב כל החלקים הללו - Azure Automation, Logic Apps, Ansible, AWS Systems Manager, WinApps, Teams, Graph והשיפורים ב-Windows וב-WSL - ניתן לבנות זרימות עבודה היברידיות חזקות באמת של Windows-Linux, שבהן אוטומציה, אינטגרציה, אבטחה ושיתוף פעולה הם מתאמים כדי שאנשים יוכלו להתמקד בהוספת ערך ולא בהתמודדות עם כלים מנותקים או תהליכים ידניים שבירים. שתפו את המידע כדי שיותר אנשים יוכלו ללמוד על הנושא.