At work we use OTRS for our help desk platform. We chose it because it’s open source and very flexible, and we could install it on our premises to have more control. So, I went ahead and made a set of docker containers that we have been running multiple OTRS 4 .0.x installations for small companies for more than a year now without issues. Now I’ve had some time to upgrade the containers to OTRS 5.
The first thing to know is that this is an unofficial OTRS docker container.
For setting up an OTRS system you need several services:
- A web server with the OTRS installation.
- A database server.
- An SMTP server.
- A proxy server (optional).
This container setup is designed that way. It uses:
- A CentOS 6.6 based container, with the latest version of OTRS installed on it according to the official installation instructions.
- A Mariadb container, pre-configured for OTRS database requirements.
- A volume container to save the data for the previous two containers.
- A Postfix SMTP relay container.
- A nginx based proxy container.
The docker-compose configuration files include all of those services, and upon container start a fresh OTRS install will be started, ready to to be configured by an OTRS administrator.
There are some environment variables you can use to control the container startup and initial state. For example, the container can be started in three ways, controlled by the OTRS_INSTALL environment variable:
- OTRS_INSTALL=no when the container is run, it will load a default vanilla OTRS installation that is ready to be configured as you need. This is the default.
- OTRS_INSTALL=yes will launch the OTRS install web interface at http://localhost/otrs/install.pl.
- OTRS_INSTALL=restore Will restore the backup specified by the OTRS_BACKUP_DATE environment variable. OTRS_BACKUP_DATE is the backup name to restore, in the same date_time format that the OTRS backup script uses, for example OTRS_BACKUP_DATE=”2015-05-26_00-32″. Backups must be inside the /var/otrs/backups directory (you should host mount it).
You need to mount that backups volume from somewhere, it can be from another volume (using –volumes-from) or mounting a host volume which contains the backup files.
For testing the containers you can bring them up with docker-compose:
sudo docker-compose build
sudo docker-compose up
This command will build all containers and pull missing images, bring up all needed containers, link them and mount volumes according to the docker-compose.yml configuration file:
version: '2' services: otrs: build: context: otrs args: OTRS_VERSION: 5.0.10-01 ports: - "80:80" # If running behind a proxy container, expose the ports instead # and link the proxy container to this one. # expose: # - "80" links: - mariadb:mariadb - postfix:postfix volumes_from: - data mariadb: build: context: mariadb expose: - "3306" volumes_from: - data environment: MYSQL_ROOT_PASSWORD: changeme postfix: image: juanluisbaptiste/postfix:latest expose: - "25" env_file: credentials-smtp.env data: image: centos/mariadb:latest volumes: - /var/lib/mysql - "./otrs/backup:/var/otrs/backups" command: /bin/true
The default database password is changeme, to change it, edit the docker-compose.yml file and change the MYSQL_ROOT_PASSWORD environment variable on the mariadb image definition before running docker-compose.
To start the containers in production mode use this docker-compose.yml file that points to the latest version of all images to be pulled and run instead of Dockerfiles to be built:
sudo docker-compose -f docker-compose-prod.yml pull sudo docker-compose -f docker-compose-prod.yml -p company_otrs up -d
After the containers finish starting up you can access the administration and customer interfaces can be accessed at following addresses:
There are also some other environment variables that can be set to customize the default install, like root and database passwords, language, theme, ticket counter start, number generator, etc, check the github page for more info. OTRS 4 sources are still available in otrs-4_0_x branch.