This tutorial is outdated. This was originally written is for Otter v2, which is not the current version of Otter. Stay tuned, an updated tutorial will be coming soon!
Managing and monitoring organizational infrastructure is an important part of the software development lifecycle, however it’s commonly done in a less than ideal manner. Often changes and patches to production servers are carried out in an unorganized, manual way. Not only does this introduce the very real possibility of human error, it also can lead to wide outages if changes made to infrastructure aren’t communicated to the team deploying applications to that infrastructure.
BuildMaster already helps teams maintain infrastructure, by allowing server configurations to be included in a deployment plan. However, even this is suboptimal. While it allows for changes to be deployed, it doesn’t monitor the infrastructure for drift, and because the infrastructure is tied to the application, in order to change settings the entire application would need to be redeployed.
The ideal solution is to use BuildMaster in conjunction with Otter and utilize Infrastructure Sync.
For the following example we’ll start with a simple web application with an Integration -> Testing ->Production pipeline. The application has a series of servers, some configured for the web and other configured for the API. Keep in mind this is a simple, trivial example. In most real world scenarios an application will have a more robust release pipeline and more in-depth infrastructure configuration. This example is designed to show how BuildMaster and Otter can be used in tandem for better infrastructure management.
As noted, this application has servers in each of its three environments, and there are both Web severs and API severs. Last, this application is being deployed with a simple Plan. The screenshots below show the server set up as well as the plan.
The first thing to do is to import the infrastructure into Otter. This can be easily done because BuildMaster configurations translate to a script that can be copied. In the administration section of BuildMaster under infrastructure, there is an Export Configuration option clicking this will pull up the infrastructure script.
To import this to Otter simply go to the administration section of Otter, and under infrastructure choose Import Configuration. You’ll need to deselect Dry-run mode, or Otter will only log what would have been imported.
Otter now reflects BuildMaster’s servers, however they are still independent of each other. So if a change was made to the servers in BuildMaster, it would not be reflected in Otter unless the change was also manually made there.
To link the infrastructure so that infrastructure changes are mirrored across each instance, we simply enable Automatic Sync.
After synchronizing BuildMaster and Otter, we can now create a plan in Otter to monitor the servers for drift.
First, we’ll create two server roles in Otter, a hdars-web-server role and a hdars-api-server role and assign servers to them.
After creating the roles we’ll create a configuration plan for the roll hdars-web-server. The plan will have just one operation, ensure App Pool.
After saving the plan, Otter will automatically check the configuration for all servers assigned to the hdars-web-server roll to see if they match the desired configuration. Because all of the servers in the hdars-web-role were deployed to from BuildMaster they already have the App Pool HdarsWeb configured appropriately.
Otter will now continually monitor all servers in this role to make sure that the App Pool exists and is configured as described.
Server drift can happen for a variety of reasons, but commonly occurs when an individual manually changes a setting on a live server. For example, let’s manually change a setting in an HdarsWeb App Pool on a server. We’ll change Managed pipeline mode: Integrated to Managed pipeline mode: Classic.
When Otter checks the configuration of servers in the hdars-web-server role, it identifies that the configuration differs from the defined configuration and flags the entire server roles as “drifted”
Drift however, can be quickly fixed by creating a remediation job. Clicking the Remediate with Job button allows Otter to change the configuration of the drifted server back to the defined configuration. Otter will only run the job on the server that is drifted – the other servers in that role will not be affected.
After running the remediation job, the status of the hdars-web-server role will return to current; meaning all servers associated with that role are configured as defined in Otter.
After setting up and testing the Ensure App Pool operation in Otter, it should be removed from the BuildMaster deployment plan.
If the Ensure App Pool operation was not removed from BuildMaster it’s likely that in the future a setting would be changed in either BuildMaster or Otter. Then as soon as the next deployment was pushed servers would be in drift because the setting was only changed in one place.