It’s quite common, in the life of an integration consultant, to spin up a couple VM’s and/or containers to prototype a solution. In most cases it suffices to provision a virtual box or docker container on your local workstation. But when architectures get bigger, you’ll also want to prove the complete solution in a fully managed environment.
For instance, I’m working on a side project showcasing the webMethods Integration suite in a complete DevsOps environment. When taking into account a dev and a clustered test environment, this will already need 14 servers. Some integration servers, messaging servers, a management server, a Jenkins, a Sonarqube, webMethods build server, etc. You get the point; way to many servers to manually install and configure …
With the infrastructure as code (IaC) methodology in mind, I’m automating the provisioning of this infrastructure. Beside the classic tools like Chef, Puppet or Ansible there’s also the AWS service called Cloudformation. I was lured into using it via the handy architecture designing tool. So I decided to give it a try!
Let’s get technical
With Cloudformation (as with almost all IaC technologies), the infrastructure is described in a json or yaml file. In that ‘template’ file you’ll describe all the components in your architecture. Think about EC2 instances, VPC, Subnetworks, Security groups, Internet gateway etc… When the template is ready, all components are provisioned using one aws cli command.
|
1 2 3 4 |
aws cloudformation create-stack --stack-name webmethods-infrastructure-demo --template-body file://$PWD/template.json --parameters file://$PWD/parameters.json |
You can follow the creation process in the Cloudformation web console. Below you’ll see an example of the creation events for a ‘simple’ template.
The template
This looks quite straightforward. The difficulty is of course in creating the template itself. When you’re new to Cloudformation, a very nice starting point to get acquainted is the architecture designing tool. This allows to drag and drop the required AWS components. As additional benefit, you’ll get a nice piece of documentation. The diagram below shows a basic example.
Dependencies and specific parameters will still need be researched via the comprehensive documentation. A simple search in the docs also offers a lot of sample templates for common setups.
The code snippet below shows a piece of the json behind the diagram. It’s the definition of the Lab1 server in the upper right corner of the diagram. Some OS configuration is defined in the “UserData” field. This part can be further extended to install custom software components.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
"Lab1": { "Type": "AWS::EC2::Instance", "Properties": { "KeyName": { "Ref": "KeyName" }, "ImageId": "ami-337be65c", "InstanceType": "t2.small", "NetworkInterfaces": [{ "DeviceIndex": "0", "AssociatePublicIpAddress": "true", "DeleteOnTermination": "true", "SubnetId": { "Ref": "WmUspSubnet" }, "GroupSet": [{ "Ref": "MySecurityGroup" }] }], "UserData": { "Fn::Base64": { "Fn::Join": ["", [ "#!/bin/bash -v\n", "sudo adduser sag\n", "sudo mkdir -p /opt/softwareag\n", "sudo chown -R sag:sag /opt/softwareag\n", "sudo yum install wget -y\n" ]] } } } } |
So far I’ve found that Cloudformation is an ideal technology for this particular use case. As all needed components are within the boundaries of AWS anyway. And when you’re already familiar with AWS, learning Cloudformation is not more then a bicycle ride over small charming hill.
I’ll still need to drag & drop a couple of ec2 instances to the diagram and I’ll have an optimal starting point for my webMethods DevOps demo environment! Author: Samuel Vandecasteele
Don’t hesitate to reach out on LinkedIn or Twitter!
Featured photo (top) by Thomas Kvistholt on Unsplash
