התבנית משוכפלת מבוססת על שכפול העיצוב של סביבה קיימת מסוימת או של סביבות קיימות לסביבה חדשה או לסביבות חדשות. לכן, התבנית הזו רלוונטית בעיקר לארכיטקטורות שמבוססות על תבנית של סביבה היברידית. במקרה כזה, אתם מריצים את עומסי העבודה של הפיתוח והבדיקות בסביבה אחת, ואת עומסי העבודה של ההכנה והייצור בסביבה אחרת.
התבנית המשוכפלת מניחה שעומסי העבודה של הבדיקות והייצור לא אמורים לתקשר ישירות זה עם זה. עם זאת, צריכה להיות אפשרות לנהל ולפרוס את שתי קבוצות עומסי העבודה באופן עקבי.
אם משתמשים בתבנית הזו, צריך לחבר את שני סביבות המחשוב באופן שעומד בדרישות הבאות:
- אינטגרציה רציפה/פריסה רציפה (CI/CD) יכולה לפרוס ולנהל עומסי עבודה בכל סביבות המחשוב או בסביבות ספציפיות.
- מערכות ניהול תצורה, מערכות מעקב ומערכות ניהול אחרות צריכות לפעול בסביבות מחשוב שונות.
- עומסי עבודה לא יכולים לתקשר ישירות בין סביבות מחשוב. אם יש צורך בכך, התקשורת צריכה להיות מדויקת ומבוקרת.
ארכיטקטורה
תרשים הארכיטקטורה הבא מציג ארכיטקטורת הפניה ברמה גבוהה של התבנית הזו, שתומכת ב-CI/CD, בניטור, בניהול הגדרות, במערכות ניהול אחרות ובקשר בין עומסי עבודה:
התיאור של הארכיטקטורה בתרשים שלמעלה:
- עומסי העבודה מופצים על סמך הסביבות הפונקציונליות (פיתוח, בדיקה, CI/CD וכלים אדמיניסטרטיביים) ברשתות VPC נפרדות בצד Google Cloud .
- VPC משותף משמש לפיתוח ולעומסי עבודה של בדיקות. עוד VPC משמש ל-CI/CD ולכלים אדמיניסטרטיביים. עם VPC משותפים:
- האפליקציות מנוהלות על ידי צוותים שונים בכל סביבה ובכל פרויקט שירות.
- פרויקט המארח מנהל ושולט בתקשורת ברשת ובאמצעי הבקרה לאבטחה בין סביבות הפיתוח והבדיקה, וגם מחוץ ל-VPC.
- רשת ה-VPC של CI/CD מחוברת לרשת שבה מופעלים עומסי העבודה של הייצור בסביבת המחשוב הפרטית שלכם.
- כללי חומת האש מאפשרים רק תעבורה מורשית.
- אפשר גם להשתמש ב-Cloud Next Generation Firewall Enterprise עם שירות למניעת חדירות (IPS) כדי להטמיע בדיקה מעמיקה של מנות נתונים למניעת איומים בלי לשנות את העיצוב או הניתוב. Cloud Next Generation Firewall Enterprise פועל על ידי יצירת נקודות קצה של חומת אש אזורית שמנוהלות על ידי Google. נקודות הקצה האלה משתמשות בטכנולוגיית יירוט חבילות כדי לבדוק באופן שקוף את עומסי העבודה ולחפש חתימות של איומים שהוגדרו. הוא גם מגן על עומסי עבודה מפני איומים.
- מאפשר תקשורת בין רשתות ה-VPC המקושרות באמצעות כתובות IP פנימיות.
- ה-peering בתבנית הזו מאפשר למערכות CI/CD ולמערכות אדמיניסטרטיביות לפרוס ולנהל עומסי עבודה של פיתוח ובדיקות.
- כדאי להקפיד על השיטות המומלצות הכלליות הבאות.
כדי ליצור את החיבור הזה של CI/CD, צריך להשתמש באחת מאפשרויות הקישוריות ההיברידיות והמולטי-ענניות שמתאימות לדרישות העסקיות והאפליקטיביות שלכם. כדי לאפשר לכם לפרוס ולנהל עומסי עבודה של ייצור, החיבור הזה מספק נגישות לרשת פרטית בין סביבות המחשוב השונות. בכל הסביבות צריך להיות מרחב כתובות IP של RFC 1918 ללא חפיפה.
אם המופעים בסביבות הפיתוח והבדיקה דורשים גישה לאינטרנט, אפשר לנסות את האפשרויות הבאות:
- אפשר לפרוס את Cloud NAT באותה רשת של פרויקט מארח של VPC משותף. פריסה באותה רשת של פרויקט מארח של VPC משותף עוזרת למנוע גישה ישירה למופעים האלה מהאינטרנט.
- לתנועה יוצאת באינטרנט, אפשר להשתמש בשרת Proxy מאובטח באינטרנט. לשרת ה-Proxy יש כמה יתרונות.
מידע נוסף על Google Cloud הכלים והיכולות שעוזרים לכם ליצור, לבדוק ולפרוס בסביבות Google Cloud היברידיות ורב-ענניות, אפשר לקרוא בבלוג DevOps and CI/CD on Google Cloud explained.
וריאציות
כדי לעמוד בדרישות עיצוב שונות, תוך התחשבות בכל דרישות התקשורת, דפוס הארכיטקטורה המשוכפל מציע את האפשרויות הבאות, שמתוארות בקטעים הבאים:
- VPC משותף לכל סביבה
- חומת אש מרכזית בשכבת האפליקציה
- טופולוגיית Hub-and-spoke
- ארכיטקטורה מבוזרת של מיקרו-שירותים עם מודל אבטחה של אפס אמון
VPC משותף לכל סביבה
האפשרות לעיצוב VPC משותף לכל סביבה מאפשרת הפרדה ברמת האפליקציה או השירות בין סביבות שונות, כולל CI/CD וכלי ניהול שאולי נדרשים כדי לעמוד בדרישות אבטחה ארגוניות מסוימות. הדרישות האלה מגבילות את התקשורת, את תחום הניהול ואת בקרת הגישה לשירותים שונים שגם צריכים להיות מנוהלים על ידי צוותים שונים.
העיצוב הזה מאפשר הפרדה באמצעות בידוד ברמת הרשת והפרויקט בין הסביבות השונות, וכך מאפשר תקשורת פרטנית יותר ובקרת גישה באמצעות ניהול זהויות והרשאות גישה (IAM).
מבחינת ניהול ותפעול, העיצוב הזה מספק גמישות בניהול האפליקציות ועומסי העבודה שנוצרו על ידי צוותים שונים לכל סביבה ולכל פרויקט שירות. צוותי תפעול רשת יכולים להקצות ולנהל את רשת ה-VPC ואת תכונות האבטחה שלה על סמך המבנים האפשריים הבאים:
- צוות אחד מנהל את כל הפרויקטים המארחים בכל הסביבות.
- צוותים שונים מנהלים את פרויקטי המארח בסביבות שלהם.
ההחלטות לגבי ניהול פרויקטים מארחים צריכות להתבסס על מבנה הצוות, פעולות האבטחה ודרישות הגישה של כל צוות. אפשר להחיל את וריאציית העיצוב הזו על רשת ה-VPC המשותפת לכל אחת מהאפשרויות לעיצוב אזור נחיתה של סביבה. עם זאת, צריך לקחת בחשבון את דרישות התקשורת של תבנית השיקוף כדי להגדיר איזו תקשורת מותרת בין הסביבות השונות, כולל תקשורת ברשת ההיברידית.
אפשר גם להקצות רשת VPC משותפת לכל סביבה ראשית, כמו שמוצג בתרשים הבא:
חומת אש מרכזית בשכבת האפליקציות
בתרחישים מסוימים, דרישות האבטחה עשויות לחייב שימוש במנגנונים של חומת אש מתקדמת שחורגים מהיכולות של Cloud Next Generation Firewall, וגם בבדיקת מנות עמוקה בשכבת האפליקציה (שכבה 7). כדי לעמוד בדרישות ובסטנדרטים של הארגון בנושא אבטחה, אפשר להשתמש במכשיר NGFW שמתארח במכשיר וירטואלי ברשת (NVA). יש כמה Google Cloud שותפים בתחום האבטחה שמציעים אפשרויות שמתאימות למשימה הזו.
כפי שמודגם בתרשים הבא, אפשר למקם את ה-NVA בנתיב הרשת בין הענן הווירטואלי הפרטי לבין סביבת המחשוב הפרטית באמצעות ממשקי רשת מרובים.
אפשר להשתמש בעיצוב הזה גם עם כמה רשתות VPC משותפות, כמו שמוצג בתרשים הבא.
ה-NVA בתכנון הזה פועל כשכבת אבטחה היקפית. הוא גם משמש כבסיס להפעלת בדיקה של תעבורת נתונים מוטבעת ולאכיפה של מדיניות בקרת גישה מחמירה.
כדי ליצור אסטרטגיית אבטחה רב-שכבתית חזקה שכוללת כללי חומת אש של VPC ויכולות של שירות למניעת פריצות, צריך לכלול בדיקה נוספת של התעבורה ואמצעי בקרה על האבטחה של זרימות התעבורה מכל הכיוונים.
טופולוגיית Hub-and-spoke
אפשרות נוספת היא להשתמש ב-VPC נפרדים (כולל VPC משותפים) עבור הפיתוח ושלבי הבדיקה השונים. בשיטה הזו, כמו שמוצג בתרשים הבא, כל סביבות הבמה מתחברות ל-VPC של CI/CD ול-VPC של הניהול בארכיטקטורת רכזת-חישורים. השתמשו באפשרות הזו אם אתם צריכים להפריד בין הדומיינים האדמיניסטרטיביים לבין הפונקציות בכל סביבה. מודל התקשורת 'מרכז וחישורים' יכול לעזור בדרישות הבאות:
- אפליקציות צריכות לגשת לקבוצה משותפת של שירותים, כמו ניטור, כלים לניהול הגדרות, CI/CD או אימות.
- צריך להחיל קבוצה משותפת של מדיניות אבטחה על תנועה נכנסת ויוצאת באופן מרכזי דרך הרכזת.
מידע נוסף על אפשרויות עיצוב של רשתות מסוג Hub-and-spoke זמין במאמרים טופולוגיית Hub-and-spoke עם מכשירים מרכזיים וטופולוגיית Hub-and-spoke ללא מכשירים מרכזיים.
כפי שמוצג בתרשים הקודם, התקשורת בין רשתות ה-VPC והקישוריות ההיברידית עוברות דרך רשת ה-VPC המרכזית. כחלק מהדפוס הזה, אתם יכולים לשלוט בתקשורת ב-VPC של הרכזת ולהגביל אותה בהתאם לדרישות הקישוריות שלכם.
כחלק מארכיטקטורת רשת מסוג Hub-and-Spoke, אלה אפשרויות הקישוריות העיקריות (בין ה-VPC של ה-Spokes לבין ה-VPC של ה-Hub) ב- Google Cloud:
- קישור בין רשתות VPC שכנות (peering)
- VPN
- שימוש במכשיר וירטואלי לרשת (NVA)
- עם כמה ממשקי רשת
- עם Network Connectivity Center (NCC)
מידע נוסף על האפשרות שכדאי לשקול בתכנון זמין במאמר ארכיטקטורת רשת מסוג Hub-and-spoke. גורם משפיע מרכזי בבחירה בין VPN לבין שיוך VPC בין הרשתות המשניות לבין ה-VPC המרכזי הוא הצורך במעבר תנועה. תנועה טרנזיטיבית פירושה שתנועה מ-spoke יכולה להגיע ל-spokes אחרים דרך ה-hub.
ארכיטקטורה מבוזרת עם מודל אבטחה של אפס אמון למיקרו-שירותים
ארכיטקטורות היברידיות וארכיטקטורות מרובות עננים עשויות לדרוש אשכולות מרובים כדי להשיג את היעדים הטכניים והעסקיים שלהן, כולל הפרדה בין סביבת הייצור לבין סביבות הפיתוח והבדיקה. לכן, אמצעי בקרה לאבטחת היקף הרשת חשובים, במיוחד אם הם נדרשים כדי לעמוד בדרישות אבטחה מסוימות.
לא מספיק לתמוך בדרישות האבטחה של ארכיטקטורות מבוזרות של מיקרו-שירותים שמתבססות על עדיפות לענן. כדאי גם לשקול ארכיטקטורות מבוזרות של מודל אבטחה של אפס אמון. ארכיטקטורת מודל אבטחה של אפס אמון מבוזרת של מיקרו-שירותים תומכת בארכיטקטורת המיקרו-שירותים שלכם באמצעות אכיפה של מדיניות אבטחה ברמת המיקרו-שירות, אימות ו-Workload Identity. האמון מבוסס על זהות ונאכף עבור כל שירות.
באמצעות ארכיטקטורת proxy מבוזרת, כמו service mesh, השירותים יכולים לאמת ביעילות את המתקשרים וליישם מדיניות של בקרת גישה מפורטת לכל בקשה, וכך ליצור סביבת מיקרו-שירותים מאובטחת וניתנת להרחבה. Cloud Service Mesh מאפשר לכם ליצור תשתית משותפת שמתאימה לפריסות שלכם ב-Google Cloud ובסביבה המקומית. ה-mesh משתמש במדיניות הרשאה כדי לאבטח את התקשורת בין השירותים.
אפשר גם לשלב בארכיטקטורה הזו את Apigee Adapter ל-Envoy, שהוא פריסה קלה של שער Apigee API בתוך אשכול Kubernetes. Apigee Adapter ל-Envoy הוא פרוקסי קצה ושירות קוד פתוח שמיועד לאפליקציות עם עדיפות לענן.
מידע נוסף בנושא הזה זמין במאמרים הבאים:
- ארכיטקטורה מבוזרת של אפס אמון
- סביבה היברידית של Google Kubernetes Engine (GKE)
- התחברות אל Google
- מחברים אשכול מקומי לGoogle Cloud רשת.
- הגדרה של רשת היברידית או רשת מרובת עננים
- פריסת Cloud Service Mesh בסביבות ובאשכולות שונים.
שיטות מומלצות לשימוש בדפוסים משוכפלים
- מערכות ה-CI/CD שנדרשות לפריסה או להגדרה מחדש של פריסות בייצור צריכות להיות זמינות מאוד, כלומר כל רכיבי הארכיטקטורה צריכים להיות מתוכננים כך שיספקו את רמת הזמינות הצפויה של המערכת. מידע נוסף זמין במאמר בנושא Google Cloud מהימנות התשתית.
- כדי למנוע שגיאות בהגדרות של תהליכים חוזרים כמו עדכוני קוד, חשוב להשתמש באוטומציה כדי ליצור סטנדרטיזציה של גרסאות ה-build, הבדיקות והפריסות.
- שילוב של מכשירי NVA מרכזיים בתכנון הזה עשוי לדרוש שילוב של כמה פלחים עם רמות שונות של בקרות גישה לאבטחה.
- כשמתכננים פתרון שכולל מכשירי NVA, חשוב לקחת בחשבון את הזמינות הגבוהה (HA) של מכשירי ה-NVA כדי להימנע מנקודת כשל יחידה שעלולה לחסום את כל התקשורת. פועלים לפי ההנחיות לתכנון ולהטמעה של זמינות גבוהה ויתירות שסופקו על ידי ספק ה-NVA.
- אם לא מייצאים נתיבי IP מקומיים דרך VPC Peering או VPN אל ה-VPC של הפיתוח והבדיקות, אפשר להגביל את יכולת ההגעה לרשת מסביבות הפיתוח והבדיקות אל הסביבה המקומית. מידע נוסף זמין במאמר בנושא החלפת מסלולים מותאמת אישית ב-VPC Network Peering.
- עבור עומסי עבודה עם כתובות IP פרטיות שעשויים לדרוש גישה לממשקי Google APIs, אפשר לחשוף את ממשקי Google APIs באמצעות נקודת קצה של Private Service Connect ברשת VPC. מידע נוסף זמין במאמר בנושא גישה מוגבלת בסדרה הזו.
- כדאי לעיין בשיטות המומלצות הכלליות לדפוסי ארכיטקטורה של רשתות היברידיות ורשתות מרובות עננים.