Rapid delivery of software is essential for efficiently running your applications in the cloud. Automating software releases with pipeline deployment increases developer productivity and allows you to release features more frequently and with fewer errors. It helps avoid downtime during deployments and automates the complexity of updating applications.
Oracle Cloud Infrastructure DevOps service provides an end-to-end continuous deployment experience to developers. Oracle Cloud Infrastructure DevOps service includes deployment pipelines to automate your continuous software delivery and deployment process (CD) to Oracle Cloud Infrastructure (OCI) platforms: Oracle Cloud Infrastructure Container Engine for Kubernetes, Oracle Functions, and Oracle Cloud Infrastructure Compute instances.
Customers migrating workloads from on-premises or other clouds to OCI and customers developing new applications on OCI can use Oracle Cloud Infrastructure.
This architecture shows a sample NodeJS application deployed with Helm Chart from the Code Repository using the Oracle Cloud Infrastructure (OCI) DevOps service. The application is deployed to Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) cluster. To simplify the process, we use Terraform for infrastructure automation.
The following diagram illustrates this reference architecture.
Description of the illustration deploy-helm-based-app.png
The architecture has the following components:
An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).
- Virtual cloud network (VCN) and subnets
A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.
- OCI DevOps project
An OCI DevOps project is a logical grouping of resources needed to implement your continuous integration and deployment (CI/CD) workload. OCI DevOps resources can be artifacts, deployment pipelines, and environments. OCI DevOps projects make it easy to enable logging, monitoring, and notifications for your OCI 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 define 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 stagesBuild stages are individual actions that take place during a run of a build pipeline. The OCI DevOps build pipeline includes three stages:
- Build Container: Executes
build_spec.yamlinstructions to compile, build and prepare necessary artifacts.
- Upload Artifacts: Uploads all the prepared artifacts like docker images are pushed to the configured Oracle Cloud Infrastructure Registry repository.
- Trigger Deployment: Triggers the deploy pipeline to apply the changes to the configured OKE.
- Build Container: Executes
- Deployment pipeline
A deployment pipeline holds the requirements that must be satisfied to deliver a set of artifacts to an environment. Pipelines contain stages, which are the building blocks of a pipeline. A Pipeline can have stages that run serially or in parallel, so you can control the flow and logic of your software release.
- Deployment stages
Stages are individual actions that take place during a run of a pipeline. The OCI DevOps deployment pipeline includes only one predefined stage called
Deploy Helmto deploy the Kubernetes application using Helm Chart. Helm Chart URL and optional
values.yamlfile OCI DevOps artifacts are sent as arguments to the Deploy Helm stage. During the execution, Deploy Helm stage fetches the Helm chart from the Oracle Cloud Infrastructure Registry and applies the same to the configured OKE OCI DevOps environment with an optionally provided
- DevOps artifact
An OCI DevOps artifact is a reference or pointer to any file, binary, package, manifest, or image that makes up your application. When creating an artifact, you must inform OCI DevOps of the source location of the actual artifact. OCI DevOps supports OCI Container Registry and OCI Artifacts Registry repositories.
- Artifact repository
The Artifact Repository creates repositories to group similar artifacts. You can upload artifacts to the repositories after they're created. These artifacts are a collection of text files, binaries, and deployment manifests that will be 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.
Helm is a package manager for Kubernetes that manages application deployment as a set of Helm charts, which lets you manage the various individual services and their lifecycles easily.
The Helm module for Oracle Linux installs Helm into a Kubernetes module (cluster).
- Helm Chart
Kubernetes YAML manifests combined into a single package that can be deployed to your Kubernetes clusters. Helm charts contain templates of Kubernetes YAML manifest files and a
values.yamlfile to supply the default template values. Use Helm charts to deploy an application or one component of a larger application.
- OCI Logging and OCI Notifications services
Oracle Cloud Infrastructure Logging and Oracle Cloud Infrastructure Notifications services store 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.
- Deployment environments
An environment is a collection of a customer’s computing resources where artifacts are deployed. Environments can be a function, Compute virtual machine (VM) or bare metal instance, or an OKE cluster.
Oracle Kubernetes cluster (OKE): OCI Container Engine for Kubernetes is a fully managed, scalable, and highly available service that you can use to deploy your containerized applications to the cloud.
Compute instances: The OCI Compute service enables you to provision and manage compute hosts in the cloud. You can launch Compute instances with shapes that meet your resource requirements for CPU, memory, network bandwidth, and storage.
Functions: Oracle Functions is a fully managed, multi-tenant, highly scalable, on-demand, Functions-as-a-Service platform. It's built on enterprise-grade OCI and powered by the Fn Project open source engine.
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 OKE cluster. You can also use a private VCN. In that case, use a NAT gateway to give the cluster access over the public internet.
- Compute shapes
This architecture uses an Oracle Linux OS image with an 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.
- Kubernetes (OKE)
This architecture deploys to the OKE cluster as the target endpoint. The worker nodes are deployed on an 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.
- 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. In this architecture, the same container registry is used to store Helm charts too.
- Artifact registry
This architecture creates an artifact for the software and configuration used by an OKE cluster. 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.
Consider the following points when deploying this reference architecture.
- Oracle Cloud
Infrastructure DevOps supported deployments
DevOps supports deployments to Kubernetes (OKE), Compute hosts, and Oracle Functions. This architecture deploys to an OKE cluster using Helm Chart. Consider deploying to other endpoints based on the requirements.
- Supported hosts
Only Linux hosts are supported for instance group deployments to Oracle Cloud Infrastructure Compute instances.
Artifacts to deploy with Oracle Cloud Infrastructure DevOps must be in an Oracle Cloud Infrastructure Artifacts Registry or container image registry repository.
The best practice is to group each application and all of its microservices into a single project.
The Terraform code for this reference architecture is available in GitHub.
- Deploy using the sample stack in Oracle Cloud Infrastructure Resource
- Click .
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 .
- Deploy using the Terraform code in GitHub:
- Go to GitHub.
- Clone or download the repository to your local computer.
- Follow the instructions in the
Learn more about the Oracle Cloud Infrastructure DevOps service, see the following resources: