Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In the original design of this module, we assumed that each ECS task had its own listener certificate and that these resources could be applied and destroy along with the ECS task. This works in most case, but was broken by the special case wherein >1 ECS task shares a listener certificate because both tasks listen on the same host_header but are differentiated by different path_pattern values (and different priorities).
This assumption broke for services like authman which meet these conditions by sharing a host_header. The original design allowed for creating a listener certificate independently (outside the apps directory), but naively assumed that separate listener certificates could be managed in the individual apps subdirectories.
The result is that running the Terraform in any of the apps subdirectories would apply or destroy the listener certificate regardless of whether other ECS tasks were using it.
In order to fix this proble, we add a manage_listener_certificate variable. This changes the behavior when applying or destroying an ECS task.
This variable is only meaningful when a load_balancer object is defined for the ECS task, and when a public load balancer is used. Tasks using a private load balancer do not need SSL certificates because intra-VPC traffic is deemed secure. Tasks not using a load balancer (such as a daemon process) don't have a listener at all.
The following assumes that the Terraform for an ECS task specifies a load_balancer block:
If the manage_listener_certificate sub-object in the load_balancer
block is true (which is the default when a load_balancer block is
defined), the listener certificate is managed with the ECS task,
and will have the same lifecycle.
If the manage_listener_certificate sub-object in the load_balancer
block is false, the module assumes that a listener certificate is
managed independently, in a separate configuration directory,
using the terraform-aws-lb-listener-certificate module.
In the latter case, the listener certificate in this case is not managed with the container, and persists beyond the lifetime of any of the individual ECS tasks that use the listener_certificate.
The intent of setting manage_listener_certificate to false is for use cases where multiple tasks share a host_header, and use path_pattern and priority sub-objects in the load_balancer block to distinguish the task to which traffic should be routed.