Deploying with Ansible and AWS S3

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.