xalt/jira
Simply run Docker with:
docker run -d -p 8080:8080 xalt/jira
If you are using OSX you first need to find out your boot2docker IP before you can access your application:
boot2docker ip
Now open http://[Docker Host IP]:8080 in your browser.
On a live environment, we are using nginx from jwilder:
https://hub.docker.com/r/jwilder/nginx-proxy/
So to run the application at your own url just run the jwilder/nginx-proxy and use the following command:
docker run -d -VIRTUAL_HOST=subdomain.domain.tld -VIRTUAL_PORT=8080 xalt/jira
If you need a persistant file system and postgres database, please use:
docker run --name mypgdb -p 5432:5432 -e POSTGRES_USER=testpg -e POSTGRES_PASSWORD=testpg -e POSTGRES_DB=pgdb -d xalt/postgres
docker run --name myjira -v /data/confluence:/var/atlassian/atlassian-jira --link mypgdb:pgdb -d -e RAM_MIN=2048 -e RAM_MAX=4096 -e VIRTUAL_HOST=subdomain.yourdomain.tld -p 8080:8080 xalt/jira
If you want to connect to the server using remote debugging in your environment:
docker run -p 8080:8080 -p 5005:5005 -e JIRA_REMOTE_DEBUG=true -d -e RAM_MIN=2048 -e RAM_MAX=4096 xalt/jira
The variables in this section are shell environment variables set directly from the shell or in the "environment" entries for the relevant docker-compose.yml file.
On startup the backup server checks the variable TIMEZONE which is false by default (see the Dockerfile). If the TIME_ZONE variable is set, it attempts to update the /etc/localtime on the container.
TIMEZONE=Europe/Berlin
To restore a Jira installation from a backup on startup, the relevant 'BACKUP' variables need to be set as in the following example:
BACKUP_HOST=192.168.123.123
BACKUP_USER=root
BACKUP_PATH=/backup/jira1
BACKUP_KEY_FILE=/tmp/id_rsa
showing the host to restore the backup from, the user to connect with, the path to restore from and the ssh key to use for the connection.
Setting the java option "jira.node.id" to anything other than "false" tells jira that we are using a clustered setup. If this is the case "jira.shared.home" will be set to the directory JIRA_HOME_SHARED and this will used as jira's home directory instead of the normal location of JIRA_HOME. e.g
JAVA_OPTS=-Djira.node.id=node-1
Adding a file called DONTSYNC at the top level of the JIRA_HOME or JIRA_HOME_SHARED tells the container never to restore a backup to this directory. If DONTSYNC is not present and the user sets the relevant 'BACKUP' variables before startup, a backup is sought on the named server which is restored to the home directory defined in JIRA_HOME or JIRA_HOME_SHARED. For example, if I have:
JIRA_HOME=/opt/docker/information-server/jira
then adding the DONTSYNC file in this dir will prevent any restore from happening. After a restore, a DONTSYNC file is added automatically.
If you wish to install additional certificates from an as yet unspecified directory, you can set the IMPORTCERT environment variable to "true" and the IMPORTPATH variable to the location of the certificates. The "keytool" will be run and will import the certificates in the specified directory on startup.
IMPORTCERT=true
IMPORTPATH=/var/certificates
If the RAM_MIN and/or RAM_MAX environment variables are set (in Megabytes), these are carried into the CATALINA_OPTS settings for tomcat. Remote debugging for tomcat can also be set up by setting the JIRA_REMOTE_DEBUG environment variable to "true" and then setting the DEBUG_PORT variable.
RAM_MIN=2048
RAM_MAX=8192
In JIRA_HOME or JIRA_HOME_SHARED an "exclude_from_backup" file can be added with directory entries in that will not be included in the backups run by this backup server.
The following variables can be set to alter settings in jira's Catalina options on startup.
PROXY_NAME="test2.domain.com"
If the HTTPS variable is set to "true", proxyPort is set to 443 and "scheme" is set to "https" in the server.xml.
HTTPS=true
If DB_POOL_SIZE is set, hibernate.cp30.max_size is set to that value in dbconfig.xml file controlling the maximum number of DB connections.
DB_POOL_SIZE=30
Jira plugins can be downloaded and installed in startup if the INSTALL_PLUGINS environment variable is set. One then needs to configure either or both of the INSTALL_PLUGINS_URLS_V1 and INSTALL_PLUGINS_URLS_V2 variables.
An example to run it in a Docker compose file:
#!shell
jira:
image: xalt/jira
volumes:
- /data/[your directory]:/var/atlassian/jira
links:
- mysql:db
environment:
- TIME_ZONE=Europe/Berlin
- VIRTUAL_HOST=[your url if you run with nginx]
- VIRTUAL_PORT=8080
- RAM_MIN=2048m
- RAM_MAX=8048m
- HTTPS=true
- PROXY_NAME=[your url if you run with nginx will be added to server.xml]
- NEWRELIC_LICENSE=xxxxxxxxxxxxxxxxxxxxxxxx
- NEWRELIC_APP_NAME=[your name if you want to use newrelic! if not remove the 3 newrelic lines]
- NEWRELIC=true
restart: always
mysql:
image: mysql:5.6
volumes:
- /data/mysql/conf:/etc/mysql/conf.d
- /data/mysqljira:/var/lib/mysql
environment:
- MYSQL_ROOT_PASSWORD=[your very long passwort you need in case you need root to the db]
- MYSQL_DATABASE=jira
- MYSQL_USER=jira
- MYSQL_PASSWORD=[your very long password]
restart: always
Mount the local custom_templates directory in the repo to /var/atlassian/jira/custom_templates (as shown below)
Copy the file you wish to edit from the container (e.g. docker cp)
Edit the file and save it to the “custom_templates” directory.
In the docker-compose.yml set “CUSTOM_TEMPLATES_ENABLED=true”.
In the docker-compose.yml set “CUSTOM_TEMPLATES_FILES” to a pipe separated list of the edited files you wish to replace in the jira file structure.
e.g.
#!shell
volumes:
- ./custom_templates:/var/atlassian/jira/custom_templates
environment:
- CUSTOM_TEMPLATES_ENABLED=true
- "CUSTOM_TEMPLATES_FILES=/opt/atlassian/jira/atlassian-jira/WEB-INF/classes/templates/plugins/footer/footer.vm|\
/opt/atlassian/jira/atlassian-jira/template/standard/text.vm|\
/opt/atlassian/jira/atlassian-jira/template/standard/checkbox.vm"
Note that the files needs to have the full path as it is in the jira file hierarchy so the entry will get long with only a few files. A multi-line entry needs the backslashes and quotes as shown.
The corresponding “custom_templates” directory listing with the edited files within would look like this:
-rwxrwxr-x 1 user user 1851 Jan 31 12:14 footer.vm
-rw-rw-r-- 1 user user 50 Jan 31 17:13 .gitignore
-rwxrwxr-x 1 user user 9709 Jan 31 12:13 text.vm
-rwxrwxr-x 1 user user 138 Jan 31 12:13 checkbox.vm
During a restart of the docker container the current files in the jira file structure are copied to the “custom_templates” directory with a .bak extension along with the date and time. The edited versions of the file are then copied over to the container just before Confluence is started.
With each restart the edited file is compared with the version in the container file structure and backed up and exchanged if they differ.
To use Liquibase to make changes to the database independently of Jira set the environment variable LIQUIBASE to true. Setting the variable LIQUIBASE_RESET to true will clear checksums for Liquibase forcing a re-run of all changesets.
To set the Base URL for Jira simply set LIQUIBASE_BASEURL.
The URL of an application link can be updated by setting an environment variable starting with LIQUIBASE_APPLICATION_LINK_ completing the name of the variable with the ID in use for the link, for example LIQUIBASE_APPLICATION_LINK_CONFLUENCE. The actual value of the variable should include 2 urls indicating the old and new URLs. e.g. LIQUIBASE_APPLICATION_LINK_JIRA=http://confluence.local.me=http://confluence.cloud.org
The Crowd URL for Confluence can be updated by setting the LIQUIBASE_CROWD_OLD variable. If this is set the application name, application password and the new URL can be set with these variables:
LIQUIBASE_CROWD_NEW_APP_NAME
LIQUIBASE_CROWD_NEW_APP_PASS
LIQUIBASE_CROWD_NEW_URL
LIQUIBASE_CROWD_OLD
Setting the environment variable LIQUIBASE_BANNER_CONFIG to true causes a banner to be set for Jira. Use the following variables to actually create the banner:
LIQUIBASE_BANNER_TYPE
LIQUIBASE_BANNER_TITLE
LIQUIBASE_BANNER_TEXT
To remove any Email Server configuration from jira, in the case of a production restore for example, set LIQUIBASE_REMOVE_MAILSERVER to true.
Setting LIQUIBASE_MINIORANGE_CONFIG to true runs a Liquibase changeset updating miniorange settings where applicable. The connection details for Liquibase can be set with the following variables:
LIQUIBASE_DB_URL
LIQUIBASE_USERNAME
LIQUIBASE_PASSWORD
LIQUIBASE_DRIVER
but these are set by default using the entries in dbconfig.xml.
LIQUIBASE_MINIORANGE_CUSTOM_APP_NAME should be set to the name of the identity provider so the config can be easily distinguished from others. The ClientID and Secret are used to connect to the provider and can be set using LIQUIBASE_MINIORANGE_CLIENT_ID and LIQUIBASE_MINIORANGE_CLIENT_SECRET. The scope defines what access will be granted and can be set with LIQUIBASE_MINIORANGE_SCOPE. The relevant endpoints must also be configured and this can be done with the following environment variables:
LIQUIBASE_MINIORANGE_ACCESSTOKEN_END_POINT
LIQUIBASE_MINIORANGE_AUTHORIZE_END_POINT
LIQUIBASE_MINIORANGE_SINGLE_LOGOUT_URL
to set the access, token and logout endpoints respectively. The default groups that will be applied to an authenticated user can be set with LIQUIBASE_MINIORANGE_DEFAULT_GROUP if there is only one group or LIQUIBASE_MINIORANGE_DEFAULT_GROUPS if there are several. The configuration can be enabled and disabled by setting LIQUIBASE_MINIORANGE_ENABLE_OAUTH_SSO to true or false.
If you are searching for other Atlassian tools, feel free to checkout our other repositories at https://hub.docker.com/u/xalt/ and https://bitbucket.org/xalt/
If you want to help with our Docker effort, please send us a pull request or just shoot over an email with your Bitbucket account to get rights on this repository.
If you need help using this images or integrating them into your infrastructure / CI process etc., feel free to contact me at philipp.goellner@xaltbc.de
docker pull xalt/jira