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.

プラットフォームについて: Data Center - この記事は、Data Center プラットフォームのアトラシアン製品に適用されます。

このナレッジベース記事は製品の Data Center バージョン用に作成されています。Data Center 固有ではない機能の Data Center ナレッジベースは、製品のサーバー バージョンでも動作する可能性はありますが、テストは行われていません。サーバー*製品のサポートは 2024 年 2 月 15 日に終了しました。サーバー製品を利用している場合は、アトラシアンのサーバー製品のサポート終了のお知らせページにて移行オプションをご確認ください。

*Fisheye および Crucible は除く

要約

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:


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.

ソリューション

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).

クリックして詳しい手順を確認


  1. AWS コンソールで、[Services] > [CloudFormation] に移動します。デプロイメントのスタックを選択してスタックの詳細を表示します。

  2. スタックの詳細画面で、[Update Stack] をクリックします。

  3. [Select Template] 画面で、[Use current template] を選択してから、[Next] をクリックします。

  4. 実行中のすべてのノードを終了する必要があります。これを実行するには、次のパラメーターを 0 に設定します。

    1. Maximum number of cluster nodes

    2. Minimum number of cluster nodes

  5. [Next] をクリックします。以降のページをクリックして進み、[Update] ボタンを使用して変更を適用します。

  6. 更新が完了したら、すべての アプリケーション ノードが終了していることを確認します。



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

To do this, update the AnsibleRepoPinSHA parameter.

クリックして詳しい手順を確認
  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.

ステップ 4: アプリケーション ノードの数の拡張

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. 

クリックして詳しい手順を確認

  1. AWS マネジメント コンソールにサインインし、ナビゲーション バーのリージョン セレクタを使用してデプロイメントに対応した AWS リージョンを選択し、https://console.aws.amazon.com/cloudformation/ で AWS CloudFormation コンソールを開きます。
  2. デプロイメントの [Stack name] をクリックします。これにより、デプロイメントのスタック情報が表示されます。ここで、[Update] をクリックします。
  3. [Select Template] ページで [Use current template] を選択したままにし、[Next] を選択します。
  4. [Specify Details] ページで、[Parameters] セクションの [Cluster nodes] に移動します。ここで、次のパラメーターに対して希望する数のアプリケーション ノードを設定します。
    1. Minimum number of cluster nodes
    2. Maximum number of cluster nodes
  5.  クリックしてスタックを更新します。

Auto Scaling の無効化について

クラスタの最小ノード数と最大ノード数が同じであるため、Auto Scaling が事実上無効化されています。

クラスタ ノードの最小数と最大数に異なる値を設定すると、Auto Scaling が有効になります。これにより、システム負荷に基づいてクラスタのサイズが動的にスケーリングされます。

ただし、Auto Scaling は無効化したままにすることをおすすめします。現時点では、Auto Scaling はご利用のデプロイメントのシステム負荷の急激な変化に効果的に対処できません。つまり、負荷に応じてクラスタを手動で再スケーリングする必要があります。




説明 Revert Ansible pinned version
製品Confluence
最終更新日 2020 年 6 月 24 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.