Agent and Agentless Orchestration Tools

What it is

Orchestration and configuration management tools apply the same settings to many devices, and they differ in whether software must be installed on each device.

An agent based tool needs a small program, the agent, running on every managed device.

An agentless tool needs nothing extra on the device. It connects using a method that the device already has, such as SSH or an API. This choice affects what the tool can manage, how it scales and how much work it adds.

How it works

The tools differ in the connection method, the direction of the work and the language.

Agentless tools

An agentless tool logs in to a device and does the work from the outside.

Ansible is the best known. It runs from a control node, and it connects to network devices over SSH, or with NETCONF or an API.

Instructions are written in YAML files called playbooks, and devices are listed in an inventory. Ansible uses a push model, so you run it and it pushes the change out.

---
- name: Configure NTP on switches
  hosts: switches
  gather_facts: false
  tasks:
    - name: Set the NTP server
      cisco.ios.ios_config:
        lines:
          - ntp server 192.0.2.10

The playbook picks the group switches from the inventory. It runs one task that uses a module for IOS to make sure the line is present. Each module knows how to talk to one kind of device.

Terraform is another agentless tool, built for provisioning. You describe the resources that you want in a declarative language, and the tool uses provider plugins and APIs to create them. It is used a lot for cloud and for controllers.

Agent based tools

An agent based tool installs an agent on the managed system. The agent contacts a central server on a schedule, and asks for its configuration.

Puppet uses a server, called the Puppet master or Puppet Server depending on the release, and an agent on each node. The agent checks in with the server at a regular interval, which is every 30 minutes by default unless it is changed, and applies the settings that the server holds. Puppet code is written in its own declarative language, in files called manifests.

Chef also uses a server and a client on each node. Its instructions are called recipes, and they are grouped into cookbooks. They are written in Ruby.

SaltStack uses a master and agents called minions, and it can also run without agents over SSH. It uses YAML for its state files.

Puppet and Chef are pull based, because the agents ask for their configuration. Agent based tools suit servers where an agent can be installed. Many network devices do not run a general purpose agent, so these tools are used less on switches and routers, except on platforms that offer a place to run one.

Push and pull

A push tool acts when you run it. A pull tool keeps checking, and so it corrects drift without anyone starting a run. Drift is when a device moves away from the intended configuration.

Comparing the tools

Declarative and idempotent

Most of these tools are declarative. You describe the end state you want, such as the NTP server being present, and the tool works out the steps. The opposite, an imperative or procedural style, lists the steps.

A good tool is idempotent. Running it again does not change a device that already matches the target.

If the NTP line is present, nothing happens. This makes it safe to run the same playbook many times.

Choosing between them

For switches and routers, agentless tools are the usual choice, because the devices already offer SSH, NETCONF or REST APIs.