How to reset the Ansible version mapped to your AWS Quick Start deployment

Still need help?

The Atlassian Community is here for you.

Ask the community


Infrastructure notice: AWS Quick Start only - This article only applies to Atlassian products deployed on AWS through any of our AWS Quick Starts.

Platform Notice: Data Center Only - This article only applies to Atlassian products on the data center platform.

Summary

Our Jira, Confluence, and Bitbucket Quick Starts for AWS use a set of Ansible playbooks to orchestrate each application node's setup. Previously, these AWS Quick Starts used the latest version of the Ansible playbooks each time you provisioned a node.

As of , we updated the Quick Starts to record the playbooks set's version upon first deployment. Each time you provision a new node, the AWS Quick Start will use the same version. The AWS Quick Start will only use the latest version of the Ansible playbooks during your first deployment.  

Background

The Ansible playbooks we use allow us to define best-practice settings for each cluster node. In turn, they also allow you to customize each node as you see fit.


These playbooks are available from a public Bitbucket repo:


https://bitbucket.org/atlassian/dc-deployments-automation/src/master/


Previously, whenever you provisioned a node, the AWS Quick Start cloned the latest repo version and run the playbooks. This ensured that you'd always get the latest fixes on your first deployment, and also each time you scaled up.


However, each time you provision a new cluster node, the AWS Quick Start used the latest version only on the new node. This could result in differently configured nodes if the playbooks were updated after you first deployed (and before you provisioned a new node). Since Jira always expects each application node to be identically configured, this could lead to unexpected errors.


With this new update, you'll always use the same version of the playbook each time you provision a node. If you want to update your cluster node's configuration with a different playbook version, you'll have to force the Quick Start to do so.

Solution

We strongly recommend you test this in a staging environment before updating your production deployment.

When you run the AWS Quick Start for the first time, it will perform the following on your application node:

  1. Clone the Ansible playbook repo.
  2. Set the CloudFormation parameter AnsibleRepoPinSHA to the repo's latest commit hash.
  3. Run the playbook to set up the node.

The AWS Quick Start identifies Ansible playbook versions by commit hash. When you provision a new application node, the AWS Quick Start will:

  1. Check the commit hash recorded in the AnsibleRepoPinSHA parameter.
  2. Clone the Ansible playbook repo on the node.
  3. Revert the repo to the version matching the commit hash in AnsibleRepoPinSHA.
  4. Run the playbook to set up the node.

By doing this, the AWS Quick Start ensures that your cluster will always have identical nodes when you scale up.

However, this also means that you will always use the same playbook version. If you want to configure your cluster to use a different version, perform the following steps. 

Step 1: Find the commit hash of the playbook version you want to use

If you plan to upgrade to the latest playbook version, you can skip to the next step.

If you plan to use a different playbook version, you'll need its commit hash. The commit hash is the last component of a commit's URL. For example, the hash of this commit is d428624ac20e61f6805ad2dfd05a6f3ca3983df6 (for a complete list of all commits to the repo, see https://bitbucket.org/atlassian/dc-deployments-automation/commits/branch/master). 

Step 2: Terminate all running application nodes

Set the number of Jira Data Center application nodes to 0. Then, update the stack. Doing this will make Jira, Confluence, or Bitbucket unavailable (until you finish the next step).

Click here for detailed instructions


  1. In the AWS console, go to Services > CloudFormation. Select your deployment’s stack to view its Stack Details.

  2. In the Stack Details screen, click Update Stack.

  3. From the Select Template screen, select Use current template and click Next.

  4. You’ll need to terminate all running nodes. To do that, set the following parameters to 0:

    1. Maximum number of cluster nodes

    2. Minimum number of cluster nodes

  5. Click Next. Click through the next pages, and then to apply the change using the Update button.

  6. Once the update is complete, check that all application nodes have been terminated.



Step 3: Update the playbook commit hash used by your deployment

To do this, update the AnsibleRepoPinSHA parameter.

Click here for detailed instructions
  1. In the AWS console, go to Services > Systems Manager.
  2. Under Application Management, select Parameter Store.
  3. Select your deployment's AnsibleRepoSHA parameter. Its entry under the Name column  should contain your deployment’s root stack name and pinned-ansible-sha.
  4. On the next screen, select Edit. This will open the Parameter details screen.

From here, you can now set which version of the Ansible playbooks your deployment should use from now on.

Option 1: Update to the latest version of the Ansible repository

To use the current latest version of the Ansible repository, enter latest in the Value field. When you prevision new nodes in the next step, the AWS Quick Start will automatically set AnsibleRepoPinSHA to the latest playbook version's commit hash. 

The AWS Quick Start will then use that playbook version whenever you provision new nodes from now on.

Option 2: Update to a specific version of the Ansible repository

To use any playbook version other than the latest, enter the commit hash you got in Step 1 in the Value field. The AWS Quick Start will then use that hash's corresponding playbook version whenever you provision new nodes from now on.

Step 4: Scale up the number of application nodes

Once you've updated the Value field from the previous step, select Save changes. You can now scale up your deployment to your original number of application nodes. 

Click here for detailed instructions

  1. Sign in to the AWS Management Console, use the region selector in the navigation bar to choose the AWS Region for your deployment, and open the AWS CloudFormation console at https://console.aws.amazon.com/cloudformation/.
  2. Click the Stack name of your deployment. This will display your deployment's Stack info. From there, click Update.
  3. On the Select Template page, leave Use current template selected, and then choose Next.
  4. On the Specify Details page, go to the Cluster nodes section of Parameters. From there, set your desired number of application nodes in the following parameters:
    1. Minimum number of cluster nodes
    2. Maximum number of cluster nodes
  5.  Click through to update the stack.

Disabled Auto Scaling

Since your cluster has the same minimum and maximum number of nodes, Auto Scaling is effectively disabled.

Setting different values for the minimum and maximum number of cluster nodes enables Auto Scaling. This dynamically scale the size of your cluster based on system load.

However, we recommend that you keep Auto Scaling disabled. At present, Auto Scaling can't effectively address sudden spikes in your deployment's system load. This means that you'll have to manually re-scale your cluster depending on the load.




DescriptionRevert Ansible pinned version
ProductBitbucket
Last modified on Jun 24, 2020

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.