לאחרונה התקיים הכנס השנתי של מיקרוסופט, Microsoft Ignite, שכלל הכרזות על המון שירותים חדשים, חידושים בשירותים קיימים ועוד.
במאמר זה אדבר אתכם על פתרון חדש בשם Azure Front Door, שנכון לכתיבת המאמר נמצא ב-Preview. תחילה, נסביר מהו הפתרון, מתי כדאי להשתמש בשירות ואיך ניתן להקים בעזרת מספר פעולות.
Azure Front Door הוא פתרון שעובד בשכבה 7 (אפליקציה HTTP/HTTPS).
השירות משתמש בפרוטוקול anycast עם Split TCP והרשת העולמית של Microsoft כדי לשפר ולהבטיח קישוריות.
בעזרת השירות ניתן לבחור את שיטת הניתוב לדוגמה: ניתוב בקשות הלקוח ל-Backend המהיר ביותר (והזמין).
השירותים החשופים דרך AFD Backend יכולים להיות כל אפליקציה עם Internet-facing שנמצאים בתוך ו/או מחוץ ל-Azure.
Azure Front Door יודעת להתמודד עם כשלים גם במידה ויש כשל ל-Azure Region שלם בדומה ל-Azure Traffic Manager.
פתרון Azure Front Door מאפשר להגדיר, לנהל ולפקח על התעבורה לאפליקציות שלנו בצורה גלובלית ע”י אופטימיזציה ובדיקות “בריאות” כדי להבטיח זמינות גבוהה.
Azure Front Door מזכיר מאוד ביכולות שלו את פתרון Azure Traffic Manager כפתרון שמבטיח זמינות גבוהה עם ניתוב תעבורה המהיר ביותר בהתאם ללקוח ויכולת להתמודד עם כשל של Azure Region שלם, אך יש ביניהם מספר הבדלים מהותיים:
פתרון Azure Front Door הוא פתרון בשכבה 7 שנותן מספר יכולות כמו עבודה עם TLS, URL Routing, Session Affinity ועוד, בשונה מ-Azure Traffic Manager שמבוסס על ניתוב בעזרת DNS בלבד.
• URL-Based Routing – מאפשר לנתב את התעבורה ל-Backend ע”י ניתוב לפי כתובת הבקשה (ניתוב בקשה ל-App הנכון בהתאם ל”סוג הבקשה”.
• Session Affinity – פתרון מבוסס Cookie המאפשר להעביר את התעבורה לאותו יישום שהתחיל עם הבקשה (ניתוב זה חשוב במידה וה-Session state נשמר באפליקציה).
• Secure Sockets Layer (SSL) termination, Smart Health Probes, Custom domain and Certificate Management, Support IPv6 and HTTP/2 ועוד.
1. הקמת Azure Front Door.
2. יצירת Backend Pool וביצוע הגדרות.
3. הגדרת ניתובים
4. ביצוע בדיקות
נכנסים לפורטל Azure, לוחצים על New ומחפשים Front Door
בוחרים Resource Group וה- Region הרצוי ועוברים לשלב ההגדרות
בשלב הראשון מגדירים שם לשירות (ה-Front Name) – שם חוקי בעולם עם סיומת azurefd.net, מחליטים אם רוצים להפעיל Session Affinity (ברירת מחדל מבוטל, ניתן לשנות בהמשך).
בשלב השני מגדירים את ה-Backend Pool שאליו ה-Front Door יעביר את הבקשות.
ב- BackendPool מגדירים איזה אפליקציות אנו חושפים דרך ה-Front Door. בדוגמה הנ”ל בחרנו 2 שירותי App Service שנמצאים באתרים שונים (West Europe ו-East US).
בנוסף מגדירים את תצורת ה-Smart Health מבחינת תדירות ביצוע בד
בנוסף מגדירים את תצורת ה-Smart Health מבחינת תדירות ביצוע בד
בשלב שלישי מגדירים את הניתוב לאיזה URL לגשת בהתאם לבקשה, לאיזה Backend Pool לגשת (במידה ויש יותר מאחד) ועוד.
מנגון ה-Routing Rule מורכב מ-2 חלקים עיקריים – “צד שמאל” ו”צד ימין”
“צד שמאל” – אנו מתאימים את הניתוב בהתאם לבקשה שנכנסת ל-Front Door ואילו ב“צד ימין” אנו מגדירים כיצד אנו מעבדים את הבקשה
בדוגמה הנ”ל הגדרנו שניתן לקבל כל בקשה ב-HTTP/HTTPS ולהעביר את
הבקשה ל-Backend רק ב-HTTPS (הגדרה שבוצעה בטאב של ה-Advanced).
בנוסף, ניתן להגדיר ניתובים על בסיס תבניות כמו /images/*, /users/ ועוד.
לאחר שסיימנו את ההגדרות אנו אמורים להגיע למצב הזה שיש לפחות חוק אחד בכל “קוביה”.
נמשיך ב-Wizard ונלחץ על Create.
כעת כל מה שנשאר זה להתחבר ל-URL שהגדרנו ב-Frontend Door ולראות מה קיבלנו
ניתן לראות בתמונה מספר דברים מעניינים:
1. שאני גולש דרך דפדפן רגיל אני מגיע לאתר ב-West Europe (מבחינת המיקום שלי זה האתר שהכי קרוב אלי) ובמידה ואני גולש דרך פרוקסי בארה”ב אני מגיע לאתר שהוקם ב-East US
2. שלחתי את הבקשה ב-HTTP רגיל אבל כתוצאה מהחוק שהגדרתי כל הבקשות ל-Backend עברו דרך HTTPS בלבד.
הערה: ניתן לשנות ו/או להוסיף Routing Rules, Backend Pools, Custom Domain לאחר ההקמה דרך Front Door Designer.
פתרון Azure Front Door מביא עימו בשורה חדשה של ניהול גלובלי של שירותים/אפליקציות ומאפשר לנו לנהל ולפקח על התעבורה לאפליקציות בצורה גלובלית ע”י אופטימיזציה לבקשות, ניתוב בקשות בהתאם לתבנית, פיזור האפליקציה במספר מקומות ובכך למנוע כשל של האפליקציה ו/או Azure Region ועוד.
ראינו במאמר כמה פשוט להקים את השירות ולבצע הגדרות בסיסיות על מנת להבטיח זמינות גבוהה לאתר.
לאחרונה התקיים הכנס השנתי של מיקרוסופט, Microsoft Ignite, שכלל הכרזות על המון שירותים חדשים, חידושים בשירותים קיימים ועוד.
במאמר זה אדבר אתכם על פתרון חדש בשם Azure Front Door, שנכון לכתיבת המאמר נמצא ב-Preview. תחילה, נסביר מהו הפתרון, מתי כדאי להשתמש בשירות ואיך ניתן להקים בעזרת מספר פעולות.
Azure Front Door הוא פתרון שעובד בשכבה 7 (אפליקציה HTTP/HTTPS).
השירות משתמש בפרוטוקול anycast עם Split TCP והרשת העולמית של Microsoft כדי לשפר ולהבטיח קישוריות.
בעזרת השירות ניתן לבחור את שיטת הניתוב לדוגמה: ניתוב בקשות הלקוח ל-Backend המהיר ביותר (והזמין).
השירותים החשופים דרך AFD Backend יכולים להיות כל אפליקציה עם Internet-facing שנמצאים בתוך ו/או מחוץ ל-Azure.
Azure Front Door יודעת להתמודד עם כשלים גם במידה ויש כשל ל-Azure Region שלם בדומה ל-Azure Traffic Manager.
פתרון Azure Front Door מאפשר להגדיר, לנהל ולפקח על התעבורה לאפליקציות שלנו בצורה גלובלית ע”י אופטימיזציה ובדיקות “בריאות” כדי להבטיח זמינות גבוהה.
Azure Front Door מזכיר מאוד ביכולות שלו את פתרון Azure Traffic Manager כפתרון שמבטיח זמינות גבוהה עם ניתוב תעבורה המהיר ביותר בהתאם ללקוח ויכולת להתמודד עם כשל של Azure Region שלם, אך יש ביניהם מספר הבדלים מהותיים:
פתרון Azure Front Door הוא פתרון בשכבה 7 שנותן מספר יכולות כמו עבודה עם TLS, URL Routing, Session Affinity ועוד, בשונה מ-Azure Traffic Manager שמבוסס על ניתוב בעזרת DNS בלבד.
• URL-Based Routing – מאפשר לנתב את התעבורה ל-Backend ע”י ניתוב לפי כתובת הבקשה (ניתוב בקשה ל-App הנכון בהתאם ל”סוג הבקשה”.
• Session Affinity – פתרון מבוסס Cookie המאפשר להעביר את התעבורה לאותו יישום שהתחיל עם הבקשה (ניתוב זה חשוב במידה וה-Session state נשמר באפליקציה).
• Secure Sockets Layer (SSL) termination, Smart Health Probes, Custom domain and Certificate Management, Support IPv6 and HTTP/2 ועוד.
1. הקמת Azure Front Door.
2. יצירת Backend Pool וביצוע הגדרות.
3. הגדרת ניתובים
4. ביצוע בדיקות
נכנסים לפורטל Azure, לוחצים על New ומחפשים Front Door
בוחרים Resource Group וה- Region הרצוי ועוברים לשלב ההגדרות
בשלב הראשון מגדירים שם לשירות (ה-Front Name) – שם חוקי בעולם עם סיומת azurefd.net, מחליטים אם רוצים להפעיל Session Affinity (ברירת מחדל מבוטל, ניתן לשנות בהמשך).
בשלב השני מגדירים את ה-Backend Pool שאליו ה-Front Door יעביר את הבקשות.
ב- BackendPool מגדירים איזה אפליקציות אנו חושפים דרך ה-Front Door. בדוגמה הנ”ל בחרנו 2 שירותי App Service שנמצאים באתרים שונים (West Europe ו-East US).
בנוסף מגדירים את תצורת ה-Smart Health מבחינת תדירות ביצוע בד
בנוסף מגדירים את תצורת ה-Smart Health מבחינת תדירות ביצוע בד
בשלב שלישי מגדירים את הניתוב לאיזה URL לגשת בהתאם לבקשה, לאיזה Backend Pool לגשת (במידה ויש יותר מאחד) ועוד.
מנגון ה-Routing Rule מורכב מ-2 חלקים עיקריים – “צד שמאל” ו”צד ימין”
“צד שמאל” – אנו מתאימים את הניתוב בהתאם לבקשה שנכנסת ל-Front Door ואילו ב“צד ימין” אנו מגדירים כיצד אנו מעבדים את הבקשה
בדוגמה הנ”ל הגדרנו שניתן לקבל כל בקשה ב-HTTP/HTTPS ולהעביר את
הבקשה ל-Backend רק ב-HTTPS (הגדרה שבוצעה בטאב של ה-Advanced).
בנוסף, ניתן להגדיר ניתובים על בסיס תבניות כמו /images/*, /users/ ועוד.
לאחר שסיימנו את ההגדרות אנו אמורים להגיע למצב הזה שיש לפחות חוק אחד בכל “קוביה”.
נמשיך ב-Wizard ונלחץ על Create.
כעת כל מה שנשאר זה להתחבר ל-URL שהגדרנו ב-Frontend Door ולראות מה קיבלנו
ניתן לראות בתמונה מספר דברים מעניינים:
1. שאני גולש דרך דפדפן רגיל אני מגיע לאתר ב-West Europe (מבחינת המיקום שלי זה האתר שהכי קרוב אלי) ובמידה ואני גולש דרך פרוקסי בארה”ב אני מגיע לאתר שהוקם ב-East US
2. שלחתי את הבקשה ב-HTTP רגיל אבל כתוצאה מהחוק שהגדרתי כל הבקשות ל-Backend עברו דרך HTTPS בלבד.
הערה: ניתן לשנות ו/או להוסיף Routing Rules, Backend Pools, Custom Domain לאחר ההקמה דרך Front Door Designer.
פתרון Azure Front Door מביא עימו בשורה חדשה של ניהול גלובלי של שירותים/אפליקציות ומאפשר לנו לנהל ולפקח על התעבורה לאפליקציות בצורה גלובלית ע”י אופטימיזציה לבקשות, ניתוב בקשות בהתאם לתבנית, פיזור האפליקציה במספר מקומות ובכך למנוע כשל של האפליקציה ו/או Azure Region ועוד.
ראינו במאמר כמה פשוט להקים את השירות ולבצע הגדרות בסיסיות על מנת להבטיח זמינות גבוהה לאתר.
הודעתך לא התקבלה - נסה שוב מאוחר יותר
Oops! Something went wrong while submitting the form