Complete CI/CD Pipeline Setup on Oracle Cloud Infrastructure (OCI) with Oracle Kubernetes Engine (OKE) – Blue/Green Deployment Strategy

 

Building a modern CI/CD pipeline is essential for delivering applications faster, safer, and with minimal downtime. In this blog, I’ll walk you through a complete end-to-end implementation of a CI/CD pipeline in OCI DevOps, integrating GitHub, Container Registry, OKE, and implementing a Blue/Green Deployment strategy.

 

 

 

This setup ensures:

• Automated build and deployment
• Zero-downtime releases
• Easy rollback mechanism
• Secure secret management

 

Let’s dive in.

Architecture Overview

We will configure:

• GitHub repository (source code)
• OCI Vault & Secrets
• OCI Container Registry
• OCI DevOps Project
• Build Pipeline
• Deployment Pipeline
• OKE Cluster
• NGINX Ingress Controller
• Blue/Green namespaces (ns-blue & ns-green)

 

Step 1: Secure GitHub Token in OCI Vault

Instead of hardcoding secrets:

1. Create a Vault
2. Create a Master Encryption Key
3. Store the GitHub PAT token as a Secret
4. Reference the secret in DevOps pipeline

This ensures enterprise-grade security for repository mirroring.

After  a vault is created, create the encryption key inside the vault

Now refer the key to the secrets

 

Secret contents is the PAT(Personal Access token) for the github. 

 

Step 2: Create an OKE Cluster

Create an OKE cluster from OCI Console.

After creation, access it from Cloud Shell:

kubectl get nodes

Your Kubernetes cluster is now ready for deployments.

3 worker nodes are up and running

 

Step 3: Create Container & Artifact Registry

• Create Container Registry → Stores Docker images
• Create Artifact Registry → Stores Kubernetes manifest files (YAML)

These artifacts will be referenced inside the pipeline.

 

Container registry:-

Artifact Registry

 

Step 4: Mirror GitHub Repository in OCI DevOps

Inside DevOps Project:

1. Click Mirror Repository
2. Provide GitHub credentials (via Vault secret which stores the GitHub PAT)
3. Wait for sync

After a few minutes, your source code will reflect in OCI.

 

 

 

 

Once it is created, we will be able to see the repositories present inside my github

 

 

 

 

After few minutes, the files will be displayed

 

 

Create the artifcats inside the devops which will store the container images and OKE manifest files

 

 

 

 

 Click on add

 

 Create the OKE manifest artifacts (choose the artifact registry created earlier)

 

 

 

Step 5: Create Build Pipeline

Important: Ensure build_spec.yaml is present in the root of the repository.

Build Pipeline Flow:

• Fetch Source Code
• Build Docker Image
• Push Image to Container Registry
• Export Image Artifact
• Trigger Deployment Pipeline

 

 

Add the next stage to deliver the artifacts for next stage

 

Click on +

 

 

 

 

Step 6: Create OKE Deployment Environment

Create an environment pointing to:

• Your OKE Cluster
• Target Namespace
• Kubernetes Manifest (oci-oke-deployment.yaml)

 

 

Step 7: Create Deployment Pipeline

 

 

 

 

 

 

Click on next

 

 

Select the environment created earlier

 

 

 

 

 

 

 

Add the trigger deployment under the build pipeline

 

 

 

 

 

Conclusion (End of Part 1)

By completing the steps above, we have successfully:

• Secured GitHub credentials using OCI Vault
• Created an OKE cluster
• Configured OCI Container & Artifact Registry
• Set up OCI DevOps Project
• Created a Build Pipeline
• Configured a Deployment Environment
• Implemented Blue/Green namespaces (ns-blue & ns-green)

At this stage, the CI/CD foundation is fully ready.

 

However, traffic is not yet exposed externally. The application is deployed inside the cluster, but we still need:

• An Ingress Controller
• Load Balancer configuration
• Traffic routing between Blue and Green
• Manual approval-based traffic shift
• Rollback mechanism

These critical production-grade components will be covered in the next blog.

---

What’s Coming in next post

In the next post-https://samappsdba.blogspot.com/2026/02/oci-devops-cicd-oke-blue-green-ingress-traffic-shift-part-2.html, we will cover:

• Setting up NGINX Ingress Controller on OKE
• Configuring LoadBalancer service
• Executing build pipeline runs
• Deploying to Green namespace
• Traffic shifting to Blue namespace
• Rollback strategy in OCI DevOps

This is where the real power of OCI DevOps Blue/Green deployment becomes visible.

 

Thanks for reading.

 

 

OCI DevOps CI/CD Pipeline with OKE Blue/Green Deployment – Part 2 (Ingress Setup, Traffic Shift & Rollback)

 In Part 1, we built the complete CI/CD foundation using:

• OCI Vault

• OCI Container & Artifact Registry

• OCI DevOps Build Pipeline

• OKE Cluster

• Blue/Green Namespaces

If you missed it, read Part 1 here:
https://samappsdba.blogspot.com/2026/02/oci-devops-cicd-pipeline-oke-blue-green-setup-part1.html

Now in Part 2, we will:

• Set up NGINX Ingress Controller

• Configure LoadBalancer

• Execute build pipeline

• Deploy to Green namespace

• Shift traffic to Blue namespace

• Perform rollback

This is where the real power of Blue/Green deployment on Oracle Cloud Infrastructure using Oracle Kubernetes Engine becomes visible

Step 8: Setup NGINX Ingress Controller on OKE

To expose applications externally, we need an Ingress Controller.

From OCI Cloud Shell, run:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.3.0/deploy/static/provider/cloud/deploy.yaml

Verify services:

kubectl get svc -n ingress-nginx

Configure Ingress Service as LoadBalancer

yaml file

kind: Service

apiVersion: v1

metadata:

  name: ingress-nginx

  namespace: ingress-nginx

spec:

  type: LoadBalancer

  selector:

    app.kubernetes.io/name: ingress-nginx

  ports:

    - name: http

      port: 80

      targetPort: http

    - name: https

      port: 443

      targetPort: https

Apply it:-

kubectl apply -f cloud-generic.yaml

Now your OKE cluster can route external traffic.

Step 9: Execute Build Pipeline

Go to OCI DevOps → Build Pipeline → Start Manual Run.

The pipeline will:

• Execute build_spec.yaml

• Build Docker image

• Push image to OCI Container Registry

• Trigger deployment pipeline

Check the deployment pipeline

Verify deployments:

NAME                                                READY   STATUS    RESTARTS   AGE

pod/sample-oke-bg-app-deployment-55db78c699-blz7r   1/1     Running   0          7m13s

pod/sample-oke-bg-app-deployment-55db78c699-d9zwh   1/1     Running   0          6m31s

pod/sample-oke-bg-app-deployment-55db78c699-fpj6h   1/1     Running   0          7m56s

 

NAME                                              CLASS    HOSTS   ADDRESS          PORTS   AGE

ingress.networking.k8s.io/sample-oke-bg-app-ing   <none>   *       129.80.114.230   80      41m

-- NS:ns-blue --

No resources found in ns-blue namespace.

Initially, traffic routes to ns-green.

Open the External IP in browser — application loads from Green namespace.

After it has been validated and passed the QA, approve it

Traffic is shifted to green namespace after successful test

Step 10: Modify Code & Deploy New Version

Commit changes to GitHub.

Within minutes:

• Code mirrors to OCI DevOps repository

• Start manual build again

• New image appears in Container Registry

• Deployment pipeline deploys to ns-blue

Now the pipeline waits for approval.

Step 11: Traffic Shift to Blue Namespace

After approval in Deployment Pipeline:

Traffic shifts from ns-green → ns-blue

Validate:

-- NS:ns-green --

NAME                                                READY   STATUS    RESTARTS   AGE

pod/sample-oke-bg-app-deployment-55db78c699-blz7r   1/1     Running   0          62m

pod/sample-oke-bg-app-deployment-55db78c699-d9zwh   1/1     Running   0          62m

pod/sample-oke-bg-app-deployment-55db78c699-fpj6h   1/1     Running   0          63m

 

NAME                                              CLASS    HOSTS   ADDRESS          PORTS   AGE

ingress.networking.k8s.io/sample-oke-bg-app-ing   <none>   *       129.80.114.230   80      97m

-- NS:ns-blue --

NAME                                                READY   STATUS    RESTARTS   AGE

pod/sample-oke-bg-app-deployment-57dd5dc988-4cvtv   1/1     Running   0          2m58s

pod/sample-oke-bg-app-deployment-57dd5dc988-hr7rt   1/1     Running   0          2m58s

pod/sample-oke-bg-app-deployment-57dd5dc988-lvp2h   1/1     Running   0          2m58s

 

NAME                                              CLASS    HOSTS   ADDRESS          PORTS   AGE

ingress.networking.k8s.io/sample-oke-bg-app-ing   <none>   *       129.80.114.230   80      51m

samsin16@cloudshell:~ (us-ashburn-1)$

 

we can see that pods are now running under blue

Ingress still uses the same External IP — but backend changes.

This ensures:

• Zero downtime

• Controlled release

• No service interruption

Step 12: Rollback (If Required)

If something goes wrong:

In Deployment Pipeline → Click Revert Traffic Shift

Traffic instantly returns to ns-green.

No rebuild required.
No downtime.
No manual intervention inside Kubernetes.

This is the beauty of OCI DevOps Blue/Green deployment

What We Achieved

By completing Part 2, we now have:

• Full CI/CD automation

• Kubernetes ingress routing

• Blue/Green traffic switching

• Approval-based production release

• Instant rollback capability

All running natively on Oracle Cloud Infrastructure.

---

Conclusion

With OCI DevOps and OKE, implementing enterprise-grade CI/CD with Blue/Green deployment becomes structured, secure, and scalable.

You now have:

Automated build
Automated deployment
Controlled traffic shift
Zero downtime strategy
Rollback mechanism

This architecture is production-ready for modern cloud-native applications

Secure Your Network: Private DNS in Oracle Cloud Infrastructure

 Private DNS in Oracle Cloud Infrastructure (OCI) refers to a service that enables you to create and manage custom domain names within your virtual cloud network (VCN). With Private DNS, you can define custom domain names and map them to specific resources, such as Compute instances, Load Balancers, or other services within your VCN.

Key features and benefits of Private DNS in OCI include:
Custom Domain Names: You can create your own domain names, such as example.com or subdomain.example.com, tailored to your organization's needs.
Resource Mapping: Private DNS allows you to map these custom domain names to specific resources within your VCN, making it easier to manage and access your services.
Network Isolation: By using Private DNS within your VCN, you can ensure that your domain names remain private and are only accessible within your network, enhancing security and control.
Integration with Oracle Services: Private DNS seamlessly integrates with other Oracle Cloud services, enabling you to easily manage domain names for resources such as Compute instances, Load Balancers, and more.
Automation and Scalability: You can automate the creation and management of domain names using OCI's APIs, CLI, or Terraform, making it easy to scale and manage your infrastructure.
Overall, Private DNS in OCI provides a flexible and secure way to manage domain names and map them to resources within your virtual cloud network, facilitating efficient communication and management of your cloud infrastructure.
Now, the objective of this post is to give an idea on how we can communicate to the resources using their hostnames. As we know, DNS is a feature which translates hostnames to IP addresses. If we have resources in OCI and they don't know the respective hostnames, then the communication can't be established. To mitigate this problem, OCI has the option of Private DNS in OCI.
A small use case here.
When we provision a compute instance, it comes with its own fully qualified domain name example oraclevcn.com. Now, if i need to set it to samappsdba.com, we need to perform some additional steps.
The high level steps
Private DNS Zone – which contain DNS data from the VCN (like IP address)
Private DNS Views – this is collection of Zones, Zone can only belong to a single View.
Private DNS Resolver – you can assign Views to Resolver which will then resolve those DNS queries for you. Remember the order, first custom views, then default and finally from Internet

Once the A record is added and published, we can do the test

[opc@instance-20240328-1959 ~]$ host -t NS samapspdba.com

samapspdba.com name server vcn-dns.oraclevcn.com.

[opc@instance-20240328-1959 ~]$

 

After I delete it the private view

 

@instance-20240328-1959 ~]$ host -t NS samapspdba.com

samapspdba.com name server vcn-dns.oraclevcn.com.

[opc@instance-20240328-1959 ~]$ nslookup www.samapspdba.com

Server:         169.254.169.254

Address:        169.254.169.254#53

 

** server can't find www.samapspdba.com: REFUSED

This is a basic demonstration on how using private DNS feature in OCI, we can customize the hostname. 

I hope this post helps someone.

Web Application Firewall(waf) as reverse proxy in Oracle Cloud (OCI)

 Oracle Cloud Infrastructure Web Application Firewall is a regional-based and edge enforcement service that is attached to an enforcement point, such as a load balancer or a web application domain name. WAF protects applications from malicious and unwanted internet traffic. WAF can protect any internet facing endpoint, providing consistent rule enforcement across a customer's applications. In this post, WAF works as a reverse proxy between the client and your website server. The real IP addresses of your website server are hidden from the visitors, and only the IP addresses of WAF are visible to them. The IP address of the web server is already mapped with DNS mapping.

Create WAF Policy

WAF Origin is basically the host or IP address of the public internet facing application that is being protected by the application. 

This takes time. Once it is created successfully, you will get the below screen.

Now test your application. Reference:-https://docs.oracle.com/en-us/iaas/Content/WAF/Concepts/gettingstarted.htm

Now, go to the OCI DNS Service and create a CNAME.

Publish the changes.

Next, modify the security lists of the webserver to recieve the requests from WAF. At this moment, we would need the IPV4 address of the WAF. If you scroll above, when we tested the application, we had recieved one IPV4 address. If I check the IP address for WAF server, it gives me the CIDR value with reference 192.29.50.64 and thus i used 192.29.0.0/16.

In the browser now, test it

We can verify the logs from WAF

Response code is 200.

I hope this post will be helpful for someone. In the next post, we will see how we can use Access Control in WAF for OCI. Till then, happy learning cloud.

Reference:-https://docs.oracle.com/en-us/iaas/Content/WAF/Concepts/overview.htm#:~:text=Oracle%20Cloud%20Infrastructure%20Web%20Application%20Firewall%20is%20a%20regional%2Dbased,malicious%20and%20unwanted%20internet%20traffic.