Understand Modern App Deployment Strategies With Oracle Cloud Infrastructure DevOps
Rapid delivery of software is essential for efficiently running your applications in the cloud. Oracle DevOps service provides a continuous integration and deployment (CI/CD) platform for developers you can use to easily build, test, and deploy software and applications on Oracle Cloud.
DevOps build and deployment pipelines reduce change-driven errors and decrease the time customers spend on building and deploying releases. The service also provides private Git repositories to store your code and supports connections to external code repositories. Whether you're migrating workloads to OCI (from on-premises or other clouds) or developing new applications on OCI, you can use the DevOps service to simplify your software delivery lifecycle.
Architecture
This Reference Architectures describes two different deployment strategies, the Blue-Green strategy and the Canary strategy.
Deployment strategies are models and practices that enable modification or upgrade of application. They allow DevOps teams to define how applications get deployed to the production environment. Choosing between different deployment strategies allows admins to make the right trade-off between the risk of deploying a new release, the impact of the new release on its users, and the infrastructure overhead needed to implement the strategy. The strategies presented here give customers more options for making the right trade-off, given their application needs.
Blue-Green Deployment
A Blue-Green deployment strategy allows DevOps teams to release a new version of their application by using two identical environments where one of them is active at a given time. The current version of the application is provisioned on the active environment, whereas the new version gets deployed to the standby environment.
Deploying to the standby environment does not impact the active environment or the user traffic. The DevOps release pipeline can run validation tests against the new version, and once approved, it gets promoted to production by simply switching the user traffic to the standby environment. This process will repeat for each new release of the application.
The main advantage of this strategy is that it offers near-zero downtime and instant rollback capabilities. If any issues with the new version arise, traffic can instantly revert to the previous stable version. Moreover, the standby environment is available for debugging issues with the application release.
- It enables quick and risk-free deployments.
- It offers an effective and simple rollback mechanism.
- It's an effective way to orchestrate A/B software testings.
- It requires little to no downtime, as the production is always served by one of the active environments (controlled by a load balancer).
- Running identical environments is expensive and maintenance is resource-intensive.
- When managing a release between two identical environments, you need to closely monitor both environments.
- Managing database dependencies between deployments can be complicated.
This diagram illustrates a Blue-Green deployment architecture:
Description of the illustration blue-green-deployment.png
Canary Deployment
With a Canary deployment strategy, the application release happens incrementally to a subset of users. Initially, the new version gets deployed to a canary environment with no user traffic. The DevOps release pipeline can run validation tests against the new version and, once ready, route only a subset of users to the canary environment.
This technique allows the DevOps team to evaluate the new application version against real user traffic. They can compare the two application versions side-by-side before rolling out the new version to a larger user base. It also offers risk mitigation, as the new version is only enabled for a small subset of users. These users can easily switch back to the previous version if any issues arise.
- You can test two application versions side-by-side with real users.
- Zero downtime for new version releases.
- Rollback to a previous version is very easy and carries the least risk.
- Testing and validating a new release at scale can be complex.
- Fetching feedback from user testing against a new release is time consuming.
The following diagram illustrates a Canary deployment strategy:
Description of the illustration canary-deployment.png
- Region
An OCI region is a localized geographic area that contains one or more datacenters, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents). The architecture uses a single region.
- DevOps project
A logical grouping of DevOps resources required to implement a CI/CD workflow. DevOps resources can be artifacts, build pipelines, deployment pipelines, external connections, triggers, and environments. DevOps projects make it easy to enable logging, monitoring, and notifications for all your DevOps resources.
- Build pipeline
A build pipeline takes a commit ID from your source code repositories and uses that source code to run your build instructions. Build pipelines defines a set of stages for the build process: building, testing and compiling software artifacts, delivering artifacts to OCI repositories, and, optionally, triggering a deployment. You define the flow and instructions of your build run in the build spec file.
- Build stagesStages are individual actions that take place during a pipeline run. Various build stages mentioned here are:
- Managed Build Stages: A managed build stage for building and testing the source code.
- Deliver Artifacts Stage: A stage to push the outputs of build stage to various repositories; for example, container images to the container repo or the deployment manifest to the artifact registry.
- Invoke Deployment: A stage to invoke a deployment pipeline once the build stages are completed ,along with parsing the exported variables from managed build stage to deployment pipeline stages.
- Code repository
Private Git repositories hosted by the DevOps service. You can store, manage, develop source code with these DevOps Code Repositories.
- Deployment pipeline
A sequence of steps for delivering and deploying a set of artifacts to a target environment. The flow and logic of your software release can be controlled by defining stages that can run in serial or parallel.
- Deployment stages
Stages are individual actions that take place during a run of a pipeline. Build stages for Blue-Green deployments are:
- Blue/Green OKE Deployment or Blue/Green Instance Group Deployment: Stage where you deploy the updated code to target environments.
- Deployment Validation: An optional stage where you can use Functions to validate the deployments.
- Control: Approval: A control stage for approving deployment to the target production environment.
- Blue/Green OKE Traffic Shift or Blue/Green Instance Group Traffic Shift: The final stage, wherein production traffic is switched to the latest deployed environment.
- Canary OKE Deployment or Canary Instance Group Deployment: Stage where you deploy the updated code to target environments.
- Deployment Validation: An optional stage where you can use Functions to validate the deployments.
- Canary OKE Traffic Shift or Canary Instance Group Traffic Shift: Stage where, based on the ramp limit (% of traffic to shift), you switch traffic toward the Canary environment.
- Control: Approval: A control stage for approving deployment to the target production environment.
- Canary Deploy Instance Group Production or OKE Deploy Production: The final stage, wherein production traffic is switched to the latest deployed environment.
- DevOps artifact
A DevOps artifact is a reference or pointer to any file, binary, package, manifest, or image that makes up your application. When creating an artifact, inform Oracle DevOps of the source location of the actual artifact. DevOps supports OCI Container Image Registry and OCI Artifact Registry repositories.
- Artifact repository
The Artifact Repository creates repositories to group similar artifacts. Once created, you can upload artifacts to this repository. These artifacts are a collection of text files, binaries, and deployment manifests that are delivered to the target deployment environment. Each artifact has a name, which is made of its path: version. The path is a string to organize the artifacts.
- OCI Logging and Notification services
OCI Logging service stores logs related to the deployment. The deployment runtime output and the final results of the deployment are shown as log entries. OCI Notifications service provides visibility into the latest state of the deployment project and its resources and takes any necessary action. For example, you're notified when an important event, such as a stage in a deploy pipeline waiting for approval. When you receive the notification message, you can go to DevOps deployment pipelines and approve the stage.
- Deployment environments
This environment is a collection of the computing resources where artifacts are deployed. Environments can be a function, Compute virtual machine (VM) or bare metal instance, or an OKE cluster.The Blue-Green deployment is available only with OKE cluster and Compute virtual machines.
Recommendations
- Compute shapes
This architecture uses an Oracle Linux OS image with either an E3 or E4 flex shape with minimum resources to host compute hosts in the OKE cluster nodes. If your application needs more memory or cores, you can choose a different shape.
- VCN
When you create a VCN, determine the number of CIDR blocks required and the size of each block based on the number of resources that you plan to attach to subnets in the VCN. Use CIDR blocks that are within the standard private IP address space. After you create a VCN, you can change, add, and remove its CIDR blocks. This architecture uses a public VCN to host Oracle Container Engine for Kubernetes. You can also use a private VCN. In that case, use a NAT gateway to give the cluster access over the public internet.
- Oracle Container Engine for
Kubernetes (OKE)
This architecture deploys to the OKE cluster as one of the target environments. The worker nodes are deployed on an E3 or E4 Oracle Linux OS. This architecture uses three worker nodes in the cluster, but you can create up to 1,000 nodes on each cluster.
- Instance group
If you choose this architecture to deploy to an instance group, a new Compute instances with your choice of shape is created in your tenancy.
- Container Image Registry
This architecture deploys Registry as a private Docker registry for internal use. Docker images are pushed to and pulled from the registry. You can also use Registry as a public Docker registry, enabling any user with internet access and knowledge of the appropriate URL to pull images from public repositories in Oracle Cloud.
- Artifact registry
This architecture creates an artifact for the software and configuration used by an instance group, OKE, and Functions deployment. The architecture creates an artifact registry repository for internal use. Software binaries, text, and deployment configurations are uploaded to and downloaded from the artifact registry repository.
Considerations
When using Oracle DevOps service to deploy a continuous integration and deployment (CI/CD) platform, consider these factors.
- DevOps-supported deployments
DevOps supports deployments to OKE, Compute hosts, and Functions. This architecture deploys to an OKE cluster. Consider deploying to other endpoints based on your specific requirements.
- Linux support
Only Linux hosts are supported for instance group deployments to Compute instances.
- Deployed artifacts
Artifacts to deploy with DevOps need to be in an OCI artifact registry or container image registry repository.
- Grouping applications
As a best practice, group each application and all its microservices into a single project.
Deploy
The Terraform code for this reference architecture is available as a sample stack in Oracle Cloud Infrastructure Resource Manager. You can also download the code from GitHub, and customize it to suit your specific requirements.
- Deploy using the sample stack in Oracle Cloud Infrastructure Resource
Manager:
- Click the button that corresponds to your desired
deployment strategy and then follow the instructions in steps 2-6:
For... Click... Canary Instances 
Canary OKE Blue-Green Instances Blue Green OKE If you aren't already signed in, enter the tenancy and user credentials.
- Select the region where you want to deploy the stack.
- Follow the on-screen prompts and instructions to create the stack.
- After creating the stack, click Terraform Actions, and select Plan.
- Wait for the job to be completed, and review the plan.
To make any changes, return to the Stack Details page, click Edit Stack, and make the required changes. Then, run the Plan action again.
- If no further changes are necessary, return to the Stack Details page, click Terraform Actions, and select Apply.
- Click the button that corresponds to your desired
deployment strategy and then follow the instructions in steps 2-6:
- Deploy using the Terraform code in GitHub:
- Go to GitHub.
- Clone or download the repository to your local computer.
- Follow the instructions in the
READMEdocument.