Bitbucket Data Center 7.X のインストール (Linux, クラスター構成)

このページでは、インストーラーを利用して Bitbucket の Data Center 版を クラスター化された構成で Linux 環境にインストールする手順について紹介します。

目次


はじめに

Bitbucket をインストールする環境は以下を想定しています。

インストールディレクトリ
(Bitbucket のプログラムを配置するディレクトリ)

/opt/atlassian/Bitbucket (Bitbucket のインストーラーのデフォルト設定を利用)

ローカルホームディレクトリ

(Bitbucket のローカルデータを保存するディレクトリ)

/var/atlassian/application-data/bitbucket

共有ホームディレクトリ
(Bitbucket の共有データを保存するディレクトリ)

/var/atlassian/application-data/Bitbucket/shared

TCP ポート番号7990 (Bitbucket のデフォルトポートを利用) (情報)アトラシアン アプリケーションで使用されるポート )
SSHポート番号7999( Bitbucket のデフォルトポートを利用) (情報)アトラシアン アプリケーションで使用されるポート )
コンテキストパス
(URL でサーバー名に続く文字)
/bitbucket

インストールを実行するユーザー

root

Bitbucket 稼働ユーザー

altbitbucket (Bitbucket のインストーラーで自動で作成されるユーザーを利用)

データベース

共有ホームディレクトリ と同一のサーバーにインストールされた PostgreSQL を利用

検索サーバーOpenSearch
Java

AdoptOpenJDK JRE (Bitbucket のインストーラーに同梱の JDK を利用)

起動方法

サービスとして登録し、自動起動する


ご注意ください

Bitbucket のバージョンによってサポートされている稼働環境は異なります。
最新の情報は、サポート対象プラットフォーム のページからご確認ください。

構成例

Bitbucket をクラスター構成にする事により、一つのノードが停止しても直ちに Bitbucket のサービスが停止するという事態を避けることができ可用性は向上します。反面、システムリソースを多く消費するためサーバーの運用負荷は高くなります。詳細は Clustering with Bitbucket をご参照下さい。 

Bitbucket をクラスター化して構成する場合は、 ロードバランサーに スティッキー HTTP セッション と tcp モードのロードバランサーが必要です。また、独立した検索サーバーが必要になります。
この手順書ではロードバランサー(単一)として  HAProxy を利用し、検索サーバーとして OpenSearch, Bitbucket を 2ノード構成にした環境でのインストール手順を説明します。

他の構成例については、Data Center の構成例 (Atlassian ドキュメント) をご参照ください。


名称インストールされているシステム・ディレクトリIP アドレス
1Bitbucket ノード1
  • Bitbucket アプリケーション (Node1)
192.168.56.123
2Bitbucket ノード2
  • Bitbucket アプリケーション (Node2)
192.168.56.124
3ロードバランサ
  • HA-Proxy
192.168.56.125
4データサーバー
  • 共有データベース(PostgreSQL)
192.168.56.116
検索サーバー
  • 検索エンジン OpenSeach 
192.168.56.126
(opensearch.ricksoft.local)
6共有ディレクトリ
  • NFS
  • 共有データディレクトリ (/data/Bitbucket/sharedhome)
192.168.56.127

1.サーバーを用意する

1. Bitbucket をインストールするサーバー

Bitbucket をインストールするサーバーをノード分用意します。必要なスペックについては以下をご参照ください。

2. ロードバランサーとして利用するサーバー

ロードバランサーを用意します。ロード バランサは「ステッキー HTTP セッション  」と 「http / tcp モードバランシング」 をサポートしている必要があります。AWS 上で構築する場合は、Amazon Elastic Load Balancing を使用する必要があります。この手順書では HAProxyを利用します。

詳細は ロードバランサーの構成オプション ( Atlassian ドキュメント) や Atlassian Data Center を使用したトラフィック分布 ( Atlassian ドキュメント)   をご確認ください。

3. データベースを構成するデータサーバー

Bitbucket で利用する共有データベース (今回は PostgreSQL)をインストールするサーバーを用意します。

4. 共有データディレクトリを構成するデータサーバー

Bitbucket で利用する Git リポジトリを格納する共有データディレクトリを構築するサーバーを用意します。

5. 検索サーバー

Bitbucket で利用するOpenSearch を利用するサーバーを準備します。OpenSearch はクラスター構成も可能ですが、今回はシングルノード構成としています。検索サーバーは以下の 3つがサポートされています。

このドキュメントでは OpenSearch を利用した手順をご紹介します。

2.各サーバーにLinux をインストールする

ロードバランサーや Bitbucket を設定するサーバー、データサーバーに それぞれ Linux をインストールしてください。本ドキュメントでは CentOS を利用します(RHELや、Ubuntu などの Debian 系ディストリビューションを利用することもできます)。

 VMwareAWS などで仮想環境のサーバーに Bitbucket をインストールすることもできます。その場合、ノード1の 仮想マシン をコピーして ノード2のサーバーを作成する事も可能です。本ドキュメントでは、仮想マシンをコピーする場合としない場合の両方に対応しています。仮想マシンのコピーをする方は、このタイミングではノード2のサーバーは準備しなくて良いです。

1. 時刻の同期

ノード1、ノード2は時刻が合っていないといけないので、NTPD が必須になります。また、タイムゾーンも合わせる必要があります。他のサーバーも時刻を合わせておくと、ログ解析の時などに便利なので、時刻を同期しておきます。

ntpd がインストールされていない場合は以下のコマンドでインストールして有効化します。下記の様に Created symlink from /etc/systemd/sy....  というメッセージが表示されれば成功です。

# yum install ntp
# systemctl enable ntpd
Created symlink from /etc/systemd/system/multi-user.target.wants/ntpd.service to /usr/lib/systemd/system/ntpd.service.

以下のコマンドで、サービスを起動します。

# systemctl start ntpd

tzselect でタイムゾーンを設定します。対話形式で設定できます。下記の様に、日本で運用するならAsia/Tokyo を選択すると良いでしょう。

# tzselect
Please identify a location so that time zone rules can be set correctly.
Please select a continent or ocean.
 1) Africa
 2) Americas
 3) Antarctica
 4) Arctic Ocean
 5) Asia
 6) Atlantic Ocean
 7) Australia
 8) Europe
 9) Indian Ocean
10) Pacific Ocean
11) none - I want to specify the time zone using the Posix TZ format.
#? 5
Please select a country.
 1) Afghanistan           18) Israel                35) Palestine
 2) Armenia               19) Japan                 36) Philippines
 3) Azerbaijan            20) Jordan                37) Qatar
 4) Bahrain               21) Kazakhstan            38) Russia
 5) Bangladesh            22) Korea (North)         39) Saudi Arabia
 6) Bhutan                23) Korea (South)         40) Singapore
 7) Brunei                24) Kuwait                41) Sri Lanka
 8) Cambodia              25) Kyrgyzstan            42) Syria
 9) China                 26) Laos                  43) Taiwan
10) Cyprus                27) Lebanon               44) Tajikistan
11) East Timor            28) Macau                 45) Thailand
12) Georgia               29) Malaysia              46) Turkmenistan
13) Hong Kong             30) Mongolia              47) United Arab Emirates
14) India                 31) Myanmar (Burma)       48) Uzbekistan
15) Indonesia             32) Nepal                 49) Vietnam
16) Iran                  33) Oman                  50) Yemen
17) Iraq                  34) Pakistan
#? 19

The following information has been given:

        Japan

Therefore TZ='Asia/Tokyo' will be used.
Local time is now:      Thu Jun 16 23:16:39 JST 2022.
Universal Time is now:  Thu Jun 16 14:16:39 UTC 2022.
Is the above information OK?
1) Yes
2) No
#? 1

You can make this change permanent for yourself by appending the line
        TZ='Asia/Tokyo'; export TZ
to the file '.profile' in your home directory; then log out and log in again.

Here is that TZ value again, this time on standard output so that you
can use the /usr/bin/tzselect command in shell scripts:
Asia/Tokyo


3.データベース を用意する

サポート対象プラットフォーム に記載されている、サポートされたデータベースを構築します。本ドキュメントでは PostgreSQL を利用しますので、以下のページの手順を実施してください。
今回はデータサーバーに PostgreSQL をインストールし、Bitbucket用の共有データベースを作成します。

ご注意ください

クラスタ化した Bitbucket では、 Bitbucket 内部の組み込みデータベース(H2) をご利用いただけません。

4.ノード1の Bitbucket のインストール・セットアップ を実行する

Bitbucket Data Center 7.X のインストール (Linux, シングルノード構成)  の 4.Git をインストールする 以降を実行します。

ここでは Bitbucket ver.7.18.1 をインストールします。インストールする Bitbucket のバージョンが異なる場合は、バージョンの部分を読み替えて実行をお願いします。

1.Bitbucket の 起動オプションの設定

クラスターモードで Bitbucket を稼働させる場合、検索エンジンは Bitbucket サーバーではなく独立したサーバーで稼働させる必要があります。そのため、起動オプションに  --no-search を指定する必要があります。systemd の設定 を実施している場合、/usr/lib/systemd/system/bitbucket.service を編集します。

# vi /usr/lib/systemd/system/bitbucket.service

下記の様に ExecStart のパラメータに --no-search  を追加してください。

/usr/lib/systemd/system/bitbucket.service を編集
ExecStart=/opt/atlassian/bitbucket/7.21.2/bin/start-bitbucket.sh --no-search 

ファイルを修正したら、以下のコマンドで reload します。

# systemctl daemon-reload

5.共有ディレクトリをセットアップする

クラスタ内のすべてのノードで読み取り/書き込み可能な共有ディレクトリを作成します。今回は、専用サーバーに共有ディレクトリを作成し、NFS で他ノードへ共有する場合の手順を紹介します。

1.ノード1の Bitbucket のサービスを停止する

Bitbucket が起動している場合は、以下のコマンドを実行し Bitbucket を停止します。
※ RHEL 7 や CentOS 7 系の OS をご利用で systemd の設定 を実施している場合は以下のコマンドで実行できます。

# systemctl stop bitbucket

2.バックアップ

作業に入る前に、Bitbucket の インストールディレクトリ (/opt/atlassian/bitbucket) と ローカルホームディレクトリ (/var/atlassian/application-data/bitbucket) のバックアップを取得する事をお勧めします。

3.共有ディレクトリサーバーで共有ディレクトリを作成する

共有ディレクトリサーバーで、以下のコマンドを実行し、共有ディレクトリを作成します。

# mkdir -p /data/bitbucket/shared

ノード1の Bitbucket のローカルホームディレクトリにある shared フォルダを、共有ディレクトリサーバーの共有ディレクトリ配下へコピーします。
例として、ノード1の Bitbucket サーバー上で以下のコマンドを実行すると、rsync コマンド利用して共有データディレクトリ配下へコピーできます。

# rsync -auz -e ssh /var/atlassian/application-data/bitbucket/shared 192.168.56.127:/data/bitbucket

(情報) rsync がインストールされていない場合は、以下のコマンドでインストールできます。

# yum -y install rsync 


共有ディレクトリの権限を設定します。

# useradd atlbitbucket
# chown -R atlbitbucket:atlbitbucket /data/bitbucket/shared

(情報)   共有ディレクトリサーバーとBitbucket の各ノードの atlbitbucket ユーザーアカウントの UID は統一している必要が有ります。詳細は Bitbucket サーバーの各ノードのユーザーID を統一する をご参照下さい。

4.共有ディレクトリサーバーで NFS を設定する

(情報) 共有ディレクトリサーバーとBitbucket の各ノードの atlbitbucket ユーザーアカウントの UID は統一している必要が有ります。Bitbucket サーバーの各ノードのユーザーID を統一する をご確認下さい。

共有ディレクトリサーバーで、nfs-utils と rpc bind, dbus パッケージをインストールします。

# yum -y install rpcbind nfs-utils

以下のコマンドを実行し、設定用のファイルを作成します。

# vi /etc/exports

共有ディレクトリを読み書き許可する範囲を指定します。 以下の例は、192.168.56.1~192.168.56.254 の範囲で許可します。 参考:アプリケーション クラスタ ノードのプロビジョニング

/etc/exports に追加
/data/bitbucket/shared 192.168.56.0/24(rw,sync,no_root_squash,no_all_squash)

以下のコマンドを実行し、設定用のファイルを変更します。

# vi /etc/sysconfig/nfs

LOCKD_TCPPORT と LOCKD_UDPPORT の コメントを外して有効化します。

/etc/sysconfig/nfs を編集
# TCP port rpc.lockd should listen on.
LOCKD_TCPPORT=32803
# UDP port rpc.lockd should listen on.
LOCKD_UDPPORT=32769

NFS と rpc bind を起動します。

# systemctl start nfs
# systemctl start rpcbind

 以下のコマンドで、OS 起動時に nfs 関連サービスが自動起動するように設定します。

# systemctl enable nfs rpcbind

以下のコマンドで Firewall を設定し、設定を反映させます。

# firewall-cmd --permanent --zone=public --add-service=nfs
# firewall-cmd --permanent --zone=public --add-service=mountd
# firewall-cmd --permanent --zone=public --add-service=rpc-bind
# firewall-cmd --permanent --zone=public --add-port=111/tcp
# firewall-cmd --permanent --zone=public --add-port=111/udp
# firewall-cmd --permanent --zone=public --add-port=32769/udp
# firewall-cmd --permanent --zone=public --add-port=32803/tcp
# firewall-cmd --reload

5. ノード1でNFSを設定・ディレクトリをマウントする。

ノード1の Bitbucket のサーバで、nfs-utils と rpc bind パッケージをインストールします

# yum -y install rpcbind nfs-utils

NFS と rpc bind を起動します。

# systemctl start nfs
# systemctl start rpcbind


以下のコマンドで、OS 起動時に nfs 関連サービスが自動起動するように設定します。

# systemctl enable nfs rpcbind

以下のコマンドで Firewall を設定し、設定を反映させます。

# firewall-cmd --permanent --zone=public --add-service=nfs
# firewall-cmd --permanent --zone=public --add-service=mountd
# firewall-cmd --permanent --zone=public --add-service=rpc-bind
# firewall-cmd --permanent --zone=public --add-port=111/tcp
# firewall-cmd --permanent --zone=public --add-port=111/udp
# firewall-cmd --reload

ノード1の Bitbucket のサーバで、以下のコマンドを実行し、共有ディレクトリを削除します。

(情報) 削除前に、/var/atlassian/application-data/bitbucket/shared のバックアップがとられている事を確認して下さい。もし取られていないと作業に失敗した場合、今まで作成した リポジトリーなどのデータが消失してしまいます。
(情報) ノード2以降の、追加のサーバーの作業の場合は削除は必要有りません。

# rm -rf /var/atlassian/application-data/bitbucket/shared

ノード1の Bitbucket のサーバで、以下のコマンドを実行し、共有ディレクトリのマウントポイントを作成します。

# mkdir -p /var/atlassian/application-data/bitbucket/shared

マウントポイントの権限を設定します。

# chown -R atlbitbucket:atlbitbucket /var/atlassian/application-data/bitbucket/shared

/etc/fstab に参照先のサーバーの共有フォルダ情報を追加します。

# vi /etc/fstab

以下の行を追加します。以下は参照先のサーバーのIPアドレスが「192.168.56.127」、共有ディレクトリのパスが「/data/bitbucket/shared」である例です。

/etc/fstab に追加
192.168.56.127:/data/bitbucket/shared /var/atlassian/application-data/bitbucket/shared nfs rw,nfsvers=3,lookupcache=pos,noatime,intr,rsize=32768,wsize=32768,_netdev 0 0

以下のコマンドを実行し、ネットワーク経由で NFS マウントします。成功した場合でも特にメッセージは表示されません。

# mount /var/atlassian/application-data/bitbucket/shared


dfコマンドを実行し、マウントが完了しているか確認します。下記の最終行の様に表示されれば成功です。

# df -h
ファイルシス                          サイズ  使用  残り 使用% マウント位置
devtmpfs                                2.9G     0  2.9G    0% /dev
tmpfs                                   2.9G     0  2.9G    0% /dev/shm
tmpfs                                   2.9G  8.6M  2.9G    1% /run
tmpfs                                   2.9G     0  2.9G    0% /sys/fs/cgroup
/dev/mapper/centos-root                  27G  3.5G   24G   13% /
/dev/sda1                              1014M  195M  820M   20% /boot
tmpfs                                   581M     0  581M    0% /run/user/0
192.168.56.127:/data/bitbucket/shared   6.2G  1.9G  4.4G   30% /var/atlassian/application-data/bitbucket/shared

6.ノード1の Bitbucket をクラスタモードへ変更する

1.構成ファイル変更

ノード1にて、共有ディレクトリの bitbucket.properties を編集します。

# vi /var/atlassian/application-data/bitbucket/shared/bitbucket.properties

以下の3行を追加します。

/var/atlassian/application-data/bitbucket/shared/bitbucket.properties に追加
hazelcast.network.multicast=true
hazelcast.group.name=your-bitbucket-cluster
hazelcast.group.password=xxxxxxxx
  • hazelcast.group.name は任意の名前で構いませんが、ネットワーク内でユニークなものにして下さい。本番用と検証用の Bitbucket があった場合は、それぞれ別々の名前にして下さい。
  • hazelcast.group.password には クラスター認証用のパスワードを設定してください。上記ではマスクしています。

2.Bitbucket サーバーの Firewall 設定

クラスタリングのノード間の通信ポートを開放します。

# firewall-cmd --permanent --zon=public --add-port=5701/tcp
# firewall-cmd --permanent --zon=public --add-port=5701/udp
# firewall-cmd --reload

(情報) 参考資料:アトラシアン アプリケーションで使用されるポート

7.ロードバランサを設定する

1.ロードバランサー様サーバーの作業

ロードバランサにするサーバーへ  HAProxy をインストールします。

# yum -y install haproxy

Bitbucket 分散用 に haproxy の設定ファイルを修正します。

# vi /etc/haproxy/haproxy.cfg


/etc/httpd/conf/extra/httpd-proxy.conf の編集結果
#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
    # to have these messages end up in /var/log/haproxy.log you will
    # need to:
    #
    # 1) configure syslog to accept network log events.  This is done
    #    by adding the '-r' option to the SYSLOGD_OPTIONS in
    #    /etc/sysconfig/syslog
    #
    # 2) configure local2 events to go to the /var/log/haproxy.log
    #   file. A line like the following can be added to
    #   /etc/sysconfig/syslog
    #
    #    local2.*                       /var/log/haproxy.log
    #
    log         127.0.0.1 local2

    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon

    # turn on stats unix socket
    stats socket /var/lib/haproxy/stats

#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
    mode                    http
    log                     global
    option                  httplog
    option                  tcplog
    option                  dontlognull
    option http-server-close
    option                  redispatch
    retries                 3
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
    timeout client          1m
    timeout server          1m
    timeout http-keep-alive 10s
    timeout check           10s
    maxconn                 3000


frontend bitbucket_http_frontend
    bind *:80
    #bind *:443 ssl crt /etc/cert.pem ciphers RC4-SHA:AES128-SHA:AES256-SHA
    default_backend bitbucket_http_backend

backend bitbucket_http_backend
    mode http
    option httplog
    option httpchk GET /bitbucket/status
    option forwardfor
    option http-server-close
    #Uncomment the following line for HAProxy 1.5.
    #appsession BITBUCKETSESSIONID len 52 timeout 1h
    balance roundrobin
    cookie BITBUCKETSESSIONID prefix
        # The following 3 lines are for HAProxy 1.6+. If you're on 1.5, uncomment them.
    stick-table type string len 52 size 5M expire 30m
    stick store-response set-cookie(BITBUCKETSESSIONID)
    stick on cookie(BITBUCKETSESSIONID)
    server bitbucket1 192.168.56.123:7990 check inter 10000 rise 2 fall 5
    server bitbucket2 192.168.56.124:7990 check inter 10000 rise 2 fall 5
    #server bitbucket02 192.168.0.2:7990 check inter 10000 rise 2 fall 5
    # The following "backup" servers are just here to show the startup page when all nodes are starting up
    #server backup01 192.168.56.124:7990 backup
    #server backup02 192.168.0.2:7990 backup

frontend bitbucket_ssh_frontend
    mode tcp
    bind *:7999
    default_backend bitbucket_ssh_backend
    timeout client 15m
    maxconn 50

backend bitbucket_ssh_backend
    mode tcp
    balance roundrobin
    server bitbucket1 192.168.56.123:7999 check port 7999
    server bitbucket2 192.168.56.124:7999 check port 7999
    #server bitbucket02 192.168.0.2:7999 check port 7999
    timeout server 15m

listen admin
    mode http
    bind *:8090
    stats enable
    stats uri /

HAProxy の自動起動設定とFirewall 設定して、HAProxy を起動します。

# systemctl enable haproxy
# firewall-cmd --permanent --zone=public --add-service=http
# firewall-cmd --permanent --zone=public --add-port=7998/tcp
# firewall-cmd --permanent --zone=public --add-port=8090/tcp
# firewall-cmd --reload
# systemctl start haproxy

ブラウザで http://<サーバマシンのIPアドレス>:8090/ へアクセスし、HAProxy の manager 画面を確認します。 ロードバランサのサーバーの IP アドレスが、「192.168.56.125」の場合は、http://192.168.56.125:8090/:へアクセスしてください。
ここでノード1とノード2 が設定できていることを確認します。

CentOS, Red Hat Enterprise Linux を使用する場合の注意点

CentOS や Red Hat Enterprise Linux 上に構築する場合、SELinux が有効化されているとHAProxy の起動に失敗することがあります。systemctl status haproxy コマンドで確認すると下記の表示となります。


# systemctl status haproxy
● haproxy.service - HAProxy Load Balancer
   Loaded: loaded (/usr/lib/systemd/system/haproxy.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since 火 2022-06-21 11:41:04 JST; 6s ago
  Process: 1747 ExecStart=/usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid $OPTIONS (code=exited, status=1/FAILURE)
 Main PID: 1747 (code=exited, status=1/FAILURE)

 6月 21 11:41:04 ha_proxy systemd[1]: Started HAProxy Load Balancer.
 6月 21 11:41:04 ha_proxy haproxy-systemd-wrapper[1747]: haproxy-systemd-wrapper: executing /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run...pid -Ds
 6月 21 11:41:04 ha_proxy haproxy-systemd-wrapper[1747]: [ALERT] 171/114104 (1748) : Starting frontend bitbucket_ssh_frontend: cannot bind socket...0:7999]
 6月 21 11:41:04 ha_proxy haproxy-systemd-wrapper[1747]: [ALERT] 171/114104 (1748) : Starting proxy admin: cannot bind socket [0.0.0.0:8090]
 6月 21 11:41:04 ha_proxy systemd[1]: haproxy.service: main process exited, code=exited, status=1/FAILURE
 6月 21 11:41:04 ha_proxy haproxy-systemd-wrapper[1747]: haproxy-systemd-wrapper: exit, haproxy RC=1
 6月 21 11:41:04 ha_proxy systemd[1]: Unit haproxy.service entered failed state.
 6月 21 11:41:04 ha_proxy systemd[1]: haproxy.service failed.
Hint: Some lines were ellipsized, use -l to show in full.

適宜設定を変更してください。

上記は、ノード1だけが動いている例です。このタイミングで、Bitbucke1が赤くなっていても問題有りません。

参考資料:ロード バランサのインストールと構成 

2.Bitbucketのサーバ基本URLの修正

これまで、Bitbucket に直接 Webブラウザーから 直接アクセスしてきましたが、今後はロードバランサー経由になるため URL が変更されます。これに合わせて、Bitbucket の設定も変更します。

  • 変更前:http://192.168.56.123:8090/bitbucket
  • 変更後::http://192.168.56.125/bitbucket

Bitbucket を停止して以下のファイルを修正します。

# vi /var/atlassian/application-data/bitbucket/shared/bitbucket.properties

以下の行を追加します。

/var/atlassian/application-data/bitbucket/shared/bitbucket.properties に追加
server.proxy-name=192.168.56.125
server.proxy-port=80

ファイルをの修正後、Bitbucket を起動し http://192.168.56.123/bitbucket (HA-Proxy経由) で Bitbucket にアクセスします。

(情報) ロードバランサーを経由していなかった時は、「Bitbucket を 起動中」という画面が表示され、起動プロセスの進捗が確認できました。ロードバランサーを経由すると完全に起動するまでは、「サーバーダウン中」とみなされるので起動中の画面は表示されなくなり、代わりにロードバランサーのエラー画面が表示されます。

Bitbucket にアクセスすると、下記のような警告メッセージが表示されますので、「サーバー設定でそれを変更してください」リンクをクリックします。


下記の画面が表示されますので、サーバ基本URLをロードバランサー経由の URL (下記は、http://192.168.56.125/bitbucket ) に変更します。

8.ノード2の作業

1.VMをコピーする場合

仮想環境の機能を利用してノード1の VM を複製して、IP アドレスを変更してノード2のサーバーとしてください。 

2.VMをコピーしない場合

ノード2のサーバーで以下の作業を実施します。

9.クラスターモードでの動作確認

1.Bitbucket の起動

Bitbucket のノードは時間をずらして起動する必要があります。まず、ノード1を起動して、Bitbucket が稼働している事を確認した後に、ノード2の Bitbucket を起動します。

2つの Bitbucket を起動した後、管理画面で「管理」→「クラスタリング」を選択します。下記の様に、2つのノードが確認できます。

この状態で、プロジェクトの作成、リポジトリーの作成、ソースのクローン、プッシュ、検索などの Bitbucket の機能確認を簡単にして下さい。

2.ノード切り替えのテスト

2台が稼働している状態で、ノード2 の Bitbucket を停止します。下記の様にクラスタリング画面の表示がノード1 のみになります。


この状態で、プロジェクトとリポジトリーを作成し、ファイルを push して登録します。

ノード2 の Bitbucket を起動します。しばらくすると、管理画面のクラスタリングにノードが2つ表示されます。この状態でノード1の Bitbucket を停止します。

下記の様にノード2 のみが稼働している状態になったら、先ほど push したファイルが閲覧できる事を確認します。


10.検索サーバーの構築

1.検索サーバー用サーバーの作業

Bitbucket Data Center は、有償製品の  Elasticsearch と Apache-2.0 ライセンスで無償利用できる OpenSearch の2つをサポートしています。ここでは、OpenSearch の利用方法を説明します。Bitbucket Data Center は OpenSacn の Ver.1.2 をサポートしていますので、OpenSearch1.2.4 のインストールとセットアップ を参照してインストールして下さい。

2.Bitbucket の作業

ノード1、ノード2のいずれかの Bitbucketサーバーで、/var/atlassian/application-data/bitbucket/shared/bitbucket.properties を編集します。

# vi /var/atlassian/application-data/bitbucket/shared/bitbucket.properties

以下の行を追加します。

/var/atlassian/application-data/bitbucket/shared/bitbucket.properties に追加
# opensearch.ricksoft.local は OpenSearchを実行するサーバー名に置き換えて下さい。
plugin.search.config.baseurl=https://opensearch.ricksoft.local:9200
# OpenSearch の INTERNAL_USERS.YML に指定したユーザー名です。
plugin.search.config.username=bitbucket
# OpenSearch の INTERNAL_USERS.YML では hash化したパスワードを登録しましたが、こちらはハッシュ化する前のパスワードを登録して下さい。
plugin.search.config.password=xxxxxxxx

自己認証局の証明書の場合は、証明書を Bitubucket サーバーに登録する必要が有ります。OpenSearch サーバーの /opt/opensearch-1.2.4/config/cacert.pem を Bitbucket サーバーにコピーして以下を実行します。パスワードは、changeit とします。

# export JAVA_HOME=/opt/atlassian/bitbucket/7.21.2/jre
# export PATH=$JAVA_HOME/bin:$PATH
# keytool -importcert -alias opensearch -keystore jssecacerts -file cacert.pem
キーストアのパスワードを入力してください:  <== ここで changeit
キーストアのパスワードを入力してください:  <== もう一度 changeit
新規パスワードを再入力してください:
所有者: EMAILADDRESS=higuchi.akira@ricksoft.jp, CN=private-ca, O="Ricksoft Co., Ltd.", ST=Tokyo, C=JP
発行者: EMAILADDRESS=higuchi.akira@ricksoft.jp, CN=private-ca, O="Ricksoft Co., Ltd.", ST=Tokyo, C=JP
シリアル番号: 85f4c703f9e3e679
有効期間の開始日: Sun Jul 24 20:13:31 JST 2022終了日: Wed Jul 23 20:13:31 JST 2025
証明書のフィンガプリント:
         SHA1: A8:2A:FD:2D:F6:87:45:73:57:D3:A5:37:71:6C:36:EC:B0:73:14:34
         SHA256: 09:F4:CD:B1:22:6B:EB:5B:49:D1:11:BE:11:8E:EC:D4:89:DD:14:04:4D:81:C1:FB:A7:B9:A8:70:83:D1:02:09
署名アルゴリズム名: SHA256withRSA
サブジェクト公開キー・アルゴリズム: 2048ビットRSAキー
バージョン: 3

拡張:

#1: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 57 6E C3 42 23 7E DC BC   A1 1E 0E 14 80 43 03 60  Wn.B#........C.`
0010: FC 6D 81 FD                                        .m..
]
]

#2: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
  CA:true
  PathLen:2147483647
]

#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 57 6E C3 42 23 7E DC BC   A1 1E 0E 14 80 43 03 60  Wn.B#........C.`
0010: FC 6D 81 FD                                        .m..
]
]

この証明書を信頼しますか。 [いいえ]:  y
証明書がキーストアに追加されました

jssecacerts というファイルができているので、これを Bitbucket が使えるように移動します。

# mv jssecacerts /var/atlassian/application-data/bitbucket/shared

各ノードの Bitbucket Server にて _start-webapp.sh ファイルを修正します。

# vi /opt/atlassian/bitbucket/7.21.2/bin/_start-webapp.sh

JVM_SUPPORT_RECOMMENDED_ARGSを見つけて、2行目と3行目を追加してください。

/opt/atlassian/bitbucket/7.21.2/bin/_start-webapp.sh を修正
JVM_SUPPORT_RECOMMENDED_ARGS="-Datlassian.plugins.enable.wait=300 -Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8"
JVM_SUPPORT_RECOMMENDED_ARGS="$JVM_SUPPORT_RECOMMENDED_ARGS -Djavax.net.ssl.trustStore=$BITBUCKET_HOME/shared/jssecacerts"
JVM_SUPPORT_RECOMMENDED_ARGS="$JVM_SUPPORT_RECOMMENDED_ARGS -Djavax.net.ssl.trustStorePassword=changeit"
export LANG=en_US.UTF-8

修正したら Bitubkcet を再起動します。

3.動作確認

再起動したら、リポジトリーに登録されている文字列で 検索して下さい。検索で、結果が表示できればOKです。
(情報) リポジトリーの大きさにより、OpenSearch 内のインデックス作成に時間がかかる場合があります。


下記の様なエラーメッセージが出た時は、Bitbucket と OpenSearch が通信できない状態です。ログファイルを確認して下さい。



リックソフト株式会社 は、日本でトップレベルのAtlassian Platinum Solution Partnerです。
大規模ユーザーへの対応実績が認められたEnterpriseの認定をうけ、高度なトレーニング要件をクリアし、小規模から大規模のお客様まで対応可能な実績を示したパートナー企業です。


Copyright © Ricksoft Co., Ltd. プライバシーポリシー お問い合わせ