Running WebHelpDesk in Docker

In a previous post, I walked through the process of creating a customized Postgres database container in Docker that accepts remote connections. The main purpose of that container is to use with WebHelpDesk, a Tomcat-based ticketing and asset tracking system.

WebHelpDesk does include an embedded Postgres database that it can use to keep track of its internal data (which is probably how many customers use it, including myself prior to Dockerizing it), but that gives us some problems. First off, we have to make sure we preserve all data in that Postgres database, so that it survives independent of the container. Secondly, the embedded Postgres version does not live in the same place as a “typical” Postgres install, and thus makes special configuration or tuning more awkward. By using an external database, we can exert far more control over the actual database’s running parameters (and make changes far more easily).

All of these are good reasons to use an external database, which is what we’re going to do with the macadmins/postgres image.

In this post, I’m going to run my Dockerized version of WebHelpDesk. This blog post is an extended version of the README for the WebHelpDesk Docker image.

Prepare the Data Container for the DB:

As always, we want to keep our data safe so that it’s independent of the container running the service. Run a data container for our customized Postgres image:
docker run -d --name whd-db-data --entrypoint /bin/echo macadmins/postgres Data-only container for postgres-whd
Now run the actual Postgres database, linking to our data container, passing in the appropriate environment variables (change the password, obviously):
docker run -d --name postgres-whd --volumes-from whd-db-data -e DB_NAME=whd -e DB_USER=whddbadmin -e DB_PASS=password macadmins/postgres

Prepare the data container for WHD:

Same deal applies to the WebHelpDesk data container:
docker run -d --name whd-data --entrypoint /bin/echo macadmins/whd Data-only container for whd
And the actual container itself:
docker run -d -p 8081:8081 --link postgres-whd:db --name whd --volumes-from whd-data macadmins/whd
Here, we use -p 8081:8081 to map port 8081 in the container to our localhost:8081.

Configure WHD Through Browser:

The container is now running, so we can access it via the web browser at http://localhost:8081/ on the Docker host.

The first time you launch WebHelpDesk, it goes through its initial setup.

This is where we get our chance to tell it not to use its embedded database, but instead use our linked Postgres database. Use the following parameters:
1. Database type: postgreSQL (External)
2. Host: db
3. Port: 5432
4. Database Name: whd
5. Username: whddbadmin
6. Password: password
Obviously, if you changed any of the -e DB_XXXX environmental variable values in the docker run command above, recreate those values above for the username, password, and database name. You can click the “Test” button to verify that the database connection works.

Note: if you try using a regular Postgres database, such as the default Postgres container, instead of the customized one, you’ll notice that the database connection will always fail.

You can skip email customization, it’s not required for setup.

Set up your preferred administrative account name & password. In the interest of best practices with security, consider using a username that isn’t “admin” for a production system.

Continue setup until you are asked to log in, and then use the credentials you specified above for name & password.

Some considerations

One significant note is that we’re running WebHelpDesk over HTTP, meaning it’s not secured. You’ll almost certainly want to configure WebHelpDesk for SSL before promoting into production use.

Additionally, you’ll probably want to get an actual SSL certificate, and not used a self-signed one.

Note that if you do set up SSL, Tomcat stores the private key for its SSL cert in its keystore, located at WebHelpDesk/conf/keystore.jks. This keystore will need to be preserved, because if the WebHelpDesk container is ever removed, so will that keystore, along with the private key that generated the CSR. If you spin another container up, your SSL certificate will most likely not be valid due to non-matching private keys in the keystore.

Configuring WebHelpDesk for SSL in Docker is a good topic for another blog post.