This is the first part in a series on building a playground for Ansible. At the highest level, Ansible is just a configuration management utility, or as they would say “an automation engine” that works across many different platforms. It’s in the same category as Chef, Puppet, DSC, or SaltStack.
Ansible in particular has been gaining a lot of traction in recent times for numerous reasons. Not only is Ansible incredibly easy to learn (relative to the other tools, but it’s also agentless. There is no complex infrastructure to setup — you just start doing things.
It’s also able to configure more types of devices because of the agentless architecture. A Cisco Catalyst 3850 won’t be able to run any of these agents, but it does have SSH — and that’s good enough for Ansible.
Red Hat’s recent purchase of Ansible also boosted confidence in Ansible and signaled a strong future for the product.
If you want to read up on Ansible, they have great documentation on their site.
Not Just Ansible
I wouldn’t go through all of this just to setup a sandbox for Ansible. While the end result of this series is to gain a basic understanding of how to use Ansible, it is just as important to learn the method of deploying infrastructure — whether sandbox/dev or production. The method is all about automated, consistent, and platform agnostic infrastructure (when possible).
This approach is not specific to Ansible, it can be used for nearly anything.
Since the purpose of the sandbox is to build an environment for safely testing Ansible, we’ll need not just the Ansible control server, but also the nodes that Ansible will be configuring.
Similar to the other tools listed above, Ansible is able to define specific roles that nodes may inhabit, and then configure those nodes to fit into those defined roles — meaning we will want to provision servers with varying roles.
To keep it simple, we’ll just provision 4 servers:
- The Ansbile ‘Control’ server
- Two web servers
- A database server
And to further simplify, they will all be put on the same network.
This section describes what I look for with any sandbox environment.As with anything, your approach should purely be drive my your ‘requirements gathering’ stage, and that’s essentially what this section is.
I don’t want to be required to be at a specific workstation, be on a certain network, run a VPN client, or any other barrier.
A step in the right direction would be to put it in Azure, AWS, DigitalOcean, or some other provider. There a couple of reasons I’m sticking to a local sandbox for this guide.
First, I do not want any reliance on the internet. Often I learn new things like Ansible while on a bus, car, train, or somewhere else that may not have a reliable internet connection. That makes it tough to use a cloud provider.
Second, I don’t want cost to be a barrier. Sure, AWS has a free tier and MSDN users get Azure credits, but that might not work for everyone. All of the tools used here are free and readily available.
Lastly, using hosting services is a skill in itself. You need pick a service, create an account, and then figure out how to use it. That’s great, and I have a post coming up on provisioning cloud resources with Packer, but it’s an unnecessary barrier.
Change Tracking/Source Control
If I am making changes to Ansible playbooks, how I provision the nodes with Vagrant, or anything else, I want those changes to be tracked and documented.
Utilize My Development Tools
I have a consistent development environment setup that I like to use. I especially like my code editor(s) and set them up a very specific way. That said, I don’t want to setup an Ansible server, SSH into it, and use VI to edit piles of YAML (whitespace….the horror). I want autocomplete, syntax highlighting, and use the tools that I am comfortable with.
I use plenty of different systems. I want the experience to be the same across my Macbook Pro, my Surface Pro, and anything else I might use. This means the tools must all be cross-platform.
No Duplication of Work
I want to define a method of provisioning the environment, and only do it one time. That goes for everything: defining VMs, OS provisioning, OS setup, pre-requisite software, networking — all of it. I want to define what it will look like and then make it happen.
I want my one-time-defined environment to be exactly the same each time. This way I don’t ever have to worry about some difference in the setup process causing issues down the road.
I don’t want to care about my test environment. I don’t want to care about downtime, patching, energy usage, virtual resource usage, etc…
And I really don’t want to care about ‘messing up’ anything. If I deeply break a system in some way, I want to destroy it and come back with a freshly provisioned system in a totally automated fashion.I absolutely do not want to waste time troubleshooting something which is unrelated to the product I am trying to learn.
I don’t want to have to worry about causing any damage from a security perspective or by interacting at all with other non-sandbox resources.
To meet the requirements above, these are the tools that I am choosing and their roles.
- Vagrant: VM, OS, and network provisioning and control.
- Git: Source control
- VirtualBox: The underlying hypervisor used by Vagrant (Vagrant calls this a ‘Provider’). While a Provider is required, it doesn’t have to be VirtualBox. Hyper-V, VMware, and Docker are all supported as well.
- Visual Studio Code: There will be plenty of code editing required for things like Vagrantfiles and Ansible playbooks. I use VS Code, but obviously you can use whatever.
As for the operating system….The tools chosen are partially chosen because they are cross-platform, meaning you can run this setup on OS X, Linux, or Windows. I’ll be using Windows just because that’s how I roll.
As mentioned earlier, all of these tools are cross-platform, so the setu process is going to be different depending on your platform choice. There is nothing complicated about the setup of any of these, but I’ll cover the installation on Windows.
I’m going to do it a non-standard way, so you can either follow along here or just do it the old-fashioned way (google the name of the applications, download them, install them). The way that I show requires PowerShell/WMF 5.0, which comes by default with Windows 10.
Troubleshooting: If you have issues with the packages not installing with the PowerShell PackageManagement module, see this post. And if you are having issues getting Vagrant working post-install, see this post!
Open PowerShell as an administrator and type
Install-Package -Name git -ProviderName chocolatey -Force -ForceBootstrap -Verbose
This will install Git and add it to your path. To see the defaults that it sets, check the Chocolatey page on their website.
The ‘Force’ switch simply makes it so that you do not have to confirm, the ‘ForceBootstrap’ switch automatically install the package provider (only needs to be done once), and ‘Verbose’ just outputs everything to stdout.
Once the installation is complete, restart PowerShell and type ‘git’. You should see the following
Same thing as above. Open PowerShell as an administrator, and type
Install-Package -Name virtualbox -ProviderName chocolatey -Force -Verbose
VirtualBox is just one of the providers than can be used. You don’t have to use it, but this guide will be using it.
Vagrant has always had issues on Windows. As of writing this, version 1.8.5 still has issues with SSH. The quickest way to get up and running with Vagrant is by using this auto-install script (written by yours truly): https://github.com/matthew-hickok/Windows-Vagrant-Install
This script does a few different things: installs Cygwin with the SSH and Rsync packages, adds Cygwin to your path and re-prioritizes it, changes a Vagrant script which sets permissions on the gusts (a requirement on Windows guests since Vagrant 1.8.5). See this post for more information.
If you don’t want to use the install script, so ahead and install it in the same way as the other packages
Install-Package -Name vagrant -ProviderName chocolatey -Force -Verbose
Again, this won’t work out of the box on Windows. You will need to complete the steps described in my other post if you do not utilize the install script.
Optional: It’s a good idea to use some type of advanced text editor, and ideally something cross-platform. You will edit YAML (Ansible playbooks), potentially Python (if you end up wanting to write your own Ansible modules), and Ruby (if you want to modify the Vagrantfile).
What to Expect in Parts 2, 3, and 4
**I changed this section as the posts were getting too long — so I broke them up a bit more**
Part 2 will cover using Git.The basic usage, such as cloning, committing, pushing, adding, removing, and .gitignore files.
Part 3 will cover Vagrant. It will explain what Vagrantfiles actually do, and will also demonstrate how to bring up an environment with ease.
Part 4 will purely cover Ansible itself. It will just cover the basics of configuration, inventories, variables, plays, and playbooks.