39,59 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Fachliteratur
- Sprache: Englisch
Ansible has grown from a small, open source orchestration tool to a full-blown orchestration and configuration management tool owned by Red Hat. Its powerful core modules cover a wide range of infrastructures, including on-premises systems and public clouds, operating systems, devices, and services—meaning it can be used to manage pretty much your entire end-to-end environment. Trends and surveys say that Ansible is the first choice of tool among system administrators as it is so easy to use.
This end-to-end, practical guide will take you on a learning curve from beginner to pro. You'll start by installing and configuring the Ansible to perform various automation tasks. Then, we'll dive deep into the various facets of infrastructure, such as cloud, compute and network infrastructure along with security.
By the end of this book, you'll have an end-to-end understanding of Ansible and how you can apply it to your own environments.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 503
Veröffentlichungsjahr: 2018
Ähnliche
Learn Ansible
Copyright © 2018 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
Commissioning Editor: Gebin GeorgeAcquisition Editor: Shrilekha InaniContent Development Editor: Nithin George VargheseTechnical Editor: Khushbu SutarCopy Editor:Safis EditingProject Coordinator: Virginia DiasProofreader: Safis EditingIndexer: Tejal Daruwale SoniGraphics: Tom ScariaProduction Coordinator: Shantanu Zagade
First published: June 2018
Production reference: 1270618
Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK.
ISBN 978-1-78899-875-8
www.packtpub.com
Mapt is an online digital library that gives you full access to over 5,000 books and videos, as well as industry leading tools to help you plan your personal development and advance your career. For more information, please visit our website.
Why subscribe?
Spend less time learning and more time coding with practical eBooks and Videos from over 4,000 industry professionals
Improve your learning with Skill Plans built especially for you
Get a free eBook or video every month
Mapt is fully searchable
Copy and paste, print, and bookmark content
PacktPub.com
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters, and receive exclusive discounts and offers on Packt books and eBooks.
Contributors
About the author
Russ McKendrick is an experienced solution architect who has been working in IT and related industries for over 25 years. During his career, he has had varied responsibilities, from looking after an entire IT infrastructure to providing first-line, second-line, and senior support in both client-facing and internal teams for large organizations.
Russ supports open source systems and tools on public and private clouds at Node4 Limited, where he heads up the public cloud team.
About the reviewer
Paul Adamson has worked as an Ops engineer, a developer, a DevOps engineer, and all variations and mixes of all of these. When not reviewing this book, Paul keeps busy helping companies embrace the AWS infrastructure. His language of choice is PHP for all the good reasons and even some of the bad, but mainly habit. While reviewing this book, Paul has been working for Healthy Performance Ltd, helping to apply cutting-edge technology to a cutting-edge approach to well-being.
Packt is searching for authors like you
If you're interested in becoming an author for Packt, please visit authors.packtpub.com and apply today. We have worked with thousands of developers and tech professionals, just like you, to help them share their insight with the global tech community. You can make a general application, apply for a specific hot topic that we are recruiting an author for, or submit your own idea.
Table of Contents
Title Page
Copyright and Credits
Learn Ansible
Packt Upsell
Why subscribe?
PacktPub.com
Contributors
About the author
About the reviewer
Packt is searching for authors like you
Preface
Who this book is for
What this book covers
To get the most out of this book
Download the example code files
Download the color images
Conventions used
Get in touch
Reviews
An Introduction to Ansible
Ansible's story
The term
The software
Ansible versus other tools
Declarative versus imperative
Configuration versus orchestration
Infrastructure as code
Summary
Further reading
Installing and Running Ansible
Technical requirements
Installing Ansible
Installing on macOS
Homebrew
The pip method
Pros and cons
Installing on Linux
Installing on Windows 10 Professional
Launching a virtual machine
An introduction to playbooks
Host inventories
Playbooks
Summary
Questions
Further reading
The Ansible Commands
Technical requirements
Inbuilt commands
Ansible
The ansible-config command
The ansible-console command
The ansible-doc command
The ansible-inventory command
Ansible Vault
Third-party commands
The ansible-inventory-grapher command
Ansible Run Analysis
Summary
Questions
Further reading
Deploying a LAMP Stack
Technical requirements
Playbook structure
LAMP stack
Common
Updating packages
Installing common packages
Configuring NTP
Creating a user
Running the role
Apache
Installing Apache
Configuring Apache
Configuring SELinux
Copying an HTML file
Running the role
MariaDB
Installing MariaDB
Configuring MariaDB
Importing a sample database
Running the role
PHP
Installing PHP
The phpinfo file
Adminer
Running the role
Overriding variables
Summary
Questions
Further reading
Deploying WordPress
Technical requirements
Preinstallation tasks
The stack-install command
Enabling the repositories
Installing the packages
The stack-config role
WordPress system user
NGINX configuration
PHP and PHP-FPM configuration
Starting NGINX and PHP-FPM
MariaDB Configuration
SELinux configuration
WordPress installation tasks
WordPress CLI installation
Creating the WordPress database
Downloading, configuring, and installing WordPress
WordPress plugins and theme installation
Running the WordPress playbook
Summary
Questions
Further reading
Targeting Multiple Distributions
Technical requirements
Launching multiple Vagrant boxes
Multi-operating system considerations
Adapting the roles
Operating system family
The stack-install role
The stack-config role
The wordpress role
Running the playbook
Summary
Questions
Further reading
The Core Network Modules
Technical requirements
Manufacturer and device support
The modules
A10 Networks
Cisco Application Centric Infrastructure (ACI)
Cisco AireOS
Apstra Operating System (AOS)
Aruba Mobility Controller
Cisco Adaptive Security Appliance (ASA)
Avi Networks
Big Switch Networks
Citrix Netscaler
Huawei CloudEngine (CE)
Arista CloudVision (CV)
Lenovo CNOS
Cumulus Linux (CL)
Dell operating system 10 (DellOS10)
Ubiquiti EdgeOS
Lenovo Enterprise Networking Operating System (ENOS)
Arista EOS
F5 BIG-IP
FortiGate FortiManager
FortiGate FortiOS
illumos
Cisco IOS and IOS XR
Brocade IronWare
Juniper Junos
Nokia NetAct
Pluribus Networks Netvisor OS
Cisco Network Services Orchestrator (NSO)
Nokia Nuage Networks Virtualized Services Platform (VSP)
Cisco NX-OS (NXOS)
Mellanox ONYX
Ordnance
Open vSwitch (OVS)
Palo Alto Networks PAN-OS
Radware
Nokia Networks Service Router Operating System (SROS)
VyOS
System
Interacting with a network device
Launching the network device
The VyOS role
Running the playbook
Summary
Questions
Further reading
Moving to the Cloud
Technical requirements
Interacting with DigitalOcean
Generating a personal access token
Installing dopy
Launching a Droplet
Running the playbook
WordPress on DigitalOcean
The host inventory
Variables
The playbook
The droplet role
Running the playbook
Summary
Questions
Further reading
Building Out a Cloud Network
Technical requirements
An introduction to AWS
Amazon Virtual Private Cloud overview
Creating an access key and secret
The VPC playbook
The VPC role
The subnets role
The internet gateway role
The security group role
The ELB role
Summary
Questions
Further reading
Highly Available Cloud Deployments
Technical requirements
Planning the deployment
Costing the deployment
WordPress considerations and high availability
The playbook
Amazon VPC
Amazon RDS
Amazon EFS
Testing the playbook
Terminating resources
EC2 instances
Instance discovery
New deployment
Existing deployment
Stack
Default variables
Deploy
WordPress
AMI
Autoscaling
Running the playbook
Terminating all the resources
Summary
Questions
Further reading
Building Out a VMware Deployment
Technical requirements
An introduction to VMware
The VMware modules
Requirements
vCloud Air
The vca_fw module
The vca_nat module
The vca_vapp module
VMware vSphere
The vmware_cluster module
The vmware_datacenter module
The vmware_vm_facts module
The vmware_vm_shell module
The vmware_vm_vm_drs_rule module
The vmware_vm_vss_dvs_migrate module
The vsphere_copy module
The vsphere_guest module
VMware vCentre
The vcenter_folder module
The vcenter_license module
The vmware_guest module
The vmware_guest_facts module
The vmware_guest_file_operation module
The vmware_guest_find module
The vmware_guest_powerstate module
The vmware_guest_snapshot module
The vmware_guest_tools_wait module
VMware ESXi
The vmware_dns_config module
The vmware_host_dns_facts module
The vmware_host module
The vmware_host_facts module
The vmware_host_acceptance module
The vmware_host_config_manager module
The vmware_host_datastore module
The vmware_host_firewall_manager module
The vmware_host_firewall_facts module
The vmware_host_lockdown module
The vmware_host_ntp module
The vmware_host_package_facts module
The vmware_host_service_manager module
The vmware_host_service_facts module
The vmware_datastore_facts module
The vmware_host_vmnic_facts module
The vmware_local_role_manager module
The vmware_local_user_manager module
The vmware_cfg_backup module
The vmware_vmkernel module
The vmware_vmkernel_facts module
The vmware_target_canonical_facts module
The vmware_vmotion module
The vmware_vsan_cluster module
The vmware_vswitch module
The vmware_drs_rule_facts module
The vmware_dvswitch module
The vmware_dvs_host module
The vmware_dvs_portgroup module
The vmware_maintenancemode module
The vmware_portgroup module
The vmware_resource_pool module
An example playbook
Summary
Questions
Further reading
Ansible Windows Modules
Technical requirements
Up-and-running
Vagrantfile
Ansible preparation
The ping module
The setup module
Installing a web server
IIS role
ASP.NET role
Interacting with AWS Windows instances
AWS role
User role
Chocolatey role
Information role
Running the playbook
Summary
Questions
Further reading
Hardening Your Servers Using Ansible and OpenSCAP
Technical requirements
OpenSCAP
Preparing the host
The playbook
Install role
Scan role
Running the initial scan
Generating the remediation Ansible playbook
Generating the remediation bash script
Running a standalone scan
Fixing the remaining failed checks
Destroying the Vagrant box
Summary
Questions
Further reading
Deploying WPScan and OWASP ZAP
Preparing the boxes
The WordPress playbook
The scan playbook
The Docker role
Testing the playbook
The WPScan role
Running a WPScan
The OWASP ZAP role
Running OWASP ZAP
Summary
Questions
Further reading
Introducing Ansible Tower and Ansible AWX
Technical requirements
Web-based Ansible
Ansible Tower
Updating the inventory file
Running the playbook
Requesting a license
The hello world demo project
Launching the AWS playbook
Adding a new project
Adding credentials
Adding an inventory
Adding the templates
Running the playbook
Removing the cluster
Tower summary
Ansible AWX
Preparing the playbook
The docker role
The awx role
Running the playbook
Using Ansible AWX
AWX summary
Summary
Questions
Further reading
Ansible Galaxy
Technical requirements
Introduction to Ansible Galaxy
Jenkins playbook
Publishing a role
Creating the docker role
Variables
Tasks
Metadata
README
Committing the code and publishing
Testing the role
Ansible Galaxy commands
Logging in
Importing
Searching
Info
Summary
Questions
Further reading
Next Steps with Ansible
Integrating with third-party services
Slack
Generating a token
The Ansible playbook
Running the playbook
Other services
Campfire
Cisco Webex Teams (Cisco Spark)
CA Flowdock
Hipchat
Mattermost
Say
ServiceNow
Syslog
Twilio
Summary of third-party services
The Ansible playbook debugger
Debugging the task
Summary of the Ansible debugger
Real-world examples
The chat example
Automated deployment
Summary
Further reading
Assessments
Chapter 2, Installing and Running Ansible
Chapter 3, The Ansible Commands
Chapter 4, Deploying a LAMP Stack
Chapter 5, Deploying WordPress
Chapter 6, Targeting Multiple Distributions
Chapter 7, The Core Network Modules
Chapter 8, Moving to the Cloud
Chapter 9, Building Out a Cloud Network
Chapter 10, Highly Available Cloud Deployments
Chapter 11, Building Out a VMware Deployment
Chapter 12, Ansible Windows Modules
Chapter 13, Hardening Your Servers Using Ansible and OpenSCAP
Chapter 14, Deploying WPScan and OWASP ZAP
Chapter 15, Introducing Ansible Tower and Ansible AWX
Other Books You May Enjoy
Leave a review - let other readers know what you think
Preface
Ansible has rapidly grown from a small open source orchestration tool to a full-blown orchestration and configuration management tool owned by Red Hat. In this book, you will learn how to write playbooks using the core Ansible modules to deploy everything from basic LAMP stacks to a full-blown highly available public cloud infrastructure.
By the end of the book, you will have learned how to do the following:
Written your own playbooks to configure servers running CentOS 7, Ubuntu 17.04, and Windows Server
Defined a highly available cloud infrastructure in code, making it easy to distribute your infrastructure configuration alongside your own code
Deployed and configured Ansible Tower and Ansible AWX
Used community contributed roles and learned how to contribute
your
own roles
Worked through several use cases of how you can use Ansible in your day-to-day role and projects
By the end of the book, you should have a good idea of how to integrate Ansible in your day-to-day roles as system administrators, developers, and DevOps practitioners.
Who this book is for
This book is perfect for system administrators, developers, and DevOps practitioners who want to take their current workflows and transform them into repeatable playbooks using Ansible. No prior knowledge of Ansible is required.
What this book covers
Chapter 1, An Introduction to Ansible, discusses what problems Ansible has been developed to resolve, who wrote it, and talks about Red Hat's involvement following their acquisition of Ansible.
Chapter 2, Installing and Running Ansible, discusses how we will work through installing Ansible on macOS and Linux, after covering its background. We will also discuss why there is no native Windows installer and cover installing Ansible on the Ubuntu shell in Windows 10 Professional.
Chapter 3, The Ansible Commands, explains how, before moving onto writing and executing more advanced playbooks, we are going to take a look at the Ansible commands. Here, we will cover the usage of the set of commands that make up Ansible.
Chapter 4, Deploying a LAMP Stack, discusses the deployment of a full LAMP stack using the various core modules that ship with Ansible. We will target the CentOS 7 virtual machine running locally.
Chapter 5, Deploying WordPress, explains the use of the LAMP stack, which we deployed in the previous chapter as our base. We will use Ansible to download, install, and configure WordPress.
Chapter 6, Targeting Multiple Distributions, explains how we will work through adapting the playbook, so it can run against both Ubuntu 17.04 and CentOS 7 servers. The final playbook from the previous two chapters have been written to target a CentOS 7 virtual machine.
Chapter 7, The Core Network Modules, explains how we will take a look at the core network modules that ship with Ansible. Due to the requirements of these modules, we will only be touching upon the functionality these modules provide.
Chapter 8, Moving to the Cloud, discusses how we will move from using local virtual machines to using Ansible to launch a Droplet in DigitalOcean, and then we will use the playbook from the previous chapters to install and configure a LAMP stack and WordPress.
Chapter 9, Building Out a Cloud Network, discusses how after launching the servers in DigitalOcean. We will move onto Amazon Web Services before we launch instances. We will need to create a network for them to be hosted in.
Chapter 10, Highly Available Cloud Deployments, continues with our Amazon Web Services deployment. We will start to deploy services into the network we created in the previous chapter, and by the end of the chapter, we will be left with a highly available WordPress installation.
Chapter 11, Building Out a VMware Deployment, discusses the core modules that allow you to interact with the various components that make up a typical VMware installation.
Chapter 12, Ansible Windows Modules, takes a look at the ever-growing collection of core Ansible modules that support and interact with Windows-based servers.
Chapter 13, Hardening Your Servers Using Ansible and OpenSCAP, explains how you can use Ansible to install and execute OpenSCAP. We will also look at using Ansible to solve any problems found during the OpenSCAP scan.
Chapter 14, Deploying WPScan and OWASP ZAP, explains the creation of a playbook that deploys and runs two security tools, OWASP ZAP and WPScan. Then, using the playbooks from previous chapters from previous chapters launches a WordPress installation to run them against.
Chapter 15, Introducing Ansible Tower and Ansible AWX, takes a look at the two graphical interfaces to Ansible, the commercial Ansible Tower and Open Source Ansible AWX.
Chapter 16, Ansible Galaxy, discusses Ansible Galaxy, which is an online repository of community contributed roles. In this chapter, we will discover some of the best roles available, how to use them, and how to create your own role and have it hosted on Ansible Galaxy.
Chapter 17, Next Steps with Ansible, teaches us how Ansible can be integrated into our day-to-day workflows, from interacting with collaboration services to troubleshooting your playbooks with the built-in debugger. We will also look at some real-world examples of how I use Ansible.
To get the most out of this book
To get the most out of this book, I assume you that you:
Have had some experience of using the command line on both Linux-based machines and also macOS
Have a basic understanding of how to install and configure services on a Linux server
Have a working knowledge of services and languages, such as Git, YAML, and virtualization
Download the example code files
You can download the example code files for this book from your account at www.packtpub.com. If you purchased this book elsewhere, you can visit www.packtpub.com/support and register to have the files emailed directly to you.
You can download the code files by following these steps:
Log in or register at
www.packtpub.com
.
Select the
SUPPORT
tab.
Click on
Code Downloads & Errata
.
Enter the name of the book in the
Search
box and follow the onscreen instructions.
Once the file is downloaded, please make sure that you unzip or extract the folder using the latest version of:
WinRAR/7-Zip for Windows
Zipeg/iZip/UnRarX for Mac
7-Zip/PeaZip for Linux
The code bundle for the book is also hosted on GitHub athttps://github.com/PacktPublishing/Learn-Ansible. In case there's an update to the code, it will be updated on the existing GitHub repository.
We also have other code bundles from our rich catalog of books and videos available athttps://github.com/PacktPublishing/. Check them out!
Download the color images
We also provide a PDF file that has color images of the screenshots/diagrams used in this book. You can download it here: https://www.packtpub.com/sites/default/files/downloads/LearnAnsible_ColorImages.pdf.
Get in touch
Feedback from our readers is always welcome.
General feedback: Email [email protected] and mention the book title in the subject of your message. If you have questions about any aspect of this book, please email us at [email protected].
Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details.
Piracy: If you come across any illegal copies of our works in any form on the Internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.
If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.
Reviews
Please leave a review. Once you have read and used this book, why not leave a review on the site that you purchased it from? Potential readers can then see and use your unbiased opinion to make purchase decisions, we at Packt can understand what you think about our products, and our authors can see your feedback on their book. Thank you!
For more information about Packt, please visit packtpub.com.
An Introduction to Ansible
In our first chapter, we are going to be looking at the technology world before tools such as Ansible came into existence in order to get an understanding of why Ansible was needed.
Before we start to talk about Ansible, let's quickly discuss the old world. I have been working with servers, mostly ones that serve web pages, since the late 90s, and the landscape is unrecognizable. To give you an idea of how I used to operate my early servers, here is a quick overview of my first few years running servers.
Like most people at the time, I started with a shared hosting account where I had very little control over anything on the server side when the site I was running at the time outgrew shared hosting. I moved to a dedicated server—this is where I thought I would be able to flex my future system administrator muscles, but I was wrong.
The server I got was a Cobalt RaQ 3, a 1U server appliance, which, in my opinion, was ahead of its time. However, I did not have root level access to the machine and for everything I needed to do, I had to use the web-based control panel. Eventually, I got a level of access where I could access the server using SSH or Telnet (I know, it was the early days), and I started to teach myself how to be a system administrator by making changes in the web control panel and looking at the changes to the configuration files on the server.
After a while, I changed servers and this time opted to forego any web-based control panel and just use what I had learned with the Cobalt RaQ to configure my first proper Linux, Apache, MySQL, PHP (LAMP) server by using the pages of notes I had made. I had created my own runbooks of one-liners to install and configure the software I needed, as well as numerous scribbles to help me look into problems and keep the lights on.
After I got my second server for another project, I realized that was probably a good time to type out my notes so that I could copy and paste them when I needed to deploy a server, which I am glad I did, as it was shortly after my first server failed—my host apologized and replaced it with a higher-specification but completely fresh machine with an updated operating system.
So I grabbed my Microsoft Word file containing the notes I made and proceeded to then copy and paste each instruction, making tweaks based on what I needed to install and also on the upgraded operating system. Several hours later, I had my server up and running and my data restored.
One of the important lessons I learned, other than that there is no such thing as too many backups, was to not use Microsoft Word to store these types of notes; the command doesn't care if your notes are all nicely formatted with headings and courier font for the bits you need to paste. What it does care about is using proper syntax, which Word had managed to autocorrect and format for print.
So, I made a copy of the history file on the server and transcribed my notes in plaintext. These notes provided the base for the next few years as I started to script parts of them, mostly the bits that didn't require any user input.
These scraps of commands, one-liners, and scripts were all adapted through Red Hat Linux 6—note the lack of the word Enterprise—all the way through to CentOS 3 and 4.
Things got complicated when I changed roles, stopped consuming services from web hosts, and started working for one. All of a sudden, I was building servers for customers who may have different requirements than my own projects—no one server was the same.
From here, I started working with Kickstart scripts, PXE boot servers, gold masters on imaging servers, virtual machines, and bash scripts that started prompting for information on the system that was being built. I had also moved from only needing to worry about maintaining my own servers to having to log in to hundreds of different physical and virtual servers, from ones that belonged to the company I was working for to customer machines.
Over the next few years, my single text file quickly morphed into a complex collection of notes, scripts, precompiled binaries, and spreadsheets of information that, if I am being honest, really only made sense to me.
While I had moved to automate quite a few parts of my day-to-day work using bash scripts and stringing commands together, I found that my days were still very much filled with running all of these tasks manually, as well as working a service desk dealing with customer-reported problems and queries.
My story is probably typical of many people, while the operating systems used will probably be considered quite ancient. Now, the entry point of using a GUI and moving to the command line, while also keeping a scratch pad of common commands, is quite a common one I have heard.
We will be covering the following topics:
Who is behind Ansible
The differences between Ansible and other tools
The problem Ansible solves
Ansible's story
Let's take quick a look at who wrote Ansible, and also what Ansible means.
The term
Before we discuss how Ansible started, we should quickly discuss the origin of the name. The term Ansible was penned by science fiction novelist Ursula K. Le Guin; it was first used in her novel Rocannon's World, first published in 1966. In the context of the story, an Ansible is a fictional device that is able to send and receive messages faster than light.
The term has since been used by several other notable authors within the genre to describe communication devices that are capable of relaying messages over interstellar distances.
The software
Ansible, the software, was originally developed by Michael DeHaan, who was also the author of Cobbler, which was developed while DeHaan was working for Red Hat.
DeHaan left Red Hat and worked for companies such as Puppet, which was a good fit since many users of Cobbler used it to hand off to a Puppet server to manage the servers once they had been provisioned.
A few years after leaving Puppet, DeHaan made the firstpublic commit on the Ansible project; this was on February 23, 2012. The original README file gave quite a simple description thatlaid the foundation for what Ansible would eventually become:
Since that first commit, and at the time of writing, there have been over 35,000 commits by 3,000 contributors over 38 branches and 195 releases.
In 2013, the project had grown and Ansible, Inc., was founded to offer commercial support to Ansible users who had relied on the project to manage both their instructors and servers, be they physical, virtual, or hosted on public clouds.
Out of the formation of Ansible, Inc., which received $6 million in series A funding, came the commercial Ansible Tower, which acted as a web-based frontend where end users can consume role-based access to Ansible services.
Then, in October 2015, Red Hat announced that they were to acquire Ansible for $150 million. In the announcement, Joe Fitzgerald, who was Vice President, Management, Red Hat at the time of the acquisition, was quoted as saying:
During the course of this book, you will find that the statement in the original README file and Red Hat's statement at the time of acquiring Ansible both still ring true.
Before we look at rolling our sleeves up and installing Ansible, which we will be doing in the next chapter, we should look at some of the core concepts surrounding it.
Ansible versus other tools
If you look at the design principles in the first commit compared to the current version, you will notice that while there have been some additions and tweaks, the core principles remain pretty much intact:
Agentless
: Everything should be managed by the SSH daemon, the WinRM protocol
in the case of Windows machines,
or API calls—there should be no reliance on either custom agents or additional ports that need to be opened or interacted with on the target host
Minimal
: You should be able to manage new remote machines without having to install any new software as each Linux host will typically have at least SSH and Python installed as part of a minimal installation
Descriptive
: You should be able to describe your infrastructure, stack, or task in a language that is readable by both
machines and humans
Simple
: The setup processes and learning curve should be simple and feel intuitive
Easy to use
: It should be the easiest IT automation system to use, ever
A few of these principles make Ansible quite different to other tools. Let's take a look at the most basic difference between Ansible and other tools, such as Puppet and Chef.
Declarative versus imperative
When I first started using Ansible, I had already implemented Puppet to help manage the stacks on the machines that I was managing. As the configuration became more and more complex, the Puppet code became extremely complicated. This is when I started looking at alternatives, and ones that fixed some of the issues I was facing.
Puppet uses a custom declarative language to describe the configuration. Puppet then packages this configuration as a manifest that the agent running on each server then applies.
The use of declarative language means that Puppet, Chef, and other configuration tools such as CFEngine all operate using the principle of eventual consistency, meaning that eventually, after a few runs of the agent, your desired configuration would be in place.
Ansible, on the other hand, is an imperative language meaning that, rather than just defining the end state of your desired outcome and letting the tool decide how it should get there, you also define the order in which tasks are executed in order to reach the state you have defined.
The example I tend to use is as follows. We have a configuration where the following states need to be applied to a server:
Create a group called
Team
Create a user
Alice
and add her to the group
Team
Create a user
Bob
and add him to the group
Team
Give the user
Alice
escalated privileges
This may seem simple; however, when you execute these tasks using a declarative language, you may, for example, find that the following happens:
Run 1
: The tasks are executed in the following order: 2, 1, 3, and 4. This means that on the first run, as the group called
Team
does not exist, adding the user
Alice
fails, which means that
Alice
is never given escalated
privileges. However, the group
Team
is added and the user called
Bob
is added.
Run 2
: Again, the tasks are executed in the following
order: 2, 1, 3, and 4. Because the group
Team
was created during run 1, the user
Alice
is now created and she is also given escalated privileges. As the group
Team
and user
Bob
already exist, they are left as is.
Run 3
: The tasks are executed in the same order as runs 1 and 2; however, as the desired configuration had been reached, no changes were made.
Each subsequent run would continue until there was either a change to the configuration or on the host itself, for example, if Bob had really annoyed Alice and she used her escalated privileges to remove the user Bob from the host. When the agent next runs, Bob will be recreated as that is still our desired configuration, no matter what access Alice thinks Bob should have.
If we were to run the same tasks using an imperative language, then the following should happen:
Run 1
: The tasks are executed in the order we defined them, meaning that the group is created, then the two users, and finally the escalated
privileges of
Alice
are applied
Run 2
: Again, the tasks are executed in the order and checks are made to ensure that our desired configuration is in place
As you can see, both ways get to our final configuration and they also enforce our desired state. With the tools that use declarative language, it is possible to declare dependencies, meaning that we can simply engineer out the issue we came across when running the tasks.
However, this example only has four steps; what happens when you have a few hundred steps that are launching servers in public cloud platforms and then installing software that needs several prerequisites?
This is the position I found myself in before I started to use Ansible. Puppet was great at enforcing my desired end configuration; however, when it came to getting there, I found myself having to worry about building a lot of logic into my manifests to arrive at my desired state.
What was also annoying is that each successful run would take about 40 minutes to complete. But as I was having dependency issues, I had to start from scratch with each failure and change to ensure that I was actually fixing the problem and not because things were starting to become consistent—not what you want when you are on a deadline.
Configuration versus orchestration
Another key difference between Ansible and the other tools that it is commonly compared to is that the majority of these tools have their origins as systems that are designed to deploy and police a configuration state.
They typically require an agent to be installed on each host, that agent discovers some information about the host it is installed on, and then calls back to a central server basically saying Hi, I am server XYZ, could I please have my configuration? The server then decides what the configuration for the server looks like and sends it across to the agent, which then applies it. Typically, this exchange takes place every 15 to 30 minutes—this is great if you need to enforce a configuration on a server.
However, the way that Ansible has been designed to run allows it to act as an orchestration tool; for example, you can run it to launch a server in your VMware environment, and once the server has been launched, it can then connect to your newly launched machine and install a LAMP stack. Then, it never has to connect to that host again, meaning that all we are left with is the server, the LAMP stack, and nothing else, other than maybe a few comments in files to say that Ansible added some lines of configuration—but that should be the only sign that Ansible was used to configure the host.
Infrastructure as code
Before we finish this chapter and move on to installing Ansible, let's quickly discuss infrastructure as code, first of all by looking at some actual code. The following bash script installs several RPMs using the yum package manager:
#!/bin/shLIST_OF_APPS="dstat lsof mailx rsync tree vim-enhanced git whois iptables-services"yum install -y $LIST_OF_APPS
The following is a Puppet class that does the same task as theprevious bash script:
class common::apps { package{ [ 'dstat', 'lsof', 'mailx', 'rsync', 'tree', 'vim-enhanced', 'git', 'whois', 'iptables-services', ]: ensure => installed, }}
Next up, we have the same task using SaltStack:
common.packages: pkg.installed: - pkgs: - dstat - lsof - mailx - rsync - tree - vim-enhanced - git - whois - iptables-services
Finally, we have the same task again, this time using Ansible:
- name: install packages we need yum: name: "{{ item }}" state: "latest" with_items: - dstat - lsof - mailx - rsync - tree - vim-enhanced - git - whois - iptables-services
Even without going into any detail, you should be able to get the general gist of what each of the three examples is doing. All three, while not strictly infrastructure, are valid examples of infrastructure as code.
This is where you manage the code that manages your infrastructure in exactly the same way as a developer would manage the source code for their application. You use source control, store it in a centrally available repository where you can collaborate with your peers, you branch and use pull requests to check in your changes, and, where possible, you write and execute unit tests to ensure that changes to your infrastructure are successful and error-free before deploying to production. This should be as automated as possible. Any manual intervention in the tasks mentioned should be seen as potentially a point of failure and you should work to automate the task.
This approach to infrastructure management has a few advantages, one being that you, as system administrators, are using the same processes and tooling as your developer colleagues, meaning that any procedures that apply to them also apply to you. This makes for a more consistent working experience, as well as exposing you to tools that you may not have been exposed to or used before.
Secondly, and more importantly, it allows you to share your work. Before this approach, this type of work seemed to others a dark art performed only by system administrators. Doing this work in the open allows you to have your peers review and comment on your configuration, as well as being able to do the same yourself to theirs. Also, you can share your work so that others can incorporate elements into their own projects.
Summary
Before we finish this chapter, I would like to just finish up my own personal journey. As mentioned elsewhere in the chapter, I moved from my collection of scripts and runbooks to Puppet, which was great until my requirements moved away from managing just server configuration and maintaining the state of the servers I was managing.
I needed to start to manage infrastructure in public clouds. This requirement quickly started to frustrate me when using Puppet. At the time, Puppet's coverage of the APIs I need to use for my infrastructure was lacking. I am assured it is a lot better now, but also I found myself having to build too much logic into my manifests with regard to the order in which each task was executed.
It is around this time, which was December 2014, that I decided to look at Ansible. I know this because I wrote a blog post entitled First Steps With Ansible, and since then, I don't think I have looked back. I have since introduced several of my work colleagues and customers to Ansible, as well as writing previous books for Packt.
In this chapter, we have taken a look at my own personal history with both Ansible and some of the other tools that Ansible is compared to, and we have discussed the differences between these tools and also where Ansible originated.
In the next chapter, we are going to look at installing Ansible and running our first playbooks against a local virtual machine.
Further reading
In this chapter, we mentioned Puppet and SaltStack:
Puppet is a configuration management tool that runs a server/agent configuration. It comes in two flavors—the open source version and an enterprise version that is supported by Puppet, the company. It is a declarative system and is closely tied to Ruby. For more information on Puppet, see
https://puppet.com/
.
SaltStack is another configuration management tool. It is extremely scalable and, while it shares a design approach with Ansible, it works in a similar way to Puppet in that it has a server/agent approach. You can find more information on SaltStack at
https://saltstack.com/
.
I also mentioned my blog, which you can find at
https://media-glass.es/
.
Installing and Running Ansible
Now that we know a little about the background of Ansible, we will work on installing it and, once installed, we will run our first set of playbooks against a test virtual machine running CentOS 7.
The following topics will be covered in this chapter:
How to install Ansible on macOS and Linux
Running Ansible on Windows 10 Professional using the Linux subsystem
Launching a test virtual machine
An introduction to playbooks
Technical requirements
In this chapter, we will be installing Ansible, so you will need a machine capable of running it. I will go into more details about these requirements in the next part of the chapter. We will also be using Vagrant to launch a virtual machine locally. There is a section that walks through installing Vagrant as well as downloading a CentOS 7 Vagrant box, which is around 400 MB.
You can find complete versions of all of the playbooks in the GitHub repository that accompanies this book at https://github.com/PacktPublishing/Learn-Ansible/tree/master/Chapter02.
Installing Ansible
Let's dive straight in and install Ansible. Throughout this book, I will be assuming that you are running a macOS host machine running macOS High Sierra or a Linux machine with Ubuntu 18.04 LTS installed. While we will cover running Ansible on Windows 10 Professional using the Linux subsystem for Windows, using Windows as a host machine will not be supported in this book.
Installing on macOS
There are a few different ways you can install Ansible on your macOS High Sierra host machine. I will cover them both.
Homebrew
The first installation method is to use a package called Homebrew.
To install Ansible using Homebrew, you first need to install Homebrew. To do this, run the following command:
$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
At each step of the installation process, the installer will tell you exactly what it is going to do and also prompt you for any additional information it needs from you in order to complete the installation.
Once installed, or if you already have Homebrew installed, run the following commands to update your list of packages and also check that your Homebrew installation is optimal:
$ brew update
$ brew doctor
Depending on how new your installation is, or when you last used it, you might see a different output to the following screenshot:
Next, we can check what packages Homebrew provides for Ansible by running the following command:
$ brew search ansible
As you can see from the results in the following screenshot, there are several packages returned in the search:
We just want the Ansible package. You can find out more about the package by running the following command:
$ brew info ansible
You can see the results of the command in the following screenshot:
As you can see, the command returns information on the version of the package that will be installed, as well as details on where you can see the code for the formula that installs the package. In our case, you can view details of the formula at https://github.com/Homebrew/homebrew-core/blob/master/Formula/ansible.rb.
To install Ansible using Homebrew, we simply have to run the following command:
$ brew install ansible
This will download and install all of the dependencies and then the Ansible package itself. Depending on how much of the dependencies are already installed on your machine, this may take a few minutes. Once installed, you should see something like the following screenshot:
As you can see from the preceding screenshot, Homebrew is quite verbose in its output, giving you both feedback on what it is doing and details on how to use the packages it installs.
The pip method
The second method, pip, is a more traditional approach to installing and configuring a Python package.
Depending on what you have installed on your machine, you may have to install pip. To do this, run the following command:
$ easy_install pip
This will install pip using the easy_install installer, which ships with macOS by default. Once installed, you can install Ansible by running the following command:
$ sudo -H pip install ansible
You will be prompted for your password, as we are using the sudo command, like Homebrew. This command will download and install all of the prerequisites needed to run Ansible on your system. While it is as verbose as Homebrew, its output contains information on what it has done, rather than hints on what do to next:
As you can see, a lot of the requirements were already satisfied.
Pros and cons
So, now that we have covered some of the different ways of installing Ansible on macOS, which is best? Well, there is no real answer to this as it comes down to personal preference. Both methods will install the latest versions of Ansible. However, Homebrew tends to be a week or two behind the current release.
If you have a lot of packages already installed using Homebrew, then you will already be used to running the following commands:
$ brew update
$ brew upgrade
Every once in a while, do update your installed packages to the latest. If you already do this, then it would make sense to use Homebrew to manage your Ansible installation.
If you are not a Homebrew user and want to make sure that you immediately have the latest version installed, then use the pip command to install Ansible. Upgrading to the latest version of Ansible is as simple as running the following command:
$ sudo -H pip install ansible --upgrade --ignore-installed setuptools
I have found that I need to use the --ignore-installed setuptools flag, as there are problems and conflicts with the version managed by macOS and the one which is part of Ansible updates. I have not known this to cause any problems.
Should you need to, then you can install older versions of Ansible using both Homebrew and pip. To do this using Homebrew, you just need to remove the current version by running the following command:
$ brew uninstall ansible
Then, you can install an earlier version of the package by running the following command:
$ brew install [email protected]
Or, for an even earlier version, you can use the command:
$ brew install [email protected]
For details on exactly which version of the package is going to be installed, you can run one of the following two commands:
$ brew info [email protected]
$ brew info [email protected]
While this will install an earlier version, you do not get much choice in which version is installed. If you really need an exact version, you can use the pip command to install it. For example, to install Ansible 2.3.1.0, you would need to run:
$ sudo -H pip install ansible==2.3.1.0 --ignore-installed setuptools
You should never need to do this. However, I have found that on some occasions, I have had to downgrade to help debug quirks in my playbooks introduced by upgrading to a later version.
As mentioned, I spend the bulk of my time in front of a macOS machine in some form or other, so which of the two methods do I use? Primarily, I use Homebrew, as I have several other tools installed using Homebrew. However, if I need to roll back to a previous version, I use pip and then return to Homebrew once the issue is resolved.
Installing on Linux
There are a few different ways of installing Ansible on Ubuntu 18.04. However, I am only going to cover one of them here. While there are packages available for Ubuntu from which you can install with apt, they tend to quickly become out of date and are typically behind the current release.
Because of this, we will be using pip. The first thing to do is install pip, and this can be done by running the following command:
$ sudo -H apt-get install python-pip
Once pip is installed, the instructions for installing Ansible are the same as installing on macOS. Simply run the following command:
$ sudo -H pip install ansible
This will download and then install Ansible and its requirements, as shown in the following screenshot:
Once installed, you can upgrade it by using the following command:
$ sudo -H pip install ansible --upgrade
Note that this time, we do not have to ignore anything as there shouldn't be any problems with the default installation. Also, downgrading Ansible is the same command:
$ sudo -H pip install ansible==2.3.1.0 --ignore-installed setuptools
The preceding commands should work on most Linux distributions, such as CentOS, Red Hat Enterprise Linux, Debian, and, Linux Mint.
Installing on Windows 10 Professional
The last platform we are going to cover is Windows 10 Professional; well, sort of. There is no supported way of running an Ansible controller on a Windows machine natively. Because of this, we will be using the Windows subsystem for Linux.
This is a feature, which, at the time of writing, is in beta, and is only available to Windows 10 Professional users. To enable it, you first need to enable developer mode. To do this, open the Windows 10 Settings app and then toggle Developer mode, which can be found under UPDATE & SECURITY, and thenFor Developers.
Once Developer mode has been enabled, you will be able to enable the shell. To do this, open Control Panel, then click on Programs and Features, and then on Turn Windows features on or off. In the list of features, you should see Windows Subsystem for Linux (Beta)listed. Tick the box next to it and thenOK. You will be prompted to reboot your machine. Following the reboot, click on the Start menu and typebash. This will trigger the installation process. You should see something like the following screenshot:
Once downloaded, it will extract and install the subsystem. You will be asked a few questions. As needed, the entire process will take between 5 and 10 minutes. Once installed, you should now have a full Ubuntu 16.04 system running on your Windows machine. You can check this by running the following command:
$ cat /etc/*release
The following screenshot shows the output for the preceding command:
From here, you can run the following commands to install Ansible:
$ sudo -H apt-get install python-pip
$ sudo -H pip install ansible
The following screenshot shows the output for the preceding command:
As you can see, everything works as if you were running an Ubuntu machine, allowing you to run and maintain your Ansible installation in exactly the same way.
As already mentioned, while this is a viable way of running an Ansible control node on a Windows-based machine, some of the other tools we will be covering in future chapters may not work with Windows. So while you may follow along using the Ubuntu instructions, some parts may not work. Where possible, I will add a note saying that it may not work on Windows-based systems.
