The delegate_to parameter configures Ansible to run a task on a specific managed node (e.g. target system) For example, let's examine using the shell module to ping. By default, Ansible uses SSH to connect to the managed nodes.

With this default configuration, if you were to run the following playbook, an SSH connection would be made to each managed node, and then each managed node would ping itself. That's probably not what you want.

---
- hosts: all
  gather_facts: false
  tasks:
    - name: ping command
      shell: "ping -c4 {{ inventory_hostname }} "

The delegate_to option can be used to tell Ansible to invoke the shell ping command on the localhost (that's the control node, the Ansible server).

---
- hosts: all
  gather_facts: false
  tasks:
    - name: ping command
      shell: "ping -c4 {{ inventory_hostname }}"
      delegate_to: localhost

In this scenario, instead of using SSH, an ICMP echo would be sent from the control node to each managed node, since ping uses ICMP.

Running this playbook will return something like this. Notice that the ping task contains -> localhost, meaning that the task was run on the control node.

PLAY [all]

TASK [Gathering Facts]
ok: [server1.example.com]
ok: [server2.example.com]
ok: [server3.example.com]
ok: [server4.example.com]
ok: [server5.example.com]

TASK [ping]
ok: [server1.example.com -> localhost]
ok: [server2.example.com -> localhost]
ok: [server3.example.com -> localhost]
ok: [server4.example.com -> localhost]
ok: [server5.example.com -> localhost]

PLAY RECAP
server1.example.com   : ok=2  changed=0  unreachable=0  failed=0
server2.example.com   : ok=2  changed=0  unreachable=0  failed=0
server3.example.com   : ok=2  changed=0  unreachable=0  failed=0
server4.example.com   : ok=2  changed=0  unreachable=0  failed=0
server5.example.com   : ok=2  changed=0  unreachable=0  failed=0

Similarly, the connection module can be used to perform tasks on the control node.