Deploy Bitbucket Data Center in AWS

The AWS Quick Start template as a method of deployment is nearing its end-of-support date on February 29, 2024. You can still use the template after this date but we won't maintain or update it. Learn more about the AWS deployment template

We recommend deploying your Data Center products on a Kubernetes cluster using our Helm charts for a more efficient and robust infrastructure and operational setup. Learn more about deploying on Kubernetes

AWS now recommends switching launch configurations, which our AWS Quick Start template uses, to launch templates. We won’t do this switch, since we’re ending our support for the AWS Quick Start template. You’ll still be able to create launch configurations until December 31, 2023.

If you decide to deploy your Data Center instance in a clustered environment, consider using Amazon Web Services (AWS). AWS allows you to scale your deployment elastically by resizing and quickly launching additional nodes, and provides a number of managed services that work out of the box with Data Center products. These services make it easier to configure, manage, and maintain your deployment's clustered infrastructure. Learn more about Data Center

非クラスタ環境とクラスタ環境

A single node is adequate for most small or medium size deployments, unless you need specific features that require clustering (for example high availability or zero-downtime upgrades).

既存の Server インストールがある場合は、Data Center にアップグレードする際にそのインフラストラクチャを引き続き使用できます。Data Center 専用の多くの機能 (SAML シングル サインオンレート制限によるシステムの保護CDN サポートなど) では、クラスタ インフラストラクチャは不要です。Server インストールのライセンスをアップグレードするだけで、Data Center のこれらの機能の使用を開始できます。

クラスタ化が必要かどうかの詳細については「アトラシアンの Data Center 製品のアーキテクチャとインフラストラクチャのオプション」をご参照ください。

Deploying your Data Center instance in a cluster using the AWS Quick Start

AWS に Data Center クラスタ全体をデプロイする最も単純な方法は、クイック スタートを使用することです。Quick Start は、AWS のセキュリティと可用性のためのベスト プラクティスを使用して、AWS 上に特定のワークロードをデプロイするのに必要な AWS コンピュータ、ネットワーク、ストレージ、およびその他のサービスを、起動、設定、および実行します。

The Quick Start provides two deployment options, each with its own template. The first option deploys the Atlassian Standard Infrastructure (ASI) and then provisions either your Data Center product into this ASI. The second option only provisions your Data Center product on an existing ASI.

The ASI is a virtual private cloud (VPC) that contains the components required by all Atlassian Data Center applications. For more information, see Atlassian Standard Infrastructure (ASI) on AWS.

デプロイメントは、以下のコンポーネントで構成されています。

  • Instances/nodes: One or more Amazon Elastic Cloud (EC2) instances as cluster nodes, running your Data Center instance.

  • Load balancer: An Application Load Balancer (ALB), which works both as a load balancer and SSL-terminating reverse proxy.

  • Amazon EFS: A shared file system for storing artifacts in a common location, accessible to multiple nodes. The Quick Start architecture implements the shared file system using the highly available Amazon Elastic File System (Amazon EFS) service.

  • Database: Your choice of shared database instance—Amazon RDS or Amazon Aurora.

  • Amazon CloudWatch: Amazon のネイティブ CloudWatch サービスによる基本的なモニタリングおよび中央ログ。

Confluence will use the Java Runtime Engine (JRE) that is bundled with Confluence (/opt/atlassian/confluence/jre/), and not the JRE that is installed on the EC2 instances (/usr/lib/jvm/jre/). 

Bitbucket-specific deployment infrastructure
  • インスタンス / ノード。Bitbucket を実行している、クラスタ ノードとしての 1 つ以上の Amazon Elastic Cloud (EC2) インスタンス。

  • ロード バランサ。ロード バランサおよび SSL ターミネート リバース プロキシの両方として機能する Amazon Elastic Load Balancer (ELB)。

  • データベース: 選択した共有データベース インスタンス – Amazon RDS または Amazon Aurora。

  • Storage: A shared NFS server to store repositories in a common location accessible to all Bitbucket nodes.

  • Amazon CloudWatch: Amazon のネイティブ CloudWatch サービスによる基本的なモニタリングおよび中央ログ。

  • An Amazon OpenSearch Service domain: For code and repository search.

Learn more about Jira products on AWS, Confluence on AWS, Bitbucket on AWS, and Crowd on AWS.

高度なカスタマイズ

迅速な実装のため、クイック スタートでは手動インストールと同じレベルのカスタマイズは提供していません。ただし、アトラシアンで使用している Ansible プレイブックの変数を通じてデプロイメントをさらにカスタマイズできます。

All of our AWS Quick Starts use Ansible playbooks to configure specific components of your deployment. These playbooks are available publicly on this repository: https://bitbucket.org/atlassian/dc-deployments-automation.

Ansible 変数を使用してこれらの構成をオーバーライドできます。詳細は、リポジトリの README ファイルを参照してください。

Note about customization in Jira

Jira allows you to apply advanced settings through the jira-config.properties file. You can also use the same file to apply the same settings to an existing Quick Start deployment. Learn how to customize the jira-config.properties file

自身の S3 バケットからのクイック スタートの起動 (推奨)

クイック スタートをもっとも素早く起動する方法は、AWS S3 バケットから直接起動することです。だだしこれを行った場合、アトラシアンでクイック スタート テンプレートに加えているすべての更新がデプロイメントに直接伝播されます。これらの更新には、テンプレートからのパラメーターの追加や削除が含まれる場合があります。これにより、デプロイメントに予期しない (および大幅な) 変更が発生する可能性があります。

本番環境の場合、クイック スタート テンプレートを自身の S3 バケットにコピーすることをおすすめします。次に、それらをそこから直接起動します。これにより、クイック スタートの更新をデプロイメントに伝播するタイミングを制御できるようになります。

To launch the Quick Start:

Jira-specific instructions
  1. Clone the Quick Start templates (including all of its submodules) to your local machine. From the command line, run:

    git clone --recurse-submodules https://github.com/aws-quickstart/quickstart-atlassian-jira.git

  2. (オプション) クイックスタート テンプレート リポジトリは、クイック スタート インターフェイスで必要となるディレクトリ構造を使用しています。必要に応じて (ストレージ コストを最小限に抑えたい場合など)、以下を除くすべてのファイルを削除できます。

    quickstart-atlassian-jira 
    ├─ submodules 
    │ └─ quickstart-atlassian-services 
    │ └─ templates 
    │ └── quickstart-vpc-for-atlassian-services.yaml 
    └─ templates 
    ├── quickstart-jira-dc-with-vpc.template.yaml 
    └── quickstart-jira-dc.template.yaml

  3. AWS コマンド ライン インターフェイスをインストールしてセットアップします。これにより、S3 バケットを作成し、そこにコンテンツをアップロードすることができます。

  4. 自身のリージョンで S3 バケットを作成します。

    aws s3 mb s3://<bucket-name> --region <AWS_REGION>

この時点で、クイック スタート テンプレートを自身の S3 バケットにアップロードできるようになりました。これを行う前に、使用するクイック スタート テンプレートを選択する必要があります。

  • quickstart-jira-dc-with-vpc.template.yaml: 新しい ASI へのデプロイ (エンドツーエンドのデプロイメント) に使用します。

  • quickstart-jira-dc.template.yaml: 既存の ASI にデプロイする際に使用します。

  1. In the template you’ve chosen, the QSS3BucketName default value is set to aws-quickstart. Replace this default with the name of your S3 bucket.

  2. クイック スタート テンプレートのローカル クローンの親ディレクトリに移動します。ここから、ローカル クローン内のすべてのファイルを S3 バケットにアップロードします。

    aws s3 cp quickstart-atlassian-jira s3://<bucket-name> --recursive --acl public-read
  3. Once you’ve uploaded everything, you’re ready to deploy your production stack from your S3 bucket. Go to Cloudformation > Create Stack. When specifying a template, paste in the Object URL of the Quick Start template you’ll be using.

Confluence-specific instructions
  1. Clone the Quick Start templates (including all of its submodules) to your local machine. From the command line, run:

    git clone --recurse-submodules https://github.com/aws-quickstart/quickstart-atlassian-confluence.git

  2. (オプション) クイックスタート テンプレート リポジトリは、クイック スタート インターフェイスで必要となるディレクトリ構造を使用しています。必要に応じて (ストレージ コストを最小限に抑えたい場合など)、以下を除くすべてのファイルを削除できます。

    quickstart-atlassian-confluence 
    ├─ submodules 
    │ └─ quickstart-atlassian-services 
    │ └─ templates 
    │ └── quickstart-vpc-for-atlassian-services.yaml 
    └─ templates 
    ├── quickstart-confluence-master-with-vpc.template.yaml 
    └── quickstart-confluence-master.template.yaml

  3. AWS コマンド ライン インターフェイスをインストールしてセットアップします。これにより、S3 バケットを作成し、そこにコンテンツをアップロードすることができます。

  4. 自身のリージョンで S3 バケットを作成します。

    aws s3 mb s3://<bucket-name> --region <AWS_REGION>

この時点で、クイック スタート テンプレートを自身の S3 バケットにアップロードできるようになりました。これを行う前に、使用するクイック スタート テンプレートを選択する必要があります。

  • quickstart-confluence-master-with-vpc.template.yaml: 新しい ASI へのデプロイ (エンドツーエンドのデプロイメント) に使用します。

  • quickstart-confluence-master.template.yaml: 既存の ASI にデプロイする際に使用します。

  1. In the template you’ve chosen, the QSS3BucketName default value is set to aws-quickstart. Replace this default with the name of your S3 bucket.

  2. クイック スタート テンプレートのローカル クローンの親ディレクトリに移動します。ここから、ローカル クローン内のすべてのファイルを S3 バケットにアップロードします。

    aws s3 cp quickstart-atlassian-confluence s3://<bucket-name> --recursive --acl public-read

  3. Once you’ve uploaded everything, you’re ready to deploy your production stack from your S3 bucket. Go to Cloudformation > Create Stack. When specifying a template, paste in the Object URL of the Quick Start template you’ll be using.

Bitbucket-specific instructions
  1. Clone the Quick Start templates (including all of its submodules) to your local machine. From the command line, run:

    git clone --recurse-submodules https://github.com/aws-quickstart/quickstart-atlassian-bitbucket

  2. (オプション) クイックスタート テンプレート リポジトリは、クイック スタート インターフェイスで必要となるディレクトリ構造を使用しています。必要に応じて (ストレージ コストを最小限に抑えたい場合など)、以下を除くすべてのファイルを削除できます。

    quickstart-atlassian-bitbucket 
    ├─ submodules 
    │ └─ quickstart-atlassian-services 
    │ └─ templates 
    │ └── quickstart-vpc-for-atlassian-services.yaml 
    └─ templates 
    ├── quickstart-bitbucket-dc-with-vpc.template.yaml 
    └── quickstart-bitbucket-dc.template.yaml

  3. AWS コマンド ライン インターフェイスをインストールしてセットアップします。これにより、S3 バケットを作成し、そこにコンテンツをアップロードすることができます。

  4. 自身のリージョンで S3 バケットを作成します。

    aws s3 mb s3://<bucket-name> --region <AWS_REGION>

この時点で、クイック スタート テンプレートを自身の S3 バケットにアップロードできるようになりました。これを行う前に、使用するクイック スタート テンプレートを選択する必要があります。

  • quickstart-bitbucket-dc-with-vpc.template.yaml: 新しい ASI へのデプロイ (エンドツーエンドのデプロイメント) に使用します。

  • quickstart-bitbucket-dc.template.yaml: 既存の ASI にデプロイする際に使用します。

  1. In the template you’ve chosen, the QSS3BucketName default value is set to aws-quickstart. Replace this default with the name of your S3 bucket.

  2. クイック スタート テンプレートのローカル クローンの親ディレクトリに移動します。ここから、ローカル クローン内のすべてのファイルを S3 バケットにアップロードします。

    aws s3 cp quickstart-atlassian-bitbucket s3://<bucket-name> --recursive --acl public-read

  3. Once you’ve uploaded everything, you’re ready to deploy your production stack from your S3 bucket. Go to Cloudformation > Create Stack. When specifying a template, paste in the Object URL of the Quick Start template you’ll be using.

Crowd-specific instructions
  1. Clone the Quick Start templates (including all of its submodules) to your local machine. From the command line, run:

    git clone --recurse-submodules https://github.com/aws-quickstart/quickstart-atlassian-crowd.git

  2. (オプション) Quick Start templates リポジトリは、クイック スタート インターフェイスで必要となるディレクトリ構造を使用しています。必要に応じて (ストレージ コストを最小限に抑えたい場合など)、以下を除くすべてのファイルを削除できます。

    quickstart-atlassian-crowd 
    ├─ submodules 
    │  └─ quickstart-atlassian-services 
    │    └─ templates 
    │     └── quickstart-vpc-for-atlassian-services.yaml 
    └─ templates 
       ├── quickstart-crowd-dc-with-vpc.template.yaml 
       └── quickstart-crowd-dc.template.yaml

  3. AWS コマンド ライン インターフェイスをインストールしてセットアップします。これにより、S3 バケットを作成し、そこにコンテンツをアップロードすることができます。

  4. 自身のリージョンで S3 バケットを作成します。

    aws s3 mb s3://<bucket-name> --region <AWS_REGION>

この時点で、クイック スタート テンプレートを自身の S3 バケットにアップロードできるようになりました。これを行う前に、使用するクイック スタート テンプレートを選択する必要があります。

  • quickstart-crowd-dc-with-vpc.template.yaml: 新しい ASI へのデプロイ (エンドツーエンドのデプロイメント) に使用します。

  • quickstart-crowd-dc.template.yaml: 既存の ASI にデプロイする際に使用します。

  1. In the template you’ve chosen, the QSS3BucketName default value is set to aws-quickstart. Replace this default with the name of your S3 bucket.

  2. クイック スタート テンプレートのローカル クローンの親ディレクトリに移動します。ここから、ローカル クローン内のすべてのファイルを S3 バケットにアップロードします。

    aws s3 cp quickstart-atlassian-crowd s3://<bucket-name> --recursive --acl public-read

  3. Once you’ve uploaded everything, you’re ready to deploy your production stack from your S3 bucket. Go to Cloudformation > Create Stack. When specifying a template, paste in the Object URL of the Quick Start template you’ll be using.

高可用性のための Amazon Aurora データベース

The Quick Start also allows you to deploy your Data Center instance with an Amazon Aurora clustered database (instead of RDS). 

クラスタは PostgreSQL 互換で、2 つのデータベース リーダーをレプリケートする、プライマリ データベース ライターを備えています。冗長性を向上させるため、異なるアベイラビリティ ゾーンにライターとリーダーをセットアップすることもできます。

ライターが失敗した場合、Aurora はリーダーの 1 つを自動的にプロモートしてライターにします。詳細は「Amazon Aurora の特徴: PostgreSQL 互換エディション」 を参照してください。

Amazon CloudWatch による基本的なモニタリングおよび中央ログ

また、クイック スタートでは、Amazon CloudWatch によるノード管理も提供されます。これにより、各ノードの CPU、ディスク、およびネットワーク アクティビティのすべてを、事前設定済みの CloudWatch ダッシュボードから追跡できます。ダッシュボードは、最新のログ出力を表示するように設定され、後で監視および指標を追加してカスタマイズできます。

既定では、Amazon CloudWatch は各ノードからログを収集し、単一の中央ソースに保存します。この中央ログにより、デプロイのログ データをより簡単かつ効果的に検索および分析できます。詳細については、「CloudWatch Logs Insights を使用したログ データの分析」および「フィルター パターンを使用したログ データ検索」を参照してください。

Amazon CloudWatch provides basic logging and monitoring but also costs extra. To help reduce the cost of your deployment, you can disable logging or turn off Amazon CloudWatch integration during deployment.
tip/resting Created with Sketch. To download your log data (for example, to archive it or analyze it outside of AWS), you’ll have to export it first to S3. From there, you can download it. See Exporting Log Data to Amazon S3 for details.

オート スケーリング グループ

この Quick Start は Auto Scaling グループを使用しますが、これはクラスタ ノード数の静的制御のみを目的としています。Auto Scaling を使用してクラスタのサイズを動的に拡張することは推奨されません。アプリケーション ノードのクラスタへの追加には通常 20 分以上かかりますが、この速度では突然の負荷のスパイクに対処できません。

If you can identify any periods of high and low load, you can schedule the application node cluster to scale accordingly. See Scheduled Scaling for Amazon EC2 Auto Scaling for more information. To study trends in your organization's load, you'll need to monitor the performance of your deployment.

AWS クイック スタートの CloudFormation テンプレートのカスタマイズ

迅速な実装のため、クイック スタートでは手動インストールと同じレベルのカスタマイズは提供していません。代わりに、クイック スタートで使用される CloudFormation テンプレートを必要に応じてカスタマイズできます。これらのテンプレートは以下のリポジトリで入手できます。

サポート対象の AWS リージョン

Not all regions offer the services required to run Data Center products. You'll need to choose a region that supports Amazon Elastic File System (EFS). These regions are:

  • アメリカ

    • バージニア北部

    • オハイオ

    • オレゴン

    • 北カリフォルニア

    • モントリオール

  • ヨーロッパ / 中東 / アフリカ

    • アイルランド

    • フランクフルト

    • ロンドン

    • パリ

  • アジア太平洋

    • シンガポール

    • 東京

    • シドニー

    • ソウル

    • ムンバイ

This list was last updated on June 20, 2019.

各リージョンで提供されるサービスは随時変更される可能性があります。使用したいリージョンがこの一覧に含まれていない場合、そこが EFS をサポートしているかどうかを AWS ドキュメントの「リージョンごとの製品サービス」の表でご確認ください。 

Even though you can deploy our Data Center products on AWS GovCloud, we don’t test or verify our AWS Quick Starts on the AWS GovCloud environment and can’t provide any support.

Other product-specific instructions

Scaling, migrating, and upgrading Confluence Data Center on AWS

Synchrony setup in Confluence

Confluence Data Center ライセンスをお持ちの場合、Synchrony を実行するには 2 つのメソッドを使用できます。

  • Confluence で管理 (推奨)
    Confluence は同じノードで自動的に Synchrony プロセスを起動して管理します。手動による操作は不要です。 

  • スタンドアロンの Synchrony クラスタ (ユーザーによる管理)
    ユーザーはスタンドアロンな Synchrony を必要なノード数で、独自のクラスタでデプロイおよび管理します。大規模なセットアップが必要です。ローリング アップグレードでは、Confluence クラスタとは別に Synchrony をアップグレードする必要があります。

シンプルなセットアップを実現してメンテナンスの労力を極力減らしたい場合、Synchrony を Confluence で管理することをおすすめします。完全な制御を実現したい場合や、エディタの高い可用性の確保が必須である場合、独自のクラスタで Synchrony を管理することが、組織に最適なソリューションである可能性があります。 

By default, the Quick Start will configure Synchrony to be managed by Confluence. However, you can use the Quick Start to configure standalone Synchrony. When you do, the Quick Start creates an Auto Scaling group containing one or more Amazon EC2 instances as cluster nodes, running Synchrony. Learn more about the possible Confluence and Synchrony configurations

Managed mode is only available in 6.12 and later. If you plan to deploy a Confluence Data Center version earlier than 6.12, you can only use Standalone mode. In the Quick Start, this means you should set your Collaborative editing mode to synchrony-separate-nodes.

Large または XLarge のデプロイの場合は、アプリケーション、Synchrony、データベースのサイズ設定のアドバイスについて、「AWS インフラストラクチャの推奨事項」をご確認ください。小規模なデプロイの場合、Confluence のシステム要件を満たすインスタンスを使用できます。より小さなインスタンス タイプ (micro、small、medium) は一般に、Confluence の実行には不十分です。

Route53 プライベート ホステッド ゾーンを使用した内部ドメイン名ルーティング

Even if your Confluence site is hosted on AWS, you can still link its DNS with an internal, on-premise DNS server (if you have one). You can do this through Amazon Route 53, creating a link between the public DNS and internal DNS. This will make it easier to access your infrastructure resources (database, shared home, and the like) through friendly domain names. You can make those domain names accessible externally or internally, depending on your DNS preferences.

ステップ 1. 新しいホステッド ゾーンを作成する

Create a Private hosted zone in Services > Route 53. The Domain Name is your preferred domain. For the VPC, use the existing Atlassian Standard Infrastructure.

ステップ 2. ホステッド ゾーンを使用するようスタックを設定する

Use your deployment’s Quick Start template to point your stack to the hosted zone from step 1. If you’re setting up Confluence for the first time, follow the Quick Start template as below:

  1. [DNS (オプション)] の [Route 53 のホステッド ゾーン] フィールドに、自身のホステッド ゾーンの名前を入力します。

  2. Enter your preferred domain sub-domain in the Sub-domain for Hosted Zone field. If you leave it blank, we'll use your stack name as the sub-domain.

  3. プロンプトに従ってスタックをデプロイします。

既存の Confluence サイトが既にある場合は、クイック スタート テンプレートでスタックを構成することもできます。このテンプレートにアクセスするには、次の手順に従います。

  1. Go to to Services > CloudFormation in the AWS console

  2. Select the stack, and select Update Stack.

  3. [DNS (オプション)] の [Route 53 のホステッド ゾーン] フィールドに、自身のホステッド ゾーンの名前を入力します。

  4. Enter your preferred domain sub-domain in the Sub-domain for Hosted Zone field. If you leave it blank, we'll use your stack name as the sub-domain.

  5. プロンプトに従ってスタックを更新します。

いずれの場合も、AWS はロード バランサー、EFS、およびデータベース用の URL と Route 53 レコードを生成します。たとえば、ホステッド ゾーンが my.hostedzone.com でスタックの名前が mystack の場合、URL mystack.db.my.hostedzone.com からデータベースにアクセスできます。

ステップ 3. DNS サーバーを Confluence サイトの VPC にリンクする

If you use a DNS server outside of AWS, then you need to link it to your deployment’s VPC (in this case, the Atlassian Standard Infrastructure). This means your DNS server should use Route 53 to resolve all queries to the hosted zone’s preferred domain (in Step 1).

これをセットアップする方法の手順については、「VPC とネットワークとの間の DNS クエリの解決」を参照してください。

自身の DNS サーバーを使用して内部向けの Confluence サイトをデプロイする場合、Amazon Route 53 を使用してパブリック DNS と内部 DNS 間のリンクを作成することができます。 

  1. Route 53 で、プライベート ホステッド ゾーンを作成します。VPC については、既存の Atlassian Services VPC を使用できます。ドメイン名はお好みのドメインに設定します。

  2. If you've already set up Confluence, go to Services > CloudFormation in the AWS console, select the stack, and select Update stack. (If you're setting up Confluence for the first time, follow the Quick Start template as below). 

  3. [その他のパラメータ] の [Route 53 のホステッド ゾーン] フィールドに、自身のホステッド ゾーンの名前を入力します。 

  4. 任意のサブドメインを入力します。または、[ホステッド ゾーンのサブドメイン] フィールドを空のままにしておくと、スタック名がサブドメインとして使用されます。

  5. プロンプトに従ってスタックを更新します。ロード バランサおよび EFS URL が生成され、Route 53 にそれぞれのレコードが作成されます。 

  6. In Confluence, go to Administration > General configuration and update the Confluence base URL to your Route 53 domain. 

  7. ご利用のオンプレミス ネットワークとプライベート ホステッド ゾーンに紐付いた VPC との間に DNS 解決をセットアップします。これを行うには、次の製品を使用します。

    1. Active Directory (Amazon Directory Service または Microsoft Active Directory)

    2. bind9 または Unbound を使用する、EC2 の DNS フォワーダ

  8. 最後に、Confluence と Synchrony の各ノードを終了して再度プロビジョニングし、変更を有効にします。

Confluence のベース URL の構成に関連する情報については、「サーバー ベース URL の設定」を参照してください。

スケーリング (拡張および縮小)

Confluence または Synchrony クラスタ ノードの数を増減させるには、次の手順を実行します。

  1. AWS マネジメント コンソールにサインインし、ナビゲーション バーのリージョン セレクタを使用してデプロイメントに対応した AWS リージョンを選択し、https://console.aws.amazon.com/cloudformation/ で AWS CloudFormation コンソールを開きます。

  2. Select the Stack name of your deployment. This will display your deployment's Stack info. From there, select Update.

  3. On the Select template page, leave Use current template selected, and then select Next.

  4. [Specify Details] ページで、[Parameters] セクションの [Cluster nodes] に移動します。ここで、次のパラメーターに対して希望する数のアプリケーション ノードを設定します。

    1. Minimum number of cluster nodes

    2. Maximum number of cluster nodes

  5.  Continue to update the stack.

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

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

Vertical vs. horizontal scaling

Adding new cluster nodes, especially automatically in response to load spikes, is a great way to increase capacity of a cluster temporarily. Beyond a certain point,  adding very large numbers of cluster nodes will bring diminishing returns. In general, increasing the size of each node (i.e., "vertical" scaling) will be able to handle a greater sustained capacity than increasing the number of nodes (i.e., "horizontal" scaling), especially if the nodes themselves are small. See Infrastructure recommendations for enterprise Confluence instances on AWS for more details. See the AWS documentation for more information on auto scaling groups. 

SSH 経由でノードに接続する

AWS Systems Manager の Sessions Manager を使用して、デプロイメントでノードレベルの構成または保守タスクを実行できます。このブラウザベースのターミナルでは、SSH キーや Bastion ホストを使用せずにノードにアクセスできます。詳細については、「Session Manager の開始方法」を参照してください。

Bastion ホストをデプロイ済みの場合、それを経由してノードにアクセスすることもできます。これを実行するには、SSH 秘密鍵ファイル (Key Name パラメータに指定した PEM ファイル) が必要です。このキーはデプロイ内のすべてのノードにアクセスできるため、安全な場所に保管するようにします。

この Bastian ホストは、デプロイの内部サブネットの任意のインスタンスへの ”踏み台” として機能します。つまり、まず Bastion ホストに接続し、そこからデプロイ内の任意のインスタンスにアクセスします。 

The Bastion host's public IP is the BastionPubIp output of your deployment's ATL-BastionStack stack. This stack is nested in your deployment's Atlassian Standard Infrastructure (ASI). To access the Bastion host, use ec2-user as the user name, for example:

  • ssh -i keyfile.pem ec2-user@<BastionPubIp>

The ec2-user has sudo access. SSH access is by root isn't allowed.

アップグレード

Consider upgrading to a Long Term Support release (if you're not on one already). Enterprise releases get fixes for critical bugs and security issues throughout its two-year support window. This gives you the option to keep a slower upgrade cadence without sacrificing security or stability. Long Term Support releases are suitable for companies who can't keep up with the frequency at which we ship feature releases.

デプロイメントのアップグレードについて、次の点をご確認ください。

  1. Confluence Data Center の最新バージョンにアップグレードする前に、アプリにそのバージョンとの互換性があるかを確認します。必要に応じてアプリを更新します。アプリの管理の詳細については、「Universal Plugin Manager の使用」を参照してください。

  2. If you need to keep Confluence Data Center running during your upgrade, we recommend using read-only mode for site maintenance.  Your users will be able to view pages, but not create or change them. 

  3. 本番サイトをアップグレードする前に、ステージング環境でアップグレードを実施することを強くおすすめします。「Confluence のアップグレードのためのステージング環境の作成方法」には、これを行うための便利なヒントが記載されています。

As of Confluence Data Center 7.9, you can now upgrade to the next bug fix version (for example, 7.9.0 to 7.9.3) with no downtime. Follow the instructions in Upgrade Confluence without downtime.

デプロイメントをアップグレードするタイミングであることを判断したら、次の手順を実行します。

ステップ 1: 実行中のすべての Confluence Data Center アプリケーション ノードの終了

Confluence Data Center スタックで使用されるアプリケーション ノードの数を 0 に設定します。その後、スタックを更新します。

If your deployment uses standalone Synchrony, scale the number of Synchrony nodes to 0 at the same time.

To udpate the stack:

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

  2. スタックの詳細画面で、[スタックの更新] を選択します。

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

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

    1. Maximum number of cluster nodes

    2. Minimum number of cluster nodes

  5. Select Next. Continue to the next pages, then apply the change using the Update button.

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

ステップ 2: Confluence Data Center スタックで使用されるバージョンの更新

Confluence Data Center で使用されるアプリケーション ノードの数を 1 に設定します。希望のバージョンを使用できるようにアプリケーション ノードを設定します。その後、スタックを再度更新します。

If your deployment uses standalone Synchrony, scale the number of Synchrony nodes to 1 at the same time.

To update the stack again:

  1. From your deployment’s Stack details screen, select Update stack again.

  2. From the Select Template screen, select Use current template, then select Next.

  3. Version パラメーターを、更新先のバージョンに設定します。

  4. 1 つのノードで使用するようにスタックを構成します。これを実行するには、次のパラメーターを 1 に設定します。

    1. Maximum number of cluster nodes

    2. Minimum number of cluster nodes

  5. Select Next. Continue through the next pages, then apply the change using the Update button.

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

You can now scale up your deployment to your original number of application nodes. You can do so for your Synchrony nodes as well, if you have standalone Synchrony. Refer back to Step 1 for instructions on how to re-configure the number of nodes used by your cluster.

AWS の Confluence Data Center では現在、古いバージョンの最後のクラスタ ノードのシャットダウンと新しいバージョンの最初のクラスタ ノードの起動の間のダウンタイムが必須であり、インスタンスをダウンタイムなしでアップグレードすることはできません。新しいノードが新しいバージョンで起動する前に、既存のすべてのノードが終了していることを確認してください。

バックアップ

AWS のネイティブ バックアップ機能を使用することをおすすめします。これは Confluence Data Center のバックアップにスナップショットを使用します。詳しくは、「AWS バックアップ」を参照してください。 

AWS への既存の Confluence サイトの移行

AWS で Confluence をデプロイしたあとに、古いデプロイメントをそこに移行することもできます。この操作を行うには、次の手順を実行します。

  1. 既存のサイトを、AWS にデプロイしたバージョン (Confluence 6.1 以降) にアップグレードします。

  2. (オプション) 古いデータベースが PostgreSQL でない場合、それを移行する必要があります。手順については、「別のデータベースへの移行」を参照してください。 

  3. PostgreSQL データベースと既存の <shared-home>/attachments ディレクトリをバックアップします。

  4. バックアップ ファイルを EC2 インスタンスの /media/atl/confluence/shared-home にコピーします。  

  5. pg_restore を使用して PostgreSQL のデータベース ダンプを RDS インスタンスにリストアします。
    この方法の詳細については、Amazon のドキュメントの「Importing Data into PostgreSQL on Amazon RDS」を参照してください。   

重要な注意事項

  • CloudFormation テンプレートを使用してクラスタを作成すると、データベース名は confluence になります。リストア時にはこのデータベース名を保持する必要があります。データベース名が保持されない場合、新しいノードのプロビジョニング時に問題が発生する可能性があります。この場合、新しいデータベースをドロップしてバックアップで置き換える必要があります。 

  • 既存のローカル ホームまたはインストール ディレクトリからインデックスなどをコピーする必要はありません。既存の共有ホーム ディレクトリからは attachments だけをコピーします。  

  • <shared-home>/config/cache-settings-overrides.properties ファイルを変更した場合、新しい環境で変更を再適用することをおすすめします。  

  • AWS ページ「Importing Data into PostgreSQL on Amazon RDS」に記載されている _copy メソッドは、Confluence の移行には推奨されません。

Administering and securing Bitbucket Data Center on AWS

Bitbucket Data Center を AWS で管理する

AWS 内で次のような Bitbucket インスタンスの管理タスクを実行するための詳細については、「Bitbucket Data Center を AWS で管理する」を参照してください。

  • configuring variables when launching Bitbucket in AWS

  • maintaining, resizing, upgrading, migrating, and customizing your Bitbucket deployment in AWS

  • Bitbucket Server AMI 内のコンポーネントについての追加の詳細

Securing Bitbucket within AWS

AWS はパブリック インターネット経由でアクセスされるため、AWS で Bitbucket Server を実行するときには適切なセキュリティ基準を適用することが重要です。Amazon Virtual Private Cloud (VPC)、Security Group、および SSL を含む幅広いセキュリティ トピックのセキュリティ ガイダンスについて、「AWS で Bitbucket を保護するためのベスト プラクティス」をご確認ください。

Performance guidelines

AWS で Bitbucket デプロイメントの最高のパフォーマンスを実現できるよう、インスタンスの CPU、メモリ、I/O リソースのプロビジョニングを適切に行うことが重要です。アトラシアンでは、水平拡張によるパフォーマンスを実現する Bitbucket Data Center と単一ノードの Bitbucket Server インスタンスのいずれを選択した場合でも使用できる、ノード単位のベスト パフォーマンスを実現するための AWS EC2 および EBS 設定の選択についての具体的な推奨設定を提供しています。

CloudFormation テンプレートを使用している場合、これらの設定はすでに含まれています。使用していない場合、「AWS でのエンタープライズ Bitbucket インスタンスの推奨インフラストラクチャ」を参照してください。

Mirroring

Smart Mirroring can drastically improve Git clone speeds for distributed teams working with large repositories. For an overview of the benefits to mirroring, see Mirrors. The Bitbucket Data Center FAQ also answers many common questions about smart mirroring (and mirroring in general). 

詳しい手順については、「ミラーのセットアップ」を参照してください。

最終更新日 2022 年 6 月 29 日

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

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