Build a CI/CD Pipeline for Cloud Deployments by Using Github Actions and Oracle Cloud Infrastructure DevOps Service
- To prevent exposure of all deployment targets to a service that resides outside of some of your security layers.
- Parts of a deployment process may differ depending on when Infrastructure as Code (IaC) maybe part of the deployment process.
- Minimize the potential impact of latency in deployment processes. So executing the final step is controlled locally with only local connections and dependencies involved.
- Ability to manage and release control assets that span multiple environments in a single place. Rather than have distributed sources.
This Reference Architecture addresses these considerations by having parts of its service outside of Oracle Cloud (for example, GitHub and others within OCI, such as DevOps). This reference architecture looks at the deployment process (CD) to Oracle Cloud Infrastructure(OCI) platforms: Oracle Container Engine for Kubernetes (OKE), Functions, and Compute instances. The common container image is built using a separate service (so the element is universal) and then deployed by DevOps so that it doesn't communicate directly OKE.
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 DevOps can be used by both customers migrating workloads from on-premises or other clouds to OCI and customers developing new applications on OCI.
Architecture
In this reference architecture, a sample application is deployed from GitHub using GitHub Actions and OCI DevOps service. The application is deployed to OKE cluster.
The following diagram illustrates this reference architecture.
Description of the illustration devops-arch.png
- 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.
- External CI System
This architecture uses GitHub Actions as an external continuous integration system. GitHub Actions automate, customize, and run software development workflows from the GitHub repository. Here, GitHub Actions is used to build code and then containerize it using Docker. When the containerized image is ready, GitHub Actions pushes the image to an OCI artifact repository (alternately, the artifact is put in a central location where the GitHub actions can be configured to nudge DevOps to retrieve the artifact. This means content is pulled, not pushed). After completing the transfer to Artifact Repository, it kicks off the OCI DevOps deployment pipeline. You can also use other continuous integration systems like Jenkins or Gitlab based on your requirements.
If IaC techniques are being used, then prior to deployment, the pipeline could use services such as the Resource Manager to instantiate an environment and, once complete, tear down those resources by using the Resource Manager to .
The Devops deployment pipeline can also store the resultant output somewhere secure for reporting.
- DevOps project
A DevOps project is a logical grouping of resources needed to implement your continuous integration and deployment (CI/CD) workload. DevOps resources can be artifacts, deployment pipelines, and environments. DevOps projects make it easy to enable logging, monitoring, and notifications for all your DevOps resources.
- 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 stagesStages 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 and integration 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, you have to 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 is used to create repositories to group similar artifacts. Once the repository is created then artifacts can be uploaded to them. 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.
- OCI Logging and Notifications 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): Oracle Container Engine for Kubernetesis 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 launch 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. It's built on enterprise-grade OCI and powered by the Fn Project open source engine.
Recommendations
- 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 either E3 or 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.
- OKE
This architecture deploys to the OKE cluster as the target endpoint. 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 Oracle Cloud.
- 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.
Considerations
Consider the following points when deploying this reference architecture.
- DevOps-supported deployments
DevOps supports deployments to OKE, Compute hosts, and Functions. This architecture deploys to an OKE cluster. Consider deploying to other endpoints based on the requirements.
- Linux support
Only Linux hosts are supported for instance group deployments to Compute instances.
- Deployed artifacts
Artifacts to deploy with DevOps need to be in an OCI artifact registry or container image registry repository.
- Grouping applications
As a best practice, group each application and all its microservices into a single project. Ensure the value proposition of splitting the process is understood and that the divisions are maintained.
Deploy
To deploy this architecture, follow the instructions for Java app deployment in this Live Lab: