The DBA and DevOps - Automation and Configuration Management

The hurdles and challenges with implementing any DevOps project into the IT organization is a common enough theme. Culture may be the biggest hurdle, but one of the easiest areas to focus on first is what to automate.

Starting with two lists and building out an outline for a project plan is a successful strategy for accomplishing this first step: What tasks are manual and take a considerable time of resources in the development cycle? What tasks are performed often, are simple and could be automated easily vs. the list of tasks that will require extensive work to be automated? What to Automate Outside of cultural challenges that we'll discuss later in this series, choosing what to automate is a huge challenge of the automation task. automation.png At one time, a DBA was thought to provide value by manually combing through logs and locating any anomalies to pro-actively address problems before they happened.

As relational databases platforms matured, alerts also matured on warning, so that scripts and services would scan the log and only alert the DBA when a critical issue was evident. The result was a more valuable administrator who could be assigned to more productive than to read through lines of mundane outputs searching for an anomaly.

Realigning the cultural idea of what makes each resource valuable in the future of automation also has to be performed, as tasks are identified and listed as potential candidates for automation. The group over the automation project, along with identifying what will need to be automated, will also consider questions like the following before building out a project plan: What languages and programs will need to be supported by the automation? Will "wrapper scripts" be needed to simplify and reuse automation of script repositories to scheduler? Is there a single scheduler and repository that can support the organizations needs for automation? What level of error handling will be required, along with notifications?

Tools like Chef, Puppet and Ansible have a loyal following and make it easy to use what's automated as functional configuration management. Wrapper Scripts Numerous, common programming languages can host a "wrapper script": Python, Shell, Perl, Powershell, and others.  A wrapper script will then ask for arguments that list which secondary script  to call, along with accepting any number of arguments that pertain to different instructions that the wrapper needs to pass to the secondary script to ensure it performs the correct task on the correct database and objects.

The reason a wrapper script is beneficial, is that it creates one script to be familiar with and a code that is reused and called from one location.  It requires less code to be scripted in the secondary calls and a uniform design for arguments. Most deployment and automation tools support scripts of various languages supplementing their own command line or user interface processing.  This makes for more robust experience and capabilities, as well as a more self-service product.

If the feature doesn't exist, simply script what is needed and add it to the product execution steps. Configuration Management Database Administrators have numerous schedulers already available to them internal and external to the database engine. Schedulers eliminate many of the after-hour work demands with OS level schedulers being the most popular.

The challenge with OS schedulers is that they are host centric and requires management per host, vs. having a centralized scheduler that is able to manage jobs for all tiers- OS, database, and application and file servers from a single location. The DevOps project planners will need to take the list of current systems, database platforms, applications and languages into consideration as they choose what configuration management system will replace the current schedulers used by different groups involved in the project to take it all to the next level.

If a decision is made to incorporate multiple solutions, then risk assessment should be performed to understand how using more than one configuration management system could impact success rate for DevOps releases, consistency across groups, as well as creation of silo environments. Well-known scheduling/configuration management tools, like Jenkins and Control-M, along with lesser-known ones like RunDeck, can create powerful, repeatable release jobs, making DevOps release management simpler across multiple products and environments. With the introduction of configuration management, now the natural next step in the project is orchestration and monitoring, which we'll cover in the next section.