An application can span across multiple Environments within your infrastructure, but have almost identical desired configuration. This guide covers arranging nodes into Environments and Node Groups appropriately and how to utilize Environment Variable Overrides.

Overview

If you are managing an application through various environments (e.g. UAT, staging, pre-prod, production) you may like to enforce that the configuration of your application is correct through each stage. However, due to the subtle differences between each environment, some slight changes to configuration are sometimes required.

This guide describes a simple web server and database application that exists through a development, staging and production life cycle. We want to monitor the configuration of each of the instances of the application through the various Environments with the same policy, but have automatic overrides depending on the Environment a node exists in.

In particular, this guide will:

  • describe the application architecture and some basic configuration we would like to monitor,
  • how to arrange these nodes into appropriate Node Groups and Environments in UpGuard Core,
  • how to create Environment Variable Overrides for each Environment, and
  • how to create a simple Policy that can be applied to each Node.

Note: It is also possible to define Node Group Variable overrides. When defining multiple variable overrides across environments and nodes, you can also define a priority or precedence order.

Application Architecture

For the purpose of this guide, we are going to use a single web server node connected to a database. The web server could be a Linux VM running Apache web server and the postgres

The web server node will be a Linux VM running, Apache web server, for example and the database node will be a postgres server, for example. This application is deployed into 2 Environments: development, staging and production. The table below outlines the hostnames of each of the 6 nodes.

Environment Web Server Node Database Node
development web-dev db-dev
staging web-stg db-stg
production web db

Arranging Nodes into Node Groups and Environments

For general information on how to add various types of nodes, please visit our Getting Started Guide.

Assuming that each of the 6 nodes have been added to the UpGuard interface, we are first going to arrange them into their respective Environments. For assistance on adding a new Environment, please refer to our guide on Creating an Environment.

Since the development and staging nodes are names with a particular suffix, when adding the new Environments, you could also specify the following node rules so that nodes can be automatically assigned to the correct Environment.

Environment Node Rule
Development .*-dev$
Staging .*-stg$

Note: we cannot define node rules for the production nodes in this scenario as the production nodes in our Environment do not have a common naming suffix. We will have to edit these nodes individually to transfer them from the Default Environment to the Production Environment.

We will next need to assign nodes into node groups. Nodes can belong to one or more node groups, and all nodes are assigned into the All Nodes node group by default. An eventual policy we create later, must be assigned to a node group, so we’re going to segment nodes into groups based on the common policy they should have applied to them. Here, we could create the following node groups for the corresponding reasons:

Node Group Member Nodes Reason
Web Servers web-dev, web-stg, web We may have common attributes we would like to enforce across identically web servers.
Databases db-dev, db-stg, db We may have common table structure or configuration we want to validate across all databases.
Applications all 6 nodes Not so much for policy assignment, but we may want to report on the compliance and health of all 6 nodes as a group.

For more information around creating node groups and adding nodes to a node group, please refer to our guide on Node Groups.

Creating Environment Variable Overrides

In this scenario, we are eventually going to write a policy that checks that the IP address of the corresponding DB server is correct for each web server. Instead of writing 3 separate policies for web server nodes in each Environment, we can write a single policy and use Environment Variable Overrides to look for the correct value depending on the Environment.

To create a new variable, navigate to Control > Variables then click “Create Variable”.

w600

Here we’re going to have a variable called database_ip and we’re going to set a default value of 192.168.1.1. For this particular scenario, it might be good practice to set the default value of a variable to the value associated with the Development Environment and then only supply overrides for staging and production. Click Save Variable.

Next, we need to define variable overrides for the other Environments. To add a variable override, locate the variable, click on the menu for the variable on the right hand side and click Add Override.

w600

In the screenshot below we are defining an Environment type of override, on the Environment Production and we’re going to use the override value 192.168.1.123.

w400

After adding a second variable override for the Staging Environment you should see the variable listed along side the overrides for each subsequent Environment.

w600

Using the Variable and its Overrides in a Policy

On each of the web server nodes, the IP address of the associated database is defined for the application in an environment variable called DB_HOSTNAME. Here, we can create a new policy check that applies to the CI path EnvVars > * > DB_HOSTNAME. We want to check that the value of this environment variable on each node has a value matching the variable (with any overrides applied).

The screenshot below shows how to configure this type of check. We define the attribute name as Value as we want to check the scanned environment variable’s value. We would like the Value attributes value to have an Exact Match with the value stored in our variable. We substitute out variable into the expected value by using the mustache curly brace syntax.

w500

After creating this policy check we would next navigate to the web server node group via the Discover > Monitored page and then assign this policy to the web servers node group. For more information on adding a policy to a node group, please refer to our guide on Creating a Policy.

The next time any of the nodes in the web servers node group is scanned, the policy will be applied and the proper variable value and any overrides will be properly substituted in.