Queue worker instellen voor Laravel

Queue workers binnen Laravel en vergelijkbare php workers binnen andere frameworks, zijn php processen die los staan van het uitserveren van de website. Het beste is als deze php processen dezelfde configuratie hebben en dezelfde versie zijn als de PHP-fpm containers die je gebruikt om de website uit te serveren. Daarom staat de configuratie hiervan in twee delen beschreven.

Jobs worden gestart door een job-controller, deze controller houdt bij of een job klaar is en of er een nieuwe job gestart moet worden. Ook geef je aan welk commando er gestart moet worden, deze wijkt af van je bestaande php-fpm pods.

apiVersion: batch/v1
kind: Job
metadata:
  labels:
    job-name: queueworker-php
  name: queueworker-php
spec:
  backoffLimit: 6
  completions: 1
  parallelism: 1
  template:
    metadata:
      labels:
        job-name: queueworker-php
      name: queueworker-php
    spec:
      containers:
      - args:
        - echo running queue worker; cd /tmp/src; php artisan queue:work
        command:
        - /bin/sh
        - -c
      restartPolicy: OnFailure 
#/eerste helft

• Parallelism: (optioneel) Hoeveel pod replicas er parallel mogen draaien. Met andere woorden hoeveel worker processen mogen er tegelijkertijd draaien? Standaard-waarde is hetzelfde als completions, dus 1.
• completions: (optioneel) Hoeveel pods moeten klaar zijn met hun worker proces voordat een job als “completed” gemarkeerd kan worden. Standaard-waard is 1.
• Template: geef hier de metadata op voor de pod controller.
• De restart policy geeft aan waneer een pod herstart moet worden.

Let op! Zoals vermeld: met een job start je een ander proces binnen dezelfde php-image, in plaats van run.sh start je bijvoorbeeld php artisan queue:work. Doordat run.sh de code verplaatst en je run.sh niet uitvoert staat je code nog in de /tmp/src/ folder.

Dit gedeelte is vooral een copy-paste van de deployment-configuratie van je php-fpm pods.
Meestal wil je het volgende overnemen van de php-fpm pods die al zijn uitgerold via het template:

• De image; zo heb je dezelfde php-versie
• Config-maps; zo heb je dezelfde configuratie
• Secrets; bijvoorbeeld voor connecties naar S3, redis, databases etc.

# tweede helft        
        env:
        - name: DB_DATABASE
          valueFrom:
            secretKeyRef:
              key: DB_NAME
              name: $name-database-configmap
        - name: DB_USERNAME
          valueFrom:
            secretKeyRef:
              key: DB_USER
              name: $name-database-configmap
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              key: DB_PASS
              name: $name-database-configmap
        - name: DB_HOST
          valueFrom:
            secretKeyRef:
              key: DB_HOST
              name: $name-database-configmap
        image: docker-registry.default.svc:5000/$site-phpfpm
        imagePullPolicy: Always
        name: $site-phpfpm
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /usr/local/etc/php/conf.d
          name: $site-phpfpm-config
      dnsPolicy: ClusterFirst
      restartPolicy: OnFailure
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
      volumes:
      - configMap:
          defaultMode: 420
          name: $site-phpfpm-config
        name: $site-phpfpm-config

Uiteraard moet je de job uitrollen als 1 yaml-file

oc apply -f queueworker-php.yaml

Om logs te lezen moeten we weten wat de naam is van de queueworker-php-pod.

oc get pods

Vervolgens kun je met: oc logs <naam van de queueworker-php-pod> de logs terugzien van de queue-worker. bijvoorbeeld:
oc logs queueworker-php-abc123

Als de queue-worker-pod niet wil starten kan het zijn dat het command wat je hebt opgegeven in je yaml-file niet klopt. Je kan een debug-shell starten met met oc debug <naam van de pod>. Als je er achter bent wat het juiste commando is, kun je de job aanpassen met oc edit jobs/<naam-van-de-job>
Als de pod wel wil starten kun je troubleshooten met oc rsh <naam van de pod>.

Officiele documentatie, Openshift jobs Officiele documentatie, Kubernetes jobs