Masaryk University Faculty of Informatics Evaluation of Infrastructure as a Code for Enterprise Automation Master’s Thesis Michal Hagara Brno, Spring 2018 Declaration Hereby I declare that this paper is my original authorial work, which I have worked out on my own. All sources, references, and liter- ature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Michal Hagara Advisor: Bruno Rossi, PhD i Acknowledgements I would like to thank Dr. Bruno Rossi for being my adviser during the thesis, as without his advice and help I would not be able to finish the thesis. I would like to thank him also for his patience and understanding on the personal level. iii Abstract Expansion of cloud and virtualization is present every day, and it has to be handled accordingly, as there is an emphasis on speed, consis- tency and time to market. The thesis deals with this phenomenon and provides insight into terms such as automation, Infrastructure as a Code, DevOps or configuration management (CM). The thesis aims to introduce how the selection process of configuration management tool for enterprise automation should be carried out, as the integra- tion of the right tool to the infrastructure is critical. The selection process is divided into two parts. First part evaluates mechanics and different aspect of configuration management tools from the practical point of view. In the second part of the thesis evaluation of public survey of configuration management tools is presented. The primary contribution of this thesis is aimed at providing insight on how the selection process of CM tool should be carried out, and also to provide a comprehensive review of CM tools for enterprise automation. iv Keywords Configuration management, automation, DevOps, Infrastructure asa Code, Ansible, Chef, Puppet, SaltStack v Contents 1 Introduction 1 2 Infrastructure as a Code 3 2.1 History and DevOps background of IaC ...........3 2.2 Infrastructure as a Code as a part of DevOps .........4 2.3 Configuration management ..................5 3 Comparison of configuration management tools 7 3.1 Ansible ............................9 3.1.1 Communication and security . .9 3.1.2 Ansible specific working mode . .9 3.1.3 Ansibles mechanics and terminology . 10 3.1.4 Ansible DSL and templating engine . 12 3.2 Chef .............................. 13 3.2.1 Communication and security . 13 3.2.2 Chefs specific working mode . 14 3.2.3 Chefs mechanics an terminology . 14 3.2.4 Chef DSL and templating engine . 16 3.3 Puppet ............................. 17 3.3.1 Communication and security . 17 3.3.2 Puppet specific working mode . 18 3.3.3 Puppets mechanics an terminology . 18 3.3.4 Puppet DSL and templating engine . 20 3.4 SaltStack ........................... 21 3.4.1 Communication and security . 21 3.4.2 Salts specific working mode . 21 3.4.3 Salts mechanics an terminology . 22 3.4.4 Salt DSL and templating engine . 25 3.5 Intermediate result of evaluation ............... 25 4 Public survey of configuration management tools 27 4.1 Installability .......................... 30 4.2 Configurability ........................ 31 4.3 Stability ............................ 33 4.4 Scalability ........................... 34 4.5 Usability/learning curve ................... 36 vii 4.6 ACL capabilities ........................ 38 4.7 Documentation ........................ 39 4.8 Support ............................ 41 4.9 Training ............................ 42 4.10 Supported Operating Systems ................ 43 4.10.1 OS Support of Ansible . 44 4.10.2 OS Support of Chef . 45 4.10.3 OS Support of Puppet . 46 4.10.4 OS Support of SaltStack . 46 4.11 Advantages .......................... 47 4.12 Disadvantages ......................... 48 4.13 Satisfaction .......................... 49 4.14 Deployment properties .................... 50 4.14.1 Portability . 50 4.14.2 Installability . 51 4.14.3 Adaptability . 51 4.14.4 Configurability . 51 4.14.5 Distributability . 51 4.14.6 Scalability . 51 4.14.7 Stability . 52 4.15 Specification management properties ............. 52 4.15.1 Language . 52 4.15.2 Monitoring . 53 4.15.3 Versioning . 53 4.15.4 Integration . 53 4.15.5 Access Control . 53 4.16 Result of the public survey of CM tools ............ 54 5 Conclusion 59 5.1 Results in regards to the comparison of CM tools ...... 59 5.2 Results in regards to the public survey of CM tools ..... 59 5.3 In retrospect .......................... 60 A Online survey 69 B CM tools code examples 77 B.1 Ansible ............................ 77 B.1.1 Playbook example . 77 viii B.2 Chef .............................. 78 B.2.1 Recipe example . 78 B.3 Puppet ............................. 79 B.3.1 Manifest example . 79 B.4 SaltStack ........................... 80 B.4.1 State file example . 80 B.5 Jinja template example .................... 81 B.6 ERB template example .................... 82 ix List of Tables 3.1 Overview of practical CM tools comparison 26 4.1 Overview of respondents occupation 29 4.2 Overview of public survey results 58 xi List of Figures 4.1 Installability graph 30 4.2 Configurability graph 32 4.3 Stability graph 34 4.4 Scalability graph 35 4.5 Usability graph 37 4.6 ACL graph 38 4.7 Documentation graph 40 4.8 Support graph 41 4.9 Training graph 42 4.10 OS Support graph 44 4.11 Advantages graph 47 4.12 Disadvantages graph 48 4.13 Satisfaction graph 49 4.14 Deployment properties graph 50 4.15 Specification Management properties graph 52 xiii 1 Introduction In the enterprise of the present, when a large number of services is involved in the business of companies, there is a need for structure and consistency as well as a need for rapid deployments. Companies services usually consist of several parts, two of them being software and network infrastructure, e.g., servers. Many companies tend to use cloud services either for themselves or to provide their services to another enterprise. There is also part of an enterprise which for different reasons, for example, security, decides to host their servers in-house. Each of these worlds deals with the same challenges and are sig- nificantly affected by modern IT demands. The client usually wants to have their service up and to run as fast and stable as possible. As part of this trend, the term DevOps arose not limited to principles of agile development. DevOps allows companies to be able to compete on fast-growing market of nowadays. In practice, there are two approaches how one can look at this term. DevOps engineer might be a developer or a Software engineer, who is also able to perform system engineers task and vice versa [1]. "DevOps is a term given to a set of practices, ideals, and tools that are helping organizations of various sizes deliver value on their IT investments at quicker rate[2, p. 30]." As a part of DevOps, or more precisely one of the steps in this practice is methodology defining network infrastructure called Infras- tructure as a Code or shortly IaC. IaC resolves around the term of idempotence, which means the ability to set up and configure the same environment every time it is applied. Not only providing consistency to new systems but also keeping already running systems according to desired definitions as the way the environment should look and behave is defined. The administrator isn’t forced to manage a large number of servers, where each becomes unique during some period, but can keep the systems in the same stat [3]. When implementing IaC in the enterprise, it’s not possible to un- derestimate selection of the right tool, as wrong decision might result 1 1. Introduction in management dissatisfaction, delayed projects, and other unplanned complications. Thus, the thesis goals and objectives are to give insight on Infras- tructure as a Code, its history, principles, and characteristics. To discuss DevOps as a base for Infrastructure as a Code. The thesis also gives insight and explores modern trends in infras- tructure automation, e.g., configuration management. The following text also evaluates configuration management tools as users around the world see them. Last but not least the thesis practically discusses different configu- ration management tools. The structure of the thesis is following: Chapter 2, Infrastructure as a Code provides information on Infras- tructure as code, DevOps principles, and configuration management tools in general. Chapter 3, Comparison of configuration management tools com- pares different aspects of configuration management tools such as security, means of communication, etc. Chapter 4, The public survey of configuration management tools gives insight on how users perceive their CM tools in regards to prop- erties such as installability, configurability, etc. 2 2 Infrastructure as a Code 2.1 History and DevOps background of IaC In the past number of IT professionals was not as large as it is today. Over the years the complexity of systems and IT grew. Professions as a System administrator, System engineer as well as more specialized jobs as Quality assurance specialists, Database specialists or Security specialist arose. With this trend the need for automated processes became apparent. System administrators as a part of operations were responsible for keeping systems up and running. DevOps was in a way a result of this continual fast expansion of IT but isn’t as new as it might seem at first glance. The term DevOps is splittable into two separate words "Development" and "Operations". This particular methodology is a convergence of several principles, as the Lean movement, Agile principles, Theory of constraints, change management, quality assurance (QA), product management and oth- ers, two of the most notable being Lean and Agile. Agile arose around the end of the second millennium and is in a way successor to waterfall model, with its incremental releases, small changes, and highly self- motivated teams.