fluxcd / flux2-kustomize-helm-example

This documentation provides a step-by-step guide on how to set up Continuous Integration/Continuous Deployment (CI/CD) for the fluxcd/flux2-kustomize-helm-example project.

Overview

Changes to Kubernetes manifests or the repository structure must be validated in CI before merging pull requests into the main branch and syncing on the cluster. This ensures that deployments are reliable and adhere to the expected configurations.

Existing CI/CD Configuration

This project includes two primary CI workflows implemented using GitHub Actions:

  1. Test Workflow: Validates Kubernetes manifests and Kustomize overlays using kubeconform.

  2. End-to-End (e2e) Workflow: Launches a Kubernetes cluster in CI using Kubernetes Kind and tests the staging setup by running Flux within that environment.

CI/CD Process

Below are the detailed steps to set up and validate your CI/CD pipeline:

1. Setting Up GitHub Access

To interact with GitHub for CI/CD processes, the following environment variables must be set:

export GITHUB_TOKEN=<your_token>
export GITHUB_USER=<your_username>
export GITHUB_REPO=<your_repository>

2. Validating the Kubernetes Cluster

Before bootstrapping or deploying, ensure that your staging cluster meets the required prerequisites:

flux check --pre

3. Bootstrap Flux on the Staging Cluster

To bootstrap Flux on your staging cluster, configure the following command. This command sets up the Flux components in the designated clusters/staging directory and establishes a deploy key with read-only access on GitHub.

flux bootstrap github \
--context=staging \
--owner=${GITHUB_USER} \
--repository=${GITHUB_REPO} \
--branch=main \
--personal \
--path=clusters/staging

4. CI Validation Steps

CI will run validation automatically. However, you can manually trigger validation with these scripts:

  • Validate YAML Files: The following script checks the validity of all YAML configurations:
#!/bin/bash
echo "INFO - Downloading Flux OpenAPI schemas"
mkdir -p /tmp/flux-crd-schemas/master-standalone-strict
curl -sL https://github.com/fluxcd/flux2/releases/latest/download/crd-schemas.tar.gz | tar zxf - -C /tmp/flux-crd-schemas/master-standalone-strict

find . -type f -name '*.yaml' -print0 | while IFS= read -r -d $'\0' file; do
    echo "INFO - Validating $file"
    yq e 'true' "$file" > /dev/null
done

echo "INFO - Validating clusters"
find ./clusters -maxdepth 2 -type f -name '*.yaml' -print0 | while IFS= read -r -d $'\0' file; do
    kubeconform "${kubeconform_flags[@]}" "${kubeconform_config[@]}" "${file}"
    if [[ ${PIPESTATUS[0]} != 0 ]]; then
      exit 1
    fi
done
  • Kustomization Validation: This script ensures that the Kustomize overlays are valid for deployment:
#!/bin/bash
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

5. End-to-End Testing

The e2e workflow will automatically create a Kubernetes cluster within CI and run the test configurations using Flux in that setup. This step includes:

  • Deploying the testing configurations
  • Running various tests to validate the setup

Deployment to Production

For additional clusters such as production, follow the outlined procedures to set up multiple environments by adjusting the paths and configurations accordingly.

Conclusion

This documentation highlights the basic CI/CD steps needed to validate and deploy using Flux with Kustomize and Helm. By establishing a robust CI/CD pipeline, the integrity and functionality of Kubernetes manifests can be assured.

If no CI/CD setup exists in your project, consider implementing the strategies outlined in this documentation to establish a workflow that supports your deployment processes efficiently.

References

Source information was taken from the README.md found within the repository. Adjustments may be required as per project-specific configurations and requirements.