Deploying with Ansible and AWS S3

Ansible is an excellent tool for automating the management and deployment of Maverics Orchestrator. Use this guide as the basis for your own Ansible code or as a guideline for a simple deployment pattern with other DevOps automation software.
Here we will use Ansible and an AWS S3 bucket as the artifact repository. This approach can be use for deployments initiated by an administrator or configured to run automatically as part of a CI/CD pipeline.

Assumptions & Prerequisites

  • Ansible is installed on a controller machine (e.g a local laptop or a dedicated server in a data center).
  • An Amazon S3 bucket is available to the controller machine and target hosts with Maverics Orchestrator versions in it.
  • Communication between the target host and the controller machine has already been established.
  • The target host is a supported Linux OS - RHEL/CentOS 7 or above.
  • In this guide we use a customer called ‘ExampleCo’, which is configurable.

Ansible Directory Structure

Use the directory structure recommended in the Ansible documentation.

Maverics Deployment

Initiate the deployment using a playbook pointing to a single role (e.g. example-cd):
- name: ExampleCo Installation
hosts: tag_Role_ExampleCo
- example-cd
The example-cd role contains two subdirectories
user1@controller-dev ~/code/ansible/roles/example-cd
> $ ls -l
drwxr-xr-x 5 user1 staff 160 Aug 30 13:55 tasks
drwxr-xr-x 3 user1 staff 96 Aug 30 14:13 vars


We use three different task files in the task directory that are driven from main.yaml:
- name: Include a play after another play
include: rpm-deploy.yml
- name: Include the configuration
include: config.yml
when: deploy_config == 'True'


This Ansible task pulls the deployment artifact from S3. We use S3 as it provides versioning to store our deployment artifacts. Pass the version which you want to deploy using the vars/main.yml file. The rpm-deploy.yml file will looks something like:
- name: Simple GET operation
bucket: strata-demo-distribution
object: /maverics/releases/{{ item }}/maverics.{{ item }}.x86_64.rpm
dest: /tmp/maverics.{{ item }}.x86_64.rpm
mode: get
- "{{ install_maverics }}"
- name: Make the maverics RPM executable
become: yes
path: /tmp/maverics.{{ item }}.x86_64.rpm
owner: centos
group: centos
mode: 0744
- "{{ install_maverics }}"
- name: Installing the maverics RPM
become: yes
name: /tmp/maverics.{{ item }}.x86_64.rpm
state: present
disable_gpg_check: yes
register: yum_output
- "{{ install_maverics }}"


Use a separate config.yml file since it does not need to be deployed after every instance of Maverics Orchestrator. The deploy_config flag in vars(main.yml) will govern if file is deployed.
Since S3 is used to store the config file, you can reference S3 versioning to roll back to a previous verison of the file.
- name: GET an object but don't download if the file checksums match.
bucket: maverics-config
object: /configs/maverics.yaml
dest: /tmp/maverics.yaml
# version: Q.rNd9.E8VDujhfOcFsKjfLOqHLPwgL5
mode: get
overwrite: different
- name: Copy a new file into place, backing up the original if it differs from the copied version
become: yes
src: /tmp/maverics.yaml
dest: /etc/maverics/maverics.yaml
remote_src: yes
owner: maverics
group: maverics
mode: '0777'
backup: yes
- name: Remove file (delete file)
path: /tmp/maverics.yaml
state: absent

Running the playbook

Set the desired version of Maverics Orchestrator in vars/main.yaml and define whether a new configuration is deployed with a new Orchestrator version or not.
install_maverics: v0.6.6
deploy_config: 'True'

Deployment rollback

To roll back a deployment, simply change the maverics version to the desired version and re-run the playbook. Note the version must be present in the S3 bucket as an object.