An Atlassian JIRA upgrade journey using docker and the atlassian docker builder

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 which 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 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 to rebuild 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 afterwards. It’s all included and tested in this box.
    If we needed it before for some reason, it’s in 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 into a folder on a docker enabled machine and running:

 

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 http://jira.intranet.local.

jira.config

The jira.config file is a file describing some of the 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 "http://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:

  1. Deploy atlassian-docker-builder locally and check the README.md for installation instructions.
  2. In the local directory, edit roles/meta-atlassian/meta/main.yml and add a line for the application you want to build.
  3. 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.

Are you still using multiple issue trackers?

Check out Exalate an advanced issue synchronization solution which supports cross organization issue tracking.
Its flexibility comes from the built-in groovy scripting capability allowing to implement almost any type of integration.

Leave a Reply

Your email address will not be published. Required fields are marked *