Cloud Deploy: Policies,Deployments and Security
1. Cloud Deploy: Policies,Deployments and Security
Cloud Deploy is a tool with a wide range of features and capabilities. Let's look at how to configure policies, canary deployments, and security. We will also look at how security is implemented in Cloud Deploy. In the deployment policy YAML file, you can restrict rollouts to specific times. This example targets a previous delivery pipeline. A rollout restriction rule is defined to restrict all rollouts in the helloworld-pipeline resource for the next 10 years. If a policy is too strict, it may result in an error output. You can override policies by adding the --override-deploy-policies flag when promoting a release. Users must be granted the roles/clouddeploy.policy admin role for the override comment to work. This override ignores the deploy policy and creates the rollout to the prod target. You can verify deployments in the skaffold.yaml configuration file by creating an echo command to run after a successful deployment. The output appears under the text payload log in that release's delivery pipeline details. Deployment hooks are also defined in the skaffold.yaml file. Deployment hooks allow you to execute actions before and after application deployments for greater control and automation. These actions are configured to run at specific stages of the deployment process, providing flexibility for tasks like predeployment validation or post-deployment integration testing. In your Cloud Deploy delivery pipeline, reference the skaffold.yaml configurations to specify when hooks should run-- predeploy or post deploy. Cloud deploy executes hooks within the designated environment, which can be the application's GKE cluster. In a delivery pipeline, successful releases are promoted to the next stage in the pipeline, and unsuccessful releases are abandoned. For example, a release might be promoted to a testing environment to ensure that the application functions properly. If successful, it's promoted to prod, and if unsuccessful, it's abandoned. You can use the gcloud deploy releases promote command to promote a release and advance it by a single stage in the pipeline. When a release is promoted to the final stage in the pipeline, approval is required to ensure untested code is not released to production. Approval is granted using the gcloud deploy rollouts approve command. If a release fails the required tests, use the gcloud deploy releases abandon command to abandon the release. New rollouts can't be created from abandoned releases, and they can't be rolled back to. Existing rollouts of abandoned releases are unaffected. A common deployment strategy in Cloud Deploy is the canary strategy, in which new versions are rolled out to users gradually. A small subset of users receives the new version, while the majority of users continue to use the stable existing version. Cloud Deploy uses service mesh technologies like Cloud Service Mesh or Istio to split traffic by directing a specified percentage to the subset of users. Cloud Deploy uses IAM for security, enabling finegrained control of user access to resource levels. This allows management to define which users can create, promote, and approve releases. You can use different service accounts for render and deploy operations for each pipeline. These service accounts can target different environments and limit access. Third-party integration support is available through notifications, enabling you to manage approvals from inside your existing tool or other ticketing solutions. And Cloud Deploy integrates with Cloud Logging for full visibility and records of user actions.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.