Administering Bitbucket Data Center in Azure
To access your jumpbox and nodes you'll need:
- The SSH credentials you provided during setup, and
- The URL of your jumpbox. This is listed as the
BASTIONURLin your deployment's Outputs tab.
Connecting to your Azure jumpbox and nodes over SSH
You can access the jumpbox via a terminal, or using the command line using:
$ eval $(ssh-agent) $ ssh-add ~/.ssh/id_rsa $ ssh -A JUMPBOX_USERNAME@BASTIONURL
SSHURL field in your deployment's Outputs tab shows the SSH command you can use to access your deployment.
Once you've accessed the jumpbox, you can jump to any of the nodes in the cluster, using:
$ ssh NODE_IP_ADDRESS
Accessing your configuration files
For your Azure deployment, you may need to make changes to your bitbucket.properties file, just as you would for a deployment on your own hardware.
your shared bitbucket.properties lives in /var/atlassian/application-data/bitbucket/shared/bitbucket.properties
The shared home is mounted on each node under /var/atlassian/application-data/bitbucket/shared.
So from an existing node (when you're logged in through SSH), you can go to /var/atlassian/application-data/bitbucket/shared
- Check if your apps are compatible with that version. Update your apps if needed. For more information about managing apps, see Using the Universal Plugin Manager.
- Enable integrity checks (if you haven't already).
We strongly recommend that you perform the upgrade first in a staging environment before upgrading your production instance. How to establish staging server environments for Bitbucket Server provides helpful tips on doing so.
We recommend you use the Azure native backup facility, which utilizes snapshots to back up your Bitbucket Data Center. The following backup advice assumes that you deployed your Bitbucket instance through the Azure Marketplace template.
We use Azure-managed database instances with high availability. Azure provides several excellent options for backing up your database, so you should take some time to work out which will be the best, and most cost effective option for your needs. See the following Azure documentation for your chosen database:
This node handles the shared NFS file system of the Bitbucket application nodes. The Azure Marketplace template creates a general-purpose Azure storage account, configured with local redundant storage (LRS). Using LRS means there are multiple copies of the data at any one time, providing a basic redundancy strategy for your content.
The Elasticsearch cluster takes snapshots of its index every hour. Those snapshots are backed up to Azure Blob Storage.
The application nodes are VMs in an Azure Virtual Machine Scale Set. Each application node has a Bitbucket installation directory and a local home directory containing things like logs and search indexes.
Like the NFS Server, application nodes are configured with local redundant storage. This means there are multiple copies of the data at any one time.
If you've manually customised any configuration files in the installation directory (for example velocity templates), you may also want to manually back these up as a reference.
As this VM acts as a jumpbox, and doesn't store any data it doesn't need to be backed up. If the VM becomes unresponsive it can be restarted from the Azure Portal.
The application gateway is highly available. As with the bastion host, it doesn't need to be backed up.
Migrating your existing instance into Azure
If you want to migrate data from an existing instance into Bitbucket Data Center in Azure, we recommend that you use the Export and import projects and repositories tool. This tool is only available to users with Bitbucket Data Center licenses.
See Disaster recovery guide for Bitbucket Data Center for guidance on developing a disaster recovery strategy. See also information in the Azure documentation about recovering from a region-wide failure Azure resiliency technical guidance: recovery from a region-wide service disruption.