Part 4 - Roles Refactor This is Part 4 of an Ansible Refactoring Series - Start Here
In our second pass through the project we will take the now more modular solution a step further and break it into roles. In this case we will basically map each of the 3 playbooks from Part 3 into 1 role each
Process Create a new branch refactor-pass-02-roles
Create a roles sub-directory in the repo
Part 3 - First Refactor This is Part 3 of an Ansible Refactoring Series - Start Here
In our first pass through the project we will just focus on breaking it up into more modular components, breaking apart the variables from the code, and cleaning up the base directory by moving out any files or templates into sub-directories. If you are Jeff Geerling and very comfortable with writing roles and collections then this part can be skipped!
Part 2 - First Deploy Now your environment is setup and customized it is time to clone, examine, and run your project repository or repo.
Simple Multi-Tier Application Overview The repo contains a simple, monolithic, playbook main.yml that deploys a multi-tier application serving both a web site and it’s associated API.
The Application comprises 3 main components, or tiers, which can be deployed onto the lab infrastructure. There is also a control node to work from.
Part 1 - Getting Started This is Part 1 of an Ansible Refactoring Series - Start Here
To follow along I assume you have access to a lab environment suitable for the task. I will add, July 2020, a Vagrantfile to simplify running this locally on your laptop. Meanwhile this can be deployed via the brand new Ansible Multitier Infra Config assuming you have AWS credentials or OpenStack.
ansible-playbook main.
Refactoring Ansible Modularity, Reuse, and Maintainability In this series I want to explore refactoring a good, or at least decent, monolithic application deployment playbook into something more modular, easier to maintain, and with simpler and better reusability We’ll start by validating it works before our first pass at simply breaking it into more modular playbooks and separating out the variables.
Moving on we’ll identify what if any components would be be better off suited to roles and consider using one or more existing roles from Ansible Galaxy if appropriate.
Overview Whilst this blog article/lab is aimed primarily at Red Hatters, and partners, who can self provision an OpenStack (OSP) Sandbox via Red Hat’s RHPDS it may also be useful to others working both with OpenStack and Ansible Agnostic Deployer aka AgnosticD. I’ll follow this up, shortly, with a second blog article repeating the same exercise but deploying from a laptop running Linux or macOS.
I’ll assume you have either self provisioned, or been provided with, an OpenStack Sandbox instance and have the necessary ssh login details etc.
Overview Whilst I’m a big fan of Ansible Tower’s UI and the overall User Experience I generally try to avoid spending time in it these days. If you spend a lot of time clicking in an automation tool you’re probably "doing it wrong" IMHO!
Up until Ansible Tower 3.6 we have been using a mix of tower-cli, Python based API calls, and Ansible Playbooks to automate our use of Tower and in particular job launching.
Overview Virtualenvs make considerable sense, discussed in more depth here, in any complex python or Ansible environment. In the HOWTO, or lab, we’ll quickly get a python 3 virtualenv up and running on a RHEL or CentOS system.
This article is written making use of one of Red Hat’s Lab Environments running RHEL, in this case on AWS, however this should run fine on CentOS standalone systems. Obviously your repo configurations may vary so adjust to taste, I’ve assumed a pretty minimal install and have opted for CentOS available repos.
Ansible and virtualenvs What started out as a single post quickly became overly long and still didn’t touch on some of the more advanced topics, plus it was marked draft for way too long. Welcome instead to a series on effectively using Ansible and virtualenvs together. Much of this is relevant in a non-Ansible context, however, it is written from an Ansible perspective.
Why virtualenvs for Ansible Part 1(this article)
home Master CheatSheet Index
Basic Pip Commands Install a python package
pip install ansible
Install a specific package version
pip install ansible==2.7.8
Uninstall a python package
pip uninstall ansible
See what versions are available (use illegal version string!)
pip install ansible==foobar
Upgrade a package
pip install --upgrade ansible or pip install ansible -U
