deployment 0.0.1

Google-Cloud-Platform-Document/.gitignore

@@ -0,0 +1,160 @@
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[cod]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# PyInstaller
+#  Usually these files are written by a python script from a template
+#  before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py,cover
+.hypothesis/
+.pytest_cache/
+cover/
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+db.sqlite3
+db.sqlite3-journal
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+
+# PyBuilder
+.pybuilder/
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# IPython
+profile_default/
+ipython_config.py
+
+# pyenv
+#   For a library or package, you might want to ignore these files since the code is
+#   intended to run in multiple environments; otherwise, check them in:
+# .python-version
+
+# pipenv
+#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
+#   However, in case of collaboration, if having platform-specific dependencies or dependencies
+#   having no cross-platform support, pipenv may install dependencies that don't work, or not
+#   install all needed dependencies.
+#Pipfile.lock
+
+# poetry
+#   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
+#poetry.lock
+
+# pdm
+#   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
+#pdm.lock
+#   pdm stores project-wide configurations in .pdm.toml, but it is recommended to not include it
+#   in version control.
+#   https://pdm.fming.dev/#use-with-ide
+.pdm.toml
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Celery stuff
+celerybeat-schedule
+celerybeat.pid
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.env
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+.dmypy.json
+dmypy.json
+
+# Pyre type checker
+.pyre/
+
+# pytype static type analyzer
+.pytype/
+
+# Cython debug symbols
+cython_debug/
+
+# PyCharm
+#  JetBrains specific template is maintained in a separate JetBrains.gitignore that can
+#  be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
+#  and can be added to the global gitignore or merged into this file.  For a more nuclear
+#  option (not recommended) you can uncomment the following to ignore the entire idea folder.
+#.idea/

Google-Cloud-Platform-Document/Cloud Build - Deploy to Compute Engine.json

@@ -0,0 +1 @@
+{"title": "Cloud Build - Deploy to Compute Engine", "url": "https://cloud.google.com/compute/docs/instances", "abstract": "# Cloud Build - Deploy to Compute Engine\nThis guide explains how to perform zero-downtime blue/green deployments on Compute Engine Managed Instance Groups (MIGs) using Cloud Build and Terraform.\nCloud Build enables you to automate a variety of developer processes, including building and deploying applications to various Google Cloud runtimes such as Compute Engine, [Google Kubernetes Engine](/build/docs/deploying-builds/deploy-gke) , [GKE Enterprise](/anthos/multicluster-management/gateway/tutorials/cloud-build-integration) , and [Cloud Functions](/build/docs/deploying-builds/deploy-functions) .\n [Compute Engine MIGs](/compute/docs/instance-groups) enable you to operate applications on multiple identical Virtual Machines (VMs). You can make your workloads scalable and highly available by taking advantage of automated MIG services, including: autoscaling, autohealing, regional (multiple zone) deployment, and automatic updating. Using the blue/green continuous deployment model, you will learn how to gradually transfer user traffic from one MIG (blue) to another MIG (green), both of which are running in production.", "content": "## Design overviewThe following diagram shows the blue/green deployment model used by the code sample described in this document:\n \nAt a high level, this model includes the following components:- Two Compute Engine VM pools: Blue and Green.\n- Three external HTTP(S) load balancers:- A Blue/Green load balancer, that routes traffic from end users to either the Blue or the Green pool of VM instances.\n- A Blue load balancer that routes traffic from QA engineers and developers to the Blue VM instance pool.\n- A Green load balancer that routes traffic from QA engineers and developers to the Green instance pool.\n- Two sets of users:- End users who have access to the Blue/Green load balancer, which points them to either the Blue or the Green instance pool.\n- QA engineers and developers who require access to both sets of pools for development and testing purposes. They can access both the Blue and the Green load balancers, which routes them to the Blue Instance pool and the Green instance pool respectively.\nThe Blue and the Green VMs pools are implemented as Compute Engine MIGs, and external IP addresses are routed into the VMs in the MIG using external HTTP(s) load balancers. The code sample described in this document uses Terraform to configure this infrastructure.\nThe following diagram illustrates the developer operations that happens in the deployment:\n \nIn the diagram above, the red arrows represent the bootstrapping flow that occurs when you set up the deployment infrastructure for the first time, and the blue arrows represent the GitOps flow that occurs during every deployment.\nTo set up this infrastructure, you run a setup script that starts the bootstrap process and sets up the components for the GitOps flow.\nThe setup script executes a Cloud Build pipeline that performs the following operations:- Creates a repository in [Cloud Source Repositories](/source-repositories/docs) named`copy-of-gcp-mig-simple`and copies the source code from the GitHub sample repository to the repository in Cloud Source Repositories.\n- Creates two [Cloud Build triggers](/build/docs/triggers) named`apply`and`destroy`.\n **Note:** Cloud Build supports first-class integration with GitHub, GitLab, and Bitbucket. Cloud Source Repositories is used in this sample for demonstration purposes.\nThe `apply` trigger is attached to a Terraform file named `main.tfvars` in the Cloud Source Repositories. This file contains the Terraform variables representing the blue and the green load balancers.\nTo set up the deployment, you update the variables in the `main.tfvars` file. The `apply` trigger runs a Cloud Build pipeline that executes `tf_apply` and performs the following operations:- Creates two Compute Engine MIGs (one for green and one for blue), four Compute Engine VM instances (two for the green MIG and two for the blue MIG), the three load balancers (blue, green, and the splitter), and three public IP addresses.\n- Prints out the IP addresses that you can use to see the deployed applications in the blue and the green instances.\nThe destroy trigger is triggered manually to delete all the resources created by the apply trigger.## Objectives\n- Use Cloud Build and Terraform to set up external HTTP(S) load balancers with Compute Engine VM instance group backends.\n- Perform blue/green deployments on the VM instances.\n## CostsIn this document, you use the following billable components of Google Cloud:- [Compute Engine](/compute/all-pricing) \n- [Cloud Build](/build/pricing) \n- [Cloud Source Repositories](/source-repositories/pricing) \n- [Cloud Load Balancing](/load-balancing/pricing) \nTo generate a cost estimate based on your projected usage,  use the [pricing calculator](/products/calculator) . \nWhen you finish the tasks that are described in this document, you can avoid continued billing by deleting the resources that you created. For more information, see [Clean up](#clean-up) .## Before you begin\n## Trying it out\n- Run the setup script from the Google code sample repository:```\nbash <(curl https://raw.githubusercontent.com/GoogleCloudPlatform/cloud-build-samples/main/mig-blue-green/setup.sh)\n```\n- When the setup script asks for user consent, enter **yes** .The script finishes running in a few seconds.\n- In the Google Cloud console, open the Cloud Build **Build history** page: [Open the Build history page](https://console.cloud.google.com/cloud-build) \n- Click on the latest build.You see the **Build details** page, which shows a Cloud Build pipeline with three build steps: the first build step creates a repository in Cloud Source Repositories, the second step clones the contents of the sample repository in GitHub to Cloud Source Repositories, and the third step adds two build triggers.\n- Open Cloud Source Repositories: [  Open Cloud Source Repositories](https://source.cloud.google.com/repos) \n- From the repositories list, click `copy-of-gcp-mig-simple` .In the **History** tab at the bottom of the page, you'll see one commit with the description `A copy of https://github.com/GoogleCloudPlatform/cloud-build-samples.git` made by Cloud Build to create a repository named `copy-of-gcp-mig-simple` .\n- Open the Cloud Build **Triggers** page: [Open Triggers page](https://console.cloud.google.com/cloud-build/triggers) \n- You'll see two build triggers named `apply` and `destroy` . The `apply` trigger is attached to the `infra/main.tfvars` file in the `main` branch. This trigger is executed anytime the file is updated. The `destroy` trigger is a manual trigger.\n- To start the deploy process, update the `infra/main.tfvars` file:- In your terminal window, create and navigate into a folder named `deploy-compute-engine` :```\nmkdir ~/deploy-compute-enginecd ~/deploy-compute-engine\n```\n- Clone the `copy-of-gcp-mig-simple` repo:```\ngcloud source repos clone copy-of-mig-blue-green\n```\n- Navigate into the cloned directory:```\ncd ./copy-of-mig-blue-green\n```\n- Update `infra/main.tfvars` to replace blue with green:```\nsed -i'' -e 's/blue/green/g' infra/main.tfvars\n```\n- Add the updated file:```\ngit add .\n```\n- Commit the file:```\ngit commit -m \"Promote green\"\n```\n- Push the file:```\ngit push\n```Making changes to `infra/main.tfvars` triggers the execution of the `apply` trigger, which starts the deployment.\n- Open Cloud Source Repositories: [  Open Cloud Source Repositories](https://source.cloud.google.com/repos) \n- From the repositories list, click `copy-of-gcp-mig-simple` .You'll see the commit with the description `Promote green` in the **History** tab at the bottom of the page.\n- To view the execution of the `apply` trigger, open the **Build history** page in the Google Cloud console: [Open the Build history page](https://console.cloud.google.com/cloud-build) \n- Open the **Build details** page by clicking on the first build.You will see the `apply` trigger pipeline with two build steps. The first build step executes Terraform apply to create the Compute Engine and load balancing resources for the deployment. The second build step prints out the IP address where you can see the application running.\n- Open the IP address corresponding to the green MIG in a browser. You'll see a screenshot similar to the following showing the deployment: \n- Go to the Compute Engine **Instance group** page to see the Blue and the Green instance groups: [Open the Instance group page](https://console.cloud.google.com/compute/instanceGroups/list) \n- Open the **VM instances** page to see the four VM instances: [Open the VM Instance page](https://console.cloud.google.com/compute/instances) \n- Open the **External IP addresses** page to see the three load balancers: [Open the External IP addresses page](https://console.cloud.google.com/networking/addresses/list) \n## Understanding the codeSource code for this code sample includes:- Source code related to the setup script.\n- Source code related to the Cloud Build pipelines.\n- Source code related to the Terraform templates.\n### Setup script`setup.sh` is the setup script that runs the bootstrap process and creates the components for the blue/green deployment. The script performs the following operations:- Enables the Cloud Build, Resource Manager, Compute Engine, and Cloud Source Repositories APIs.\n- Grants the`roles/editor`IAM role to the Cloud Build service account in your project. This role is required for Cloud Build to create and set up the necessary GitOps components for the deployment.\n- Grants the`roles/source.admin`IAM role to the Cloud Build service account in your project. This role is required for the Cloud Build service account to create the Cloud Source Repositories in your project and clone the contents of the sample GitHub repository to your Cloud Source Repositories.\n- Generates a Cloud Build pipeline named `bootstrap.cloudbuild.yaml` inline, that:- Creates a new repository in Cloud Source Repositories.\n- Copies the source code from the sample GitHub repository to the new repository in Cloud Source Repositories.\n- Creates the apply and destroy build triggers.\n [  mig-blue-green/setup.sh ](https://github.com/GoogleCloudPlatform/cloud-build-samples/blob/HEAD/mig-blue-green/setup.sh) [View on GitHub](https://github.com/GoogleCloudPlatform/cloud-build-samples/blob/HEAD/mig-blue-green/setup.sh) \n```\nset -eBLUE='\\033[1;34m'RED='\\033[1;31m'GREEN='\\033[1;32m'NC='\\033[0m'echo -e \"\\n${GREEN}\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\"echo -e \"# \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0#\"echo -e \"# \u00a0Zero-Downtime Blue/Green VM Deployments Using \u00a0 \u00a0 #\"echo -e \"# \u00a0Managed Instance Groups, Cloud Build & Terraform \u00a0#\"echo -e \"# \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0#\"echo -e \"\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##\n##${NC}\\n\"echo -e \"\\nSTARTED ${GREEN}setup.sh:${NC}\"echo -e \"\\nIt's ${RED}safe to re-run${NC} this script to ${RED}recreate${NC} all resources.\\n\"echo \"> Checking GCP CLI tool is installed\"gcloud --version > /dev/null 2>&1readonly EXPLICIT_PROJECT_ID=\"$1\"readonly EXPLICIT_CONSENT=\"$2\"if [ -z \"$EXPLICIT_PROJECT_ID\" ]; then\u00a0 \u00a0 echo \"> No explicit project id provided, trying to infer\"\u00a0 \u00a0 PROJECT_ID=\"$(gcloud config get-value project)\"else\u00a0 \u00a0 PROJECT_ID=\"$EXPLICIT_PROJECT_ID\"fiif [ -z \"$PROJECT_ID\" ]; then\u00a0 \u00a0 echo \"ERROR: GCP project id was not provided as parameter and could not be inferred\"\u00a0 \u00a0 exit 1else\u00a0 \u00a0 readonly PROJECT_NUM=\"$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)')\"\u00a0 \u00a0 if [ -z \"$PROJECT_NUM\" ]; then\u00a0 \u00a0 \u00a0 \u00a0 echo \"ERROR: GCP project number could not be determined\"\u00a0 \u00a0 \u00a0 \u00a0 exit 1\u00a0 \u00a0 fi\u00a0 \u00a0 echo -e \"\\nYou are about to:\"\u00a0 \u00a0 echo -e \" \u00a0* modify project ${RED}${PROJECT_ID}/${PROJECT_NUM}${NC}\"\u00a0 \u00a0 echo -e \" \u00a0* ${RED}enable${NC} various GCP APIs\"\u00a0 \u00a0 echo -e \" \u00a0* make Cloud Build ${RED}editor${NC} of your project\"\u00a0 \u00a0 echo -e \" \u00a0* ${RED}execute${NC} Cloud Builds and Terraform plans to create\"\u00a0 \u00a0 echo -e \" \u00a0* ${RED}4 VMs${NC}, ${RED}3 load balancers${NC}, ${RED}3 public IP addresses${NC}\"\u00a0 \u00a0 echo -e \" \u00a0* incur ${RED}charges${NC} in your billing account as a result\\n\"fiif [ \"$EXPLICIT_CONSENT\" == \"yes\" ]; then\u00a0 echo \"Proceeding under explicit consent\"\u00a0 readonly CONSENT=\"$EXPLICIT_CONSENT\"else\u00a0 \u00a0 echo -e \"Enter ${BLUE}'yes'${NC} if you want to proceed:\"\u00a0 \u00a0 read CONSENTfiif [ \"$CONSENT\" != \"yes\" ]; then\u00a0 \u00a0 echo -e \"\\nERROR: Aborted by user\"\u00a0 \u00a0 exit 1else\u00a0 \u00a0 echo -e \"\\n......................................................\"\u00a0 \u00a0 echo -e \"\\n> Received user consent\"fi\n## Executes action with one randomly delayed retry.#function do_with_retry {\u00a0 \u00a0 COMMAND=\"$@\"\u00a0 \u00a0 echo \"Trying $COMMAND\"\u00a0 \u00a0 (eval $COMMAND && echo \"Success on first try\") || ( \\\u00a0 \u00a0 \u00a0 \u00a0 echo \"Waiting few seconds to retry\" &&\u00a0 \u00a0 \u00a0 \u00a0 sleep 10 && \\\u00a0 \u00a0 \u00a0 \u00a0 echo \"Retrying $COMMAND\" && \\\u00a0 \u00a0 \u00a0 \u00a0 eval $COMMAND \\\u00a0 \u00a0 )}echo \"> Enabling required APIs\"# Some of these can be enabled later with Terraform, but I personally# prefer to do all API enablement in one place with gcloud.gcloud services enable \\\u00a0 \u00a0 --project=$PROJECT_ID \\\u00a0 \u00a0 cloudbuild.googleapis.com \\\u00a0 \u00a0 cloudresourcemanager.googleapis.com \\\u00a0 \u00a0 compute.googleapis.com \\\u00a0 \u00a0 sourcerepo.googleapis.com \\\u00a0 \u00a0 --no-user-output-enabled \\\u00a0 \u00a0 --quietecho \"> Adding Cloud Build to roles/editor\"gcloud projects add-iam-policy-binding \\\u00a0 \u00a0 \"$PROJECT_ID\" \\\u00a0 \u00a0 --member=\"serviceAccount:$PROJECT_NUM@cloudbuild.gserviceaccount.com\" \\\u00a0 \u00a0 --role='roles/editor' \\\u00a0 \u00a0 --condition=None \\\u00a0 \u00a0 --no-user-output-enabled \\\u00a0 \u00a0 --quietecho \"> Adding Cloud Build to roles/source.admin\"gcloud projects add-iam-policy-binding \\\u00a0 \u00a0 \"$PROJECT_ID\" \\\u00a0 \u00a0 --member=\"serviceAccount:$PROJECT_NUM@cloudbuild.gserviceaccount.com\" \\\u00a0 \u00a0 --condition=None \\\u00a0 \u00a0 --role='roles/source.admin' \\\u00a0 \u00a0 --no-user-output-enabled \\\u00a0 \u00a0 --quietecho \"> Configuring bootstrap job\"rm -rf \"./bootstrap.cloudbuild.yaml\"cat <<'EOT_BOOT' > \"./bootstrap.cloudbuild.yaml\"tags:- \"mig-blue-green-bootstrapping\"steps:- id: create_new_cloud_source_repo\u00a0 name: \"gcr.io/cloud-builders/gcloud\"\u00a0 script: |\u00a0 \u00a0 #!/bin/bash\u00a0 \u00a0 set -e\u00a0 \u00a0 echo \"(Re)Creating source code repository\"\u00a0 \u00a0 gcloud source repos delete \\\u00a0 \u00a0 \u00a0 \u00a0 \"copy-of-mig-blue-green\" \\\u00a0 \u00a0 \u00a0 \u00a0 --quiet || true\u00a0 \u00a0 gcloud source repos create \\\u00a0 \u00a0 \u00a0 \u00a0 \"copy-of-mig-blue-green\" \\\u00a0 \u00a0 \u00a0 \u00a0 --quiet- id: copy_demo_source_into_new_cloud_source_repo\u00a0 name: \"gcr.io/cloud-builders/gcloud\"\u00a0 env:\u00a0 \u00a0 - \"PROJECT_ID=$PROJECT_ID\"\u00a0 \u00a0 - \"PROJECT_NUMBER=$PROJECT_NUMBER\"\u00a0 script: |\u00a0 \u00a0 #!/bin/bash\u00a0 \u00a0 set -e\u00a0 \u00a0 readonly GIT_REPO=\"https://github.com/GoogleCloudPlatform/cloud-build-samples.git\"\u00a0 \u00a0 echo \"Cloning demo source repo\"\u00a0 \u00a0 mkdir /workspace/from/\u00a0 \u00a0 cd /workspace/from/\u00a0 \u00a0 git clone $GIT_REPO ./original\u00a0 \u00a0 cd ./original\u00a0 \u00a0 echo \"Cloning new empty repo\"\u00a0 \u00a0 mkdir /workspace/to/\u00a0 \u00a0 cd /workspace/to/\u00a0 \u00a0 gcloud source repos clone \\\u00a0 \u00a0 \u00a0 \u00a0 \"copy-of-mig-blue-green\"\u00a0 \u00a0 cd ./copy-of-mig-blue-green\u00a0 \u00a0 echo \"Making a copy\"\u00a0 \u00a0 cp -r /workspace/from/original/mig-blue-green/* ./\u00a0 \u00a0 echo \"Setting git identity\"\u00a0 \u00a0 git config user.email \\\u00a0 \u00a0 \u00a0 \u00a0 \"$PROJECT_NUMBER@cloudbuild.gserviceaccount.com\"\u00a0 \u00a0 git config user.name \\\u00a0 \u00a0 \u00a0 \u00a0 \"Cloud Build\"\u00a0 \u00a0 echo \"Commit & push\"\u00a0 \u00a0 git add .\u00a0 \u00a0 git commit \\\u00a0 \u00a0 \u00a0 \u00a0 -m \"A copy of $GIT_REPO\"\u00a0 \u00a0 git push- id: add_pipeline_triggers\u00a0 name: \"gcr.io/cloud-builders/gcloud\"\u00a0 env:\u00a0 \u00a0 - \"PROJECT_ID=$PROJECT_ID\"\u00a0 script: |\u00a0 \u00a0 #!/bin/bash\u00a0 \u00a0 set -e\u00a0 \u00a0 echo \"(Re)Creating destroy trigger\"\u00a0 \u00a0 gcloud builds triggers delete \"destroy\" --quiet || true\u00a0 \u00a0 gcloud builds triggers create manual \\\u00a0 \u00a0 \u00a0 \u00a0 --name=\"destroy\" \\\u00a0 \u00a0 \u00a0 \u00a0 --repo=\"https://source.developers.google.com/p/$PROJECT_ID/r/copy-of-mig-blue-green\" \\\u00a0 \u00a0 \u00a0 \u00a0 --branch=\"master\" \\\u00a0 \u00a0 \u00a0 \u00a0 --build-config=\"pipelines/destroy.cloudbuild.yaml\" \\\u00a0 \u00a0 \u00a0 \u00a0 --repo-type=CLOUD_SOURCE_REPOSITORIES \\\u00a0 \u00a0 \u00a0 \u00a0 --quiet\u00a0 \u00a0 echo \"(Re)Creating apply trigger\"\u00a0 \u00a0 gcloud builds triggers delete \"apply\" --quiet || true\u00a0 \u00a0 gcloud builds triggers create cloud-source-repositories \\\u00a0 \u00a0 \u00a0 \u00a0 --name=\"apply\" \\\u00a0 \u00a0 \u00a0 \u00a0 --repo=\"copy-of-mig-blue-green\" \\\u00a0 \u00a0 \u00a0 \u00a0 --branch-pattern=\"master\" \\\u00a0 \u00a0 \u00a0 \u00a0 --build-config=\"pipelines/apply.cloudbuild.yaml\" \\\u00a0 \u00a0 \u00a0 \u00a0 --included-files=\"infra/main.tfvars\" \\\u00a0 \u00a0 \u00a0 \u00a0 --quietEOT_BOOTecho \"> Waiting API enablement propagation\"do_with_retry \"(gcloud builds list --project \"$PROJECT_ID\" --quiet && gcloud compute instances list --project \"$PROJECT_ID\" --quiet && gcloud source repos list --project \"$PROJECT_ID\" --quiet) > /dev/null 2>&1\" > /dev/null 2>&1echo \"> Executing bootstrap job\"gcloud beta builds submit \\\u00a0 \u00a0 --project \"$PROJECT_ID\" \\\u00a0 \u00a0 --config ./bootstrap.cloudbuild.yaml \\\u00a0 \u00a0 --no-source \\\u00a0 \u00a0 --no-user-output-enabled \\\u00a0 \u00a0 --quietrm ./bootstrap.cloudbuild.yamlecho -e \"\\n${GREEN}All done. Now you can:${NC}\"echo -e \" \u00a0* manually run 'apply' and 'destroy' triggers to manage deployment lifecycle\"echo -e \" \u00a0* commit change to 'infra/main.tfvars' and see 'apply' pipeline trigger automatically\"echo -e \"\\n${GREEN}Few key links:${NC}\"echo -e \" \u00a0* Dashboard: https://console.cloud.google.com/home/dashboard?project=$PROJECT_ID\"echo -e \" \u00a0* Repo: https://source.cloud.google.com/$PROJECT_ID/copy-of-mig-blue-green\"echo -e \" \u00a0* Cloud Build Triggers: https://console.cloud.google.com/cloud-build/triggers;region=global?project=$PROJECT_ID\"echo -e \" \u00a0* Cloud Build History: https://console.cloud.google.com/cloud-build/builds?project=$PROJECT_ID\"echo -e \"\\n.............................\"echo -e \"\\n${GREEN}COMPLETED!${NC}\"\n```\n### Cloud Build pipelines`apply.cloudbuild.yaml` and `destroy.cloudbuild.yaml` are the Cloud Build config files that the setup script uses to set up the resources for the GitOps flow. `apply.cloudbuild.yaml` contains two build steps:- `tf_apply build`build step that calls the function`tf_install_in_cloud_build_step`, which installs Terraform.`tf_apply`that creates the resources used in the GitOps flow. The functions`tf_install_in_cloud_build_step`and`tf_apply`are defined in`bash_utils.sh`and the build step uses the`source`command to call them.\n- `describe_deployment`build step that calls the function`describe_deployment`that prints out the IP addresses of the load balancers.\n`destroy.cloudbuild.yaml` calls `tf_destroy` that deletes all the resources created by `tf_apply` .\nThe functions `tf_install_in_cloud_build_step` , `tf_apply` , `describe_deployment` , and `tf_destroy` are defined in the file `bash_utils.sh` . The build config files use the `source` command to call the functions.\n [  mig-blue-green/pipelines/apply.cloudbuild.yaml ](https://github.com/GoogleCloudPlatform/cloud-build-samples/blob/HEAD/mig-blue-green/pipelines/apply.cloudbuild.yaml) [View on GitHub](https://github.com/GoogleCloudPlatform/cloud-build-samples/blob/HEAD/mig-blue-green/pipelines/apply.cloudbuild.yaml) \n```\nsteps:\u00a0 - id: run-terraform-apply\u00a0 \u00a0 name: \"gcr.io/cloud-builders/gcloud\"\u00a0 \u00a0 env:\u00a0 \u00a0 \u00a0 - \"PROJECT_ID=$PROJECT_ID\"\u00a0 \u00a0 script: |\u00a0 \u00a0 \u00a0 #!/bin/bash\u00a0 \u00a0 \u00a0 set -e\u00a0 \u00a0 \u00a0 source /workspace/lib/bash_utils.sh\u00a0 \u00a0 \u00a0 tf_install_in_cloud_build_step\u00a0 \u00a0 \u00a0 tf_apply\u00a0 - id: describe-deployment\u00a0 \u00a0 name: \"gcr.io/cloud-builders/gcloud\"\u00a0 \u00a0 env:\u00a0 \u00a0 \u00a0 - \"PROJECT_ID=$PROJECT_ID\"\u00a0 \u00a0 script: |\u00a0 \u00a0 \u00a0 #!/bin/bash\u00a0 \u00a0 \u00a0 set -e\u00a0 \u00a0 \u00a0 source /workspace/lib/bash_utils.sh\u00a0 \u00a0 \u00a0 describe_deploymenttags:\u00a0 - \"mig-blue-green-apply\"\n```\n [  mig-blue-green/pipelines/destroy.cloudbuild.yaml ](https://github.com/GoogleCloudPlatform/cloud-build-samples/blob/HEAD/mig-blue-green/pipelines/destroy.cloudbuild.yaml) [View on GitHub](https://github.com/GoogleCloudPlatform/cloud-build-samples/blob/HEAD/mig-blue-green/pipelines/destroy.cloudbuild.yaml) \n```\nsteps:\u00a0 - id: run-terraform-destroy\u00a0 \u00a0 name: \"gcr.io/cloud-builders/gcloud\"\u00a0 \u00a0 env:\u00a0 \u00a0 \u00a0 - \"PROJECT_ID=$PROJECT_ID\"\u00a0 \u00a0 script: |\u00a0 \u00a0 \u00a0 #!/bin/bash\u00a0 \u00a0 \u00a0 set -e\u00a0 \u00a0 \u00a0 source /workspace/lib/bash_utils.sh\u00a0 \u00a0 \u00a0 tf_install_in_cloud_build_step\u00a0 \u00a0 \u00a0 tf_destroytags:\u00a0 - \"mig-blue-green-destroy\"\n```\nThe following code shows the function `tf_install_in_cloud_build_step` that's defined in `bash_utils.sh` . The build config files call this function to install Terraform on the fly. It creates a Cloud Storage bucket to record the Terraform status.\n [  mig-blue-green/lib/bash_utils.sh ](https://github.com/GoogleCloudPlatform/cloud-build-samples/blob/HEAD/mig-blue-green/lib/bash_utils.sh) [View on GitHub](https://github.com/GoogleCloudPlatform/cloud-build-samples/blob/HEAD/mig-blue-green/lib/bash_utils.sh) \n```\nfunction tf_install_in_cloud_build_step {\u00a0 \u00a0 echo \"Installing deps\"\u00a0 \u00a0 apt update\u00a0 \u00a0 apt install \\\u00a0 \u00a0 \u00a0 \u00a0 unzip \\\u00a0 \u00a0 \u00a0 \u00a0 wget \\\u00a0 \u00a0 \u00a0 \u00a0 -y\u00a0 \u00a0 echo \"Manually installing Terraform\"\u00a0 \u00a0 wget https://releases.hashicorp.com/terraform/1.3.4/terraform_1.3.4_linux_386.zip\u00a0 \u00a0 unzip -q terraform_1.3.4_linux_386.zip\u00a0 \u00a0 mv ./terraform /usr/bin/\u00a0 \u00a0 rm -rf terraform_1.3.4_linux_386.zip\u00a0 \u00a0 echo \"Verifying installation\"\u00a0 \u00a0 terraform -v\u00a0 \u00a0 echo \"Creating Terraform state storage bucket $BUCKET_NAME\"\u00a0 \u00a0 gcloud storage buckets create \\\u00a0 \u00a0 \u00a0 \u00a0 \"gs://$BUCKET_NAME\" || echo \"Already exists...\"\u00a0 \u00a0 echo \"Configure Terraform provider and state bucket\"cat <<EOT_PROVIDER_TF > \"/workspace/infra/provider.tf\"terraform {\u00a0 required_version = \">= 0.13\"\u00a0 backend \"gcs\" {\u00a0 \u00a0 bucket = \"$BUCKET_NAME\"\u00a0 }\u00a0 required_providers {\u00a0 \u00a0 google = {\u00a0 \u00a0 \u00a0 source \u00a0= \"hashicorp/google\"\u00a0 \u00a0 \u00a0 version = \">= 3.77, < 5.0\"\u00a0 \u00a0 }\u00a0 }}EOT_PROVIDER_TF\u00a0 \u00a0 echo \"$(cat /workspace/infra/provider.tf)\"}\n```\nThe following code snippet shows the function `tf_apply` that's defined in `bash_utils.sh` . It first calls `terraform init` that loads all modules and custom libraries and then runs `terraform apply` to load the variables from the `main.tfvars` file.\n [  mig-blue-green/lib/bash_utils.sh ](https://github.com/GoogleCloudPlatform/cloud-build-samples/blob/HEAD/mig-blue-green/lib/bash_utils.sh) [View on GitHub](https://github.com/GoogleCloudPlatform/cloud-build-samples/blob/HEAD/mig-blue-green/lib/bash_utils.sh) \n```\nfunction tf_apply {\u00a0 \u00a0 echo \"Running Terraform init\"\u00a0 \u00a0 terraform \\\u00a0 \u00a0 \u00a0 \u00a0 -chdir=\"$TF_CHDIR\" \\\u00a0 \u00a0 \u00a0 \u00a0 init\u00a0 \u00a0 echo \"Running Terraform apply\"\u00a0 \u00a0 terraform \\\u00a0 \u00a0 \u00a0 \u00a0 -chdir=\"$TF_CHDIR\" \\\u00a0 \u00a0 \u00a0 \u00a0 apply \\\u00a0 \u00a0 \u00a0 \u00a0 -auto-approve \\\u00a0 \u00a0 \u00a0 \u00a0 -var project=\"$PROJECT_ID\" \\\u00a0 \u00a0 \u00a0 \u00a0 -var-file=\"main.tfvars\"}\n```\nThe following code snippet shows the function `describe_deployment` that's defined in `bash_utils.sh` . It uses `gcloud compute addresses describe` to fetch the IP addresses of the load balancers using the name and prints them out.\n [  mig-blue-green/lib/bash_utils.sh ](https://github.com/GoogleCloudPlatform/cloud-build-samples/blob/HEAD/mig-blue-green/lib/bash_utils.sh) [View on GitHub](https://github.com/GoogleCloudPlatform/cloud-build-samples/blob/HEAD/mig-blue-green/lib/bash_utils.sh) \n```\nfunction describe_deployment {\u00a0 \u00a0 NS=\"ns1-\"\u00a0 \u00a0 echo -e \"Deployment configuration:\\n$(cat infra/main.tfvars)\"\u00a0 \u00a0 echo -e \\\u00a0 \u00a0 \u00a0 \"Here is how to connect to:\" \\\u00a0 \u00a0 \u00a0 \"\\n\\t* active color MIG: http://$(gcloud compute addresses describe ${NS}splitter-address-name --region=us-west1 --format='value(address)')/\" \\\u00a0 \u00a0 \u00a0 \"\\n\\t* blue color MIG: http://$(gcloud compute addresses describe ${NS}blue-address-name --region=us-west1 --format='value(address)')/\" \\\u00a0 \u00a0 \u00a0 \"\\n\\t* green color MIG: http://$(gcloud compute addresses describe ${NS}green-address-name --region=us-west1 --format='value(address)')/\"\u00a0 \u00a0 echo \"Good luck!\"}\n```\nThe following code snippet shows the function `tf_destroy` that's defined in `bash_utils.sh` . It calls `terraform init` that loads all modules and custom libraries and then runs `terraform destroy` that unloads the Terraform variables.\n [  mig-blue-green/lib/bash_utils.sh ](https://github.com/GoogleCloudPlatform/cloud-build-samples/blob/HEAD/mig-blue-green/lib/bash_utils.sh) [View on GitHub](https://github.com/GoogleCloudPlatform/cloud-build-samples/blob/HEAD/mig-blue-green/lib/bash_utils.sh) \n```\nfunction tf_destroy {\u00a0 \u00a0 echo \"Running Terraform init\"\u00a0 \u00a0 terraform \\\u00a0 \u00a0 \u00a0 \u00a0 -chdir=\"$TF_CHDIR\" \\\u00a0 \u00a0 \u00a0 \u00a0 init\u00a0 \u00a0 echo \"Running Terraform destroy\"\u00a0 \u00a0 terraform \\\u00a0 \u00a0 \u00a0 \u00a0 -chdir=\"$TF_CHDIR\" \\\u00a0 \u00a0 \u00a0 \u00a0 destroy \\\u00a0 \u00a0 \u00a0 \u00a0 -auto-approve \\\u00a0 \u00a0 \u00a0 \u00a0 -var project=\"$PROJECT_ID\" \\\u00a0 \u00a0 \u00a0 \u00a0 -var-file=\"main.tfvars\"}\n```\n### Terraform templatesYou'll find all the Terraform configuration files and variables in the `copy-of-gcp-mig-simple/infra/` folder.- `main.tf`: this is the Terraform configuration file\n- `main.tfvars`: this file defines the Terraform variables.\n- `mig/`and`splitter/`: these folders contain the modules that define the load balancers. The`mig/`folder contains the Terraform configuration file that defines the MIG for the Blue and the Green load balancers. The Blue and the Green MIGs are identical, therefore they are defined once and instantiated for the blue and the green objects. The Terraform configuration file for the splitter load balancer is in the`splitter/`folder .\nThe following code snippet shows the contents of `infra/main.tfvars` . It contains three variables: two that determine what application version to deploy to the Blue and the Green pools and a variable for the active color: Blue or Green. Changes to this file triggers the deployment.\n [  mig-blue-green/infra/main.tfvars ](https://github.com/GoogleCloudPlatform/cloud-build-samples/blob/HEAD/mig-blue-green/infra/main.tfvars) [View on GitHub](https://github.com/GoogleCloudPlatform/cloud-build-samples/blob/HEAD/mig-blue-green/infra/main.tfvars) \n```\nMIG_VER_BLUE \u00a0 \u00a0 = \"v1\"MIG_VER_GREEN \u00a0 \u00a0= \"v1\"MIG_ACTIVE_COLOR = \"blue\"\n```\nThe following is a code snippet from `infra/main.tf` . In this snippet:- A variable is defined for the Google Cloud project.\n- Google is set as the Terraform provider.\n- A variable is defined for namespace. All objects created by Terraform are prefixed with this variable so that multiple versions of the application can be deployed in the same project and the object names don't collide with each other.\n- Variables`MIG_VER_BLUE`,`MIG_VER_BLUE`, and`MIG_ACTIVE_COLOR`are the bindings for the variables in the`infra/main.tfvars`file.\n [  mig-blue-green/infra/main.tf ](https://github.com/GoogleCloudPlatform/cloud-build-samples/blob/HEAD/mig-blue-green/infra/main.tf) [View on GitHub](https://github.com/GoogleCloudPlatform/cloud-build-samples/blob/HEAD/mig-blue-green/infra/main.tf) \n```\nvariable \"project\" {\u00a0 type \u00a0 \u00a0 \u00a0 \u00a0= string\u00a0 description = \"GCP project we are working in.\"}provider \"google\" {\u00a0 project = var.project\u00a0 region \u00a0= \"us-west1\"\u00a0 zone \u00a0 \u00a0= \"us-west1-a\"}variable \"ns\" {\u00a0 type \u00a0 \u00a0 \u00a0 \u00a0= string\u00a0 default \u00a0 \u00a0 = \"ns1-\"\u00a0 description = \"The namespace used for all resources in this plan.\"}variable \"MIG_VER_BLUE\" {\u00a0 type \u00a0 \u00a0 \u00a0 \u00a0= string\u00a0 description = \"Version tag for 'blue' deployment.\"}variable \"MIG_VER_GREEN\" {\u00a0 type \u00a0 \u00a0 \u00a0 \u00a0= string\u00a0 description = \"Version tag for 'green' deployment.\"}variable \"MIG_ACTIVE_COLOR\" {\u00a0 type \u00a0 \u00a0 \u00a0 \u00a0= string\u00a0 description = \"Active color (blue | green).\"}\n```\nThe following code snippet from `infra/main.tf` shows the instantiation of the splitter module. This module takes in the active color so that the splitter load balancer knows which MIG to deploy the application.\n [  mig-blue-green/infra/main.tf ](https://github.com/GoogleCloudPlatform/cloud-build-samples/blob/HEAD/mig-blue-green/infra/main.tf) [View on GitHub](https://github.com/GoogleCloudPlatform/cloud-build-samples/blob/HEAD/mig-blue-green/infra/main.tf) \n```\nmodule \"splitter-lb\" {\u00a0 source \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 = \"./splitter\"\u00a0 project \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0= var.project\u00a0 ns \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 = \"${var.ns}splitter-\"\u00a0 active_color \u00a0 \u00a0 \u00a0 \u00a0 = var.MIG_ACTIVE_COLOR\u00a0 instance_group_blue \u00a0= module.blue.google_compute_instance_group_manager_default.instance_group\u00a0 instance_group_green = module.green.google_compute_instance_group_manager_default.instance_group}\n```\nThe following code snippet from `infra/main.tf` defines two identical modules for Blue and Green MIGs. It takes in the color, the network, and the subnetwork which are defined in the splitter module.\n [  mig-blue-green/infra/main.tf ](https://github.com/GoogleCloudPlatform/cloud-build-samples/blob/HEAD/mig-blue-green/infra/main.tf) [View on GitHub](https://github.com/GoogleCloudPlatform/cloud-build-samples/blob/HEAD/mig-blue-green/infra/main.tf) \n```\nmodule \"blue\" {\u00a0 source \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 = \"./mig\"\u00a0 project \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0= var.project\u00a0 app_version \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0= var.MIG_VER_BLUE\u00a0 ns \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 = var.ns\u00a0 color \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0= \"blue\"\u00a0 google_compute_network \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 = module.splitter-lb.google_compute_network\u00a0 google_compute_subnetwork \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0= module.splitter-lb.google_compute_subnetwork_default\u00a0 google_compute_subnetwork_proxy_only = module.splitter-lb.google_compute_subnetwork_proxy_only}module \"green\" {\u00a0 source \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 = \"./mig\"\u00a0 project \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0= var.project\u00a0 app_version \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0= var.MIG_VER_GREEN\u00a0 ns \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 = var.ns\u00a0 color \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0= \"green\"\u00a0 google_compute_network \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 = module.splitter-lb.google_compute_network\u00a0 google_compute_subnetwork \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0= module.splitter-lb.google_compute_subnetwork_default\u00a0 google_compute_subnetwork_proxy_only = module.splitter-lb.google_compute_subnetwork_proxy_only}\n```\nThe file `splitter/main.tf` defines the objects that are created for the splitter MIG. The following is a code snippet from `splitter/main.tf` that contains the logic to switch between the Green and the Blue MIG. It's backed by the service `google_compute_region_backend_service` , which can route traffic to two backend regions: `var.instance_group_blue` or `var.instance_group_green` . `capacity_scaler` defines how much of the traffic to route.\nThe following code routes 100% of the traffic to the specified color, but you can update this code for canary deployment to route the traffic to a subset of the users.\n [  mig-blue-green/infra/splitter/main.tf ](https://github.com/GoogleCloudPlatform/cloud-build-samples/blob/HEAD/mig-blue-green/infra/splitter/main.tf) [View on GitHub](https://github.com/GoogleCloudPlatform/cloud-build-samples/blob/HEAD/mig-blue-green/infra/splitter/main.tf) \n```\nresource \"google_compute_region_backend_service\" \"default\" {\u00a0 name \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0= local.l7-xlb-backend-service\u00a0 region \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0= \"us-west1\"\u00a0 load_balancing_scheme = \"EXTERNAL_MANAGED\"\u00a0 health_checks \u00a0 \u00a0 \u00a0 \u00a0 = [google_compute_region_health_check.default.id]\u00a0 protocol \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0= \"HTTP\"\u00a0 session_affinity \u00a0 \u00a0 \u00a0= \"NONE\"\u00a0 timeout_sec \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 = 30\u00a0 backend {\u00a0 \u00a0 group \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 = var.instance_group_blue\u00a0 \u00a0 balancing_mode \u00a0= \"UTILIZATION\"\u00a0 \u00a0 capacity_scaler = var.active_color == \"blue\" ? 1 : 0\u00a0 }\u00a0 backend {\u00a0 \u00a0 group \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 = var.instance_group_green\u00a0 \u00a0 balancing_mode \u00a0= \"UTILIZATION\"\u00a0 \u00a0 capacity_scaler = var.active_color == \"green\" ? 1 : 0\u00a0 }}\n```\nThe file `mig/main.tf` defines the objects pertaining to the Blue and the Green MIGs. The following code snippet from this file defines the Compute Engine instance template that's used to create the VM pools. Note that this instance template has the Terraform lifecycle property set to `create_before_destroy` . This is because, when updating the version of the pool, you cannot use the template to create the new version of the pools when it is still being used by the previous version of the pool. But if the older version of the pool is destroyed before creating the new template, there'll be a period of time when the pools are down. To avoid this scenario, we set the Terraform lifecycle to `create_before_destroy` so that the newer version of a VM pool is created first before the older version is destroyed.\n [  mig-blue-green/infra/mig/main.tf ](https://github.com/GoogleCloudPlatform/cloud-build-samples/blob/HEAD/mig-blue-green/infra/mig/main.tf) [View on GitHub](https://github.com/GoogleCloudPlatform/cloud-build-samples/blob/HEAD/mig-blue-green/infra/mig/main.tf) \n```\nresource \"google_compute_instance_template\" \"default\" {\u00a0 name = local.l7-xlb-backend-template\u00a0 disk {\u00a0 \u00a0 auto_delete \u00a0= true\u00a0 \u00a0 boot \u00a0 \u00a0 \u00a0 \u00a0 = true\u00a0 \u00a0 device_name \u00a0= \"persistent-disk-0\"\u00a0 \u00a0 mode \u00a0 \u00a0 \u00a0 \u00a0 = \"READ_WRITE\"\u00a0 \u00a0 source_image = \"projects/debian-cloud/global/images/family/debian-10\"\u00a0 \u00a0 type \u00a0 \u00a0 \u00a0 \u00a0 = \"PERSISTENT\"\u00a0 }\u00a0 labels = {\u00a0 \u00a0 managed-by-cnrm = \"true\"\u00a0 }\u00a0 machine_type = \"n1-standard-1\"\u00a0 metadata = {\u00a0 \u00a0 startup-script = <<EOF\u00a0 \u00a0 #! /bin/bash\u00a0 \u00a0 sudo apt-get update\u00a0 \u00a0 sudo apt-get install apache2 -y\u00a0 \u00a0 sudo a2ensite default-ssl\u00a0 \u00a0 sudo a2enmod ssl\u00a0 \u00a0 vm_hostname=\"$(curl -H \"Metadata-Flavor:Google\" \\\u00a0 \u00a0 http://169.254.169.254/computeMetadata/v1/instance/name)\"\u00a0 \u00a0 sudo echo \"<html><body style='font-family: Arial; margin: 64px; background-color: light${var.color};'><h3>Hello, World!<br><br>version: ${var.app_version}<br>ns: ${var.ns}<br>hostname: $vm_hostname</h3></body></html>\" | \\\u00a0 \u00a0 tee /var/www/html/index.html\u00a0 \u00a0 sudo systemctl restart apache2\u00a0 \u00a0 EOF\u00a0 }\u00a0 network_interface {\u00a0 \u00a0 access_config {\u00a0 \u00a0 \u00a0 network_tier = \"PREMIUM\"\u00a0 \u00a0 }\u00a0 \u00a0 network \u00a0 \u00a0= var.google_compute_network.id\u00a0 \u00a0 subnetwork = var.google_compute_subnetwork.id\u00a0 }\u00a0 region = \"us-west1\"\u00a0 scheduling {\u00a0 \u00a0 automatic_restart \u00a0 = true\u00a0 \u00a0 on_host_maintenance = \"MIGRATE\"\u00a0 \u00a0 provisioning_model \u00a0= \"STANDARD\"\u00a0 }\u00a0 tags = [\"load-balanced-backend\"]\u00a0 # NOTE: the name of this resource must be unique for every update;\u00a0 # \u00a0 \u00a0 \u00a0 this is wy we have a app_version in the name; this way\u00a0 # \u00a0 \u00a0 \u00a0 new resource has a different name vs old one and both can\u00a0 # \u00a0 \u00a0 \u00a0 exists at the same time\u00a0 lifecycle {\u00a0 \u00a0 create_before_destroy = true\u00a0 }}\n```## Clean upTo avoid incurring charges to your Google Cloud account for the resources used in this   tutorial, either delete the project that contains the resources, or keep the project and   delete the individual resources.\n### Delete individual resources\n- Delete the Compute Engine resources created by the apply trigger:- Open the Cloud Build **Triggers** page: [Open Triggers page](https://console.cloud.google.com/cloud-build/triggers) \n- In the **Triggers** table, locate the row corresponding to the **destroy** trigger, and click **Run** . When the trigger completes execution, the resources created by the **apply** trigger are deleted.\n- Delete the resources created during bootstrapping by running the following command in your terminal window:```\nbash <(curl https://raw.githubusercontent.com/GoogleCloudPlatform/cloud-build-samples/main/mig-blue-green/teardown.sh)\n```\n### Delete the project\n- **Caution** : Deleting a project has the following effects:- **Everything in the project is deleted.** If you used an existing project for  the tasks in this document, when you delete it, you also delete any other work you've  done in the project.\n- **Custom project IDs are lost.** When you created this project, you might have created a custom project ID that you want to use in  the future. To preserve the URLs that use the project ID, such as an`appspot.com`URL, delete selected resources inside the project instead of deleting the whole project.\nIf you plan to explore multiple architectures, tutorials, or quickstarts, reusing projects  can help you avoid exceeding project quota limits.\n- Delete a Google Cloud project:\n- ```\ngcloud projects delete PROJECT_ID\n```\n## What's next\n- Learn more about [build triggers](/build/docs/triggers) .\n- Learn how to [view build provenance](/build/docs/securing-builds/view-build-provenance) .", "guide": "Cloud Build"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Abandon a release.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Abandon a release", "url": "https://cloud.google.com/deploy/docs/abandon-release", "abstract": "# Cloud Deploy - Abandon a release\nThis page describes how to permanently abandon a Cloud Deploy release.\nYou can permanently [abandon](/deploy/docs/terminology#abandon) a release. An abandoned release has the following characteristics:\n- You can't promote an abandoned release.\n- You can't roll back to an abandoned release.\n- You can't unabandon a release. After you abandon a release, it's permanently deactivated.\nReasons for abandoning a release include the following, for example:\n- There's a bug in the release\n- There's a security issue in the release\n- A feature included in the release has been deprecated\nTo abandon a release, run the following command:\n```\ngcloud deploy releases abandon RELEASE_NAME --delivery-pipeline=PIPELINE_NAME --region=REGION\n```\nWhere:\n- Is the name of the release to abandon. This is required.\n- Is the name of the delivery pipeline that created the release. This is required.\n- Is the name of the region in which the release was created, for example `us-central1` . This is required.", "content": "## IAM permissions\nThe IAM permissions required for abandoning a release are included in the following roles:\n- roles/clouddeploy.admin\n- roles/clouddeploy.operator\n- roles/clouddeploy.developer## Rollouts from abandoned releases\nWhen you abandon a release, any rollouts created from that release that are in progress or queued continue to completion\u2014they are not cancelled. However, you can't create new rollouts from an abandoned release.\n## View abandoned releases\nIn Google Cloud console, you can see if a release has been abandoned. The **Releases** tab, on the Delivery pipeline details page, labels the release as \"abandoned\":", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - About Cloud Deploy regions.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - About Cloud Deploy regions", "url": "https://cloud.google.com/deploy/docs/regions", "abstract": "# Cloud Deploy - About Cloud Deploy regions\nThe Cloud Deploy service runs as multiple independent, isolated instances in various Google Cloud locations. The location where you create a delivery pipeline determines which Cloud Deploy instance stores and processes requests for that pipeline.\nThe [Cloud Locations page](https://cloud.google.com/about/locations) lists supported regions for each Google Cloud product, including Cloud Deploy.\n**Note:** you must create targets, releases, and rollouts in the same region in which you created the delivery pipeline. (GKE and GKE Enterprise clusters represented by those targets, however, can be in any region.)\nWhen Cloud Deploy uses other Google Cloud resources for a pipeline, it creates them in the same location if possible, including Cloud Storage buckets, for example, which Cloud Deploy uses to store rendered configuration manifests.\nCloud Deploy instances can deploy applications to locations other than the one where Cloud Deploy is running. This capability allows your delivery pipelines to deploy to multiple regions. However, a given delivery pipeline is only accessible by a single Cloud Deploy instance.\nCloud Deploy instances operate independently, so a failure in one region doesn't affect an instance in another. For this reason, if you are only deploying to a single region, we recommended (but don't require) that you create your pipeline in the same location as your target cluster.\n**Note:** your choice of region can have an impact on performance and billing, because data transfers among Google Cloud locations can perform better or worse, depending on location", "content": ".", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - About custom targets.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - About custom targets", "url": "https://cloud.google.com/deploy/docs/custom-targets", "abstract": "# Cloud Deploy - About custom targets\nThis document describes how custom targets work in Cloud Deploy.\nCloud Deploy includes built-in support for various runtime environments as [targets](/deploy/docs/terminology#target) . But the list of supported target types is finite. With custom targets, you can deploy to other systems besides the supported runtimes.\nA custom target is a target that represents an arbitrary output environment other than a runtime that Cloud Deploy supports.\nThe page [Create a custom target](/deploy/docs/create-custom-target) describes the process of defining a custom target type and implementing it as a target in a delivery pipeline.\n#", "content": "## What goes into a custom target?\nEach custom target consists of the following components:\n- Custom actions, [defined in skaffold.yaml](/deploy/docs/create-custom-target#skaffold_define_action) These are similar to how you define [deploy hooks](/deploy/docs/hooks) . In the `skaffold.yaml` file, you define `customActions` , where each custom action identifies a container image to use, and commands to run on that container.In this way, the custom target is simply a custom-defined action or set of actions.For any custom target type, you configure a custom render action and a custom deploy action. These actions consume values provided by Cloud Deploy and must fulfill a [set of required outputs](#required_inputs_and_outputs) .The custom render action is optional, but you must create one unless your custom target will work correctly if rendered by `skaffold render` , which is the default for Cloud Deploy.\n- A [custom target type definition](/deploy/docs/create-custom-target#define_custom_target_type) The `CustomTargetType` is a Cloud Deploy resource that identifies the custom actions (separately defined in your `skaffold.yaml` ) that targets of this type use for release render and rollout deploy activities.\n- A [target definition](/deploy/docs/create-custom-target#define_target) The target definition for a custom target is the same as for any target type, except that it includes the `customTarget` property, whose value is the name of the `CustomTargetType` .\nWith those components in place, you can use the target as you would any target, referencing it from your delivery pipeline progression, and making full use of Cloud Deploy features, such as [promotion and approvals](/deploy/docs/promote-release) , and [rollbacks](/deploy/docs/roll-back) .\n### An example\nThe quickstart [Define and use a custom target type](/deploy/docs/deploy-app-custom-target) creates a custom target type that includes simple commands to run on a container image\u2014one command for render and one for deploy. The commands, in this case, just add text to the required output files for render and deploy.\nFor more examples, see [Custom target examples](#custom_target_examples) .\n## Required inputs and outputs\nAny custom target type defined for Cloud Deploy must satisfy requirements for input and output, for both render and deploy. This section lists what inputs and outputs are required, and how they are provided.\nCloud Deploy provides the required inputs, for both render and deploy, as environment variables. The following sections list these inputs, as well as the outputs that your custom render and deploy actions must return.\nIn addition to the environment variables listed in this section, Cloud Deploy passes to your custom containers any [deploy parameters](/deploy/docs/parameters) you have set.\n### Inputs to render actions\nFor custom render actions, Cloud Deploy provides the following required inputs, as environment variables. For multi-phase rollouts ( [canary deployments](/deploy/docs/deployment-strategies/canary) ), Cloud Deploy provides these variables for each phase.\n- `CLOUD_DEPLOY_PROJECT`The Google Cloud project in which the custom target type is created.\n- `CLOUD_DEPLOY_LOCATION`The Google Cloud region for the custom target type.\n- `CLOUD_DEPLOY_DELIVERY_PIPELINE`The name of the Cloud Deploy delivery pipeline referencing the custom target type.\n- `CLOUD_DEPLOY_RELEASE`The name of the release for which the render operation is invoked.\n- `CLOUD_DEPLOY_TARGET`The name of the Cloud Deploy target that uses the custom target type.\n- `CLOUD_DEPLOY_PHASE`The [rollout phase](/deploy/docs/deployment-strategies/manage-rollout#phases) to which the render corresponds.\n- `CLOUD_DEPLOY_REQUEST_TYPE`For the custom render action, this is always `RENDER` .\n- `CLOUD_DEPLOY_FEATURES`A comma-separated list of Cloud Deploy features which the custom container must support. This variable is populated based on features configured in your delivery pipeline.If your implementation doesn't support the features in this list, we recommend that it fail during rendering.For [standard deployments](/deploy/docs/deployment-strategies#what_deployment_strategies_does_support) , this is empty. For canary deployments, the value is `CANARY` . If the value provided by Cloud Deploy is `CANARY` , your render action is invoked for each phase in the canary. The canary percentage for each phase is provided in the `CLOUD_DEPLOY_PERCENTAGE_DEPLOY` environment variable.\n- `CLOUD_DEPLOY_PERCENTAGE_DEPLOY`The percentage of deployment associated with this render operation. If the `CLOUD_DEPLOY_FEATURES` environment variable is set to `CANARY` , your custom render action is called for each phase, and this variable is set to the canary percentage for each phase. For [standard deployments](/deploy/docs/deployment-strategies#what_deployment_strategies_does_support) and for canary deployments that have reached the `stable` phase, this is `100` .\n- `CLOUD_DEPLOY_STORAGE_TYPE`The storage provider. Always `GCS` .\n- `CLOUD_DEPLOY_INPUT_GCS_PATH`The Cloud Storage path for the render-file archive written when the release was created.\n- `CLOUD_DEPLOY_OUTPUT_GCS_PATH`The Cloud Storage path where the custom render container is expected to upload artifacts to be used for deployment. Note that the render action must upload a file named `results.json` containing the results of this render operation. For more information, see [Outputs from render action](#render_contract_outputs) .\n### Outputs from render action\nYour custom render action must provide the information described in this section. The information must be included in the results file, named `results.json` , located in the Cloud Storage bucket provided by Cloud Deploy.\n- Rendered configuration file or files\n- A `results.json` file, containing the following information:- An indication of the success or failure state of the custom action.Valid values are `SUCCEEDED` and `FAILED` .\n- (Optional) any error messages that are generated by the custom action.\n- The Cloud Storage path for the rendered configuration file or files.The path for all the rendered configuration files is the full URI. You populate it partly using the value of the `CLOUD_DEPLOY_OUTPUT_GCS_PATH` [provided](#render_contract_inputs) by Cloud Deploy.You must provide the rendered configuration file, even if it's empty. The contents of the file can be anything, in any format, as long as it's consumable by your custom deploy action. We recommend this file be human readable, so that you and other users in your organization can view this file in the [release inspector](/deploy/docs/view-release) .If you need to examine the `results.json` file, for example for debugging, you can find the Cloud Storage URI to it in the Cloud Build logs.\n### Example render results file\nThe following is a sample `results.json` file output from a custom render action:\n```\n{\u00a0 resultStatus: \"SUCCEEDED\"\u00a0 manifestFile: \"gs://bucket/my-pipeline/release-001/rollout-a/01234/custom-output/manifest.yaml\" \u00a0\u00a0 failureMessage: \"\"}\n```\n### Inputs to deploy actions\nFor custom deploy actions, Cloud Deploy provides the following required inputs, as environment variables:\n- `CLOUD_DEPLOY_PROJECT`The Google Cloud project in which the custom target is created.\n- `CLOUD_DEPLOY_LOCATION`The Google Cloud region for the custom target type.\n- `CLOUD_DEPLOY_DELIVERY_PIPELINE`The name of the Cloud Deploy delivery pipeline referencing the target that uses the custom target type.\n- `CLOUD_DEPLOY_RELEASE`The name of the release for which the deploy operation is invoked.\n- `CLOUD_DEPLOY_ROLLOUT`The name of the Cloud Deploy rollout that this deploy is for.\n- `CLOUD_DEPLOY_TARGET`The name of the Cloud Deploy target that uses the custom target type.\n- `CLOUD_DEPLOY_PHASE`The [rollout phase](/deploy/docs/deployment-strategies/manage-rollout#phases) to which the deploy corresponds.\n- `CLOUD_DEPLOY_REQUEST_TYPE`For the custom deploy action, this is always `DEPLOY` .\n- `CLOUD_DEPLOY_FEATURES`A comma-separated list of Cloud Deploy features which the custom container must support. This variable is populated based on features configured in your delivery pipeline.If your implementation doesn't support the features in this list, we recommend that it fail during rendering.For [standard deployments](/deploy/docs/deployment-strategies#what_deployment_strategies_does_support) , this is empty. For canary deployments, the value is `CANARY` . If the value provided by Cloud Deploy is `CANARY` , your render action is invoked for each phase in the canary. The canary percentage for each phase is provided in the `CLOUD_DEPLOY_PERCENTAGE_DEPLOY` environment variable.\n- `CLOUD_DEPLOY_PERCENTAGE_DEPLOY`The percentage of deployment associated with this deploy operation. If the `CLOUD_DEPLOY_FEATURES` environment variable is set to `CANARY` , your custom deploy action is called for each phase, and this variable is set to the canary percentage for each phase. Your deploy action must run for each phase.\n- `CLOUD_DEPLOY_STORAGE_TYPE`The storage provider. Always `GCS` .\n- `CLOUD_DEPLOY_INPUT_GCS_PATH`The Cloud Storage path where the custom renderer wrote the rendered configuration files.\n- `CLOUD_DEPLOY_SKAFFOLD_GCS_PATH`The Cloud Storage path to the rendered Skaffold configuration.\n- `CLOUD_DEPLOY_MANIFEST_GCS_PATH`The Cloud Storage path to the rendered manifest file.\n- `CLOUD_DEPLOY_OUTPUT_GCS_PATH`The path to the Cloud Storage directory where the custom deploy container is expected to upload deploy artifacts. For more information, see [Outputs from deploy action](#deploy_contract_outputs) .\n### Outputs from deploy action\nYour custom deploy action must write a `results.json` output file. This file must be located in the Cloud Storage bucket provided by Cloud Deploy ( `CLOUD_DEPLOY_OUTPUT_GCS_PATH` ).\nThe file must include the following:\n- An indication of the success or failure state of the custom deploy action.The following are the valid statuses:- `SUCCEEDED`\n- `FAILED`\n- `SKIPPED` (for canary deployments where [canary phases are skipped](/deploy/docs/deployment-strategies/canary#skipped_phases) to go straight to `stable` .)\n- (Optional) A list of deploy artifact files, in the form of Cloud Storage pathsThe path is the full URI. You populate it partly using the value of the `CLOUD_DEPLOY_OUTPUT_GCS_PATH` [provided](#render_contract_inputs) by Cloud Deploy.Files listed here are populated in [job run resources](/deploy/docs/deployment-strategies/manage-rollout#jobs_and_job_runs) as deploy artifacts.\n- (Optional) A failure message, if the custom deploy action is unsuccessful (returning a `FAILED` state)This message is used to populate the `failure_message` on the [job run](/deploy/docs/deployment-strategies/manage-rollout#jobs_and_job_runs) for this deploy action.\n- (Optional) A skip message, to provide additional information if the action returns a `SKIPPED` status.\nIf you need to examine the `results.json` file, for example for debugging, you can find the Cloud Storage URI for it in the Cloud Build release render logs.\n### Example deploy results file\nThe following is a sample `results.json` file output from a custom deploy action:\n```\n{\u00a0 resultStatus: \"SUCCEEDED\"\u00a0 artifactFiles: [\u00a0 \u00a0 \"gs://bucket/my-pipeline/release-001/rollout-a/01234/custom-output/file1.yaml\",\u00a0 \u00a0 \"gs://bucket/my-pipeline/release-001/rollout-a/01234/custom-output/file2.yaml\",\u00a0 ]\u00a0 failureMessage: \"\"\u00a0 skipMessage: \"\"}\n```\n## Further information about custom actions\nHere are some things to keep in mind when setting up and using custom target types.\n### Executing the custom actions\nYour custom render and deploy actions run in the Cloud Deploy [execution environment](/deploy/docs/execution-environment) . You can't configure your custom actions to run on a Google Kubernetes Engine cluster.\n### Using remote, reusable Skaffold configs\nAs described in this document, you configure your custom action in the `skaffold.yaml` file provided at release creation. But you can also store Skaffold configs in a Git repository or in a Cloud Storage bucket and [reference them from your custom target type definition](/deploy/docs/create-custom-target#remote_skaffold) . This lets you use custom actions defined and stored in a single, shared location, instead of including the custom actions with each releases's `skaffold.yaml` file.\n### Custom targets and deployment strategies\nCustom targets are fully supported for [standard](/deploy/docs/terminology#standard_deployment_strategy) deployments.\nCloud Deploy supports [canary deployments](/deploy/docs/deployment-strategies/canary) as long as the custom renderer and deployer support the canary feature.\nYou must use [custom canary configuration](/deploy/docs/deployment-strategies/canary#custom) . [Automated and custom-automated](/deploy/docs/deployment-strategies/canary#types_of_canary) canaries are not supported.\n### Custom targets and deploy parameters\nYou can use [deploy parameters](/deploy/docs/parameters) with custom targets. You can set them on the delivery pipeline [stage](/deploy/docs/parameters#add_to_pipeline_stage) , on the target that uses a custom target type, or on the [release](/deploy/docs/parameters#pass_to_releases_create) .\nDeploy parameters are passed to your custom render and deploy containers, as environment variables, in addition to [those already provided](#required_inputs_and_outputs) .\n## Custom target examples\nThe [cloud-deploy-samples repository](https://github.com/GoogleCloudPlatform/cloud-deploy-samples/tree/main/custom-targets/) contains a set of sample custom target implementations. The following samples are available:\n- GitOps\n- Vertex AI\n- Terraform\n- Infrastructure Manager\n- Helm\nEach sample includes a quickstart.\nThese samples are not a supported Google Cloud product, and are not covered by a Google Cloud support contract. To report bugs or request features in a Google Cloud product, contact Google Cloud support.\n## What's next\n- Now that you know about custom targets, find out how to [configure and use them](/deploy/docs/create-custom-target) .\n- Try the [quickstart: Define and use a custom target type](/deploy/docs/deploy-app-custom-target) .\n- Learn more about [configuring Cloud Deploy targets](/deploy/docs/config-files#target_definitions) .\n- Learn about Cloud Deploy [execution environments](/deploy/docs/execution-environment) .", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - About the automation resource.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - About the automation resource", "url": "https://cloud.google.com/deploy/docs/automation-resource", "abstract": "# Cloud Deploy - About the automation resource\nThis document describes the Cloud Deploy resources used to execute [automations](/deploy/docs/automation) .\nYou can configure Cloud Deploy to automatically perform certain delivery pipeline tasks, such as promote a release or advance a rollout to a given phase. These automations rely on two Cloud Deploy resources:\n- The `Automation` itself\n- The `AutomtationRun`\nThese resources are described in this document.\n", "content": "## The Automation resource\nAn `Automation` is a Cloud Deploy resource that defines how to automate one or more delivery pipeline tasks. The `Automation` associates one or more target resources with one or more automation `rules` .\nThe `Automation` resource includes the following:\n- A reference to the target against which to perform the automation (the `selector` ).\n- An automation rule that determines how to do the automation.\n- Metadata, such as `description` , `annotations` , and `labels` .\n- A `suspended` property.\n- The service account to use to perform the automation. The service account is required, and it must have the [necessary permissions](/deploy/docs/automation#roles_and_permissions_required) to perform the automation. Automation doesn't assume a default service account.\nThe `Automation` resource is a child resource of the [delivery pipeline](/deploy/docs/architecture#resources) ; if you [delete a delivery pipeline](/deploy/docs/delete-pipeline) , all automations that are children of that pipeline are also deleted.\nThe [configuration file schema](/deploy/docs/config-files#automation_definitions) describes how to configure the `Automation` .\n## The AutomationRun resource\nAn `AutomationRun` represents an execution of an [automation rule](/deploy/docs/automation-rules) .\n## The automation service account\nThe service account you use to invoke an automation can be the [default service account](/deploy/docs/cloud-deploy-service-account#execution_service_account) or another service account. However, even if you're using the default service account, you must specify it, using the `serviceAccount` property in the `Automation` configuration.\nThe automation service account must have `actAs` permission on the [applicable execution service account](/deploy/docs/cloud-deploy-service-account#execution_service_account) . Also, if the automation service account isn't in the same project as the delivery pipeline, the Cloud Deploy [service agent](/deploy/docs/cloud-deploy-service-account#service_agent) must have `actAs` on the automation service account.\n### Required permissions on the automation service account\nWhether you specify the default or a non-default service account for an automation, the service account must have the following permissions:\n- Permission to `actAs` the [execution service account](/deploy/docs/cloud-deploy-service-account#execution_service_account) .\n- [Permissions](/deploy/docs/iam-roles-permissions#permissions) to perform the operations that are being automated ( `clouddeploy.rollouts.advance` , `clouddeploy.releases.promote` , for example).## What's next\n- Try the [quickstart: Automate release creation and rollout advancement](/deploy/docs/deploy-app-automation) .\n- Read about [automation rules](/deploy/docs/automation-rules) .", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Access and use platform logs.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Access and use platform logs", "url": "https://cloud.google.com/deploy/docs/platform-logs", "abstract": "# Cloud Deploy - Access and use platform logs\nThis page describes how to view [platform logs](/logging/docs/api/platform-logs) generated by Cloud Deploy. Platform logs in Google Cloud are service-specific logs, which you can use to debug and troubleshoot issues, and better understand the Google Cloud services you're using.\nCloud Deploy generates logs for the following events:\n- Release render state changes to in-progress, succeeded, and failed\n- Rollout state changes to in-progress, succeeded, failed, halted, canceling, and canceled\n- Rollout state changes to pending [approval](/deploy/docs/promote-release#manage_approvals_for_a_delivery_pipeline) , approved, and rejected\n- [Phase advancement](/deploy/docs/deployment-strategies/manage-rollout#advance_rollout) in rollouts, including phases that have been advanced, and phases that are waiting for advancement\n- Failure to send a Pub/Sub notification for a status change, for the following resource types:- delivery pipelines\n- targets\n- releases\n- rollouts\n- job runs\n", "content": "## Access the platform logs generated by Cloud Deploy\n- Open the Google Cloud Observability [Logs Explorer page](/logging/docs/view/logs-explorer-interface) in Google Cloud console.\n- In the [query pane](/logging/docs/view/logs-explorer-interface#query-builder) , click the **Log name** drop-down, and enter the **Log ID** of the platform log you want to see.You can get the Log ID from the [list in the platform logs page](/logging/docs/api/platform-logs#cloud_deploy) .\n- Select that log, and click **Apply** .Available logs are listed in the **Query results** .\n- To view the contents of that log, click the arrow next to any log listed in the query results.## What's next\n- [Learn how to set up alerting policies](/deploy/docs/alerts) .", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Audit logging.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Audit logging", "url": "https://cloud.google.com/deploy/docs/audit-logs", "abstract": "# Cloud Deploy - Audit logging\nThis page describes the audit logs created for Cloud Deploy activity.\n", "content": "## Audit logging summary\nGoogle Cloud services write audit logs to help you answer the questions of \"who did what, where, and when?\" within your Google Cloud projects and organizations.\nFor Cloud Deploy, only admin activity is logged for auditing purposes. This audit information is provided by default. Admin activity consists of operations that modify the configuration or metadata of a Cloud Deploy resource. Any API call that creates, updates, or deletes a Cloud Deploy resource is not included in admin logging.\nFor more information, see [Cloud Audit Logs](/logging/docs/audit) .\n## Audited operations\nThe following is a list of the Cloud Deploy operations that are logged for auditing:\n- `projects.locations.customTargetTypes.create`\n- `projects.locations.customTargetTypes.delete`\n- `projects.locations.customTargetTypes.update`\n- `projects.locations.deliveryPipelines.create`\n- `projects.locations.deliveryPipelines.delete`\n- `projects.locations.deliveryPipelines.setIamPolicy`\n- `projects.locations.deliveryPipelines.update`\n- `projects.locations.deliveryPipelines.automation.create`\n- `projects.locations.deliveryPipelines.automation.delete`\n- `projects.locations.deliveryPipelines.automation.setIamPolicy`\n- `projects.locations.deliveryPipelines.automation.update`\n- `projects.locations.deliveryPipelines.automationRuns.cancel`\n- `projects.locations.deliveryPipelines.releases.create`\n- `projects.locations.deliveryPipelines.releases.rollouts.advance`\n- `projects.locations.deliveryPipelines.releases.rollouts.approve`\n- `projects.locations.deliveryPipelines.releases.rollouts.cancel`\n- `projects.locations.deliveryPipelines.releases.rollouts.create`\n- `projects.locations.deliveryPipelines.releases.rollouts.ignoreJob`\n- `projects.locations.deliveryPipelines.releases.rollouts.jobRuns.terminate`\n- `projects.locations.deliveryPipelines.releases.rollouts.retryJob`\n- `projects.locations.targets.create`\n- `projects.locations.targets.delete`\n- `projects.locations.targets.setIamPolicy`\n- `projects.locations.targets.update`\nUnlike audit logs for other services, Cloud Deploy only has `ADMIN_READ` and `ADMIN_WRITE` data access logs and does not offer `DATA_READ` and `DATA_WRITE` logs. `DATA_READ` and `DATA_WRITE` logs are only used for services that store and manage user data, and Cloud Deploy considers its resources to be administrative configuration information.\n## Permissions for accessing the logs\nThe following users can view admin activity logs:\n- [Project owners, editors, and viewers](/iam/docs/understanding-roles#basic) .\n- Users with the [Logs Viewer](/logging/docs/access-control#permissions_and_roles) IAM role.\n- Users with the`logging.logEntries.list`IAM permission.\nSee [IAM roles and permissions](/deploy/docs/iam-roles-permissions) for more information.\n## Audit log format\nAudit log entries have the following structure:\n- An object of type [LogEntry](/logging/docs/reference/v2/rest/v2/LogEntry) that contains the entire log entry.\n- An object of type [AuditLog](/logging/docs/reference/audit/auditlog/rest/Shared.Types/AuditLog) that is held in the`protoPayload`field of the`LogEntry`object.\nKnowing what information is held in these objects helps you understand and retrieve your audit log entries using the Logs Explorer and the Cloud Logging API.\nAll audit log entries contain the name of an audit log, a resource, and a service:\n- **logName** : This field indicates whether the log is an Admin Activity or Data Access audit log. For Cloud Deploy, these are admin activity only. For example:```\nprojects/[PROJECT_ID]/logs/cloudaudit.googleapis.com/activityorganizations/[ORGANIZATION_ID]/logs/cloudaudit.googleapis.com/activity\n```Within a project or organization, these log names are suffixed with the abbreviated `activity` .\n- **serviceName** : For Cloud Deploy, the field contains `clouddeploy.googleapis.com` .Resource types belong to a single service, but a service can have several resource types. For a list of services and resources, see [Mapping services to resources](/logging/docs/api/v2/resource-list#service-names) .\nFor more details, see [Audit Log Datatypes](/logging/docs/audit/api) .\n## Enabling logs\nAdmin activity logs are enabled and logged by default. These logs do not count toward your [log ingestion quota](/logging/quota-policy) . By default, data access logs are not recorded, but you can [configure them](/logging/docs/audit/configure-data-access) to be recorded.\n## Quotas and limits\nFor information about limitations on Logging, see [Quotas and Limits](/logging/quotas) .\n## Viewing logs\nTo view a summary of your Admin Activity:\n- Open Google **Cloud Activity** : [Go to Activity](https://console.cloud.google.com/home/activity) \nTo select and filter your logs and view them in detail:\n- Open the **Logs Explorer page** : [Go to the Logs Explorer page](https://console.cloud.google.com/logs/query) \n- In the Logs Explorer, select the **Resource** whose audit logs you want to see.\n- In the **Log name** drop-down, select the name of the log you want to see.Select **Activity** for Admin Activity audit logs, and **data_access** for Data Access audit logs (if the logs are available).The audit logs are shown in the Logs Explorer.\nYou can also use the Logs Explorer advanced filter interface to specify the resource type and log name. For more information, see [Retrieving audit logs](/logging/docs/audit/api#retrieving_audit_logs) .\n## Exporting your audit logs\nYou can export copies of some or all of your logs to other applications, other repositories, or third parties. To export your logs, see [Exporting logs](/logging/docs/export) .\nAn organization can create an aggregated sink that can export log entries from all the projects, folders, and billing accounts of the organization. Like any sink, your aggregated sink contains a filter that selects individual log entries. To aggregate and export your audit logs, see [Aggregated sinks](/logging/docs/export/aggregated_sinks) .\nTo read your log entries through the API, see [entries.list](/logging/docs/reference/v2/rest/v2/entries/list) . To read your log entries using the SDK, see [Reading log entries](/sdk/gcloud/reference/logging/read) .\n## What's next\n- Read the [Logs Explorer](/logging/docs/view/logs_viewer) page for instructions on filtering logs.\n- Read [Configure and manage sinks](/logging/docs/export/configure_export_v2) page for instructions on exporting logs.", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Automate release promotion and rollout advancement in Cloud Deploy.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Automate release promotion and rollout advancement in Cloud Deploy", "url": "https://cloud.google.com/deploy/docs/deploy-app-automation", "abstract": "# Cloud Deploy - Automate release promotion and rollout advancement in Cloud Deploy\n# Automate release promotion and rollout advancement in Cloud Deploy\nThis page shows you how to use Cloud Deploy to automatically promote a release to a target and advance a rollout to its next phase.\nIn this quickstart, you'll do the following:- Create two GKE clusters or two Cloud Run services.\n- Create a [Skaffold](/skaffold) configuration and either a Kubernetes manifest or a Cloud Run service definition.\n- Define your Cloud Deploy delivery pipeline and deployment targets.The pipeline will deploy to two targets: `dev` and `staging` . And the `staging` target uses a [canary deployment strategy](/deploy/docs/deployment-strategies/canary) .\n- Define two automation rules:- An automation to promote the release into the `staging` target on successful rollout to `dev` .\n- An automation to advance the rollout to the `stable` phase upon successful completion of the `canary-25` ` phase.\n- Instantiate your delivery pipeline by creating a release, which automatically deploys to the `dev` target.\n- View the delivery pipeline and release in the Google Cloud console.Because of the automated promotion, this release is promoted into the `staging` automatically.Because the `staging` target uses a canary deployment strategy, and this is the first deployment into that runtime, the `canary-25` phase is skipped. See [Why phases are sometimes skipped](/deploy/docs/deployment-strategies#skip_phases) to understand more about why the canary phase is skipped the first time.Because of the automated phase-advance, the rollout is advanced to the `stable` phase.\n", "content": "## Before you begin- If you already have the CLI installed, make sure you're running the latest version:\n- ```\ngcloud components update\n```\n- Make sure the [default Compute Engine service account](/deploy/docs/cloud-deploy-service-account#execution_service_account) has sufficient permissions.The service account might already have the necessary permissions. These steps are included for projects that disable automatic role grants for default service accounts.- First add the`clouddeploy.jobRunner`role:```\ngcloud projects add-iam-policy-binding PROJECT_ID \\\n --member=serviceAccount:$(gcloud projects describe PROJECT_ID \\\n --format=\"value(projectNumber)\")-compute@developer.gserviceaccount.com \\\n --role=\"roles/clouddeploy.jobRunner\"\n```\n- Add the`clouddeploy.releaser`role:```\ngcloud projects add-iam-policy-binding PROJECT_ID \\\n --member=serviceAccount:$(gcloud projects describe PROJECT_ID \\\n --format=\"value(projectNumber)\")-compute@developer.gserviceaccount.com \\\n --role=\"roles/clouddeploy.releaser\"\n```\n- Add the developer role for your specific runtime.\n- For GKE:```\ngcloud projects add-iam-policy-binding PROJECT_ID \\\n --member=serviceAccount:$(gcloud projects describe PROJECT_ID \\\n --format=\"value(projectNumber)\")-compute@developer.gserviceaccount.com \\\n --role=\"roles/container.developer\"\n```\n- For Cloud Run:```\ngcloud projects add-iam-policy-binding PROJECT_ID \\\n --member=serviceAccount:$(gcloud projects describe PROJECT_ID \\\n --format=\"value(projectNumber)\")-compute@developer.gserviceaccount.com \\\n --role=\"roles/run.developer\"\n```\n- Add the`iam.serviceAccountUser`role, which includes the`actAs`permission for the default service account to deploy to the runtime:```\ngcloud iam service-accounts add-iam-policy-binding $(gcloud projects describe PROJECT_ID \\\n --format=\"value(projectNumber)\")-compute@developer.gserviceaccount.com \\\n --member=serviceAccount:$(gcloud projects describe PROJECT_ID \\\n --format=\"value(projectNumber)\")-compute@developer.gserviceaccount.com \\\n --role=\"roles/iam.serviceAccountUser\" \\\n --project=PROJECT_ID\n```\n- Add the`iam.serviceAccountUser`role, including`actAs`permission for yourself, to use the default service account:```\ngcloud iam service-accounts add-iam-policy-binding $(gcloud projects describe PROJECT_ID \\\n --format=\"value(projectNumber)\")-compute@developer.gserviceaccount.com \\\n --member=user:YOUR_EMAIL_ADDRESS \\\n --role=\"roles/iam.serviceAccountUser\" \\\n --project=PROJECT_ID\n```In this case, is the email address you use to access Google Cloud.## Create your runtime environments **If you're deploying to Cloud Run, you can skip this command** .\nFor GKE, create two clusters: `automation-quickstart-cluster-dev` and `automation-quickstart-cluster-staging` , with default settings. The clusters' Kubernetes API endpoints must be network-reachable from the public internet. GKE clusters are externally accessible by default.\n```\ngcloud container clusters create-auto automation-quickstart-cluster-dev \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--project=PROJECT_ID \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--region=us-central1 \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0&& gcloud container clusters create-auto automation-quickstart-cluster-staging \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--project=PROJECT_ID \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--region=us-central1\n```## Get your project number.You need your project number to identify the default service account. This is necessary for configuring the automation resource.- Run the following command to get your project number:```\ngcloud projects describe PROJECT_ID\n```\n- Copy the project number from the command-line output, and paste it here.You don't need to run this as a command. Pasting it here populates the service account reference in the automation config later in this quickstart.```\nPROJECT_NUMBER\n```\n## Prepare your Skaffold configuration and application manifestCloud Deploy uses [Skaffold](/deploy/docs/using-skaffold) to provide the details for what to deploy and how to deploy it properly for your separate [targets](/deploy/docs/terminology#target) .\nIn this quickstart, you create a `skaffold.yaml` file, which identifies the application manifest to be used to deploy the sample app.- Open a terminal window.\n- Create a new directory and navigate into it.\n```\nmkdir deploy-automation-gke-quickstartcd deploy-automation-gke-quickstart\n```\n```\nmkdir deploy-automation-run-quickstartcd deploy-automation-run-quickstart\n```\n- Create a file named `skaffold.yaml` with the following contents:\n```\napiVersion: skaffold/v4beta7kind: Configmetadata:\u00a0 name: gke-automationmanifests:\u00a0 rawYaml:\u00a0 - k8s-deployment.yamldeploy:\u00a0 kubectl: {}\n```\n```\napiVersion: skaffold/v4beta7kind: Configmetadata:\u00a0 name: run-automationprofiles:- name: dev\u00a0 manifests:\u00a0 \u00a0 rawYaml:\u00a0 \u00a0 - run-dev.yaml- name: staging\u00a0 manifests:\u00a0 \u00a0 rawYaml:\u00a0 \u00a0 - run-staging.yamldeploy:\u00a0 cloudrun: {}\n```\nThis file is a minimal Skaffold config. For this quickstart, you create the file. But you can also [have Cloud Deploy create one for you](/deploy/docs/using-skaffold/getting-started-skaffold#have_generate_your_skaffoldyaml) , for simple, non-production applications.See the [skaffold.yaml reference](https://skaffold.dev/docs/references/yaml/) for more information about this file.\n- Create the definition for your application\u2014a pair of service definitions for Cloud Run or a Kubernetes manifest for GKE.\nCreate a file named `k8s-deployment.yaml` , with the following contents:\n```\napiVersion: apps/v1kind: Deploymentmetadata:\u00a0 name: my-deployment\u00a0 labels:\u00a0 \u00a0 app: my-app\u00a0 namespace: defaultspec:\u00a0 replicas: 1\u00a0 selector:\u00a0 \u00a0 matchLabels:\u00a0 \u00a0 \u00a0 app: my-app\u00a0 template:\u00a0 \u00a0 metadata:\u00a0 \u00a0 \u00a0 labels:\u00a0 \u00a0 \u00a0 \u00a0 app: my-app\u00a0 \u00a0 spec:\u00a0 \u00a0 \u00a0 containers:\u00a0 \u00a0 \u00a0 - name: nginx\u00a0 \u00a0 \u00a0 \u00a0 image: my-app-image---apiVersion: v1kind: Servicemetadata:\u00a0 name: my-service\u00a0 namespace: defaultspec:\u00a0 selector:\u00a0 \u00a0 app: my-app\u00a0 ports:\u00a0 \u00a0 - protocol: TCP\u00a0 \u00a0 \u00a0 port: 80\n```\nThis file is a simple Kubernetes [manifest](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-manifest) , which is applied to the cluster to deploy the application.- Create a file named `run-dev.yaml` , with the following contents:```\napiVersion: serving.knative.dev/v1kind: Servicemetadata:\u00a0 name: my-automation-run-service-devspec:\u00a0 template:\u00a0 \u00a0 spec:\u00a0 \u00a0 \u00a0 containers:\u00a0 \u00a0 \u00a0 - image: my-app-image\n```\n- Create a file named `run-staging.yaml` , with the following contents:```\napiVersion: serving.knative.dev/v1kind: Servicemetadata:\u00a0 name: my-automation-run-service-stagingspec:\u00a0 template:\u00a0 \u00a0 spec:\u00a0 \u00a0 \u00a0 containers:\u00a0 \u00a0 \u00a0 - image: my-app-image\n```\nThis file is a simple Cloud Run service definition, which is used at deploy time to create your Cloud Run service.\n## Create your delivery pipeline, targets, and automationYou can define your delivery pipeline and targets in one file or in separate files. You can also define an automation action in a separate file. This quickstart uses one file for the pipeline, targets, and automation.- Create your delivery pipeline, target definitions, and automation action:\nIn the `deploy-automation-gke-quickstart` directory, create a new file: `clouddeploy.yaml` , with the following contents:\n```\napiVersion: deploy.cloud.google.com/v1kind: DeliveryPipelinemetadata:\u00a0 name: my-automation-demo-app-1description: Automation demonstration pipelineserialPipeline:\u00a0 stages:\u00a0 - targetId: automation-quickstart-dev\u00a0 - targetId: automation-quickstart-staging\u00a0 \u00a0 profiles: []\u00a0 \u00a0 strategy:\u00a0 \u00a0 \u00a0 canary:\u00a0 \u00a0 \u00a0 \u00a0 runtimeConfig:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 kubernetes:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 serviceNetworking:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 service: \"my-service\"\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 deployment: \"my-deployment\"\u00a0 \u00a0 \u00a0 \u00a0 canaryDeployment:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 percentages: [25]\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 verify: false---apiVersion: deploy.cloud.google.com/v1kind: Targetmetadata:\u00a0 name: automation-quickstart-devdescription: Dev cluster to demonstrate deploy automationgke:\u00a0 cluster: projects/PROJECT_ID/locations/us-central1/clusters/automation-quickstart-cluster-dev---apiVersion: deploy.cloud.google.com/v1kind: Targetmetadata:\u00a0 name: automation-quickstart-stagingdescription: Staging cluster to demonstrate deploy automationgke:\u00a0 cluster: projects/PROJECT_ID/locations/us-central1/clusters/automation-quickstart-cluster-staging---apiVersion: deploy.cloud.google.com/v1kind: Automationmetadata:\u00a0 name: my-automation-demo-app-1/promotedescription: promotes a releasesuspended: falseserviceAccount: PROJECT_NUMBER-compute@developer.gserviceaccount.comselector:- target:\u00a0 \u00a0 id: automation-quickstart-devrules:- promoteRelease:\u00a0 \u00a0 name: \"promote-release\"\u00a0 \u00a0 wait: 1m\u00a0 \u00a0 toTargetId: \"@next\"---apiVersion: deploy.cloud.google.com/v1kind: Automationmetadata:\u00a0 name: my-automation-demo-app-1/advancedescription: advances a rolloutsuspended: falseserviceAccount: PROJECT_NUMBER-compute@developer.gserviceaccount.comselector:- target:\u00a0 \u00a0 id: automation-quickstart-stagingrules:- advanceRollout:\u00a0 \u00a0 name: \"advance-rollout\"\u00a0 \u00a0 sourcePhases: [\"canary-25\"]\u00a0 \u00a0 wait: 1m\n```\n **Note:** In this file, the targets and the automations config are included with the delivery pipeline, but you can define targets in a separate file or multiple separate files, and automations in a separate file or files.\nIn the `deploy-automation-run-quickstart` directory, create a new file: `clouddeploy.yaml` , with the following contents:\n```\napiVersion: deploy.cloud.google.com/v1kind: DeliveryPipelinemetadata:\u00a0 name: my-automation-demo-app-1description: Automation demonstration pipelineserialPipeline:\u00a0 stages:\u00a0 - targetId: automation-quickstart-dev\u00a0 \u00a0 profiles: [dev]\u00a0 - targetId: automation-quickstart-staging\u00a0 \u00a0 profiles: [staging]\u00a0 \u00a0 strategy:\u00a0 \u00a0 \u00a0 canary:\u00a0 \u00a0 \u00a0 \u00a0 runtimeConfig:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 cloudRun:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 automaticTrafficControl: true\u00a0 \u00a0 \u00a0 \u00a0 canaryDeployment:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 percentages: [25]\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 verify: false---apiVersion: deploy.cloud.google.com/v1kind: Targetmetadata:\u00a0 name: automation-quickstart-devdescription: Dev cluster to demonstrate deploy automationrun:\u00a0 location: projects/PROJECT_ID/locations/us-central1---apiVersion: deploy.cloud.google.com/v1kind: Targetmetadata:\u00a0 name: automation-quickstart-stagingdescription: Staging cluster to demonstrate deploy automationrun:\u00a0 location: projects/PROJECT_ID/locations/us-central1---apiVersion: deploy.cloud.google.com/v1kind: Automationmetadata:\u00a0 name: my-automation-demo-app-1/promotedescription: Promotes a release to the next targetsuspended: falseserviceAccount: PROJECT_NUMBER-compute@developer.gserviceaccount.comselector:- target:\u00a0 \u00a0 id: automation-quickstart-devrules:- promoteRelease:\u00a0 \u00a0 name: \"promote-release\"\u00a0 \u00a0 wait: 1m\u00a0 \u00a0 toTargetId: \"@next\"---apiVersion: deploy.cloud.google.com/v1kind: Automationmetadata:\u00a0 name: my-automation-demo-app-1/advancedescription: advances a rolloutsuspended: falseserviceAccount: PROJECT_NUMBER-compute@developer.gserviceaccount.comselector:- target:\u00a0 \u00a0 id: automation-quickstart-stagingrules:- advanceRollout:\u00a0 \u00a0 name: \"advance-rollout\"\u00a0 \u00a0 sourcePhases: [\"canary-25\"]\u00a0 \u00a0 wait: 1m\n```\n **Note:** In this file, the targets and the automations config are included with the delivery pipeline, but you can define targets in a separate file or multiple separate files, and automations in a separate file or files.\n- Register your pipeline and targets with the Cloud Deploy service:```\ngcloud deploy apply --file=clouddeploy.yaml --region=us-central1 --project=PROJECT_ID\n```You now have a pipeline, with one multi-target comprising two GKE or Cloud Run targets, ready to deploy your application.\n- Confirm your pipeline and targets:In the Google Cloud console, navigate to the Cloud Deploy **Delivery pipelines** page to view of list of your available delivery pipelines. [Open the Delivery pipelines page](https://console.cloud.google.com/deploy/delivery-pipelines) The delivery pipeline you just created is shown, with two targets listed in the **Targets** column.\n- Click the pipeline name to open the delivery pipeline visualization and details.\n- Select the **Automations** tab, under **Delivery pipeline details** .The two automations you created are shown.\n## Create a releaseA release is the central Cloud Deploy resource representing the changes being deployed. The delivery pipeline defines the lifecycle of that release. See [Cloud Deploy service architecture](/deploy/docs/architecture#how_they_fit_together_to_deliver_your_release) for details about that lifecycle.\nRun the following command from the `deploy-automation-gke-quickstart` directory to create a `release` resource that represents the container image to deploy:\n```\n\u00a0gcloud deploy releases create test-release-001 \\\u00a0 \u00a0--project=PROJECT_ID \\\u00a0 \u00a0--region=us-central1 \\\u00a0 \u00a0--delivery-pipeline=my-automation-demo-app-1 \\\u00a0 \u00a0--images=my-app-image=gcr.io/google-containers/nginx@sha256:f49a843c290594dcf4d193535d1f4ba8af7d56cea2cf79d1e9554f077f1e7aaa\n```\nRun the following command from the `deploy-automation-run-quickstart` directory to create a `release` resource that represents the container image to deploy:\n```\n\u00a0gcloud deploy releases create test-release-001 \\\u00a0 \u00a0--project=PROJECT_ID \\\u00a0 \u00a0--region=us-central1 \\\u00a0 \u00a0--delivery-pipeline=my-automation-demo-app-1 \\\u00a0 \u00a0--images=my-app-image=us-docker.pkg.dev/cloudrun/container/hello@sha256:6063adf8f687702b4065151acddba6781c47bc602167eb9f3bec8aebc9ce95cc\n```By default, when you create a release, a rollout is created automatically for the first target in your pipeline.\nBecause this quickstart includes two automations, two things happen automatically:- After a successful deployment in the first target, the release is automatically promoted to the second target.There is a one-minute wait time on the promote automation.\n- In the second target, where there is a 25% canary configured, the second automation advances the rollout from `canary-25` to `stable` .For this first release, the `canary-25` phase is skipped, because there is no pre-existing version of the app to canary agains. And the rollout is automatically advanced to `stable` .There is a one-minute delay on the advance automation.\nWhen everything finishes, the application is deployed to successfully to both targets without you having to do anything further.\nIf you want to know more about running a canary deployment strategy, you can try the [canary quickstart](/deploy/docs/deploy-app-canary) .## View the results in Google Cloud consoleYou can view the results, including the automation runs, in the Google Cloud console.- Navigate to the Cloud Deploy **Delivery pipelines** page to view your delivery pipeline. [Open the Delivery pipelines page](https://console.cloud.google.com/deploy/delivery-pipelines) \n- Click the name of your delivery pipeline \"my-automation-demo-app-1\".The pipeline visualization shows the app's deployment status. If enough time has elapsed, both targets will show green.And your release is listed on the **Releases** tab under **Delivery pipelinedetails** .\n- Click the **Automation runs** tab.There are two entries, one for each of the two automations you created. You can click either one to see the details of that automation run.\n## Clean upTo avoid incurring charges to your Google Cloud account for   the resources used on this page, follow these steps.- Delete the GKE clusters or Cloud Run services:\n```\ngcloud container clusters delete automation-quickstart-cluster-dev --region=us-central1 --project=PROJECT_ID \\&& gcloud container clusters delete automation-quickstart-cluster-staging --region=us-west1 --project=PROJECT_ID\n```\n```\ngcloud run services delete my-automation-run-service-dev --region=us-central1 --project=PROJECT_ID \\&& gcloud run services delete my-automation-run-service-staging --region=us-central1 --project=PROJECT_ID\n```\n- Delete the delivery pipeline, targets, automations, release, and rollouts:```\ngcloud deploy delete --file=clouddeploy.yaml --force --region=us-central1 --project=PROJECT_ID\n```\n- Delete the Cloud Storage buckets that Cloud Deploy created.One ends with `_clouddeploy` , and the other is `[region].deploy-artifacts.[project].appspot.com` . [Open the Cloud Storage browser page](https://console.cloud.google.com/storage/browser) \nThat's it, you completed this quickstart!## What's next\n- [Learn more about Cloud Deploy](/deploy/docs/overview) .\n- [Learn the basics of deploying applications](/deploy/docs/deploying-application) .\n- [Try out the Cloud Deploy walkthrough](https://shell.cloud.google.com/?show=ide%2Cterminal&walkthrough_id=deploy--cloud-deploy-e2e-gke) .\n- [Learn how to combine Google Cloud CI/CD tools to develop and deliversoftware effectively to GKE](https://cloud.google.com/architecture/app-development-and-delivery-with-cloud-code-gcb-cd-and-gke) .", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Automate your deployment.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Automate your deployment", "url": "https://cloud.google.com/deploy/docs/automation", "abstract": "# Cloud Deploy - Automate your deployment\nThis document is an overview of deploy automation.\nYou can configure Cloud Deploy to automatically perform release-related and rollout-related tasks for a given delivery pipeline. These tasks include [release promotion](/deploy/docs/automation-rules#configuring_a_promoterelease_automation_rule) and [phase advancement](/deploy/docs/automation-rules#configuring_an_advancerollout_automation_rule) .\n[Learn more](/deploy/docs/automation-resource) about the resources used for release automation in Cloud Deploy.\n[Learn more](/deploy/docs/automation-rules) about how to set up the rules that define how these automations work.\n", "content": "## Actions you can automate\nIn Cloud Deploy, you can automate the following release and rollout activities:\n- Promote a releaseYou can configure Cloud Deploy to promote your release automatically, upon a successful rollout to a target. For example, if you have three targets, `dev` , `staging` , and `prod` , you can configure an automation such that the release is promoted to `prod` , without further human interaction, upon a successful deployment into `staging` .\n- Advance a rolloutYou can configure Cloud Deploy to advance a rollout from one [phase](/deploy/docs/deployment-strategies/manage-rollout#phases) to the next, after a successful rollout to the previous target. Phase advancement is available only in targets that use a [canary deployment strategy](/deploy/docs/deployment-strategies/canary) .## How does automation work?\nEach automation is tied to the delivery pipeline for which it's used. You can't share an automation across multiple delivery pipelines.\nThe following is the general process for configuration and execution of an automation:\n- You [configure an Automation](/deploy/docs/config-files#automation_definitions) This automation is associated with one delivery pipeline.\n- You register that automation using `gcloud deploy apply` .This creates the [Automation resource](/deploy/docs/automation-resource#the_automation_resource) .\n- You invoke the delivery pipeline associated with this automation by [creating a release](/deploy/docs/deploying-application#invoke_your_delivery_pipeline_to_create_a_release) .\n- The rollout is successful into at least one target.\n- In the target that this automation is configured for...If the automation is `promoteRelease` :- Execution waits for the rollout to succeed into the source target. The source target is the `selector.target` configured for the automation, not in the `AutomationRule` .\n- If there is a `wait` time configured, execution waits for that time also.\n- The release is automatically promoted to the next target in the pipeline progression, or to a specific target, [if indicated](/deploy/docs/automation-rules#promoterelease_rule) .\nIf the automation is `advanceRollout` and the target uses a canary deployment strategy:- Execution waits for the identified [source phase](/deploy/docs/automation-rules#advancerollout_rule) , if there is one.The `sourcePhase` property is optional, and if no source phases are specified, each phase in the rollout is advanced automatically. The automatic phase advancement happens when the source phase is `IN_PROGRESS` , subject to `wait` time.\n- If there is a `wait` time configured, execution waits for that time also.When you're automating a canary deployment, you use this wait time to specify the duration of each canary phase.\n- The rollout is automatically advanced from that source phase to the next phase in the rollout.\n- If there's an additional source phase, it's treated the same, including the same wait time, if applicable.\n### Automation resources\nThere are two Cloud Deploy resources that are specifically for automation:\n- AutomationAn `Automation` is a child resource of a delivery pipeline, and it includes the following information:- A pointer to the target or targets for which the automation is used\n- The rule or rules that govern what the automation does and how it does it\nConfiguration for the Automation resource is described in the document [About the automation resource](/deploy/docs/automation-resource) .When you run `gcloud deploy apply` against a file that includes an automation configuration ( `kind: Automation` ), Cloud Deploy creates an [automation resource](/deploy/docs/automation-resource#the_automation_resource) , which associates a delivery pipeline and a target or targets with one or more [automation rules](/deploy/docs/automation-rules) .\n- Automation runThe `AutomationRun` is an instance of an automation. It's a pointer to its corresponding Automation resource, plus information about the rollout that spawned it, and other metadata.The automation run is created when an automation is triggered.\n[Learn more about automation resources](/deploy/docs/automation-resource) .\n### Automation rules\nAn automation rule defines an action that can be taken on your delivery pipeline automatically, as well as details about how the automation is to be performed.\n[Learn more about automation rules](/deploy/docs/automation-rules) .\n### Identity and Access Management roles and permissions required\nIn addition to the permissions you need to run any Cloud Deploy delivery pipeline, and to perform the tasks to be automated (like advancing a rollout), there are several permissions that are needed in order to perform certain operations on the `Automation` and `AutomationRun` resources:\n- `clouddeploy.automations.create`\n- `clouddeploy.automations.delete`\n- `clouddeploy.automations.get`\n- `clouddeploy.automations.list`\n- `clouddeploy.automations.update`\n- `clouddeploy.automationRuns.cancel`\n- `clouddeploy.automationRuns.get`\n- `clouddeploy.automationRuns.list`\nSee [IAM roles and permissions](/deploy/docs/iam-roles-permissions) For more information, including which Cloud Deploy [roles including these permissions](/deploy/docs/iam-roles-permissions#predefined_roles) .\n## Create an automation\nYou can create an automation, including using any of the [available automation rules](/deploy/docs/automation-rules#available_automation_rules) , by configuring an automation, then creating the automation resource using `gcloud deploy apply`\nSee the following section (Configuring automation), and [Configuring automation rules](/deploy/docs/automation-rules#configuring_automation_rules) .\n### Configuring automation\nSee the [Configuration file schema](/deploy/docs/config-files#automation_definitions) for details on how to configure the [Automation resource](/deploy/docs/automation-resource#the_automation_resource) .\n### Automation rule configuration\nIn addition to this automation configuration, you specify [automation rules](/deploy/docs/automation-rules) . Configuration is different for each of the available rules.\nSee [Using automation rules](/deploy/docs/automation-rules) for descriptions of each of the available rules.\n## Suspend an automation\nYou can suspend an existing resource without deleting it. This can be useful for testing an automation without affecting the delivery pipeline. When you suspend an automation, the automation isn't run, but [platform logs](/deploy/docs/platform-logs) are still generated.\n- In the [Automation configuration](/deploy/docs/config-files#automation_definitions) , Update the `suspended` property to `true` .\n- Run `gcloud deploy apply` against that configuration file.\n- [Platform logs](/sdeploy/docs/platform-logs) are still generated when the automation is instantiated, even if it's suspended. You can use this to test and debug the automation without affecting the delivery pipeline.## What's next\n- Try the [quickstart: Automate release creation and rollout advancement](/deploy/docs/deploy-app-automation) .\n- [Learn more](/deploy/docs/automation-rules) about Cloud Deploy automation rules.\n- [Learn more](/deploy/docs/automation-resource) about Cloud Deploy automation resources.\n- See the [configuration file schema documentation](/deploy/docs/config-files#automation_definitions) for details on the automation configuration files.", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Canary-deploy an application to a target.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Canary-deploy an application to a target", "url": "https://cloud.google.com/deploy/docs/deploy-app-canary", "abstract": "# Cloud Deploy - Canary-deploy an application to a target\n# Canary-deploy an application to a target\nThis quickstart shows you how to use Cloud Deploy to deliver a sample application image in a canary deployment to either Google Kubernetes Engine or to Cloud Run. (You can also run a canary deployment [to GKE Enterprise](/deploy/docs/anthos-targets) , but only GKE and Cloud Run are shown in this quickstart.)\nA canary deployment splits traffic between an already-deployed version of the application and the new version. Cloud Run apportions traffic based on the percentages you configure in the delivery pipeline. GKE deploys the new version to a proportion of pods. This quickstart deploys to 50% first, then to 100%.\nIn this quickstart, there is only one [target](/deploy/docs/terminology#target) , ( `prod` ). So we create only one GKE cluster or one Cloud Run service to run your application.\nIn this quickstart, you'll do the following:- Create one GKE cluster or define one Cloud Run service.You can canary deploy to GKE Enterprise clusters too, but this quickstart uses GKE and Cloud Run only.\n- Create a [Skaffold](/skaffold) configuration and a Kubernetes manifest to specify the (pre-built) container image to deploy.\n- Define your Cloud Deploy delivery pipeline and deployment [target](/deploy/docs/terminology#target) .\n- Invoke your delivery pipeline by creating a release, which automatically deploys to one target.This first release [skips the canary phase](#we_skip_to_the_stable_phase) .\n- View the delivery pipeline and release in the Google Cloud console.\n- Create a second release, this time executing the canary stage to deploy the application to 50%.\n- Advance the release to deploy to 100%.\n", "content": "## Before you begin- If you already have the CLI installed, make sure you're running the latest version:\n- ```\ngcloud components update\n```\n- Make sure the [default Compute Engine service account](/deploy/docs/cloud-deploy-service-account#execution_service_account) has sufficient permissions.The service account might already have the necessary permissions. These steps are included for projects that disable automatic role grants for default service accounts.- First add the`clouddeploy.jobRunner`role:```\ngcloud projects add-iam-policy-binding PROJECT_ID \\\n --member=serviceAccount:$(gcloud projects describe PROJECT_ID \\\n --format=\"value(projectNumber)\")-compute@developer.gserviceaccount.com \\\n --role=\"roles/clouddeploy.jobRunner\"\n```\n- Add the developer role for your specific runtime.\n- For GKE, and GKE with Gateway API:```\ngcloud projects add-iam-policy-binding PROJECT_ID \\\n --member=serviceAccount:$(gcloud projects describe PROJECT_ID \\\n --format=\"value(projectNumber)\")-compute@developer.gserviceaccount.com \\\n --role=\"roles/container.developer\"\n```\n- For Cloud Run:```\ngcloud projects add-iam-policy-binding PROJECT_ID \\\n --member=serviceAccount:$(gcloud projects describe PROJECT_ID \\\n --format=\"value(projectNumber)\")-compute@developer.gserviceaccount.com \\\n --role=\"roles/run.developer\"\n```\n- Add the`iam.serviceAccountUser`role, which includes the`actAs`permission to deploy to the runtime:```\ngcloud iam service-accounts add-iam-policy-binding $(gcloud projects describe PROJECT_ID \\\n --format=\"value(projectNumber)\")-compute@developer.gserviceaccount.com \\\n --member=serviceAccount:$(gcloud projects describe PROJECT_ID \\\n --format=\"value(projectNumber)\")-compute@developer.gserviceaccount.com \\\n --role=\"roles/iam.serviceAccountUser\" \\\n --project=PROJECT_ID\n```\n## Create your runtime environment\nCreate one GKE [Autopilot](/deploy/docs/kubernetes-engine/docs/concepts/autopilot-overview) cluster:\n```\n\u00a0gcloud container clusters create-auto canary-quickstart-cluster \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 --project=PROJECT_ID \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 --region=us-central1\n```- Create one GKE cluster, with recommended settings to support using with Istio:```\ngcloud container clusters create canary-quickstart-cluster \\\u00a0 \u00a0 \u00a0 \u00a0--machine-type=n1-standard-1 \\\u00a0 \u00a0 \u00a0 \u00a0--num-nodes 4 \\\u00a0 \u00a0 \u00a0 \u00a0--region=us-central1 \\\u00a0 \u00a0 \u00a0 \u00a0--project=PROJECT_ID\n```\n- Get the cluster credentials:```\ngcloud container clusters get-credentials canary-quickstart-cluster \\\u00a0 \u00a0 \u00a0 \u00a0--project=PROJECT_ID \\\u00a0 \u00a0 \u00a0 \u00a0--region=us-central1\n```\n- Install the Kubernetes Gateway API CRDs if not already present on the cluster.```\nkubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v0.6.2/standard-install.yaml\n```\n- Enable Istio's Gateway controller implementation by installing Istio.```\ncurl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.17.2 sh - \\&& ./istio-1.17.2/bin/istioctl install --set profile=minimal -y\n```\nIf you're using Cloud Run, you can skip this command, you don't need to do anything here.## Prepare your Skaffold configuration and application manifestCloud Deploy uses [Skaffold](/deploy/docs/using-skaffold) to provide the details for what to deploy and how to deploy it properly to your [target](/deploy/docs/terminology#target) .\nIn this quickstart, you create a `skaffold.yaml` file, which identifies the Kubernetes manifest or Cloud Run service configuration to be deployed.- Open a terminal window.\n- Create a new directory and navigate into it.\n```\nmkdir deploy-canary-quickstart-gkecd deploy-canary-quickstart-gke\n```\n```\nmkdir deploy-canary-quickstart-gke-gatewayapicd deploy-canary-quickstart-gke-gatewayapi\n```\n```\nmkdir deploy-canary-quickstart-runcd deploy-canary-quickstart-run\n```\n- Create a file named `skaffold.yaml` with the following contents:\n```\napiVersion: skaffold/v4beta7kind: Configmanifests:\u00a0 rawYaml:\u00a0 - kubernetes.yamldeploy:\u00a0 kubectl: {}\n```\n```\napiVersion: skaffold/v4beta7kind: Configmanifests:\u00a0 rawYaml:\u00a0 - kubernetes.yamldeploy:\u00a0 kubectl: {}\n```\n```\napiVersion: skaffold/v4beta7kind: Configmanifests:\u00a0 rawYaml:\u00a0 - run.yamldeploy:\u00a0 cloudrun: {}\n```\nThis file is a minimal Skaffold config, identifying your manifest. For this quickstart, you create the file. But you can also [have Cloud Deploy create one for you](/deploy/docs/using-skaffold/getting-started-skaffold#have_generate_your_skaffoldyaml) , for simple, non-production applications.See the [skaffold.yaml reference](https://skaffold.dev/docs/references/yaml/) for more information about this file.\n- Create your application manifest.\nCreate a file named `kubernetes.yaml` , in the `deploy-canary-quickstart-gke` directory, with the following contents:\n```\napiVersion: apps/v1kind: Deploymentmetadata:\u00a0 name: my-deployment\u00a0 labels:\u00a0 \u00a0 app: my-app\u00a0 namespace: defaultspec:\u00a0 replicas: 1\u00a0 selector:\u00a0 \u00a0 matchLabels:\u00a0 \u00a0 \u00a0 app: my-app\u00a0 template:\u00a0 \u00a0 metadata:\u00a0 \u00a0 \u00a0 labels:\u00a0 \u00a0 \u00a0 \u00a0 app: my-app\u00a0 \u00a0 spec:\u00a0 \u00a0 \u00a0 containers:\u00a0 \u00a0 \u00a0 - name: nginx\u00a0 \u00a0 \u00a0 \u00a0 image: my-app-image---apiVersion: v1kind: Servicemetadata:\u00a0 name: my-service\u00a0 namespace: defaultspec:\u00a0 selector:\u00a0 \u00a0 app: my-app\u00a0 ports:\u00a0 \u00a0 - protocol: TCP\u00a0 \u00a0 \u00a0 port: 80\n```\nThis file is a simple Kubernetes [manifest](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-manifest) , which is applied to the cluster to deploy the application.\nCreate a file named `kubernetes.yaml` , in the `deploy-canary-quickstart-gke-gatewayapi` directory, with the following contents:\n```\nkind: GatewayapiVersion: gateway.networking.k8s.io/v1beta1metadata:\u00a0 name: my-gateway\u00a0 annotations:\u00a0 \u00a0 networking.istio.io/service-type: \"ClusterIP\"spec:\u00a0 gatewayClassName: istio\u00a0 listeners:\u00a0 - name: default\u00a0 \u00a0 hostname: \"*.example.com\"\u00a0 \u00a0 port: 80\u00a0 \u00a0 protocol: HTTP\u00a0 \u00a0 allowedRoutes:\u00a0 \u00a0 \u00a0 namespaces:\u00a0 \u00a0 \u00a0 \u00a0 from: All---kind: HTTPRouteapiVersion: gateway.networking.k8s.io/v1beta1metadata:\u00a0 name: my-httproutespec:\u00a0 parentRefs:\u00a0 - kind: Gateway\u00a0 \u00a0 name: my-gateway\u00a0 hostnames:\u00a0 - \"test.example.com\"\u00a0 rules:\u00a0 - backendRefs:\u00a0 \u00a0 - name: my-service\u00a0 \u00a0 \u00a0 port: 80---apiVersion: v1kind: Servicemetadata:\u00a0 name: my-servicespec:\u00a0 selector:\u00a0 \u00a0 app: my-app\u00a0 ports:\u00a0 - name: tcp-port\u00a0 \u00a0 protocol: TCP\u00a0 \u00a0 port: 80\u00a0 \u00a0 targetPort: 8080---apiVersion: apps/v1kind: Deploymentmetadata:\u00a0 name: my-deployment\u00a0 labels:\u00a0 \u00a0 app: my-appspec:\u00a0 replicas: 1\u00a0 selector:\u00a0 \u00a0 matchLabels:\u00a0 \u00a0 \u00a0 app: my-app\u00a0 template:\u00a0 \u00a0 metadata:\u00a0 \u00a0 \u00a0 labels:\u00a0 \u00a0 \u00a0 \u00a0 app: my-app\u00a0 \u00a0 spec:\u00a0 \u00a0 \u00a0 containers:\u00a0 \u00a0 \u00a0 - name: nginx\u00a0 \u00a0 \u00a0 \u00a0 image: my-app-image\n```\nThis file is a Kubernetes [manifest](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-manifest) , which is applied to the cluster to deploy the application. This manifest includes the Service and Deployment resources required for canary deployment, plus an HTTPRoute and the Gateway resource needed for using Gateway API.\nCreate a file named `run.yaml` , in the `deploy-canary-quickstart-run` directory, with the following contents:\n```\napiVersion: serving.knative.dev/v1kind: Servicemetadata:\u00a0 name: my-canary-run-servicespec:\u00a0 template:\u00a0 \u00a0 spec:\u00a0 \u00a0 \u00a0 containers:\u00a0 \u00a0 \u00a0 - image: my-app-image\n```\nThis file is a Cloud Run service configuration file, which is applied at deploy time to create your service in Cloud Run. **Note:** If you want to use different manifests per target, read [this articleabout managing manifests](/deploy/docs/using-skaffold/managing-manifests) to find out more about using Skaffold profiles.## Create your delivery pipeline and targetsYou can define your delivery pipeline and targets in one file or in separate files. In this quickstart, we create one file for our pipeline and our single target:\nCreate a file named `clouddeploy.yaml` , in the `deploy-canary-quickstart-gke` directory, with the following contents:\n```\napiVersion: deploy.cloud.google.com/v1kind: DeliveryPipelinemetadata:\u00a0 name: my-canary-demo-app-1description: main application pipelineserialPipeline:\u00a0 stages:\u00a0 - targetId: prod\u00a0 \u00a0 profiles: []\u00a0 \u00a0 strategy:\u00a0 \u00a0 \u00a0 canary:\u00a0 \u00a0 \u00a0 \u00a0 runtimeConfig:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 kubernetes:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 serviceNetworking:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 service: \"my-service\"\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 deployment: \"my-deployment\"\u00a0 \u00a0 \u00a0 \u00a0 canaryDeployment:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 percentages: [50]\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 verify: false---apiVersion: deploy.cloud.google.com/v1kind: Targetmetadata:\u00a0 name: proddescription: prod GKE clustergke:\u00a0cluster: projects/PROJECT_ID/locations/us-central1/clusters/canary-quickstart-cluster\n```\nCreate a file named `clouddeploy.yaml` , in the `deploy-canary-quickstart-gke-gatewayapi` directory, with the following contents:\n```\napiVersion: deploy.cloud.google.com/v1kind: DeliveryPipelinemetadata:\u00a0 name: my-canary-demo-app-1description: main application pipelineserialPipeline:\u00a0 stages:\u00a0 - targetId: prod\u00a0 \u00a0 profiles: []\u00a0 \u00a0 strategy:\u00a0 \u00a0 \u00a0 canary:\u00a0 \u00a0 \u00a0 \u00a0 runtimeConfig:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 kubernetes:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 gatewayServiceMesh:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 httpRoute: \"my-httproute\"\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 service: \"my-service\"\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 deployment: \"my-deployment\"\u00a0 \u00a0 \u00a0 \u00a0 canaryDeployment:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 percentages: [50]\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 verify: false---apiVersion: deploy.cloud.google.com/v1kind: Targetmetadata:\u00a0 name: proddescription: prod GKE clustergke:\u00a0cluster: projects/PROJECT_ID/locations/us-central1/clusters/canary-quickstart-cluster\n```\nCreate a file named `clouddeploy.yaml` , in the `deploy-canary-quickstart-run` directory, with the following contents:\n```\napiVersion: deploy.cloud.google.com/v1kind: DeliveryPipelinemetadata:\u00a0 name: my-canary-demo-app-1description: main application pipelineserialPipeline:\u00a0 stages:\u00a0 - targetId: prod\u00a0 \u00a0 profiles: []\u00a0 \u00a0 strategy:\u00a0 \u00a0 \u00a0 canary:\u00a0 \u00a0 \u00a0 \u00a0 runtimeConfig:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 cloudRun:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 automaticTrafficControl: true\u00a0 \u00a0 \u00a0 \u00a0 canaryDeployment:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 percentages: [50]\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 verify: false---apiVersion: deploy.cloud.google.com/v1kind: Targetmetadata:\u00a0 name: proddescription: prod Run Servicerun:\u00a0 location: projects/PROJECT_ID/locations/us-central1\n```\n- Register your pipeline and targets with the Cloud Deploy service:```\ngcloud deploy apply --file=clouddeploy.yaml --region=us-central1 --project=PROJECT_ID\n```You now have a pipeline, with one target configured for a canary deployment strategy.\n- Confirm your pipeline and targets:In the Google Cloud console, navigate to the Cloud Deploy **Delivery pipelines** page to view of list of your available delivery pipelines. [Open the Delivery pipelines page](https://console.cloud.google.com/deploy/delivery-pipelines) The delivery pipeline you just created is shown, and the one target you configured is listed in the **Targets** column.\n## Create a releaseA release is the central Cloud Deploy resource representing the changes being deployed. The delivery pipeline defines the lifecycle of that release. See [Cloud Deploy service architecture](/deploy/docs/architecture#how_they_fit_together_to_deliver_your_release) for details about that lifecycle.\nTo create a `release` resource that represents the container image to deploy, run the following command from the `deploy-canary-quickstart-gke` , `deploy-canary-quickstart-gke-gatewayapi` , or `deploy-canary-quickstart-run` directory:\n```\n\u00a0gcloud deploy releases create test-release-001 \\\u00a0 \u00a0--project=PROJECT_ID \\\u00a0 \u00a0--region=us-central1 \\\u00a0 \u00a0--delivery-pipeline=my-canary-demo-app-1 \\\u00a0 \u00a0--images=my-app-image=gcr.io/google-containers/nginx@sha256:f49a843c290594dcf4d193535d1f4ba8af7d56cea2cf79d1e9554f077f1e7aaa\n```\n```\n\u00a0gcloud deploy releases create test-release-001 \\\u00a0 \u00a0--project=PROJECT_ID \\\u00a0 \u00a0--region=us-central1 \\\u00a0 \u00a0--delivery-pipeline=my-canary-demo-app-1 \\\u00a0 \u00a0--images=my-app-image=gcr.io/google-containers/nginx@sha256:f49a843c290594dcf4d193535d1f4ba8af7d56cea2cf79d1e9554f077f1e7aaa\n```\n```\n\u00a0gcloud deploy releases create test-release-001 \\\u00a0 \u00a0--project=PROJECT_ID \\\u00a0 \u00a0--region=us-central1 \\\u00a0 \u00a0--delivery-pipeline=my-canary-demo-app-1 \\\u00a0 \u00a0--images=my-app-image=us-docker.pkg.dev/cloudrun/container/hello@sha256:6063adf8f687702b4065151acddba6781c47bc602167eb9f3bec8aebc9ce95cc\n```When you create a release, Cloud Deploy automatically creates a rollout resource too, to immediately deploy to your one target, `prod` .\n### We skip to the stable phaseWith this first release, we skip the canary phase, and deploy to 100% (stable phase). This is because the application hasn't been deployed previously, so there's no way to calculate 50% of pods (for GKE) or how traffic is split for the service (for Cloud Run). The pods (GKE) or revisions (Cloud Run) don't exist yet.\nHaving skipped the canary phase, we're now ready to start the stable phase, which takes traffic to 100%. After that, we'll create another release, and that will execute the canary.\nIn a real-world situation, you will usually execute a canary deployment where your application is already running, so this phase skipping will be rare.## View the release in Google Cloud consoleNow that you've created the first release, the rollout is created, and you can view the release and the rollout in Google Cloud console. You can also view the pipeline visualization, which shows the current status of the release.- In the Google Cloud console, navigate to the Cloud Deploy **Delivery pipelines** page to view your **my-canary-demo-app-1** delivery pipeline. [Open the Delivery pipelines page](https://console.cloud.google.com/deploy/delivery-pipelines) \n- Click the name of your delivery pipeline \"my-canary-demo-app-1\".The pipeline visualization shows the app's deployment status. Because there's only one stage in the pipeline, the visualization shows only one node.And your release is listed on the **Releases** tab under **Delivery pipelinedetails** .\n- Click the release name, `test-release-001` .Your rollouts appear under **Rollouts** . You can click a rollout to view its details, including the deployment log.Notice that the rollout status is \"Pending advance,\" and the target shown in the pipeline visualization has a link to \"Advance to stable.\"\n## Advance the rollout phaseAfter the first release, the canary phase was skipped, and the rollout is waiting to start the \"stable\" phase, which deploys the application to 100%:- In the pipeline visualization, click **Advance to stable** .\n- When prompted, click **Advance** to confirm.\nAfter a few minutes, the rollout is now in the \"stable\" phase, and the application is deployed to 100%.## Execute the canary deploymentBecause the first release [skipped the canary phase](#we_skip_to_the_stable_phase) , we'll now create another release, which this time does execute a canary deployment.- To create a new `release` , run the following command from the `deploy-canary-quickstart-gke` , `deploy-canary-quickstart-gke-gatewayapi` or `deploy-canary-quickstart-run` directory:\n```\ngcloud deploy releases create test-release-002 \\\u00a0 --project=PROJECT_ID \\\u00a0 --region=us-central1 \\\u00a0 --delivery-pipeline=my-canary-demo-app-1 \\\u00a0 --images=my-app-image=gcr.io/google-containers/nginx@sha256:f49a843c290594dcf4d193535d1f4ba8af7d56cea2cf79d1e9554f077f1e7aaa\n```\n```\ngcloud deploy releases create test-release-002 \\\u00a0 --project=PROJECT_ID \\\u00a0 --region=us-central1 \\\u00a0 --delivery-pipeline=my-canary-demo-app-1 \\\u00a0 --images=my-app-image=gcr.io/google-containers/nginx@sha256:f49a843c290594dcf4d193535d1f4ba8af7d56cea2cf79d1e9554f077f1e7aaa\n```\n```\ngcloud deploy releases create test-release-002 \\\u00a0 --project=PROJECT_ID \\\u00a0 --region=us-central1 \\\u00a0 --delivery-pipeline=my-canary-demo-app-1 \\\u00a0 --images=my-app-image=us-docker.pkg.dev/cloudrun/container/hello@sha256:6063adf8f687702b4065151acddba6781c47bc602167eb9f3bec8aebc9ce95cc\n```\nAfter a few minutes, a rollout is created, and this time the canary stage is executed:When the first rollout phase finishes, the rollout is now in the canary phase:This means that the application is now deployed to 50%. For serviceNetworking-based GKE, it's deployed to half of your pods. For Gateway API-based GKE and Cloud Run traffic is allocated to 50%.\n- Click **Advance Rollout** , then click **Advance** when prompted.This advances the rollout to the \"stable\" phase, deploying the application to 100%.\n## Clean upTo avoid incurring charges to your Google Cloud account for   the resources used on this page, follow these steps.- Delete the `canary-quickstart-cluster` cluster (GKE only):```\ngcloud container clusters delete canary-quickstart-cluster --region=us-central1 --project=PROJECT_ID\n```\n- Delete the `my-canary-run-service` service (Cloud Run only):```\ngcloud run services delete my-canary-run-service --region=us-central1 --project=PROJECT_ID\n```\n- Delete the delivery pipeline, target, and all release and rollout resources:```\ngcloud deploy delete --file=clouddeploy.yaml --force --region=us-central1 --project=PROJECT_ID\n```\n- Delete the Cloud Storage buckets that Cloud Deploy created.One ends with `_clouddeploy` , and the other is `[region].deploy-artifacts.[project].appspot.com` . [Open the Cloud Storage browser page](https://console.cloud.google.com/storage/browser) \nThat's it, you completed this quickstart!## What's next\n- [Learn more about Cloud Deploy](/deploy/docs/overview) .\n- [Learn the basics of deploying applications](/deploy/docs/deploying-application) .\n- [Try out the Cloud Deploy walkthrough](https://shell.cloud.google.com/?show=ide%2Cterminal&walkthrough_id=deploy--cloud-deploy-e2e-gke) .\n- Learn how to [manage your manifests](/deploy/docs/skaffold) .\n- [Learn how to combine Google Cloud CI/CD tools to develop and deliversoftware effectively to GKE](/architecture/app-development-and-delivery-with-cloud-code-gcb-cd-and-gke) .", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Cloud Deploy Terminology.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Cloud Deploy Terminology", "url": "https://cloud.google.com/deploy/docs/terminology", "abstract": "# Cloud Deploy - Cloud Deploy Terminology\nThe terms in this document are defined according to how they're used in Cloud Deploy.\n", "content": "## Abandon\nTo [permanently deactivate a release](/deploy/docs/abandon-release) .\n## Application\nThe software you are going to deploy using Cloud Deploy.\n## Application delivery\nDelivery of the assets necessary to deploy an application into an intended [target](#target) environment. In Cloud Deploy, application delivery consists of generating, promoting, and delivering your [application](#application) 's Kubernetes manifests into the cluster.\n## Artifact\nThe container images to be deployed (build artifacts), and configuration files, such as manifests and Skaffold configs, that are used for the deployment ( [target artifacts](#target_artifacts) ).\n## Automation\nAutomation lets you configure your delivery pipeline and targets so that some actions can be performed on releases and rollouts for that pipeline, without requiring human intervention. For example, you can set up your delivery pipeline so that promotion into a specific target happens automatically, under the right circumstances. [Learn more](/deploy/docs/automation) .\n## Automation rule\nThe behavior of an [automation](/deploy/docs/automation) is defined in part by the automation rule. An automation rule defines what is automated, for example, promoting a release.\nThe available automation rules are listed in the document [Using automation rules](/deploy/docs/automation-rules) .\n## Automation run\nAn instance of an [Automation](#automation) .\n## Canary deployment\nA deployment strategy in which you roll out your changes to a subset of users first, test it to ensure reliability, then roll it out fully.\n## Child rollout\nFor [Parallel deployment](#parallel_deployment) , the rollout generated to deploy to a [child target](#child_target) .\nSee also, [Controller rollout](#controller_rollout) .\n## Child target\nFor [Parallel deployment](#parallel_deployment) , a target that represents one of the multiple GKE, GKE Enterprise, or Cloud Run individual targets you're deploying to simultaneously.\nSee also, [Multi-target](#multi_target) , [Parallel deployment](#parallel_deployment) , [Child rollout](#child_rollout) .\n## Continuous delivery\nA software engineering [practice](/solutions/devops/devops-tech-continuous-delivery) in which changes can be released to users safely, frequently, and mostly automatically.\n## Continuous deployment\nA software engineering practice that results in changes to code and configuration being deployed automatically.\nWhereas continuous requires manual approval at one or more stages, continuous deployment is automatic, with no manual approval required.\n## Controller rollout\nA rollout generated for [parallel deployment](#parallel_deployment) . The controller rollout isn't used to deploy to a single target cluster or service; rather, it has one [child rollout](#child_rollout) for each [child target](#child_target) .\nSee also, [Parallel deployment](#parallel_deployment) , [Multi-target](#multi_-_target) .\n## Custom target\nA target that uses a user-defined [custom target type](/deploy/docs/custom-targets) rather than one of the [supported target types](/deploy/docs/create-pipeline-targets#define_the_delivery_pipeline_and_targets) .\n## Declarative\nConfiguration for a system, such as a Kubernetes cluster, that describes the intended state and relies on that system to achieve that state. Contrast with imperative configuration, in which you describe the specific steps to achieve that state.\nBesides rendering and deploying declarative Kubernetes manifests, Cloud Deploy uses declarative resource definitions to define the rendering and delivery process. `skaffold.yaml` and `clouddeploy.yaml` are typical filenames for the Skaffold definition and delivery-pipeline definition.\n## Delivery pipeline\nA representation of the workflow that delivers an application to each target in a [deployment progression](#progression) .\nDocumentation for Cloud Deploy uses the term \" pipeline\" to distinguish it from other pipelines you might use, such as a CI pipeline.\nIn Cloud Deploy, the delivery pipeline is defined in a YAML configuration file\u2014typically `clouddeploy.yaml` \u2014and that definition consists of the following:\n- Deployment [targets](#target) \n- The promotion sequence among those targets\n**Note:** you can define targets in a separate file.\nSee also [Pipeline instance](#pipeline_instance) .\n## Deploy hook\nAn arbitrary [action](/deploy/docs/hooks#configure_in_skaffold) you can run before or after deploying. [Learn more](/deploy/docs/hooks) .\n## Deploy parameters\nPlaceholders that can be added to a manifest but that are not resolved as part of rendering. Instead, values for these placeholders are assigned after each target-specific manifest is rendered. [Learn more](/deploy/docs/parameters) .\n## Deployment strategy\nA technique for safely deploying changes to your application while minimizing impact to users.\n## Execution environment\nA set of Google Cloud resources on which Cloud Deploy runs. It consists of the following:\n- The default or private [worker pool](/build/docs/private-pools/private-pools-overview) in which Cloud Deploy executes rendering and deploying actions\n- The default or alternate [execution environment](/deploy/docs/execution-environment) service account that calls Cloud Deploy to perform rendering and deploying\n- The default or alternate storage location for rendered manifests in Cloud Storage.## Hydrating\nSee [Render](#render) .\n## Job\nA specific operation to be performed on a rollout, such as deploy or verify. [Learn more](/deploy/docs/verify-deployment) .\n## Job run\nA child resource of a rollout, the job run is an instance of a job. That is, it represents an attempt to perform a job such as deploy or verify. [Learn more](/deploy/docs/verify-deployment) .\n## Manifest\nA Kubernetes configuration object that is used to create, modify, and delete Kubernetes resources such as pods, deployments, services, or ingresses.\nManifests in Cloud Deploy exist in one of two states: rendered or unrendered. An unrendered manifest is not ready for deployment into a target. The rendering process, which includes populating specific values into the manifest, is often performed by tools like Helm, Kustomize, and kpt. Cloud Deploy uses Skaffold to orchestrate the rendering of configuration (the [skaffold render](https://skaffold.dev/docs/workflows/ci-cd/#separation-of-rendering-and-deployment) command).\nSee also, [Render](#render) .\n## Multi-target\nWhen configuring or performing a parallel deployment, a multi-target is a single pipeline stage, but can comprise more than one target runtime.\nSee also, [Child target](#child_target) , [Parallel deployment](#parallel_deployment) , [Controller rollout](#controller_rollout) .\n## Parallel deployment\nThe practice of deploying an application to more than one target at the same time, in the same delivery pipeline stage. This technique allows you to deploy to multiple clusters or services in production, for example.\n## Phase\nThe collection of operations (jobs) in a rollout that are logically grouped together, for example a deploy or a deploy and verify. [Learn more](/deploy/docs/verify-deployment) .\n## Pipeline\nSee [Delivery pipeline](#delivery_pipeline)\n## Pipeline instance\nA snapshot of a delivery pipeline, taken when a `release` is created. Cloud Deploy keeps this snapshot to ensure that all deployments of a release are consistently managed using the pipeline as it was defined when the `release` was created.\nSee [Pipeline instances per release](/deploy/docs/pipeline-instances) for more information.\n## Pipeline mismatch\nWhen a delivery pipeline or target is changed after a release is created, the [pipeline instance](#pipeline_instance) associated with the `release` is now different from the pipeline definition.\nIf there's a pipeline mismatch, Cloud Deploy prompts you to examine the definitions before you promote a release or attempt a rollback.\nSee [Pipeline instances per release](/deploy/docs/pipeline-instances) for more information.\n## Progression\nA configuration, in your delivery pipeline configuration file, that describes a promotion sequence from one target to another\u2014for example from `test` to `staging` to `prod` .\n## Promotion\nThe process of advancing a release from one target to another, according to the [progression](#progression) defined in the delivery pipeline.\n## Register\nTo provide an application to the Cloud Deploy service, in the form of a delivery pipeline, so that the application's delivery is managed by the service.\n## Release\nA Cloud Deploy resource that represents the changes (code, configuration or both) to be deployed.\nThe release lifecycle is described in the document [Cloud Deployservice architecture](/deploy/docs/architecture#how_they_fit_together_to_deliver_your_release) .\n## Render\nTo prepare a manifest for deployment in the target. Rendering a manifest consists mainly of providing values for the variables in the manifest. Cloud Deploy does this using [skaffold render](https://skaffold.dev/docs/workflows/ci-cd/#separation-of-rendering-and-deployment) .\nThis doesn't include populating values for [deploy parameters](/deploy/docs/parameters)\n## Rollout\nA resource that associates a [release](#release) with a deployment [target](#target) . A `rollout` is created per release per target, so in a simple progression across three targets in a delivery pipeline, there would be three `rollout` resources for the release\u2014one for each target.\nFor more complex deployments, for example using a canary deployment strategy, a `rollout` can be more complicated. [Learn more](/deploy/docs/deployment-strategies#structure_of_a_rollout) .\n## Standard deployment strategy\nThe standard deployment strategy is the default way of deploying an application to a target. For each stage defined in the delivery pipeline, your application is deployed fully to the target, each time replacing the application as it was previously deployed.\n## Stage\nOne target or multi-target in a delivery pipeline. For example, in a simple delivery pipeline that has the following stages:\n- `dev`\n- `staging`\n- `prod`\nEach of those is one stage.\nWhen performing [parallel deployment](#parallel_deployment) , the [multi-target](/deploy/docs/parallel) is a single stage, but the [child targets](#child_target) are not separate stages.\n## Suspend (a delivery pipeline)\nTo prevent creation and promotion of releases from a given delivery pipeline. For more information, see [Suspending a delivery pipeline](/deploy/docs/suspend-pipeline)\n## Target\nThe specific runtime environment (Kubernetes cluster, Cloud Run service, or other supported runtime) into which to deploy the application. Also, the configuration for that environment.\nYou can define your targets in your [delivery pipeline](#delivery_pipeline) configuration file, or in a separate file.\nA target can also be a [multi-target](#multi-target) or a [child target](#child_target) to support [parallel deployment](#parallel_deployment) .\n## Target artifact\nA configuration file used for rendering and deploying an application on a target. These include Kubernetes manifest or Cloud Run service definition, Skaffold configuration files, and the rendering source used to create these.\n## Verification\nThe ability to confirm that a deployment was successful, by running an arbitrary container, with tests. [Learn more about deployment verification](/deploy/docs/verify-deployment) .", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Cloud Deploy service accounts.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Cloud Deploy service accounts", "url": "https://cloud.google.com/deploy/docs/cloud-deploy-service-account", "abstract": "# Cloud Deploy - Cloud Deploy service accounts\nThis document describes service accounts that are used to run Cloud Deploy and to call Cloud Deploy to run various operations.\nCloud Deploy uses two service accounts:\n- The Cloud Deploy [service agent](/iam/docs/service-agents) Cloud Deploy uses this service account to interact with your project. You can't replace this service agent with an alternate service account, but you can edit permissions on it, for example when you're using resources outside of the project (such as a service account or a private Cloud Build worker pool).\n- The Cloud Deploy execution service accountCloud Deploy uses this service account to execute render and deploy operations in Cloud Build. This account needs permissions sufficient to read from and write to the Cloud Storage bucket and to access deployment targets.The default service account for execution is the [default Compute Engine service account](/deploy/docs/cloud-deploy-service-account#default_service_account) . You can specify an alternate service account in the [target configuration](/deploy/docs/config-files#target_definitions) .\n- The Cloud Deploy automation service accountThis is the service account Cloud Deploy uses to perform [automations](/deploy/docs/automation) . This can be the default execution service account or another service account. See [The automation service account](/deploy/docs/automation-resource#automation_service_account) For more information about this service account.\nSee [Creating and managing service accounts](/iam/docs/creating-managing-service-accounts) for instructions on how to edit service-account permissions and how to create an alternate service account.\n", "content": "## Cloud Deploy service agent\nThe Cloud Deploy service agent is a service account that Cloud Deploy uses to interact with other Google Cloud services Cloud Deploy relies on. These services include Cloud Build, Pub/Sub, and Cloud Audit Logs.\nThe name of this service account follows this pattern:\n`service-<project-number>@gcp-sa-clouddeploy.iam.gserviceaccount.com`\nYou can't replace the service agent with an alternate service account. But you might need to add permissions, for example to allow access to a private pool in another project, configured as part of an [execution environment](/deploy/docs/execution-environment) .\n## Cloud Deploy execution service account\nBy default, Cloud Deploy runs using the [default Compute Engineservice account](/iam/docs/service-account-types#default) . That service account has sufficient permissions in the project that contains it to render manifests and deploy to your targets.\nThe name of this service account follows this pattern:\n`[project-number]-compute@developer.gserviceaccount.com`\nThis default service account has broad permissions. The best practice is to change your [execution environment](/deploy/docs/execution-environment) so that Cloud Deploy runs as a different service account. You can change the execution service account for each [target](/deploy/docs/config-files#target_definitions) using the `executionConfigs.privatePool.serviceAccount` property or the `executionConfigs.defaultPool.serviceAccount` property in the [target definition](/deploy/docs/config-files#target_definitions) .\nAny service account you set for these properties must have the `roles/clouddeploy.jobRunner` role in the Cloud Deploy project. If the default execution service account doesn't have this permission, run the following command:\n```\n\u00a0gcloud projects add-iam-policy-binding PROJECT_ID \\\u00a0 \u00a0 \u00a0--member=serviceAccount:$(gcloud projects describe PROJECT_ID \\\u00a0 \u00a0 \u00a0--format=\"value(projectNumber)\")-compute@developer.gserviceaccount.com \\\u00a0 \u00a0 \u00a0--role=\"roles/clouddeploy.jobRunner\"\n```\n### What service accounts to create\nIf you choose not to use the default execution service account for rendering and deploying, you need to create one or more alternate service accounts to use. These are service accounts that Cloud Deploy runs as, and they're [configured in the target configuration](/deploy/docs/config-files#target_definitions) .\nOne reason to create more than one would be to have a specific service account or accounts for deploying to restricted targets, like a production target.\nOne possible approach is to use separate service accounts per delivery pipeline. Each such service account would include roles with sufficient permissions to render and to deploy.\nFor deployments to Google Kubernetes Engine, you can [restrict the service account to one namespace](/deploy/docs/securing/sa-by-namespace) .\n### Using service accounts from a different project\nFor your [execution environment](/deploy/docs/execution-environment) , you can specify a service account that's in a different project from the one in which you create your target:\n- On the project that owns the service account, [enable the cross-project SAorganization policy](https://cloud.google.com//iam/docs/attach-service-accounts#enabling-cross-project) .\n- Grant the Cloud Deploy [service agent](#service_agent) ( `service-<project-number>@gcp-sa-clouddeploy.iam.gserviceaccount.com` ) the `iam.serviceAccounts.actAs` permission for your service account.In this case, `project-number` is the project in which you created your target.You can also grant the [roles/iam.serviceAccountUser](/iam/docs/understanding-roles#service-accounts-roles) role, which includes that permission, in the project of and on each service account that's in a different project from the one where Cloud Deploy is running.\n- Grant the Cloud Build service agent ( `service-<project-number>@gcp-sa-cloudbuild.iam.gserviceaccount.com` ) the `roles/iam.serviceAccountTokenCreator` role.In this case, `project-number` is the project in which you created your target, and this role is granted in the service account's project.You must grant this role for each service account configured in a target's execution environment if that service account is in a different project from the one where Cloud Deploy is running.\n- Grant the caller of `gcloud deploy releases create` and `gcloud deploy rollouts create` `iam.serviceAccounts.actAs` permission on the service account, or the `[roles/iam.serviceAccountUser](/iam/docs/understanding-roles#service-accounts-roles)` role.\n### Required permissions\n- The service account used for rendering configurations must have sufficient permissions to access the Cloud Storage bucket where your Cloud Deploy resources are stored (delivery pipelines, releases, rollouts).The role `roles/clouddeploy.jobRunner` includes all permissions the render service account ( [privatePool or defaultPool](/deploy/docs/config-files#target_definitions) ) needs.\n- The service account used for deploying must have sufficient permissions to deploy to the target cluster, permission to access the Cloud Storage bucket. **Note:** If you use a custom Cloud Storage bucket, you can put it anywhere. (It doesn't need to be in the same region, for example, as the delivery pipeline.)\n- The service account that calls Cloud Deploy to create a release must have the `clouddeploy.releaser` role. It must also have the `iam.serviceAccount.actAs` permission to use the service account that renders manifests (for example through the [roles/iam.serviceAccountUser](/iam/docs/understanding-roles#service-accounts-roles) role).\n- The service account that calls Cloud Deploy to promote a release or create a `rollout` must have the `iam.serviceAccount.actAs` permission to use the service account that deploys to targets (for example through the [roles/iam.serviceAccountUser](/iam/docs/understanding-roles#service-accounts-roles) role).\n- The service account configured for an [automation](/deploy/docs/automation) must have permission to run the operations that are being automated. [Learn more](/deploy/docs/automation-resource#automation_service_account) .## The automation service account\nYou can automate some actions in a release. Cloud Deploy runs these automations using the automation service account, which can be the default execution service account, a non-default service account used as the execution service account, or another service account.\nThis service account is described in the section [The automation service account](/deploy/docs/automation-resource#automation_service_account) .\n## What's next\n- Learn about [IAM](/iam/docs) .\n- Find out about [predefined Cloud Deploy roles](/deploy/docs/iam-roles-permissions#predefined_roles) .\n- Understand how to [Create and manage service accounts](/iam/docs/creating-managing-service-accounts) .", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Cloud Deploy service architecture.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Cloud Deploy service architecture", "url": "https://cloud.google.com/deploy/docs/architecture", "abstract": "# Cloud Deploy - Cloud Deploy service architecture\nThis document describes the relationships between Cloud Deploy and the external systems it works with in order to deploy your applications. These systems are other Google Cloud services and third-party tools.\n", "content": "## The high-level view\nThe following diagram shows the relationships between Cloud Deploy and the separate systems it relies on.\nAs shown in this diagram, Cloud Deploy interacts with the following systems:\n- Your CI systemCloud Deploy supports most CI tools, as long as one output from your CI process can be a call to the Cloud Deploy [API](/deploy/docs/api/reference/rest) or [CLI](/sdk/gcloud/reference/deploy) to [create a release](/deploy/docs/deploying-application#invoke_your_delivery_pipeline_to_create_a_release) .\n- [Cloud Build](/build/docs) Cloud Deploy calls Cloud Build to render your manifests and to deploy to the target runtime. For more details, see Execution environments[]()\n- [Skaffold](/skaffold) Cloud Deploy uses Skaffold through Cloud Build to render and deploy your manifests, thus deploying your application.\n- [Cloud Storage](/gcs/docs) Cloud Deploy stores rendering source and rendered manifests in a Cloud Storage bucket.\n- [Google Cloud Observability](/stackdriver/docs) and [Cloud Audit Logs](/logging/docs) .Google Cloud Observability collects and makes available logging data for Cloud Deploy.See also [Audit logging](/deploy/docs/audit-logs) .\n- [Pub/Sub](/pubsub/docs) Cloud Deploy publishes messages to several Pub/Sub topics. You can use this service to integrate with external workflow, testing, and other related systems.See [Subscribing to Cloud Deploy notifications](/deploy/docs/subscribe-deploy-notifications) and [Integrating Cloud Deploy with other system](/deploy/docs/integrating) for more information.\n- Target runtimeCloud Deploy uses [skaffold apply](https://skaffold.dev/docs/workflows/ci-cd/#separation-of-rendering-and-deployment) , through Cloud Build, to deploy your applications to your target runtime (GKE or GKE Enterprise).## Cloud Deploy resources\nThe following diagram shows the resources that Cloud Deploy uses to deliver your applications, and the relationships among those resources:\nAs shown in this diagram, the relationships among the resources are as follows:\n- The [delivery pipeline](/deploy/docs/terminology#delivery_pipeline) can yield zero or more releases and can reference one or more [targets](/deploy/docs/terminology#target) , including [multi-targets](/deploy/docs/terminology#multi-target) and their associated [child-targets](/deploy/docs/terminology#child_target) .\n- The delivery pipeline can also reference one or more [automations](/deploy/docs/automation) , which automate actions on Cloud Deploy resources.\n- Each [release](/deploy/docs/terminology#release) includes the [pipeline instance](/deploy/docs/terminology#pipeline_instance) \u2014a \"snapshot\" of the delivery pipeline and targets as they were configured when the release was created.\n- Each release can yield zero or more [rollouts](/deploy/docs/terminology#rollout) , and can reference zero or more artifacts.Each rollout includes at least one phase, representing a collection of operations (jobs) in a rollout that are logically grouped together, for example, a deploy or a deploy and verify.Each phase includes one or more jobs, representing what is to be done on the rollout\u2014either deploy or verify. Each job can include one or more job runs, which are instances of jobs, for example, an attempt to deploy. A job run is a child resource of the rollout. [Multi-targets](/deploy/docs/terminology#multi-target) , used for [parallel deployment](/deploy/docs/parallel) , create [controller rollouts](/deploy/docs/terminology#controller_rollout) , which create child rollouts, which correspond to child targets.\n- Each rollout is associated with one target.For [parallel deployment](/deploy/docs/parallel) , each [child target](/deploy/docs/terminology#child_target) is associated with one [child rollout](/deploy/docs/terminology#child_rollout) .\n- Each target is associated with one GKE or Anthos cluster, or other runtime destination for the application.\n- A target can be associated with one or more delivery pipelines.\n- An artifact is any output from your CI process (for example, a [container image](/deploy/docs/integrating-ci#build_artifacts_versus_images) ) that is deployed to a target runtime as part of a rollout.\nFurther, a rollout has one or more phases, and phases have one or more jobs and one or more job runs.\nAs shown in this diagram, a rollout includes the following:\n- PhasesA phase contains one or more jobs (for example deploy, or deploy and verify). Each rollout has one or more phases. A phase is a sub-message in a rollout.\n- JobsThe specific operation to be performed on a rollout, for example deploy or verify. A job is a sub-message in a rollout.\n- JobRunsAn instance of a job, for example an attempt to verify. Each job may have zero or more JobRuns. The JobRun is a child resource of a rollout.\nAutomations contain automation rules, which may be referenced by zero or more AutomationRun resources. AutomationRuns are instances of executed automation rules, for example an automated promotion from one target to another. Automation and AutomationRun resources are peer-child resources beneath a delivery pipeline.\n## How they fit together to deliver your release\nThis section describes how Cloud Deploy interacts with the components listed in this document to automate the delivery of your application as a [release](/deploy/docs/terminology#release) .\n- Your CI system invokes a Cloud Deploy delivery pipeline.Your CI process calls Cloud Deploy using the [CLI](/sdk/gcloud/reference/deploy/releases/create) or [API](/deploy/docs/api/reference/rest/v1/projects.locations.deliveryPipelines.releases/create) to create a new release, passing the build artifacts or references to images.For more information about integrating your CI system, see [Integrating Cloud Deploy with other systems](/deploy/docs/integrating#integrating_with_your_ci_system) .\n- When a new release is created, Cloud Deploy does the following:- Stores an instance of the delivery pipeline as part of the release.This pipeline instance remains unchanged for this release, even if the delivery pipeline configuration is changed. See [Pipeline instances perrelease](/deploy/docs/pipeline-instances) for more information.Also, the [Skaffold version](/deploy/docs/using-skaffold/select-skaffold) is stored as a part of the release. In most cases, this will be the default Skaffold version, but because [you can specify other versions](/deploy/docs/using-skaffold/select-skaffold) , that information is stored.\n- Calls Cloud Build, which gets the Skaffold rendering source from Cloud Storage.Cloud Deploy stores the rendering source in the default or alternate Cloud Storage bucket.\n- Calls [skaffold diagnose](https://skaffold.dev/docs/references/cli/#skaffold-diagnose) (using the Skaffold version stored upon release creation) to generate a single effective manifest.\n- Calls the `render` operation.If you're using built-in targets, Cloud Deploy calls [skaffold render](https://skaffold.dev/docs/workflows/ci-cd/#separation-of-rendering-and-deployment) to render the manifest using the provided images or build artifacts. Cloud Deploy substitutes image names in `spec.templates.spec.containers.image` with the full image paths (including digests or tags) provided on the `gcloud deploy releases create` command or in a build artifacts file [referenced by that command](/deploy/docs/integrating-ci#calling_from_your_ci_pipeline) .If you're using a [custom target](/deploy/docs/custom-targets) , Cloud Deploy calls the [render operation](/deploy/docs/custom-targets#deploy_contract_inputs) defined for its custom target type.Cloud Deploy stores the rendered manifest in the default or alternate Cloud Storage bucket.Cloud Deploy performs these actions using the default or an alternate [execution environment](/deploy/docs/execution-environment) .\n- When a rollout is created (automatically after release creation or on demand later), Cloud Deploy does the following:- Calls pre-deploy hooks, if any are specified.If you're using a [canary](/deploy/docs/deployment-strategies/canary) deployment strategy, pre-deploy hooks are called at the start of the first phase.\n- Calls the `deploy` operation.If you're using built-in targets, Cloud Deploy automatically creates and deploys a rollout to the first target, by calling [skaffold apply](https://skaffold.dev/docs/workflows/ci-cd/#separation-of-rendering-and-deployment) . If you're using a built-in target, the first rollout is created automatically upon release creation. **Note:** `skaffold apply` includes the Skaffold [health check](https://skaffold.dev/docs/workflows/ci-cd#waiting-for-skaffold-deployments) , which waits for deployments to stabilize.If you're using a [custom target](/deploy/docs/custom-targets) , Cloud Deploy automatically creates a rollout to the first target, calling the [deploy operation](/deploy/docs/custom-targets#deploy_contract_inputs) defined for its custom target type.For built-in targets and custom targets, the rollout to the first target, is automatic only when the release is created using the command line.The process of deploying to the first target is the same as for promotions, as described in the next step.\n- Calls [skaffold verify](https://skaffold-v2.web.app/docs/pipeline-stages/verify/) , if `verify` is `true` for the target in the delivery pipeline [config](/deploy/docs/config-files#verify) and if verification is [specified in the Skaffold configuration](/deploy/docs/verify-deployment#configure_skaffold) .\n- Calls post-deploy hooks, if any are specified, after `verify` , if a `verify` is specified. Otherwise, post-deploy hooks are called after `deploy` .If you're using a canary deployment strategy, post-deploy hooks are performed as the last job in the final rollout phase.\n- When it's time to promote the release to the next target, Cloud Build retrieves the target-specific manifest from Cloud Storage. Then Cloud Build invokes [skaffold apply](https://skaffold.dev/docs/workflows/ci-cd/#separation-of-rendering-and-deployment) to apply the rendered manifest to the specified target runtime.If the target requires [approval](/deploy/docs/promote-release#manage_approvals_for_a_delivery_pipeline) , you can approve or reject through the CLI or using the Console.Also, Cloud Deploy generates a Pub/Sub message, which you can subscribe to in order to [automatically initiate an approvalworkflow](/deploy/docs/integrating#for_approvals) .Cloud Deploy uses the Skaffold version and the pipeline instance that are associated with this release, and performs this step in the default or custom execution environment.This process is true not only for promotions, but also for rollbacks and for redeployments.\n- Throughout Cloud Deploy operations, the service publishes notifications to [several Pub/Sub topics](/deploy/docs/subscribe-deploy-notifications) (for example, when a rollout [requires approval](/deploy/docs/promote-release#require_approval) ).This and other integrations are described further in [Integrating Cloud Deploywith external systems](/deploy/docs/integrating) .\n- You can specify an [automation](/deploy/docs/automation) to automatically perform various [operations](/deploy/docs/automation-rules) within the delivery pipeline. These can be executed at their designated time. An [automationRun](/deploy/docs/automation-resource#the_automationrun_resource) represents an automation rule execution.\n- Throughout Cloud Deploy operation, the service writes platform logs and [audit logs](/deploy/docs/audit-logs) to Google Cloud Observability and Cloud Audit Logs.\nThrough all of these steps, flow control and access to resources are restricted using [Identity and Access Management](/deploy/docs/iam-roles-permissions) .\n## What's next\n- Learn more about how to [integrate Cloud Deploy with other systems](/deploy/docs/integrating) \n- See important information about the [Skaffold version lifecycle](/deploy/docs/using-skaffold/select-skaffold) .\n- Learn about Cloud Deploy [execution environments](/deploy/docs/execution-environment) .\n- Try the [Cloud Deploy Skaffold profiles walkthrough](https://shell.cloud.google.com/?show=ide%2Cterminal&walkthrough_id=deploy--cloud-deploy-profiles-gke) \n- [Learn how to combine Google Cloud CI/CD tools to develop and deliversoftware effectively to GKE](https://cloud.google.com/architecture/app-development-and-delivery-with-cloud-code-gcb-cd-and-gke) .", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Cloud Deploy 區域簡介.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Cloud Deploy \u5340\u57df\u7c21\u4ecb", "url": "https://cloud.google.com/deploy/docs/regions?hl=zh-cn", "abstract": "# Cloud Deploy - Cloud Deploy \u5340\u57df\u7c21\u4ecb\nCloud Deploy \u670d\u52d9\u5728\u5404\u7a2e Google Cloud \u4f4d\u7f6e\u4f5c\u7232\u591a\u500b\u7368\u7acb\u7684\u7368\u7acb\u5be6\u4f8b\u904b\u884c\u3002\u5275\u5efa\u4ea4\u4ed8\u6d41\u6c34\u7dda\u7684\u4f4d\u7f6e\u6c7a\u5b9a\u4e86\u54ea\u500b Cloud Deploy \u5be6\u4f8b\u5b58\u5132\u548c\u8655\u7406\u8a72\u6d41\u6c34\u7dda\u7684\u8acb\u6c42\u3002\n[\u201cCloud \u4f4d\u7f6e\u201d\u9801\u9762](https://cloud.google.com/about/locations?hl=zh-cn) \u5217\u51fa\u4e86\u6bcf\u500b Google Cloud \u7522\u54c1\uff08\u5305\u62ec Cloud Deploy\uff09\u652f\u6301\u7684\u5340\u57df\u3002\n**\u6ce8\u610f** \uff1a\u60a8\u5fc5\u9808\u5728\u5275\u5efa\u4ea4\u4ed8\u6d41\u6c34\u7dda\u7684\u540c\u4e00\u5340\u57df\u4e2d\u5275\u5efa\u76ee\u6a19\u3001\u7248\u672c\u548c\u767c\u4f48\u3002\uff08\u4f46\u662f\uff0c\u7531\u9019\u4e9b\u76ee\u6a19\u8868\u793a\u7684 GKE \u548c GKE Enterprise \u96c6\u7fa3\u53ef\u4ee5\u4f4d\u65bc\u4efb\u4f55\u5340\u57df\u4e2d\u3002\uff09\n\u7576 Cloud Deploy \u7232\u6d41\u6c34\u7dda\u4f7f\u7528\u5176\u4ed6 Google Cloud \u8cc7\u6e90\u6642\uff0c\u5b83\u6703\u76e1\u53ef\u80fd\u5728\u540c\u4e00\u4f4d\u7f6e\u5275\u5efa\u9019\u4e9b\u8cc7\u6e90\uff0c\u4f8b\u5982 Cloud Deploy \u7528\u4f86\u5b58\u5132\u6e32\u67d3\u914d\u7f6e\u6e05\u55ae\u7684 Cloud Storage \u5b58\u5132\u5206\u5340\u3002\nCloud Deploy \u5be6\u4f8b\u53ef\u4ee5\u5c07\u61c9\u7528\u90e8\u7f72\u5230\u9664\u904b\u884c Cloud Deploy \u7684\u4f4d\u7f6e\u4e4b\u5916\u7684\u4f4d\u7f6e\u3002\u6b64\u529f\u80fd\u5141\u8a31\u60a8\u7684\u4ea4\u4ed8\u6d41\u6c34\u7dda\u90e8\u7f72\u5230\u591a\u500b\u5340\u57df\u3002\u4f46\u662f\uff0c\u7d66\u5b9a\u7684\u4ea4\u4ed8\u6d41\u6c34\u7dda\u53ea\u80fd\u7531\u55ae\u500b Cloud Deploy \u5be6\u4f8b\u8a2a\u554f\u3002\nCloud Deploy \u5be6\u4f8b\u7368\u7acb\u904b\u884c\uff0c\u56e0\u6b64\u4e00\u500b\u5340\u57df\u7684\u6545\u969c\u4e0d\u6703\u5f71\u97ff\u53e6\u4e00\u500b\u5340\u57df\u4e2d\u7684\u5be6\u4f8b\u3002\u56e0\u6b64\uff0c\u5982\u679c\u60a8\u50c5\u90e8\u7f72\u5230\u55ae\u500b\u5340\u57df\uff0c\u6211\u5011\u5efa\u8b70\uff08\u4f46\u4e0d\u8981\u6c42\uff09\u5728\u76ee\u6a19\u96c6\u7fa3\u6240\u5728\u7684\u4f4d\u7f6e\u5275\u5efa\u6d41\u6c34\u7dda\u3002\n**\u6ce8\u610f** \uff1a\u60a8\u9078\u64c7\u7684\u5340\u57df\u53ef\u80fd\u6703\u5f71\u97ff\u6027\u80fd\u548c\u7d50\u7b97\uff0c\u56e0\u7232 Google Cloud \u4f4d\u7f6e\u4e4b\u9593\u7684\u6578\u64da\u50b3\u8f38\u53ef\u80fd\u8868\u73fe\u8f03\u597d\u6216\u8f03\u5dee\uff0c\u5177\u9ad4\u53d6\u6c7a\u65bc\u4f4d\u7f6e", "content": "\u3002", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Cloud Deploy 服務架構.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Cloud Deploy \u670d\u52d9\u67b6\u69cb", "url": "https://cloud.google.com/deploy/docs/architecture?hl=zh-cn", "abstract": "# Cloud Deploy - Cloud Deploy \u670d\u52d9\u67b6\u69cb\n\u672c\u6587\u6a94\u4ecb\u7d39\u4e86 Cloud Deploy \u8207\u5176\u914d\u5408\uff08\u4ee5\u4fbf\u90e8\u7f72\u61c9\u7528\uff09\u7684\u5916\u90e8\u7cfb\u7d71\u4e4b\u9593\u7684\u95dc\u4fc2\u3002\u9019\u4e9b\u7cfb\u7d71\u662f\u5176\u4ed6 Google Cloud \u670d\u52d9\u548c\u7b2c\u4e09\u65b9\u5de5\u5177\u3002\n", "content": "## \u6982\u8981\u8996\u5716\n\u4e0b\u5716\u986f\u793a\u4e86 Cloud Deploy \u8207\u5176\u4f9d\u8cf4\u7684\u7368\u7acb\u7cfb\u7d71\u4e4b\u9593\u7684\u95dc\u4fc2\u3002\n\u5982\u5716\u6240\u793a\uff0cCloud Deploy \u8207\u4ee5\u4e0b\u7cfb\u7d71\u4ea4\u4e92\uff1a\n- \u60a8\u7684 CI \u7cfb\u7d71Cloud Deploy \u652f\u6301\u5927\u591a\u6578 CI \u5de5\u5177\uff0c\u524d\u63d0\u662f CI \u6d41\u7a0b\u7684\u4e00\u500b\u8f38\u51fa\u53ef\u4ee5\u8abf\u7528 Cloud Deploy [API](https://cloud.google.com/deploy/docs/api/reference/rest?hl=zh-cn) \u6216 [CLI](https://cloud.google.com/sdk/gcloud/reference/deploy?hl=zh-cn) \u4f86 [\u5275\u5efa\u7248\u672c](https://cloud.google.com/deploy/docs/deploying-application?hl=zh-cn#invoke_your_delivery_pipeline_to_create_a_release) \u3002\n- [Cloud Build](https://cloud.google.com/build/docs?hl=zh-cn) Cloud Deploy \u8abf\u7528 Cloud Build \u4ee5\u5448\u73fe\u6e05\u55ae\u4e26\u90e8\u7f72\u5230\u76ee\u6a19\u904b\u884c\u6642\u3002 For more details, see Execution environments[]()\n- [Skaffold](https://cloud.google.com/skaffold?hl=zh-cn) Cloud Deploy \u901a\u904e Cloud Build \u4f7f\u7528 Skaffold \u5448\u73fe\u548c\u90e8\u7f72\u61c9\u7528\uff0c\u5f9e\u800c\u90e8\u7f72\u61c9\u7528\u3002\n- [Cloud Storage](https://cloud.google.com/gcs/docs?hl=zh-cn) Cloud Deploy \u5c07\u6e32\u67d3\u4f86\u6e90\u548c\u6e32\u67d3\u6e05\u55ae\u5b58\u5132\u5728 Cloud Storage \u5b58\u5132\u6876\u4e2d\u3002\n- [Google Cloud \u53ef\u89c0\u6e2c\u6027](https://cloud.google.com/stackdriver/docs?hl=zh-cn) \u548c [Cloud Audit Logs](https://cloud.google.com/logging/docs?hl=zh-cn) \u3002Google Cloud Observability \u6703\u6536\u96c6\u4e26\u63d0\u4f9b Cloud Deploy \u7684\u65e5\u8a8c\u8a18\u9304\u6578\u64da\u3002\u53e6\u8acb\u53c3\u95b1 [\u5be9\u8988\u65e5\u8a8c\u8a18\u9304](https://cloud.google.com/deploy/docs/audit-logs?hl=zh-cn) \u3002\n- [Pub/Sub](https://cloud.google.com/pubsub/docs?hl=zh-cn) Cloud Deploy \u6703\u5c07\u6d88\u606f\u767c\u4f48\u5230\u591a\u500b Pub/Sub \u4e3b\u984c\u3002\u60a8\u53ef\u4ee5\u4f7f\u7528\u6b64\u670d\u52d9\u4f86\u8207\u5916\u90e8\u5de5\u4f5c\u6d41\u3001\u6e2c\u8a66\u548c\u5176\u4ed6\u76f8\u95dc\u4fc2\u7d71\u96c6\u6210\u3002\u5982\u9700\u77ad\u89e3\u8a73\u60c5\uff0c\u8acb\u53c3\u95b1 [\u8a02\u95b1 Cloud Deploy \u901a\u77e5](https://cloud.google.com/deploy/docs/subscribe-deploy-notifications?hl=zh-cn) and [Integrating Cloud Deploy with other system](/deploy/docs/integrating) \u3002\n- \u76ee\u6a19\u904b\u884c\u6642Cloud Deploy \u901a\u904e Cloud Build \u4f7f\u7528 [skaffold apply](https://skaffold.dev/docs/workflows/ci-cd/#separation-of-rendering-and-deployment) \u5c07\u61c9\u7528\u90e8\u7f72\u5230\u76ee\u6a19\u904b\u884c\u6642\uff08GKE \u6216 GKE Enterprise\uff09\u3002## Cloud Deploy \u8cc7\u6e90\n\u4e0b\u5716\u986f\u793a\u4e86 Cloud Deploy \u7528\u65bc\u4ea4\u4ed8\u61c9\u7528\u7684\u8cc7\u6e90\u4ee5\u53ca\u9019\u4e9b\u8cc7\u6e90\u4e4b\u9593\u7684\u95dc\u4fc2\uff1a\n\u5982\u5716\u6240\u793a\uff0c\u5404\u8cc7\u6e90\u4e4b\u9593\u7684\u95dc\u4fc2\u5982\u4e0b\uff1a\n- [\u4ea4\u4ed8\u6d41\u6c34\u7dda](https://cloud.google.com/deploy/docs/terminology?hl=zh-cn#delivery_pipeline) \u53ef\u4ee5\u751f\u6210\u96f6\u500b\u6216\u591a\u500b\u7248\u672c\uff0c\u4e26\u4e14\u53ef\u4ee5\u5f15\u7528\u4e00\u500b\u6216\u591a\u500b\u76ee\u6a19 [](https://cloud.google.com/deploy/docs/terminology?hl=zh-cn#target) \uff0c\u5305\u62ec [\u591a\u76ee\u6a19](https://cloud.google.com/deploy/docs/terminology?hl=zh-cn#multi-target) \u53ca\u5176\u95dc\u806f\u7684 [\u5b50\u76ee\u6a19](https://cloud.google.com/deploy/docs/terminology?hl=zh-cn#child_target) \u3002\n- \u6bcf\u500b [\u7248\u672c](https://cloud.google.com/deploy/docs/terminology?hl=zh-cn#release) \u90fd\u5305\u542b [\u6d41\u6c34\u7dda\u5be6\u4f8b](https://cloud.google.com/deploy/docs/terminology?hl=zh-cn#pipeline_instance) \uff0c\u5373\u5275\u5efa\u7248\u672c\u6642\u4ea4\u4ed8\u6d41\u6c34\u7dda\u548c\u76ee\u6a19\u7684\u201c\u5feb\u7167\u201d\u3002\n- \u6bcf\u500b\u7248\u672c\u53ef\u4ee5\u751f\u6210\u96f6\u500b\u6216\u591a\u500b\u201c\u767c\u4f48\u201d [](https://cloud.google.com/deploy/docs/terminology?hl=zh-cn#rollout) \uff0c\u4e26\u4e14\u53ef\u4ee5\u5f15\u7528\u96f6\u500b\u6216\u591a\u500b\u5de5\u4ef6\u3002\u6bcf\u500b\u767c\u4f48\u81f3\u5c11\u5305\u542b\u4e00\u500b\u968e\u6bb5\uff0c\u8868\u793a\u767c\u4f48\u4e2d\u908f\u8f2f\u4e0a\u7d44\u5408\u5728\u4e00\u8d77\u7684\u64cd\u4f5c\uff08\u4f5c\u696d\uff09\u96c6\u5408\uff0c\u4f8b\u5982\u90e8\u7f72\u6216\u90e8\u7f72\u548c\u9a57\u8b49\u3002\u6bcf\u500b\u968e\u6bb5\u90fd\u5305\u542b\u4e00\u500b\u6216\u591a\u500b\u4f5c\u696d\uff0c\u8868\u793a\u8981\u5728\u767c\u4f48\u6642\u5b8c\u6210\u7684\u64cd\u4f5c\uff0c\u5373\u90e8\u7f72\u6216\u9a57\u8b49\u3002\u6bcf\u500b\u4f5c\u696d\u53ef\u4ee5\u5305\u542b\u4e00\u500b\u6216\u591a\u500b\u4f5c\u696d\u904b\u884c\uff0c\u9019\u4e9b\u4f5c\u696d\u904b\u884c\u662f\u4f5c\u696d\u7684\u5be6\u4f8b\uff0c\u4f8b\u5982\uff0c\u5617\u8a66\u90e8\u7f72\u3002\u4f5c\u696d\u904b\u884c\u662f\u767c\u4f48\u7684\u5b50\u8cc7\u6e90\u3002\u7528\u65bc [\u4e26\u884c\u90e8\u7f72](https://cloud.google.com/deploy/docs/parallel?hl=zh-cn) \u7684 [\u591a\u76ee\u6a19](https://cloud.google.com/deploy/docs/terminology?hl=zh-cn#multi-target) \u53ef\u5275\u5efa [\u63a7\u5236\u5668\u767c\u4f48](https://cloud.google.com/deploy/docs/terminology?hl=zh-cn#controller_rollout) \uff0c\u6b64\u985e\u767c\u4f48\u6703\u5275\u5efa\u8207\u5b50\u76ee\u6a19\u5c0d\u61c9\u7684\u5b50\u767c\u4f48\u3002\n- \u6bcf\u6b21\u767c\u4f48\u90fd\u8207\u4e00\u500b\u76ee\u6a19\u76f8\u95dc\u806f\u3002\u5c0d\u65bc [\u4e26\u884c\u90e8\u7f72](https://cloud.google.com/deploy/docs/parallel?hl=zh-cn) \uff0c\u6bcf\u500b [\u5b50\u76ee\u6a19](https://cloud.google.com/deploy/docs/terminology?hl=zh-cn#child_target) \u90fd\u8207\u4e00\u500b [\u5b50\u767c\u4f48](https://cloud.google.com/deploy/docs/terminology?hl=zh-cn#child_rollout) \u76f8\u95dc\u806f\u3002\n- \u6bcf\u500b\u76ee\u6a19\u90fd\u8207\u61c9\u7528\u7684\u4e00\u500b GKE\u3001Anthos \u96c6\u7fa3\u6216\u5176\u4ed6\u904b\u884c\u6642\u76ee\u6a19\u76f8\u95dc\u806f\u3002\n- \u76ee\u6a19\u53ef\u4ee5\u8207\u4e00\u500b\u6216\u591a\u500b\u4ea4\u4ed8\u6d41\u6c34\u7dda\u76f8\u95dc\u806f\u3002\n- \u5de5\u4ef6\u662f\u6307\u5728\u767c\u4f48\u904e\u7a0b\u4e2d\u90e8\u7f72\u5230\u76ee\u6a19\u904b\u884c\u6642\u7684\u4efb\u4f55 CI \u6d41\u7a0b\u8f38\u51fa\uff08\u4f8b\u5982 [\u5bb9\u5668\u6620\u50cf](https://cloud.google.com/deploy/docs/integrating-ci?hl=zh-cn#build_artifacts_versus_images) \uff09\u3002\n\u6b64\u5916\uff0c\u767c\u4f48\u5305\u542b\u4e00\u500b\u6216\u591a\u500b\u968e\u6bb5\uff0c\u800c\u968e\u6bb5\u5305\u542b\u4e00\u500b\u6216\u591a\u500b\u4f5c\u696d\u4ee5\u53ca\u4e00\u500b\u6216\u591a\u500b\u4f5c\u696d\u904b\u884c\u3002\n\u5982\u5716\u6240\u793a\uff0c\u767c\u4f48\u5305\u542b\u4ee5\u4e0b\u5167\u5bb9\uff1a\n- \u968e\u6bb5\u4e00\u500b\u968e\u6bb5\u5305\u542b\u4e00\u500b\u6216\u591a\u500b\u4f5c\u696d\uff08\u4f8b\u5982\u90e8\u7f72\uff0c\u6216\u8005\u90e8\u7f72\u548c\u9a57\u8b49\uff09\u3002\u6bcf\u500b\u767c\u4f48\u90fd\u6709\u4e00\u500b\u6216\u591a\u500b\u968e\u6bb5\u3002\u968e\u6bb5\u662f\u767c\u4f48\u4e2d\u7684\u5b50\u6d88\u606f\u3002\n- \u4f5c\u696d\u8981\u5728\u767c\u4f48\u6642\u57f7\u884c\u7684\u7279\u5b9a\u64cd\u4f5c\uff0c\u4f8b\u5982\u90e8\u7f72\u6216\u9a57\u8b49\u3002\u4f5c\u696d\u662f\u767c\u4f48\u4e2d\u7684\u5b50\u6d88\u606f\u3002\n- JobRuns\u4f5c\u696d\u5be6\u4f8b\uff0c\u4f8b\u5982\u5617\u8a66\u9a57\u8b49\u3002\u6bcf\u500b\u4f5c\u696d\u53ef\u4ee5\u6709\u96f6\u500b\u6216\u591a\u500b JobRun\u3002JobRun \u662f\u767c\u4f48\u7684\u5b50\u8cc7\u6e90\u3002## \u5b83\u5011\u5982\u4f55\u6574\u5408\u5728\u4e00\u8d77\u4ee5\u4ea4\u4ed8\u7248\u672c\n\u672c\u90e8\u5206\u4ecb\u7d39 Cloud Deploy \u5982\u4f55\u8207\u672c\u6587\u6a94\u4e2d\u5217\u51fa\u7684\u7d44\u4ef6\u9032\u884c\u4ea4\u4e92\uff0c\u4ee5\u81ea\u52d5\u5c07\u61c9\u7528\u4f5c\u7232 [\u7248\u672c](https://cloud.google.com/deploy/docs/terminology?hl=zh-cn#release) \u4ea4\u4ed8\u3002\n- \u60a8\u7684 CI \u7cfb\u7d71\u6703\u8abf\u7528 Cloud Deploy \u4ea4\u4ed8\u6d41\u6c34\u7dda\u3002\u60a8\u7684 CI \u6d41\u7a0b\u4f7f\u7528 [CLI](https://cloud.google.com/sdk/gcloud/reference/deploy/releases/create?hl=zh-cn) \u6216 [API](https://cloud.google.com/deploy/docs/api/reference/rest/v1/projects.locations.deliveryPipelines.releases/create?hl=zh-cn) \u8abf\u7528 Cloud Deploy\uff0c\u4ee5\u5275\u5efa\u65b0\u7684\u7248\u672c\uff0c\u4e26\u5c07\u69cb\u5efa\u5de5\u4ef6\u6216\u5c0d\u6620\u50cf\u7684\u5f15\u7528\u50b3\u905e\u3002\u5982\u9700\u8a73\u7d30\u77ad\u89e3\u5982\u4f55\u96c6\u6210 CI \u7cfb\u7d71\uff0c\u8acb\u53c3\u95b1 [\u5c07 Cloud Deploy \u8207\u5176\u4ed6\u7cfb\u7d71\u96c6\u6210](https://cloud.google.com/deploy/docs/integrating?hl=zh-cn#integrating_with_your_ci_system) \u3002\n- \u5275\u5efa\u65b0\u7248\u672c\u5f8c\uff0cCloud Deploy \u6703\u57f7\u884c\u4ee5\u4e0b\u64cd\u4f5c\uff1a- \u5c07\u4ea4\u4ed8\u6d41\u6c34\u7dda\u7684\u5be6\u4f8b\u5b58\u5132\u7232\u7248\u672c\u7684\u4e00\u90e8\u5206\u3002\u5373\u4f7f\u4ea4\u4ed8\u6d41\u6c34\u7dda\u914d\u7f6e\u5df2\u66f4\u6539\uff0c\u6b64\u7248\u672c\u7684\u6b64\u6d41\u6c34\u7dda\u5be6\u4f8b\u4e5f\u4fdd\u6301\u4e0d\u8b8a\u3002\u5982\u9700\u77ad\u89e3\u8a73\u60c5\uff0c\u8acb\u53c3\u95b1 [\u6bcf\u500b\u7248\u672c\u7684\u6d41\u6c34\u7dda\u5be6\u4f8b](https://cloud.google.com/deploy/docs/pipeline-instances?hl=zh-cn) \u3002\u6b64\u5916\uff0c [Skaffold \u7248\u672c](https://cloud.google.com/deploy/docs/using-skaffold/select-skaffold?hl=zh-cn) \u4e5f\u6703\u5b58\u5132\u5728\u8a72\u7248\u672c\u4e2d\u3002\u5728\u5927\u591a\u6578\u60c5\u6cc1\u4e0b\uff0c\u9019\u5c07\u662f\u9ed8\u8a8d\u7684 Skaffold \u7248\u672c\uff0c\u4f46\u7531\u65bc [\u60a8\u53ef\u4ee5\u6307\u5b9a\u5176\u4ed6\u7248\u672c](https://cloud.google.com/deploy/docs/using-skaffold/select-skaffold?hl=zh-cn) \uff0c\u7cfb\u7d71\u6703\u5b58\u5132\u8a72\u4fe1\u606f\u3002\n- \u8abf\u7528 Cloud Build\uff0c\u4ee5\u5f9e Cloud Storage \u7372\u53d6 Skaffold \u6e32\u67d3\u4f86\u6e90\u3002Cloud Deploy \u5c07\u6e32\u67d3\u4f86\u6e90\u5b58\u5132\u5728\u9ed8\u8a8d\u6216\u5099\u7528 Cloud Storage \u5b58\u5132\u6876\u4e2d\u3002\n- \u8abf\u7528 [skaffold diagnose](https://skaffold.dev/docs/references/cli/#skaffold-diagnose) \uff08\u4f7f\u7528\u5275\u5efa\u7248\u672c\u6642\u5b58\u5132\u7684 Skaffold \u7248\u672c\uff09\u751f\u6210\u55ae\u500b\u6709\u6548\u7684\u6e05\u55ae\u3002\n- \u8abf\u7528 [skaffold render](https://skaffold.dev/docs/workflows/ci-cd/#separation-of-rendering-and-deployment) \u4ee5\u4f7f\u7528\u63d0\u4f9b\u7684\u6620\u50cf\u6216\u69cb\u5efa\u5de5\u4ef6\u6e32\u67d3\u6e05\u55ae\u3002Cloud Deploy \u6703\u5c07 `spec.templates.spec.containers.image` \u4e2d\u7684\u6620\u50cf\u540d\u7a31\u66ff\u63db\u7232 `gcloud deploy releases create` \u547d\u4ee4\u6216 [\u8a72\u547d\u4ee4\u5f15\u7528\u7684](https://cloud.google.com/deploy/docs/integrating-ci?hl=zh-cn#calling_from_your_ci_pipeline) \u69cb\u5efa\u5de5\u4ef6\u6587\u4ef6\u4e2d\u63d0\u4f9b\u7684\u5b8c\u6574\u6620\u50cf\u8def\u5f91\uff08\u5305\u62ec\u6458\u8981\u6216\u6a19\u8a18\uff09\u3002Cloud Deploy \u5c07\u6e32\u67d3\u7684\u6e05\u55ae\u5b58\u5132\u5728\u9ed8\u8a8d\u6216\u5099\u7528 Cloud Storage \u5b58\u5132\u6876\u4e2d\u3002Cloud Deploy \u4f7f\u7528\u9ed8\u8a8d\u6216\u5099\u7528 [\u57f7\u884c\u74b0\u5883](https://cloud.google.com/deploy/docs/execution-environment?hl=zh-cn) \u57f7\u884c\u9019\u4e9b\u64cd\u4f5c\u3002\n- \u901a\u904e\u8abf\u7528 [skaffold apply](https://skaffold.dev/docs/workflows/ci-cd/#separation-of-rendering-and-deployment) \u81ea\u52d5\u5275\u5efa\u767c\u4f48\u4e26\u5c07\u5176\u90e8\u7f72\u5230\u7b2c\u4e00\u500b\u76ee\u6a19\u3002\u50c5\u7576\u5f9e CLI \u8abf\u7528 Cloud Deploy \u4ee5\u5275\u5efa\u7248\u672c\u6642\uff0c\u6b64\u5b57\u6bb5\u624d\u9069\u7528\u3002\u90e8\u7f72\u5230\u7b2c\u4e00\u500b\u76ee\u6a19\u7684\u904e\u7a0b\u8207\u63d0\u5347\u76f8\u540c\uff0c\u5982\u4e0b\u4e00\u6b65\u6240\u8ff0\u3002 **\u6ce8\u610f** \uff1a `skaffold apply` \u5305\u542b Skaffold [\u5065\u5eb7\u6aa2\u67e5](https://skaffold.dev/docs/workflows/ci-cd#waiting-for-skaffold-deployments) \uff0c\u5b83\u6703\u7b49\u5f85\u90e8\u7f72\u9032\u5165\u7a69\u5b9a\u72c0\u614b\u3002\n- \u5982\u679c\u4ea4\u4ed8\u6d41\u6c34\u7dda [\u914d\u7f6e](https://cloud.google.com/deploy/docs/config-files?hl=zh-cn#verify) \u4e2d\u7684\u76ee\u6a19\u7684 `verify` \u7232 `true` \uff0c\u4e26\u4e14 [\u5728 Skaffold \u914d\u7f6e\u4e2d\u6307\u5b9a\u4e86\u9a57\u8b49](https://cloud.google.com/deploy/docs/verify-deployment?hl=zh-cn#configure_skaffold) \uff0c\u5247\u8abf\u7528 [skaffold verify](https://skaffold-v2.web.app/docs/pipeline-stages/verify/) \u3002\n- \u7576\u9700\u8981\u5c07\u7248\u672c\u63d0\u5347\u5230\u4e0b\u4e00\u500b\u76ee\u6a19\u6642\uff0cCloud Build \u6703\u5f9e Cloud Storage \u4e2d\u6aa2\u7d22\u7279\u5b9a\u65bc\u76ee\u6a19\u7684\u6e05\u55ae\u3002\u7136\u5f8c\uff0cCloud Build \u8abf\u7528 [skaffold apply](https://skaffold.dev/docs/workflows/ci-cd/#separation-of-rendering-and-deployment) \u4ee5\u5c07\u5df2\u6e32\u67d3\u6e05\u55ae\u61c9\u7528\u65bc\u6307\u5b9a\u7684\u76ee\u6a19\u904b\u884c\u6642\u3002\u5982\u679c\u76ee\u6a19\u9700\u8981 [\u6279\u51c6](https://cloud.google.com/deploy/docs/promote-release?hl=zh-cn#manage_approvals_for_a_delivery_pipeline) \uff0c\u60a8\u53ef\u4ee5\u901a\u904e CLI \u6216\u4f7f\u7528\u63a7\u5236\u6aaf\u6279\u51c6\u6216\u62d2\u7d55\u3002\u6b64\u5916\uff0cCloud Deploy \u9084\u6703\u751f\u6210\u4e00\u689d Pub/Sub \u6d88\u606f\uff0c\u60a8\u53ef\u8a02\u95b1\u8a72\u6d88\u606f\u4ee5 [\u81ea\u52d5\u5553\u52d5\u5be9\u6279\u5de5\u4f5c\u6d41](https://cloud.google.com/deploy/docs/integrating?hl=zh-cn#for_approvals) \u3002Cloud Deploy \u4f7f\u7528\u8207\u6b64\u7248\u672c\u95dc\u806f\u7684 Skaffold \u7248\u672c\u548c\u6d41\u6c34\u7dda\u5be6\u4f8b\uff0c\u4e26\u5728\u9ed8\u8a8d\u6216\u81ea\u5b9a\u7fa9\u57f7\u884c\u74b0\u5883\u4e2d\u57f7\u884c\u6b64\u6b65\u9a5f\u3002\u6b64\u904e\u7a0b\u4e0d\u50c5\u9069\u7528\u65bc\u63d0\u5347\uff0c\u4e5f\u9069\u7528\u65bc\u56de\u6efe\u548c\u91cd\u65b0\u90e8\u7f72\u3002\n- \u5728\u6574\u500b Cloud Deploy \u64cd\u4f5c\u904e\u7a0b\u4e2d\uff0c\u8a72\u670d\u52d9\u6703\u5411 [\u591a\u500b Pub/Sub \u4e3b\u984c](https://cloud.google.com/deploy/docs/subscribe-deploy-notifications?hl=zh-cn) \u767c\u4f48\u901a\u77e5\uff08\u4f8b\u5982\uff0c\u7576\u767c\u4f48 [\u9700\u8981\u6279\u51c6](https://cloud.google.com/deploy/docs/promote-release?hl=zh-cn#require_approval) \u6642\uff09\u3002 [\u5c07 Cloud Deploy \u8207\u5916\u90e8\u7cfb\u7d71\u96c6\u6210](https://cloud.google.com/deploy/docs/integrating?hl=zh-cn) \u4e2d\u4ecb\u7d39\u4e86\u6b64\u96c6\u6210\u548c\u5176\u4ed6\u96c6\u6210\u3002\n- \u5728\u6574\u500b Cloud Deploy \u64cd\u4f5c\u904e\u7a0b\u4e2d\uff0c\u8a72\u670d\u52d9\u6703\u5c07\u5e73\u81fa\u65e5\u8a8c\u548c [\u5be9\u8988\u65e5\u8a8c](https://cloud.google.com/deploy/docs/audit-logs?hl=zh-cn) \u5beb\u5165 Google Cloud Observability \u548c Cloud Audit Logs\u3002\n\u5728\u6240\u6709\u9019\u4e9b\u6b65\u9a5f\u4e2d\uff0c\u90fd\u53ef\u4ee5\u4f7f\u7528 [Identity and Access Management](https://cloud.google.com/deploy/docs/iam-roles-permissions?hl=zh-cn) \u4f86\u9650\u5236\u6d41\u63a7\u5236\u548c\u8cc7\u6e90\u8a2a\u554f\u6b0a\u9650\u3002\n## \u5f8c\u7e8c\u6b65\u9a5f\n- \u8a73\u7d30\u77ad\u89e3\u5982\u4f55 [\u5c07 Cloud Deploy \u8207\u5176\u4ed6\u7cfb\u7d71\u96c6\u6210](https://cloud.google.com/deploy/docs/integrating?hl=zh-cn) \u3002\n- \u67e5\u770b\u6709\u95dc [Skaffold \u7248\u672c\u751f\u547d\u9031\u671f](https://cloud.google.com/deploy/docs/using-skaffold/select-skaffold?hl=zh-cn) \u7684\u91cd\u8981\u4fe1\u606f\u3002\n- \u77ad\u89e3 Cloud Deploy [\u57f7\u884c\u74b0\u5883](https://cloud.google.com/deploy/docs/execution-environment?hl=zh-cn) \u3002\n- \u8a66\u7528 [Cloud Deploy Skaffold \u914d\u7f6e\u6587\u4ef6\u6f14\u793a](https://shell.cloud.google.com/?show=ide%2Cterminal&%3Bwalkthrough_id=deploy--cloud-deploy-profiles-gke&hl=zh-cn) \n- [\u77ad\u89e3\u5982\u4f55\u7d50\u5408\u4f7f\u7528 Google Cloud CI/CD \u5de5\u5177\uff0c\u4ee5\u6709\u6548\u5730\u958b\u767c\u8edf\u4ef6\u4e26\u5c07\u5176\u4ea4\u4ed8\u5230 GKE](https://cloud.google.com/architecture/app-development-and-delivery-with-cloud-code-gcb-cd-and-gke?hl=zh-cn) \u3002", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Cloud Deploy 服務賬號.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Cloud Deploy \u670d\u52d9\u8cec\u865f", "url": "https://cloud.google.com/deploy/docs/cloud-deploy-service-account?hl=zh-cn", "abstract": "# Cloud Deploy - Cloud Deploy \u670d\u52d9\u8cec\u865f\n\u672c\u6587\u6a94\u4ecb\u7d39\u7528\u65bc\u904b\u884c Cloud Deploy \u548c\u8abf\u7528 Cloud Deploy \u4ee5\u904b\u884c\u5404\u7a2e\u64cd\u4f5c\u7684\u670d\u52d9\u5e33\u865f\u3002\nCloud Deploy \u4f7f\u7528\u5169\u500b\u670d\u52d9\u5e33\u865f\uff1a\n- Cloud Deploy [\u670d\u52d9\u4ee3\u7406](https://cloud.google.com/iam/docs/service-agents?hl=zh-cn) Cloud Deploy \u4f7f\u7528\u6b64\u670d\u52d9\u5e33\u865f\u8207\u60a8\u7684\u9805\u76ee\u9032\u884c\u4ea4\u4e92\u3002\u60a8\u7121\u6cd5\u5c07\u6b64\u670d\u52d9\u4ee3\u7406\u66ff\u63db\u7232\u5099\u7528\u670d\u52d9\u8cec\u865f\uff0c\u4f46\u53ef\u4ee5\u4fee\u6539\u5176\u6b0a\u9650\uff0c\u4f8b\u5982\uff0c\u7576\u4f7f\u7528\u9805\u76ee\u5916\u90e8\u7684\u8cc7\u6e90\uff08\u4f8b\u5982\u670d\u52d9\u8cec\u865f\u6216\u5c08\u7528 Cloud Build \u5de5\u4f5c\u5668\u6c60\uff09\u6642\u3002\n- Cloud Deploy \u57f7\u884c\u670d\u52d9\u5e33\u865fCloud Deploy \u4f7f\u7528\u6b64\u670d\u52d9\u5e33\u865f\u5728 Cloud Build \u4e2d\u57f7\u884c\u6e32\u67d3\u548c\u90e8\u7f72\u64cd\u4f5c\u3002\u6b64\u8cec\u865f\u9700\u8981\u8db3\u5920\u7684\u6b0a\u9650\u624d\u80fd\u5c0d Cloud Storage \u5b58\u5132\u6876\u57f7\u884c\u8b80\u5beb\u64cd\u4f5c\u4ee5\u53ca\u8a2a\u554f\u90e8\u7f72\u76ee\u6a19\u3002\u7528\u65bc\u57f7\u884c\u7684\u9ed8\u8a8d\u670d\u52d9\u8cec\u865f\u662f [\u9ed8\u8a8d\u7684 Compute Engine \u670d\u52d9\u8cec\u865f](https://cloud.google.com/deploy/docs/cloud-deploy-service-account?hl=zh-cn#default_service_account) \u3002\u60a8\u53ef\u4ee5\u5728 [\u76ee\u6a19\u914d\u7f6e](https://cloud.google.com/deploy/docs/config-files?hl=zh-cn#target_definitions) \u4e2d\u6307\u5b9a\u5099\u7528\u670d\u52d9\u8cec\u865f\u3002\n- Cloud Deploy \u81ea\u52d5\u5316\u670d\u52d9\u5e33\u865f\u9019\u662f Cloud Deploy \u7528\u65bc\u57f7\u884c [\u81ea\u52d5\u5316](https://cloud.google.com/deploy/docs/automation?hl=zh-cn) \u7684\u670d\u52d9\u5e33\u865f\u3002\u9019\u53ef\u4ee5\u662f\u9ed8\u8a8d\u57f7\u884c\u670d\u52d9\u5e33\u865f\u6216\u5176\u4ed6\u670d\u52d9\u5e33\u865f\u3002\u8acb\u53c3\u95b1 [\u81ea\u52d5\u5316\u670d\u52d9\u5e33\u865f](https://cloud.google.com/deploy/docs/automation-resource?hl=zh-cn#automation_service_account) \u3002\u5982\u9700\u8a73\u7d30\u77ad\u89e3\u6b64\u670d\u52d9\u5e33\u865f\u3002\n\u5982\u9700\u77ad\u89e3\u5982\u4f55\u4fee\u6539\u670d\u52d9\u8cec\u865f\u6b0a\u9650\u4ee5\u53ca\u5982\u4f55\u5275\u5efa\u5099\u7528\u670d\u52d9\u8cec\u865f\uff0c\u8acb\u53c3\u95b1 [\u5275\u5efa\u548c\u7ba1\u7406\u670d\u52d9\u8cec\u865f](https://cloud.google.com/iam/docs/creating-managing-service-accounts?hl=zh-cn) \u3002\n", "content": "## Cloud Deploy \u670d\u52d9\u4ee3\u7406\nCloud Deploy \u670d\u52d9\u4ee3\u7406\u662f Cloud Deploy \u7528\u4f86\u8207 Cloud Deploy \u4f9d\u8cf4\u7684\u5176\u4ed6 Google Cloud \u670d\u52d9\u9032\u884c\u4ea4\u4e92\u7684\u670d\u52d9\u5e33\u865f\u3002\u9019\u4e9b\u670d\u52d9\u5305\u62ec Cloud Build\u3001Pub/Sub \u548c Cloud Audit Logs\u3002\n\u6b64\u670d\u52d9\u8cec\u865f\u7684\u540d\u7a31\u9075\u5faa\u4ee5\u4e0b\u6a21\u5f0f\uff1a\n`service-<project-number>@gcp-sa-clouddeploy.iam.gserviceaccount.com`\n\u60a8\u4e0d\u80fd\u5c07\u670d\u52d9\u4ee3\u7406\u66ff\u63db\u7232\u5099\u7528\u670d\u52d9\u8cec\u865f\u3002\u4f46\u60a8\u53ef\u80fd\u9700\u8981\u6dfb\u52a0\u6b0a\u9650\uff0c\u4f8b\u5982\uff0c\u5141\u8a31\u8a2a\u554f\u53e6\u4e00\u500b\u9805\u76ee\u4e2d\u914d\u7f6e\u7232 [\u57f7\u884c\u74b0\u5883](https://cloud.google.com/deploy/docs/execution-environment?hl=zh-cn) \u4e00\u90e8\u5206\u7684\u5c08\u7528\u6c60\u3002\n## Cloud Deploy \u57f7\u884c\u670d\u52d9\u5e33\u865f\n\u9ed8\u8a8d\u60c5\u6cc1\u4e0b\uff0cCloud Deploy \u4f7f\u7528 [\u9ed8\u8a8d Compute Engine \u670d\u52d9\u5e33\u865f](https://cloud.google.com/iam/docs/service-account-types?hl=zh-cn#default) \u904b\u884c\u3002\u8a72\u670d\u52d9\u8cec\u865f\u5728\u5305\u542b\u5b83\u7684\u9805\u76ee\u4e2d\u5177\u6709\u8db3\u5920\u7684\u6b0a\u9650\uff0c\u53ef\u4ee5\u6e32\u67d3\u6e05\u55ae\u4e26\u5c07\u5176\u90e8\u7f72\u5230\u60a8\u7684\u76ee\u6a19\u3002\n\u6b64\u670d\u52d9\u8cec\u865f\u7684\u540d\u7a31\u9075\u5faa\u4ee5\u4e0b\u6a21\u5f0f\uff1a\n`[project-number]-compute@developer.gserviceaccount.com`\n\u6b64\u9ed8\u8a8d\u670d\u52d9\u8cec\u865f\u5177\u6709\u5ee3\u6cdb\u7684\u6b0a\u9650\u3002\u6700\u4f73\u505a\u6cd5\u662f\u66f4\u6539 [\u57f7\u884c\u74b0\u5883](https://cloud.google.com/deploy/docs/execution-environment?hl=zh-cn) \uff0c\u4ee5\u4fbf Cloud Deploy \u4ee5\u5176\u4ed6\u670d\u52d9\u5e33\u865f\u7684\u8eab\u4efd\u904b\u884c\u3002\u60a8\u53ef\u4ee5\u66f4\u6539\u4f7f\u7528 [\u76ee\u6a19\u5b9a\u7fa9](https://cloud.google.com/deploy/docs/config-files?hl=zh-cn#target_definitions) \u7684 `executionConfigs.privatePool.serviceAccount` \u5c6c\u6027\u6216 `executionConfigs.defaultPool.serviceAccount` \u5c6c\u6027\u4f86\u66f4\u65b0 [\u76ee\u6a19](https://cloud.google.com/deploy/docs/config-files?hl=zh-cn#target_definitions) \u7684\u57f7\u884c\u670d\u52d9\u8cec\u865f\u3002\n\u60a8\u7232\u9019\u4e9b\u5c6c\u6027\u8a2d\u7f6e\u7684\u4efb\u4f55\u670d\u52d9\u8cec\u865f\u90fd\u5fc5\u9808\u5728 Cloud Deploy \u9805\u76ee\u4e2d\u5177\u6709 `roles/clouddeploy.jobRunner` \u89d2\u8272\u3002\u5982\u679c\u9ed8\u8a8d\u57f7\u884c\u670d\u52d9\u8cec\u865f\u6c92\u6709\u6b64\u6b0a\u9650\uff0c\u8acb\u904b\u884c\u4ee5\u4e0b\u547d\u4ee4\uff1a\n```\n\u00a0gcloud projects add-iam-policy-binding PROJECT_ID \\\u00a0 \u00a0 \u00a0--member=serviceAccount:$(gcloud projects describe PROJECT_ID \\\u00a0 \u00a0 \u00a0--format=\"value(projectNumber)\")-compute@developer.gserviceaccount.com \\\u00a0 \u00a0 \u00a0--role=\"roles/clouddeploy.jobRunner\"\n```\n### \u8981\u5275\u5efa\u54ea\u4e9b\u670d\u52d9\u8cec\u865f\n\u5982\u679c\u60a8\u9078\u64c7\u4e0d\u4f7f\u7528\u9ed8\u8a8d\u7684\u57f7\u884c\u670d\u52d9\u8cec\u865f\u9032\u884c\u6e32\u67d3\u548c\u90e8\u7f72\uff0c\u5247\u9700\u8981\u5275\u5efa\u4e00\u500b\u6216\u591a\u500b\u5099\u7528\u670d\u52d9\u8cec\u865f\u3002\u9019\u4e9b\u662f Cloud Deploy \u4ee5\u5176\u8eab\u4efd\u904b\u884c\u7684\u670d\u52d9\u5e33\u865f\uff0c\u4e26 [\u5728\u76ee\u6a19\u914d\u7f6e\u4e2d\u9032\u884c\u914d\u7f6e](https://cloud.google.com/deploy/docs/config-files?hl=zh-cn#target_definitions) \u3002\n\u5275\u5efa\u591a\u500b\u670d\u52d9\u8cec\u865f\u7684\u4e00\u500b\u539f\u56e0\u662f\u60a8\u53ef\u4ee5\u4f7f\u7528\u7279\u5b9a\u670d\u52d9\u8cec\u865f\u4f86\u90e8\u7f72\u5230\u53d7\u9650\u76ee\u6a19\uff0c\u4f8b\u5982\u751f\u7522\u76ee\u6a19\u3002\n\u4e00\u7a2e\u53ef\u80fd\u7684\u65b9\u6cd5\u662f\u7232\u6bcf\u500b\u4ea4\u4ed8\u6d41\u6c34\u7dda\u4f7f\u7528\u55ae\u7368\u7684\u670d\u52d9\u8cec\u865f\u3002\u6bcf\u500b\u6b64\u985e\u670d\u52d9\u8cec\u865f\u90fd\u5305\u542b\u5177\u6709\u8db3\u5920\u6b0a\u9650\u4f86\u9032\u884c\u6e32\u67d3\u548c\u90e8\u7f72\u7684\u89d2\u8272\u3002\n\u5982\u9700\u90e8\u7f72\u5230 Google Kubernetes Engine\uff0c\u60a8\u53ef\u4ee5 [\u5c07\u670d\u52d9\u5e33\u865f\u9650\u5236\u7232\u4e00\u500b\u547d\u540d\u7a7a\u9593](https://cloud.google.com/deploy/docs/securing/sa-by-namespace?hl=zh-cn) \u3002\n### \u4f7f\u7528\u5176\u4ed6\u9805\u76ee\u4e2d\u7684\u670d\u52d9\u8cec\u865f\n\u5c0d\u65bc [\u57f7\u884c\u74b0\u5883](https://cloud.google.com/deploy/docs/execution-environment?hl=zh-cn) \uff0c\u60a8\u53ef\u4ee5\u6307\u5b9a\u670d\u52d9\u5e33\u865f\uff0c\u8a72\u5e33\u865f\u4f4d\u65bc\u8207\u5275\u5efa\u76ee\u6a19\u6642\u4e0d\u540c\u7684\u9805\u76ee\u4e2d\uff1a\n- \u5728\u64c1\u6709\u8a72\u670d\u52d9\u5e33\u865f\u7684\u9805\u76ee\u4e0a\uff0c [\u5553\u7528\u8de8\u9805\u76ee SA \u7d44\u7e54\u653f\u7b56](https://cloud.google.com//iam/docs/attach-service-accounts?hl=zh-cn#enabling-cross-project) \u3002\n- \u5411 Cloud Deploy [\u670d\u52d9\u4ee3\u7406](#service_agent) ( `service-<project-number>@gcp-sa-clouddeploy.iam.gserviceaccount.com` ) \u6388\u4e88\u60a8\u7684\u670d\u52d9\u5e33\u865f\u7684 `iam.serviceAccounts.actAs` \u6b0a\u9650\u3002\u5728\u9019\u7a2e\u60c5\u6cc1\u4e0b\uff0c `project-number` \u662f\u60a8\u5728\u5176\u4e2d\u5275\u5efa\u4e86\u76ee\u6a19\u7684\u9805\u76ee\u3002\u60a8\u9084\u53ef\u4ee5\u5728\u8207\u904b\u884c Cloud Deploy \u904b\u884c\u7684\u9805\u76ee\u4e0d\u540c\u7684\u9805\u76ee\u4e2d\uff0c\u7232\u6bcf\u500b\u670d\u52d9\u5e33\u865f\u6388\u4e88\u5305\u542b\u8a72\u6b0a\u9650\u7684 [roles/iam.serviceAccountUser](https://cloud.google.com/iam/docs/understanding-roles?hl=zh-cn#service-accounts-roles) \u89d2\u8272\u3002\n- \u5411 Cloud Build \u670d\u52d9\u4ee3\u7406 ( `service-<project-number>@gcp-sa-cloudbuild.iam.gserviceaccount.com` ) \u6388\u4e88 `roles/iam.serviceAccountTokenCreator` \u89d2\u8272\u3002\u5728\u9019\u7a2e\u60c5\u6cc1\u4e0b\uff0c `project-number` \u662f\u60a8\u5728\u5176\u4e2d\u5275\u5efa\u4e86\u76ee\u6a19\u7684\u9805\u76ee\uff0c\u4e26\u4e14\u6b64\u89d2\u8272\u5728\u670d\u52d9\u5e33\u865f\u7684\u9805\u76ee\u4e2d\u6388\u4e88\u3002\u5982\u679c\u76ee\u6a19\u57f7\u884c\u74b0\u5883\u4e2d\u914d\u7f6e\u7684\u6bcf\u500b\u670d\u52d9\u5e33\u865f\u8207\u904b\u884c Cloud Deploy \u7684\u9805\u76ee\u4f4d\u65bc\u4e0d\u540c\u7684\u9805\u76ee\u4e2d\uff0c\u60a8\u5fc5\u9808\u5411\u8a72\u670d\u52d9\u5e33\u865f\u6388\u4e88\u6b64\u89d2\u8272\u3002\n- \u5411 `gcloud deploy releases create` \u548c `gcloud deploy rollouts create` \u7684\u8abf\u7528\u65b9\u6388\u4e88\u670d\u52d9\u5e33\u865f\u7684 `iam.serviceAccounts.actAs` \u6b0a\u9650\u6216 `[roles/iam.serviceAccountUser](/iam/docs/understanding-roles#service-accounts-roles)` \u89d2\u8272\u3002\n### \u6240\u9700\u6b0a\u9650\n- \u7528\u65bc\u6e32\u67d3\u914d\u7f6e\u7684\u670d\u52d9\u5e33\u865f\u5fc5\u9808\u5177\u6709\u8db3\u5920\u7684\u6b0a\u9650\uff0c\u80fd\u5920\u8a2a\u554f\u5b58\u5132 Cloud Deploy \u8cc7\u6e90\uff08\u4ea4\u4ed8\u6d41\u6c34\u7dda\u3001\u7248\u672c\u3001\u767c\u4f48\uff09\u7684 Cloud Storage \u5b58\u5132\u6876\u3002`roles/clouddeploy.jobRunner` \u89d2\u8272\u5305\u542b\u6e32\u67d3\u670d\u52d9\u8cec\u865f\uff08 [privatePool \u6216 defaultPool](https://cloud.google.com/deploy/docs/config-files?hl=zh-cn#target_definitions) \uff09\u6240\u9700\u7684\u6240\u6709\u6b0a\u9650\u3002\n- \u7528\u65bc\u90e8\u7f72\u7684\u670d\u52d9\u8cec\u865f\u5fc5\u9808\u5177\u6709\u90e8\u7f72\u5230\u76ee\u6a19\u96c6\u7fa3\u7684\u7684\u8db3\u5920\u6b0a\u9650\u4ee5\u53ca \u8a2a\u554f Cloud Storage \u5b58\u5132\u6876\u7684\u6b0a\u9650\u3002 **\u6ce8\u610f** \uff1a\u5982\u679c\u4f7f\u7528\u81ea\u5b9a\u7fa9 Cloud Storage \u5b58\u5132\u6876\uff0c\u60a8\u53ef\u4ee5\u5c07\u5176\u653e\u5728\u4efb\u4f55\u4f4d\u7f6e\u3002\uff08\u4f8b\u5982\uff0c\u5b83\u4e0d\u9700\u8981\u8207\u4ea4\u4ed8\u6d41\u6c34\u7dda\u4f4d\u65bc\u540c\u4e00\u5340\u57df\u3002\uff09\n- \u8abf\u7528 Cloud Deploy \u4ee5\u5275\u5efa\u7248\u672c\u7684\u670d\u52d9\u5e33\u865f\u5fc5\u9808\u5177\u6709 `clouddeploy.releaser` \u89d2\u8272\u3002\u5b83\u9084\u5fc5\u9808\u5177\u6709 `iam.serviceAccount.actAs` \u6b0a\u9650\uff0c\u4ee5\u4f7f\u7528\u5448\u73fe\u6e05\u55ae\u7684\u670d\u52d9\u5e33\u865f\uff08\u4f8b\u5982\uff0c\u901a\u904e [roles/iam.serviceAccountUser](https://cloud.google.com/iam/docs/understanding-roles?hl=zh-cn#service-accounts-roles) \u89d2\u8272\uff09\u3002\n- \u8abf\u7528 Cloud Deploy \u4ee5\u63d0\u5347\u7248\u672c\u6216\u5275\u5efa `rollout` \u7684\u670d\u52d9\u5e33\u865f\u5fc5\u9808\u5177\u6709 `iam.serviceAccount.actAs` \u6b0a\u9650\u624d\u80fd\u4f7f\u7528\u90e8\u7f72\u5230\u76ee\u6a19\u7684\u670d\u52d9\u5e33\u865f\uff08\u4f8b\u5982\uff0c\u901a\u904e [roles/iam.serviceAccountUser](https://cloud.google.com/iam/docs/understanding-roles?hl=zh-cn#service-accounts-roles) \u89d2\u8272\uff09\u3002\n- \u7232 [\u81ea\u52d5\u5316](https://cloud.google.com/deploy/docs/automation?hl=zh-cn) \u914d\u7f6e\u7684\u670d\u52d9\u5e33\u865f\u5fc5\u9808\u5177\u6709\u904b\u884c\u6b63\u5728\u81ea\u52d5\u5316\u7684\u64cd\u4f5c\u7684\u6b0a\u9650\u3002 [\u77ad\u89e3\u8a73\u60c5](https://cloud.google.com/deploy/docs/automation-resource?hl=zh-cn#automation_service_account) \u3002## \u81ea\u52d5\u5316\u670d\u52d9\u5e33\u865f\n\u60a8\u53ef\u4ee5\u81ea\u52d5\u57f7\u884c\u7248\u672c\u4e2d\u7684\u67d0\u4e9b\u64cd\u4f5c\u3002Cloud Deploy \u4f7f\u7528\u81ea\u52d5\u5316\u670d\u52d9\u5e33\u865f\u4f86\u904b\u884c\u9019\u4e9b\u81ea\u52d5\u5316\u64cd\u4f5c\uff0c\u81ea\u52d5\u5316\u670d\u52d9\u5e33\u865f\u53ef\u4ee5\u662f\u9ed8\u8a8d\u57f7\u884c\u670d\u52d9\u5e33\u865f\u3001\u7528\u4f5c\u57f7\u884c\u670d\u52d9\u5e33\u865f\u7684\u975e\u9ed8\u8a8d\u670d\u52d9\u5e33\u865f\u6216\u5176\u4ed6\u670d\u52d9\u5e33\u865f\u3002\n[\u81ea\u52d5\u5316\u670d\u52d9\u5e33\u865f](https://cloud.google.com/deploy/docs/automation-resource?hl=zh-cn#automation_service_account) \u90e8\u5206\u4ecb\u7d39\u4e86\u6b64\u670d\u52d9\u8cec\u865f\u3002\n## \u5f8c\u7e8c\u6b65\u9a5f\n- \u77ad\u89e3 [IAM](https://cloud.google.com/iam/docs?hl=zh-cn) \u3002\n- \u77ad\u89e3 [\u9810\u5b9a\u7fa9\u7684 Cloud Deploy \u89d2\u8272](https://cloud.google.com/deploy/docs/iam-roles-permissions?hl=zh-cn#predefined_roles) \u3002\n- \u77ad\u89e3\u5982\u4f55 [\u5275\u5efa\u548c\u7ba1\u7406\u670d\u52d9\u8cec\u865f](https://cloud.google.com/iam/docs/creating-managing-service-accounts?hl=zh-cn) \u3002", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Cloud Deploy 概覽.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Cloud Deploy \u6982\u89bd", "url": "https://cloud.google.com/deploy/docs/overview?hl=zh-cn", "abstract": "# Cloud Deploy - Cloud Deploy \u6982\u89bd\nCloud Deploy \u662f\u4e00\u9805\u4ee3\u7ba1\u5f0f\u670d\u52d9\uff0c\u53ef\u81ea\u52d5\u5c07\u61c9\u7528\u4ea4\u4ed8\u5230\u5b9a\u7fa9\u7684\u5347\u7d1a\u5e8f\u5217\u4e2d\u7684\u4e00\u7cfb\u5217 [\u76ee\u6a19](https://cloud.google.com/deploy/docs/terminology?hl=zh-cn#target) \u74b0\u5883\u3002\u5982\u679c\u60a8\u8981\u90e8\u7f72\u66f4\u65b0\u5f8c\u7684\u61c9\u7528\uff0c\u5247\u9700\u8981\u5275\u5efa\u4e00\u500b [\u7248\u672c](https://cloud.google.com/deploy/docs/terminology?hl=zh-cn#release) \uff0c\u5176 [lifecycle](https://cloud.google.com/deploy/docs/architecture?hl=zh-cn#how_they_fit_together_to_deliver_your_release) \u7531 [\u4ea4\u4ed8\u6d41\u6c34\u7dda](https://cloud.google.com/deploy/docs/terminology?hl=zh-cn#delivery_pipeline) \u7ba1\u7406\u3002\n", "content": "## Cloud Deploy \u6d41\u6c34\u7dda\u7684\u5de5\u4f5c\u539f\u7406\nCloud Deploy \u4ea4\u4ed8\u6d41\u6c34\u7dda\u5305\u542b\u4ee5\u4e0b\u4fe1\u606f\uff1a\n- \u60a8\u5728\u5f15\u7528\u4ea4\u4ed8\u6d41\u6c34\u7dda\u6642\u4f7f\u7528\u7684\u540d\u7a31\u548c\u8aaa\u660e\u3002\n- \u984c\u8a2d\u5e8f\u5217\uff0c\u63cf\u8ff0\u90e8\u7f72\u5230\u5df2\u914d\u7f6e [\u76ee\u6a19](https://cloud.google.com/deploy/docs/terminology?hl=zh-cn#target) \u7684\u9806\u5e8f\u3002\n- \uff08\u53ef\u9078\uff09 [\u6a19\u7c64\u548c\u8a3b\u91cb](https://cloud.google.com/deploy/docs/labels-annotations?hl=zh-cn) \u3002\n- \u6216\u8005\uff0c\u4f60\u4e5f\u53ef\u4ee5\u6307\u5b9a\u76ee\u6a19\u5b9a\u7fa9\u672c\u8eab\u3002\n\u53ef\u4ee5\u5728\u540c\u4e00\u4ea4\u4ed8\u6d41\u6c34\u7dda [\u914d\u7f6e\u6587\u4ef6](https://cloud.google.com/deploy/docs/config-files?hl=zh-cn) \u6216\u4e00\u500b\u6216\u591a\u500b\u55ae\u7368\u7684\u6587\u4ef6\u4e2d [\u5b9a\u7fa9](https://cloud.google.com/deploy/docs/config-files?hl=zh-cn#target_definitions) \u76ee\u6a19\u3002\u591a\u500b\u4ea4\u4ed8\u6d41\u6c34\u7dda\u53ef\u4ee5\u4f7f\u7528\u76f8\u540c\u7684\u4e00\u500b\u6216\u591a\u500b\u76ee\u6a19\uff0c\u4f46\u7d66\u5b9a\u76ee\u6a19\u5728\u7d66\u5b9a\u7684\u4ea4\u4ed8\u6d41\u6c34\u7dda\u4e2d\u53ea\u80fd\u4f7f\u7528\u4e00\u6b21\u3002\n### Cloud Deploy \u4ea4\u4ed8\u6d41\u7a0b\n\u4e0b\u9762\u4ecb\u7d39\u4e86\u7c21\u55ae\u7684 Cloud Deploy \u6301\u7e8c\u4ea4\u4ed8\u5834\u666f\u4e2d\u6703\u767c\u751f\u7684\u60c5\u6cc1\u3002\n- \u60a8\u5728 [YAML \u914d\u7f6e\u6587\u4ef6](https://cloud.google.com/deploy/docs/config-files?hl=zh-cn#structure_of_a_delivery_pipeline_configuration_file) \u4e2d\u5b9a\u7fa9 [\u4ea4\u4ed8\u6d41\u6c34\u7dda](https://cloud.google.com/deploy/docs/terminology?hl=zh-cn#delivery_pipeline) \u3002\u6b64\u914d\u7f6e\u6587\u4ef6\u5b9a\u7fa9\u5c07\u61c9\u7528\u90e8\u7f72\u5230\u4e00\u7cfb\u5217 [\u76ee\u6a19](https://cloud.google.com/deploy/docs/terminology?hl=zh-cn#target) \u7684\u63d0\u5347\u5e8f\u5217\u3002\u6b64\u5916\uff0c\u60a8\u9084\u9700\u8981\u4e00\u9805 [Skaffold](https://cloud.google.com/skaffold?hl=zh-cn) \u7684 [\u914d\u7f6e](https://skaffold.dev/docs/references/yaml/) \uff0cCloud Deploy \u9700\u8981\u9019\u9805\u914d\u7f6e\u624d\u80fd\u57f7\u884c\u6e32\u67d3\u548c\u90e8\u7f72\u64cd\u4f5c\u3002\n- \u60a8\u53ef\u4ee5\u5728\u6d41\u6c34\u7dda\u914d\u7f6e\u6587\u4ef6\u6216\u4e00\u500b\u6216\u591a\u500b\u55ae\u7368\u7684\u6587\u4ef6\u4e2d\u5b9a\u7fa9\u76ee\u6a19\u3002\n- \u60a8\u53ef\u4ee5\u5411 Cloud Deploy \u670d\u52d9\u8a3b\u518a\u6d41\u6c34\u7dda\u3002\u73fe\u5728\uff0c\u670d\u52d9\u77e5\u9053\u4e86\u60a8\u7684\u61c9\u7528\uff0c\u56e0\u6b64\u6703\u6839\u64da\u60a8\u5b9a\u7fa9\u7684\u63d0\u5347\u5e8f\u5217\u7ba1\u7406\u90e8\u7f72\u5230\u76ee\u6a19\u7684\u64cd\u4f5c\u3002\n- CI \u6d41\u7a0b\u7684\u8f38\u51fa\u5305\u62ec\u5c0d Cloud Deploy \u7684\u8abf\u7528\uff0c\u4ee5\u5553\u52d5\u60a8\u7684\u4ea4\u4ed8\u6d41\u6c34\u7dda\u3002\u6b64\u8abf\u7528\u6703\u5275\u5efa `release` \u8cc7\u6e90\uff0c\u8a72\u8cc7\u6e90\u8868\u793a\u6bcf\u500b\u76ee\u6a19\u7684\u5df2\u6e32\u67d3\u6e05\u55ae\uff0c\u6bcf\u500b\u6e05\u55ae\u90fd\u662f\u4f7f\u7528\u63d0\u4f9b\u7684\u6e32\u67d3\u4f86\u6e90\u3001skaffold.yaml \u548c\u5c0d\u8981\u90e8\u7f72\u7684\u7279\u5b9a\u5bb9\u5668\u6620\u50cf\u7684\u5f15\u7528\u751f\u6210\u7684\u3002\u9996\u6b21\u8abf\u7528\u5275\u5efa [\u7248\u672c](https://cloud.google.com/deploy/docs/terminology?hl=zh-cn#release) \u6642\uff0cCloud Deploy \u6703\u81ea\u52d5\u5275\u5efa\u4e00\u500b [rollout](https://cloud.google.com/deploy/docs/terminology?hl=zh-cn#rollout) \u8cc7\u6e90\uff0c\u5c07\u7248\u672c\u8207\u7b2c\u4e00\u500b\u76ee\u6a19\u74b0\u5883\u76f8\u95dc\u806f\u3002\u6839\u64da\u8a72\u767c\u4f48\uff0c\u60a8\u7684\u61c9\u7528\u6703\u90e8\u7f72\u5230\u7b2c\u4e00\u500b\u76ee\u6a19\u3002\u60a8\u53ef\u4ee5\u4f7f\u7528\u4efb\u4f55 CI \u5de5\u5177\uff0c\u53ea\u8981\u5b83\u6703\u8f38\u51fa\u4e00\u500b\u6216\u591a\u500b\u5bb9\u5668\u6620\u50cf\u4ee5\u63d0\u4f9b\u7d66 Cloud Deploy \u4ea4\u4ed8\u6d41\u6c34\u7dda\u5373\u53ef\u3002\u6b64\u5916\uff0c\u5275\u5efa\u767c\u4f48\u548c\u8abf\u7528\u4ea4\u4ed8\u6d41\u6c34\u7dda\u7684\u8abf\u7528\u4e0d\u5fc5\u4f86\u81ea CI \u5de5\u5177\u3002\u5b83\u53ef\u4ee5\u4f86\u81ea\u8173\u672c\u6216\u97ff\u61c9 CI \u904e\u7a0b\u5b8c\u6210\u7684\u4efb\u4f55\u7cfb\u7d71\u3002\n- \u7576\u60a8\u6e96\u5099\u597d\u5c07\u61c9\u7528\u90e8\u7f72\u5230\u4e0b\u4e00\u500b\u76ee\u6a19\u6642\uff0c\u53ef\u4ee5\u8abf\u7528 Cloud Deploy \u4f86\u63d0\u5347\u8a72\u61c9\u7528\u3002\u7121\u8ad6\u662f\u54ea\u7a2e\u60c5\u6cc1\uff0c\u8abf\u7528\u63d0\u5347\u7684\u8abf\u7528\u90fd\u6703\u5c0e\u81f4 Cloud Deploy \u5275\u5efa\u65b0\u7684\u767c\u4f48\u3002\n- \u63d0\u5347\u6703\u7e7c\u7e8c\u4ee5\u5b8c\u6210\u63d0\u5347\u5e8f\u5217\u4e2d\u7684\u6240\u6709\u76ee\u6a19\uff0c\u6700\u5f8c\u4e00\u500b\u662f `prod` \uff08\u6216\u60a8\u7528\u65bc\u5c07\u61c9\u7528\u90e8\u7f72\u5230\u751f\u7522\u7684\u6700\u7d42\u76ee\u6a19\u7684\u4efb\u4f55\u540d\u7a31\uff09\u3002 [Cloud Deploy \u670d\u52d9\u67b6\u69cb](https://cloud.google.com/deploy/docs/architecture?hl=zh-cn#how_they_fit_together_to_deliver_your_release) \u66f4\u8a73\u7d30\u5730\u4ecb\u7d39\u4e86\u7248\u672c\u7684\u5275\u5efa\u548c\u63a8\u5ee3\u904e\u7a0b\u3002\n\u5728\u6574\u500b\u6d41\u6c34\u7dda\u57f7\u884c\u904e\u7a0b\u4e2d\uff0cCloud Deploy \u6703\u6536\u96c6\u6307\u6a19\u548c [\u5be9\u8988](https://cloud.google.com/deploy/docs/audit-logs?hl=zh-cn) \u8a73\u7d30\u4fe1\u606f\u3002\n### \u63a8\u5ee3\n[\u63d0\u5347\u7248\u672c](https://cloud.google.com/deploy/docs/promote-release?hl=zh-cn) \u5c31\u662f\u5c07\u7248\u672c\u90e8\u7f72\u5230\u6d41\u6c34\u7dda\u4e2d\u5b9a\u7fa9\u7684\u63d0\u5347\u5e8f\u5217\u4e2d\u7684\u4e0b\u4e00\u500b\u76ee\u6a19\u3002\u5c0d Cloud Deploy \u7684\u7b2c\u4e00\u6b21\u8abf\u7528\u6703\u5275\u5efa\u4e00\u500b `release` \uff0c\u7136\u5f8c\u5275\u5efa\u4e00\u500b `rollout` \u8cc7\u6e90\uff08\u7528\u65bc\u90e8\u7f72\u5230\u63d0\u5347\u5e8f\u5217\u4e2d\u7684\u7b2c\u4e00\u500b\u76ee\u6a19\uff09\u3002\u4e4b\u5f8c\u6bcf\u6b21\u8abf\u7528\u4ee5\u63d0\u5347\u7248\u672c\u90fd\u6703\u5c0e\u81f4\u767c\u4f48\u5230\u4e0b\u4e00\u500b\u76ee\u6a19\u3002\n### \u6279\u51c6\n\u60a8\u53ef\u4ee5\u6307\u5b9a\u9700\u8981\u6279\u51c6\u624d\u80fd\u63d0\u5347\u5230\u4efb\u4f55\u76ee\u6a19\u3002\u4f8b\u5982\uff0c\u60a8\u53ef\u80fd\u9700\u8981\u7372\u5f97\u6279\u51c6\u624d\u80fd\u63d0\u5347\u5230\u751f\u7522\u76ee\u6a19\u3002\u5982\u9700\u8981\u6c42\u6279\u51c6\u76ee\u6a19\uff0c\u8acb\u5728 [\u76ee\u6a19\u5b9a\u7fa9](https://cloud.google.com/deploy/docs/config-files?hl=zh-cn#target_definitions) \u4e2d\u8a2d\u7f6e `requireApproval` \u5c6c\u6027\u3002\n\u7576\u76ee\u6a19\u9700\u8981\u5be9\u6279\u6642\uff0cCloud Deploy \u6703\u751f\u6210\u4e00\u689d Pub/Sub \u6d88\u606f\uff0c\u4f9b\u96c6\u6210\u7cfb\u7d71\u4f7f\u7528\u3002 \u4f8b\u5982\uff0c\u5de5\u55ae\u7cfb\u7d71\u53ef\u4ee5\u8a02\u95b1\u8a72\u6d88\u606f\u4ee5\u5553\u52d5\u5be9\u6279\u5de5\u4f5c\u6d41\u3002\n\u5982\u9700\u8a73\u7d30\u77ad\u89e3\u4fc3\u92b7\u6d3b\u52d5\u548c\u7ba1\u7406\u4fc3\u92b7\u6d3b\u52d5\u7684\u5be9\u6279\uff0c\u8acb\u53c3\u95b1 [\u9700\u8981\u6279\u51c6](https://cloud.google.com/deploy/docs/promote-release?hl=zh-cn) \u3002\n### \u901a\u77e5\nCloud Deploy \u7232\u4ee5\u4e0b\u4e8b\u4ef6\u63d0\u4f9b Pub/Sub \u901a\u77e5\uff1a\n- \u6e32\u67d3\uff1a\u958b\u59cb\u3001\u6210\u529f\u548c\u5931\u6557\n- \u90e8\u7f72\uff1a\u958b\u59cb\u3001\u6210\u529f\u548c\u5931\u6557\n- \u9700\u8981\u7372\u5f97\u6279\u51c6\n- \u6279\u51c6\u5df2\u7372\u5f97\u6279\u51c6\n- \u6279\u51c6\u8acb\u6c42\u906d\u62d2\nCloud Deploy \u4f7f\u7528 Pub/Sub \u4e3b\u984c\u4f86\u767c\u9001\u9019\u4e9b\u901a\u77e5\u3002\n\u5982\u9700\u77ad\u89e3\u8a73\u60c5\uff0c\u8acb\u53c3\u95b1 [\u4f7f\u7528 Cloud Deploy \u901a\u77e5](https://cloud.google.com/deploy/docs/subscribe-deploy-notifications?hl=zh-cn) \u3002\n### \u56de\u6efe\nCloud Deploy \u652f\u6301\u5728\u4efb\u4f55\u76ee\u6a19\u4e2d\u56de\u6efe\u5df2\u90e8\u7f72\u7684\u61c9\u7528\u3002Cloud Deploy \u4e2d\u7684\u56de\u6efe\u5305\u62ec\u91dd\u5c0d\u4e0a\u6b21\u6210\u529f\u90e8\u7f72\u7684\u7248\u672c\u89f8\u767c\u767c\u4f48\u3002\u65b0\u767c\u4f48\u6703\u4f7f\u7528\u8a72\u6210\u529f\u90e8\u7f72\u4e2d\u4f7f\u7528\u7684\u76f8\u540c\u53c3\u6578\u3002\n\u5982\u9700\u77ad\u89e3\u8a73\u60c5\uff0c\u8acb\u53c3\u95b1 [\u56de\u6efe\u90e8\u7f72](https://cloud.google.com/deploy/docs/roll-back?hl=zh-cn) \u3002\n## Skaffold \u548c Cloud Deploy \u7c21\u4ecb\nCloud Deploy \u4f7f\u7528 [Skaffold](https://cloud.google.com/skaffold?hl=zh-cn) \u9032\u884c\u6e32\u67d3\u3001\u90e8\u7f72\u548c\u9a57\u8b49\u3002\u85c9\u52a9 Skaffold\uff0c\u60a8\u9084\u53ef\u4ee5\u8f15\u9b06\u5c07\u672c\u5730\u958b\u767c\u5faa\u74b0\u9023\u63a5\u5230 Cloud Deploy \u6301\u7e8c\u4ea4\u4ed8\u6d41\u6c34\u7dda\u3002\n\u5982\u9700\u8a73\u7d30\u77ad\u89e3 Cloud Deploy \u5982\u4f55\u8207 Skaffold \u96c6\u6210\uff0c\u8acb\u53c3\u95b1 [Skaffold \u6982\u89bd](https://cloud.google.com/deploy/docs/using-skaffold?hl=zh-cn) \u3002\n## \u5c07 Cloud Deploy \u8207\u5176\u4ed6 Google Cloud \u5de5\u5177\u642d\u914d\u4f7f\u7528\nCloud Deploy \u652f\u6301 CI/CD \u6d41\u6c34\u7dda\u4e2d\u5e7e\u4e4e\u6240\u6709\u4e0a\u6e38\u5de5\u5177\u3002 \u4e5f\u5c31\u662f\u8aaa\uff0c\u60a8\u53ef\u4ee5\u4f7f\u7528\u4efb\u4f55\u958b\u767c\u74b0\u5883\u548c\u6e90\u4ee3\u78bc\u5eab\u3001\u4efb\u4f55\u6301\u7e8c\u96c6\u6210 (CI) \u7cfb\u7d71\u548c\u4efb\u4f55\u5de5\u4ef6\u4ee3\u78bc\u5eab\u3002\n\u4e0b\u6e38\uff0cCloud Deploy \u90e8\u7f72\u5230 Google Kubernetes Engine\u3001Cloud Run \u548c GKE Enterprise\u3002\n\u5982\u679c\u60a8\u4e3b\u8981\u4f7f\u7528 Google Cloud \u5de5\u5177\uff0c\u5247\u5f9e\u6e90\u4ee3\u78bc\u5230\u751f\u7522\u74b0\u5883\u7684\u6d41\u7a0b\u5982\u4e0b\u6240\u793a\uff1a\n- \u4f7f\u7528 [Cloud Code](https://cloud.google.com/code/docs?hl=zh-cn) \u4f86\u5275\u5efa\u61c9\u7528\u4f86\u6e90\u3002Cloud Code \u64f4\u5c55\u4e86\u5e7e\u7a2e\u6d41\u884c\u7684 IDE\uff08VS Code\u3001IntelliJ \u548c Cloud Shell\uff09\uff0c\u4ee5\u4fbf\u66f4\u8f15\u9b06\u5730\u69cb\u5efa\u61c9\u7528\u4ee5\u5728 Google Cloud \u4e0a\u90e8\u7f72\u548c\u904b\u884c\u3002\n- \u4f7f\u7528 [Skaffold](https://skaffold.dev) \u4f86\u7ba1\u7406\u672c\u5730\u958b\u767c\u5faa\u74b0\u3002Cloud Deploy \u901a\u904e Cloud Build \u4f7f\u7528 Skaffold \u4f86\u6e32\u67d3\u548c\u90e8\u7f72\u6e05\u55ae\u3002\u9019\u7a2e\u96c6\u6210\u610f\u5473\u7740\u60a8\u9700\u8981\u7dad\u8b77 `skaffold.yaml` \u6587\u4ef6\uff0c\u4f46\u4e26\u4e0d\u610f\u5473\u7740\u60a8\u9700\u8981\u5c07 Skaffold \u8a2d\u7232\u672c\u5730\u958b\u767c\u6d41\u7a0b\u7684\u4e00\u90e8\u5206\u3002\u4f46\u60a8\u53ef\u4ee5\u5229\u7528\u5b83\u9032\u884c [\u6301\u7e8c\u958b\u767c](https://skaffold.dev/docs/workflows/dev/) \u3002\n- \u4f7f\u7528 Cloud Build \u69cb\u5efa\u61c9\u7528\u3002\u85c9\u52a9 [Cloud Build](https://cloud.google.com/build/docs?hl=zh-cn) \uff0c\u60a8\u53ef\u4ee5\u8a2d\u7f6e CI \u6d41\u6c34\u7dda\uff0c\u8a72\u6d41\u6c34\u7dda\u53ef\u7531\u63d0\u4ea4\u5230\u6e90\u4ee3\u78bc\u5eab\u89f8\u767c\u3002Cloud Build \u7684\u8f38\u51fa\u5c07\u662f\u5305\u542b\u53ef\u90e8\u7f72\u5bb9\u5668\u6620\u50cf\u7684\u5de5\u4ef6\u3002\u60a8\u53ef\u4ee5\u6dfb\u52a0\u5c0d Cloud Deploy \u7684\u8abf\u7528\uff0c\u4ee5\u5275\u5efa\u7248\u672c\u4e26\u8abf\u7528\u4ea4\u4ed8\u6d41\u6c34\u7dda\u3002\n- \u5c07\u5de5\u4ef6\u5b58\u5132\u5728 Artifact Registry \u4e2d\u3002Cloud Deploy \u5f9e [Artifact Registry](https://cloud.google.com/artifact-registry/docs?hl=zh-cn) \u4e2d\u6aa2\u7d22\u4e00\u500b\u6216\u591a\u500b\u5bb9\u5668\u6620\u50cf\uff0c\u4ee5\u96c6\u4e2d\u5b58\u5132\u5de5\u4ef6\u548c\u4f9d\u8cf4\u9805\u3002\n- \u5728 Cloud Deploy \u4e2d\u914d\u7f6e\u4ea4\u4ed8\u6d41\u6c34\u7dda\uff0c\u4ee5\u63d0\u53d6\u5bb9\u5668\u6620\u50cf\u4e26\u9010\u6b65\u90e8\u7f72 n \u500b\u76ee\u6a19\u3002 \u5728\u4ea4\u4ed8\u6d41\u6c34\u7dda\u4e2d\u6a19\u8b58\u7684\u6bcf\u500b\u76ee\u6a19\u90fd\u4ee3\u8868\u6700\u7d42\u90e8\u7f72\u61c9\u7528\u7684 GKE \u96c6\u7fa3\u3001Cloud Run \u6216 GKE \u96c6\u7fa3\u3002\n- \u5728 GKE\u3001Cloud Run \u6216 GKE Enterprise \u4e0a\u7ba1\u7406\u60a8\u7684\u61c9\u7528\u3002 [GKE](https://cloud.google.com/kubernetes-engine/docs?hl=zh-cn) \u662f Google Cloud \u7ba1\u7406\u7684\u74b0\u5883\uff0c\u7528\u65bc\u5728 Kubernetes \u4e0a\u904b\u884c\u5bb9\u5668\u5316\u61c9\u7528\u3002\u85c9\u52a9 [Cloud Run](https://cloud.google.com/run/docs?hl=zh-cn) \uff0c\u60a8\u53ef\u4ee5\u5728\u7121\u670d\u52d9\u5668\u74b0\u5883\u4e2d\u904b\u884c\u5bb9\u5668\u3002 [GKE Enterprise](https://cloud.google.com/anthos/docs?hl=zh-cn) \u53ef\u7232\u96f2\u7aef\u548c\u672c\u5730\u74b0\u5883\u63d0\u4f9b\u4e00\u81f4\u7684\u958b\u767c\u548c\u904b\u71df\u9ad4\u9a57\u3002\n- \u4f7f\u7528 Google Cloud Observability \u76e3\u63a7\u61c9\u7528\u7684\u6027\u80fd\u3002 [Google Cloud Observability](https://cloud.google.com/stackdriver/docs?hl=zh-cn) \u53ef\u7232\u60a8\u7684\u61c9\u7528\u63d0\u4f9b\u96c6\u6210\u5f0f\u76e3\u63a7\u548c\u65e5\u8a8c\u8a18\u9304\u3002## \u5f8c\u7e8c\u6b65\u9a5f\n- \u5982\u9700\u5feb\u901f\u8f15\u9b06\u5730\u5275\u5efa\u4ea4\u4ed8\u6d41\u6c34\u7dda\u4e26\u7528\u5176\u90e8\u7f72\u61c9\u7528\uff0c\u8acb\u53c3\u95b1 [\u5feb\u901f\u5165\u9580](https://cloud.google.com/deploy/docs/quickstarts?hl=zh-cn) \u3002\n- \u8a66\u7528 [Cloud Deploy \u6f14\u793a](https://shell.cloud.google.com/?show=ide%2Cterminal&%3Bwalkthrough_id=deploy--cloud-deploy-e2e-gke&hl=zh-cn) \u3002\n- \u8a73\u7d30\u77ad\u89e3 [Cloud Deploy \u7d44\u4ef6\u5982\u4f55\u5354\u540c\u5de5\u4f5c](https://cloud.google.com/deploy/docs/architecture?hl=zh-cn) \u3002\n- \u67e5\u770b [Google Cloud \u67b6\u69cb\u6846\u67b6\uff1a\u5353\u8d8a\u904b\u71df](https://cloud.google.com/architecture/framework/operational-excellence?hl=zh-cn) \uff0c\u67e5\u770b\u6709\u95dc\u5982\u4f55\u4f7f\u7528\u5353\u8d8a\u904b\u71df\u539f\u5247\u69cb\u5efa\u81ea\u52d5\u4ea4\u4ed8\u57fa\u790e\u7684\u6587\u7ae0\u3002\n- [\u77ad\u89e3\u5982\u4f55\u7d50\u5408\u4f7f\u7528 Google Cloud CI/CD \u5de5\u5177\uff0c\u4ee5\u6709\u6548\u5730\u958b\u767c\u8edf\u4ef6\u4e26\u5c07\u5176\u4ea4\u4ed8\u5230 GKE](https://cloud.google.com/architecture/app-development-and-delivery-with-cloud-code-gcb-cd-and-gke?hl=zh-cn) \u3002", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Cloud Deploy 術語.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Cloud Deploy \u8853\u8a9e", "url": "https://cloud.google.com/deploy/docs/terminology?hl=zh-cn", "abstract": "# Cloud Deploy - Cloud Deploy \u8853\u8a9e\n\u672c\u6587\u6a94\u4e2d\u7684\u8853\u8a9e\u6839\u64da\u5b83\u5011\u5728 Cloud Deploy \u4e2d\u7684\u4f7f\u7528\u65b9\u5f0f\u9032\u884c\u5b9a\u7fa9\u3002\n", "content": "## \u7121\u6eff\u610f\u7b54\u6848\n\u5982\u9700 [\u6c38\u4e45\u505c\u7528\u67d0\u500b\u7248\u672c](https://cloud.google.com/deploy/docs/abandon-release?hl=zh-cn) \uff0c\n## \u61c9\u7528\n\u60a8\u5c07\u4f7f\u7528 Cloud Deploy \u90e8\u7f72\u7684\u8edf\u4ef6\u3002\n## \u61c9\u7528\u4ea4\u4ed8\n\u4ea4\u4ed8\u5c07\u61c9\u7528\u90e8\u7f72\u5230\u610f\u5411 [\u76ee\u6a19](#target) \u74b0\u5883\u6240\u9700\u7684\u8cc7\u6e90\u3002\u5728 Cloud Deploy \u4e2d\uff0c\u61c9\u7528\u4ea4\u4ed8\u5305\u62ec\u751f\u6210\u3001\u5347\u7d1a [\u61c9\u7528](#application) \u7684 Kubernetes \u6e05\u55ae\u4e26\u5c07\u5176\u4ea4\u4ed8\u5230\u96c6\u7fa3\u4e2d\u3002\n## \u5de5\u4ef6\n\u8981\u90e8\u7f72\u7684\u5bb9\u5668\u6620\u50cf\uff08\u69cb\u5efa\u5de5\u4ef6\uff09\u4ee5\u53ca\u7528\u65bc\u90e8\u7f72\u7684\u914d\u7f6e\u6587\u4ef6\uff08\u4f8b\u5982\u6e05\u55ae\u548c Skaffold \u914d\u7f6e\uff09\uff08 [\u76ee\u6a19\u5de5\u4ef6](#target_artifacts) \uff09\u3002\n## \u81ea\u52d5\u5316\n\u901a\u904e\u81ea\u52d5\u5316\u529f\u80fd\uff0c\u60a8\u53ef\u4ee5\u914d\u7f6e\u4ea4\u4ed8\u6d41\u6c34\u7dda\u548c\u76ee\u6a19\uff0c\u4ee5\u4fbf\u53ef\u4ee5\u5c0d\u8a72\u6d41\u6c34\u7dda\u7684\u7248\u672c\u548c\u767c\u4f48\u57f7\u884c\u67d0\u4e9b\u64cd\u4f5c\uff0c\u800c\u7121\u9700\u4eba\u5de5\u5e72\u9810\u3002\u4f8b\u5982\uff0c\u60a8\u53ef\u4ee5\u8a2d\u7f6e\u4ea4\u4ed8\u6d41\u6c34\u7dda\uff0c\u4ee5\u4fbf\u5728\u9069\u7576\u60c5\u6cc1\u4e0b\u81ea\u52d5\u63d0\u5347\u5230\u7279\u5b9a\u76ee\u6a19\u3002 [\u77ad\u89e3\u8a73\u60c5](https://cloud.google.com/deploy/docs/automation?hl=zh-cn) \u3002\n## \u81ea\u52d5\u5316\u64cd\u4f5c\u898f\u5247\n[\u81ea\u52d5\u5316\u64cd\u4f5c](https://cloud.google.com/deploy/docs/automation?hl=zh-cn) \u7684\u884c\u7232\u90e8\u5206\u7531\u81ea\u52d5\u5316\u898f\u5247\u5b9a\u7fa9\u3002\u81ea\u52d5\u5316\u898f\u5247\u7528\u65bc\u5b9a\u7fa9\u81ea\u52d5\u5316\u64cd\u4f5c\uff0c\u4f8b\u5982\u63a8\u5ee3\u7248\u672c\u3002\n[\u4f7f\u7528\u81ea\u52d5\u5316\u898f\u5247](https://cloud.google.com/deploy/docs/automation-rules?hl=zh-cn) \u6587\u6a94\u5217\u51fa\u4e86\u53ef\u7528\u7684\u81ea\u52d5\u5316\u898f\u5247\u3002\n## \u81ea\u52d5\u5316\u904b\u884c\n[Automation](#automation) \u7684\u5be6\u4f8b\u3002\n## Canary \u90e8\u7f72\n\u4e00\u7a2e\u90e8\u7f72\u7b56\u7565\uff0c\u5373\u5148\u5411\u4e00\u90e8\u5206\u7528\u6236\u767c\u4f48\u66f4\u6539\uff0c\u5c0d\u5176\u9032\u884c\u6e2c\u8a66\u4ee5\u78ba\u4fdd\u53ef\u9760\u6027\uff0c\u7136\u5f8c\u5168\u9762\u767c\u4f48\u3002\n## \u5b50\u767c\u4f48\n\u5c0d\u65bc [\u4e26\u884c\u90e8\u7f72](#parallel_deployment) \uff0c\u7cfb\u7d71\u6703\u751f\u6210\u90e8\u7f72\u5230 [\u5b50\u76ee\u6a19](#child_target) \u7684\u767c\u4f48\u3002\n\u53e6\u8acb\u53c3\u95b1 [\u63a7\u5236\u5668\u767c\u4f48](#controller_rollout) \u3002\n## \u5b50\u5b9a\u4f4d\u689d\u4ef6\n\u5c0d\u65bc [\u4e26\u884c\u90e8\u7f72](#parallel_deployment) \uff0c\u4e00\u500b\u76ee\u6a19\uff0c\u8868\u793a\u8981\u540c\u6642\u90e8\u7f72\u5230\u7684\u591a\u500b GKE\u3001GKE Enterprise \u6216 Cloud Run \u5404\u500b\u76ee\u6a19\u3002\n\u53e6\u8acb\u53c3\u95b1 [\u591a\u76ee\u6a19](#multi_target) \u3001 [\u4e26\u884c\u90e8\u7f72](#parallel_deployment) \u3001 [\u5b50\u767c\u4f48](#child_rollout) \u3002\n## \u6301\u7e8c\u4ea4\u4ed8\n\u4e00\u7a2e\u8edf\u4ef6\u5de5\u7a0b [\u505a\u6cd5](https://cloud.google.com/solutions/devops/devops-tech-continuous-delivery?hl=zh-cn) \uff0c\u5176\u4e2d\u66f4\u6539\u53ef\u4ee5\u5b89\u5168\u3001\u983b\u7e41\u4e26\u4e14\u4e3b\u8981\u662f\u81ea\u52d5\u767c\u4f48\u5230\u7528\u6236\u3002\n## \u6301\u7e8c\u90e8\u7f72\n\u5c0e\u81f4\u81ea\u52d5\u90e8\u7f72\u5c0d\u4ee3\u78bc\u548c\u914d\u7f6e\u7684\u66f4\u6539\u7684\u8edf\u4ef6\u5de5\u7a0b\u505a\u6cd5\u3002\n\u6301\u7e8c\u4ea4\u4ed8 \u9700\u8981\u5728\u4e00\u500b\u6216\u591a\u500b\u968e\u6bb5\u9032\u884c\u624b\u52d5\u6279\u51c6\uff0c\u800c\u6301\u7e8c\u90e8\u7f72\u662f\u81ea\u52d5\u9032\u884c\u7684\uff0c\u7121\u9700\u624b\u52d5\u6279\u51c6\u3002\n## \u63a7\u5236\u5668\u767c\u4f48\n\u7232 [\u4e26\u884c\u90e8\u7f72](#parallel_deployment) \u751f\u6210\u7684\u767c\u4f48\u3002\u63a7\u5236\u5668\u767c\u4f48\u4e0d\u7528\u65bc\u90e8\u7f72\u5230\u55ae\u500b\u76ee\u6a19\u96c6\u7fa3\u6216\u670d\u52d9\uff1b\u800c\u662f\u91dd\u5c0d\u6bcf\u500b [\u5b50\u76ee\u6a19](#child_target) \u6709\u4e00\u500b [\u5b50\u767c\u4f48](#child_rollout) \u3002\n\u53e6\u8acb\u53c3\u95b1 [\u4e26\u884c\u90e8\u7f72](#parallel_deployment) \u3001 [\u591a\u76ee\u6a19](#multi_-_target) \u3002\n## \u81ea\u5b9a\u7fa9\u76ee\u6a19\n\u4f7f\u7528\u7528\u6236\u5b9a\u7fa9\u7684 [\u81ea\u5b9a\u7fa9\u76ee\u6a19\u985e\u578b](https://cloud.google.com/deploy/docs/custom-targets?hl=zh-cn) \u800c\u4e0d\u662f\u67d0\u500b [\u53d7\u652f\u6301\u7684\u76ee\u6a19\u985e\u578b](https://cloud.google.com/deploy/docs/create-pipeline-targets?hl=zh-cn#define_the_delivery_pipeline_and_targets) \u7684\u76ee\u6a19\u3002\n## \u8072\u660e\u5f0f\n\u7cfb\u7d71\uff08\u4f8b\u5982 Kubernetes \u96c6\u7fa3\uff09\u7684\u914d\u7f6e\uff0c\u63cf\u8ff0\u9810\u671f\u72c0\u614b\u4e26\u4f9d\u8cf4\u8a72\u7cfb\u7d71\u5be6\u73fe\u8a72\u72c0\u614b\u3002\u8207\u547d\u4ee4\u5f0f\u914d\u7f6e\u76f8\u5c0d\uff1b\u5728\u547d\u4ee4\u5f0f\u914d\u7f6e\u4e2d\uff0c\u60a8\u63cf\u8ff0\u5be6\u73fe\u8a72\u72c0\u614b\u7684\u5177\u9ad4\u6b65\u9a5f\u3002\n\u9664\u4e86\u6e32\u67d3\u548c\u90e8\u7f72\u8072\u660e\u6027 Kubernetes \u6e05\u55ae\u4e4b\u5916\uff0cCloud Deploy \u9084\u4f7f\u7528\u8072\u660e\u6027\u8cc7\u6e90\u5b9a\u7fa9\u4f86\u5b9a\u7fa9\u6e32\u67d3\u548c\u4ea4\u4ed8\u6d41\u7a0b\u3002 `skaffold.yaml` \u548c `clouddeploy.yaml` \u662f Skaffold \u5b9a\u7fa9\u548c\u4ea4\u4ed8\u6d41\u6c34\u7dda\u5b9a\u7fa9\u7684\u5178\u578b\u6587\u4ef6\u540d\u3002\n## \u4ea4\u4ed8\u6d41\u6c34\u7dda\n\u5411 [\u90e8\u7f72\u9032\u5c55](#progression) \u4e2d\u7684\u6bcf\u500b\u76ee\u6a19\u4ea4\u4ed8\u61c9\u7528\u7684\u5de5\u4f5c\u6d41\u7684\u8868\u793a\u6cd5\u3002\nCloud Deploy \u7684\u6587\u6a94\u4f7f\u7528\u201c\u4ea4\u4ed8\u6d41\u6c34\u7dda\u201d\u4e00\u8a5e\u4f86\u5c07\u5176\u8207\u60a8\u53ef\u80fd\u4f7f\u7528\u7684\u5176\u4ed6\u6d41\u6c34\u7dda\uff08\u4f8b\u5982 CI \u6d41\u6c34\u7dda\uff09\u5340\u5206\u958b\u4f86\u3002\n\u5728 Cloud Deploy \u4e2d\uff0c\u4ea4\u4ed8\u6d41\u6c34\u7dda\u5728 YAML \u914d\u7f6e\u6587\u4ef6\uff08\u901a\u5e38\u7232 `clouddeploy.yaml` \uff09\u4e2d\u5b9a\u7fa9\uff0c\u8a72\u5b9a\u7fa9\u5305\u62ec\u4ee5\u4e0b\u5167\u5bb9\uff1a\n- \u90e8\u7f72 [\u76ee\u6a19](#target) \n- \u9019\u4e9b\u76ee\u6a19\u4e2d\u7684\u63d0\u5347\u5e8f\u5217\n**\u6ce8\u610f** \uff1a\u60a8\u53ef\u4ee5\u5728\u55ae\u7368\u7684\u6587\u4ef6\u4e2d\u5b9a\u7fa9\u76ee\u6a19\u3002\n\u53e6\u8acb\u53c3\u95b1 [\u6d41\u6c34\u7dda\u5be6\u4f8b](#pipeline_instance) \u3002\n## \u90e8\u7f72\u9264\u5b50\n\u60a8\u53ef\u4ee5\u5728\u90e8\u7f72\u4e4b\u524d\u6216\u90e8\u7f72\u4e4b\u5f8c\u904b\u884c\u7684\u4efb\u610f [\u64cd\u4f5c](https://cloud.google.com/deploy/docs/hooks?hl=zh-cn#configure_in_skaffold) \u3002 [\u77ad\u89e3\u8a73\u60c5](https://cloud.google.com/deploy/docs/hooks?hl=zh-cn) \u3002\n## \u90e8\u7f72\u53c3\u6578\n\u53ef\u6dfb\u52a0\u5230\u6e05\u55ae\u4e2d\uff0c\u4f46\u4e0d\u5728\u6e32\u67d3\u904e\u7a0b\u4e2d\u89e3\u6790\u7684\u4f54\u4f4d\u7b26\u3002\u76f8\u53cd\uff0c\u9019\u4e9b\u4f54\u4f4d\u7b26\u7684\u503c\u6703\u5728\u6bcf\u500b\u7279\u5b9a\u65bc\u76ee\u6a19\u7684\u6e05\u55ae\u5448\u73fe\u5f8c\u9032\u884c\u5206\u914d\u3002 [\u77ad\u89e3\u8a73\u60c5](https://cloud.google.com/deploy/docs/parameters?hl=zh-cn) \u3002\n## \u90e8\u7f72\u7b56\u7565\n\u4e00\u7a2e\u5b89\u5168\u90e8\u7f72\u61c9\u7528\u66f4\u6539\u4e26\u6700\u5927\u9650\u5ea6\u5730\u6e1b\u5c11\u5c0d\u7528\u6236\u7684\u5f71\u97ff\u7684\u6280\u8853\u3002\n## \u57f7\u884c\u74b0\u5883\n\u904b\u884c Cloud Deploy \u7684\u4e00\u7d44 Google Cloud \u8cc7\u6e90\u3002 \u5b83\u5305\u542b\u4ee5\u4e0b\u5167\u5bb9\uff1a\n- Cloud Deploy \u5728\u5176\u4e2d\u57f7\u884c\u6e32\u67d3\u548c\u90e8\u7f72\u64cd\u4f5c\u7684\u9ed8\u8a8d\u6216\u5c08\u7528 [\u5de5\u4f5c\u5668\u6c60](https://cloud.google.com/build/docs/private-pools/private-pools-overview?hl=zh-cn) \n- \u8abf\u7528 Cloud Deploy \u4ee5\u57f7\u884c\u6e32\u67d3\u548c\u90e8\u7f72\u7684\u9ed8\u8a8d\u6216\u5099\u7528 [\u57f7\u884c\u74b0\u5883](https://cloud.google.com/deploy/docs/execution-environment?hl=zh-cn) \u670d\u52d9\u5e33\u865f\n- Cloud Storage \u4e2d\u5df2\u6e32\u67d3\u6e05\u55ae\u7684\u9ed8\u8a8d\u6216\u5099\u7528\u5b58\u5132\u4f4d\u7f6e\u3002## \u878d\u5408\n\u8acb\u53c3\u95b1 [\u6e32\u67d3](#render) \u3002\n## \u4f5c\u696d\n\u8981\u5728\u767c\u4f48\u6642\u57f7\u884c\u7684\u7279\u5b9a\u64cd\u4f5c\uff0c\u4f8b\u5982\u90e8\u7f72\u6216\u9a57\u8b49\u3002 [\u77ad\u89e3\u8a73\u60c5](https://cloud.google.com/deploy/docs/verify-deployment?hl=zh-cn) \u3002\n## \u4f5c\u696d\u904b\u884c\n\u4f5c\u7232\u767c\u4f48\u7684\u5b50\u8cc7\u6e90\uff0c\u4f5c\u696d\u904b\u884c\u662f\u4f5c\u696d\u7684\u5be6\u4f8b\u3002\u4e5f\u5c31\u662f\u8aaa\uff0c\u5b83\u8868\u793a\u5617\u8a66\u57f7\u884c\u90e8\u7f72\u6216\u9a57\u8b49\u7b49\u4f5c\u696d\u3002 [\u77ad\u89e3\u8a73\u60c5](https://cloud.google.com/deploy/docs/verify-deployment?hl=zh-cn) \u3002\n## \u6e05\u55ae\n\u7528\u65bc\u5275\u5efa\u3001\u4fee\u6539\u548c\u522a\u9664 Kubernetes \u8cc7\u6e90\uff08\u4f8b\u5982 Pod\u3001Deployment\u3001Service \u6216 Ingress\uff09\u7684 Kubernetes \u914d\u7f6e\u5c0d\u8c61\u3002\nCloud Deploy \u4e2d\u7684\u6e05\u55ae\u4ee5\u5169\u7a2e\u72c0\u614b\u4e2d\u7684\u4e00\u7a2e\u5b58\u5728\uff1a\u5df2\u6e32\u67d3\u6216\u672a\u6e32\u67d3\u3002\u672a\u6e32\u67d3\u7684\u6e05\u55ae\u5c1a\u672a\u6e96\u5099\u597d\u90e8\u7f72\u5230\u76ee\u6a19\u4e2d\u3002\u6e32\u67d3\u6d41\u7a0b\uff08\u5305\u62ec\u5c07\u7279\u5b9a\u503c\u586b\u5145\u5230\u6e05\u55ae\u4e2d\uff09\u901a\u5e38\u7531 Helm\u3001Kustomize \u548c kpt \u7b49\u5de5\u5177\u57f7\u884c\u3002Cloud Deploy \u4f7f\u7528 Skaffold \u7de8\u6392\u914d\u7f6e\u7684\u6e32\u67d3\uff08 [skaffold render](https://skaffold.dev/docs/workflows/ci-cd/#separation-of-rendering-and-deployment) \u547d\u4ee4\uff09\u3002\n\u53e6\u8acb\u53c3\u95b1 [\u6e32\u67d3](#render) \u3002\n## \u591a\u76ee\u6a19\n\u914d\u7f6e\u6216\u57f7\u884c\u4e26\u884c\u90e8\u7f72\u6642\uff0c\u591a\u76ee\u6a19\u662f\u6307\u55ae\u500b\u6d41\u6c34\u7dda\u968e\u6bb5\uff0c\u4f46\u53ef\u4ee5\u5305\u542b\u591a\u500b\u76ee\u6a19\u904b\u884c\u6642\u3002\n\u53e6\u8acb\u53c3\u95b1 [\u5b50\u76ee\u6a19](#child_target) \u3001 [\u4e26\u884c\u90e8\u7f72](#parallel_deployment) \u3001 [\u63a7\u5236\u5668\u767c\u4f48](#controller_rollout) \u3002\n## \u4e26\u884c\u90e8\u7f72\n\u5728\u540c\u4e00\u4ea4\u4ed8\u6d41\u6c34\u7dda\u968e\u6bb5\u540c\u6642\u5c07\u61c9\u7528\u90e8\u7f72\u5230\u591a\u500b\u76ee\u6a19\u7684\u505a\u6cd5\u3002\u4f8b\u5982\uff0c\u9019\u7a2e\u65b9\u6cd5\u53ef\u8b93\u60a8\u90e8\u7f72\u5230\u751f\u7522\u74b0\u5883\u4e2d\u7684\u591a\u500b\u96c6\u7fa3\u6216\u670d\u52d9\u3002\n## \u968e\u6bb5\n\u767c\u4f48\u4e2d\u4ee5\u908f\u8f2f\u65b9\u5f0f\u7d44\u5408\u5728\u4e00\u8d77\u7684\u64cd\u4f5c\uff08\u4f5c\u696d\uff09\u96c6\u5408\uff0c\u4f8b\u5982\u90e8\u7f72\u6216\u90e8\u7f72\u548c\u9a57\u8b49\u3002 [\u77ad\u89e3\u8a73\u60c5](https://cloud.google.com/deploy/docs/verify-deployment?hl=zh-cn) \u3002\n## \u6d41\u6c34\u7dda\n\u8acb\u53c3\u95b1 [\u4ea4\u4ed8\u6d41\u6c34\u7dda](#delivery_pipeline)\n## \u6d41\u6c34\u7dda\u5be6\u4f8b\n\u5275\u5efa `release` \u6642\u622a\u53d6\u7684\u4ea4\u4ed8\u6d41\u6c34\u7dda\u7684\u5feb\u7167\u3002Cloud Deploy \u6703\u4fdd\u7559\u6b64\u5feb\u7167\uff0c\u4ee5\u78ba\u4fdd\u4f7f\u7528\u5275\u5efa `release` \u6642\u6240\u5b9a\u7fa9\u7684\u6d41\u6c34\u7dda\u4e00\u81f4\u5730\u7ba1\u7406\u7248\u672c\u7684\u6240\u6709\u90e8\u7f72\u3002\n\u5982\u9700\u77ad\u89e3\u8a73\u60c5\uff0c\u8acb\u53c3\u95b1 [\u6bcf\u500b\u7248\u672c\u7684\u6d41\u6c34\u7dda\u5be6\u4f8b](https://cloud.google.com/deploy/docs/pipeline-instances?hl=zh-cn) \u3002\n## \u6d41\u6c34\u7dda\u4e0d\u5339\u914d\n\u7576\u5728\u5275\u5efa\u7248\u672c\u5f8c\u66f4\u6539\u767c\u4f48\u6d41\u6c34\u7dda\u6216\u76ee\u6a19\u6642\uff0c\u8207 `release` \u95dc\u806f\u7684 [\u6d41\u6c34\u7dda\u5be6\u4f8b](#pipeline_instance) \u73fe\u5728\u8207\u6d41\u6c34\u7dda\u5b9a\u7fa9\u4e0d\u540c\u3002\n\u5982\u679c\u5b58\u5728\u6d41\u6c34\u7dda\u4e0d\u5339\u914d\uff0cCloud Deploy \u6703\u63d0\u793a\u60a8\u6aa2\u67e5\u5b9a\u7fa9\uff0c\u7136\u5f8c\u518d\u63d0\u5347\u7248\u672c\u6216\u5617\u8a66\u56de\u6efe\u3002\n\u5982\u9700\u77ad\u89e3\u8a73\u60c5\uff0c\u8acb\u53c3\u95b1 [\u6bcf\u500b\u7248\u672c\u7684\u6d41\u6c34\u7dda\u5be6\u4f8b](https://cloud.google.com/deploy/docs/pipeline-instances?hl=zh-cn) \u3002\n## \u9032\u5c55\n\u4ea4\u4ed8\u6d41\u6c34\u7dda\u914d\u7f6e\u6587\u4ef6\u4e2d\u7684\u4e00\u9805\u914d\u7f6e\uff0c\u7528\u65bc\u63cf\u8ff0\u5f9e\u4e00\u500b\u76ee\u6a19\u5230\u53e6\u4e00\u500b\u76ee\u6a19\u7684\u63d0\u5347\u5e8f\u5217\uff0c\u4f8b\u5982\u5f9e `test` \u5230 `staging` \u518d\u5230 `prod` \u3002\n## \u63a8\u5ee3\n\u6839\u64da\u4ea4\u4ed8\u6d41\u6c34\u7dda\u4e2d\u5b9a\u7fa9\u7684 [\u9032\u5c55](#progression) \u5c07\u7248\u672c\u5f9e\u4e00\u500b\u76ee\u6a19\u63a8\u9032\u5230\u53e6\u4e00\u500b\u76ee\u6a19\u7684\u904e\u7a0b\u3002\n## \u8a3b\u518a\n\u4ee5\u4ea4\u4ed8\u6d41\u6c34\u7dda\u7684\u5f62\u5f0f\u5411 Cloud Deploy \u670d\u52d9\u63d0\u4f9b\u61c9\u7528\uff0c\u4ee5\u4fbf\u61c9\u7528\u7684\u4ea4\u4ed8\u7531\u8a72\u670d\u52d9\u7ba1\u7406\u3002\n## \u767c\u4f48\u7248\u672c\nCloud Deploy \u8cc7\u6e90\uff0c\u8868\u793a\u8981\u90e8\u7f72\u7684\u66f4\u6539\uff08\u4ee3\u78bc\u548c/\u6216\u914d\u7f6e\uff09\u3002\n[Cloud Deploy \u670d\u52d9\u67b6\u69cb](https://cloud.google.com/deploy/docs/architecture?hl=zh-cn#how_they_fit_together_to_deliver_your_release) \u6587\u6a94\u4ecb\u7d39\u4e86\u767c\u4f48\u751f\u547d\u9031\u671f\u3002\n## \u6e32\u67d3\n\u6e96\u5099\u6e05\u55ae\u4ee5\u5728\u76ee\u6a19\u4e2d\u90e8\u7f72\u3002\u6e32\u67d3\u6e05\u55ae\u4e3b\u8981\u662f\u7232\u6e05\u55ae\u4e2d\u7684\u8b8a\u91cf\u63d0\u4f9b\u503c\u3002Cloud Deploy \u4f7f\u7528 [skaffold render](https://skaffold.dev/docs/workflows/ci-cd/#separation-of-rendering-and-deployment) \u57f7\u884c\u6b64\u64cd\u4f5c\u3002\n\u9019\u4e0d\u5305\u62ec\u7232 [\u90e8\u7f72\u53c3\u6578](https://cloud.google.com/deploy/docs/parameters?hl=zh-cn) \u586b\u5145\u503c\n## \u767c\u4f48\n\u5c07 [\u7248\u672c](#release) \u8207\u90e8\u7f72 [\u76ee\u6a19](#target) \u95dc\u806f\u7684\u8cc7\u6e90\u3002\u7cfb\u7d71\u6703\u7232\u6bcf\u500b\u76ee\u6a19\u7684\u6bcf\u500b\u7248\u672c\u5275\u5efa\u4e00\u500b `rollout` \uff0c\u56e0\u6b64\u5728\u4ea4\u4ed8\u6d41\u6c34\u7dda\u4e2d\u7684\u4e09\u500b\u76ee\u6a19\u7684\u7c21\u55ae\u9032\u7a0b\u4e2d\uff0c\u8a72\u7248\u672c\u6703\u6709\u4e09\u500b `rollout` \u8cc7\u6e90\uff0c\u6bcf\u500b\u76ee\u6a19\u5c0d\u61c9\u4e00\u500b\u3002\n\u5c0d\u65bc\u66f4\u5fa9\u96dc\u7684\u90e8\u7f72\uff08\u4f8b\u5982\u4f7f\u7528 Canary \u90e8\u7f72\u7b56\u7565\uff09\uff0c `rollout` \u53ef\u80fd\u6703\u66f4\u5fa9\u96dc\u3002 [\u77ad\u89e3\u8a73\u60c5](https://cloud.google.com/deploy/docs/deployment-strategies?hl=zh-cn#structure_of_a_rollout) \u3002\n## \u6a19\u6e96\u90e8\u7f72\u7b56\u7565\n\u6a19\u6e96\u90e8\u7f72\u7b56\u7565\u662f\u5c07\u61c9\u7528\u90e8\u7f72\u5230\u76ee\u6a19\u7684\u9ed8\u8a8d\u65b9\u5f0f\u3002\u5c0d\u65bc\u4ea4\u4ed8\u6d41\u6c34\u7dda\u4e2d\u5b9a\u7fa9\u7684\u6bcf\u500b\u968e\u6bb5\uff0c\u60a8\u7684\u61c9\u7528\u90fd\u6703\u5b8c\u5168\u90e8\u7f72\u5230\u76ee\u6a19\uff0c\u4e26\u4e14\u6bcf\u6b21\u90fd\u6703\u66ff\u63db\u4e4b\u524d\u90e8\u7f72\u7684\u61c9\u7528\u3002\n## \u968e\u6bb5\n\u4ea4\u4ed8\u6d41\u6c34\u7dda\u4e2d\u7684\u4e00\u500b\u76ee\u6a19\u6216\u591a\u500b\u76ee\u6a19\u3002\u4f8b\u5982\uff0c\u5728\u5177\u6709\u4ee5\u4e0b\u968e\u6bb5\u7684\u7c21\u55ae\u4ea4\u4ed8\u6d41\u6c34\u7dda\u4e2d\uff1a\n- `dev`\n- `staging`\n- `prod`\n\u6bcf\u500b\u9078\u9805\u5747\u7232\u4e00\u500b\u968e\u6bb5\u3002\n\u57f7\u884c [\u4e26\u884c\u90e8\u7f72](#parallel_deployment) \u6642\uff0c [multi-target](https://cloud.google.com/deploy/docs/parallel?hl=zh-cn) \u662f\u55ae\u500b\u968e\u6bb5\uff0c\u4f46 [\u5b50\u76ee\u6a19](#child_target) \u4e0d\u662f\u55ae\u7368\u7684\u968e\u6bb5\u3002\n## \u66ab\u505c\uff08\u4ea4\u4ed8\u6d41\u6c34\u7dda\uff09\n\u9632\u6b62\u5f9e\u7d66\u5b9a\u4ea4\u4ed8\u6d41\u6c34\u7dda\u5275\u5efa\u548c\u63d0\u5347\u7248\u672c\u3002\u5982\u9700\u77ad\u89e3\u8a73\u60c5\uff0c\u8acb\u53c3\u95b1 [\u66ab\u505c\u4ea4\u4ed8\u6d41\u6c34\u7dda](https://cloud.google.com/deploy/docs/suspend-pipeline?hl=zh-cn)\n## \u76ee\u6a19\n\u8981\u5728\u5176\u4e2d\u90e8\u7f72\u61c9\u7528\u7684\u7279\u5b9a\u904b\u884c\u6642\u74b0\u5883\uff08Kubernetes \u96c6\u7fa3\u3001Cloud Run \u670d\u52d9\u6216\u5176\u4ed6\u53d7\u652f\u6301\u7684\u904b\u884c\u6642\uff09\u3002\u4ee5\u53ca\u8a72\u74b0\u5883\u7684\u914d\u7f6e\u3002\n\u60a8\u53ef\u4ee5\u5728 [\u4ea4\u4ed8\u6d41\u6c34\u7dda](#delivery_pipeline) \u914d\u7f6e\u6587\u4ef6\u4e2d\u5b9a\u7fa9\u76ee\u6a19\uff0c\u4e5f\u53ef\u4ee5\u5728\u55ae\u7368\u7684\u6587\u4ef6\u4e2d\u5b9a\u7fa9\u76ee\u6a19\u3002\n\u76ee\u6a19\u4e5f\u53ef\u4ee5\u662f [multi-target](#multi-target) \u6216 [\u5b50\u76ee\u6a19](#child_target) \uff0c\u4ee5\u652f\u6301 [\u4e26\u884c\u90e8\u7f72](#parallel_deployment) \u3002\n## \u76ee\u6a19\u5de5\u4ef6\n\u7528\u65bc\u5728\u76ee\u6a19\u4e0a\u6e32\u67d3\u548c\u90e8\u7f72\u61c9\u7528\u7684\u914d\u7f6e\u6587\u4ef6\u3002\u9019\u4e9b\u6587\u4ef6\u5305\u62ec Kubernetes \u6e05\u55ae\u6216 Cloud Run \u670d\u52d9\u5b9a\u7fa9\u3001Skaffold \u914d\u7f6e\u6587\u4ef6\u4ee5\u53ca\u7528\u65bc\u5275\u5efa\u9019\u4e9b\u5167\u5bb9\u7684\u6e32\u67d3\u6e90\u3002\n## \u9a57\u8b49\n\u80fd\u5920\u901a\u904e\u904b\u884c\u4efb\u610f\u5bb9\u5668\u9032\u884c\u6e2c\u8a66\u4f86\u78ba\u8a8d\u90e8\u7f72\u662f\u5426\u6210\u529f\u7684\u529f\u80fd\u3002 [\u8a73\u7d30\u77ad\u89e3\u90e8\u7f72\u9a57\u8b49](https://cloud.google.com/deploy/docs/verify-deployment?hl=zh-cn) \u3002", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Configuration schema reference.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Configuration schema reference", "url": "https://cloud.google.com/deploy/docs/config-files", "abstract": "# Cloud Deploy - Configuration schema reference\nThe Cloud Deploy configuration file or files define the [delivery pipeline](/deploy/docs/terminology#delivery_pipeline) , the [targets](/deploy/docs/terminology#target) to deploy to, and the [progression](/deploy/docs/terminology#progression) of those targets.\nThe delivery pipeline configuration file include [target definitions](#target_definitions) , or those can be in a separate file or files. By convention, a file containing both the delivery pipeline config and the target configs is called `clouddeploy.yaml` , and a pipeline config without targets is called `delivery-pipeline.yaml` . But you can give these files any name you want.\n**Note:** your organization might prefer to separate target definitions from the pipeline definition, so that different roles can manage those configurations separately. Cloud Deploy supports that practice.\n", "content": "## What goes where\nCloud Deploy uses two main configuration files:\n- Delivery pipeline definition\n- [Target definition](#target_definitions) \nThese can be separate files, or the delivery pipeline and targets can be configured in the same file.\n**Note:** After you define the configuration file or files, you create the delivery pipeline and target resources using the command line, as described in [Registering the delivery pipeline and targets](/deploy/docs/create-pipeline-targets#register_the_delivery_pipeline_and_targets) .\n## Structure of a delivery pipeline configuration file\nThe following configuration includes a target definition:\n```\n# Delivery pipeline configapiVersion: deploy.cloud.google.com/v1kind: DeliveryPipelinemetadata:\u00a0name:\u00a0annotations:\u00a0labels:description:suspended:serialPipeline:\u00a0stages:\u00a0- targetId:\u00a0 \u00a0profiles: []# Deployment strategies# One of:# \u00a0 standard:# \u00a0 canary:# See the strategy section in this document for details.\u00a0 \u00a0strategy:\u00a0 \u00a0 \u00a0standard:\u00a0 \u00a0 \u00a0 \u00a0verify:\u00a0 \u00a0 \u00a0 \u00a0predeploy:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0actions: []\u00a0 \u00a0 \u00a0 \u00a0postdeploy:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0actions: []\u00a0 \u00a0deployParameters:\u00a0 \u00a0- values:\u00a0 \u00a0 \u00a0matchTargetLabels:\u00a0- targetId:\u00a0 \u00a0profiles: []\u00a0 \u00a0strategy:\u00a0 \u00a0deployParameters:---# Target configapiVersion: deploy.cloud.google.com/v1kind: Targetmetadata:\u00a0name:\u00a0annotations:\u00a0labels:description:multiTarget:\u00a0targetIds: []deployParameters:requireApproval:\n## Runtimes# one of the following runtimes:gke:\u00a0cluster:\u00a0internalIp:\n## or:anthosCluster:\u00a0membership:\n## or:run:\u00a0location:\n## or:customTarget:\u00a0 customTargetType:\n## (End runtimes. See documentation in this article for more details.)#executionConfigs:- usages:\u00a0 - [RENDER | PREDEPLOY | DEPLOY | VERIFY | POSTDEPLOY]\u00a0 workerPool:\u00a0 serviceAccount:\u00a0 artifactStorage:\u00a0 executionTimeout:---# Custom target type configapiVersion: deploy.cloud.google.com/v1kind: CustomTargetTypemetadata:\u00a0 name:\u00a0 annotations:\u00a0 labels:description:customActions:\u00a0 renderAction:\u00a0 deployAction:\u00a0 includeSkaffoldModules:\u00a0 \u00a0 - configs:\u00a0 \u00a0 # either:\u00a0 \u00a0 googleCloudStorage:\u00a0 \u00a0 \u00a0 source:\u00a0 \u00a0 \u00a0 path:\u00a0 \u00a0 # or:\u00a0 \u00a0 git:\u00a0 \u00a0 \u00a0 repo:\u00a0 \u00a0 \u00a0 path:\u00a0 \u00a0 \u00a0 ref:---# Automation configapiVersion: deploy.cloud.google.com/v1kind: Automationmetadata:\u00a0 name:\u00a0 labels:\u00a0 annotations:description:suspended:serviceAccount:selector:- target:\u00a0 \u00a0 id:\u00a0 \u00a0 # or\u00a0 \u00a0 labels:rules:- [RULE_TYPE]:\u00a0 name:\u00a0 [RULE-SPECIFIC_CONFIG]\n```\nThis YAML has three main components:\n- The main delivery pipeline and progressionThe configuration file can include any number of pipeline definitions.\n- The target definitionsFor simplicity, only one target is shown in this example, but there can be any number of them. Also, targets can be defined in a separate file or files.\n- Custom target type definitions [Custom targets](/deploy/docs/custom-targets) , require a custom target type definition. As with targets and automations, custom target types can be defined in the same file as the delivery pipeline, or in separate file.\n- Automation definitionsYou can create any [deploy automations](/deploy/docs/automation) in the same file as your delivery pipeline and targets, or in a separate file or files. For simplicity, only one `Automation` is shown here, but you can create as many as you want.\nThese components are defined in the rest of this document.\n## Pipeline definition and progression\nIn addition to pipeline metadata, such as `name` , the main pipeline definition includes a list of references to [targets](/deploy/docs/terminology#target) in deployment sequence order. That is, the first target listed is the first deployment target. After you've deployed to that target, promoting the release deploys to the next target in the list.\nThe following are the configuration properties for a delivery pipeline, not including target definitions.\n### metadata.name\nThe `name` field takes a string that must be unique per project and location.\n### metadata.annotations and metadata.labels\nDelivery pipeline configuration can include annotations and labels. Annotations and labels are stored with the delivery pipeline resource after the pipeline has been [registered](/deploy/docs/create-pipeline-targets#register_the_delivery_pipeline_and_targets) .\nFor more information, see [Using labels and annotations with Cloud Deploy](/deploy/docs/labels-annotations) .\n### description\nAn arbitrary string describing this delivery pipeline. This description is shown in the delivery pipeline details in Google Cloud console.\n### suspended\nA Boolean, which if `true` [suspends the delivery pipeline](/deploy/docs/suspend-pipeline) such that it can't be used to create, promote, roll back, or redeploy releases. Also, if the delivery pipeline is suspended, you can't approve or reject a rollout created from that pipeline.\nThe default is `false` .\n### serialPipeline\nThe beginning of the definition of a serial-progression delivery pipeline. This stanza is required.\n### stages\nA list of all targets to which this delivery pipeline is configured to deploy.\nThe list must be in the order of the delivery sequence you want. For example, if you have targets called `dev` , `staging` , and `production` , list them in that same order, so that your first deployment is to `dev` , and your final deployment is into `production` .\nPopulate each `stages.targetId` field with the value of the `metadata.name` field in the corresponding target definition. And under `targetId` , include `profiles` :\n```\nserialPipeline:\u00a0stages:\u00a0- targetId:\u00a0 \u00a0profiles: []\u00a0 \u00a0strategy:\u00a0 \u00a0 \u00a0standard:\u00a0 \u00a0 \u00a0 \u00a0verify:\n```\n### targetId\nIdentifies the specific target to use for this stage of the delivery pipeline. The value is the `metadata.name` property from the [target definition](#target_definitions) .\n`strategy.standard.verify` set to `true` enables [deployment verification](/deploy/docs/verify-deployment) on the target. If no deployment strategy is specified, the `standard` deployment strategy is used, with verification set to `false` .\n### profiles\nTakes a list of zero or more Skaffold profile names, from `skaffold.yaml` . Cloud Deploy uses the profile with [skaffold render](https://skaffold.dev/docs/workflows/ci-cd/#separation-of-rendering-and-deployment) when creating the release. Skaffold profiles let you vary configuration between targets while using a single configuration file.\n## strategy\nIncludes properties for specifying a deployment strategy. The following strategies are supported:\n- `standard:`The application is deployed fully to the specified target.This is the default deployment strategy. If you omit `strategy` , Cloud Deploy uses the `standard` deployment strategy.\n- `canary:`In a [canary deployment](/deploy/docs/deployment-strategies/canary) , you deploy a new version of your application progressively, replacing the already running version by percentage-based increments (for example, 25%, then 50%, then 75%, then fully.)\nThe deployment strategy is defined per target. For example, you might have a canary strategy for your `prod` target, but a standard strategy (no `strategy` specified) for your other targets.\nFor more information, see [Use a deployment strategy](/deploy/docs/deploy/docs/deployment-strategies) .\n### strategy configuration\nThis section shows the configuration elements for `strategy` , for each supported runtime.\nThe standard strategy includes only the following elements:\n```\nstrategy:\u00a0 standard:\u00a0 \u00a0 verify: true|false\n```\nThe `verify` property is optional. The default is `false` , meaning, there will be no [verify](/deploy/docs/verify-deployment) phase for the resulting rollouts.\nYou can omit the `strategy` element for a [standard](/deploy/docs/deployment-strategies#what_strategies) deployment strategy.\nThe following sections describe configuration for a [canary deployment](/deploy/docs/deployment-strategies/canary) strategy, for each runtime that Cloud Deploy supports.\n```\nstrategy:\u00a0 canary:\u00a0 \u00a0 runtimeConfig:\u00a0 \u00a0 \u00a0 cloudRun:\u00a0 \u00a0 \u00a0 \u00a0 automaticTrafficControl: true | false\u00a0 \u00a0 canaryDeployment:\u00a0 \u00a0 \u00a0 percentages: [PERCENTAGES]\u00a0 \u00a0 \u00a0 verify: true | false\n```\nThe following YAML shows how to configure a deployment strategy for a GKE or GKE Enterprise target, using [service-based networking](/deploy/docs/deployment-strategies/canary#gke-and-anthos_1) :\n```\n\u00a0 \u00a0 \u00a0 canary:\u00a0 \u00a0 \u00a0 \u00a0 runtimeConfig:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 kubernetes:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 serviceNetworking:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 service: \"SERVICE_NAME\"\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 deployment: \"DEPLOYMENT_NAME\"\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 disablePodOverprovisioning: true | false\u00a0 \u00a0 \u00a0 \u00a0 canaryDeployment:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 percentages: [PERCENTAGES]\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 verify: true | false\n```\nThe following YAML shows how to configure a deployment strategy for a GKE or GKE Enterprise target, using [Gateway API](/deploy/docs/deployment-strategies/canary#gateway) :\n```\n\u00a0 \u00a0 \u00a0 canary:\u00a0 \u00a0 \u00a0 \u00a0 runtimeConfig:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 kubernetes:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 gatewayServiceMesh:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 httpRoute: \"HTTP_ROUTE_NAME\"\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 service: \"SERVICE_NAME\"\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 deployment: \"DEPLOYMENT_NAME\"\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 routeUpdateWaitTime: \"WAIT_TIME\"\u00a0 \u00a0 \u00a0 \u00a0 canaryDeployment:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 percentages: [\"PERCENTAGES\"]\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 verify: true | false\n```\nNotice in this example [routeUpdateWaitTime](/deploy/docs/deployment-strategies/canary#gateway) . This is included because Gateway API splits traffic using an `HTTPRoute` resource, and sometimes there is a delay propagating changes made to the `HTTPRoute` . In such cases requests may be dropped, because traffic is being sent to resources that are unavailable. You can use `routeUpdateWaitTime` to cause Cloud Deploy to wait after applying `HTTPRoute` changes, if you observe this delay.\nThe following YAML shows how to configure a [custom](/deploy/docs/deployment-strategies/canary#custom) or [custom-automated](/deploy/docs/deployment-strategies/canary#custom-autmated) canary deployment strategy. Runtime-specific configuration, in the `runtimeConfig` section, is omitted for custom canary, but included in automated and custom automated canary configuration.\n```\nstrategy:\u00a0 \u00a0 \u00a0 \u00a0canary:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0# Runtime configs are configured as shown in the\u00a0 \u00a0 \u00a0 \u00a0 \u00a0# Canary Deployment Strategy section of this document.\u00a0 \u00a0 \u00a0 \u00a0 \u00a0runtimeConfig:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0# Manual configuration for each canary phase\u00a0 \u00a0 \u00a0 \u00a0 \u00a0customCanaryDeployment:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0- name: \"PHASE1_NAME\"\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0percent: PERCENTAGE1\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0profiles: [ \"PROFILE1_NAME\" ]\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0verify: true | false\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0- \u2026\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0- name: \"stable\"\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0percent: 100\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0profiles: [ \"LAST_PROFILE_NAME\" ]\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0verify: true|false\n```\n### verify\nOptional boolean indicating whether or not to support [deployment verification](/deploy/docs/verify-deployment) for this target. The default is `false` .\nEnabling deployment verification also [requires a verify stanza](/deploy/docs/verify-deployment/configure_skaffold_for_deployment_verification) in the `skaffold.yaml` . If you don't provide this property, the verify job will fail.\n### deployParameters\nAllows you to specify key value pairs to pass values to manifests for label-matched targets, when using [deploy parameters](/deploy/docs/parameters) .\nYou can also include this on [targets](#target_definitions) .\nDeploy parameters set on a delivery pipeline use labels to match targets:\n```\ndeployParameters:- values:\u00a0 \u00a0 someKey: \"value1\"\u00a0 matchTargetLabels:\u00a0 \u00a0 label1: firstLabel- values:\u00a0 \u00a0 someKey: \"value2\"\u00a0 matchTargetLabels:\u00a0 \u00a0 label2: secondLabel\n```\nIn this example, there are two values provided for the key, and for each value, there is a label. The value is applied to the manifest for any target that has a matching label.\n### predeploy and postdeploy jobs\nThese allow you to reference custom actions ( [defined separately](/deploy/docs/hooks#configure_in_skaffold) , in `skaffold.yaml` ) to run before the deploy job ( `predeploy` ) and after the verify job, if present ( `postdeploy` ). If there's no verify job, the postdeploy job runs after the deploy job.\nDeploy hooks are configured under `strategy.standard` or `strategy.canary` as follows:\n```\nserialPipeline:\u00a0 stages:\u00a0 - targetId: \u00a0 \u00a0 strategy:\u00a0 \u00a0 \u00a0 standard:\u00a0 \u00a0 \u00a0 \u00a0 predeploy:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 actions: [ACTION_NAME]\u00a0 \u00a0 \u00a0 \u00a0 postdeploy:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 actions: [ACTION_NAME]\n```\nWhere is the name configured in `skaffold.yaml` for `customActions.name` .\nYou can configure `predeploy` and `postdeploy` jobs under any strategy ( `standard` , `canary` , for example).\nFor more information about configuring and using pre- and post-deploy hooks, see [Run hooks before and after deploying](/deploy/docs/hooks) .\n## Target definitions\nThe delivery pipeline definition file can contain target definitions, or you can specify targets in a separate file. You can repeat Target names within a project, but they must be unique within a delivery pipeline.\nYou can reuse targets among multiple delivery pipelines. However, you can only reference a target once from within a single delivery pipeline's progression.\nSee also: [Custom target type definitions](#custom_target_type_definitions)\n### For GKE targets\nThe following YAML shows how to configure a target that [deploys to a GKE cluster](/deploy/docs/gke-targets) :\n```\n\u00a0 \u00a0 \u00a0apiVersion: deploy.cloud.google.com/v1\u00a0 \u00a0 \u00a0kind: Target\u00a0 \u00a0 \u00a0metadata:\u00a0 \u00a0 \u00a0 name:\u00a0 \u00a0 \u00a0 annotations:\u00a0 \u00a0 \u00a0 labels:\u00a0 \u00a0 \u00a0description:\u00a0 \u00a0 \u00a0deployParameters:\u00a0 \u00a0 \u00a0multiTarget:\u00a0 \u00a0 \u00a0 targetIds: []\u00a0 \u00a0 \u00a0requireApproval:\u00a0 \u00a0 \u00a0gke:\u00a0 \u00a0 \u00a0 cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]\u00a0 \u00a0 \u00a0 internalIp:\u00a0 \u00a0 \u00a0executionConfigs:\u00a0 \u00a0 \u00a0- usages:\u00a0 \u00a0 \u00a0 \u00a0- [RENDER | PREDEPLOY | DEPLOY | VERIFY | POSTDEPLOY]\u00a0 \u00a0 \u00a0 \u00a0workerPool:\u00a0 \u00a0 \u00a0 \u00a0serviceAccount:\u00a0 \u00a0 \u00a0 \u00a0artifactStorage:\u00a0 \u00a0 \u00a0 \u00a0executionTimeout:\n```\nThe name of this target. This name must be globally unique.\nTarget configuration supports [Kubernetes annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) and [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/) , but Cloud Deploy does not require them.\nAnnotations and labels are stored with the target resource. For more information, see [Using labels and annotations with Cloud Deploy](/deploy/docs/labels-annotations) .\nThis field takes an arbitrary string that describes the use of this target.\nYou can include [deploy parameters](/deploy/docs/parameters) on any target, along with values. Those values are assigned to the corresponding keys in your manifest, after rendering.\nThe `deployParameters` stanza takes key-value pairs, as shown:\n```\ndeployParameters:\u00a0 someKey: \"someValue\"\u00a0 someOtherKey: \"someOtherValue\"\n```\nIf you set deploy parameters on a [multi-target](/deploy/docs/terminology#multi-target) , the value is assigned to the manifest for all of that multi-target's [child targets](/deploy/docs/terminology#child_target) .\nThis property is optional, and is used to configure a [multi-target](/deploy/docs/terminology#multi_target) to be used for [parallel deployment](/deploy/docs/parallel) .\nThe value is a comma-separated list of [child targets](/deploy/docs/terminology#child_target) . Child targets are configured as normal targets, and don't include this `multiTarget` property.\nWhether promotion to this target requires manual approval. Can be `true` or `false` .\nThis property is optional. The default is `false` .\nWhen you configure [parallel deployment](/deploy/docs/parallel) , you can require approval on the multi-target only\u2014not on child targets.\nFor GKE clusters only, the resource path identifying the cluster where your application will be deployed:\n```\ngke:\u00a0 cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]\n```\n- `project_name`The Google Cloud project in which the cluster lives.\n- `location`The location where the cluster lives. For example, `us-central1` . The cluster can also be zonal ( `us-central1-c` ).\n- `cluster_name`The name of the cluster, as it appears in your list of clusters in Google Cloud console.\nHere's an example:\n```\ngke:\u00a0 cluster: projects/cd-demo-01/locations/us-central1/clusters/prod\n```\nOmit the `gke` property when configuring a [multi-target](/deploy/docs/terminology#multi-target) . The GKE cluster is configured instead inside the corresponding child target.\nSee [executionConfigs](#executionconfigs) , in this article, for descriptions of the execution environment properties.\nWhether or not the specified GKE cluster uses a private IP address. This property is optional. By default, Cloud Deploy uses the publicly available IP address for the cluster. If there's a private IP address and you want to use it, set this to `true` .\n### For Cloud Run targets\nThe following YAML shows how to configure a target that [deploys to a Cloud Run service](/deploy/docs/run-targets) :\n```\n\u00a0 \u00a0 \u00a0apiVersion: deploy.cloud.google.com/v1\u00a0 \u00a0 \u00a0kind: Target\u00a0 \u00a0 \u00a0metadata:\u00a0 \u00a0 \u00a0 name:\u00a0 \u00a0 \u00a0 annotations:\u00a0 \u00a0 \u00a0 labels:\u00a0 \u00a0 \u00a0description:\u00a0 \u00a0 \u00a0multiTarget:\u00a0 \u00a0 \u00a0 targetIds: []\u00a0 \u00a0 \u00a0requireApproval:\u00a0 \u00a0 \u00a0run:\u00a0 \u00a0 \u00a0 location: projects/[project_name]/locations/[location]\u00a0 \u00a0 \u00a0executionConfigs:\u00a0 \u00a0 \u00a0- usages:\u00a0 \u00a0 \u00a0 \u00a0- [RENDER | PREDEPLOY| \u00a0DEPLOY | VERIFY | POSTDEPLOY]\u00a0 \u00a0 \u00a0 \u00a0workerPool:\u00a0 \u00a0 \u00a0 \u00a0serviceAccount:\u00a0 \u00a0 \u00a0 \u00a0artifactStorage:\u00a0 \u00a0 \u00a0 \u00a0executionTimeout:\n```\nThe name of this target. This name must be unique per region.\nTarget configuration supports [annotations and labels](/deploy/docs/labels-annotations) , but Cloud Deploy does not require them.\nAnnotations and labels are stored with the target resource. For more information, see [Using labels and annotations with Cloud Deploy](/deploy/docs/labels-annotations) .\nThis field takes an arbitrary string that describes the use of this target.\nThis property is optional, and is used to configure a [multi-target](/deploy/docs/terminology#multi_target) to be used for [parallel deployment](/deploy/docs/parallel) .\nThe value is a comma-separated list of [child targets](/deploy/docs/terminology#child_target) . Child targets are configured as normal targets, and don't include this `multiTarget` property.\nWhether promotion to this target requires manual approval. Can be `true` or `false` .\nThis property is optional. The default is `false` .\nWhen you configure [parallel deployment](/deploy/docs/parallel) , you can require approval on the multi-target only\u2014not on child targets.\nFor Cloud Run services only, the location where the service will be created:\n```\nrun:\u00a0 location: projects/[project_name]/locations/[location]\n```\n- `project_name`The Google Cloud project in which the service will live.\n- `location`The location where the service will lives. For example, `us-central1` .\nOmit the `run` property when configuring a [multi-target]. The location of the Cloud Run service is configured instead inside the corresponding child target.\nSee [executionConfigs](#executionconfigs) , in this article, for descriptions of the execution environment properties.\n### For GKE Enterprise targets\nTarget configuration for [deploying to an GKE cluster](/deploy/docs/anthos-targets) is similar to configuring a target for a [GKE target](#for_gke_targets) , except that the property is `anthosCluster.membership` , instead of `gke.cluster` , the resource path is different, and `internalIp` is not applicable.\n```\nanthosCluster:\u00a0 membership: projects/[project_name]/locations/global/memberships/[membership_name]\n```\n- `project_name`The Google Cloud project in which the GKE Enterprise cluster lives.\n- `/location/global/`The location where the cluster is registered. `global` , in all cases.\n- `membership_name`The name of the GKE Enterprise cluster membership.\nHere's an example:\n```\nanthosCluster:\u00a0 membership: projects/cd-demo-01/locations/global/memberships/prod\n```\nOmit the `anthosCluster` property when configuring a [multi-target]. The GKE Enterprise cluster is configured instead inside the corresponding child target.\nFor more information about deploying to GKE clusters, see [Deploying to Anthos user clusters](/deploy/docs/anthos-targets) .\n### For custom targets\nConfiguration for [custom targets](/deploy/docs/custom-targets) is similar to all other target types, except that it does not include a `gke` stanza, nor a `run` stanza, nor an `anthosCluster` stanza.\nInstead, custom targets include a `customTarget` stanza:\n```\ncustomTarget:\u00a0 customTargetType: [CUSTOM_TARGET_TYPE_NAME]\n```\nWhere `CUSTOM_TARGET_TYPE_NAME` is the name you used in the [custom target type definition](#custom_target_type_definitions) .\nHere's an example:\n```\napiVersion: deploy.cloud.google.com/v1kind: Targetmetadata:\u00a0 name: sample-envcustomTarget:\u00a0 customTargetType: basic-custom-target\n```\n### executionConfigs\nA set of fields to specify a non-default [execution environment](/deploy/docs/execution-environment) for this target.\n**Note:** all configuration properties under `executionConfigs` are optional. You don't need to [specify an execution environment](/deploy/docs/execution-environment) if you can use the default worker pool, service account, and storage bucket.\n- `usages`Either `RENDER` or `DEPLOY` or both, plus `PREDEPLOY` , `VERIFY` , or `POSTDEPLOY` if [verification](/deploy/docs/verify-deployment) or [deploy hooks](/deploy/docs/hooks) are [enabled](#strategy) on the target. These indicate which of those operations to [perform](/deploy/docs/architecture#how_they_fit) for this target using this execution environment. To indicate that a custom execution environment is to be used for predeploy hook, render, deploy, postdeploy hook, and verification, you would configure it as follows:```\nusages:- RENDER- PREDEPLOY- DEPLOY- VERIFY- POSTDEPLOY\n```If verification is [enabled on the pipeline stage](/deploy/docs/verify-deployment#configure_pipeline) , and you don't specify `VERIFY` in a `usages` stanza, Cloud Deploy uses the default execution environment for verification. Predeploy and postdeploy [hooks](/deploy/docs/hooks) work the same way.However, if there is a custom execution environment for `RENDER` and `DEPLOY` , you specify one for `VERIFY` , `PREDEPLOY` , OR `POSTDEPLOY` if they're configured on the delivery pipeline. `VERIFY` , `PREDEPLOY` , and `POSTDEPLOY` can be in the same `usages` as `RENDER` or `DEPLOY` , or in separate `usages` .You can't specify `usages.VERIFY` , `usages.PREDEPLOY` , or `usages.POSTDEPLOY` unless `RENDER` and `DEPLOY` are specified in the same or separate custom execution environments.\n- `workerPool`Configuration for the worker pool to use. This takes a resource path identifying the Cloud Build worker pool to use for this target. For example:`projects/p123/locations/us-central1/workerPools/wp123` .To use the [default Cloud Build pool](/build/docs/private-pools/private-pools-overview#overview_of_default_pools_and_private_pools) , omit this property.A given target can have two `workerPool` s (one for `RENDER` and one for `DEPLOY` ). When configuring the default pool, you can specify an alternate service account or storage location or both.\n- `serviceAccount`The name of the service account to use for this operation ( `RENDER` or `DEPLOY` ) for this target.\n- `artifactStorage`The Cloud Storage bucket to use for this operation ( `RENDER` or `DEPLOY` ) for this target, instead of the default bucket.\n- `executionTimeout`Optional. Sets the timeout, in seconds, for operations that Cloud Build performs for Cloud Deploy. By default this is `3600` seconds (1 hour). Example: `executionTimeout: \"5000s\"`\n**Note:** If you specify a configuration for either RENDER or DEPLOY, you must do so for the other, even if one uses default values (only the `usages:` property).\nThe `executionConfigs` configuration described in this document is new. The previous syntax is still supported:\n```\nexecutionConfigs:- privatePool:\u00a0 \u00a0 workerPool:\u00a0 \u00a0 serviceAccount:\u00a0 \u00a0 artifactStorage:\u00a0 usages:\u00a0 - [RENDER | DEPLOY]- defaultPool:\u00a0 \u00a0 serviceAccount:\u00a0 \u00a0 artifactStorage:\u00a0 usages:\u00a0 - [RENDER | DEPLOY]\n```\nWhen you're configuring an `executionConfigs` stanza for a [multi-target](/deploy/docs/terminology#multi-target) , each child target [can inherit that execution environment](/deploy/docs/parallel#execution_environments_and_parallel_deployment) from that multi-target.\n## Custom target type definitions\nThis section describes the fields used to define [custom target types](/deploy/docs/custom-targets)\nAs with standard targets and automations, `CustomTargetType` definitions can be included with your delivery pipeline definition, or in a separate file or files.\nThe following YAML shows how to configure a custom target type:\n```\napiVersion: deploy.cloud.google.com/v1kind: CustomTargetTypemetadata:\u00a0 name: [CUSTOM_TARGET_TYPE_NAME]\u00a0 annotations:\u00a0 labels:description:customActions:\u00a0 renderAction: [RENDER_ACTION_NAME]\u00a0 deployAction: [DEPLOY_ACTION_NAME]\u00a0 includeSkaffoldModules:\u00a0 \u00a0 - configs:\u00a0 \u00a0 # either:\u00a0 \u00a0 googleCloudStorage:\u00a0 \u00a0 \u00a0 source:\u00a0 \u00a0 \u00a0 path:\u00a0 \u00a0 # or:\u00a0 \u00a0 git:\u00a0 \u00a0 \u00a0 repo:\u00a0 \u00a0 \u00a0 path:\u00a0 \u00a0 \u00a0 ref:\n```\nWhere:\n- `[CUSTOM_TARGET_TYPE_NAME]`Is an arbitrary name you give to this custom target type definition. This name is referenced in the [target definition](#target_definitions) for any target that uses the custom target type you're defining.\n- `[RENDER_ACTION_NAME]`Is the name of the custom render action. This value is the `customAction.name` defined in `skaffold.yaml` .\n- `[DEPLOY_ACTION_NAME]`Is the name of the custom deploy action. This value is the `customAction.name` defined in `skaffold.yaml` .\n- For `includeSkaffoldModules` , see [Use remote Skaffold configs](/deploy/docs/create-custom-target#remote_skaffold) .## Automation definitions\nThis section describes the fields used to define the Cloud Deploy [automation](/deploy/docs/automation-resource#the_automation_resource) resources.\nAs with targets, `Automation` definitions can be included with your delivery pipeline definition, or in a separate file or files.\nFor more information about automation in Cloud Deploy, see the [automation documentation](/deploy/docs/automation) .\nThe following YAML shows how to configure an automation. Note that the specifics of an automation are different per rule. (Configuration for the available automation rule types is in the document [Using automation rules](/deploy/docs/automation-rules) .)\n```\napiVersion: deploy.cloud.google.com/v1kind: Automationmetadata:\u00a0 name: [PIPELINE_NAME]/[PURPOSE]\u00a0 labels:\u00a0 annotations:description: [DESCRIPTION]suspended: true | falseserviceAccount: [SERVICE_ACCOUNT_ID]selector:- target:\u00a0 \u00a0 id: [TARGET_ID]\u00a0 \u00a0 #or\u00a0 \u00a0 labels: `[LABEL_KEY]:[LABEL_VALUE]`rules:- [RULE_TYPE]:\u00a0 \u00a0 name:[RULE_NAME]\u00a0 [RULE-SPECIFIC_CONFIG]\n```\nWhere:\n- `[PIPELINE_NAME]`Is the same as the `metadata.name` value in the delivery pipeline that uses this automation. All automations are exclusive to the delivery pipelines for which they're created. That is, you can't share an automation across more than one delivery pipeline.\n- `[PURPOSE]`Is any further descriptive name for this automation. Typically, this would be the action that's automated. For example, `my-app-pipeline/promote` .\n- `labels` and `annotations` are any labels or annotations you want to associate with this automation.\n- `[DESCRIPTION]`Is an optional description for this automation.\n- `suspended``true` or `false` , indicating whether this automation is active or suspended. If set to `true` , the automation is not used. This can be useful for [testing an automation without affecting the delivery pipeline](/deploy/docs/automation#suspend) .\n- `[SERVICE_ACCOUNT_ID]`Is the ID of the service account used to perform the [automation](/deploy/docs/automation-resources#automation_service_account) . For example, if the automation is `promoteRelease` , then this service account performs the release promotion, and thus requires the [permissions that are needed](/deploy/docs/iam-roles-permissions#permissions) to promote a release.A value is required for this property. Cloud Deploy doesn't use the [default service account](/deploy/docs/cloud-deploy-service-account#execution_service_account) for automations.This service account must have the following permissions:- `actAs` permission to impersonate the execution service account.\n- [permission](/deploy/docs/iam-roles-permissions#permissions) to perform the operation being automated, for example, `clouddeploy.releases.promote` to promote a release, or `clouddeploy.rollouts.advance` to advance a rollout phase.\n- `[TARGET_ID]`Is the ID of the target or targets for which this automation is used. Although an automation is tied to a delivery pipeline, it's only executed on the specified target or targets.\n- `[LABEL_KEY]:[LABEL_VALUE]`Is a key-value pair to match against a key-value pair defined on the target. This select all targets associated with the delivery pipeline that have the same label and value.\n- `[RULE_TYPE]`Is the name of the automation rule used for this automation. This is either `promoteRelease` or `advanceRollout` . You can include more than one rule in an automation, including more than one of the same RULE_TYPE. For example, you can have more than one `promoteRelease` rule in the same automation. [Learn more](/deploy/docs/automation-rules) .\n- `[RULE_NAME]`A name for the rule. This name must be unique within the delivery pipeline. A value is required for this property.\n- `[RULE-SPECIFIC_CONFIG]`Configuration is different for each supported automation type. Those configurations are shown in [Using automation rules](/deploy/docs/automation-rules) .## What's next\n- Find out more about [how Cloud Deploy works](/deploy/docs/overview) .\n- Learn how to [set up a delivery pipeline for your application](/deploy/docs/create-pipeline-targets) .\n- Learn how to [manage your manifests](/deploy/docs/skaffold) .\n- Avoid mismatches between your release and your delivery pipeline by learning about [pipeline instances](/deploy/docs/pipeline-instances) .", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Create Cloud Deploy alerts.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Create Cloud Deploy alerts", "url": "https://cloud.google.com/deploy/docs/alerts", "abstract": "# Cloud Deploy - Create Cloud Deploy alerts\nThis page describes how to use Cloud Deploy and [Google Cloud Observability](https://cloud.google.com/products/operations) to set up alerting policies so you are notified for specific events and conditions in Cloud Deploy.\nAlerts for Cloud Deploy are generated using [platform logs](/deploy/docs/platform-logs) stored by Cloud Logging. Google Cloud Observability supports alerts generated using time-series data from Cloud Monitoring, but Cloud Deploy alerts are [based on logs only](/logging/docs/alerting/log-based-alerts) .\nCloud Deploy alert policies are per delivery pipeline.\n**Note:** In addition to the alerts described in this article, you can [subscribe to Cloud Deploy service notifications](/deploy/docs/subscribe-deploy-notifications) using Pub/Sub topics.\n", "content": "## What are alerts?\nAlerts are notifications from Google Cloud Observability under certains conditions. You specify those conditions in an alerting policy. The [Google Cloud Observability documentation](/monitoring/alerts) describes alerting and alerting policies in more detail. This document describes the specific Cloud Deploy activities for which you can set up alerting policies.\n## Available alerts\nYou can set up alerting policies for the following circumstances, specific to Cloud Deploy:\n- The [render](/deploy/docs/terminology#render) operation, for a given release, has failed.For every release, all manifests, service definitions, and any other configs that must be rendered, are rendered for all targets before anything is deployed. This alert notifies you if a release's render operation fails.\n- A rollout has failed.This alert notifies you when a rollout within this delivery pipeline fails. You can then take action, as described in the article [Manage rollouts](/deploy/docs/deployment-strategies/manage-rollout) .\n- A rollout requires [approval](/deploy/docs/promote-release#manage_approvals_for_a_delivery_pipeline) .One of your targets is configured to require approval, and the release is now being promoted to that target, but approval is pending.\n- A rollout with a [canary deployment strategy](/deploy/docs/deployment-strategies/canary) requires [phase advancement](/deploy/docs/deployment-strategies/manage-rollout#advance_rollout) .When using a canary deployment strategy, each canary increment is a phase in the rollout for that release and target. Advancing those stages can be done manually or automatically. If there's a rollout waiting for a stage to be advanced, this alert lets you know.## What permissions do you need?\nThe person using the Google Cloud console to set up alerting policies must have the [permissions that Google Cloud Observability requires](/monitoring/alerts/using-alerting-ui#before_you_begin) .\n## Configure Cloud Deploy alerts\nTo create an alert for a delivery pipeline:\n- Open the **Delivery pipeline details** page for the pipeline for which you want to create an alert policy.\n- Click the **Recommended alerts** button.The **Alert policy templates** dialog is displayed, showing the alert-policy templates that are available for Cloud Deploy.\n- Select each policy template you want to use for this delivery pipeline.You can also click **Show options** to set options for the template, and to see current log messages related to that policy template.\n- Under **Configure notifications** , select the notification channel or channels the notifications will be sent to.If you don't already have notification channels configured, you can click **Manage notification channels** .\nBy default, a maximum of 1 alert per policy is sent every 5 minutes. You can configure this in the **Show options** sections of each alert policy template.\nFor more information about setting up alerting policies and notification channels, see the [Alerting overview](/monitoring/alerts) .\n### Other ways to set up alerts\nBesides creating alert policies using the Google Cloud console, you can [use the Cloud Monitoring API](/monitoring/alerts/policies-in-api) or [the Google Cloud Observability Terraform provider](/monitoring/alerts/terraform) .\n## What's next\n- [Learn more about Google Cloud Observability](/monitoring/alerts) alerts.\n- [Read about Cloud Deploy platform logs](/deploy/docs/platform-logs) .", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Create a custom target.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Create a custom target", "url": "https://cloud.google.com/deploy/docs/create-custom-target", "abstract": "# Cloud Deploy - Create a custom target\nThis document describes how to create a custom Cloud Deploy target type and use that custom target type as a [target](/deploy/docs/terminology#target) in a Cloud Deploy [delivery pipeline](/deploy/docs/terminology#delivery_pipeline) .\nThe following is the high-level process for creating a custom target type and using it in your delivery pipeline:\n- [Create a containerized application](#create_containerized_application) or applications that include the functionality to deploy to your custom target, and that fulfill the Cloud Deploy [requirements](/deploy/docs/custom-targets#required_inputs_and_outputs) for custom target types.\n- [Define a custom action](#skaffold_define_action) in `skaffold.yaml` that references that container and specifies the command or commands to run on it.\n- [Create a CustomTargetType definition](#define_custom_target_type) referencing the custom action from the previous step, and register it as a Cloud Deploy resource.\n- [Define a new target](#define_target) with a `customTarget` property that identifies your new custom target type.\n- [Reference that target](#add_target_to_pipeline) from your delivery pipeline [progression](/deploy/docs/terminology#progression) .\n- [Create a release](#create_release) .\nEach of these steps is described in detail in the rest of this document.\n", "content": "## Create your containerized applications\nThe functionality to deploy to your custom target is defined in containerized applications, which you provide to Cloud Deploy by [referencing them from your skaffold.yaml file](#skaffold_define_action) . When your delivery pipeline includes a target that uses a custom target type, Cloud Deploy calls the custom-action containers defined for that custom target type, in Skaffold, to execute the render and deploy actions you've defined.\nThe behavior of your applications is up to you. However, it must consume the input environment variables provided by Cloud Deploy, and it must return the [required outputs](/deploy/docs/custom-targets#required_inputs_and_outputs) .\nIn most cases, you will create one container for your render action and one for your deploy action, for each custom target type you create. The render action is optional, but if you don't provide one, Cloud Deploy uses the default `skaffold render` .\n## Define your custom actions in Skaffold\nWith your custom-action container image or images in place, you reference them from your [skaffold.yaml configuration file](/deploy/docs/using-skaffold) .\nYou configure each custom action for a custom target in a `customActions` stanza. For any custom target type, you create a custom action, in Skaffold, for render and one for deploy. The [CustomTargetType](#define_custom_target_type) definition identifies which custom action is used for render and which is used for deploy.\n**Note:** The custom renderer is not required if your custom target can use the manifest generated by the default renderer ( `skaffold render` ). In almost all cases, you will need a custom render action.\nThe following is the configuration for custom render and deploy actions in `skaffold.yaml` :\n```\napiVersion: skaffold/v4beta7kind: ConfigcustomActions:# custom render action- name:\u00a0 containers:\u00a0 - name:\u00a0 \u00a0 image:\u00a0 \u00a0 command:\u00a0 \u00a0 args:# custom deploy action- name:\u00a0 containers:\u00a0 - name:\u00a0 \u00a0 image:\u00a0 \u00a0 command:\u00a0 \u00a0 args:\n```\nIn this Skaffold configuration:\n- `customActions.name`Is an arbitrary name for the custom render or deploy action. The `CustomTargetType` definition references this name, in the `renderAction` property or the `deployAction` property.\n- The `containers` stanza includes your reference, plus commands to run that container.The `containers` stanza allows more than one container, but Google recommends you only use one.\n- `customActions.containers.name`Is an arbitrary name for the specific container you're using for this action. As a best practice, this container name should always be SHA qualified.\n- `image`Is the path to the container image.\n- `command`Is the command or commands to run on the container.\n- `args`Is a collection of arguments to the `command` .\nSee the [Skaffold YAML reference](https://skaffold.dev/docs/references/yaml/) for detailed documentation on the configuration properties used in [customActions](https://skaffold.dev/docs/custom-actions) .\n**Note:** you can also define Skaffold configs and store them in a Git repository or in a Cloud Storage bucket, and [reference those configs from your custom target type definition](#remote_skaffold) .\n## Define your custom target type\nYou define a custom target by first creating a custom target , using the [CustomTargetType configuration](/deploy/docs/config-files#custom_target_type_definitions) . You can create the `CustomTargetType` in the same file as your delivery pipeline definition, or with target definitions, or in a separate file.\nThe `CustomTargetType` definition is as follows:\n```\n# Custom target type config (preview)apiVersion: deploy.cloud.google.com/v1kind: CustomTargetTypemetadata:\u00a0 name: [CUSTOM_TARGET_TYPE_NAME]\u00a0 annotations:\u00a0 labels:description:customActions:\u00a0 renderAction: [RENDER_ACTION_NAME]\u00a0 deployAction: [DEPLOY_ACTION_NAME]\u00a0 includeSkaffoldModules:\n```\nWhere\n- `CUSTOM_TARGET_TYPE_NAME`Is an arbitrary name you give to this custom target type definition. This name is referenced in the [target definition](/deploy/docs/config-files#target_definitions) for any target that uses the custom target type you're defining.\n- `RENDER_ACTION_NAME`Is the name of the custom render action. This value is the `customAction.name` defined in `skaffold.yaml` for the [render](/deploy/docs/custom-targets#required_inputs_and_outputs) action.\n- `DEPLOY_ACTION_NAME`Is the name of the custom deploy action. This value is the `customAction.name` defined in `skaffold.yaml` for the [deploy](/deploy/docs/custom-targets#required_inputs_and_outputs) action.\n- `includeSkaffoldModules`Is an optional stanza to use if you're using remote Skaffold configs. The properties in this stanza are shown in the section [Use remote Skaffold configs](#remote_skaffold) .\n### Use remote Skaffold configs\nYou can store Skaffold configs in a public Git repository or in a Cloud Storage bucket, and reference those configs from your custom target type definition.\nUsing remote Skaffold configs means that the `skaffold.yaml` you provide at release time doesn't need to have the custom actions defined. This allows for sharing custom actions across your organization.\nTo use remote Skaffold configs:\n- Create a Skaffold configuration with your custom action or actions.\n- Store the configuration in a Git repository or in a Cloud Storage bucket.\n- In your custom target type definition, add a `customActions.includeSkaffoldModules` stanza.\n- Under `includeSkaffoldModules` , specify the following:- Optionally, one or more `configs` elements:`- configs: [\"name1\", \"name2\"]`The value of `configs` is a list of strings that match the `metadata.name` property on each Skaffold config to be included. If this is omitted, Cloud Deploy takes all of the configs in the specified path.\n- Either a `googleCloudStorage` stanza or a `git` stanza.For Cloud Storage:```\ngoogleCloudStorage:\u00a0 source: PATH_TO_GCS_BUCKET\u00a0 path: FILENAME\n```For Git:```\ngit:\u00a0 repo: REPO_URL\u00a0 path: PATH_TO_FILE\u00a0 ref: BRANCH_NAME\n```Where:`PATH_TO_GCS_BUCKET` is the path to a Cloud Storage directory, ending with `/*` , where the Skaffold configs are stored. Skaffold downloads all the files in this directory then finds the relevant Skaffold file with the configs, based on the configured relative path.`FILENAME` is the name of the file that includes the Skaffold configs. This `path:` property is optional; if you don't specify it, Cloud Deploy assumes `skaffold.yaml` . If there's no `skaffold.yaml` , or if the filename you specify is not there, then the release creation fails.`REPO_URL` is the URL to the Git repository.`PATH_TO_FILE` is the path in that repository to the file containing the Skaffold configs.`BRANCH_NAME` is the name of the branch (for example, `main` ) from which to take the Skaffold configs.\nThe following custom target-type YAML is a `customActions` stanza with an `includeSkaffoldModules` stanza, pointing to Skaffold configs stored in a Cloud Storage bucket:\n```\ncustomActions:\u00a0 renderAction: my-custom-action\u00a0 deployAction: my-custom-action\u00a0 includeSkaffoldModules:\u00a0 \u00a0 - configs: [\"myConfig\"]\u00a0 \u00a0 \u00a0 googleCloudStorage:\u00a0 \u00a0 \u00a0 \u00a0 source: \"gs://my-custom-target-bucket/my-custom/*\"\u00a0 \u00a0 \u00a0 \u00a0 path: \"skaffold.yaml\n```\nThe following YAML is a Skaffold config, which the custom action shown is referencing:\n```\napiVersion: skaffold/v4beta7kind: Configmetadata:\u00a0 name: myConfigcustomActions:\u00a0 - name: my-custom-action\u00a0 \u00a0 containers:\u00a0 \u00a0 \u00a0 - name: my-custom-container\u00a0 \u00a0 \u00a0 \u00a0 image: us-east1-docker.pkg.dev/abcdefg/foldername/myimage@sha256:c56fcf6e0a7637ddf0df3d56a0dd23bfce03ceca06a6fc527b0e0e7430e6e9f9\n```\n### Register your custom target type\nAfter you've configured the `CustomTargetType` , run the [gcloud deploy apply](/sdk/gcloud/reference/deploy/apply) command to register the `CustomTargetType` resource in a Google Cloud project:\n```\ngcloud deploy apply --file=[FILE] --project=[PROJECT] --region=[REGION]\n```\nWhere:\n`FILE` is the name of the file in which you've defined this custom target type.\n`PROJECT` is the Google Cloud project in which to create this resource. The `CustomTargetType` must be in the same project as the `Target` resource that references it. You don't need to specify the project if you have set it as your default project for the Google Cloud CLI.\n`REGION` is the region (for example, `us-centra1` ) in which to create this resource. The `CustomTargetType` must be in the same region as the `Target` resource that references it. You don't need to specify the region if you have set it as your default region for the gcloud CLI.\nWith the `CustomTargetType` now created as a Cloud Deploy resource, you can now use it in a `Target` definition to create your custom target.\nFor more information on the `CustomTargetType` definition, see the [Cloud Deploy configuration schema reference](/deploy/docs/config-files#custom_target_type_definitions) .\n## Define your target\nThe only difference between a target definition for a supported target type and a custom target definition is that the custom target definition includes a `customTarget` stanza. The syntax for a `customTarget` is as follows:\n```\ncustomTarget:\u00a0 customTargetType: [CUSTOM_TARGET_TYPE_NAME]\n```\nWhere `CUSTOM_TARGET_TYPE_NAME` is the value from the `name` property defined in your [custom target type configuration](#define_custom_target_type) .\n**Note:** You can use [multi-targets](/deploy/docs/parallel) where the child targets are custom targets. In this case, all child targets must be of the same `CustomTargetType` .\n## Add your target to the delivery pipeline\nYou can use a custom target in a delivery pipeline exactly as you would use a supported target type. That is, there is no difference in the delivery pipeline progression between targets of a supported target type and custom targets.\nAll targets in a delivery pipeline must use the same target type. For example, you can't have a delivery pipeline with some targets deploying to Google Kubernetes Engine and some custom targets.\nAs with supported target types, you can include [deploy parameters](/deploy/docs/parameters) in the pipeline stage.\n## Create a release\n**Note:** If you're not using [remote Skaffold configs](#remote_skaffold) , the `skaffold.yaml` file you provide for the release must define the custom actions that the custom target type requires.\nWith your custom target type fully defined, and a target created to use that type, you can now create a release, in the normal way:\n```\ngcloud deploy releases create [RELEASE_NAME] \\\u00a0 --project=[PROJECT_NAME] \\\u00a0 --region=[REGION] \\\u00a0 --delivery-pipeline=[PIPELINE_NAME]\n```\nUpon release creation your custom render action is executed for each target in your delivery pipeline, including processing [deploy parameters](/deploy/docs/parameters) configured on the release, targets, or the delivery pipeline. Cloud Deploy provides the [deploy parameters as input](/deploy/docs/custom-targets#custom_targets_and_deploy_parameters) to the custom render container.\n## View the output of your custom targets\nIf your custom action satisfies the [requirements](/deploy/docs/custom-targets#required_inputs_and_outputs) for custom targets, you can use Google Cloud console to view the rendered artifacts.\nFollow these steps to view the output of your custom render action.\n- In the Google Cloud console, navigate to the Cloud Deploy **Delivery pipelines** page to view your delivery pipeline. [Open the Delivery pipelines page](https://console.cloud.google.com/deploy/delivery-pipelines) \n- Click the name of your delivery pipeline.The pipeline visualization shows the app's deployment status, and your release is listed on the **Releases** tab under **Delivery pipelinedetails** .\n- Click the release name.The **Release details** page is shown.\n- Click the **Artifacts** tab.\n- Under **Target artifacts** , click the arrow next to **View artifacts** .The rendered artifacts are listed, including the rendered `skaffold.yaml` and rendered manifest file generated by the custom renderer. And you can click the **Storage location** link next to each one to go to the Cloud Storage bucket to view those files.You can also click the **View artifacts** link to view those files by release, by target, or by phase, using the [release inspector](/deploy/docs/view-release#view_release_artifacts) .## What's next\n- Try the [quickstart: Define and use a custom target type](/deploy/docs/deploy-app-custom-target) \n- See the available [sample custom target types](/deploy/docs/custom-targets#custom_target_examples) .\n- [Create a delivery pipeline and targets](/deploy/docs/create-pipeline-targets) .\n- Learn more about [configuring Cloud Deploy targets](/deploy/docs/config-files#target_definitions)", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Create a pipeline and release in the Google Cloud console.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Create a pipeline and release in the Google Cloud console", "url": "https://cloud.google.com/deploy/docs/deploy-app-in-console", "abstract": "# Cloud Deploy - Create a pipeline and release in the Google Cloud console\n# Create a pipeline and release in the Google Cloud console\nThis page shows you how to use the Google Cloud console to create a Cloud Deploy delivery pipeline, and then create a release for that pipeline.\nIn this quickstart, you'll do the following:- Create two GKE clusters or configure two Cloud Run services.\n- Create a [delivery pipeline](/deploy/docs/terminology/delivery_pipeline) and two [targets](/deploy/docs/terminology/target) using the Google Cloud console.\n- Instantiate your delivery pipeline by creating a release using the Google Cloud console.After you create this release, the application is automatically deployed to the target.\n- See the results in Google Cloud console.\n", "content": "## Before you begin- If you already have the CLI installed, make sure you're running the latest version:\n- ```\ngcloud components update\n```\n## Create your runtime environment **If you're deploying to Cloud Run, you can skip this command** .\nFor GKE, create two clusters: `quickstart-cluster-for-console-staging` and `quickstart-cluster-for-console-prod` , with default settings. The clusters' Kubernetes API endpoints must be network-reachable from the public internet. GKE clusters are externally accessible by default.\n```\ngcloud container clusters create-auto quickstart-cluster-for-console-staging \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--project=PROJECT_ID \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--region=us-central1 && \\gcloud container clusters create-auto quickstart-cluster-for-console-prod \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--project=PROJECT_ID \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--region=us-central1\n```## Create a delivery pipeline and two targetsYou can use Cloud Deploy to [create a delivery pipeline and targets](/deploy/docs/create-pipeline-targets) based on configuration specified in one or more YAML files. But you can also create a delivery pipeline using the Google Cloud console.\nIn this section, you use Google Cloud console to create a delivery pipeline and two targets. When you use Google Cloud console, you don't need to create any YAML files; Cloud Deploy creates your [skaffold.yaml](/deploy/docs/using-skaffold/getting-started-skaffold) and manifest for you.- In the Google Cloud console, navigate to the Cloud Deploy main page. [Open the Delivery pipelines page](https://console.cloud.google.com/deploy/delivery-pipelines) \n- Click **Create** The **Create a delivery pipeline** form is displayed.\n- In the **Pipeline name** field, replace the default text with `in-console-quickstart-pipeline` .\n- Optionally, enter a description for this delivery pipeline.\n- In the **Region** drop-down, select `us-central1` .\n- Select your runtime.If you're deploying to GKE, select **Google KubernetesEngine** . Otherwise, select **Cloud Run** .\n- Create your targets:\n- Under **New target** , in the **Target name** field, replace the default text with `console-staging` .\n- From the **Kubernetes Engine cluster** drop-down, select `quickstart-cluster-for-console-staging` .\n- Click **Done** .\n- Click **Add target** .Replace the default text for **Target name** with `console-prod` .\n- Select `quickstart-cluster-for-console-prod` from the **Kubernetes Engine cluster** drop-down.\n- Select **Require approval for rollouts** .For this quickstart, we're requiring approval on the second target but not on the first target.\n- Click **Create** to create this delivery pipeline.\n- Under **New target** , in the **Target name** field, replace the default text with `console-staging` .\n- From the **Region** drop-down, select `us-central1` .\n- Click **Done** .\n- Click **Add target** .\n- Replace the default text for **Target name** with `console-prod` .\n- Activate the **Require approval for rollouts** checkbox for this target.For this quickstart, we're requiring approval on the second target but not on the first target.\n- Click **Create** to create this delivery pipeline.\n **Note:** If the default Compute Engine service account doesn't have the necessary permissions, you can click the **Grant** button to add them, when prompted.You now have a delivery pipeline with two targets, ready to create a release. The pipeline's page is displayed, showing both targets, with no rollouts.\n## Create a releaseNow that you have a delivery pipeline, with two targets, pointing to two GKE clusters or two Cloud Run services, you can create a release to deploy your application to the first target.- If you're not already on the delivery pipeline page, showing the new delivery pipeline `in-console-quickstart-pipeline` , navigate there now.The pipeline visualization is shown, with no rollouts.\n- Click the **Create release** button.The **Create a release** dialog is shown. Most of the fields are pre-populated. Keep these default values.You can click the **View manifest** button to view the manifest the automatically generated manifest, for either target, and you can click **View Skaffold file** to view the generated `skaffold.yaml` . You can also edit them, but for this quickstart leave them as they are.\n- Optionally, add a description for this release, in the **Description** field.\n- Click **Create** to start the release.The rollout details page is shown, for the rollout to the first target, and you can watch the progress of this rollout. It will take a few minutes to complete. It may take a few seconds for the rollout to start.\n- After the first rollout finishes, click the delivery pipeline name to go to the delivery pipeline page.The pipeline visualization is shown, with the rollout complete to the first target.\n- Click **Promote** to start the rollout to the next target.The **Promote** dialog is shown.\n- Keep the default values, add a **Rollout description** if you want, then click **Promote** .Because we selected **Require approval for rollouts** when we created the second target, this promotion is waiting for approval.\n- Click **Review** , in the delivery pipeline visualization.The approval page is shown.\n- Click **Review** again, and in the approval dialog, click **Approve** .The rollout is started for the second target. You can click the delivery pipeline name again to watch the progress in the pipeline visualization.\nWhen the second rollout is finished, the application is deployed in the second target, and your delivery pipeline has completed.## Clean upTo avoid incurring charges to your Google Cloud account for   the resources used on this page, follow these steps.- Delete the GKE clusters or Cloud Run services:\n```\ngcloud container clusters delete quickstart-cluster-for-console-staging --region=us-central1 --project=PROJECT_ID \\&& gcloud container clusters delete quickstart-cluster-for-console-prod --region=us-central1 --project=PROJECT_ID\n```\n```\ngcloud run services delete in-console-quickstart-pipeline-target-1 --region=us-central1 --project=PROJECT_ID \\&& gcloud run services delete in-console-quickstart-pipeline-target-2 --region=us-central1 --project=PROJECT_ID\n```\n- From the delivery pipeline page, click **Delete** to delete the delivery pipeline, the release, and rollouts.Type the pipeline name in the field provided, and click **Confirm** to finish deleting the resources.\n- Delete both targets:```\ngcloud deploy targets delete console-staging --region=us-central1 \u00a0&& \\gcloud deploy targets delete console-prod --region=us-central1\n```\n- Delete the Cloud Storage buckets that Cloud Deploy created.One ends with `_clouddeploy` , and the other is `[region].deploy-artifacts.[project].appspot.com` . [Open the Cloud Storage browser page](https://console.cloud.google.com/storage/browser) \nThat's it, you completed this quickstart!## What's next\n- [Learn more about Cloud Deploy](/deploy/docs/overview) .\n- [Learn the basics of deploying applications](/deploy/docs/deploying-application) .\n- [Try out the Cloud Deploy walkthrough](https://shell.cloud.google.com/?show=ide%2Cterminal&walkthrough_id=deploy--cloud-deploy-e2e-gke) .\n- Learn how to [manage your manifests](/deploy/docs/skaffold) .\n- [Learn how to combine Google Cloud CI/CD tools to develop and deliversoftware effectively to GKE](https://cloud.google.com/architecture/app-development-and-delivery-with-cloud-code-gcb-cd-and-gke) .", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Create your delivery pipeline and targets.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Create your delivery pipeline and targets", "url": "https://cloud.google.com/deploy/docs/create-pipeline-targets", "abstract": "# Cloud Deploy - Create your delivery pipeline and targets\nThis page describes how to create the delivery pipeline and targets that describe where and how Cloud Deploy will deploy your application. See [Configuration file schema](/deploy/docs/config-files) for a description of the YAML file structure for delivery pipelines and targets.\n", "content": "## About the delivery pipeline and targets\nYour delivery pipeline describes a [progression](/deploy/docs/terminology#progression) of deployment [targets](/deploy/docs/terminology#target) . You can define those targets in the same file as the delivery pipeline or in one or more separate files.\nAfter you create the delivery pipeline and target definition file or files, you run `gcloud deploy apply` against each of those files to register them as Cloud Deploy resources.\n## Define the delivery pipeline and targets\nThe structure of the delivery pipeline and target configuration files is described [here](/deploy/docs/config-files) .\nYou can call this file anything you want. By convention, a delivery pipeline config that  [target](/deploy/docs/terminology#target) definitions is called `clouddeploy.yaml` , and one that instead references targets defined in one or more separate files is named `delivery-pipeline.yaml` .\nThe target can point to [GKE](/deploy/docs/config-files#for_gke_targets) , [GKE Enterprise](/deploy/docs/config-files#for_anthos_targets) , or [Cloud Run](/deploy/docs/config-files#for_run_targets) . Within a delivery pipeline, all targets must reference the same runtime type (all GKE, or all GKE Enterprise, for example).\n## Create a delivery pipeline and targets using the Google Cloud console\nYou can use the Google Cloud console to create a new delivery pipeline and target or targets. This is useful for trying out Cloud Deploy, but is not suitable for production workloads. (You can also use the Google Cloud console to [create a release](/deploy/docs/deploying-application#create_pipeline_in_ui) .)\nTo create the delivery pipeline:\n- From the **Delivery pipelines** page, click **Create** .\n- Provide a name (or keep the default) and, optionally, a description.\n- Select your region.\n- Choose your runtime environment.For GKE, choose **Google Kubernetes Engine** , or select **Cloud Run** if that's the runtime you're deploying to.\n- Under **New target** , provide a name (or keep the default).\n- If you want to require [approval](/deploy/docs/promote-release#manage_approvals_for_a_delivery_pipeline) on this target, select the **Require approval for rollouts** checkbox.\n- If you're going to use a [canary deployment strategy](/deploy/docs/deployment-strategies/canary) on this target, select the **Enable canary** checkbox. **Note:** You can enable canary here for Cloud Run only. For GKE, you need to configure it as described [here](/deploy/docs/deployment-strategies/canary) .\n- Click **Done** .\n- Click **Add target** and follow these steps for each additional target you want to create.\n- When you have all your targets, click **Create** to create the delivery pipeline and target resources.## Register the delivery pipeline and targets\n**If you created your pipeline and targets using the Google Cloud console,you don't need to do this.**\nTo register your delivery pipeline with Cloud Deploy, you run `gcloud deploy apply` once for each separate definition file. That is, if you define three targets in three files, you would run the command four times\u2014once for the delivery pipeline, and once for each target.\nThe following command registers a delivery pipeline with its targets defined in the same file.\n```\ngcloud deploy apply --file=PIPELINE_CONFIG \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 --region=LOCATION \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 --project=PROJECT\n```\nYou now have a delivery pipeline that can manage deployment of your releases, and target resources that can be used by any delivery pipeline in the same project and region.\n### A single-file example\nThe command in this example registers a delivery pipeline and targets that are all defined in the same file:\n```\ngcloud deploy apply --file=clouddeploy.yaml --region=us-central1\n```\n### An example using separate files\nFor this example, there are three targets defined in three separate files, so you run four commands:\n```\ngcloud deploy apply --file=delivery-pipeline.yaml --region=us-central1 && \\gcloud deploy apply --file=target_dev.yaml --region=us-central1 && \\gcloud deploy apply --file=target_staging.yaml --region=us-central1 && \\gcloud deploy apply --file=target_prod.yaml --region=us-central1\n```\nThe `--region` flag is required unless you've set a default (using `gcloud config set deploy/region [REGION]` ). The region must be the same for the delivery pipeline and all targets that pipeline references.\n## Create the delivery pipeline and targets using Terraform\nYou can also use the [Google Cloud Terraform provider](https://registry.terraform.io/providers/hashicorp/google/latest/docs) to create [delivery pipeline](https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/clouddeploy_delivery_pipeline) and [target](https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/clouddeploy_target) resources.\nThe [Google Cloud beta Terraform provider](https://registry.terraform.io/providers/hashicorp/google-beta/latest/docs) may include support for Cloud Deploy features in [Preview](/products#product-launch-stages) .\n## Edit existing pipelines and targets\nYou can later edit any delivery pipeline or target config and run `gcloud deploy apply` to update the pipeline or target resource. But those changes [do not affect any existing releases, as they are managed by the originaldelivery pipeline](/deploy/docs/pipeline-instances) .\n## Require manual approval for a deployment\nTo require manual approval for a given target, include the following property on the [target definition](/deploy/docs/config-files#target_definitions) :\n`requireApproval: true`\nThe default is `false` . If you omit this property from the delivery-pipeline config, or provide no value for it, deploying to this target doesn't require approval. (But the caller trying to promote to the target still needs the `clouddeploy.rollouts.create` IAM permission.)\nYou can even require manual approval on the first target. When a release is created, using the CLI, for the first target, the `rollout` is created automatically. If approval is required, Cloud Deploy creates the `rollout` , but in a pending-release state until approval is given.\n## What's next\n- [Create your Skaffold configuration](/deploy/docs/using-skaffold/getting-started-skaffold) .\n- See [Deploying your application](/deploy/docs/deploying-application) to find out how to invoke your delivery pipeline and create a release.", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Define and use a custom target type.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Define and use a custom target type", "url": "https://cloud.google.com/deploy/docs/deploy-app-custom-target", "abstract": "# Cloud Deploy - Define and use a custom target type\n# Define and use a custom target type\nThis quickstart shows you how to use Cloud Deploy to create a custom target type, then deploy to a custom target of that type.\nIn this quickstart, you'll do the following:- Create a [Skaffold](/skaffold) configuration.The Skaffold configuration file is where you configure the behavior of the target. This configuration references container images plus shell commands to run on those images, which are the actions for render and deploy operations.\n- Define a custom target type, and a target that references that type.\n- Define your Cloud Deploy delivery pipeline.This pipeline includes only one stage and uses only one target. In that stage, you'll reference the target you configured.\n- Create a release, which automatically creates a rollout, resulting in the custom render and deploy operations being performed.As part of this release and rollout, the render and deploy operations defined in your Skaffold configuration are both run.\n- View the results of the custom operations. This includes a rendered configuration file uploaded to Cloud Storage, and a string written to that file, as well as a results file that includes the status of the operation.\n", "content": "## Before you begin- If you already have the Google Cloud CLI installed, make sure you're running the latest version:\n- ```\ngcloud components update\n```\n- Make sure the [defaultCompute Engine service account](/deploy/docs/cloud-deploy-service-account#execution_service_account) has sufficient permissions.The service account might already have the necessary permissions. These steps are included for projects that disable automatic role grants for default service accounts.\n- First add the`clouddeploy.jobRunner`role:```\ngcloud projects add-iam-policy-binding PROJECT_ID \\\n --member=serviceAccount:$(gcloud projects describe PROJECT_ID \\\n --format=\"value(projectNumber)\")-compute@developer.gserviceaccount.com \\\n --role=\"roles/clouddeploy.jobRunner\"\n```\n- Add the developer role for your specific runtime.\n- Add the`iam.serviceAccountUser`role, which includes the`actAs`permission to deploy to the runtime:```\ngcloud iam service-accounts add-iam-policy-binding $(gcloud projects describe PROJECT_ID \\\n --format=\"value(projectNumber)\")-compute@developer.gserviceaccount.com \\\n --member=serviceAccount:$(gcloud projects describe PROJECT_ID \\\n --format=\"value(projectNumber)\")-compute@developer.gserviceaccount.com \\\n --role=\"roles/iam.serviceAccountUser\" \\\n --project=PROJECT_ID\n```## Prepare your Skaffold configuration and application manifestCloud Deploy uses [Skaffold](/deploy/docs/using-skaffold) to provide the details for what to deploy and how to deploy it to your [target](/deploy/docs/terminology#target) .\nIn this quickstart, you create a `skaffold.yaml` file, which which defines custom actions that represent the render and deploy operations for the custom target type.\nNote that the custom actions provided in this quickstart don't actually deploy any application to a runtime. Both the render and deploy actions upload a results file to Cloud Storage to fulfill the custom-target contract between Cloud Deploy and the user-defined render and deploy.- Open a terminal window.\n- Create a new directory and navigate into it.```\nmkdir custom-target-quickstartcd custom-target-quickstart\n```\n- Create a file named `skaffold.yaml` with the following contents:```\napiVersion: skaffold/v4beta7kind: ConfigcustomActions:- name: custom-render\u00a0 containers:\u00a0 - name: render\u00a0 \u00a0 image: gcr.io/google.com/cloudsdktool/google-cloud-cli@sha256:66e2681aa3099b4e517e4cdcdefff8f2aa45d305007124ccdc09686f6712d018\u00a0 \u00a0 command: ['/bin/bash']\u00a0 \u00a0 args:\u00a0 \u00a0 \u00a0 - '-c'\u00a0 \u00a0 \u00a0 - |-\u00a0 \u00a0 \u00a0 \u00a0 echo \"Sample manifest rendered content\" > manifest.txt\u00a0 \u00a0 \u00a0 \u00a0 gsutil cp manifest.txt $CLOUD_DEPLOY_OUTPUT_GCS_PATH/manifest.txt\u00a0 \u00a0 \u00a0 \u00a0 echo {\\\"resultStatus\\\": \\\"SUCCEEDED\\\", \\\"manifestFile\\\": \\\"$CLOUD_DEPLOY_OUTPUT_GCS_PATH/manifest.txt\\\"} > results.json\u00a0 \u00a0 \u00a0 \u00a0 gsutil cp results.json $CLOUD_DEPLOY_OUTPUT_GCS_PATH/results.json- name: custom-deploy\u00a0 containers:\u00a0 - name: deploy\u00a0 \u00a0 image: gcr.io/google.com/cloudsdktool/google-cloud-cli@sha256:66e2681aa3099b4e517e4cdcdefff8f2aa45d305007124ccdc09686f6712d018\u00a0 \u00a0 command: ['/bin/bash']\u00a0 \u00a0 args:\u00a0 \u00a0 \u00a0 - '-c'\u00a0 \u00a0 \u00a0 - |-\u00a0 \u00a0 \u00a0 \u00a0 echo {\\\"resultStatus\\\": \\\"SUCCEEDED\\\"} > results.json\u00a0 \u00a0 \u00a0 \u00a0 gsutil cp results.json $CLOUD_DEPLOY_OUTPUT_GCS_PATH/results.json\n```This file includes the `customActions:` stanza, defining a custom render action and a custom deploy action. Each of these custom actions references a container image to run, and commands to run on that container.See the [skaffold.yaml reference](https://skaffold.dev/docs/references/yaml/) for more information about this configuration file.\n## Create your delivery pipeline, custom target type, and targetYou can define your delivery pipeline, custom target type, and target in one file or in separate files. In this quickstart, you create a single file with all three.- In the custom-target-quickstart directory, create a new file, `clouddeploy.yaml` , with the following content:```\napiVersion: deploy.cloud.google.com/v1kind: DeliveryPipelinemetadata:\u00a0 name: custom-targets-pipelineserialPipeline:\u00a0 stages:\u00a0 - targetId: sample-env---apiVersion: deploy.cloud.google.com/v1kind: Targetmetadata:\u00a0 name: sample-envcustomTarget:\u00a0 customTargetType: basic-custom-target---apiVersion: deploy.cloud.google.com/v1kind: CustomTargetTypemetadata:\u00a0 name: basic-custom-targetcustomActions:\u00a0 renderAction: custom-render\u00a0 deployAction: custom-deploy\n``` **Note:** The custom target type and the target are included with the delivery pipeline in this file, but you can define them in a separate file or multiple separate files.\n- Register your pipeline and targets with the Cloud Deploy service:```\ngcloud deploy apply --file=clouddeploy.yaml --region=us-central1 --project=PROJECT_ID\n```You now have a delivery pipeline, with one target. This is your target using the custom target type, and this pipeline doesn't deploy an application to a runtime.\n- Confirm your pipeline and targets:In the Google Cloud console, navigate to the Cloud Deploy **Delivery pipelines** page to view of list of your available delivery pipelines. [Open the Delivery pipelines page](https://console.cloud.google.com/deploy/delivery-pipelines) The delivery pipeline you just created is shown, with one target listed in the **Targets** column.\n## Create a releaseA release is the central Cloud Deploy resource representing the changes being deployed. The delivery pipeline defines the lifecycle of that release. See [Cloud Deploy service architecture](/deploy/docs/architecture#how_they_fit_together_to_deliver_your_release) for details about that lifecycle.\nRun the following command from the `custom-target-quickstart` directory to create a `release` resource that represents the custom action to deploy:\n```\ngcloud deploy releases create test-release-001 \\\u00a0 --project=PROJECT_ID \\\u00a0 --region=us-central1 \\\u00a0 --delivery-pipeline=custom-targets-pipeline\n```\nAs with all releases (unless they include `--disable-initial-rollout` ), Cloud Deploy automatically creates a [rollout](/deploy/docs/terminology#rollout) resource too. And all phases of that rollout are executed, including render and deploy.## View the results in Google Cloud consoleAfter a few minutes, your deployment is complete. In this case, because the two custom actions are commands to echo strings into a file and upload the file to Cloud Storage, nothing is deployed into any target runtime.\nHowever, you can view the file and the strings in that file:- In the Google Cloud console, navigate to the Cloud Deploy **Delivery pipelines** page to view your delivery pipeline ( `custom-targets-pipeline` ). [Open the Delivery pipelines page](https://console.cloud.google.com/deploy/delivery-pipelines) \n- Click the name of your delivery pipeline ( `custom-targets-pipeline` ).The pipeline visualization shows the app's deployment status. Because there's only one stage in the pipeline, the visualization shows only one node.And your release is listed on the **Releases** tab under **Delivery pipelinedetails** .\n- Click the release name.The **Release details** page is shown.\n- Click the **Artifacts** tab.\n- Under **Target artifacts** , click the **VIEW ARTIFACTS** link.The rendered manifest file is shown. In this case, the file is the output of the custom render action you defined in your `skaffold.yaml` configuration file, containing the string \"Sample manifest rendered content\".\n- Find the **Cloud Storage** buckets created by this release. [Open the Cloud Storage browser page](https://console.cloud.google.com/storage/browser) The **Buckets** page is displayed, showing two buckets created for this release. One bucket contains the delivery pipeline configuration file and the rendered `skaffold.yaml` . The other includes the output file our custom action is configured to create.\n- Click the bucket whose name starts with `us-central1.deploy-artifacts` ...\n- Click the folder whose name starts with `custom-targets-pipeline-` , then click the `test-release-001` folder.\n- Click the folder whose name is your rollout name, which should be `test-release-001-to-sample-env-0001` .\n- Click the folder shown, which is a UUID, then click the `custom-output` folder.\n- Click `results.json` , then click the hyperlinked URL in the **AuthenticatedURL** field.This file contains the string you configured as output from the `custom-deploy` action, in your `skaffold.yaml` :\n **Note:** you can also see the **render** results in the Cloud Storage bucket, but it's quicker to use the release inspector, as shown in the [first steps](#view_the_results_in) of this procedure.## Clean upTo avoid incurring charges to your Google Cloud account for   the resources used on this page, follow these steps.- Delete the delivery pipeline, target, release, and rollout:```\ngcloud deploy delete --file=clouddeploy.yaml --force --region=us-central1 --project=PROJECT_ID\n```\n- Delete both of the Cloud Storage buckets that Cloud Deploy created. [Open the Cloud Storage browser page](https://console.cloud.google.com/storage/browser) \nThat's it, you completed this quickstart!## What's next\n- [Learn more about custom targets](/deploy/docs/custom-targets) .\n- See the available [sample custom target types](/deploy/docs/custom-targets#custom_target_examples) .\n- [Learn more about Cloud Deploy](/deploy/docs/overview) .\n- [Learn the basics of deploying applications](/deploy/docs/deploying-application) .\n- [Try out the Cloud Deploy walkthrough](https://shell.cloud.google.com/?show=ide%2Cterminal&walkthrough_id=deploy--cloud-deploy-e2e-gke) .", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Delete Cloud Deploy resources.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Delete Cloud Deploy resources", "url": "https://cloud.google.com/deploy/docs/delete-pipeline", "abstract": "# Cloud Deploy - Delete Cloud Deploy resources\nThis page describes how to delete Cloud Deploy resource, including the following:\n- [Delivery pipelines](#delete_a_delivery_pipeline) \n- [Targets](#delete_a_target) \n- [Custom target types](#delete_a_custom_target_type) \n- [Automations](#delete_an_automation) ", "content": "## Delete a delivery pipeline\nYou can delete a delivery pipeline from the Google Cloud console or using the gcloud CLI.\n### Delete a delivery pipeline using the Google Cloud console\n- In the Google Cloud console, navigate to the Cloud Deploy **Delivery pipelines** page to find the delivery pipeline you want to delete. [Open the Delivery pipelines page](https://console.cloud.google.com/deploy/delivery-pipelines) \n- Click the name of the delivery pipeline you want to delete.The **Delivery pipeline details** page is shown.\n- Click **Delete** .\n### Delete a delivery pipeline using the gcloud CLI\nIf you have a delivery pipeline without any subresources (releases or rollouts), you can delete it by running the following command:\n```\ngcloud deploy delivery-pipelines delete PIPELINE_NAME\n```\nIf the pipeline you want to delete has any releases or rollouts associated with it, you need to include the `--force` flag in order to delete the pipeline and those subresources:\n```\ngcloud deploy delivery-pipelines delete PIPELINE_NAME --force\n```\nCloud Deploy prevents you from deleting the pipeline if there's a release or rollout in a state that would cause problems if deleted. For example, you can't delete a delivery pipeline if a rollout is in the `PENDING` state, but you delete it if the rollout is in a `PENDING_APPROVAL` state. If you can't delete the pipeline, you need to reject approval, or advance or cancel the rollout to a terminal state (such as `SUCCEEDED` or `FAILED` ).\n## Delete a target\nYou can delete a target from the Google Cloud console or using the gcloud CLI. These two methods are described in the sections that follow.\n### Delete a target using the gcloud CLI\nWhen you delete a target using the gcloud CLI, that targets is deleted whether or not it's in use by any delivery pipeline.\nUse the following command to delete a target from the gcloud CLI:\n```\ngcloud deploy targets delete TARGET_NAME --region=REGION\n```\nWhere:\nis the name of the target you want to delete. This is the same as the value for `metadata.name` in the [target configuration](/deploy/docs/config-files#target_definitions) .\nis the name of the region in which the target was created, for example `us-central1` .\nCloud Deploy doesn't prevent you from deleting a target that's actively used by other delivery pipelines.\n### Delete a target using the Google Cloud console\nYou can delete a target using the Google Cloud console, only if that target isn't in use by an existing delivery pipeline resource. That is, if there is a pipeline with a stage that points to the target, then you can't delete the target from the Google Cloud console.\nFollow these steps to delete the target using the Google Cloud console:\n- Navigate to the Cloud Deploy **Targets** page.All available targets in your current project are displayed.\n- Click the menu icon for the target you want to delete.\n- Click **Delete target** .If the target you're trying to delete is referenced by a delivery pipeline, you can't select **Delete target** .If the target referenced by a delivery pipeline, the **Delete target** dialog is shown.\n- Type the target name in the text field provided, and click **Confirm** .## Delete a custom target type\nFrom a command shell, use the following command to delete a [custom target type](/deploy/docs/custom-targets) resource:\n```\ngcloud deploy custom-target-types delete CUSTOM_TARGET_TYPE_NAME \\\u00a0 \u00a0 \u00a0 --region=REGION_NAME\n```\nWhere:\n- Is the name of the custom target type you want to delete. This is the same as the `metadata.name` property in the [custom target type definition](/deploy/docs/config-files#custom_target_type_definitions) .\n- Is the region in which you created the custom target type, for example `us-central1` .## Delete an automation\nYou can delete any automation resource created in your project. You can delete the automation using the Google Cloud console or the gcloud CLI:\n### Delete an automation using the Google Cloud console\n- In the Google Cloud console, navigate to the Cloud Deploy **Delivery pipelines** page to find the delivery pipeline your automation is associated with. [Open the Delivery pipelines page](https://console.cloud.google.com/deploy/delivery-pipelines) \n- Click the name of your delivery pipeline.\n- Under **Delivery pipeline details** , select the **Automations** tab.\n- Click the name of the automation you want to delete.The **Automation details** are shown.\n- Click the **Delete** button, and confirm the deletion by typing the automation name and clicking **Confirm** .\n### Delete an automation using the gcloud CLI\nFrom a command shell, use the following command to delete an automation resource:\n```\ngcloud deploy automations delete AUTOMATION_NAME \\\u00a0 \u00a0 \u00a0 --delivery-pipeline=PIPELINE_NAME \\ --region=REGION_NAME\n```\nWhere:\n- Is the name of the automation you want to delete. This is the same as the `metadata.name` property in the [automation definition](/deploy/docs/config-files#automation_definitions) .\n- Is the name of the delivery pipeline this automation is associated with. All automations exist only within the scope of one delivery pipeline.\n- Is the region in which you created the automation, for example `us-central1` .## What's next\n- Find out how to [suspend a delivery pipeline](/deploy/docs/suspend-pipeline) .\n- Learn more about [automations](/deploy/docs/automation) .\n- Learn how to [use service notifications](/deploy/docs/subscribe-deploy-notifications)", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Deploy a Cloud Run service or job.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Deploy a Cloud Run service or job", "url": "https://cloud.google.com/deploy/docs/run-targets", "abstract": "# Cloud Deploy - Deploy a Cloud Run service or job\nThis document describes how to deploy your applications, including Cloud Run services and Cloud Run jobs.\nCloud Deploy allows you to deploy your container-based workloads to any [Cloud Run service](/run/docs/deploying) or [job](/run/docs/create-jobs) . All Cloud Deploy features are supported when you deploy to Cloud Run targets for Cloud Run services, but canary deployments aren't supported for Cloud Run jobs.\nThis document describes the three main configurations you need to complete in order to deploy to Cloud Run:\n- [Create your target configuration](#create_your_target_configuration) \n- [Create your Skaffold configuration](#create_your_skaffold_configuration) \n- Create your Cloud Run [service definitions](#create_your_service_definitions) or [job definitions](#create_your_job_definitions) \n**Note:** To deploy to Cloud Run, you must [choose Skaffold version 2.0 or greater](/deploy/docs/using-skaffold/select-skaffold#choose_what_version_of_skaffold_to_use) when you create a release. If you don't specify any Skaffold version when you create a release to deploy to Cloud Run, the latest Cloud Run-compatible default Skaffold version is selected automatically.\n", "content": "## Limitations\n- You can only deploy one Cloud Run service or job per target.\n- You can't run a [canary deployment](/deploy/docs/deployment-strategies/canary) against a Cloud Run job.Cloud Run services, however, can use a canary deployment.## Before you begin\n- Make sure you're using [gcloud CLI](/sdk/gcloud/reference/components/update) version `401.0.0` or greater.\n- [Have a Cloud Deploy delivery pipeline](/deploy/docs/create-pipeline-targets) .## Create your target configuration\nThe target can be configured in your delivery pipeline YAML, or can be in a separate file. Also, you can configure more than one target in the same file.\nIn the target definition, create a `run` stanza to identify the location where the Cloud Run service will be created.\nThe syntax for specifying the Cloud Run service or job in your target definition is as follows:\n```\nrun:\u00a0location: projects/[project_name]/locations/[region_name]\n```\nThis resource identifier uses the following elements:\n- [ `project_name` ] is the name of the Google Cloud project in which your Cloud Run service or job will be created.You'll do this for each target. We recommend a different project for each Cloud Run service or job. If you want more than one service or job in the same project, you need to use [Skaffold profiles](https://cloud.google.com/deploy/docs/using-skaffold/managing-manifests) in your `skaffold.yaml` configuration file.\n- [ `region_name` ] is the region in which the service or job will be created. Your service or job can be in any [region that Cloud Run supports](https://cloud.google.com/about/locations) .\nThe following is an example target configuration, defining the Cloud Run service or job to create:\n```\n\u00a0 \u00a0 \u00a0 apiVersion: deploy.cloud.google.com/v1\u00a0 \u00a0 \u00a0 kind: Target\u00a0 \u00a0 \u00a0 metadata:\u00a0 \u00a0 \u00a0 \u00a0name: dev\u00a0 \u00a0 \u00a0 description: development service\u00a0 \u00a0 \u00a0 run:\u00a0 \u00a0 \u00a0 \u00a0location: projects/my-app/locations/us-central1\n```\nYou can define this target inside a Cloud Deploy delivery pipeline definition, or separately. Either way, you must [register the target](/deploy/docs/create-pipeline-targets#register_the_delivery_pipeline_and_targets) before you create the release to deploy your Cloud Run service or job.\n## Create your Skaffold configuration\nThe following is an `skaffold.yaml` file for a [Cloud Run deployment](https://skaffold-v2.web.app/docs/pipeline-stages/deployers/cloudrun/) :\n```\napiVersion: skaffold/v4beta7kind: Configmetadata: \u00a0 name: cloud-run-applicationmanifests:\u00a0 rawYaml:\u00a0 - service.yamldeploy:\u00a0 cloudrun: {}\n```\nIn this `skaffold.yaml` file...\n- `manifests.rawYaml` provides the names of the Cloud Run service definitions.In this example, `service.yaml` is the file that defines a Cloud Run service that Skaffold will deploy. This filename can be anything, but by convention it's `service.yaml` for a service, and `job.yaml` for a job.\n- The `deploy` stanza specifies how you want the manifest to be deployed, specifically, the project and location. `deploy` is required.We recommend you leave the empty `{}` . Cloud Deploy populates this during rendering, based on the project and location from the target definition.For local development, however, you can provide values here. However, Cloud Deploy always use the project and location from the target definition, regardless of whether values are provided here.## Create your Cloud Run service definitions\nTo create a Cloud Run service definition, you can either create one manually, or copy one from an existing service. Both are described in this section.\n### Option 1: create a new Cloud Run service.yaml\nThe [service.yaml](/run/docs/reference/yaml/v1) defines your Cloud Run service. When you create a release, Skaffold uses this definition to deploy your service.\nHere's a simplified example:\n```\napiVersion: serving.knative.dev/v1kind: Servicemetadata:\u00a0name: [SERVICE_NAME]spec:\u00a0template:\u00a0 spec:\u00a0 \u00a0containers:\u00a0 \u00a0- image: [IMAGE_PATH]\n```\nWhere:\n- `[SERVICE_NAME]` is a name for this Cloud Run service.\n- `[IMAGE_PATH]` points to the container image or images you're deploying with this service.\n### Option 2: copy a service.yaml from an existing service using Google Cloud console\nYou can create a service using Google Cloud console or use an existing one, and copy your `service.yaml` from there.\nTo get the `service.yaml` using Google Cloud CLI:\n```\ngcloud run services describe [service_name] --format=export\n```\nTo get the `service.yaml` from Google Cloud console:\n- In Google Cloud console, go to the Cloud Run Services page.\n- Select the existing service whose definition you want to use.\nOr you can [create a new one](/run/docs/deploying#service) , then select it. When you select the service, the Service Details page is shown:- Select the **YAML** tab.\n- Click **Edit** , then copy the contents of the YAML into a new file called `service.yaml` , in your file system, such that Skaffold can use it when you [create a release](/deploy/docs/deploying-application#invoke_your_delivery_pipeline_to_create_a_release) .## Create your Cloud Run job definitions\nTo deploy a Cloud Run job definition, you can either create one manually, or copy one from an existing job. Both are described in this section.\nNote that jobs aren't necessarily run upon being deployed by Cloud Deploy. This is different from services, which are running applications after they're deployed. How a job is invoked depends on the job itself.\n### Option 1: create a new Cloud Run job.yaml\nThe [job.yaml](/run/docs/reference/yaml/v1#job) defines your Cloud Run job. When you create a release, Skaffold uses this definition to deploy the job.\nHere's a simplified example:\n```\napiVersion: run.googleapis.com/v1kind: Jobmetadata:\u00a0name: [JOB_NAME]spec:\u00a0 template:\u00a0 spec:\u00a0 \u00a0containers:\u00a0 \u00a0- image: [IMAGE_PATH]\n```\nWhere:\n- `[JOB_NAME]` is a name for this Cloud Run job.\n- `[IMAGE_PATH]` points to the container image you're deploying for this job.\n### Option 2: copy a job.yaml from an existing job using Google Cloud console\nYou can create a job using Google Cloud console or use an existing one, and copy your `job.yaml` from there.\nTo get the `job.yaml` using Google Cloud CLI:\n```\ngcloud run jobs describe [job_name] --format=export\n```\nTo get the `job.yaml` from Google Cloud console:\n- In Google Cloud console, go to the Cloud Run Jobs page.\n- Select the existing job whose definition you want to use.\nOr you can [create a new one](/run/docs/create-jobs#job) , then select it. When you select the job, the Job Details page is shown:- Select the **YAML** tab.\n- Click **Edit** , then copy the contents of the YAML into a new file called `job.yaml` , in your file system, such that Skaffold can use it when you [create a release](/deploy/docs/deploying-application#invoke_your_delivery_pipeline_to_create_a_release) .## Putting it all together\nNow that you have your Cloud Run service or job definition, your `skaffold.yaml` configuration, and your Cloud Deploy target definition, and you've [registered your target](/deploy/docs/create-pipeline-targets#register_the_delivery_pipeline_and_targets) as a Cloud Deploy resource, you can now [invoke your delivery pipeline](https://cloud.google.com/deploy/docs/deploying-application#invoke_your_delivery_pipeline_to_create_a_release) to create a release and progress it through the progression of targets defined in the pipeline.\nThe quickstart [Deploy an app to Cloud Run using Cloud Deploy](/deploy/docs/deploy-app-run) shows all of this in action.\n## Behavior of services across revisions\nWhen you re-deploy a service, the new revision is based on the newly deployed `service.yaml` . Nothing about the previous revision is maintained, unless it's the same in the newly deployed YAML. For example, if there are configuration settings or labels in the previous revision that are not in the new YAML, those settings or labels are absent from the new revision.\n## Deploying Cloud Run services and jobs in multiple projects\nIf you need to deploy services or jobs that are in different projects, your [execution service account](/deploy/docs/cloud-deploy-service-account) needs permission to access the projects in which those services or jobs are defined.\nSee [Cloud Deploy execution service account](/deploy/docs/cloud-deploy-service-account#execution_service_account) and [Identity and Access Management roles and permissions](/deploy/docs/iam-roles-permissions) for more information.\n## What's next\n- Try the [quickstart: deploy an application to Cloud Run](/deploy/docs/deploy-app-run) \n- Learn more about [configuring Cloud Deploy targets](/deploy/docs/config-files#target_definitions) \n- Learn about Cloud Deploy [execution environments](/deploy/docs/execution-environment) .\n- Learn more about [Skaffold support for Cloud Run](https://skaffold-v2.web.app/docs/pipeline-stages/deployers/cloudrun/) \n- Learn more about [Cloud Run](/run/docs)", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Deploy an app to Cloud Run using Cloud Deploy.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Deploy an app to Cloud Run using Cloud Deploy", "url": "https://cloud.google.com/deploy/docs/deploy-app-run", "abstract": "# Cloud Deploy - Deploy an app to Cloud Run using Cloud Deploy\n# Deploy an app to Cloud Run using Cloud Deploy\nThis page shows you how to use Cloud Deploy to deliver a sample application image named `hello` to a sequence of two Cloud Run services or two Cloud Run jobs.\nIn this quickstart, you'll do the following:- Create a [Skaffold](/skaffold) configuration\n- Create configuration files for two Cloud Run services or two jobs.These files define the services or jobs, and specify the (pre-built) container images to deploy.\n- Define your Cloud Deploy delivery pipeline and deployment [targets](/deploy/docs/terminology#target) , which point to the two services or the two jobs.\n- Instantiate your delivery pipeline by creating a release, which automatically deploys to the first target.\n- Promote the release to the second target.\n- View both rollouts in Google Cloud console.\n", "content": "## Before you begin- If you already have the CLI installed, make sure you're running the latest version:\n- ```\ngcloud components update\n```\n- Make sure the [default Compute Engine service account](/deploy/docs/cloud-deploy-service-account#execution_service_account) has sufficient permissions.The service account might already have the necessary permissions. These steps  are included for projects that disable automatic role grants for default  service accounts.\n- Add the`clouddeploy.jobRunner`role:```\ngcloud projects add-iam-policy-binding PROJECT_ID \\\n --member=serviceAccount:$(gcloud projects describe PROJECT_ID \\\n --format=\"value(projectNumber)\")-compute@developer.gserviceaccount.com \\\n --role=\"roles/clouddeploy.jobRunner\"\n```\n- Grant the default execution service account`actAs` [permission to deploy workloads](https://cloud.google.com/run/docs/reference/iam/roles#additional-configuration) into Cloud Run:```\ngcloud iam service-accounts add-iam-policy-binding $(gcloud projects describe PROJECT_ID \\\n --format=\"value(projectNumber)\")-compute@developer.gserviceaccount.com \\\n --member=serviceAccount:$(gcloud projects describe PROJECT_ID \\\n --format=\"value(projectNumber)\")-compute@developer.gserviceaccount.com \\\n --role=\"roles/iam.serviceAccountUser\" \\\n --project=PROJECT_ID\n```\n- Add the Cloud Run developer permissions:```\ngcloud projects add-iam-policy-binding PROJECT_ID \\\n --member=serviceAccount:$(gcloud projects describe PROJECT_ID \\\n --format=\"value(projectNumber)\")-compute@developer.gserviceaccount.com \\\n --role=\"roles/run.developer\"\n```If you have trouble adding either of these roles, contact your project administrator.\n## Prepare your Skaffold configurationCloud Deploy uses [Skaffold](/deploy/docs/using-skaffold) to provide the details for what to deploy and how to deploy it properly for your separate [targets](/deploy/docs/terminology#target) .\nFor this quickstart, you create a `skaffold.yaml` file, which identifies the Cloud Run service or job definition to be used to deploy the sample app.- Open a terminal window.\n- Create a new directory, named `deploy-run-quickstart` and navigate into it.```\nmkdir deploy-run-quickstartcd deploy-run-quickstart\n```\n- Create a file named `skaffold.yaml` with the following contents:\n```\napiVersion: skaffold/v4beta7kind: Configmetadata: \u00a0 name: deploy-run-quickstartprofiles:- name: dev\u00a0 manifests:\u00a0 \u00a0 rawYaml:\u00a0 \u00a0 - run-service-dev.yaml- name: prod\u00a0 manifests:\u00a0 \u00a0 rawYaml:\u00a0 \u00a0 - run-service-prod.yamldeploy:\u00a0 cloudrun: {}\n```\n```\napiVersion: skaffold/v4beta7kind: Configmetadata: \u00a0 name: deploy-run-quickstartprofiles:- name: dev\u00a0 manifests:\u00a0 \u00a0 rawYaml:\u00a0 \u00a0 - run-job-dev.yaml- name: prod\u00a0 manifests:\u00a0 \u00a0 rawYaml:\u00a0 \u00a0 - run-job-prod.yamldeploy:\u00a0 cloudrun: {}\n```\nThis file is a minimal Skaffold config, identifying your Cloud Run services or jobs. See the [skaffold.yaml reference](https://skaffold.dev/docs/references/yaml/) for more information about this file.\n## Prepare your Cloud Run services or jobsFor this quickstart, you'll create either two different Cloud Run services or two Cloud Run jobs, in the same project. Cloud Deploy also supports deploying across multiple projects. Also, we use [Skaffold profiles](https://skaffold.dev/docs/environment/profiles/) to make it possible to have two services or jobs in the same project. When you use different projects, you might not need to use Skaffold profiles.\n- Create a file named `run-service-dev.yaml` with the following contents:```\napiVersion: serving.knative.dev/v1kind: Servicemetadata:\u00a0 name: deploy-run-service-devspec:\u00a0 template:\u00a0 \u00a0 spec:\u00a0 \u00a0 \u00a0 containers:\u00a0 \u00a0 \u00a0 - image: my-app-image\n```This file defines a Cloud Run service. As the name `deploy-run-service-dev` implies, this is your `dev` service, and corresponds to the first target in your delivery pipeline progression.\n- Create a file named `run-service-prod.yaml` with the following contents:```\napiVersion: serving.knative.dev/v1kind: Servicemetadata:\u00a0 name: deploy-run-service-prodspec:\u00a0 template:\u00a0 \u00a0 spec:\u00a0 \u00a0 \u00a0 containers:\u00a0 \u00a0 \u00a0 - image: my-app-image\n```This file defines another Cloud Run service, and as the name `deploy-run-service-prod` implies, this is your `prod` service, and corresponds to the second target in your delivery pipeline progression.\n- Create a file named `run-job-dev.yaml` with the following contents:```\napiVersion: run.googleapis.com/v1kind: Jobmetadata:\u00a0 name: deploy-run-job-devspec:\u00a0 template:\u00a0 \u00a0 spec:\u00a0 \u00a0 \u00a0 template:\u00a0 \u00a0 \u00a0 \u00a0 spec:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 containers:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 - image: my-app-image\n```This file defines a Cloud Run job. As the name `deploy-run-job-dev` implies, this is your `dev` job, and corresponds to the first target in your delivery pipeline progression.\n- Create a file named `run-job-prod.yaml` with the following contents:```\napiVersion: run.googleapis.com/v1kind: Jobmetadata:\u00a0 name: deploy-run-job-prodspec:\u00a0 template:\u00a0 \u00a0 spec:\u00a0 \u00a0 \u00a0 template:\u00a0 \u00a0 \u00a0 \u00a0 spec:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 containers:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 - image: my-app-image\n```This file defines another Cloud Run job. As the name `deploy-run-job-prod` implies, this is your `prod` job, and corresponds to the second target in your delivery pipeline progression.\n## Create your delivery pipeline and targetsYou can define your pipeline and targets in one file or in separate files. In this quickstart, you create a single file.- In the `deploy-run-quickstart` directory, create a new file: `clouddeploy.yaml` , with the following contents:```\napiVersion: deploy.cloud.google.com/v1kind: DeliveryPipelinemetadata:\u00a0 name: my-run-demo-app-1description: main application pipelineserialPipeline:\u00a0 stages:\u00a0 - targetId: run-qsdev\u00a0 \u00a0 profiles: [dev]\u00a0 - targetId: run-qsprod\u00a0 \u00a0 profiles: [prod]---apiVersion: deploy.cloud.google.com/v1kind: Targetmetadata:\u00a0 name: run-qsdevdescription: Cloud Run development servicerun:\u00a0 location: projects/PROJECT_ID/locations/us-central1---apiVersion: deploy.cloud.google.com/v1kind: Targetmetadata:\u00a0 name: run-qsproddescription: Cloud Run production servicerun:\u00a0 location: projects/PROJECT_ID/locations/us-central1\n``` **Note:** In this file, targets are included with the delivery pipeline, but you can define targets in a separate file or multiple separate files.\n- Register your pipeline and targets with the Cloud Deploy service:```\ngcloud deploy apply --file=clouddeploy.yaml --region=us-central1 --project=PROJECT_ID\n```You now have a pipeline, with targets, ready to deploy your application to your first target.\n- Confirm your pipeline and targets:In the Google Cloud console, navigate to the Cloud Deploy **Delivery pipelines** page to view of list of your available delivery pipelines. [Open the Delivery pipelines page](https://console.cloud.google.com/deploy/delivery-pipelines) The delivery pipeline you just created is shown, and the two targets are listed in the **Targets** column.\n## Create a releaseA release is the central Cloud Deploy resource representing the changes being deployed. The delivery pipeline defines the lifecycle of that release. See [Cloud Deploy service architecture](/deploy/docs/architecture#how_they_fit_together_to_deliver_your_release) for details about that lifecycle.\nRun the following command from the `deploy-run-quickstart` directory to create a `release` resource that represents the container image to deploy:\n```\n\u00a0gcloud deploy releases create test-release-001 \\\u00a0 \u00a0--project=PROJECT_ID \\\u00a0 \u00a0--region=us-central1 \\\u00a0 \u00a0--delivery-pipeline=my-run-demo-app-1 \\\u00a0 \u00a0--images=my-app-image=us-docker.pkg.dev/cloudrun/container/hello@sha256:6063adf8f687702b4065151acddba6781c47bc602167eb9f3bec8aebc9ce95cc\n```\n```\n\u00a0gcloud deploy releases create test-release-001 \\\u00a0 \u00a0--project=PROJECT_ID \\\u00a0 \u00a0--region=us-central1 \\\u00a0 \u00a0--delivery-pipeline=my-run-demo-app-1 \\\u00a0 \u00a0--images=my-app-image=us-docker.pkg.dev/cloudrun/container/job@sha256:d7c33651fbad911a9a0a0c16f2f9b3a79f0b9e3e89afb205603af706067feac5\n```As with all releases (unless they include `--disable-initial-rollout` ), Cloud Deploy automatically creates a [rollout](/deploy/docs/terminology#rollout) resource too. The application is automatically deployed into the first target in the progression.## Promote the release **Note:** after you create the release, you might need wait a few minutes before you continue with this step.- From the **Delivery pipelines** page, click the `my-run-demo-app-1` pipeline. [Open the Delivery pipelines page](https://console.cloud.google.com/deploy/delivery-pipelines) The Delivery pipeline details page shows a graphical representation of your delivery pipeline's progress. In this case, it shows that the release was deployed to the `run-qsdev` target.\n- On the first target in the delivery pipeline visualization, click **Promote** .The **Promote release** dialog is shown. It shows the details of the target you're promoting to.\n- Click **Promote** .The release is now queued for deployment into `run-qsprod` . When deployment is complete, the delivery pipeline visualization shows it as deployed:\n## View the results in Google Cloud console\n- In the Google Cloud console, navigate to the Cloud Deploy **Delivery pipelines** page to view your **my-run-demo-app-1** delivery pipeline. [Open the Delivery pipelines page](https://console.cloud.google.com/deploy/delivery-pipelines) \n- Click the name of your delivery pipeline \"my-run-demo-app-1\".The pipeline visualization shows the app's progress through the pipeline.And your release is listed on the **Releases** tab under **Delivery pipelinedetails** .\n- Click the release name, `test-release-001` .Your rollouts appear under **Rollouts** . You can click a rollout to view its details, including the deployment log.\n## Accessing your Cloud Run serviceBy default, you must be authenticated in order to access newly created Cloud Run services. See the Cloud Run [Authentication overview](/run/docs/authenticating/overview) to learn how to provide credentials and to find out what Identity and Access Management configuration is required in order access the service without authentication. This doesn't apply to Cloud Run jobs.## Clean upTo avoid incurring charges to your Google Cloud account for   the resources used on this page, follow these steps.- Delete the `deploy-qs-dev` Cloud Run service or job:\n```\ngcloud run services delete deploy-run-service-dev --region=us-central1 --project=PROJECT_ID\n```\n```\ngcloud run jobs delete deploy-run-job-dev --region=us-central1 --project=PROJECT_ID\n```\n- Delete the `deploy-qs-prod` service:\n```\ngcloud run services delete deploy-run-service-prod --region=us-central1 --project=PROJECT_ID\n```\n```\ngcloud run jobs delete deploy-run-job-prod --region=us-central1 --project=PROJECT_ID\n```\n- Delete the delivery pipeline, targets, release and rollouts:```\ngcloud deploy delete --file=clouddeploy.yaml --force --region=us-central1 --project=PROJECT_ID\n```\n- Delete the Cloud Storage buckets that Cloud Deploy created.One ends with `_clouddeploy` , and the other is `[region].deploy-artifacts.[project].appspot.com` . [Open the Cloud Storage browser page](https://console.cloud.google.com/storage/browser) \nThat's it, you completed this quickstart!## What's next\n- [Learn more about Cloud Deploy](/deploy/docs/overview) .\n- [Learn the basics of deploying applications](/deploy/docs/deploying-application) .\n- Read the [how-to article for deploying to Cloud Run](/deploy/docs/run-targets) \n- Learn how to [manage your manifests](/deploy/docs/skaffold) .\n- [Learn how to combine Google Cloud CI/CD tools to develop and deliversoftware effectively to GKE](https://cloud.google.com/architecture/app-development-and-delivery-with-cloud-code-gcb-cd-and-gke) .", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Deploy an app to GKE using Cloud Deploy.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Deploy an app to GKE using Cloud Deploy", "url": "https://cloud.google.com/deploy/docs/deploy-app-gke", "abstract": "# Cloud Deploy - Deploy an app to GKE using Cloud Deploy\n# Deploy an app to GKE using Cloud Deploy\nThis page shows you how to use Cloud Deploy to deliver a sample application image named `nginx` to a sequence of two Google Kubernetes Engine clusters.\nIn this quickstart, you'll do the following:- Create the two clusters.\n- Create a [Skaffold](/skaffold) configuration and a Kubernetes manifest to specify the (pre-built) container image to deploy.\n- Define your Cloud Deploy delivery pipeline and deployment [targets](/deploy/docs/terminology#target) , which point to the two clusters.\n- Instantiate your delivery pipeline by creating a release, which automatically deploys to the first target.\n- Promote the release to the second target.\n- View both rollouts in Google Cloud console.\n", "content": "## Before you begin- Make sure the [default Compute Engine service account](/deploy/docs/cloud-deploy-service-account#execution_service_account) has sufficient permissions.The service account might already have the necessary permissions. These steps  are included for projects that disable automatic role grants for default  service accounts.\n- Add the`clouddeploy.jobRunner`role:```\ngcloud projects add-iam-policy-binding PROJECT_ID \\\n --member=serviceAccount:$(gcloud projects describe PROJECT_ID \\\n --format=\"value(projectNumber)\")-compute@developer.gserviceaccount.com \\\n --role=\"roles/clouddeploy.jobRunner\"\n```\n- Add the Kubernetes developer permissions:```\ngcloud projects add-iam-policy-binding PROJECT_ID \\\n --member=serviceAccount:$(gcloud projects describe PROJECT_ID \\\n --format=\"value(projectNumber)\")-compute@developer.gserviceaccount.com \\\n --role=\"roles/container.developer\"\n```If you have trouble adding either of these roles, contact your project administrator.\n- Add the`iam.serviceAccountUser`role, which includes the`actAs`permission to deploy to the runtime:```\ngcloud iam service-accounts add-iam-policy-binding $(gcloud projects describe PROJECT_ID \\\n --format=\"value(projectNumber)\")-compute@developer.gserviceaccount.com \\\n --member=serviceAccount:$(gcloud projects describe PROJECT_ID \\\n --format=\"value(projectNumber)\")-compute@developer.gserviceaccount.com \\\n --role=\"roles/iam.serviceAccountUser\" \\\n --project=PROJECT_ID\n```## Create your Google Kubernetes Engine clustersCreate two clusters: `qsdev` and `qsprod` , with default settings. The clusters' Kubernetes API endpoints must be network-reachable from the public internet. GKE clusters are externally accessible by default.\n```\ngcloud container clusters create-auto quickstart-cluster-qsdev --project=PROJECT_ID --region=us-central1 && gcloud container clusters create-auto quickstart-cluster-qsprod --project=PROJECT_ID --region=us-central1\n```## Prepare your Skaffold configuration and Kubernetes manifestCloud Deploy uses [Skaffold](/deploy/docs/using-skaffold) to provide the details for what to deploy and how to deploy it properly for your separate [targets](/deploy/docs/terminology#target) .\nIn this quickstart, you create a `skaffold.yaml` file, which identifies the Kubernetes manifest to be used to deploy the sample app.- Open a terminal window.\n- Create a new directory, named `deploy-gke-quickstart` and navigate into it.```\nmkdir deploy-gke-quickstartcd deploy-gke-quickstart\n```\n- Create a file named `skaffold.yaml` with the following contents:```\napiVersion: skaffold/v4beta7kind: Configmanifests:\u00a0 rawYaml:\u00a0 - k8s-*deploy:\u00a0 kubectl: {}\n```This file is a minimal Skaffold config, identifying your manifest. For this quickstart, you create the file. But you can also [have Cloud Deploy create one for you](/deploy/docs/using-skaffold/getting-started-skaffold#have_generate_your_skaffoldyaml) , for simple, non-production applications.See the [skaffold.yaml reference](https://skaffold.dev/docs/references/yaml/) for more information about this file.\n- Create a file named `k8s-pod.yaml` , with the following contents:```\napiVersion: v1kind: Podmetadata:\u00a0 name: getting-startedspec:\u00a0 containers:\u00a0 - name: nginx\u00a0 \u00a0 image: my-app-image\n```This file is a simple Kubernetes [manifest](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-manifest) , which is applied to the cluster to deploy the application.\n **Note:** If you want to use different manifests per target, read [this articleabout managing manifests](/deploy/docs/using-skaffold/managing-manifests) to find out more about using Skaffold profiles.## Create your delivery pipeline and targetsYou can define your pipeline and targets in one file or in separate files. In this quickstart, you create a single file.- In the `deploy-gke-quickstart` directory, create a new file: `clouddeploy.yaml` , with the following contents:```\napiVersion: deploy.cloud.google.com/v1kind: DeliveryPipelinemetadata:\u00a0 name: my-gke-demo-app-1description: main application pipelineserialPipeline:\u00a0 stages:\u00a0 - targetId: qsdev\u00a0 \u00a0 profiles: []\u00a0 - targetId: qsprod\u00a0 \u00a0 profiles: []---apiVersion: deploy.cloud.google.com/v1kind: Targetmetadata:\u00a0 name: qsdevdescription: development clustergke:\u00a0 cluster: projects/PROJECT_ID/locations/us-central1/clusters/quickstart-cluster-qsdev---apiVersion: deploy.cloud.google.com/v1kind: Targetmetadata:\u00a0 name: qsproddescription: production clustergke:\u00a0 cluster: projects/PROJECT_ID/locations/us-central1/clusters/quickstart-cluster-qsprod\n```\n- Register your pipeline and targets with the Cloud Deploy service:```\ngcloud deploy apply --file=clouddeploy.yaml --region=us-central1 --project=PROJECT_ID\n```You now have a pipeline, with targets, ready to deploy your application to your first target.\n- Confirm your pipeline and targets:In the Google Cloud console, navigate to the Cloud Deploy **Delivery pipelines** page to view of list of your available delivery pipelines. [Open the Delivery pipelines page](https://console.cloud.google.com/deploy/delivery-pipelines) The delivery pipeline you just created is shown, and the two targets are listed in the **Targets** column.\n## Create a releaseA release is the central Cloud Deploy resource representing the changes being deployed. The delivery pipeline defines the lifecycle of that release. See [Cloud Deploy service architecture](/deploy/docs/architecture#how_they_fit_together_to_deliver_your_release) for details about that lifecycle.\nRun the following command from the `deploy-gke-quickstart` directory to create a `release` resource that represents the container image to deploy:\n```\ngcloud deploy releases create test-release-001 \\\u00a0 --project=PROJECT_ID \\\u00a0 --region=us-central1 \\\u00a0 --delivery-pipeline=my-gke-demo-app-1 \\\u00a0 --images=my-app-image=gcr.io/google-containers/nginx@sha256:f49a843c290594dcf4d193535d1f4ba8af7d56cea2cf79d1e9554f077f1e7aaa\n```\nAs with all releases (unless they include `--disable-initial-rollout` ), Cloud Deploy automatically creates a [rollout](/deploy/docs/terminology#rollout) resource too. The application is automatically deployed into the first target in the progression.## Promote the release **Note:** after you create the release, you might need wait a few minutes before you continue with this step.- From the **Delivery pipelines** page, click the `my-gke-demo-app-1` pipeline. [Open the Delivery pipelines page](https://console.cloud.google.com/deploy/delivery-pipelines) The Delivery pipeline details page shows a graphical representation of your delivery pipeline's progress. In this case, it shows that the release was deployed to the `qsdev` target.\n- On the first target in the delivery pipeline visualization, click **Promote** .The **Promote release** dialog is shown. It shows the details of the target you're promoting to.\n- Click **Promote** .The release is now queued for deployment into `qsprod` . When deployment is complete, the delivery pipeline visualization shows it as deployed:\n## View the results in Google Cloud console\n- In the Google Cloud console, navigate to the Cloud Deploy **Delivery pipelines** page to view your **my-gke-demo-app-1** delivery pipeline. [Open the Delivery pipelines page](https://console.cloud.google.com/deploy/delivery-pipelines) \n- Click the name of your delivery pipeline \"my-gke-demo-app-1\".The pipeline visualization shows the app's progress through the pipeline.And your release is listed on the **Releases** tab under **Delivery pipelinedetails** .\n- Click the release name, `test-release-001` .Your rollouts appear under **Rollouts** . You can click a rollout to view its details, including the deployment log.\n## Clean upTo avoid incurring charges to your Google Cloud account for   the resources used on this page, follow these steps.- Delete the `qsdev` cluster:```\ngcloud container clusters delete quickstart-cluster-qsdev --region=us-central1 --project=PROJECT_ID\n```\n- Delete the `qsprod` cluster:```\ngcloud container clusters delete quickstart-cluster-qsprod --region=us-central1 --project=PROJECT_ID\n```\n- Delete the delivery pipeline, targets, release and rollouts:```\ngcloud deploy delete --file=clouddeploy.yaml --force --region=us-central1 --project=PROJECT_ID\n```\n- Delete the Cloud Storage buckets that Cloud Deploy created.One ends with `_clouddeploy` , and the other is `[region].deploy-artifacts.[project].appspot.com` . [Open the Cloud Storage browser page](https://console.cloud.google.com/storage/browser) \nThat's it, you completed this quickstart!## What's next\n- [Learn more about Cloud Deploy](/deploy/docs/overview) .\n- [Learn the basics of deploying applications](/deploy/docs/deploying-application) .\n- [Try out the Cloud Deploy walkthrough](https://shell.cloud.google.com/?show=ide%2Cterminal&walkthrough_id=deploy--cloud-deploy-e2e-gke) .\n- Learn how to [manage your manifests](/deploy/docs/skaffold) .\n- [Learn how to combine Google Cloud CI/CD tools to develop and deliversoftware effectively to GKE](https://cloud.google.com/architecture/app-development-and-delivery-with-cloud-code-gcb-cd-and-gke) .", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Deploy an app to multiple targets at the same time.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Deploy an app to multiple targets at the same time", "url": "https://cloud.google.com/deploy/docs/deploy-app-parallel", "abstract": "# Cloud Deploy - Deploy an app to multiple targets at the same time\n# Deploy an app to multiple targets at the same time\nThis page shows you how to use Cloud Deploy to deliver a sample application to two [targets](/deploy/docs/terminology#target) at the same time\u2014a parallel deployment.\nIn this quickstart, you'll do the following:- Create two GKE clusters or two Cloud Run services.You can deploy in parallel to GKE Enterprise clusters too, but this quickstart uses GKE and Cloud Run only.\n- Create a [Skaffold](/skaffold) configuration and either a Kubernetes manifest or a Cloud Run service definition.\n- Define your Cloud Deploy delivery pipeline and deployment targets.This will have only one target, but that target will be a \u2014a target that represents more than one deployment target. This multi-target will comprise two actual targets, delivering your app to the two clusters or services.\n- Instantiate your delivery pipeline by creating a release, which automatically deploys to the two targets in parallel.\n- View the \"controller rollout\" and child rollouts in Google Cloud console.\n", "content": "## Before you begin- If you already have the CLI installed, make sure you're running the latest version:\n- ```\ngcloud components update\n```\n- Make sure the [default Compute Engine service account](/deploy/docs/cloud-deploy-service-account#execution_service_account) has sufficient permissions.The service account might already have the necessary permissions. These steps are included for projects that disable automatic role grants for default service accounts.- First add the`clouddeploy.jobRunner`role:```\ngcloud projects add-iam-policy-binding PROJECT_ID \\\n --member=serviceAccount:$(gcloud projects describe PROJECT_ID \\\n --format=\"value(projectNumber)\")-compute@developer.gserviceaccount.com \\\n --role=\"roles/clouddeploy.jobRunner\"\n```\n- Add the developer role for your specific runtime.\n- For GKE:```\ngcloud projects add-iam-policy-binding PROJECT_ID \\\n --member=serviceAccount:$(gcloud projects describe PROJECT_ID \\\n --format=\"value(projectNumber)\")-compute@developer.gserviceaccount.com \\\n --role=\"roles/container.developer\"\n```\n- For Cloud Run:```\ngcloud projects add-iam-policy-binding PROJECT_ID \\\n --member=serviceAccount:$(gcloud projects describe PROJECT_ID \\\n --format=\"value(projectNumber)\")-compute@developer.gserviceaccount.com \\\n --role=\"roles/run.developer\"\n```\n- Add the`iam.serviceAccountUser`role, which includes the`actAs`permission to deploy to the runtime:```\ngcloud iam service-accounts add-iam-policy-binding $(gcloud projects describe PROJECT_ID \\\n --format=\"value(projectNumber)\")-compute@developer.gserviceaccount.com \\\n --member=serviceAccount:$(gcloud projects describe PROJECT_ID \\\n --format=\"value(projectNumber)\")-compute@developer.gserviceaccount.com \\\n --role=\"roles/iam.serviceAccountUser\" \\\n --project=PROJECT_ID\n```\n## Create your runtime environments **If you're deploying to Cloud Run, you can skip this command** .\nFor GKE, create two clusters: `quickstart-cluster-qsprod1` and `quickstart-cluster-qsprod2` , with default settings. The clusters' Kubernetes API endpoints must be network-reachable from the public internet. GKE clusters are externally accessible by default.\n```\ngcloud container clusters create-auto quickstart-cluster-qsprod1 \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--project=PROJECT_ID \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--region=us-central1 \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0&& gcloud container clusters create-auto quickstart-cluster-qsprod2 \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--project=PROJECT_ID \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--region=us-west1\n```## Prepare your Skaffold configuration and application manifestCloud Deploy uses [Skaffold](/deploy/docs/using-skaffold) to provide the details for what to deploy and how to deploy it properly for your separate [targets](/deploy/docs/terminology#target) .\nIn this quickstart, you create a `skaffold.yaml` file, which identifies the application manifest to be used to deploy the sample app.- Open a terminal window.\n- Create a new directory and navigate into it.\n```\nmkdir deploy-gke-parallel-quickstartcd deploy-gke-parallel-quickstart\n```\n```\nmkdir deploy-run-parallel-quickstartcd deploy-run-parallel-quickstart\n```\n- Create a file named `skaffold.yaml` with the following contents:\n```\napiVersion: skaffold/v4beta1kind: Configmanifests:\u00a0 rawYaml:\u00a0 - k8s-deployment.yamldeploy:\u00a0 kubectl: {}\n```\n```\napiVersion: skaffold/v4beta1kind: Configmanifests:\u00a0 rawYaml:\u00a0 - service.yamldeploy:\u00a0 cloudrun: {}\n```\nThis file is a minimal Skaffold config. For this quickstart, you create the file. But you can also [have Cloud Deploy create one for you](/deploy/docs/using-skaffold/getting-started-skaffold#have_generate_your_skaffoldyaml) , for simple, non-production applications.See the [skaffold.yaml reference](https://skaffold.dev/docs/references/yaml/) for more information about this file.\n- Create the definition for your application\u2014a service definition for Cloud Run or a Kubernetes manifest for GKE.\nCreate a file named `k8s-deployment.yaml` , with the following contents:\n```\napiVersion: apps/v1kind: Deploymentmetadata:\u00a0 name: my-deployment\u00a0 labels:\u00a0 \u00a0 app: my-app\u00a0 namespace: defaultspec:\u00a0 replicas: 1 # from-param: ${replicaCount}\u00a0 selector:\u00a0 \u00a0 matchLabels:\u00a0 \u00a0 \u00a0 app: my-app\u00a0 template:\u00a0 \u00a0 metadata:\u00a0 \u00a0 \u00a0 labels:\u00a0 \u00a0 \u00a0 \u00a0 app: my-app\u00a0 \u00a0 spec:\u00a0 \u00a0 \u00a0 containers:\u00a0 \u00a0 \u00a0 - name: nginx\u00a0 \u00a0 \u00a0 \u00a0 image: my-app-image\n```\nThis file is a simple Kubernetes [manifest](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-manifest) , which is applied to the cluster to deploy the application.\nCreate a file named `service.yaml` , with the following contents:\n```\napiVersion: serving.knative.dev/v1kind: Servicemetadata:\u00a0 name: my-parallel-run-servicespec:\u00a0 template:\u00a0 \u00a0 metadata:\u00a0 \u00a0 \u00a0 annotations:\u00a0 \u00a0 \u00a0 \u00a0 autoscaling.knative.dev/minScale: 1 # from-param: ${minInstances}\u00a0 \u00a0 spec:\u00a0 \u00a0 \u00a0 containers:\u00a0 \u00a0 \u00a0 - image: my-app-image\n```\nThis file is a simple Cloud Run service definition, which is used at deploy time to create your Cloud Run service. **Note:** If you want to use different manifests per target, read [this articleabout managing manifests](/deploy/docs/using-skaffold/managing-manifests) to find out more about using Skaffold profiles.## Create your delivery pipeline and targetsYou can define your pipeline and targets in one file or in separate files. In this quickstart, you create a single file.- Create your delivery pipeline and target definition:\nIn the `deploy-gke-parallel-quickstart` directory, create a new file: `clouddeploy.yaml` , with the following contents:\n```\napiVersion: deploy.cloud.google.com/v1kind: DeliveryPipelinemetadata:\u00a0 name: my-parallel-demo-app-1description: main application pipelineserialPipeline:\u00a0 stages:\u00a0 - targetId: qsprod-multi\u00a0 \u00a0 profiles: []\u00a0 \u00a0 deployParameters:\u00a0 \u00a0 - values:\u00a0 \u00a0 \u00a0 \u00a0 replicaCount: \"1\"\u00a0 \u00a0 \u00a0 matchTargetLabels:\u00a0 \u00a0 \u00a0 \u00a0 label1: label1\u00a0 \u00a0 - values:\u00a0 \u00a0 \u00a0 \u00a0 replicaCount: \"2\"\u00a0 \u00a0 \u00a0 matchTargetLabels:\u00a0 \u00a0 \u00a0 \u00a0 label2: label2---apiVersion: deploy.cloud.google.com/v1kind: Targetmetadata:\u00a0 name: qsprod-multidescription: production clustersmultiTarget:\u00a0 targetIds: [qsprod-a, qsprod-b]---apiVersion: deploy.cloud.google.com/v1kind: Targetmetadata:\u00a0 name: qsprod-a\u00a0 labels:\u00a0 \u00a0 label1: label1description: production cluster 2gke:\u00a0 cluster: projects/PROJECT_ID/locations/us-central1/clusters/quickstart-cluster-qsprod1---apiVersion: deploy.cloud.google.com/v1kind: Targetmetadata:\u00a0 name: qsprod-b\u00a0 labels:\u00a0 \u00a0 label2: label2description: production cluster 3gke:\u00a0 cluster: projects/PROJECT_ID/locations/us-west1/clusters/quickstart-cluster-qsprod2\n```\n **Note:** In this file, targets are included with the delivery pipeline, but you can define targets in a separate file or multiple separate files.\nIn the `deploy-run-parallel-quickstart` directory, create a new file: `clouddeploy.yaml` , with the following contents:\n```\napiVersion: deploy.cloud.google.com/v1kind: DeliveryPipelinemetadata:\u00a0 name: my-parallel-demo-app-1description: main application pipelineserialPipeline:\u00a0 stages:\u00a0 - targetId: qsprod-multi\u00a0 \u00a0 profiles: []\u00a0 \u00a0 deployParameters:\u00a0 \u00a0 - values:\u00a0 \u00a0 \u00a0 \u00a0 minInstances: \"2\"\u00a0 \u00a0 \u00a0 matchTargetLabels:\u00a0 \u00a0 \u00a0 \u00a0 label1: label1\u00a0 \u00a0 - values:\u00a0 \u00a0 \u00a0 \u00a0 minInstances: \"3\"\u00a0 \u00a0 \u00a0 matchTargetLabels:\u00a0 \u00a0 \u00a0 \u00a0 label2: label2---apiVersion: deploy.cloud.google.com/v1kind: Targetmetadata:\u00a0 name: qsprod-multidescription: productionmultiTarget:\u00a0 targetIds: [qsprod-a, qsprod-b]---apiVersion: deploy.cloud.google.com/v1kind: Targetmetadata:\u00a0 name: qsprod-a\u00a0 labels:\u00a0 \u00a0 label1: label1description: production us-central1run:\u00a0 location: projects/PROJECT_ID/locations/us-central1---apiVersion: deploy.cloud.google.com/v1kind: Targetmetadata:\u00a0 name: qsprod-b\u00a0 labels:\u00a0 \u00a0 label2: label2description: production us-west1run:\u00a0 location: projects/PROJECT_ID/locations/us-west1\n```\n **Note:** In this file, targets are included with the delivery pipeline, but you can define targets in a separate file or multiple separate files.\nNotice that this file includes three targets: a multi-target and two child targets. You can also configure targets in separate file, rather than with your delivery pipeline.Notice also that the delivery pipeline includes `deployParameters` , with labels, and the child targets include labels to match those parameters. This allows you to pass separate values to separate child targets, if you want. [Learn more](/deploy/docs/parameters) .\n- Register your pipeline and targets with the Cloud Deploy service:```\ngcloud deploy apply --file=clouddeploy.yaml --region=us-central1 --project=PROJECT_ID\n```You now have a pipeline, with one multi-target comprising two GKE or Cloud Run targets, ready to deploy your application.\n- Confirm your pipeline and targets:In the Google Cloud console, navigate to the Cloud Deploy **Delivery pipelines** page to view of list of your available delivery pipelines. [Open the Delivery pipelines page](https://console.cloud.google.com/deploy/delivery-pipelines) The delivery pipeline you just created is shown. Notice that there is one target listed in the **Targets** column even though you configured three targets (one multi-target and two child targets) in your `clouddeploy.yaml` file.Notice that the only target listed is the multi-target `qsprod-multi` . Child targets are not shown.\n## Create a releaseA release is the central Cloud Deploy resource representing the changes being deployed. The delivery pipeline defines the lifecycle of that release. See [Cloud Deploy service architecture](/deploy/docs/architecture#how_they_fit_together_to_deliver_your_release) for details about that lifecycle.\nRun the following command from the `deploy-gke-parallel-quickstart` directory to create a `release` resource that represents the container image to deploy:\n```\n\u00a0gcloud deploy releases create test-release-001 \\\u00a0 \u00a0--project=PROJECT_ID \\\u00a0 \u00a0--region=us-central1 \\\u00a0 \u00a0--delivery-pipeline=my-parallel-demo-app-1 \\\u00a0 \u00a0--images=my-app-image=gcr.io/google-containers/nginx@sha256:f49a843c290594dcf4d193535d1f4ba8af7d56cea2cf79d1e9554f077f1e7aaa \\\u00a0 \u00a0--to-target=qsprod-multi\n```\nRun the following command from the `deploy-run-parallel-quickstart` directory to create a `release` resource that represents the container image to deploy:\n```\n\u00a0gcloud deploy releases create test-release-001 \\\u00a0 \u00a0--project=PROJECT_ID \\\u00a0 \u00a0--region=us-central1 \\\u00a0 \u00a0--delivery-pipeline=my-parallel-demo-app-1 \\\u00a0 \u00a0--images=my-app-image=us-docker.pkg.dev/cloudrun/container/hello@sha256:6063adf8f687702b4065151acddba6781c47bc602167eb9f3bec8aebc9ce95cc \\\u00a0 \u00a0--to-target=qsprod-multi\n```As always, when you create a release, a rollout is created automatically for the first target in your pipeline (or, as in this case, a specific target specified using `--to-target=` ). In this quickstart, this target is a multi-target, so the [rollout](/deploy/docs/terminology#rollout) is a \"controller rollout\" for two child targets, and there are no subsequent targets in the delivery pipeline. This means that your application is deployed everywhere upon rollout creation.## View the results in Google Cloud consoleNow that you've created the release, and the controller rollout and child rollouts are created, those child rollouts are now deployed (or are in the process of being deployed) to their respective GKE clusters or Cloud Run services.- In the Google Cloud console, navigate to the Cloud Deploy **Delivery pipelines** page to view your **my-parallel-demo-app-1** delivery pipeline. [Open the Delivery pipelines page](https://console.cloud.google.com/deploy/delivery-pipelines) \n- Click the name of your delivery pipeline \"my-parallel-demo-app-1\".The pipeline visualization shows the app's deployment status. Because there's only one stage in the pipeline, the visualization shows only one node.And your release is listed on the **Releases** tab under **Delivery pipelinedetails** .\n- Click the release name, `test-release-001` .Your rollouts appear under **Rollouts** . You can click a rollout to view its details, including the deployment log.\n## Clean upTo avoid incurring charges to your Google Cloud account for   the resources used on this page, follow these steps.- Delete the GKE clusters or Cloud Run services:\n```\ngcloud container clusters delete quickstart-cluster-qsprod1 --region=us-central1 --project=PROJECT_ID \\&& gcloud container clusters delete quickstart-cluster-qsprod2 --region=us-west1 --project=PROJECT_ID\n```\n```\ngcloud run services delete my-parallel-run-service --region=us-central1 --project=PROJECT_ID \\&& gcloud run services delete my-parallel-run-service --region=us-west1 --project=PROJECT_ID\n```\n- Delete the delivery pipeline, multi-target, child targets, release, and rollouts:```\ngcloud deploy delete --file=clouddeploy.yaml --force --region=us-central1 --project=PROJECT_ID\n```\n- Delete the Cloud Storage buckets that Cloud Deploy created.One ends with `_clouddeploy` , and the other is `[region].deploy-artifacts.[project].appspot.com` . [Open the Cloud Storage browser page](https://console.cloud.google.com/storage/browser) \nThat's it, you completed this quickstart!## What's next\n- [Read more](/deploy/docs/parallel) about how to deploy to multiple targets at the same time.\n- [Learn more about Cloud Deploy](/deploy/docs/overview) .\n- [Learn the basics of deploying applications](/deploy/docs/deploying-application) .\n- [Try out the Cloud Deploy walkthrough](https://shell.cloud.google.com/?show=ide%2Cterminal&walkthrough_id=deploy--cloud-deploy-e2e-gke) .\n- Learn how to [manage your manifests](/deploy/docs/skaffold) .\n- [Learn how to combine Google Cloud CI/CD tools to develop and deliversoftware effectively to GKE](https://cloud.google.com/architecture/app-development-and-delivery-with-cloud-code-gcb-cd-and-gke) .", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Deploy manually.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Deploy manually", "url": "https://cloud.google.com/deploy/docs/deploy-manually", "abstract": "# Cloud Deploy - Deploy manually\nThis page describes how to manually deploy your application to a specific target.\nDuring normal use, Cloud Deploy deploys your application into each target in the [progression](/deploy/docs/terminology#progression) , in sequence. But you can also manually deploy your application to any defined target.\nYou can manually deploy a new or an existing release.\n", "content": "## Manually deploy an existing release\nIf a release is already created, you can simply promote it to the intended target:\n```\ngcloud deploy releases promote --release=RELEASE_NAME \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--delivery-pipeline=PIPELINE_NAME \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--to-target=TARGET_NAME \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--region=REGION\n```\nWhere:\n- is the name of the release which you're manually promoting to the intended target.\n- is the name of the delivery pipeline that describes the automated deployment progression you're overriding.\n- is the name of the target you're manually deploying to.\n- is the name of the region in which the release was created, for example `us-central1` . This is required.## Manually deploy a new release\nBy default, when you create a release Cloud Deploy automatically deploys it to the first target in the promotion sequence. But you can specify a target other than the first one.\nAs with the default first target in the progression, Cloud Deploy automatically creates the `rollout` for the specified target and deploys the release there.\nTo manually deploy a new release, run the following command:\n```\ngcloud deploy releases create \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--release=RELEASE_NAME \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--delivery-pipeline=PIPELINE_NAME \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--to-target=TARGET_NAME \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--region=REGION\n```\nWhere:\n- is the name of the release which you're manually promoting to the intended target.\n- is the name of the delivery pipeline that describes the automated deployment progression you're overriding.\n- is the name of the target you're manually deploying to.\n- is the name of the region in which to create the release, for example `us-central1` . This is required.## Effect of manual deployment on the progression\nWhen you manually deploy to a specific target and then promote the release without specifying a target, Cloud Deploy promotes it to the correct next target in the progression. This is because the service tracks the furthest target to which a release has been deployed. If the release is already in the last target in the progression, Cloud Deploy returns a message indicating there is no further target to promote to.", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Deploy to GKE Enterprise user clusters.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Deploy to GKE Enterprise user clusters", "url": "https://cloud.google.com/deploy/docs/anthos-targets", "abstract": "# Cloud Deploy - Deploy to GKE Enterprise user clusters\nThis document describes how to deploy your applications to [GKE Enterprise clusters](/anthos/clusters/docs) . Support for GKE Enterprise targets enables deployment to AWS, Azure, and on-premises clusters.\nCloud Deploy lets you deploy your container-based workloads to any GKE Enterprise user cluster that you can access using [Connect](/anthos/multicluster-management/gateway/using) gateway.\n", "content": "## Before you begin\n- Have a GKE Enterprise user cluster that you will deploy to.This cluster can be one which you created as an GKE Enterprise user cluster, or you can [register an existing Kubernetes cluster](/anthos/multicluster-management/connect/registering-a-cluster) . Clusters which you create for GKE Enterprise automatically receive memberships. For existing clusters which you [register to a fleet](/anthos/multicluster-management/fleets) , you designate a membership name when registering. You will need this membership name for the target configuration.If you're using Google Cloud CLI version 407.0.0 or newer, you need to include the `--install-connect-agent` flag on the [gcloud container fleet memberships register command](https://cloud.google.com/sdk/gcloud/reference/container/fleet/memberships/register) , when you register a Google Kubernetes Engine cluster. The Connect agent is no longer installed by default.\n- Set up [Connect gateway](/anthos/multicluster-management/gateway/setup) to connect the registered cluster or clusters to Google Cloud.Be sure to set up the gateway using the same service account that will be used as the [Cloud Deploy execution service account](/deploy/docs/cloud-deploy-service-account#execution_service_account) . If you don't, then the execution service account won't have the necessary permissions to deploy to the GKE Enterprise cluster. **Note:** Enable [Workload Identity](/kubernetes-engine/docs/how-to/workload-identity) on the GKE clusters in order to set up Connect gateway.## Set up your Cloud Deploy to deploy to GKE Enterprise\n- Create your [target configuration](/deploy/docs/config-files) .The target can be configured in your delivery pipeline YAML, or can be in a separate file. Also, you can configure more than one target in the same file, but they must be in different `kind: Target` stanzas.\n- Grant the [execution service account](/deploy/docs/execution-environment) the [roles that it needs](/anthos/multicluster-management/gateway/setup#grant_roles_to_users) so that it can interact with connected clusters through the gateway.This grant is necessary whether you're using the default Cloud Deploy service account or a [custom service account](/deploy/docs/execution-environment#changing_from_the_default_to_custom_execution_service_account) .\n- [Set up RBAC](/anthos/multicluster-management/gateway/setup#configure_role-based_access_control_rbac_policies) for the [execution service account](/deploy/docs/execution-environment) on the Kubernetes cluster that underlies the Anthos cluster.\n- Optional: if the underlying cluster is not a GKE cluster, you might need to [configure an imagePullSecret](/artifact-registry/docs/access-control#pullsecrets) to allow your cluster to pull from Artifact Registry.\n- In the target definition, create an `anthosCluster` stanza to point to the GKE Enterprise cluster:The syntax for specifying an GKE Enterprise cluster is as follows:```\nanthosCluster:\u00a0membership: projects/[project_name]/locations/global/memberships/[membership_name]\n```This GKE Enterprise resource identifier uses the following elements:- [ `project_name` ] is the name of the Google Cloud project in which you're running this cluster.The cluster you're deploying to, including GKE Enterprise clusters, does need to be in the same project as your delivery pipeline.\n- [ `membership_name` ] is the name that you chose when [registering the cluster](/anthos/multicluster-management/connect/registering-a-cluster) to a fleet.\nFor `location` , all GKE Enterprise cluster memberships are `global` , so you don't need to change `/locations/global/` in this resource identifier.\nThe following is an example target configuration, pointing to an GKE Enterprise user cluster:\n```\n\u00a0 \u00a0 \u00a0 apiVersion: deploy.cloud.google.com/v1\u00a0 \u00a0 \u00a0 kind: Target\u00a0 \u00a0 \u00a0 metadata:\u00a0 \u00a0 \u00a0 \u00a0name: qsdev\u00a0 \u00a0 \u00a0 description: development cluster\u00a0 \u00a0 \u00a0 anthosCluster:\u00a0 \u00a0 \u00a0 \u00a0membership: projects/my-app/locations/global/memberships/my-app-dev-cluster\n```\n## What's next\n- Learn more about [configuring Cloud Deploy targets](/deploy/docs/config-files#target_definitions) \n- Learn about Cloud Deploy [execution environments](/deploy/docs/execution-environment) .\n- Learn more about [GKE Enterprise](/anthos/docs) \n- Learn more about [Connect gateway](/anthos/multicluster-management/gateway) .", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Deploy to a Google Kubernetes Engine cluster.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Deploy to a Google Kubernetes Engine cluster", "url": "https://cloud.google.com/deploy/docs/gke-targets", "abstract": "# Cloud Deploy - Deploy to a Google Kubernetes Engine cluster\nThis document describes how to deploy your applications to Google Kubernetes Engine clusters.\nCloud Deploy allows you to deploy your container-based workloads to any [Google Kubernetes Engine](/kubernetes-engine/docs/concepts/kubernetes-engine-overview) cluster. All Cloud Deploy features are supported when you deploy to GKE targets.\n", "content": "## Before you begin\n- Have one or more GKE clusters to deploy to.If you don't have any GKE clusters to deploy to, you can [create them](/kubernetes-engine/docs/concepts/types-of-clusters) .\n- [Have a Cloud Deploy delivery pipeline](/deploy/docs/create-pipeline-targets) .\n- Make sure your [execution service account](/deploy/docs/execution-environment) has the [roles and permissions](/deploy/docs/iam-roles-permissions) it needs.\nIn this `skaffold.yaml` file, the `deploy` stanza includes `kubectl` , which indicates that Skaffold is rendering for, and deploying to, Kubernetes (GKE). And the manifests you use for this application are listed under there.\n## Create your target configuration\nEach target can be configured in your delivery pipeline YAML, or can be in a separate file. Also, you can configure more than one target in the same file, but they must be in different `kind: Target` stanzas.\nIn the target definition, create a `gke` stanza to point to the GKE cluster:\nThe syntax for specifying a GKE cluster is as follows:\n```\ngke:\u00a0cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]\n```\nThis GKE resource identifier uses the following elements:\n- [ `project_name` ] is the name of the Google Cloud project in which you're running this cluster.The cluster you are deploying to does need to be in the same project as your delivery pipeline.\n- [ `location` ] is the region in which the cluster was created.\n- [ `cluster_name` ] is the name given to the cluster when it was created.You can find this name in the list of clusters for your project, in the Google Cloud console.\nThe following is an example target configuration, pointing to a GKE cluster:\n```\n\u00a0 \u00a0 \u00a0 apiVersion: deploy.cloud.google.com/v1\u00a0 \u00a0 \u00a0 kind: Target\u00a0 \u00a0 \u00a0 metadata:\u00a0 \u00a0 \u00a0 \u00a0name: dev\u00a0 \u00a0 \u00a0 description: development cluster\u00a0 \u00a0 \u00a0 gke:\u00a0 \u00a0 \u00a0 \u00a0cluster: projects/my-app/locations/us-central1/clusters/my-app-dev-cluster\n```\n## Create your Skaffold configuration\nThis section provides and explains an example of a simple Skaffold configuration to use when deploying to a GKE cluster.\nThe following is an `skaffold.yaml` file for deployment to a GKE cluster:\n```\napiVersion: skaffold/v4beta7kind: Configmetadata: \u00a0 name: gke-applicationmanifests:\u00a0 rawYaml:\u00a0 - deployment.yamldeploy:\u00a0 kubectl: {}\n```\n[Using Skaffold with Cloud Deploy](/deploy/docs/using-skaffold) describes in more detail how to use Skaffold with your delivery pipeline.\n## Prepare your Kubernetes manifests\nTo deploy your application to GKE, you provide Cloud Deploy with one or more Kubernetes manifests, which are [rendered](/deploy/docs/terminology#render) and then applied to the target cluster or clusters to deploy your application.\nIf you don't have those manifests, create them before you try to deploy using a Cloud Deploy delivery pipeline.\nYou can [use Kustomize or Helm](/deploy/docs/using-skaffold/managing-manifests) to help you create manifests. You can also use Kustomize or Helm if your manifests are templated and need to be rendered.\n## Putting it all together\nNow that you have your Kubernetes manifests, your `skaffold.yaml` configuration, and your Cloud Deploy target definitions, and you've [registered your targets](/deploy/docs/create-pipeline-targets#register_the_delivery_pipeline_and_targets) as Cloud Deploy resources, you can now [invoke your delivery pipeline](/deploy/docs/deploying-application#invoke_your_delivery_pipeline_to_create_a_release) to create a release and progress it through the progression of targets defined in the pipeline.\n## Deploy to a private cluster\nYou can deploy your application to a private GKE cluster, using either of two options:\n- [Using a Virtual Private Cloud network](#use-vpc) \n- [Using GKE Enterprise targets and connect gateway](#use-connect) \n### Use a Virtual Private Cloud network\nYou can configure a target to deploy to a [private GKE cluster](/kubernetes-engine/docs/concepts/private-cluster-concept) connected to a [Virtual Private Cloud](/vpc/docs) network:\n- [Create your private cluster](/kubernetes-engine/docs/how-to/private-clusters) A private cluster is a VPC-native cluster whose nodes and Pods are isolated by default from the public internet.If you plan to use the internal IP of the private cluster target, then set `internalIp` to `true` under `gke` in the [target configuration](/deploy/docs/config-files#privateip) .\n- In Cloud Build, [create a private worker pool](/build/docs/private-pools/use-in-private-network#deploying-to-clusters) that you can use to deploy to this private cluster.\n- [Configure the execution environment to use that private pool](#changing_from_the_default_pool_to_a_private_pool) .You must use this pool for `RENDER` . You can also use it for `DEPLOY` and for `VERIFY` . Here's an example that uses `RENDER` and `DEPLOY` :```\nexecutionConfigs:- usages:\u00a0 - RENDER\u00a0 - DEPLOY\u00a0 workerPool: \"projects/p123/locations/us-central1/workerPools/wp123\"\n```\nSee [Access private GKE clusters from Cloud Build private pools using Identity Service for GKE](/build/docs/private-pools/access-private-gke-clusters-identity-service) and [Access private GKE clusters with Cloud Build private pools](/build/docs/private-pools/accessing-private-gke-clusters-with-cloud-build-private-pools) for more information.\n### Project and permissions considerations\nYou can configure a target to use a private worker pool that can deploy to a private cluster. But there are some things to note if resources are in different projects.\n- When Cloud Deploy and the worker pool are in separate projects\nTo communicate with a private pool that has access to a VPC and that's in a different project from your target, the Cloud Deploy [service agent](/deploy/docs/cloud-deploy-service-account#service_agent) needs sufficient permissions to talk to that project.\nThe [execution service account](/deploy/docs/cloud-deploy-service-account#execution_service_account) also needs permissions to access the Cloud Storage bucket.\n- When the worker pool and the cluster are in separate projects\nIf the private GKE cluster is in a different project from the private worker pool, the [execution service account](/deploy/docs/cloud-deploy-service-account#execution_service_account) requires sufficient permissions to talk to the project the cluster is in.\n### Use GKE Enterprise targets and connect gateway\nYou can configure a target to deploy to a [private GKE cluster](/kubernetes-engine/docs/concepts/private-cluster-concept) using [Anthos targets](/deploy/docs/anthos-targets) and [connect gateway](/anthos/multicluster-management/gateway) .\nThis approach does not require that you use a Virtual Private Cloud or virtual private network connections.\n## What's next\n- Try the [quickstart: deploy an application to GKE](/deploy/docs/deploy-app-gke) \n- Invoke your delivery pipeline to [create a release](/deploy/docs/deploying-application#invoke_your_delivery_pipeline_to_create_a_release) \n- Learn more about [configuring Cloud Deploy targets](/deploy/docs/config-files#target_definitions) \n- Learn more about [using Skaffold with Cloud Deploy](/deploy/docs/using-skaffold) \n- Learn about Cloud Deploy [execution environments](/deploy/docs/execution-environment) .\n- Learn more about [GKE](/kubernetes-engine/docs)", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Deploy to custom target types.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Deploy to custom target types", "url": "https://cloud.google.com/deploy/docs/deploy-to-custom-targets", "abstract": "# Cloud Deploy - Deploy to custom target types\n**    Preview     ** This product is subject to the \"Pre-GA Offerings Terms\" in the General Service Terms section   of the [Service Specific Terms](/terms/service-terms#1) .     Pre-GA products are available \"as is\" and might have limited support.    For more information, see the [launch stage descriptions](/products#product-launch-stages) .\nIn addition to deploying to any of the supported target types, (Google Kubernetes Engine, Cloud Run GKE Enterprise), you can use Cloud Deploy to deploy to custom targets.\nA custom target is a Cloud Deploy target that deploys to a runtime or an output that is not one of the standard, supported target types.\nThe article [About custom targets](/deploy/docs/custom-targets) describes custom targets and how you can use them in a Cloud Deploy delivery pipeline.\n", "content": "## What's next\n- [Learn more about custom targets and how they work](/deploy/docs/custom-targets) .\n- [Learn how to define custom target types and use them in your delivery pipeline](/deploy/docs/create-custom-target) .\n- [Learn how to create delivery pipelines and targets](/deploy/docs/create-pipeline-targets) .\n- [Try a Cloud Deploy quickstart](/deploy/docs/deploy/docs/quickstarts) .", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Deploy to multiple targets at the same time.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Deploy to multiple targets at the same time", "url": "https://cloud.google.com/deploy/docs/parallel", "abstract": "# Cloud Deploy - Deploy to multiple targets at the same time\nUsing Cloud Deploy, you can deploy to a target that's configured to represent multiple targets, and your application is deployed to those targets in parallel (concurrently). The target you identify as a stage in your pipeline is called a [multi-target](/deploy/docs/terminology#multi-target) , and the targets that multi-target comprises are called [child targets](/deploy/docs/terminology#child-target) .\nYou can use parallel deployment with any target type that Cloud Deploy supports, including Google Kubernetes Engine, Cloud Run, and GKE Enterprise.\n#", "content": "## Why parallel deployment\nYou can use parallel deployment, for example, to deploy your application to multiple production targets. In this case, you don't need to deploy to each target in succession, because there's no progression (for example, from dev to staging to production).\nAnd this parallel deployment can be a part of a normal delivery pipeline progression: `dev -> staging -> prod [prod1, prod2, prod3, prod4, ...]` .\n**Note:** you can use parallel deployment for any stage in your delivery pipeline.\n## Cloud Deploy resources used for parallel deployment\nParallel deployment uses the following Cloud Deploy specialized resources:\n- multi-targetsA multi-target is a target that is configured with the property `multiTarget` , at the top level of the target config YAML, and instead of referencing the runtime cluster or service, it references one or more other targets, using `multiTarget.targetIds` .\n- Child targetsA child target is any target referenced by a multi-target as `multiTarget.targetIds` . The child must also reference a supported target type (Google Kubernetes Engine, GKE Enterprise, or Cloud Run.\n- Controller rolloutsA controller rollout is a rollout that corresponds to the multi-target.See [Limitations](#limitations) for more information about what you can and can't do with a controller rollout.\n- [Child rollouts](/deploy/docs/terminology#child_rollout) See [Limitations](#limitations) for more information about what you can and can't do with a child rollout.## Set up parallel deployment\nSetting up parallel deployment consists of defining one multi-target and the number of child targets you need (up to the [limit](#limitations) ). Target definitions are the same as for all targets, except for the following:\n- Multi-targets include the`multiTarget`property.\n- Child targets do not include the`multiTarget`property, but are referenced from the multi-target using the`multiTarget.targetIds`property.\n- You can configure the multi-target for approval, but not the child targets, which cannot include`requireApproval:true`.\nMulti-targets and child targets can include custom [execution environment](/deploy/docs/execution-environment) configs. If a child target doesn't specify an execution environment, it inherits the one defined in the multi-target definition, or the default. See [Execution environments and parallel deployment](#execution_environments_and_parallel_deployment) for more details.\n### Configure the multi-target\nA multi-target is a single target identified as a stage in your delivery pipeline, but pointing to one or more child targets.\nThe multi-target configuration includes the `multiTarget` property. A multi-target cannot have the `gke` or `run` or `anthosCluster` properties. Configuration for a multi-target is the same regardless of which runtime you're deploying to.\nIn your delivery pipeline YAML or in a separate YAML file, create the basic target definition, including `multiTarget` :\n```\napiVersion: deploy.cloud.google.com/v1kind: Targetmetadata:\u00a0name: TARGET_NAMEdescription: TARGET_DESCRIPTIONmultiTarget:\u00a0targetIds: [ CHILD_TARGET1, CHILD_TARGET2, CHILD_TARGETn ]\n```\nIn this YAML...\n- is the name of this multi-target, which is used in the [delivery pipeline definition](/deploy/docs/config-files#stages) , `stages.targetId` property.\n- are the names of the child targets this multi-target deploys to. Each name corresponds to the `name` property in the child target definition.\nThe presence of the `multiTarget.targetIds` property makes this target a multi-target.\n### Configure the child targets\nFor each target [identified](#configure_the_multi-target) as a child in your multi-target configuration, configure another target, as a child target:\nIn your [delivery pipeline YAML](/deploy/docs/config-files) or in a separate YAML file, create the basic target definition:\n```\napiVersion: deploy.cloud.google.com/v1kind: Targetmetadata:\u00a0name: CHILD_TARGET1description: TARGET_DESCRIPTIONgke:\u00a0cluster: projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_NAME\n```\nIn this YAML...- is the name of this child target. The name corresponds to one member in the list of targets in the `multiTarget.targetIds` property in the [multi-target definition](#configure_the_multi-target) .\n- The value of the `gke.cluster` property is the resource name of the cluster this target refers to, including the project ID, the region, and the cluster name.\nThis target is configured the same as a standard GKE target. The only thing that makes this a child target is that its referenced by the `multiTarget.targetIds` property in the multi-target.\n```\napiVersion: deploy.cloud.google.com/v1kind: Targetmetadata:\u00a0name: CHILD_TARGET1description: TARGET_DESCRIPTIONrun:\u00a0location: projects/PROJECT_ID/locations/REGION\n```\nIn this YAML...- is the name of this child target. The name corresponds to one member in the list of targets in the `multiTarget.targetIds` property in the [multi-target definition](#configure_the_multi-target) .\n- The value of the `run.location` property is the resource name of the Cloud Run service this target refers to, including the project ID and the region.\nThis target is configured the same as a standard Cloud Run target. The only thing that makes this a child target is that its referenced by the `multiTarget.targetIds` property in the multi-target.\n```\napiVersion: deploy.cloud.google.com/v1kind: Targetmetadata:\u00a0name: CHILD_TARGET1description: TARGET_DESCRIPTIONanthosCluster:\u00a0membership: projects/PROJECT_ID/locations/global/memberships/MEMBERSHIP_NAME\n```\nIn this YAML...- is the name of this child target. The name corresponds to one member in the list of targets in the `multiTarget.targetIds` property in the [multi-target definition](#configure_the_multi-target) .\n- is the name that you chose when you [registered the GKE Enterprise user cluster](/anthos/multicluster-management/connect/registering-a-cluster) to a fleet.\nThis target is configured the same as a standard GKE Enterprise target. The only thing that makes this a child target is that its referenced by the `multiTarget.targetIds` property in the multi-target.\n### Create the release\nWith a multi-target and child targets configured, [create the delivery pipeline and target resources](/deploy/docs/create-pipeline-targets#register_the_delivery_pipeline_and_targets) , and then create a release, as normal.\nThe lifecycle of the delivery pipeline is the same as with any Cloud Deploy pipeline and targets, except that when it gets to the stage with the multi-target, Cloud Deploy creates a controller rollout for the multi-target and a child rollout to deploy the application to each child target.\nPub/Sub messages in response to Cloud Deploy operations distinguish between controller rollouts and child rollouts.\n## Limitations\n- A multi-target can have no more than 50 child targets.\n- All child targets of a single multi-target must have the same target runtime (all GKE, or all GKE Enterprise, for example).\n- Within a delivery pipeline, a child target can have only one parent multi-target.\n- A multi-target can't be childless, and it can't reference itself or another multi-target as child targets.\n- You can't use a child target more than once within a single delivery pipeline, but you can re-use them in different pipeline.\n- [Default pools](/deploy/docs/execution-environment#about_worker_pools) have concurrency limits, but private pools don't.When you deploy to a multi-target, all child rollouts are deployed at the same time, up to the Cloud Build concurrency limit. If you have more child targets than that limit, the deploy jobs for some targets won't run until others finish, which means that Cloud Deploy doesn't deploy to all child targets at the same time, in this case.Additionally, if the targets include [verify jobs](/deploy/docs/verify-deployment) , it's possible for one or more of those verify jobs to start before the application has been deployed to all child targets.If you need to be able to deploy concurrently to more targets than the limit specified in the [Cloud Build documentation](/build/quotas#quotas) , you have two options:- [Request an increase](/build/quotas#increasing_quota) of the number of concurrent builds you can run.\n- [Set up a private pool](/build/docs/private-pools/private-pools-overview) and [configure your targets to use that pool](/docs/execution-environment#changing_from_the_default_pool_to_a_private_pool) .\n## Execution environments and parallel deployment\nEach target can be configured to use a non-default execution environment.\n- If the multi-target has a non-default execution environment, all child targets using the default execution environment, inherit the non-default one from the multi-target\n- If the multi-target uses the default execution environment, any child target that is configured with a non-default execution environment uses that non-default one.\nThese rules make it easier to propagate execution environments to child targets from a multi-target, so you don't have to define or change the execution environment for each child target, while still allowing you to customize the execution environment for one or more child targets if you need to do so.\nSee [Using Google Cloud Deploy execution environments](/deploy/docs/execution-environment) for more information about execution environments in Cloud Deploy.\n## Roll back a parallel deployment\nIf you need to roll back a deployment from multiple, parallel targets, Roll back the multi-target, as described in [Roll back a target](/deploy/docs/roll-back) .\n## Approvals for parallel deployment\nAs with any targets, you can configure your parallel deployment to require [approvals](/deploy/docs/promote-release#manage_approvals_for_a_delivery_pipeline) . With parallel deployment, however, you can only configure approval on the multi-target. The approval or rejection affects all child targets together.\n## View parallel deployment in Google Cloud console\nYou can view details for your multi-target, child targets, the controller rollout, and child rollouts in Google Cloud console.\nWhen you view the list of targets for a given delivery pipeline, in the Delivery Pipeline Details, the multi-target is listed, but child targets aren't. When you view release details, however, you can see the controller rollout and the child rollouts. You can also see controller and child rollouts listed on the **Rollouts** tab on the Delivery Pipeline details page.\nIn the [release inspector](/deploy/docs/view-release) , you can view, and diff, rendered manifests for child rollouts.\n## Pass deploy parameters to targets\nYou can differentiate among child targets by including parameters in your manifest and values in your delivery pipeline definition. Those values can be [applied separately](/deploy/docs/parameters#add_to_pipeline_stage) to the separate manifests, based on label matching on the corresponding targets.\nFor example, you might want a different number of replicas for each child target. To do so, you would include the parameters and values in the delivery pipeline's [progression](/deploy/docs/terminology#progression) , along with labels on the child targets to match for each parameter-value pair.\nLearn more about [deploy parameters](https://cloud.google.com/deploy/docs/parameters) .\n## Use parallel deployment with a deployment strategy\nYou can deploy in parallel when you're using a [canary deployment strategy](/deploy/docs/deployment-strategies/canary) . See [Use parallel deployment with a canary deployment strategy](/deploy/docs/deployment-strategies/canary#parallel_canary) for more information.\n## What's next\n- Try the [quickstart: Deploy an app to multiple targets at the same time](/deploy/docs/deploy-app-parallel) .\n- Learn more about [using deploy parameters](/deploy/docs/parameters) .\n- See the [target configuration schema](/deploy/docs/config-files#target_definitions) .\n- Review the article [Cloud Deploy service architecture](/deploy/docs/architecture) .", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Deploy your application.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Deploy your application", "url": "https://cloud.google.com/deploy/docs/deploying-application", "abstract": "# Cloud Deploy - Deploy your application\nThis page describes how to use Cloud Deploy to get your application into your intended target runtime environments. Before you do this, you need to [create your delivery pipeline and targets](/deploy/docs/create-pipeline-targets) .\n", "content": "## Before you begin\nThis section describes the things you need to have in place before you can deploy your application using Cloud Deploy.\n- Make sure your [execution service account](/deploy/docs/cloud-deploy-service-account#execution_service_account) has the necessary [IAM roles and permissions](/deploy/docs/iam-roles-permissions) .\n- [Create your delivery pipeline and targets](/deploy/docs/create-pipeline-targets) .Cloud Deploy can deploy to Google Kubernetes Engine, Cloud Run, and GKE Enterprise clusters. [Target configuration](/deploy/docs/config-files#target_definitions) differs depending on which of these you're deploying to.\n- Have your container images and manifests.You need one or more container images to deploy and one or more Kubernetes manifests (to deploy to GKE) or service YAML files (to deploy to Cloud Run).You need a continuous integration pipeline, or some other process, to build and place your images. Your [CI tool](/deploy/docs/integrating-ci) can be Cloud Build, Jenkins, or anything that results in container images that you can provide to your Cloud Deploy delivery pipeline.\n- [Have a skaffold.yaml configuration file](/deploy/docs/using-skaffold/getting-started-skaffold) .Cloud Deploy calls [skaffold render](https://skaffold.dev/docs/workflows/ci-cd/#separation-of-rendering-and-deployment) to render the Kubernetes manifests using this file and [skaffold apply](https://skaffold.dev/docs/workflows/ci-cd/#separation-of-rendering-and-deployment) to deploy them into your target. To do this, Skaffold requires at least a minimal `skaffold.yaml` . You can get one in either of two ways:- Create your own.Note that the `skaffold.yaml` file must reference the namespace corresponding to a [supported Skaffold version](/deploy/docs/using-skaffold/select-skaffold#supported_versions) in the first line, as in this example:```\n`apiVersion: skaffold/v4beta7`\n```\n- Have it generated for you.If you don't already have a `skaffold.yaml` file, you can [have Cloud Deploy create one for you](/deploy/docs/using-skaffold/getting-started-skaffold#have_generate_your_skaffoldyaml) . This file is suitable for onboarding, learning, or demonstrating Cloud Deploy, and should not be used for production workloads.\nSee [Using Skaffold with Cloud Deploy](/deploy/docs/using-skaffold) for more details. Also, [Managing manifests in Cloud Deploy](/deploy/docs/using-skaffold/managing-manifests) has more details on using Skaffold and Cloud Deploy with manifest-management tools, such as Helm, Kustomize, and kpt.## Set up Cloud Deploy for the runtime environment of your choice\nCloud Deploy can deploy your application to any of the following runtime environments:\n- [GKE](/deploy/docs/gke-targets) \n- [GKE Enterprise](/deploy/docs/anthos-targets) \n- [Cloud Run](/deploy/docs/run-targets) ## Invoke your delivery pipeline to create a release\nAfter you've configured Cloud Deploy to deploy to your runtime, you can now submit your application to be deployed according to the delivery pipeline you created.\n- Run your regular continuous-integration (CI) process, creating the deployable artifact or artifacts.\n- Initiate the delivery pipeline by calling Cloud Deploy to create a release.Run the following command from the directory containing your Skaffold config:```\ngcloud deploy releases create RELEASE_NAME --delivery-pipeline=PIPELINE_NAME --region=REGION\n```Because this command creates a tar file of the entire contents of the directory, and any subdirectories, you might not want to run this command from your home or root directory. Either run the command from the directory containing your Skaffold config, or include the `--source=` option, described later.In this command...`` is a name to give to this release. The name must be unique among all releases for this delivery pipeline.You can specify dynamic release names by including `'$DATE'` or `'$TIME'` or both. For example, if you invoke this command at 3:07pm UTC, `'rel-$TIME'` resolves to `rel-1507` . `'$DATE'` and `'$TIME'` must be in single-quotes, and the time is UTC time on the machine where you invoke the command.`` is the name of the delivery pipeline that will manage deployment of this release through the progression of targets. This name must match the [name field in the pipeline definition](/deploy/docs/config-files#name) .`` is the name of the region in which you're creating the release, for example `us-central1` . This is required.\n**Note:** optionally, you can include `--source=` `` to specify the location of the `skaffold.yaml` file. The default is the current directory.\nThis command uploads a tar file containing your configs to a Cloud Storage bucket and creates the release. Cloud Deploy also automatically creates a rollout and deploys your image to the first target defined in the delivery pipeline.\nIn addition to the parameters shown with this command, you can include of the following options:\n- `--images=<name=path/name:$IMAGE_SHA>,<name=path/name:$IMAGE_SHA>`A collection of image name to image full-path replacements.\n- `--build-artifacts=<path/file>`A reference to a Skaffold build artifacts output file, which can be passed in to represent the image full path replacements.\nThese two options are mutually exclusive.\nYou can also include one of the following flags to have Cloud Deploy generate a `skaffold.yaml` file for you:\n- [--from-k8s-manifest=K8S_MANIFEST](/sdk/gcloud/reference/deploy/releases/create#--from-k8s-manifest) The generated Skaffold config is based on the Kubernetes manifest you pass this flag. Using this flag with either the `--skaffold-file` flag or the `--source` flag, generates an error. See [Generating your skaffold.yaml](/deploy/docs/using-skaffold/getting-started-skaffold#generating_your_skaffoldyaml) for more details.\n- [--from-run-manifest=RUN_MANIFEST](/sdk/gcloud/reference/deploy/releases/create#--from-run-manifest) The generated Skaffold config is based on the Cloud Run service YAML you pass this flag. Using this flag with either the `--skaffold-file` flag or the `--source` flag, generates an error. See [Generating your skaffold.yaml](/deploy/docs/using-skaffold/getting-started-skaffold#generating_your_skaffoldyaml) for more details.\nThese two options are mutually exclusive.\nYou can also include a `.gcloudignore` file if there are any files in the directory which you don't want included in the tar file.\n### Create a release from the Google Cloud console\nYou can use the Google Cloud console to create a release for a delivery pipeline. This is useful for trying out Cloud Deploy, but is not suitable for production workloads.\nThe following procedure assumes you have already created a delivery pipeline and one or more targets. (You can also use the Google Cloud console) to [create your delivery pipeline](/deploy/docs/create-pipeline-targets#create_pipeline_in_ui) .)\n- From the **Delivery pipeline details** page, for a specific delivery pipeline, click **Create release** .\n- In the **Choose a container** field, paste or type the path to the container image you want to deploy. You can also use the default container pre-populated in this field, for evaluation.You can also click **Select** to choose a container image from Artifact Registry or Container Registry.\n- Provide a unique name for this release, in the **Release name** field, or use the default name provided.\n- Provide a name for the rollout, in the **Rollout name** field, or use the default name provided.This name is used for the rollout to the first target, for this release. For subsequent targets, you can name the rollout in the **Promote** dialog or on the `gcloud deploy releases promote` command.\n- Optionally, include a description for this release, in the **Description** field.\n- Under **Deployment details** , enter a name for your GKE deployment or Cloud Run service, or use the default name provided.For GKE, Cloud Deploy generates the manifest for you. For Cloud Run, Cloud Deploy generates the service definition, which is used to create the service.\n- Click **Create** .\nCloud Deploy uses the generated manifest or Cloud Run service definition, and the generated `skaffold.yaml` , to create the release.\n### Change the deployment timeout\nFor deployments to GKE and GKE Enterprise target clusters, there are three separate timeouts that affect how long the system waits for Kubernetes to report a stable deployment:\n- Cloud Build has a timeout of 1 hour on operations that Cloud Build performs for Cloud Deploy.You can change this timeout in the [configuration for your execution environment](/deploy/docs/config-files#executionconfigs) .\n- [Skaffold](/deploy/docs/set-up-skaffold) has a [health-check timeout (deploy.statusCheckDeadlineSeconds)](https://skaffold.dev/docs/pipeline-stages/status-check/#configuring-timeout-for-status-check) , which is the amount of time, in seconds, to wait for deployments to stabilize.The default is 600 seconds (10 minutes). To use this timeout, [deploy.statusCheck](https://skaffold.dev/docs/references/yaml/#deploy-statusCheck) must be set to `true` . By default, it is. If `statusCheck` is `false` , there is no status check, the rollout is marked successful after `kubectl apply` finishes successfully.\n- For Kubernetes resources of `kind: Deployment` , there's [Deployment.spec.progressDeadlineSeconds](https://kubernetes.io/docs/concepts/workloads/controllers/_print/#progress-deadline-seconds) , which is the amount of time Kubernetes waits for the Deployment to report as stable.This timeout is applicable to `Deployment` resources only. Here's how these first two timeouts work together:- If `Deployment.spec.progressDeadlineSeconds` , in Kubernetes, is unset, then the Skaffold health-check timeout is the effective timeout, whether it's the default or is explicitly set.\n- If `Deployment.spec.progressDeadlineSeconds` , in Kubernetes, is set, then Skaffold ignores its own health-check timeout, and the Kubernetes progress deadline is the effective timeout. However, if the Kubernetes timeout is explicitly set to `600` (10 minutes), then Skaffold assumes that it's the default (unset) and ignores it, and the Skaffold timeout is used (if set).\n- If neither timeout is set, then the effective timeout is the Skaffold default of `600` (10 minutes).\nBesides `Deployment` s, other Kubernetes resources can have timeouts, which do not influence the stability timeout. If any of these are present, review them to ensure they are not in conflict with the stability timeout.If Skaffold (or Cloud Build) times out, the GKE deployment continues to run. Cloud Deploy shows a failure, but it can still succeed or fail on the GKE cluster.\nTo change your deployment stability timeout:\n- Ensure that [deploy.statusCheck](https://skaffold.dev/docs/references/yaml/#deploy-statusCheck) is set to `true` in `skaffold.yaml` .`true` is the default. When `true` , Skaffold waits for health checks to report a stable deployment, subject to the timeout value in the next step.\n- In [skaffold.yaml](/deploy/docs/set-up-skaffold) , set `statusCheckDeadlineSeconds` to the number of seconds you want to wait.```\ndeploy:\u00a0 ...\u00a0 statusCheck: true\u00a0 statusCheckDeadlineSeconds: 600\u00a0 ...\n```The default is `600` (10 minutes). Skaffold waits this amount of time for a stable deployment. If this time is exceeded before the deployment is stable, the deployment fails.\n- Optionally, you can add [tolerateFailuresUntilDeadline: true](https://skaffold.dev/docs/status-check/#configuring-failure-behavior-for-status-check) after `statusCheckDeadlineSeconds` .This setting tells Skaffold not to exit if a single deployment fails, but to tolerate failures until `statusCheckDeadlineSeconds` expires. This setting can help in situations where you have resources that might need more time (up to the status-check deadline) to reach a stable state.For example, if you're using Istio or Anthos Service Mesh, you might have a failed deployment with a message similar to this one:```\nerror iptables validation failed; workload is not ready for Istio.\nWhen using Istio CNI, this can occur if a pod is scheduled before the node is ready.\n```The setting works with Skaffold 2.0 or greater only.\n- In your Kubernetes manifest, for resources of `kind: Deployment` , set `Deployment.spec.progressDeadlineSeconds` to the same value as you set for `statusCheckDeadlineSeconds` .## What's next\n- Find out about [deploying to GKE](/deploy/docs/gke-targets) \n- Find out about [deploying to Cloud Run](/deploy/docs/run-targets) \n- Find out about [deploying to GKE Enterprise](/deploy/docs/anthos-targets) \n- Learn how to [create your delivery pipeline and targets](/deploy/docs/create-pipeline-targets) \n- Learn how to [promote a release](/deploy/docs/promote-release)", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Get Started with Skaffold in Cloud Deploy.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Get Started with Skaffold in Cloud Deploy", "url": "https://cloud.google.com/deploy/docs/using-skaffold/getting-started-skaffold", "abstract": "# Cloud Deploy - Get Started with Skaffold in Cloud Deploy\nThis document describes how to get started using [Skaffold](/skaffold) as part of Cloud Deploy, including the following:\n- Configuring Skaffold for use with a Cloud Deploy delivery pipeline\n- Using Skaffold and Cloud Deploy with third-party rendering tools, such as Helm and Kustomize\n- Optionally, using Skaffold for local development\n- Optionally, using Skaffold for continuous integration and continuous deployment (CI/CD)", "content": "## Why Skaffold?\nWant to know why Cloud Deploy uses Skaffold, and why you need to manage a Skaffold configuration? Read on.\n### I'm experienced with CI/CD, but I don't use Skaffold currently\nSkaffold is an open source command-line tool to improve productivity for developers. It orchestrates continuous development, continuous integration (CI), and continuous delivery (CD).\nSkaffold provides declarative, portable configuration, using a pluggable architecture, letting you use different tools for the render phase.\nWhen a release is created, Cloud Deploy calls Skaffold to render your manifests. At deploy time, Cloud Deploy calls Skaffold again to apply those manifests to deploy your application to each [target](/deploy/docs/terminology#target) in your [progression](/deploy/docs/terminology#progression) . After deployment, Skaffold performs health checks to monitor the target runtime for successful deployment.\n### Skaffold for continuous development\nWhen you use [Skaffold for continuous development](https://skaffold.dev/docs/workflows/dev/) , images are built, tested, and deployed to a cluster (or Minikube) as you change your code. [Cloud Code for VS Code](https://cloud.google.com/code/docs/vscode/running-an-application) and [Cloud Code for IntelliJ](https://cloud.google.com/code/docs/intellij/deploying-a-k8-app) IDE extensions integrate Skaffold into Visual Studio Code and JetBrains IDEs, for continuous development.\n### Skaffold for continuous delivery\nYou can also use [Skaffold for continuous delivery](https://skaffold.dev/docs/workflows/ci-cd/) , with build, deploy, render, and apply steps. Cloud Deploy uses Skaffold's [render and apply](https://skaffold.dev/docs/workflows/ci-cd/#separation-of-rendering-and-deployment) capabilities. To use Cloud Deploy, [you need at least a validskaffold.yaml configuration file](/deploy/docs/using-skaffold/getting-started-skaffold#whats_required_to_make_work) .\nThrough Skaffold, you can also integrate with third-party manifest-management tools, such as [Helm](https://helm.sh) , and [Kustomize](https://kustomize.io) . Using Skaffold in this way lets you use the features of those tools to render manifests. `kubectl` remains the for these manifests.\n### I'm new to deploying to Kubernetes\nWith Skaffold, you can configure a base set of manifests for all your deployments. You can then use Skaffold's rendering engine, through Cloud Deploy, to render, and then deploy, each deployment-specific manifest from one of those base manifests.\nRead more about [managing manifests](/deploy/docs/using-skaffold/managing-manifests) , including examples of using Skaffold and Cloud Deploy with common manifest-templating tools, such as Helm and Kustomize.\n## What's required to make Cloud Deploy work?\nTo use a basic Cloud Deploy delivery pipeline, the [skaffold.yaml](https://skaffold.dev/docs/references/yaml/) configuration file needs at least the following configuration:\n- The header information that all `skaffold.yaml` configurations need:```\napiVersion: skaffold/v4beta7kind: Config\n```\n- A `manifests` stanza, for GKE, GKE Enterprise, or Cloud Run listing all raw Kubernetes manifests (unless you're using a manifest-management tool, such as Helm or Kustomize).Here's an example using a raw Kubernetes manifest:```\nmanifests:\u00a0 rawYaml:\u00a0 - deployment.yaml\n```If you plan to use a renderer (like Helm or Kustomize) to render manifests, see [Add Helm support to your skaffold.yaml](#add_helm_support_to_your_skaffoldyaml) and [Add Kustomize support to your skaffold.yaml](#add_kustomize_support_to_your_skaffoldyaml) for guidance on how to configure Skaffold to use these tools.For Helm and Kustomize examples, see [Manage manifests](/deploy/docs/using-skaffold/managing-manifests) \n- A `deploy` stanza, with either `deploy.kubectl` , for deploying to GKE or to GKE Enterprise, or `deploy.cloudrun` for deploying to Cloud Run.For GKE and GKE Enterprise targets:```\ndeploy:\u00a0 kubectl: {}\n```The deploy stanza deploys the application manifests that were provided in the manifests stanza.For Cloud Run targets:```\ndeploy:\u00a0 cloudrun: {}\n```The deploy stanza deploys the application manifests provided in the manifests stanza.\nIf you're using [custom targets](/deploy/docs/custom-targets) , your `skaffold.yaml` must have the header ( `apiVersion` and `kind:` ), plus the [custom actions](/deploy/docs/create-custom-target#skaffold_define_action) that the custom target will use if the custom target type doesn't already reference a [remote Skaffold configuration](/deploy/docs/create-custom-target#remote_skaffold) .\n### Create a skaffold.yaml file\nCloud Deploy uses Skaffold for rendering and deploying your applications.\nFor each release, you need to provide at least a `skaffold.yaml` file that identifies the manifests to use. See the [previous section](/deploy/docs/using-skaffold/getting-started-skaffold#whats_required_to_make_work) for guidance about what needs to go in this file.\n**Note:** The Cloud Code plugins [for VS Code](/code/docs/vscode/install) and [for IntelliJ](https://cloud.google.com/code/docs/intellij/install#installing) help with schema validation, completion, and documentation when you're working in Skaffold configuration files.\n### Have Cloud Deploy generate your skaffold.yaml\nIf you don't have a `skaffold.yaml` file, but you do have a single Kubernetes manifest or a Cloud Run service definition file, Cloud Deploy can generate a `skaffold.yaml` file for you .\nThe generated Skaffold file will be available in the Cloud Storage source staging directory after the release is complete.\nThe following command includes the `--from-k8s-manifest` flag, passing the Kubernetes manifest. Cloud Deploy uses the information in the manifest to generate the `skaffold.yaml` , which is then used for the release.\n```\ngcloud deploy releases create \u00a0RELEASE_NAME --delivery-pipeline=PIPELINE_NAME --from-k8s-manifest=MANIFEST --region=REGION \n```\nTo generate the `skaffold.yaml` from a Cloud Run service YAML, use the same command, but with `--from-run-manifest` instead of `--from-k8s-manifest`\nUsing either of these flags with either the `--skaffold-file` flag or the `--source` flag generates an error.\n**Caution:** This generated `skaffold.yaml` file isn't suitable for production workloads.\n**Note:** Besides having Cloud Deploy generate the file for you, you can also have Skaffold generate it. See the [Skaffold documentation](https://skaffold.dev/docs/pipeline-stages/init/) for more information.\nThe generated `skaffold.yaml` is suitable for onboarding, learning, and demonstrating Cloud Deploy. After you're familiar with Cloud Deploy, and for production workloads, you might want a Skaffold configuration that differentiates among your targets (using [Skaffold profiles](#about_skaffold_profiles) ).\nWhen you use the generated `skaffold.yaml` file as a starting point to create your own differentiated Skaffold config, be sure you use the file in the rendering source archive, the rendered file. The rendering source is available to download from the **Artifacts** tab on the **Release details ** page.\n- This generated `skaffold.yaml` is included in the render source stored in a Cloud Storage bucket.You can view this file by downloading the `.tar.gz` file and extracting it.\n- The rendered `skaffold.yaml` is available in **Target artifacts** .In the **Target artifacts** section, click **View artifacts** .## Using Skaffold for local development\nOne of the strengths of Skaffold is that you can use it for [localdevelopment](https://skaffold.dev/docs/workflows/dev/) , and for CI/CD. In `dev` mode, Skaffold watches your source files, and when it detects a change, Skaffold rebuilds the images, retests, and redeploys the containers to a minikube cluster (for example) on your local machine.\nWhen using Skaffold in this way, you can use the same commands locally as for remote deployment.\nIf you use Skaffold for local development, you can define separate Skaffold profiles for your targets, and a default deploy stanza for local development.\nWhen you stop `dev` mode, Skaffold cleans up deployed artifacts from the cluster.\n## Using Skaffold for CI/CD\nBesides using Skaffold for continuous local build and deploy, you can use Skaffold for CI/CD. Cloud Deploy uses the CI/CD features in Skaffold to render and apply your manifests and deploy your application to your defined targets, given container images built using a CI tool like [Cloud Build](/build) and an image registry like [Artifact Registry](/artifact-registry) .\n### Render, deploy, and apply\nSkaffold separates the manifest rendering process from deployment. Cloud Deploy calls [skaffold render](https://skaffold.dev/docs/references/cli/#skaffold-render) , to render the manifests, and [skaffold apply](https://skaffold.dev/docs/references/cli/#skaffold-apply) to apply them to the [target](/deploy/docs/terminology#target) .\nThis separation between render and apply lets you capture the full declarative state of your application in configuration, so that it can be applied safely and repeatably (for example, for rollbacks). This technique also makes approvals easier. Because manifests are rendered for all targets before the first rollout, you can see the rendered YAML that will be applied to each target.\nCloud Deploy doesn't support using other deployers to deploy your application. You can, however, use tools like [Helm](https://helm.sh/) or [Kustomize](https://kustomize.io/) for rendering.\nTo learn more about how Cloud Deploy deploys using `kubectl` as the deployer, see [Cloud Deploy Service architecture](/deploy/docs/architecture#how_they_fit_together_to_deliver_your_release) .\n### About Skaffold profiles\nYou can create separate Skaffold [profiles](https://skaffold.dev/docs/environment/profiles/) \u2014identified in `skaffold.yaml` , in a `profiles:` stanza.\nWhen using Skaffold profiles with Cloud Deploy, you might create separate profiles for all, or some, of your targets. For example, different profiles for `dev` , `staging` , and `prod` .\nProfiles aren't necessary in order to use Skaffold in Cloud Deploy, but are useful for defining manifest customizations among your targets, for example using different Kustomize `kustomization.yaml` files per target.\n### Add Kustomize support to your skaffold.yaml\nIntegrating your Kustomize configuration with your Cloud Deploy/Skaffold configuration consists of the following:\n- Include a `kustomization.yaml` file among your configuration files.You can store your configuration files in a local directory or in a Cloud Storage bucket.\n- In your `skaffold.yaml` file, create a `deploy` stanza for each profile.You can also have a `deploy` stanza outside of any defined profiles, if you're not using profiles or for a default deploy configuration not tied to a profile.The following is an example Skaffold config that shows `deploy` stanzas per profile, and uses a fictional sample app called `my-app` :```\napiVersion: skaffold/v4beta7kind: Configbuild:\u00a0 artifacts:\u00a0 \u00a0 - image: my-app-web-profiles\u00a0 \u00a0 \u00a0 context: my-app-web-profiles\u00a0 \u00a0 - image: my-app-application-profiles\u00a0 \u00a0 \u00a0 context: my-app-application-profiles\u00a0 googleCloudBuild:\u00a0 \u00a0 projectId: ${PROJECT_ID}profiles:- name: local\u00a0 manifests:\u00a0 \u00a0 kustomize:\u00a0 \u00a0 \u00a0 paths:\u00a0 \u00a0 \u00a0 \u00a0 - my-app-application-profiles/kubernetes/local- name: test\u00a0 manifests:\u00a0 \u00a0 kustomize:\u00a0 \u00a0 \u00a0 paths:\u00a0 \u00a0 \u00a0 \u00a0 - my-app-application-profiles/kubernetes/test- name: staging\u00a0 manifests:\u00a0 \u00a0 kustomize:\u00a0 \u00a0 \u00a0 paths:\u00a0 \u00a0 \u00a0 \u00a0 - my-app-application-profiles/kubernetes/staging- name: prod\u00a0 manifests:\u00a0 \u00a0 kustomize:\u00a0 \u00a0 \u00a0 paths:\u00a0 \u00a0 \u00a0 \u00a0 - my-app-application-profiles/kubernetes/proddeploy:\u00a0 kubectl: {}\n```The Skaffold configuration shown here has separate profiles for `test` , `staging` , and `prod` targets. It also shows a profile for local development. In each profile, there's a `deploy.kustomize` stanza with a path that points to the location of the kustomization to use for that target.\n**Note:** although this configuration is in a `deploy` stanza, Skaffold uses it to the manifest for the intended target, not to deploy.\n### Add Helm support to your skaffold.yaml\nYou can use Helm to render your manifests. Cloud Deploy doesn't use Helm to deploy your applications, and supports only `kubectl` as a deployer.\nTo use Helm, you need your Helm chart or charts, stored in any location you can reference from within your `skaffold.yaml` . This location can be in a file system, a repository, possibly along with your `skaffold.yaml` , or an Open Container Initiative (OCI) repository.\nTo use a Helm chart, you add a `helm` stanza to your [skaffold.yaml](https://skaffold.dev/docs/references/yaml/) file.\n**Note:** You can also use Helm with Skaffold profiles.\n```\napiVersion: skaffold/v4beta7kind: Configbuild:\u00a0 artifacts:\u00a0 - image: skaffold-helm-imagemanifests:\u00a0 helm:\u00a0 \u00a0 releases:\u00a0 \u00a0 - name: skaffold-helm-image\u00a0 \u00a0 \u00a0 chartPath: chartsdeploy:\u00a0 kubectl: {}\n```\nThe [skaffold.yaml reference](https://skaffold.dev/docs/references/yaml/#deploy-helm) shows what's required in this `helm` stanza.\n## Unsupported Skaffold features\nThe following features of Skaffold can't be used in Cloud Deploy:\n- [Lifecycle hooks](https://skaffold.dev/docs/pipeline-stages/lifecycle-hooks/) \n- [Dynamic Skaffold modules](https://skaffold.dev/docs/design/config/#multiple-configuration-support) Using `--module=` to select specific modules for `build` , `render` , `apply` , and so on, is not supported. Static modules are supported.\n- In Helm, the ability to [create a namespace](https://helm.sh/docs/faq/changes_since_helm2/#automatically-creating-namespaces) if one doesn't exist.## What's next\n- Visit the [Skaffold site](https://skaffold.dev) to find out about how it works and what it can do for you.\n- [Practice](https://shell.cloud.google.com/?show=ide%2Cterminal&walkthrough_id=deploy--cloud-deploy-profiles-gke) using Cloud Deploy with Kustomize and Skaffold profiles.\n- [Learn how](/deploy/docs/using-skaffold/select-skaffold) Cloud Deploy selects the Skaffold version to use, when the Skaffold version changes, and how to determine which version is in use.\n- [Learn how](/deploy/docs/using-skaffold/managing-manifests) to use Skaffold profiles with advanced manifest-management tools like Helm, Kustomize, and kpt.", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - IAM roles and permissions.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - IAM roles and permissions", "url": "https://cloud.google.com/deploy/docs/iam-roles-permissions", "abstract": "# Cloud Deploy - IAM roles and permissions\nThis page describes Cloud Deploy service accounts, roles, and permissions.\nAccess in Cloud Deploy is controlled using [Identity and Access Management (IAM)](/iam) . IAM enables you to create and manage permissions for Google Cloud resources. Cloud Deploy provides a specific set of [predefined IAM roles](/iam/docs/understanding-roles#role_types) where each role contains a set of permissions. You can use these roles to give more fine-grained access to specific Google Cloud resources and prevent unwanted access to other resources. IAM lets you adopt the [security principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege) , so you grant only the necessary access to your resources.\nSee [Using IAM to restrict Cloud Deploy access](/deploy/docs/securing/iam) to learn about advanced access-control security features.\n", "content": "## Service accounts in Cloud Deploy\nBy default, Cloud Deploy runs using the default Compute Engine service account. That service account has sufficient permissions to render manifests and deploy to your targets.\n**Note:** make sure the service account you're using has the `logging.logEntries.create` permission. The [default service account](/deploy/docs/cloud-deploy-service-account#execution_service_account) has this permission by default, but some organizations remove it, by policy. If it's missing, your Cloud Build jobs won't have any logs attached to them.\n[Find out more](/deploy/docs/cloud-deploy-service-account) about how Cloud Deploy uses service accounts.\n## Predefined Cloud Deploy roles\nWith IAM, every API method in Cloud Deploy API requires that the identity making the API request has the appropriate permissions to use the resource. Permissions are granted by setting policies that grant roles to a principal (user, group, or service account) of your project. You can grant multiple roles to a principal on the same resource.\nThe IAM documentation includes a [searchable reference](/iam/docs/understanding-roles#predefined) of all predefined roles.\nThe following table lists the Cloud Deploy IAM roles and the permissions that they include:\n| Role         | Description                                                | Permissions                                                                                                                                                                                                                                |\n|:----------------------------------------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| roles/clouddeploy.viewer    | Can view Cloud Deploy resources.                                           | clouddeploy.*.get clouddeploy.*.list                                                                                                                                                                                                                         |\n| roles/clouddeploy.admin     | Full control of Cloud Deploy resources.                                         | clouddeploy.*                                                                                                                                                                                                                               |\n| roles/clouddeploy.customTargetTypeAdmin | Full control of Cloud Deploy custom target types.                                       | clouddeploy.customTargetType.*                                                                                                                                                                                                                           |\n| roles/clouddeploy.developer    | Can create, retrieve, update, and delete Cloud Deploy delivery pipeline resources.                              | clouddeploy.deliveryPipelines.get clouddeploy.deliveryPipelines.list clouddeploy.deliveryPipelines.create clouddeploy.deliveryPipelines.delete clouddeploy.deliveryPipelines.update clouddeploy.deliveryPipelines.getIamPolicy clouddeploy.releases.* clouddeploy.rollouts.get clouddeploy.rollouts.list clouddeploy.operations.* clouddeploy.jobRuns.get clouddeploy.jobRuns.list clouddeploy.automations.get clouddeploy.automations.list clouddeploy.automationRuns.get clouddeploy.automationRuns.list                                                                                                        |\n| roles/clouddeploy.operator    | Can create, retrieve, update, and delete Cloud Deploy delivery pipeline and target resources. Can create and retrieve release, rollout, and job run resources. Can retrieve custom target type resources. | clouddeploy.customTargetType.get clouddeploy.customTargetType.list clouddeploy.customTargetType.getIamPolicy clouddeploy.deliveryPipelines.get clouddeploy.deliveryPipelines.list clouddeploy.deliveryPipelines.create clouddeploy.deliveryPipelines.delete clouddeploy.deliveryPipelines.update clouddeploy.deliveryPipelines.getIamPolicy clouddeploy.releases.* clouddeploy.targets.get clouddeploy.targets.list clouddeploy.targets.create clouddeploy.targets.delete clouddeploy.targets.update clouddeploy.targets.getIamPolicy clouddeploy.rollouts.advance clouddeploy.rollouts.cancel clouddeploy.rollouts.create clouddeploy.rollouts.get clouddeploy.rollouts.ignoreJob clouddeploy.rollouts.list clouddeploy.rollouts.retryJob clouddeploy.rollouts.rollback clouddeploy.operations.* clouddeploy.jobRuns.get clouddeploy.jobRuns.list clouddeploy.jobRuns.terminate clouddeploy.automations.* clouddeploy.automationRuns.* |\n| roles/clouddeploy.approver    | Can view and approve Cloud Deploy rollout resources only.                                     | clouddeploy.rollouts.get clouddeploy.rollouts.list clouddeploy.rollouts.approve clouddeploy.operations.* clouddeploy.jobRuns.get clouddeploy.jobRuns.list                                                                                                                                                                                            |\n| roles/clouddeploy.jobRunner    | Can execute Cloud Deploy work without permission to deploy to a target.                                 | logging.logEntries.create storage.objects.create storage.objects.list storage.objects.get                                                                                                                                                                                                            |\n| roles/clouddeploy.releaser    | Can create and retrieve releases and rollouts                                        | clouddeploy.customTargetType.get clouddeploy.deliveryPipelines.get clouddeploy.targets.get clouddeploy.releases.create clouddeploy.releases.get clouddeploy.releases.list clouddeploy.rollouts.advance clouddeploy.rollouts.cancel clouddeploy.rollouts.create clouddeploy.rollouts.get clouddeploy.rollouts.list clouddeploy.rollouts.rollback clouddeploy.jobRuns.get clouddeploy.jobRuns.list                                                                                                                                  |\n**Note:** If an [alternate service account](/deploy/docs/execution-environment#changing_from_the_default_to_custom_execution_service_account) is specified on the target, users with the `roles/clouddeploy.admin` , `.developer` , and `.operator` roles must also have the `iam.serviceAccounts.actAs` permission for the service accounts specified in a rollout target.\nIn addition to the Cloud Deploy predefined roles, the [basic](/iam/docs/understanding-roles#basic) Viewer, Editor, and Owner roles also include permissions related to Cloud Deploy. However, we recommend that you grant predefined roles where possible to comply with the [security principle of least privilege](/iam/docs/using-iam-securely#least_privilege) .\n## Permissions\nThe following table lists the permissions that the caller must have to call each method:\n| API Method       | Required permission      | Description                                  |\n|:-----------------------------------|:-------------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------|\n| automations.create()    | clouddeploy.automations.create    | Create a new automation resource.                            |\n| automations.delete()    | clouddeploy.automations.delete    | Delete an existing automation resource.                           |\n| automations.get()     | clouddeploy.automations.get    | Retrieve details for an individual automation resource.                       |\n| automations.list()     | clouddeploy.automations.list    | List automation resources and their metadata.                         |\n| automations.update()    | clouddeploy.automations.update    | Update an existing automation resource.                           |\n| automationRuns.cancel()   | clouddeploy.automationRuns.cancel   | Cancel a running automation.                              |\n| automationRuns.get()    | clouddeploy.automationRuns.get    | Retrieve details for an individual automation run.                        |\n| automationRuns.list()    | clouddeploy.automationRuns.list   | List automation runs and their metadata.                           |\n| customTargetTypes.create()   | clouddeploy.customTargetType.create  | Create a custom target type resource.                           |\n| customTargetTypes.delete()   | clouddeploy.customTargetType.delete  | Delete a custom target type resource.                           |\n| customTargetTypes.get()   | clouddeploy.customTargetType.get   | Retrieve details for a custom target type.                          |\n| customTargetTypes.getIamPolicy() | clouddeploy.customTargetType.getIamPolicy | Get the IAM policy for a custom target type resource.                       |\n| customTargetTypes.list()   | clouddeploy.customTargetType.list   | List available custom target types and their metadata.                       |\n| customTargetTypes.patch()   | clouddeploy.customTargetType.patch   | Update an existing custom target type.                           |\n| customTargetTypes.setIamPolicy() | clouddeploy.customTargetType.setIamPolicy | Set the IAM policy for a custom target type resource.                       |\n| deliveryPipelines.create()   | clouddeploy.deliveryPipelines.create  | Create a new delivery pipeline resource.                           |\n| deliveryPipelines.delete()   | clouddeploy.deliveryPipelines.delete  | Delete an existing delivery pipeline resource.                         |\n| deliveryPipelines.get()   | clouddeploy.deliveryPipelines.get   | Retrieve details for an individual delivery pipeline.                       |\n| deliveryPipelines.getIamPolicy() | clouddeploy.deliveryPipelines.getIamPolicy | Get the IAM policy for a delivery pipeline resource.                        |\n| deliveryPipelines.list()   | clouddeploy.deliveryPipelines.list   | List delivery pipelines and their metadata.                          |\n| deliveryPipelines.rollbackTarget() | clouddeploy.rollouts.rollback    | Rolls back a target.                                |\n| deliveryPipelines.setIamPolicy() | clouddeploy.deliveryPipelines.setIamPolicy | Set the IAM policy for a delivery pipeline resource.                        |\n| deliveryPipelines.update()   | clouddeploy.deliveryPipelines.update  | Update an existing delivery pipeline resource.                         |\n| jobRuns.get()      | clouddeploy.jobRuns.get     | Retrieve a JobRuns resource.                              |\n| jobRuns.list()      | clouddeploy.jobRuns.list     | List JobRuns resources and their metadata.                          |\n| jobRuns.terminate()    | clouddeploy.jobRuns.terminate    | Terminate an in-progress job run.                            |\n| operations.cancel()    | clouddeploy.operations.cancel    | Cancel a long-running operation.                             |\n| operation.delete()     | clouddeploy.operations.delete    | Delete a long-running operation.                             |\n| operations.get()     | clouddeploy.operations.get     | Get a specific long-running operation (for example, to return the status of a release's creation).            |\n| operations.list()     | clouddeploy.operations.list    | List long-running operations.                             |\n| releases.abandon()     | clouddeploy.releases.abandon    | Abandon a release and prevent further rollouts against the release.                    |\n| releases.create()     | clouddeploy.releases.create    | Create a new release resource. The caller also requires iam.serviceAccounts.actAs permission on the service account used to render the manifest. |\n| releases.get()      | clouddeploy.releases.get     | Retrieve details for individual release.                           |\n| releases.list()     | clouddeploy.releases.list     | List releases and metadata.                              |\n| releases.promote()     | clouddeploy.rollouts.create    | Promote the release to next target.                            |\n| rollouts.advance()     | clouddeploy.rollouts.advance    | Advance a rollout to the next phase.                            |\n| rollouts.approve()     | clouddeploy.rollouts.approve    | Approve or reject a rollout with approval state of required.                      |\n| rollouts.cancel()     | clouddeploy.rollouts.cancel    | Cancel a rollout.                                |\n| rollouts.create()     | clouddeploy.rollouts.create    | Create a new rollout resource. The caller also requires iam.serviceAccounts.actAs permission on the project or service account used to deploy. |\n| rollouts.get()      | clouddeploy.rollouts.get     | Retrieve details for individual rollout.                           |\n| rollouts.ignoreJob()    | clouddeploy.rollouts.ignoreJob    | Ignore a failed job.                                |\n| rollouts.list()     | clouddeploy.rollouts.list     | List rollouts and metadata.                              |\n| rollouts.retryJob()    | clouddeploy.rollouts.retryJob    | Retries a failed job.                               |\n| targets.create()     | clouddeploy.targets.create     | Create a new target resource.                             |\n| targets.delete()     | clouddeploy.targets.delete     | Delete an existing target resource.                            |\n| targets.get()      | clouddeploy.targets.get     | Retrieve details for an individual target.                          |\n| targets.getIamPolicy()    | clouddeploy.targets.getIamPolicy   | Gets the IAM policy for a target resource.                          |\n| targets.list()      | clouddeploy.targets.list     | List targets and their metadata.                             |\n| targets.setIamPolicy()    | clouddeploy.targets.setIamPolicy   | Sets the IAM policy for a target resource.                          |\n| targets.update()     | clouddeploy.targets.update     | Update an existing target resource.                            |\n## Using IAM to restrict actions on Cloud Deploy resources\nYou can secure your Cloud Deploy resources using IAM in the following ways:\n- IAM meta APIsUse [setIamPolicy](/sdk/gcloud/reference/projects/set-iam-policy) on Cloud Deploy resources to restrict actions on those resources.\n- Conditional IAMProgrammatically apply [access policies](/iam/docs/granting-changing-revoking-access#policy-overview) , including the [conditions](/iam/docs/conditions-overview) under which to grant or deny access.\nYou can use these policies and conditions to restrict the following actions on your Cloud Deploy resources:\n- Create a delivery pipeline or targetYou can grant this access to specific users or groups.\n- Update or delete a specific delivery pipelineYou can grant this access to specific users or groups.\n- Create a release for a specific delivery pipelineYou can grant this access to specific users or groups.\n- Update or delete a specific targetYou can grant this access to specific users or groups.\n- Create or approve a rollout or promote a releaseYou can grant this access to specific users or groups for a specific target or delivery pipeline.You can also set a condition that limits this access to within a specified time window.## What's next\n- Learn about [IAM](/iam/docs) .\n- Learn more about [using conditions in IAM](/deploy/docs/securing/iam#about_iam_conditions) \n- Find out more about [Cloud Deploy service accounts](/deploy/docs/cloud-deploy-service-account) .", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - IAM 角色和權限.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - IAM \u89d2\u8272\u548c\u6b0a\u9650", "url": "https://cloud.google.com/deploy/docs/iam-roles-permissions?hl=zh-cn", "abstract": "# Cloud Deploy - IAM \u89d2\u8272\u548c\u6b0a\u9650\n\u672c\u9801\u9762\u4ecb\u7d39\u4e86 Cloud Deploy \u670d\u52d9\u5e33\u865f\u3001\u89d2\u8272\u548c\u6b0a\u9650\u3002\nCloud Deploy \u4e2d\u7684\u8a2a\u554f\u6b0a\u9650\u901a\u904e [Identity and Access Management (IAM)](https://cloud.google.com/iam?hl=zh-cn) \u9032\u884c\u63a7\u5236\u3002\u901a\u904e IAM\uff0c\u60a8\u53ef\u4ee5\u5275\u5efa\u548c\u7ba1\u7406\u5c0d Google Cloud \u8cc7\u6e90\u7684\u6b0a\u9650\u3002Cloud Deploy \u63d0\u4f9b\u4e86\u4e00\u7d44\u7279\u5b9a\u7684 [\u9810\u5b9a\u7fa9 IAM \u89d2\u8272](https://cloud.google.com/iam/docs/understanding-roles?hl=zh-cn#role_types) \uff0c\u5176\u4e2d\u6bcf\u500b\u89d2\u8272\u90fd\u5305\u542b\u4e00\u7d44\u6b0a\u9650\u3002\u60a8\u53ef\u4ee5\u4f7f\u7528\u9019\u4e9b\u89d2\u8272\u4ee5\u66f4\u7cbe\u7d30\u7684\u65b9\u5f0f\u6388\u4e88\u5c0d\u7279\u5b9a Google Cloud \u8cc7\u6e90\u7684\u8a2a\u554f\u6b0a\u9650\uff0c\u4e26\u9632\u6b62\u5c0d\u5176\u4ed6\u8cc7\u6e90\u9032\u884c\u4e0d\u5fc5\u8981\u7684\u8a2a\u554f\u3002IAM \u5141\u8a31\u60a8\u63a1\u7528 [\u6700\u5c0f\u6b0a\u9650\u5b89\u5168\u539f\u5247](https://en.wikipedia.org/wiki/Principle_of_least_privilege) \uff0c\u60a8\u53ea\u9700\u6388\u4e88\u5c0d\u60a8\u8cc7\u6e90\u7684\u5fc5\u8981\u8a2a\u554f\u6b0a\u9650\u3002\n\u5982\u9700\u77ad\u89e3\u9ad8\u7d1a\u8a2a\u554f\u6b0a\u9650\u63a7\u5236\u5b89\u5168\u529f\u80fd\uff0c\u8acb\u53c3\u95b1 [\u4f7f\u7528 IAM \u9650\u5236 Cloud Deploy \u8a2a\u554f\u6b0a\u9650](https://cloud.google.com/deploy/docs/securing/iam?hl=zh-cn) \u3002\n", "content": "## Cloud Deploy \u4e2d\u7684\u670d\u52d9\u8cec\u865f\n\u9ed8\u8a8d\u60c5\u6cc1\u4e0b\uff0cCloud Deploy \u4f7f\u7528\u9ed8\u8a8d\u7684 Compute Engine \u670d\u52d9\u5e33\u865f\u904b\u884c\u3002\u8a72\u670d\u52d9\u8cec\u865f\u5177\u6709\u8db3\u5920\u7684\u6b0a\u9650\u4f86\u6e32\u67d3\u6e05\u55ae\u4e26\u5c07\u5176\u90e8\u7f72\u5230\u60a8\u7684\u76ee\u6a19\u3002\n**\u6ce8\u610f** \uff1a\u8acb\u78ba\u4fdd\u60a8\u4f7f\u7528\u7684\u670d\u52d9\u8cec\u865f\u5177\u6709 `logging.logEntries.create` \u6b0a\u9650\u3002\u9ed8\u8a8d\u60c5\u6cc1\u4e0b\uff0c [\u9ed8\u8a8d\u670d\u52d9\u8cec\u865f](https://cloud.google.com/deploy/docs/cloud-deploy-service-account?hl=zh-cn#execution_service_account) \u5177\u6709\u6b64\u6b0a\u9650\uff0c\u4f46\u67d0\u4e9b\u7d44\u7e54\u6703\u6839\u64da\u653f\u7b56\u79fb\u9664\u6b64\u6b0a\u9650\u3002\u5982\u679c\u8a72\u6b0a\u9650\u7f3a\u5931\uff0c\u60a8\u7684 Cloud Build \u4f5c\u696d\u5c07\u4e0d\u6703\u9644\u52a0\u4efb\u4f55\u65e5\u8a8c\u3002\n[\u8a73\u7d30\u77ad\u89e3](https://cloud.google.com/deploy/docs/cloud-deploy-service-account?hl=zh-cn) Cloud Deploy \u5982\u4f55\u4f7f\u7528\u670d\u52d9\u5e33\u865f\u3002\n## \u9810\u5b9a\u7fa9\u7684 Cloud Deploy \u89d2\u8272\n\u4f7f\u7528 IAM \u6642\uff0cCloud Deploy API \u4e2d\u7684\u6bcf\u500b API \u65b9\u6cd5\u90fd\u8981\u6c42\u767c\u51fa API \u8acb\u6c42\u7684\u8eab\u4efd\u5177\u6709\u4f7f\u7528\u76f8\u61c9\u8cc7\u6e90\u7684\u9069\u7576\u6b0a\u9650\u3002\u60a8\u53ef\u4ee5\u901a\u904e\u8a2d\u7f6e\u653f\u7b56\u7232\u9805\u76ee\u4e3b\u8cec\u865f\uff08\u7528\u6236\u3001\u7fa3\u7d44\u6216\u670d\u52d9\u8cec\u865f\uff09\u6388\u4e88\u89d2\u8272\uff0c\u9032\u800c\u6388\u4e88\u76f8\u61c9\u6b0a\u9650\u3002\u60a8\u53ef\u4ee5\u5c31\u540c\u4e00\u8cc7\u6e90\u6388\u4e88\u67d0\u500b\u4e3b\u8cec\u865f\u591a\u500b\u89d2\u8272\u3002\nIAM \u6587\u6a94\u5305\u542b\u6240\u6709\u9810\u5b9a\u7fa9\u89d2\u8272\u7684 [\u53ef\u641c\u7d22\u53c3\u8003\u6587\u6a94](https://cloud.google.com/iam/docs/understanding-roles?hl=zh-cn#predefined) \u3002\n\u4e0b\u8868\u5217\u51fa\u4e86 Cloud Deploy IAM \u89d2\u8272\u53ca\u5176\u5305\u542b\u7684\u6b0a\u9650\uff1a\n| \u89d2\u8272         | \u8aaa\u660e                                | \u6b0a\u9650                                                                                                                                                                                                                                 |\n|:----------------------------------------|:------------------------------------------------------------------------------------------------------------------------------------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| roles/clouddeploy.viewer    | \u53ef\u4ee5\u67e5\u770b Cloud Deploy \u8cc7\u6e90\u3002                          | clouddeploy.*.get clouddeploy.*.list                                                                                                                                                                                                                         |\n| roles/clouddeploy.admin     | \u64c1\u6709\u5c0d Cloud Deploy \u8cc7\u6e90\u7684\u5b8c\u5168\u63a7\u5236\u6b0a\u3002                        | clouddeploy.*                                                                                                                                                                                                                               |\n| roles/clouddeploy.customTargetTypeAdmin | \u64c1\u6709\u5c0d Cloud Deploy \u81ea\u5b9a\u7fa9\u76ee\u6a19\u985e\u578b\u7684\u5b8c\u5168\u63a7\u5236\u6b0a\u3002                     | clouddeploy.customTargetType.*                                                                                                                                                                                                                           |\n| roles/clouddeploy.developer    | \u53ef\u4ee5\u5275\u5efa\u3001\u6aa2\u7d22\u3001\u66f4\u65b0\u548c\u522a\u9664 Cloud Deploy \u4ea4\u4ed8\u6d41\u6c34\u7dda\u8cc7\u6e90\u3002                   | clouddeploy.deliveryPipelines.get clouddeploy.deliveryPipelines.list clouddeploy.deliveryPipelines.create clouddeploy.deliveryPipelines.delete clouddeploy.deliveryPipelines.update clouddeploy.deliveryPipelines.getIamPolicy clouddeploy.releases.* clouddeploy.rollouts.get clouddeploy.rollouts.list clouddeploy.operations.* clouddeploy.jobRuns.get clouddeploy.jobRuns.list clouddeploy.automations.get clouddeploy.automations.list clouddeploy.automationRuns.get clouddeploy.automationRuns.list                                                                                                        |\n| roles/clouddeploy.operator    | \u53ef\u4ee5\u5275\u5efa\u3001\u6aa2\u7d22\u3001\u66f4\u65b0\u548c\u522a\u9664Cloud Deploy \u4ea4\u4ed8\u6d41\u6c34\u7dda\u548c\u76ee\u6a19\u8cc7\u6e90\u3002 \u53ef\u4ee5\u5275\u5efa\u548c\u6aa2\u7d22\u7248\u672c\u3001\u767c\u4f48\u548c\u4f5c\u696d\u904b\u884c\u8cc7\u6e90\u3002 \u53ef\u4ee5\u6aa2\u7d22\u81ea\u5b9a\u7fa9\u76ee\u6a19\u985e\u578b\u8cc7\u6e90\u3002 | clouddeploy.customTargetType.get clouddeploy.customTargetType.list clouddeploy.customTargetType.getIamPolicy clouddeploy.deliveryPipelines.get clouddeploy.deliveryPipelines.list clouddeploy.deliveryPipelines.create clouddeploy.deliveryPipelines.delete clouddeploy.deliveryPipelines.update clouddeploy.deliveryPipelines.getIamPolicy clouddeploy.releases.* clouddeploy.targets.get clouddeploy.targets.list clouddeploy.targets.create clouddeploy.targets.delete clouddeploy.targets.update clouddeploy.targets.getIamPolicy clouddeploy.rollouts.advance clouddeploy.rollouts.cancel clouddeploy.rollouts.create clouddeploy.rollouts.get clouddeploy.rollouts.ignoreJob clouddeploy.rollouts.list clouddeploy.rollouts.retryJob clouddeploy.rollouts.rollback clouddeploy.operations.* clouddeploy.jobRuns.get clouddeploy.jobRuns.list clouddeploy.jobRuns.terminate clouddeploy.automations.* clouddeploy.automationRuns.* |\n| roles/clouddeploy.approver    | \u53ef\u4ee5\u67e5\u770b\u548c\u6279\u51c6 Cloud Deploy \u767c\u4f48\u8cc7\u6e90\u3002                        | clouddeploy.rollouts.get clouddeploy.rollouts.list clouddeploy.rollouts.approve clouddeploy.operations.* clouddeploy.jobRuns.get clouddeploy.jobRuns.list                                                                                                                                                                                            |\n| roles/clouddeploy.jobRunner    | \u7121\u9700\u90e8\u7f72\u5230\u76ee\u6a19\u7684\u6b0a\u9650\u3002                            | logging.logEntries.create storage.objects.create storage.objects.list storage.objects.get                                                                                                                                                                                                            |\n| roles/clouddeploy.releaser    | \u53ef\u4ee5\u5275\u5efa\u548c\u6aa2\u7d22\u7248\u672c\u548c\u767c\u4f48                           | clouddeploy.customTargetType.get clouddeploy.deliveryPipelines.get clouddeploy.targets.get clouddeploy.releases.create clouddeploy.releases.get clouddeploy.releases.list clouddeploy.rollouts.advance clouddeploy.rollouts.cancel clouddeploy.rollouts.create clouddeploy.rollouts.get clouddeploy.rollouts.list clouddeploy.rollouts.rollback clouddeploy.jobRuns.get clouddeploy.jobRuns.list                                                                                                                                  |\n**\u6ce8\u610f** \uff1a\u5982\u679c\u91dd\u5c0d\u76ee\u6a19\u6307\u5b9a\u4e86 [\u5099\u7528\u670d\u52d9\u8cec\u865f](https://cloud.google.com/deploy/docs/execution-environment?hl=zh-cn#changing_from_the_default_to_custom_execution_service_account) \uff0c\u5247\u64c1\u6709 `roles/clouddeploy.admin` \u3001 `.developer` \u548c `.operator` \u89d2\u8272\u7684\u7528\u6236\u9084\u5fc5\u9808\u5177\u6709\u767c\u4f48\u76ee\u6a19\u4e2d\u6307\u5b9a\u7684\u670d\u52d9\u8cec\u865f\u7684 `iam.serviceAccounts.actAs` \u6b0a\u9650\u3002\n\u9664\u4e86 Cloud Deploy \u9810\u5b9a\u7fa9\u89d2\u8272\u4e4b\u5916\uff0c [\u57fa\u672c](https://cloud.google.com/iam/docs/understanding-roles?hl=zh-cn#basic) Viewer\u3001Editor \u548c Owner \u89d2\u8272\u9084\u5305\u542b\u8207 Cloud Deploy \u76f8\u95dc\u7684\u6b0a\u9650\u3002\u4f46\u662f\uff0c\u6211\u5011\u5efa\u8b70\u60a8\u5118\u53ef\u80fd\u6388\u4e88\u9810\u5b9a\u7fa9\u89d2\u8272\uff0c\u4ee5\u4fbf\u7b26\u5408 [\u6700\u5c0f\u6b0a\u9650\u5b89\u5168\u539f\u5247](https://cloud.google.com/iam/docs/using-iam-securely?hl=zh-cn#least_privilege) \u3002\n## \u6b0a\u9650\n\u4e0b\u8868\u5217\u51fa\u4e86\u8abf\u7528\u8005\u8abf\u7528\u6bcf\u500b\u65b9\u6cd5\u5fc5\u9808\u5177\u5099\u7684\u6b0a\u9650\uff1a\n| API \u65b9\u6cd5       | \u6240\u9700\u6b0a\u9650         | \u8aaa\u660e                       |\n|:-----------------------------------|:-------------------------------------------|:----------------------------------------------------------------------------------------------|\n| automations.create()    | clouddeploy.automations.create    | \u5275\u5efa\u65b0\u7684\u81ea\u52d5\u5316\u8cc7\u6e90\u3002                   |\n| automations.delete()    | clouddeploy.automations.delete    | \u522a\u9664\u73fe\u6709\u7684\u81ea\u52d5\u5316\u64cd\u4f5c\u8cc7\u6e90\u3002                 |\n| automations.get()     | clouddeploy.automations.get    | \u6aa2\u7d22\u55ae\u500b\u81ea\u52d5\u5316\u8cc7\u6e90\u7684\u8a73\u7d30\u4fe1\u606f\u3002                |\n| automations.list()     | clouddeploy.automations.list    | \u5217\u51fa\u81ea\u52d5\u5316\u8cc7\u6e90\u53ca\u5176\u5143\u6578\u64da\u3002                 |\n| automations.update()    | clouddeploy.automations.update    | \u66f4\u65b0\u73fe\u6709\u81ea\u52d5\u5316\u8cc7\u6e90\u3002                   |\n| automationRuns.cancel()   | clouddeploy.automationRuns.cancel   | \u53d6\u6d88\u6b63\u5728\u904b\u884c\u7684\u81ea\u52d5\u5316\u64cd\u4f5c\u3002                 |\n| automationRuns.get()    | clouddeploy.automationRuns.get    | \u6aa2\u7d22\u55ae\u500b\u81ea\u52d5\u5316\u904b\u884c\u7684\u8a73\u7d30\u4fe1\u606f\u3002                |\n| automationRuns.list()    | clouddeploy.automationRuns.list   | \u5217\u51fa\u81ea\u52d5\u5316\u904b\u884c\u53ca\u5176\u5143\u6578\u64da\u3002                 |\n| customTargetTypes.create()   | clouddeploy.customTargetType.create  | \u5275\u5efa\u81ea\u5b9a\u7fa9\u76ee\u6a19\u985e\u578b\u8cc7\u6e90\u3002                  |\n| customTargetTypes.delete()   | clouddeploy.customTargetType.delete  | \u522a\u9664\u81ea\u5b9a\u7fa9\u76ee\u6a19\u985e\u578b\u8cc7\u6e90\u3002                  |\n| customTargetTypes.get()   | clouddeploy.customTargetType.get   | \u6aa2\u7d22\u81ea\u5b9a\u7fa9\u76ee\u6a19\u985e\u578b\u7684\u8a73\u7d30\u4fe1\u606f\u3002                |\n| customTargetTypes.getIamPolicy() | clouddeploy.customTargetType.getIamPolicy | \u7372\u53d6\u81ea\u5b9a\u7fa9\u76ee\u6a19\u985e\u578b\u8cc7\u6e90\u7684 IAM \u653f\u7b56\u3002               |\n| customTargetTypes.list()   | clouddeploy.customTargetType.list   | \u5217\u51fa\u53ef\u7528\u7684\u81ea\u5b9a\u7fa9\u76ee\u6a19\u985e\u578b\u53ca\u5176\u5143\u6578\u64da\u3002               |\n| customTargetTypes.patch()   | clouddeploy.customTargetType.patch   | \u66f4\u65b0\u73fe\u6709\u7684\u81ea\u5b9a\u7fa9\u76ee\u6a19\u985e\u578b\u3002                 |\n| customTargetTypes.setIamPolicy() | clouddeploy.customTargetType.setIamPolicy | \u7232\u81ea\u5b9a\u7fa9\u76ee\u6a19\u985e\u578b\u8cc7\u6e90\u8a2d\u7f6e IAM \u653f\u7b56\u3002               |\n| deliveryPipelines.create()   | clouddeploy.deliveryPipelines.create  | \u5275\u5efa\u65b0\u7684\u4ea4\u4ed8\u6d41\u6c34\u7dda\u8cc7\u6e90\u3002                  |\n| deliveryPipelines.delete()   | clouddeploy.deliveryPipelines.delete  | \u522a\u9664\u73fe\u6709\u7684\u4ea4\u4ed8\u6d41\u6c34\u7dda\u8cc7\u6e90\u3002                 |\n| deliveryPipelines.get()   | clouddeploy.deliveryPipelines.get   | \u6aa2\u7d22\u500b\u5225\u4ea4\u4ed8\u6d41\u6c34\u7dda\u7684\u8a73\u7d30\u4fe1\u606f\u3002                |\n| deliveryPipelines.getIamPolicy() | clouddeploy.deliveryPipelines.getIamPolicy | \u7372\u53d6\u4ea4\u4ed8\u6d41\u6c34\u7dda\u8cc7\u6e90\u7684 IAM \u653f\u7b56\u3002                |\n| deliveryPipelines.list()   | clouddeploy.deliveryPipelines.list   | \u5217\u51fa\u4ea4\u4ed8\u6d41\u6c34\u7dda\u53ca\u5176\u5143\u6578\u64da\u3002                 |\n| deliveryPipelines.rollbackTarget() | clouddeploy.rollouts.rollback    | \u56de\u6efe\u76ee\u6a19\u3002                     |\n| deliveryPipelines.setIamPolicy() | clouddeploy.deliveryPipelines.setIamPolicy | \u7232\u4ea4\u4ed8\u6d41\u6c34\u7dda\u8cc7\u6e90\u8a2d\u7f6e IAM \u653f\u7b56\u3002                |\n| deliveryPipelines.update()   | clouddeploy.deliveryPipelines.update  | \u66f4\u65b0\u73fe\u6709\u7684\u4ea4\u4ed8\u6d41\u6c34\u7dda\u8cc7\u6e90\u3002                 |\n| jobRuns.get()      | clouddeploy.jobRuns.get     | \u6aa2\u7d22 JobRuns \u8cc7\u6e90\u3002                   |\n| jobRuns.list()      | clouddeploy.jobRuns.list     | \u5217\u51fa JobRuns \u8cc7\u6e90\u53ca\u5176\u5143\u6578\u64da\u3002                 |\n| jobRuns.terminate()    | clouddeploy.jobRuns.terminate    | \u7d42\u6b62\u6b63\u5728\u9032\u884c\u7684\u4f5c\u696d\u904b\u884c\u3002                  |\n| operations.cancel()    | clouddeploy.operations.cancel    | \u53d6\u6d88\u9577\u6642\u9593\u904b\u884c\u7684\u64cd\u4f5c\u3002                  |\n| operation.delete()     | clouddeploy.operations.delete    | \u522a\u9664\u9577\u6642\u9593\u904b\u884c\u7684\u64cd\u4f5c\u3002                  |\n| operations.get()     | clouddeploy.operations.get     | \u7372\u53d6\u7279\u5b9a\u7684\u9577\u6642\u9593\u904b\u884c\u7684\u64cd\u4f5c\uff08\u4f8b\u5982\uff0c\u6062\u5fa9\u5230\u7248\u672c\u5275\u5efa\u7684\u72c0\u614b\uff09\u3002         |\n| operations.list()     | clouddeploy.operations.list    | \u5217\u51fa\u9577\u6642\u9593\u904b\u884c\u7684\u64cd\u4f5c\u3002                  |\n| releases.abandon()     | clouddeploy.releases.abandon    | \u68c4\u7528\u67d0\u500b\u7248\u672c\u4e26\u963b\u6b62\u5c0d\u8a72\u7248\u672c\u9032\u884c\u9032\u4e00\u6b65\u767c\u4f48\u3002             |\n| releases.create()     | clouddeploy.releases.create    | \u5275\u5efa\u65b0\u7684\u7248\u672c\u8cc7\u6e90\u3002\u8abf\u7528\u65b9\u9084\u9700\u8981\u5c0d\u7528\u65bc\u6e32\u67d3\u6e05\u55ae\u7684\u670d\u52d9\u8cec\u865f\u64c1\u6709 iam.serviceAccounts.actAs \u6b0a\u9650\u3002 |\n| releases.get()      | clouddeploy.releases.get     | \u6aa2\u7d22\u5404\u500b\u7248\u672c\u7684\u8a73\u7d30\u4fe1\u606f\u3002                  |\n| releases.list()     | clouddeploy.releases.list     | \u5217\u51fa\u7248\u672c\u548c\u5143\u6578\u64da\u3002                   |\n| releases.promote()     | clouddeploy.rollouts.create    | \u5c07\u7248\u672c\u63d0\u5347\u5230\u4e0b\u4e00\u500b\u76ee\u6a19\u3002                  |\n| rollouts.advance()     | clouddeploy.rollouts.advance    | \u5c07\u767c\u4f48\u4f5c\u696d\u63a8\u9032\u5230\u4e0b\u4e00\u968e\u6bb5\u3002                 |\n| rollouts.approve()     | clouddeploy.rollouts.approve    | \u6279\u51c6\u6216\u62d2\u7d55\u72c0\u614b\u7232 required \u7684\u767c\u4f48\u3002               |\n| rollouts.cancel()     | clouddeploy.rollouts.cancel    | \u53d6\u6d88\u767c\u4f48\u3002                     |\n| rollouts.create()     | clouddeploy.rollouts.create    | \u5275\u5efa\u65b0\u7684\u767c\u4f48\u8cc7\u6e90\u3002\u8abf\u7528\u65b9\u9084\u9700\u8981\u5c0d\u7528\u65bc\u90e8\u7f72\u7684\u9805\u76ee\u6216\u670d\u52d9\u8cec\u865f\u64c1\u6709 iam.serviceAccounts.actAs \u6b0a\u9650\u3002 |\n| rollouts.get()      | clouddeploy.rollouts.get     | \u6aa2\u7d22\u500b\u5225\u767c\u4f48\u7684\u8a73\u7d30\u4fe1\u606f\u3002                  |\n| rollouts.ignoreJob()    | clouddeploy.rollouts.ignoreJob    | \u5ffd\u7565\u5931\u6557\u7684\u4f5c\u696d\u3002                    |\n| rollouts.list()     | clouddeploy.rollouts.list     | \u5217\u51fa\u767c\u4f48\u548c\u5143\u6578\u64da\u3002                   |\n| rollouts.retryJob()    | clouddeploy.rollouts.retryJob    | \u91cd\u8a66\u5931\u6557\u7684\u4f5c\u696d\u3002                    |\n| targets.create()     | clouddeploy.targets.create     | \u5275\u5efa\u65b0\u7684\u76ee\u6a19\u8cc7\u6e90\u3002                   |\n| targets.delete()     | clouddeploy.targets.delete     | \u522a\u9664\u73fe\u6709\u7684\u76ee\u6a19\u8cc7\u6e90\u3002                   |\n| targets.get()      | clouddeploy.targets.get     | \u6aa2\u7d22\u500b\u5225\u76ee\u6a19\u7684\u8a73\u7d30\u4fe1\u606f\u3002                  |\n| targets.getIamPolicy()    | clouddeploy.targets.getIamPolicy   | \u7372\u53d6\u76ee\u6a19\u8cc7\u6e90\u7684 IAM \u653f\u7b56\u3002                  |\n| targets.list()      | clouddeploy.targets.list     | \u5217\u51fa\u76ee\u6a19\u53ca\u5176\u5143\u6578\u64da\u3002                   |\n| targets.setIamPolicy()    | clouddeploy.targets.setIamPolicy   | \u8a2d\u7f6e\u76ee\u6a19\u8cc7\u6e90\u7684 IAM \u653f\u7b56\u3002                  |\n| targets.update()     | clouddeploy.targets.update     | \u66f4\u65b0\u73fe\u6709\u7684\u76ee\u6a19\u8cc7\u6e90\u3002                   |\n## \u4f7f\u7528 IAM \u9650\u5236\u5c0d Cloud Deploy \u8cc7\u6e90\u7684\u64cd\u4f5c\n\u60a8\u53ef\u4ee5\u901a\u904e\u4ee5\u4e0b\u65b9\u5f0f\u4f7f\u7528 IAM \u4fdd\u8b77 Cloud Deploy \u8cc7\u6e90\uff1a\n- IAM \u5143 API\u5c0d Cloud Deploy \u8cc7\u6e90\u4f7f\u7528 [setIamPolicy](https://cloud.google.com/sdk/gcloud/reference/projects/set-iam-policy?hl=zh-cn) \u4f86\u9650\u5236\u5c0d\u9019\u4e9b\u8cc7\u6e90\u7684\u64cd\u4f5c\u3002\n- \u689d\u4ef6 IAM\u4ee5\u7de8\u7a0b\u65b9\u5f0f\u61c9\u7528 [\u8a2a\u554f\u6b0a\u9650\u653f\u7b56](https://cloud.google.com/iam/docs/granting-changing-revoking-access?hl=zh-cn#policy-overview) \uff0c\u5305\u62ec\u6388\u4e88\u6216\u62d2\u7d55\u8a2a\u554f\u6b0a\u9650\u7684 [conditions](https://cloud.google.com/iam/docs/conditions-overview?hl=zh-cn) \u3002\n\u60a8\u53ef\u4ee5\u4f7f\u7528\u9019\u4e9b\u653f\u7b56\u548c\u689d\u4ef6\u4f86\u9650\u5236\u5c0d Cloud Deploy \u8cc7\u6e90\u57f7\u884c\u4ee5\u4e0b\u64cd\u4f5c\uff1a\n- \u5275\u5efa\u4ea4\u4ed8\u6d41\u6c34\u7dda\u6216\u76ee\u6a19\u60a8\u53ef\u4ee5\u5411\u7279\u5b9a\u7528\u6236\u6216\u7fa3\u7d44\u6388\u4e88\u6b64\u8a2a\u554f\u6b0a\u9650\u3002\n- \u66f4\u65b0\u6216\u522a\u9664\u7279\u5b9a\u7684\u4ea4\u4ed8\u6d41\u6c34\u7dda\u60a8\u53ef\u4ee5\u5411\u7279\u5b9a\u7528\u6236\u6216\u7fa3\u7d44\u6388\u4e88\u6b64\u8a2a\u554f\u6b0a\u9650\u3002\n- \u7232\u7279\u5b9a\u4ea4\u4ed8\u6d41\u6c34\u7dda\u5275\u5efa\u7248\u672c\u60a8\u53ef\u4ee5\u5411\u7279\u5b9a\u7528\u6236\u6216\u7fa3\u7d44\u6388\u4e88\u6b64\u8a2a\u554f\u6b0a\u9650\u3002\n- \u66f4\u65b0\u6216\u522a\u9664\u7279\u5b9a\u76ee\u6a19\u60a8\u53ef\u4ee5\u5411\u7279\u5b9a\u7528\u6236\u6216\u7fa3\u7d44\u6388\u4e88\u6b64\u8a2a\u554f\u6b0a\u9650\u3002\n- \u5275\u5efa\u6216\u6279\u51c6\u767c\u4f48\u6216\u63d0\u5347\u7248\u672c\u60a8\u53ef\u4ee5\u5411\u7279\u5b9a\u7528\u6236\u6216\u7d44\u6388\u4e88\u5c0d\u7279\u5b9a\u76ee\u6a19\u6216\u4ea4\u4ed8\u6d41\u6c34\u7dda\u7684\u6b64\u8a2a\u554f\u6b0a\u9650\u3002\u60a8\u9084\u53ef\u4ee5\u8a2d\u7f6e\u689d\u4ef6\uff0c\u5c07\u6b64\u8a2a\u554f\u6b0a\u9650\u9650\u5236\u5728\u6307\u5b9a\u7684\u6642\u9593\u7bc4\u570d\u5167\u3002## \u5f8c\u7e8c\u6b65\u9a5f\n- \u77ad\u89e3 [IAM](https://cloud.google.com/iam/docs?hl=zh-cn) \u3002\n- \u8a73\u7d30\u77ad\u89e3\u5982\u4f55 [\u5728 IAM \u4e2d\u4f7f\u7528\u689d\u4ef6](https://cloud.google.com/deploy/docs/securing/iam?hl=zh-cn#about_iam_conditions) \n- \u8a73\u7d30\u77ad\u89e3 [Cloud Deploy \u670d\u52d9\u8cec\u865f](https://cloud.google.com/deploy/docs/cloud-deploy-service-account?hl=zh-cn) \u3002", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Integrating Cloud Deploy with other systems.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Integrating Cloud Deploy with other systems", "url": "https://cloud.google.com/deploy/docs/integrating", "abstract": "# Cloud Deploy - Integrating Cloud Deploy with other systems\nYou can integrate Cloud Deploy with some of the other systems you rely on for software delivery. This page describes how to integrate Cloud Deploy with the following:\n- Test tooling\n- Workflow management\nSee [Integrating with your CI system](/deploy/docs/integrating-ci) to learn how to call Cloud Deploy from your CI pipeline.\n", "content": "## Before you begin\nThe instructions on this page assume you already meet the following conditions:\n- You have [enabled the applicable APIs](https://console.cloud.google.com/flows/enableapi?apiid=clouddeploy.googleapis.com,cloudbuild.googleapis.com,storage-component.googleapis.com,container.googleapis.com&redirect=https://cloud.google.com/deploy/docs/deploy-app-gke&_ga=2.88599711.504283000.1626992575-1788689322.1622287630) \n- You have at least one delivery pipeline [defined](/deploy/docs/config-file) and [registered](/deploy/docs/create-pipeline-targets#register_the_delivery_pipeline_and_targets) with Cloud Deploy.\n- You have at least one [target defined](/deploy/docs/config-files#target_definitions) , and your delivery pipeline references that target.\n- You have [set up Pub/Sub notifications](/deploy/docs/subscribe-deploy-notifications) to receive notifications from the following topics:- `clouddeploy-operations`\n- `clouddeploy-approvals`\n## Integrating with automated testing\nYou can use Cloud Deploy with Pub/Sub to integrate testing with your delivery pipeline, so you can promote the release automatically, for continuous delivery.\nYou can also use annotations on a rollout to provide a link to test results. For more information, see [Using labels and annotations with Cloud Deploy](/deploy/docs/labels-annotations) .\n### Using Pub/Sub to automate promotion\n- Listen to [Pub/Sub messages](/deploy/docs/subscribe-deploy-notifications) from the `clouddeploy-operations` topic.The message contains the following attributes:- `Action: SUCCEED`\n- `ResourceType: Rollout`\n- `Resource: projects/.../locations/.../deliveryPipelines/.../releases/.../rollouts/...`\n- When you receive a notification that deployment has succeeded, run your tests on your deployed application.\n- When your tests succeed, call Cloud Deploy to automatically promote to the next stage:```\ngcloud deploy releases promote RELEASE_NAME \\--delivery-pipeline=PIPELINE_NAME \\--region=REGION \\--annotations=KEY=VALUE,...\n```where:- is the name of the release. This value is required.\n- is the name of the delivery pipeline managing this release. This value is required.\n- is the region in which the pipeline is running. If you've set the property `deploy/region` , you can omit this flag.\n- is a list of one or more key-value string pairs, comma-separated, which can contain information about your test results and other testing information. Here's an example:`gcloud deploy releases promote --annotations=\"from_target=test,status=stable\"`Annotations on the rollout are immutable, so if you add a status annotation, you can't later update that status on the same rollout.\n### Using annotations to provide access to test results\nIf you have the URL pointing to where test results can be accessed, you can provide that URL as an annotation on a rollout, using the `--annotations` flag. Here's an example:\n```\ngcloud deploy releases promote --delivery-pipeline=my-demo-app-1 --region=us-central1 --project=my-demo-app-1-project --release=test-release-001 --annotations=\"test_results_url=https://example.com/results/my-demo-app-test-results-dev\"\n```\nFor more information, see [Using labels and annotations with Cloud Deploy](/deploy/docs/labels-annotations) .\n## Integrating with third-party workflow management\nCloud Deploy publishes operational messages to Pub/Sub. Your workflow management tool can subscribe to these Pub/Sub topics and use them to trigger specific workflows.\n### For approvals\nThe `clouddeploy-approvals` topic notifies your system when an approval is required for a rollout. Your external workflow system can then work its magic to get the approval, then call `gcloud deploy rollouts approve` .\nThe account that issues the `rollouts approve` command must have the predefined IAM role `roles/clouddeploy.approver` .\nTo set up an external approval workflow:\n- [Require approval on the target](/deploy/docs/promote-release#manage_approvals_for_a_delivery_pipeline) .In the definition for that target, include `requireApproval: true` .\n- To consume the messages, subscribe to the `clouddeploy-approvals` Pub/Sub topic, and set up your workflow management system.\n- When your workflow management system receives a message from the `clouddeploy-approvals` topic that includes `\"Action\": \"Required\"` , it kicks off an approval workflow, configured according to the requirements of your organization.The message also includes a reference to the rollout to be approved, in the following format:`Resource: projects/.../locations/.../deliveryPipelines/.../releases/.../rollouts/...`The output of the approval workflow is an [approval or rejection](/deploy/docs/promote-release#manage_approvals_for_a_delivery_pipeline) of the rollout.\n- Your workflow management system returns the approval or rejection to Cloud Deploy in the form of the following command:The command for approval is as follows:```\ngcloud deploy rollouts approve ROLLOUT \\--delivery-pipeline=PIPELINE_NAME \\--region=REGION \\--release=RELEASE_NAME\n```The command for rejecting the rollout is as follows:```\ngcloud deploy rollouts reject ROLLOUT \\--delivery-pipeline=PIPELINE_NAME \\--region=REGION \\--release=RELEASE_NAME\n```where:- is the name of the rollout for which approval was requested.\n- is the delivery pipeline managing deployment of your application.\n- is the name of the release with which this rollout is associated.\n- is the region in which the delivery pipeline is running.Here's an example:\n`gcloud deploy rollouts approve test-rollout --delivery-pipeline=web-app --release=test-release --region=us-central1`", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Integrating Cloud Deploy with your CI system.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Integrating Cloud Deploy with your CI system", "url": "https://cloud.google.com/deploy/docs/integrating-ci", "abstract": "# Cloud Deploy - Integrating Cloud Deploy with your CI system\nThis document describes how to invoke your Cloud Deploy delivery pipeline from your continuous integration (CI) system.\nIntegrating Cloud Deploy with your CI system is as simple as adding a call to the Cloud Deploy `gcloud` [CLI](/sdk/gcloud/reference/deploy) . This call occurs at the point in your CI pipeline at which your application is ready to be deployed.\n**Note:** Your CI process is responsible for building and placing images, so that Cloud Deploy can reference them for deployment.\n", "content": "## Before you begin\nThe instructions on this page assume you already meet the following conditions:\n- You have [enabled the applicable APIs](https://console.cloud.google.com/flows/enableapi?apiid=clouddeploy.googleapis.com,cloudbuild.googleapis.com,storage-component.googleapis.com,container.googleapis.com&redirect=https://cloud.google.com/deploy/docs/deploy-app-gke&_ga=2.88599711.504283000.1626992575-1788689322.1622287630) \n- You have at least one delivery pipeline [defined](/deploy/docs/config-files) and [registered](/deploy/docs/create-pipeline-targets#register_the_delivery_pipeline_and_targets) with Cloud Deploy.\n- You have at least one [target defined](/deploy/docs/config-files#target_definitions) , and your delivery pipeline references that target.## Calling Cloud Deploy from your CI pipeline\n**Note:** the principal calling this command must use [the clouddeploy.releaser IAM role](/deploy/docs/iam-roles-permissions#predefined_roles) or an equivalent set of permissions, and must have [actAs permission](/iam/docs/service-accounts-actas) for the [service account](/deploy/docs/execution-environment#defaults) used to deploy to the first target and the service account used to perform the [render](/deploy/docs/terminology#render) operation.\nThe following command creates a new release, thus invoking a delivery pipeline instance:\n```\ngcloud deploy releases create RELEASE_NAME \\\u00a0 --delivery-pipeline=PIPELINE_NAME \\\u00a0 --region=REGION \\\u00a0 --annotations=[KEY=VALUE,...] \\\u00a0 --images=[IMAGE_LIST]\n```\nWhere...\n- is a name you give to this release. This value is required.You can specify dynamic release names by including `'$DATE'` or `'$TIME'` or both. For example, if you invoke this command at 3:07pm UTC, `'rel-$TIME'` resolves to `rel-1507` . `'$DATE'` and `'$TIME'` must be in single-quotes.\n- is the name of your [registered delivery pipeline](/deploy/docs/create-pipeline-targets) . This value is required.\n- is the region in which you're creating this release. The region doesn't need to be the same region in which you're ultimately deploying your application.\n- [ = ,...]is an optional list of one or more annotations to apply to the release, in the form of key-value pairs.You can use annotations to track release provenance, for example, by passing an annotation like `commitId=0065ca0` . All annotations on the release are returned when you `list` or `get` the release, and are displayed with the release in the Google Cloud console, so you can see release provenance there too.\n- [ ]is a comma-separated list of image-name-to-image-path replacements. For example: `--images=image1=path/to/image1:v1@sha256:45db24,image2=path/to/image2:v1@sha256:55xy18` .This value isn't required if you pass `--build-artifacts` , which identifies a Skaffold build artifacts output file.When Cloud Deploy renders the manifest, the image name in the unrendered manifest is replaced with the full image reference in the rendered manifest. That is, `image1` , from this example, is in the unrendered manifest and is replaced in the rendered manifest with `path/to/image1:v1@sha256:45db24` .\n### Example using direct image reference\nThe following command creates a new release, passing an image reference directly, rather than a build artifacts file:\n```\ngcloud deploy releases create my-release \\\u00a0 --delivery-pipeline=web-app \\\u00a0 --region=us-central1 \\\u00a0 --images=image1=path/to/image1:v1@sha256:45db24\n```\nIn this example, `my-release` is the release name. If you want to generate a release name based on date or time, you can include `'$DATE'` or `'TIME'` or both. Time is UTC time on the machine where you invoke the command. `'$DATE'` and `'$TIME'` must be in single quotes.\nHere's an example:\n```\ngcloud deploy releases create rel-'$DATE'-'$TIME' \\\u00a0 --delivery-pipeline=web-app \\\u00a0 --region=us-central1 \\\u00a0 --images=image1=path/to/image1:v1@sha256:45db24\n```\nIn this example, the command generates a release name with the prefix `rel-` , plus the date and time, for example: `rel-20220131-1507` .\nIt's also common to use the Git SHA in a release name. See the [Cloud Build and Docker examples](#examples_passing_a_build_artifacts_file) in this document.\n### Build artifacts versus images\nOn the `gcloud deploy releases create` command, you can pass either a set of image references or a build artifacts file reference.\n- Use `--images=[NAME=TAG,...]` to refer to one or more individual container images.This value is a reference to a collection of individual image name to image full path replacements. Here's an example:`gcloud deploy releases create my-release --images=image1=path/to/image1:v1@sha256:45db24`\n- Use `--build-artifacts=` to point to a Skaffold build artifacts output file.\n### Cloud Build examples, passing a build artifacts file\n**Note:** the service account running the Cloud Build trigger must use [the clouddeploy.releaser IAM role](/deploy/docs/iam-roles-permissions#predefined_roles) or an equivalent set of permissions, and must have [actAs permission](/iam/docs/service-accounts-actas) to deploy to the first target.\nThe following YAML file demonstrates Cloud Build for a [Docker build](https://docs.docker.com/engine/reference/commandline/build/) image push, and ultimately creates a Cloud Deploy release.\nThis example builds and pushes an image to an artifact repository and constructs a command to create a release, with a release name based on the short commit SHA. This example must be used as a Cloud Build SCM [trigger](/build/docs/automating-builds/create-manage-triggers) because it relies on the `$COMMIT_SHA` variable.\nThis example pushes an image to a Docker tag that's the same as the commit hash of the source repo. Then the same commit hash, as a Docker tag, is referenced from the release-command arguments.\n```\nsteps:# Build and tag using commit sha- name: 'gcr.io/cloud-builders/docker'\u00a0 args: ['build', '.', '-t', 'REPO_LOCATION/$PROJECT_ID/IMAGE_NAME:${COMMIT_SHA}', '-f', 'Dockerfile']# Push the container image- name: 'gcr.io/cloud-builders/docker'\u00a0 args: ['push', 'REPO_LOCATION/$PROJECT_ID/IMAGE_NAME:${COMMIT_SHA}']# Create release in Google Cloud Deploy- name: gcr.io/google.com/cloudsdktool/cloud-sdk\u00a0 entrypoint: gcloud\u00a0 args:\u00a0 \u00a0 [\u00a0 \u00a0 \u00a0 \"deploy\", \"releases\", \"create\", \"rel-${SHORT_SHA}\",\u00a0 \u00a0 \u00a0 \"--delivery-pipeline\", \"PIPELINE_NAME\",\u00a0 \u00a0 \u00a0 \"--region\", \"us-central1\",\u00a0 \u00a0 \u00a0 \"--annotations\", \"commitId=${REVISION_ID}\",\u00a0 \u00a0 \u00a0 \"--images\", \"IMAGE_NAME=REPO_LOCATION/$PROJECT_ID/IMAGE_NAME:${COMMIT_SHA}\"\u00a0 \u00a0 ]\n```\nNote that the image name at the end of this example, `\"--images\", \"` `` `=` is substituted in the rendered manifest with the full image reference.\nThe following YAML file is the content of a Cloud Build build configuration that includes a call to Cloud Deploy to create a release, with a release name based on the date. This example also shows Skaffold used for the build.\n```\nsteps:- name: gcr.io/k8s-skaffold/skaffold\u00a0 args:\u00a0 \u00a0 - skaffold\u00a0 \u00a0 - build\u00a0 \u00a0 - '--interactive=false'\u00a0 \u00a0 - '--file-output=/workspace/artifacts.json'- name: gcr.io/google.com/cloudsdktool/cloud-sdk\u00a0 entrypoint: gcloud\u00a0 args:\u00a0 \u00a0 [\u00a0 \u00a0 \u00a0 \"deploy\", \"releases\", \"create\", \"rel-${SHORT_SHA}\",\u00a0 \u00a0 \u00a0 \"--delivery-pipeline\", \"PIPELINE_NAME\",\u00a0 \u00a0 \u00a0 \"--region\", \"us-central1\",\u00a0 \u00a0 \u00a0 \"--annotations\", \"commitId=${REVISION_ID}\",\u00a0 \u00a0 \u00a0 \"--build-artifacts\", \"/workspace/artifacts.json\"\u00a0 \u00a0 ]\n```\n**Note:** in the `gcloud` command included in this example, the release name is passed as `rel-${SHORT_SHA}` . This dynamic naming ensures a unique release name per committed change.\n## Connect GitHub Actions to Cloud Deploy\nIf you're using GitHub Actions for continuous integration or other software delivery-related activities, you can connect to Cloud Deploy for continuous delivery using the [create-cloud-deploy-release](https://github.com/marketplace/actions/create-cloud-deploy-release) GitHub Action.\n## Using annotations to track the release's provenance\nThe `--annotations=` flag lets you apply one or more arbitrary key-value pairs to the release that this command creates. You would add this flag to the `gcloud deploy releases create` command.\nFor example, you can use the following key-value pairs to track the source of the image to be deployed.\nHere's an example:\n```\ngcloud deploy releases create web-app-1029rel \\\u00a0 --delivery-pipeline=web-app \\\u00a0 --region=us-central1 \\\u00a0 --annotations=commitId=0065ca0,author=user@company.com \\\u00a0 --images=image1=path/to/image1:v1@sha256:45db24\n```\nYou could also create an annotation whose value is the URL pointing to the pull request, for example. For more information, see [Using labels and annotations with Cloud Deploy](/deploy/docs/labels-annotations) .", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Manage Skaffold versions.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Manage Skaffold versions", "url": "https://cloud.google.com/deploy/docs/using-skaffold/select-skaffold", "abstract": "# Cloud Deploy - Manage Skaffold versions\nCloud Deploy uses [Skaffold](/skaffold) , through Cloud Build, to deploy your application by rendering and deploying manifests.\nThe page describes how Cloud Deploy selects what version of Skaffold to use. This page also includes information about the following:\n- [How often the Skaffold version changes](#how_selects_new_versions) \n- [How to find out the current version](#find_out_the_skaffold_version_associated_with_a_release) \n- [How long each version is supported](#skaffold_version_deprecation_and_maintenance_policy) ", "content": "## What version of Skaffold does Cloud Deploy use?\nCloud Deploy performs its operations using a custom image, which includes a Skaffold LTS version. Each supported version of Skaffold is listed in the [table](#supported_versions) in this document, linked to the repository of all Cloud Deploy images. The version number of each Cloud Deploy image corresponds to the Skaffold version number.\nBefore August 30, 2022, Cloud Deploy used the LTS version of the most recent [publicly available Skaffold images](https://console.cloud.google.com/gcr/images/k8s-skaffold/GLOBAL/skaffold?gcrImageListsize=30) .\n**Note:** the Skaffold version associated with a release is used for the entire lifecycle of that release, and cannot be changed during that lifetime. The release lifecycle consists of all render, deploy, and verify operations on that release. This includes up to deployment into the final target in the progression, and beyond (rollbacks or redeployments).\n### Supported versions\n| Skaffold version  | Max schema version | As-of date  | Default? |\n|:-----------------------|:---------------------|:-----------------|:-----------|\n| 2.10.x (release notes) | v4beta9    | February 2, 2024 | \u2713   |\n| 2.8.x (release notes) | v4beta7    | October 27, 2023 | nan  |\n| 2.6.x (release notes) | v4beta6    | July 6, 2023  | nan  |\n| 2.3.x (release notes) | v4beta4    | April 24, 2023 | nan  |\n| 2.0.x (release notes) | v4beta1    | January 9, 2023 | nan  |\nEach version in this table links to a repository in Artifact Registry. In that repository, look for the most recent date for the latest version or for the version you want. The repository linked is in the `us-central1` region, but these images are available in each region where Cloud Deploy is available. The image that gets used is in the region where the delivery pipeline was created.\nCloud Deploy uses the latest patch release for each supported Skaffold version. We announce support for new versions, including specific Skaffold version patches, in the [release notes](/deploy/docs/release-notes) .\n### Preview version\nYou can use the [Cloud Deploy Preview image](https://console.cloud.google.com/artifacts/docker/cd-image-prod/us-central1/cd-image/cd?project=cd-image-prod) , which includes preview features.\nThe Skaffold version in the preview image can be updated at any time, and doesn't follow a regular release schedule. We recommend you not use the preview version for production workloads.\nThe preview version is in the same repository as the supported versions. Look for images with a tag that begins with `skaffold_preview` .\nSome preview features require the Cloud Deploy preview image. For these features, Cloud Deploy uses that preview version without you having to do anything. If you try to select a different Skaffold version when you create a release using a preview feature, the command fails.\n### Find out the Skaffold version associated with a release\nYou can find the version Cloud Deploy is using at any given time by running the following command:\n```\ngcloud deploy releases describe RELEASE \\\u00a0 \u00a0 \u00a0 \u00a0--delivery-pipeline=DELIVERY_PIPELINE \\\u00a0 \u00a0 \u00a0 \u00a0--region=REGION\n```\nThe version is shown in the `skaffoldVersion` attribute in the output.\n### Choose what version of Skaffold to use\nYou can use any [supported](#supported_versions) version of Skaffold. To select the version that you want to use, include the [--skaffold-version](https://cloud.google.com/sdk/gcloud/reference/deploy/releases/create#--skaffold-version) flag on the `gcloud deploy releases create` command:\n```\ngcloud deploy releases create RELEASE_NAME \\\u00a0 \u00a0 \u00a0 \u00a0--delivery-pipeline=PIPELINE_NAME \\\u00a0 \u00a0 \u00a0 \u00a0--skaffold-version=SKAFFOLD_VERSION \\\u00a0 \u00a0 \u00a0 \u00a0--region=REGION\n```\nWhere ' ' is the (supported) version of Skaffold to use for this release. The version should be in the form of `n.nn` for a numbered version, or `skaffold_preview` to use the [preview version](#preview_version) .\nFor example, the following command selects Skaffold version `2.8` :\n```\ngcloud deploy releases create release-001 \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 --delivery-pipeline=my-pipeline \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 --skaffold-version=2.8 \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 --region=us-central1\n```\nAnd this command selects the Skaffold [preview version](#preview_version) :\n```\ngcloud deploy releases create release-001 \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--delivery-pipeline=my-pipeline \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--skaffold-version=skaffold_preview \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--region=us-central1\n```\n## How Cloud Deploy selects new versions\nA new version of Skaffold is selected every 90 days. At the end of that 90-day cycle, Google Cloud adds support for a new Skaffold version. You can now use that version with Cloud Deploy. It becomes the default version used to create and manage all releases for the next 90-day cycle.\nCloud Deploy [release notes](/deploy/docs/release-notes) are updated to announce each newly supported release.\n## Skaffold version deprecation and maintenance policy\nSkaffold versions are supported for 12 months, with a 60-day maintenance period. This maintenance period means that releases tied to a version are still supported for 60 days after support for that version has expired. You can still create rollouts from those releases, but you can't create using a Skaffold version that's in the maintenance period.\nAfter the 60-day maintenance period, the Skaffold version is no longer supported. You can no longer create rollouts from a release that uses the unsupported version. However, all data associated with the release remains.\n| Skaffold version  | As-of date  | Maintenance start | Expiration  |\n|:-----------------------|:-----------------|:--------------------|:------------------|\n| 2.10.x (release notes) | February 2, 2024 | February 2, 2025 | April 3, 2025  |\n| 2.8.x (release notes) | October 26, 2023 | October 26, 2024 | December 25, 2024 |\n| 2.6.x (release notes) | July 6, 2023  | July 6, 2024  | September 4, 2024 |\n| 2.3.x (release notes) | April 24, 2023 | May 1, 2024   | July 1, 2024  |\n| 2.0.x (release notes) | January 9, 2023 | January 9, 2024  | March 10, 2024 |\n## What's next\n- Read more about [integrating Cloud Deploy with other systems](/deploy/docs/integrating) .\n- [Find out more](/deploy/docs/set-up-skaffold) about how Skaffold works with Cloud Deploy and how to make it work well for you.\n- The document [Managing manifests in Cloud Deploy](/deploy/docs/using-skaffold/managing-manifests) describes more about how you can use Skaffold, including with other, third-party manifest-management tools.", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Manage application secrets.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Manage application secrets", "url": "https://cloud.google.com/deploy/docs/securing/secrets", "abstract": "# Cloud Deploy - Manage application secrets\nThis page describes some best practices for managing secrets for applications you deploy to Google Kubernetes Engine or GKE Enterprise clusters using Cloud Deploy.\nBecause injecting application secrets into deployment artifacts introduces security risks, avoid managing secrets from within Cloud Deploy pipelines.\nSecrets consumed in this way should be generated, managed, and rotated outside of the scope of Cloud Deploy.\nSecrets, in this context, refer to sensitive data such as database credentials, API keys, certificates, or passwords.\n", "content": "## Kubernetes secrets\nKubernetes Secrets are secure objects that store sensitive data, such as passwords, OAuth tokens, and SSH keys in your clusters, separate from Pods. Secrets are similar to ConfigMaps, but are intended to hold confidential data.\nBecause Kubernetes Secrets are not secure by default, without encryption, the approaches described in this document do not use them.\n## Managing secrets for use with Cloud Deploy\nThis section describes how to manage secrets for applications that you deploy using Cloud Deploy.\nThe following are two approaches to secrets management with GKE or GKE Enterprise:\n- [Google Secret Manager](/secret-manager) \n- [Hashicorp Vault](https://www.vaultproject.io/) \n### Google Secret Manager\nSecret Manager is a fully managed, multi-region Google Cloud service that securely stores API keys, passwords, and other sensitive data.\nSecrets from Secret Manager can be accessed from the cluster using the [client library](/secret-manager/docs/reference/libraries) and [Workload Identity](/kubernetes-engine/docs/how-to/workload-identity) authentication, or using the [Secrets Store CSI driver](https://github.com/kubernetes-sigs/secrets-store-csi-driver) .\nTo use Secret Manager for your application:\n- [Create a secret using Secret Manager](/secret-manager/docs/creating-and-accessing-secrets#create) .\n- Reference the secret from your application code [using the SDK](/secret-manager/docs/accessing-the-api) .\nYou can specify additional metadata for the secret using environment variables, for example secret version, or application environment (such as dev, staging, prod).\nIf the deployment process for a specific feature includes provisioning of infrastructure, then create or update the secret using Secret Manager as part of the provisioning process, before deploying the application.\nFor more information on managing Kubernetes secrets with Secret Manager, see [Using Secret Manager with other products ](/secret-manager/docs/using-other-products) .\n### Hashicorp Vault\n[Hashicorp Vault](https://www.vaultproject.io/) is a popular and widely used open source tool for managing secrets. Google Cloud has extensive integrations and support for Vault, along with other Hashicorp tools such as Terraform.\nYou can configure Vault within your Kubernetes cluster as follows:\n- Access Vault secrets through the [API](https://vaultproject.io/api) and authenticate using [Workload Identity](/kubernetes-engine/docs/how-to/workload-identity) .\n- Inject Secrets into your Kubernetes Pods using [Vault Agent](https://learn.hashicorp.com/tutorials/vault/agent-kubernetes) containers.\n- Use the [Vault CSI Provider](https://vaultproject.io/docs/platform/k8s/csi) to consume those secrets.\n**Note:** when you implement Vault, you're responsible for securing and updating the Vault cluster, and for configuring backups and high availability.\n## What's next\n- Find out more about Secret Manager [best practices](/secret-manager/docs/best-practices) .\n- Read a [blog post](https://jryancanty.medium.com/hashicorp-vault-and-terraform-on-google-cloud-security-best-practices-3d94de86a3e9) about security best practices using HashiCorp Vault and Terraform on Google Cloud.\n- [Read more about secrets management in GKE](/kubernetes-engine/docs/concepts/security-overview) .\n- [Learn about configuring Vault on Google Cloud](https://www.vaultproject.io/docs/secrets/gcp) .", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Manage manifests in Cloud Deploy.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Manage manifests in Cloud Deploy", "url": "https://cloud.google.com/deploy/docs/using-skaffold/managing-manifests", "abstract": "# Cloud Deploy - Manage manifests in Cloud Deploy\nThis page describes how to configure Cloud Deploy to render the configuration for each target in a delivery pipeline.\nCloud Deploy uses [Skaffold](/skaffold) to render your Kubernetes manifests. The service supports rendering of raw manifests and more advanced manifest-management tools, such as [Helm](https://helm.sh) , [Kustomize](https://kustomize.io) , and [kpt](https://github.com/GoogleContainerTools/kpt) .\nThe rendering process has two stages:\n- The manifest-management tool generates the manifest.\n- Skaffold substitutes the image references in the manifest with the images you want to deploy in your release.\nThis page includes configuration examples using Helm and Kustomize.\n", "content": "## Using Skaffold to generate your configuration\nIf you don't already have a Skaffold configuration file ( `skaffold.yaml` ), you can use Skaffold to generate one for you, based on what's in your repository.\n- Install Skaffold using Google Cloud CLI:`gcloud components install skaffold`\n- Run `skaffold init` in the repository that contains your manifests:`skaffold init --skip-build`\nThis command creates a `skaffold.yaml` file in your repository. That file references the manifests in that repository. The contents look like this:\n```\napiVersion: skaffold/v4beta7kind: Configmetadata:\u00a0 name: sample-appmanifests:\u00a0 rawYaml:\u00a0 \u00a0 - k8s-manifests/deployment.yaml\u00a0 \u00a0 - k8s-manifests/rbac.yaml\u00a0 \u00a0 - k8s-manifests/redis.yaml\u00a0 \u00a0 - k8s-manifests/service.yaml\n```\n## Rendering raw manifests\nRaw manifests are manifests that aren't managed by a tool like Helm or Kustomize, and therefore don't need any pre-processing before being hydrated and deployed to a cluster.\nBy default, Cloud Deploy uses [skaffold render](https://skaffold.dev/docs/workflows/ci-cd/#separation-of-rendering-and-deployment) to render your Kubernetes manifests, replacing untagged image names with the tagged image names of the container images you're deploying. Then when you promote the release, Cloud Deploy uses [skaffold apply](https://skaffold.dev/docs/workflows/ci-cd/#separation-of-rendering-and-deployment) to apply the manifests and deploy the images to your Google Kubernetes Engine cluster.\n**Note:** When you first create the release, deployment happens automatically. Cloud Deploy creates the rollout and deploys into the first target.\nA `manifests` stanza from a basic configuration looks like this:\n```\nmanifests:\u00a0 rawYaml:\u00a0 \u00a0 - PATH_TO_MANIFEST\n```\nSee the [Skaffold documentation](https://skaffold.dev/docs) for more information on what values can be passed here.\n## Rendering using Helm\nYou can use Cloud Deploy to render your [Helm](https://helm.sh) charts. To do so, you include Helm chart details in a `deploy` stanza in a Skaffold profile.\nEach such definition looks like this:\n```\napiVersion: skaffold/v4beta7kind: Configmanifests:\u00a0 helm:\u00a0 \u00a0 releases:\u00a0 \u00a0 \u00a0 - name: RELEASE_NAME\u00a0 \u00a0 \u00a0 \u00a0 chartPath: PATH_TO_HELM_CHART\u00a0 \u00a0 \u00a0 \u00a0 artifactOverrides:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 image: IMAGE_NAME\n```\nWhere:\nis the name of the Helm chart instance for this release.\nis the local path to a packaged Helm chart or an unpacked Helm chart directory.\nis the name of the container image you're deploying.\nYour Helm chart must have a value `image` parameter that defines the image to be deployed in the chart.\nYou can use additional Helm configuration options, as described in the [Skaffold documentation](https://skaffold.dev/docs/pipeline-stages/deployers/helm/)\n## Rendering using Kustomize\nYou can use [Kustomize](https://kustomize.io) with Cloud Deploy. To do so, you point to the Kustomization files from within the `deploy` stanza in your `skaffold.yaml` profile configuration.\nYou include a separate Kustomize configuration for each target for which you're using Kustomize, under each corresponding `profile` in your `skaffold.yaml` .\nEach such definition looks like this:\n```\napiVersion: skaffold/v4beta7kind: Configmanifests:\u00a0 kustomize:\u00a0 \u00a0 paths:\u00a0 \u00a0 \u00a0 - PATH_TO_KUSTOMIZE\n```\nWhere:\npoints to your Kustomization files. The default is `[\".\"]`\nYou can use additional Kustomize configuration options, as described in the [Skaffold documentation](https://skaffold.dev/docs/pipeline-stages/deployers/kustomize/)\n## Configuring different manifests per target\nOften each target needs a slightly different configuration. For example, you might have more replicas in your production deployments than in your staging deployments.\nYou can render a different set of manifests for each target by providing each variation as a different [Skaffold profile](https://skaffold.dev/docs/environment/profiles/) .\n### Profiles with Raw manifests\nWhen working with raw manifests you can point Cloud Deploy at a different file, depending on the target. You could configure that as follows:\n```\napiVersion: skaffold/v4beta7kind: Configprofiles:\u00a0 - name: prod\u00a0 \u00a0 manifests:\u00a0 \u00a0 \u00a0 rawYaml:\u00a0 \u00a0 \u00a0 \u00a0 - prod.yaml\u00a0 - name: staging\u00a0 \u00a0 manifests:\u00a0 \u00a0 \u00a0 rawYaml:\u00a0 \u00a0 \u00a0 \u00a0 - staging.yaml\n```\n### Profiles with Kustomize\nHere's an example `skaffold.yaml` that has different profiles for staging and production using Kustomize, where each profile points to a different Kustomization:\n```\napiVersion: skaffold/v4beta7kind: Configprofiles:\u00a0 - name: prod\u00a0 \u00a0 manifests:\u00a0 \u00a0 \u00a0 kustomize:\u00a0 \u00a0 \u00a0 \u00a0 paths:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 - environments/prod\u00a0 - name: staging\u00a0 \u00a0 manifests:\u00a0 \u00a0 \u00a0 kustomize:\u00a0 \u00a0 \u00a0 \u00a0 paths:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 - environments/staging\n```\n### Profiles referenced in the delivery pipeline\nThese profiles, defined in `skaffold.yaml` , are referenced in the [deliverypipeline config](/deploy/docs/config-files) , per target:\n```\nserialPipeline:\u00a0 stages:\u00a0 - targetId: staging-target\u00a0 \u00a0 profiles:\u00a0 \u00a0 - staging\u00a0 - targetId: prod-target\u00a0 \u00a0 profiles:\u00a0 \u00a0 - prod\n```\n## What's next\n- Learn more about [Cloud Deploy delivery pipeline configuration](/deploy/docs/config-files) .\n- Try the [Cloud Deploy Skaffold profiles walkthrough](https://shell.cloud.google.com/?show=ide%2Cterminal&walkthrough_id=deploy--cloud-deploy-profiles-gke) \n- Learn more about [Kustomize](https://kustomize.io) .\n- Learn more about [Helm](https://helm.sh) .\n- Learn more about [Kpt](https://googlecontainertools.github.io/kpt) \n- Consider using [Artifact Registry](https://cloud.google.com/artifact-registry) to store artifacts such as Helm charts or Kustomizations.", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Manage rollouts.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Manage rollouts", "url": "https://cloud.google.com/deploy/docs/deployment-strategies/manage-rollout", "abstract": "# Cloud Deploy - Manage rollouts\nA Cloud Deploy rollout includes phases. A phase is an ordered, logical grouping of jobs to do in a rollout.\nEach phase includes jobs, which are the actions to take in each phase (for example, `deploy` or `verify` ). And each job can have zero or more job runs. A job run is an instance of a job. If the job hasn't run, there are no job runs.\nThis document describes [phases](/deploy/docs/terminology#phase) , [jobs](/deploy/docs/terminology#job) , and [job runs](/deploy/docs/terminology#job_runs) , and how to manage them.\n", "content": "## Structure of a rollout\nA rollout is a Cloud Deploy resource that associates a [release](/deploy/docs/terminology#release) with a [target](/deploy/docs/terminology#target) .\n### Phases\nA rollout consists of one or more [phases](/deploy/docs/terminology#phase) .\nFor a [standard](/deploy/docs/deployment-strategies) deployment strategy, there is only one phase: `stable` .\nFor a [canary](/deploy/docs/deployment-strategies/canary) deployment strategy, There is a separate phase for each configured percentage. For example, if you configure a canary that deploys 25%, then 50%, then 100%, there will be three phases:\n- `canary-25`\n- `canary-50`\n- `stable`\nThese phase names are standard: `canary-[PERCENTAGE]` for canary stages, and `stable` for the 100% phase. However, if you configure a [manual](/deploy/docs/deployment-strategies/canary#configure_a_manual_canary) or [custom](/deploy/docs/deployment-strategies/canary#custom) canary, you can control the phase names.\n### Jobs and job runs\nEach rollout phase includes one or more jobs.\nFor a rollout in a [standard](/deploy/docs/deployment-strategies) deployment strategy, with no deployment verification enabled, there is one phase ( `stable` ).\nFor a canary rollout, there will be a phase for each part of the canary (for example, `canary-25` , `canary-50` , `stable` ), and for each phase there is a `deploy` job. If verification is enabled, there is also a `verify` job for each phase.\nA job run is an instance of a job. For example, a job run for a `deploy` job is executed, and if it succeeds, there is no further job run for that job. If it fails, it can be retried as another job run.\n## Skipping phases the first time\nSome deployment strategies (for example, canary) apportion traffic between the old and new versions. If you're deploying to a target for the first time, there's no old version, so we can't apportion the traffic.\nFor this reason, when you deploy a canary for the first time, we skip the canary phase or phases and run the `stable` phase. After that, the application is deployed, and future canary deployments will include the canary phases.\nIn a real-world situation, you will usually execute a canary deployment where your application is already running, so this phase skipping will be rare.\n## States within a rollout\nRollouts, phases, jobs, and job runs all have states. This section describes the states for each.\n### Rollout states\nA rollout will have one of the following states:\n- `APPROVAL_REJECTED`The rollout [required approval](/deploy/docs/promote-release#require_approval) , but the approval was rejected.\n- `CANCELLED`The terminal state for rollouts that have been [canceled](#cancel_rollout) by a user.\n- `CANCELLING`A user has canceled the rollout, but the cancellation has not finished processing.\n- `HALTED`In a [parallel deployment](/deploy/docs/parallel) , if one or more child rollouts fail, but at least one child rollout succeeds, the [controller](/deploy/docs/terminology#controller_rollout) rollout is HALTED if there are more phases after the current one.You can resume a halted controller rollout by doing any of the following:- Cancel the controller rollout\n- Retry or ignore any failed jobs on child rollouts\n- `IN_PROGRESS`A job run is processing.\n- `FAILED`A job failed, and the user didn't choose to [ignore the failure](#ignore_job) .\n- `PENDING`The rollout has not begun processing. This state transitions to `IN_PROGRESS` or `CANCELED` .\n- `PENDING_APPROVAL`The rollout [requires approval](/deploy/docs/promote-release#require_approval) , but has not yet been approved.\n- `PENDING_RELEASE`The rollout is waiting for the [release to be rendered](/deploy/docs/architecture#how_they_fit_together_to_deliver_your_release) .\n- `SUCCEEDED`The rollout has finished, with no failures.\n### Phase states\nA phase will have one of the following states:\n- `PENDING`The phase is waiting for another phase in the rollout to finish.\n- `IN_PROGRESS`The phase has started.\n- `SUCCEEDED`The phase completed successfully.\n- `FAILED`A job in the phase failed, and the user didn't choose to [ignore the failure](#ignore_job) .\n- `ABORTED`A previous phase failed.\n- `SKIPPED`When you're running a deployment strategy, such as a [canary](/deploy/docs/deployment-strategies/canary) , Cloud Deploy skips to the `stable` phase in cases where there isn't yet a running version of the application with which to split traffic. In this case, the state is set to `SKIPPED` .\n### Job states\nA job will have one of the following states:\n- `ABORTED`If a phase fails, subsequent phases are aborted.If a job fails, and that failure is not [ignored](#ignore_job) , subsequent jobs are aborted. For example, if a phase includes a deploy job and a verify job, and the deploy job fails, the verify job is aborted.\n- `DISABLED`Some jobs in a Phase might be disabled. For example, phases always include verify jobs, whether or not [verification](/deploy/docs/verify-deployment) is enabled. If verification enabled, then the verify job is set to `DISABLED` .\n- `FAILED`A job run for this job failed, and the user didn't choose to [ignore the failure](#ignore_job) .The user chose to [terminate the job run](#terminate_job_run) for this job.\n- `IGNORED`A job run for this job failed, and the user chose to [ignore the failure](#ignore_job) .\n- `IN_PROGRESS`A job run for this job is currently running.\n- `PENDING`The job run for this job is waiting to begin, because another phase or job hasn't finished.\n- `SKIPPED`When you're running a deployment strategy, such as a [canary](/deploy/docs/deployment-strategies/canary) , Cloud Deploy skips to the `stable` phase in cases where there isn't yet a running version of the application with which to split traffic. In this case, the state is set to `SKIPPED` on jobs within the skipped phase or phases.\n- `SUCCEEDED`The job run finished successfully, and the next job in the phase has started, or the next phase has started or is ready to start (possibly pending user input), or the rollout has finished.\n### Job run states\n- `FAILED`The job run failed during execution.\n- `IN_PROGRESS`The job run has begun, but hasn't finished.\n- `TERMINATED`The user [terminated the job run](#terminate_job_run) .\n- `TERMINATING`The user [terminated the job run](#terminate_job_run) , but it hasn't finished terminating yet.\n- `SUCCEEDED`When a job run finishes successfully, without failing or being terminated by a user, it's put into a `SUCCEEDED` state, which## Manage your rollout\nUsing the Google Cloud console or the Google Cloud SDK, you can do the following with a Cloud Deploy rollout:\n- [Advance the rollout](#advance_rollout) \n- [Cancel the rollout](#cancel_rollout) \n- [Terminate a job run](#terminate_job_run) \n- [Ignore a job](#ignore_job) \n- [Retry a failed job](#retry_failed_job) \nIf you're using parallel deployment a canary deployment strategy, see [this document](/deploy/docs/deployment-strategies/canary#parallel_canary) .\n### Advance a rollout\nFor targets configured to use a deployment strategy other than \"standard,\" you need to advance the rollout from phase to phase.\nFor example, if you have a target configured to perform a simple canary deploy with 50% and `stable` (100%) phases only, you would need to advance the rollout once, from the `canary-50` phase to the `stable` (100%) phase.\n```\ngcloud deploy rollouts advance ROLLOUT_NAME \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--release=RELEASE_NAME \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--delivery-pipeline=PIPELINE_NAME \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--region=REGION\n```\nWhere:\n`` is the name of the current rollout which you're advancing to the next phase.\n`` is the name of the release that this rollout is part of.\n`` is the name of the delivery pipeline you're using to manage deployment of this release.\n`` is the name of the region in which the release was created, for example `us-central1` . This is required.\nSee the Google Cloud SDK reference for more information about the [gcloud deploy rollouts advance command](/sdk/gcloud/reference/deploy/rollouts/advance) .- [Open the Deliverypipelines page](https://console.cloud.google.com/deploy/delivery-pipelines) .\n- Click your pipeline shown in the list of delivery pipelines.The Delivery pipeline details page shows a graphical representation of your delivery pipeline's progress.\n- On the **Rollouts** tab, under **Delivery pipeline details** , click the name of your rollout.The rollout details page is shown, for that rollout.Notice that in this example, the rollout has a `canary-50` phase and a `stable` phase. Your rollout might have more phases or different phases.\n- Click **Advance rollout** .The rollout is advanced to the next phase.\n### Cancel a rollout\nYou can cancel any rollout which hasn't finished. You can also cancel a failed rollout to prevent further actions on it (such as ignore or retry). The rollout must be in one of the following states:\n- `FAILED`\n- `HALTED`\n- `IN_PROGRESS`\n- `PENDING`\n- `PENDING_APPROVAL`\n- `PENDING_RELEASE`\nAfter you cancel a rollout, that rollout is in a `CANCELLING` state until all outstanding job runs have completed. You can [terminate](#terminate_job_run) outstanding job runs that you don't want to wait for. Once the rollout is `CANCELLED` , it can no longer be advanced or modified.\nTo cancel a rollout:\n```\ngcloud deploy rollouts cancel ROLLOUT_NAME \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--release=RELEASE_NAME \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--delivery-pipeline=PIPELINE_NAME \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--region=REGION\n```\nWhere:\n`` is the name of the current rollout which you're advancing to the next phase.\n`` is the name of the release that this rollout is part of.\n`` is the name of the delivery pipeline you're using to manage deployment of this release.\n`` is the name of the region in which the release was created, for example `us-central1` . This is required.\nSee the Google Cloud SDK reference for more information about the [gcloud deploy rollouts cancel command](/sdk/gcloud/reference/deploy/rollouts/cancel) .- [Open the Deliverypipelines page](https://console.cloud.google.com/deploy/delivery-pipelines) .\n- Click your pipeline shown in the list of delivery pipelines.The Delivery pipeline details page shows a graphical representation of your delivery pipeline's progress.\n- On the **Rollouts** tab, under **Delivery pipeline details** , click the name of your rollout.The rollout details page is shown, for that rollout.Notice that in this example, the rollout has a `canary-50` phase and a `stable` phase. Your rollout might have more phases or different phases.\n- Click **Cancel rollout** .The rollout is canceled.\n### Terminate a job run\nYou can end a job run that's currently in progress. You might want to do this, for example, if a job run appears to be taking too long or not working as expected. The job run must be `IN_PROGRESS` for you to terminate it.\n```\ngcloud deploy job-runs terminate JOB_RUN_ID \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--release=RELEASE_NAME \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--delivery-pipeline=PIPELINE_NAME \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--rollout=ROLLOUT_NAME \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--region=REGION\n```\nWhere:\n`` is the (UUID) of the job run you want to terminate. You can find the job run ID in the Google Cloud console, for Cloud Deploy, on the rollout page:You can also get the job runs ID using the `gcloud deploy rollouts describe` command.\n`` is the name of the release that this job run is part of.\n`` is the name of the delivery pipeline you're using to manage deployment of this release.\n`` is the name of the rollout this job run is part of.\n`` is the name of the region in which the release was created, for example `us-central1` . This is required.\nSee the Google Cloud SDK reference for more information about the [gcloud deploy job-runs terminate command](/sdk/gcloud/reference/deploy/job-runs/terminate) .- [Open the Deliverypipelines page](https://console.cloud.google.com/deploy/delivery-pipelines) .\n- Click your pipeline shown in the list of delivery pipelines.The Delivery pipeline details page shows a graphical representation of your delivery pipeline's progress.\n- On the **Rollouts** tab, under **Delivery pipeline details** , click the name of your rollout.The rollout details page is shown, for that rollout.Notice that in this example, the rollout has a `canary-50` phase and a `stable` phase. Your rollout might have more phases or different phases.\n- Under **Phases** , click the phase that includes the job whose job run you're terminating.\n- Under **Job runs** select the specific job run you're terminating, then click **Terminate** .The job run is terminated, and the job status, as shown in the **Phases** table, is `Failure` .\nAfter you terminate a job run, the job is considered failed and you can do any of the following:\n- Leave it that way and disregard the failed rollout\n- Retry the job\n- [Ignore the job](#ignore_job) and continue with the next job or phase in the rollout\n**Note:** When you're using a [parallel deployment](/deploy/docs/parallel) , you can terminate job runs on child rollouts only\u2014not controller rollouts.\n### Ignore a job\nYou can ignore a failed job and move immediately to the next job in the phase. That job might have failed for any reason, including you or someone else [terminated](#terminate_job_run) a job run for that job.\nA failed job means a failed phase and a failed rollout. However if you ignore the failure, both the phase and the rollout can be progressed and can ultimately have `SUCCEEDED` states.\n```\ngcloud deploy rollouts ignore-job ROLLOUT_NAME \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--release=RELEASE_NAME \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--delivery-pipeline=PIPELINE_NAME \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--job-id=JOB_ID \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--phase-id=PHASE_ID \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--region=REGION\n```\nWhere:\n`` is the name of the rollout this job run is part of.\n`` is the name of the current release that includes this job.\n`` is the name of the delivery pipeline you're using to manage deployment of this release.\n`` is the name of the job to ignore, for example `DEPLOY` . You can find the job name in the **Phases** table for the rollout, in the Google Cloud console:`` is the name of the phase that includes the job you're ignoring.\n`` is the name of the region in which the release was created, for example `us-central1` .\nSee the Google Cloud SDK reference for more information about the [gcloud deploy rollouts ignore-job command](/sdk/gcloud/reference/deploy/rollouts/ignore-job) .- [Open the Deliverypipelines page](https://console.cloud.google.com/deploy/delivery-pipelines) .\n- Click your pipeline shown in the list of delivery pipelines.The Delivery pipeline details page shows a graphical representation of your delivery pipeline's progress.\n- On the **Rollouts** tab, under **Delivery pipeline details** , click the name of your rollout.The rollout details page is shown, for that rollout.\n- Select the failed job to ignore.\n- Click the **Ignore failures** button.The failed job run is ignored, and the rollout continues as if the job had succeeded. That is, if there are other jobs in the same phase, they are executed. Otherwise, the rollout is ready to advance to the next phase.\n**Note:** When you're using a [parallel deployment](/deploy/docs/parallel) , you can ignore jobs on child rollouts only\u2014not controller rollouts.\n### Retry a failed job\nYou can retry a job run that failed. The job can fail for any of the following reasons:\n- A job run failed to complete.For example, there could have been a permissions failure.\n- A user [terminated a job run](#terminate_job_run) from that job.Terminating a job run results in a failed job, which you can retry.\n- A verification test failed.For a [verification](/deploy/docs/verify-deployment) job, a verification test failed. Even though the verification job completed correctly, one of your verification tests failed, and we propagate that back to the verification job. In this case, you would retry the job as part of debugging the failed test against your application.\nTo retry a failed job:\n```\ngcloud deploy rollouts retry-job JOB_NAME \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--release=RELEASE_NAME \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--delivery-pipeline=PIPELINE_NAME \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--rollout=ROLLOUT_NAME \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--phase=PHASE_ID \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--region=REGION\n```\nWhere:\n`` is the name of the job that you're retrying. For example, if you're retrying the verify job after a failed verification, this would be `verify` .\n`` is the name of the release that this job run is part of.\n`` is the name of the delivery pipeline you're using to manage deployment of this release.\n`` is the name of the rollout this job run is part of.\n`` is name of the phase that this job is part of. For example, `canary-50` , or `stable` .\n`` is the name of the region in which the release was created, for example `us-central1` . This is required.\nSee the Google Cloud SDK reference for more information about the [gcloud deploy rollouts retry-job command](/sdk/gcloud/reference/deploy/rollouts/retry-job) .- [Open the Deliverypipelines page](https://console.cloud.google.com/deploy/delivery-pipelines) .\n- Click your pipeline shown in the list of delivery pipelines.The Delivery pipeline details page shows a graphical representation of your delivery pipeline's progress.\n- On the **Rollouts** tab, under **Delivery pipeline details** , click the name of your rollout.The rollout details page is shown, for that rollout.\n- Under **Phases and Jobs** , click the phase that includes the job you're retrying.\n- Select the job to retry.\n- Click **Retry** , and confirm.The job run is executed again and the job status, as shown in the **Phases** table, is \"in progress\". If there are other jobs in the same phase, they are executed. Otherwise, the rollout is ready to advance to the next phase.\n**Note:** When you're using a [parallel deployment](/deploy/docs/parallel) , you can retry jobs on child rollouts only\u2014not controller rollouts.\n## What's next\n- Find out more about [how deployment strategies work](/deploy/docs/deployment-strategies) in Cloud Deploy.\n- See the [Cloud Deploy service architecture](/deploy/docs/architecture) documentation for more information about how rollouts, phases, jobs, and job runs fit in with the rest of Cloud Deploy.", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Overview of Cloud Deploy.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Overview of Cloud Deploy", "url": "https://cloud.google.com/deploy/docs/overview", "abstract": "# Cloud Deploy - Overview of Cloud Deploy\nCloud Deploy is a managed service that automates delivery of your applications to a series of [target](/deploy/docs/terminology#target) environments in a defined promotion sequence. When you want to deploy your updated application, you create a [release](/deploy/docs/terminology#release) , whose [lifecycle](/deploy/docs/architecture#how_they_fit_together_to_deliver_your_release) is managed by a [delivery pipeline](/deploy/docs/terminology#delivery_pipeline) .\n", "content": "## How a Cloud Deploy pipeline works\nThe Cloud Deploy delivery pipeline contains the following information:\n- A name, which you use when referring to the delivery pipeline, and a description.\n- The promotion sequence, describing the order in which to deploy to the configured [targets](/deploy/docs/terminology#target) .\n- Optionally, [labels and annotations](/deploy/docs/labels-annotations) .\n- Also optionally, the target definitions themselves.\nTargets can be [defined](/deploy/docs/config-files#target_definitions) in the same delivery pipeline [configuration file](/deploy/docs/config-files) , or in one or more separate files. Multiple delivery pipelines can use the same target or targets, but a given target can be used only once in a given delivery pipeline.\n### The Cloud Deploy delivery process\nThe following is a description of what happens in a simple Cloud Deploy continuous delivery scenario.\n- You define your [delivery pipeline](/deploy/docs/terminology#delivery_pipeline) in a [YAML configuration file](/deploy/docs/config-files#structure_of_a_delivery_pipeline_configuration_file) .This configuration file defines the promotion sequence in which to deploy your application to a series of [targets](/deploy/docs/terminology#target) .You also need a [configuration](https://skaffold.dev/docs/references/yaml/) for [Skaffold](/skaffold) , which Cloud Deploy needs in order to perform render and deploy operations.\n- You define your targets, either in the pipeline configuration file or in a separate file or files.\n- You register your pipeline with the Cloud Deploy service.Now that the service knows about your application, it manages the deployment to targets according to your defined promotion sequence.\n- The output of your CI process includes a call to Cloud Deploy to initiate your delivery pipeline.This call creates a `release` resource, representing the rendered manifest for each target, each of which is generated using the provided rendering source, skaffold.yaml, and references to specific container images to deploy. For this first call to create a [release](/deploy/docs/terminology#release) , Cloud Deploy automatically creates a [rollout](/deploy/docs/terminology#rollout) resource, which associates the release with the first target environment. Based on that rollout, your application is deployed to the first target.You can use any CI tool as long as it outputs one or more container images to provide to your Cloud Deploy delivery pipeline.Furthermore, the call to create a release and invoke a delivery pipeline doesn't have to come from the CI tool. It can come from a script or any system responding to completion of the CI process.\n- When you're ready to deploy your application to the next target, you call Cloud Deploy to promote it.In each case, the call to invoke the promotion causes Cloud Deploy to create a new rollout.\n- Promotion continues through all targets in your promotion sequence, the last of which is `prod` (or whatever name you use for your final target to put the application into production).The process of release creation and promotion is described in more detail in [Cloud Deploy service architecture](/deploy/docs/architecture#how_they_fit_together_to_deliver_your_release) .\nThroughout pipeline execution, Cloud Deploy collects metrics and [audit](/deploy/docs/audit-logs) details.\n### Promotion\nTo [promote a release](/deploy/docs/promote-release) is to deploy it to the next target in the promotion sequence defined in your pipeline. The first call to Cloud Deploy creates a `release` , then a `rollout` resource that's used to deploy to the first target in the promotion sequence. Each subsequent call to promote the release results in a rollout to the next target.\n### Approvals\nYou can specify that an approval is needed for promotion to any target. For example, you might want to require approval for promotion into a production target. To require approval for a target, set the `requireApproval` property in the [target definition](/deploy/docs/config-files#target_definitions) .\nWhen a target requires approval, Cloud Deploy generates a Pub/Sub message that can be consumed by an integrated system. For example, a ticketing system could subscribe to the message to kick off an approval workflow.\nSee [Require approval](/deploy/docs/promote-release) for more information on promotions and managing approval for promotions.\n### Notifications\nCloud Deploy provides Pub/Sub notifications for the following events:\n- Render: start, success, and failure\n- Deploy: start, success, and failure\n- Approval required\n- Approval approved\n- Approval rejected\nCloud Deploy uses a Pub/Sub topic to send these notifications.\nSee [Using Cloud Deploy notifications](/deploy/docs/subscribe-deploy-notifications) for more details.\n### Rollbacks\nCloud Deploy supports rolling back your deployed application in any target. A rollback in Cloud Deploy consists of triggering a rollout against the last successfully deployed release. The new rollout uses the same parameters that were used in that successful deployment.\nSee [Rolling back a deployment](/deploy/docs/roll-back) for more details.\n## About Skaffold and Cloud Deploy\nCloud Deploy uses [Skaffold](/skaffold) for rendering, deployment, and verification. With Skaffold, you can also easily connect your local development loop to a Cloud Deploy continuous delivery pipeline.\nTo learn more about how Cloud Deploy integrates with Skaffold, see the [Skaffold overview](/deploy/docs/using-skaffold) .\n## Cloud Deploy with other Google Cloud tools\nCloud Deploy supports almost any tool upstream in a CI/CD pipeline. That is, you can use any development environment and source code repository, any continuous integration (CI) system, and any artifact repository.\nDownstream, Cloud Deploy deploys to Google Kubernetes Engine, Cloud Run, and GKE Enterprise.\nIf you used mostly Google Cloud tools, your source-to-prod flow would look like this:\n- Use [Cloud Code](/code/docs) to create your application source.Cloud Code extends several popular IDEs (VS Code, IntelliJ, Cloud Shell) to make it easier to build applications to deploy and run on Google Cloud.\n- Use [Skaffold](https://skaffold.dev) to manage your local development loop.Cloud Deploy uses Skaffold, through Cloud Build, to render and deploy your manifests. This integration means that you need to maintain a `skaffold.yaml` file, but does not otherwise mean you need to make Skaffold part of your local development flow. But you can take advantage of it for [continuous development](https://skaffold.dev/docs/workflows/dev/) .\n- Build your application using Cloud Build. [Cloud Build](/build/docs) lets you set up a CI pipeline that can be triggered from a commit to your source code repository. The output from Cloud Build will be artifacts including deployable container images. You can add a call to Cloud Deploy to create a release and invoke your delivery pipeline.\n- Store your artifacts in Artifact Registry.Cloud Deploy retrieves the container image or images from [Artifact Registry](/artifact-registry/docs) , which lets you centrally store artifacts and dependencies.\n- Configure your delivery pipeline in Cloud Deploy to take the container image and deploy it in a progression of targets.Each of those targets identified in your delivery pipeline represents a GKE cluster, Cloud Run, or GKE cluster where your application is ultimately deployed.\n- Manage your application on GKE, Cloud Run or GKE Enterprise. [GKE](/kubernetes-engine/docs) is the Google Cloud managed environment for running containerized applications on Kubernetes.With [Cloud Run](/run/docs) , you can run containers in a serverless environment. [GKE Enterprise](/anthos/docs) provides a consistent development and operations experience for cloud and on-premises environments.\n- Monitor the performance of your application using Google Cloud Observability. [Google Cloud Observability](/stackdriver/docs) offers integrated monitoring and logging for your application.## What's next\n- For a quick-and-easy look at how to create a delivery pipeline and use it to deploy an application, try the [quickstarts](/deploy/docs/quickstarts) .\n- Try out one of the [Cloud Deploy walkthroughs](/deploy/docs/tutorials) .\n- Learn more about [how Cloud Deploy components work together](/deploy/docs/architecture) .\n- Review [Google Cloud Architecture Framework: Operational excellence](/architecture/framework/operational-excellence) for articles on how to use the principles of operational excellence to build an automated delivery foundation.\n- [Learn how to combine Google Cloud CI/CD tools to develop and deliversoftware effectively to GKE](https://cloud.google.com/architecture/app-development-and-delivery-with-cloud-code-gcb-cd-and-gke) .", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Pass parameters to your deployment.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Pass parameters to your deployment", "url": "https://cloud.google.com/deploy/docs/parameters", "abstract": "# Cloud Deploy - Pass parameters to your deployment\nUsing Cloud Deploy, you can pass parameters for your release, and those values are provided to the manifest or manifests before those manifests are applied to their respective targets. This substitution is done manifests are [rendered](/deploy/docs/terminology#render) . Values are provided to all manifests identified in your `skaffold.yaml` file that contain the corresponding placeholders.\nAll you need to do is include placeholders in your manifest, and set the values for those placeholder in either your Cloud Deploy delivery pipeline or target configuration, or when you create a release.\nThis article describes how to make that happen.\n", "content": "## Why use deploy parameters?\nA typical use for this would be to apply different values to manifests for different targets in a [parallel deployment](/deploy/docs/parallel) . But you can use deploy parameters for anything that requires post-render key-value pair substitution in your manifest.\n## How it works\nThe following steps describe the general process for configuring deploy parameters and providing values:\n- You configure deploy parameterization, as described [here](#configure_deploy_parameters) .This includes the following:- Add the placeholders to your manifest.\n- Add values for those placeholders.There are three ways to do this, described [here](#three_ways) .\n- When you create a release, your manifest is [rendered](/deploy/docs/terminology#render) .If you start with a templated manifest, values are applied now for template variables. If you start with a raw manifest, it remains unchanged. This rendering is done by [Skaffold](/deploy/docs/using-skaffold) .However, you can have additional variables in your manifest for which values aren't applied at render time. These are the deploy parameters described in this document.At release creation, all deploy parameters are compiled into a [dictionary](#view_parameters) , which is used to substitute values before the manifests are applied. **Note:** If a given deploy parameter (key) is assigned more than one value, the release fails.\n- After rendering, Cloud Deploy substitutes values for deploy parameters.These are the values you configured in the first step.The process already applied values to manifest templates, replacing some values, and adding labels specific to Cloud Deploy. But the values for these deploy parameters are substituted after rendering. The differences between manifest templates and deploy parameters are described [here](#how_is_this_different_from_manifest_templates) .\n- The manifest is applied to the target runtime, to deploy your application.This includes the values substituted at render time, and the values for any deploy parameters## Different ways to pass values\nYou can provide parameters, and values for those parameters in three ways:\n- [In the delivery pipeline definition](#add_to_pipeline_stage) You provide the parameter and its value in the definition for a stage in the delivery pipeline progression. The parameter is passed to the target represented by that stage. If that stage references a multi-target, the values set here are used for all child targets.This method lets you replace a value for all releases within a given pipeline, for all affected targets. The parameters defined for a stage identify a label, and the corresponding target for that stage must have a matching label.\n- [In the target definition](#add_to_target) You configure the parameter and its value in the definition for the target itself. This method lets you replace a value for that target for all releases.\n- [On the command line](#pass_to_releases_create) , when you create a releaseYou include the parameter and its value using the `--deploy-parameters` flag on the `gcloud deploy releases create` command.This method lets you replace a value at release creation time, applying that value to that manifests of all affected targets.\nConfiguration for these is explained in more detail [here](#configure_deploy_parameters) .\n### Can I use more than one of these methods?\nYes, you can include deploy parameters in the pipeline stage, in the target config, on the command line. The result is that all the parameters are accepted and added to the dictionary. However, if a specific parameter is passed in more than one place, but with different values, the `gcloud deploy releases create` command fails with an error.\n## How is this different from manifest templates\nDeploy parameters, as described in this article, are distinguished from placeholders in a templated manifest by the [syntax](#add_placeholders) . But if you're wondering why you would need deploy parameters instead of just using the standard techniques for templated manifests, the following table shows the different purposes:\n| Technique   | Substitution time | Applies to        |\n|:---------------------|:--------------------|:------------------------------------------|\n| Manifest template | Rendering phase  | Specific release; specific target   |\n| On command line  | Post-rendering  | Specific release; all targets    |\n| On delivery pipeline | Post-rendering  | All releases; specific targets (by label) |\n| On target   | Post-rendering  | All releases; specific target    |\nThis article is about deploy parameters only (on command line, pipeline, and target), not [templated manifests](/deploy/docs/using-skaffold/managing-manifests) .\n## Limitations\n- For each [type of parameter](#three_ways) , you can create a maximum of 25 parameters.\n- A child target can additionally inherit up to 25 parameters from its parent multi-target, up to a maximum of 100 parameters on the targets, including those set on the pipeline stage.\n- The key name is limited to a maximum of 512 characters, and the following regex:```\n/^[a-zA-Z0-9][-A-Za-z0-9_.]{0,61}[a-zA-Z0-9]$/\n```\n- You can't have two keys of the same name applied to the same target.\n- The prefix `CLOUD_DEPLOY_` is reserved, and cannot be used for a key name.## Configure deploy parameters\nThis section describes how to configure deploy parameter values that will be applied to your Kubernetes manifest, your Cloud Run service, or your Helm template.\nBesides configuring those key-value pairs, you need to add the placeholder or placeholders to your manifest, as described in this section.\n### Add placeholders to your manifest\nIn your Kubernetes manifest (for GKE) or service YAML (for Cloud Run), you add placeholders for any values you want to substitute after rendering.\nFor releases that aren't using the [Helm](#helm_placeholders) renderer with Skaffold, use the following syntax for your placeholders:\n```\n[PROPERTY]: [DEFAULT_VALUE] # from-param: $[VAR_NAME]\n```\nIn this line...\n- Is the configuration property in your Kubernetes manifest or Cloud Run service YAML.\n- Is a value to use if there are no values provided for this property on the command line or in the pipeline or target config.\n- Uses a comment character to set off the Cloud Deploy `deploy-parameters` directive, and `from-param:` tells Cloud Deploy that a `deploy-parameters` placeholder follows.\n- Is the placeholder to substitute. This must match the key of a key-value pair provided in the delivery pipeline or target config, or upon release creation.If you're using the Helm renderer with Skaffold, use the following syntax in your Helm template to add placeholders:\n```\n[PROPERTY]: \u00a0{{ .Values.VAR_NAME }} \n```\n### Add a parameter to the pipeline stage\nYou can add key-value pairs to a stage in the delivery pipeline progression. This is useful for [parallel deployments](/deploy/docs/parallel) , to distinguish among child targets.\n- Add the placeholders to your Kubernetes manifest or Cloud Run service, as described [here](#add_placeholders) .Here's an example:```\napiVersion: apps/v1kind: Deploymentmetadata:\u00a0name: nginx-deployment\u00a0labels:\u00a0 \u00a0app: nginxspec:\u00a0replicas: 1 # from-param: ${deploy_replicas}\u00a0selector:\u00a0 \u00a0matchLabels:\u00a0 \u00a0 \u00a0app: nginx\u00a0template:\u00a0 \u00a0metadata:\u00a0 \u00a0 \u00a0labels:\u00a0 \u00a0 \u00a0 \u00a0app: nginx\u00a0 \u00a0spec:\u00a0 \u00a0 \u00a0containers:\u00a0 \u00a0 \u00a0- name: nginx\u00a0 \u00a0 \u00a0 \u00a0image: nginx:1.14.2\u00a0 \u00a0 \u00a0 \u00a0ports:\u00a0 \u00a0 \u00a0 \u00a0- containerPort: 80\n```\n- Configure your delivery pipeline to include `deployParameters` for the applicable pipeline stage.The following YAML is the configuration for a pipeline stage whose target is a multi-target, which in this case has two child targets:```\nserialPipeline:\u00a0stages:\u00a0 \u00a0- targetId: dev\u00a0 \u00a0 \u00a0profiles: []\u00a0 \u00a0- targetId: prod \u00a0# multi-target\u00a0 \u00a0 \u00a0profiles: []\u00a0 \u00a0 \u00a0deployParameters:\u00a0 \u00a0 \u00a0 \u00a0- values:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0deploy_replicas: 1\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0log_level: \"NOTICE\"\u00a0 \u00a0 \u00a0 \u00a0 \u00a0matchTargetLabels: # optional, applies to all resources if unspecified; AND'd\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0my-app: \"post-render-config-1\"\u00a0 \u00a0 \u00a0 \u00a0- values:\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0deploy_replicas: 2\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0log_level: \"WARNING\"\u00a0 \u00a0 \u00a0 \u00a0 \u00a0matchTargetLabels: # optional, applies to all resources if unspecified; AND'd\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0my-app: \"post-render-config-2\"\n```In this delivery pipeline configuration, the `deployParameters` stanza includes two `values` , each of which has the following:- The variable name, which is the same name as the variable you set in the manifest\n- A value for that variable\n- One or more labels (optional) to match against target-specific labelsIf you don't specify a label, in a `matchTargetLabels` stanza, that value is used for all targets in the stage.\n- If you included `matchTargetLabels` , you also must [include labels on the targets](#add_to_target) , to match them. In this way, you identify which value to assign to which child target.The target must match labels set in the `values` stanza.If you omit `matchTargetLabels` , the `values` you set on the pipeline are applied to all child targets. But if you set more than one value for the same parameter, the release will fail.\nAfter each manifest is rendered, Cloud Deploy adds the value for each variable into the rendered manifest.\n### Add a parameter to the target configuration\nYou can add key-value pairs to a target. If you're using deploy parameters to distinguish among multiple child targets, configure them on those child targets, not on the multi-target.\n- [Configure](#add_placeholders) your Kubernetes manifest or Cloud Run service definition using a parameter in place of the value you want to set at deploy time.Here's an example:```\napiVersion: apps/v1kind: Deploymentmetadata:\u00a0name: nginx-deployment\u00a0labels:\u00a0 \u00a0app: nginxspec:\u00a0selector:\u00a0 \u00a0matchLabels:\u00a0 \u00a0 \u00a0app: nginx\u00a0template:\u00a0 \u00a0metadata:\u00a0 \u00a0 \u00a0labels:\u00a0 \u00a0 \u00a0 \u00a0app: nginx\u00a0 \u00a0spec:\u00a0 \u00a0 \u00a0containers:\u00a0 \u00a0 \u00a0- name: nginx\u00a0 \u00a0 \u00a0 \u00a0image: nginx:1.14.2\u00a0 \u00a0 \u00a0 \u00a0env:\u00a0 \u00a0 \u00a0 \u00a0- name: envvar1\u00a0 \u00a0 \u00a0 \u00a0 \u00a0value: example1 # from-param: ${application_env1}\u00a0 \u00a0 \u00a0 \u00a0- name: envvar2\u00a0 \u00a0 \u00a0 \u00a0 \u00a0value: example2 # from-param: ${application_env2}\n```In this manifest, the parameter `envvar1` is set to a default of `example1` , and `envvar2` is set to a default of `example2` .\n- Configure your [targets](/deploy/docs/terminology#target) to include `deployParameters` .For each parameter you're including, you identify the following:- The key name, which is the same name as the key (variable) you set in the manifest.\n- A value for that key. If you don't provide a value, the default value set in the manifest is used.\nThe following YAML is the configuration for two targets. Each target includes a `deployParameters` stanza setting a value. Each target also includes a label, to be matched with deploy parameters [configured on a pipeline stage](#add_to_pipeline_stage) .```\napiVersion: deploy.cloud.google.com/v1beta1kind: Targetmetadata:\u00a0 name: prod1\u00a0 labels:\u00a0 \u00a0 my-app: \"post-render-config-1\"description: development clusterdeployParameters:\u00a0 application_env1: \"newValue1\"---apiVersion: deploy.cloud.google.com/v1beta1kind: targetmetadata:\u00a0 name: prod2\u00a0 labels:\u00a0 \u00a0 my-app: \"post-render-config-2\"description: development clusterdeployParameters:\u00a0 application_env1: \"newValue2\"\n```\nWhen the release is created, but after the manifests are rendered, Cloud Deploy adds these values to the rendered manifests if they include the associated keys.\n### Pass a parameter at release creation\nFollow these steps to pass parameters and values to the release:\n- [Configure](#add_placeholders) your Kubernetes manifest or Cloud Run service definition using a parameter in place of the value you want to set at deploy time.Here's an example:```\napiVersion: apps/v1kind: Deploymentmetadata:\u00a0name: nginx-deployment\u00a0labels:\u00a0 \u00a0app: nginxspec:\u00a0selector:\u00a0 \u00a0matchLabels:\u00a0 \u00a0 \u00a0app: nginx\u00a0template:\u00a0 \u00a0metadata:\u00a0 \u00a0 \u00a0labels:\u00a0 \u00a0 \u00a0 \u00a0app: nginx\u00a0 \u00a0annotations:\u00a0 \u00a0 \u00a0commit: defaultShaValue # from-param: ${git-sha}\u00a0 \u00a0spec:\u00a0 \u00a0 \u00a0containers:\u00a0 \u00a0 \u00a0- name: nginx\u00a0 \u00a0 \u00a0 \u00a0image: nginx:1.14.2\n```In this example, the commit SHA is set as a variable called `${git-sha}` . A value for this is passed at release creation, using the `--deploy-parameters=` option, as seen in the next step.Syntax for this variable is `$` plus the variable name in braces. In this example, it's `${git-sha}` .\n- When you create a release, include the `--deploy-parameters` option on the `gcloud deploy releases create` command.`--deploy-parameters` takes a comma-separated list of key-value pairs, where the key is the placeholder you [added to the manifest](#add_placeholders) .The command will look similar to this:```\ngcloud deploy releases create test-release-001 \\--project=my-example-project \\--region=us-central1 \\--delivery-pipeline=my-params-demo-app-1 \\--images=my-app-image=gcr.io/google-containers/nginx@sha256:f49a843c290594dcf4d193535d1f4ba8af7d56cea2cf79d1e9554f077f1e7aaa \\--deploy-parameters=\"git-sha=f787cac\"\n```\nWhen the release is created, but after manifest rendering, Cloud Deploy provides the values to the rendered manifests if they include the associated keys.\n## View all parameters for a release\nYou can view the parameters that have been set for a given release. They're displayed in a table on the **Release details** page and on the command line ( `gcloud deploy releases describe` ).\n- From the main Cloud Deploy page, click the delivery pipeline that includes the release you want to see.\n- On the **Release details** page, select the **Artifacts** tab.\nAll deploy parameters that have been set for this release are shown in a table, with the variable name and value in one column, and the affected target or targets in the other column.\n## What's next\n- Try the [quickstart: Use deploy parameters](/deploy/docs/deploy-app-parameters) .\n- Find out more about using [parallel deployments](/deploy/docs/parallel) .", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Pipeline instances per release.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Pipeline instances per release", "url": "https://cloud.google.com/deploy/docs/pipeline-instances", "abstract": "# Cloud Deploy - Pipeline instances per release\nWhen you invoke Cloud Deploy to create a new release to be managed by your delivery pipeline, the pipeline and targets are preserved in their current state for that release. You can still edit your delivery pipeline and target definition files, but the changes that you make affect future releases only.\n**Note:** In addition to storing the pipeline instance with the release, Cloud Deploy also stores the execution environment, as [defined with the target](/deploy/docs/config-files#target_definitions) .\n", "content": "## Why does Cloud Deploy do this?\nTo keep your releases reliable and durable, the delivery pipeline and its associated resources are preserved at the time the release is created. This preservation prevents recent changes to the delivery pipeline definition from affecting the release in ways the generated manifests might not be able to accommodate.\n## Why does this matter?\nWhen a delivery pipeline is changed after your release is created, Cloud Deploy delivers the release according to the previous pipeline definition (as it was when the release was created) not the new definition. This behavior isn't a problem unless you, or someone else in your organization, expects the release to follow the updated pipeline behavior.\n## When does this matter?\n- When you promote a `release`When the release was first created, Cloud Deploy took a snapshot of the pipeline. That snapshot\u2014the \u2014is the version of the pipeline that controls the deployment cycle of that `release` .If anyone edit the pipeline, and then you promote the release to the next target, Cloud Deploy displays a warning informing you that the deployment might not behave as you expect. You can respond by confirming the promotion or canceling it.TODO: update this after we finalize the language\n```\n gcloud deploy releases promote \n  \u2026\n  WARNING: The delivery pipeline was modified since was created.\n  This release will promote based on the state of the delivery pipeline at the\n  time of release creation.\n  It will not be rolled out to the pipeline in its current state.\n  Promoting will result in .\n  Learn more at: https://cloud.google.com/deploy/docs/pipeline-instances\n  Are you sure you want to promote to ? Y/n\n```\nIf you confirm that you want to continue, then the release is promoted to the intended target cluster, with that target configured as defined when you created the `release` . That is, changes to the target do not affect that `release` .\n- When you approve a `rollout`As with promotion, if you approve a `rollout` and there's a mismatch between the pipeline instance associated with the release, and the current pipeline definition, Cloud Deploy displays a message telling you about the mismatch. You can confirm or cancel the approval.\n- When you roll back a `release` .If a delivery pipeline or target is changed after a `rollout` , and you try to roll back, there will be a pipeline mismatch. Cloud Deploy will prompt you to confirm you really want to roll back. In this case, we strongly recommend you examine the change to the delivery pipeline or target before rolling back.", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Promote your release and manage approvals.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Promote your release and manage approvals", "url": "https://cloud.google.com/deploy/docs/promote-release", "abstract": "# Cloud Deploy - Promote your release and manage approvals\nThis page describes how to promote an existing Cloud Deploy release to the next target in a delivery pipeline [progression](/deploy/docs/terminology#progression) .\n", "content": "## Before you begin\nThis page assumes you have already [created a release](/deploy/docs/deploying-application#invoke_your_delivery_pipeline_to_create_a_release) .\n## Promote the release\nWhen your release is deployed into a target defined in your delivery pipeline, you can promote it to the next target:\n```\ngcloud deploy releases promote --release=RELEASE_NAME \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--delivery-pipeline=PIPELINE_NAME \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--region=REGION\n```\nWhere:\n`` is the name of the release you're promoting.\n`` is the name of the delivery pipeline you're using to manage deployment of this release.\n`` is the name of the region in which the release was created, for example `us-central1` . This is required.\nSee the Google Cloud SDK reference for more information about the [gcloud deploy releases promote command](/sdk/gcloud/reference/deploy/releases/promote) .\n **Note:** you can also include `--to-target=` `` to specify a destination target. If you omit `--to-target` , the release is promoted to the next target in the promotion sequence.- [Open the Deliverypipelines page](https://console.cloud.google.com/deploy/delivery-pipelines) .\n- Click your pipeline shown in the list of delivery pipelines.The Delivery pipeline details page shows a graphical representation of your delivery pipeline's progress.\n- On the first target in the delivery pipeline visualization, click **Promote** .The **Promote release** dialog is shown. It shows the details of the target you're promoting to.\n- Click **Promote** .\nIf the delivery pipeline or target has changed since the release was created, Cloud Deploy returns a message indicating a possible [mismatch](/deploy/docs/pipeline-instances#when_does_this_matter) , and prompts you to confirm the promotion. You can respond `n` to the prompt and examine the differences between the pipeline versions before you proceed. If you choose to promote anyway, the release is deployed according to the delivery pipeline as it was defined when the release was created. See [Pipeline instances per release](/deploy/docs/pipeline-instances) for more information about pipeline mismatches.\nCloud Deploy creates a `rollout` for the release into the destination target, and the release is queued for deployment. When it's deployed, the delivery pipeline visualization shows that fact:\n## Manage approvals for a delivery pipeline\nYou can require approval for any target, and you can approve or reject releases into that target.\nApprovals can be managed programmatically by integrating your workflow management system (such as ServiceNow), or other system, with Cloud Deploy using Pub/Sub and the Cloud Deploy API.\n### Require approval\nTo require approval on any target, set `requireApproval` to `true` in the target configuration:\n```\n\u00a0 \u00a0 \u00a0apiVersion: deploy.cloud.google.com/v1\u00a0 \u00a0 \u00a0kind: Target\u00a0 \u00a0 \u00a0metadata:\u00a0 \u00a0 \u00a0 name:\u00a0 \u00a0 \u00a0description:\u00a0 \u00a0 \u00a0requireApproval: true\n```\nSee [Delivery pipeline configuration](/deploy/docs/config-files#requireapproval) for further details.\nWhen a rollout is pending approval, users or systems that subscribe to the `clouddeploy-approvals` Pub/Sub topic receive notification and can then approve or reject the rollout.\nWhen using [parallel deployment](/deploy/docs/parallel) , you can configure the multi-target to [require approval](/deploy/docs/parallel#approvals_for_parallel_deployment) . If promotion to the target is rejected, the controller rollout fails, with a state of `APPROVAL_REJECTED` , and the child rollouts are not created.\n### Approve or reject a rollout\nEach target can [require approval](/deploy/docs/promote-release#require_approval) before any release is deployed to it. When you promote to a target that requires approval, Cloud Deploy publishes a Pub/Sub message to the `clouddeploy-approvals` topic.\nAny user or service account with the role `roles/clouddeploy.approver` can approve a Cloud Deploy rollout to a target that requires approval.\nYour integrated workflow management system, having received an approval-required notification using [service notifications](/deploy/docs/subscribe-deploy-notifications) , can approve or reject the rollout using the Cloud Deploy API.- In the Google Cloud console, navigate to the Cloud Deploy **Delivery pipelines** page to view of list of your available delivery pipelines. [Open the Delivery pipelines page](https://console.cloud.google.com/deploy/delivery-pipelines) The list of delivery pipelines is shown in Google Cloud console. Delivery pipelines that have been configured but not [registered](/deploy/docs/deploying-application#defining_your_delivery_pipeline) with the Cloud Deployservice are not shown.\n- Click the name of the delivery pipeline.The pipeline visualization is shown. If approval is pending, and if you have the `roles/clouddeploy.approver` role, or equivalent permissions, the visualization includes a **Review** link.\n- Click **Review** .A list is shown of rollouts pending approval.\n- Click **Review** .The Approve rollout screen is shown.The **Manifest diff** tab shows any changes to the rendered manifest from the currently deployed version (if any) to the one you're now approving (or rejecting).\n- Click **Approve** or **Reject** .If you approve, your application is deployed into the target. If you reject, the application is not deployed, and can't be approved later unless re-promoted.\nA user with the `roles/clouddeploy.approver` role can manually approve or reject a rollout. To approve:\n```\ngcloud deploy rollouts approve rollout-name --delivery-pipeline=pipeline-name \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--region=region \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0--release=release-name\n```\nTo reject:\n```\ngcloud deploy rollouts reject rollout-name --delivery-pipeline=pipeline-name \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 --region=region \\\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 --release=release-name\n```", "guide": "Cloud Deploy"}

Google-Cloud-Platform-Document/Cloud Deploy/Cloud Deploy - Quickstarts.json

@@ -0,0 +1 @@
+{"title": "Cloud Deploy - Quickstarts", "url": "https://cloud.google.com/deploy/docs/quickstarts", "abstract": "# Cloud Deploy - Quickstarts", "content": "\n", "guide": "Cloud Deploy"}