Build a Continuous Integration and Deployment Pipeline by Using Oracle Cloud Infrastructure DevOps Services

Rapid delivery of software is key for efficiently building and deploying 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 remediating issues by enabling software to be rebuilt and then retested as changes are applied and, as a result, detecting any adverse impact early.

The service includes the provision of private GIT repositories to store your code and supports connections to external code repositories to hold source code and configuration files. As build processes depend on and produce intermediate artifacts (modules, packages, and so on), they also work with Oracle’s artifact and container 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.

When working in a hybrid or multicloud environment, OCI DevOps can be used to create artifacts to be deployed in other environments.

Architecture

This reference architecture establishes all the services and configuration that allows you to build and test a sample Node.js web application and then deploy it to OKE by using the OCI DevOps. The Terraform deployment includes the creation of the pipelines and repositories needed. The application source code is hosted on a DevOps code repository. The user can then commit the code into the 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 with 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.

The pipeline provided doesn’t address considerations such as applying unit tests and analyzing code quality by using static code analysis and linter tools.

The following diagram illustrates this reference architecture.

Description of deploy-pipeline-devops-arch.png follows
Description of the illustration deploy-pipeline-devops-arch.png

deploy-pipeline-devops-arch-oracle.zip

This architecture has the following components:
  • Region

    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.
    Environments can be in different OCI regions from the region of the deployment pipeline. This separation allows developers to deploy in multiple OCI regions using the same deployment pipeline.

Recommendations

Use the following recommendations as a starting point for creating a build and deploy pipeline by using OCI DevOps. Your requirements might differ from the architecture described here.
  • 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.

  • 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 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.

Considerations

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.

Deploy

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 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 CLI:
    1. Go to GitHub.
    2. Clone or download the repository to your local computer.
    3. Follow the instructions in the README document.

Change Log

This log lists significant changes: