teamatldocker/jira

Dockerized Atlassian Jira

Dockerized Atlassian Jira

Introduction

Run Jira Core, Jira Software, or Jira Service Desk in a Docker container.

"The best software teams ship early and often - Not many tools, one tool. Jira Software is built for every member of your software team to plan, track, and release great software." - [Source]

Products, Versions, and Tags

Product	Version	Tags
Jira Software	8.22.4	latest, 8.22.4, latest.de, 8.22.4.de
Jira Service Desk	4.22.4	servicedesk, servicedesk.4.22.4, servicedesk.de, servicedesk.4.22.4.de
Jira Core	8.22.4	core, core.8.22.4, core.de, core.8.22.4.de

On every release, the oldest and the newest tags are rebuild.

You may also like

• teamatldocker/confluence: Create, organize, and discuss work with your team
• teamatldocker/bitbucket: Code, Manage, Collaborate
• teamatldocker/crowd: Identity management for web apps
• development - running this image for development including a debugger

Setup

Docker-Compose:

Jira will be available at http://yourdockerhost

$ curl -O https://raw.githubusercontent.com/teamatldocker/jira/master/docker-compose.yml
$ docker-compose up -d

Docker-CLI:

Jira will be available at http://yourdockerhost Data will be persisted inside docker volume jiravolume.

docker run -d -p 80:8080 -v jiravolume:/var/atlassian/jira --name jira teamatldocker/jira

Docker run

1. Start Database

This uses the postgres image. Data will be persisted inside docker volume postgresvolume. Note: You should change the password!

docker network create jiranet
docker run --name postgres -d \
    --network jiranet \
    -v postgresvolume:/var/lib/postgresql \
    -e 'POSTGRES_USER=jira' \
    -e 'POSTGRES_PASSWORD=jellyfish' \
    -e 'POSTGRES_DB=jiradb' \
    -e 'POSTGRES_ENCODING=UNICODE' \
    -e 'POSTGRES_COLLATE=C' \
    -e 'POSTGRES_COLLATE_TYPE=C' \
    postgres:9.5-alpine

2. Start Jira

docker run -d --name jira \
    --network jiranet \
    -v jiravolume:/var/atlassian/jira \
	  -e "JIRA_DATABASE_URL=postgresql://jira@postgres/jiradb" \
	  -e "JIRA_DB_PASSWORD=jellyfish"  \
	  -p 80:8080 teamatldocker/jira

Proxy Configuration

You can specify your proxy host and proxy port with the environment variables JIRA_PROXY_NAME and JIRA_PROXY_PORT. The value will be set inside the Atlassian server.xml at startup!

When you use HTTPS then you also have to include the environment variable JIRA_PROXY_SCHEME.

Example

This will set the values inside the server.xml in /opt/jira/conf/server.xml and build the image with the current Jira release

• Proxy Name: myhost.example.com
• Proxy Port: 443
• Poxy Protocol Scheme: https

docker run -d --name jira \
    -v jiravolume:/var/atlassian/jira \
    -e "JIRA_PROXY_NAME=myhost.example.com" \
    -e "JIRA_PROXY_PORT=443" \
    -e "JIRA_PROXY_SCHEME=https" \
    teamatldocker/jira

Database Setup for Official Database Images

1. Start a database server.
2. Create a database with the correct collate.
3. Start Jira.

Example with PostgreSQL:

First start the database server:

Note: Change Password!

docker network create jiranet
docker run --name postgres -d \
    --network jiranet \
    -e 'POSTGRES_USER=jira' \
    -e 'POSTGRES_PASSWORD=jellyfish' \
    postgres:9.5

This is the official Postgres image.

Then create the database with the correct collate:

docker run -it --rm \
    --network jiranet \
    postgres:9.5-alpine \
    sh -c 'exec createdb -E UNICODE -l C -T template0 jiradb -h postgres -p 5432 -U jira'

Password is jellyfish. Creates the database jiradb under user jira with the correct encoding and collation.

Then start Jira:

Start the Jira and link it to the postgres instance.

docker run -d --name jira \
    --network jiranet \
    -v jiravolume:/var/atlassian/jira \
	  -e "JIRA_DATABASE_URL=postgresql://jira@postgres/jiradb" \
	  -e "JIRA_DB_PASSWORD=jellyfish" \
	  -p 80:8080 teamatldocker/jira

Demo Database Setup

Note: It's not recommended to use a default initialized database for Jira in production! The default databases are all using a not recommended collation! Please use this for demo purposes only!

This is a demo "by foot" using the docker cli. In this example, we setup an empty PostgreSQL container. Then we connect and configure the Jira accordingly. Afterwards, the Jira container can always resume on the database.

Steps:

• Start Database container
• Start Jira

PostgreSQL

Let's use a PostgreSQL image and set it up:

PostgreSQL - official image

$ docker network create jiranet
$ docker run --name postgres -d \
    --network jiranet \
    -e 'POSTGRES_DB=jiradb' \
    -e 'POSTGRES_USER=jiradb' \
    -e 'POSTGRES_PASSWORD=jellyfish' \
    postgres:9.5-alpine

PostgreSQL - community image

$ docker run --name postgres -d \
    --network jiranet \
    -e 'DB_USER=jiradb' \
    -e 'DB_PASS=jellyfish' \
    -e 'DB_NAME=jiradb' \
    sameersbn/postgresql:9.5-4

Now start the Jira container and let it use the container. On first startup you have to configure your Jira yourself and fill it with a test license. Afterwards every time you connect to a database the Jira configuration will be skipped.

$ docker run -d --name jira \
    --network jiranet \
    -v jiravolume:/var/atlassian/jira \
	  -e "JIRA_DATABASE_URL=postgresql://jiradb@postgres/jiradb" \
	  -e "JIRA_DB_PASSWORD=jellyfish" \
	  -p 80:8080 teamatldocker/jira

MySQL

Let's use a MySQL image and set it up:

MySQL - official image

$ docker network create jiranet
$ docker run -d --name mysql \
    --network jiranet \
    -e 'MYSQL_ROOT_PASSWORD=verybigsecretrootpassword' \
    -e 'MYSQL_DATABASE=jiradb' \
    -e 'MYSQL_USER=jiradb' \
    -e 'MYSQL_PASSWORD=jellyfish' \
    mysql:5.6

Now start the Jira container and let it use the container. On first startup you have to configure your Jira yourself and fill it with a test license. Afterwards every time you connect to a database the Jira configuration will be skipped.

$ docker run -d --name jira \
    --network jiranet \
    -v jiravolume:/var/atlassian/jira \
    -e "JIRA_DATABASE_URL=mysql://jiradb@mysql/jiradb" \
    -e "JIRA_DB_PASSWORD=jellyfish"  \
    -p 80:8080 \
    teamatldocker/jira

SQL Server

Starting with version 7.8.0 of Jira, Atlassian no longer provides/uses the jTDS JDBC driver and instead bundles the Microsoft JDBC driver. This proves to be a bit of a headache because while the jTDS driver used the conventional JDBC URL scheme, Microsoft's driver uses a non-standard JDBC URL scheme that departs wildly from the usual (see Issue #72 for details). As a result of this deviation from the standard, users wishing to connect to a SQL Server database MUST encode their host/port/database information in the JIRA_DATABASE_URL and cannot leverage the individual JIRA_DB_* variables. Note that any additional driver properties needed can be appended in much the same was as databaseName is handled in the example below.

docker run \
    -d \
    --name jira \
    --network jiranet \
    -v jiravolume:/var/atlassian/jira \
    -e "JIRA_DATABASE_URL=sqlserver://MySQLServerHost:1433;databaseName=MyDatabase" \
    -e "JIRA_DB_USER=jira-app" \
    -e "JIRA_DB_PASSWORD=***" \
    -p 8080:8080 \
    teamatldocker/jira

Database Wait Feature

A Jira container can wait for the database container to start up. You have to specify the host and port of your database container and Jira will wait up to one minute for the database.

You can define the waiting parameters with the environment variables:

• DOCKER_WAIT_HOST: The host to poll Mandatory!
• DOCKER_WAIT_PORT: The port to poll Mandatory!
• DOCKER_WAIT_TIMEOUT: The timeout in seconds. Optional! Default: 60
• DOCKER_WAIT_INTERVAL: The time in seconds we should wait before polling the database again. Optional! Default: 5

Example waiting for a PostgreSQL database:

First start Jira:

docker network create jiranet
docker run --name jira \
    --network jiranet \
    -v jiravolume:/var/atlassian/jira \
    -e "DOCKER_WAIT_HOST=postgres" \
    -e "DOCKER_WAIT_PORT=5432" \
	  -e "JIRA_DATABASE_URL=postgresql://jira@postgres/jiradb" \
	  -e "JIRA_DB_PASSWORD=jellyfish"  \
	  -p 80:8080 teamatldocker/jira

Waits at most 60 seconds for the database.

Start the database within 60 seconds:

docker run --name postgres -d \
    --network jiranet \
    -v postgresvolume:/var/lib/postgresql \
    -e 'POSTGRES_USER=jira' \
    -e 'POSTGRES_PASSWORD=jellyfish' \
    -e 'POSTGRES_DB=jiradb' \
    -e 'POSTGRES_ENCODING=UNICODE' \
    -e 'POSTGRES_COLLATE=C' \
    -e 'POSTGRES_COLLATE_TYPE=C' \
    postgres:9.5-alpine

Build The Image

docker-compose build jira

If you want to build a specific release, just replace the version in .env and again run

docker-compose build jirqa

• Proxy Name: myhost.example.com
• Proxy Port: 443
• Poxy Protocol Scheme: https

Just type:

$ docker run -d --name jira \
    -v jiravolume:/var/atlassian/jira \
    -e "JIRA_PROXY_NAME=myhost.example.com" \
    -e "JIRA_PROXY_PORT=443" \
    -e "JIRA_PROXY_SCHEME=https" \
    teamatldocker/jira

Will set the values inside the server.xml in /opt/jira/conf/server.xml

NGINX HTTP Proxy

This is an example on running Atlassian Jira behind NGINX with 2 Docker commands!

First start Jira:

$ docker network create jiranet
$ docker run -d --name jira \
    --network jiranet \
    -v jiravolume:/var/atlassian/jira \
    -e "JIRA_PROXY_NAME=192.168.99.100" \
    -e "JIRA_PROXY_PORT=80" \
    -e "JIRA_PROXY_SCHEME=http" \
    teamatldocker/jira

Example with dockertools

Then start NGINX:

$ docker run -d \
    -p 80:80 \
    --network jiranet \
    --name nginx \
    -e "SERVER1REVERSE_PROXY_LOCATION1=/" \
    -e "SERVER1REVERSE_PROXY_PASS1=http://jira:8080" \
    teamatldocker/nginx

Jira will be available at http://192.168.99.100.

NGINX HTTPS Proxy

This is an example on running Atlassian Jira behind NGINX-HTTPS with2 Docker commands!

Note: This is a self-signed certificate! Trusted certificates by letsencrypt are supported. Documentation can be found here: teamatldocker/nginx

First start Jira:

$ docker network create jiranet
$ docker run -d --name jira \
    --network jiranet \
    -v jiravolume:/var/atlassian/jira \
    -e "JIRA_PROXY_NAME=192.168.99.100" \
    -e "JIRA_PROXY_PORT=443" \
    -e "JIRA_PROXY_SCHEME=https" \
    teamatldocker/jira

Example with dockertools

Then start NGINX:

$ docker run -d \
    -p 443:443 \
    --name nginx \
    --network jiranet \
    -e "SERVER1REVERSE_PROXY_LOCATION1=/" \
    -e "SERVER1REVERSE_PROXY_PASS1=http://jira:8080" \
    -e "SERVER1CERTIFICATE_DNAME=/CN=CrustyClown/OU=SpringfieldEntertainment/O=crusty.springfield.com/L=Springfield/C=US" \
    -e "SERVER1HTTPS_ENABLED=true" \
    -e "SERVER1HTTP_ENABLED=false" \
    teamatldocker/nginx

Jira will be available at https://192.168.99.100.

Configuration

A Word About Memory Usage

Jira like any Java application needs a huge amount of memory. If you limit the memory usage by using the Docker --mem option make sure that you give enough memory. Otherwise, Jira will begin to restart randomly.

You should give at least 1-2GB more than the JVM maximum memory setting to your container.

Java JVM memory settings are applied by manipulating properties inside the setenv.sh file and this image can set those properties for you.

The following example applies the minimum memory for Jira 8.0+ of 2048 megabytes and a maximum of 8192 megabytes.

The correct properties from the Atlassian documentation are:

• JVM_MINIMUM_MEMORY
• JVM_MAXIMUM_MEMORY

The image will set those properties, if you precede the property name with SETENV_.

docker run -d -p 80:8080 --name jira \
    -v jiravolume:/var/atlassian/jira \
    -e "SETENV_JVM_MINIMUM_MEMORY=2048m" \
    -e "SETENV_JVM_MAXIMUM_MEMORY=8192m" \
    teamatldocker/jira

Jira Startup Plugin Purge

You can enable osgi plugin purge on startup and restarts. The image will merciless purge the direcories

• /var/atlassian/jira/plugins/.bundled-plugins
• /var/atlassian/jira/plugins/.osgi-plugins

This will help solving corrupted plugin caches. Make sure to increasing the plugin timeout because Jira will have to rebuild the whole cache at each startup.

This is controlled by the environment variable JIRA_PURGE_PLUGINS_ONSTART. Possible values:

• true: Purge will be done each time container is started or restarted.
• false (Default): No purge will be done.

Example:

$ docker run -d -p 80:8080 -v jiravolume:/var/atlassian/jira \
    -e "JIRA_PURGE_PLUGINS_ONSTART=true" \
    --name jira teamatldocker/jira

Jira SSO With Crowd

You enable Single Sign On with Atlassian Crowd. What is crowd?

"Users can come from anywhere: Active Directory, LDAP, Crowd itself, or any mix thereof. Control permissions to all your applications in one place – Atlassian, Subversion, Google Apps, or your own apps." - Atlassian Crowd

This is controlled by the environment variable JIRA_CROWD_SSO. Possible values:

• true: Jira configuration will be set to Crowd SSO authentication class at every restart.
• false: Jira configuration will be set to Jira Authentication class at every restart.
• ignore (Default): Config will not be touched, current image setting will be taken.

You have to follow the manual for further settings inside Jira and Crowd: Documentation

Example:

$ docker run -d -p 80:8080 -v jiravolume:/var/atlassian/jira \
    -e "JIRA_CROWD_SSO=true" \
    --name jira teamatldocker/jira

SSO will be activated, you will need Crowd in order to authenticate.

Custom Configuration

You can use your customized configuration, e.g. Tomcat's server.xml. This is necessary when you need to configure something inside Tomcat that cannot be achieved by this image's supported environment variables. I will give an example for server.xml any other configuration file works analogous.

1. First create your own valid server.xml.
2. Mount the file into the proper location inside the image. E.g. /opt/jira/conf/server.xml.
3. Start Jira

docker run -d --name jira \
    -p 80:8080 \
    -v jiravolume:/var/atlassian/jira \
    -v $(pwd)/server.xml:/opt/jira/conf/server.xml \
    teamatldocker/jira

Note: server.xml is located in the directory where the command is executed.

Extending This Image

You can easily extend this image with your own tooling by following the example below:

FROM teamatldocker/jira

USER root

... Install your tooling ...

USER jira
CMD ["jira"]

Upgrading Jira

Run in debug mode

This description is without any guarantee as this procedure may get outdated or omit critical details which may lead to data loss. Use at own risk. If you want to run Jira with a debug port, please see examples/debug - essentially what we do is

• we add the debug port as an env parameter
• we overwrite the start-jira.sh script so we do not user catalina.sh run as startup bun rater catalina.sh jpda run .. that is about anything we changed in there
• we expose the port 5005 to the host so we can connect

Before you take any action make sure you can potentially upgrade:

1. Check inside Jira administration panel if your installed plugins are all upwards compatible. Jira has a very good feedback system where you can see if you plugin provider is compatible to the latest Jira version.

2. Check or ask inside this repository if anyone has tested the latest image. I have experienced issues when Jira has upgraded to a new major version: E.g. 6.x to 7.x. In this case sometimes the image has to be adapted. Minor versions and especially bugfix version can be usually be used without any problems.

Now make a Backup in order to be able to fallback:

1. Stop your database and Jira instance.
2. Make a backup of your volumes. (Both Jira and database). For example use (https://github.com/blacklabelops/volumerize)[blacklabelops/volumerize] to backup your volume.

Now Upgrade your Jira container:

1. Remove your stopped Jira container: docker rm your_jira_container_name
2. Upgrade your local image: docker pull teamatldocker/jira:new_version
3. Use the same start command as the last container but with the new image teamatldocker/jira:new_version
4. Jira will start its upgrading routine on both the local files and database. Run docker logs -f your_jira_container_name and lookout for error messages.

Now Test your Jira instance:

1. Login and check your functionality
2. Check if all plugins are running
3. Check Jira administration pannel for error messages

Test okay?

Your finished!

Test not okay?

Rollback:

1. Stop Jira and database instance.
2. Play back your backup. E.g. delete volumes, create volumes and copy back old files. Both Jira and database! You can simplify things with blacklabelops/volumerize.
3. Remove your stopped Jira container: docker rm your_jira_container_name
4. Use the same start command as the last container but with the old image teamatldocker/jira:old_version

Example

Let's assume your running Jira 7.6.2 with my example setup and you want to upgrade to Jira 7.7.1.

PostgreSQL has been started with the following settings:

$ docker run --name postgres -d \
    --network jiranet \
    -v postgresvolume:/var/lib/postgresql \
    ...
    postgres:9.5-alpine

Jira has been started with the following settings:

$ docker run -d --name jira \
    --network jiranet \
    -v jiravolume:/var/atlassian/jira \
	  ...
	  -p 80:8080 teamatldocker/jira:7.6.2

This means:

• Jira instance has name jira and data is inside volume jiravolume and has version 7.6.2.
• Database instance has name postgres and data is inside volume postgresvolume.

Stop both instance with the following commands:

$ docker stop jira
$ docker stop postgres

Correct order is first Jira then database.

Backup both volumes in order to be able to Rollback. In this example we use blacklabelops/volumerize to backup to another volume.

Run the following command to backup both database and Jira in one simple step:

$ docker run \
    --rm \
    -v jiravolume:/source/application_data:ro \
    -v postgresvolume:/source/application_database_data:ro \
    -v jirabackup:/backup \
    -e "VOLUMERIZE_SOURCE=/source" \
    -e "VOLUMERIZE_TARGET=file:///backup" \
    blacklabelops/volumerize backup

jiravolume and postgresvolume will have a backup inside jirabackup.

Now Upgrade Jira by switching the container to a new image:

$ docker rm jira
$ docker pull teamatldocker/jira:7.7.1

Start the database and Jira with the same parameters as before but with the new image tag 7.7.1:

$ docker start postgres
$ docker run -d --name jira \
    --network jiranet \
    -v jiravolume:/var/atlassian/jira \
	  ...
	  -p 80:8080 teamatldocker/jira:7.7.1

Wait until Jira has ended the upgrade procedure and your instance is available again!

1. Login and check your functionality
2. Check if all plugins are running
3. Check the Jira administration panel for error messages

If everything looks good, you're finished!

If you encountered an issue, you can Rollback to the last version.

Stop both instance with the following commands:

docker stop jira
docker stop postgres

Restore both volumes in order to be able to use the last version again. In this example we use blacklabelops/volumerize to restore from another volume.

Run the following command to restore both database and Jira in one simple step:

$ docker run \
    --rm \
    -v jiravolume:/source/application_data \
    -v postgresvolume:/source/application_database_data \
    -v jirabackup:/backup:ro \
    -e "VOLUMERIZE_SOURCE=/source" \
    -e "VOLUMERIZE_TARGET=file:///backup" \
    blacklabelops/volumerize restore

Data will be written back to jiravolume and postgresvolume.

Start the old version again:

Start the database and Jira with the same parameters as before but with the old image 7.6.2:

$ docker start postgres
$ docker rm jira
$ docker run -d --name jira \
    --network jiranet \
    -v jiravolume:/var/atlassian/jira \
	  ...
	  -p 80:8080 teamatldocker/jira:7.6.2

jira's Issues

docker-compose up

使用docker-compose up -d启动jira的时候报下面的错误：
jirasoftware | mkdir: can't create directory '/var/atlassian/jira/log': Permission denied

Heads up!

Really nice work here, almost entirely complete, even a matching postgresql handling the encoding.

I just wanted to thank you! I am creating a public rancher catalog on top of your images, thank you!

Explain volume usages

Its uncommon for images to not talk about data persistence. That said, since it can lead to serious issues that people use anon volumes ( docker-compose down and your killed ), you should update each example mounting a named volume at /var/atlassian/jira and /var/lib/postgresql - its regular practice to do so since it protects from a lot of harm.

I am aware, that people should actually know that, but that is a good reminder.

Reverse proxy providing SSL in front of JIRA

I ended up needing a connector like this in server.xml. Otherwise, JIRA would keep reporting the scheme mismatch wherein the diagnostics detect https (due to accessing on secure URL) and JIRA would detect http given tomcat configuration within the container.

<Connector acceptCount="100"
              connectionTimeout="20000"
              disableUploadTimeout="true"
              enableLookups="false"
              maxHttpHeaderSize="8192"
              maxThreads="150"
              minSpareThreads="25"
              port="8080"
              protocol="HTTP/1.1"
              redirectPort="8443"
              useBodyEncodingForURI="true"
              scheme="https"
              proxyName="jira.example.com"
              proxyPort="443" />

And a Dockerfile like so:

FROM blacklabelops/jira:core.7.3.0
ADD server.xml /opt/jira/conf

Do you think this is a generic enough use-case that it can be supported through an ENV variable through blacklabelops/jira?

[Question] nginx and letsencrypt 502 Bad Gateway

Him I would like to ask on ow to setp jira using letsencrypt.

I tried these ff commands but failed.

docker run -d --name jiraserver \
    -v jiravolume:/var/atlassian/jira \
    -e "JIRA_PROXY_NAME=mydomain.com" \
    -e "JIRA_PROXY_PORT=443" \
    -e "JIRA_PROXY_SCHEME=https" \
    blacklabelops/jira


docker run --rm \
    -p 80:80 \
    -p 443:443 \
    -v letsencrypt_certificates:/etc/letsencrypt \
    -e "[email protected]" \
    -e "LETSENCRYPT_DOMAIN1=mydomain.com" \
    blacklabelops/letsencrypt install

docker run -d \
    -p 443:443 \
    -p 80:80 \
    -v letsencrypt_certificates:/etc/letsencrypt \
    -v letsencrypt_challenges:/var/www/letsencrypt \
    -e "NGINX_REDIRECT_PORT80=true" \
    -e "SERVER1REVERSE_PROXY_LOCATION1=/" \
    -e "SERVER1REVERSE_PROXY_PASS1=http://jiraserver:8080" \
    -e "SERVER1HTTPS_ENABLED=true" \
    -e "SERVER1HTTP_ENABLED=true" \
    -e "SERVER1LETSENCRYPT_CERTIFICATES=true" \
    -e "SERVER1CERTIFICATE_FILE=/etc/letsencrypt/live/mydomain.com/fullchain.pem" \
    -e "SERVER1CERTIFICATE_KEY=/etc/letsencrypt/live/mydomain.com/privkey.pem" \
    -e "SERVER1CERTIFICATE_TRUSTED=/etc/letsencrypt/live/mydomain.com/fullchain.pem" \
    --name nginx \
    blacklabelops/nginx

docker run -d \
    -v letsencrypt_certificates:/etc/letsencrypt \
    -v letsencrypt_challenges:/var/www/letsencrypt \
    -e "LETSENCRYPT_WEBROOT_MODE=true" \
    -e "[email protected]" \
    -e "LETSENCRYPT_DOMAIN1=mydomain.com" \
    --name letsencrypt \
    blacklabelops/letsencrypt

Thank you

Check if Postgres Database is ready before startup

Prerequisites

• [X ] Put an X between the brackets on this line if you have done all of the following:
  • Reproduced the problem.
  • Checked that your issue isn't already filed.
  • Filled the form.
  • Included logs and system information.

Description

Jira starts up before postgres is ready most of the time. It would be nice to have an option where the jira container checks if postgres is ready like (this)[https://github.com/docker/compose/issues/374#issuecomment-300671114]

Steps to Reproduce

1. docker-compose file with postgres database and jira containers
2. docker-compose up
3. jira is broken with generic "cannot connect to database" page

Expected behavior: Jira container to check for dependent database to be ready

Actual behavior: A race condition on startup with the database

Reproduces how often: For me, every time. But I imagine this changes depending on a lot of factors.

Versions

blacklabelops/jira:7.6.0

Logs And Environment Information

Docker version 1.13.1, build 092cba3
Ubuntu Release: 16.04
docker-compose version 1.8.0

version: '2.0'
services:

  jira-postgres:
    build: jira-postgres
    restart: always
    networks:
      - atlassian
    volumes:
      - /etc/timezone:/etc/timezone
      - jiraDatabaseVol:/var/lib/postgresql/data

  jira:
    build: jira
    restart: always
    networks:
      atlassian:
        aliases:
          - jira
    ports:
      - "8080:8080"
    volumes:
      - /etc/timezone:/etc/timezone
      - jiraVol:/var/atlassian/jira
    links:
      - jira-postgres:postgres
    environment:
      - "JIRA_DATABASE_URL=postgresql://jirauser@postgres/jiradbihave"
      - "JIRA_DB_PASSWORD=mypassword"
      - "JIRA_PROXY_NAME=jira.proxy.net"
      - "JIRA_PROXY_PORT=443"
      - "JIRA_PROXY_SCHEME=https"
    depends_on:
      - jira-postgres

Update to Jira 7.3.3

Hello,

first i want to thank you for sharing this useful, easy to use, docker container. It works very well on my server. The only thing is that i want to update to version 7.3.3. Will there be a newer image coming soon with this version?

Best regards,

Merlin

JIRA core tag version 7.3.0 does not exist

The readme cites core.7.3.0 as the latest tag available for JIRA core, but it does not exist on docker hub? Am I reading this correctly?

Thanks for awesome alpine images.

Jira 7.3.5 is available

I'm about done for the night, but I can do a pull request tomorrow if you want.

https://confluence.atlassian.com/adminjira/jira-platform-releases/jira-7-3-x-platform-release-notes

Any plans to allow multiple proxy connectors?

Du to the nature of service-desk you might have a different customer-domain for your service-desk compared to the domain for your "internal" use of jira.

Handling this requires 2 different connector entries, but right now only one is possible.

Shall we make the service.xml be overwriteable by a custom file - one we mount somewhere and copy over on very container start ( needed in case of codebase updates )? This would open a wide range of flexible solutions for customizing server.xml without you being in charge implementing it bit by bit ( though i really like the ENV way..)

Reserving Older Images

I have just seen that dockerhub seems to delete older images when a number of overall images is reached. The oldest image is 9 months old, although this repository is more than 2 years old.

Does this affect anybody? Do you need to pull images older than 1 year or is everybody up to date?

Crowd SSO Support Enabler/Disabler

Request by someone to enable crowd SSO support.

Described here Integrating Crowd with Atlassian JIRA

Todo:

Environment variable to enable the following entry:

file: JIRA/atlassian-jira/WEB-INF/classes/seraph-config.xml
Comment-Out: <!--<authenticator class="com.atlassian.jira.security.login.JiraSeraphAuthenticator"/>-->
Un-Comment: <authenticator class="com.atlassian.jira.security.login.SSOSeraphAuthenticator"/>

And vice versa.

Guide to create a bitbucket-server docker image

I understand that this issue is not jira related, but i am not sure how i would reach you witch such a topic best.

I would like to create a bitbucket server docker image, based on what you do.

Are there any starting points you want to me to look at - i can try to get along with your Dockerfile here, i surely have to somehow adjust the answerfile and things like that.

Any chance you would like to join efforts and do this under your flag, blacklabelops/bitbucket?

There is also https://bitbucket.org/atlassian/docker-atlassian-bitbucket-server - so there is also a question if it makes sense - it seems to be maintained

Promote the docker-compose.yml

Not sure why people love to do and read overcomplicated docker run examples which never going to be used in any real case scenario and also are by no means elegant, practical or a shortcut.

You should really consider giving the people a curl docker-compose.yml && docker-compose up example, pointing at docker-compose.yml lines to document variables - this will make the jump start a lot easier.

docker run examples should be considered advanced topic or deeper explanation.

Just my POV, ignore it if its to blurred for you :)

Limit Docker logging?

Should Docker logging be limited by adding something as follows to docker-compose.yml?

logging:
      # limit logs retained on host to 25MB
      driver: "json-file"
      options:
        max-size: "500k"
        max-file: "50"

Could not create connection to database server.

@blacklabelops

I'd like to connect mysql via official mysql container with below code:

docker run -d --name mysql \
  -e 'MYSQL_ROOT_PASSWORD=pass1234' \
  -e 'MYSQL_DATABASE=jiradb' \
  -e 'MYSQL_USER=jiradb' \
  -e 'MYSQL_PASSWORD=jellyfish' \
  -p 3306:3306 \
  mysql:5.7.7

But after run jira container

docker run -d --name jira \
    -e "DATABASE_URL=mysql://jiradb@mysql/jiradb" \
    -e "DB_PASSWORD=jellyfish"  \
    --link mysql:mysql \
    -p 8100:8080 \
    blacklabelops/jira

I got error:

2015-08-02 04:59:08,972 localhost-startStop-1 ERROR [NoModule] Error getting datasource via DBCP: JdbcDatasourceInfo{uri='jdbc:mysql://mysql:3306/jiradb?autoReconnect=true&characterEncoding=utf8&useUnicode=true&sessionVariables=storage_engine%3DInnoDB', driverClassName='com.mysql.jdbc.Driver', username='jiradb', password='********', isolationLevel='null', connectionProperties=null, connectionPoolInfo=ConnectionPoolInfo{maxSize=20, minSize=20, initialSize=null, maxIdle=20, maxWait=30000, sleepTime=300000, lifeTime=600000, deadLockMaxWait=600000, deadLockRetryWait=10000, validationQuery=null, minEvictableTimeMillis=null, timeBetweenEvictionRunsMillis=null, poolPreparedStatements=null, testOnBorrow=null, testOnReturn=null, testWhileIdle=null, maxOpenPreparedStatements=null, numTestsPerEvictionRun=null, removeAbandonedTimeout=300, validationQueryTimeout=null, defaultCatalog=null}}
org.apache.commons.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory (Could not create connection to database server. Attempted reconnect 3 times. Giving up.)
at org.apache.commons.dbcp.BasicDataSource.createPoolableConnectionFactory(BasicDataSource.java:1549)

Can you help?

always get postgresql timeout

Running the docker-compose on ubuntu 16.04 will always run into the following error "Timeout after 1m0s waiting on dependencies to become available: [tcp://postgresql:5432]"

Running the same on mac osx all is fine. Is there any solution to fix it?

request: allow for reverse proxy as <domain/ip-address>/jira

The following currently fails:

docker network create jiranet
docker run -d --name jira --network jiranet -v jiravolume:/var/atlassian/jira -e "JIRA_PROXY_NAME=10.0.0.21” -e "JIRA_PROXY_PORT=8111” -e "JIRA_PROXY_SCHEME=http” blacklabelops/jira
docker run -d -p 8111:80 --network jiranet --name nginx -e "SERVER1REVERSE_PROXY_LOCATION1=/jira” -e "SERVER1REVERSE_PROXY_PASS1=http://jira:8080” blacklabelops/nginx

Gives an error message when visiting http://10.0.0.21:8111/jira

Oops, you've found a dead link

Xmx option doesn't limit memory usage

I'm trying to limit the memory usage of jira. My compose file looks like:

jira:
    image: blacklabelops/jira
    container_name: jira
    mem_limit: 1350m
    volumes:
      - jira_home:/var/atlassian/jira
    ports:
      - 8080:8080
    environment:
      - 'CATALINA_OPTS= -Xms256m -Xmx400m'
    network_mode: "host"
    depends_on:
      - "postgres"
    restart: always

I set Xmx to 400 just to test the memory usage. Just from starting the container, I get up to 1gb. Shouldn't the Xmx400m limit that, or am I misunderstanding the purpose of that? If so, is there any other way to limit the memory usage? The problem I'm running into is when jira uses too much memory, the container just restarts.

Also, it appears your hipchat is down. I just get redirected to hipchat signup

Update to JIRA Core 7.4.0 / JIRA Software 7.4.0 / JIRA Servicedesk 3.6.0

Add restart to docker-compose?

Would it be beneficial to add restart: always to docker-compose.yml?

Atlassian Database Collate Correction

Currently all demos are using the official images, therefore running inside the wrong collate. Collate correction must be handled manually which does not work for automation, e.g. docker-compose.

Solution:

• New Atlassian PostgreSQL or MySQL Docker container, rewrapping the official and implementing the atlassian database installation routine.

Wrong JVM version! You are running with .. but JIRA requires at least 1.8 to run

Hello,

when i using your image locally with docker-compose on my arch linux i've got no problem but when I use it on my server (alpine 3.7) i've got the following message :

Wrong JVM version! You are running with .. but JIRA requires at least 1.8 to run.

Any idea ?

Thanks for support.

Add timezone handling for JIRA

it can be critical to have a different timezone then UTC if you migrated your jira, e.g. for worklogs and tempo.

Can't connect to Atlassian Marketplace due to DNS issues

Sorry if this is a general Docker issue and not due to your images, but JIRA can't connect to Marketplace. I guess it's due to name resolution not working from inside the container:

# docker exec -it jira /bin/bash
bash-4.3$ nslookup google.com
nslookup: can't resolve '(null)': Name does not resolve
nslookup: can't resolve 'google.com': Try again

Any idea on how to fix this? I'm using your docker-compose.yml.

PS:

Docker version 17.05.0-ce, build 89658be
docker-compose version 1.13.0, build 1719ceb

Jira upgrade path using immutable docker containers

Hi there,

I am trying to figure out the correct upgrade path when using immutable Jira containers... I could not find much so far, the most complete description I could find being cptactionhank/docker-atlassian-jira#3 .

The problem with the description is that it does not seem to be foolproof, especially when upgrading to major upgrades (e.g. 6.x.x => 7.x.x), and that it does not mention how to deal with installed add-ons.

Any information/opinion/links on the subject?

Em

Add ability to configure proxy settings in server.xml

When running jira behind the proxy some things like attachments does not work correctly, unless one logs into running jira container and update server config, adding proxy-related settings to the <Connector/> section, like so:

<Service  name="Catalina">
       <Connector
       port="8080"
       proxyName="external.proxy.address"
       proxyPort="443"
       scheme="https"
       secure="true"
       maxThreads="150"
       minSpareThreads="25"
       connectionTimeout="20000"
       enableLookups="false"
       maxHttpHeaderSize="8192"
       protocol="HTTP/1.1"
       useBodyEncodingForURI="true"
       redirectPort="8443"
       acceptCount="100"
       disableUploadTimeout="true"
       bindOnInit="false"
   />

It would be great if these settings could be passed as environment variables to the container.

urldecode replaces % to x

Prerequisites

• [ X ] Put an X between the brackets on this line if you have done all of the following:
  • Reproduced the problem.
  • Checked that your issue isn't already filed.
  • Filled the form.
  • Included logs and system information.

Description

If the username has %40 instead of replacing %40 to @, urldecode changes it to x40. This causes problem with database connection

Steps to Reproduce

If username as hello@world, then when we pass in uri it will be postgres://hello%[email protected]

Expected behavior: [What you expect to happen]
Username should be hello@world in the dbconfig.xml

Actual behavior: [What actually happens]

username ios hellox40world in the dbconfig.xml

Reproduces how often:
100%

Have the fix. Will raise a pr as soon as i test it.

Jira 7.5.1 is out!

If you don't get a chance before, I'll do a pull request this weekend.

https://confluence.atlassian.com/jirasoftware/issues-resolved-in-7-5-1-939495773.html

Nothing too major.

Database Driver Version

Currently the container is running with Postgres Driver 9.1. The driver should mirror the database version.

Solutions:

• Either always install latest Postgres when driver is downwards compatible
• Some way of being able to choose the database version: Env variable then download in entrypoint.

Note: Same with MySQL.

Should we move from MySQL driver 5.1.46 to 8.0.11?

Should we move mysql-connector-java from 5.1.46 to 8.0.11?

Per their website:

MySQL Connector/J 8.0 is highly recommended for use with MySQL Server 8.0, 5.7, 5.6, and 5.5. Please upgrade to MySQL Connector/J 8.0.

The only concern I would have is if they built for a higher Java version than the lowest version Atlassian supports for Jira.

Immutable Images - Daily new tag builds

The versioned tags are changing SHA1 daily.

This is unfriendly to SWARM clusters (and similar) which lock hash + tag version, but then are not able to download the container image the next day to a new swarm host because the hash has changed.

The build process should be improved to only rebuild when necessary.

Fails for SQL Server (new JDBC driver from Atlassian)

Atlassian introduced use of a new JDBC driver (the one created by Microsoft) and version 7.8.0 no longer includes the prior jTDS JDBC driver. The current docker definition needs to be revised to adjust for this.

New JDBC Driver Classname:
com.microsoft.sqlserver.jdbc.SQLServerDriver

New URL Scheme:
jdbc:sqlserver://[serverName[\instanceName][:portNumber]][;property=value[;property=value]]

See also:

• https://confluence.atlassian.com/jirakb/updating-jdbc-url-for-microsoft-sql-server-934718842.html
• https://confluence.atlassian.com/jirakb/using-integrated-security-with-mssql-for-jira-939494383.html

Support for Postgres 10

Will you be adding support for Postgres 10 with your Jira image?

Although this is not officially supported yet, We have done this by including the latest postgres drivers in our internal builds.

https://jdbc.postgresql.org/

Adding any certificate to the Java Keystore

Hi,

We need to add a certificate to the java keystore to allow Jira (and confluence) to connect to our internal user directory. This is already done for the letsencrypt certificates.

Would it be possible to add variables to allow to do that for certificates of our choice ?

Em

Document 'CATALINA_OPTS= -Xms256m -Xmx1g'

One of the more important options for regular use, i saw it in the docker-compose.yml - you should mention it in the README

docker-complose file is not working

Prerequisites

• Put an X between the brackets on this line if you have done all of the following:
  • Reproduced the problem.
  • Checked that your issue isn't already filed.
  • Filled the form.
  • Included logs and system information.

Description

when boot jira app by using docker-compose, jira boot failed, cannot connect to mysql database.

if only using "docker run" commands to boot jira app, it is fine.

Steps to Reproduce

1. [First Step]
2. [Second Step]
3. [and so on...]

Expected behavior: [What you expect to happen]

Actual behavior: [What actually happens]

Reproduces how often: [What percentage of the time does it reproduce?]

Versions

Logs And Environment Information

7.5.0 release

Would be nice if there was 7.5.0 release as well. Thanks in advance!

Proposal: Adjusting Server.xml With Envs

You can vote for this feature. Do you need this?

Adjusting the server.xml connector attributes with envs.

Example:

$ docker run -d -p 80:8090 -p 8091:8091 \
    --name jira \
    -e "JIRA_CONNECTOR_PROPERTY1=proxyPort" \
    -e "JIRA_CONNECTOR_VALUE1=80" \
    -e "JIRA_CONNECTOR_PROPERTY2=proxyName" \
    -e "JIRA_CONNECTOR_VALUE2=confluence.example.org" \
    blacklabelops/jira

Broken Support Channel Link

Hipchat had several security issues and Atlassian changed their link system. Now my URL-Forwarding is not working anymore. I am adding the direct link.

The channel can also be reached manually. The channels name is blacklabelops/support in Hipchat.

Docker Hub not updating

Docker hub still only has JIRA 7.4.1, but this repo has been updated to 7.4.2

Explain the need of JIRA_DELAYED_START or better use wait-for-it

you need https://github.com/blacklabelops/jira/blob/master/docker-compose.yml#L20 to ensure DB is started before jira tries to access it but its not documented and will lead to random issues for people.

I would suggest you add it to the docs, or, i rather would suggest using wait-for-it https://github.com/vishnubob/wait-for-it

COPY ./bin/wait-for-it.sh /usr/local/bin/wait-for-it

on the top of the docker-entrypoint.sh

wait-for-it -t 60 -h db -p 5432

and thats it for the guard. Bootstrap starts when the DB is available

Automatically pull Jira version info?

Does it make sense to automatically build from the latest version info from the Atlassian website?

These feeds could be used:

• https://my.atlassian.com/download/feeds/current/jira-core.json
• https://my.atlassian.com/download/feeds/current/jira-software.json
• https://my.atlassian.com/download/feeds/current/jira-servicedesk.json

Any plans to mount / modify cacerts

Due to the current nature of lets-encrypt certificates with java ( included starting from 1.8u57 or something) creating applications links between jira/bamboo/confluence/bitbucketserver does not work unless the LE root / chain is imported into the java cacerts..

which is not located in the data folder, but rather in the codebase.

Do you plan to work on this kind of thing - any ideas how we could tackle this?

Proposal: To have more than one db on the same container

It would be great to configure more than one db on the same container and it could be used on docker compose file like this:

docker run --name postgres -d
-e 'POSTGRES_USER=jira'
-e 'POSTGRES_PASSWORD=jellyfish'
-e 'POSTGRES_DB1=jiradb'
-e 'POSTGRES_ENCODING1=UNICODE'
-e 'POSTGRES_COLLATE1=C'
-e 'POSTGRES_COLLATE_TYPE1=C'
-e 'POSTGRES_DB2=confluencedb'
-e 'POSTGRES_ENCODING2=UNICODE'
-e 'POSTGRES_COLLATE2=C'
-e 'POSTGRES_COLLATE_TYPE2=C'
-e 'POSTGRES_DB3=bitbucketdb'
-e 'POSTGRES_ENCODING3=UNICODE'
-e 'POSTGRES_COLLATE3=C'
-e 'POSTGRES_COLLATE_TYPE3=C'
blacklabelops/postgres

This way we can have one single db server/container.

Add SQLServer support to common.sh

It would be nice if this would also support SQLserver. I've tested this by adding the following:

imagescripts\common.sh

    *:sqlserver)
      if [ -z "$(read_var $prefix PORT)" ]; then
        eval "${prefix}_PORT=1433"
      fi
      local host_port_name="$(read_var $prefix HOST):$(read_var $prefix PORT)/$(read_var $prefix NAME)"
      local jdbc_driver="net.sourceforge.jtds.jdbc.Driver"
      local jdbc_url="jdbc:jtds:sqlserver://$host_port_name"
      local hibernate_dialect="org.hibernate.dialect.SQLServerDialect"
      local database_type="mssql"
      ;;

imagescripts\launch.sh

if [ "$JIRA_DB_TYPE" == "mssql" ]; then
    SCHEMA='<schema-name>dbo</schema-name>'
fi

License

Please add a license for the contents of this repository

Error when build image

Hi There, first of all I would like to thanks for this amazing job.

I did some modifications in order to attend my needs and when I try to build I got error on log file and cannot run the container:

I ran the ./scripts/build.sh from root directory, should I use other command?

After download JIRA software:
Unpacking JRE ...
Starting Installer ...
Feb 24, 2017 12:48:51 PM java.util.prefs.FileSystemPreferences$1 run
INFO: Created user preferences directory.
Feb 24, 2017 12:48:51 PM java.util.prefs.FileSystemPreferences$2 run
INFO: Created system preferences directory in java.home.
The installation directory has been set to /opt/jira.
Extracting files ...
java.io.IOException: Cannot run program "/opt/jira/bin/setup_user.sh" (in directory "/opt/jira/."): error=2, No such file or directory
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
at java.lang.Runtime.exec(Runtime.java:620)
at com.install4j.runtime.installer.helper.launching.LaunchHelper.launchOtherwise(Unknown Source)
at com.install4j.runtime.installer.helper.launching.LaunchHelper.launchApplication(Unknown Source)
at com.install4j.runtime.beans.actions.misc.RunExecutableAction.execute(Unknown Source)
at com.install4j.runtime.beans.actions.SystemInstallOrUninstallAction.install(Unknown Source)
at com.install4j.runtime.installer.InstallerContextImpl.performActionInt(Unknown Source)
at com.install4j.runtime.installer.ContextImpl.performAction(Unknown Source)
at com.install4j.runtime.installer.controller.Controller.executeActions(Unknown Source)
at com.install4j.runtime.installer.controller.Controller.executeActions(Unknown Source)
at com.install4j.runtime.installer.controller.Controller.handleCommand(Unknown Source)
at com.install4j.runtime.installer.controller.Controller.start(Unknown Source)
at com.install4j.runtime.installer.Installer.main(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.exe4j.runtime.LauncherEngine.launch(Unknown Source)
at com.install4j.runtime.launcher.Launcher.main(Unknown Source)
Caused by: java.io.IOException: error=2, No such file or directory
at java.lang.UNIXProcess.forkAndExec(Native Method)
at java.lang.UNIXProcess.(UNIXProcess.java:247)
at java.lang.ProcessImpl.start(ProcessImpl.java:134)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
... 18 more
In action "set jira user account name [Run script]" (screen "Installation"), property "Script":
java.lang.NullPointerException
at I4jScript_Internal_385.eval(I4jScript_Internal_385.java:18)
at I4jScript_Internal_385.evaluate(I4jScript_Internal_385.java:27)
at com.install4j.runtime.installer.helper.Script.evaluate(Unknown Source)
at com.install4j.runtime.installer.ContextImpl.runScript(Unknown Source)
at com.install4j.runtime.installer.ContextImpl.runScript(Unknown Source)
at com.install4j.runtime.beans.actions.control.RunScriptAction.execute(Unknown Source)
at com.install4j.runtime.beans.actions.SystemInstallOrUninstallAction.install(Unknown Source)
at com.install4j.runtime.installer.InstallerContextImpl.performActionInt(Unknown Source)
at com.install4j.runtime.installer.ContextImpl.performAction(Unknown Source)
at com.install4j.runtime.installer.controller.Controller.executeActions(Unknown Source)
at com.install4j.runtime.installer.controller.Controller.executeActions(Unknown Source)
at com.install4j.runtime.installer.controller.Controller.handleCommand(Unknown Source)
at com.install4j.runtime.installer.controller.Controller.start(Unknown Source)
at com.install4j.runtime.installer.Installer.main(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.exe4j.runtime.LauncherEngine.launch(Unknown Source)
at com.install4j.runtime.launcher.Launcher.main(Unknown Source)
An error occurred:
com.install4j.api.beans.UndefinedVariableException: installer:jiraAccountName
Error log: /tmp/install4jError1372929459834865074.log
com.install4j.api.beans.UndefinedVariableException: installer:jiraAccountName
at com.install4j.runtime.installer.InstallerVariables$InstallerReplacementCallback.handleError(Unknown Source)
at com.install4j.runtime.installer.InstallerVariables$InstallerReplacementCallback.getReplacement(Unknown Source)
at com.install4j.runtime.util.StringUtil.replaceVariable(Unknown Source)
at com.install4j.runtime.installer.InstallerVariables.replaceVariables(Unknown Source)
at com.install4j.runtime.installer.InstallerVariables.replaceVariables(Unknown Source)
at com.install4j.runtime.installer.InstallerVariables.replaceVariables(Unknown Source)
at com.install4j.api.beans.AbstractBean.replaceVariables(Unknown Source)
at com.install4j.runtime.beans.actions.text.ModifyTextFileAction.getReplaceValue(Unknown Source)
at com.install4j.runtime.beans.actions.text.ModifyTextFileAction.modifyFile(Unknown Source)
at com.install4j.runtime.beans.actions.files.AbstractModifyFileAction.executeForSingleFile(Unknown Source)
at com.install4j.runtime.beans.actions.files.AbstractModifyFileAction.executeForMultipleFiles(Unknown Source)
at com.install4j.runtime.beans.actions.files.AbstractModifyMultipleFilesAction.execute(Unknown Source)
at com.install4j.runtime.beans.actions.SystemInstallOrUninstallAction.install(Unknown Source)
at com.install4j.runtime.installer.InstallerContextImpl.performActionInt(Unknown Source)
at com.install4j.runtime.installer.ContextImpl.performAction(Unknown Source)
at com.install4j.runtime.installer.controller.Controller.executeActions(Unknown Source)
at com.install4j.runtime.installer.controller.Controller.executeActions(Unknown Source)
at com.install4j.runtime.installer.controller.Controller.handleCommand(Unknown Source)
at com.install4j.runtime.installer.controller.Controller.start(Unknown Source)
at com.install4j.runtime.installer.Installer.main(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.exe4j.runtime.LauncherEngine.launch(Unknown Source)
at com.install4j.runtime.launcher.Launcher.main(Unknown Source)
java.io.IOException: Cannot run program "/opt/jira/bin/setup_user.sh" (in directory "/opt/jira/."): error=2, No such file or directory
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
at java.lang.Runtime.exec(Runtime.java:620)
at com.install4j.runtime.installer.helper.launching.LaunchHelper.launchOtherwise(Unknown Source)
at com.install4j.runtime.installer.helper.launching.LaunchHelper.launchApplication(Unknown Source)
at com.install4j.runtime.beans.actions.misc.RunExecutableAction.execute(Unknown Source)
at com.install4j.runtime.beans.actions.SystemInstallOrUninstallAction.install(Unknown Source)
at com.install4j.runtime.installer.InstallerContextImpl.performActionInt(Unknown Source)
at com.install4j.runtime.installer.ContextImpl.performAction(Unknown Source)
at com.install4j.runtime.installer.controller.Controller.executeActions(Unknown Source)
at com.install4j.runtime.installer.controller.Controller.executeActions(Unknown Source)
at com.install4j.runtime.installer.controller.Controller.handleCommand(Unknown Source)
at com.install4j.runtime.installer.controller.Controller.start(Unknown Source)
at com.install4j.runtime.installer.Installer.main(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.exe4j.runtime.LauncherEngine.launch(Unknown Source)
at com.install4j.runtime.launcher.Launcher.main(Unknown Source)
Caused by: java.io.IOException: error=2, No such file or directory
at java.lang.UNIXProcess.forkAndExec(Native Method)
at java.lang.UNIXProcess.(UNIXProcess.java:247)
at java.lang.ProcessImpl.start(ProcessImpl.java:134)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
... 18 more
Launching JIRA Software ...
Feb 24, 2017 12:49:27 PM com.atlassian.modzdetector.HashRegistry store
INFO: wrote 987 hashes to /opt/jira/install.reg

When I try to run the image:
[FATAL tini (7)] Executing child process '/usr/local/share/atlassian/docker-entrypoint.sh' failed: 'No such file or directory'

My my change was in the file docker-entrypoint.sh
I add this:
if [ -n "${JIRA_JSESSIONID_NAME}" ]; then
xmlstarlet ed -P -S -L --insert "//Context/[not(@sessionCookieName)]" --type attr -n sessionCookieName --value "${JIRA_JSESSIONID_NAME}" ${JIRA_INSTALL}/conf/server.xml
fi

Because when I run JIRA and Confluence in the same machine I got problems related with JSESSIONID and drop user from each application.

Thanks in advance.

Build System Development Branch

Description

You can now pull the latest development version!

Development branch builds will be released into Dockerhub. The images have the contents of the latest builds and will be tagged accordingly:

• Development version with Jira Software inside: blacklabelops/jira:development-software
• Development version with Jira Core inside: blacklabelops/jira:development-core
• Development version with Jira Service-Desk inside: blacklabelops/jira:development-servicedesk

Versions

Starting from Jira 7.8.0

Loaded with failures over JIRA running behind HAProxy

As in reference to #10, I'm still having loads of failures on JIRA that is running behind HAProxy that sets SSL cert. Sometimes pages just go Safari can't open the page because the server where page is located is not responding.

docker-compose.yml:

version: '2'
services:
  web:
    image: 'blacklabelops/jira:7.5.0'
    hostname: 'jira.mydomain.com'
    restart: always
    ports:
      - '8080:8080'
    links:
      - db
    volumes:
      - ./jira:/var/atlassian/jira
    environment:
      JIRA_DATABASE_URL: 'mysql://jira@db/jira'
      JIRA_DB_PASSWORD: 'mypass'
      JIRA_PROXY_NAME: 'jira.mydomain.com'
      JIRA_PROXY_PORT: '443'
      JIRA_PROXY_SCHEME: 'https'
      DOCKER_WAIT_HOST: 'db'
      DOCKER_WAIT_PORT: '3306'
    logging:
      driver: json-file
      options:
        max-size: 10m
  db:
    image: mariadb:10.1
    environment:
      MYSQL_DATABASE: 'jira'
      MYSQL_USER: 'jira'
      MYSQL_PASSWORD: 'mypass'
      MYSQL_ROOT_PASSWORD: 'myrootpass'
    volumes:
      - ./data:/var/lib/mysql
    logging:
      driver: json-file
      options:
        max-size: 10m
    restart: always
    command: mysqld --character-set-server=utf8 --collation-server=utf8_bin

haproxy.cfg:

frontend https-in                   
  bind *:443 ssl crt /etc/haproxy/certs/
  reqadd X-Forwarded-Proto:\ https  
  mode http                         

  acl jira_control hdr(host) -i jira.mydomain.com
  use_backend jira_backend if jira_control 

backend jira_backend
  redirect scheme https if !{ ssl_fc }
  balance leastconn                 
  option httpclose
  option forwardfor
  server jira 127.0.0.1:8080