DevOps and Continuous Configuration Automation by Didier De Cock, Senior Principal Consultant, CA Technologies

Transcription

1 About the author DevOps and Continuous Configuration Automation by Didier De Cock, Senior Principal Consultant, CA Technologies Introduction Didier De Cock is a Senior Principal Consultant within CA s Application Delivery CSU, and helps customers realize their DevOps vision. Didier has over 16 years of presales experience with CA Technologies in North America and EMEA. Before CA he worked at Ernst & Young as a network administrator. He holds VMware VCP3, ITIL v2/v3 and Cisco CCDA certifications. The term Configuration is applied broadly within technology that it s easy to get confused as to what different vendors or solutions specifically mean when they use this term. This discussion addresses configuration in terms of repeatable settings that can be standardized across datacenter infrastructure elements, including servers, operating systems, applications, databases and middleware. In this article, we are going to focus on two areas: configuration discovery with change detection and configuration deployment with management. These areas are misconstrued as management intensive and provide more value than CTOs realize. Configuration discovery with change detection is about understanding what you have on the floor, relating it all together, and detecting all critical changes. Configuration deployment with management is about making sure critical elements are in lockstep with the policies that have been set up and deploying them if they don t exist. Another way to look at this is: the first area covers an extensive range of configuration settings and requires very little upfront knowledge about the elements; while the second area covers a narrow set of configuration settings and requires in-depth understanding of the elements. In the paragraphs to follow, you will come to understand a new way to consider these processes so that your configuration effort yields increased operational efficiency and reduced risk. Getting a grip on your application environment The adage You can t manage what you don t measure. is very applicable to configuration automation, so the question then becomes How much do I need to manage? The answer to this question is a risk management exercise. In dealing with Fortune 500 customers, I ve seen what impact a single incorrect configuration change can have on the brand image of the company, it s not pretty. A bunch of highly specialized IT professionals drop everything and start to scrub hundreds of data points on dozens of machines in order to find the needle in the haystack that caused the gears to come to a grinding halt. Some companies try to manage their application environment in Excel or Visio, but those documents are outdated before they are finished. Others try to manage it in their infrastructure monitoring tools, but they typically produce a hierarchical picture that lacks the depth of discovery most people expect. But specialized tools, which cover both the infrastructure interrelationships and the application configuration in depth, are carefully designed to measure what you need to manage.

2 The need for multiple discovery layers In order to build a complete picture of a complex application environment, multiple layers of discovery will be needed. The first layer listens on-the-wire and captures the communication traffic between servers. This will produce output such as Server A on IP 1 is communicating with Server B on IP 2 and they are exchanging SQL Server data using port X. The first layer gives us many of the interrelationships but not all of them. For example, it wouldn t know that server A is a virtual machine that sits inside a hypervisor, or that server B uses a SAN device. The second layer gently queries the hypervisor and storage managers and draws out the relevant relationships. At this point we have an excellent picture of how the big items are related, but lacking the depth of the configuration details. The final layer goes inside each host and creates a map of the application structure, databases layout, operating system and so forth, and grabs the key configuration details for those items you want to manage. The final layer is really cool as it tells you the dependencies within a single host, such as The JRE 1.6 located in path ABC is used by Application A, and the JRE 1.6 located on the same host in path XYZ is used by Application X. Continuous Discovery best practices Large production environments are not static, changes might not be as frequent as in lower environments but they are more important. If you had the ability to continuously discover a production environment to the extent described in this article, you might be rather surprised at what you will learn about the variability of your production assets. So how do we tackle understanding changes in production environments? The answer is continuous discovery. The discovery engine basically needs to show what is new, what has changed, and what is gone. This regular review needs to be incorporated into your change management process to ensure the data is consistent when needed. Visualization It is great to have all this data, but sometimes a picture is worth a thousand words. A powerful visualization engine allows you to look at the data from any angle, so you can easily flip between a view that shows everything related to a server and a view that shows everything related to an application. The same engine also allows

3 you to start at any level of granularity and zoom out or zoom in based on the task at hand. Detecting changes to your infrastructure As this type of data is captured on a regular basis, the software is essentially creating a little time machine that allows you to go back and forth between time periods. This is very useful: I once had a customer who changed an application configuration file as part of a Friday afternoon fire-drill and it slipped through the normal change control mechanisms in place. Everything ran fine for two weeks until the operations team rebooted the VM. After the reboot, the application didn t come up. The customer looked at the change records and nothing obvious popped up. It took them quite a while to determine the obscure change that caused the outage. The little time machine could have compared the current state with any other past state, and it would have found the discrepancy in no time. Any large application environment will consist of thousands of configuration elements, so it s important to assign categories and weights to each configuration element that will reduce the level of noise when trying to find the needle in the haystack. Being able to limit or expand your scope on the fly, so that you don t get

4 overwhelmed with too much data. Reporting plays a big role in this, and quick-look dashboards help to hone in on the things that require attention. Configuration deployment/management Back in the 1980s, every UNIX vendor sprinkled their own flavor on the OS; and later in the 1990s, the same thing happened with Linux. The typical system administrator would create little scripts to automate the tasks that needed to be performed on a regular basis. With the different flavors it would be hard to create a common script that would be able to run on every platform. This is where configuration deployment with management tools finds their roots: they provided a common way to automate the configuration deployment/management across UNIX/Linux platforms. First on the scene was CFEngine, but today, Puppet and Chef garner a large share of the attention in the configuration management space. They use slightly different methods to reach the same goal. First, ease the pain of deploying a complex set of configurations (for example: a typical middleware installation has an installation manual that contains dozens of pages), and second make sure the configurations stay compliant with the pre-defined policy (for example: make sure that your port definitions always remain the same). More recently, the same tools have been leveraged to deploy virtual machines together with their applications and as such it is sometimes called infrastructure as code, because you describe in code/policies how to deploy a new infrastructure from scratch. These tools prove to be very beneficial in today s world where hundreds of machines are spun up, configured and subsequently managed by a single system administrator.

5 Confusion still exists when it comes to deploying applications, because the word Application again means different things to different people. From a configuration perspective an Application is something like Apache, JBoss, and even a database installation such as MySQL; and these are excellent candidates to be deployed and managed by such solution. An application can also be the code that runs on this infrastructure, code written by the customer. The latter type of application deployment is not such a good candidate since those typically have large variability in their deployment. Summary One could argue that if policies were setup correctly with a configuration deployment/management tool, configuration changes wouldn t need to be discovered or tracked with a continuous discovery solution. For new projects businesses should definitely look at embracing configuration deployment solutions. Large data centers however contain a lot of critical legacy software and those big shops can benefit greatly from continuous discovery solutions to ease the pain of managing these complex environments.

6 Connect with CA Technologies at ca.com CA Technologies (NASDAQ: CA) helps customers succeed in a future where every business from apparel to energy is being rewritten by software. From planning to development to management to security, at CA we create software that fuels transformation for companies in the application economy. With CA software at the center of their IT strategy, organizations can leverage the technology that changes the way we live from the data center to the mobile device. Learn more about CA Technologies at CA. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies. ITIL is a Registered Trade Mark of AXELOS Limited. The statements and opinions expressed in this document are those of the author(s) and are not necessarily those of CA. CA and the authors assume no responsibility for consequences resulting from the publication of or use of this document, and are not responsible for, and expressly disclaim liability for, damages of any kind.