How to establish staging server environments for Bitbucket Server

お困りですか?

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

コミュニティに質問

プラットフォームについて: Server および Data Center のみ。この記事は、Server および Data Center プラットフォームのアトラシアン製品にのみ適用されます。

Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Fisheye および Crucible は除く

目的


このドキュメントでは、Bitbucket のエンタープライズ環境のセットアップについてのベストプラクティスをご説明します。

  • 変更のロールアウトに関連して、手順面のガバナンスについてのベストプラクティスの推奨事項
  • Recommendations for development/staging/production architecture
  • 非本番サーバーのデプロイ方法についての技術的な手順

前提事項

  • For this document, we are assuming that as an administrator, you would rather script changes. Therefore we have omitted UI-based changes or separate tools such as the database configuration tool in favor of specifying file system locations.

On this page:

tip/resting Created with Sketch.

注意:

  • このドキュメントで記載されている手順は Bitbucket Server バージョン 4.0 以降で操作します。
  • Please read the entire document before bringing a staging server live. There are risks associated with connecting to production instances that require attention, which is called out in the document.

1. アーキテクチャ方針

多くのシステム管理チームは自社のエンタープライズ アプリケーションについて、ステージング環境やフェイルオーバー セットアップなどのアーキテクチャを確立しています。このドキュメントの推奨事項は、そのような組織全体の方針の変更や置換を意図するものではありません。アトラシアン製品をステージング環境で取り扱う際に考慮すべき点を明らかにするものです。 

定義

このドキュメントの説明では、次のように用語を定義します。

  • Production: your live instance, expecting minimal downtime and well-tested changes.
  • ステージング: 本番の前段階の環境。システム管理チームがロールアウト前に正確な手順を確立できる。
  • 開発: 全員が利用できる自由な環境。ユーザーは最先端の変更やリスクを伴う変更を試すことができる。 
推奨事項

アトラシアン製品がクリティカルなシステムである場合、開発、ステージング、本番の 3 階層のアーキテクチャを推奨します。

  • ステージング環境の主な目的は、本番段階に進む前の変更やアップグレードをシステム管理者がテストすることです。
  • 開発環境は、さまざまな事業単位が本番環境へのロールアウトを依頼する前に変更を独自でテストする場所です。

2. ガバナンス方針

In addition to architecture, we also recommend establishing a governance strategy for changes. This could include:

  • プラグイン インストール リクエストのデプロイとテストのための戦略作成。ある環境で非常に有用なプラグインが大規模なクリティカル システムでは適切でないことがあることに注意してください。
  • 開発環境のリフレッシュ タイムラインの公開。

3. How to refresh a Staging Server

ここでは、既存のステージング インストールを保有しているものと仮定しています。お持ちでない場合は、これらの手順を利用してステージング環境をセットアップできます。 

ステージング サーバーのセットアップが本番環境に影響しないように十分配慮してください。ステージング (または開発) サーバーを起動する前に、以降のヒントをご確認ください。

3.1 以降の代替策のいずれかを利用して本番環境の完全なバックアップを作成

  1. Bitbucket Server Backup Client (not supported by Bitbucket Data Center)
  2. Bitbucket DIY Backup

3.2 本番環境のバックアップ全体をステージング環境にコピー 

  1. ステージング サーバーをシャットダウンします。
  2. バックアップに利用した方法に基づき、バックアップをステージング環境に復元します。 
    1. Backup Client から新しく作成した DB を利用するように復元
    2. DIY Backup の復元
  3. システム環境変数 BITBUCKET_HOME が適切に設定されていることを確認します。詳細については「Bitbucket Server のホーム ディレクトリの設定」をご確認ください。

3.3 ステージング環境で固有の構成を実施

これは非常に重要です。ステージング環境が本番環境のデータベースを参照しないようにします。 

DIY を利用した場合
  • ステージング データベースを参照するようにデータベース接続を構成します。BITBUCKET_HOME/sharedbitbucket-config.properties を編集します。 
  • Fix your <BBS_HOME>/shared/server.xml . In case you had a reverse proxy you need to remove the reference to the old name, otherwise, your new instance will redirect you to the production environment:
<Connector port="7990"
     protocol="HTTP/1.1"
     connectionTimeout="20000"
     useBodyEncodingForURI="true"
     redirectPort="443"
     compression="on"
     compressableMimeType="text/html,text/xml,text/plain,text/css,application/json,application/javascript,application/x-javascript"
     secure="true"
     scheme="https"
     proxyName="mycompany.com" 
     proxyPort="443" />

Bitbucket Server 5.0+ を利用している場合、プロキシ構成は bitbucket.properties で行われており、server.xml は利用されていません。

tip/resting Created with Sketch.

既存の Bitbucket Server インストールでデータベース (例: BitbucketServerDB) を利用していて、新しい Bitbucket Server インストールが同じマシンまたはデータベース サーバーで実行されている場合、新しいデータベースを別の名前で作成します (Bitbucket Server 4.0.2 に対して BitbucketServerDB_402 などの、直感的なもの)。Oracle では、ピリオドやアンダーバーを持つスキーマ名はサポートされません。新しいデータベースに、古い Bitbucket Server データベースと同じアクセス権限があることを確認します。

Restore クライアントを利用した場合
  • このクライアントは、指定されたパラメーターを bitbucket.properties ファイル (新しく復元された Bitbucket Server のホーム ディレクトリのBITBUCKET_HOME/sharedbitbucket.properties) に書き込みます。これは、Backup Client からの復元で新しく作成された DB を利用する手順 (ステップ 3.2) の一環として行われます。
  • Fix your <BBS_HOME>/shared/server.xml . In case you had a reverse proxy you need to remove the reference to the old name, otherwise, your new instance will redirect you to the production environment:

Bitbucket Server 5.0+ を利用している場合、プロキシ構成は bitbucket.properties で行われており、server.xml は利用されていません。

3.4 ステージング環境の分離

このステップは、ステージング環境を初めてセットアップするときか、ステージング環境の前回のリフレッシュ以降に本番環境が別のサーバー/アプリケーションと連携された場合にのみ必要です。

データがコピーされて Bitbucket Server の構成が更新されたり、ステージング環境を本番 (およびほかの) 環境から完全に分離することが推奨されます。これは、ステージング インスタンスが他の連携システムに接続したりそれらとやり取りしたするのを防ぐためです。このような例には、アプリケーション リンク経由で接続されたアプリケーションや Bitbucket Server のスマート ミラーが考えられます。 

これを行うもっとも簡単な方法は、/etc/hosts (Linux) または C:\Windows\System32\drivers\etc\hosts (Windows) ファイルを編集し、すべての関連するホスト名が転送対象外の IP アドレス (例: 0.0.0.0) を指すようにすることです。例:

0.0.0.0 jira.company.com crowd.company.com mirror.us.company.com

Instead of modifying the host's file, you can also block traffic via firewall rules if you prefer.

3.5 Remove Smart Mirror settings

If you are using Smart Mirrors or Mirror Farms with your production instance, you need to remove their configuration from the staging instance before starting it, because otherwise, your staging environment may attempt to synchronize with the mirrors.

Bitbucket 8.0 以降では、初回の起動時にのみ bitbucket.properties に次のプロパティを追加することでこれを行えます。起動後にプロパティを削除またはコメント アウトします。 

# Deletes mirror configuration on startup - Should only be run once on staging only.
plugin.mirroring.delete.on.startup=true

バージョン 7.21 以前では次のクエリを利用してデータベースから構成を削除できます。

These queries must be run on the staging copy of your Bitbucket Server database. Only execute if the instance is down. They must never be run on your production database unless explicitly instructed to do so by Atlassian Support.

DELETE FROM plugin_setting WHERE key_name LIKE 'acnct.bitbucket.mirror.%';
DELETE FROM plugin_setting WHERE key_name = 'ac.addon.list' AND key_value LIKE '%mirror%';
DELETE FROM "AO_8E6075_MIRRORING_REQUEST";
DELETE FROM "AO_8E6075_MIRROR_SERVER";

3.6 Disable webhooks

The existing webhooks may try to contact production resources when triggered by Git activity. In order to avoid this from happening, you can disable the webhooks via the database:

  1. View the webhooks:

    -- The select query below is an example for a specific webhook name. Remove the where clause to retrieve all webhooks.
    select a.*, r.name from "AO_A0B856_WEBHOOK" a JOIN repository r on cast(a."SCOPE_ID" as integer)=r.id where a."NAME" = "Test";
  2. Run the update query to disable webhooks:

    These queries must be run on the staging copy of your Bitbucket Server database. Only execute if the instance is down. They must never be run on your production database unless explicitly instructed to do so by Atlassian Support.

    -- The update query below is an example for a specific webhook name. Remove the where clause to update all webhooks.
    update "AO_A0B856_WEBHOOK" where "NAME" = "Test"
    set "ACTIVE" = false;

3.7 Remove OAuth ConsumerService record from plugin_setting table

Remove com.atlassian.oauth.consumer.ConsumerService:host.__HOST_SERVICE__   record from plugin_setting table. This record contains oauth private key and Bitbucket Base URL which is referenced while creating application links with other Atlassian Products.
(warning) Having this record in the Bitbucket staging instance can lead to the display of Bitbucket production Base URL in integrated applications (such Jira, Jira Cloud, Bamboo etc.,) instead of Bitbucket staging URL.

delete from plugin_setting where key_name like '%com.atlassian.oauth.consumer.ConsumerService:host.__HOST_SERVICE__%';

(info) Note that Bitbucket automatically creates the record (if not present) with the current instance setup during the process of creating application links.

3.8 ステージング サーバーの再起動

これで、サーバーを再起動する準備が整いました。再起動したら、前述の手順を安全に実行したことを確認するために次の事項を確認してください。

  1. データベースが本番環境を参照していないことを確認します。これを確認するには、[管理] > [サポート ツール] > [データベース情報] に移動してシステム情報を確認します。[接続 URL] が適切な場所を指しているのを確認します。
  2. Ensure emails are disabled or configured for the dev server. (Administration > Mail server)

3.9 起動後の修正

  1. If you can't log in. It could be that the External Directory that was configured in production is not available from the restored instance for some reason. You can get around this by using the Lockout recovery process procedure, removing the external directory, creating an admin account, log out, and start using the new admin account to perform your instance configuration.
  2. サイトのベース URL の更新。Bitbucket のベース URL の指定」を参照してサイトの URL をステージングの URL に変更します。
  3. Apply for a Development License.  See our licensing FAQ to generate a license for the staging server. Refer to Update your license key to apply it.
  4. Reconfigure app links. If you are connecting to other servers via app links, you'll need to change the server ID for those instances. 

    tip/resting Created with Sketch.

    If you leave app links in place, it's possible to have your production instance point back to the staging server, if a link is generated.

  5. CI ツールをご利用の場合はビルドをトリガーする hook が構成されていないことを確認します。Bamboo を利用している場合、アプリケーション リンクを無効化したタイミングで対応できます。Jenkins 等を利用している場合はこれらの hook を手動で無効化または削除する必要があります。 
  6. リポジトリやビルド システムに影響するプラグインについては、本番システムに影響を与えるかどうかを確認する必要があります。たとえば Mirror プラグインを利用している場合、ステージング環境へのプッシュが外部の本番システムにミラーされないように接続を編集する必要があります。


最終更新日 2024 年 6 月 14 日

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

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