OpsLevel has chosen to partner with Replicated to provide a superior installation & support experience for self-hosting a copy of OpsLevel the application.
- A License file provided by OpsLevel
- A place to host the application (VM or Kubernetes cluster)
- Admin access in various 3rd Party software to setup integrations
Your OpsLevel account manager will provide your license and instructions for how to perform the installation depending on if you are using a VM or a Kubernetes cluster to host the application.
If you would like to know more about the installation methods you can read about them over at Replicated
Replicated provides you with a Customer Admin Console to manage the lifecycle of self-hosted OpsLevel application.
Once you have performed the installation and you have logged into the customer admin console you will be asked to provide your license file before you can begin any of the configuration.
If you have provided a valid license you will then be prompted with a configuration screen to supply any additional configuration for things like: connecting to an external MySQL DB, integrating with 3rd Party software like Github, Jira & Pagerduty etc.
By default, you do not need to adjust anything other than the Account Configuration as standard defaults have been provided. Certain integrations will be unavailable within the app if the configuration is not provided)
The following sections describe in more details each configuration section.
The section provides you an easy way to generate a Kubernetes ingress manifest which exposes the application frontend through your clusters ingress controller.
The Ingress Subdomain and Ingress Domain are used to configure the Kubernetes ingress resource and to allow the application to perform link generation for e-mails.
The Ingress Annotations section must be in YAML format and will be applied to the Kubernetes ingress. There are 2 default annotations that we recommend to help protect the application from large payloads causing the application from consuming excessive memory. If you do intend to send payloads larger than that please increase the amount.
By default, the installation creates a MySQL container alongside the application for getting started quickly.
This is not recommended for production and as such, this section provides you with the detailed configuration needed to allow the application to connect to an “external” MySQL database that has been hardened for production and is monitored by you.
The MySQL database is where all of the data of the application is stored. If this database is destroyed all of the data within OpsLevel is also destroyed. We recommend you setup regular backups.
There are a handful of MySQL parameters that need to be set that we have enumerated here but do also note that we have configured preflight checks to ensure the database OpsLevel connects to will work properly.
[mysqld] init_connect='SET collation_connection = utf8mb4_unicode_ci,NAMES utf8mb4' character_set_server = 'utf8mb4' collation_server = 'utf8mb4_unicode_ci' [client] default_character_set = 'utf8mb4'
Our application is configured to perform any pending migrations on this database at startup. Please be aware that this is not an “online” process and as such may lock the database for a period of time while the migrations complete preventing use of the application. This is something we are looking into changing in the future.
By default the installation creates a container of Redis alongside the application for the purposes of getting started quickly. This is not recommended for production and as such this section provides you with the configuration needed to allow the application to connect to an “external” Redis database that has been hardened for production and is monitored by you.
The Redis database is used to store pending asyncrnous jobs waiting to be processed. If this database is destroyed all that is lost is pending jobs. For the most part many asynchronous tasks will be re-enqueued at a later time but there are a few cases where losing the job means that specific data that was ingested will never be processed.
This section allows you to configure SMTP settings so that the application may send e-mails. It is recommended that you give the application access to send e-mail so you may receive the following types of e-mails:
- User Invite
- Password Reset
The following 3rd Party integrations will require that the application is exposed to the internet so that the 3rd Party software can send data to the application (usually in the form of a webhook).
To create a GitHub App follow these instructions
Then provide the configuration options which can be found on the settings page of the created GitHub App
To create a User Owned Gitlab App follow these instructions
You will need to ensure the redirect uri has the following path added to it
/integrations/gitlab/finish_setup and has the scopes
read_repository as seen in this example:
To create a Bitbucket Webhook follow these instructions
To create a PagerDuty App follow these instructions to setup the application.
Once the app is created you’ll need to add OAuth2 functionality. Enter the callback url of your exposed OpsLevel application and click save. Copy the Client ID and Client Secret and set them in the configuration respectively.
Once you have completed all the needed configurations you can click next and the preflight checks will begin to run. The purpose of these checks is to ensure the configuration you’ve given and the location you intend to host the application has the best chance of starting up correctly. If any of the preflight checks fail you will need to fix them before completing the installation.
At this point you should now have a running self-hosted OpsLevel.
If you are having trouble setting up your self-hosted OpsLevel in any way, send us an email at email@example.com and we’ll be happy to help debug and diagnose any issues.