このページでは、インストーラーを利用して Bitbucket の Data Center 版を クラスター化された構成で Linux 環境にインストールする手順について紹介します。
目次
はじめに
Bitbucket をインストールする環境は以下を想定しています。
インストールディレクトリ | /opt/atlassian/Bitbucket (Bitbucket のインストーラーのデフォルト設定を利用) |
|---|---|
ローカルホームディレクトリ (Bitbucket のローカルデータを保存するディレクトリ） | /var/atlassian/application-data/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 アドレス | |
|---|---|---|---|
| 1 | Bitbucket ノード１ |
| 192.168.56.123 |
| 2 | Bitbucket ノード２ |
| 192.168.56.124 |
| 3 | ロードバランサ |
| 192.168.56.125 |
| 4 | データサーバー |
| 192.168.56.116 |
| 5 | 検索サーバー |
| 192.168.56.126 |
| 6 | 共有ディレクトリ |
| 192.168.56.127 |
１．サーバーを用意する
1. Bitbucket をインストールするサーバー
Bitbucket をインストールするサーバーをノード分用意します。必要なスペックについては以下をご参照ください。
- Bitbucket サーバーサイジング（リックソフトブログより）
- Bitbucket Data Center の技術的概要 - インフラストラクチャと要件 (Atlassian ドキュメントより)
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 を利用した手順をご紹介します。
２．各サーバーにLinux をインストールする
ロードバランサーや Bitbucket を設定するサーバー、データサーバーに それぞれ Linux をインストールしてください。本ドキュメントでは CentOS を利用します（RHELや、Ubuntu などの Debian 系ディストリビューションを利用することもできます）。
１． 時刻の同期
ノード１、ノード２は時刻が合っていないといけないので、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
３．データベース を用意する
サポート対象プラットフォーム に記載されている、サポートされたデータベースを構築します。本ドキュメントでは PostgreSQL を利用しますので、以下のページの手順を実施してください。
今回はデータサーバーに PostgreSQL をインストールし、Bitbucket用の共有データベースを作成します。
ご注意ください
クラスタ化した Bitbucket では、 Bitbucket 内部の組み込みデータベース(H2) をご利用いただけません。
４．ノード１の Bitbucket のインストール・セットアップ を実行する
Bitbucket Data Center 7.X のインストール (Linux, シングルノード構成) の ４．Git をインストールする 以降を実行します。
ここでは Bitbucket ver.7.18.1 をインストールします。インストールする Bitbucket のバージョンが異なる場合は、バージョンの部分を読み替えて実行をお願いします。
１．Bitbucket の 起動オプションの設定
クラスターモードで Bitbucket を稼働させる場合、検索エンジンは Bitbucket サーバーではなく独立したサーバーで稼働させる必要があります。そのため、起動オプションに --no-search を指定する必要があります。systemd の設定 を実施している場合、/usr/lib/systemd/system/bitbucket.service を編集します。
# vi /usr/lib/systemd/system/bitbucket.service
下記の様に ExecStart のパラメータに --no-search を追加してください。
ExecStart=/opt/atlassian/bitbucket/7.21.2/bin/start-bitbucket.sh --no-search
ファイルを修正したら、以下のコマンドで reload します。
# systemctl daemon-reload
５．共有ディレクトリをセットアップする
クラスタ内のすべてのノードで読み取り/書き込み可能な共有ディレクトリを作成します。今回は、専用サーバーに共有ディレクトリを作成し、NFS で他ノードへ共有する場合の手順を紹介します。
１．ノード１の Bitbucket のサービスを停止する
Bitbucket が起動している場合は、以下のコマンドを実行し Bitbucket を停止します。
※ RHEL 7 や CentOS 7 系の OS をご利用で systemd の設定 を実施している場合は以下のコマンドで実行できます。
# systemctl stop bitbucket
２．バックアップ
作業に入る前に、Bitbucket の インストールディレクトリ (/opt/atlassian/bitbucket) と ローカルホームディレクトリ (/var/atlassian/application-data/bitbucket) のバックアップを取得する事をお勧めします。
３．共有ディレクトリサーバーで共有ディレクトリを作成する
共有ディレクトリサーバーで、以下のコマンドを実行し、共有ディレクトリを作成します。
# mkdir -p /data/bitbucket/shared
ノード１の Bitbucket のローカルホームディレクトリにある shared フォルダを、共有ディレクトリサーバーの共有ディレクトリ配下へコピーします。
例として、ノード１の 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 を統一する をご参照下さい。
４．共有ディレクトリサーバーで 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 の範囲で許可します。 参考：アプリケーション クラスタ ノードのプロビジョニング
/data/bitbucket/shared 192.168.56.0/24(rw,sync,no_root_squash,no_all_squash)
以下のコマンドを実行し、設定用のファイルを変更します。
# vi /etc/sysconfig/nfs
LOCKD_TCPPORT と LOCKD_UDPPORT の コメントを外して有効化します。
# 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
５． ノード１でNFSを設定・ディレクトリをマウントする。
ノード１の 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
ノード１の Bitbucket のサーバで、以下のコマンドを実行し、共有ディレクトリを削除します。
削除前に、/var/atlassian/application-data/bitbucket/shared のバックアップがとられている事を確認して下さい。もし取られていないと作業に失敗した場合、今まで作成した リポジトリーなどのデータが消失してしまいます。 ノード２以降の、追加のサーバーの作業の場合は削除は必要有りません。
# rm -rf /var/atlassian/application-data/bitbucket/shared
ノード１の 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」である例です。
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
６．ノード１の Bitbucket をクラスタモードへ変更する
１．構成ファイル変更
ノード１にて、共有ディレクトリの bitbucket.properties を編集します。
# vi /var/atlassian/application-data/bitbucket/shared/bitbucket.properties
以下の3行を追加します。
hazelcast.network.multicast=true hazelcast.group.name=your-bitbucket-cluster hazelcast.group.password=xxxxxxxx
- hazelcast.group.name は任意の名前で構いませんが、ネットワーク内でユニークなものにして下さい。本番用と検証用の Bitbucket があった場合は、それぞれ別々の名前にして下さい。
- hazelcast.group.password には クラスター認証用のパスワードを設定してください。上記ではマスクしています。
２．Bitbucket サーバーの Firewall 設定
クラスタリングのノード間の通信ポートを開放します。
# firewall-cmd --permanent --zon=public --add-port=5701/tcp # firewall-cmd --permanent --zon=public --add-port=5701/udp # firewall-cmd --reload
７．ロードバランサを設定する
１．ロードバランサー様サーバーの作業
ロードバランサにするサーバーへ HAProxy をインストールします。
# yum -y install haproxy
Bitbucket 分散用 に haproxy の設定ファイルを修正します。
# vi /etc/haproxy/haproxy.cfg
#---------------------------------------------------------------------
# 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/:へアクセスしてください。
ここでノード１とノード２ が設定できていることを確認します。
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.
適宜設定を変更してください。
上記は、ノード１だけが動いている例です。このタイミングで、Bitbucke1が赤くなっていても問題有りません。
参考資料：ロード バランサのインストールと構成
２．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
以下の行を追加します。
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 ) に変更します。
８．ノード２の作業
１．VMをコピーする場合
仮想環境の機能を利用してノード１の VM を複製して、IP アドレスを変更してノード２のサーバーとしてください。
２．VMをコピーしない場合
ノード２のサーバーで以下の作業を実施します。
- LInux をインストールした後、Bitbucket Data Center 7.X のインストール (Linux, シングルノード構成) の ４．Git をインストールする から ９. ポートの開放 までを実施します。
- 上記 606437400 を実施します。
- 上記 ５．ノード１でNFSを設定・ディレクトリをマウントする を実施します。
- 上記 ２．Bitbucket サーバーの Firewall 設定 を実施します。
以下のコマンドをBitbucket のノード２サーバーで実行して、ノード１のファイルをノード２にコピーします。
# rsync -auz -e ssh --exclude shared 192.168.56.123:/var/atlassian/application-data/bitbucket/ /var/atlassian/
９．クラスターモードでの動作確認
１．Bitbucket の起動
Bitbucket のノードは時間をずらして起動する必要があります。まず、ノード１を起動して、Bitbucket が稼働している事を確認した後に、ノード２の Bitbucket を起動します。
２つの Bitbucket を起動した後、管理画面で「管理」→「クラスタリング」を選択します。下記の様に、2つのノードが確認できます。
この状態で、プロジェクトの作成、リポジトリーの作成、ソースのクローン、プッシュ、検索などの Bitbucket の機能確認を簡単にして下さい。
２．ノード切り替えのテスト
２台が稼働している状態で、ノード2 の Bitbucket を停止します。下記の様にクラスタリング画面の表示がノード1 のみになります。
この状態で、プロジェクトとリポジトリーを作成し、ファイルを push して登録します。
ノード2 の Bitbucket を起動します。しばらくすると、管理画面のクラスタリングにノードが２つ表示されます。この状態でノード1の Bitbucket を停止します。
下記の様にノード2 のみが稼働している状態になったら、先ほど push したファイルが閲覧できる事を確認します。
１０．検索サーバーの構築
１．検索サーバー用サーバーの作業
Bitbucket Data Center は、有償製品の Elasticsearch と Apache-2.0 ライセンスで無償利用できる OpenSearch の２つをサポートしています。ここでは、OpenSearch の利用方法を説明します。Bitbucket Data Center は OpenSacn の Ver.1.2 をサポートしていますので、OpenSearch1.2.4 のインストールとセットアップ を参照してインストールして下さい。
２．Bitbucket の作業
ノード１、ノード２のいずれかの Bitbucketサーバーで、/var/atlassian/application-data/bitbucket/shared/bitbucket.properties を編集します。
# vi /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を見つけて、２行目と３行目を追加してください。
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 を再起動します。
３．動作確認
再起動したら、リポジトリーに登録されている文字列で 検索して下さい。検索で、結果が表示できればOKです。 リポジトリーの大きさにより、OpenSearch 内のインデックス作成に時間がかかる場合があります。
下記の様なエラーメッセージが出た時は、Bitbucket と OpenSearch が通信できない状態です。ログファイルを確認して下さい。
