התחברות לאשכול מחוץ ל-VPC שלו

כדי להתחבר לאשכול AlloyDB ל-PostgreSQL מאפליקציות שפועלות מחוץ לרשת ה-VPC שהוגדרה לו (למשל, סביבות מקומיות, ספקי שירותי ענן אחרים או רשתות VPC נפרדות), אתם יכולים לנתב את התעבורה דרך מכונה וירטואלית (VM) מתווכת, Cloud VPN או Cloud Interconnect. לפני שמתחילים, ודאו שיצרתם אשכול AlloyDB.

מידע על חיבורים חיצוניים

אשכול AlloyDB מורכב מכמה צמתים בתוך רשתGoogle Cloud VPC. כשיוצרים אשכול, אפשר להגדיר גישה לשירותים פרטיים בין אחת מרשתות ה-VPC שלכם לבין רשת ה-VPC שמנוהלת על ידי Google ומכילה את האשכול החדש. החיבור הזה מאפשר לכם להשתמש בכתובות IP פרטיות כדי לגשת למשאבים ברשת ה-VPC של האשכול, כאילו הם חלק מרשת ה-VPC שלכם.

יש מצבים שבהם האפליקציה צריכה להתחבר לאשכול מחוץ לרשת ה-VPC המחוברת:

  • האפליקציה פועלת במקום אחר בסביבה של Google Cloud , מחוץ לרשת ה-VPC שמחוברת לאשכול באמצעות גישה לשירותים פרטיים.

  • האפליקציה פועלת ברשת VPC שנמצאת מחוץ לרשת של Google.

  • האפליקציה פועלת באופן מקומי, במכונה שנמצאת במקום אחר באינטרנט הציבורי.

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

סיכום של פתרונות לחיבור חיצוני

אנחנו ממליצים על שני פתרונות כלליים ליצירת חיבורים חיצוניים, בהתאם לצרכים שלכם:

  • לפיתוח פרויקטים או ליצירת אב טיפוס, או לסביבת ייצור בעלות נמוכה יחסית, הגדירו מכונה וירטואלית (VM) מתווכת – שנקראת גם bastion – בתוך ה-VPC. יש כמה שיטות להשתמש במכונה הווירטואלית המתווכת הזו כחיבור מאובטח בין סביבת אפליקציה חיצונית לבין אשכול AlloyDB.

  • בסביבות ייצור שדורשות זמינות גבוהה, כדאי ליצור חיבור קבוע בין ה-VPC לאפליקציה באמצעות Cloud VPN או Cloud Interconnect.

בקטעים הבאים נתאר בפירוט את הפתרונות האלה לחיבורים חיצוניים.

התחברות באמצעות VM מתווך

כדי ליצור חיבור לאשכול AlloyDB מחוץ ל-VPC שלו באמצעות כלים בקוד פתוח ומינימום משאבים נוספים, מריצים שירות proxy ב-VM מתווך שמוגדר בתוך ה-VPC. אתם יכולים להגדיר מכונה וירטואלית חדשה למטרה הזו, או להשתמש במכונה וירטואלית שכבר פועלת ב-VPC של אשכול AlloyDB.

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

התחברות באמצעות IAP

באמצעות שרת proxy לאימות זהויות (IAP), אתם יכולים להתחבר לאשכול באופן מאובטח בלי לחשוף את כתובת ה-IP הציבורית של המכונה הווירטואלית המתווכת. כדי להגביל את הגישה דרך הנתיב הזה, משתמשים בשילוב של כללי חומת אש וניהול זהויות והרשאות גישה (IAM). לכן, IAP הוא פתרון טוב לשימושים שאינם בסביבת הייצור, כמו פיתוח ויצירת אב טיפוס.

כדי להגדיר גישה של IAP לאשכול:

  1. מתקינים את Google Cloud CLI בלקוח החיצוני.

  2. הכנת הפרויקט להעברת TCP של IAP.

    כשמגדירים את הכלל החדש של חומת האש, מאפשרים תעבורת נתונים נכנסת מסוג TCP ליציאה 22 (SSH). אם אתם משתמשים ברשת ברירת המחדל של הפרויקט, והכלל default-allow-ssh שאוכלס מראש מופעל, אתם לא צריכים להגדיר כלל נוסף.

  3. מגדירים העברה ליציאה אחרת בין הלקוח החיצוני לבין המכונה הווירטואלית המתווכת באמצעות SSH דרך IAP.

    gcloud compute ssh my-vm \
       --tunnel-through-iap \
       --zone=ZONE_ID \
       --ssh-flag="-L PORT_NUMBER:ALLOYDB_IP_ADDRESS:5432"

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫ZONE_ID: מזהה האזור שבו נמצא האשכול, לדוגמה us-central1-a.
    • ‫ALLOYDB_IP_ADDRESS: כתובת ה-IP של מכונת AlloyDB שאליה רוצים להתחבר.
    • ‫PORT_NUMBER: מספר היציאה של ה-VM.

  4. בודקים את החיבור באמצעות psql בלקוח החיצוני, ומחברים אותו ליציאה המקומית שציינתם בשלב הקודם. לדוגמה, כדי להתחבר בתפקיד המשתמש postgres ליציאה 5432:

    psql -h localhost -p 5432 -U USERNAME

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫USERNAME: משתמש PostgreSQL שרוצים לחבר למכונה, למשל משתמש ברירת המחדל postgres.

התחברות דרך שרת proxy מסוג SOCKS

הפעלת שירות SOCKS ב-VM המתווך מספקת חיבור גמיש וניתן להתאמה לאשכול AlloyDB, עם הצפנה מקצה לקצה שסופקה על ידי AlloyDB Auth Proxy. אם מגדירים אותו כמו שצריך, אפשר להשתמש בו לעומסי עבודה בסביבת הייצור.

הפתרון הזה כולל את השלבים הבאים:

  1. מתקינים, מגדירים ומריצים שרת SOCKS במכונה הווירטואלית המתווכת. דוגמה אחת היא Dante, פתרון פופולרי בקוד פתוח.

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

  2. מגדירים את כללי חומת האש של VPC כדי לאפשר תעבורת נתונים ב-TCP מכתובת ה-IP או מהטווח המתאימים ליציאה שהוגדרה בשרת SOCKS.

  3. מתקינים את שרת ה-proxy לאימות של AlloyDB בלקוח החיצוני.

  4. מריצים את AlloyDB Auth Proxy בלקוח החיצוני, כשמשתנה הסביבה ALL_PROXY מוגדר לכתובת ה-IP של ה-VM המתווך, ומציינים את היציאה שבה משתמש שרת ה-SOCKS.

    בדוגמה הזו, שרת ה-proxy לאימות של AlloyDB מוגדר להתחבר למסד הנתונים ב-my-main-instance, באמצעות שרת SOCKS שפועל ב-198.51.100.1 ביציאה 1080:

    ALL_PROXY=socks5://198.51.100.1:1080 ./alloydb-auth-proxy \
projects/PROJECT_ID/locations/REGION_ID/clusters/CLUSTER_ID/instances/INSTANCE_ID

    אם אתם מתחברים מרשת VPC מקושרת, אתם יכולים להשתמש בכתובת ה-IP הפנימית של המכונה הווירטואלית המתווכת. אחרת, השתמשו בכתובת ה-IP החיצונית שלה.

  5. בודקים את החיבור באמצעות psql בלקוח החיצוני, ומחברים אותו ליציאה ש-AlloyDB Auth Proxy מאזין לה. לדוגמה, כדי להתחבר בתפקיד המשתמש postgres ליציאה 5432:

    psql -h IP_ADDRESS -p PORT_NUMBER -U USERNAME

התחברות באמצעות מאגר חיבורים של PostgreSQL

אם אתם צריכים להתקין ולהריץ את שרת ה-proxy לאימות של AlloyDB ב-VM המתווך, במקום בלקוח חיצוני, אתם יכולים להפעיל חיבורים מאובטחים אליו על ידי התאמה שלו לשרת proxy שמודע לפרוטוקול, שנקרא גם pooler. מאגרי קוד פתוח פופולריים ל-PostgreSQL כוללים את Pgpool-II ו-PgBouncer.

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

לכל מכונה באשכול AlloyDB יש כתובת IP פנימית נפרדת, ולכן כל שירות proxy יכול לתקשר רק עם מכונה ספציפית אחת: המכונה הראשית, המכונה במצב המתנה או מאגר קריאה. לכן צריך להפעיל שירות מאגר נפרד, עם אישור SSL שהוגדר בהתאם, לכל מכונה באשכול.

חיבור באמצעות Cloud VPN או Cloud Interconnect

לעבודה בסביבת ייצור שדורשת זמינות גבוהה (HA), מומלץ להשתמש במוצר Google Cloud Network Connectivity: ‏Cloud VPN או Cloud Interconnect, בהתאם לצרכים של השירות החיצוני ולהטופולוגיה של הרשת. לאחר מכן מגדירים את Cloud Router כדי לפרסם את הנתיבים המתאימים.

השימוש במוצר Network Connectivity הוא תהליך מורכב יותר מהגדרת VM מתווך, אבל בגישה הזו Google אחראית על זמן הפעולה התקינה ועל הזמינות, ולא אתם. במיוחד, ל-HA VPN יש הסכם רמת שירות (SLA) של 99.99%, ולכן הוא מתאים לסביבות ייצור.

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

למידע נוסף על הפתרונות האלה, קראו את המאמר בחירת מוצרים של Network Connectivity.

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