Docker container for a Cronicle single-server master node
This repo is based on the work from nicholasamorim
Some useful features were included in order to facile automation and integration into a CI/CD platform.
- automatic creation of account, plugins and apiKeys during initial setup
- default plugin for a mongo db backup with S3 upload
- automatic creation of events during initial setup
- aws-ci installed by default
latest
,0.5.0
, Dockerfile
Latest version of Cronicle server based upon nodejs Docker image.
docker pull stepos01/docker-cronicle:latest
docker run --name cronicle --hostname localhost -p 3012:3012 stepos01/docker-cronicle:latest
Alternatively with persistent data and logs:
docker run --name cronicle \
-v /path-to-cronicle-storage/data:/opt/cronicle/data:rw \
-v /path-to-cronicle-storage/logs:/opt/cronicle/logs:rw \
--hostname localhost -p 3012:3012 stepos01/docker-cronicle:latest
The web UI will be available at: http://localhost:3012
NOTE: please replace the hostname
localhost
, this is only for testing purposes! If you rename the hostname also consider setting the environmental variableCRONICLE_base_app_url
. e.gdocker run --name cronicle --hostname cronicle-host -p 3012:3012 -e CRONICLE_base_app_url='http://cronicle-host:3012' stepos01/cronicle:latest
Cronicle process runs under the cronicle
user with ID 1001
and GUID
1001`. If you are using Docker bind mounts set permissions accordingly.
Path | Description |
---|---|
/opt/cronicle/data | Volume for data |
/opt/cronicle/logs | Volume for logs |
/opt/cronicle/plugins | Volume for plugins |
Cronicle supports a special environment variable syntax, which can specify command-line options as well as override any configuration settings. The variable name syntax is CRONICLE_key
where key
is one of several command-line options (see table below) or a JSON configuration property path.
For overriding configuration properties by environment variable, you can specify any top-level JSON key from config.json
, or a path to a nested property using double-underscore (__
) as a path separator. For boolean properties, you can specify 1
for true and 0
for false. Here is an example of some of the possibilities available:
Environmental variable | Description | Default value |
---|---|---|
CRONICLE_base_app_url | A fully-qualified URL to Cronicle on your server, including the port if non-standard. This is used for self-referencing URLs. | http://localhost:3012 |
CRONICLE_WebServer__http_port | The HTTP port for the web UI of your Cronicle server. (Keep default value, unless you know what you are doing) | 3012 |
CRONICLE_WebServer__https_port | The SSL port for the web UI of your Cronicle server. (Keep default value, unless you know what you are doing) | 443 |
CRONICLE_web_socket_use_hostnames | Setting this parameter to 1 will force Cronicle's Web UI to connect to the back-end servers using their hostnames rather than IP addresses. This includes both AJAX API calls and Websocket streams. |
1 |
CRONICLE_server_comm_use_hostnames | Setting this parameter to 1 will force the Cronicle servers to connect to each other using hostnames rather than LAN IP addresses. |
1 |
CRONICLE_web_direct_connect | When this property is set to 0 , the Cronicle Web UI will connect to whatever hostname/port is on the URL. It is expected that this hostname/port will always resolve to your master server. This is useful for single server setups, situations when your users do not have direct access to your Cronicle servers via their IPs or hostnames, or if you are running behind some kind of reverse proxy. If you set this parameter to 1 , then the Cronicle web application will connect directly to your individual Cronicle servers. This is more for multi-server configurations, especially when running behind a load balancer with multiple backup servers. The Web UI must always connect to the master server, so if you have multiple backup servers, it needs a direct connection. |
0 |
CRONICLE_socket_io_transports | This allows you to customize the socket.io transports used to connect to the server for real-time updates. If you are trying to run Cronicle in an environment where WebSockets are not allowed (perhaps an ancient firewall or proxy), you can change this array to contain the polling transport first. Otherwise set it to ["websocket"] |
["polling", "websocket"] |
A custom configuration file can be provide in the following location:
/path-to-cronicle-storage/data/config.json.import
The file will get loaded the very first time Cronicle is started. If afterwards a forced reload of the custom configuration is needed remove the following file and restart the Docker container:
/path-to-cronicle-storage/data/.setup_done
A sample config can be found here
As mentioned earlier, one of the additional feature is related to automating the creation of users, groups, apiKeys... We simply need to modify the setup.json provided in this repository
The file will get loaded the very first time Cronicle is started. If afterwards a forced reload of the custom configuration is needed remove the following file and restart the Docker container:
/path-to-cronicle-storage/data/.setup_done
A more exhaustive explanation about the possibilities can be found in the following thread: Thread on automating cronicle by the author
In the setup.json
file, we can see the creation of an user with username
stephane
and password admin
. This is achieved by updating the
following JSON with
Lines 16 to 27 in e7982bb
Details about values to be used can be found here Thread on automating cronicle by the author
In the setup.json
file, we can see the creation of a plugin called
mongobackup
.
Lines 62 to 81 in e7982bb
plugins
folder.
Our events created from the mongo backup plugin expects a few parameters
Parameter name | Description |
---|---|
name | the name of the backup |
uri | the mongo url of the database ( tested with srv format). The utility used for backup is mongorestore. |
aws_access_key_id* | AWS secret key |
aws_secret_access_key* | AWS secret key |
aws_default_region* | AWS default region |
s3_destination | the destination on S3(Could be any bucket or path. e.g: mybucket/cronicle/mybackups |
*: those parameters are set as hidden. So they are added attached to the plugin directly and are assigned a value, and they cannot be seen nor modified afterwards without rebuilding and redeploying the container. This is done to avoid exposing private keys on the Cronicle user interface.]
In the setup.json
file, we can see the creation of a category
called mongo
. This is achieved by updating the
following JSON with
Lines 114 to 123 in e7982bb
In the setup.json
file, we can see the creation of an API Key.
Lines 144 to 162 in e7982bb
adminKey
, we should update it as well
in the plugins/create-jobs.sh
docker-cronicle/plugins/create-jobs.sh
Lines 3 to 7 in e7982bb
Much more can be achieved by modifying the setup.json
file.
A good starting point can be found there:
Event can be created automatically during the initial setup.
You just need to create the proper JSON file and add it into the jobs
folder.
This project contains two sample jobs.
- one for running a mongo backup, once a day at 4 AM
- one for running a POST http call every 5 minute to a dummy endpoint
A hack for quickly prototyping event, is to create them from the UI, then observe the traffic and capture the payload of the request made by the browser ruding the creation of the event. Once you have the payload, you can modify it and add it to the jobs folder.
The creation of jobs is done through API using a plugin.
The script in charge of creating the jobs can be found here.
The script is launched 90s after starting the server.
We will notice the presence of the ApiKey which was created earlier in the setup.json
The default credentials for the web interface are: admin
/ admin
https://github.com/nicholasamorim/docker-cronicle https://github.com/jhuckaby/Cronicle