This repository is a collection of thoughts đĄ intended to help customers with a successful Ansible Automation Platform adoption. âď¸ This repository is by no means a substitution for enterprises that require a full-blown consulting/services need. The focus is on SMEs that are looking for guidance to accelerate their Ansible Automation Platform journey đ .
Maybe you noticed already that I didn't just say Ansible adoption. I said: Ansible Automation Platform. Let me quickly explain why that is: Ansible itself is a tool, and a tool is limited by its function. A hammer alone doesn't build a house. What you need is a collection of tools: a toolkit - or what we call it: A platform. That is the big difference between using Ansible to automate some tasks and using Ansible Automation Platform to implement an automation strategy for your business.
An Automation journey involves 5 phases in my opinion, as seen below. The fact that you are here means that your are at least Aware that there is a need for a strategy.
This document will help you to conquer Level 1-3 as they are the easiest to achieve and are achievable by any business in a relatively short period. The Year 1 section will also include some tips on how to achieve Level 4 and 5.
- Introduction & Prerequisite Learning
- Preparation Tasks
- Day 1
- Week 1
- Month 1 to 3
- Year 1
- Appendix
- Official Red Hat Ansible Blog
- Ansible Automation for SysAdmins - A quickstart guide to Ansible
- Company Success Stories and Exammples for Automation
- Sample AWS Playbooks
- Collection of Blog Posts
- Sample VMvare Playbooks
- Getting Started with Windows Automation
- Learning Ansible with CentOS7
- Terraform and Ansible Example
I think that the most important thing for a successful automation journey is the planning phase. A well-planned automation đ§âđŹ journey will allow you to save time while a badly planned automation journey will likely simply introduce another tool that will eat away precious time in an already busy day đ ââď¸ . This repository is meant to help you with the planning and execution of a successful automation journey.
đĽ To do this, we will look at the tasks necessary before actually deploying Ansible & Ansible Tower, discuss some of the different deployment options as well as identifying targets for the first year.
Before you can get started, it is essential to gain a basic understanding of how Ansible works and how playbooks are written. There are a variety of sources available to you:
A variety of teams within Red Hat offer monthly Ansible workshops that you can attend free of charge. These workshops come in 5 different flavors, depending on your background and needs, my recommendation is the basic Red Hat Enterprise Linux Workshop as it offers a well-rounded curriculum:
- Ansible Red Hat Enterprise Linux Workshop focused on automating Linux platforms like Red Hat Enterprise Linux
- Ansible Network Automation Workshop focused on router and switch platforms like Arista, Cisco, Juniper
- Ansible F5 Workshop focused on automation of F5 BIG-IP
- Ansible Security Automation focused on automation of security tools like Check Point Firewall, IBM QRadar, and the IDS Snort
- Ansible Windows Automation Workshop focused on automation of Microsoft Windows
To avail of this option, get in touch with your local account team. Keep in mind that this is good enough as a basic starting point, for full certification, look at the next option.
If you want the best training on the market then there is no better option than this. Red Hat offers 7 different learning paths that will ensure that you are set up for success.
- Microsoft Windows Automation with Red Hat Ansible
- Advanced Automation: Ansible Best Practices
- Red Hat System Administration III: Linux Automation with Ansible
- Red Hat Certified Engineer (RHCE) exam for Red Hat Enterprise Linux 8
- Ansible Essentials: Simplicity in Automation Technical Overview
- Ansible for Network Automation
- The Red Hat Certified Specialist in Advanced Automation
Each learning path is designed with a goal in mind. The optional certification that you can get at the end of each course carries real value as Red Hat certifications are one of the hardest to get in the IT industry.
There are dozens of online resources available nowadays. If you prefer to learn at your own pace and you know that this way of learning works well for you - go ahead! I have used Udemy before and can recommend the following course: Ansible for the Absolute Beginner - Hands-On - DevOps as well as the advanced course Ansible Advanced - Hands-On DevOps. I have no affiliation with Udemy or the creator.
If you have experience with other automation tools such as Chef or Puppet and you like to just do your own thing, skip to the docs and just get your hands dirty. There is no reason why you wouldn't be able to do this, Ansible is straight forward in its application and requires a very minimal setup. The only problem here is that this option generally skips Ansible Tower.
Jeff Geerling runs a great blog and published dozens of videos on Ansible. He also published a book called Ansible for DevOps that has sold >20.000 copies as of 2019. Jeff is a very vocal contributor to the Ansible Open Source project. I can recommend his content as his blogs helped me a lot when starting.
Great, you have a basic understanding of Ansible and you know how to write playbooks. That alone would be sufficient to help you with personal projects or enable you to automate specific tasks during your day-to-day work. This of course not a strategy, nor does it scale particularly well.
Your first step should be to get in touch with your Red Hat account team and discuss evaluation subscriptions, simultaneously you can follow the steps below. If you don't know who your account team is, you can reach us here and someone will get in touch with you.
The first question you need to answer is the Who question. Who do you want to include in your automation journey? Will it be mainly system administrators? Windows SysAdmins? Linux SysAdmins? Networking teams? Developers? Infrastructure? On-Prem and Cloud teams?
This is the first step in my opinion. Others might disagree with this as one could argue that it is more important to identify the What. From my experience, both work just fine. I prefer to identify the people that need to be involved as it allows all involved parties to work together from the planning phase. The involved teams can then decide on What is to be automated.
You should also start thinking about Users and Teams within Tower. There is a designated RBAC best practices section in the Docs, make sure you read it - you don't need to understand everything in detail. If you are using Enterprise Authentication methods such as LDAP or SAML, it is also important that you look at the relevant section in the docs.
Again, there is no need yet to apply these. But you should identify a strategy.
You should be able to answer the following questions:
- Who will be the core Ansible automation team in the first year?
- Who could extend the core team after this period?
- What RBAC model will be used? Do we need one? If you have only 3 users, the answer is likely no.
- Do we want to use LDAP, AD, or SAML for authentication?
Decide what you want to achieve. You can find inspiration here and here. Identify the tasks that you want to automate. This could be onboarding for new users, deploying VMs, configuring cloud VPCs, or maintaining networking equipment. You should identify 10-20 small tasks for the first few weeks that you want to automate - âď¸ important: Keep it realistic and don't overcomplicate things. Don't come up with something like I want to automate our on-prem infrastructure.
đ Think especially of tasks that are time-consuming and error-prone.
Example Tasks:
- Patching: Request made, operation team logs into machine, applies the patch, reboots the server, validate service, closes change request.
- Provisioning: Dev Team requests VM, operation team deploys VM template, configures VM to organization standard, installs and configures requested software, passes off VM to Dev team, closes request.
You should be able to:
- Identify 10-20 tasks that you want to deliver within the first month.
- Understand who will deliver these tasks.
- Expand each task into individual steps required to execute.
It is important that you give yourself enough time âąď¸ to adopt your new automation tool. If you know that September and October are a busy time for your business, then delay the rollout until November. Don't put extra stress on yourself đ¤. Automation is meant to make your life easier, if you think of it as just another thing that you need to do, you will likely not succeed.
Make sure that you can answer the following questions:
- When will you rollout Ansible and Ansible Tower?
- Are there any roadblocks such as holidays or business disruptors during this rollout?
- Is everyone involved aware of the roadmap?
- Do you know how to reach Red Hat Support in case you encounter any technical problems?
You should have a basic understanding of how Inventories work. And you have also identified what you want to automate. I would recommend spending some time identifying an Inventory strategy. There are a variety of ways to manage your inventories, my recommendation is to utilize Dynamic Inventories in Ansible Tower.
Identify a strategy that works for you to group hosts based on the tasks you have identified.
Examples:
- All RHEL hosts
- All Webservers within a specific VPC
- Windows Servers in AWS EU-West region
The only step left is to decide on the deployment method. Do you need a highly available Ansible Tower deployment or is a basic deployment sufficient? You can find all the deployment options listed in the docs.
I would recommend starting with a basic one machine deployment for smaller teams that manage up to 100 nodes. As long as you have 8-16GB RAM available and 100 GB of storage, you will be fine. If you will have >10 users and a couple of hundred nodes to manage - a clustered approach will be the right decision. The steps for this are explained here.
đ It is really important to remind yourself why you did all of this. Your main goals are to save money, time, and remove sources for errors. All those questions you answered so far will help you to do this.
Today is the big day đĽł, go ahead and deploy your Ansible Tower instance/-s. Implement your authentication model and setup RBAC as you have planned. Then go ahead and set up your inventory, credentials, and projects. It is essential to get these Day 1 tasks right, as it will determine how successful the first 2 weeks will be. If you spent time on the preparation tasks and came up with a strategy, then there is no reason why you should encounter any roadblocks today.
âď¸ Don't forget to personalize Ansible Tower with a custom logo and login message.
You will have identified how you want to manage Ansible Tower users. The following options are available to you - simply follow the instructions based on your preference:
- Username and Password Login
- Token Based Authentication: OAuth2
- Social Authentication: GitHub & Google
- Enterprise Authentication: AD, LDAP, RADIUS, SAML
You can start with a static inventory if there are <100 hosts and there is little volatility for your hosts and hostnames. On the other hand, a dyanamic inventory will allow for greater flexibility and allow you to scale out.
It's not difficult to switch from static to dynamic inventories later on. Don't worry if you struggle with custom inventory scripts, just make sure you have the hosts setup that you identified for your initial tasks. That's the minimum goal.
Set your credentials for private SCM repositories and your hosts. I recommend deploying public keys on the target hosts and storing the private key as a credential. Never use passwords if avoidable.
For the first 3 months, a single repository that contains all playbooks is sufficient, for most users. If you have different teams that manage vastly different environments, find a model that works for you. You could create one repository that manages all Linux machines, one that manages all networking equipment, one for Windows hosts, etc.
Set up a project within Tower for each of those repositories. Make sure that the right users and teams have access to those projects.
You should now have a running Ansible Tower deployment with access to 1 or more repositories to manage your playbooks, as well as access to your target hosts either via static inventories or dynamic inventories through the credentials that you have set up.
You are now ready to do actual work!
You have identified some basic tasks that you would like to automate. Start with those tasks. To accelerate your execution, this section contains some sample playbooks. You can find the playbooks in the Week1 folder.
Now that you're starting to write real playbooks, it is important to get things right đ. For that reason, I would recommend using the Ansible Linter. The following style guide is outdated but could work as a baseline for your company. Just trust me on this one. Without a style guide, things will get out of hand and things get unmaintainable over time. I've learned that lesson the hard way myself đ.
This playbook deploys a NodeJS application with forever. It uses a single variable that is specified at the beginning of the playbook.
This playbook demonstrates how Collections can be configured and used within Ansible Tower.
The integration between Ansible is VMware is quite extensive. The official Ansible documentation contains an entire section around Ansible for VMware. You can also get the collection source code directly.
Pick a simple use case and make it work. For example, look at the vmware_guest module and use it to create a virtual machine on an ESXi host:
- name: Create a virtual machine on given ESXi hostname
community.vmware.vmware_guest:
hostname: "{{ vcenter_hostname }}"
username: "{{ vcenter_username }}"
password: "{{ vcenter_password }}"
validate_certs: no
folder: /DC1/vm/
name: test_vm_0001
state: poweredon
guest_id: centos64Guest
# This is hostname of particular ESXi server on which user wants VM to be deployed
esxi_hostname: "{{ esxi_hostname }}"
disk:
- size_gb: 10
type: thin
datastore: datastore1
hardware:
memory_mb: 512
num_cpus: 4
scsi: paravirtual
networks:
- name: VM Network
mac: aa:bb:dd:aa:00:14
ip: 10.10.10.100
netmask: 255.255.255.0
device_type: vmxnet3
wait_for_ip_address: yes
wait_for_ip_address_timeout: 600
delegate_to: localhost
register: deploy_vm
Ansible has extensive integration with AWS. You can find a quick start guide here. Deploying an EC2 instance is as simple as:
- hosts: localhost
gather_facts: False
tasks:
- name: Provision a set of instances
ec2:
key_name: my_key
group: test
instance_type: t2.micro
image: "{{ ami_id }}"
wait: true
exact_count: 5
count_tag:
Name: Demo
instance_tags:
Name: Demo
register: ec2
AWS offers hundreds of products. Pick something relevant to you, such as backing up a database, deploying a new user to an EC2 instance, or a developer self-service for development and testing purposes.
At this stage, you should have a few playbooks that help you with the automation of basic tasks. It is important that you take some time now to review how the first week went. Were there any roadblocks? Is everyone confident when it comes to the basics: Can you write playbooks, use roles, use collections, apply variables when needed, etc.
Some advice from experience: Don't pull the Java programmer behavior and try to modularize all of your playbooks in the beginning. Make sure that they do what you want them to do. You will be able to review them at a later stage. In the first week it's much more important to get started and deliver playbooks that help you automate stuff.
You must identify what you want to do for the following 12 weeks.
This is arguably the most exciting stage as you are now an advanced Ansible Automation team and you can start pushing the boundaries. Make sure that you truly understand the core concepts and more advanced ones such as:
There are of course a lot more things that you can learn. But don't worry, you will pick them up over time. It is much more important to identify tasks that you want to automate and deliver them.
If you need more inspiration on what to automate, have a look here or here.
Look at your current usage and evaluate the need for a non-production Tower cluster. This is often used in larger enterprises but it could also make sense for an SME depending on the usage and criticality of hosts that are managed.
ServiceNow offers great integration with Ansible. There is a fantastic blog post that helps you with a step-by-step guide setting all of this up.
You could also write a simple web-app that makes use of the Tower API, this is especially useful if HR is looking to automate the onboarding process for a new employee.
There are no limits. Again, start small and roll with it.
You should be able to use and apply roles and collections. Now is also a good time to look into rewriting some of the more complex playbooks and refactor them as roles or even collections.
Make sure that you understand the Ansible Automation Hub and all of its benefits, such as Automation Analytics or the private Automation Hub.
At the end of these 3 months, all of your initial set tasks should be completed â . You should have some roles written and modularized some of the more complex playbooks. Meet with the core Ansible team and review your experiences and decide on a strategy for the following 9 months.
- Are there any issuesâ
- Do you need more resourcesâ
- What went well, what didn't go wellâ
- Who is using Ansible, is there a need to include other teamsâ
This is simple: Keep reviewing what you are doing and identify milestones. Set specific targets. Don't fall into the trap of sating 'yeah we will automate stuff'. What are you going to automate and why? Be as specific as possible.
Now is also a good time to think about on-boarding for new Ansible users in your company. Come up with a learning and on-boarding process for core users and identify a documentation and maintenance strategy.
How do you share playbooks between multiple teams? Are playbooks properly documented? Are there obsolete playbooks?
Ansible excels as an automation tool because it plays so well with other tools such as Terraform and ServiceNow. My recommendation would be to explore the integration with those tools to achieve an Everything as Code state.
A great example is Terraform + Ansible. Terraform excels at being an Infrastructure as Code tool. Especially for complex environments. Ansible on the other hand is fantastic at configuring these environments. Why not combine both?
Some examples:
The Right Way to DevOps with Terraform and Ansible
Ansible and HashiCorp: Better Together
The Automation Services Catalog is probably my favorite feature added in 2020 to the Ansible Automation platform. It is basically a mini ServiceNow system for your playbooks.
Imagine the following: The Dev team wants to get a VM with specific specifications. All they need to do is fill out a form and send it off. A manager can then review and approve the request and off you go - the job will run and send out a notification to the dev team with the machine credentials.
There is much more in it of course, but that's the just of it.
You have mastered Level 3 on the initial graphic. But how do you reach Level 4 or even 5?
Standards and Governance are hugely important as they will make your life significantly easier over time. Most of these items are common sense and should already be practiced - but it is important to review them item by item and have a reality check with your teams. The more you scale up your automation strategy, the more important structure becomes.
- Repository structure, code standards, documentation, and reuse mechanisms (collections/roles/Automation Hub).
- Standardized testing and CI approaches for new playbooks.
- Identify and utilize sources of truth - or start building them.
- Automate content release process, deployments, and lifecycle.
- Operationalize your automation, considering access control, scale, and auditing/visibility.
This is the final boss and the hardest beast to tackle - the larger your organization, the worse this one becomes. Organizational change. Such an over-used term, I know. But it is true: If you want to have an Organization-Wide Automation Strategy, you need to bring the whole organization on board with you.
So how exactly can you increase adoption across silos?
- Socialize and enforce the standards and governance mentioned earlier.
- Charter and empower an Automation team with vision across the organization.
- Establish your Automation platform and simplify onboarding.
- Expand Ansible integrations in support of end-to-end automation.
- Identify and track metrics and KPIs within Automation Hub. Focus on outcomes.
Get in touch with your account team as early as possible to discuss your experiences from the past few months and look at your renewal. Do you need more nodes to manage? Would you like to engage the Red Hat Services team to improve your workflow?
This is meant to be a collection of interesting documents and blogs that might be helpful.
GitHub Repository: Pat Harrison (Domain SA Red Hat)
Pat Harrison - Cloud Automation Blog
GitHub Repository: Pat Harrison (Domain SA Red Hat)
Blog Post: Writing Ansible Playbooks for New Terraform Servers