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.
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.
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:
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.
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
- Clone the Ansible playbook repo on the node.
- Revert the repo to the version matching the commit hash in
- 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).
In the AWS console, go to Services > CloudFormation. Select your deployment’s stack to view its Stack Details.
In the Stack Details screen, click Update Stack.
From the Select Template screen, select Use current template and click Next.
You’ll need to terminate all running nodes. To do that, set the following parameters to 0:
Maximum number of cluster nodes
Minimum number of cluster nodes
Click Next. Click through the next pages, and then to apply the change using the Update button.
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
- In the AWS console, go to Services > Systems Manager.
- Under Application Management, select Parameter Store.
- Select your deployment's
AnsibleRepoSHAparameter. Its entry under the Name column should contain your deployment’s root stack name and
- 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.
- 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/.
- Click the Stack name of your deployment. This will display your deployment's Stack info. From there, click Update.
- On the Select Template page, leave Use current template selected, and then choose Next.
- 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:
- Minimum number of cluster nodes
- Maximum number of cluster nodes
- 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.