Getting Started With FusionReactor in CommandBox and Docker

3 Ways To Achieve Digital Transformation With AI
PlayStation 5 VS Xbox X: The Little We Know So Far

Getting Started With FusionReactor in Commandbox and Docker

I’ve spent the last few weeks playing with FusionReactor (FR) in my new Commandbox / Docker setup deployed on Fargate. I wanted to do some really casual benchmarks and get comfortable with how my deployment process was going to work. One of the pieces to my docker puzzle was how FusionReactor worked in docker containers, both in production, but also locally.

After all, the traditional Fusion Reactor model is the “on-premise” version, where you install the client, and access via a local URL. But how was this going to work in a containerized environment? Thankfully, the complexity of getting FR working within CommandBox is actually laughably simple. You will however need the “Hybrid” license.

Installing the Client

Our first job is installing the Commandbox Fusion Reactor module which bootstraps Fusion Reactor to any Commandbox server you start. To install the module, we simply need to run `box install commandbox-fusionreactor`. However, since I wanted this to be part of the Docker image, I just added that to my Dockerfile:

FROM ortussolutions/commandbox:3.0.2
LABEL maintainer “Example Person”

# Environment Variables
ENV FR_LICENCE “”
ENV FR_GROUP “Local”
ENV CFENGINE “lucee@5.3.6+61”
ENV HEADLESS “true”

COPY . /app
RUN box install commandbox-fusionreactor –verbose

# WARM UP THE SERVER
RUN ${BUILD_DIR}/util/warmup-server.sh

The eagle-eyed among you might spot a couple of `ENV` variables – one which is the Fusion Reactor Licence Key, and the other a “grouping” option.

Since I’m running this locally to start with via `docker-compose` I use a `.env` file containing the Fusion Reactor Licence Key – when deployed to AWS, this is stored in an AWS Secret, and pulled in at build/deploy time.

The last key to the puzzle is then ensuring that license key is passed to Commandbox, which is easily achievable via your `server.json` file:

Getting Started With FusionReactor in CommandBox and Docker, FusionReactor

You could of course add the Fusion Reactor module as a dependency in your `box.json` and do `box install` within your Dockerfile too; it’s up to you.

Checking it Worked

If all goes according to plan, when rebuilding your image, you should see some extra log lines:

Getting Started With FusionReactor in CommandBox and Docker, FusionReactor

Additionally, you should see some debug information after the warmup/install process:

Getting Started With FusionReactor in CommandBox and Docker, FusionReactor

Lastly, and most importantly, you should see the server pop up at https://app.fusionreactor.io/

Group all the things!

The `cloudGroup` passed into the Fusion Reactor module config is optional, but highly recommended, especially if like me you have multiple AWS environments for staging/production. As we can set these via environment variables, it makes tracking down a troublesome request a lot easier.

Server online counts

One caveat is to not panic about the number of offline servers that Fusion Reactor displays. In your Fargate cluster, if you have specified a certain number of tasks which must be running – say 4 instances – then each time you do a deployment, the 4 old tasks will be killed and 4 new ones take their place. If you botch a deploy or something like a configuration option doesn’t work, then there’s a risk that Fargate goes into a bit of a loop, constantly shutting down and starting servers to get a healthy one. This can mean your offline server count might spiral as Fusion Reactor UI still displays your unhealthy servers for 7 days or so by default.