AWS クイック スタート テンプレートを使用して Data Center 製品をデプロイする

1. クイック スタート テンプレート (すべてのサブモジュールを含む) をローカル マシンに複製します。コマンド ラインから、以下を実行します。

   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. 選択したテンプレートでは、QSS3BucketName の既定値は aws-quickstart に設定されています。この既定値を S3 バケットの名前に置き換えてください。

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

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

3. すべてをアップロードしたら、S3 バケットから本番スタックをデプロイする準備が整いました。[Cloudformation] > [Create Stack (スタックの作成)] に移動します。テンプレートを指定する際は、使用するクイック スタート テンプレートのオブジェクト URL を貼り付けます。

1. クイック スタート テンプレート (すべてのサブモジュールを含む) をローカル マシンに複製します。コマンド ラインから、以下を実行します。

   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. 選択したテンプレートでは、QSS3BucketName の既定値は aws-quickstart に設定されています。この既定値を S3 バケットの名前に置き換えてください。

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

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

3. すべてをアップロードしたら、S3 バケットから本番スタックをデプロイする準備が整いました。[Cloudformation] > [Create Stack (スタックの作成)] に移動します。テンプレートを指定する際は、使用するクイック スタート テンプレートのオブジェクト URL を貼り付けます。

1. クイック スタート テンプレート (すべてのサブモジュールを含む) をローカル マシンに複製します。コマンド ラインから、以下を実行します。

   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. 選択したテンプレートでは、QSS3BucketName の既定値は aws-quickstart に設定されています。この既定値を S3 バケットの名前に置き換えてください。

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

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

3. すべてをアップロードしたら、S3 バケットから本番スタックをデプロイする準備が整いました。[Cloudformation] > [Create Stack (スタックの作成)] に移動します。テンプレートを指定する際は、使用するクイック スタート テンプレートのオブジェクト URL を貼り付けます。

1. クイック スタート テンプレート (すべてのサブモジュールを含む) をローカル マシンに複製します。コマンド ラインから、以下を実行します。

   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. 選択したテンプレートでは、QSS3BucketName の既定値は aws-quickstart に設定されています。この既定値を S3 バケットの名前に置き換えてください。

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

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

3. すべてをアップロードしたら、S3 バケットから本番スタックをデプロイする準備が整いました。[Cloudformation] > [Create Stack (スタックの作成)] に移動します。テンプレートを指定する際は、使用するクイック スタート テンプレートのオブジェクト URL を貼り付けます。

Confluence での Synchrony セットアップ

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

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

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

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

クイック スタートでは、既定では Synchrony を Confluence によって管理するように設定されます。ただし、クイック スタートを使用してスタンドアロンの Synchrony を設定することができます。これを行うと、クイック スタートでは、Synchrony を実行するクラスタ ノードとして 1 つ以上の Amazon EC2 インスタンスを含む Auto Scaling グループが作成されます。Confluence および Synchrony で利用可能な設定の詳細をご確認ください。

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

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

Confluence サイトが AWS でホストされている場合も、内部のオンプレミス DNS サーバーがある場合はそこに Confluence サイトの DNS をリンクすることができます。これを行うには、Amazon Route 53 を通じて、公開 DNS と内部 DNS の間にリンクを作成します。これにより、わかりやすいドメイン名を使用してインフラストラクチャ リソース (データベース、共有ホームなど) に簡単にアクセスできるようになります。DNS 設定に応じて、これらのドメイン名を外部または内部からアクセスできるようにすることができます。

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

[サービス] > [Route 53] でプライベート ホステッド ゾーンを作成します。ドメイン名は任意のドメインに設定します。VPC の場合、既存の Atlassian Standard Infrastructure を使用します。

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

ご利用のデプロイのクイック スタート テンプレートを使用して、スタックがステップ 1 のホステッド ゾーンをポイントするようにします。Confluence を初めてセットアップする場合、次のようにクイック スタート テンプレートに従います。

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

2. [Sub-domain for Hosted Zone (ホステッド ゾーンのサブドメイン)] フィールドに希望するドメインのサブドメインを入力します。空のままにしておくと、スタック名がサブドメインとして使用されます。

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

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

1. AWS コンソールで [Services (サービス)] > [CloudFormation] に移動します。

2. スタックを選択して [Update Stack (スタックの更新)] を選択します。

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

4. [Sub-domain for Hosted Zone (ホステッド ゾーンのサブドメイン)] フィールドに希望するドメインのサブドメインを入力します。空のままにしておくと、スタック名がサブドメインとして使用されます。

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

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

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

AWS 以外の DNS サーバーを使用する場合、それをデプロイの VPC (この場合は Atlassian Standard Infrastructure) にリンクする必要があります。つまり、DNS サーバーでは、Route 53 を使用して、ホステッド ゾーンで指定したドメイン (ステップ 1) へのすべてのクエリを解決する必要があります。

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

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

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

2. すでに Confluence をセットアップしている場合、AWS コンソールで [Services (サービス)] > [CloudFormation] に移動し、スタックを選択して [Update Stack (スタックの更新)] を選択します(Confluence を初めてセットアップする場合、次のようにクイック スタート テンプレートに従います)。 

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

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

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

6. Confluence で、[管理] > [一般設定] に移動し、Confluence のベース URL を Route 53 のドメインに更新します。 

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. デプロイのスタック名を選択します。これにより、デプロイのスタック情報が表示されます。そこから、[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.  スタックの更新を続けます。

垂直スケーリングと水平スケーリングの違い

負荷スパイクに対応するために、新しいクラスタ ノードを (特に自動的に) 追加することで、クラスタのキャパシティを一時的に増加させることができます。特定のしきい値を超えると、大量のクラスタ ノードの追加による効果は減少します。一般に、特にノード自体が小さい場合、各ノードのサイズを増加させる (「垂直」スケーリング) と、ノード数を増やす (「水平」スケーリング) 場合よりも大きな持続的キャパシティを扱うことができます。詳細については、「AWS でのエンタープライズ Confluence インスタンスの推奨インフラストラクチャ」を参照してください。自動スケーリング グループの詳細については、AWS のドキュメントを参照してください。 

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

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

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

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

Bastion ホストの公開 IP は、デプロイの ATL-BastionStack スタックの BastionPubIp 出力です。このスタックは、デプロイの Atlassian Standard Infrastructure (ASI) にネストされています。Bastion ホストにアクセスするには、次の例のように、ユーザー名として ec2-user を使用します。

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

ec2-user は、sudo アクセスを持ちます。root による SSH アクセスは許可されません。

アップグレード

長期サポート リリースをまだ使用していない場合、そちらへのアップグレードもご検討ください。エンタープライズ リリースでは、2 年間のサポート期間を通して、重要なバグおよびセキュリティの課題に対する修正が適用されます。これにより、セキュリティや安定性を損ねることなく、アップグレードの頻度を減らすことができます。長期サポート リリースは、機能リリースのリリース頻度でのアップグレードが難しい企業に最適です。

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

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

2. アップグレード中も Confluence Data Center を稼働させ続ける必要がある場合は、サイト保守のために読み取り専用モードを使用することをお勧めします。ユーザーはページを閲覧できますが、作成や変更を行うことはできません。 

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

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

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

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

スタックを更新するには、次の手順に従います。

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

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

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. 更新が完了したら、すべての アプリケーション ノードが終了していることを確認します。

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

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

スタックを再び更新するには、次の手順に従います。

1. デプロイの [Stack Details (スタックの詳細)] 画面で、[Update Stack (スタックの更新)] をもう一度クリックします。

2. [Select Template (テンプレートの選択)] 画面で、[Use current template (現在のテンプレートを使用)] を選択してから、[Next (次へ)] を選択します。

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

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

   1. Maximum number of cluster nodes

   2. Minimum number of cluster nodes

5. [Next (次へ)] を選択します。以降のページに進み、[Update (更新)] ボタンを使用して変更を適用します。

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

これで、デプロイをスケール アップしてアプリ ノードの数を元に戻せます。スタンドアロンの Synchrony がある場合は、Synchrony ノードでも同様に実行します。クラスタで使用されるノードの数を再設定する方法については、ステップ 1 を参照してください。

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」を参照してください。   

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

スマート ミラーリングにより、大規模なリポジトリを使用する分散チーム向けに Git クローンの速度を大幅に改善できます。ミラーリングの利点の概要については、「ミラー」を参照してください。スマート ミラーリング (およびミラーリング全般) についてのよくある質問への回答を「Bitbucket Data Center の FAQ」にも多数掲載しています。 

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