Java App Server AWS OpsWorks Stacks Layer
Important
The AWS OpsWorks Stacks service reached end of life on May 26, 2024 and has been disabled for both new and existing customers.
We strongly recommend customers migrate their workloads to other solutions as soon as possible. If you have questions about migration, reach out to the AWS Support Team on AWS re:Post
Note
This layer is available only for Linux-based stacks.
The Java App Server layer is an AWS OpsWorks Stacks layer that provides a blueprint for instances that
function as Java application servers. This layer is based on Apache Tomcat 7.0DataSource object
to connect to a back end data store.
Installation: Tomcat is installed in
/usr/share/tomcat7.
The Add Layer page provides the following configuration options:
- Java VM Options
-
You can use this setting to specify custom Java VM options; there are no default options. For example, a common set of options is
-Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC. If you use Java VM Options, make sure that you pass a valid set of options; AWS OpsWorks Stacks does not validate the string. If you attempt to pass an invalid option, the Tomcat server typically fails to start, which causes setup to fail. If that happens, you can examine the instance's setup Chef log for details. For more information on how to view and interpret Chef logs, see Chef Logs. - Custom security groups
-
This setting appears if you chose to not automatically associate a built-in AWS OpsWorks Stacks security group with your layers. You must specify which security group to associate with the layer. For more information, see Create a New Stack.
- Elastic Load Balancer
-
You can attach an Elastic Load Balancing load balancer to the layer's instances. For more information, see Elastic Load Balancing Layer.
You can specify other configuration settings by using custom JSON or a custom attributes file. For more information, see Custom Configuration.
Important
If your Java application uses SSL, we recommend that you disable SSLv3 if possible
to address the vulnerabilities described in CVE-2014-3566
Disabling SSLv3 for Apache Servers
To disable SSLv3, you must modify the Apache server's
ssl.conf file's SSLProtocol setting. To do so,
you must override the built-in apache2 cookbook'sssl.conf.erb template file, which the Java App Server layer's Setup
recipes use to create ssl.conf. The details depend on which
operating system you specify for the layer's instances. The following summarizes the
required modifications for Amazon Linux and Ubuntu systems. SSLv3 is automatically
disabled for Red Hat Enterprise Linux (RHEL) systems. For more information on how to
override a built-in template, see Using Custom Templates.
- Amazon Linux
-
The
ssl.conf.erbfile for these operating systems is in theapache2cookbook'sapache2/templates/default/modsdirectory. The following shows the relevant part of the built-in file.... #SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL # enable only secure protocols: SSLv3 and TLSv1.2, but not SSLv2 SSLProtocol all -SSLv2 </IfModule>Override
ssl.conf.erband modify theSSLProtocolsetting as follows.... #SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL # enable only secure protocols: SSLv3 and TLSv1.2, but not SSLv2 SSLProtocol all -SSLv3 -SSLv2 </IfModule> - Ubuntu 14.04 LTS
-
The
ssl.conf.erbfile for this operating system is in theapache2cookbook'sapache2/templates/ubuntu-14.04/modsdirectory. The following shows the relevant part of the built-in file.... # The protocols to enable. # Available values: all, SSLv3, TLSv1.2 # SSL v2 is no longer supported SSLProtocol all ...Change this setting to the following.
... # The protocols to enable. # Available values: all, SSLv3, TLSv1.2 # SSL v2 is no longer supported SSLProtocol all -SSLv3 -SSLv2 ...
