Private Deployment
Rulebricks on GCP

Rulebricks on AWS

Configuration

Docker Compose via and GCE t2a-standard-2 (ARM instance) and a small (20GB) persistent disk. Postgres is hosted locally, so terraform destroy without a manually provisioned and attached volume will cause data destruction. For robust deployment using this method, we recommend also configuring standard snapshots of the disk to recover data in the case of an outage.

Instructions

Running the single terraform script provided to you via terraform apply should be all you need to create your own, private instance of Rulebricks, but there are two major things to keep in mind before execution.

  1. You will need to update your DNS records quickly after terraform completes creating resources. We recommend deciding on a subdomain, and logging in and pulling up your DNS management console for wherever your primary domain is hosted before running terraform.
  2. There are certain defaults inside the terraform script you may wish to customize, such as the locations/regions of any resources created. Like any terraform script you execute, we recommend a complete read-through to thoroughly understand the resources being created. Things in the script you may need to line up, should you edit the deployment region:
    1. Region (any valid GCE region e.g. us-central1)
    2. Availability Zone (any valid zone within the selected region e.g. us-central1-a)

Receiving Updates

Live updates using our compose scheme cause a small amount of downtime (1 min/update received)– unless a blue-green scheme is engineered manually, which we do not have.

Your deployment will automatically scan for updates via watchtower at a rather high frequency of once a minute– this can be disabled and will regardless be adjusted down and towards periods of low usage as our private cloud offering matures.

Resolving Issues

Issues with deployment can usually be resolved by reading the contents of sudo journalctl -u google-startup-scripts.service (GCP’s startup script logs)