Day Two Operations¶

Setting up cronjobs¶

The chart can manage Symfony based cronjobs and bash based cronjobs. See the examples to setup either one of them

Setup a Symfony cronjob¶

crons:
- name: ibexa-cron-run
  command: ibexa:cron:run
  schedule: * * * * *

Setup a BASH cronjob¶

crons:
- name: ibexa-cron-run
  type: bash
  command: bin/console ibexa:cron:run
  schedule: * * * * *

crons:
- name: ibexa-cron-run
  type: bash
  command: >
    bin/console ibexa:reindex;
    bin/console c:c;
  schedule: 5 3 * * *

Setting up Varnish for stale cache¶

Check the healthcheck-bundle installation

composer require xrow/healthcheck-bundle

Add to your values.yml:

varnish:
  probe:
    enabled: true
    host: localhost
    path: /check

localhost should trigger your default siteaccess.

Taking the Ibexa DXP website for maintenance¶

Scale down the frontend deployment to 0 replicas and perform your work like database migrations or full reindexing. The stale cache will be still active.

Protecting non production systems from unauthorized access¶

varnish:
  firewall:
    enabled: true
    whitelist:
    - "192.168.0.2"
    - "192.168.0.0/16"
    auth:
      username: admin
      password: password

Setting up message queue and consumer¶

This guide will explain how to setup the services for the Symfony Messenger. The services are not enabled by default.

rabbitmq:
  enabled: true

messagequeue:
  enabled: true
  args:
    - bin/console
    - messenger:consume
    - async

async is the name if the transport you consume. You can also consume multiple transports by adding more arguments to the messenger:consume command. See the Symfony Messenger documentation for more examples.

Add chart post actions to composer for integration with CI/CD¶

Hooks available via the helm chart¶

    "scripts": {
        "post-helm-install": [
            "bin/console ibexa:reindex"
        ],
        "post-helm-upgrade": [
            "bin/console ibexa:reindex"
        ]
    },

Hooks available via the helm chart pipeline¶

Those hooks are only available if you use our GitLab standard pipeline.

    "scripts": {
        "post-pipeline-install": [
            "bin/console ibexa:reindex"
        ],
        "post-pipeline-data-sync": [
            "bin/console ibexa:reindex"
        ]
    },

Adding a static storage volume for files¶

Create static PersistentVolumeClaim definition

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: ibexa-files
  namespace: ibexa-test
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 2500Gi
  storageClassName: '-'

Set storage.existingClaim in your values.yaml with the value of ibexa-files. Once the PV created automatically by your default provisioner and the PV is bound you can copy the Ibexa DXP storage files into the PV.

Creating a non cluster-admin service account for deployment¶

It is good security practise to deploy the chart with a user that doesn't have the permissions of a cluster-admin.

Service account is needed for this improved security b. This account should not be able to see any other projects on the cluster but it should be able to create its own projects.

First of all this service account has to be created on the cluster by an admin user with this following script:

The script can be run with the following command:

source <(curl -s -k https://gitlab.com/xrow-public/ci-tools/-/raw/3.0/scripts/library.sh)
# Syntax: ci_kubernetes_create_service_account <namespace> <service-account-name>
ci_kubernetes_create_service_account ibexa-production deployment-user

The script creates two new cluster roles. The first role xrow-self-provisioner-with-namespaces only adds the permission to create and delete namespaces so that the service account can create a helm release with using the --create-namespace option. The second role adds a new cluster role which extends the existing admin role.

Then the service account will be created in the kube-public namespace and gets the cluster roles xrow-self-provisioner-with-namespaces and self-provisioner. Afterwards the new project will be created and the service account gets the admin role inside this project. This is necessary if the project already exists. If the service account is now creating a new project it will automatically get the admin role inside this project and with it all needed permissions to create an Ibexa helm release.

The script is also creating a kubeconfig file in which will help you authenticate towards the cluster API.