Pseudo Code Infrastructure
In this second part we go somewhat deeper into the code, but this is in no way code. In the old days of IT development a step in the development of software was writing pseudo code. This was not executable code, but a text step inbetween to write what certain steps would have to do.
Ansible is in its descriptive nature a form of speudo code itself.
I use the term pseudo code here, to describe results that a block of tasks should accomplish, this creates a better overview on the play than a list of 100 tasks.
In this part, we will take each playbook and separate this into parts that we can relate to, but are still not ansible tasks, these are more like blocks of tasks. This way we can have a simple list of things to do creating a large play that will do many tasks.
Most of the time these blocks will translate to ansible roles.
Foundation (VM creation)
For the foundation, we can see these global tasks:
validate_variables:
test if all vars needed are defined
create_vars_for_VM_creation:
ensure all params are in place
to create the vm
if host_in_cloud:
create_network:
create network path for host(s)
register ip_address
register hostname
register_vm_in DNS:
ensure the hostname resolves
to the correct ip address
create_the_vm:
create the virtual machine using the vars
and the template image
wait for the VM to boot
You see that is part is a rather limited set of blocks and easy to follow. But creating the variable for vm creation can be an enormous structure spanning multiple pages in your playbook. This way you know what tasks are ahead of you.
Describes here is only the deployment flow, this becomes more complex, if you add host deletion and/or redeployment strategies into the same play.
An example:
validate_variables:
test if all vars needed are defined
If strategy is 'create or redeploy':
create_vars_for_VM_creation:
ensure all params are in place
to create the vm
If strategy is 'remove':
unregister_vm_in DNS:
ensure the hostname no longer resolves
cleanup DNS
IF strategy is 'redeploy or remove':
delete the VM from virtual platform
If strategy is 'create':
register_vm_in DNS:
ensure the hostname resolves
to the correct ip address
If strategy is 'create or redeploy':
create_the_vm:
create the virtual machine using the vars
and the template image
wait for the VM to boot
This is where you can validate the sequence of events and if thing stay valid in the process.
An error in this execution order could leave you with a lengthy install process, with no result if you throw away the system after installation.
I aways work with the latter version of the above flow, so I can cleanup systems I created, or even recover non-funtioning servers, by creating them from scratch.
First floor (system adoption)
As the system is created, we need to make the system valid for the organization it will run in (adopt it in the IT landscape). This means configure the storage, adding security, LDAP, monitoring and much more.
In this part the sequence is, as in any other step, of the essence. So here we can add some clarity.
Again, these are just examples, you must fill in the list for your organization:
validate_variables:
are all variables needed present and valid?
if lvm is defined:
create partitions:
on additional disks
create volume groups:
on partitioned disks
create logical volumes:
in correct volume groups
with configured size
format volume
mount:
create the mountpoints
mount the volumes
configure resolving:
configure resolv.conf
configure firewall:
install firewall packages
ensure only port 22 is opened
enable and start firewall service
configure time:
install packages
configure timezone
configure timesync
enable time service
configure monitoring:
install packages
open firewall port (if needed)
configure/register monitoring
enable monitoring service
configure logrotation:
install packages
configure logrotation
enforce selinux policies:
install packages
configure policies
ensure selinux is enforcing
configure logon services:
install packages
configure pam
enable logon service
create local users:
create local accounts
create homes directories
set access rights
configure sudoers:
configure sudoers as needed
These are the most common steps in any organization, there can be meny more, but you can already see that each section has a list of basic tasks. translate this to roles and you know what to add into a role and this list gives you the order in which to execute the tasks/roles.
After use don't throw this away, but add it to your documentation, this way you have the overview over the roles and steps that are executed during deployment.
second floor (Middleware or layered product)
This is called second floor, but this can be used multiple times to install a number of middleware packages.
As already stated in the previous section there can be multiple dependencies for an application to run, these middleware dependencies are not always installaed on the same system as the application, but in testing environments this could well be used as such to save on system costs.
The purpose of this step is to install a middleware service, each separate, to enable multi-server setups.
For a database:
if database is defined:
install database:
install packages
configure database
configure database authentication
configure firewall port
enable and start database service
ensure database backup schedule
You see that no data is imported into the database, this is not the responsibility of the database installation. This must be done by the application that will use the database, this way the playbook/role is generic.
For an application server platform:
if jboss is defined:
install jboss packages
configure defaults
configure firewall ports (for jboss only)
enable and start service
Again, no application specific configuration, the application has to create its own configuration, so this can stay generic.
The roof (Application)
The last part of this host installation is the installation and configuration of the application.
As aal the previous parts were of a generic nature, we must now add configurations for all the parts that are used in this application. So the installation of an application can be very simple, like install package and run the app.
Or it can be very complex.
In the simplest configuration you won't need a overview like we made for the previous steps, but I advise you to still create it and add it to the docunetation. It is part of the documentation standards and future changes will have its place.
if database is defined:
add connection
if database is local:
if data not present:
restore or create data
install_application:
prepare applicationserver:
create directories
create application profile
add datasource
add message queus
install dependencies
install application:
install packages
open firewall application ports
start application