Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for multiple volumes for an ecs task definition #10836

Closed
AKoetsier opened this issue Dec 19, 2016 · 10 comments
Closed

Support for multiple volumes for an ecs task definition #10836

AKoetsier opened this issue Dec 19, 2016 · 10 comments

Comments

@AKoetsier
Copy link
Contributor

AKoetsier commented Dec 19, 2016

Terraform Version

0.8.1

Affected Resource(s)

  • aws_ecs_task_definition

Requested Behavior

In the aws_ecs_task_definition you can specify a single volume. However the AWS API documentation mentions you can specify multiple volumes. It would be nice if that would also be possible within aws_ecs_task_definition.

@AKoetsier
Copy link
Contributor Author

Sorry, clearly a RTFM

@mikelindsey-okta
Copy link

How is this clearly an RTFM?

I have RTFM, and terraform does not support a plurality of volumes. The source code shows it doesn't support lists of volumes or a JSON block.

@AKoetsier
Copy link
Contributor Author

You can just repeat the volume block to add multiple volumes.

@dminnear
Copy link

There is no indication on https://www.terraform.io/docs/providers/aws/r/ecs_task_definition.html#volume that the volume block can be resused. I think it should be added to the documentation since at least a few people are confused.

@Ninir
Copy link
Contributor

Ninir commented Jul 18, 2017

Hey everyone,

Just to let you know that the documentation has been updated accordingly, and the website should reflect it on the next release.

@ozbillwang
Copy link

ozbillwang commented Sep 14, 2017

Here is my user case.

It is hard to set volume blocks with different applications in terraform modules.

  volume  {
    name      = "service-storage"
    host_path = "/ecs/service-storage"
  }

  volume  {
    name      = "www"
    host_path = "/var/www/html"
  }

Which I prefer

  volumes = [
  {
    "name": "service-storage",
    "host": {
      "sourcePath": "/ecs/service-storage"
    }
  },
  {
    "name": "www",
    "host": {
      "sourcePath": "/var/www/html"
    }
  }
]

with that, I can define it as exteral json file as well , same as container_definitions ((sample: https://www.terraform.io/docs/providers/aws/r/ecs_task_definition.html) ), what ever how many volumes need be added.

  container_definitions = "${file("task-definitions/service.json")}"
  volumes = "${file("task-definitions/volumes.json")}"

Because of this reason, I have to take this resource aws_ecs_task_definition out of a ECS service terraform module. It is bad.

@tomstockton
Copy link

@ozbillwang I've got exactly the same problem. Did you find an acceptable workaround?!

@ozbillwang
Copy link

@tomstockton

I by-pass the volume setting and use links option in task definition, so containers in same task definition can share the folders.

For example, when build image, add below line in Dockerfile

VOLUME /var/www/html /ecs/service-storage

In task definition, add below lines

"links": [
  "${app_name}:application"
],

@simoneroselli
Copy link

Loading volumes from whatever external source is fundamental here. Moving the task_definition out of any ecs service modules is a big frustration because it makes the module resource (service) depending from an "interface" value (task_definition arn). Really bad and pointless.

Any chances to have this feature?

@ghost
Copy link

ghost commented Apr 6, 2020

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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked and limited conversation to collaborators Apr 6, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants