このガイドでは以下の用語について説明します：

• Installation directory - <Bitbucket install directory> is the directory where you installed Bitbucket on a node.
• Shared home directory – <Bitbucket shared home> The directory you created that is accessible to all nodes in the cluster via the same path.

Bitbucket Data Center component requirements

You can see a component diagram of a typical Bitbucket Data Center instance, and read about detailed requirements of each component on the page Bitbucket Data Center requirements and on the Supported platforms page.

A Bitbucket Data Center instance consists of a cluster of components, each running on a dedicated machine:

• A cluster of Bitbucket application nodes all running the same version of Bitbucket Data Center web application. These can be virtual or physical machines, have synchronized clocks (for example, using NTP) and be configured with the identical timezone, are allowed to connect to a Bitbucket cluster node's Hazelcast port, which by default is port 5701.
• A load balancer that supports both HTTP mode (for web traffic) and TCP mode (for SSH traffic), and support session affinity ("sticky sessions").
• A supported external database, shared and available to all all cluster nodes.
• A shared file system that is physically located in the same data center, available to all clusters nodes, and accessible by NFS as a single mount point.
• A remote Elasticsearch instance, with a only one remote connection to Bitbucket. The instance may be a standalone Elasticsearch installation, or a clustered installation behind a load balancer, but note that Bitbucket Data Center will only work with Elasticsearch 5.5.

Be sure to test your Bitbucket Data Center installation thoroughly before deploying to production

Regardless of the installation process you use, be sure to smoke test your Bitbucket Data Center instance every step of the way. Be sure to:

• Set up and test Bitbucket Data Center in your staging environment before deploying to a production environment.
• Test Bitbucket Data Center with identical data (repositories, users, add-ons) to your production instance. 

Accessing a Bitbucket Data Center installation

At the end of the installation process, the URL of the Bitbucket Data Center instance will be the URL of the load balancer, so this is the machine that you will need to assign the name of your Bitbucket Data Center instance in the DNS. The remaining machines (Bitbucket cluster nodes, shared database, and shared file system) do not need to be publicly accessible to your users. 

はじめる前に

Before you install Bitbucket Data Center, there are a few questions you need to answer. 

Do you already have a production instance of Bitbucket Server running?

Install Bitbucket Data Center on the first application node

1. Download Bitbucket Data Center

Download the latest installer - www.atlassian.com/software/bitbucket/download.

2. インストーラーを実行する

1. インストーラーを実行可能にします。

   手順について

   Change to the directory where you downloaded the installer, then execute this command:

   chmod +x atlassian-bitbucket-x.x.x-x64.bin

   Where x.x.x is the version you downloaded.

   
   
   

2. Run the installer – we recommend using sudo to run the installer as this will create a dedicated account to run Bitbucket and allow you to run Bitbucket as a service.

   手順について

   インストーラーを実行するために sudo を使用するには、次のコマンドを実行します。 

   $ sudo ./atlassian-bitbucket-x.x.x-x64.bin

   Where x.x.x is the version you downloaded.

   root ユーザー権限でインストーラーを実行することもできます。

   
   
   

3. プロンプトに従ってBitbucket をインストールします。次の情報を提供します。
   
   1. Type of Bitbucket instance - the type of installation, for these instructions select Data Center.
   2. Installation directory - where Bitbucket will be installed.
   3. Home directory - where Bitbucket application data will be stored.
   4. TCP ports - the HTTP connector port and control port Bitbucket will run on.

Provision the shared database, filesystem, and Elasticsearch nodes

Once you've installed the first Bitbucket application node, you now need to provision the share database and shared filesystem to use with Bitbucket Data Center. 

3. Provision your shared database

Set up your shared database server. 

• Bitbucket Server を PostgreSQL に接続する
  
• Bitbucket Server を SQL Server に接続する
  
• Bitbucket Server を Oracle に接続する
  

Ensure your database is configured to allow enough concurrent connections. Bitbucket Server by default uses up to 80 connections per cluster node, which can exceed the default connection limit of some databases. For example, in PostgreSQL the default limit is usually 100 connections. If you use PostgreSQL, you may need to edit your postgresql.conf file, to increase the value of max_connections, and restart Postgres.

See Connecting Bitbucket Server to an external database for more information, and note that clustered databases are not supported.

4. Provision your shared file system

1. Create a Bitbucket Server user account named atlbitbucket on the shared file system server using this command:
   
    Do not run Bitbucket Server as root. Many NFS servers squash accesses by root to another user.

   sudo useradd -c "Atlassian Bitbucket" -u 1001 atlbitbucket

   
   

   1. This account will own everything in the Bitbucket Server shared home directory. 

   2. This user account must have the same UID on all cluster nodes and the shared file system server. 
      
      

      UID 1001 isn't available on my system...

      In a fresh Linux install the UID of a newly created account is typically 1001, but in general there is no guarantee that this UID will be free on every Linux system. Choose a UID for atlbitbucket that's free on all your cluster nodes and the shared file system server, and substitute this for 1001 in the above command.

2. Ensure your shared file system server has the NFS lock service enabled.
   

3. Ensure the user running Bitbucket Server, atlbitbucket, is able to read and write everything in the Bitbucket shared home directory, both the node-local part and the shared part (in NFS). The easiest way to do this is to ensure that:

   1. atlbitbucket owns all files and directories in the Bitbucket home directory,
   2. atlbitbucket has the recommended umask of 0027, and
   3. atlbitbucket has the same UID on all machines.
      
      
4. If you're moving from Bitbucket Server to Bitbucket Data Center:

   1. Restore the content of directory <Bitbucket shared home directory>/shared from the backup you have taken into the new shared database and shared home directory.

      Only the shared directory in the Bitbucket Server home directory needs to be restored into the shared home directory. The remaining directories (bin, caches, export, lib, log, plugins, and tmp) contain only caches and temporary files, and do not need to be restored. 

See Bitbucket Data Center FAQ for performance guidelines when using NFS.

5. Provision your Elasticsearch node

To set up your Elasticsearch server, you will

1. Install Elasticsearch on a remote machine.
2. Configure Elasticsearch's elasticsearch.yml file to work with Bitbucket Data Center.
3. Secure Elasticsearch with a username and password that Bitbucket will use to access Elasticsearch, with a minimum of HTTP restricted access.
4. Connect Elasticsearch to Bitbucket.

There are detailed instructions on the page Install and configure a remote Elasticsearch instance to help you provision your remote Elasticsearch installation.

Provision application cluster nodes

6. Provision application cluster nodes

1. Provision cluster node infrastructure. You can automate this using a configuration management tool such as Chef, Puppet, or Vagrant, and/or by spinning up identical virtual machine snapshots. 
   
   

2. On each cluster node, mount the shared home directory as ${BITBUCKET_HOME}/shared. Note that only the ${BITBUCKET_HOME}/shared directory should be shared between cluster nodes.  All other directories, including ${BITBUCKET_HOME}, should be node-local (that is, private to each node).  
   
   

   1. For example, suppose your Bitbucket home directory is /var/atlassian/application-data/bitbucket , and your shared home directory is available as an NFS export called bitbucket-san:/bitbucket-shared . Add the following line to /etc/fstab on each cluster node:
      
      
      

      /etc/fstab

      bitbucket-san:/bitbucket-shared /var/atlassian/application-data/bitbucket/shared nfs lookupcache=pos,noatime,intr,rsize=32768,wsize=32768 0 0

   2. Then mount it:

      mkdir -p /var/atlassian/application-data/bitbucket/shared
      sudo mount -a

      
      
      

3. Ensure all your cluster nodes have synchronized clocks and identical timezone configuration. Here are some examples for how to do this:
   
   

   For RedHat Enterprise Linux or CentOS:

   sudo yum install ntp
   sudo service ntpd start
   sudo tzselect

   
   

   For Ubuntu Linux:

   sudo apt-get install ntp
   sudo service ntp start
   sudo dpkg-reconfigure tzdata

4. Repeat steps 1 and 2 to install Bitbucket Data Center on each of the provisioned application cluster nodes. 

7. Start the first cluster node

Edit the file ${BITBUCKET_HOME}/shared/bitbucket.properties and add the following lines:

# Use multicast to discover cluster nodes (recommended).
hazelcast.network.multicast=true

# If your network does not support multicast, you may uncomment the following lines and substitute
# the IP addresses of some or all of your cluster nodes. (Not all of the cluster nodes have to be
# listed here but at least one of them has to be active when a new node joins.) 
#hazelcast.network.tcpip=true
#hazelcast.network.tcpip.members=192.168.0.1:5701,192.168.0.2:5701,192.168.0.3:5701

# The following should uniquely identify your cluster on the LAN. 
hazelcast.group.name=your-bitbucket-cluster
hazelcast.group.password=your-bitbucket-cluster

JVM_SUPPORT_RECOMMENDED_ARGS="-Dhazelcast.prefer.ipv4.stack=false"

Using multicast to discover cluster nodes (hazelcast.network.multicast=true) is recommended, but requires all your cluster nodes to be accessible to each other via a multicast-enabled network. If your network does not support multicast then you can set  hazelcast.network.multicast=false,  hazelcast.network.tcpip=true, and hazelcast.network.tcpip.members to a comma-separated list of cluster nodes instead. Only enable one of hazelcast.network.tcpip or hazelcast.network.multicast, not both.

Choose a name for hazelcast.group.name and hazelcast.group.password that uniquely identifies the cluster on your LAN. If you have more than one cluster on the same LAN (for example, other Bitbucket Data Center instances or other products based on similar technology such as Confluence Data Center) then you must assign each cluster a distinct name, to prevent them from attempting to join together into a "super cluster". 

Then start Bitbucket Server. See Starting and stopping Bitbucket Server.

Then go to http://<bitbucket>:7990/admin/license, and install your Bitbucket Data Center license. Restart Bitbucket Server for the change to take effect. If you need a Bitbucket Data Center license, you can purchase one that fits your needs, or, get an evaluation license.

Install and configure your load balancer

8. Install your load balancer

You can use the load balancer of your choice, either hardware or software. Bitbucket Data Center does not bundle a load balancer. 

Your load balancer must proxy three protocols:

If your load balancer supports health checks of the cluster nodes, configure it to perform a periodic HTTP GET of http:// <bitbucket>:7990/status, where <bitbucket> is the cluster node's name or IP address. This returns one of two HTTP status codes:

• 200 OK
• 500 Internal Server Error

If a cluster node does not return 200 OK within a reasonable amount of time, the load balancer should not direct any traffic to it. 

You should then be able to navigate to http://<load-balancer>/, where <load-balancer> is your load balancer's name or IP address. This should take you to your Bitbucket Server front page. 

Example: HAProxy load balancer

If you don't have a particular preference or policy for load balancers, you can use HAProxy which is a popular Open Source software load balancer.

Here is an example haproxy.cfg configuration file (typically found in the location /etc/haproxy/haproxy.cfg).  This assumes:

• Your Bitbucket cluster node is at address 192.168.0.1, listening on the default ports 7990 (HTTP) and 7999 (SSH). 
• You have a valid SSL certificate at /etc/cert.pem.

global
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon
    tune.ssl.default-dh-param 1024
defaults
    log                     global
    option                  dontlognull
    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
    errorfile               408 /dev/null	# Workaround for Chrome 35-36 bug.  See http://blog.haproxy.com/2014/05/26/haproxy-and-http-errors-408-in-chrome/

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 /status
    option forwardfor
    option http-server-close
    appsession BITBUCKETSESSIONID len 52 timeout 1h
    balance roundrobin
    cookie BITBUCKETSESSIONID prefix
    stick-table type string len 52 size 5M expire 30m
    stick store-response set-cookie(BITBUCKETSESSIONID)
    stick on cookie(BITBUCKETSESSIONID)
    server bitbucket01 192.168.0.1: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.0.1:7990 backup
    #server backup02 192.168.0.2:7990 backup

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

backend bitbucket_ssh_backend
    mode tcp
    balance roundrobin
    server bitbucket01 192.168.0.1: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 /

Once you have configured the haproxy.cfg file, start the haproxy service.

sudo service haproxy start

You can also monitor the health of your cluster by navigating to HAProxy's statistics page at http://<load-balancer>:8090/. You should see a page similar to this:

9. Configure Bitbucket for HAProxy

Bitbucket needs to be configured to work with HAProxy. For example:

server.proxy-name=bitbucket.company.com
server.proxy-port=443
server.secure=true
server.require-ssl=true

Read Securing Bitbucket behind HAProxy using SSL for more details.

10. Add a new Bitbucket application node to the cluster

Go to a new cluster node, and start Bitbucket Server. See Starting and stopping Bitbucket Server.

Once Bitbucket Server has started, go to https://<load-balancer>/admin/clustering. You should see a page similar to this:

Verify that the new node you have started up has successfully joined the cluster. If it does not, please check your network configuration and the ${BITBUCKET_HOME}/log/atlassian-bitbucket.log files on all nodes. If you are unable to find a reason for the node failing to join successfully, please contact Atlassian Support .

11. Connect the new Bitbucket cluster node to the load balancer

If you are using your own hardware or software load balancer, consult your vendor's documentation on how to add the new Bitbucket cluster node to the load balancer.

If you are using HAProxy, uncomment these lines

server bitbucket02 192.168.0.2:7990 check inter 10000 rise 2 fall 5

server bitbucket02 192.168.0.2:7999 check port 7999

in your haproxy.cfg file and restart haproxy:

sudo service haproxy restart

新しいノードがクラスター内にあり、リクエストを受信することを検証します。これを行うには、各ノードでログを調べ、いずれもトラフィックを受信していることを確認し、さらに、一方のノードで実行された更新をもう一方のノードで表示できるかどうかも調べます。 

Add remaining applications nodes to the cluster

12. Repeat steps 10 and 11 for each additional cluster node

おめでとうございます!

That's it! Bitbucket Data Center is accessible from a URL like this: http://<load_balancer_IP_address>:<port>

次のステップ

When setting up Bitbucket in a production environment, we recommend that you configure these aspects next:

• Bitbucket Server をユーザー ディレクトリに接続 - 外部ディレクトリに保存されているユーザー / グループを管理します。
• Bitbucket Server を専用ユーザーとして実行 - 制限された権限を持つユーザー アカウントを使用して Bitbucket Server を実行します。
• Bitbucket のホーム ディレクトリの保護 - ホーム ディレクトリを不正アクセスから保護します。
• Bitbucket Server のプロキシと安全性確保 - リバース プロキシの内側で Bitbucket Server を実行し、HTTPS アクセスを有効化します。
• データ復旧計画の作成 - インスタンスのホーム ディレクトリおよびデータベースをバックアップします。

大規模な組織を対象とした Bitbucket Server のセットアップの詳細については、「大規模な組織で Bitbucket Server を使用する」を参照してください。