שימוש ברשתות VPC משותפות

הדף הזה מתייחס ל-Apigee, אבל לא ל-Apigee Hybrid.

לעיון במסמכי התיעוד של Apigee Edge

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

היתרון של VPC משותף

סביבת זמן הריצה של Apigee (שפועלת ב-VPC שמנוהל על ידי Google) מקושרת ל-VPC שבבעלותכם. בטופולוגיה הזו, נקודת הקצה של זמן הריצה של Apigee יכולה לתקשר עם רשת ה-VPC שלכם, כמו שמוצג בתרשים הבא:

VPC משותף עם קצה עורפי פנימי ב-VPC של פרויקט אחר

אפשר לעיין גם במאמר סקירה כללית של ארכיטקטורת Apigee.

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

VPC משותף עם קצה עורפי פנימי ב-VPC של פרויקט אחר

אם מקשרים את ה-VPC של Apigee ל-VPC של ה-Backend, כמו שמוצג בתרשים, אפשר להגיע ל-Backend מרשת ה-VPC של Apigee ולהיפך, כי הקישור בין הרשתות הוא סימטרי. עם זאת, פרויקט הדייר של Apigee יכול לתקשר רק עם ה-VPC של Apigee, כי הקישור לא עובר בין רשתות שכנות, כפי שמתואר במסמכי התיעוד בנושא קישור בין רשתות שכנות (peering) של VPC. כדי שזה יעבוד, אפשר לפרוס שרתי proxy נוספים ב-VPC של Apigee כדי להעביר תנועה דרך קישור ה-peering אל ה-VPC של ה-backend. עם זאת, הגישה הזו מוסיפה תקורה תפעולית ותחזוקה נוספות.

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

הגדרת VPC משותף עם Apigee

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

סקירה כללית על הארכיטקטורה של VPC משותף

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

דרישות מוקדמות

  1. מומלץ לעיין במושגים שמוסברים במאמר סקירה כללית על VPC משותף. חשוב להבין את המושגים פרויקט מארח ופרויקט שירות.
  2. יוצרים פרויקט חדש ב-Google Cloud שאפשר להגדיר בו VPC משותף. הפרויקט הזה הוא הפרויקט המארח. איך יוצרים ומנהלים פרויקטים
  3. פועלים לפי השלבים במאמר הקצאת משאבים ל-VPC משותף כדי להקצות משאבים לפרויקט ל-VPC משותף. כדי להפעיל את הפרויקט המארח ב-VPC משותף, צריך להיות אדמין בארגון או לקבל תפקידי אדמין מתאימים בניהול הזהויות והרשאות הגישה (IAM).
  4. יוצרים פרויקט שני ב-Google Cloud. הפרויקט הזה הוא פרויקט שירות. בהמשך, תצרפו אותו לפרויקט המארח.

הורדת הסקריפט

‫Apigee מספק סקריפט הקצאה כדי לפשט את יצירת הטופולוגיה הנדרשת. צריך למשוך את הסקריפט מ-GitHub:

  1. משכפלים את הפרויקט ב-GitHub שמכיל את הסקריפט: 
    git clone https://github.com/apigee/devrel.git
  2. עוברים לספרייה הבאה בפרויקט: 
    cd devrel/tools/apigee-x-trial-provision
  3. מגדירים את משתני הסביבה הבאים: 
    export HOST_PROJECT=HOST_PROJECT_ID
export SERVICE_PROJECT=SERVICE_PROJECT_ID

    כאשר:

    • ‫HOST_PROJECT_ID הוא מזהה הפרויקט של פרויקט המארח של ה-VPC המשותף שיצרתם כאחד מהתנאים המוקדמים.
    • ‫SERVICE_PROJECT_ID הוא מזהה הפרויקט של פרויקט השירות ב-Google Cloud שיצרתם בדרישות המוקדמות.

הגדרת פרויקט המארח

  1. מגדירים את משתני הסביבה הבאים:
    2. export NETWORK=YOUR_SHARED_VPC
export SUBNET=YOUR_SHARED_SUBNET
export PEERING_CIDR=CIDR_BLOCK

    כאשר:

    • ‫YOUR_SHARED_VPC הוא השם של רשת ה-VPC המשותפת.
    • ‫YOUR_SHARED_SUBNET הוא השם של רשת המשנה של ה-VPC המשותף.
    • ‫CIDR_BLOCK הוא בלוק ה-CIDR של ה-VPC של Apigee. לדוגמה: 10.111.0.0/23.
  2. כדי להגדיר את ה-VPC peering ואת חומת האש של Apigee, מריצים את הסקריפט עם האפשרויות הבאות: 
    ./apigee-x-trial-provision.sh \
    -p $HOST_PROJECT --shared-vpc-host-config --peering-cidr $PEERING_CIDR

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

    export NETWORK=projects/$HOST_PROJECT/global/networks/$NETWORK
export SUBNET=projects/$HOST_PROJECT/regions/us-west1/subnetworks/$SUBNET
  3. מייצאים את המשתנים שהוחזרו בפלט.

הגדרת פרויקט השירות

בשלב הזה מגדירים את פרויקט השירות. כשהסקריפט מסתיים, הוא יוצר ופורס proxy לדוגמה של API בסביבת Apigee שלכם, שבו תוכלו להשתמש כדי לבדוק את הקצאת ההרשאות.

  1. מריצים את הסקריפט apigee-x-trial-provision.sh בפעם השנייה כדי להקצות לפרויקט השירות את הגדרות הרשת המשותפת: 
    ./apigee-x-trial-provision.sh \
    -p $SERVICE_PROJECT

    הסקריפט יוצר שרת proxy לדוגמה בסביבת Apigee ומדפיס פקודת curl אל STDOUT שאפשר להפעיל כדי לבדוק את ההקצאה.

  2. קוראים ל-proxy ל-API של הבדיקה. לדוגמה: 
    curl -v https://10-111-111-111.nip.io/hello-world

הגדרת פרויקט שירות אחר לשירותי קצה עורפי

מומלץ להפריד את תשתית הענן של Google לכמה פרויקטים. בחירה של היררכיית משאבים לאזור הנחיתה ב-Google Cloud בקטע הזה מוסבר איך לפרוס שירות backend בפרויקט שירות נפרד ולצרף אותו למארח של ה-VPC המשותף. ‫Apigee יכול להשתמש בשירות לקצה העורפי כיעד של proxy ל-API, כי גם פרויקט השירות של Apigee וגם פרויקט השירות לקצה העורפי מצורפים למארח של ה-VPC המשותף.

דרישות מוקדמות

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

הגדרת פרויקט השירות

בקטע הזה תבדקו שירות לקצה העורפי בתת-רשת אחרת של VPC משותף, תיצרו תת-רשת שנייה בפרויקט המארח ותשתמשו בכתובת ה-IP הפרטית שלה מסוג RFC1918 ככתובת היעד של שרתי ה-proxy של Apigee API.

  1. מתוך פרויקט שירות לקצה העורפי, מריצים את הפקודה הבאה כדי לראות את כל רשתות המשנה המשותפות שזמינות: 
    gcloud compute networks subnets list-usable --project $HOST_PROJECT  --format yaml

    פלט לדוגמה: 

    ipCidrRange: 10.0.0.0/20
network: https://www.googleapis.com/compute/v1/projects/my-svpc-hub/global/networks/hub-vpc
subnetwork: https://www.googleapis.com/compute/v1/projects/my-svpc-hub/regions/europe-west1/subnetworks/sub1
  2. יוצרים את משתני הסביבה הבאים: 
    BACKEND_SERVICE_PROJECT=PROJECT_ID
SHARED_VPC_SUBNET=SUBNET

    כאשר:

    • ‫PROJECT_ID הוא שם פרויקט השירות שיצרתם עבור שירותי הקצה העורפי.
    • ‫SUBNET הוא אחד מהפלט של רשתות המשנה מהפקודה הקודמת.
  3. כדי ליצור שירות backend‏ httpbin בפרויקט למטרות בדיקה, משתמשים בפקודה הבאה: 
    gcloud compute --project=$BACKEND_SERVICE_PROJECT instances create-with-container httpbin \
  --machine-type=e2-small --subnet=$SHARED_VPC_SUBNET \
  --image-project=cos-cloud --image-family=cos-stable --boot-disk-size=10GB \
  --container-image=kennethreitz/httpbin --container-restart-policy=always --tags http-server
  4. יוצרים ופורסים proxy ל-API של Apigee לפי השלבים במאמר בנושא יצירת proxy ל-API.
  5. מקבלים את כתובת ה-IP הפנימית של המכונה הווירטואלית (VM) שבה פועל שירות היעד. תשתמשו בכתובת ה-IP הזו בשלב הבא כדי להפעיל את proxy ל-API לבדיקה: 
    gcloud compute instances list --filter=name=httpbin
  6. כדי לבדוק את ההגדרה, מתקשרים לשרת ה-proxy. משתמשים בכתובת ה-IP הפנימית של המכונה הווירטואלית שקיבלתם בשלב הקודם. בדוגמה הבאה מניחים שנתתם לנתיב הבסיס של ה-proxy את השם /myproxy. לדוגמה: 
    curl -v https://INTERNAL_IP/myproxy

    הקריאה הזו ל-API מחזירה Hello, Guest!.