The Jira project is a sub-project of the overarching DevOps Tool-Chain (DOTC) project. This project — and its peer projects — is designed to handle the automated deployment of common DevOps tool-chain services onto STIG-harderend, EL7-compatible Amazon EC2 instances and related AWS resources. The first part of this automation is comprised of CloudFormation (CFn) templates. Included in this project are the following templated activities:
Additionally, automation-scripts are provided to automate the deployment of the Jira Server software onto the relevant EC2 instances - whether stand-alone or managed via AWS's AutoScaling service.
The above may be usable to &mdash or, more likely, act as a starting-point for &mdash - automate the deployment of Jira DataCenter. No associated testing was done: if you borrow these templates to underpin additional capabilities, please contribute back the fruits of that effort (or notify us so we can link to your project).
These templates are intended for use within AWS VPCs. It is further expected that the deployed-to VPCs will be configured with public and private subnets. All Jira elements other than the Elastic LoadBalancer(s) are expected to be deployed into private subnets. The Elastic LoadBalancers provide transit of Internet-originating web UI requests to the the Jira node's web-based interface.
It is generally expected that the use of the various, individual-service templates will be run via the "parent" template(s). The "parent" template allows for a kind of "one-button" deployment method where all the user needs to worry about is populating the template's fields and ensuring that CFn can find the child templates.
In order to use the "parent" template, it is recommended that the child templates be hosted in an S3 bucket separate from the one created for backups by this stack-set. The template-hosting bucket may be public or not. The files may be set to public or not. CFn typically has sufficient privileges to read the templates from a bucket without requiring the containing bucket or files being set public. Use of S3 for hosting eliminates the need to find other hosting-locations or sort out access-particulars of those hosting locations.
The EC2-related templates — either autoscale or instance — currently require that the scripts be anonymously curl
able. The scripts can still be hosted in a non-public S3 bucket, but the scripts' file-ACLs will need to allow public-read
. This may change in future releases — likely via an enhancement to the IAM template.
These templates do not include Route53 functionality. It is assumed that the requisite Route53 or other DNS alias will be configured separate from the instantiation of the public-facing ELB.
The capability to automate the installation of Jira plugins is provided through a supporting script. The plugins-script takes arrays containing URLs to the plugin binaries and downloads the files into the appropriate Jira plugins-folder. To pre-install Jira plugins, edit the plugin-script by adding plugin URLs into the appropriate plugins-array variable. Update the plugin parameter in the Cfn templates with the URL where the plugins-script file is hosted. The plugin script will be executed as part of the Jira Cfn deployment.
--acl=public-read
https://<USERNAME>:<PASSWORD>@<FQDN>/PATH/TO/FILE
https://<S3-BUCKET-HOSTNAME>/PATH/TO/FILE?<SIGNATURE>
The templates and scripts act together to make standing up a new service is quick and (reasonably) easy. Application-level configuration - beyond JDBC configuration - are not handled by these templates and scripts.
These templates and scripts are also designed to ensure that Jira data is persisted and backed up. This ensures that the Jira service can be quickly and easily reconstituted as necessary.