This content is part of the Essential Guide: Explore Ansible for DevOps configuration management

Essential Guide

Browse Sections
Tip

Agentless Ansible structure opens up configuration management potential

Ansible is easy to use for IT ops pros, and it supports multicloud functionality within its automation structure. This simple walkthrough gets sys admins started with the tool.

Ansible is among the easiest configuration management tools to use. The Ansible structure is agentless, and configurations are set up as playbooks written in YAML.

Ansible uses Secure Socket Shell (SSH) rather than agents, which are the structural connections for many other configuration management tools. To start with Ansible basics, the administrator creates a user account on the management node and managed nodes, then generates an SSH key pair for that account from the management node. The user pushes this SSH key pair to the managed nodes and then is ready to control configurations from a central machine.

The Ansible structure for configuration commands

Ansible defines the work applied to the managed nodes in the IT environment via sets of instructions called playbooks. A playbook runs tasks on the nodes. Modules provide the tasks in the Ansible structure for configuration management. The module adds an abstraction layer to ensure that Ansible executes specific tasks in the same way on different nodes.

An example will clarify what a module does in Ansible's structure. In this example, the user wants to know that a line is added to a configuration file. From a Linux command line, the administrator would use a construction like echo hello >> sometextfile. However, Ansible works with multiple OSes, so this approach won't work. Instead, the copy module, which copies a file on the local system to remote ones, ensures that Ansible makes any required modification to the text file -- no matter which OS it configures. Ansible offers hundreds of modules by default, and users can write their own.

Setting up an Ansible playbook isn't hard, but there is a challenge. Ansible users write playbooks in YAML. YAML is sensitive to syntax errors, which are easy to make, because the language requires space indents for the items in a file.

Listing 1: A short example of an Ansible playbook demonstrates the YAML format.

[student@workstation dev-vars-facts]$ cat playbook.yml

---

- name: Install fileserver packages

  hosts: fileservers

  tasks:

    - name: Includes the variable

      include_vars: package.yml

    - name: Installs the package

      include: install_package.yml

The Ansible playbook shown in Listing 1 refers to several locations where external items are defined. The hosts definition comes from the inventory file. The task is defined, which also requires some external files. The package.yml file contains a list of variables, while the install_package.yml file contains a definition of the packages to be installed.

Red Hat purchased the company behind Ansible in 2015 and has integrated it into many of its products. For example, Ceph storage previously used a complicated deployment that involved many commands and edits in several configuration files on several servers. In the Ansible structure, an administrator enters the required parameters in one central configuration file that pushes to all nodes involved.

Include files make it easier to maintain the configuration across multiple scenarios. For a simple task definition as in this playbook, there is no need to work with many include files. Enterprises deploying Ansible across a heterogeneous IT estate will find include files are an essential part of the configuration management tool's structure.

Listing 2: This playbook does not have any dependencies except for the host definitions and is ready to run its configured tasks.

[student@workstation imp-playbook]$ cat ftpserver.yml 

---

- name: ftp server installed

  hosts: servera.example.com

  remote_user: devops

  become: yes

  become_method: sudo

  become_user: root

  tasks:

  - block:

    - name: latest vsftpd version installed

      yum:

        name: vsftpd

        state: latest

    - name: latest firewalld version installed

      yum:

        name: firewalld

        state: latest

  - block:

    - name: firewalld permits ftp service

      firewalld:

        service: ftp

        permanent: true

        state: enabled

        immediate: yes

  - block:

    - name: vsftpd enabled and running

      service: 

        name: vsftpd

        enabled: true

        state: started

    - name: firewalld enabled and running

      service:

        name: firewalld

        enabled: true

        state: started

...

The playbook in Listing 2 has three blocks of code. In the first block, the vsftpd and firewalld services are installed. The next block writes configuration to firewalld to have it allow for incoming FTP traffic. The last block of YAML code in this Ansible playbook starts both services.

Once Ansible generates the playbook, use the ansible-playbook command followed by the name of the playbook. The instructions in the playbook will do everything else.

Up in the Ansible Tower

For larger enterprise IT environments, the Ansible command-line management falls short. Red Hat sells a more integrated console as Ansible Tower. The product combines a dashboard and graphical inventory system with role-based access control, scheduling and a notifications service. Ansible Tower makes it easier to manage a wide spectrum of settings and has a web-based interface from which administrators can check the current state of technology stacks.

Next Steps

Use this guide to choose the right configuration management tool

Configuration isn't just important -- it's mandatory

Be sure your configuration management tool is multicloud-compatible

Dig Deeper on Systems automation and orchestration

Software Quality
App Architecture
Cloud Computing
SearchAWS
TheServerSide.com
Data Center
Close