Shortly about automation with Ansible

Ansible roles, playbooks and inventory

Ansible roles are a way to manage multiple scenarios like starting services, making configuration changes, installing software etc. You can easily use the developed scripts from different playbooks so that your code is efficient and without duplicated code. With each role you define what you want to do and achieve. Ansible has a nice documentation about roles.
 

Simply said, with Ansible playbooks you will define the different roles to be executed on different hosts. Ansible documentation is again really helpful to learn more about playbooks.
 

What we still miss in the playbooks and roles is the host information to which devices we want to connect to and how. For that purpose you should use an inventory file to define the services and hosts being accessed. In our example below, we do not define a special communication method and thus use the default protocol for the CLI ie. SSH. The keys to be used and users are also defined in the inventory file. Ansible’s documentation is again helpful to take the first steps with the inventory file.
 

You may want to define a few configurations for Ansible and manage them with a file called ansible.cfg. For each project you are likely to define the verbosity level, log paths, inventory file’s location and some other behaviour. Ansible’s documentation related to the configuration settings is again helpful with plenty of examples and definitions.
 

Ultimately you want to verify the Ansible syntax before anything is taken into use. For that there is available a useful tool called ansible-lint. It’s a command line tool for linting playbooks, roles and collections. It helps developers to create good code with proven behaviours and helps you maintain code. The easiest way to install the tool is with Python’s pip, you can as well use package managers like Homebrew or dnf to do it.
 

That’s it, describing shortly the main ideas of automation with Ansible.
 

Example project

Here we have a simple example repository using Ansible + Github Actions. The example uses Ansible’s playbook and a specific update role to update a predefined device. The update role manages the device’s software with Ansible’s built-in module apt, which is a common acronym for anyone that has been using Debian or its derivatives. List of all available built-in modules.
 

The project uses GitHub Actions to verify the repository. The repository codebase is analysed with a tool called super-linter. More information about the possibilities of super-linter can be found from its repository.
 

The example project uses a SSH private key to connect to the device. It’s straightforward but one may want to use a service like Vault or looking up the secret from other resources as a variable – it depends on how you would like to run your setup.
 

Next blog post

Our next blog post might focus on something else, like using Terraform, Pulumi or Bicep in combination with Ansible to create “known environments”. Combining infrastructure tooling with Ansible is a good combination that everyone should consider in all kinds of modern software projects. Alternatively we could discuss something different like, version control and/or CI/CD pipelines.
 
Plenty of possibilities, let’s see what we will come up with!
 

The blog post author

The post was written by Mikko Drocan.
He’s currently leading the Circle’s DevSecOps business unit and has a long technical background from various software development projects.
LinkedIn: https://www.linkedin.com/in/mikkodrocan/