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

OCI Generative AI Authentication Explained: Dynamic Groups vs Tenancy API Keys vs New GenAI API Keys

 

Introduction

When working with OCI Generative AI, one of the most common questions engineers struggle with is:

"How exactly should I authenticate when calling GenAI services?"

Should you use:

• Dynamic Groups with Instance or Resource Principals?

• The global OCI tenancy API key?

• Or the newly launched API Keys for OCI Generative AI?

Oracle’s documentation covers each option individually, but the practical differences — especially when agents are involved — are often unclear. This confusion frequently leads to authorization errors like “Authorization failed or requested resource not found”, even when IAM policies appear correct.

In this article, we’ll break down when to use each authentication method, what they can and cannot do, and how to choose the right one for your OCI Generative AI workload.

---

The Three Authentication Options in OCI Generative AI

---

1. Dynamic Groups with Instance / Resource Principals

This is the recommended enterprise approach for OCI-native workloads.

How it works

• Your OCI resource (Compute VM, OKE Pod, Function, etc.) is added to a Dynamic Group

• IAM policies grant that dynamic group access to Generative AI services

• Authentication happens automatically via Instance Principal or Resource Principal

Example policy:

Allow dynamic-group GENAI to manage genai-agent-family in tenancy

What this is used for

• OCI Compute → Generative AI

• OCI Functions → Generative AI

• OKE workloads → Generative AI

Supported GenAI features

Model inference
 Embeddings
GenAI Agent Runtime (agents, RAG, tools)
Object Storage integration
Enterprise IAM governance

This is mandatory when calling:

agent-runtime.generativeai.<region>.oci.oraclecloud.com

---

2. Global OCI Tenancy API Keys

These are the classic OCI user API keys.

How they work

• API key is generated for an IAM user

• Requests are signed using OCI’s request signing mechanism

• Typically used from laptops, CI/CD, or external systems

Downsides

• Long-lived credentials

• Manual key rotation

• Not ideal for workloads running inside OCI

Supported GenAI features

Model inference
Limited agent support
Not recommended for production agents

Oracle generally discourages this approach for GenAI workloads running on OCI resources.

---

3. Newly Launched OCI Generative AI API Keys

In early 2025, Oracle introduced service-specific API keys for Generative AI:

🔗 Official announcement:
https://docs.oracle.com/en-us/iaas/releasenotes/generative-ai/api-keys.htm

These are not OCI tenancy API keys.

What makes them different

• Scoped only to OCI Generative AI

• Simple Bearer-token authentication

• Similar in concept to OpenAI or Anthropic API keys

• No OCI request signing required

Supported endpoints

https://inference.generativeai.<region>.oci.oraclecloud.com

Supported GenAI features

Chat completion
Text generation
Embeddings

Critical limitation

GenAI Agent Runtime is NOT supported

API keys cannot authenticate against:

agent-runtime.generativeai.<region>.oci.oraclecloud.com

This means:

• No agents

• No RAG

• No tools

• No memory

• No OCI service integrations

Oracle Generative AI has two distinct service planes:

Plane	Purpose	Auth supported
Inference Plane	Direct model calls	API Keys, IAM
Agent Runtime Plane	Agents, tools, RAG	IAM only

The new API keys work only for inference, while agents are treated as first-class OCI resources, governed by IAM.

---

Which One Should You Use?

Use Dynamic Groups + Instance Principal if:

• You are calling GenAI Agents

• Your workload runs inside OCI

• You need RAG, tools, Object Storage access

• You want enterprise-grade security

Use GenAI API Keys if:

• You only need model inference

• You are calling from outside OCI

• You want quick experimentation

• You do NOT need agents

Avoid Global Tenancy API Keys when possible

They still work, but they are rarely the best option for modern GenAI workloads. These API keys are stored in your resources such as VM and hence poses security risks.

---

Final Thoughts

OCI Generative AI gives multiple authentication choices — but they are not interchangeable.

The new GenAI API keys simplify access to hosted models, while dynamic groups and instance principals remain the only supported path for GenAI Agents.

Understanding this distinction upfront can save hours of debugging IAM policies and mysterious 404 authorization errors

OCI Load Balancer Health Check Failing Despite Correct Security Rules? Here’s How to Fix It

 If you’re managing Oracle Cloud Infrastructure (OCI), you might have encountered a frustrating issue: your OCI Load Balancer backend health check fails even though your security lists, route tables, and firewall settings are correct.

In this blog, we’ll break down why this happens and provide a step-by-step solution.

---

Understanding the OCI Load Balancer Health Check

OCI Load Balancers periodically check the health of backend servers by sending requests to a specific port and protocol (TCP or HTTP). If the response is not as expected, the backend is marked unhealthy, and traffic is not routed to it.

Common symptoms of failing health checks:

• Status: Connection failed

• Status: Status code mismatch

• Backend remains Critical in the OCI console

Even if all your network rules are correct, the LB may still mark the backend as unhealthy due to application-level issues.

---

Case Study: Health Check Failing Despite Correct Security Settings

Here’s an example scenario:

• Backend VM private IP: **.**.**.**

• OCI Load Balancer health check node IP: **.**.**.**

• Security lists and NSGs are correctly configured to allow traffic from the LB subnet

• Firewall on the VM is disabled

Yet, the LB health check reports:

Critical – Connection failed

Step 1: Check if the backend application is listening

Run:

ss -lntp | grep :80

• If nothing is listening on the configured port, the health check will fail

• In our case, starting Apache (httpd) fixed the “Connection failed” issue:

sudo systemctl start httpd
sudo systemctl enable httpd

---

Step 2: Check the HTTP response code

After starting the web server, the health check may still fail with:

Status code mismatch

Run a test from the backend VM:

curl -i http://10.24.139.43/

• In our example, the response was:

HTTP/1.1 403 Forbidden

• OCI expects HTTP 200 OK by default. A 403 indicates Apache cannot serve the requested page, even if the server is running.

---

Step 3: Fix Apache configuration and permissions

1. Ensure Apache allows access to the DocumentRoot:

<Directory "/var/www/html">
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

2. Create a simple index file to return HTTP 200:

sudo bash -c 'echo "<html><body><h1>OK</h1></body></html>" > /var/www/html/index.html'
sudo chmod 644 /var/www/html/index.html
sudo chown apache:apache /var/www/html/index.html
sudo systemctl restart httpd

3. Test again:

curl -i http://10.24.139.43/

Output should be:

HTTP/1.1 200 OK
<html><body><h1>OK</h1></body></html>

---

Step 4: Verify LB health check

• OCI Load Balancer will now mark the backend Healthy within 30–60 seconds

• Traffic through the LB will work correctly for end users

---

Key Takeaways

1. Security rules alone do not guarantee a healthy backend. Always check the application layer.

2. 403 Forbidden or 404 Not Found responses will cause health check failures.

3. Ensure the backend serves HTTP 200 OK on the health check path.

4. Always test using curl or nc to simulate LB requests.

---

Conclusion

If your OCI Load Balancer health check is failing despite correct network settings, don’t panic. Most likely, the issue is at the application level — either the server is not listening, or the HTTP response is not 200 OK.

By ensuring your backend web server is running, the correct permissions are set, and a valid index page is served, your LB will pass the health checks, and traffic will flow smoothly.