Pump up your ITIL with Automation

In the world of automation and agility, it seems that Information Technology Infrastructure Library (ITIL) doesn't have a role to play anymore, being marked as an "old school" framework. Can it be the end of the methodology after it served numerous IT organizations for so long as a guideline and blueprint for their processes?

This series of articles shows how automation, and more specifically Red Hat Ansible Automation Platform and the principles of Infrastructure as Code (IaC), can help bring some of the ITIL topics into the agile and automated bliss:

• Configuration management
• Change and release management
• Incident and problem management

So let's step into the topic of configuration management and what everybody still knows as CMDB (Configuration Management Database) even if ITIL has since long titled it as CMS (Configuration Management System). This name change was meant to highlight the fact that the function can be fulfilled by a combination of multiple databases and tools, but it won't matter here, so we'll stick to the infamous CMDB term.

Do you love your CMDB? Probably not, according to my experience with numerous customers. The data is generally outdated and wrong, considered useless, which means that its maintenance is considered a chore. This means that it's maintained with as little effort as possible, in a careless manner, making it even less up-to-date, and in a downward spiral you go.

To avoid the crash, we need first to understand that a CMDB and the related Configuration management have two main purposes:

1. Document the desired state of your environment - this is too often done manually, with the admins required to maintain the configuration once in the "real world" and once in the CMDB. To do this, companies often populate the CMDB from the discovery of the environment, which leads to a database that documents the current state. Note that there is no clarity if it corresponds to the desired state or not.
2. Support the change management process by allowing an analysis of the environment, e.g. to validate that there is enough disk space free on each server before installing the new bloated software. Based on the noted lack of trust in the data quality, it is generally ignored as part of the process.

Looking at the above shortcoming, we need first to more clearly structure our database, as it contains multiple kinds of data:

1. Desired state data - this is information that comes from a service or change request and represents what one needs to have in one's environment.
2. Actual state data - this is information discovered from the environment and representing its current state.

As data can be only desired, only actual or both, we have three categories, which we'll reference with A to C for sake of simplicity:

Because admins don't want to maintain the desired state twice, you use the desired state in your CMDB (type A and B) as inventory source for Ansible Automation Platform to configure your environment from it. Admins know that the better the data in the CMDB, the better the result in the real world, which leads to less work. That should be enough motivation to quickly improve the data quality of your CMDB.

Because the CMDB doesn't mix-up desired state and actual state for the data of category A, you can detect discrepancies, make a decision on how to fix it, and use Ansible again for automated remediation. This should help you quickly align reality with desired state, and have the right data to make decisions.

The data of type C isn't of much use for automation, and is meant for decision making in your change management process, though you could decide to skip a patch cycle if the disks are too full. That said, you shouldn't confuse this aspect with monitoring; monitoring a disk full situation and correcting it quickly belongs to incident management, not to configuration management.

Once you've reached this first stage, you can go to the next level and use Ansible Automation Platform to automatically populate the desired state in your CMDB.

Let's assume you have a service portal where customers can order new services or modify and decommission them, using a service catalogue and a dialog driving them through the choices they need to make. Using the input variables grabbed through the dialog, the service portal can, using the automation controller's API, trigger a workflow to fulfil the service. One of the first steps of the workflow is then to enter those input variables as desired state (type A and B) into the CMDB. It has the advantage that, should the workflow job fail, you still have the desired state documented and could trigger the action again once the root cause for the failure has been fixed.

It would now be nice to have commit, branch and tag functions like in Git to roll-back such changes easily. But perhaps someone will invent a CMDB with such functionality based on this article. In the meantime, connect Ansible Automation Platform to your CMDB and add value and quality to your CMDB with automation.

Learn more about using Ansible Automation Platform for configuration management

Take a video tour

This eight-minute overview video highlights the components and features found in the latest version of Ansible Automation Platform---and how they come together to deliver a comprehensive enterprise automation experience.

Automation content navigator releases with Ansible Automation Platform 2.2

What is it?

Automation content navigator was released alongside Red Hat Ansible Automation Platform 2.0 and changed the way content creators build and test Ansible automation. Navigator 1.0 drew together multiple Ansible command line tools like ansible-playbook, ansible-doc, ansible-config, etc. and continues to accrue seriously useful new features to help deliver greater flexibility to automation creators.

Coinciding with the release of Ansible Automation Platform 2.2, navigator 2.0 introduces improvements to existing functionality alongside additional features to aid in the development of automation content.

Within navigator 2.0, you will find:

• Automation execution environment image build support 
• Ability to interact in real-time with automation execution environments 
• Settings subcommand to view active configuration of local environment 
• Generate a sample configuration file that can be used for new projects
• Automatic mode selection (stdout vs. interactive) 
• Technology preview lint support, UI improvements, Collections view support for Ansible built-ins, time zone support, color enhancements, and more!

Looking closer

Image builder support

Before the release of navigator 2.0, a separate command line application (ansible-builder)  was needed to build execution environment images from human readable YAML files. With this release, ansible-navigator installs ansible-builder and includes a new build command that is used to pass through arguments to ansible-builder allowing content creators to create images from a single familiar interface.

Why should I care?

All enhancements to ansible-builder can be leveraged from ansible-navigator. This functionality helps to cement navigator's role within the content creators workflow to allow not only content creation and environment introspection, but also execution environment build support from within navigator.

Things to try:

• Add the arista.avd Collection to the supported execution environment:

==> ./builder/execution-environment.yml

---
version: 1
build_arg_defaults:
  EE_BASE_IMAGE: "registry.redhat.io/ansible-automation-platform-21/ee-supported-rhel8:latest"
dependencies:
  galaxy: requirements.yml
  system: ""
  python: ""

==> ./builder/requirements.yml

---
collections:
  - arista.avd

$ ansible-navigator builder build --workdir builder

Introducing the exec command

With a new subcommand, exec, automation creators now have the ability to open a shell in the default execution environment. This allows creators to further inspect the execution environment and leverage utilities installed within the execution environment without installing them on a local workstation.

For example, imagine you're creating some new workflows and you need to leverage an additional Collection from Ansible automation hub. Instead of installing the ansible-galaxy command-line tool on the local workstation, you can run a command within navigator to install the Collection in a directory alongside the new workflows. Because the current working directory is bind mounted to the running container, the installed Collection is placed on the local filesystem.

ansible-navigator exec -- ansible-galaxy collection install servicenow.itsm -p ./collections

After running the above command, a new directory called "Collections" should exist in your current working directory (CWD). This directory will be made available to the execution environment at runtime because the CWD is bind mounted at runtime. This allows you to always tell which Collections are installed within the execution environment and which have been bind mounted to the container.

Why should I care?

Navigator lowers the barrier for creating new content! A creator now only needs to install ansible-navigator to begin creating new automation. Leveraging execution environments, the content creator doesn't even need to install ansible-core! Navigator pulls in a default execution environment that contains ansible-core and common Ansible command line utilities such as ansible-galaxy. The exec command allows these to be leveraged from within the default execution environment instead of relying on workstation configuration.

Things to try:

• Encrypt a secret using a vault password file:

$ echo secret_vault_password > password_file
$ ansible-navigator exec -- ansible-vault encrypt_string --vault-password-file password_file 'secret'
!vault |
          $ANSIBLE_VAULT;1.1;AES256
          64323039613737313538666239363032396361613464393033343165663631653835356232373139

Encryption successful

• Scaffold a new Collection in the CWD, in the playbook adjacent Collection directory:

$ ansible-navigator exec -- env
ANSIBLE_CACHE_PLUGIN=jsonfile
DESCRIPTION=Red Hat Ansible Automation Platform Minimal Execution Environment
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh

Navigator settings command

The settings command surfaces the configuration of the local environment from within navigator. From the settings screen, creators are able to view default values and values changed by local configuration parameters. Leveraging this within an integrated development environment (IDE) such as VS Code is especially helpful using features like command+click to open a file path within the editor. For example, a creator is able to see that a local ansible.cfg or ansible-navigator.yml file is being sourced by navigator and can open that file within the configured editor directly from the navigator settings screen.

Why should I care?

Ansible is flexible! System-wide configuration files can be sourced for multiple automation projects. It's very helpful to the content creator to be able to view default configuration, which configuration parameters have been defined in local configuration files and which files are being sourced by the current project. All of this enhances a streamlined creator workflow that becomes more predictable for content creators.

Navigator sample settings

Imagine you are an automation content creator starting a new project. You know that this new project will:

• use a newly built execution environment
• require navigator to have reasonable configuration defaults

In addition, you know you want to customize navigator to use your preferred code editor.

Navigator sample settings allow creators to display a sample ansible-navigator.yml configuration file with all parameters commented out. This allows the creator to pick and choose which settings to adjust for the new project. Things like default execution environment image name, image pull policy, which code editor to use when opening files from navigator, etc. are all configured from ansible-navigator.yml. Additionally, this sample settings file can be written to the local filesystem where, once edited for the new project, can be sourced by navigator.

$ ansible-navigator settings --sample > my.yaml

Why should I care?

Multiple automation projects usually mean multiple execution environments that need to be defined as the default execution environment for the corresponding project. By allowing settings files to be created from navigator, creators do not need to rely on memory to define the parameters necessary to customize and deploy their projects.

Things to try:

• Use the TUI to review the current settings:

$ ansible-navigator settings

• Review the effective setting for ansible-navigator:

$ ansible-navigator settings --effective

• Show the source for each of the current settings:

$ ansible-navigator settings --sources

Automatic mode selection

Navigator consists of a textual user interface (TUI) that operates in interactive mode by default. In interactive mode, creators run commands and navigate the interface by using a series of keystrokes. Navigator 1.0 supported standard out mode for some commands. This means that instead of opening up the full interactive user interface, creators could run commands and query information about the local environment without opening up the TUI. Standard out mode is helpful, for instance, in CI/CD pipelines where there is no need to run commands interactively.

With navigator 2.0, more commands are supported in standard out mode. For example, the collections subcommand can now run in standard out mode and interactive mode. It's very useful to automation creators to see which Collections are available in the environment to figure out which modules can be leveraged in automated workflows.

Additionally, navigator now supports automatic mode selection for commands that are only offered in a single mode. Previously the --mode command line argument was necessary for commands that only supported mode stdout.

Why should I care?

Navigator is easily adapted to individual creators' workflows and preferences. Even more, by adding standard out support for more commands, navigator can now be utilized in automated build environments.

Things to try:

• Show the help for the ansible-playbook command without specifying --mode stodut

$ ansible-navigator run --help-playbook

• Show the help for the ansible-builder command:

$ ansible-navigator builder --help-builder

Lint functionality (technology preview)

One very nice use of interactive mode is in the newly added and experimental feature for linting Ansible content. The lint subcommand, when coupled with a path to an Ansible Playbook or directory of Ansible content, opens a new screen in navigator where problems and suggestions are displayed for the file(s) passed into the lint command. As the problem files are corrected and saved, the list of problems and suggestions shrinks. Coupled with a code editor's ability to control+click to open a file path, editing files with potential issues is quick and fits in well with the rest of the creator experience.

Why should I care?

Consistent content produces reliable automation. Lint support allows creators the ability to ensure that the content produced adheres to best practices.

Things to try:

• Lint a playbook using the latest creator execution environment

$ ansible-navigator lint site.yaml --eei quay.io/ansible/creator-ee:latest

What now?

Automation content navigator 2.0 is available for use today! Navigator offers improvements to the authoring and testing experience. As a result, automation content creators have more tools on hand to assist in the creation and maintenance of automated workflows.