Infrastructure As Code

In these pages I will try to explain what infrastructure as code is and how I created this.
It is the most widely used way to configure systems, because it gives a layered installation, in which each layer can be tested separately before deployment in production.
In these pages we will go through the theory of the buildingblock strategy and we will first explain what it is and then try to a possible implementation of this.
The first part is non technical and helps with a general understanding of this way of building.
The second part will handle steps to do in a sort of text flow chart.
The last part wil describe actual code from an implementation.

Building a house

Think of building your infrastructure in your virtual system as if it was a house:
- first: thing you do is lay the foundation - second: is the first floor - third: a second story (if you need it) - last: add the roof

This procedure can be repeated for almost any house ( with some differences for each house), this is where the variables come in to modify the behaviour of the buildingblocks used to build the house. Later more on this.

Each of these steps is a separate playbook and therefore a possible step in a workflow

The foundation

This will be base of your house, it must be strong enough to support your whole house.
The components of a standard foundation:
- start with a standard image from your supplier (like redhat UBI)
- enable your ansible account in the image
- configure network
- create additional disks

Variables for this step:

ip_address: <ip-address>
hostname: <hostname>
disk:
  - name: </dev/name1>
    size: <size>
    lvm_vg: database
  - name: </dev/name2>
    size: <size>
    lvm_vg: application

I don't specify any technical details for these variables, this varies with each implementation, but it should be somewhat obvious we need them. I also don't descibe where these come from, this is also installation dependent, we will address this later.

Ground floor (or first floor)

Here you wil find the rooms (storage volumes) for the OS and the later layers, these are created from the vars added to the machine.
Additional tasks:
- configure network services - start the firewall, open only port 22
- apply hardening
- time sync
- apply selinux policies
- register system to monitoring

And whatever your company requires, as long as it fits the foundation and has nothing to do with applications.
In the foundation (as this is where the machine is created) the number of cpu's and memory is usually implemented, through the creation of the VM.
In this step you might also register your new system to software management systems, like RedHat satellite or online repositories to be able to apply security updates.
This is the moment to apply the latest security updates for the system you created, if the base image is not too old, this should not take much time.

The additional variables for this part of the installation (if any):

resolving:
  dns: <dns_ipaddress>
  domain: <search_domain>
  options: <dns_options>
time:
  servers: <time_servers>
  zone: <timezone>
lvm:
  - lv_name: data
    mountpoint: /data/db
    size: <size>
    vg_name: database
  - lv_name: application
    mountpoint: /data/application
    size: <size>
    vg_name: application

These variables are an extension to the variables for the foundation and tell the code what disk to use and what size the filesystem to create has to be. Once the filesystem is created, it will be mounted on the given mountpoint. This way the storage will be availlable to the next step.

Optional second story

The second story of our Virtual Machine building is a middleware layer (if we need one for our application).
First we need to define what middleware is:

Middleware

Is software that is needed for an application to run- or store/get data that is not part of the application itself.
So what qualifies as middleware? - databases
- runtimes (jboss, java and others) - messaging queing apps - many others..

Not all of these will be installed on the same host as the application, but sometimes we need client packages installed and configured. As these can be used for multiple applications, we create a separate playbook for this, so it can be reused.

The roof

The last step of building a house is the installation of the roof (application).
This completes the installation of the host and leaves the application in a running state.
Form this moment, clients, end users can use the application.

This concludes part one, the overview.

Next step

Back