Sync Files Between Linux Servers with Ansible

Keeping files synchronized between Linux servers is a common task. You may want to copy application configuration, NGINX settings, SSL certificates, or other files from one server to another to make both look identical.

Ansible provides several ways to copy files, but for server-to-server synchronization, ansible.posix.synchronize is usually the best choice. It uses rsync, so only changed files are transferred, making it much faster than copying everything every time.

The playbook performs four steps:

  • Check whether the target server already has an SSH key.
  • Upload the SSH key if it is missing.
  • Allow the target server to connect to the source server.
  • Synchronize the required directories or files.

Prerequisites: network connection between servers, configured sudoers , generated a pair of ssh keys, defined variables used in the playbook

Step 1 – Check whether an SSH key already exists

Before uploading a key, the playbook checks whether one is already present.

- name: Check if id_rsa key already exists (target)
ansible.builtin.stat:
path: ~/.ssh/id_rsa
register: id_rsa
become: true
become_user: "{{ target_host_user }}"
when: ('target_host' in inventory_hostname)

The important parts are:

  • register: id_rsa stores the result of the stat module so later tasks can check whether the file exists.
  • become_user: "{{ target_host_user }}" runs the task as the application user instead of root. This checks the correct home directory.
  • when ensures this task runs only on the target server.

Step 2 – Upload the SSH key

If the key does not exist, create the .ssh directory and upload both the private and public keys.

- name: Set target ssh
when: ('target_host' in inventory_hostname) and (not id_rsa.stat.exists)
become: true
become_user: "{{ target_host_user }}"
block:
- name: Set target ssh | Create directories for ssh (target)
ansible.builtin.file:
path: "{{ item }}"
state: directory
owner: "{{ target_host_user }}"
group: "{{ target_host_user }}"
mode: "0700"
loop:
- ~/.ssh
- name: Set target ssh | Upload keys to ssh dir
no_log: true
ansible.builtin.copy:
dest: "~/.ssh/{{ item.file }}"
content: "{{ item.content }}"
mode: "{{ item.mode }}"
loop:
- { file: "id_rsa", content: "{{ target_host_private_key }}", mode: "0600" }
- { file: "id_rsa.pub", content: "{{ target_host_public_key }}", mode: "0644" }

The interesting options are:

  • block groups related tasks under a single when condition.
  • no_log: true prevents the private SSH key from appearing in the Ansible output or logs.
  • loop allows us to interact with multiple files in just a one task
  • The task only runs when id_rsa.stat.exists is false, making the playbook idempotent.

Step 3 – Allow the target server to connect

The source server must trust the target server’s SSH key.

- name: Add target public key to source host
ansible.posix.authorized_key:
user: "{{ source_host_user }}"
key: "{{ target_host_ssh_public_key }}"
state: present
register: auth_key
when: ('source_host' in inventory_hostname)

The authorized_key module adds the target server’s public key to the source server’s authorized_keys file. After this, the target server can connect over SSH without a password.

Step 4 – Synchronize the files

Finally, synchronize the required directories.

- name: Synchronize source and target files (target)
ansible.posix.synchronize:
src: "{{ source_host_user }}@{{ source_host }}:{{ item.src }}"
dest: "{{ item.dest }}"
mode: pull
rsync_path: sudo rsync
rsync_opts:
- "-e 'ssh -i /home/{{ target_host_user }}/.ssh/id_rsa'"
- "--mkpath"
- "--delete"
loop:
- { src: "/etc/nginx/", dest: "/etc/nginx/" }
- { src: "{{ app_dir }}/config/", dest: "{{ app_dir }}/config/" }
- { src: "/home/{{ app_user }}/.somefile", dest: "/home/{{ app_user }}/" }
delegate_to: "{{ inventory_hostname }}"
register: rsync_result
failed_when: rsync_result.rc not in [0, 23]
become: true
when: ('target_host' in inventory_hostname) and (auth_key is defined)

A few options are worth explaining:

  • mode: pull means the target server connects to the source server and downloads the files.
  • src: "{{ source_host_user }}@{{ source_host }}:{{ item.src }}" tells rsync to read the files directly from the remote server over SSH.
  • rsync_path: sudo rsync runs rsync with sudo on the source server, allowing access to protected directories such as /etc/nginx.
  • -e 'ssh -i ...' tells rsync which SSH private key to use.
  • --mkpath creates the destination directory if it does not already exist.
  • --delete removes files that no longer exist on the source server, keeping both servers synchronized.
  • delegate_to: "{{ inventory_hostname }}" makes sure the synchronization runs on the target server. Since we use mode: pull, the target server is responsible for opening the SSH connection.
  • failed_when: rsync_result.rc not in [0, 23] ignores rsync exit code 23, which commonly indicates that a source file or directory does not exist. Depending on your environment, this may be expected and should not fail the playbook.

Push vs Pull

The synchronize module supports two synchronization modes.

  • Push (mode: push) – the source server connects to the destination server and sends the files
  • Pull (mode: pull) – the destination server connects to the source server and downloads the files.

This example uses pull mode because the target server initiates the SSH connection. This is often preferred when the source server should not connect to other machines.

Other ways to copy files

The synchronize module is not the only option.

  • copy – Copies files from the Ansible control node to managed hosts. Best for small files or configuration files.
  • template – Similar to copy, but processes Jinja2 templates before copying.
  • fetch – Copies files from managed hosts back to the Ansible control node.
  • command or shell – Runs rsync directly if you need options that are not supported by the synchronize module.

I hope the post was useful.

Cheers.

Technical Review: Learn PowerShell in a Month of Lunches, Fourth Edition

Let me continue with a series of blog posts discussing technical reviews conducted between 2022 and the present year. In a previous post, I highlighted “Learn PowerShell in a Month of Lunches” as the ideal starting point for anyone delving into PowerShell.

If you’ve never read any book from the “Learn <Something> in a Month of Lunches” series, these books are unique because each chapter contains clear explanations, examples, and practical lab tasks at the end to reinforce the chapter’s topic. Such books are designed to streamline your learning process. As evident from the table of contents, there are approximately 30 chapters or fewer. By dedicating just one day to each chapter, you can master the technology in just one month.

Having reviewed this book myself, I found it immensely valuable. The authors, PowerShell team members Travis Plunk and Tyler Leonhardt, alongside Microsoft MVP James Petty, have updated the third edition to encompass the latest version of PowerShell, which includes its expansion into multiple platforms such as Linux and macOS. Consequently, the book is no longer confined to Windows.

Let’s examine the table of contents to see what you’ll be able to accomplish with PowerShell after reading the book.

:: Table of Contents ::

1 Before you begin
2 Meet PowerShell
3 Using the help system
4 Running commands
5 Working with providers
6 The pipeline: Connecting commands
7 Adding commands
8 Objects: Data by another name
9 A practical interlude
10 The pipeline, deeper
11 Formatting: And why it’s done on the right
12 Filtering and comparisons
13 Remote control: One-to-one and one-to-many
14 Multitasking with background jobs
15 Working with many objects, one at a time
16 Variables: A place to store your stuff
17 Input and output
18 Sessions: Remote control with less work
19 You call this scripting?
20 Improving your parameterized script
21 Using regular expressions to parse text files
22 Using someone else’s script
23 Adding logic and loops
24 Handling errors
25 Debugging techniques
26 Tips, tricks, and techniques
27 Never the end
App. PowerShell cheat sheet

Is this book for you? If you’re an Administrator, DevOps Engineer, or even a developer, you’ll undoubtedly find the book extremely useful and easy to follow. It covers topics such as handling errors, loops, filtering and comparison, input and output, and much more. After reading at least two editions myself, I highly recommend this book as one of my favorites, given its well-structured content (chapter-labs-summary). Rating 10/10.