Deploy SupportPal using Docker (Microservices)

SupportPal provides a docker image intended for use in a microservice style architecture, whereby each service is deployed to a separate container.

This guide is tailored towards experienced DevOps engineers and provides a broad overview of how to use the image. The user is expected to separately configure several components such as a webserver, a MySQL database, and more. Gaps are intentionally left in this document, and the user is expected to fill them based on their individual requirements.

Docker Monolithic
If you wish to use a simpler, more streamlined, setup we recommend Docker Monolithic.

Contents

Repository
Architecture
Installing the Helpdesk
High Availability Usage (Advanced)

Repository

SupportPal provides a universal image which is preconfigured with all dependencies, optimised software settings and security hardened.

It is available from AWS ECR with tags matching an application version which is greater than 5.0.0. For example: public.ecr.aws/supportpal/helpdesk:5.0.0

Architecture

There are few expectations and dependencies on 3rd party services that the helpdesk software relies on to operate normally - all are available for free.

Persistence and storage

A typical docker container is ephemeral, and should be treated as such. However, SupportPal containers need several directories to persist indefinitely so the data is not lost. The following directories in the image are expected to be persisted. The same data should be shared and synchronised for all containers using the SupportPal image.

/supportpal/addons
/supportpal/config/production
/supportpal/storage

Containers

The software expects the following containers:

Web Server
Use of a supported web server.

Web workers (php-fpm)
php-fpm workers can be spawned from our image using:


docker run --name supportpal public.ecr.aws/supportpal/helpdesk:${APP_VERSION} bash /etc/cmd/php-fpm.sh

Database
Use of a supported database.

Task Scheduler
The software relies on a periodic cron job.


docker run --name supportpal public.ecr.aws/supportpal/helpdesk:${APP_VERSION} bash /etc/cmd/cron.sh

The following containers are optional, but highly recommended in a production environment:

Redis
Redis should replace the built-in file based storage systems. See configuring Redis for further guidance.
Websocket server
The built-in AJAX polling based system should be replaced with a web socket server. The image will automatically configure and enable web sockets. If you need to make changes to the connection details, you can do so via the operator panel at Settings -> General -> Third-Party Integrations -> Pusher.
```
docker run --name supportpal public.ecr.aws/supportpal/helpdesk:${APP_VERSION} bash /etc/cmd/sockets.sh
```
Background Jobs
Background jobs rely on a Redis connection, and the SUPPORTPAL_QUEUE_CONNECTION environment variable:
```
SUPPORTPAL_QUEUE_CONNECTION=redis
```
Background jobs can be spawned using our image:
```
docker run --name supportpal public.ecr.aws/supportpal/helpdesk:${APP_VERSION} bash /etc/cmd/queues.sh
```
Meilisearch
Meilisearch offers a more reliable search experience, than the built-in method. See configuring Meilisearch for further guidance.

Mail Transport Agent (MTA)

The Docker image does not include a mail transport agent (MTA), as such the built-in PHP mail() option will not work without additional configuration. For simplicity, we recommend to make use of the built-in SMTP option as this does not require additional Docker configuration.

A Functional Example

A functional example of a deployment built using this images, using docker-compose can be found at: github://supportpal/helpdesk-install .

Installing the Helpdesk

Start by having one container online (php-fpm), and run the following command:


docker exec -it supportpal bash /scripts/init-helpdesk.sh

High Availability Usage

For setups with high-load, it may be necessary to scale your infrastructure to having multiple containers of each task running. For example, if the helpdesk is having an influx of HTTP requests the number of php-fpm containers could be scaled up.

Storage Considerations

As mentioned previously, there are a few directories which must be kept synchronised across containers.

SupportPal Marketplace (/supportpal/addons)

This directory is special because it contains code that loads on every request. In a HA deployment we recommend:

To use a high-bandwidth, low latency, shared storage for this directory
To build a custom docker image based on the image provided, and bundle any necessary addons. This would eliminate the necessity to persist the /supportpal/addons directory. However, beware, that this would also prevent use of the marketplace from within the software itself.

/supportpal/storage

We recommend to make use of an S3 compatible service for storing files in the storage/ directory. See configuring cloud storage for guidance.

Other directories

For all other directories, we recommend using a high-bandwidth, low latency, share storage service.