Modern Server Management with Ansible
Talking about Azure Arc and Azure Update Manager at Midwest Management Summit, and during user-group sessions, I quickly saw areas of opportunity. The consistent comments that I heard from people, whether online or in-person, were along the lines of: this is really cool but how do I manage my servers, and 3rd party apps in Azure without ConfigMgr? These questions got me thinking, for those of us that are trying to get started on our cloud-native journey, there's very real management tasks and concerns that need to be addressed in order to make the leap.
Barriers
▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀
Before I move onto some solutions that I've been playing with, I want to address the elephant in the room, barriers to making the leap to cloud-native.
I asked on Twitter:
The general consensus:
Overwhelm - start where? There's so many cool things out there, but how do I make the business justification for what I'm about to do?
Skills gap - I've built all of these PowerShell scripts and I want to keep using them. I don't want to throw all of that time away and I don't really have time to learn something new.
Building out a new lab - in order to even get started I have to figure out how to even use this new tool, let alone build out an environment.
Fear - “What if it doesn't work, what if I oversell this solution and can’t deliver?” That’s very real and I can definitely relate to those concerns, more than once.
I'm a small team (or a team of just me) - the overwhelm of work, and feeling as through there’s zero bandwidth to try something new seems to be a universal experience. The sage advice heard from the many more experienced people before me, there will always be more than enough work. Carve out time to develop and automate otherwise you’ll never have the time.
Why Ansible?
What made Azure Arc appealing to me, the single pane of glass for managing server updates, utilizing skills I was already developing across Intune and the Azure stack, Ansible had the same appeal. My motivation is to alleviate some of my workload and work towards a set-and-forget-ish solution, giving me the breathing room needed to implement more cool things.
Ansible is an “is an open source IT automation engine that automates provisioning, configuration management, application deployment, orchestration, and many other IT processes. It is free.”
AGENTLESS.
Ansible is agentless. You’re actually getting closer to your cloud-native goal instead of adding more agents/complexity to your environment.
No need to re-write all of your PowerShell (or other language) scripts. You can easily run them in an Ansible playbook leveraging the orchestration abilities of Ansible and super charging your scripts with the ability to dynamically run on hosts given specified parameters discovered by Ansible (in an easy-to-read format).
I'll start this off with saying, this blog post is just meant to get you started. I recommend playing around with these steps in a lab environment. There are additional enterprise implementations (and much better security), but we'll get to those in a later post, for right now, we're going to get going and just dive in.
Getting started with Ansible I had zero experience with Linux and started learning July 1st. Nothing quite like a deadline to kick ya into gear.... ;)
Windows Subsystem for Linux (WSL) ✩°｡🎧 ✩°｡⋆⸜
▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄
Let's get started with WSL. Install WSL wherever you prefer, I'd recommend a VM that way you can always tear it down and start over. If you are using a VM built in Hyper-V, you'll want to enable nested virtualization, the easiest method is with PowerShell:
Set-VMProcesssor -VMName <VMName> -ExposeVirtualizationExtensions $true
I followed the Microsoft docs: Set up a WSL development environment
WSL Configuration ✩ ♬₊.⋆☾⋆⁺₊✧✩♬
▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄
After setting up WSL, install Git and configure the following settings in your Git config file with your respective information:
Install pywinrm (the Python client for the WinRM service):
Installing Ansible…
To install Ansible, you’ll run the following command (I added black, flake8, ansible-lint, and pylint for formatting assistance).
pip3 install black flake8 ansible ansible-lint pylint
VS Code ‧₊˚🖇️✩ ₊˚🎧⊹ ♡
▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄
I find the easiest method to using Ansible is with VS Code and opening into the WSL folder you’ll be working in (note, case sensitivity applies):
Ansible Terminology:
Declarative: Approaching a task by describing the end state instead of a description of the sequence of steps needed to accomplish that end state.
Example from Ansible’s documentation: A declarative specification of a task would be: “put me in California”. Depending on your current location, the sequence of steps to get you to California may vary, and if you are already in California, nothing at all needs to be done. Ansible’s Resources are declarative; it figures out the steps needed to achieve the final state. It also lets you know whether or not any steps needed to be taken to get to the final state
Facts: things that are discovered about remote nodes. Facts are inferred, rather than set.
Host: the remote machine that Ansible manages.
Inventories: group of hosts. This a device collection in ConfigMgr or device group in Intune. Inventories can be dynamic can be updated in real-time as you run playbooks and automation jobs.
Playbooks: the language Ansible uses to orchestrate, configure, administer, or deploy systems.
Plays: While a playbook is a list of plays, a play is simply the mapping between a set of hosts selected by a host specifier and the tasks which run on those hosts.
Roles: units of organization in Ansible implying implementation of a specific behavior. Roles apply certain variable values, and due to their associated file structure, roles allow the specification of shared behavior among playbooks.
Tags: allows the tagging of resources with keywords and then running only the parts of the playbook that correspond with those keywords.
Task: specified actions run against a host.
List: the JSON or YAML version of an array in PowerShell
Templates: Ansible can easily transfer files to remote systems but often it is desirable to substitute variables in other files. Variables may come from the inventory file, Host Vars, Group Vars, or Facts. Templates use the Jinja2 template engine and can also include logical constructs like loops and if statements.
Vars (Variables): As opposed to Facts, variables are names of values (they can be simple scalar values – integers, booleans, strings) or complex ones (dictionaries/hashes, lists) that can be used in templates and playbooks. They are declared things, not things that are inferred from the remote system’s current state or nature (which is what Facts are).
YAML: Ansible does not want to force people to write programming language code to automate infrastructure, so Ansible uses YAML to define playbook configuration languages and also variable files. YAML is nice because it has a minimum of syntax and is very clean and easy for people to skim.
Ansible WSL Gotchas ‧₊˚🖇️✩ ₊˚🎧⊹
▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄
When I first started running Ansible, I kept running into permissions that I couldn’t quite solve. The permission issue that I had was how I found Jeremy Murrah’s Ansible for the Windows Admin (hyperlink is set to start where he’s talking about the permission issue) presentation to begin with (his GitHub). Jeremy references this blogpost by Craig Wilhite: Chmod/Chown WSL Improvements - Windows Command Line (microsoft.com).
I wouldn’t consider myself an expert on Linux permissions, but found this Reddit comment helpful.
If you’re like me and didn’t have any Linux experience, actually opening, editing, and saving various files was challenging at first given that it seemed like there was an assumption that this is common knowledge… If you choose to change the specific file based off of the Reddit comment above, you’ll want to run the following command in your Ubuntu terminal:
sudo nano /etc/wsl.conf
The nano command will open the actual file from the terminal. To save and close the file, the following keystrokes get the job done:
ctrl + o
enter
ctrl + x
Enrolling Servers into Ansible
Ansible communicates with Windows devices using WinRM.
For ease of enrollment, I setup my environment by running Ansible’s PowerShell script on the servers that I wanted to manage: ConfigureRemotingForAnsible.ps1
Once remoting is configured, set an admin account and password for Ansible to use.
Using Ansible on Hosts
I promise, the hardest part of making the jump to Ansible is setting up the Linux environment for Ansible to run in.;)
Ansible Playbooks ✩ ♬ ₊˚.✩
▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄
I’ve setup my GitHub to get a folder structure going for you that you can walk through playing with Ansible.
Now we’ll get comfortable with the terminal. Using the file structure I just mentioned, we’re going to test the communication with my specified servers.
ansible -m win_ping windows -i group.vars/hosts --ask-pass
Order of operations:
ansible - telling the shell to use ansible
windows - telling the shell to call the windows hosts
-m win_ping - which ansible module to use
-i group.vars/hosts - calling inventory and where inventory lives
- - ask-pass - the password that Ansible will use for connecting to the host since we haven’t set up a vault. This is only a step if you don’t have the Ansible account password stored in a vault that is called during a play/playbook.
Key things to remember, Ansible has specific Windows modules that you’ll want to use when running tasks on Windows clients.
Azure Arc Enrollment
Following all of the steps from Azure Arc - Post Session, the only difference will be that for the Deployment Method we’ll instead us Ansible.
ansible-playbook -i group.var/hosts azure/arc-onboard.yml --ask-pass
Order of operations:
ansible-playbook - telling the shell that we’ll be using an ansible playbook
-i group.vars/hosts - calling inventory and where inventory lives
azure/arc-onboarding.yml - calling the playbook that we’ll be using
- - ask-pass - same as above
Chocolatey
I’ll be writing up another post to cover Chocolatey a bit more in-depth, but to get started I’ll be running a simple playbook to install a couple of applications from the Chocolatey repository.
ansible-playbook -i group.vars/hosts chocolatey/playbook.choco.yml --ask-pass
Order of operations:
ansible-playbook - telling the shell that we’ll be using an ansible playbook
-i group.vars/hosts - calling inventory and where inventory lives
chocolatey/choco.yml - calling the playbook that we’ll be using
- - ask-pass - same as above
But why change?
To reiterate, why use Ansible in my environment?
For me, just like why I chose to start using Azure Arc, I kept running into server management as the sticking point for jumping to fully cloud-native. Using Ansible, I’m now able to leverage desired state configuration, complimented by version control for easy peer review or rollback scenarios, on all of my Arc-enabled servers AND I can manage applications with Chocolatey. Rather than scrapping all of my PowerShell scripts, I can still use them by calling them from a playbook (I’ll be covering in a later post), and I’m using the same skills that I am in the rest of my cloud management skillset, just tacking on a bit more YAML than what I was using before.
Oh, and I had to learn some Linux and Python, but that’s been on my list for a long time.. so really, it was a win-win-win for me!
When I’m evaluating solutions, I’m always looking for solutions that save time and allow for dynamic, scalable, and cohesive management.
┊˚➶ ｡˚ ☁
Resources:
Ansible packages:
Craig Wilhite - Chmod/Chown WSL Improvements
Jeremy Murrah’s PowerShell DevOps Global Summit presentation:
Josh King’s PowerShell DevOps Global Summit presentations:
Microsoft Docs:
Python packages: