הפעלת נקודת קצה פרטית באמצעות מרשם השירותים של Service Directory

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

במסמך הזה מוסבר איך לרשום מכונה וירטואלית (VM) ברשת של ענן וירטואלי פרטי (VPC) כנקודת קצה של Service Directory:

  • רשת VPC מספקת קישוריות למכונות הווירטואליות ומאפשרת ליצור נקודות קצה פרטיות ברשת ה-VPC באמצעות כתובות IP פנימיות. קריאות HTTP למשאב של רשת VPC נשלחות דרך רשת פרטית תוך אכיפה של ניהול זהויות והרשאות גישה (IAM) ו-VPC Service Controls.

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

הדיאגרמה הבאה מספקת סקירה כללית:

שליחת בקשת HTTP למספר יציאה במכונה וירטואלית באמצעות מידע מ-Service Directory

באופן כללי, צריך לבצע את הפעולות הבאות:

  1. נותנים הרשאות לסוכן השירות של Cloud Workflows כדי שהוא יוכל לצפות במשאבים של Service Directory ולגשת לרשתות VPC באמצעות Service Directory.
  2. יוצרים רשת VPC כדי לספק פונקציונליות של רשת.
  3. יוצרים כלל של חומת אש ב-VPC כדי לאפשר או לחסום תעבורת נתונים אל מכונות וירטואליות ברשת ה-VPC או מהן.
  4. יוצרים מכונה וירטואלית ברשת ה-VPC. מכונה וירטואלית ב-Compute Engine היא מכונה וירטואלית שמתארחת בתשתית של Google. המונחים מכונה של Compute Engine ‏(Compute Engine instance), מכונת VM‏ (VM instance) ו-VM הם מילים נרדפות ומשמשים לסירוגין.
  5. פריסת אפליקציה ב-VM. אתם יכולים להריץ אפליקציה במכונה הווירטואלית ולאשר שהתנועה מועברת כצפוי.

  6. מגדירים את Service Directory כדי שהפעלת תהליך העבודה תוכל להפעיל נקודת קצה של Service Directory.

  7. יוצרים ומפעילים את תהליך העבודה. הערך private_service_name בתהליך העבודה מציין את נקודת הקצה של ספריית השירותים שרשמתם בשלב הקודם.

מתן הרשאות לסוכן השירות של Cloud Workflows

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

  1. כשמפעילים workflow בפעם הראשונה, סוכן השירות של Cloud Workflows נוצר באופן אוטומטי בפורמט הבא:

    service-PROJECT_NUMBER@gcp-sa-workflows.iam.gserviceaccount.com

    אפשר ליצור ידנית את חשבון השירות בפרויקט בלי תהליכי עבודה באמצעות הפקודה הזו:

    gcloud beta services identity create \
    --service=workflows.googleapis.com \
    --project=PROJECT_ID

    מחליפים את PROJECT_ID במזהה הפרויקט ב- Google Cloud.

  2. כדי להציג משאבים של Service Directory, צריך להקצות את התפקיד 'צפייה ב-Service Directory' (servicedirectory.viewer) בפרויקט לסוכן השירות של Workflows:

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:service-PROJECT_NUMBER@gcp-sa-workflows.iam.gserviceaccount.com \
    --role=roles/servicedirectory.viewer

    מחליפים את PROJECT_NUMBER במספר הפרויקט ב- Google Cloud. אפשר לראות את מספר הפרויקט בדף Welcome במסוף Google Cloud או על ידי הרצת הפקודה הבאה:

    gcloud projects describe PROJECT_ID --format='value(projectNumber)'

  3. כדי לגשת לרשתות VPC באמצעות Service Directory, צריך להקצות את התפקיד 'שירות מורשה של Private Service Connect' (roles/servicedirectory.pscAuthorizedService) בפרויקט לסוכן השירות של Workflows:

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:service-PROJECT_NUMBER@gcp-sa-workflows.iam.gserviceaccount.com \
    --role=roles/servicedirectory.pscAuthorizedService

יצירת רשת VPC

רשת VPC היא גרסה וירטואלית של רשת פיזית שמוטמעת בתוך רשת הייצור של Google. הוא מספק קישוריות למכונות הווירטואליות שלכם ב-Compute Engine.

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

לדוגמה, הפקודה הבאה יוצרת רשת VPC במצב אוטומטי:

gcloud compute networks create NETWORK_NAME \
    --subnet-mode=auto

מחליפים את NETWORK_NAME בשם של רשת ה-VPC.

מידע נוסף זמין במאמר בנושא יצירה וניהול של רשתות VPC.

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

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

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

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

gcloud compute firewall-rules create RULE_NAME \
    --network=projects/PROJECT_ID/global/networks/NETWORK_NAME \
    --direction=INGRESS \
    --action=ALLOW \
    --source-ranges=IP_ADDRESS_RANGE \
    --rules=all

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

  • ‫RULE_NAME: שם לכלל חומת האש.

  • ‫IP_ADDRESS_RANGE: טווח אחד או יותר של כתובות IPv4 או IPv6. השיטה המומלצת היא לציין את טווחי כתובות ה-IP הספציפיים שנדרשים כדי לאפשר גישה. שימו לב לנקודות הבאות:

    • הגישה לרשת פרטית ב-Service Directory משתמשת ב-35.199.192.0/19 כטווח פנימי בלבד עם קפיצות הבאות שנמצאות כולן בתוך הרשת של Google. מידע נוסף זמין במאמר בנושא נתיבים ל-Cloud DNS ול-Service Directory.

    • הכללת 35.235.240.0/20 בטווח המקור מאפשרת חיבורי SSH באמצעות העברת TCP של Identity-Aware Proxy ‏ (IAP), אם מתקיימות כל שאר הדרישות המוקדמות. מידע נוסף זמין במאמר שימוש ב-IAP להעברת TCP.

    • אם אתם משתמשים בכלי SSH בדפדפן כדי להתחבר למכונת VM של Compute Engine מתוך מסוף Google Cloud , יש דרישות ספציפיות.

  • הערך all של הדגל --rules גורם לכך שכל הפרוטוקולים וכל יציאות היעד רלוונטיים לכלל כלל חומת האש. אפשר לצמצם את ההיקף על ידי ציון פרוטוקולים ויציאות.

  • אפשר להשתמש בדגלים --target-tags ו---target-service-accounts כדי להגדיר יעדים. אם לא מגדירים יעדים, הכלל חל על כל היעדים ברשת.

מידע נוסף זמין במאמר בנושא שימוש בכללים של חומת האש ב-VPC.

יצירת מכונה וירטואלית ברשת ה-VPC

המכונות הווירטואליות כוללות אשכולות של Google Kubernetes Engine‏ (GKE), מכונות עם סביבה גמישה של App Engine ומוצרים אחרים Google Cloud שנבנו על מכונות וירטואליות של Compute Engine. כדי לתמוך בגישה לרשת פרטית, משאב של רשת VPC יכול להיות מכונה וירטואלית או יעד נתמך אחר. מידע נוסף זמין במאמר סקירה כללית על גישה לרשת פרטית.

במכונות וירטואליות של Compute Engine אפשר להריץ תמונות ציבוריות של Linux ו-Windows Server ש-Google מספקת, וגם תמונות פרטיות בהתאמה אישית שאפשר ליצור או לייבא מהמערכות הקיימות. אפשר גם לפרוס קונטיינרים של Docker.

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

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

  1. יצירה והפעלה של מופע של מכונה וירטואלית:

    gcloud compute instances create VM_NAME \
    --image-family=debian-11 \
    --image-project=debian-cloud \
    --machine-type=e2-micro \
    --network-interface network=projects/PROJECT_ID/global/networks/NETWORK_NAME

    מחליפים את VM_NAME בשם של המכונה הווירטואלית.

  2. אם מוצגת בקשה לאשר את האזור של המופע, מקלידים y.

    אחרי שיוצרים את מופע ה-VM, צריך לשים לב לכתובת INTERNAL_IP שמוחזרת.

  3. נכנסים לדף VM instances במסוף Google Cloud .

    כניסה לדף VM instances

  4. בעמודה Name (שם), לוחצים על השם של מכונת ה-VM המתאימה.

  5. אם המכונה הווירטואלית פועלת, כדי לעצור אותה לוחצים על Stop.

  6. כדי לערוך את המכונה הווירטואלית, לוחצים על Edit (עריכה).

  7. בקטע Networking > Firewalls, כדי לאפשר תנועת HTTP או HTTPS למכונה הווירטואלית, בוחרים באפשרות Allow HTTP traffic או Allow HTTPS traffic.

    בדוגמה הזו, מסמנים את תיבת הסימון Allow HTTP traffic.

    ‫Compute Engine מוסיף תג רשת למכונה הווירטואלית, שמקשר את כלל חומת האש למכונה הווירטואלית. לאחר מכן, המערכת יוצרת את כלל חומת האש המתאים לתעבורת נתונים נכנסת, שמאפשר את כל תעבורת הנתונים הנכנסת ביציאה tcp:80 (HTTP) או tcp:443 (HTTPS).

  8. כדי לשמור את השינויים, לוחצים על שמירה.

  9. כדי להפעיל מחדש את המכונה הווירטואלית, לוחצים על התחלה/המשך.

מידע נוסף זמין במאמר יצירה והפעלה של מכונה וירטואלית.

פריסת אפליקציה ב-VM

כדי לבדוק את הגדרות הרשת ולוודא שהתעבורה מועברת כמו שצריך, אפשר לפרוס אפליקציה בסיסית ב-VM שמקשיבה ליציאה.

לדוגמה, הפקודות הבאות יוצרות שירות אינטרנט ב-Node.js שמקשיב ליציאה 3000.

  1. יוצרים חיבור SSH למכונה הווירטואלית.

  2. מעדכנים את מאגרי החבילות:

    sudo apt update

  3. מתקינים את NVM,‏ Node.js ו-npm.

    מידע נוסף זמין במאמר הגדרת סביבת פיתוח ב-Node.js.

  4. ליצור קובץ package.json באופן אינטראקטיבי:

    npm init

    לדוגמה:

    {
"name": "test",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "hello"
},
"author": "",
"license": "ISC"
}

  5. מתקינים את Express, מסגרת לאפליקציות אינטרנט ל-Node.js:‏

    npm install express

  6. כותבים את הקוד לאפליקציית הבדיקה:

    vim app.js

    בדוגמה הבאה נוצרת אפליקציה שמגיבה לבקשות GET לנתיב הבסיס (/) עם הטקסט 'Hello, world!‎'.

    const express = require('express');
const app = express();

app.get('/', (req, res) => {
  res.status(200).send('Hello, world!').end();
});

app.listen(3000, () => {
  console.log('Sample app listening on port 3000.');
});

    שימו לב ליציאה שהאפליקציה מאזינה לה. צריך להשתמש באותו מספר יציאה כשמגדירים את נקודת הקצה לשירות Service Directory.

  7. מוודאים שהאפליקציה מקשיבה ליציאה 3000:

    node app.js

ב-Compute Engine יש מגוון אפשרויות פריסה. מידע נוסף זמין במאמר בחירת אסטרטגיית פריסה של עומס העבודה ב-Compute Engine.

הגדרת Service Directory

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

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

  1. יוצרים מרחב שמות:

    gcloud service-directory namespaces create NAMESPACE \
    --location=REGION

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

    • ‫NAMESPACE: המזהה של מרחב השמות או מזהה מלא של מרחב השמות.
    • ‫REGION: האזורשמכיל את מרחב השמות, לדוגמה us-central1. Google Cloud

  2. יוצרים שירות:

    gcloud service-directory services create SERVICE \
    --namespace=NAMESPACE \
    --location=REGION

    מחליפים את SERVICE בשם השירות שאתם יוצרים.

  3. מגדירים נקודת קצה.

    gcloud service-directory endpoints create ENDPOINT \
    --namespace=NAMESPACE \
    --service=SERVICE \
    --network=projects/PROJECT_NUMBER/locations/global/networks/NETWORK_NAME \
    --port=PORT_NUMBER \
    --address=IP_ADDRESS \
    --location=REGION

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

    • ‫ENDPOINT: השם של נקודת הקצה שאתם יוצרים.
    • ‫PORT_NUMBER: היציאה שבה פועלת נקודת הקצה, לדוגמה 3000.
    • ‫IP_ADDRESS: כתובת ה-IPv6 או ה-IPv4 של נקודת הקצה. זוהי כתובת ה-IP הפנימית שרשמתם קודם.

מידע נוסף זמין במאמרים הגדרת Service Directory והגדרת גישה לרשת פרטית.

יצירה ופריסה של תהליך העבודה

קריאה לנקודת קצה פרטית או הפעלה שלה מ-Workflows מתבצעת באמצעות בקשת HTTP. לשיטות הנפוצות ביותר של בקשות HTTP יש קיצור דרך לקריאה (כמו http.get ו-http.post), אבל אפשר ליצור כל סוג של בקשת HTTP על ידי הגדרת השדה call ל-http.request וציון סוג הבקשה באמצעות השדה method. מידע נוסף זמין במאמר בנושא שליחת בקשת HTTP.

  1. יוצרים קובץ קוד מקור לתהליך העבודה:

    touch call-private-endpoint.JSON_OR_YAML

    מחליפים את JSON_OR_YAML ב-yaml או ב-json, בהתאם לפורמט של תהליך העבודה.

  2. בכלי לעריכת טקסט, מעתיקים את זרימת העבודה הבאה (שבמקרה הזה משתמשת בפרוטוקול HTTP לערך url) לקובץ קוד המקור:

    YAML

    main:
  steps:
    - checkHttp:
        call: http.get
        args:
          url: http://IP_ADDRESS
          private_service_name: "projects/PROJECT_ID/locations/REGION/namespaces/NAMESPACE/services/SERVICE"
        result: res
    - ret:
        return: ${res}

    JSON

    {
  "main": {
    "steps": [
      {
        "checkHttp": {
          "call": "http.get",
          "args": {
            "url": "http://IP_ADDRESS",
            "private_service_name": "projects/PROJECT_ID/locations/REGION/namespaces/NAMESPACE/services/SERVICE"
          },
          "result": "res"
        }
      },
      {
        "ret": {
          "return": "${res}"
        }
      }
    ]
  }
}

    הערך של private_service_name חייב להיות מחרוזת שמציינת שם שירות רשום של Service Directory בפורמט הבא:

    projects/PROJECT_ID/locations/LOCATION/namespaces/NAMESPACE_NAME/services/SERVICE_NAME

  3. פורסים את תהליך העבודה. למטרות בדיקה, אתם יכולים לצרף את חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine לתהליך העבודה כדי לייצג את הזהות שלו:

    gcloud workflows deploy call-private-endpoint \
    --source=call-private-endpoint.JSON_OR_YAML \
    --location=REGION \
    --service-account=PROJECT_NUMBER-compute@developer.gserviceaccount.com

  4. מריצים את תהליך העבודה:

    gcloud workflows run call-private-endpoint \
    --location=REGION

    אמורה להופיע תוצאה דומה לזו:

    argument: 'null'
duration: 0.650784403s
endTime: '2023-06-09T18:19:52.570690079Z'
name: projects/968807934019/locations/us-central1/workflows/call-private-endpoint/executions/4aac88d3-0b54-419b-b364-b6eb973cc932
result: '{"body":"Hello, world!","code":200,"headers":{"Connection":"keep-alive","Content-Length":"21","Content-Type":"text/html;
charset=utf-8","Date":"Fri, 09 Jun 2023 18:19:52 GMT","Etag":"W/\"15-NFaeBgdti+9S7zm5kAdSuGJQm6Q\"","Keep-Alive":"timeout=5","X-Powered-By":"Express"}}'
startTime: '2023-06-09T18:19:51.919905676Z'
state: SUCCEEDED

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