Building a cloud platform using Terraform Enterprise, Ansible Tower, and Service Now at FIS

Transcript

Hello, my name is James Bailey. I work for FIS. I’ve been working here for six years and just started a journey developing the cloud platform using ServiceNow, Ansible Tower, and Terraform back in November.

Architectural Principle

I started on this journey looking for an infrastructure as code solution that our development teams and our everyday project managers can use. We decided that we’d have to have two entry points. One is ServiceNow for our project managers. One is Terraform for our advanced users who want to use the everyday, up-and-coming features that get released for cloud platforms.

We also wanted to get rid of all the ITIL processes as manual actions: so change control requests, CI management, all of that we wanted to integrate. So when you speak to your colleague, you won’t have to turn around and say, “Do you remember how to raise a change control?”

Our Goals

Our goal is to use ServiceNow as our portal front-end, Terraform for all our Git Commit ingestions — ensuring that we do all of the ITIL processes, so we are in line with ServiceNow service management requests. And make sure that every VM or instance — whichever word you’re used to — complies with the FIS standard.

So, we make sure that we have IPAM integrated with it. Capacity management in our case is Densify — they’ve got big fix agents; Flexera — it carries on and on and on. But typically, this is done by hand, and things get missed — things aren’t verified.

We want to make sure that in every environment, whether it be our private cloud — which we’re working on, but in the future, our public cloud — you get the same treatment. So whenever you deploy a VM, you have to do it the FIS way. You don’t do it like the Wild West — which I’m sure many companies are used to.

Our Initial Functions

This year we’re releasing into FIS are how to create a new VM — a new instance. People can go to the portal and request a Windows or Linux virtual machine, specify the size, and since you click and get a VM in 15 minutes.

At the moment, within FIS, it takes 11 weeks on parts of the network — which obviously is a dramatic change. As well as that, we’re allowing people to be able to update via the ServiceNow portal as well. If you’ve already got an existing VM, you want to be able to update it to a larger size — you can do so using this same platform.

One thing which honestly — a couple of months ago was a pipe dream of mine — was the ability to import an instance. I did quite a bit of research and found that, yes, this is coming down the line. HashiCorp is working on it, but it wasn’t ready for us — so we’ve created it ourselves for VMware.

A user can now go to ServiceNow, click a button, and it will find that VM and turn it into Terraform code for us. We can allow users to manage their old VMs wherever they are, however old they are — Row 6, Windows 2003, 2008. It doesn’t matter. We can manage those using Terraform. We don’t care, it just gets ingested into the code, which already exists, and we’re there. That’s the detail of what we’re doing.

I’m going to show you some demos of the work and how we’ve been able to do that. How we’ve joined up ServiceNow, all the way through to Terraform — using the power of Ansible Tower to keep to the core beliefs of Terraform Enterprise and use it as infrastructure as code.

Import Function Demo

I’m going to show you the demo of our import function. This was recorded by a colleague called Gavin, who has been working on the coding part of this for me. You can see our portal that’s been created within ServiceNow. He’s going to click on import a legacy virtual machine, and then he’s going to fill in the relevant information.

Within ServiceNow, we’ve created an account system to allow cross charging. He’s going to pick out the support group within that budget that’s going to be allowed to manage that group — that object within ServiceNow — fill in the information, then send it to go to import it.

This request is now created in ServiceNow. Our proprietary function within Ansible Tower is now going to sit there and wait for that request to be raised — then start running through functions and job templates to make sure every field within the ITIL process is completed. Then import that instance into the Git Repo.

It is going to create that Git Repo for us because this budget doesn’t have anything. You see he’s going to refresh it. We’ll have a brand-new Git Repo with nothing in there. It works the same with an existing Git Repo. It’s going to pull down a state file and allow that to be checked and updated as well. You can see it’s currently going through all of the actions which are in the playbook to make sure everything is being imported correctly.

It’s now interrogated the VM on VMware using the Ansible modules. It’s converted that all into our module file, which we’ve created to be able to standardize the way we create VMs.

As you can see, this TF file has only variables in it. It uses a module that we’ve created within Terraform Enterprise to standardize that. That module includes IPAM, capacity management, creation of the VM. Then it will do the CMDB actions, and then — also after that — it will do the configuration of the agents.

At the moment, it’s gone through the policies to make sure we protect any VMs that already exist. We want to make sure that when you import a VM, we do not potentially break a VM that already exists out there.

This is a key thing for us, so we’ve got that action set in Sentinel. Then it will import it. In this case, it’s now done the import into Terraform Enterprise, and it’s actually importing it into the CMDB.

Now Gavin is going into the CMDB to look for that CI. As you can see, he’s successfully found it, and it has the relevant information that we are currently populating. It’s not very much, but this is still a development phase product. We’re working with our service management partners to make sure we have all the information — and all the links within all applications.

It’s now checking whether the process is finished inside the workspace. It continuously loops round to make sure that it’s ready. Once it’s finished, it will go back.

He did two VMs. This is now doing the second one. Within this feature, they allowed them to be able to loop around and do two VMs in one go. Once this VM has been imported, it will report back using IT Free, which is a function that we’ve built onto Ansible Tower to push it back into ServiceNow to confirm this request has been completed successfully.

As you can see, it’s doing the CI CMDB import. This also currently uses an Ansible Tower provider that we’ve created within Terraform, which allows us to use Ansible Tower as a forward and backward action — post-action task.

For example, when we would come to deploy a domain controller, we can build a domain controller and destroy the domain controller using terraform plan because we use Tower to do the post-action tasks without the risk of destroying our domain. As you can see, the request has been closed complete by IT Free as everything has been imported.

Upgrade Instance Demo

The upgrade is to allow us to be able to update one of those VMs that we’ve imported into Terraform to have extra disc or extra memory as well from what it currently already has. As you can see on the video, you’ve got one of the VMs we’ve already imported — showing it’s got two CPUs and 4GB of memory.

Gavin’s going back into the portal, and he’s going to go into servers. He’s going to select modify an existing virtual machine. Within here, he’s going to select the support group — because different support groups have different rights over what actions they can do against different budgets.

He will then select the budget and then select the virtual machine from out of the CMDB. At the moment, the record of where that TF file is not there in the CMDB, but that is due to be populated. At the moment, he’s entered it in manually. He’s updating the CPUs and memory. Again, since this recording has been done, we have got this to be dynamically populated so people can update it automatically from presented field values.

As you can see — as previously with the import video — you’ve got the request raised. Ansible Tower is there, sitting, watching for that request to be raised. It’s picked that up. Now it’s able to start running through the process to update the Terraform code — to be able to make sure that is then applied to the virtual machine in VMware. It’s going to pull the Git Repo, update the TF file. Once it’s done that, it is going to plan out and run all of our Sentinel checks — make sure it’s all happy and meets the policies which have been set out.

Policy check start. It’s applying those changes to that virtual machine — it’s now updating those virtual machines. This is because these are Hot Add enabled, and — as you can see — the CPUs are now four, and the memory is now eight. It’s got an extra disc as well.

Now it’s going back to the CMDB to make sure that the records are up to date with the correct information in real time. The change has been made and is updating it straight away. Doesn’t have to wait for a scan as you go along and detect that change has happened someday in the month. It’s automatically done so that the CMDB is updated in real time with the changes that are happening. As you can see, this one says 8GB of RAM, 4 CPUs as well. The combined disk space is 70 now rather than 50. The request again is closed complete.

Conclusion

That’s a quick tour through the work that we’ve been doing over the past ten months. A lot more is in the pipeline for us to get more out of Terraform — and Terraform Enterprise itself. We’re working very closely with our HashiCorp account team as well to be able to drive this on further.

I’d like to say a big thank you to the team I work with across the world, in India, in Denver and the rest of America, and within the UK — and especially the account team that I’ve been working with, with HashiCorp. Thank you very much.