plus3it / cfn-jira Goto Github PK

Problem Description:

Amazon Certificate Manager (ACM) is not available for use in all regions/partitions. In these regions/partitions, it will be necessary to use Identity and Access Management (IAM) to host SSL certificates used for ELB-based SSL-termination. To maximize portability, ELB templates should allow use of either ACM- or IAM-hosted SSL certificates.

Expected Behavior:

ELBs support SSL-termination whether ACM is available for use in a given region/partition.

Actual Behavior:

ELBs do not currently support SSL-termination when ACM is unavailable for use in a given region/partition.

Affected Components

The following templates need remediation:

• make_jira-dc_ELBv1-pub.tmplt.json
• make_jira-dc_ELBv2-pub.tmplt.json
• make_jira-dc_parent-EFS-ELBv1.tmplt.json
• make_jira-dc_parent-EFS-ELBv2-autoscale.tmplt.json
• make_jira-dc_parent-EFS-ELBv2-instance.tmplt.json

Fix recommendation:

Add a Condition{} and Parameters{} components and associated logic within the Resources{} sections to support selection of ACM- or IAM-hosted SSL certificates when launching an ELB template.

Problem Description:

With EL 7.6's rebasing of cloud-init, the current cloud-init-per declaration in UserData results in the secondary EBS being mkfsed each time the instance boots.

Expected Behavior:

Secondary EBS is only mkfsed during initial boot

Actual Behavior:

Secondary EBS being mkfsed each time the instance boots.

Fix recommendation:

Update UserData. Change:

"  - cloud-init-per instance mkfs-appvolume mkfs -t ext4 ",

To:

"  - cloud-init-per instance appvolume mkfs -t ext4 ",

Problem Description:

Templates may not be sufficiently portable if ARNs hardcode the :aws: partition-element into them (won't work in specialty-regions like aws-cn). See AWS::Partition pseudo-param documentation.

Expected Behavior:

All templates should work in all AWS partitions

Actual Behavior:

The make_jira-dc_ELBv1-pub.tmplt.json template will fail if not launched into the default/commercial AWS region

Fix recommendation:

Update enumerated template-files to update all "arn:aws:... string-literals to something more like:

            {
              "Fn::Join": [
                ":",
                [
                  "arn",
                  { "Ref": "AWS::Partition"},
                  …,
                  …
                ]
              ]
            }

Since initial authoring, AWS has updated available PGSQL versions. Per today's (2018-12-10) notifications, AWS is recommending updating running versions to at least 9.6.9.

AWS's currently-supported versions are (application support may vary: test if moving to a higher major):

10.4
10.3
10.1
9.6.10
9.6.9
9.6.8
9.6.6
9.6.5
9.6.3
9.6.2
9.6.1
9.5.14
9.5.13
9.5.12
9.5.10
9.5.9
9.5.7
9.5.6
9.5.4
9.5.2

Problem Description:

It may be desirable to offer the ability to customize database tuning-options. Need the DB to use a custom — rather than the currently used RDS-default — parameter group.

Expected Behavior:

Ability to tune DB behavior via DB parameter-group settings

Actual Behavior:

Current use of RDS-default DB parameter-group precludes tuning customizations

(Detailed) Steps to reproduce:

Deploy RDS DB from existing templates

(Optional) Fix recommendation:

Add a AWS::RDS::DBParameterGroup resource-type into the current RDS templating.

Make sure they aren't too aggressive — particularly the EC2s'/ASGs' and RDSes'

Problem Description:

Currently installed backup logic in /etc/cron.d/jira-data-backup is sub-optimal from a performance perspecctive

Expected Behavior:

Maximize S3 performance to be more equivalent to those outlined in AWS documentation

Actual Behavior:

Backup/restore slower than could be. Mostly not a problem, now, but will become a problem as backed-up dataset grows in size (particularly number of elements backed up)

Fix recommendation:

Change current backup method from an s3 sync of the Jira content to a tar cf - <JIRA_CONTENT> | s3 cp - s3://<BUCKET>/<KEY>/<TAR_FILE> method

Problem Description:

AWS has released new instance types that might better align to some deployment-scopes

Expected Behavior:

Support t3 and m5 instance-types where possible

Actual Behavior:

Does not currently support t3 and m5 instance-types at all

(Optional) Fix recommendation:

Update template logic to allow for t3 and m5 instance-types

Currently, CWA logging is not enabled in the EC2 template(s). When rebasing against the watchmaker 1.5.6 templates, generic CWA logging should be enabled. Need to also ensure the template-installed logging definitions also include the Jira application logs. Probably best to work this issue in coordination with issue #6 .

Problem Description:

Templates last based prior to usage of CloudWatch Agent. Update to include optional CloudWatch logic

Expected Behavior:

Template installs CloudWatch agent in regions that support it.

Actual Behavior:

No hooks for CloudWatch Agent present

(Optional) Fix recommendation:

Re-baseline EC2 templates against latest watchmaker templates