AKA ansible_rclone and formerly rclone
An Ansible role to install rclone directly from upstream.
- Clone this repo into your local roles-directory or install via
ansible-galaxy install stefangweichinger.ansible_rclone - Add role to the hosts you want
rcloneinstalled to. - Run
ansible...
Please note that this role installs rclone from the upstream repository and not from the OS repositories!
And feel free to rate the role on Ansible Galaxy to improve its "Community Score ". You're welcome!
The build tests use the galaxy-action molecule action and run on a selected set of distros:
- Debian 9,10,11,12
- Fedora 34,35,36. Fedora 37 and 38 work as well but aren't actively tested because of issues with the related docker-images.
- Ubuntu 1804,2004,2204
- Ubuntu-derived distros: Linux Mint, Pop!_OS
Some older releases also work with this role, but I decided to remove some of them from galaxy_info.
PRs welcome, but we can't test on every platform.
In early 2022 I removed the tests for CentOS as it is not receiving upstream packages anymore. The role should still work, though.
Available variables are listed below, along with default values (see defaults/main.yml):
This can be used to toggle the installation of manpages.
This variable chooses the target architecture (for example 'amd64').
The version of rclone to install. rclone_version can be set to a specific version number.
Make sure you add the last number as well: "1.56" won't work, "1.56.0" will do (check upstream repo for available releases).
rclone_version: "1.56.0"
Can be set to "stable", or "beta" to install the latest beta version.
rclone_release: "beta"
The location to install the rclone config file to if you provide rclone_configs
These variables allow for setting the ownership of the directory and config file for rclone. They are mostly needed if configuring rclone to run as an other user than root (maybe a specific backup user or so).
rclone_config_owner:
OWNER: rclone
GROUP: rclone
This variable allows for predefined remote configs to be loaded. rclone_configs must be a YAML list with a name variable and a properties variable which is another list of arbitrary key value pairs. See the example below which would configure a Google Drive remote:
rclone_configs:
- name: ExampleGoogleDriveRemote
properties:
type: drive
client_id: 12345
client_secret: 67890
token: ' {"access_token":"","token_type":"","refresh_token":"","expiry":""}'
Note that the space after the single quote ' for token is intentional in order to force this into a string. Otherwise, it will be interpreted as an object and have its double quotes be converted to single quotes within the config file which rclone cannot parse correctly.
The rclone_configs variable is used to recreate the rclone.conf file. This config file stores the rclone remotes that have been defined and are usable. This is an alternative to simply copying a stored rclone.conf file directly.
The rclone_configs simply takes a list of YAML objects which must have a name which will map to the name of the remote, and a properties which can be any key, value pairs which will map to the variables stored under that remote. These should be the ones expected by the rclone.conf file for the remote type you're configuring.
For example, to recreate a standard encrypted Google Drive mount setup, the rclone.conf will look similar to below, assuming you have your encypted files stored in the "media" folder on Google Drive:
[google-drive]
type = drive
client_id = <CLIENT_ID>
client_secret = <CLIENT_SECRET>
token = {"access_token":"<ACCESS_TOKEN>","token_type":"Bearer","refresh_token":"<REFRESH_TOKEN>","expiry":"<DATETIME>"}
root_folder_id = <ROOT_FOLDER_ID>
[encrypted-media]
type = crypt
remote = google-drive:media
filename_encryption = standard
password = <PASSWORD>
password2 = <PASSWORD2>
To enable the role to recreate that config file, you can provide an rclone_configs variable as follows.
Note that this should always be encrypted if stored publicly as it gives access to your remotes:
rclone_configs:
- name: google-drive
properties:
type: drive
client_id: <CLIENT_ID>
client_secret: <CLIENT_SECRET>
token: ' {"access_token":"<ACCESS_TOKEN>","token_type":"Bearer","refresh_token":"<REFRESH_TOKEN>","expiry":"<DATETIME>"}'
root_folder_id = <ROOT_FOLDER_ID>
- name: encrypted-media
properties:
type: crypt
remote: google-drive:media
filename_encryption: standard
password: <PASSWORD>
password2: <PASSWORD2>
The task to create/update rclone.conf registers a variable named setup_rclone_config. The attributes of the variable are that of the ansible.builtin.template module (e.g. setup_rclone_config.dest, setup_rclone_config.uid, etc.) and common return values (e.g. setup_rclone_config.changed, setup_rclone_config.failed, etc.)
You can reference this variable in later tasks if you wish to perform an action when the config has been updated. For example:
- name: Install and configure rclone
ansible.builtin.include_role:
name: stefangweichinger.ansible_rclone
vars:
rclone_configs:
- name: ExampleGoogleDriveRemote
properties:
type: drive
client_id: 12345
client_secret: 67890
- name: Restart rclone
ansible.builtin.systemd:
name: rclone.service
state: restarted
when: setup_rclone_config.changedNote: This example assumes you have created the rclone.service systemd unit yourself. That action is not a function of this role.
This variable allows for the configuration of rclone mounts within your infrastructure. rclone_mounts should be a YAML list of objects, each including keys for name, remote_name, remote_path, local_path, and auto_mount. This setup enables precise control over multiple mount points, their remote sources, and whether they should be automatically mounted.
To define mounts, you'll specify each mount's details in the playbook, allowing Ansible to handle the mounting process as per your configuration. This method is advantageous for managing mounts across multiple systems or ensuring persistent mounts across reboots when combined with the auto_mount option.
The name defines the mount's identifier, used partly in naming the service. remote_name and remote_path determine the remote storage location, while local_path indicates where it mounts locally.
auto_mount controls whether the mount and corresponding service automatically activate, ensuring availability after reboots or redeployments.
When incorporating rclone_mounts into your setup, each mount point you define will correspond to a system service, facilitating management and automation.
Example configuration for mounting a directory from Backblaze B2 as a local backup directory:
rclone_mounts:
- name: my-app
remote_name: BackblazeLM
remote_path: "/my-app"
local_path: "/var/backups/my-app/"
auto_mount: trueNone.
- hosts: rclone-hosts
roles:
- rclone
Module Name Issue:
[WARNING]: - stefangweichinger.rclone was NOT installed successfully: - sorry, stefangweichinger.rclone was not found on https://galaxy.ansible.com/api/
Note that this module has undergone a name change. It was previously known as stefangweichinger.rclone, however Galaxy changed its naming methods. I am considering a change that will put move it back to this name for simplicity. Ansible Galaxy substitutes - to _ and used to strip a prefix or ansible. For more information, see the this issue.
Changed in January 2023:
We are using SemVer and CHANGELOG generation powered by Conventional Commits. Commit messages are now done using commitizen, which is run in a pre-commit command.
This is new and will maybe see more finetuning.
The tests of this ansible role use molecule. I use the GitHub Action Test Ansible roles with Molecule for these tests.
In November 2020 I switched over to running the CI pipeline within Github Actions:
https://github.com/stefangweichinger/ansible-rclone/actions
This, like this whole repo, is a work in progress.
In January 2022 I learned about tox
tox can be used for testing against various different Python versions, Ansible versions, etc.
It is run within the molecule tests now.
At first I used Travis CI, see the logs at https://travis-ci.org/github/stefangweichinger/ansible-rclone
Please consider sponsoring this project and/or rating the role on Ansible Galaxy.