Administer Bitbucket Data Center in AWS

このページの内容

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

デプロイ方法としての AWS クイック スタート テンプレートはアトラシアンではサポートされなくなりましたテンプレートは今後も利用できますが、保守や更新は行われません。

より効率的で堅牢なインフラストラクチャと運用のセットアップのために、Helm チャートを使用して Data Center 製品を Kubernetes クラスターにデプロイすることをお勧めします。Kubernetes へのデプロイに関する詳細はこちらをご確認ください。

AWS は、現在、AWS クイック スタート テンプレートで使用される起動設定を起動テンプレートに切り替えることを推奨していますが、AWS クイック スタート テンプレートのサポートは終了しているため、アトラシアンではこの切り替えを行う予定はありません。そのため、このテンプレートを使用して起動設定を作成することはできません。

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

Connecting to your instance using SSH

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

Bastion ホスト経由でのアクセス

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 アクセスは許可されません。


HTTPS を有効化するように SSL を構成する

Bitbucket のセキュリティを強化するには、信頼される証明局 (CA) から取得した適切な SSL 証明書を使用する必要があります。この方法については、「AWS での Bitbucket の保護」を参照してください。

Backing up your instance

The Atlassian Bitbucket Server AMI includes a complete set of Bitbucket Server DIY Backup scripts which has been built specifically for AWS. For instructions on how to backup and restore your instance please refer to Using Bitbucket Server DIY Backup in AWS.

アップグレード

Bitbucket Data Center の最新バージョンにアップグレードする前に、次の点をご確認ください。
  1. アプリにそのバージョンとの互換性があるかどうかを確認します。必要に応じてアプリを更新します。アプリの管理の詳細については、「Universal Plugin Manager の使用」を参照してください。
  2. 整合性チェックを有効にします (まだ有効化されていない場合)。 

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

AWS での Bitbucket Data Center のアップグレードは、以下の 3 つの手順で行います。

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

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

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


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




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

Bitbucket 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: アプリケーション ノードの数の拡張

これで、デプロイメントを拡張してアプリケーション ノードの数を元に戻せます。詳しい手順については、「スケール アップおよびスケール ダウン」を参照してください。


Stopping and starting your EC2 instance

An EC2 instance launched from the Atlassian Bitbucket Server AMI can be stopped and started just as any machine can be powered off and on again.

When stopping your EC2 instance, it is important to first

  1. atlbitbucketatlbitbucket_searchpostgresql93 サービスを停止します。
  2. /media/atl ファイルシステムをアンマウントします。

If your EC2 instance becomes unavailable after stopping and restarting

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

To update the hostname for your Bitbucket Server instance

  1. Restart the Bitbucket service on all application nodes by running this command, which will update the hostname

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

Migrating your existing Bitbucket Server or Bitbucket Data Center instance into AWS

既存のインスタンスを AWS に移行する作業には、${BITBUCKET_HOME}  とデータベースの一貫したバックアップを AWS インスタンスに移動する操作が含まれます。

To migrate your existing instance into AWS

  1. Bitbucket Data Center と Server ナレッジ ベースで、移行に関する既知の問題の存在を確認します。
  2. Alert users to the forthcoming service outage.
  3. 新しいサーバーがユーザー ディレクトリに接続できない場合にロックアウトされないよう、Bitbucket Server の内部ディレクトリでインスタンスの SYSADMIN  権限を持つユーザーを作成します。
  4. Take a backup of your instance with either the Bitbucket Server Backup Client (Bitbucket Server only) or the Bitbucket Server DIY Backup (Bitbucket Server or Data Center).
  5. クイックスタートの手順を使用し、CloudFormation テンプレートを使用して AWS で Bitbucket Server を起動します。
  6. Connect to your AWS EC2 instance with SSH and upload the backup file.
  7. Restore the backup with the same tool used to generate it.
  8. 必要に応じて、${BITBUCKET_HOME}/shared/bitbucket.properties ファイルの JDBC 設定を更新します。

Resizing the data volume in your Bitbucket Server instance

By default, the application data volume in an instance launched from the Atlassian Bitbucket Server AMI is a standard Linux ext4 filesystem, and can be resized using the standard Linux command line tools.

To resize the data volume in your Bitbucket Server instance

  1. atlbitbucketatlbitbucket_searchpostgresql93 サービスを停止します。
  2. /media/atl ファイルシステムをアンマウントします。
  3. Create a snapshot of the volume to resize.
  4. Create a new volume from the snapshot with the desired size, in the same availability zone as your EC2 instance.
  5. 古いボリュームを接続解除し、新しくリサイズされたボリュームを /dev/sdf として接続します。
  6. resize2fs を使用して /dev/sdf のサイズを変更し、サイズが変更されたことを確認してから /media/atl 上に再度マウントします。 
  7. atlbitbucketatlbitbucket_searchpostgresql93 サービスを開始します。

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

Moving your Bitbucket Server data volume between instances

Occasionally, you may need to move your Bitbucket Server data volume to another instance–for example, when setting up staging or production instances, or when moving to an instance to a different availability zone. 

There are two approaches to move your Bitbucket Server data volume to another instance

  1. Take a backup of your data volume with Bitbucket Server DIY Backup, and restore it on your new instance. See Using Bitbucket Server DIY Backup in AWS for this option. 
  2. Launch a new instance from the Atlassian Bitbucket Server AMI with a snapshot of your existing data volume.

    A Bitbucket Server data volume may only be moved to a Bitbucket Server instance of the same or higher version than the original.

To launch a new instance from the Bitbucket Server AMI using a snapshot of your existing Bitbucket Server data volume

  1. 既存の Bitbucket Server インスタンス上で atlbitbucketatlbitbucket_searchpostgresql93 サービスを停止します。
  2. /media/atl ファイルシステムをアンマウントします。
  3. Bitbucket Server データ ボリューム (/dev/sdf としてインスタンスに接続されているもの) のスナップショットを作成します。
  4. スナップショットの生成が完了したら、「Bitbucket を 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. Once Bitbucket Server has restarted your new instance should be fully available. 
  7. ホスト名が変更された場合は、bitbucket.properties   ファイル (一般には /var/atlassian/application-data/bitbucket/shared/ にあります) の JDBC URL 構成、および管理画面の Bitbucket Server のベース URL を更新して、変更を反映させる必要があります。

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

アプリケーション ノードの数を増減するには、次の手順を実行します。

  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 はご利用のデプロイメントのシステム負荷の急激な変化に効果的に対処できません。つまり、負荷に応じてクラスタを手動で再スケーリングする必要があります。

垂直拡張と水平拡張の違い

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 Recommendations for running Bitbucket in AWS for more information.

最終更新日 2022 年 8 月 18 日

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

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