Rapid delivery of software is essential for efficiently running your applications in the cloud. Oracle Cloud Infrastructure (OCI) DevOps services provide a continuous integration and deployment (CI/CD) platform for developers to easily build, test, and deploy software and applications on Oracle Cloud.
OCI DevOps build and deployment pipelines reduce change-driven errors and decrease the time customers spend on building and deploying releases. The service also provides a 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 OCI DevOps to simplify your software delivery lifecycle.
This reference architecture builds and tests a sample Node.js web application and then deploys it to OKE by using the OCI DevOps. The application source code is hosted on a DevOps code repository. The end user commits the code into the code repository, which triggers the start of a build pipeline.
The build pipeline follows a user-defined flow to build and test software, then create a container image of the latest version of the application. The output of the build is stored in the container registry as an image. Then a deployment pipeline uses the built image from the container registry and a Kubernetes manifest to deploy the most recent version of the application to OKE.
To simplify the setup of this example CI/CD workflow, Terraform is used to automate creation and configuration of OCI DevOps resources for this sample application.
The following diagram illustrates this reference architecture.
An OCI 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). The architecture uses a single region.
- DevOps project
A logical grouping of DevOps resources needed 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 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.
- Code repository
Private Git repositories hosted by DevOps service. You can store, manage, develop source code with OCI 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. The DevOps deployment pipeline includes the following predefined stage types for you to use in your release process:
- Rolling deployment: An incremental release to OKE, Functions, or instance groups
- Wait: Wait N seconds
- Manual approval: Proceed if an approval is given; stop if an approval is rejected.
- Invoke function: Perform custom tasks or integrations by calling a Function and pass an artifact of request parameters.
- 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
Artifact Repository creates repositories to group similar artifacts. When the repository is created, you can upload artifacts to it. 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
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 provision and manage Compute hosts in the cloud. You can deploy Compute instances with shapes that meet your resource requirements for CPU, memory, network bandwidth, and storage.
- Functions: Oracle Functions is a fully managed, multitenant, highly scalable, on-demand, functions-as-a-service platform. The service is built on enterprise-grade Oracle Cloud Infrastructure and powered by the Fn Project open source engine.
- Compute shapes
This architecture uses an Oracle Linux OS image with either E3 or E4 flex shape. You can start with minimum resources that are required for Compute hosts in your instance group environment and the OKE cluster nodes. If your application needs more memory or cores, you can choose a different shape.
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 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 the OKE cluster as one of the target environments. The worker nodes are deployed on a 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.
- 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 OCI.
Consider the following points when deploying this reference architecture:
- DevOps supports deployments to OKE, Compute hosts, Functions.
- Only Linux hosts are supported for instance group deployments to Compute instances.
- Artifacts to deploy with DevOps must be in an OCI artifact registry or container image registry repository.
- The best practice is to group each application and all its microservices into a single project.
The Terraform code for creating build and deploy pipeline using OCI DevOps 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 CLI:
- Go to GitHub.
- Clone or download the repository to your local computer.
- Follow the instructions in the README document.
To learn more about OCI DevOps, see the following resources: