Buy me a DrinkEther Coffee (5$)

tektoSync (Part 1): Bootstrapping a Local GitOps Lab & Tekton CI

Published on:

2026-06-06

#GitOps #OpenShift #Tekton #CI_CD #Homelab #PlatformEngineering

Table of Contents

1. The Vision & Architecture

2. Setting the Stage: Repositories & Credentials

3. Pipeline-as-Code with Tekton CI

4. What's Next?

1. The Vision & Architecture

After passing my Red Hat OpenShift certification, I wanted to immediately bridge the gap between theory and reality. tektoSync is a local, end-to-end GitOps blueprint that deploys a containerized Node.js microservices application (the OG Coolstore) on OpenShift CRC. It uses Tekton for Continuous Integration, ArgoCD for Continuous Deployment, and Kustomize for configuration management.

PS: Running OpenShift Local (CRC) is notoriously greedy with hardware resources. To prevent it from choking, I implemented a multi-node homelab strategy, offloading peripheral DevOps infrastructure (like the Git server) to a dedicated secondary machine.

Infrastructure Breakdown

Host Machine	Operating System	Allocated Resources	Role / Services Managed
Primary Host	Fedora Workstation	12 vCPUs, 32 GB RAM	OpenShift Local (CRC Cluster)
Secondary Host	Debian 12	8 vCPUs, 12 GB RAM	Podman container platform hosting Gitea

By keeping heavy operators like Gitea off the main cluster, the Tekton pipelines and ArgoCD syncs had the breathing room they needed to run efficiently.

2. Setting the Stage: Repositories & Credentials

The blueprint splits the application source code and deployment states into two isolated repositories, as shown in my github repo Click me, hosted on the local Gitea server. This establishes a true GitOps separation of concerns.

1. The Git Repositories

coolstore-nodejs: The Application Repo containing the core microservices, standard Dockerfiles, and the .tekton/ directory.
tektoSync-Config: The Configuration Repo containing the dry declarative state managed via Kustomize.

First, we create a new namespace for the application to live in. oc new-project dev-sandbox

Next, we install the OpenShift GitOps (ArgoCD) and OpenShift Pipelines (Tekton) operators via the cluster's OperatorHub.

2. Cross-Namespace Credential Management

Because Tekton and ArgoCD run in completely different namespaces, credentials must be routed precisely. We apply the Gitea token secret to the app namespace and bind it to the default pipeline account so Tekton can pull/push code. oc apply -f gitea/gitea-creds.yaml -n dev-sandbox ; oc secrets link pipeline gitea-creds --for=pull,mount -n dev-sandbox

For ArgoCD, we apply the repository access credentials directly to the GitOps operator management namespace. oc apply -f gitea/gitea-repo-creds.yaml -n openshift-gitops

3. Secret Encryption

To adhere to GitOps principles, no plaintext secrets can be pushed to Git. I utilized Bitnami's Sealed Secrets to encrypt database configurations. We configure the controller to run in our namespace. oc apply -f sealedsecrets-perms.yaml -n dev-sandbox

3. Pipeline-as-Code with Tekton CI

Each core microservice is mapped to a dedicated Tekton pipeline comprising three foundational tasks. This forms the quintessential GitOps CI loop:

Fetch Config: Pulls down the current state of the tektoSync-Config repository from Gitea.
Build & Push: Uses the local microservice Dockerfile to build a container image and pushes it directly into the OpenShift Internal Container Registry.
Patch Configuration: Updates the corresponding image tag in the Kustomize overlays/dev layout, committing and pushing the delta back to Gitea.

PS: A major engineering lesson learned during this phase involved the Persistent Volume Claim (PVC). The pipeline relies on a shared PVC acting as its workspace. Due to the ReadWriteOnce (RWO) storage class nature on a single-node CRC instance, parallel execution was restricted. Pipelines must be executed sequentially to ensure clean filesystem locking across tasks.

4. What's Next?

With the CI loop successfully building and updating configuration manifests, the next step is utilizing ArgoCD to deploy the heavy-duty microservice architecture, and planning the integration of AI-driven DevSecOps agents. Read about it in Part 2 here.