trussworks / terraform-aws-ecs-service Goto Github PK

Is it doable to add External Deployment Type for this ECS service module?

The existing types are: EC2 and Fargate. We need the support for External Deployment Type to enable the third party tool to deploy ECS service.

Add new function for External Deployment Type beside of EC2 and Fargate.

AWS documentation:
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-type-external.html

The 3.3.0 release had a bug and wasn't usable with TF12, AWS 3.X. This PR fixed it, but it's not tagged yet so it's not easily usable. Could you please tag/release commit b6106f9 terraform012 branch as release 3.3.1?

This issue provides visibility into Renovate updates and their statuses. Learn more

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

• fix(deps): update module github.com/aws/aws-sdk-go to v1.42.1

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• fix(deps): update dependencies (patch) (github.com/aws/aws-sdk-go, github.com/gruntwork-io/terratest)

• Check this box to trigger a request for Renovate to run again on this repository

Hello,

I'm getting the following error when trying to create a service that uses an existing cluster and an existing ALB.

Error:

Error: error creating ECS service (webserver-test): InvalidParameterException: Unable to assume role and validate the specified targetGroupArn. Please verify that the ECS service role being passed has the proper permissions.

I am not quite sure I understand what service role this error could be referring to.

Configuration:

module "app_ecs_service" {
  source = "trussworks/ecs-service/aws"

  name                           = var.application_name
  environment                    = var.environment
  ec2_create_task_execution_role = true

  ecs_cluster           = var.cluster_data
  ecs_vpc_id            = var.existing_vpc
  ecs_subnet_ids        = var.subnet_ids
  tasks_desired_count   = 2
  container_definitions = var.app_definition
  kms_key_id = var.kms_key_id

  associate_alb      = true
  alb_security_group = var.alb_security_group
  lb_target_groups = [
    {
      container_port              = 3000
      container_health_check_port = 3000
      lb_target_group_arn         = var.load_balancer_arn
    }
  ]
}

Describe the bug
ECS container service_registries doesn't work as expected.
The container_port and port for service_registries should be optional, but in the module it required the input.
I need to disable both container_port and port value from trussworks/ecs-service module main.tf and variables.tf to run terraform apply correctly.

Using
AWS CLI aws-cli/2.2.38
terraform v1.3.4
module "ecs-service" {
source = "trussworks/ecs-service/aws"
version ="6.6.0"

main.tf
dynamic "service_registries" {
for_each = var.service_registries
content {
registry_arn = service_registries.value.registry_arn
container_name = service_registries.value.container_name
#container_port = service_registries.value.container_port
#port = service_registries.value.port
}
}

variable "service_registries" {
description = ""
type = list(object({
registry_arn = string
container_name = string
#container_port = number
#port = number
}))
default = []
}

I Have several ECS Tasks deployed in EC2 (Not Fargate), but this module don't create the execution role if the task is not Fargate.

Add new variable, something like ec2_task_execution_role create. With this new variable add a new condition to create execution role:

• If ecs_fargate is true => Create the execution role (Current condition)

• if ecs_fargate is false but ec2_task_execution_role is true => create the execution rule

If makes sense, i can create the PR

Hello,

This might not be a good place to ask this, but I am curious about the code block around lifecycle ignore_changes and what's the philosophy around managing the container definitions in a deployment tool and any pointer for a deployment tool that you can share.

https://github.com/trussworks/terraform-aws-ecs-service/blob/master/main.tf#L433

lifecycle {
    ignore_changes = [
      requires_compatibilities,
      cpu,
      memory,
      execution_role_arn,
      container_definitions,
    ]
  }

Describe the bug
EFS volumes (efs_volume_configuration or docker_volume_configuration) doesn't work with trussworks/terraform-aws-ecs-service v.6.6.0 using the module. I need to modify locally the ecs module main.tf and variables.tf and disable some unnecessary rows to make it happen.

AWS CLI version: aws-cli/2.2.38
terraform v1.3.4
module "ecs-service" {
source = "trussworks/ecs-service/aws"
version ="6.6.0"

When using the ecs module, you can find from main.tf

dynamic "volume" {
for_each = var.container_volumes
content {
name = volume.value.name
}
}
and from variables.tf

variable "container_volumes" {
description = "Volumes that containers in your task may use."
default = []
type = list(
object({
name = string
})
)
}

So basically as default you can add only the name for container_volumes without any efs_volume_configuration or docker_volume_configuration

I need to modify locally main.tf and add extra information to enable mapping the efs volume configuration for ECS

dynamic "volume" {
for_each = var.container_volumes
content {
name = volume.value.name

  # host_path = lookup(volume.value, "host_path", null)

  # dynamic "docker_volume_configuration" {
  #   for_each = lookup(volume.value, "docker_volume_configuration", [])
  #   content {
  #     autoprovision = lookup(docker_volume_configuration.value, "autoprovision", null)
  #     driver        = lookup(docker_volume_configuration.value, "driver", null)
  #     driver_opts   = lookup(docker_volume_configuration.value, "driver_opts", null)
  #     labels        = lookup(docker_volume_configuration.value, "labels", null)
  #     scope         = lookup(docker_volume_configuration.value, "scope", null)
  #   }
  # }

  dynamic "efs_volume_configuration" {
    for_each = lookup(volume.value, "efs_volume_configuration", [])
    content {
      file_system_id          = lookup(efs_volume_configuration.value, "file_system_id", null)
      root_directory          = lookup(efs_volume_configuration.value, "root_directory", null)
      # transit_encryption      = lookup(efs_volume_configuration.value, "transit_encryption", null)
      # transit_encryption_port = lookup(efs_volume_configuration.value, "transit_encryption_port", null)
      # dynamic "authorization_config" {
      #   for_each = lookup(efs_volume_configuration.value, "authorization_config", [])
      #   content {
      #     access_point_id = lookup(authorization_config.value, "access_point_id", null)
      #     iam             = lookup(authorization_config.value, "iam", null)
      #   }
      # }
    }
  }
}

}

and then add to variables.tf

variable "container_volumes" {
description = "Volumes that containers in your task may use."
type = list(object({
#host_path = string
name = string
# docker_volume_configuration = list(object({
# autoprovision = bool
# driver = string
# driver_opts = map(string)
# labels = map(string)
# scope = string
# }))
efs_volume_configuration = list(object({
file_system_id = string
root_directory = string
# transit_encryption = string
# transit_encryption_port = string
# authorization_config = list(object({
# access_point_id = string
# iam = string
# }))
}))
}))
default = []
}

Dependabot couldn't parse the go.mod found at /go.mod.

The error Dependabot encountered was:

go: github.com/gruntwork-io/[email protected] requires
	github.com/google/[email protected] requires
	github.com/vdemeester/[email protected] requires
	k8s.io/[email protected] requires
	google.golang.org/[email protected]: invalid version: git fetch --unshallow -f origin in /opt/go/gopath/pkg/mod/cache/vcs/30a5dbaa452c7ca9354df264080379bbcf24496036c60968495fa0ec4a41888c: exit status 128:
	error: RPC failed; HTTP 502 curl 22 The requested URL returned error: 502 Bad Gateway
	fatal: The remote end hung up unexpectedly

View the update logs.

some Containers require a volume to function.
add ability for volumes in the task definition so container that require volumes can be used.

Is your feature request related to a problem? Please describe.
For any deploys not using ports 8080 or 8081 in lb_target_groups, and hello_world_container_ports not defined, the module will error saying something along the lines of the cluster has no routing to the ports defined in lb_target_groups. I don't have the exact error offhand, but the error is somewhat vague, and we ended up changing the task definition to include the port we were using to make the apply happy

This is in no way a pressing need, more of a QoL change I think that would help for future users.

Describe the solution you'd like
Maybe have hello_world_container_ports and lb_target_groups.container_port checked in a local where you concat the target group ports to the hello world ports in case they are missing?

If I have some time, I can try and come up with an idea for how to concat the two params, I know it isn't just a simple concat since the target group param is a list of objects. There'd probably need to be an intermediate list where you pull the service and access ports and append them to that list

Describe alternatives you've considered
We found the hello_world_container_ports param after creating a new version of the definition with the ports defined, that's the only other way we could think of to have it work

Additional context
Add any other context or screenshots about the feature request here.

Describe the bug

The service_registries variable has 4 parameters, and all 4 required from this module. In the underlying module that this calls, the only required parameter is registry_arn, they rest are listed as optional. When we try to add this functionality on an existing module, we have to specify all 4 parameters, or the module will fail validations. However, on existing ECS services, we do not need the port and container_port, because they are optional and dealt with by the ECS config JSON.

I think a way to fix this would to tweaking the variable structure so that it can accept those parameters not being there, and then main to set them if they are there, or null if not

To Reproduce
Steps to reproduce the behavior:

1. Create a service without the service_registries section defined
2. Update with adding that parameter
3. You will either get an error because parameters are not set, or because they are and you don't need them

Expected behavior

The parameters are optional instead of required