Ansible is a powerful automation tool that allows you to manage and configure systems, including version control systems like Git. In this tutorial, we will explore the basics of managing Git repositories using Ansible. We’ll cover the essentials of the Ansible inventory file, introduce the concept of playbooks, and provide an example playbook for cloning a Git repository and running a WildFly Bootable JAR application.
Prerequisites
Make sure you have Ansible installed on your control machine. You can follow the installation instructions on the Ansible official website.
Ansible Inventory File
The Ansible inventory file is a simple text file that contains a list of hosts that Ansible will manage. It is often located at /etc/ansible/hosts by default. The inventory file can also be specified using the -i option when running Ansible commands. Below is an example inventory file:
[git_servers] server1 ansible_host=192.168.1.100 ansible_user=myuser server2 ansible_host=192.168.1.101 ansible_user=myuser
[git_servers]is a group name.server1andserver2are hostnames or IP addresses.ansible_hostspecifies the target host’s IP address or hostname.ansible_userspecifies the user Ansible should use to connect to the target hosts.
For testing purposes, however, we will be using localhost as entry for your Inventory File. This way, all tasks will run on your machine:
[local] localhost ansible_connection=local
Ansible Playbooks
Ansible playbooks are YAML files that define a set of tasks to be executed on remote hosts. Each playbook consists of one or more plays, and each play contains a list of tasks. A task is a single unit of work, such as installing a package or copying a file.
Example Playbook: Cloning a Git Repository
Let’s create a simple Ansible playbook that clones WildFly Bootable Jar Git repository and run one of the examples in the repository. If you are new to WildFly Bootable Jar the following article discuss it more in detail: Turn your WildFly application in a Bootable JAR Create a file named playbook.yml with the following content:
---
- name: WildFly JAX-RS Example Deployment
hosts: localhost
gather_facts: true
vars:
destination_dir: "{{ lookup('env','HOME') }}/output"
git_tag: "10.0.0.Final"
tasks:
- name: Check if WildFly JAR Maven Plugin directory exists
stat:
path: "{{ destination_dir }}/wildfly-jar-maven-plugin"
register: plugin_directory_exists
- name: Clone WildFly JAR Maven Plugin Git Repository
git:
repo: [email protected]:wildfly-extras/wildfly-jar-maven-plugin.git
dest: "{{ destination_dir }}/wildfly-jar-maven-plugin"
version: "{{ git_tag }}"
when: not plugin_directory_exists.stat.exists
- name: Move to examples/jaxrs directory
command: cd "{{ destination_dir }}/wildfly-jar-maven-plugin/examples/jaxrs"
args:
chdir: "{{ destination_dir }}/wildfly-jar-maven-plugin/examples/jaxrs"
- name: Run Maven Install and WildFly JAR Plugin
command: mvn install wildfly-jar:run
args:
chdir: "{{ destination_dir }}/wildfly-jar-maven-plugin/examples/jaxrs"
The Playbook contains both a configuration section and a Task section. Let’s see them both:
The Playbook Configuration
Firstly, here, the hosts: localhost line indicates that the playbook is intended to run on the local machine (localhost). The inventory file is not explicitly consulted to determine the target hosts in this case, as the target host is implicitly set to the local machine.
Then vars defines variables of the playbook:
destination_dir: Variable storing the destination directory for cloning the Git repository. Defaults to the user’s home directory ($HOME/output).git_tag: Variable storing the Git tag or branch name to be checked out. Defaults to “10.0.0.Final”.
The Task Configuration
stat task: Uses the stat module to check if the specified directory ({{ destination_dir }}/wildfly-jar-maven-plugin) exists. The result is registered in the variable plugin_directory_exists.
git task: Clones the WildFly JAR Maven Plugin Git repository into the specified destination directory. It uses the built-in Git module setting the attributes repo, dest and version. The task is conditional (when) and only runs if the directory doesn’t exist (not plugin_directory_exists.stat.exists).
Finally, we execute two command line tasks: at first we move the specified directory using the cd command. The args section ensures the change of the working directory (chdir) to the specified path. Then, we execute the Maven command to install dependencies and run the WildFly JAR plugin. The working directory is set to the specified path.
You can run the playbook as follows:
ansible-playbook -i inventory playbook.yml
Verify that all Tasks are ok:
PLAY [WildFly JAX-RS Example Deployment] ******************************************************* TASK [Gathering Facts] ************************************************************************* ok: [localhost] TASK [Check if WildFly JAR Maven Plugin directory exists] ************************************** ok: [localhost] TASK [Clone WildFly JAR Maven Plugin Git Repository] ******************************************* changed: [localhost] TASK [Move to examples/jaxrs directory] ******************************************************** changed: [localhost] TASK [Run Maven Install and WildFly JAR Plugin] ************************************************
Finally, reach out the example Bootable Jar application which returns an Hello World message from the “hello” Endpoint:
Conclusion
This tutorial introduced the basics of managing Git repositories with Ansible. We covered the Ansible inventory file, playbook structure, and provided an example playbook for cloning a Git repository. Ansible’s flexibility and simplicity make it a valuable tool for automating Git-related tasks across multiple servers. Explore Ansible’s extensive documentation for more advanced use cases and features.
Source code for this tutorial: https://github.com/fmarchioni/mastertheboss/tree/master/ansible/bootable-jar