AWS での Bitbucket Data Center

このページでは、Amazon Web Services (AWS) 環境に Bitbucket Data Center をデプロイする際の考慮事項について説明します。

 

Bitbucket Data Center は AWS (Amazon Web Services) 環境に最適です。AWS では、追加のノードをリサイズおよびすばやく起動することでデプロイメントを柔軟にスケーリングできるだけでなく、Bitbucket Data Center ですぐに動作する多数のマネージド サービスを利用し、あらゆる設定やメンテナンスを自動で処理できます。

AWS コンポーネント

この図は、AWS での一般的な Bitbucket Data Center デプロイメントを表しています。

このページの内容:

 

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

  • クラスタ ノードとして Bitbucket を実行している、1 つ以上の Amazon Elastic Compute Cloud (EC2) インスタンス。
    • 一般に、これらのインスタンスは Amazon Auto Scaling Group で管理され、指定された上限および下限の負荷に対応してクラスタ ノードの数を手動または自動でスケール アップまたはダウンできます。
  • 1 つの Amazon Elastic Load Balancer (ELB): ロード バランサおよび SSL ターミネートを行うリバース プロキシ。
  • 共有ホーム ディレクトリ用 Elastic Block Store (EBS) ボリュームを接続した、専用 NFS サーバーとしての EC2 インスタンス。 
  • 共有データベースとしての Amazon Relational Database (RDS) インスタンス。
  • コードおよびリポジトリ検索用の Amazon Elasticsearch Service ドメイン。
Bitbucket バージョン Bitbucket Server 4.10.0 以降。
クラスタノード Auto Scaling Group によって管理された、Bitbucket を実行する 1 つ以上の EC2 インスタンス。
ロード バランサとリバース プロキシ

リスナーを次のように構成した、Amazon Elastic Load Balancer。

ロード バランサのプロトコル ロード バランサのポート インスタンスのプロトコル インスタンスのポート
http 80 http 7991
HTTPS 443 http 7990
TCP 7999 TCP 7999

セキュリティ上の理由により、Bitbucket はポート 7991 で受信したすべての http:// リクエストを直ちに https:// にリダイレクトするよう構成されています。

NFS サーバー

クラスタの専用 NFS サーバーとして設定された 1 つの EC{6} インスタンス (Bitbucket 共有ホーム ディレクトリを保存する EBS ボリュームを持つ)。これには、Bitbucket Server のリポジトリ、添付ファイルおよびその他のデータがすべて含まれます。

データベース Amazon RDS for PostgreSQL 9.5。
Elasticsearch Amazon Elasticsearch Service、バージョン 2.3。

CloudFormation テンプレートおよびクイック スタート ガイド

AWS CloudFormation テンプレートは、AWS リソースのコレクションを説明する 1 つの JSON または YAML ファイルです。これを使用することで、すべてを 1 つの "スタック" としてまとめて作成、更新、および削除できます。AWS CloudFormation を使用したリソースの管理は、個別のリソースのデプロイおよび管理よりも短時間で実行でき、より便利です。

また、Amazon は、AWS の多数の主要アプリケーションのための標準化および自動化された参照デプロイメントとしてクイック スタートを公開しています。各クイック スタートは、セキュリティと可用性のための AWS のベスト プラクティスを使用し、AWS で特定の作業負荷をデプロイするために必要な AWS コンピュータ、ネットワーク、ストレージ、およびその他のサービスを起動、構成、および実行します。

AWS 環境で最も簡単に Bitbucket Data Center を立ち上げる方法は、クイック スタート ガイドおよび関連付けられている CloudFormation テンプレートに従うことです。完全な Bitbucket Data Center クイック スタート ガイドおよびテンプレートは次の場所から入手できます。

AWS CloudFormation およびクイック スタートでは通常、追加の AWS 料金は発生しませんが、通常の AWS のアカウント請求プロセスを使用し、CloudFormation 経由で起動されたすべての AWS リソースの支払いを行う必要があります。

(error) Note: The Bitbucket Data Center Quick Start is not available in some regions, such as govcloud-us (AWS GovCloud (US)) and cn-north-1 (China (Beijing)).

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

クラスタ ノードの数を増やすまたは減らす方法

  1. AWS コンソールで [サービス] > [CloudFormation] に移動してスタックを選択し、[スタックの更新] をクリックします。
  2. クラスタ ノードの最小数クラスタ ノードの最大数のパラメーターを必要に応じて変更します。

オート スケーリング グループでこれを検出してパラメーターに変更を適用するには、数分かかる場合があります。

クラスタ ノードの最小数と最大数に同じ数を指定した場合を除き、オート スケーリング グループには、2 つの制限間で最適な必要ノード数を実現するための、新しいクラスタ ノードの起動や、既存のものの自動終了が許可されています。既定では、このターゲット数は以下の CloudWatch メトリックによって決定されます。

  • オート スケーリング グループで 5 分間の平均 CPU 使用率が 60 % を上回った場合、ノードのターゲット数を 1 増やします (最大値まで)。
  • オート スケーリング グループで 30 分間の平均 CPU 使用率が 40 % を下回った場合、ノードのターゲット数を 1 減らします (最小値まで)。

スケーリング イベント間では、既定で 10 分間の "クールダウン" 期間も適用されます。詳細については、「メトリックに基づいたスケーリング」を参照してください。 

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

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

Bitbucket クラスタ ノードとファイル サーバーに SSH を実行して、構成またはメンテナンス タスクを実行することができます。SSH 秘密鍵ファイル (Amazon からダウンロードし、Key Name パラメータとして指定した PME ファイル) を安全な場所に保持しておく必要があります。これはインスタンス内のすべてのノードに対する鍵であり、これをなくすと "ロックアウト" されてしまう可能性があります。詳細は、「AWS で Bitbucket Data Center を管理する」を参照してください。

注: BitbucketDataCenter.template は、すべての EC2 インスタンスを、内部サブネット パラメーターで指定したサブネットに展開します。外部から到達できない内部サブネットを指定した場合、外部サブネット内で実行されていてアクセス可能な EC2 インスタンスに SSH を実行してこれを起動し、"ジャンプ ボックス" として使用して、内部サブネット内のインスタンスに対して SSH を実行する必要があります。つまり、"ジャンプ ボックス" に SSH を実行し、そこから内部サブネットにデプロイされている任意のインスタンスに SSH を実行します。

SSH 経由でインスタンスに接続する場合、ユーザー名として ec2-user を使用します。例:

ssh -i keyfile.pemec2-user@ec2-xx-xxx-xxx-xxx.compute-1.amazonaws.com

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

SSL 証明書のインストール

初めて BitbucketDataCenter.template を起動する前に、「クラシック ロード バランサ用 SSL 証明書」の説明にしたがって SSL 証明書を Amazon にアップロードしておくことをおすすめします。次に、Bitbucket Data Center を起動する際に、SSL Certificate Name パラメーターに SSL 証明書の名前を指定します。これは ELB に自動的にデプロイされ、リスナーは次のようにセットアップされます。

ロード バランサのプロトコル ロード バランサのポート インスタンスのプロトコル インスタンスのポート
http 80 http 7991
HTTPS 443 http 7990

初回起動時に SSL 証明書をセットアップしなかった場合や、SSL 証明書名パラメーターを省略した場合、ELB は次のように 1 つの HTTP リスナーでのみ構成されます。

ロード バランサのプロトコル ロード バランサのポート インスタンスのプロトコル インスタンスのポート
http 80 http 7990

 

初回起動に SSL 証明書をインストールまたは変更する方法

  1. AWS コンソールで、[サービス] > [CloudFormation] に移動してスタックを選択し、[スタックの更新] をクリックします。
  2. [SSL 証明書名] パラメーターを新しい証明書の名前に変更します。
  3. Configure the HTTP to HTTPS redirect manually in the bitbucket.properties file, located in the <Bitbucket home directory>/shared directory, as described in Redirect HTTP Requests to HTTPS.
  4. すべてのアプリケーション ノードで次のコマンドを実行して、Bitbucket サービスを再起動します。

    sudo service atlbitbucket restart
  5. Bitbucket インスタンスのホスト名が変更されている場合、「Bitbucket Server のベース URL を指定する」ページの説明にしたがい、Bitbucket のベース URL を更新する必要があります。

アップグレード

Bitbucket Server アップグレード ガイドのステップを確認し、アップグレード先の Bitbucket のバージョンのアップグレード ノートを確認します。これは、以降のステップに加えて追加ステップが必要になる場合があるためです。

Note: it is recommended to update the AMI to the latest version before upgrading Bitbucket. For some versions, such as Bitbucket Server 5.0, the latest AMI is required. The latest AMI IDs are referenced in the  BitbucketDataCenter.template in the bitbucket.org repository.

To upgrade a Bitbucket Data Center instance launched from BitbucketDataCenter.template:

  1. AWS コンソールで [サービス] > [CloudFormation] に移動してスタックを選択し、[スタックの更新] をクリックします。
  2. バージョン パラメータを新しいバージョンに変更します (この操作をおこなっても既存のクラスタ ノードはアップグレードされませんが、オート スケーリング グループで起動された新しいノードがその新しいバージョンになります)。
  3. 既存のクラスタ ノードを終了し、オート スケーリング グループに対し、新しいバージョンを実行する新しいノードを起動することを許可します。

Bitbucket Data Center では現在、古いバージョンの最後のクラスタ ノードのシャットダウンと新しいバージョンの最初のクラスタ ノードの起動の間のダウンタイムが必須であり、インスタンスをダウンタイムなしでアップグレードすることはできません。

バックアップ

BitbucketDataCenter.template から起動した各 Bitbucket Data Center インスタンスには、ゼロダウンタイム バックアップ用に Amazon EBS および RDS スナップショットを使用するように事前にインストールおよび設定された、Bitbucket DIY Backup ユーティリティが付属しています。ファイル サーバー インスタンスに SSH を使用し、次のコマンドを実行します。

cd /opt/atlassian/bitbucket-diy-backup
git pull
./bitbucket.diy-backup.sh

This script can also be run on a regular schedule (e.g., hourly), from cron. See Using Bitbucket zero downtime backup for more information.

ミラーのデプロイ

AWS で既存の Bitbucket Data Center インスタンスのミラーをデプロイする方法

  1. Deploy BitbucketServer.template, with the Bitbucket properties parameter set to application.mode=mirror.

  2. 新しいミラー インスタンスに SSH 接続し、「SSL を使用して nginx の内側にある Bitbucket Server を保護する」の説明にしたがって SSL 証明書をインストールします。

  3. 新しいミラーのセットアップ ウィザードを通常どおり進めます。

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

ディザスタ リカバリのスタンバイ インスタンスのデプロイ

AWS に既存の Bitbucket Data Center インスタンスのディザスタ リカバリ用スタンバイをデプロイする方法

  1. Find out the Amazon Resource Name (ARN) of your primary instance's RDS database. This is given by the DBMaster output of your primary's CloudFormation stack, and will be a string of the form arn:aws:rds:eu-west-1:123456789012:db:qdc37u5sysye14.
  2. この ARN に設定された Bitbucket properties パラメーターを使用して、希望する AWS リージョン (一般にはプライマリ インスタンスと同じ地域) に BitbucketDataCenter.template をデプロイします。 

    この時点で、クラスタ ノードが実行されていないスタンバイ インスタンスと、Amazon RDS のリード レプリカ データベースがあるはずです。

  3. atlassian-bitbucket-diy-backup 変数を次のように構成し、「Bitbucket Data Center のディザスタ リカバリ ガイド」にしたがいます。

    BACKUP_HOME_TYPE=zfs
    BACKUP_DATABASE_TYPE=amazon-rds

    DR_RDS_READ_REPLICA=<RDS リード レプリカの識別子>
    STANDBY_JDBC_URL=jdbc:postgresql://<endpoint of your RDS read replica>.rds.amazonaws.com:5432/bitbucket

プライマリ Bitbucket インスタンスからディザスタ リカバリ用のスタンバイにフェイルオーバーを行う必要がある場合、上記の スケール アップおよびスケール ダウン セクションに記載されているように、スタンバイ スタックのクラスタ ノードの最小数パラメーターを更新することでクラスタ ノードを起動できます。

詳細については、「Bitbucket Data Center のディザスタ リカバリ ガイド」を参照してください。

AWS への既存のインスタンスの移行

AWS に既存のインスタンスを移行する方法

  1. データベースを PostgreSQL に移行していない場合、移行を行います。
  2. Bitbucket Server DIY Backup」にしたがい、既存のホーム ディレクトリとデータベースのバックアップを作成します。
  3. バックアップ ファイルをファイル サーバー EC2 インスタンスにコピーします。
  4. Unpack the backup file under /media/atl/bitbucket/shared of your file server.
  5. Restore the PostgreSQL database dump contained in the backup file to your RDS instance with pg_restore .
最終更新日 2017 年 7 月 6 日

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

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