This documentation provides an overview of the CI/CD automation scripts present in the fluxcd/flux2-kustomize-helm-example project. Utilizing GitHub Actions, the project automates the validation and deployment of Kubernetes manifests using Flux, Kustomize, and Helm.

CI/CD Workflows

The primary automation is facilitated through two GitHub Actions workflows configured in the .github/workflows directory:

1. Test Workflow (test.yaml): Validates the Kubernetes manifests and Kustomize overlays using kubeconform, ensuring that all changes are syntactically correct and adhere to expected schema standards.

2. End-to-End Workflow (e2e.yaml): Initiates a Kubernetes cluster in the CI environment using Kind, testing the staging setup by deploying and validating Flux within that cluster.

Test Workflow Configuration

The following excerpt from the test.yaml file demonstrates the automated testing of Kubernetes manifests:

name: Test Kubernetes Manifests

on:
  pull_request:
    branches:
      - main

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Validate Kustomize Overlays
        run: |
          ./scripts/validate.sh

This job triggers on pull requests to the main branch and utilizes the validate.sh script to perform validation.

End-to-End Workflow Configuration

The e2e.yaml configuration showcases how the CI/CD pipeline sets up Kind and tests the full deployment:

name: End-to-End Test

on:
  push:
    branches:
      - main

jobs:
  e2e:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Set up Kind
        run: |
          kind create cluster --name e2e
          kubectl cluster-info --context kind-e2e

      - name: Deploy Flux
        run: |
          flux bootstrap github \
          --owner=${{ secrets.GITHUB_USER }} \
          --repository=${{ secrets.GITHUB_REPO }} \
          --branch=main \
          --path=clusters/staging

In this example, a cluster is created, and Flux is bootstrapped to ensure continuous delivery from the GitHub repository.

Validation Script

The scripts/validate.sh script is essential for running validations locally and as part of the CI process. Below is a detailed look at its components:

#!/usr/bin/env bash

set -o errexit
set -o pipefail

kustomize_flags=("--load-restrictor=LoadRestrictionsNone")
kustomize_config="kustomization.yaml"

kubeconform_flags=("-skip=Secret")
kubeconform_config=("-strict" "-ignore-missing-schemas" "-schema-location" "default" "-schema-location" "/tmp/flux-crd-schemas" "-verbose")

echo "INFO - Validating kustomize overlays"
find . -type f -name $kustomize_config -print0 | while IFS= read -r -d $'\0' file; do
  echo "INFO - Validating kustomization ${file/%$kustomize_config}"
  kustomize build "${file/%$kustomize_config}" "${kustomize_flags[@]}" | kubeconform "${kubeconform_flags[@]}" "${kubeconform_config[@]}"
  if [[ ${PIPESTATUS[0]} != 0 ]]; then
    exit 1
  fi
done

Key Functions of validate.sh

• Kustomization Validation: It finds all kustomization files, runs kustomize build to generate the final Kubernetes manifests, and validates them against defined schemas with kubeconform.

• Error Handling: Any validation failure during the CI/CD process will halt the pipeline, ensuring that only valid configurations are deployed.

Next Steps

If there are no CI/CD workflows currently set up in the project, implementation can follow these steps:

1. Create appropriate GitHub Actions YAML files in the .github/workflows directory.

2. Define jobs to validate and test the Kubernetes manifests using the scripts provided in the scripts directory.

3. Set up notifications in the workflows to keep the team informed about the success or failure of CI/CD jobs.

In conclusion, the CI/CD automation provided in this project leverages GitHub Actions for automated validation and deployment, ensuring reliability in managing Kubernetes manifests and infrastructure changes.