Using Terraform to Up Your Automation Game - Building the Fleet

Populating our Virtual Private Cloud

In the previous post we successfully created our Virtual Private Cloud (VPC) in AWS via infrastructure as code utilizing Terraform, which provided us the ability to stand up and tear down our infrastructure landing pad on demand.  Now that our landing pad is complete and can be deployed at any time, let's build our fleet of load balanced web servers.

Building the Fleet Using Terraform Modules

Taking a similar approach to our VPC build out we will once again utilize Terraform modules, this time to create and build out our web server fleet.  In addition to the Terraform Module Registry there are a number of different sources from which to select ready built modules - including GitHub.  For our web server cluster we will utilize a short and simple webserver_cluster module that I have made available in my GitHub terraform repository.

This module creates a basic web server cluster which leverages an AWS launch configuration and auto scaling group to spin up the EC2 instances that will be perfuming as web servers.  It also places a load balancer in front of these servers which balances traffic amongst them and performs health checks to be sure the fleet is bullet proof.  The module also configures the necessary security groups to allow http traffic inbound.  All we need to do is to specify the size and number of the web servers and where to land them.

To call this module we simply need to append to the file to call the webserver_cluster module and specify how our web server fleet should be built.

module "webserver_cluster" {
    source = ""
    cluster_name        = "webserver-dev"
    ami                 = "ami-a9d09ed1"
    key_name            = "MyOregonSSH"
    instance_type       = "t2.micro"
    min_size            = 2
    max_size            = 2

    vpc_id     = "${module.vpc.vpc_id}"
    subnet_ids = ["${module.vpc.public_subnets}"]

In the code statement above we simply call out the source of our webserver_cluster module which resides in GitHub, specify a name for our cluster, the image and size server to use, a key name should we need to connect to an instance, the minimum and maximum number of servers to deploy, along with the VPC and subnets to place them in (referenced from our VPC build out).

In this case we are going to deploy two web servers to the public subnets we built in our VPC.

Deploying the Fleet

After updating our file with the code segment above, let's now initialize and test the deployment of our web servers.  Since we are adding a new module plan we must rerun our terraform init command to load the module.  We can then execute a terraform plan for validation and finally terraform apply to deploy our fleet of web servers to the public subnets of or VPC residing in AWS us-west-2.


Validate the Plan and Deploy using terraform plan and terraform apply.


Accessing the Fleet

So our deployment is complete, but how can we access it?  When building infrastructure, Terraform stores hundreds of attribute values for all of our resources.  We are often only interested in just a few of these resource, like the DNS name of our load balancer to access the website.  Outputs are used to identify and tell Terraform what data is important to show back to the user.

Outputs are stored as variables and it is considered best practice to organize them in a separate file within our repository.  We will create a new file called in the  same directory as our file and specify the key pieces of information about our fleet, including:  DNS name of the load balancer, private subnets, public subnets, NAT IPs, etc.

output "vpc_id" {
  description = "The ID of the VPC"
  value       = "${module.vpc.vpc_id}"

# Subnets
output "private_subnets" {
  description = "List of IDs of private subnets"
  value       = ["${module.vpc.private_subnets}"]

output "public_subnets" {
  description = "List of IDs of public subnets"
  value       = ["${module.vpc.public_subnets}"]

# NAT gateways
output "nat_public_ips" {
  description = "List of public Elastic IPs created for AWS NAT Gateway"
  value       = ["${module.vpc.nat_public_ips}"]

output "elb_dns_name" {
  value = "${module.webserver_cluster.elb_dns_name}"

output "asg_name" {
  value = "${module.webserver_cluster.asg_name}"

output "elb_security_group_id" {
  value = "${module.webserver_cluster.elb_security_group_id}"

After creating and saving the file, we can issue a terraform refresh against our deployed environment to refresh its state and see the outputs.  We could have also issued a terraform output to see these values, and they will be displayed the next time terraform apply is executed.


Browsing to the value contained in our elb_dns_name output, we see our website.  Success.


Scaling the Fleet

So now that our fleet is deployed, let's scale it.  This is a very simple operation requiring just a small adjustment to the min and max size setting within the webserver_cluster module.  We will adjust two lines in and rerun our plan/deployment.


min_size            = 8
max_size            = 10


Viola.  Our web server fleet now has been scaled up with an in place update that has no service disruption.  This showcases the power of infrastructure as code and AWS auto-scaling groups.


Scaling back our fleet, as well as clean up is equally as easy.  Simply issue a terraform destroy to minimize AWS spend and wipe our slate clean.

Multi-Region/Multi-Enviornment Deployment

Now that we have an easy way to deploy and scale our fleet, the next step is to put our re-usable code to work to build out our development, staging and production environments across AWS regions.

Using Terraform to Up Your Automation Game

As a proponent of automation I am a big fan of using Terraform to deploy infrastructure across my environments.  Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently.  With an ever-growing list of supported providers it is clear that it belongs in our automation toolbox and can be leveraged across local datacenter, IaaS, PaaS and SaaS deployments.  If you come from a VMware background and work with AWS or Azure, like me, I would recommend checking out Nick Colyer's PluralSight course and Yevgeniy Brikman's "Terraform: Up & Running" book / blog posts.  Hopefully this post will entice you to learn more.


Our mission is to create and deploy a set of auto-scaling web servers, front ended by a load balancer for our development, staging and production environments across 3 different AWS regions.  We will utilize a modular approach to create and build our infrastructure, and reuse our code when possible to keep things simple.

Building A Virtual Private Cloud

Before deploying any instances, we need to create our landing pad which will consist of a dedicated VPC (Virtual Private Cloud) and the necessary subnets, gateways, route tables and other AWS goodies.  The diagram below depicts the development environment to be deployed in the AWS us-west-2 region, including private, public and database subnets across 3 availability zones.


Terraform allows us to take a modular approach for our deployment by offering self-contained/packaged configurations called modules.  Modules allow us to piece together our infrastructure, and enable the use of reusable components.  Terraform provides a Module Registery of community and verified modules for some of the most common infrastructure configurations.  For our purposes we will leverage the VPC module for AWS.

To begin creating our development VPC, we can create a file called  Inside this Terraform file we will add a few lines of declarative code and the AWS provider to attach to the us-west-2 region.  I am hiding my AWS credentials, but you can include them under the AWS provider.

provider "aws" {
  region = "us-west-2"
  access_key = "AWSAccessKeyHere"
  secret_key = "AWSSecretKeyHere"

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "1.37.0"

  name = "dev"

  cidr = ""

  azs             = ["us-west-2a", "us-west-2b", "us-west-2c"]
  private_subnets = ["", "", ""]
  public_subnets  = ["", "", ""]
  database_subnets = ["", ""]

  enable_nat_gateway = true
  single_nat_gateway = true

  tags = {
    Owner       = "user"
    Environment = "dev"

  vpc_tags = {
    Name = "dev-environment"

We add a few additional lines of code to our file inserting the VPC module for AWS to define the availability zones, subnets, IP addresses and tags.  You can carve out your subnets as you see fit.  Less then 30 lines of code and we are now ready to initialize and deploy a working VPC for our development envioronment.  You can see why I like Terraform.

Deploying our VPC

To deploy our newly created VPC, we simple need to install Terraform on our computer, initialize and plan the deployment and then apply it.  The download and install of Terraform is very straight forward as it deploys as a single binary.  From the command line browse to the directory that holds your file, and execute the initialize, plan and apply commands.

terraform init

The first command that should be run after setting up a new Terraform configuration is terraform init.  This command is used to initialize a working directory containing Terraform configuration files, and needs to be run from the same directory that our file is located.

terraform plan

Before deploying our development environment, Terraform provides the ability to run a check to see whether the execution plan matches our expectations for what is to be deployed.  By running the terraform plan command, no changes will be made to the resources or state of our environment.  In our case, there will be 25 additions to our development environment and these created items are detailed in the output of the terraform plan command.

terraform apply

Now that everything is initialized and the plan meets our expectation, it is time to deploy.  The terraform apply command is used to apply the changes specified in the execution plan.  You will be prompted to enter 'yes' in order to deploy.  The summary of this command shows that all 25 additions completed.  We now have a working VPC for our development environment.


We can confirm that is the case by logging into AWS and viewing our VPC in the us-west-2 region.

terraform destroy

One of my favorite uses of Terraform is to quickly turn up an infrastructure environment with only a few lines of code, and conversely tear it down when it is no longer needed.  This is extremely practical when working with cloud providers to keep costs low and maintain a clean environment which is ready for future deployments.  The terraform destroy command does exactly what you would expect - it is used to destroy the managed infrastructure deployed.  In our case we will utilize terraform destroy to tear down our development VPC.  When we are ready to use it again, we simply issue a plan and apply - which is the power of Infrastructure as Code.


Deploying our Web Servers, Load Balancers and Auto-Scaling Groups

Now that we have a place to put our web servers, it is time to create and deploy them.  We will complete this process in the next post.

Managing Servers in a Serverless World

Serverless computing is the new craze, but let's agree that the naming is confusing and I would argue misleading. Serverless computing is the idea that you can build, deploy, and run applications and/or services without the need to think about servers.  But not thinking about servers and being "serverless" are two very different things.  Applications and services need to run and execute somewhere, whether in your datacenter, a co-location facility, the public cloud or your basement.  Servers haven't disappeared and are not going to anytime soon.


I am sure most of us can agree that while servers are not going way, managing them is not a key business differentiator and therefore the "serverless" concept certainly resonates despite being inaccurate. Customers expect server management to be simple and to just work without spending absorbent amounts of time dealing with the minutia involved.  Wouldn't it be nice to simply hit an "update" button that remediates vulnerabilities at the firmware level for things like Spectre and Meltdown across your entire server farm?  Recognizing this, server manufacturers are working to continuously improve their lifecycle management functions for a market who wants to think less about provisioning, maintaining, securing and operating servers.

As one of the largest global server manufacturers, Dell/EMC appears to recognize this growing mindset and is aiming to simplify, automate and unify their server life cycle management functions.  A core component of their approach is the recently announced OpenManage Enterprise product.

OpenManage Enterprise is a systems management console currently in Tech Release, which serves as the evolution of the OpenManage Essentials product that most Dell server customers and administrators are familiar with.  OpenManage Enterprise adds some really nice capabilities that make it easier to deploy and immediately use.  Some of these capabilities that I am most excited about are:

  • It deploys entirely as a virtual appliance which includes everything you need to get up and running.  No more separate servers and databases to manage.  
  • The UI is web based and therefore consumable across platforms (including a mobile app) as it has been built with HTML5.  The performance improvements are immediately recognizable.  Yeah!!! - no more java plugins.
  • You can manage up to 5500 devices (soon to be 8,000) within a single interface, and separate out management through the use of role based and device level access.  
  • It integrates directly with iDRAC for remote management and configuration, as well as SupportAssist for proactive and automated support.
  • The enhanced discovery feature allow you to quickly sweep the datacenter to pull devices into management, as well as determining the warranty levels on those devices.  This includes servers, storage, networking and third-party devices.
  • A deliberate focus on automation for both Dell and third-party servers/devices using a RESTful API and integration with Redfish
  • Free software download

Real World Examples

Impressed by the list of features and capabilities that OpenManage Enterprise is offering, I downloaded the free software and took it for a spin.  The speed of deployment and access was as advertised....extremely easy and fast.  The discovery recognized servers, hyper-converged appliances, and storage devices.  It is apparent that while a core focus of OpenManage Enterprise is to reduce the headache of server management, it was designed to work across multiple systems.  This makes sense as we see servers now operating in different capacities - storage controllers, hyper-converged platforms, stand-alone and third party offerings.


One of my new favorite views is the ability to see warranty information for all devices under management.  This information is literally 1-click from the home screen and shows all warranty information including: status, expiration, ship date, order number, and service level.  Extremely useful.


For more granular level detail you can utilize device categories, custom groupings or the 'search everything' field to find a system and drill in on specifics.  Of course hardware, firmware, O/S and system health information is available but so is compliance detail to an established baseline, so that you can easily identify and remediate those systems in which firmware updates need to be performed.  Remote console access to the server with iDRAC and Virtual Console is conveniently located on the device home screen.


There is AN APP For That

Yes, OpenManage Enterprise also has a mobile app, which is also free to download.  While mobile access might not be for everyone, I find the ability to reboot a server or look at diagnostics without having to connect my laptop and log into VPN in to be very convenient.  Just be sure to lock your phone, because you do have a significant amount of power available to you through the app.


I would have to say I am very impressed by OpenManage Enterprise.  Not only is the the list of features and capabilities impressive, but they are practical and easy to use.  For system administrators who live in a "serverless" world and are asked to think and focus less on server management, OpenManage Enterprise certainly delivers.

Security has Failed, Analytics to the Rescue

Security has Failed.  A refreshing, and I believe honest, statement presented by Dr. Richard Ford, Chief Scientist of Forcepoint when talking about the current state of traditional Computer Security.  Computers are complicated and by their very nature are a difficult landscape in which to separate the good from the bad - the core function of security.  Using traditional computer security means (anti-virus, firewalls, secure web gateways) is no longer an adequate way in which to draw these lines.  In the words of Dr. Ford, when it comes to the computer security playing field, "it is much easier to play offense then defense."


Can Analytics Help?

Realizing that traditional means are not adequate, Forcepoint is taking what they call a "human-centric approach" to security.  This approach seeks to understand normal human behavior as it relates to the flow of data in and out of an organization.  The goal is to become better at drawing the lines between the good and bad, allowing their customers to identify and respond to risks in real-time.  Rather than static definitions (firewall rules allowing system A and system B to communicate on a specified port), it is far more valuable to provide dynamic intelligence which incorporates both system context and user behavior into computer security decision making.  Forcepoint is working to provide this value through User and Entity Behavior Analytics (UEBA).

UEBA is what is referred to as the "Brains" of the Forcepoint suite of products.  UEBA allows a dynamic risk score to be calculated and assigned to users and computers through the use of data modeling.  Much like data modeling helps financial institutions determine if an applicant is at risk of default before approving or denying a loan, UEBA utilizes data modeling to determine the security risk of a given person and/or system.  The risk score calculated through these models is then utilized by the Forcepoint security products to make a more informed decision.

Of course, no two customer environments and policies are indentical so identifying system context and user behavior goes through a learning and training process.  Forcepoint states that the training of their data models to detect what is normal in a customer environment can be accomplished in days.  The UEBA models are purposely generic at their start and updated over time.  This flexibility allows for refinement of the models as new threats are presented within an environment.  Once in place, the models assist in distinguishing and alerting anomolies from normal activity.


Having worked a number of years now in the data analytics space helping customers reduce the noise-to-signal ratio within their data environments, it seems obvious to me that analytics can provide immediate value to a 'failed' traditional computer security industry.

At What Expense

So if behavior based analytics seems intriguing and scary to you all within the same breath, you are not alone. Forcepoint is in the business of intersecting people and data, therefore they are very conscience in designing and creating solutions in which privacy and personal protection are a core focus.  Anytime you record, model, analyze and act on human behaviors the topic of privacy must be understood.  The tradeoff between minimizing insider threats while protecting personal information is non-trivial.  While time did not allow us to drive into how privacy in implemented within the UEBA product, perhaps we can learn more in a future session.

Learn More

If you are interested in learning more about Forcepoint's computer security offerings or wish to view the entire UEBA Tech Field Day presentation, I have embedded the recording below.  This and other presentations can be found on the Tech Field Day website.

Disclaimer:  I was personally invited to attend Tech Field Day 16, with the event team covering my travel and accommodation costs.  However I was not compensated for my time.  I am not required to blog on any content; blog posts are not edited or reviewed by the presenters or Tech Field Day team before publication.