Reduce Cognos Install Times with AWS EC2 User Data and AMIs

Installing Cognos again, and again, and again…

Installing Cognos takes time. The more complex the environment, the more time it takes. The time spent running the Cognos installer is compounded by the number of environments that need to be created. Fortunately, there are options on AWS to help Cognos administrators get out of the business of waiting for the install to complete. The two options we will be exploring here are EC2 user data and custom AMIs.

EC2 user data

Silent installs of Cognos are nothing new and have been around for years. If you haven’t used them before, you can read up on the detailed documentation from IBM here. Silent installs are great on their own. If you are always installing the same Cognos components on a certain server profile, time can be saved by setting up the silent installer to install those specific components. Where this ties into running Cognos on AWS is integrating it with EC2 user data.

For those unfamiliar, EC2 user data is a set of commands that can be passed to an EC2 instance during when it launches. These commands are used to configure the instance or download and install software. For example, if the Cognos installer, server zip file, and response file are hosted on S3, user data can be used to download these dependencies and then perform the Cognos installation using the silent install command. An example user data script written in PowerShell is below.

 
Silent Cognos Install in Powershell
 

For a Cognos administrator, this is fantastic! This means the software can be installed as the instances are being provisioned which reduces setup time and improves efficiency.

AMIs

If silent installs aren’t an option, there are still avenues for limiting the time spent running the Cognos installer. The next tool that would be recommended is AMIs (Amazon Machine Image). AMIs are templates that contain pre-installed software and configurations. How does this fit within a Cognos environment? Let’s say in a typical deployment (DEV, QA, PROD) there is at least one dedicated dispatcher, content manager, and gateway per environment. Historically, this would mean an administrator would need to run the Cognos installer nine times between all the environments. Phew! That’s a lot of tedious, redundant steps just to get Cognos installed. This is where AMIs can be useful. Leveraging AMIs allows an administrator to install each Cognos tier once and use those templates across all environments. Using the above scenario as an example, let’s see how we can use AMIs to reduce the overall install time.

To start, we would provision three EC2 instances. We would then install the necessary software. On instance 1, we would install the content manager components. On instance 2, we would install the dispatcher components. Finally, on instance 3, we would install the gateway components, IIS, and IIS Application Request Routing. The instances would then be shut down.

It’s important to note that while you can shut down the instances normally before making the AMI, we recommend shutting down with Sysprep to improve the usability of the AMI when provisioning new instances. If you’re unfamiliar with Sysprep and EC2, more details on that option can be found here.

Once Sysprep has completed and the instance is shut down, it’s time to create the AMIs. Select an instance in the EC2 console and navigate to Actions > Image > Create Image. Give the image a name and description and select Create Image. It will take a few minutes for the AMI to be created. This process will need to be completed for the remaining instances.

Creating an AMI in Amazon EC2

Once the AMI builds are finished, you will now have a repository of custom AMIs with Cognos preinstalled.

Custom AMIs with Cognos preinstalled

These AMIs can now be used as templates to provision the three Cognos environments. For example, we can launch three EC2 instances using the content manager AMI to create the three content managers needed for all our environments. All we need to do then is run Cognos Configuration because the software is already installed. Using AMIs this way allows us to reduce our installation time by a third.

Which to use?

We’ve looked at using EC2 user data and custom AMIs to speed up the install time for Cognos environments. But which should you use? Each method has its own advantages and disadvantages.

Creating AMIs takes more initial set up time compared to executing EC2 user data at launch. However, this means the initial launch of a custom AMI will be much faster than launching with user data. This is because we will have to wait for the user data script to complete executing and for Cognos to be installed before that instance would be ready for use. AMIs would help reduce start up time over the long run if new environments need to be spun up regularly. However, this means the AMIs will need to be maintained and updated with the latest OS updates and patches.

User data has no set up time beyond the development of the script itself. This means an AWS managed AMI can be used whenever a new environment is needed. This eliminates the need to manually manage AMIs yourself. It would also allow for a more seamless transition to new versions of Cognos. Simply replace the old installer and server zip files with new ones and the script can pick up those new files the next time it runs.

In the end, use what works for you. For those comfortable scripting in PowerShell or bash, user data provides for a simple and streamlined process for installing Cognos. For those less comfortable with scripting, AMIs will still reduce time spent installing Cognos across your multiple environments.

Conclusion

EC2 user data and AMIs are fantastic tools to reduce installation and configuration time of new Cognos deployments. For those new to AWS, explore both these options for deploying new Cognos resources to see how they can fit into your specific workflow.

Join us here for more updates to this series to address questions and discuss patterns to consider when migrating Cognos to AWS. If you need help sooner, reach out to us now! We’d love to have a conversation with you about your AWS migration journey.