Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Deploy atlassian/bitbucket-server on an openshift cluster

Julian Stamp
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
April 2, 2020

Since I was not able to find much information about how to deploy bitbucket on an openshift cluster, I would like to share valuable insights I had during the process.

Initial Setup

The initial setup was easy. Simply navigating the Openshift wizard for creating a deployment configuration and referencing the dockerhub image atlassian/bitbucket-server created most of the api objects needed for a deployment.

SSL secured connection

Openshift routes provide the option for edge termination. This corresponds somewhat to the reverse proxy setup for bitbucket server. Accordingly, the bitbucket properties need to be set. This can be achieved by seeding the properties as runtime environment variables. The following variables were needed to enable the https schema with the edge termination option of the route:

value: '7990'
value: https
value: 'true'
value: '443'

Openshift Runtime User

Openshift requires images to be written in a certain way. One particular requirement is that images need to be written to support arbitrary user IDs (Link to openshift documentation). The docker image by atlassian has a bunch of folder paths written to be owned by the user 'bitbucket'. Openshift starts containers with a random userid.This causes the problem that the user does not have write permission to the folders it needs to write to.

Instead of rewriting the image and change the group ownership of the directories that need to have write permission for the runtime user, it is also possible to mount volumes to these directories. The arbitrary runtime user is the owner of the directories that are mounted at runtime. So far I identified two separate directories that need to be owned by the runtime user.

BITBUCKET_HOME: /var/atlassian/application-data/bitbucket
ELASTICSEARCH_LOGS: /opt/atlassian/bitbucket/elasticsearch/logs


Filestorage Type Persisten volume

Apparently, bitbucket and elastic search have a problem to deal with the glusterfs storage file system. A recommended storage type is gp2.

Java truststore for application links

1. Download the relevant certificates to a file

openssl s_client -showcerts -connect jira.server:443 </dev/null 2>/dev/null|openssl x509 -outform PEM > jira.cert

2. Create the truststore

keytool -import -file cert.crt -alias cert -keystore bitbucket.truststore

This command will require you to set a password, reenter it several times and confirm to proceede between the different import steps.

Make sure to take note of the password and add it to the environment variable JVM_SUPPORT_RECOMMENDED_ARGS as !


3. Create a config map containing the binary

oc create configmap bitbucket-truststore --from-file=bitbucket.truststore

4. Mount the truststore from configmap as file. This requires to add the configmap as volume to the pod and mount the volume to the container. Furthermore, it is necessary to provide the path to and password for the truststore to the custom java args environment variable for bitbucket server JVM_SUPPORT_RECOMMENDED_ARGS.

Liveness Probe

The liveness probe can use a http GET request to the /status url.

failureThreshold: 3
path: /status
port: 7990
scheme: HTTP
initialDelaySeconds: 300
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1

Open questions

Currently, I still did not manage to setup a working readiness. The naive probes that are suggested by the Openshift UI as GET request on container port 7990 kept the application unavailable.



Log in or Sign up to comment
AUG Leaders

Atlassian Community Events