GitHub action to deploy Prometheus and Grafana.

Supported Cloud Providers:

• AWS

Note: This action is currently in beta. Please report any issues you find by creating an Issue or a Pull Requests

This project is supported by Bitovi, a DevOps Consultancy and a proud supporter of Open Source software.

You can get help or ask questions on our Discord channel! Come hang out with us; We love discussing solutions!

Or, you can hire us for training, consulting, or development. Set up a free consultation.

This is a list of requirements you'll need to meet in order to use this action.

1. An AWS account (yep, that's it!)

You'll need Access Keys from an AWS account

Secrets first! First, fill out the values in the .env.example file. Then, create a secret in your repo called DOT_ENV and paste the contents into it. (Do NOT commit any files with your secrets in them!) If not set, Grafana will use the default admin/admin. (You can change this in the first login.)

Create .github/workflow/deploy.yaml with the following to build on push.

name: Basic deploy
on:
  push:
    branches: [ main ]

jobs:
  Prometheus-Deploy:
    runs-on: ubuntu-latest
    steps:
    - id: deploy
      name: Deploy
      uses: bitovi/[email protected]
      with:
        aws_access_key_id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws_secret_access_key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        env_ghs: ${{ secrets.DOT_ENV }}

Once deployed, Visualize the metrics in the Prometheus UI itself (port :9090) or visualize via Grafana (port :3000).

name: Advanced deploy
on:
  push:
    branches: [ main ]

permissions:
  contents: read

jobs:
  Prometheus-Deploy:
    runs-on: ubuntu-latest
    steps:
    - id: deploy
      name: Deploy
      uses: bitovi/[email protected]
      with:
        aws_access_key_id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws_secret_access_key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws_session_token: ${{ secrets.AWS_SESSION_TOKEN }}
        aws_default_region: us-east-1
        aws_ec2_instance_type: t2.small
        aws_additional_tags: "{\"key1\": \"value1\",\"key2\": \"value2\"}"

        aws_r53_domain_name: example.com
        aws_r53_sub_domain_name: app

        env_ghs: ${{ secrets.DOT_ENV }}
        env_ghv: ${{ vars.VARS }}

        
        grafana_datasource_dir: sandbox/observability/grafana/datasources
        prometheus_config: sandbox/observability/prometheus/prometheus.yml
        grafana_scrape_interval: 60m
        prometheus_scrape_interval: 60m
        prometheus_retention_period: 365d
        cadvisor_enable: true
        cadvisor_extra_targets: "target1:8080,target2:8080"
        node_exporter_enable: true
        node_exporter_extra_targets: "target1:9100,target2:9100"
        # Advanced options
        aws_ec2_port_list: "9090,3000,8080,9100"
        aws_elb_create: false

1. Action Defaults
2. AWS Configuration
3. Secrets and Environment Variables
4. EC2
5. Stack
6. Stack Management
7. Domains
8. VPC
9. Advanced Options

The following inputs can be used as step.with keys

aws_ec2_instance_public_ip is a must if deployment is done using GitHub runners. Needed to access instance and install Docker. Only set this to false if using a self-hosted GitHub runner with access to your private IP.

As a default, Prometheus and Grafana ports (9090,3000) for the EC2 instance are being exposed. (aws_ec2_port_list). An ELB will also be created exposing them too.

The load balancer will listen for outside connections (aws_elb_listen_port) and forward this traffic to the defined ports (aws_elb_app_port). You can change all of this values to expose the services you wish, directly from the EC2 instance or through the ELB. (No need to expose EC2 instance port for ELB ports to work.). You can even set different listening ports for the ELB. (aws_elb_listen_port will map 1 to 1 with aws_elb_app_port.).

Tip: Setting aws_elb_listen_port to 3000 will only expose Grafana. No need to set anything else.

ELB is a must if you intend to use DNS and/or certificates. (aws_elb_create must be true).

For envirnoment variables in your app, you can provide:

• env_repo - A file in your repo that contains env vars
• env_ghv - An entry in Github actions variables
• env_ghs - An entry in Github secrets
• env_aws_secret - The path to a JSON format secret in AWS

These environment variables are merged (in the following order) to the .env file and provided to both the Prometheus and Grafana services:

• Terraform passed env vars ( This is not optional nor customizable )
• Repository checked-in env vars - repo_env file as default. (KEY=VALUE style)
• Github Secret - Create a secret named DOT_ENV - (KEY=VALUE style)
• AWS Secret - JSON style like '{"key":"value"}'

Most resources will contain the tag ${GITHUB_ORG_NAME}-${GITHUB_REPO_NAME}-${GITHUB_BRANCH_NAME}, some of them, even the resource name after. We limit this to a 60 characters string because some AWS resources have a length limit and short it if needed.

We use the kubernetes style for this. For example, kubernetes -> k(# of characters)s -> k8s. And so you might see some compressions are made.

For some specific resources, we have a 32 characters limit. If the identifier length exceeds this number after compression, we remove the middle part and replace it for a hash made up from the string itself.

Buckets names can be made of up to 63 characters. If the length allows us to add -tf-state, we will do so. If not, a simple -tf will be added.

As a default, the application will be deployed and the ELB public URL will be displayed.

If domain_name is defined, we will look up for a certificate with the name of that domain (eg. example.com). We expect that certificate to contain both example.com and *.example.com.

If you wish to set up domain_name and disable the certificate lookup, set up no_cert to true.

Setting create_root_cert to true will create this certificate with both example.com and *.example.com for you, and validate them. (DNS validation).

Setting create_sub_cert to true will create a certificate just for the subdomain, and validate it.

⚠️ Be very careful here! Created certificates are fully managed by Terraform. Therefor they will be destroyed upon stack destruction.

To change a certificate (root_cert, sub_cert, ARN or pre-existing root cert), you must first set the no_cert flag to true, run the action, then set the no_cert flag to false, add the desired settings and excecute the action again. (This will destroy the first certificate.)

This is necessary due to a limitation that prevents certificates from being changed while in use by certain resources.

BitOps allows you to define Infrastructure-as-Code for multiple tools in a central place. This action uses a BitOps Operations Repository to set up the necessary Terraform and Ansible to create infrastructure and deploy to it.

We would love for you to contribute to bitovi/github-actions-deploy-prometheus and help make it even better than it is today!

Would you like to see additional features? Create an issue or a Pull Requests.

The scripts and documentation in this project are released under the MIT License.