Keeping pace with Atlassian releases
One of the problems we encounter when developing add-ons for Atlassian is that Atlassian is releasing new versions every couple of weeks (and sometimes faster).
To be able to run our integration tests in different environments, we are using docker to set up the application under test. Docker allows us to quickly set up a new instance connected to a postgres database with the right attributes required to run our integration tests.
Of course, whenever Atlassian releases a new version of the application, we need to be able to create a new image in a few steps. This blog shows how we actually deal with this challenge.
Introducing the Atlassian docker builder
The Atlassian docker builder is an open-source environment that automatically builds containers for all Atlassian applications.
Have a look at the code provided by Dieter Verelst (werus.be).
Here are some of the features in short:
- In case Atlassian switches the download-URL or binary-package-name, it will fetch the correct release file (for example, atlassian-jira-6.4.13.tar.gz — atlassian-jira-software-7.2.3.tar.gz ). You only need to specify the version, the rest is automagic.
- In case of a product-name change (stash-bitbucket), it will still build the correct containers and generalize them along the way.
- In the case of Confluence (> 6.0.0) needing ‘synchrony’, it will add an extra reverse proxy to the container for the web sockets, so you only need to forward: 8090 and not the 8090/8091 as documented by Atlassian. It just works.
- Automatic container configuration embedded for Jira/confluence/Bitbucket (add a configfile, and it will automatically reconfigure the container to perform the necessities like changing the base-url, server.xml, dbconfig.xml, or other). This has been ill-maintained, so support for bitbucket > 5.0 is a bit … dodgy, but it probably still works given the new method is completely different :).
- You can run any container after the build using ‘docker run —rm -it -p 0.0.0.0:8080:8080 atlassian/jira:7.2.3’ for example. Don’t forget to add an extra path to make your application data persistent. ( /opt/Jira/data , /opt/fecru/data/ … ).
- Dependency-based build. You can build Jira 6.4 to java7 or java8, for example, if you wish to do so.
- Atlassian-sdks included in containers.
- It forces rebuilding the container in case it’s required. Otherwise, it will reuse the same layers and end up with the same container.
- Building really old containers. For example, to convert some older mediawiki you can use the Universal Wiki Converter to migrate content to Confluence. But this is only supported up until Confluence 4.3.7. Now you can quickly build a container with that version and get started really fast to make your conversion and destroy the container afterward. It’s all included and tested in this box.
If we needed it before for some reason, it’s on this list.
Using the containers
Before we dive into the details of the Atlassian docker builder, let’s first show how we use these containers to deploy the Atlassian applications.
Bringing up JIRA (with postgres and a reverse proxy) is as simple as copying docker-compose.yml and jira.config – ask us the links directly—into a folder on a docker-enabled machine and run:
docker-compose up -d
docker-compose.yml
version: '2'
services:
#
# The proxy is based on the excellent jwilder images which auto reconfigures whenever a container
# comes up when it provides a VIRTUAL_HOST and VIRTUAL_PORT
#
proxy:
image: jwilder/nginx-proxy
ports:
- 0.0.0.0:80:80
- 0.0.0.0:443:443
volumes:
- /var/run/docker.sock:/tmp/docker.sock
- ./certs:/etc/nginx/certs:ro
networks:
- proxy
#
# The jiradb is a postgres based database service which automatically configures a database for JIRA
# The database name userid and password are defined in the environment
#
jiradb:
image: atlassian/postgres:9.4
volumes:
#
# All data is externalised in the persist directory
#
- ./persist/jira/db:/opt/jira/data
environment:
- DB_PASS=atlassian
- DB_NAME=jira
- DB_USER=atlassian
networks:
- jira
#
# JIRA itself is jira 7.4.0
#
jira:
image: atlassian/jira:7.4.0
volumes:
- ./persist/jira/home:/opt/jira/data
- ./jira.config:/opt/jira/config/jira.config
networks:
- jira
- proxy
environment:
- VIRTUAL_HOST=jira.intranet.local
- VIRTUAL_PORT=8080
networks:
jira:
proxy:
This will bring up JIRA running on top of postgres, behind an nginx based reverse proxy, reachable on Jira’s intranet.
jira.config
The jira.config file is a file describing some parameters required to bring up JIRA:
- Database details
- Baseurl
- Disarm
- Memory settings
It is optional. Check out the ‘docker-compose’ subfolder of the atlassian-docker-builder distribution for more information:
jira {
disarm true
minimumMemory "768m"
maximumMemory "768m"
database {
user "atlassian"
password "atlassian"
host "jiradb"
name "jira"
type "postgres72"
schema "public"
}
baseUrl "https://jira.intranet.local"
}
Building a new version
Whenever Atlassian releases a new version of JIRA, we use the Atlassian docker builder to build a docker image (locally). The steps are really simple:
- Deploy atlassian-docker-builder locally and check the README.md for installation instructions.
- In the local directory, edit roles/meta-atlassian/meta/main.yml and add a line for the application you want to build.
- Run ./build.sh.
The docker image of the application will be added locally, and ready to be used in the docker environment.
The video
The video below shows how you can upgrade your JIRA in less than 5 minutes
- Build a new image using the builder.
- Update docker-compose.yml.
- Done.
Conclusion
Standardizing the deployment of the Atlassian tools is easy due to the atlassian-docker-framework. It is based on a MIT license, so go ahead and give it a try.
