Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

שילוב של Gemini Cloud Assist עם כלים של צד שלישי באמצעות MCP

במאמר הזה נסביר איך לשלב את Gemini Cloud Assist ו-Application Design Center עם כלים של צד שלישי, כולל Antigravity,‏ Gemini CLI ו-Cursor, באמצעות Model Context Protocol‏ (MCP).

‫MCP מאפשר לשלב את Gemini Cloud Assist ואת היכולות האג'נטיות של App Design Center ישירות בכלים המועדפים של צד שלישי ובתהליכי עבודה מותאמים אישית, כדי שתוכלו לגשת למומחיות בתפעול הענן בדיוק במקום שבו אתם כבר עובדים. פרטים נוספים על MCP זמינים במאמר הגדרת MCP לאפליקציית ה-AI.

כלי MCP של Gemini Cloud Assist

‫Gemini Cloud Assist הוא סוכן שאפשר לגשת אליו דרך קבוצה של כלים של MCP באמצעות התבנית agents-as-tools. בניגוד לכלים שמחלצים נתונים או מבצעים עיבוד פרוצדורלי, הכלים של Gemini Cloud Assist חושפים פונקציונליות של סוכן של כל Gemini Cloud Assist או של תהליכי עבודה ספציפיים. הסוכן שמופעל על ידי קריאות לכלי MCP מבצע קריאות לכלי משלו באופן פנימי אל Google Cloud. הכלים הבאים של MCP פורסמו כדי שנציגים יוכלו להשתמש בהם:

‫ask_cloud_assist: זה הממשק הראשי לקבלת עזרה ולסוכן Gemini Cloud Assist. Google Cloudאפשר לגשת לכל הפונקציות של Gemini Cloud Assist דרך הכלי הזה, והוא כולל את הפונקציות של שאר הכלים של MCP.
‫design_infra: תומך בתהליכי עבודה לתכנון ולארכיטקטורה של תשתית ב- Google Cloud. הוא פועל עם כלי שרת MCP של App Design Center כדי לנהל את מחזור החיים של תכנון התשתית – לדוגמה, להריץ ולתקן ממצאים בנושא אבטחה, או לפרוס ולתקן בעיות.
investigate_issue: התמיכה הזו מאפשרת לפתור בעיות בתהליכי עבודה ב-Google Cloud. הוא יכול לבצע פתרון בעיות מהיר או פתרון בעיות מעמיק יותר באמצעות משאב חקירה.
‫invoke_operation: תומך בתהליכי עבודה ליצירה, לעדכון ולמחיקה של משאבים ב- Google Cloud. הכלי הזה פועל רק אם מופעלות פעולות של סוכנים. אפשר לבצע פעולות כתיבה ב-Gemini Cloud Assist רק באמצעות הפעלה של הכלי הזה.
‫optimize_costs: תומך בתהליכי עבודה לניתוח, למעקב ולאופטימיזציה של עלויות. Google Cloud הוא מספק פירוט של ההוצאות ומזהה הזדמנויות לשיפור היעילות בעלויות על ידי איתור משאבים לא פעילים או משאבים שלא מנוצלים מספיק.

כלי MCP ב-App Design Center

הכלים האלה, שלרוב מתואמים על ידי הכלי design_infra של Gemini Cloud Assist, מנהלים את מחזורי החיים של אפליקציות בתשתית באמצעות App Design Center, כולל ניהול תבניות, תאימות לאבטחה ותיקון בעיות ופריסה. הכלים הם:

‫setup_adc: מאתחל את סביבת App Design Center. זהו שלב הגדרה חד-פעמי שחייבים לבצע לפני שמשתמשים בכלים אחרים ב-App Design Center.
‫manage_application: ניהול מחזור החיים של פריסת אפליקציה. באמצעות הכלי הזה אפשר לפרוס עיצוב מאומת באמצעות App Design Center, או לאחזר את הסטטוס והפרטים של פריסה קיימת. זה השלב האחרון שבו העיצוב שלכם הופך לתשתית שנפרסה ב- Google Cloud.
‫manage_application_template: ניהול התוכן של תשתית כקוד (IaC) בתכנון התשתית. אפשר להשתמש באפשרות הזו כדי לשמור את העיצוב כתבנית של App Design Center, לייצא את העיצוב כקובצי Terraform או לעדכן את העיצוב. לדוגמה, אפשר להשתמש בכלי הזה כדי לעדכן את העיצוב על ידי שינוי הגדרות הרכיבים והגדרות הפרמטרים.
‫assess_best_practices: מבצע ביקורת מקיפה על האבטחה וההגדרות של עיצוב האפליקציה לפני הפריסה. הוא מאמת את העיצוב מול מסגרות של Security Command Center ואמצעי בקרה רלוונטיים, ומחזיר דוח עם ממצאים שניתן לפעול לפיהם כדי לתקן את הבעיות.
‫list_application_templates: מציג רשימה של כל עיצובי האפליקציות הזמינים.

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

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

הענקת גישה: כדי להשתמש ב-MCP, צריך לקבל תפקיד בניהול זהויות והרשאות גישה (IAM) שכולל את ההרשאה mcp.googleapis.com/tools.call, למשל אחד מהתפקידים הבאים ב-Gemini Cloud Assist:
- roles/geminicloudassist.user
- roles/geminicloudassist.editor
- roles/geminicloudassist.admin
אם עדיין לא עשיתם זאת, אתם צריכים להתקין את ה-CLI של gcloud ואת רכיבי הבטא שלו.
מפעילים את שירות ה-MCP בפרויקט באמצעות הפקודה הבאה:
```
gcloud beta services mcp enable geminicloudassist.googleapis.com \
    --project=PROJECT_ID
```
מחליפים את PROJECT_ID במזהה הפרויקט ב- Google Cloud .
מריצים את הפקודה הבאה כדי לבצע אימות באמצעות Application Default Credentials:
```
gcloud auth application-default login
```

הגדרת MCP עבור הלקוח

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

כדי להפעיל את תהליך העבודה המלא של עיצוב עד פריסה, צריך להגדיר את הלקוח להתחבר לשרתי ה-MCP של Gemini Cloud Assist ושל App Design Center, ולכלול את קובץ SKILL.md הרלוונטי. בקטעי הקוד הבאים מוצגת התצורה המשולבת.

Gemini CLI

הגדרה באמצעות תוסף

מתקינים את שרת ה-MCP כתוסף ל-Gemini CLI באמצעות הפקודה הבאה:

gemini extensions install https://github.com/GoogleCloudPlatform/gemini-cloud-assist-mcp

הגדרה ידנית

מגדירים את ההגדרות של שרת ה-MCP.

פותחים את קובץ ההגדרות של Gemini CLI בהיקף המשתמש בכתובת ~/.gemini/settings.json או את ההגדרות בהיקף סביבת העבודה בכתובת .gemini/settings.json. אם הקובץ לא קיים, יוצרים אותו. מוסיפים או ממזגים את בלוק ההגדרות הבא מתחת למפתח mcpServers. מוודאים שהקובץ בפורמט JSON תקין. ההגדרה הזו משתמשת אוטומטית ב-Application Default Credentials.

{
  "mcpServers": {
    "gemini_cloud_assist": {
      "httpUrl": "https://geminicloudassist.googleapis.com/mcp",
      "authProviderType": "google_credentials",
      "oauth": {
        "scopes": ["https://www.googleapis.com/auth/cloud-platform"]
      },
      "timeout": 600000
    },
    "application_design_center": {
      "httpUrl": "https://designcenter.googleapis.com/mcp",
      "authProviderType": "google_credentials",
      "oauth": {
        "scopes": ["https://www.googleapis.com/auth/cloud-platform"]
      },
      "timeout": 600000
    }
  }
}

יוצרים ומאכלסים את קובצי המיומנות.

יוצרים קובץ SKILL.md באחת מהספריות הבאות. מעתיקים ומדביקים את התוכן בפורמט Markdown של המיומנות שבחרתם מהקטע הפניה למיומנות במסמך הזה לקובץ.
- היקף Workspace: .gemini/skills/<skill-name>/
- היקף המשתמשים: ~/.gemini/skills/<skill-name>/
דוגמה למבנה ספריות:
```
.gemini/
└── skills/
    ├── design-and-deploy/
    │   └── SKILL.md
    └── google-gemini-cloud-assist/
        └── SKILL.md
              
```
מאמתים את המיומנויות.

אחרי שמשנים את הקבצים settings.json ו-SKILL.md, מפעילים מחדש את Gemini CLI. כדי לבדוק את זה, משתמשים בפקודות הבאות:
- ‫/skills list: כדי לוודא שהמיומנויות המקומיות שלכם זוהו בהצלחה.
- ‫/mcp list: כדי לוודא שהשרתים של Gemini Cloud Assist ושל Application Design Center MCP מחוברים.

Antigravity

מתקינים את התוסף.

ב-Antigravity, פותחים את זירת המסחר Extensions. מחפשים את התוסף Gemini Cloud Assist, לוחצים על התקנה ואז על רענון.

מגדירים את שרתי ה-MCP באופן ידני.

פותחים את החלונית Manage MCP Servers (ניהול שרתי MCP) ולוחצים על View raw config (הצגת הגדרות גולמיות) כדי לערוך את הקובץ mcp_config.json. מוסיפים או ממזגים את בלוק ההגדרות הבא. ההגדרה הזו משתמשת ב-Application Default Credentials שלכם לאימות.

{
  "mcpServers": {
    "gemini_cloud_assist": {
      "serverUrl": "https://geminicloudassist.googleapis.com/mcp",
      "headers": {},
      "authProviderType": "google_credentials"
    },
    "application_design_center": {
      "serverUrl": "https://designcenter.googleapis.com/mcp",
      "headers": {},
      "authProviderType": "google_credentials"
    }
  }
}

אימות ההגדרה

אחרי שמשנים את הקבצים mcp_config.json ו-SKILL.md, מפעילים מחדש את Antigravity. בחלונית Agent, משתמשים בפקודות הבאות עם לוכסן כדי לאמת את החיבור:
- ‫/skills list: אימות הגילוי של הכישורים המקומיים.
- ‫/mcp list: מוודא שהשרתים של Gemini Cloud Assist ושל Application Design Center MCP מחוברים.

סמן

ב Google Cloud פרויקט, יוצרים מזהה לקוח OAuth 2.0 לאפליקציה למחשב.
מגדירים את URI://anysphere.cursor-mcp/oauth/callback ככתובת ה-URL להפניה אוטומטית. מידע נוסף מופיע במאמרי העזרה בנושא Cursor.

מוסיפים או ממזגים את בלוק ההגדרות הבא:

   {
     "mcpServers": {
       "gemini_cloud_assist": {
         "url": "https://geminicloudassist.googleapis.com/mcp",
         "auth": {
           "CLIENT_ID": "${env:OAUTH_CLIENT_ID}",
           "CLIENT_SECRET": "${env:OAUTH_CLIENT_SECRET}",
           "scopes": ["https://www.googleapis.com/auth/cloud-platform"]
         }
       }
     }
   }

היכולות של Gemini Cloud Assist

הכלים של Gemini Cloud Assist ושל App Design Center MCP משתמשים ביכולות של הסוכן כדי לתת לו הוראות. הכישורים האלה עוזרים לסוכן לבצע את המשימות הבאות:

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

כשמשתמשים בסוכנים אינטראקטיביים כמו Antigravity או Gemini CLI, אפשר לשלב את כלי ה-MCP של Gemini Cloud Assist עם סוכנים ותהליכי עבודה אחרים. הכלים האלה מספקים מגוון רחב של יכולות, שיכול להיות שחלקן חופפות ליכולות של כלים מיוחדים שכבר יש לכם. כדי לבצע אופטימיזציה בהתאם לסביבה ולתרחיש השימוש הספציפיים שלכם, מומלץ להשתמש בשיטות הבאות:

התאמה אישית של הגדרת המיומנות: מעדכנים את הקובץ SKILL.md כדי לציין את הכוונות ואת תרחישי השימוש שבהם רוצים להפעיל את Gemini Cloud Assist. כך מוודאים שהסוכן יופעל רק במשימות שבהן נדרש הידע הנרחב שלו בענן.
הפעלת מיומנויות באופן מפורש: הרבה סוכנים אינטראקטיביים מאפשרים לכם לשלוט בהפעלה של מיומנות מסוימת. אם הסוכן תומך בכך, אפשר להגדיר את המיומנות כך שתידרש הפעלה ידנית באמצעות פקודות סלאש (/) או תיוגים עם @ (@). הגישה הזו מאפשרת לכם לבחור בדיוק מתי להשתמש ב-Gemini Cloud Assist ומתי להשתמש בכלי מיוחד אחר.

הפניה למיומנויות של Gemini Cloud Assist

אנחנו ממליצים להשתמש בקובץ SKILL.md בכל הסוכנים שהוגדרו באמצעות כלי ה-MCP של Gemini Cloud Assist. הקובץ הזה מספק לסוכן שלכם הנחיות לשימוש נכון בכלים.

תכנון ופריסה של תשתית

---
name: designing-and-deploying-infrastructure
description: This skill is used to design, assess, deploy, and troubleshoot cloud infrastructure using the Application Design Center (ADC).
---

# Designing and Deploying Infrastructure

## Index
1. [Overview](#overview)
2. [Best Practices & Constraints](#best-practices--constraints)
3. [Phase 1: Infrastructure Design & Refinement](#phase-1-infrastructure-design--refinement)
4. [Phase 2: Best Practices Assessment & Design Iteration](#phase-2-best-practices-assessment--design-iteration)
5. [Phase 3: Application Deployment](#phase-3-application-deployment)
6. [Phase 4: Get Deployed Resources](#phase-4-get-deployed-resources)
7. [Phase 5: Troubleshoot Deployment Failures](#phase-5-troubleshoot-deployment-failures)
8. [Phase 6: Verification & E2E Testing](#phase-6-verification--e2e-testing)

## Overview
This skill provides a prescriptive, multi-loop workflow for the entire infrastructure lifecycle on Google Cloud Platform (GCP). It leverages the Gemini Application Designer (GAD) and Application Design Center (ADC) tools (like `gemini_cloud_assist:design_infra` and `application_design_center:assess_best_practices`) to intelligently design architectures, assess best practices, and automate deployment and troubleshooting.
Always maintain the persona of a Principal Cloud Architect. Delegate all research and design to the specialized tools provided.
**Note:** These tools are part of the `gemini_cloud_assist` and `application_design_center` MCP Servers. Tool names are qualified with their respective server names (e.g., `gemini_cloud_assist:tool_name`).

## Best Practices & Constraints
-   **Delegation & No Manual Design**: Delegate all architecture decisions and product selections to the `gemini_cloud_assist:design_infra` tool. **Do not** design manually or edit generated Terraform code. Request changes via the tool.
-   **Inputs**: Always ask the user for required context like project ID, service accounts, etc. if necessary -- do not make assumptions or use placeholders.
-   **Visualization Power**: Always render the Mermaid diagram from `gemini_cloud_assist:design_infra` in every implementation plan. Refresh the diagram after every design change. Do not create your own diagrams.
-   **Loop Discipline**: Follow the workflow loops and exit criteria strictly. If you cannot follow the Infrastructure Lifecycle Workflow, you must exit and inform the user (for example, if the user cancels the process, or if you hit the maximum troubleshooting loop threshold in Phase 5).
-   **Application Template as the main resource**: The application template is the main resource when generating and iterating on a design. **Always** look for the application template URI in the `gemini_cloud_assist:design_infra` response (`serializedApplicationTemplateURI`), and use that for the rest of the Infrastructure Lifecycle Workflow.
    -   **Application Template vs Application**: Application template is a template that is used to create an application. Application is an instance of an application template. Do not confuse these two.
    -   **Never** attempt to create an application template URI yourself; always use the URI returned from `gemini_cloud_assist:design_infra`.

## Infrastructure Lifecycle Workflow
### Phase 1: Infrastructure Design & Refinement
**Goal**: Transform vague user requirements into a concrete, approved architectural design.
1.  **Requirement Gathering**: Capture user intent if it's vague (e.g., "3-tier web app with high availability").
Guidelines for initial design that **you must follow**:
    - Gather project ID (required) and ADC space ID (optional) from the user.
2.  **Codebase Analysis**: Critically, **before** calling `gemini_cloud_assist:design_infra`, you **must** perform a thorough exhaustive analysis of the user's application codebase (if available). **Do not** stop at high-level documentation or configuration files at the surface level; you **must** inspect the full depth of the codebase, including business logic, to find hidden API clients, dependencies, environment variables, and other application code context required to design cloud infrastructure. The list below outlines critical checks you **must** perform. **Do not** limit your investigation to only these items:
    - If you scan the application code to provide additional context, summarize *only* the application's characteristics (e.g., languages, frameworks, statefulness) and **do not** assume or suggest specific infrastructure components or services (e.g., **do not** choose the product type (e.g. GKE, Cloud Run, etc) or network information unless the user explicitly requested them or they are specified in codebase).
    - **NEVER** rely solely on `grep_search`, `os.environ`, or summary documentation (like READMEs) to determine infrastructure needs. **DO NOT** make premature assumptions or over-optimize for speed. Accuracy is critical; you **must** inspect the entire codebase.
    - Identify required environment variables, secrets, ports exposed in application, and database connection patterns. Environment Variables may also be present in nginx config files. Environment variables are critical for architecture so double check you have identified all of them.
    - Identify all the dependencies on existing GCP services (e.g., Vertex AI API, pre-existing GCS buckets). Along with the rest of the codebase, you **must** read dependency files (e.g., `requirements.txt`, `package.json`, `go.mod`) to identify GCP SDKs used and scan source code for explicit GCP client initializations.
    - Scan the codebase (e.g., `cloudbuild.yaml`, `Dockerfile`, CI/CD configs) to extract container image URLs. If no image is found or if the identified image does not exist in the Artifact Registry, you must build and upload the image. Provide only the resulting URL to `gemini_cloud_assist:design_infra`.
3.  **Initial Design**: Call `gemini_cloud_assist:design_infra` tool with `command="manage_app_design"` and the user's query. Ensure that `project` is `projects/{project_id}`
    - **MANDATORY - PRODUCT AGNOSTICISM**: Do NOT architect the infrastructure prematurely (e.g. "frontend should be a Cloud Run service"), instead delegate this responsibilty entirely to `gemini_cloud_assist:design_infra` tool. The codebase analysis results __may suggest__ certain product types (e.g. database uses the PostgreSQL client library, therefore database may be PostgreSQL), but otherwise make **zero** assumptions about the architecture. Since environment variables are critical to the architecture, you **must** pass the full set discovered during codebase analysis phase in all the design_infra manage_app_design requests.
    - **Prevent Naming Collisions**: Generate a unique, non-sequential five-character alphanumeric suffix, strictly avoiding common patterns like `12345`, `abcde` or `a1b2c`. Instruct `gemini_cloud_assist:design_infra` in the prompt to append this suffix to all newly created components.
4.  **Visualization, Terraform Code and Verification**: The `gemini_cloud_assist:design_infra` will respond with a Mermaid diagram, Terraform code, and the `serializedApplicationTemplateURI`.
    - Retrieve the Terraform code corresponding to each `.tf` file referenced and save them into a dedicated directory called `infra`.
    - You **must** present an Implementation Plan that contains the Mermaid diagram rendered within the Implementation Plan, as well as the location of the Terraform configs.
    - **Verification Step**: This is a critical step. You **must** meticulously verify the generated Terraform code to ensure it includes all the environment variables, secrets, dependencies, and correct container image URLs required by application, identified during the Codebase Analysis step. If *any* required configurations are missing or incorrect, you **must** iterate on the design using `gemini_cloud_assist:design_infra command="manage_app_design"` to correct them. **Do not proceed to deployment with an unverified or incomplete design.**
5.  **Iteration**: Refine the design by feeding user feedback back into `gemini_cloud_assist:design_infra`.
    -   **Design Iteration Constraints**: When iterating on the design, **do not** make manual edits to the Terraform code. **Always** use `gemini_cloud_assist:design_infra` tool exclusively to update the Terraform code.  **Always** keep the local Terraform code in sync with Terraform code returned from `gemini_cloud_assist:design_infra`.
    -   **Visualization Update**: Update the Implementation Plan by re-rendering the Mermaid diagram and updating the Terraform configs.
    -   **Retries**: After encountering transient errors and you need to retry `gemini_cloud_assist:design_infra` calls, you **must make exactly the same call** with **same** arguments.
6.  **Exit Criteria**:
    -   Design fulfills all critical requirements and has resources needed by the application, especially the environment variables for each service.
    -   User confirms the design is satisfactory.
    -   `gemini_cloud_assist:design_infra` reaches a stable state with no further architectural changes.

### Phase 2: Best Practices Assessment & Design Iteration
**Goal**: Validate design alignment with security, cost, and reliability benchmarks prior to deployment.
1. **Execution**: Invoke `assess_best_practices` using the application template metadata (project, location, space and application template identifiers).
2. **Analysis**: You **MUST** present all findings to the user in a pretty tabular fashion per framework, detailing specific violations, and their associated severity levels - before proceeding to remediation.
3. **Remediation Loop**:
    - Pass identified findings as context to `gemini_cloud_assist:design_infra(command="manage_app_design")`.
    - **Strict Constraint**: All modifications must be executed via the `gemini_cloud_assist:design_infra` tool; manual Terraform manipulation is prohibited.
    - Perform a diff-based comparison between current and updated Terraform code for user approval.
    - Re-assess post-update to verify the resolution of findings.
4. **Exit Criteria**:
    - **Optimization**: Zero findings remaining.
    - **Convergence**: `gemini_cloud_assist:design_infra` provides no further suggestions.
    - **Threshold**: Maximum of three (3) iterative attempts reached.
5. **Transition**: Proceed to Phase 3 deployment only upon loop termination.

### Phase 3: Application Deployment
**Goal**: Deploy the application template to the GCP environment.
1.  **Deploy Application**: Use the `application_design_center:manage_application` tool with the `APPLICATION_OPERATION_DEPLOY` operation to deploy the application.
    *   **Required Arguments**: `project`, `location`, `spaceId`, `applicationTemplateUri`, `applicationId`, `serviceAccount`.
    *   **Note**: This returns a Long-Running Operation (LRO). Inform the user that the deployment has started.
    *   **Example**:
        ```json
        {
          "project": "my-project",
          "location": "us-central1",
          "spaceId": "my-space",
          "applicationId": "my-app",
          "operation": "APPLICATION_OPERATION_DEPLOY",
          "applicationTemplateUri": "projects/my-project/locations/us-central1/spaces/my-space/applicationTemplates/my-template",
          "serviceAccount": "projects/my-project/serviceAccounts/deployer@my-project.iam.gserviceaccount.com"
        }
        ```
2.  **Monitor Deployment**: Repeatedly poll the LRO (e.g., every 30-60 seconds) until `done: true`.
3.  **Handle Results**:
    -   **Success**: If `done` is `true` and there is no `error` field, proceed to Phase 4.
    -   **Failure**: If an `error` field is present, proceed to Phase 5.

### Phase 4: Get Deployed Resources
1.  **Retrieve Information**: Call the `application_design_center:manage_application` tool with the `APPLICATION_OPERATION_GET` operation, providing `project`, `location`, `spaceId` and `applicationId`, to fetch the outputs and status of the deployed resources.
    *   **Example**:
        ```json
        {
          "project": "my-project",
          "location": "us-central1",
          "spaceId": "my-space",
          "applicationId": "my-app",
          "operation": "APPLICATION_OPERATION_GET"
        }
        ```
2.  **User Confirmation**: Present the deployed resource information to the user and conclude the task.

### Phase 5: Troubleshoot Deployment Failures
**Goal**: Diagnose and remediate deployment failures iteratively.
When troubleshooting a failed application, follow these steps.
**Process:**
1.  **Initiate Troubleshooting:**
    - **Action:** Call `gemini_cloud_assist:design_infra` with `applicationUri` (format: projects/{project}/locations/{location}/spaces/{spaceId}/applications/{applicationId}) to get suggested fixes.
    - Convert the returned response to JSON. The value of a parameter may be a JSON string that needs to be parsed.
    - **Expected Output Structure from Troubleshooting:**
      ```json
      {
        "summary": "...",
        "troubleshootingSteps": [
          {
            "description": "...",
            "gcloud_commands": ["gcloud ..."],
            "componentParameters": null
          },
          {
            "description": "...",
            "gcloud_commands": null,
            "componentParameters": [
              {
                "componentUri": "projects/.../components/comp-a",
                "parameters": [
                  { "key": "param1", "value": "new_value" },
                  { "key": "param3", "value": "another" }
                ]
              }
            ]
          }
        ]
      }
      ```
2.  **Analyze Troubleshooting Steps**: Iterate through each `step` in `troubleshootingSteps`. Identify if `gcloud_commands` or `component_parameters` are provided.
3.  **Update Application Template**:
    - **If `component_parameters` updates are suggested**:
      1. Get the `application_template_id` from the Application object obtained in Step 2. The value is present at `serialized_application_template.uri`. Get the `application_template_id` from the uri.
      2. **Update Application Template**: Call `application_design_center:manage_application_template` with `APPLICATION_TEMPLATE_OPERATION_UPDATE_COMPONENT_PARAMETERS`.
         - **Tool**: `application_design_center:manage_application_template`
         - **Arguments**: `parent`, `applicationTemplateId`, `componentParameters`, `operation` - `APPLICATION_TEMPLATE_OPERATION_UPDATE_COMPONENT_PARAMETERS`
      3. **Example**:
         ```json
         {
           "applicationTemplateId": "my-template",
           "componentParameters": [
             {
               "component": "projects/my-project/locations/us-central1/spaces/my-space/applicationTemplates/my-template/components/cloud-run-1",
               "parameters": [
                 {
                   "key": "containers",
                   "value": [
                     {
                       "container_image": "us-docker.pkg.dev/cloudrun/container/hello",
                       "container_name": "service-container",
                       "ports": {
                         "container_port": 8080,
                         "name": "http1"
                       },
                       "resources": {
                         "cpu_idle": false,
                         "limits": {
                           "cpu": "4",
                           "memory": "16Gi"
                         },
                         "startup_cpu_boost": false
                       }
                     }
                   ]
                 }
               ]
             }
           ],
           "operation": "APPLICATION_TEMPLATE_OPERATION_UPDATE_COMPONENT_PARAMETERS",
           "parent": "projects/my-project/locations/us-central1/spaces/my-space"
         }
         ```
4.  **Retry Deployment**:
    - **Action**: Attempt to deploy the application again.
    - **Tool**: `application_design_center:manage_application`
    - **Arguments**: `project`, `location`, `spaceId`, `applicationTemplateUri`, `applicationId`, `serviceAccount`. `operation` - `APPLICATION_OPERATION_DEPLOY`
5.  **Iterate if Necessary**: If deployment fails again, repeat troubleshooting steps up to 5 times. Report the history to the user if the limit is reached.
**Operational Notes:**
* Mutating tool calls often return an LRO.
* Always poll LROs on behalf of the user; do not ask the user to run the polling command.
* Do not sleep during deployment status polling. Poll actively every 30-60 seconds until the LRO is done.
* Apply `debug_deployment` responses exactly as provided.
* For retries, disregard previous attempts and start from Step 2 again.
* Handle bad-gateway errors during commit with jittered retries and verify the template revision.
* Exclude `PORT` from being explicitly set as a Cloud Run environment variables as it is a reserved name.

### Phase 6: Verification & E2E Testing
Following a successful deployment:
- Verify that services are using correct container image URLs and that each component is healthy.
- Conduct a simple demo test to ensure E2E functionality and validate the hosted services are working as expected.

פועלים ב Google Cloud

---
name: operating-google-cloud
description: Comprehensive management of GCP resources and Kubernetes. Supports direct tool delegation for assistance, infrastructure design, troubleshooting, cost optimization, and resource mutations.
---

# Managing GCP and Kubernetes

## Index
1. [Overview](#overview)
2. [Tool Usage & Routing](#tool-usage--routing)
3. [Instructions and Constraints](#instructions-and-constraints)

## Overview
GCP and Kubernetes resources and mutations should use MCP tools. These tools are specialized backend agents. As the client agent, your role is to identify the intent and delegate the entire task verbatim to the appropriate intelligent tool.

**Note:** These tools are part of the `gemini_cloud_assist` and `application_design_center` MCP Servers. Tool names are qualified with their respective server names (e.g., `gemini_cloud_assist:tool_name`).

## Tool Usage & Routing

1.  **General Assistance & Orchestration**: Use `gemini_cloud_assist:ask_cloud_assist` for general inquiries, estate queries (e.g., "List my active VMs"), low-complexity directives, and triage of ambiguous issues.
    *   *Triggers*: Broad questions, status checks, exploratory queries, mutative directives (e.g., "Restart VM", "Scale cluster").
    *   *Routing*: This is the **default choice** for intents that are purely informational or involve general cloud concepts.

2.  **Infrastructure Design & Architecture**: Use `gemini_cloud_assist:design_infra` for designing, architecting, or deploying infrastructure.
    *   *Commands*: 
        - `manage_app_design`: Use for comprehensive ADC application designs and IaC imports.
        - `generate_terraform`: Use for single-resource Terraform generation.
        - `generate_gcloud` / `generate_bigquery`: Use for generating CLI commands.
        - `generate_kubernetes_yaml`: Use for Kubernetes manifests.
        - `debug_deployment`: Use for debugging ADC deployment failures.

3.  **Troubleshooting & Deep Diagnostics**: Use `gemini_cloud_assist:investigate_issue` for specialized "SRE in a box" diagnostics and Root Cause Analysis (RCA).
    *   *Triggers*: Outages, crashes, latency spikes, deep debugging, error log reasoning, and understanding application dependencies (topology).
    *   *Routing*: Use when the user asks "Why" a failure occurred or needs remediation for a known incident.

4.  **Cost Optimization**: Use `gemini_cloud_assist:optimize_costs` for analyzing spend and identifying savings.
    *   *Triggers*: Spending analysis, top cost drivers, identifying idle or underutilized resources for the purpose of saving money.
    *   *Constraints*: This tool is **read-only**; it provides analysis but does not execute changes. Do not use for general utilization queries unrelated to cost.

5.  **GKE Resource Mutations**: Use `gemini_cloud_assist:invoke_operation` specifically for GKE operations.
    *   *Operation Types*: `GKE_APPLY` (for raw YAML manifests) and `GKE_PATCH` (for specific JSON patches).
    *   *Input Requirement*: The `userQuery` must be a stringified JSON object containing `operation_type` and the corresponding `gke_apply` or `gke_patch` details.

## Instructions and Constraints
When answering any queries about Google Cloud Platform (GCP), YOU MUST follow these rules:

- **Context ID Persistence:** All Gemini Cloud Assist (GCA) tools return a `contextId` in their response. Ensure that any subsequent turns to a GCA tool pass this `contextId` as a parameter to maintain multi-turn conversation state.
- **Direct Tool Mapping:** Upon receiving a request about GCP resources, immediately invoke the relevant tool identified in the Routing section.
- **Context Integrity:** Pass the user's entire prompt exactly as provided; maintain the original query without summarization, rephrasing, or truncation.
- **Atomic Delegation:** Execute the request as a single turn; delegate the entire problem to the tool rather than breaking it down into intermediate queries.
- **Identifier Precision:** Include all identifiers (Project IDs, Cluster names, or Instance paths) discovered in the prompt.
- **Local Context Enrichment:** Forward the user's query to the tools along with any additional relevant local context identified in the working directory.
- **Persistence to Local Workspace:** Save any configuration, manifest, or YAML generated or updated by the tools to the local workspace.
- **Tool Exclusivity:** Rely exclusively on the provided MCP tools for cloud interactions; refrain from executing local commands such as `gcloud` or `kubectl`.
- **Remote Source of Truth:** Rely solely on MCP tools to discover and validate the existence of cloud resources; bypass local validation against configuration files like `.gcloud/config` or `kubeconfig`.
- **Execution Workflow:** Always ask the user if they want to apply the YAML using `gemini_cloud_assist:invoke_operation` after generation. Explicitly ask: "Would you like to proceed with applying this configuration?". If the user confirms, invoke the tool to apply the manifests.

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

הגדרות נוספות של Gemini לאדמינים Google Cloud

שילוב של Gemini Cloud Assist עם כלים של צד שלישי באמצעות MCP קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.