הבנת Arc Azure

אחת ההכרזות המעניינות יותר בכנס Ignite של מיקרוסופט 2019 הייתה Azure Arc, כלי ניהול חדש לתשתיות יישומי ענן היברידיות. על בסיס מושגים של Azure, Arc נועד לאפשר לך לנהל משאבים מקומיים מפורטל Azure, תוך פריסת מדיניות ושירותים למכונות וירטואליות ו- Kubernetes. הוא כולל גם גרסאות מכולות של מסד הנתונים SQL של ​​Azure ושל Hyperscale של PostgreSQL כדי לתת ליישומים היברידיים מבוססי Kubernetes אפשרויות נתונים עקביות תכלת.

Azure Arc מרחיבה את מודל Azure Resource Manager עד לשרתים ואשכולות Kubernetes. זה נועד לנהל משאבים באופן ענני באשר הם, ולהתייחס לכלי המשאבים של Azure כאל מישור הבקרה שלך. זה מציב אותה ברמה הרבה יותר גבוהה מרוב כלי הניהול. לדוגמה, אם אתה משתמש בו במכונות וירטואליות הפועלות ברשת Windows Server, היית מנהל את מחשבי ה- VM באמצעות כלי ניהול Hyper-V ואת תצורת השרת ויישומים הפועלים עליהם באמצעות Azure Arc.

שימוש ב- Azure Arc עם שרתים

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

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

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

ניהול יישומי Kubernetes ב- Arc Arc

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

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

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

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

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

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

היכרות עם מודל ניהול חדש וממוקד בענן

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

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

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

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

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