התחברות לרשת VPC

אנחנו ממליצים להשתמש בDirect VPC egress כדי לשלוח תעבורת נתונים לרשת VPC, בלי צורך במחבר.

עם זאת, אם אתם לא יכולים להשתמש בתעבורת נתונים יוצאת ישירות ל-VPC, אתם יכולים להגדיר במקום זאת מחבר גישה ל-VPC ללא שרת. בדף הזה מוסבר איך לחבר שירות או משימה של Cloud Run לרשת ה-VPC באמצעות מחבר, כדי לאפשר תעבורת נתונים יוצאת (egress) מ-Cloud Run למכונות וירטואליות של Compute Engine, למכונות של Memorystore ולכל משאב אחר עם כתובת IP פנימית.

לפני שמתחילים

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

  • אם אתם משתמשים ב-VPC משותף, עיינו במסמכי התיעוד שעוסקים באופן ספציפי בהגדרת גישה ל-VPC ללא שרת (Serverless) למוצר שלכם.

  • אם יש לכם אילוץ במדיניות הארגון שמונע את השימוש ב-Cloud Deployment Manager, לא תוכלו ליצור או למחוק מחברים של "גישה ל-VPC ללא שרת". כדי ליצור או למחוק מחבר, צריך להשתמש בפונקציונליות של Deployment Manager.

  • אם הגדרתם בפרויקט מדיניות בנושא קובצי אימג' מהימנים, ודאו שאתם מאשרים את הפרויקט serverless-vpc-access-images במדיניות הארגון constraints/compute.trustedimageProjects.

    דרישות לגבי רשת המשנה של המחבר

  • לכל מחבר נדרשת רשת משנה ייעודית משלו למטרת PRIVATE, עם טווח כתובות IPv4 ראשי של /28. משאבים אחרים, כמו מכונות וירטואליות, Private Service Connect או מאזני עומסים, לא יכולים להשתמש ברשת המשנה הזו. אחרי שיוצרים את המחבר, אי אפשר להרחיב את רשת המשנה. הוא חייב להישאר /28.

  • כדי ליצור מחבר בפרויקט שירות שמשתמש ברשת VPC משותפת בפרויקט מארח, מנהל הרשת של רשת ה-VPC המשותפת צריך ליצור באופן ידני את רשת המשנה של המחבר לפני שתוכלו ליצור את המחבר.

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

    gcloud compute networks subnets describe SUBNET --region=REGION

    מחליפים את SUBNET בשם של רשת המשנה ואת REGION באזור שבו נמצאת רשת המשנה.

    בפלט, בודקים את הפרטים הבאים:

    • רשת המשנה היא רשת משנה רגילה. ב-Google Cloud CLI, המשמעות היא שהערך של purpose הוא PRIVATE.
    • טווח כתובות ה-IPv4 הראשי של רשת המשנה, ipCidrRange, הוא /28.

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

    כש- Google Cloud יוצרת רשת משנה למחבר, חשוב לשים לב לנקודות הבאות:

    • רשתות משנה שנוצרו באופן אוטומטי בשביל מחברים לא מופיעות כשמציגים רשימה של רשתות משנה, גם אם משתמשים במסוף Google Cloud , ב-Google Cloud CLI או ב-Compute Engine API.

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

    • רשתות משנה שנוצרות באופן אוטומטי נכללות ברשימת רשתות המשנה שמוצגת כשמתארים רשת VPC.

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

מגבלות

  • אין תמיכה בתנועה ב-IPv6.
  • אי אפשר ליצור מחברי גישה ל-VPC ללא שרת באזור asia-southeast3.
  • יצירת מחברים של חיבור לרשת VPC נכשלת בסביבות של Assured Workloads. כדי לעקוף את הבעיה, אפשר להגדיר Direct VPC egress למשאבים בלי שרת (serverless).

יצירת מחבר

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

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

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

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

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

אפשר ליצור מחבר באמצעות מסוף Google Cloud ,‏ Google Cloud CLI או Terraform.

המסוף

  1. נכנסים לדף הסקירה הכללית של Serverless VPC Access.

    כניסה לדף Serverless VPC Access

  2. לוחצים על Create connector.

  3. בשדה Name, מזינים שם למחבר שתואם למוסכמות מתן השמות של Compute Engine, עם הדרישות הנוספות הבאות: השם חייב להיות באורך של פחות מ-21 תווים, ומקפים (-) נספרים כשני תווים.

  4. בשדה Region, בוחרים אזור למחבר. האזור צריך להיות זהה לאזור של השירות ללא שרת (serverless).

  5. בשדה Network, בוחרים את רשת ה-VPC שאליה רוצים לצרף את המחבר.

  6. בשדה Subnet, בוחרים אחת מהאפשרויות הבאות:

    • יצירת מחבר באמצעות רשת משנה קיימת: בוחרים את רשת המשנה הקיימת בשדה Subnet.

    • יצירת מחבר ורשת משנה חדשה: בשדה Subnet בוחרים באפשרות Custom IP range. לאחר מכן, מזינים את הכתובת הראשונה ב-CIDR /28 שלא בשימוש (לדוגמה 10.8.0.0/28) כדי להשתמש בה כטווח הראשי של כתובות IPv4 של רשת משנה חדשה ש- Google Cloud יוצר ברשת ה-VPC של המחבר. חשוב לוודא שטווח כתובות ה-IP לא מתנגש עם נתיבים קיימים ברשת ה-VPC של המחבר. השם של רשת המשנה החדשה מתחיל בקידומת "aet-‎".

  7. (אופציונלי) כדי להגדיר אפשרויות התאמה לעומס, שמאפשרות שליטה נוספת במחבר, לוחצים על Show Scaling Settings כדי להציג את טופס ההתאמה לעומס.

    1. מגדירים את מספר המכונות המינימלי והמקסימלי של המחבר, או משתמשים בערכי ברירת המחדל: 2 (מינימום) ו-10 (מקסימום). המחבר מתרחב עד למקסימום שצוין אם השימוש בתנועה מחייב זאת. צריך להשתמש בערכים בין 2 ל-10.
    2. בתפריט Instance Type, בוחרים את סוג המכונה שבה רוצים להשתמש למחבר, או משתמשים בברירת המחדל e2-micro. שימו לב לסרגל הצד של העלויות שמופיע בצד ימין כשבוחרים את סוג המכונה, שבו מוצגות הערכות של רוחב הפס והעלויות.

  8. לוחצים על יצירה.

  9. כשהמחבר יהיה מוכן לשימוש, יופיע סימן וי ירוק ליד השם שלו.

gcloud

  1. מפעילים את Cloud Shell במסוף Google Cloud .

    הפעלת Cloud Shell

    בחלק התחתון של מסוף Google Cloud יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.

  2. מעדכנים את הרכיבים של gcloud לגרסה העדכנית:

    gcloud components update

  3. מוודאים שה-API של "חיבור לרשת (VPC) מאפליקציית serverless" מופעל בפרויקט:

    gcloud services enable vpcaccess.googleapis.com

  4. יוצרים את המחבר באחת מהאפשרויות הבאות:

    לפרטים נוספים ולארגומנטים אופציונליים, עיינו במפרט של gcloud.

    • יצירת מחבר באמצעות רשת משנה קיימת:

      gcloud compute networks vpc-access connectors create CONNECTOR_NAME \
 --region REGION \
 --subnet SUBNET_NAME \
 --subnet-project HOST_PROJECT_ID \
 --min-instances MIN \
 --max-instances MAX \
 --machine-type MACHINE_TYPE

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

      • ‫CONNECTOR_NAME: שם למחבר, שתואם למוסכמות מתן השמות של Compute Engine, עם דרישות נוספות: השם חייב להיות באורך של פחות מ-21 תווים, ומקפים (-) נספרים כשני תווים.
      • ‫REGION: אזור למחבר, שתואם לאזור של השירות או המשימה ללא שרת (serverless).
      • ‫SUBNET_NAME: השם של תת-הרשת הקיימת.
      • ‫HOST_PROJECT_ID: מזהה הפרויקט המארח של ה-VPC המשותף. אם המחבר ורשת המשנה הקיימת נמצאים באותו פרויקט, משמיטים את הדגל --subnet-project.
      • ‫MIN: המספר המינימלי של המכונות שבהן ישתמש המחבר. צריך להשתמש במספר שלם בין 2(ברירת המחדל) לבין 9.
      • ‫MAX: המספר המקסימלי של המכונות שבהן אפשר להשתמש במחבר. צריך להשתמש במספר שלם בין 3 ל-10 (ברירת המחדל).
      • ‫MACHINE_TYPE: צריך להיות אחד מהערכים הבאים: f1-micro, ‏e2-micro או e2-standard-4.

    • יצירת מחבר ורשת משנה חדשה:

      gcloud compute networks vpc-access connectors create CONNECTOR_NAME \
 --region REGION \
 --network VPC_NETWORK \
 --range IP_RANGE
 --min-instances MIN \
 --max-instances MAX \
 --machine-type MACHINE_TYPE

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

      • ‫CONNECTOR_NAME: שם למחבר, שתואם למוסכמות מתן השמות של Compute Engine, עם הדרישות הנוספות שהשם חייב להיות באורך של פחות מ-21 תווים, ושמקפים (-) נספרים כשני תווים.
      • ‫REGION: אזור למחבר, שתואם לאזור של השירות או המשימה ללא שרת (serverless).
      • ‫VPC_NETWORK: השם של רשת ה-VPC שאליה רוצים לחבר את המחבר. המחבר ורשת ה-VPC צריכים להיות באותו פרויקט.
      • ‫IP_RANGE: צריך לספק CIDR של /28 שלא נמצא בשימוש (לדוגמה 10.8.0.0/28) כדי להשתמש בו כטווח הראשי של כתובות IPv4 של רשת משנה חדשה שנוצרת על ידי Google Cloud ברשת ה-VPC של המחבר. חשוב לוודא שטווח כתובות ה-IP לא מתנגש עם מסלולים קיימים ברשת ה-VPC של המחבר. השם של רשת המשנה החדשה מתחיל בקידומת "aet-‎".
      • ‫MIN: המספר המינימלי של המכונות שבהן ישתמש המחבר. צריך להשתמש במספר שלם בין 2(ברירת המחדל) לבין 9.
      • ‫MAX: המספר המקסימלי של המכונות שבהן אפשר להשתמש במחבר. צריך להשתמש במספר שלם בין 3 ל-10 (ברירת המחדל). אם המחבר מגיע למספר המקסימלי של מכונות, הוא לא יורד בחזרה.
      • ‫MACHINE_TYPE: צריך להיות אחד מהערכים הבאים: f1-micro, ‏e2-micro או e2-standard-4.

  5. לפני שמשתמשים במחבר, צריך לוודא שהוא במצב READY:

    gcloud compute networks vpc-access connectors describe CONNECTOR_NAME \
--region REGION

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

    • ‫CONNECTOR_NAME: השם של המחבר שציינתם בשלב הקודם.
    • ‫REGION: האזור של המחבר, שציינתם בשלב הקודם.

    הפלט צריך להכיל את השורה state: READY.

Terraform

אתם יכולים להשתמש במשאב של Terraform כדי להפעיל את ה-API של vpcaccess.googleapis.com.

resource "google_project_service" "vpcaccess-api" {
  project = var.project_id # Replace this with your project ID in quotes
  service = "vpcaccess.googleapis.com"
}

אתם יכולים להשתמש במודולים של Terraform כדי ליצור רשת VPC ותת-רשת, ואז ליצור את המחבר.

module "test-vpc-module" {
  source       = "terraform-google-modules/network/google"
  version      = "~> 18.0"
  project_id   = var.project_id # Replace this with your project ID in quotes
  network_name = "my-serverless-network"
  mtu          = 1460

  subnets = [
    {
      subnet_name   = "serverless-subnet"
      subnet_ip     = "10.10.10.0/28"
      subnet_region = "us-central1"
    }
  ]
}

module "serverless-connector" {
  source     = "terraform-google-modules/network/google//modules/vpc-serverless-connector-beta"
  version    = "~> 18.0"
  project_id = var.project_id
  vpc_connectors = [{
    name        = "central-serverless"
    region      = "us-central1"
    subnet_name = module.test-vpc-module.subnets["us-central1/serverless-subnet"].name
    # host_project_id = var.host_project_id # Specify a host_project_id for shared VPC
    machine_type  = "e2-standard-4"
    min_instances = 2
    max_instances = 7
    }
    # Uncomment to specify an ip_cidr_range
    #   , {
    #     name          = "central-serverless2"
    #     region        = "us-central1"
    #     network       = module.test-vpc-module.network_name
    #     ip_cidr_range = "10.10.11.0/28"
    #     subnet_name   = null
    #     machine_type  = "e2-standard-4"
    #     min_instances = 2
    #   max_instances = 7 }
  ]
  depends_on = [
    google_project_service.vpcaccess-api
  ]
}

הגדרת סביבה ללא שרת (serverless) לשימוש במחבר

אחרי שיוצרים מחבר של חיבור לרשת (VPC) מאפליקציית serverless, מגדירים את סביבת ה-serverless כך שתשתמש במחבר, לפי ההוראות לסביבת ה-serverless:

הגדרת Cloud Run לשימוש במחבר

כשיוצרים שירות חדש או פורסים גרסה חדשה, אפשר להגדיר את השירות כך שישתמש במחבר באמצעות מסוף Google Cloud ,‏ Google Cloud CLI, קובץ YAML או משאב Terraform.

המסוף

  1. נכנסים ל-Cloud Run במסוף Google Cloud :

    כניסה ל-Cloud Run

  2. בתפריט הניווט של Cloud Run, לוחצים על Services:

    1. אם אתם מגדירים שירות חדש, לוחצים על Deploy container וממלאים את דף הגדרות השירות הראשוני. לאחר מכן לוחצים על Containers, Networking, Security כדי להרחיב את דף הגדרת השירות.

    2. אם אתם מגדירים שירות קיים, לוחצים על השירות.

  3. לוחצים על הכרטיסייה חיבורים.

  4. בשדה VPC Connector, בוחרים את המחבר שבו רוצים להשתמש או בוחרים באפשרות None כדי לנתק את השירות מרשת VPC.

  5. לוחצים על Create או על Deploy.

gcloud

  1. מפעילים את Cloud Shell במסוף Google Cloud .

    הפעלת Cloud Shell

    בחלק התחתון של מסוף Google Cloud יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.

  2. כדי לציין מחבר במהלך הפריסה, משתמשים בדגל --vpc-connector:

    gcloud run deploy SERVICE --image IMAGE_URL --vpc-connector CONNECTOR_NAME
    • מחליפים את SERVICE בשם השירות.
    • מחליפים את IMAGE_URL.
    • מחליפים את CONNECTOR_NAME בשם של המחבר. אם המחבר נמצא בפרויקט המארח של VPC משותף, צריך לציין את השם המלא, לדוגמה: 
      projects/HOST_PROJECT_ID/locations/CONNECTOR_REGION/connectors/CONNECTOR_NAME
       כאשר HOST_PROJECT_ID הוא המזהה של הפרויקט המארח, CONNECTOR_REGION הוא האזור של המחבר ו-CONNECTOR_NAME הוא השם שנתתם למחבר.

    כדי לצרף, לעדכן או להסיר מחבר לשירות קיים, משתמשים בפקודה gcloud run services update עם אחד מהדגלים הבאים, לפי הצורך:

    לדוגמה, כדי לצרף או לעדכן מחבר:

    gcloud run services update SERVICE --vpc-connector CONNECTOR_NAME
    • מחליפים את SERVICE בשם השירות.
    • מחליפים את CONNECTOR_NAME בשם של המחבר.

YAML

  1. אם אתם יוצרים שירות חדש, דלגו על השלב הזה. אם אתם מעדכנים שירות קיים, הורידו את הגדרת ה-YAML שלו:

    gcloud run services describe SERVICE --format export > service.yaml

  2. מוסיפים או מעדכנים את המאפיין run.googleapis.com/vpc-access-connector במאפיין annotations שבמאפיין ברמה העליונה spec:

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/vpc-access-connector: CONNECTOR_NAME
    • מחליפים את SERVICE בשם של שירות Cloud Run.
    • מחליפים את CONNECTOR_NAME בשם של המחבר. אם המחבר נמצא בפרויקט המארח של VPC משותף, צריך לציין את השם המלא, לדוגמה: 
      projects/HOST_PROJECT_ID/locations/CONNECTOR_REGION/connectors/CONNECTOR_NAME
       כאשר HOST_PROJECT_ID הוא המזהה של הפרויקט המארח, CONNECTOR_REGION הוא האזור של המחבר ו-CONNECTOR_NAME הוא השם שנתתם למחבר.

  3. מחליפים את השירות בהגדרות החדשות שלו באמצעות הפקודה הבאה:

    gcloud beta run services replace service.yaml

Terraform

אתם יכולים להשתמש במשאב של Terraform כדי ליצור שירות ולהגדיר אותו כך שישתמש במחבר שלכם.

# Cloud Run service
resource "google_cloud_run_v2_service" "gcr_service" {
  name     = "mygcrservice"
  location = "us-west1"

  deletion_protection = false # set to "true" in production

  template {
    containers {
      image = "us-docker.pkg.dev/cloudrun/container/hello"
      resources {
        limits = {
          cpu    = "1000m"
          memory = "512Mi"
        }
      }
      # the service uses this SA to call other Google Cloud APIs
      # service_account_name = myservice_runtime_sa
    }

    scaling {
      # Limit scale up to prevent any cost blow outs!
      max_instance_count = 5
    }

    vpc_access {
      # Use the VPC Connector
      connector = google_vpc_access_connector.connector.id
      # all egress from the service should go through the VPC Connector
      egress = "ALL_TRAFFIC"
    }
  }
}

הגדרת פונקציות Cloud Run לשימוש במחבר

אפשר להגדיר פונקציה שתשתמש במחבר ממסוף Google Cloud או מ-Google Cloud CLI:

המסוף

  1. נכנסים לדף הסקירה הכללית של פונקציות Cloud Run במסוףGoogle Cloud :

    כניסה לדף Cloud Run functions

  2. לוחצים על Create function. לחלופין, לוחצים על פונקציה קיימת כדי לעבור לדף הפרטים שלה, ולוחצים על Edit.

  3. מרחיבים את ההגדרות המתקדמות בלחיצה על RUNTIME, BUILD AND CONNECTIONS SETTINGS.

  4. בכרטיסייה Connections, בקטע Egress settings, מזינים את שם המחבר בשדה VPC connector.

gcloud

  1. מפעילים את Cloud Shell במסוף Google Cloud .

    הפעלת Cloud Shell

    בחלק התחתון של מסוף Google Cloud יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.

  2. משתמשים בפקודה gcloud functions deploy כדי לפרוס את הפונקציה ומציינים את הדגל --vpc-connector:

    gcloud functions deploy FUNCTION_NAME \
--vpc-connector CONNECTOR_NAME \
FLAGS...

    כאשר:

    • ‫FUNCTION_NAME הוא שם הפונקציה.
    • ‫CONNECTOR_NAME הוא שם המחבר. אם המחבר נמצא בפרויקט המארח של VPC משותף, צריך לציין את השם המלא, לדוגמה: 
      projects/HOST_PROJECT_ID/locations/CONNECTOR_REGION/connectors/CONNECTOR_NAME
       כאשר HOST_PROJECT_ID הוא המזהה של הפרויקט המארח, CONNECTOR_REGION הוא האזור של המחבר, ו- CONNECTOR_NAME הוא השם שנתתם למחבר.
    • ‫FLAGS... מתייחס לדגלים אחרים שאתם מעבירים במהלך פריסת הפונקציה.

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

הגדרת App Engine לשימוש במחבר

‫Python 2

  1. להפסיק להשתמש בשירות אחזור כתובות ה-URL של App Engine.

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

    אם צריך, עדיין אפשר להשתמש בספריית urlfetch ישירות לבקשות ספציפיות, אבל זה לא מומלץ.

  2. מוסיפים את השדה Serverless VPC Access לקובץ app.yaml:

    vpc_access_connector:
 name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME

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

    • ‫PROJECT_ID במזהה הפרויקט ב- Google Cloud . אם המחבר נמצא בפרויקט המארח של VPC משותף, צריך להזין את המזהה של הפרויקט המארח.
    • REGION באזור שבו נמצא המחבר.
    • CONNECTOR_NAME בשם של המחבר.

  3. פורסים את השירות:

    gcloud app deploy

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

Java 8

  1. להפסיק להשתמש בשירות אחזור של כתובות אתרים ב-App Engine URLFetchService.

  2. מוסיפים את הרכיב "חיבור לרשת (VPC) מאפליקציית serverless" לקובץ appengine-web.xml של השירות:

    <vpc-access-connector>
<name>projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME</name>
</vpc-access-connector>

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

    • ‫PROJECT_ID במזהה הפרויקט ב- Google Cloud . אם המחבר נמצא בפרויקט המארח של VPC משותף, צריך להזין את המזהה של הפרויקט המארח.
    • REGION באזור שבו נמצא המחבר.
    • CONNECTOR_NAME בשם של המחבר.

  3. פורסים את השירות:

    gcloud app deploy WEB-INF/appengine-web.xml

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

Go 1.11

  1. להפסיק להשתמש בשירות אחזור כתובות ה-URL של App Engine.

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

  2. מוסיפים את השדה Serverless VPC Access לקובץ app.yaml:

    vpc_access_connector:
 name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME

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

    • ‫PROJECT_ID במזהה הפרויקט ב- Google Cloud
    • REGION באזור שבו נמצא המחבר
    • CONNECTOR_NAME בשם של המחבר.

  3. פורסים את השירות:

    gcloud app deploy

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

כל שאר סביבות זמן הריצה

  1. מוסיפים את השדה Serverless VPC Access לקובץ app.yaml:

    vpc_access_connector:
 name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME

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

    • ‫PROJECT_ID במזהה הפרויקט ב- Google Cloud . אם המחבר נמצא בפרויקט המארח של VPC משותף, צריך להזין את המזהה של הפרויקט המארח.
    • REGION באזור שבו נמצא המחבר.
    • CONNECTOR_NAME בשם של המחבר.

  2. פורסים את השירות:

    gcloud app deploy

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

הגדרת כללים לחומת האש בשביל מחברים

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

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

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

הטווחים האלה משמשים את התשתית של Google שעליה מבוססים Cloud Run, פונקציות Cloud Run וסביבת ברירת המחדל ב-App Engine. כל הבקשות מכתובות ה-IP האלה מגיעות מהתשתית של Google, כדי לוודא שכל משאב בלי שרת (serverless) מתקשר רק עם המחבר שאליו הוא מחובר.

בנוסף, צריך לאפשר תנועה מרשת המשנה של המחבר למשאבים ברשת ה-VPC.

כדי לבצע את השלבים האלה, צריך להיות לכם אחד מהתפקידים הבאים בפרויקט המארח:

בהגדרה בסיסית, מחילים את הכללים כדי לאפשר למשאבים בלי שרת (serverless) בכל פרויקט שירות שמחובר לרשת ה-VPC המשותפת לשלוח בקשות לכל משאב ברשת.

כדי להחיל את הכללים האלה, מריצים את הפקודות הבאות בפרויקט המארח:

  1. יוצרים כללים של חומת אש שמאפשרים לבקשות מתשתית ה-Serverless של Google ומבדיקות תקינות להגיע לכל המחברים ברשת. בפקודות האלה, יציאות ה-UDP וה-TCP משמשות כשרתי proxy ולבדיקות תקינות של HTTP, בהתאמה. אל תשנו את היציאות שצוינו.

    gcloud compute firewall-rules create serverless-to-vpc-connector \
    --allow tcp:667,udp:665-666,icmp \
    --source-ranges=35.199.224.0/19 \
    --direction=INGRESS \
    --target-tags vpc-connector \
    --network=VPC_NETWORK
     
    gcloud compute firewall-rules create vpc-connector-to-serverless \
    --allow tcp:667,udp:665-666,icmp \
    --destination-ranges=35.199.224.0/19 \
    --direction=EGRESS \
    --target-tags vpc-connector \
    --network=VPC_NETWORK
     
    gcloud compute firewall-rules create vpc-connector-health-checks \
    --allow tcp:667 \
    --source-ranges=35.191.0.0/16,35.191.192.0/18,130.211.0.0/22 \
    --direction=INGRESS \
    --target-tags vpc-connector \
    --network=VPC_NETWORK

    מחליפים את VPC_NETWORK בשם של רשת ה-VPC שאליה רוצים לצרף את המחבר.

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

    gcloud compute firewall-rules create vpc-connector-requests \
    --allow tcp,udp,icmp \
    --direction=INGRESS \
    --source-tags vpc-connector \
    --network=VPC_NETWORK

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

יצירת כללים לחומת האש למחברים ספציפיים

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

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

  • תגי רשת: לכל מחבר יש שני תגי רשת: vpc-connector ו-vpc-connector-REGION-CONNECTOR_NAME. השתמשו בפורמט השני כדי להגביל את ההיקף של כללי חומת האש למחבר ספציפי.
  • טווחי כתובות IP: אפשר להשתמש בהם רק לכללי תעבורת נתונים יוצאת, כי הם לא פועלים לכללי תעבורת נתונים נכנסת. אתם יכולים להשתמש בטווח ה-IP של רשת המשנה של המחבר כדי להגביל את ההיקף של כללי חומת האש למחבר VPC אחד.

הגבלת הגישה של ה-VM של המחבר למשאבים של רשת ה-VPC

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

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

הדוגמאות הבאות ממחישות כל אחת מהאסטרטגיות.

הגבלת הגישה באמצעות כללי תעבורת נתונים נכנסת (ingress)

בוחרים תגי רשת או טווחי CIDR כדי לשלוט בתנועה הנכנסת לרשת ה-VPC.

תגי רשת

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

  1. חשוב לוודא שיש לכם את ההרשאות הנדרשות כדי להוסיף כללי חומת אש. אתם צריכים אחד מהתפקידים הבאים בניהול זהויות והרשאות גישה (IAM):

  2. דחיית תנועה של מחברים ברשת ה-VPC.

    יוצרים כלל חומת אש לתעבורת נתונים נכנסת (ingress) עם עדיפות נמוכה מ-1,000 ברשת ה-VPC, כדי לדחות תעבורת נתונים נכנסת מתג הרשת של המחבר. הכלל הזה מבטל את כלל חומת האש המשתמע שנוצר כברירת מחדל ברשת ה-VPC על ידי החיבור לרשת (VPC) מאפליקציית serverless.

    gcloud compute firewall-rules create RULE_NAME \
--action=DENY \
--rules=PROTOCOL \
--source-tags=VPC_CONNECTOR_NETWORK_TAG \
--direction=INGRESS \
--network=VPC_NETWORK \
--priority=PRIORITY

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

    • ‫RULE_NAME: השם של כלל חומת האש החדש. לדוגמה, deny-vpc-connector.

    • ‫PROTOCOL: פרוטוקול אחד או יותר שרוצים לאפשר ממחבר ה-VPC. הפרוטוקולים הנתמכים הם tcp או udp. לדוגמה, tcp:80,udp מאפשר תנועת TCP דרך יציאה 80 ותנועת UDP. מידע נוסף זמין במאמרי העזרה בנושא הדגל allow.

      למטרות אבטחה ואימות, אתם יכולים גם להגדיר כללי דחייה כדי לחסום תנועה בפרוטוקולים הבאים שלא נתמכים: ah,‏ all,‏ esp,‏ icmp,‏ ipip ו-sctp.

    • ‫VPC_CONNECTOR_NETWORK_TAG: תג הרשת של המחבר האוניברסלי, אם רוצים להגביל את הגישה לכל המחברים (כולל מחברים שייווצרו בעתיד), או תג הרשת הייחודי, אם רוצים להגביל את הגישה למחבר ספציפי.

      • תג רשת אוניברסלי: vpc-connector

      • תג רשת ייחודי: vpc-connector-REGION-CONNECTOR_NAME

        מחליפים את:

        • ‫REGION: האזור של המחבר שרוצים להגביל
        • ‫CONNECTOR_NAME: שם המחבר שרוצים להגביל

      למידע נוסף על תגי רשת של מחברים, ראו תגי רשת.

    • ‫VPC_NETWORK: השם של רשת ה-VPC

    • ‫PRIORITY: מספר שלם בין 0 ל-65535. לדוגמה, הערך 0 מגדיר את העדיפות הגבוהה ביותר.

  3. מאפשרים תנועה מהמחבר למשאב שאמור לקבל תנועה מהמחבר.

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

    gcloud compute firewall-rules create RULE_NAME \
--allow=PROTOCOL \
--source-tags=VPC_CONNECTOR_NETWORK_TAG \
--direction=INGRESS \
--network=VPC_NETWORK \
--target-tags=RESOURCE_TAG \
--priority=PRIORITY

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

    • ‫RULE_NAME: השם של כלל חומת האש החדש. לדוגמה, allow-vpc-connector-for-select-resources.

    • ‫PROTOCOL: פרוטוקול אחד או יותר שרוצים לאפשר ממחבר ה-VPC. הפרוטוקולים הנתמכים הם tcp או udp. לדוגמה, tcp:80,udp מאפשר תנועת TCP דרך יציאה 80 ותנועת UDP. מידע נוסף זמין במאמרי העזרה בנושא הדגל allow.

    • ‫VPC_CONNECTOR_NETWORK_TAG: תג הרשת של המחבר האוניברסלי, אם רוצים להגביל את הגישה לכל המחברים (כולל מחברים שייווצרו בעתיד), או תג הרשת הייחודי, אם רוצים להגביל את הגישה למחבר ספציפי. הוא צריך להתאים לתג הרשת שציינתם בשלב הקודם.

      • תג רשת אוניברסלי: vpc-connector

      • תג רשת ייחודי: vpc-connector-REGION-CONNECTOR_NAME

        מחליפים את:

        • ‫REGION: האזור של המחבר שרוצים להגביל
        • ‫CONNECTOR_NAME: שם המחבר שרוצים להגביל

      למידע נוסף על תגי רשת של מחברים, ראו תגי רשת.

    • ‫VPC_NETWORK: השם של רשת ה-VPC

    • ‫RESOURCE_TAG: תג הרשת של משאב ה-VPC שאליו רוצים שמחבר ה-VPC ייגש

    • ‫PRIORITY: מספר שלם שקטן מהעדיפות שהגדרתם בשלב הקודם. לדוגמה, אם הגדרתם את העדיפות של הכלל שיצרתם בשלב הקודם ל-990, נסו 980.

למידע נוסף על הדגלים הנדרשים והאופציונליים ליצירת כללים של חומת אש, קראו את המסמכים של gcloud compute firewall-rules create.

טווח CIDR

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

  1. חשוב לוודא שיש לכם את ההרשאות הנדרשות כדי להוסיף כללי חומת אש. צריך להיות לכם אחד מהתפקידים הבאים בניהול זהויות והרשאות גישה (IAM):

  2. דחיית תנועה של מחברים ברשת ה-VPC.

    ברשת ה-VPC, יוצרים כלל חומת אש לתעבורת נתונים נכנסת עם עדיפות נמוכה מ-1,000, כדי לדחות תעבורת נתונים נכנסת מטווח ה-CIDR של המחבר. הכלל הזה מבטל את כלל חומת האש המשתמע שנוצר כברירת מחדל ברשת ה-VPC על ידי החיבור לרשת (VPC) מאפליקציית serverless.

    gcloud compute firewall-rules create RULE_NAME \
--action=DENY \
--rules=PROTOCOL \
--source-ranges=VPC_CONNECTOR_CIDR_RANGE \
--direction=INGRESS \
--network=VPC_NETWORK \
--priority=PRIORITY

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

    • ‫RULE_NAME: השם של כלל חומת האש החדש. לדוגמה, deny-vpc-connector.

    • ‫PROTOCOL: פרוטוקול אחד או יותר שרוצים לאפשר ממחבר ה-VPC. הפרוטוקולים הנתמכים הם tcp או udp. לדוגמה, tcp:80,udp מאפשר תנועת TCP דרך יציאה 80 ותנועת UDP. מידע נוסף זמין במאמרי העזרה בנושא הדגל allow.

      למטרות אבטחה ואימות, אתם יכולים גם להגדיר כללי דחייה כדי לחסום תנועה בפרוטוקולים הבאים שלא נתמכים: ah,‏ all,‏ esp,‏ icmp,‏ ipip ו-sctp.

    • ‫VPC_CONNECTOR_CIDR_RANGE: טווח ה-CIDR של המחבר שהגישה אליו מוגבלת

    • ‫VPC_NETWORK: השם של רשת ה-VPC

    • ‫PRIORITY: מספר שלם בין 0 ל-65535. לדוגמה, הערך 0 מגדיר את העדיפות הגבוהה ביותר.

  3. מאפשרים תנועה מהמחבר למשאב שאמור לקבל תנועה מהמחבר.

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

    gcloud compute firewall-rules create RULE_NAME \
--allow=PROTOCOL \
--source-ranges=VPC_CONNECTOR_CIDR_RANGE \
--direction=INGRESS \
--network=VPC_NETWORK \
--target-tags=RESOURCE_TAG \
--priority=PRIORITY

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

    • ‫RULE_NAME: השם של כלל חומת האש החדש. לדוגמה, allow-vpc-connector-for-select-resources.

    • ‫PROTOCOL: פרוטוקול אחד או יותר שרוצים לאפשר ממחבר ה-VPC. הפרוטוקולים הנתמכים הם tcp או udp. לדוגמה, tcp:80,udp מאפשר תנועת TCP דרך יציאה 80 ותנועת UDP. מידע נוסף זמין במאמרי העזרה בנושא הדגל allow.

    • ‫VPC_CONNECTOR_CIDR_RANGE: טווח ה-CIDR של המחבר שאת הגישה שלו אתם מגבילים

    • ‫VPC_NETWORK: השם של רשת ה-VPC

    • ‫RESOURCE_TAG: תג הרשת של משאב ה-VPC שאליו רוצים שמחבר ה-VPC ייגש

    • ‫PRIORITY: מספר שלם שקטן מהעדיפות שהגדרתם בשלב הקודם. לדוגמה, אם הגדרתם את העדיפות של הכלל שיצרתם בשלב הקודם ל-990, נסו 980.

למידע נוסף על הדגלים הנדרשים והאופציונליים ליצירת כללים של חומת האש, קראו את המאמר בנושא gcloud compute firewall-rules create.

הגבלת הגישה באמצעות כללים לתעבורת נתונים יוצאת (egress)

כך יוצרים כללי תעבורת נתונים יוצאת כדי להגביל את הגישה למחבר:

  1. חשוב לוודא שיש לכם את ההרשאות הנדרשות כדי להוסיף כללי חומת אש. צריך להיות לכם אחד מהתפקידים הבאים בממשק ניהול הזהויות והרשאות הגישה (IAM):

  2. דחיית תעבורת נתונים יוצאת מהמחבר.

    יוצרים כלל של חומת אש לתעבורת נתונים יוצאת במחבר של Serverless VPC Access, כדי למנוע ממנו לשלוח תעבורת נתונים יוצאת לכל יעד, למעט תגובות מבוססות.

    gcloud compute firewall-rules create RULE_NAME \
--action=DENY \
--rules=PROTOCOL \
--direction=EGRESS \
--target-tags=VPC_CONNECTOR_NETWORK_TAG \
--network=VPC_NETWORK \
--priority=PRIORITY

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

    • ‫RULE_NAME: השם של כלל חומת האש החדש. לדוגמה, deny-vpc-connector.

    • ‫PROTOCOL: פרוטוקול אחד או יותר שרוצים לאפשר ממחבר ה-VPC. הפרוטוקולים הנתמכים הם tcp או udp. לדוגמה, tcp:80,udp מאפשר תנועת TCP דרך יציאה 80 ותנועת UDP. מידע נוסף זמין במאמרי העזרה בנושא הדגל allow.

      למטרות אבטחה ואימות, אתם יכולים גם להגדיר כללי דחייה כדי לחסום תנועה בפרוטוקולים הבאים שלא נתמכים: ah,‏ all,‏ esp,‏ icmp,‏ ipip ו-sctp.

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

    • ‫VPC_NETWORK: השם של רשת ה-VPC

    • ‫PRIORITY: מספר שלם בין 0 ל-65535. לדוגמה, הערך 0 מגדיר את העדיפות הגבוהה ביותר.

  3. מאפשרים תנועה יוצאת כשהיעד נמצא בטווח ה-CIDR שאליו רוצים שהמחבר ייגש.

    משתמשים בדגלים allow ו-destination-ranges כדי ליצור כלל חומת אש שמאפשר תעבורת נתונים יוצאת מהמחבר לטווח יעדים ספציפי. מגדירים את טווח היעד לטווח ה-CIDR של המשאב ברשת ה-VPC שאליו רוצים שהמחבר יוכל לגשת. מגדירים את העדיפות של הכלל הזה לערך נמוך יותר מהעדיפות של הכלל שיצרתם בשלב הקודם.

    gcloud compute firewall-rules create RULE_NAME \
--allow=PROTOCOL \
--destination-ranges=RESOURCE_CIDR_RANGE \
--direction=EGRESS \
--network=VPC_NETWORK \
--target-tags=VPC_CONNECTOR_NETWORK_TAG \
--priority=PRIORITY

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

    • ‫RULE_NAME: השם של כלל חומת האש החדש. לדוגמה, allow-vpc-connector-for-select-resources.

    • ‫PROTOCOL: פרוטוקול אחד או יותר שרוצים לאפשר ממחבר ה-VPC. הפרוטוקולים הנתמכים הם tcp או udp. לדוגמה, tcp:80,udp מאפשר תנועת TCP דרך יציאה 80 ותנועת UDP. מידע נוסף זמין במאמרי העזרה בנושא הדגל allow.

    • ‫RESOURCE_CIDR_RANGE: טווח ה-CIDR של המחבר שהגישה אליו מוגבלת

    • ‫VPC_NETWORK: השם של רשת ה-VPC

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

    • ‫PRIORITY: מספר שלם שקטן מהעדיפות שהגדרתם בשלב הקודם. לדוגמה, אם הגדרתם את העדיפות של הכלל שיצרתם בשלב הקודם ל-990, נסו 980.

למידע נוסף על הדגלים הנדרשים והאופציונליים ליצירת כללים של חומת אש, קראו את המסמכים של gcloud compute firewall-rules create.

עדכון מחבר

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

  • סוג המכונה (המכונה הווירטואלית)
  • מספר מינימלי ומקסימלי של מכונות
  • קצב העברת הנתונים, מספר המכונות וניצול המעבד (CPU) לאחרונה

עדכון סוג המכונה

המסוף

  1. נכנסים לדף הסקירה הכללית של Serverless VPC Access.

    כניסה לדף Serverless VPC Access

  2. בוחרים את המחבר שרוצים לערוך ולוחצים על עריכה.

  3. ברשימה Instance type, בוחרים את סוג המכונה (המכונה הווירטואלית) הרצוי. למידע על סוגי המכונות הזמינים, קראו את המאמר קצב העברת נתונים ושינוי קנה מידה.

gcloud

  1. מפעילים את Cloud Shell במסוף Google Cloud .

    הפעלת Cloud Shell

    בחלק התחתון של מסוף Google Cloud יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.

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

    gcloud beta compute networks vpc-access connectors update CONNECTOR_NAME --region=REGION --machine-type=MACHINE_TYPE
     מחליפים את הערכים בשדות הבאים:

הקטנת המספר המינימלי והמקסימלי של המכונות

כדי להקטין את המספר המינימלי והמקסימלי של המכונות:

  1. יוצרים מחבר חדש עם הערכים הרצויים.
  2. מעדכנים את השירות או הפונקציה כדי להשתמש במחבר החדש.
  3. מוחקים את המחבר הישן אחרי שמעבירים את התנועה שלו.

הגדלת המספר המינימלי והמקסימלי של המכונות

המסוף

  1. נכנסים לדף הסקירה הכללית של Serverless VPC Access.

    כניסה לדף Serverless VPC Access

  2. בוחרים את המחבר שרוצים לערוך ולוחצים על עריכה.

  3. בשדה Minimum instances, בוחרים את המספר המינימלי הרצוי של מכונות.

    הערך הקטן ביותר שאפשר להזין בשדה הזה הוא הערך הנוכחי. הערך המקסימלי שאפשר להזין בשדה הזה הוא הערך הנוכחי בשדה Maximum instances פחות 1. לדוגמה, אם הערך בשדה Maximum instances הוא 8, הערך הגבוה ביותר שאפשר להזין בשדה Minimum instances הוא 7.

  4. בשדה Maximum instances, בוחרים את המספר המקסימלי הרצוי של מכונות.

    הערך הקטן ביותר שאפשר להזין בשדה הזה הוא הערך הנוכחי. הערך המקסימלי שאפשר להזין בשדה הזה הוא 10.

gcloud

  1. מפעילים את Cloud Shell במסוף Google Cloud .

    הפעלת Cloud Shell

    בחלק התחתון של מסוף Google Cloud יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.

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

    gcloud beta compute networks vpc-access connectors update CONNECTOR_NAME --region=REGION --min-instances=MIN_INSTANCES --max-instances=MAX_INSTANCES
     מחליפים את הערכים בשדות הבאים:

  • ‫CONNECTOR_NAME: השם של המחבר
  • ‫REGION: שם האזור של המחבר
  • ‫MIN_INSTANCES: המספר המינימלי המועדף של המכונות.
    • הערך הקטן ביותר שאפשר להזין בשדה הזה הוא הערך הנוכחי של min_instances. כדי למצוא את הערך הנוכחי, עיינו בקטע חיפוש ערכי המאפיינים הנוכחיים.
    • הערך הגדול ביותר שאפשר להזין בשדה הזה הוא הערך הנוכחי של max_instances פחות 1, כי הערך של min_instances חייב להיות קטן מהערך של max_instances. לדוגמה, אם הערך של max_instances הוא 8, הערך המקסימלי האפשרי בשדה הזה הוא 7. אם המחבר משתמש בערך ברירת המחדל של max-instances, שהוא 10, הערך הגדול ביותר האפשרי בשדה הזה הוא 9. כדי למצוא את הערך של max-instances, עיינו בקטע חיפוש ערכי המאפיינים הנוכחיים.

  • MAX_INSTANCES:

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

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

איך למצוא את ערכי המאפיינים הנוכחיים

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

gcloud compute networks vpc-access connectors describe CONNECTOR_NAME --region=REGION --project=PROJECT
 מחליפים את הערכים בשדות הבאים:

  • ‫CONNECTOR_NAME: השם של המחבר
  • ‫REGION: שם האזור של המחבר
  • ‫PROJECT: שם הפרויקט ב- Google Cloud

מעקב אחרי השימוש במחברים

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

כדי להציג תרשימים של מדדי התפוקה, מספר המכונות וניצול המעבד (CPU) של המחבר לאורך זמן באמצעות מסוף Google Cloud :

  1. נכנסים לדף הסקירה הכללית של Serverless VPC Access.

    כניסה לדף Serverless VPC Access

  2. לוחצים על שם המחבר שרוצים לעקוב אחריו.

  3. בוחרים את מספר הימים שרוצים להציג, בין יום אחד ל-90 ימים.

  4. בתרשים Throughput, מעבירים את הסמן מעל התרשים כדי לראות את קצב הנתונים האחרון של המחבר.

  5. בתרשים Number of instances, מעבירים את העכבר מעל התרשים כדי לראות את מספר המכונות שהמחבר השתמש בהן לאחרונה.

  6. בתרשים CPU Utilization, מציבים את הסמן מעל התרשים כדי לראות את השימוש האחרון של המחבר במעבד. בתרשים מוצג השימוש ב-CPU שמתחלק בין המכונות באחוזונים ה-50, ה-95 וה-99.

מחיקת מחבר

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

משתמשי VPC משותף שמגדירים מחברים בפרויקט המארח של ה-VPC המשותף יכולים להשתמש בפקודה gcloud compute networks vpc-access connectors describe כדי להציג את רשימת הפרויקטים שבהם יש משאבים ללא שרת (serverless) שמשתמשים במחבר נתון.

כדי למחוק מחבר, משתמשים במסוף Google Cloud או ב-Google Cloud CLI:

המסוף

  1. נכנסים לדף הסקירה הכללית של Serverless VPC Access במסוףGoogle Cloud :

    כניסה לדף Serverless VPC Access

  2. בוחרים את המחבר שרוצים למחוק.

  3. לוחצים על Delete.

gcloud

  1. מפעילים את Cloud Shell במסוף Google Cloud .

    הפעלת Cloud Shell

    בחלק התחתון של מסוף Google Cloud יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.

  2. כדי למחוק מחבר, משתמשים בפקודה הבאה של gcloud:

    gcloud compute networks vpc-access connectors delete CONNECTOR_NAME --region=REGION

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

    • ‫CONNECTOR_NAME בשם של המחבר שרוצים למחוק.
    • REGION באזור שבו נמצא המחבר.

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

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

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

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

יתרונות

חיבור לרשת (VPC) מאפליקציית serverless מאפשר לכם לכתוב מספר כלשהו של אילוצים בהתאמה אישית, באמצעות רוב השדות שמוגדרים על ידי המשתמש ב-Serverless VPC Access API. לדוגמה, אתם יכולים ליצור אילוץ בהתאמה אישית שמציין באילו רשתות משנה אפשר להשתמש במחבר של חיבור לרשת (VPC) מאפליקציית serverless.

אחרי שמחילים את האילוץ, בקשות שמפירות מדיניות שאוכפת אילוץ בהתאמה אישית מציגות הודעת שגיאה ב-CLI של gcloud וביומנים של "גישה ל-VPC ללא שרת (Serverless)". הודעת השגיאה מכילה את מזהה האילוץ ואת התיאור של האילוץ המותאם אישית שהופר.

ירושה של מדיניות

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

מגבלות

אי אפשר לציין סוג מכונה, מספר מינימלי של מכונות או מספר מקסימלי של מכונות.

לפני שמתחילים

חשוב לוודא שאתם יודעים מהו מזהה הארגון שלכם.

התפקידים הנדרשים

כדי לקבל את ההרשאות שדרושות לניהול מדיניות הארגון, בקשו מהאדמין להקצות לכם את התפקיד אדמין של מדיניות הארגון (roles/orgpolicy.policyAdmin) ב-IAM במשאב הארגון. כדי לקרוא הסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

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

יצירת אילוץ בהתאמה אישית

אילוץ מותאם אישית מוגדר בקובץ YAML לפי המשאבים, השיטות, התנאים והפעולות שנתמכים בשירות שבו אתם אוכפים את מדיניות הארגון. התנאים של האילוצים המותאמים אישית מוגדרים באמצעות Common Expression Language (CEL). בקטע CEL במאמר יצירה וניהול של אילוצים בהתאמה אישית מוסבר איך ליצור תנאים באילוצים בהתאמה אישית באמצעות CEL.

כדי ליצור קובץ YAML לאילוץ בהתאמה אישית של חיבור לרשת (VPC) מאפליקציית serverless, אפשר להיעזר בדוגמה הבאה:

name: organizations/ORGANIZATION_ID/customConstraints/CONSTRAINT_NAME
resourceTypes:
- vpcaccess.googleapis.com/Connector
methodTypes:
- CREATE
condition: "CONDITION"
actionType: ACTION
displayName: DISPLAY_NAME
description: DESCRIPTION

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

  • ‫ORGANIZATION_ID: מזהה הארגון, למשל 123456789.

  • ‫CONSTRAINT_NAME: השם שרוצים לתת לאילוץ המותאם אישית החדש. אילוץ בהתאמה אישית חייב להתחיל ב-custom., ויכול לכלול רק אותיות רישיות, אותיות קטנות או מספרים, לדוגמה, custom.defaultNetworkConstraint. האורך המקסימלי של השדה הזה הוא 70 תווים, לא כולל הקידומת.

  • ‫CONDITION: תנאי CEL שנכתב כנגד ייצוג של משאב שירות נתמך. האורך המקסימלי של השדה הזה הוא 1,000 תווים. לדוגמה: "resource.network == default".

  • ‫ACTION: הפעולה שצריך לבצע אם מתקיים התנאי condition. הערך יכול להיות ALLOW או DENY.

  • ‫DISPLAY_NAME: שם קריא לאנשים של האילוץ. האורך המקסימלי של השדה הזה הוא 200 תווים.

  • ‫DESCRIPTION: תיאור קריא של האילוץ שיוצג כהודעת שגיאה במקרה של הפרת המדיניות, לדוגמה, "Require network to not be set to default.". האורך המקסימלי של השדה הזה הוא 2,000 תווים.

למידע נוסף על יצירת אילוץ בהתאמה אישית, ראו הגדרת אילוצים בהתאמה אישית.

הגדרת אילוץ בהתאמה אישית

המסוף

כדי ליצור אילוץ בהתאמה אישית:

  1. במסוף Google Cloud , נכנסים לדף מדיניות הארגון.

    כניסה לדף Organization policies

  2. בכלי לבחירת פרויקטים, בוחרים את הפרויקט שרוצים להגדיר לו את מדיניות הארגון.
  3. לוחצים על Custom constraint.
  4. בתיבה Display name, מזינים שם לאילוץ שיהיה קריא לאנשים. השם הזה מופיע בהודעות שגיאה ואפשר להשתמש בו לזיהוי ולניפוי באגים. אל תשתמשו בפרטים אישיים מזהים (PII) או במידע רגיש בשמות לתצוגה, כי השם הזה עלול להיחשף בהודעות שגיאה. השדה הזה יכול להכיל עד 200 תווים.
  5. בתיבה Constraint ID, מזינים את המזהה שרוצים לתת לאילוץ החדש בהתאמה אישית. אילוץ בהתאמה אישית יכול להכיל רק אותיות (כולל אותיות רישיות וקטנות) או מספרים, לדוגמה custom.defaultNetworkConstraint. השדה הזה יכול להכיל עד 70 תווים, לא כולל הקידומת (custom.), לדוגמה, organizations/123456789/customConstraints/custom. אל תכללו פרטים אישיים מזהים (PII) או מידע רגיש במזהה האילוץ, כי הם עלולים להיחשף בהודעות שגיאה.
  6. בתיבה Description, מזינים תיאור קריא לאנשים של האילוץ. התיאור הזה משמש כהודעת שגיאה כשיש הפרה של המדיניות. ציינו פרטים על הסיבה להפרת המדיניות ואיך לפתור את הבעיה. אל תכללו פרטים אישיים מזהים (PII) או מידע רגיש בתיאור, כי הם עלולים להיחשף בהודעות שגיאה. השדה הזה יכול להכיל עד 2,000 תווים.
  7. בתיבה Resource type, בוחרים את השם של משאב ה- Google Cloud REST שמכיל את האובייקט והשדה שרוצים להגביל, לדוגמה container.googleapis.com/NodePool. רוב סוגי המשאבים תומכים בעד 20 אילוצים בהתאמה אישית. אם תנסו ליצור יותר אילוצים בהתאמה אישית, הפעולה תיכשל.
  8. אפשר לאכוף את האילוץ הזה רק ב-REST CREATE.

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

  9. כדי להגדיר תנאי, לוחצים על עריכת התנאי.
    1. בחלונית Add condition, יוצרים תנאי CEL שמתייחס למשאב שירות נתמך, לדוגמה resource.management.autoUpgrade == false. השדה הזה יכול להכיל עד 1,000 תווים. לפרטים על השימוש ב-CEL, קראו את המאמר Common Expression Language. מידע נוסף על משאבי השירות שבהם אפשר להשתמש באילוצים מותאמים אישית מופיע במאמר שירותים שנתמכים באילוצים מותאמים אישית.
    2. לוחצים על Save.
  10. בקטע Action, בוחרים אם לאשר או לדחות את השיטה שנבדקה אם התנאי מתקיים.

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

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

  11. לוחצים על Create constraint.

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

gcloud

  1. כדי ליצור אילוץ בהתאמה אישית, יוצרים קובץ YAML בפורמט הבא: 
    2. name: organizations/ORGANIZATION_ID/customConstraints/CONSTRAINT_NAME
resourceTypes: RESOURCE_NAME
methodTypes:
  - CREATE
condition: "CONDITION"
actionType: ACTION
displayName: DISPLAY_NAME
description: DESCRIPTION

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

    • ‫ORGANIZATION_ID: מזהה הארגון, למשל 123456789.
    • ‫CONSTRAINT_NAME: השם שרוצים לתת לאילוץ החדש בהתאמה אישית. אילוץ בהתאמה אישית יכול להכיל רק אותיות (כולל אותיות רישיות וקטנות) או מספרים, לדוגמה, custom.defaultNetworkConstraint. השדה הזה יכול להכיל עד 70 תווים, לא כולל הקידומת (custom.) – לדוגמה, organizations/123456789/customConstraints/custom. אל תכללו פרטים אישיים מזהים (PII) או מידע רגיש במזהה האילוץ, כי הם עלולים להיחשף בהודעות שגיאה.
    • ‫RESOURCE_NAME: השם המלא של המשאב ב- Google Cloudשמכיל את האובייקט והשדה שרוצים להגביל. לדוגמה, vpcaccess.googleapis.com/Connector. רוב סוגי המשאבים תומכים בעד 20 אילוצים בהתאמה אישית. אם תנסו ליצור יותר אילוצים בהתאמה אישית, הפעולה תיכשל.
    • ‫methodTypes: שיטות ה-REST שעליהן נאכף האילוץ. הערך יכול להיות רק CREATE.

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

    • ‫CONDITION: תנאי CEL שנכתב כנגד ייצוג של משאב שירות נתמך. השדה הזה יכול להכיל עד 1,000 תווים. לדוגמה, "resource.network == default".

      • למידע נוסף על המשאבים הזמינים לכתיבת תנאים, ראו משאבים נתמכים.

    • ‫ACTION: הפעולה שצריך לבצע אם התנאי condition מתקיים. הערך יכול להיות רק ALLOW.

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

    • ‫DISPLAY_NAME: שם קריא לאנשים של האילוץ. השם הזה מופיע בהודעות שגיאה ואפשר להשתמש בו לזיהוי ולניפוי באגים. אל תשתמשו בפרטים אישיים מזהים (PII) או במידע רגיש בשמות המוצגים, כי השם הזה עלול להיחשף בהודעות שגיאה. השדה הזה יכול להכיל עד 200 תווים.
    • ‫DESCRIPTION: תיאור ידידותי למשתמש של האילוץ, שיוצג כהודעת שגיאה במקרה של הפרת המדיניות. השדה הזה יכול להכיל עד 2,000 תווים.
  2. אחרי שיוצרים את קובץ ה-YAML לאילוץ חדש בהתאמה אישית, צריך להגדיר אותו כדי שיהיה זמין למדיניות הארגון. כדי להגדיר אילוץ בהתאמה אישית, משתמשים בפקודה gcloud org-policies set-custom-constraint: 
    3. gcloud org-policies set-custom-constraint CONSTRAINT_PATH

    מחליפים את CONSTRAINT_PATH בנתיב המלא לקובץ האילוץ בהתאמה אישית. לדוגמה, /home/user/customconstraint.yaml.

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

  3. כדי לוודא שהאילוץ המותאם אישית קיים, משתמשים בפקודה gcloud org-policies list-custom-constraints: 
    4. gcloud org-policies list-custom-constraints --organization=ORGANIZATION_ID

    מחליפים את ORGANIZATION_ID במזהה של משאב הארגון.

    למידע נוסף, קראו את המאמר הצגת מדיניות הארגון.

אכיפה של אילוץ בהתאמה אישית

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

המסוף

  1. במסוף Google Cloud , נכנסים לדף מדיניות הארגון.

    כניסה לדף Organization policies

  2. בכלי לבחירת פרויקטים, בוחרים את הפרויקט שרוצים להגדיר לו את מדיניות הארגון.
  3. ברשימה שבדף מדיניות הארגון, בוחרים את האילוץ כדי להציג את הדף Policy details של אותו אילוץ.
  4. כדי להגדיר את מדיניות הארגון למשאב הזה, לוחצים על ניהול המדיניות.
  5. בדף עריכת המדיניות, בוחרים באפשרות במקום המדיניות של המשאב הראשי.
  6. לוחצים על Add a rule.
  7. בקטע Enforcement, בוחרים אם לאכוף את מדיניות הארגון הזו או לא.
  8. אופציונלי: כדי להוסיף תנאי למדיניות הארגון על סמך תג, לוחצים על Add condition. שימו לב: אם מוסיפים כלל מותנה למדיניות הארגון, צריך להוסיף לפחות כלל אחד לא מותנה, אחרת אי אפשר לשמור את המדיניות. מידע נוסף מופיע במאמר הגדרת ההיקף של מדיניות הארגון באמצעות תגים.
  9. לוחצים על בדיקת השינויים כדי לדמות את ההשפעה של מדיניות הארגון. מידע נוסף זמין במאמר בדיקת שינויים במדיניות הארגון באמצעות סימולטור המדיניות.
  10. כדי לאכוף את מדיניות הארגון במצב פרימטר לבדיקות, לוחצים על הגדרת המדיניות להרצת בדיקה. למידע נוסף, קראו את המאמר בדיקת כללי מדיניות של הארגון.
  11. אחרי שמוודאים שמדיניות הארגון במצב פרימטר לבדיקות פועלת כמו שצריך, לוחצים על Set policy כדי להגדיר את המדיניות הפעילה.

gcloud

  1. כדי ליצור מדיניות ארגונית עם כללים בוליאניים, יוצרים קובץ YAML של מדיניות שמפנה לאילוץ: 
    2. name: projects/PROJECT_ID/policies/CONSTRAINT_NAME
spec:
  rules:
  - enforce: true

dryRunSpec:
  rules:
  - enforce: true

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

    • ‫PROJECT_ID: הפרויקט שבו רוצים לאכוף את האילוץ.
    • ‫CONSTRAINT_NAME: השם שהגדרתם לאילוץ המותאם אישית. לדוגמה, custom.defaultNetworkConstraint.
  2. כדי לאכוף את מדיניות הארגון במצב פרימטר לבדיקות, מריצים את הפקודה הבאה עם הדגל dryRunSpec: 
    3. gcloud org-policies set-policy POLICY_PATH --update-mask=dryRunSpec

    מחליפים את POLICY_PATH בנתיב המלא לקובץ ה-YAML של מדיניות הארגון. המדיניות תיכנס לתוקף תוך 15 דקות לכל היותר.

  3. אחרי שמוודאים שמדיניות הארגון במצב פרימטר לבדיקות פועלת כמצופה, מגדירים את המדיניות הפעילה באמצעות הפקודה org-policies set-policy והדגל spec: 
    4. gcloud org-policies set-policy POLICY_PATH --update-mask=spec

    מחליפים את POLICY_PATH בנתיב המלא לקובץ ה-YAML של מדיניות הארגון. המדיניות תיכנס לתוקף תוך 15 דקות לכל היותר.

בדיקת האילוץ המותאם אישית

כדי לבדוק את הדוגמה שמגבילה את הגדרות התעבורה הנכנסת, פורסים מחבר בפרויקט כשהרשת מוגדרת ל-default:

gcloud compute networks vpc-access connectors create org-policy-test \
    --project=PROJECT_ID \
    --region=REGION_ID \
    --network=default

הפלט שיתקבל:

Operation denied by custom org policies: ["customConstraints/custom.defaultNetworkConstraint": "Require network to not be set to default."]

דוגמאות למדיניות ארגונית בהתאמה אישית לתרחישים נפוצים

בטבלה הבאה מפורטות דוגמאות לאילוצים בהתאמה אישית שיכולים להיות שימושיים לחיבורים לרשת VPC ללא שרת:

תיאור תחביר של אילוצים
דרישה שמחברי חיבור לרשת VPC יוכלו להשתמש רק ברשת ספציפית. 
    name: organizations/ORGANIZATION_ID/customConstraints/custom.allowlistNetworks
    resourceTypes:
    - vpcaccess.googleapis.com/Connector
    methodTypes:
    - CREATE
    condition: "resource.network == 'allowlisted-network'"
    actionType: ALLOW
    displayName: allowlistNetworks
    description: Require connectors to use a specific network.
תיאור תחביר של אילוצים
לדרוש שלמחברים של חיבור לרשת (VPC) מאפליקציית serverless תהיה גישה רק לרשת משנה ספציפית. 
    name: organizations/ORGANIZATION_ID/customConstraints/custom.restrictSubnetForProject
    resourceTypes:
    - vpcaccess.googleapis.com/Connector
    methodTypes:
    - CREATE
    condition: "resource.subnet.name == 'allocated-subnet'"
    actionType: ALLOW
    displayName: restrictSubnetForProject
    description: This project is only allowed to use the subnet "allocated-subnet".

הגדרת סביבת Cloud Run לשימוש ב-Direct VPC במקום במחבר

אתם יכולים להפעיל את שירות Cloud Run כדי לשלוח תעבורת נתונים יוצאת (egress) ישירות לרשת VPC, וכך לאפשר גישה למכונות וירטואליות של Compute Engine, למכונות של Memorystore ולכל משאב אחר עם כתובת IP פנימית.

הגדרת השירות לשימוש ב-Direct VPC

Direct VPC egress מאפשר לשירות Cloud Run לשלוח תעבורת נתונים לרשת VPC בלי מחבר של חיבור לרשת (VPC) מאפליקציית serverless. עלויות הרשת מצטמצמות לאפס, בדיוק כמו השירות עצמו. אפשר גם להוסיף תגי רשת ישירות לגרסאות של שירות Cloud Run כדי לשפר את אבטחת הרשת, למשל על ידי החלת כללי חומת אש של VPC.

אפשר להגדיר Direct VPC egress עם שירות באמצעות מסוףGoogle Cloud ,‏ Google Cloud CLI,‏ YAML או Terraform.

המסוף

  1. נכנסים ל-Cloud Run במסוף Google Cloud :

    כניסה ל-Cloud Run

  2. בתפריט הניווט של Cloud Run, לוחצים על Services:

    1. אם אתם מגדירים שירות חדש, לוחצים על Deploy container וממלאים את דף הגדרות השירות הראשוני. לאחר מכן לוחצים על Containers, Networking, Security כדי להרחיב את דף הגדרת השירות.

    2. אם אתם מגדירים שירות קיים, לוחצים על השירות.

  3. נכנסים לכרטיסייה Networking.

  4. לוחצים על Connect to a VPC for outbound traffic.

  5. לוחצים על שליחת תנועה ישירות ל-VPC.

  6. בשדה Network, בוחרים את רשת ה-VPC שאליה רוצים לשלוח את התנועה.

  7. בשדה Subnet, בוחרים את רשת המשנה שממנה השירות מקבל כתובות IP. אפשר לפרוס כמה שירותים באותה רשת משנה.

  8. אופציונלי: מזינים את השמות של תגי הרשת שרוצים לשייך לשירות או לשירותים. תגי רשת מצוינים ברמת הגרסה. לכל גרסה של שירות יכולים להיות תגי רשת שונים, כמו network-tag-2.

  9. בקטע Traffic routing, בוחרים אחת מהאפשרויות הבאות:

    • Route only requests to private IPs to the VPC כדי לשלוח רק תנועה לכתובות פנימיות דרך רשת ה-VPC.
    • ‫Route all traffic to the VPC כדי לשלוח את כל תעבורת הנתונים היוצאת דרך רשת ה-VPC.

  10. כדי ליצור שירות חדש, לוחצים על יצירה. לוחצים על View diff & redeploy ואז על Deploy changes בשירות קיים.

  11. כדי לוודא שהשירות נמצא ברשת ה-VPC, לוחצים על השירות ואז על הכרטיסייה Networking. הרשת ורשת המשנה מופיעות בכרטיס VPC.

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

gcloud

שירות

כדי לפרוס שירות Cloud Run בלי מחבר מ-Google Cloud CLI:

  1. מעדכנים את הרכיבים של gcloud לגרסה העדכנית:

    gcloud components update

  2. מוודאים שה-Compute Engine API מופעל בפרויקט:

    gcloud services enable compute.googleapis.com

  3. פורסים את שירות Cloud Run באמצעות הפקודה הבאה:

    gcloud run deploy SERVICE_NAME \
    --image=IMAGE_URL \
    --network=NETWORK \
    --subnet=SUBNET \
    --network-tags=NETWORK_TAG_NAMES \
    --vpc-egress=EGRESS_SETTING \
    --region=REGION

    מחליפים את:

    • ‫SERVICE_NAME בשם של שירות Cloud Run.
    • IMAGE_URLus-docker.pkg.dev/cloudrun/container/hello:latest. אם משתמשים ב-Artifact Registry, צריך כבר ליצור את המאגר REPO_NAME. כתובת ה-URL היא בפורמט LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG
    • ‫NETWORK בשם של רשת ה-VPC. מציינים רשת VPC או רשת משנה, או את שתיהן. אם מציינים רק רשת, לרשת המשנה יהיה אותו שם כמו לרשת.
    • ‫SUBNET בשם של רשת המשנה. רשת המשנה חייבת להיות בגודל /26 או יותר. תעבורת נתונים יוצאת ישירה ל-VPC תומכת בטווחי IPv4 מסוג RFC 1918, RFC 6598 ו-Class E. אפשר לפרוס או להריץ כמה שירותים או משימות באותה רשת משנה, אבל אי אפשר לשתף את רשת המשנה עם מחברים קיימים.
    • אופציונלי: NETWORK_TAG_NAMES עם השמות של תגי הרשת שרוצים לשייך לשירות, מופרדים בפסיקים. בשירותים, תגי הרשת מצוינים ברמת הגרסה. לכל גרסה של שירות יכולים להיות תגי רשת שונים, כמו network-tag-2.
    • ‫EGRESS_SETTING עם ערך הגדרת תעבורת נתונים יוצאת:
      • ‫all-traffic: כל התנועה היוצאת נשלחת דרך רשת ה-VPC.
      • ‫private-ranges-only: שליחת תנועה רק לכתובות פנימיות דרך רשת ה-VPC.
    • ‫REGION באזור של השירות.

  4. כדי לוודא שהשירות נמצא ברשת ה-VPC, מריצים את הפקודה הבאה:

    gcloud run services describe SERVICE_NAME \
    --region=REGION

    מחליפים את:

    • SERVICE_NAME בשם של השירות.
    • ‫REGION באזור של השירות שציינתם בשלב הקודם.

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

    VPC access:
  Network:       default
  Subnet:        subnet
  Egress:        private-ranges-only

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

תפקיד

כדי לפרוס פונקציית Cloud Run בלי מחבר מ-Google Cloud CLI:

  1. מעדכנים את הרכיבים של gcloud לגרסה העדכנית:

    gcloud components update

  2. מוודאים שה-API של Compute Engine מופעל בפרויקט:

    gcloud services enable compute.googleapis.com

  3. פורסים את פונקציית Cloud Run באמצעות הפקודה הבאה:

    gcloud run deploy FUNCTION_NAME \
    --image=IMAGE_URL \
    --network=NETWORK \
    --subnet=SUBNET \
    --network-tags=NETWORK_TAG_NAMES \
    --vpc-egress=EGRESS_SETTING \
    --region=REGION \
    --function=FUNCTION_ENTRYPOINT

    מחליפים את:

    • ‫FUNCTION_NAME בשם של פונקציית Cloud Run.
    • IMAGE_URLus-docker.pkg.dev/cloudrun/container/hello:latest. אם משתמשים ב-Artifact Registry, צריך כבר ליצור את המאגר REPO_NAME. כתובת ה-URL היא בפורמט LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG
    • ‫NETWORK בשם של רשת ה-VPC. מציינים רשת VPC או רשת משנה, או את שתיהן. אם מציינים רק רשת, לרשת המשנה יהיה אותו שם כמו לרשת.
    • ‫SUBNET בשם של רשת המשנה. רשת המשנה חייבת להיות בגודל /26 או יותר. תעבורת נתונים יוצאת ב-Direct VPC תומכת בטווחי IPv4 מסוג RFC 1918,‏ RFC 6598 ו-Class E. אפשר לפרוס או להריץ כמה שירותים או משימות באותה רשת משנה, אבל אי אפשר לשתף את רשת המשנה עם מחברים קיימים.
    • ‫NETWORK_TAG_NAMES (אופציונלי): השמות של תגי הרשת שרוצים לשייך לפונקציה, מופרדים בפסיקים. בפונקציות, תגי הרשת מצוינים ברמת הגרסה. לכל גרסה יכולים להיות תגי רשת שונים, כמו network-tag-2.
    • ‫EGRESS_SETTING עם ערך הגדרת תעבורת נתונים יוצאת:
      • ‫all-traffic: כל התנועה היוצאת נשלחת דרך רשת ה-VPC.
      • ‫private-ranges-only: שליחת תנועה רק לכתובות פנימיות דרך רשת ה-VPC.
    • ‫REGION באזור של הפונקציה.
    • אופציונלי: FUNCTION_ENTRYPOINT עם נקודת הכניסה לפונקציה בקוד המקור. זה הקוד ש-Cloud Run מריץ כשהפונקציה פועלת. הערך של הדגל הזה חייב להיות שם פונקציה או שם מחלקה שמוגדר במלואו וקיים בקוד המקור.

  4. כדי לוודא שהפונקציה נמצאת ברשת ה-VPC, מריצים את הפקודה הבאה:

    gcloud run services describe FUNCTION_NAME \
    --region=REGION

    מחליפים את:

    • FUNCTION_NAME בשם של הפונקציה.
    • ‫REGION באזור של הפונקציה שציינתם בשלב הקודם.

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

    VPC access:
  Network:       default
  Subnet:        subnet
  Egress:        private-ranges-only

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

YAML

  1. אם אתם יוצרים שירות חדש, דלגו על השלב הזה. אם אתם מעדכנים שירות קיים, הורידו את הגדרת ה-YAML שלו:

    gcloud run services describe SERVICE --format export > service.yaml

  2. מעדכנים את המאפיינים הבאים:

    apiVersion: serving.knative.dev/v1
  kind: Service
  metadata:
    name: SERVICE_NAME
    labels:
      cloud.googleapis.com/location: REGION
  spec:
    template:
      metadata:
        annotations:
          run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET","tags":"NETWORK_TAG_NAMES"}]'
          run.googleapis.com/vpc-access-egress: EGRESS_SETTING
      spec:
        containers:
        - image: IMAGE

    מחליפים את:

    • ‫SERVICE_NAME בשם של שירות Cloud Run. שמות השירותים צריכים להיות באורך של עד 49 תווים, וייחודיים לכל אזור ופרויקט.
    • ‫REGION מחליפים באזור של שירות Cloud Run, שצריך להיות זהה לאזור של רשת המשנה.
    • ‫NETWORK בשם של רשת ה-VPC. מציינים רשת VPC או רשת משנה, או את שתיהן. אם מציינים רק רשת, לרשת המשנה יהיה אותו שם כמו לרשת.
    • ‫SUBNET בשם של רשת המשנה. רשת המשנה חייבת להיות בגודל /26 או יותר. תעבורת נתונים יוצאת (egress) ב-Direct VPC תומכת בטווחי IPv4 מסוג RFC 1918,‏ RFC 6598 ו-Class E. אפשר לפרוס או להריץ כמה שירותים או משימות באותה רשת משנה, אבל אי אפשר לשתף את רשת המשנה עם מחברים קיימים.
    • אופציונלי: NETWORK_TAG_NAMES עם השמות של תגי הרשת שרוצים לשייך לשירות. בשירותים, תגי הרשת מצוינים ברמת הגרסה. לכל גרסה של שירות יכולים להיות תגי רשת שונים, כמו network-tag-2.
    • ‫EGRESS_SETTING עם ערך הגדרת תעבורת נתונים יוצאת:
      • ‫all-traffic: כל התנועה היוצאת נשלחת דרך רשת ה-VPC.
      • ‫private-ranges-only: שליחת תנועה רק לכתובות פנימיות דרך רשת ה-VPC.
    • ‫IMAGE בכתובת ה-URL של קובץ האימג' של הקונטיינר של השירות.

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

  3. יוצרים או מעדכנים את השירות באמצעות הפקודה הבאה:

    gcloud run services replace service.yaml

Terraform

כדי ללמוד איך להחיל הגדרות ב-Terraform או להסיר אותן, ראו פקודות בסיסיות ב-Terraform.

  1. מוסיפים לקובץ main.tf את הנתונים הבאים:

    /**
 * Copyright 2024 Google LLC
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

# Example configuration of a Cloud Run service with direct VPC

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service"
  location = "us-central1"

  deletion_protection = false # set to "true" in production

  template {
    containers {
      image = "us-docker.pkg.dev/cloudrun/container/hello"
    }
    vpc_access {
      network_interfaces {
        network    = "default"
        subnetwork = "default"
        tags       = ["tag1", "tag2", "tag3"]
      }
    }
  }
}

אם רוצים לאפשר גישה לשירות בלי אימות, אפשר להפוך את השירות לגלוי לכולם.

הגדרת המשימה לשימוש ב-Direct VPC

Direct VPC egress מאפשר למשימת Cloud Run לשלוח תעבורת נתונים לרשת VPC בלי מחבר גישה ל-VPC ללא שרת (Serverless). אתם יכולים גם להוסיף תגי רשת ישירות למשימות Cloud Run כדי לשפר את אבטחת הרשת, למשל להחיל כללי חומת אש של VPC.

אפשר להגדיר Direct VPC egress עם משימה באמצעותGoogle Cloud המסוף, Google Cloud CLI או YAML.

המסוף

  1. כניסה ל-Cloud Run

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

  3. לוחצים על Container, Variables & Secrets, Connections, Security כדי להרחיב את דף מאפייני המשימה.

  4. לוחצים על הכרטיסייה חיבורים.

  5. לוחצים על Connect to a VPC for outbound traffic.

  6. לוחצים על שליחת תנועה ישירות ל-VPC.

  7. בשדה Network, בוחרים את רשת ה-VPC שאליה רוצים לשלוח תנועה.

  8. בשדה Subnet, בוחרים את רשת המשנה שממנה המשימה מקבלת כתובות IP. אפשר להריץ כמה משימות באותה רשת משנה.

  9. בקטע Traffic routing, בוחרים אחת מהאפשרויות הבאות:

    • Route only requests to private IPs to the VPC כדי לשלוח רק תנועה לכתובות פנימיות דרך רשת ה-VPC.
    • ‫Route all traffic to the VPC כדי לשלוח את כל תעבורת הנתונים היוצאת דרך רשת ה-VPC.

  10. אופציונלי: מזינים את השמות של תגי הרשת שרוצים לשייך לשירות או לשירותים. תגי רשת מצוינים ברמת הגרסה. לכל גרסה של שירות יכולים להיות תגי רשת שונים, כמו network-tag-2.

  11. אופציונלי: מזינים את השמות של תגי הרשת שרוצים לשייך למשימה או למשימות. במשימות, תגי הרשת מצוינים ברמת ההפעלה. לכל הפעלה של משימה יכולים להיות תגי רשת שונים, כמו network-tag-2.

  12. לוחצים על יצירה או על עדכון.

  13. כדי לוודא שהמשימה נמצאת ברשת ה-VPC, לוחצים על המשימה ואז על הכרטיסייה Configuration. הרשת ותת-הרשת מופיעות בכרטיס VPC.

    עכשיו אפשר להריץ את המשימה ב-Cloud Run ולשלוח בקשות מהמשימה לכל משאב ברשת ה-VPC, בהתאם לכללי חומת האש.

gcloud

כדי ליצור משימת Cloud Run בלי מחבר מ-Google Cloud CLI:

  1. מעדכנים את הרכיבים של gcloud לגרסה העדכנית:

    gcloud components update

  2. מוודאים שה-Compute Engine API מופעל בפרויקט:

    gcloud services enable compute.googleapis.com

  3. יוצרים משימת Cloud Run באמצעות הפקודה הבאה:

    gcloud run jobs create JOB_NAME \
--image=IMAGE_URL \
--network=NETWORK \
--subnet=SUBNET \
--network-tags=NETWORK_TAG_NAMES \
--vpc-egress=EGRESS_SETTING \
--region=REGION

    מחליפים את:

    • ‫JOB_NAME בשם של המשימה ב-Cloud Run.
    • ‫IMAGE_URL: הפניה לקובץ האימג' של הקונטיינר, לדוגמה us-docker.pkg.dev/cloudrun/container/job:latest
    • ‫NETWORK בשם של רשת ה-VPC. מציינים רשת VPC או רשת משנה, או את שתיהן. אם מציינים רק רשת, לרשת המשנה יהיה אותו שם כמו לרשת.
    • ‫SUBNET בשם של רשת המשנה. רשת המשנה חייבת להיות בגודל /26 או יותר. תעבורת נתונים יוצאת ישירה ל-VPC תומכת בטווחי IPv4 מסוג RFC 1918, RFC 6598 ו-Class E. אפשר לפרוס או להריץ כמה שירותים או משימות באותה רשת משנה, אבל אי אפשר לשתף את רשת המשנה עם מחברים קיימים.
    • אופציונלי: NETWORK_TAG_NAMES עם השמות של תגי הרשת שרוצים לשייך למשימה. במשימות, תגי הרשת מצוינים ברמת ההפעלה. לכל הפעלה של משימה יכולים להיות תגי רשת שונים, כמו network-tag-2.
    • ‫EGRESS_SETTING עם ערך הגדרת תעבורת נתונים יוצאת:
      • ‫all-traffic: כל התנועה היוצאת נשלחת דרך רשת ה-VPC.
      • ‫private-ranges-only: שליחת תנועה רק לכתובות פנימיות דרך רשת ה-VPC.
    • ‫REGION באזור של המשימה.

  4. כדי לוודא שהמשימה נמצאת ברשת ה-VPC, מריצים את הפקודה הבאה:

    gcloud run jobs describe JOB_NAME \
  --region=REGION

    מחליפים את:

    • ‫JOB_NAME בשם של המשימה.
    • ‫REGION באזור של המשימה שציינתם בשלב הקודם.

    הפלט אמור להכיל את השם של הרשת ושל רשת המשנה, לדוגמה:

    VPC network:
  Network:       default
  Subnet:        default

עכשיו אפשר להריץ את המשימה ב-Cloud Run ולשלוח בקשות מהמשימה לכל משאב ברשת ה-VPC, בהתאם לכללי חומת האש.

YAML

  1. אם אתם יוצרים משימה חדשה, דלגו על השלב הזה. אם אתם מעדכנים משימה קיימת, הורידו את הגדרת ה-YAML שלה:

    gcloud run jobs describe JOB --format export > job.yaml

  2. מעדכנים את המאפיינים הבאים:

    apiVersion: run.googleapis.com/v1
  kind: Job
  metadata:
    name: JOB_NAME
    labels:
      cloud.googleapis.com/location: REGION
  spec:
    template:
      metadata:
        annotations:
          run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET","tags":"NETWORK_TAG_NAMES"}]'
          run.googleapis.com/vpc-access-egress: EGRESS_SETTING
      spec:
        containers:
        - image: IMAGE

    מחליפים את:

    • ‫JOB_NAME בשם של המשימה ב-Cloud Run. שמות המשימות צריכים להיות באורך של עד 49 תווים, וייחודיים לכל אזור ופרויקט.
    • ‫REGION באזור של משימת Cloud Run, שצריך להיות זהה לאזור של רשת המשנה.
    • ‫NETWORK בשם של רשת ה-VPC. מציינים רשת VPC או רשת משנה, או את שתיהן. אם מציינים רק רשת, לרשת המשנה יהיה אותו שם כמו לרשת.
    • ‫SUBNET בשם של רשת המשנה. רשת המשנה חייבת להיות בגודל /26 או יותר. תעבורת נתונים יוצאת ב-Direct VPC תומכת בטווחי IPv4 מסוג RFC 1918,‏ RFC 6598 ו-Class E. אפשר לפרוס או להריץ כמה שירותים או משימות באותה רשת משנה, אבל אי אפשר לשתף את רשת המשנה עם מחברים קיימים.
    • אופציונלי: NETWORK_TAG_NAMES עם השמות של תגי הרשת שרוצים לשייך למשימה. במשימות, תגי הרשת מצוינים ברמת ההפעלה. לכל הפעלה של משימה יכולים להיות תגי רשת שונים, כמו network-tag-2.
    • ‫EGRESS_SETTING עם ערך הגדרת תעבורת נתונים יוצאת:
      • ‫all-traffic: כל התנועה היוצאת נשלחת דרך רשת ה-VPC.
      • ‫private-ranges-only: שליחת תנועה רק לכתובות פנימיות דרך רשת ה-VPC.
    • ‫IMAGE בכתובת ה-URL של קובץ האימג' של הקונטיינר של המשימה.

  3. יוצרים או מעדכנים את המשימה באמצעות הפקודה הבאה:

    gcloud run jobs replace job.yaml

פתרון בעיות

הרשאות של חשבון שירות

סוכן שירות של גישה ל-VPC ללא שרת (Serverless)

כדי לבצע פעולות בפרויקט Google Cloud , החיבור לרשת (VPC) מאפליקציית serverless משתמש בחשבון השירות Serverless VPC Access Service Agent. כתובת האימייל של חשבון השירות הזה היא בפורמט הבא:

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

כברירת מחדל, לחשבון השירות הזה יש את התפקיד סוכן שירות של גישה ל-VPC ללא שרת (Serverless) (roles/vpcaccess.serviceAgent). אם תשנו את ההרשאות של החשבון הזה, יכול להיות שהפעולות של הגישה ל-VPC ללא שרת ייכשלו.

סוכן שירות של Google APIs

‫Serverless VPC Access API תלוי ב-Deployment Manager כדי להקצות את המשאבים הבסיסיים שמטמיעים את המחבר. כדי לבצע פעולות בפרויקט ב- Google Cloud , Deployment Manager משתמש בסוכן שירות של Google APIs. כתובת האימייל של חשבון השירות הזה היא בפורמט הבא:

PROJECT_NUMBER@cloudservices.gserviceaccount.com

כברירת מחדל, לחשבון השירות הזה יש את התפקיד "עריכה" (roles/project.editor) או את ההרשאות של התפקיד "עריכה". אם אתם רוצים לתת לסוכן השירות של Google APIs הרשאות מוגבלות יותר, בלי להשפיע על הפונקציונליות של חיבור לרשת VPC ללא שרת, אתם יכולים לתת לחשבון השירות הזה את התפקיד סוכן שירות של גישה ל-VPC ללא שרת (roles/vpcaccess.serviceAgent).

שירותים מסוימים, מלבד Deployment Manager, מסתמכים גם על הרשאות ברירת המחדל של תפקיד העריכה של סוכן השירות של Google APIs. הסרת התפקיד הזה עלולה להשפיע על שירותים ומשאבים אחרים, מלבד Serverless VPC Access API. למידע נוסף על ההשלכות של הסרת התפקיד "עריכה" מסוכן השירות של Google APIs, קראו את המאמר סוכן שירות של Google APIs.

ביצועים חלשים ברשת או ניצול גבוה של המעבד (CPU) במצב חוסר פעילות

שימוש במחבר אחד לאלפי מכונות עלול לגרום לירידה בביצועים ולניצול מוגבר של המעבד (CPU) במצב חוסר פעילות. כדי לפתור את הבעיה, צריך לפצל את השירותים בין כמה מחברים.

בעיות ב-MTU בהתאמה אישית

אם נתקלתם בבעיות עם MTU בהתאמה אישית, ודאו שאתם משתמשים בהגדרת ברירת המחדל של MTU ב-Cloud Run.

שגיאות

שגיאה: לחשבון השירות נדרש תפקיד של סוכן שירות

אם אתם משתמשים באילוץ על מדיניות הארגון Restrict Resource Service Usage כדי לחסום את Cloud Deployment Manager‏ (deploymentmanager.googleapis.com), יכול להיות שתופיע הודעת השגיאה הבאה:

Serverless VPC Access service account (service-<PROJECT_NUMBER>@gcp-sa-vpcaccess.iam.gserviceaccount.com) needs Serverless VPC Access Service Agent role in the project.

מגדירים את מדיניות הארגון כך ש-Deployment Manager יוסר מרשימת הישויות שנחסמו או יתווסף לרשימת ההיתרים.

שגיאה ביצירת המחבר

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

  • מציינים טווח כתובות IP פנימיות מסוג RFC 1918 שלא חופף לאף אחת מהכתובות השמורות ברשת ה-VPC.
  • נותנים לפרויקט הרשאה להשתמש בתמונות של מכונות וירטואליות ב-Compute Engine מהפרויקט עם המזהה serverless-vpc-access-images. למידע נוסף על עדכון מדיניות הארגון בהתאם, ראו הגדרת אילוצי גישה לתמונות.

אין גישה למשאבים

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

אם אתם מגדירים מחבר בפרויקט שירות של VPC משותף, ודאו שכללי חומת האש מאפשרים תעבורת נתונים נכנסת (ingress) מהתשתית ללא שרת (serverless) אל המחבר.

שגיאה: החיבור נדחה

אם אתם מקבלים שגיאות מסוג connection refused או connection timeout שפוגעות בביצועי הרשת, יכול להיות שמספר החיבורים גדל ללא הגבלה בין הקריאות לאפליקציה ללא שרת (serverless). כדי להגביל את מספר החיבורים המקסימלי לכל מכונה, צריך להשתמש בספריית לקוח שתומכת במאגרי חיבורים. דוגמאות מפורטות לשימוש במאגרי חיבורים מופיעות במאמר ניהול חיבורים למסדי נתונים.

השגיאה "המשאב לא נמצא"

כשמוחקים רשת VPC או כלל של חומת אש, יכול להיות שתופיע הודעה דומה לזו: The resource "aet-uscentral1-subnet--1-egrfw" was not found.

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

השלבים הבאים