Deploy Bitbucket Data Center in AWS

このページでは、Amazon Web Services でセルフマネージドの Bitbucket Data Center および Bitbucket Server インスタンスを実行するときに利用できるオプションの概要について説明します。

Amazon Web Services (AWS) 上で Bitbucket を実行することにより、組織内でコードをホスティングする場所や方法を引き続き管理しながら、ハードウェアへの先行投資を行うことなく、拡張可能なコンピューティング キャパシティを活用できます。

アトラシアンでは次のものを提供しています。

  • クラスタ化された Bitbucket Data Center を数分でデプロイし、AWS のセキュリティと可用性のベスト プラクティスを使用する、AWS クイック スタート
  • プロセスを自動化しながら異なるデプロイメント要件向けにカスタマイズできる、Amazon CloudFormation テンプレート。 
  • よりカスタマイズされたデプロイメントを構成するアプリケーション サーバーとして Bitbucket Server を EC2 で実行するために使用できる、Amazon Mahine Image (AMI)
  • AWS で Bitbucket Server および Bitbucket Data Center インスタンスを手動でデプロイ、バックアップ、復元、サイジング、および管理するためのツールおよびガイドライン

非クラスタ環境とクラスタ環境

クラスタ化を必要とする特定の機能 (例: 高可用性) を必要としない場合、"Small" または "Medium" サイズのデプロイでは単一ノードが適しています。 

既存の Server インストールがある場合は、Data Center にアップグレードする際にそのインフラストラクチャを引き続き使用できます。Data Center 専用の多くの機能 (SAML シングル サインオンレート制限によるシステムの保護CDN サポートなど) では、クラスタ インフラストラクチャは不要です。Server インストールのライセンスをアップグレードするだけで、Data Center のこれらの機能の使用を開始できます。
 
クラスタ化が必要かどうかの詳細については「アトラシアンの Data Center 製品のアーキテクチャとインフラストラクチャのオプション」をご参照ください。


AWS クイックスタートを使用したクラスタでの Bitbucket Data Center のデプロイ

AWS に Bitbucket Data Center をデプロイする最も単純な方法は、AWS クイックスタートを使用することです。クイックスタートは、AWS のセキュリティと可用性のためのベスト プラクティスを使用して、AWS 上に特定のワークロードをデプロイするのに必要な AWS コンピュータ、ネットワーク、ストレージ、およびその他のサービスを、起動、設定、および実行します。


クイックスタートでは 2 つのデプロイメント オプションが提供され、それぞれが独自のテンプレートを持ちます。1 つめのオプションは、Atlassian Standard Infrastructure (ASI) をデプロイし、この ASI に Bitbucket Data Center をプロビジョニングします。2 つめのオプションは、既存の ASI への Bitbucket Data Center のデプロイのみを行います。

Atlassian Standard Infrastructure (ASI)

ASI は、アトラシアンのすべての Data Center 製品で必要なコンポーネントを含む仮想プライベート クラウド (VPC) です。詳細については、「AWS の Atlassian Standard Infrastructure (ASI)」をご参照ください。

以下は、Bitbucket Data Center 用の AWS クイックスタートによるデプロイのアーキテクチャの概要です。

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

    • インスタンス / ノード。Bitbucket を実行している、クラスタ ノードとしての 1 つ以上の Amazon Elastic Cloud (EC2) インスタンス。
    • ロード バランサ。ロード バランサおよび SSL ターミネート リバース プロキシの両方として機能する Amazon Elastic Load Balancer (ELB)。
    • データベース: 選択した共有データベース インスタンス – Amazon RDS または Amazon Aurora。
    • ストレージ。すべての Bitbucket ノードにアクセス可能な共通の場所にリポジトリを保存する、共有 NFS サーバー。
    • Amazon CloudWatch: Amazon のネイティブ CloudWatch サービスによる基本的なモニタリングおよび中央ログ。
    • コードおよびリポジトリ検索用の Amazon OpenSearch Service ドメイン。

アーキテクチャ、コンポーネント、およびデプロイメント プロセスの詳細については、アトラシアンのクイック スタート ガイド を参照してください。

高度なカスタマイズ

迅速な実装のため、クイック スタートでは手動インストールと同じレベルのカスタマイズは提供していません。ただし、アトラシアンで使用している Ansible プレイブックの変数を通じてデプロイメントをさらにカスタマイズできます。

アトラシアンが提供しているすべての AWS クイック スタートでは、Ansible プレイブックを使用してデプロイメントの特定のコンポーネントを構成しています。これらのプレイブックは次のリポジトリで公開されています。

https://bitbucket.org/atlassian/dc-deployments-automation

Ansible 変数を使用してこれらの構成をオーバーライドできます。詳細は、リポジトリの README ファイルを参照してください。

自身の S3 バケットからのクイック スタートの起動 (推奨)

クイック スタートをもっとも素早く起動する方法は、AWS S3 バケットから直接起動することです。だだしこれを行った場合、アトラシアンでクイック スタート テンプレートに加えているすべての更新がデプロイメントに直接伝播されます。これらの更新には、テンプレートからのパラメーターの追加や削除が含まれる場合があります。これにより、デプロイメントに予期しない (および大幅な) 変更が発生する可能性があります。

本番環境の場合、クイック スタート テンプレートを自身の S3 バケットにコピーすることをおすすめします。次に、それらをそこから直接起動します。これにより、クイック スタートの更新をデプロイメントに伝播するタイミングを制御できるようになります。

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

  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 を貼り付けます。

高可用性のための Amazon Aurora データベース

クイックスタートによって、(RDS の代わりに) Amazon Aurora クラスタ データベースを使用して Bitbucket Data Center をデプロイすることもできます。 

クラスタは PostgreSQL 互換で、2 つのデータベース リーダーをレプリケートする、プライマリ データベース ライターを備えています。冗長性を向上させるため、異なるアベイラビリティ ゾーンにライターとリーダーをセットアップすることもできます。

ライターが失敗した場合、Aurora はリーダーの 1 つを自動的にプロモートしてライターにします。詳細は「Amazon Aurora の特徴: PostgreSQL 互換エディション」 を参照してください。

新しい Amazon Aurora クラスタ データベースを手動でセットアップし、それを Bitbucket Data Center に接続する手順については、「Amazon Aurora を使用するために Bitbucket Data Center を構成する」を参照してください。Amazon Aurora は Bitbucket Data Center 6.7 以降でサポートされています。

Amazon CloudWatch による基本的なモニタリングおよび中央ログ

また、クイック スタートでは、Amazon CloudWatch によるノード管理も提供されます。これにより、各ノードの CPU、ディスク、およびネットワーク アクティビティのすべてを、事前設定済みの CloudWatch ダッシュボードから追跡できます。ダッシュボードは、最新のログ出力を表示するように設定され、後で監視および指標を追加してカスタマイズできます。

既定では、Amazon CloudWatch は各ノードからログを収集し、単一の中央ソースに保存します。この中央ログにより、デプロイのログ データをより簡単かつ効果的に検索および分析できます。詳細については、「CloudWatch Logs Insights を使用したログ データの分析」および「フィルター パターンを使用したログ データ検索」を参照してください。

Amazon CloudWatch は基本的なロギングとモニタリングを提供しますが、コストもかかります。デプロイのコストを削減するために、デプロイ中にはログを無効にするか、Amazon CloudWatch 連携をオフにすることができます。

tip/resting Created with Sketch.

ログ データをダウンロードするには (AWS 以外の場所でアーカイブおよび分析する場合など)、データを最初に S3 にエクスポートする必要があります。そこからダウンロードできます。詳しくは、「Amazon S3 へのログ データのエクスポート」を参照してください。

オート スケーリング グループ

この Quick Start は Auto Scaling グループを使用しますが、これはクラスタ ノード数の静的制御のみを目的としています。Auto Scaling を使用してクラスタのサイズを動的に拡張することは推奨されません。アプリケーション ノードのクラスタへの追加には通常 20 分以上かかりますが、この速度では突然の負荷のスパイクに対処できません。

高負荷および低負荷の期間を特定できる場合、それに応じてアプリケーション ノード クラスターのスケールをスケジュールできます。詳細については、「Amazon EC2 Auto Scalingのための拡張スケジュール」を参照してください。 

組織の負荷の傾向を調査するには、デプロイメントのパフォーマンスを監視する必要があります。実施方法のヒントについては、「Bitbucket Data Center のサンプル デプロイメントおよび監視戦略」を参照してください。 

AWS クイック スタートの CloudFormation テンプレートのカスタマイズ

迅速な実装のため、クイック スタートでは手動インストールと同じレベルのカスタマイズは提供していません。代わりに、クイック スタートで使用される CloudFormation テンプレートを必要に応じてカスタマイズできます。これらのテンプレートは以下のリポジトリで入手できます。

https://github.com/aws-quickstart/quickstart-atlassian-bitbucket

Bitbucket Data Center を AWS で管理する

AWS 内で次のような Bitbucket インスタンスの管理タスクを実行するための詳細については、「Bitbucket Data Center を AWS で管理する」を参照してください。

  • AWS で Bitbucket を起動時に変数を構成する
  • AWS で Bitbucket インスタンスをメンテナンス、リサイズ、移行、およびカスタマイズする
  • Bitbucket Server AMI 内のコンポーネントについての追加の詳細

AWS 内での Bitbucket の保護

AWS はパブリック インターネット経由でアクセスされるため、AWS で Bitbucket Server を実行するときには適切なセキュリティ基準を適用することが重要です。Amazon Virtual Private Cloud (VPC)、Security Group、および SSL を含む幅広いセキュリティ トピックのセキュリティ ガイダンスについて、「AWS で Bitbucket を保護するためのベスト プラクティス」をご確認ください。

パフォーマンスのガイドライン

AWS で Bitbucket デプロイメントの最高のパフォーマンスを実現できるよう、インスタンスの CPU、メモリ、I/O リソースのプロビジョニングを適切に行うことが重要です。アトラシアンでは、水平拡張によるパフォーマンスを実現する Bitbucket Data Center と単一ノードの Bitbucket Server インスタンスのいずれを選択した場合でも使用できる、ノード単位のベスト パフォーマンスを実現するための AWS EC2 および EBS 設定の選択についての具体的な推奨設定を提供しています。

CloudFormation テンプレートを使用している場合、これらの設定はすでに含まれています。使用していない場合、「AWS でのエンタープライズ Bitbucket インスタンスの推奨インフラストラクチャ」を参照してください。

ミラーリング

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

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

Last modified on Mar 2, 2022

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

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