Deploy a WAR Package From Nexus To AWS Using Ansible

- By Manisha Sahasrabudhe on May 21, 2018

This tutorial explains how to deploy a Java-based WAR package stored on Nexus Repository Manager to a virtual machine running on AWS EC2 using Ansible playbooks.

This document assumes you're familiar with the following concepts:

The best way to get started is to install Ansible on your local machine, and run your playbook manually. Follow the instructions in this blog to achieve this workflow.  Once you understand the mechanics of it, you should consider automating your workflow by following our documentation on Automated deployment of a JAR/WAR package from Nexus to AWS using Ansible.

 

Step-by-step instructions

Follow the steps below in order to manually deploy your JAR package.

 

Step 1: Prep your machine

  • Have your security credentials handy to authenticate to your AWS Account. Refer to the AWS Credentials documentation.

  • Execute the following commands to set up your AWS credentials as environment variables. The playbook will need these at runtime.

    export AWS_ACCESS_KEY_ID=<enter your access key>
    export AWS_SECRET_ACCESS_KEY=<enter your secret key>
  • Install Ansible based on the OS of the machine from which you plan to execute the script. Refer to the Ansible Installation guide.

 

Step 2: Prepare Ansible playbook

  • Ansible uses a folder structure that looks like this:

    • ansible.cfg holds configuration info
    • inventory has the inventory of artifacts
    • variables.yml has the variables that are used to replace wildcards in your playbooks to make them more reusable
    • war_deploy_playbook.yml is the playbook which has a list of tasks to deploy your WAR
├── ansible.cfg
├── inventory
│   ├── base
│   ├── ec2.ini
│   ├── ec2.py
│   ├── static_hosts
├── variables.yml
├── war_deploy_playbook.yml
  • It is important to note the following:
    • war_deploy_playbook.yml scripts have some wildcards, which ansible replaces with values from variables.yml.
    • Since we want to create a reusable playbook, we have not hardcoded values in variables.yml but left it up to the user to replace these when needed. This will be done in a later step, just before running the playbook.
  • In ansible.cfg, replace ${PEM_CD_WAR_VM_KEYPATH} with the path to the PEM key that has access to SSH into your EC2 machine.

  • In variables.yml, replace these wildcards with your desired values: ${AWS_REGION} ${repository_url} ${group_id} ${artifact_id} ${artifact_version} ${artifact_extension} ${artifact_filename} ${artifact_dest}.

 

Step 3: Run your playbook!

  • Execute the following command to run the ansible playbook from the directory that contains the playbook.

ansible-playbook -v war_deploy_playbook.yml
  • Verify on the EC2 machine that the correct WAR file was copied to ${artifact_dest}.

  • You can also run shell scripts that will execute after deployment by changing the last task in war_deploy_playbook.yml or adding a new shell task.

    - name: Test copy action
      shell: "ls "

 

Challenges with manual execution of Ansible playbooks

There are a few challenges with manual execution of Ansible playbooks:

  • Ansible playbook templates can be reused since they have wildcards. However, you need a programmatic way to replace wildcards at runtime. Creating static variables files is an option, but reduces reusability.
  • Automating provisioning for different environments and creating a dependency tree of all applications that are deployed into that environment is tedious to achieve with manual steps. You need an automated workflow to effectively transfer information like subnet_id, security_group_id to downstream activities. for e.g. EC2 provisioners.
  • Security with RBAC is a problem. The machine used to provision is authenticated to an AWS account (even in the case of service accounts). This means that the only way you can implement RBAC across multiple projects/teams is to use multiple accounts on the machine. This is messy and painful to maintain at scale.
  • The machine has to be prepped with the right version of the CLI. If multiple teams are deploying and they have a need to use different versions of the CLI, you will need different deployment machines for each team.

In a nutshell, if you want to achieve frictionless execution of Ansible playbooks with modular, reusable playbooks, you need to templatize your playbooks and automate the workflow used to execute them.

 

Automated deployments from Nexus to AWS with Ansible 

To show you how to automate the workflow described above, we have designed a step by step tutorial in our documentation:

Automated Deployments of a JAR Package from Nexus to AWS

Your simple workflow at the end of the tutorial will look like this:

Screen Shot 2018-05-09 at 3.23.20 PM

 Schedule a demo

If you want a live demo of the Shippable platform and watch this scenario in action, schedule a demo with us:

Schedule a demo

Topics: AWS, java, ansible, nexus