DEV Community: Woulf

From craftsmanship to industrialization: Multi-environment GitOps with Argo CD and Kustomize on MicroK8s

Woulf — Mon, 07 Jul 2025 12:51:43 +0000

Setting up a self-hosted multi-environment GitOps workflow using Argo CD, Kustomize, and cert-manager on MicroK8s: architecture, challenges, mistakes, and Kubernetes deployment automation.

🌍 Context: Why this project?

This project is the logical continuation of a process started several months earlier. Initially, my infrastructure was managed manually: a few Kubernetes files stored in a repo, an Ingress to manage incoming traffic, a Let’s Encrypt certificate, a deployment exposed internally via a ClusterIP service, and a NodePort for external access.

But this approach quickly showed its limits:

No multi-environment management
No overall view of the cluster's state
Updates via pipelines were limited (only resource creation or update, with the rest done manually), and no clear history

I wanted a more robust setup, closer to what’s done in real companies: full infrastructure versioning, multi-env deployment, GitOps, more complete monitoring (traces, logs), and security.

🚀 Technical Goals

This new project aims to build a solid and maintainable foundation to deploy any application in a self-hosted Kubernetes cluster. The pillars:

GitOps with Argo CD for declarative deployments
Multi-environment (dev, staging, prod...) using kustomize
TLS Certificates automatically managed by cert-manager
NGINX Ingress for public HTTPS exposure
Full infra versioning: Ingress, Cert-Manager, and Argo CD are installed via Helm, but managed with Kustomize
One namespace per environment

📊 Tech Stack

MicroK8s: lightweight single-node Kubernetes distribution
Helm: chart manager for installing tools like Argo CD, cert-manager, ingress-nginx
Kustomize: overlays for different environments (dev, prod)
Argo CD: GitOps engine for continuous deployment
cert-manager + ClusterIssuer Let’s Encrypt: public TLS certificates

📂 Repo Structure

The repository is structured as follows:

.
├── environments/
│   ├── dev/         # Development environment
│   ├── staging/     # Pre-production environment
│   └── prod/        # Simulated production
├── base/            # K8s components common to all environments

Each tool is installed via Helm with a versioned values.yaml, and the dev/, staging/, and prod/ environments are Kustomize overlays with targeted patches.

Repo available here: github.com/Wooulf/devops-bootcamp-ippon

📦 Multi-Environment Management with Kustomize

Kustomize is the tool I use to cleanly manage different environments (dev, staging, prod) from a shared base of Kubernetes resources. Unlike Helm, it doesn’t rely on an external templating engine. It’s about composing declarative files rather than generating them dynamically.

Each environment inherits common resources from base/, and applies environment-specific patches (e.g., domain name, Docker image, namespace...).

Example:

.
├── base/
│   └── portfolio/
│       ├── kustomization.yaml
│       ├── deployment.yaml
│       ├── service.yaml
│       └── ingress.yaml
├── environments/
│   ├── dev/
│   │   ├── kustomization.yaml
│   │   └── patch-ingress-host.json
│   ├── staging/
│   └── prod/

Each directory (base or environment-specific like dev, staging, or prod) contains a mandatory kustomization.yaml file. This file defines which Kubernetes resources to compose and which environment-specific modifications to apply (e.g., a JSON patch to change the Ingress host).

Example:

environments/dev/kustomization.yaml:

namespace: dev
resources:
  - ../../base/portfolio
patches:
  - path: patch-ingress-host.json
    target:
      kind: Ingress
      name: portfolio-ingress

patch-ingress-host.json:

[
  { "op": "replace", "path": "/spec/tls/0/hosts/0", "value": "dev.woulf.fr" },
  { "op": "replace", "path": "/spec/rules/0/host", "value": "dev.woulf.fr" }
]

👉 With this structure, I can deploy the same project in multiple environments by only changing context and a few target variables.

🔍 Quick tip: to validate the local Kustomize output before handing over to Argo CD:

kubectl kustomize environments/dev

This generates the final YAML as it would be applied in the cluster.

You can then apply it using:

kubectl apply -k environments/dev

🚀 Why I Use Argo CD

Argo CD is the heart of my GitOps strategy: it ensures the actual Kubernetes cluster state always matches the manifests in Git.

What I like about Argo CD:

Clear visual interface of deployment states
Automatic (pull-based) deployment on commit
History tracking, rollback support
Automatic drift detection
Easy targeting of specific environments/namespaces

⚙️ Installing Argo CD with HTTPS

Argo CD was installed via Helm in the argocd namespace, with this configuration:

global:
  domain: argocd.woulf.fr

configs:
  params:
    server.insecure: "true"

server:
  certificate:
    enabled: true
    secretName: argocd-tls
    domain: argocd.woulf.fr
    issuer:
      group: cert-manager.io
      kind: ClusterIssuer
      name: letsencrypt-prod

  ingress:
    enabled: true
    ingressClassName: nginx
    annotations:
      nginx.ingress.kubernetes.io/backend-protocol: "HTTP"
    hosts:
      - argocd.woulf.fr
    tls:
      - hosts:
          - argocd.woulf.fr
        secretName: argocd-tls

Why server.insecure: true? Because TLS termination is handled at the Ingress level. Internal traffic remains HTTP, which is acceptable in a local or single-tenant VPS cluster.

🌐 Public Access via Ingress

The TLS certificate is automatically generated by cert-manager from the letsencrypt-prod ClusterIssuer. Argo CD is now publicly available at https://argocd.woulf.fr.

📌 Defining a GitOps Deployment with Argo CD

To connect Argo CD to my Git repo and define what to sync, I created an Application Kubernetes resource:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: portfolio-dev
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/Wooulf/devops-bootcamp-ippon
    targetRevision: HEAD
    path: environments/dev
  destination:
    server: https://kubernetes.default.svc
    namespace: dev
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

👉 The Argo CD Application file is also versioned in my Git repo: argocd/applications/portfolio-dev.yaml

🔍 How It Works

source.repoURL + path + targetRevision

Argo CD watches the environments/dev directory of the repo https://github.com/Wooulf/devops-bootcamp-ippon. Any modification triggers an automatic sync.
destination

The app is deployed in the local cluster (MicroK8s) using https://kubernetes.default.svc, in the dev namespace.
syncPolicy.automated
- automated: syncs automatically without manual actions
- prune: removes resources no longer defined in Git
- selfHeal: restores resources changed manually in the cluster
syncOptions.CreateNamespace=true

Automatically creates the dev namespace if it doesn’t exist, making the deployment autonomous and idempotent.

🔁 Final Result

Fully automated GitOps deployment in dev environment
Continuous compliance between Git and the cluster
Resource updates and deletions only controlled via Git
Dynamic namespace creation without manual preconfiguration

The dev portfolio is now auto-deployed with the latest Docker image tagged latest, and publicly accessible at https://dev.woulf.fr.

🎯 Argo CD interface: deployment state and sync across dev, staging, and prod environments.

🔍 Detailed view of the portfolio-dev app in the dev namespace — every resource is tracked, versioned, and synced to Git.

🧨 Problems Encountered (and Solved)

Persistent self-signed certificates I had persistent invalid certificates due to two simultaneous creation mechanisms: an annotation cert-manager.io/cluster-issuer on the Ingress and a server.certificate config in Helm's values.yaml. 👉 Solution: keep only one source of truth, Helm config with server.certificate in this case.

Temporary certificate active after Let’s Encrypt provisioning Cert-manager sometimes installs a temporary cert before Let’s Encrypt issues the final one. 👉 Just wait, this is expected behavior.

MicroK8s “losing” add-ons (Helm, DNS, etc.) after reboot Some MicroK8s add-ons were disabled after reboot. 👉 Required to manually restart certain services.

ClusterIssuer missing after cluster reboot After reboot, my ClusterIssuer wasn’t recognized, I had forgotten to version it in GitOps at the beginning. 👉 Solved by adding it explicitly in the Argo CD-managed manifests.

HTTPS access errors despite seemingly correct config In my case, caused by an active temporary certificate, or bad TLS termination on Ingress. 👉 Solved by handling TLS only at the Ingress level.

🧾 Summary

In this article, I started transitioning toward a multi-environment GitOps infrastructure, with:

Installing Argo CD via Helm in a dedicated namespace
Managing HTTPS with cert-manager and a Let’s Encrypt ClusterIssuer
Resolving common certificate issues (self-signed, temporary, double creation)
Exposing Argo CD via HTTPS using NGINX Ingress
First GitOps deployment of an app (portfolio) in the dev environment, dynamically patched via kustomize

This technical foundation now allows me to test, version, and secure deployments just like in production, while keeping maximum infrastructure control.

🔜 Coming in the Next Article

We’ll move forward by integrating Argo CD Image Updater to automatically update deployed images, adding a security layer with SealedSecrets to protect the API token used to interact with Argo CD, and making the system fully autonomous in true GitOps fashion.

Article 6: Minimalist monitoring with Prometheus & Grafana

Woulf — Mon, 07 Jul 2025 12:33:06 +0000

Integrating Prometheus & Grafana to monitor my self-hosted Kubernetes cluster with public HTTPS access, a customized default dashboard, and maintained security, all in an MVP GitOps logic.

In this sixth step, I’m integrating a monitoring system to supervise my Kubernetes cluster, keeping things minimalist, self-hosted, and avoiding unnecessary complexity.

Objective: simple and effective visibility

I want to view the state of my cluster at a glance: CPU, memory, pods, network. No over-engineering, no email alerts, just a clear dashboard.

I’m using the Helm chart kube-prometheus-stack, widely used in production, even though I’m underutilizing it here for educational purposes.

Installation with Helm

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

helm upgrade --install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --values prometheus-stack-values.yaml

I disabled alertmanager in the values.yaml file, since I don’t want to manage alerts for this MVP:

alertmanager:
  enabled: false

Why not use the MicroK8s Prometheus module?

MicroK8s offers a prometheus module that can be enabled in one line:

microk8s enable prometheus

But this module is a black box and hard to integrate into a GitOps workflow:

It’s not versioned in your Git repo
It offers almost no control over configuration or versions
It doesn’t separate Grafana and Prometheus cleanly

By choosing the Helm chart kube-prometheus-stack, I keep full control over configuration via my values.yaml, can version my infrastructure, and make my setup portable to any cloud or local Kubernetes cluster.

Grafana access

I created an Ingress at grafana.woulf.fr with an HTTPS certificate managed by cert-manager.

Admin access is protected by a Kubernetes Secret (not committed), defined like this:

grafana:
  admin:
    existingSecret: monitoring-grafana

Secret creation

kubectl -n monitoring create secret generic monitoring-grafana \
  --from-literal=admin-user=admin \
  --from-literal=admin-password=********

To enable easy public access, I allowed anonymous access with the Viewer role (read-only):

grafana:
  grafana.ini:
    auth.anonymous:
      enabled: true
      org_name: Main Org.
      org_role: Viewer
      hide_version: true

Default dashboard

I chose the built-in Kubernetes / Compute Resources / Cluster dashboard, then exported and versioned it into a ConfigMap, mounting it as the home dashboard:

grafana:
  grafana.ini:
    dashboards:
      default_home_dashboard_path: /var/lib/grafana/dashboards/grafana-dashboard-home/default.json
  dashboardsConfigMaps:
    grafana-dashboard-home: grafana-dashboard-home
  sidecar:
    dashboards:
      enabled: true
      label: grafana_dashboard
      searchNamespace: ALL

The related ConfigMap is versioned in my infra repo and labeled with grafana_dashboard: "1" to be auto-loaded by Grafana’s sidecar.

📁 A ConfigMap is a Kubernetes resource that lets you mount non-sensitive files into a pod.
It is automatically reloaded when modified.

Result

Grafana is publicly accessible over HTTPS
Default dashboard is readable and useful
No login required to monitor the cluster
Admin account is secured via a Kubernetes Secret

This approach follows DevOps best practices while staying simple and understandable for a visitor or recruiter.

🧠 What about production?

This setup is intentionally minimalist and educational, but in a production context, several aspects would be hardened:

Alertmanager would be enabled with alert routing to services (email, Slack, etc.) to notify when components fail.
Grafana access wouldn’t be anonymous: it would be IP-restricted, proxied, or SSO/LDAP-protected.
Admin passwords wouldn’t be handled via static Secrets, but through Vault or a secrets manager (SealedSecrets, ExternalSecrets).
Dashboards would be provisioned via API or dedicated files with more modular versioning strategies.
TLS certificates would be managed via larger-scale automatic rotation mechanisms (wildcard DNS, ACME DNS challenge, etc.)

But for this MVP, the setup offers a great balance between simplicity, readability, baseline security, and GitOps maintainability.

⚡ Next step: adding loki for centralized log collection? Or testing ArgoCD for advanced GitOps?

Stay tuned!

Article 5: HTTPS setup and future improvements

Woulf — Mon, 07 Jul 2025 12:25:58 +0000

Setting up HTTPS certificates using Let’s Encrypt and cert-manager, with challenge configuration and security annotations in the Kubernetes Ingress.

In this fifth step, I’ll go over how I enabled an SSL/TLS certificate to secure woulf.fr, still within a DevOps mindset. We'll cover:

Why Let’s Encrypt
Why cert-manager
Essential annotations (ssl-redirect, hsts-max-age)

Project context

Throughout the previous articles, I’ve:

Deployed a Kubernetes cluster using MicroK8s on a VPS
Containerized my application with Docker
Set up a GitHub Actions CI/CD pipeline to automatically build and publish the Docker image
Split app code and infrastructure into separate Git repositories
Deployed everything to Kubernetes using a GitOps approach

The final step was to secure the site with HTTPS.

Why Let’s Encrypt?

Let’s Encrypt is a free, automated, and open certificate authority. It’s the go-to solution for obtaining a valid SSL/TLS certificate easily.

Advantages:

Free: no cost for issuing or renewing certificates
Automated: works well with DevOps tools and Kubernetes
Trusted: certificates are valid in all modern browsers

Why cert-manager?

cert-manager is a Kubernetes operator built to automate certificate lifecycle management (issuing, renewal, rotation...).

It allows you to:

Create SSL/TLS certificates using Kubernetes Certificate resources
Handle validation challenges automatically with Let’s Encrypt
Manage renewals with no manual intervention

It fits naturally into a GitOps workflow: certificates and their configuration can be versioned in the infra repo.

How the HTTP-01 challenge works

To verify domain ownership, Let’s Encrypt uses HTTP-based validation:

cert-manager creates a Challenge at a special URL:

http://woulf.fr/.well-known/acme-challenge/<token>

It spins up a temporary acmesolver pod that responds with a key
Let’s Encrypt queries the URL:
- If the correct key is returned, the certificate is issued
- If not, validation fails

By adding this annotation to the Ingress:

acme.cert-manager.io/http01-edit-in-place: "true"

the HTTP challenge is integrated directly into the main Ingress, avoiding conflicts (which I had with separate solver pods/Ingresses).

Adding annotations for extra security

`nginx.ingress.kubernetes.io/ssl-redirect`

nginx.ingress.kubernetes.io/ssl-redirect: "true"

Automatically redirects HTTP traffic to HTTPS.

Once the certificate is active, this ensures users always connect over HTTPS.

`nginx.ingress.kubernetes.io/hsts-max-age`

nginx.ingress.kubernetes.io/hsts-max-age: "31536000"

Adds an HSTS (HTTP Strict Transport Security) header, telling browsers to refuse HTTP for 1 year (31,536,000 seconds).

⚠️ Enable this only after HTTPS is confirmed working, as it prevents fallback to HTTP.

Final configuration example

Here’s a snippet of the final Ingress configuration with all best practices included:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: woulf-ingress
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
    acme.cert-manager.io/http01-edit-in-place: "true"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/hsts-max-age: "31536000"
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - woulf.fr
      secretName: woulf-fr-tls
  rules:
    - host: woulf.fr
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: portfolio
                port:
                  number: 3000

What’s next?

✅ The site is now accessible via HTTPS, with a Let’s Encrypt certificate fully managed by cert-manager.

Here’s what I’m planning next:

Monitoring: set up Prometheus / Grafana stack
Centralized logging: using Loki or EFK
Advanced GitOps: try out ArgoCD or Flux to continuously observe and reconcile cluster state

This project is my first step toward a fully automated and maintainable infrastructure. And it’s only the beginning 👨‍🚀

Article 4: Kubernetes deployment with GitOps

Woulf — Mon, 07 Jul 2025 12:21:25 +0000

Deploying my version-controlled Kubernetes infrastructure using GitOps, with automated application via a dedicated pipeline and public exposure of my portfolio.

After setting up the build and push of my Docker image, it’s time to take it further: versioning and automating the deployment of my Kubernetes infrastructure.

Separation of concerns: code vs infra

To maintain a clean architecture and GitOps logic, I split the infrastructure from the application code into two separate Git repositories:

Wooulf/forkfolio: contains the website’s source code (Next.js), the Dockerfile, and a CI pipeline for building and pushing the Docker image.
Wooulf/infra-k8s-terraform: contains all Kubernetes configuration files (deployment.yaml, service.yaml, etc.), and a separate CI/CD pipeline for applying them to the cluster.

🎯 This structure decouples application code from infrastructure, making it easier to maintain, review, and evolve both parts independently.

Deploying the application on MicroK8s

To run my app on the cluster and expose it cleanly to the public, I’ve configured the following components:

A Deployment: handles pod lifecycle (updates, resilience, etc.)
A ClusterIP Service: stabilizes internal communication to the pod
An Ingress: routes incoming HTTP traffic to the correct app
A NodePort Service: exposes the Ingress Controller to the outside world

One request, one path

Together, these components route an incoming HTTP request through the cluster as follows:

🌐 Client → VPS (port 80) → NodePort → Ingress → ClusterIP → Pod

Here’s a visual diagram of the flow:

Kubernetes manifest files

These are the versioned files in the infra repo:

🧱 Deployment

Handles container deployment, updates, and redundancy.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: portfolio
spec:
  replicas: 1
  selector:
    matchLabels:
      app: portfolio
  template:
    metadata:
      labels:
        app: portfolio
    spec:
      containers:
        - name: portfolio
          image: woulf/portfolio:latest
          ports:
            - containerPort: 3000

🌐 ClusterIP Service

Exposes the pod within the cluster via a stable internal IP.

apiVersion: v1
kind: Service
metadata:
  name: portfolio
spec:
  selector:
    app: portfolio
  ports:
    - port: 80
      targetPort: 3000

🌍 Ingress

Links the domain name (woulf.fr) to the correct internal service.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: woulf-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - host: woulf.fr
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: portfolio
                port:
                  number: 3000
  ingressClassName: nginx

🛣️ NodePort Service to expose the Ingress Controller

This service exposes the NGINX Ingress Controller pod to the public by opening a port on the VPS.

apiVersion: v1
kind: Service
metadata:
  name: nginx-ingress-microk8s-controller
  namespace: ingress
spec:
  type: NodePort
  externalIPs:
    - 185.216.27.229
  selector:
    name: nginx-ingress-microk8s
  ports:
    - port: 80
      targetPort: 80
      nodePort: 32180

💡 externalIPs allows manual exposure of a service on a VPS’s public IP. It’s a functional approach for self-hosted setups, but in a cloud context, we’d use a LoadBalancer service, which integrates with the provider’s networking. On bare-metal clusters, MetalLB can simulate this behavior.

GitHub Actions pipeline in the infra repo

Once versioned, the files are applied to my cluster automatically using a second CI/CD pipeline in the infra-k8s-terraform repository.

It triggers on changes to the k8s/ folder:

on:
  push:
    paths:
      - 'k8s/**'

jobs:
  apply_k8s_configs:
    steps:
      - uses: actions/checkout@v4
      - uses: azure/k8s-set-context@v3
        with:
          kubeconfig: \${{ secrets.KUBECONFIG }}
      - run: kubectl apply -f k8s/
      - run: kubectl get all

✅ Result: with every config commit, the cluster is automatically synced.

What’s next?

I could go further with a fully-fledged GitOps tool like ArgoCD or Flux. These tools continuously monitor the Git repository and update the cluster without relying on a manual pipeline.

⚠️ This setup is minimalistic: it doesn’t include high availability or dynamic traffic management. Still, it’s more than enough for a self-hosted portfolio in MVP mode.

🔄 This setup gives me fast feedback between commits and production, while keeping my infra code versioned and clean. It’s not quite GitOps-as-a-Service, but it’s close.

💡 In the next article, I’ll talk about secret management, the upcoming HTTPS setup, some monitoring ideas, and possible future improvements to my infrastructure.

Article 3: Docker + GitHub Actions

Woulf — Mon, 07 Jul 2025 12:16:00 +0000

Automating the Docker build of my portfolio with GitHub Actions, publishing to Docker Hub, and seamless redeployment on Kubernetes.

Automating the build and push of a Node.js app

In this third step, I tackle the containerization of my Next.js application (personal portfolio), and the creation of a CI/CD pipeline to automate the Docker image build, its push to Docker Hub, and the automatic redeployment to Kubernetes.

CI/CD: Building the Docker image

The goal is to:

Produce a lightweight, optimized Docker image
Automatically publish it to Docker Hub
Restart the deployment on the cluster with zero downtime

Everything is defined in a GitHub Actions pipeline located in the application repository, under .github/workflows/deploy.yml.

Building the Docker image

Here is the Dockerfile used:

# Step 1: Base image for build and run
FROM node:23-alpine AS base
WORKDIR /app
ENV NEXT_TELEMETRY_DISABLED=1

# Step 2: Install dependencies
FROM base AS deps
COPY package.json package-lock.json ./
RUN npm ci

# Step 3: Build and fetch Dev.to articles securely
FROM base AS builder
COPY --from=deps /app/node_modules ./node_modules
COPY . .

ENV NEXT_PUBLIC_URL=https://woulf.fr
ENV NEXT_PUBLIC_EMAIL=corentinboucardpro@gmail.com

# Secure token injection via BuildKit
RUN --mount=type=secret,id=devto_token \\
  DEVTO_API_KEY=\$(cat /run/secrets/devto_token) node scripts/fetchDevtoArticles.js && npm run build

# Step 4: Final runtime image
FROM base AS runner
ENV NODE_ENV=production
ENV PORT=3000

# Create non-root user
RUN addgroup -S nodejs -g 1001 && \\
    adduser -S nextjs -u 1001 -G nodejs && \\
    mkdir .next && chown nextjs:nodejs .next

WORKDIR /app

COPY --from=builder /app/public ./public
COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static

USER nextjs
EXPOSE 3000
CMD ["node", "server.js"]

🧠 Notes on the Dockerfile:

Multi-stage build: separates base, dependencies, build, and runtime phases results in a clean and minimal image.
Alpine base (node:23-alpine): lightweight, fast to pull, smaller attack surface (more secure).
Copying package*.json first: leverages Docker cache when dependencies don’t change → drastically speeds up builds.
Using npm ci: ensures a clean install based on package-lock.json without re-resolving versions.
Secure token injection via BuildKit: avoids exposing secrets in the image or logs. Token is available only during the build.
Dev.to article fetching during build: keeps content updated without committing it to the repo.
Non-root user (nextjs): improves runtime security.
Copying only required folders (.next/standalone, .next/static): recommended by Next.js for Docker deployments.
EXPOSE 3000: informative for docs and some tools.

🔐 Result: a lightweight, secure, fast-to-build Docker image ready for production.

Pipeline in the application repository

The deploy.yml pipeline contains two jobs:

Build & push the image
Redeploy to the Kubernetes cluster

name: Deploy Website

on:
  push:
    branches:
      - main

jobs:
  docker:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Set up QEMU
        uses: docker/setup-qemu-action@v3

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Login to Docker Hub
        uses: docker/login-action@v3
        with:
          username: \${{ secrets.DOCKER_USERNAME }}
          password: \${{ secrets.DOCKER_PASSWORD }}

      - name: Build and push
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: woulf/portfolio:latest
          secrets: |
            "devto_token=\${{ secrets.DEVTO_TOKEN }}"

  rollout_k8s:
    runs-on: ubuntu-latest
    needs: docker
    steps:
      - name: Set up Kubernetes context
        uses: azure/k8s-set-context@v3
        with:
          kubeconfig: \${{ secrets.KUBECONFIG }}

      - name: Restart Deployment
        run: |
          kubectl rollout restart deployment/portfolio -n default
          kubectl rollout status deployment/portfolio -n default

🧠 Notes on the pipeline:

Auto-trigger on push to main: deploys automatically on merge, great for rolling releases.
Modular workflow: two isolated jobs (docker, rollout_k8s) for clarity and maintainability.
Official Docker action with BuildKit: handles cache, secrets, multi-platform builds.
Secrets via secrets.*: no credentials in code, tokens injected at build time only.
--mount=type=secret: ensures temporary use of secrets without exposing them in the final image.
Pushes to Docker Hub (woulf/portfolio:latest): versioned and publicly accessible.
Kubernetes redeploy with zero downtime: kubectl rollout restart updates the pod smoothly.
Deployment status check: prevents continuing if deployment fails.
needs: docker: guarantees the image is pushed before attempting redeploy.

🔄 Result: a robust, fully automated CI/CD pipeline that updates content, rebuilds your Docker image, and redeploys to Kubernetes, all from a single push.

Secret management

No credentials are hardcoded. Everything is securely stored via GitHub Secrets:

DOCKER_USERNAME / DOCKER_PASSWORD → for Docker Hub
KUBECONFIG → to connect to the MicroK8s cluster remotely
DEVTO_TOKEN → to fetch Dev.to articles automatically during build

Result

✅ On every push:

Dev.to articles are fetched
Docker image is rebuilt and pushed
App is redeployed with no interruption

💡 Next steps:

Add Trivy scan
Add a HEALTHCHECK
Reduce production dependencies

➡️ In the next article, I’ll explain how I versioned the Kubernetes infrastructure in a separate repository and set up a GitOps pipeline to keep the cluster in sync.

Article 2: Installing and configuring MicroK8s

Woulf — Thu, 26 Jun 2025 09:57:00 +0000

Setting up my local Kubernetes cluster with MicroK8s – installation, network configuration, activation of key modules, and secure access through UFW.

Now that the project foundation is laid, it’s time to set up the Kubernetes infrastructure on my VPS using MicroK8s.

This will be the technical base on which I’ll deploy my portfolio.

Step 1 - Installing MicroK8s

I start by installing MicroK8s using the snap package manager (already present on Ubuntu):

sudo snap install microk8s --classic

Step 2 - Adding My User

By default, all microk8s commands require sudo.

To get rid of that, I add my user to the microk8s group:

sudo usermod -a -G microk8s $USER
newgrp microk8s

Step 3 - Verifying Installation

I check that the cluster is properly installed and ready:

microk8s status --wait-ready

Step 4 - Enabling Essential Modules

I enable the following components:

microk8s enable dns ingress storage

Quick explanations:

dns: internal name resolution within the cluster
ingress: Ingress Controller (nginx reverse proxy)
storage: management of persistent volumes

Step 5 - Testing the Cluster

I verify everything is working with:

microk8s kubectl get all -A

Step 6 - Using kubectl Without microk8s Prefix

To use kubectl directly without prefix, I export the config:

microk8s config > ~/.kube/config

Step 7 - Opening Ports with UFW

I configure the firewall (ufw) to allow necessary connections:

sudo ufw allow 22/tcp     # SSH
sudo ufw allow 80,443/tcp # HTTP / HTTPS (Ingress)
sudo ufw allow 16443/tcp  # Kubernetes API
sudo ufw enable

Cluster Ready 🚀

The Kubernetes cluster is now ready to host my upcoming deployments.

In the next article, I’ll focus on building the Docker image for my site and setting up the first CI/CD pipeline to automatically publish it.

Article 1: Setting up a minimalist GitOps deployment

Woulf — Thu, 26 Jun 2025 09:23:32 +0000

An introduction to my GitOps approach for self-hosting my portfolio, with code/infrastructure separation, Kubernetes deployment, and automated CI/CD.

Project Context

As part of my shift towards DevOps, I decided to automate the deployment of my personal website.

The project follows a GitOps model: in other words, the Git repository (hosted on GitHub) serves as the single source of truth. Any change merged into the repository should be automatically reflected in the production environment.

Repository Structure

To follow this GitOps logic, I chose to separate the application code from the infrastructure configuration in two distinct Git repositories:

An application repository: Wooulf/forkfolio, which contains the website’s source code (Next.js), the Dockerfile, and a CI pipeline to build and deploy the Docker image.
An infrastructure repository: Wooulf/infra-k8s-terraform, which includes all Kubernetes configuration files (deployment.yaml, service.yaml, ingress.yaml, etc.), along with another pipeline that automatically applies changes to the cluster.

🔁 This separation improves maintainability, clarifies responsibilities, and follows GitOps best practices.

Project Goals

The aim is to build a Minimum Viable Product (MVP) with an agile mindset, focusing first on the essential features:

A minimalist Kubernetes cluster using MicroK8s
Deployment of my portfolio as a Docker container
Public exposure via a custom domain name
A CI/CD pipeline to automate updates
Basic monitoring to observe cluster health

Why MicroK8s?

I chose MicroK8s for its simplicity and lightweight setup.

It’s an ideal solution for testing environments, proof-of-concept setups, or personal projects like this one.

Other options like K3s, kind, or minikube may be considered later as the project evolves.

Environment Used

I’m using a VPS already set up at PulseHeberg, with the following specs:

Processor: Intel Xeon E5-2680v4
RAM: 8 GB DDR4
Storage: 1 TB RAID 10
Connection: 750 Mbps
System: Ubuntu 22.04 LTS

This VPS easily exceeds MicroK8s requirements:

“MicroK8s runs in as little as 540MB of memory, but to accommodate workloads, we recommend a system with at least 20G of disk space and 4G of memory.”

- Official documentation

What’s Next?

In the next article, I’ll walk through the initial configuration of the MicroK8s cluster on this VPS, including:

Installing MicroK8s
Enabling required modules (DNS, ingress…)
Setting up the firewall

🔧 The idea is to lay the technical foundations on which the entire project will be built.

De l'artisanat à l'industrialisation : GitOps multi-env avec Argo CD et Kustomize sur MicroK8s

Woulf — Fri, 30 May 2025 15:15:17 +0000

Mise en place d’un GitOps multi-environnement auto-hébergé avec Argo CD, Kustomize et cert-manager sur MicroK8s : architecture, défis, erreurs, et automatisation des déploiements Kubernetes.

🌍 Contexte : Pourquoi ce projet ?

Ce projet est le prolongement logique d'une démarche amorcée plusieurs mois auparavant. Initialement, mon infrastructure était gérée de façon artisanale : quelques fichiers Kubernetes posés dans un repository, un Ingress pour gérer le trafic entrant, un certificat Let’s Encrypt, un déploiement de mon app exposée en interne via un service ClusterIP, ainsi qu'un NodePort pour l'exposition externe.

Mais rapidement, cette approche a montré ses limites :

Pas de gestion multi-environnement
Pas de vision d'ensemble de l'état du cluster
Mises à jour via pipelines mais limitées (uniquement création ou mise à jour de ressources, le reste devant se faire manuellement), sans historique clair

Je voulais un setup plus robuste, plus proche de ce qui se fait en entreprise : versionnement complet de l'infrastructure, déploiement multi-env, GitOps, monitoring plus complet (traces, logs) et sécurité.

🚀 Objectifs techniques

Ce nouveau projet vise à construire une base solide et maintenable pour déployer n'importe quelle application dans un cluster Kubernetes auto-hébergé. Les piliers :

GitOps avec Argo CD pour des déploiements déclaratifs
Multi-environnement (dev, staging, prod...) via kustomize
Certificats TLS gérés automatiquement par cert-manager
Ingress NGINX pour l'exposition publique en HTTPS
Versionnement complet de l'infra : Ingress, Cert-Manager, Argo CD sont installés via Helm, mais pilotés via Kustomize
Namespace par environnement

📊 Stack technique

MicroK8s : distribution légère de Kubernetes, mono-nœud
Helm : gestionnaire de chart pour l'installation d'outils comme Argo CD, cert-manager, ingress-nginx
Kustomize : overlay d'environnements (dev, prod)
Argo CD : moteur GitOps pour le déploiement continu
cert-manager + ClusterIssuer Let's Encrypt : certificats TLS publics

📂 Organisation du repo

Le repository est structuré comme suit :

.
├── environments/
│   ├── dev/         # Déploiement dédié au développement
│   ├── staging/     # Environnement de préproduction
│   └── prod/        # Production simulée
├── base/            # Composants K8s communs à tous les environnements

Chaque outil est installé via Helm avec un values.yaml versionné, et les environnements dev/, staging/ et prod/ sont des overlays Kustomize avec des patchs ciblés.

Le repo est disponible ici : github.com/Wooulf/devops-bootcamp-ippon.

📦 Gestion multi-environnement avec Kustomize

Kustomize est l’outil que j’utilise pour gérer proprement mes différents environnements (dev, staging, prod) à partir d’une base commune de ressources Kubernetes. Contrairement à Helm, il ne nécessite pas de moteur de templating externe. On parle ici de composition de fichiers déclaratifs plutôt que de génération dynamique.

Chaque environnement hérite des ressources communes de base/, et vient appliquer des patches spécifiques (ex : nom de domaine, image Docker, namespace...).

Exemple :

.
├── base/
│   └── portfolio/
│       ├── kustomization.yaml
│       ├── deployment.yaml
│       ├── service.yaml
│       └── ingress.yaml
├── environments/
│   ├── dev/
│   │   ├── kustomization.yaml
│   │   └── patch-ingress-host.json
│   ├── staging/
│   └── prod/

Chaque répertoire (qu’il s’agisse de base ou d’un environnement comme dev, staging ou prod) contient un fichier kustomization.yaml obligatoire. Ce fichier décrit les ressources Kubernetes à assembler ainsi que les éventuelles modifications spécifiques à l’environnement (comme un patch JSON pour changer le host de l’Ingress).

Cette approche permet une composition claire et modulaire des ressources, tout en gardant un contrôle précis sur les différences entre environnements.

Exemple :
environments/dev/kustomization.yaml :

namespace: dev
resources:
  - ../../base/portfolio
patches:
  - path: patch-ingress-host.json
    target:
      kind: Ingress
      name: portfolio-ingress

patch-ingress-host.json :

[
  { "op": "replace", "path": "/spec/tls/0/hosts/0", "value": "dev.woulf.fr" },
  { "op": "replace", "path": "/spec/rules/0/host", "value": "dev.woulf.fr" }
]

👉 Avec cette structure, je peux déployer le même projet dans plusieurs environnements en changeant uniquement le contexte et quelques variables cibles.

🔍 Petit tip : pour valider la sortie Kustomize en local avant de confier le déploiement à Argo CD, on peut utiliser :
kubectl kustomize environments/dev
Cela génère le YAML final tel qu’il sera appliqué dans le cluster.

Et on peut l'appliquer comme ça :
kubectl apply -k environments/dev

🚀 Pourquoi j’utilise Argo CD ?

Argo CD est le cœur de ma stratégie GitOps : c’est lui qui veille à ce que l’état réel du cluster Kubernetes soit toujours synchronisé avec les manifests Git.

Ce que j’apprécie dans Argo CD :

Interface visuelle claire de l’état des déploiements
Déploiement automatique (pull-based) dès qu’un commit est détecté
Historique des modifications, gestion des rollback
Vérification automatique de la dérive de configuration
Facilité de ciblage d’environnements/namespaces spécifiques

⚙️ Installation d'Argo CD avec HTTPS

Argo CD a été installé via Helm dans le namespace argocd, avec cette configuration :

global:
  domain: argocd.woulf.fr

configs:
  params:
    server.insecure: "true"

server:
  certificate:
    enabled: true
    secretName: argocd-tls
    domain: argocd.woulf.fr
    issuer:
      group: cert-manager.io
      kind: ClusterIssuer
      name: letsencrypt-prod

  ingress:
    enabled: true
    ingressClassName: nginx
    annotations:
      nginx.ingress.kubernetes.io/backend-protocol: "HTTP"
    hosts:
      - argocd.woulf.fr
    tls:
      - hosts:
          - argocd.woulf.fr
        secretName: argocd-tls

Pourquoi server.insecure: true ? Car la terminaison TLS est gérée au niveau de l'Ingress. Le trafic interne reste en HTTP, ce qui est acceptable dans un cluster local/VPS non mutualisé.

🌐 Accès public via Ingress

Le certificat TLS est généré automatiquement par cert-manager à partir du ClusterIssuer letsencrypt-prod. Argo CD est maintenant accessible publiquement via https://argocd.woulf.fr.

📌 Définir un déploiement GitOps avec Argo CD

Pour connecter Argo CD à mon dépôt Git et lui indiquer quoi synchroniser dans le cluster, j'ai créé une ressource Kubernetes de type Application :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: portfolio-dev
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/Wooulf/devops-bootcamp-ippon
    targetRevision: HEAD
    path: environments/dev
  destination:
    server: https://kubernetes.default.svc
    namespace: dev
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

👉 Le fichier Application Argo CD est également versionné dans mon dépôt Git, visible ici : argocd/applications/portfolio-dev.yaml.

🔍 Comment ça fonctionne

source.repoURL + path + targetRevision

Argo CD surveille le répertoire environments/dev du dépôt Git https://github.com/Wooulf/devops-bootcamp-ippon. Toute modification (commit, push) dans ce dossier déclenche une synchronisation automatique.
destination

L’application est déployée dans le cluster local (MicroK8s) via l’URL https://kubernetes.default.svc, dans le namespace dev.
syncPolicy.automated
- automated: synchronisation automatique sans action manuelle.
- prune: suppression des ressources obsolètes qui ne sont plus déclarées dans Git.
- selfHeal: restauration automatique si une ressource est modifiée manuellement dans le cluster.
syncOptions.CreateNamespace=true

Le namespace dev est créé automatiquement s’il n’existe pas encore, rendant le déploiement autonome et idempotent.

🔁 Résultat final

Déploiement GitOps complet et automatique dans l’environnement dev
Conformité assurée en permanence entre Git et le cluster
Mise à jour ou suppression de ressources pilotée uniquement depuis le dépôt Git
Namespace dev créé dynamiquement sans préconfiguration manuelle

Le portfolio dev est maintenant déployé automatiquement avec la dernière image Docker taggée latest, et accessible via https://dev.woulf.fr.

🎯 Interface Argo CD : état de santé et synchronisation des environnements dev, staging et prod.

🔍 Vue détaillée de l'application portfolio-dev déployée dans le namespace dev — chaque ressource est traquée, versionnée, et synchronisée à Git.

🧨 Problèmes rencontrés (et résolus)

Certificats auto-signés persistants J’ai eu des certificats non valides persistants (auto-signés) à cause de deux mécanismes de création simultanés : une annotation cert-manager.io/cluster-issuer sur l’Ingress et une configuration server.certificate dans les values.yaml de Helm. 👉 Solution : ne conserver qu’une seule source de vérité. Ici, la configuration Helm via server.certificate.

Certificat temporaire actif après provisionnement Let's Encrypt Cert-manager installe parfois un certificat temporaire avant que Let's Encrypt émette le définitif. 👉 Il suffit d’attendre la mise à jour, c’est un comportement normal.

MicroK8s qui "perd" des add-ons (Helm, DNS, etc.) après redémarrage J’ai constaté que certains add-ons de MicroK8s se désactivaient au reboot. 👉 Nécessité de relancer manuellement certains services.

ClusterIssuer manquant après reboot du cluster Après redémarrage, mon ClusterIssuer n’était plus reconnu. Cela venait d’un oubli de le versionner dans mon GitOps au début. 👉 Résolu en l’ajoutant explicitement dans les manifests surveillés par Argo CD.

Erreurs d’accès HTTPS malgré une config a priori correcte Liées dans mon cas à un certificat temporaire encore actif, ou à une mauvaise terminaison TLS côté Ingress. 👉 En fixant la gestion TLS uniquement au niveau Ingress, le problème a disparu.

🧾 En résumé

Dans cet article, j’ai amorcé la transition vers une infrastructure GitOps multi-environnement, avec :

L’installation d’Argo CD via Helm dans un namespace dédié
La gestion du HTTPS avec cert-manager et un ClusterIssuer Let’s Encrypt
La résolution de problèmes classiques liés aux certificats (self-signed, temporaires, double création de certificat)
L’exposition d’Argo CD en HTTPS via Ingress NGINX
Le premier déploiement GitOps d’une application (portfolio) dans l’environnement dev, patché dynamiquement via kustomize

Ce socle technique me permet désormais de tester, versionner et sécuriser mes déploiements comme en production, tout en gardant un maximum de contrôle sur l'infrastructure.

🔜 À venir dans le prochain article

On poursuivra en intégrant Argo CD Image Updater pour assurer la mise à jour automatique des images déployées, en ajoutant une couche de sécurité avec SealedSecrets pour protéger le token d'API permettant d'interagir avec Argo CD. On verra aussi comment rendre ce système autonome, sans intervention manuelle, toujours dans une logique GitOps.

Article 6 : Monitoring minimaliste avec Prometheus & Grafana

Woulf — Sun, 18 May 2025 14:21:04 +0000

Intégration de Prometheus & Grafana pour monitorer mon cluster Kubernetes auto-hébergé, avec accès HTTPS public, dashboard par défaut personnalisé et sécurité maintenue, le tout dans une logique MVP GitOps.

Dans cette sixième étape, j'intègre un système de monitoring pour superviser mon cluster Kubernetes, toujours dans une logique MVP, auto-hébergée, et sans complexité inutile.

Objectif : visibilité simple et efficace

Je veux pouvoir visualiser l'état de mon cluster en un coup d’œil : CPU, mémoire, pods, réseau. Pas de sur-ingénierie, pas d’alerts emails, juste un dashboard clair.

J'utilise le chart Helm kube-prometheus-stack, largement adopté en prod, même s’il est ici sous-utilisé dans un but pédagogique.

Installation via Helm

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

helm upgrade --install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --values prometheus-stack-values.yaml

J'ai désactivé alertmanager dans le values.yaml, car je ne souhaite pas gérer d'alertes pour ce MVP :

alertmanager:
  enabled: false

Pourquoi ne pas utiliser le module Prometheus de MicroK8s ?

MicroK8s propose un module prometheus activable en une ligne :

microk8s enable prometheus

Mais ce module reste une boîte noire difficile à intégrer dans un workflow GitOps :

Il n'est pas versionné dans le dépôt Git
Il n'offre quasiment aucun contrôle sur la configuration ou les versions
Il ne permet pas de séparer proprement Grafana et Prometheus

En choisissant le chart Helm kube-prometheus-stack, je garde la maîtrise complète de la configuration via mon values.yaml, je peux versionner mon infrastructure, et je rends mon setup portatif sur n'importe quel autre cluster Kubernetes cloud ou local.

Accès à Grafana

J'ai créé un Ingress à grafana.woulf.fr avec certificat HTTPS géré par cert-manager.

L'accès admin est protégé par un Secret Kubernetes (non committé) défini comme :

grafana:
  admin:
    existingSecret: monitoring-grafana

Création du Secret

kubectl -n monitoring create secret generic monitoring-grafana \
  --from-literal=admin-user=admin \
  --from-literal=admin-password=********

Et pour permettre un accès public simple, j’ai activé l'accès anonyme avec le rôle Viewer (lecture seule) :

grafana:
  grafana.ini:
    auth.anonymous:
      enabled: true
      org_name: Main Org.
      org_role: Viewer
      hide_version: true

Dashboard par défaut

J'ai choisi le dashboard Kubernetes / Compute Resources / Cluster fourni par défaut dans le chart, puis je l’ai exporté, versionné dans un ConfigMap, et monté comme dashboard d’accueil :

grafana:
  grafana.ini:
    dashboards:
      default_home_dashboard_path: /var/lib/grafana/dashboards/grafana-dashboard-home/default.json
  dashboardsConfigMaps:
    grafana-dashboard-home: grafana-dashboard-home
  sidecar:
    dashboards:
      enabled: true
      label: grafana_dashboard
      searchNamespace: ALL

Le ConfigMap correspondant est versionné dans le repo d’infra, et porte le label grafana_dashboard: "1" pour être pris en compte automatiquement par le sidecar Grafana.

📁 Un ConfigMap est une ressource Kubernetes qui permet de monter des fichiers non sensibles dans un pod.
Il est rechargé automatiquement en cas de modification.

Résultat

Grafana accessible publiquement, en HTTPS
Dashboard par défaut lisible et utile
Aucun login requis pour consulter l’état du cluster
Compte admin sécurisé via Secret Kubernetes

Cette approche respecte les bonnes pratiques DevOps, tout en restant simple et facilement compréhensible pour un visiteur ou un recruteur.

🧠 Et en production ?

Ce setup est volontairement minimaliste et pédagogique, mais plusieurs aspects seraient renforcés dans un contexte de production :

Alertmanager serait activé, avec des routes d’alerte vers des services externes (email, Slack, etc.), pour être notifié dès qu’un composant tombe.
L’accès Grafana ne serait pas ouvert en anonyme : il serait restreint par IP, protégé par un proxy ou connecté à un SSO/LDAP.
Le mot de passe admin ne serait pas géré via un Secret statique, mais externalisé via Vault ou une solution de gestion de secrets (SealedSecrets, ExternalSecrets).
Les dashboards seraient provisionnés via API ou fichiers dédiés, avec une stratégie de gestion de version plus modulaire.
Le certificat TLS serait géré via des mécanismes de rotation automatique à plus grande échelle (wildcard DNS, ACME DNS challenge...).

Mais dans le cadre de ce MVP, cette configuration me donne un bon équilibre entre simplicité, lisibilité, sécurité de base et maintenabilité GitOps.

⚡ Prochaine étape : ajout de loki pour la collecte de logs centralisée ? Ou test d’ArgoCD pour GitOps avancé ?

C'est ouvert !

Article 5 : Finalisation de l’HTTPS et perspectives d'évolution

Woulf — Wed, 16 Apr 2025 08:58:00 +0000

Mise en place d’un certificat HTTPS via Let’s Encrypt et cert-manager, avec configuration des challenges et annotations de sécurité dans l’Ingress Kubernetes.

Dans cette cinquième étape, je reviens sur la mise en place d’un certificat SSL/TLS pour sécuriser le site woulf.fr, toujours dans une optique DevOps. Nous allons voir :

Pourquoi Let’s Encrypt
Pourquoi cert-manager
Les annotations essentielles (ssl-redirect, hsts-max-age)

Contexte du projet

Au fil des articles précédents, j’ai :

Déployé un cluster Kubernetes via MicroK8s sur un VPS.
Conteneurisé mon application avec Docker.
Mis en place une CI/CD GitHub Actions pour builder et publier automatiquement l’image Docker.
Séparé code applicatif et infrastructure dans deux dépôts Git distincts.
Déployé le tout sur Kubernetes avec une logique GitOps.

La dernière étape consistait à sécuriser l’accès au site avec HTTPS.

Pourquoi Let’s Encrypt ?

Let’s Encrypt est une autorité de certification gratuite, automatisée et ouverte. C’est aujourd’hui la référence pour obtenir facilement un certificat SSL/TLS valide.

Avantages :

Gratuit : aucun coût d’émission ni de renouvellement.
Automatisé : compatible avec les outils DevOps et Kubernetes.
Reconnu : les certificats sont valides pour tous les navigateurs modernes.

Pourquoi cert-manager ?

cert-manager est un opérateur Kubernetes développé pour gérer automatiquement les certificats (émission, renouvellement, rotation…).

Il permet de :

Créer un certificat SSL/TLS via des objets Certificate Kubernetes.
Effectuer la validation (challenge) automatiquement auprès de Let’s Encrypt.
Gérer les renouvellements sans aucune intervention manuelle.

Il s’intègre très bien dans un workflow GitOps : on peut versionner les certificats et leur configuration dans le repo d’infra.

Fonctionnement du challenge HTTP-01

Pour vérifier que je suis bien propriétaire du nom de domaine, Let’s Encrypt effectue une vérification via HTTP :

cert-manager crée un Challenge avec une URL spéciale sur le domaine :

   http://woulf.fr/.well-known/acme-challenge/<token>

Il lance un pod acmesolver temporaire qui répond à cette URL avec une clé unique.
Let’s Encrypt interroge l’URL :
- Si la bonne clé est retournée, le certificat est délivré.
- Sinon, la validation échoue.

Avec l’ajout de l’annotation suivante dans l’Ingress :

acme.cert-manager.io/http01-edit-in-place: "true"

le challenge HTTP est directement intégré dans l’Ingress principal, ce qui évite des conflits (que j'ai eu avec des Ingress/POD dédiés au solver).

Ajout d'annotations pour une sécurité supplémentaire

`nginx.ingress.kubernetes.io/ssl-redirect`

nginx.ingress.kubernetes.io/ssl-redirect: "true"

Forcer automatiquement la redirection HTTP vers HTTPS.

Une fois le certificat valide, on peut s'assurer que les utilisateurs accèdent toujours au site en HTTPS.

`nginx.ingress.kubernetes.io/hsts-max-age`

nginx.ingress.kubernetes.io/hsts-max-age: "31536000"

Ajoute un en-tête HSTS (HTTP Strict Transport Security) pour dire aux navigateurs de refuser toute future connexion en HTTP pendant 1 an (31 536 000 secondes).

⚠️ Attention à ne l’activer qu’après avoir vérifié que HTTPS fonctionne, car cela empêche tout retour vers HTTP.

Exemple final de configuration

Voici un extrait du fichier Ingress après intégration des bonnes pratiques :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: woulf-ingress
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
    acme.cert-manager.io/http01-edit-in-place: "true"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/hsts-max-age: "31536000"
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - woulf.fr
      secretName: woulf-fr-tls
  rules:
    - host: woulf.fr
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: portfolio
                port:
                  number: 3000

Ce qu’il reste à faire

✅ Le site est maintenant accessible en HTTPS, avec un certificat Let’s Encrypt automatiquement géré par cert-manager.

Voici ce que je prévois pour la suite :

Monitoring : mettre en place un stack Prometheus / Grafana.
Logs centralisés : avec Loki ou EFK.
GitOps avancé : tester ArgoCD ou Flux pour observer et réconcilier les états du cluster.

Ce projet est un premier pas vers une infrastructure entièrement automatisée et maintenable. Et ce n’est que le début 👨‍🚀

Article 4 : Déploiement Kubernetes avec GitOps

Woulf — Mon, 07 Apr 2025 12:09:18 +0000

Déploiement de mon infrastructure Kubernetes versionnée avec GitOps, avec application automatisée via une pipeline dédiée et exposition publique de mon portfolio.

Après avoir mis en place le build et le push de mon image Docker, il est temps d’aller plus loin : versionner et automatiser le déploiement de mon infrastructure Kubernetes.

Séparation des responsabilités : code vs infra

Pour garder une architecture propre et maintenir une logique GitOps, j’ai séparé l’infrastructure du code applicatif dans deux dépôts Git différents :

Wooulf/forkfolio : contient le code source de mon site (Next.js), le Dockerfile et une pipeline CI pour builder + déployer l’image Docker.
Wooulf/infra-k8s-terraform : contient tous les fichiers de configuration Kubernetes (deployment.yaml, service.yaml, etc.), et une autre pipeline CI/CD dédiée à leur application sur le cluster.

🎯 Ce découpage permet de découpler le code applicatif de l'infrastructure, ce qui facilite la maintenance, les revues de code ciblées, et l’évolution des deux parties de manière indépendante.

Déploiement de l'application sur MicroK8s

Pour que mon application tourne sur le cluster et soit exposée proprement au public, j’ai mis en place les éléments suivants :

Un Deployment : qui gère le cycle de vie du pod (mises à jour, résilience…)
Un Service ClusterIP : pour stabiliser la communication interne vers le pod
Un Ingress : pour router les requêtes HTTP externes vers la bonne application
Un Service NodePort : pour exposer l’Ingress Controller au monde extérieur

Une requête, un chemin

L'ensemble de ces composants permet de faire transiter une requête HTTP entrante à travers le cluster, comme ceci :

🌐 Client → VPS (port 80) → NodePort → Ingress → ClusterIP → Pod

Voici un schéma clair et visuel du fonctionnement :

Fichiers de définition Kubernetes

Voici les fichiers versionnés dans le repo d’infra :

🧱 Deployment

Gère le déploiement du conteneur, les mises à jour, la redondance.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: portfolio
spec:
  replicas: 1
  selector:
    matchLabels:
      app: portfolio
  template:
    metadata:
      labels:
        app: portfolio
    spec:
      containers:
        - name: portfolio
          image: woulf/portfolio:latest
          ports:
            - containerPort: 3000

🌐 Service ClusterIP

Expose le pod à l’intérieur du cluster via une IP stable.

apiVersion: v1
kind: Service
metadata:
  name: portfolio
spec:
  selector:
    app: portfolio
  ports:
    - port: 80
      targetPort: 3000

🌍 Ingress

Fait le lien entre un nom de domaine (woulf.fr) et le bon service interne.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: woulf-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - host: woulf.fr
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: portfolio
                port:
                  number: 3000
  ingressClassName: nginx

🛣️ Service NodePort pour exposer l’Ingress Controller

Ce Service expose le pod NGINX de l’Ingress Controller vers l’extérieur, via un port ouvert sur le VPS.
Cela permet aux requêtes HTTP/HTTPS d’atteindre le cluster depuis l’extérieur.

apiVersion: v1
kind: Service
metadata:
  name: nginx-ingress-microk8s-controller
  namespace: ingress
spec:
  type: NodePort
  externalIPs:
    - 185.216.27.229
  selector:
    name: nginx-ingress-microk8s
  ports:
    - port: 80
      targetPort: 80
      nodePort: 32180

💡 externalIPs permet d’exposer manuellement un service sur l’IP publique d’un VPS. C’est une approche fonctionnelle en environnement auto-hébergé, mais dans un contexte cloud, on privilégiera les Service de type LoadBalancer, qui s’intègrent directement avec l’infrastructure réseau du fournisseur. Pour les clusters sans cloud provider, une solution comme MetalLB permet de simuler ce comportement.

Pipeline GitHub Actions dans le repo infra

Une fois les fichiers versionnés, je les applique automatiquement sur mon cluster grâce à une deuxième pipeline CI/CD dans le dépôt infra-k8s-terraform.

Elle s’exécute dès qu’un fichier est modifié dans le dossier k8s/ :

on:
  push:
    paths:
      - 'k8s/**'

jobs:
  apply_k8s_configs:
    steps:
      - uses: actions/checkout@v4
      - uses: azure/k8s-set-context@v3
        with:
          kubeconfig: ${{ secrets.KUBECONFIG }}
      - run: kubectl apply -f k8s/
      - run: kubectl get all

✅ Résultat : à chaque commit de config, le cluster se synchronise automatiquement.

Et la suite ?

Je pourrais aller encore plus loin avec un outil GitOps complet comme ArgoCD ou Flux. Ces outils se chargeraient de surveiller le dépôt Git en continu et de mettre à jour le cluster sans passer par une pipeline manuelle.

⚠️ Ce setup reste minimaliste : il n'inclut pas de haute disponibilité ni de gestion dynamique du trafic. Il est cependant suffisant pour un portfolio auto-hébergé, dans une logique de MVP.

🔄 Ce setup me permet d’avoir une boucle de feedback rapide entre mes commits et le résultat en production, tout en gardant un code d’infra proprement versionné. Ce n’est pas encore du GitOps “as a Service”, mais on s’en approche.

💡 Dans le prochain article, je parlerai de la gestion des secrets, du futur passage en HTTPS, des idées de monitoring, et des prochaines évolutions possibles de mon infrastructure.

Article 3 : Docker + GitHub Actions

Woulf — Mon, 07 Apr 2025 12:00:33 +0000

Automatisation du build Docker de mon portfolio avec GitHub Actions, publication sur Docker Hub et redéploiement transparent sur Kubernetes.

Automatiser le build et le push d’une app Node.js

Dans cette troisième étape, je m’attaque à la conteneurisation de mon application Next.js (portfolio personnel), et à la mise en place d’une pipeline CI/CD pour automatiser le build de l’image Docker, son push sur Docker Hub, et le redéploiement automatique sur Kubernetes.

CI/CD : création de l’image Docker

L’objectif est de :

Produire une image Docker légère et optimisée
La publier automatiquement sur Docker Hub
Redémarrer le déploiement sur le cluster sans downtime

Tout est défini dans une pipeline GitHub Actions située dans le dépôt de mon application, sous .github/workflows/deploy.yml.

Construction de l’image Docker

Voici le Dockerfile utilisé :

# Étape 1 — Base d’image pour builder et runner
FROM node:23-alpine AS base
WORKDIR /app
ENV NEXT_TELEMETRY_DISABLED=1

# Étape 2 — Installation des dépendances
FROM base AS deps
COPY package.json package-lock.json ./
RUN npm ci

# Étape 3 — Build avec récupération sécurisée des articles Dev.to
FROM base AS builder
COPY --from=deps /app/node_modules ./node_modules
COPY . .

ENV NEXT_PUBLIC_URL=https://woulf.fr
ENV NEXT_PUBLIC_EMAIL=corentinboucardpro@gmail.com

# Injection sécurisée du token Dev.to via BuildKit
RUN --mount=type=secret,id=devto_token \\
  DEVTO_API_KEY=\$(cat /run/secrets/devto_token) node scripts/fetchDevtoArticles.js && npm run build

# Étape 4 — Image finale pour l’exécution
FROM base AS runner
ENV NODE_ENV=production
ENV PORT=3000

# Création d’un utilisateur non-root
RUN addgroup -S nodejs -g 1001 && \\
    adduser -S nextjs -u 1001 -G nodejs && \\
    mkdir .next && chown nextjs:nodejs .next

WORKDIR /app

COPY --from=builder /app/public ./public
COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static

USER nextjs
EXPOSE 3000
CMD ["node", "server.js"]

🧠 Quelques remarques sur le Dockerfile :

Multi-stage build : séparation claire entre les étapes de base, d'installation, de build, et de runtime, ce qui permet une image finale propre et minimale.
Base alpine (node:23-alpine) : image légère, rapide à télécharger, avec une surface d’attaque réduite (bon point pour la sécurité).
Copie du package*.json avant le code source : permet de tirer parti du cache Docker tant que les dépendances ne changent pas → accélère drastiquement les builds.
Utilisation de npm ci : garantit une installation propre et rapide des dépendances en se basant uniquement sur le package-lock.json, sans résoudre les versions à nouveau.
Injection sécurisée du token Dev.to avec BuildKit : évite d’exposer des secrets sensibles dans l’image ou les logs. Le token est utilisé uniquement le temps du build.
Téléchargement dynamique des articles Dev.to : via un script exécuté pendant le build, ce qui permet de maintenir le contenu à jour sans le committer dans le dépôt.
Création d’un utilisateur non-root (nextjs) : renforce la sécurité à l’exécution en limitant les permissions du processus Node.js.
Répertoires .next/standalone et .next/static : copiés depuis l'étape de build pour ne garder que le strict nécessaire à l’exécution (selon les recommandations Next.js pour le déploiement Docker).
EXPOSE 3000 : uniquement informatif, mais utile pour la documentation, certains outils, et la lisibilité du Dockerfile.

🔐 Résultat : une image Docker légère, sécurisée, rapide à builder, et prête à être déployée en prod.

Pipeline dans le dépôt applicatif

La pipeline deploy.yml contient deux jobs :

Le build & push de l’image
Le redéploiement sur le cluster Kubernetes

name: Deploy Website

on:
  push:
    branches:
      - main

jobs:
  docker:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Set up QEMU
        uses: docker/setup-qemu-action@v3

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Login to Docker Hub
        uses: docker/login-action@v3
        with:
          username: \${{ secrets.DOCKER_USERNAME }}
          password: \${{ secrets.DOCKER_PASSWORD }}

      - name: Build and push
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: woulf/portfolio:latest
          secrets: |
            "devto_token=\${{ secrets.DEVTO_TOKEN }}"

  rollout_k8s:
    runs-on: ubuntu-latest
    needs: docker
    steps:
      - name: Set up Kubernetes context
        uses: azure/k8s-set-context@v3
        with:
          kubeconfig: \${{ secrets.KUBECONFIG }}

      - name: Restart Deployment
        run: |
          kubectl rollout restart deployment/portfolio -n default
          kubectl rollout status deployment/portfolio -n default

🧠 Quelques remarques sur la pipeline :

Déclencheur automatique sur push sur main : permet de publier les changements dès qu’ils sont mergés, sans action manuelle. Utile en mode rolling release.
Workflow modulaire : deux jobs bien séparés (docker et rollout_k8s), ce qui isole les responsabilités entre la construction/push et le déploiement.
Utilisation de docker/build-push-action@v5 : outil maintenu par Docker Inc. pour builder efficacement avec BuildKit, gérer les caches, secrets, tags, et plateformes.
Secrets gérés par GitHub (secrets.*) : aucun mot de passe ou token dans le code. Le token Dev.to est passé via secrets en tant que secret mount avec BuildKit.
BuildKit + --mount=type=secret : permet d’injecter un token dans un RUN temporairement (jamais exposé dans l'image finale, ni dans les logs).
Push sur Docker Hub avec tag woulf/portfolio:latest : ton image est automatiquement versionnée et disponible en ligne pour un déploiement rapide sur n’importe quel cluster.
Redéploiement Kubernetes via kubectl rollout restart : déclenche un redéploiement du pod sans downtime (Kubernetes gère le remplacement progressif).
Vérification du statut avec kubectl rollout status : empêche la pipeline de continuer si le déploiement échoue → fiabilise le process.
Utilisation de needs: docker dans le job de déploiement : garantit que l’image est bien poussée avant le restart sur le cluster.

🔄 Résultat : un pipeline CI/CD robuste, 100% automatisé, qui met à jour ton contenu, ton image Docker, et ton déploiement Kubernetes en un seul push.

Gestion des secrets

Aucun identifiant n’est codé en dur. Tout est stocké de manière sécurisée via les GitHub Secrets :

DOCKER_USERNAME / DOCKER_PASSWORD → pour Docker Hub
KUBECONFIG → pour se connecter à mon cluster MicroK8s à distance
DEVTO_TOKEN → pour accéder à l’API Dev.to et télécharger les articles automatiquement pendant le build

Résultat

✅ À chaque push :

Les articles Dev.to sont récupérés
L’image est reconstruite et poussée
L’app est redéployée sans interruption

💡 Prochaines étapes :

Ajouter scan Trivy
Ajout d’un HEALTHCHECK
Réduction des dépendances côté prod

➡️ Dans le prochain article, je vous explique comment j’ai versionné l’infrastructure Kubernetes dans un second dépôt, et mis en place une pipeline GitOps pour garder le cluster synchronisé.