Deploy a Helm-based Application with Oracle Cloud Infrastructure DevOps

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 deploy-helm-based-app.png follows
Description of the illustration deploy-helm-based-app.png

The architecture has the following components:

  • Region

    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 stages

    Build stages are individual actions that take place during a run of a build pipeline. The OCI DevOps build pipeline includes three stages:
    1. Build Container: Executes build_spec.yaml instructions to compile, build and prepare necessary artifacts.
    2. Upload Artifacts: Uploads all the prepared artifacts like docker images are pushed to the configured Oracle Cloud Infrastructure Registry repository.
    3. Trigger Deployment: Triggers the deploy pipeline to apply the changes to the configured OKE.
  • 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 Helm to deploy the Kubernetes application using Helm Chart. Helm Chart URL and optional values.yaml file 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 values.yaml file.

  • 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

    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.yaml file 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.

    This architecture uses an OKE cluster as an environment. Environments can be in different OCI regions from the region of the deployment pipeline. This allows developers to deploy in multiple OCI regions using the same deployment pipeline.


Use the following recommendations as a starting point. Your requirements might differ from the architecture described here.
  • 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 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

    Artifacts to deploy with Oracle Cloud Infrastructure DevOps must be in an Oracle Cloud Infrastructure Artifacts Registry or container image registry repository.

  • Projects

    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 Manager:
    1. Click Deploy to Oracle Cloud.

      If you aren't already signed in, enter the tenancy and user credentials.

    2. Select the region where you want to deploy the stack.
    3. Follow the on-screen prompts and instructions to create the stack.
    4. After creating the stack, click Terraform Actions, and select Plan.
    5. 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.

    6. If no further changes are necessary, return to the Stack Details page, click Terraform Actions, and select Apply.
  • Deploy using the Terraform code in GitHub:
    1. Go to GitHub.
    2. Clone or download the repository to your local computer.
    3. Follow the instructions in the README document.


Author: Ashok Raja CM

Contributor: Saurabh Shah, Lukasz Feldman