Datasource aws_ecs_task_definition should be able to query inside container definitions.

[hashibot]

This issue was originally opened by @maartenvanderhoef as hashicorp/terraform#11907. It was migrated here as part of the provider split. The original body of the issue is below.

---

Hi Everyone,

Feature request regarding the latest added datasource: aws_ecs_task_definition. I think it would be an advantage to be able to query the inside of the container definitions, especially retrieving the docker image-path through the datasource aws_ecs_task_definition would be extremely practical to be able to make changes to the task_definition without having to input the current image defined in the task_definition.
This would make it easier to deploy to ECS without terraform and meanwhile keep using TF for changes to the task_definition.

Adding to that having a data source for the aws_ecs_service would be helpful to get the desired_count of the current active aws_ecs_service or make the desired_count optional as described in hashicorp/terraform#9690

With a setup as describe below I can use different tools for docker image deployment and still use Terraform for modifications to the task definition (memory, cpu, etc. ). When applying
those modifications the current running docker image is being used freeing me of inputting the current running running image which looks closer like
12345.dkr.ecr.us-east-1.amazonaws.com/myapp:201702-97cd14affc2f0dc965813929dfeb9cef60a308a2 than mongo:latest.

# new data source for ecs_service to be able to retrieve the current desired_count 
data "aws_ecs_service" "app" {     
  name = "${aws_ecs_service.app.name}"
}

data "aws_ecs_task_definition" "app" {
  task_definition = "${aws_ecs_task_definition.app.family}"
}

data "template_file" "task_definition" {
  template = "${file("${"${path.module}/task-definition.json"}")}"

  # Of the first container_definition take the image path. If it exists use this, otherwise take the given var.image_url.
  vars {
    #### NEW MAGIC HERE ###
    image_url        = "${data.aws_ecs_task_definition.app.container_definitions.0.image ? data.aws_ecs_task_definition.app.container_definitions.0.image : var.image_url}"
  }
}

resource "aws_ecs_task_definition" "app" {
  family = "${var.cluster_name}-${var.shortname}"
  task_role_arn = "${aws_iam_role.ecs_tasks_role.arn}"
  container_definitions = "${data.template_file.task_definition.rendered}"
}

resource "aws_ecs_service" "app" {
  name = "${var.ecs_service_name}"
  cluster = "${aws_ecs_cluster.foo.id}"
  # Copying the desired count of the current active service, when not available, take the desired_count of the current active aws_ecs_service
  desired_count = "${data.aws_ecs_service.desired_count ? data.aws_ecs_service.desired_count : var.desired_count }

  # Track the latest ACTIVE revision
  task_definition = "${aws_ecs_task_definition.app.family}:${max("${aws_ecs_task_definition.app.revision}", "${data.aws_ecs_task_definition.app.revision}")}"
}

[schmod]

aws_ecs_container_definition may be the thing that you are looking for.

However, I have not been able to find a way to use it effectively in a workflow, as I end up with a chicken/egg problem, wherein the data block fails on the initial deployment, as no service has been created yet.

Ideally, I'd like to be able to deploy and manage my infrastructure with Terraform, but manage image deployments to ECS externally. In other words, I want to be able to tell Terraform: "Use the image from the most recent task definition, but take everything else from the TF configuration." If you already have existing infrastructure , this can be accomplished by using aws_ecs_container_definition as a data-source, pointed at your deployed task definition. Unfortunately, that data source fails cannot be used during a "clean" first deployment.

[steveh]

I'm in the same boat. I want to manage everything but the image with TF. If the container definitions could themselves be defined by Terraform (instead of a JSON blob) I wonder if you could also use ignore_changes?

[steveh]

related: #632

[github-actions]

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!