Funded by the EU.

faas-deployment

EO4EU GitLab Repository Development Guide

This repository follows a CI/CD process designed to give developers control over when to trigger deployments.

The structure and logic outlined below ensure efficient versioning and deployment using GitLab CI/CD and Flux CD.

---

Repository Structure

dagger/                                      # Python Dagger functions directory  
.gitlab-ci.yml                               # CI pipeline global structure file  
env/dev/operator/cookiecutter-config.yaml    # Parameters for generating Operator Helm chart (development)
env/dev/controller/cookiecutter-config.yaml  # Parameters for generating Controller Helm chart (development)
env/prod/operator/cookiecutter-config.yaml   # Parameters for generating Operator Helm chart (production)
env/prod/controller/cookiecutter-config.yaml # Parameters for generating Controller Helm chart (production)
dagger.json                                  # Dagger SDK configuration (Python)  

---

Components

This deployment manages two separate components:

• Operator: The FaaS operator service that manages function deployments and orchestration
• Controller: The FaaS controller service that handles function execution and lifecycle management

Each component has its own Helm chart and configuration, deployed separately to allow independent versioning and updates.

---

CI/CD Workflow and Helm Chart Versioning

To avoid triggering a deployment on every repository code change, the versioning mechanism follows standard Flux CD behavior: the Helm Controller re-deploys the application whenever it detects a new chart version. This means a new Kubernetes deployment is not triggered unless the Helm chart version in the respective component's cookiecutter-config.yaml is manually updated by the developer.

How to Trigger a Deployment

To trigger a re-deployment for a specific component (operator or controller):

1. Manually increment the chart_version field in the component's cookiecutter-config.yaml:
   • For operator: env/{dev|prod}/operator/cookiecutter-config.yaml
   • For controller: env/{dev|prod}/controller/cookiecutter-config.yaml
2. Use semantic versioning: <major>.<minor>.<patch> (e.g. 1.0.3).
3. Commit and push this change to make Flux CD proceed with a re-deployment of that specific component.

Note: Each component (operator and controller) can be versioned and deployed independently.

---

Dynamic Manifests Upload

The operator component supports dynamic manifest templates that can be updated independently of the Helm chart deployment.

How to Update Dynamic Manifests

To upload new or modified dynamic manifests to the operator:

1. Edit any file in the env/{dev|prod}/operator/dynamic/ directory
   • These are Kubernetes manifest templates used by the operator for function deployments
2. Commit and push the changes
3. The CI/CD pipeline will automatically:
   • Package all files in the dynamic/ directory into a zip archive
   • Upload the archive to the operator service via its admin API
   • Wait for the operator service to be responsive before uploading

Note: This upload happens independently of Helm chart deployments, allowing you to update function deployment templates without changing the operator's version.

The pipeline job responsible for this is:

• operator_upload_manifests_dev (for development)
• operator_upload_manifests_prod (for production)

---

Persistent Volume Claim (PVC) for Application Storage

If your application needs persistent storage, you can enable PVC support in the component's cookiecutter-config.yaml.

Step 1: Create the PVC in Kubernetes

Create a file named {component}-pvc.yaml (e.g., operator-pvc.yaml) with the following content:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: operator-pvc
  namespace: provision-handler
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: csi-cinder-sc-retain
  volumeMode: Filesystem

Apply the PVC using:

kubectl apply -f operator-pvc.yaml

Step 2: Enable PVC Support

Set the following parameter in your component's cookiecutter-config.yaml:

include_persistent_volume_claim: "yes"

Then define your PVC parameters like so:

pvc_persistent_volume_claim_name: "operator-pvc"
pvc_persistent_volume_claim_mount_path: "/mnt/storage"
pvc_persistent_volume_name: "pvc-73b31b79-3c95-4eaf-b15d-3e1e0fe764ff"
pvc_storage_class_name: "csi-cinder-sc-retain"
pvc_storage: "5Gi"

Note: Each component (operator and controller) can have its own PVC if needed.

---

Defining Environment Variables Using Vault

You can define application environment variables in both the component's cookiecutter-config.yaml and in HashiCorp Vault.

Step 1: Configure Vault Reference in cookiecutter-config.yaml

Set the following structure in your component's configuration file, e.g.:

include_external_admin_secret: "yes"
external_admin_secret_data:
    "data": [
      {
        secret_key: "token",
        vault_secret_key: "eo4eu-cicd/mixed_credentials/eo4eu-faas/faas-deployment-prod",
        vault_secret_property: "token"
      },
      {
        secret_key: "hash",
        vault_secret_key: "eo4eu-cicd/mixed_credentials/eo4eu-faas/faas-deployment-prod",
        vault_secret_property: "hash"
      }
    ]

Step 2: Access the Vault Interface

1. Go to: https://vault.wekeo.internal.eo4eu.eu/
2. Log in using the OIDC method and authenticate via EO4EU Keycloak.
3. Navigate to the secret path (e.g. eo4eu-cicd/mixed_credentials/...) to create or update variables.
4. If you don’t have access, you need to provide your OIDC UUID (as shown in your Vault profile) to a Vault administrator at ECMWF, who will grant access.

Common Secret Paths

GitLab Credentials (used by Flux to sync Helm releases)

• eo4eu-cicd/gitlab_credentials/eo4eu-faas/faas-deployment
• eo4eu-cicd/gitlab_credentials/eo4eu-faas/faas-operator
• eo4eu-cicd/gitlab_credentials/eo4eu-faas/faas-controller

Registry Pull Secrets (used by Flux to pull container images)

• eo4eu-cicd/registry_pull_secret/eo4eu-faas/faas-deployment

Application Environment Variables

• eo4eu-cicd/mixed_credentials/eo4eu-faas/faas-deployment-prod (for production)
• eo4eu-cicd/mixed_credentials/eo4eu-faas/faas-deployment-dev (for development)

---

Final Notes

• All CI/CD logic is fully automated except for Helm chart versioning, which is a manual developer decision.
• Developers are expected to manage their Helm chart version updates in accordance with deployment needs.
• Operator and Controller are deployed and versioned independently - changes to one component do not affect the other.
• Each component has its own configuration file under env/{dev|prod}/{operator|controller}/cookiecutter-config.yaml.