BACKGROUND IMAGE: sinemaslow/iStock

E-Handbook:

Configuration as code specifies and simplifies IT deployment

Get started Bring yourself up to speed with our introductory content.

How infrastructure as code benefits and eases provisioning

Being able to provision services with code means a simplification to sometimes complicated processes. Plus, you won't need to worry about the platform that service will run on.

It's a heterogeneous infrastructure environment out there in IT. Whether you choose on-premises infrastructure or the cloud, every vendor has its own designs and configuration preferences. Since each service has a unique approach to solving the very same problems, it might be time to consider how infrastructure as code benefits your IT operations.

Ultimately, it doesn't matter whether you choose Apache, Microsoft Internet Information Services (IIS) or Nginx for your web servers or do away with all of that instead and use a cloud provider. Every option opens up an HTTP listener and serves up a webpage.

Organizations have their preferred platform and tooling and tend to stick with that. But at what cost? If one company considers itself a Microsoft shop that scripts all automation in PowerShell while using Azure for all its cloud projects, and another considers itself a Linux shop choosing Python and AWS, what are they giving up? Probably quite a bit. They're participating in the feared vendor lock-in scenario -- but they don't have to.

There's a better way through a more generic infrastructure as code approach.

Via its more generic approach, infrastructure as code benefits your efficiency goals.

Following the script

Treating infrastructure configurations as code is a major benefit of the approach. It means that you're writing the code to provision infrastructure on demand, which then allows an organization to merely execute code and automation to build infrastructure from scratch. This approach, which is sometimes described as configuration as code, delivers an important advantage: flexibility. An administrator can run a script instead of racking a physical server. Since this script is code, it's simple text -- and easily modified.

One way engineers can take advantage of infrastructure as code benefits is to provision services without worrying about the platform on which those services will run. Similar to the cloud model, it allows organizations to define services via a declarative nature rather than an iterative one.

Engineers can use infrastructure as code to provision services without worrying about the platform on which those services will run.

An engineer who needs a new web service, for example, no longer needs to spend countless hours on Google to learn how to install each kind of web server. Instead, the engineer can declare that a web service is needed, provide some parameters, and the code will decide where to place the service and how to configure it.

You could build your own infrastructure as code solution, but most use tools such as Puppet, Chef, Ansible or SaltStack. Each of these tools has its own way of defining infrastructure, and each allows an administrator to define a service without worrying about all of the if-then logic necessary when deploying to heterogeneous environments.

For example, the creation of an Apache web service in Puppet might look something like this:

class apache2 {
    package {'apache2':
            ensure => present,
    }

    service {'apache2':
            ensure => "running",
            enable => "true",
            require => Package["apache2"],
    }
}

In Chef, it would look something like this:

name "webserver"
run_list(
    "recipe[apache2]",
)
default_attributes(
    "apache" => {
    "listen" => ["*:80", "*:443"]
    }
)

You can see there's no code checking whether a service already exists (if statement), nor are there Apache-specific configuration values. All of that logic has been abstracted away in the tooling. Using configuration management tools allows administrators to define declaratively what they want the infrastructure to look like. The tooling makes it happen.

Say, for example, an administrator doesn't want to limit herself to deploying Apache and needs to build some kind of dynamic script. She can use configuration management tools or a script of her choosing. The concept of infrastructure as code is generic and isn't tied to a particular tool. She could write a simple script, such as the one below. Once the workflow is defined, she's then free to incorporate this logic into a configuration management tool or a script of her choosing. This is an example script in PowerShell, but the same logic could be applied to any language or tool:

## Parameters to pass to the script at run-time
param($EnvironmentName)

## Source of server names mapped to environments
$environmentServers = @{
    Production = 'SRV1','SRV2'
    Test = 'SRV3','SRV4'
}

## Discover the servers available
$targetedServers = $environmentServers[$EnvironmentName]

## Small function to determine operating system
function Get-OperatingSystem {
    param($ServerName)

    ## Code to determine operating system here and to output either Windows or Linux
}

foreach ($server in $targetedServers) {
    if ((Get-OperatingSystem -ServerName $server) -eq 'Linux') {
        ## Deploy Apache
    } elseif ((Get-OperatingSystem -ServerName $server) -eq 'Windows') {
        ## Deploy IIS
    }
}

Infrastructure as code benefits from logic

By using code, you can define all of the logic and rules ahead of time to determine what kind of web server to deploy to various servers. By just calling this script using a single line of code, (see example below) you can intelligently and automatically deploy any kind of web server to any environment:

.\Deploy-WebServer.ps1 -EnvironmentName Production

By designing our configuration in such a way to be idempotent, you also don't need to worry about the state of environments (such as production or test.) Simply run the script, and it follows the logic you've built.

In this example, we essentially built the infrastructure as code ourselves. But this kind of task comes pre-built with configuration management tooling, making this process even easier.

Developers aren't limited just to software anymore. Infrastructure developers are on the rise, and the demand will be high for anyone who can understand how to develop the logic and rules associated with infrastructure deployment and management. By understanding the concept, talented engineers will see that infrastructure as code benefits an organization and that they can adapt it in many useful ways.

This was last published in July 2018

Dig Deeper on Configuration Management and DevOps

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

How would infrastructure as code benefit your provisioning practices?
Cancel

-ADS BY GOOGLE

SearchDataCenter

SearchAWS

SearchServerVirtualization

SearchCloudApplications

TheServerSide.com

SearchCloudComputing

DevOpsAgenda

Close