Ansible is a powerful configuration management system that can be used to manage settings of remote hosts using SSH. It’s primarily used for system automation tasks such as software installation, system updates, and application deployments.

In Ansible, you can perform tasks using either a single command (Ansible command) or an organized sequence of tasks (Ansible Playbook). These two methods offer different levels of control and complexity. Let’s dive in and understand each one of them.

Ansible Command

The Ansible command is a single command that you use to perform a quick task on a remote host. For example, if you wanted to check the uptime of a remote server, you might use an Ansible command like this:

ansible -m command -a 'uptime' server-hostname

In this command:

  • -m command: Specifies the module to use. In this case, we are using the command module which is used to run any command on the remote host.
  • -a 'uptime': Specifies the arguments to the module. In this case, the argument is uptime, which is the command to be run on the remote host.
  • server-hostname: This is the inventory hostname of the remote host where the command will be run.

The advantage of using Ansible commands is that they are quick and easy to use. They are excellent for performing simple tasks on a remote host. However, for complex tasks involving multiple steps, or for managing larger environments, Ansible Playbooks are the preferred method.

Examples

# Query many servers, change the site or server type, or just all servers on that site.
ansible -i inventories/new-york-site/staging game-servers -m shell "lsb_release -a"

# Query what kernel and version of ubuntu is running
ansible -i inventories/singapore/prod all -m shell -a 'echo "$(lsb_release -drc)\nKernel: $(uname -r)\n $(hostname)" | tr "\n" " "' | grep -v CHANGED

# Remove old docker containers that have exited
ansible -i inventories/sto/docker all --extra-vars @~/.ansible/tk-vault.yml -m shell -a "docker rm `docker ps -a -f status=exited -q`"

# Install something on a machines
ansible -i myinventory.yml server1 -b -m apt -a "pkg=iptables-persistent state=present"

Ansible Playbook

Ansible Playbooks offer a more sophisticated way to manage remote hosts. A Playbook is a YAML file that contains a list of tasks to be performed on the remote hosts. These tasks can be conditional, meaning they can be performed based on the result of previous tasks. Playbooks can also use variables, templates, and include other playbooks, making them a powerful tool for system configuration management.

Here is a simple example of an Ansible Playbook:

---
- hosts: web-servers
  tasks:
    - name: Ensure Apache is at the latest version
      ansible.builtin.yum:
        name: httpd
        state: latest
    - name: Write the Apache config file
      ansible.builtin.template:
        src: /srv/httpd.j2
        dest: /etc/httpd.conf
    - name: Ensure Apache is running
      ansible.builtin.service:
        name: httpd
        state: started

This Playbook is used to ensure Apache is installed, configured, and running on all web servers.

Playbooks are the heart of Ansible and provide a repeatable, re-usable, simple configuration management and multi-machine deployment system.

Common Directory Structure

In a typical Ansible setup, you’ll often see the following directory structure:

inventories/
   production/              # inventory file for production servers
    group_vars/             # here we assign variables to particular groups, its for variables shared by many servers
      all.yml
      webservers.yml
      database-servers.yml
   staging/                 # inventory file for staging environment
    host_vars/              # here we assign variables to particular servers.
      webserver1.yml        # these inventory variables will override variables in group_vars
      webserver2/           # the folder name has to match the server name.
        mysql.yml           # uniq settings about mysql for webserver 2
        grafana.yml
        something.yml
playbooks/
  site.yml                # master playbook
  webservers.yml          # playbook for webserver tier
  dbservers.yml           # playbook for dbserver tier

roles/
    common/             # this hierarchy represents a "role"
        tasks/          #
            main.yml    # tasks file can include smaller files if warranted
        handlers/       #
            main.yml    # handlers file
        templates/      # files for use with the template resource
            ntp.conf.j2  #
        files/          #
            bar.txt     # files for use with the copy resource
            foo.sh      #
        vars/           #
            main.yml    # variables associated with this role
        defaults/       #
            main.yml    # default lower priority variables for this role
        meta/           #
            main.yml    # role dependencies

This is one of many directory structures for a manageable Ansible setup. However, based on your organization and specific use-cases, you might have a different structure.

In conclusion, both Ansible command and Ansible Playbook are powerful tools for managing remote systems. Choose the right one based on your use case. While the Ansible command is perfect for quick and easy tasks, Playbooks offer a more powerful, flexible solution for complex tasks and larger environments. And understanding the common directory structure of Ansible is key to organizing your infrastructure code in a more manageable way.


Buy Me a Coffee