DevOps on Google Cloud

DevOps is a set of practices that combines software development (Dev) and IT operations (Ops). Its goal is to shorten the development lifecycle and provide continuous delivery with high software quality. On Google Cloud, DevOps is implemented through a suite of tools that automate the build, test, deployment, and monitoring of applications. The core philosophy is to break down silos between teams, automate repetitive tasks, and establish feedback loops.

A continuous integration and continuous delivery (CI/CD) pipeline is the backbone of DevOps. In Google Cloud, this pipeline typically consists of:

Cloud Build - Build triggers: Can be set to run on push to a branch, tag creation, or pull request. - Timeout: Default 10 minutes, max 24 hours. - Machine types: E2_HIGHCPU_8 (8 vCPUs, 8 GB memory) is default. Others include E2_HIGHCPU_32 and N1_HIGHCPU_32. - Logs: Stored in Cloud Logging; can be viewed in Console or gcloud builds log. - Build artifacts: Can be stored in Cloud Storage bucket.

Container Registry / Artifact Registry - Image format: Docker V2 and OCI. - Regions: Multi-regional (e.g., gcr.io) or regional (us.gcr.io). - Vulnerability scanning: Enabled by default for new images; uses Container Analysis. - Retention: No automatic deletion; must be configured via lifecycle policies.

Cloud Operations - Cloud Monitoring: Collects metrics from GCP services, custom metrics, and agent-based metrics. Default retention for metrics is 6 weeks for most, but can be extended. - Cloud Logging: Retains logs for 30 days (free tier) or 365 days (paid tier). - Cloud Trace: Samples traces by default at 10% rate; can be adjusted. - Error Reporting: Groups similar errors automatically.

Building with Cloud Build

# Submit a build using cloudbuild.yaml
gcloud builds submit --config cloudbuild.yaml .

# View build logs
gcloud builds log BUILD_ID

# List builds
gcloud builds list

Example cloudbuild.yaml:

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/$PROJECT_ID/my-image', '.']
- name: 'gcr.io/cloud-builders/docker'
  args: ['push', 'gcr.io/$PROJECT_ID/my-image']
- name: 'gcr.io/cloud-builders/kubectl'
  args: ['set', 'image', 'deployment/my-deployment', 'my-container=gcr.io/$PROJECT_ID/my-image']
  env:
  - 'CLOUDSDK_COMPUTE_ZONE=us-central1-a'
  - 'CLOUDSDK_CONTAINER_CLUSTER=my-cluster'

Working with Container Registry

# Tag and push an image
docker tag my-image gcr.io/my-project/my-image:latest
docker push gcr.io/my-project/my-image:latest

# Pull an image
docker pull gcr.io/my-project/my-image:latest

# List images in registry
gcloud container images list --repository=gcr.io/my-project

Monitoring with Cloud Operations

# Create a monitoring policy
gcloud alpha monitoring policies create --policy-from-file policy.yaml

# View logs
gcloud logging read "resource.type=gae_app AND severity>=ERROR" --limit 10

DevOps on Google Cloud integrates tightly with:

- Fetches dependencies. - Runs unit tests. - Builds a Docker image. - Pushes the image to Container Registry. 4. Cloud Build then deploys the image to GKE by updating a deployment. 5. After deployment, Cloud Operations begins monitoring application metrics and logs. 6. If an error is detected, Error Reporting sends an alert via Cloud Monitoring. 7. The developer can roll back to a previous image using kubectl rollout undo or by triggering a previous build.

DevOps relies on IaC to manage environments consistently. Google Cloud Deployment Manager and Terraform are used to define infrastructure in declarative templates. These templates are version-controlled and applied through CI/CD pipelines, ensuring that staging and production environments are identical and reproducible.

Cloud Operations provides a unified view of application health. Uptime checks can monitor external endpoints. Custom dashboards can display key metrics like request latency, error rate, and CPU usage. Alerts can be configured to notify on-call engineers via email, SMS, or PagerDuty. This feedback loop allows teams to detect and fix issues quickly, completing the DevOps cycle.

A large e-commerce company uses Google Cloud to run its website. The development team releases updates every two weeks. They use Cloud Source Repositories for code, Cloud Build for CI/CD, and GKE for deployment. The pipeline builds a Docker image, runs unit and integration tests, and deploys to a staging cluster. After manual approval, Cloud Deploy promotes the release to production using a blue-green strategy. Cloud Operations monitors the site; if error rates spike after a release, an alert triggers an automatic rollback. This setup reduced release time from weeks to days and improved uptime.

A bank uses Artifact Registry with vulnerability scanning to ensure no images with critical CVEs are deployed. Their Cloud Build pipeline includes a step that checks the vulnerability scan results; if any critical vulnerability is found, the build fails. Images are signed using Binary Authorization, ensuring only signed images are deployed to GKE. Cloud Operations logs are retained for 365 days to meet audit requirements. This approach helps the bank maintain security and compliance while still deploying frequently.