DOCSLIB.ORG

A Comparison of Resource Utilization and Deployment Time for Open-Source Software Deployment Tools

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Comparison of Resource Utilization and Deployment Time for Open-Source Software Deployment Tools A COMPARISON OF RESOURCE UTILIZATION AND DEPLOYMENT TIME FOR OPEN-SOURCE SOFTWARE DEPLOYMENT TOOLS Bachelor’s Degree Project in Information Technology with a Specialisation in Network and Systems Administration, IT604G G2E, 22,5 Högskolepoäng Spring term 2017 Jonathan Johansson [email protected] Supervisor: Johan Zaxmy Examiner: Birgitta Lindström Abstract The purpose of this study is to compare the software deployment tools Ansible, Chef and SaltStack regarding deployment time and their respective resource utilization, and the findings of this study are also compared to the previous works of Benson et al. (2016), which also studied deployment time. However, there is no previous research which mentions resource utilization, which is equally important. The study consists of an experiment performed in one of the laboratory rooms at the University of Skövde where all three software deployment tools are configured to deploy a set amount of packages to three hosts each. By measuring deployment time with the most stable releases (as of 2017-04-22) for each software deployment tool, as well as resource utilization for each host and server, this study may assist system administrators to make more informed decisions when deciding which application to use to manage their computers and infrastructure. The results of the study show that Chef is the fastest software deployment tool in terms of deployment time. Chef is also shown to be the most optimized application, as its usage of resources is better than both Ansible and SaltStack. Keywords: Software Deployment Tools, Ansible, Chef, SaltStack Swedish translation Syftet med denna studie är att studera och jämföra fjärrinstallationsprogrammen Ansible, Chef och SaltStack gällande den tid det att installera en mängd program på ett antal klienter, och deras respektive resursutnyttjande. Resultaten från denna studie jämförs även med tidigare studier av Benson et al. (2016), som också studerat tidsåtgången för Ansible, Chef och SaltStack. Det finns emellertid ingen tidigare forskning som nämner resursutnyttjande, vilket är lika viktigt. Studien består av ett experiment som utförs i ett av laboratorierna vid Högskolan i Skövde där alla tre program konfigureras och användes för att installera en viss mängd paket till tre klientdatorer vardera. Genom att mäta tiden det tar för varje program med de senaste stabila utgåvorna (2017-04-22), samt resursutnyttjandet för varje klientdator och server, kan systemadministratörer läsa denna studie för att fatta mer informerade beslut när de bestämmer vilken applikation som ska användas för att hantera deras datorer och infrastruktur. Resultaten av studien visar att Chef är det snabbaste fjärrinstallationsprogrammet för att installera paket på klienter. Chef visar sig också vara den mest optimerade applikationen, eftersom dess resursutnyttjande är bättre än både Ansible och SaltStack. Nyckelord: Fjärrinstallationsprogram, Ansible, Chef, SaltStack Configuration Management and the Cloud Software configuration management tools, also known as software deployment tools, are ways to semi-automate or fully automate time-craving processes such as updating software, re-configuring parameters and the likes on one, or even hundreds of thousands of clients and servers. The three software configuration management tools which this study looks at are Ansible, Chef and SaltStack. Ansible is written in Python, a scripting language, and uses SSH (Secure Shell, a cryptographic network protocol) to deploy packages. Chef is written in the programming language Erlang and requires the client(s) to be installed with an agent, known as the Chef-client. SaltStack is also written in Python, and like Chef, also requires an agent, called a Salt Minion. By measuring the three tools in regards to not only the time it takes for each tool to install a set amount of packages, but also the amount of resources that they utilize during the installations, they can be compared more closely than done in previous research, such as that by Benson et al. (2016). The three tools are tested by setting up an experiment where each server, installed with Ansible, Chef or SaltStack, are accompanied by three hosts each, and given the same resources to operate on to accurately measure each tool with identical environments. Results show that Chef, the Erlang-written tool, is almost twice as fast as both Ansible and SaltStack when deploying applications, and also use a lot more resources – Chef’s memory usage, for example, is shown to operate at an average of 1641 megabytes, which compared to SaltStack’s 643 megabytes and Ansible’s 132 megabytes, is a large difference. System administrators and other IT professionals who handle large amounts of clients and servers may use this research as a basis for making more informed decisions when deciding which tool to implement to handle their infrastructures. With cloud computing being an ever-increasing market with seemingly no end, the need for software configuration management tools too has become very important to handle the large amounts of clients and servers correctly. Table of Contents 1 Introduction .......................................................................................................................................... 1 2 Background ........................................................................................................................................... 2 2.1 Cloud computing ........................................................................................................................... 2 2.1.1 Infrastructure as a Service ...................................................................................................... 2 2.2 Software configuration management ........................................................................................... 4 2.3 Ansible ........................................................................................................................................... 4 2.4 Chef ............................................................................................................................................... 4 2.5 SaltStack ........................................................................................................................................ 5 2.6 Related research ............................................................................................................................ 5 2.6.1 Related benchmark research ................................................................................................. 6 3 Problem definition ................................................................................................................................ 7 3.1 Aim ................................................................................................................................................ 7 3.2 Research question ......................................................................................................................... 7 3.3 Hypotheses .................................................................................................................................... 7 3.4 Motivation ..................................................................................................................................... 8 3.5 Objectives ...................................................................................................................................... 8 3.5 Limitations ..................................................................................................................................... 8 4 Methodology ........................................................................................................................................ 9 4.1 Gathering data ............................................................................................................................... 9 4.1.2 Experiment ................................................................................................................................. 9 4.2 Experimental design ...................................................................................................................... 9 4.2.1 Experimental environment................................................................................................... 10 4.2.2 Experiment topology ............................................................................................................ 12 4.3 Validity ......................................................................................................................................... 13 4.3.1 Validity threats ......................................................................................................................... 13 4.4 Ethics ........................................................................................................................................... 14 5 Results ................................................................................................................................................ 15 5.1 Server Comparison ...................................................................................................................... 15 5.1.1 Server deployment time comparison ................................................................................... 15 5.1.2 Server resource utilization comparison ............................................................................... 16 5.2 Host comparison ........................................................................................................................
Load more

Recommended publications
  • Salt Documentation Release 2014.7.6
    Salt Documentation Release 2014.7.6 SaltStack, Inc. May 19, 2015 Contents 1 Introduction to Salt 1 1.1 e 30 second summary ........................................... 1 1.2 Simplicity ................................................... 1 1.3 Parallel execution ............................................... 1 1.4 Building on proven technology ....................................... 2 1.5 Python client interface ............................................ 2 1.6 Fast, flexible, scalable ............................................. 2 1.7 Open ...................................................... 2 1.8 Salt Community ................................................ 2 1.9 Mailing List .................................................. 2 1.10 IRC ....................................................... 3 1.11 Follow on Github ............................................... 3 1.12 Blogs ...................................................... 3 1.13 Example Salt States .............................................. 3 1.14 Follow on ohloh ................................................ 3 1.15 Other community links ............................................ 4 1.16 Hack the Source ................................................ 4 2 Installation 5 2.1 ick Install .................................................. 5 2.2 Platform-specific Installation Instructions ................................. 5 2.3 Dependencies ................................................. 26 2.4 Optional Dependencies ............................................ 27 2.5 Upgrading
    [Show full text]
  • Python Guide Documentation 0.0.1
    Python Guide Documentation 0.0.1 Kenneth Reitz 2015 11 07 Contents 1 3 1.1......................................................3 1.2 Python..................................................5 1.3 Mac OS XPython.............................................5 1.4 WindowsPython.............................................6 1.5 LinuxPython...............................................8 2 9 2.1......................................................9 2.2...................................................... 15 2.3...................................................... 24 2.4...................................................... 25 2.5...................................................... 27 2.6 Logging.................................................. 31 2.7...................................................... 34 2.8...................................................... 37 3 / 39 3.1...................................................... 39 3.2 Web................................................... 40 3.3 HTML.................................................. 47 3.4...................................................... 48 3.5 GUI.................................................... 49 3.6...................................................... 51 3.7...................................................... 52 3.8...................................................... 53 3.9...................................................... 58 3.10...................................................... 59 3.11...................................................... 62
    [Show full text]
  • Python Guide Documentation 0.0.1
    Python Guide Documentation 0.0.1 Kenneth Reitz 2015 09 13 Contents 1 Getting Started 3 1.1 Picking an Interpreter..........................................3 1.2 Installing Python on Mac OS X.....................................5 1.3 Installing Python on Windows......................................6 1.4 Installing Python on Linux........................................7 2 Writing Great Code 9 2.1 Structuring Your Project.........................................9 2.2 Code Style................................................ 15 2.3 Reading Great Code........................................... 24 2.4 Documentation.............................................. 24 2.5 Testing Your Code............................................ 26 2.6 Common Gotchas............................................ 30 2.7 Choosing a License............................................ 33 3 Scenario Guide 35 3.1 Network Applications.......................................... 35 3.2 Web Applications............................................ 36 3.3 HTML Scraping............................................. 41 3.4 Command Line Applications....................................... 42 3.5 GUI Applications............................................. 43 3.6 Databases................................................. 45 3.7 Networking................................................ 45 3.8 Systems Administration......................................... 46 3.9 Continuous Integration.......................................... 49 3.10 Speed..................................................
    [Show full text]
  • Network Automation Journey
    Network Automation Journey A systems engineer NetOps perspective Walid Shaari FOSDEM 2018 @walidshaari 4th February 2018 https://www.linkedin.com/in/walidshaari Brussels background image credit: https://commons.wikimedia.org/wiki/File:Social_Network_Analysis_Visualization.png Walid Shaari @walidshaari https://www.linkedin.com/in/walidshaari ● System engineer supporting HPC Linux clusters ● Configuration management evaluation and deployment project in 2014 ● Advocating open source, automation, containers and Kubernetes ● Husband and father of 3 lovely kids ● Last 3 months in short work assignment with Network management team Incentives • Open source and standards • Pure Layer 3 network implementation • Lightweight IP to IP encapsulation • Policy based secure networking • Scalable and simple • Scale out SDN controller • Openstack , Docker, Kubernetes, Mesos and CNI “In 2018, we will see more demands placed on the continuous delivery of changes to networking setups due to pressure from containerisation, distributed systems, and security needs. Thus, networking must become as flexible and automation-friendly as the software that runs over it, and become less of a bottleneck.” Nigel Kersten, Chief Technical Strategist at Puppet https://www.itproportal.com/features/what-do-organisations-need-to-prepare-for-in-2018/ How to build an event driven, dynamically reconfigurable microservices platform by Sven Beauprez: https://www.youtube.com/watch?time_continue=388&v=1D8hyLWMtfM Enterprise Network management trends Intent Based Networking Event Driven
    [Show full text]
  • Saltstack-Formulas Documentation Release Master
    SaltStack-Formulas Documentation Release master salt-formulas contributors Nov 12, 2018 Contents 1 Overview 1 2 Contents 3 2.1 Project Introduction...........................................3 2.2 Development Documentation...................................... 488 2.3 Installation and Operations Manual................................... 525 3 Indices and tables 549 i ii CHAPTER 1 Overview This project provides scalable and reliable IT automation using SaltStack for installing and operating wide variety of services and resources. Project provides standards to define service models and processes with ability to reuse these components in varying contexts. 1 SaltStack-Formulas Documentation, Release master 2 Chapter 1. Overview CHAPTER 2 Contents 2.1 Project Introduction Here you will find documentation relevant to architecture and goals of the project. Existing formula ecosystem and undelying metadata standards. 2.1.1 Overview Chapter 1. Overview Home SaltStack-Formulas Project Introduction Project Objectives • Collateral Goodies Project provides standards to define service models and processes with ability to reuse these components in varying contexts. Metadata model shared accross all services let us explore underlying relationships that ease the management of infrastructures acoross whole life-span. The project has little different objectives compare to official salt-formulas. The general orientation of project may be similar to the official salt formulas but the major differences lie at meta-data model and clear decomposition which being consistent
    [Show full text]
  • Devops Tools (Chef, Puppet, Saltstack and Ansible Comparison)
    DevOps Tools (Chef, Puppet, Saltstack and Ansible Comparison) “The tools we use reinforce the behavior; the behavior reinforces the tool. Thus, if you want to change your behavior, change your tools.” – Adam Jacob, CTO, Chef Before we start comparing DevOps tool. Let’s go through few basic concepts… What is Idempotency? Different vendors define idempotence in slightly different ways. OpsCode defines it to mean that a script “can run multiple times on the same system and the results will always be identical.” Ansible states that its scripts “will seek to avoid changes to the system unless a change needs to be made.” This mean that their scripts can be run repeatedly and will only change something when the script and actual server configuration differ. Idempotency ensures a system won't stray from its designated desired state, sending alerts to systems administrators if a requested change would cause a disruption. In Chef word: Convergence and idempotence are not Chef-specific. They're generally attributed to configuration management theory, though have use in other fields, notably mathematics. The way we (Chef) talk about this is that Chef takes idempotent actions to converge the system to the state declared by the various resources. Every resource in Chef is declarative, and performs a test about the current state of the resource, and then repairs the system to match that. Idempotent Behaviour - Configuration management tools keep track of the state of resources in order to avoid repeating tasks that were executed before. If a package was already installed, the tool won't try to install it again.
    [Show full text]
  • Salt Documentation Release 2018.3.3
    Salt Documentation Release 2018.3.3 SaltStack, Inc. Feb 18, 2019 Contents i ii CHAPTER 1 Introduction to Salt We’re not just talking about NaCl. 1.1 The 30 second summary Salt is: • a configuration management system, capable of maintaining remote nodes in defined states (for example, ensuring that specific packages are installed and specific services are running) • a distributed remote execution system used to execute commands and query data on remote nodes, either individually or by arbitrary selection criteria It was developed in order to bring the best solutions found in the world of remote execution together and make them beer, faster, and more malleable. Salt accomplishes this through its ability to handle large loads of information, and not just dozens but hundreds and even thousands of individual servers quickly through a simple and manageable interface. 1.2 Simplicity Providing versatility between massive scale deployments and smaller systems may seem daunting, but Salt is very simple to set up and maintain, regardless of the size of the project. e architecture of Salt is designed to work with any number of servers, from a handful of local network systems to international deployments across different data centers. e topology is a simple server/client model with the needed functionality built into a single set of daemons. While the default configuration will work with lile to no modification, Salt can be fine tuned to meet specific needs. 1.3 Parallel execution e core functions of Salt: • enable commands to remote systems to be called in parallel rather than serially • use a secure and encrypted protocol • use the smallest and fastest network payloads possible • provide a simple programming interface Salt also introduces more granular controls to the realm of remote execution, allowing systems to be targeted not just by hostname, but also by system properties.
    [Show full text]
  • Evaluation of Infrastructure As a Code for Enterprise Automation
    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.
    [Show full text]
  • A Study of Configuration Management Systems Solutions for Deployment and Configuration of Software in a Cloud Environment
    TVE 14 013 maj Examensarbete 15 hp Juni 2014 A Study of Configuration Management Systems Solutions for Deployment and Configuration of Software in a Cloud Environment Kim Torberntsson Ylva Rydin Abstract A Study of Configuration Management Systems Kim Torberntsson & Ylva Rydin Teknisk- naturvetenskaplig fakultet UTH-enheten The amount of servers needed in the world is constantly increasing along with the end users Besöksadress: constantly increasing demand for large scale network Ångströmlaboratoriet Lägerhyddsvägen 1 solutions and IT- services. With virtualisation and cloud Hus 4, Plan 0 computing it has become much easier to create and deploy large numbers of virtual servers, but the servers Postadress: still need configuration. This is precisely what Box 536 751 21 Uppsala configuration management systems (CMS) can help with. Cloud providers often want to include built in Telefon: support for these systems to simplify for their 018 – 471 30 03 customers. The purpose of the study was to compare Telefax: the different CMS available and to recommend the 018 – 471 30 00 ones that deserve to be supported by a cloud provider. A general study, based on parameters defined in the Hemsida: report, was made on twenty different CMS. The five top http://www.teknat.uu.se/student solutions were Puppet, Chef, CFEngine, Salt and Ansible, where Salt and Ansible are more lightweight solutions and Puppet, Chef and CFEngine are more advanced. They were included in a comparison study based on opinions and reviews from the Internet. The recommendation for a hypothetical cloud provider is to include support for several CMS if possible. If not, it is recommended to support one of the lightweight ones, preferably Salt, and one of the more advanced, preferably Puppet.
    [Show full text]
  • Lifecycle Management with Foreman and Katello Basics and Spacewalk Migration
    Lifecycle management with Foreman and Katello Basics and Spacewalk migration Christian Stankowic www.stankowic-development.net Free and Open Source software Conference 19.08.2017 whoami Christian Stankowic VMware Global Inc. Senior PSO Consultant Blogger and book author 2 AGENDA Agenda Overview Installation Content management Puppet Automation Spacewalk migration 4 OVERVIEW What is Foreman? Open-source lifecycle management suite Creating, configuring and inventoring1 systems Support configuration using Puppet or optionally2 Chef, Salt and Ansible 1. Facts, system profiling 2. per plug-in 6 facter 1 $ facter -p 2 architecture => x86_64 3 domain => stankowic.loc 4 interfaces => docker0,ens192,lo 5 ... 6 memoryfree => 1.14 GB 7 processor0 => Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz 8 virtual => vmware Listing 1: facter output 7 Plug-ins Currently nearly 100 plug-ins available online Some examples: Cockpit Monitoring Jenkins CI Slack Third-party DNS-/DHCP 8 Virtualize _all_ the workloads Integration into popular hypervisors and cloud plattforms: VMware vSphere3 oVirt Amazon EC2 Microsoft Azure XEN OpenStack, OpenNebula 3. ESXi and vCenter Server 9 Additional features Roll-based configuration Multitenancy Integration into LDAP, FreeIPA and Microsoft Active Directory Domain Services Distributing infrastructure services to satellite instances Well-documented RESTful API for automation purposes 10 What is Katello? Content management plug-in for Foreman Combines Pulp and Fiction Candlepin software projects Synchronizes OSTree/RPM packages4 and Docker/Puppet modules 4. DEB support in progress 11 Additional features Managing errata Managing subscriptions and channel permissions Snapshots, freezing content verions (e.g. Dev, QA, Prod) 12 13 Foreman/Katello vs. Satellite 6 Foreman RHS6 Releases 1-2 months 11 months Puppet ver- 4.x 3.65 sion Server OS $Linux RHEL Support × X6 Orchestration Smart Proxy Capsule RHN × X7 5.
    [Show full text]
  • Cfengine Manual Pdf
    Cfengine manual pdf click here to download Cfengine reference manual (version b5). Promise bodies. A part of a promise which details and constrains its nature. Data types An interpretation of a. www.doorway.ru). ©. Copyright c your system (see installation guide: .. www.doorway.ru • CFEngine 3 Beginning Examples. How do I install the prerequisites for the hub manually? 8. I For client upgrades there are 2 approaches: manual or automatic upgrade. 1. transferring the files manually by diskette, and examining every serial what is shown above, "is owned by mark, has the extension '.pdf' or '.fdf', and whose. CFEngine Manuals. At its core, CFEngine is a simple framework which supplies a rich standard library of tools to implement and manage very large systems. You can run cf-agent manually, but if you want to have it run on what is shown above, "is owned by mark, has the extension '.pdf' or '.fdf', and whose. CFEngine Homepage · Home · Guide · CFEngine Enterprise · Examples · Reference · Download · CFEngine Enterprise · Guide · Examples and Tutorials. CFEngine Quick Start Guide. Installation; CFEngine File Structure; Create and Manually Execute a Policy . www.doorway.ru Jun 30, Note: If you have manually configured a different location for the .. Here is an exercise: try using the reference manual to look up the elements. Jan 21, This manual corresponds to CFENGINE Edition for version . and cfengine will then parse your file and carry out the instructions. How do I install the prerequisites for the hub manually? .. See more details for the software licensing here; www.doorway.ru pdf. 5. Reference manual: www.doorway.ru If you need assistance in body file˙select pdf˙files.
    [Show full text]
  • Saltstack Is an Open-Source Configuration Management and Remote Execution Engine
    SaltStack i SaltStack About the Tutorial SaltStack is an open-source configuration management and remote execution engine. It remotely executes commands across all machines. It is a python based software. Thomas S Hatch is the creator and the principal architect of SaltStack. SaltStack uses the ZeroMQ messaging library to process high-speed requirements for all networking layers. Salt is simple, scalable and fast. This tutorial will explore the basic principles of SaltStack, SaltStack setup, Minion file system and then walk through with remote execution steps, configuration management, cloud management, Python API operations and finally conclude with a complete working example. Audience This is a tutorial for those professionals who are aspiring to make a career in SaltStack. This tutorial will give you enough understanding on the remote execution operation and configuration management. Prerequisites Before you start doing practice with the various components given in this tutorial, it is being assumed that you are already aware and have a sound knowledge of ZeroMQ and core knowledge of Python. Copyright & Disclaimer Copyright 2018 by Tutorials Point (I) Pvt. Ltd. All the content and graphics published in this e-book are the property of Tutorials Point (I) Pvt. Ltd. The user of this e-book is prohibited to reuse, retain, copy, distribute or republish any contents or a part of contents of this e-book in any manner without written consent of the publisher. We strive to update the contents of our website and tutorials as timely and as precisely as possible, however, the contents may contain inaccuracies or errors. Tutorials Point (I) Pvt.
    [Show full text]