Use OCI DevOps to deploy Helm charts with Provenance and Container Instances via Shell stage

Rapid delivery of software is essential for efficiently running your applications in the cloud. The Oracle Cloud Infrastructure DevOps (OCI DevOps) service provides a continuous integration and deployment (CI/CD) platform for developers.

You can use the OCI DevOps service 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 you spend on building and deploying releases.

The OCI DevOps service also provides private Git repositories to store your code and supports connections to external code repositories.Whether you are migrating workloads to Oracle Cloud Infrastructure (OCI), from on-premises or other clouds or developing new applications on OCI, you can use the OCI DevOps service to simplify your software delivery lifecycle.

Architecture

In this reference architecture, we will deploy a cloud-native application deployment using OCI DevOps. Oracle Container Engine for Kubernetes (OKE) and OCI Container Instances are used as a deployment target for OCI DevOps.

The major features covered in this reference architecture are:

  • Deploy Helm Chart with Provenance and Integrity checks: Signing a Helm package and validating the integrity by using GNU Privacy guard keys via deployment pipelines.
  • Use Shell stage to deploy the application to OCI Container Instances: Shell stage allows you to run custom commands in the deployment pipeline. This stage can be added at any point in the deployment pipeline. In this reference architecture, we use Shell stage to deploy an application to OCI Container Instances.
  • Trigger file-based execution of OCI build pipeline: In OCI DevOps, a build run can be automatically triggered when you commit your changes to a code repository. Using this we can set the exclusion and inclusion of a set of files /folders against which the build pipelines execute during a code change.
  • Run managed build stages using custom build runner: Custom build runner allows you to set the desired OCPU and memory for the build runner to support necessary resources for running build instructions.
  • Use Terraform with remote state backend from OCI DevOps build pipeline: The S3 compatible OCI Object Storage bucket is used as a remote backend to store the Terraform states. The Terraform is executed from the OCI build pipeline, which is enabled with resource principal so that the client can control the resource access based on policies.

The following diagram illustrates this reference architecture.



oci-devops-helm-shell-oracle.zip

The architecture has the following components:

  • Tenancy

    A tenancy is a secure and isolated partition that Oracle sets up within Oracle Cloud when you sign up for Oracle Cloud Infrastructure. You can create, organize, and administer your resources in Oracle Cloud within your tenancy. A tenancy is synonymous with a company or organization. Usually, a company will have a single tenancy and reflect its organizational structure within that tenancy. A single tenancy is usually associated with a single subscription, and a single subscription usually only has one tenancy.

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

  • Compartment

    Compartments are cross-region logical partitions within an Oracle Cloud Infrastructure tenancy. Use compartments to organize your resources in Oracle Cloud, control access to the resources, and set usage quotas. To control access to the resources in a given compartment, you define policies that specify who can access the resources and what actions they can perform.

  • Code Repository

    Private Git repositories can be hosted by the OCI DevOps service. You can store, manage, and develop source code with the OCI DevOps code repositories.

  • Build Pipeline

    The build pipeline 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.

  • Managed build stage

    The managed build stage, builds and tests your software with a fast and scalable OCI DevOps service-managed build runner that runs build instructions. In this reference architecture, we are using a build stage with default shapes (pre-defined OCPUs and memory) and custom shapes (user-defined values of OCPUs and memory).

  • Deliver artifact stage

    The deliver artifact stage is one of the build stages that help to push an artifact or container image to the OCI Container Registry or OCI Artifacts Registry, post the managed build stage.

  • Deploy pipeline

    A sequence of steps for deploying a set of artifacts to a target environment. A deployment pipeline contains stages that run sequentially or in parallel.

  • Helm chart deployment stage

    Helm is an open-source package manager for Kubernetes that provides the ability to share, package, and deploy software built for Kubernetes. The OCI DevOps service supports deployment of Helm charts to Container Engine for Kubernetes (OKE) clusters. The Helm chart deployment stage also verifies the integrity of the Helm chart before deployment.

  • Shell deployment stage

    Shell stage allows you to run custom commands in the deployment pipeline. This stage can be added at any point in the deployment pipeline.

  • Container Instances

    OCI Container Instances is a serverless compute service that enables you to quickly and easily run containers without managing any servers. Container Instances runs your containers on serverless compute optimized for container workloads that provide the same isolation as virtual machines.

  • Vault

    Oracle Cloud Infrastructure Vault enables you to centrally manage the encryption keys that protect your data and the secret credentials that you use to secure access to your resources in the cloud. You can use the Vault service to create and manage vaults, keys, and secrets.

  • Object Storage

    The Oracle Cloud Infrastructure Object Storage service is an internet-scale, high-performance storage platform that offers reliable and cost-efficient data durability. The Object Storage service can store an unlimited amount of unstructured data of any content type, including analytic data and rich content, like images and videos.

  • Logging

    The Oracle Cloud Infrastructure Logging service is a highly scalable and fully managed single pane of glass for all the logs in your tenancy. Logging provides access to logs from Oracle Cloud Infrastructure resources. These logs include critical diagnostic information that describes how resources are performing and being accessed.

  • Notifications

    Use the Oracle Cloud Infrastructure Notifications service to set up communication channels for publishing messages using topics and subscriptions.

Recommendations

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.

    Select CIDR blocks that don't overlap with any other network (in Oracle Cloud Infrastructure, your on-premises data center, or another cloud provider) to which you intend to set up private connections.

    After you create a VCN, you can change, add, and remove its CIDR blocks.

    When you design the subnets, consider your traffic flow and security requirements. Attach all the resources within a specific tier or role to the same subnet, which can serve as a security boundary.

  • Compute shapes

    This architecture uses an Oracle Linux OS image with an E4 flex shape with minimum resources to host compute hosts or Virtual nodes in the OKE cluster nodes. If your application needs more memory or cores, you can choose a different shape.

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

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

  • Integrity & Security

    There are several focused areas here to ensure the security and integrity of application software. OCI Vault is used for storing the helm chart encryption and to ensure the validation of the chart before deployment. The registries (Artifact & Container) ensure that the application images and artifacts are saved and stored with the necessary security. Several security rules and necessary route rules are enforced via OCI Virtual Cloud network to allow only the necessary network traffic for application and infrastructure. Also, the object storage is marked as private so that the traffic is secured and controlled.

  • Object Storage

    Object Storage provides quick access to large amounts of structured and unstructured data of any content type, including database backups, analytic data, and rich content such as images and videos. You can safely and securely store and then retrieve data directly from the internet or from within the cloud platform. You can seamlessly scale storage without experiencing any degradation in performance or service reliability. Use standard storage for "hot" storage that you need to access quickly, immediately, and frequently. Use archive storage for "cold" storage that you retain for long periods and seldom or rarely access. The application code is set within a privately hosted repository. On top of all the resources necessary OCI Identity policies are enforced accordingly.

Considerations

When using OCI DevOps service to deploy a continuous integration and deployment (CI/CD) platform, consider these factors.

  • DevOps-supported deployments

    DevOps support deployments to Oracle Container Engine for Kubernetes (OKE), Compute hosts, and OCI Functions. This architecture deploys to an OKE cluster and uses a shell stage for other possible targets. Consider deploying to other endpoints based on your specific requirements.

  • Deployed artifacts

    The artifacts to be deployed with DevOps must be in an OCI Artifacts 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:
    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.

Explore More

Review these additional resources to learn more about the features of this reference architecture.

Acknowledgments

  • Author: Rahul M R