Implement CI / CD for reliable releases
Continuous Integration
CI is a developer workflow in which developers frequently pull from the master and commit their changes into a feature branch. These commits triggers are built in a build system such as Jenkins.
The build process creates a new application image by using Cloud Build and stores it in an artifact repository such as container registry. A deployment system such as Spinnaker deploys the artifacts in your cloud environment.
You can use deployment manager to stand up the resources for the managed services that your app needs.
After your app is deployed in your development environment, you can automatically run tests to verify your code.
If all test pass, you can join the feature branch into master.
Continuous Delivery
CD is a workflow that is triggered when changes are pushed to the master repository. The build system builds the code and creates application images.
The depoyment system deploys the application images to the staging environment and runs integration tests, performance tests and more.
If all test pass, the build is tagged as a release candidate to build.
You can manually approve a release candidate build.
This approval can trigger deployment to production environments as a canary or blue-green release. You can monitor the performance of your app and print in the prod environments by using monitoring services such as StackDriver.
If the new deployment functions optimally, you can switch over your entire traffic to this new release. But if you discover problems, you can also quickly roll back to the last stable release.
Continuous Deployment
It varies very slightly in that there’s no manual approval process. The deployment system automatically deploys release candidates to the production environment.
Containers
Container-based virtualization is an alternative to hardware virtualization as in traditional VMs (Virtual Machines). VMs are isolated from one another in part by having each VM have its own instance of the OS.
But OS can be slow and resource heavy.
Containers respond to this problem by using OS built-in capabilities to isolate environments from one another.
A process is a running program. The memory address spaces of running processes have long been isolated from one another. Containers build on this isolation.
They take advantage of additional OS features that give processes the capability to have their own namespaces. And that gives a supervisor process the ability to limit other processes access to resources.
Containers start much faster than VMs and use fewer resources. Because each container does not have its own version of the OS.
Why use Containers for deployment?
What do Containers offer?
-
Consistency
Across development, testing and production environments -
Loose Coupling
Between application and OS layers -
Workload migration Simplified between on-premises and cloud environments
-
Agility
Agile development and operations
What does containers provide that VMs don’t?
-
Simple deployment
By packaging your app as a singularly addressable, registry stored, one command line, deployable component. Containers radically simplify app deployments. -
Rapid availability
By abstracting just the OS instead of the whole physical computer. -
Further subdivide compute resources
Leverage microservices, if a micro VM seems overkill or if scaling an entire VM at a time, seems like a big step function. Containers will make a big positive impact in your system
Build Pipelines with Cloud Build and Deployment manager
Use Cloud Build and Container Registry to create application images
The container image for your application is a complete package that contains the app binary and all the software that’s required for it to run. When you deploy the same container image on your development, test and prod environments, you can be sure that your app will perform exactly the same way in all of them.
Cloud Build is a service that enables you to set up build pipelines to create a Docker container image for your app and push the image to a Google Cloud Container Registry. You don’t need to download tools and images to build a machine or manage your build infrastructure.
By using Container Registry and Cloud Build, you can create build pipelines that are automatically triggered when you commit to a repository.
In Container Registry, you can create a build trigger that is executed based on a trigger type. a trigger type specifies whether build should be triggered based on commits to a particular branch in a repo or commits that contain a particular tag.
You must also create a build config file that specifies the steps in the build pipeline. Steps are analogous to commands or scripts that you execute to build your app. Each build step is a Docker container that’s invoked by Cloud Build when the build is executed. The step name identifies the container to invoke for the build step. The images attribute contains the name of the container image to be created by this build config.
Cloud Build enables you to specify different types of source repositories, tag container images to enable searches, and create build steps that perform operations such as downloading and processing data without even creating a container image. The build config can be specified in either YAML or JSON format.
Cloud Build mounts your source code into the /workspace directory of the Docker container associated with the build step. The artifacts produced by each build step are persisted in the /workspace folder, and can be used by the following build step.
Cloud Build automatically pushes the buit container image to container registry. In Container Registry you can view the status and history of builds.
Cloud Build also publishes built status notifications to Cloud Pub/Sub. You can subscribe to these notifications to take action based on build status or other attributes.
Use Deployment Manager to launch your GCP resources
Deployment Manager enables you to launch VM instances based on container images taht are created by your build pipeline. You can also use Deployment Manager to launch other GCP resources that are required by your app.
The Deployment Manager API is integrated into the GCP. A deployment config defines the Cloud resources to provision. This config includes the type and properties of the resources that are part of the deployment. A deployment configuration consists of a top-level config file, YAML syntax templates, and additional files.
You can declare all your resources in the top-level config file for simple deployments. For more complex configs or to create reusable chunks of config, you can create templates that create subsets of configuration. You can then import one or mroe templates to construct your complete config. Deployment Manager will then expand these templates to create your final config. These reusable templates can be developed using Jinja or Python syntax. They’re used to generate YAML config.
Benefits of using Deployment Manager
-
You can reuse and configure resources differently for each environments
You can create test and prod environments by using the same deployment config with different template properties, env variables and conditions -
For complex deployments you can specify dependencies between resources The creation of a VM might depend on the creation of persistent disks
-
You can specify startup scripts that are run when the VM launches They may download software or run other commands
-
You can declare outputs for the template You can expose the IP address of a database created in a template so that others scripts can connect to this databse