Administering Bitbucket Data Center in Azure
The Azure Resource Manager template as a method of deployment is no longer supported or maintained by Atlassian. You can still customize it for your own usage to deploy Data Center products on Azure though.
We recommend deploying your Data Center products on a Kubernetes cluster using our Helm charts for a more efficient and robust infrastructure and operational setup. Learn more about deploying on Kubernetes
Once you've deployed Bitbucket Data Center through the Azure Marketplace template, administering the application is similar to managing an application on your own hardware. The exception being that you'll need to go via the jumpbox to access your nodes, and shared home directory.
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@BASTIONURLThe 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_ADDRESSAccessing 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
Upgrading
- 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.
To upgrade to a later version of Bitbucket in Azure, you must first connect to your instance using SSH, then follow the steps in the Upgrade Bitbucket from an archive file. Note that you cannot use the installer if you're upgrading Bitbucket Server or a single-node Data Center using an Azure template.
Backing up
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.
Database
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:
NFS Server
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 template also configures your deployment to back up the NFS server disks into the Azure Recovery Service vault daily. If you need to take point-in-time backups, use snapshots.
Search server
The Elasticsearch cluster takes snapshots of its index every hour. Those snapshots are backed up to Azure Blob Storage.
Application nodes
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.
Bastion host
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.
Application gateway
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.
Disaster recovery
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.