Developing the Drupal Operator

The Drupal Operator is built with the Operator SDK (Ansible-based) and uses Kustomize for its Kubernetes manifests. This page describes how to work on and test the operator itself.

  • Current Operator SDK version used: v1.29.0

Prerequisites

To develop the operator you need:

Environment setup

In the operator repository, copy the example environment file and edit it:

cp .env.example .env

In .env, set (for example):

  • KUBECONFIG – your kubeconfig path if not default

  • IMG – the operator image to build and push, for example:

    IMG=ozziio/drupal-operator:3.1.6

Then load it:

source .env

For local testing with kind or Minikube, you can use .env.local.example (if present) as a reference.

Build and push the operator image

Build the operator image:

make docker-build IMG=$IMG

Log in to your container registry (for example, Docker Hub), then push:

make docker-push IMG=$IMG

After this, the image $IMG should be available to your cluster.

Install CRDs and deploy the operator

Install the CRDs and base configuration:

make install

This applies:

  • CRDs from config/crd/
  • RBAC from config/rbac/
  • Other base manifests

Deploy the operator controller manager:

make deploy IMG=$IMG

This creates:

  • The operator Deployment
  • Supporting Services and RBAC

Verify the operator is running:

kubectl get pods -n drupal-operator-system
kubectl logs deploy/drupal-operator-controller-manager -n drupal-operator-system

(Adjust the namespace if you use a different one.)

Warning Do not run make uninstall on a live or shared cluster. It removes CRDs and will trigger garbage collection of all related resources (Drupal sites, databases, backups, etc.).

Project structure overview

Key directories and files:

  • watches.yaml Maps CRDs to Ansible roles/playbooks. This is how the Operator SDK knows which role to run when a Drupal resource changes.

  • roles/setup/ Main Ansible role responsible for:

  • Creating ConfigMaps, Secrets, PVCs
  • Deploying MariaDB, Drupal, and optional Memcached
  • Managing CronJobs and Jobs for cron, backups, imports, locale updates

  • Updating CR status fields

  • config/ Kustomize-based deployment manifests:

  • config/crd/ – CRDs for Drupal and related resources
  • config/rbac/ – Roles and RoleBindings
  • config/manager/ – Operator manager Deployment
  • config/testing/, config/kind-testing/ – overlays for testing

  • config/prometheus/ – optional metrics/monitor configuration

  • install/ Static install manifests (CRDs, RBAC, operator Deployment) that can be used without Operator SDK, for environments where you prefer kubectl apply over make install / make deploy.

  • molecule/ Contains Molecule scenarios for automated testing of the operator.

Testing with Molecule

The repository includes Molecule scenarios such as:

  • molecule/default
  • molecule/kind
  • molecule/test-cluster
  • molecule/test-local

Each scenario typically has:

  • create.yml / destroy.yml – cluster/namespace setup and teardown
  • converge.yml – applies test resources (e.g., a Drupal CR)
  • verify.yml – checks that resources behave as expected

To run a scenario, for example the default one:

cd molecule/default
molecule test

This will:

  • Prepare a test environment
  • Deploy the operator
  • Apply test Drupal resources
  • Verify behavior (e.g., pods running, services created, status updated)

Development tips

  • Use a local cluster (kind, Minikube, MicroK8s) to isolate your changes.
  • Tag images uniquely (for example, ozziio/drupal-operator:dev-<user>-<date>) to avoid clashing with production images.

  • Watch the operator logs while reconciling:

    kubectl logs -f deploy/drupal-operator-controller-manager -n drupal-operator-system

  • Test small changes incrementally:

  • Adjust a variable or template.
  • Rebuild and push the image.
  • Redeploy with make deploy IMG=$IMG.
  • Apply or update a Drupal resource and observe behavior.

Cleanup

For a complete cleanup of your test environment:

  • Delete any Drupal resources you created:
kubectl delete drupal --all-namespaces --all
  • Optionally delete the namespaces used for testing.

Avoid running make uninstall on any cluster that contains data you care about, as it removes CRDs and triggers deletion of all associated resources.