Bitbucket Data Center を AWS で管理する

このページの内容

お困りですか?

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

コミュニティに質問

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

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

SSH を使用して、デプロイでノードレベルの構成または保守タスクを実行できます。これを実行するには、SSH 秘密鍵ファイル (Key Name パラメータに指定した PME ファイル) が必要です。このキーはデプロイ内のすべてのノードにアクセスできるため、安全な場所に保管するようにします。

デプロイへのアクセスを制限するため、アトラシアンのクイック スタートでは Bastion ホストをデプロイしています。SSH を使用してデプロイに接続するには、まず Bastion ホストにアクセスする必要があります。このホストは、デプロイの内部サブネットの任意のインスタンスへの ”踏み台” として機能します。つまり、まず SSH で Bastion ホストに接続し、そこからデプロイ内の任意のインスタンスに接続します。 

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

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

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

tip/resting Created with Sketch.

AWS Systems Manager の Session Manager を使用してデプロイ内のインスタンスに直接アクセスすることもできます。この場合、Bastion ホストへの接続はまったく不要となります。

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

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

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

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

アップグレード

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

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

Upgrading a Bitbucket Data Center on AWS involves three steps:

Step 1: Terminate all running Bitbucket Data Center application nodes

Set the number of application nodes used by the Bitbucket Data Center stack to 0. Then, update the stack.

Click here for detailed instructions


  1. In the AWS console, go to Services > CloudFormation. Select your deployment’s stack to view its Stack Details.

  2. In the Stack Details screen, click Update Stack.

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

  4. You’ll need to terminate all running nodes. To do that, set the following parameters to 0:

    1. Maximum number of cluster nodes

    2. Minimum number of cluster nodes

  5. Click Next. Click through the next pages, and then to apply the change using the Update button.

  6. Once the update is complete, check that all application nodes have been terminated.




Step 2: Update the version used by your Bitbucket Data Center stack

Set the number of application nodes used by Bitbucket Data Center to 1. Configure it to use the version you want. Then, update the stack again.

Click here for detailed instructions

  1. From your deployment’s Stack Details screen, click Update Stack again.

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

  3. Set the Version parameter to the version you’re updating to.

  4. Configure your stack to use one node. To do that, set the following parameters to 1:

    1. Maximum number of cluster nodes

    2. Minimum number of cluster nodes

  5. Click Next. Click through the next pages, and then to apply the change using the Update button.


Step 3: Scale up the number of application nodes

You can now scale up your deployment to your original number of application nodes. For detailed instructions on how do to this, see Scaling up and down.


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

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

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

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

停止 / 再起動後に 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 への移行

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

既存のインスタンスを 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. atlbitbucketatlbitbucket_searchpostgresql93 サービスを停止します。
  2. /media/atl ファイルシステムをアンマウントします。
  3. リサイズするボリュームのスナップショットを作成します。
  4. EC2 インスタンスと同じアベイラビリティ ゾーンで、必要なサイズの新しいボリュームをスナップショットから作成します。
  5. 古いボリュームを接続解除し、新しくリサイズされたボリュームを /dev/sdf として接続します。
  6. resize2fs を使用して /dev/sdf のサイズを変更し、サイズが変更されたことを確認してから /media/atl 上に再度マウントします。 
  7. atlbitbucketatlbitbucket_searchpostgresql93 サービスを開始します。

詳細については、「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. 既存の Bitbucket Server インスタンス上で atlbitbucketatlbitbucket_searchpostgresql93 サービスを停止します。
  2. /media/atl ファイルシステムをアンマウントします。
  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. ホスト名が変更された場合は、bitbucket.properties   ファイル (一般には /var/atlassian/application-data/bitbucket/shared/ にあります) の JDBC URL 構成、および管理画面の Bitbucket Server のベース URL を更新して、変更を反映させる必要があります。

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

To increase or decrease the number of application nodes:

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

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

最終更新日: 2019 年 9 月 24 日

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

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