How to reset the Ansible version mapped to your AWS Quick Start deployment
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.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
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:
- Clone the Ansible playbook repo.
- Set the CloudFormation parameter
AnsibleRepoPinSHAto the repo's latest commit hash. - 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:
- Check the commit hash recorded in the
AnsibleRepoPinSHAparameter. - Clone the Ansible playbook repo on the node.
- Revert the repo to the version matching the commit hash in
AnsibleRepoPinSHA. - 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).
Step 3: Update the playbook commit hash used by your deployment
To do this, update the AnsibleRepoPinSHA parameter.
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.