Bitbucket Server を AWS で管理する

AWS 上の Bitbucket で作業する際は、ノードの追加や既存のノードのアップグレードによって環境を拡張したり、それらに SSH 経由で接続したりすることができます。

SSH を使用したインスタンスへの接続

You need your SSH private key file (the PEM file you downloaded from Amazon and specified as the Key Name parameter) in a safe to access all your nodes. Keep this key safe; if you lose it, you may find yourself locked out of your deployment.

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

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

The ec2-user has sudo access. The Atlassian Bitbucket Server AMI does not allow SSH access by root

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

Configure SSL to enable HTTPS

To enhance Bitbucket's security, you should use a proper SSL certificate obtained from a reputable Certificate Authority (CA). See Securing Bitbucket in AWS for instructions on how to do this.

インスタンスのバックアップ

Atlassian Bitbucket Server AMI には、AWS 用に作成された Bitbucket Server DIY Backup スクリプトの完全なセットが含まれます。インスタンスのバックアップおよび復元方法については、「AWS で Bitbucket Server DIY Backup を使用する」を参照してください。

インスタンスのアップグレード

Before upgrading to a later version of Bitbucket Data Center:
  1. Check if your apps are compatible with that version. Update your apps if needed. For more information about managing apps, see Using the Universal Plugin Manager.
  2. Enable integrity checks (if you haven't already). 

We strongly recommend that you perform the upgrade first in a staging environment before upgrading your production instance. How to establish staging server environments for Bitbucket Server provides helpful tips on doing so.

To upgrade to a later version of Bitbucket in AWS, you must first connect to your instance using SSH, then follow the steps in the Bitbucket Server upgrade guide.

EC2 インスタンスの停止と開始

Atlassian Bitbucket Server AMI から起動した EC2 インスタンスは、他のマシンと同様にいつでも停止 / 起動できます。

EC2 インスタンスを停止する前に必要な手順

  1. Stop the atlbitbucketatlbitbucket_search, and postgresql93 services.
  2. Unmount the /media/atl filesystem.

停止 / 再起動後に EC2 インスタンスを利用できなくなった場合

インスタンスへのアクセスに、固定のプライベート IP アドレスまたは Elastic IP アドレスではなく Amazon で自動的に割り当てられたパブリック IP アドレスを使用している場合、EC2 インスタンスのバックアップを再び起動すると、IP アドレスが変更されている場合があります。これが発生すると、インスタンスにアクセスできなくなり、"The host name for your Atlassin instance has changed" ページが表示されます。これを修正するには、Bitbucket Server インスタンスのホスト名を更新する必要があります。

Bitbucket Server インスタンスのホスト名を更新する方法

  1. このコマンドを実行してすべてのアプリケーション ノードで Bitbucket サービスを再起動します。これにより、ホスト名が更新されます。

    sudo service atlbitbucket restart
  2. Bitbucket Server が再起動するのを待ちます。
  3. Bitbucket Server のベース URL をパブリック DNS 名または IP アドレスにセットアップした場合、管理画面で Bitbucket Server のベース URL を更新して変更を反映させます。

既存の Bitbucket Server インスタンスまたは Bitbucket Data Center インスタンスの AWS への移行

Migrating an existing instance to AWS involves moving consistent backups of your ${BITBUCKET_HOME} and your database to the AWS instance.

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

  1. Bitbucket Server ナレッジベースで、既知の問題がないかどうかを確認します。
  2. ユーザーに対し、今後のサービス停止を周知します。
  3. 新しいサーバーがユーザー ディレクトリに接続できない場合にロックアウトされないよう、Bitbucket Server の内部ディレクトリでインスタンスの SYSADMIN  権限を持つユーザーを作成します。
  4. Bitbucket Server Backup Client (Bitbucket Server のみ) または Bitbucket Server DIY Backup (Bitbucket Server または Data Center) でインスタンスのバックアップを作成します。
  5. クイックスタートの手順を使用し、CloudFormation テンプレートを使用して AWS で Bitbucket Server を起動します。
  6. SSH を使用して AWS EC2 インスタンスに接続し、バックアップ ファイルをアップロードします。
  7. バックアップを作成したときと同じツールを使用してバックアップを復元します。
  8. 必要に応じて、${BITBUCKET_HOME}/shared/bitbucket.properties ファイルの JDBC 設定を更新します。

Bitbucket Server インスタンスでのデータ ボリュームのリサイズ

既定では、Atlassian Bitbucket Server AMI で起動したインスタンスのアプリケーション データ ボリュームは標準の Linux ext4 ファイルシステムであり、標準の Linux コマンド ライン ツールを使用してリサイズできます。

Bitbucket Server インスタンスでデータ ボリュームをリサイズする方法

  1. Stop the atlbitbucketatlbitbucket_search, and postgresql93 services.
  2. Unmount the /media/atl filesystem.
  3. リサイズするボリュームのスナップショットを作成します。
  4. EC2 インスタンスと同じアベイラビリティ ゾーンで、必要なサイズの新しいボリュームをスナップショットから作成します。
  5. Detach the old volume and attach the newly resized volume as /dev/sdf.
  6. Resize /dev/sdf using resize2fs, verify that its size has changed, and remount it on /media/atl
  7. Start the atlbitbucketatlbitbucket_search, and postgresql93 services.

詳細については、「Linux で EBS ボリュームのストレージ スペースを拡大する」、「Linux パーティションを拡大する」、Linux マニュアル ページの resize2fs および関連コマンドを参照してください。 

インスタンス間での Bitbucket Server データ ボリュームの移動

ステージングおよび本番環境をセットアップする場合や、インスタンスを別のアベイラビリティ ゾーンに移動させる場合など、Bitbucket Server データを別のインスタンスに移動させる必要がある場合があります。 

Bitbucket Server データ ボリュームを別のインスタンスに動かすには、2 つのアプローチがあります。

  1. Bitbucket Server DIY Backup でデータ ボリュームのバックアップを作成し、新しいインスタンス上に復元します。このオプションについては、「AWS で Bitbucket Server DIY Backup を使用する」を参照してください。 
  2. 既存のデータ ボリュームのスナップショットを使用して、Atlassian Bitbucket Server AMI から新しいインスタンスを起動します。

    Bitbucket Server データ ボリュームは、元のバージョン以降の Bitbucket Server インスタンスにのみ移動できます。

既存の Bitbucket Server データ ボリュームを使用して Bitbucket Server AMI から新しいインスタンスを起動する方法

  1. Stop the atlbitbucketatlbitbucket_search, and postgresql93 services on your existing Bitbucket Server instance.
  2. Unmount the /media/atl filesystem.
  3. Bitbucket Server データ ボリューム (/dev/sdf としてインスタンスに接続されているもの) のスナップショットを作成します。
  4. スナップショットの生成が完了したら、「Bitbucket Server を AWS で手動で開始する」の手順に従い、Atlassian Bitbucket Server AMI から新しいインスタンスを起動します。ストレージを追加する際は、次のように、EBS ボリューム デバイスを /dev/sdf  に変更し、作成されたスナップショットの ID を入力します。
  5. アベイラビリティ ゾーンの移動 (またはインスタンスの停止および新しいインスタンスの開始) によって、ユーザーが Bitbucket Server インスタンスにアクセスするために使用するホスト名 (プライベートまたはパブリック) が変更された場合、SSH で接続して
    sudo /opt/atlassian/bin/atl-update-host-name.sh <newhostname>
    を実行する必要があります。ここで、<newhostname> は新しいホスト名です。 
  6. Bitbucket Server が再起動したら、新しいインスタンスを完全に使用できます。 
  7. If the host name has changed you should also update the JDBC URL configuration in the bitbucket.properties file (typically located in /var/atlassian/application-data/bitbucket/shared/), as well as Bitbucket Server's base URL in the administration screen to reflect this.

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

To increase or decrease the number of cluster nodes

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

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

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

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

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

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

最終更新日 2019 年 6 月 7 日

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

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