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

בדף הזה נבחנות דרכים שונות להתחבר לאשכול AlloyDB ל-PostgreSQL מחוץ לענן הווירטואלי הפרטי (VPC) שהוגדר לו. המדריך יוצא מנקודת הנחה שכבר יצרתם אשכול AlloyDB.

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

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

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

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

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

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

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

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

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

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

התחברות דרך מכונה וירטואלית מתווכת

כדי ליצור חיבור לאשכול 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: מספר היציאה של המכונה הווירטואלית.

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

    psql -h localhost -p 5432 -U USERNAME

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

    • ‫USERNAME: משתמש postgreSQL שאליו רוצים להתחבר למופע – לדוגמה, משתמש ברירת המחדל postgres.

חיבור דרך שרת SOCKS proxy

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

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

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

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

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

  3. מתקינים את AlloyDB Auth Proxy בלקוח החיצוני.

  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 בלקוח החיצוני, ומחברים אותו ליציאה שבה שרת ה-proxy של AlloyDB Auth מאזין. לדוגמה, כדי להתחבר בתור תפקיד המשתמש postgres ליציאה 5432:

    psql -h IP_ADDRESS -p PORT_NUMBER -U USERNAME

קישור באמצעות מאגר PostgreSQL

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

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

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

חיבור דרך Cloud VPN או Cloud Interconnect

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

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

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

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

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