What is the current behavior?

Tasks cannot start due to this error:

ResourceInitializationError: unable to pull secrets or registry auth: execution resource retrieval failed: unable to retrieve secrets from ssm: service call has been retried 5 time(s): RequestCanceled: request context canceled caused by: context deadli...

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.

• I created a VPN, load balancer, and SSM secret
• I configured a minimal instance of this module including task_container_secrets
• I attached an existing working policy to the IAM roles to allow access SSM secrets

I discovered this stackoverflow post, which suggests the issue may be due to a change in network interface configuration as of Fargate 1.4.0.

I attemted to debug the issue based on information in that thread with no luck.

What is the expected behavior?

Fargate tasks able to access SSM secrets

Software versions?

Module version: 6.4.1

➜ terraform --version
Terraform v1.0.10
on linux_amd64
+ provider registry.terraform.io/hashicorp/aws v3.70.0

What is the current behavior?

Currently, this Terraform module only supports one single container to be added to the container_definitions
https://github.com/umotif-public/terraform-aws-ecs-fargate/blob/6.7.0/main.tf#L184

What is the expected behavior?

It would be useful being able to specify sidecars.

Some references:

• https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/ecs_task_definition.html#basic-example
• https://aws.amazon.com/blogs/compute/nginx-reverse-proxy-sidecar-container-on-amazon-ecs/

Is it possible with the current version of code to pass custom security group(s) for ECS Fargate service ? If not could you take this as a feature request.

What is the current behavior?
There is a way to set up volumes, but in container definition you can not setup mountpoints.

What is the expected behavior?
Please add mountPointsto container definition to be able to use EFS fe https://docs.aws.amazon.com/AmazonECS/latest/developerguide/efs-volumes.html#specify-efs-config

I want to use this module to deploy dev environments.

All these connect to a single database, would make things easy, if there's one database SG and one web server SG shared by all ECS services/

What is the current behavior?
The portMapping list of the task definition only lists 1 port as defined in task_container_port. Since target-group lists container_port, that value should be used to populate portMapping

Terraform fails when trying to map TG container port to a non-existent portMapping

 Error: failed creating ECS service (ecs-fargate-example): InvalidParameterException: The container ecs-fargate-example did not have a container port 5672 defined.
│ 
│   with module.fargate.aws_ecs_service.service,
│   on .terraform/modules/fargate/main.tf line 295, in resource "aws_ecs_service" "service":
│  295: resource "aws_ecs_service" "service" {

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.
Example code
https://gist.github.com/networkprogrammer/3c64d16d379098260309fea2e8aa7af4

What is the expected behavior?
Ideally, the container port should be picked from the tg's container port. That way AWS does not complain about port mapping not existing

Details
I have an nginx container listening on multiple ports. With task_container_port being used to populate port-mapping, I have to run multiple instances of the same container with task_container_port set to different ports, although they do the same thing.

Software versions?
Terraform v1.1.6
on linux_amd64

• provider registry.terraform.io/hashicorp/aws v4.5.0
• provider registry.terraform.io/hashicorp/random v3.1.1

umotif-public/ecs-fargate/aws: 6.4.2
umotif-public/alb/aws: 2.X

My Terraform Template:

# Configure the AWS Provider
provider "aws" {
  region = "us-east-2"
}

variable "subnets" {
  type    = list(string)
  default = ["subnet-00xxxxxxxxx", "subnet-0xxxxxxxxxx"]
}

variable "sg" {
  type    = string
  default = "sg-0xxxxxxxxxxxxx"
}

resource "aws_ecs_cluster" "cluster" {
  name = "example-ecs-cluster"

  capacity_providers = ["FARGATE_SPOT", "FARGATE"]

  default_capacity_provider_strategy {
    capacity_provider = "FARGATE_SPOT"
  }

  setting {
    name  = "containerInsights"
    value = "disabled"
  }
}


module "ecs-fargate" {
  source = "umotif-public/ecs-fargate/aws"
  version = "6.2.0"

  name_prefix        = "ecs-fargate-example"
  vpc_id             = "vpc-0exxxxxxxxx"
  private_subnet_ids = var.subnets

  cluster_id         = aws_ecs_cluster.cluster.id

  task_container_image   = "marcincuber/2048-game:latest"
  task_definition_cpu    = 256
  task_definition_memory = 512

  task_container_port             = 80
  task_container_assign_public_ip = true

  target_groups = [
    {
      target_group_name = "tg-fargate-example"
      container_port    = 80
    }
  ]

  health_check = {
    port = "traffic-port"
    path = "/"
  }

  tags = {
    Environment = "test"
    Project = "Test"
  }
}

The Error I get after terraform apply.

Error: error creating ecs-fargate-example service: InvalidParameterException: The target group with targetGroupArn arn:aws:elasticloadbalancing:us-east-2:213128371923:targetgroup/tg-fargate-example/bxxxxxxxxdb does not have an associated load balancer.

  on .terraform/modules/ecs-fargate/main.tf line 284, in resource "aws_ecs_service" "service":
 284: resource "aws_ecs_service" "service" {

Tried on Terraform 0.14 and 1.0.1.

This is a bug tracker, not a support system. For usage questions, please use Stack Overflow where there are a lot more people ready to help you out.
I have followed through the example in the https://github.com/umotif-public/terraform-aws-ecs-fargate and updated the VPCid, subnets and getting the following error regarding the ALB. Does this module depend on ALB? any suggestions how to fix this error. thx
Error: error creating ECS service (ecs-fargate-example): InvalidParameterException: The target group with targetGroupArn arn:aws:elasticloadbalancing:us-east-1:227073609655:targetgroup/tg-fargate-example/164c8cb0a9a46e4d does not have an associated load balancer.
│
│ with module.ecs-fargate.aws_ecs_service.service,
│ on .terraform\modules\ecs-fargate\main.tf line 279, in resource "aws_ecs_service" "service":
│ 279: resource "aws_ecs_service" "service" {

What is the current behavior?
I followed the instructions in the release notes for v6.0.0 to upgrade from 5.1.0 → 6.2.0 and ran into an issue. See below:

│ Error: Invalid index
│
│   on .terraform/modules/fargate/fargate/main.tf line 156, in resource "aws_lb_listener" "alb_listener":
│  156:     target_group_arn = module.fargate.target_group_arn[0]
│     ├────────────────
│     │ module.fargate.target_group_arn is empty tuple
│
│ The given key does not identify an element in this collection value.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.

• Removed lb_arn
• Updated target_group_arn = module.fargate.target_group_arn[0]

Terraform reported this as if it was a static failure, so I wasn't really able to debug it much further.

What is the expected behavior?
Expected following the upgrade guide would succeed.

Software versions?

$ terraform -v
Terraform v0.15.5
on darwin_arm64

What is the current behavior?
When terraform tries to plan/apply, it errors out saying for_each needs to know the number of instances needed. See error below

Error: Invalid for_each argument
│ 
│   on .terraform/modules/fargate.fargate5672/main.tf line 96, in resource "aws_lb_target_group" "task":
│   96:   for_each = var.load_balanced ? { for tg in var.target_groups : tg.target_group_name => tg } : {}
│     ├────────────────
│     │ var.load_balanced is true
│     │ var.target_groups is tuple with 1 element
│ 
│ The "for_each" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many instances will be created. To work around this, use the -target argument to
│ first apply only the resources that the for_each depends on.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.
This module will work

module "fargate80" {
  source  = "umotif-public/ecs-fargate/aws"
  version = "6.4.2"
  name_prefix = "${var.name}-80"
  desired_count = 2
  # sg_name_prefix     = "my-security-group-name" # uncomment if you want to name security group with specific name

  vpc_id             = var.vpc_id
  private_subnet_ids = var.private_subnet_ids
  cluster_id         = aws_ecs_cluster.cluster.id
#   task_container_assign_public_ip = true

  target_groups = [
    {
      target_group_name = "mgmt"
      container_port    = 80
      protocol = "TCP"
    }
  ]
  task_container_protocol = "TCP"
  wait_for_steady_state = true

  task_container_image   = "nginx:latest"
  task_definition_cpu    = 256
  task_definition_memory = 512

  task_container_port             = 80
  health_check = {
    port = 80
    path = "/"
  }

  task_stop_timeout = 90
  depends_on = [
    module.nlb
  ]
}

This does not

module "fargate5672" {
  source  = "umotif-public/ecs-fargate/aws"
  version = "6.4.2"
  name_prefix = "${var.name}-5672"
  desired_count = var.desired_count
  # sg_name_prefix     = "my-security-group-name" # uncomment if you want to name security group with specific name

  vpc_id             = var.vpc_id
  private_subnet_ids = var.private_subnet_ids
  cluster_id         = aws_ecs_cluster.cluster.id
#   task_container_assign_public_ip = true

  target_groups = [
    {
      target_group_name = var.rabbit_tg_name
      container_port    = 5672
      protocol = "TCP"
    }
  ]
  task_container_protocol = "TCP"
  wait_for_steady_state = true

  task_container_image   = "nginx:latest"
  task_definition_cpu    = 256
  task_definition_memory = 512

  task_container_port             = 5672
  health_check = {
    protocol = "TCP"
  }

  task_stop_timeout = 90

  depends_on = [
    module.nlb
  ]
}

What is the expected behavior?

When using a variable for target_group_name the module should be able to use the interpolated name or not re-tag Name in the tags here -

I can then try using the Name tag as part of the name to change the Name of the tg. Today, I call the module from another module of mine.
Deploying multiple instances would create target-groups with the same name causing errors.

Software versions?

6.4.2

the module only allow to use target group that the module creates.
how can I add a pre-defined target group that I already created with terraform?

thanks!

What is the current behavior?
There's no variable for declaring secrets in the task definition

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.
I guess this is more of a feature request?

What is the expected behavior?
A secrets variable is available that replicates functionality in the task definition parameter as provided by https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html

Software versions?
Latest versions of terraform and umotif-public/terraform-aws-ecs-fargate

Is it possible to add the field "success codes" in the health check map? It can be found under advanced settings in the AWS console:

What is the current behavior?
When you add multiple target groups to the module, it also adds these target groups to the load_balancer block in aws_ecs_server under the dynamic "load_balancer" section. When you want to do a blue/green deployments via CodeDeploy, only one target group should be assigned to the ecs service at any given time. CodeDeploy is swapping these target groups out during the deployment.

What happens now is that the ecs service has multiple target groups assigned, each task's private IP address is added to each target group. When the codedeploy deployment happens, it gets stuck during the install phase, since it can't register the new replacement task in either target group.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.
/

What is the expected behavior?
Although this may be out of scope for this module and not the intended usage, it would maybe be nice to mention this behavior somewhere in the documentation.

My current workaround is:

• Let the module only create one target group, for you blue deployments
• Outside the module create another target group resource for green deployments, and attach it to a different listener with a different port than your main listener, such as 8080
• In your codedeploy you can now pass both listeners (production listener for example on port 80 and test listener on 8080) and both target groups (blue and green target groups)

The problem will be that after the deployment has gone through, the target groups will have been switched out (codedeploy is doing this), so your infra state will not match your terraform any longer.

When you do a terraform apply after the first deployment, it will want to revert those changes. The module does not provide lifecycle ignore_changes on the load_balancer block, and so applying those changes will possibly break the load balancer routing to your ecs service.

The only workaround I've found for that is to clone the repo and to add lifecycle block with ignore_changes on load_balancer in the aws_ecs_server resource.

Software versions?
6.4.1

I keep getting the following error and not sure how to fix it.

 Error: error creating ecs-fargate-example service: InvalidParameterException: The target group with targetGroupArn arn:aws:elasticloadbalancing:us-east-1:549567774903:targetgroup/tg-fargate-example/97c07ffe67daf38f does not have an associated load balancer.
│ 
│   with module.ecs-fargate.aws_ecs_service.service,
│   on .terraform/modules/ecs-fargate/main.tf line 279, in resource "aws_ecs_service" "service":
│  279: resource "aws_ecs_service" "service" {

Here's main.tf

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 3.27"
    }
  }

  required_version = ">= 0.14.9"
}


provider "aws" {
  profile = "xxx"
  region  = "us-east-1"
}


resource "aws_ecs_cluster" "cluster" {
  name = "example-ecs-cluster"

  capacity_providers = ["FARGATE_SPOT", "FARGATE"]

  default_capacity_provider_strategy {
    capacity_provider = "FARGATE_SPOT"
  }

  setting {
    name  = "containerInsights"
    value = "disabled"
  }
}

module "ecs-fargate" {
  source = "umotif-public/ecs-fargate/aws"
  version = "~> 6.1.0"

  name_prefix        = "ecs-fargate-example"
  vpc_id             = "xxxx"
  private_subnet_ids = ["xxxx", "xxx"]

  cluster_id         = aws_ecs_cluster.cluster.id

  task_container_image   = "marcincuber/2048-game:latest"
  task_definition_cpu    = 256
  task_definition_memory = 512

  task_container_port             = 80
  task_container_assign_public_ip = false

  target_groups = [
    {
      target_group_name = "tg-fargate-example"
      container_port    = 80
    }
  ]

  health_check = {
    port = "traffic-port"
    path = "/"
  }

  tags = {
    Environment = "test"
    Project = "Test"
  }
}

Software versions?
Terraform v1.0.5
on linux_amd64

• provider registry.terraform.io/hashicorp/aws v3.56.0

What is the current behavior?
Attempting to set up private DNS service discovery for the fargate service created by this module, I get the error message
Error: InvalidParameterException: The values specified for serviceRegistries do not require a value for 'containerPort'. Remove the value and retry. followed by the registry ARN and name.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.
In my instantiation of the Umotif Fargate module I added this parameter:
service_registry_arn = aws_service_discovery_service.service.arn which references a Service Discovery Service resource.

What is the expected behavior?
Everything provisions successfully and the Fargate service updates the Service Discovery service as required.

Software versions?

• Terraform v0.13.5
• terraform-aws-ecs-fargate v4.0.3

Hello,

I was wondering if it was possible to add custom task role support to this project?

Thanks,

Suppose we have the following setup:

resource "aws_lb_listener" "alb_80" {
  load_balancer_arn = module.alb.arn
  port              = "80"
  protocol          = "HTTP"

  default_action {
    type             = "forward"
    target_group_arn = module.fargate.target_group_arn[0]
  }
}

resource "aws_lb_listener" "alb_81" {
  load_balancer_arn = module.alb.arn
  port              = "81"
  protocol          = "HTTP"

  default_action {
    type             = "forward"
    target_group_arn = module.fargate.target_group_arn[1]
  }
}

module "fargate" {
  source = "../../"

  name_prefix = "ecs-fargate-example"
  ...

  target_groups = [
    {
      target_group_name = "B"
      container_port    = 80
    },
    {
      target_group_name = "A"
      container_port    = 81
    }
  ]

  ...
}

The above code reads as though:

• aws_lb_listener.alb_80 will map to target_group_name = "B"
• aws_lb_listener.alb_81 will map to target_group_name = "A"

However, I think the opposite actually happens. The module uses the following code for outputs:

output "target_group_arn" {
  description = "The ARN of the Target Group used by Load Balancer."
  value       = [for tg_arn in aws_lb_target_group.task : tg_arn.arn]
}

The for expression can modify the ordering of the input target_groups list. From terraform's documentation:

Because for expressions can convert from unordered types (maps, objects, sets) to ordered types (lists, tuples), Terraform must > choose an implied ordering for the elements of an unordered collection.

For maps and objects, Terraform sorts the elements by key or attribute name, using lexical sorting.

Can you confirm whether my understanding of the problem is correct?

I saw this issue was closed, so not sure if there was a fix for it. I think this would be a good addition to this module.

Issue#54

What is the current behavior?

Error: error waiting for ECS service (arn:aws:ecs:us-east-11234567890:service/ecs-cluster/ecs-fargate) to become ready: ResourceNotReady: exceeded wait attempts
│
│   with module.fargate.aws_ecs_service.service,
│   on ..\..\main.tf line 295, in resource "aws_ecs_service" "service":
│  295: resource "aws_ecs_service" "service" {

For some reason, terraform exits with the above error. But I could see the resources on the console. Not sure if there is any timeout value we could add until the resources get created.

What is the current behavior?

I have both a Fargate Terraform module and a GitHub Action deploying Fargate. GitHub Action knows to updates the latest TaskDefinition. The Fargate Terraform module continues to update the old version that it created.

aws-actions/amazon-ecs-render-task-definition@v1
aws-actions/amazon-ecs-deploy-task-definition@v1

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.

I don't have a great way to show the repo. We have a big, private repo. I'm guessing this will be pretty easy to confirm by someone that knows this code. I'm guessing this is working as implemented.

What is the expected behavior?

I'd expect this module to either reuse the latest TaskDefinition or create a new TaskDefinition.

Software versions?

6.1.0

What is the current behavior?
Following the README I cannot deploy an ECS service.

module.ecs-fargate.aws_ecs_service.service: Creating...
module.ecs-fargate.aws_ecs_service.service: Still creating... [10s elapsed]
module.ecs-fargate.aws_ecs_service.service: Still creating... [20s elapsed]
module.ecs-fargate.aws_ecs_service.service: Still creating... [30s elapsed]
module.ecs-fargate.aws_ecs_service.service: Still creating... [40s elapsed]
module.ecs-fargate.aws_ecs_service.service: Still creating... [50s elapsed]
module.ecs-fargate.aws_ecs_service.service: Still creating... [1m0s elapsed]
module.ecs-fargate.aws_ecs_service.service: Still creating... [1m10s elapsed]
module.ecs-fargate.aws_ecs_service.service: Still creating... [1m20s elapsed]
module.ecs-fargate.aws_ecs_service.service: Still creating... [1m30s elapsed]
module.ecs-fargate.aws_ecs_service.service: Still creating... [1m40s elapsed]
module.ecs-fargate.aws_ecs_service.service: Still creating... [1m50s elapsed]
module.ecs-fargate.aws_ecs_service.service: Still creating... [2m0s elapsed]

Error: InvalidParameterException: The target group with targetGroupArn arn:aws:elasticloadbalancing:REGION:ACCOUNTID:targetgroup/ecs-fargate-example-target-80/ANOTHERID does not have an associated load balancer. "ecs-fargate-example"

The target group seems to be created, but without being attached to ALB

module.ecs-fargate.aws_lb_target_group.task[0]: Creating...
module.ecs-fargate.aws_lb_target_group.task[0]: Creation complete after 1s [id=arn:aws:elasticloadbalancing:ap-southeast-1:465259923894:targetgroup/ecs-fargate-example-target-80/1e5ca7e82f23a419]

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.

What is the expected behavior?

Software versions?

Terraform v0.14.6
+ provider registry.terraform.io/hashicorp/aws v3.27.0

Hello,

Currently we would like to restrict the outgoing traffic for our fargate service. After looking at the source code in "https://github.com/umotif-public/terraform-aws-ecs-fargate/blob/master/main.tf" I just found out that there is a default security rule created which allow all outgoing traffic.
This represent an issue for us, since our security guidelines force us to limit outgoing traffic only to what it is necessary.

Would be possible to add an a feature toggle or input variable like 'deny_egress_to_anywhere' which if set to true then no egress rule will be created?

Something like

`module "ecs-fargate" {
source = "umotif-public/ecs-fargate/aws"
version = "6.5.0"
vpc_id = var.vpc_id
private_subnet_ids = var.private_subnets_ids

cluster_id = aws_ecs_cluster.cluster.id
deny_egress_to_anywhere = true
`