Before the summer the Butler tool turned two years old – time flies!
Over those years I have installed, tweaked and upgraded a fair number of Butler instances… Not a problem per se, but maintaining a production grade Butler instance does assume a certain level of experience around Node.js, Linux, networking etc.
The most recent Butler version (v2.2) attempts to make it easier to deploy and operate Butler. This is achieved by deploying Butler as a Docker container instead of a regular Node.js app.
The Docker image (from which a container is created) contains exactly the same Node.js app that you can run right on your server or laptop – i.e. there is no functional difference what so ever between running the Node app natively, and running it as a Docker container.
There are some significant benefits of running Butler under Docker:
I worked out the issue preventing me to add additional nodes to a Qlik Sense Enterprise suystem whose central node had been updated to June 2018.
The June 2018 version of Qlik Sense Enterprise relies on a database called “SenseServices” to be available in the Postgres db (as in earlier versions, Postgres can run on the central node or on some other server).
When running the June 2018 installer on a new server (which is to be added as a new node in a Sense Enterprise cluster), the installer verifies that the SenseServices database exists. If it does not, you get an error half-way through the installer:
Maybe there is info somewhere that you need to create a new “SenseServices” db in Postgress before installing additional Sense nodes… but I looked (a lot) without finding anything.
Qlik’s annual Qonnections conference in Orlando wrapped up yesterday.
Three days packed with the latest from both the Qlikosphere in general and Qlik in particular.
I had more session conflicts (where I wanted to attend several interesting sessions at the same time) than during any previous year, which is a sign of interesting topics, hopefully also of high quality sessions.
This one is long overdue, but finally here: Butler SOS v2.0
The new version is an almost complete re-write of v1.0. Changes are plentiful and include
All warnings and errors stored by Sense in its log database are now pulled into Butler SOS, from where it can be graphed and acted upon. This is a big deal, as it was previously not possible to get notifications or alerts when errors or warnings started to pile up in the logs.
Operational health metrics are still pulled from Qlik Sense, but this is now done directly from the QIX engine rather than via a hard-to-secure virtual proxy.
Using certificates for authentication with Sense removes potential security issues with v1.0.
Config file is now YAML instead of JSON. More human readable and with inline comments.
Config file now allows for more fine-grained control of Butler SOS.
Several bugs fixed, especially around sending metrics to MQTT.
The readme file on GitHub has all the details, here are some screen shots to get you started though:
Google has licensed Simba’s driver, which is great! The Simba driver has proven very stable and performant, and being able to use it freely to access data in BigQuery is likely to benefit BigQuery adoption.
The Simba drivers support both Standard and Legacy SQL modes in BigQuery, as well as large result sets, and are confirmed to be working very nicely with Qlik Sense September 2017 version.
There are versions available for 32/64 bit Windows, OS X, and 32/64 bit Linux.
I recently had a need for an isolated Qlik Sense environment, in order to test some of the new features of Qlik Sense September 2017.
While it works perfectly fine to run Sense with self-signed certificates, you then get browser warnings that the certificates are not valid etc. That might be fine, but as the test at hand involved testing my app duplicator service for Qlik Sense (which require a proper SSL cert) together with the September 2017 version of Sense, I needed a proper SSL certificate.
As I have good experiences using the free certificates of Let’s Encrypt (they secure this blog, for example) I thought it would be a good exercise figuring out how to use them together with Qlik Sense Enterprise.
The notes below are largely reminders-to-self, in case I need to do this again some day. Maybe they can also be useful for others out there.
When relying on various Node.js services (e.g. Butler SOS, Butler, App Duplicator etc), you quickly run into the challenge to ensure all services are always up and running.
A failing service might be fine, as long as it is quickly restarted in a predictable way.
A concrete example could be Qlik Sense or QlikView apps that send status messages to Slack during the execution of their reload scripts. Those messages will fail if Butler is for some reason not running.
This leads us to the conclusion that the services must automatically be
a) started when a server is rebooted, and
b) restarted if they for some reason terminate/die.
Enter process monitors.
At their core, process monitors ensure that the desired processes are always running, i.e. bullet b) above. Some process monitors also offer additional features such as zero-downtime restart of services, memory and performance profiling of the monitored services, being able to monitor different kinds of processes (not only Node.js ditto).
Adding to the pain is the fact that Sense and QlikView runs on Windows servers, meaning that all those great tools available on Linux cannot be used.
Looking at Node.js specifially, I have found two process monitors to work well on Windows: Forever and PM2.