Ignore real-world changes only

[StyleT]

Hi! I'm using Terraform for AWS ECS cluster provisioning and Python script for deploying a new versions of tasks in cluster since TF fits not really well for this (it can't check that deploy wasn't successful for example). To ignore task version changes that were done by Python script I'm using ignore_changes = [ "task_definition" ] parameter. And everything work perfectly except 1 issue. Now container_definitions update in aws_ecs_task_definition doesn't switches task definition to the latest version in aws_ecs_service.

Terraform Version

0.7.0

Affected Resource(s)

• aws_ecs_service
• aws_ecs_task_definition

  Terraform Configuration Files

resource "aws_ecs_task_definition" "frontend" {
    family = "frontend-staging"
    container_definitions = "{...}"
}

resource "aws_ecs_service" "frontend" {
    name = "frontend"
    cluster = "tst-cluster"
    task_definition = "${aws_ecs_task_definition.frontend.arn}"
    desired_count = 2

    lifecycle {
        ignore_changes = [ "task_definition" ]
    }
}

[CpuID]

I do something similar with an independent deploy tool written in Go.

What would be the motive to managing the aws_ecs_service and aws_ecs_task_definition resource at all in TF?

We opted to manage the cluster itself, and the ASG/LC with Terraform, and left task defs/services to the outside utility instead.

On 13 Aug 2016, at 1:40 PM, Vlad Fedosov notifications@github.com wrote:

Hi! I'm using Terraform for AWS ECS cluster provisioning and Python script for deploying a new versions of tasks in cluster since TF fits not really well for this (it can't check that deploy wasn't successful for example). To ignore task version changes that were done by Python script I'm using ignore_changes = [ "task_definition" ] parameter. And everything work perfectly except 1 issue. Now container_definitions update in aws_ecs_task_definition doesn't switches task definition to the latest version in aws_ecs_service.

Terraform Version

0.7.0

Affected Resource(s)

aws_ecs_service aws_ecs_task_definition Terraform Configuration Files

resource "aws_ecs_task_definition" "frontend" { family = "frontend-staging" container_definitions = "{...}" }

resource "aws_ecs_service" "frontend" { name = "frontend" cluster = "tst-cluster" task_definition = "${aws_ecs_task_definition.frontend.arn}" desired_count = 2

lifecycle {
    ignore_changes = [ "task_definition" ]
}

} — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[StyleT]

@CpuID Such approach allows us to keep all eggs in one place. TF for example dynamically passes generated by AWS ELB DNS names to the Docker containers through ENV params.

[CpuID]

Fair enough, everyone has a different use case :) I'm sure some context is always helpful for others.

[apparentlymart]

@StyleT with AWS Autoscaling Groups, Terraform has an extra feature where you can tell it to wait until a certain number of instances are in the group before declaring the creation successful.

Do you think there could be a comparable feature here, where Terraform could optionally monitor some aspect of the ECS service to determine whether the deploy succeeded, and thus address your concern a different way without needing that external program?

[StyleT]

@apparentlymart I don't think that it's good idea to have 1 tool for everything. I prefer UNIX way with range of small tools. Deploy process it's something that doesn't fits well in declarative TF style. For example during deploy I need to launch DB migrations/seeds, notify NewRelic, etc... So I still need some external program behind TF. From my point of view it's more reasonable to improve TF compatibility with other tools instead of adding deploy logic to TF. Also I'm still not comfortable with automatic TF launch because it allows to do so much... Of course I can limit it with AWS IAM policies but it's not an easy way.

P.S.: Talking about this issue. In my team, finally, we came to the following:

• Remove task definitions from TF and keep only services there with task_definition parameter that equals to task definition family name without revision number & mark it as ignore_changes.
• Put task definition config file (without environment config) to app repo & export them as shared artefact during build phase.
• During deployment
  • retrieve env vars from some storage
  • put them into task definition config from the build artefact
  • register new task definition
  • put new task definition revision to the service
  • wait for service stabilisation
  • If deploy was unsuccessful - revert service to previous task revision

[apparentlymart]

@StyleT definitely a valid position. I lean towards thinking of Terraform as a helper utility optimized for applying changes consistently across many separate systems, and that the "range of small tools" are the providers/resources within it that help you express the desired end-state. But in Terraform's current state there is definitely a limit to how far this idea can be taken. In particular, delegating to other tools for certain actions (we happen to use Rundeck tasks for that) is a perfectly reasonable idea, I think we just have a different -- and equally reasonable -- idea of where the boundary is between what Terraform deals with and where this "other actions" begin. :grinning:

[StyleT]

@apparentlymart you're totally right 😄

Honestly since I found solution for my problem this issue can be closed, but I would like to hear more opinions about possible ways to solve issue described above in more easier way (with or without changes in TF code). This use case wasn't described in the Internet so it's not so easy to find a solution for TF newbie.

[acejam]

I've been battling with an issue similar to this myself. I've opted to use ignore_changes as well. Each application repo then has a docker/ folder which contains a JSON task definition template. During deploy time, Jenkins dupes this file, modifies it, and passes it to the register-task-defintion AWS cli call.

[svperfecta]

I think the OP had it right. A lot of times variables in the container definition are resources configured by Terraform. It would be hard to manage that outside of Tform.

[hashibot]

Hello! :robot:

We use GitHub issues for tracking bugs and enhancements rather than for questions. While we can sometimes help with certain simple problems here, it's better to use the community forum where there are more people ready to help. The GitHub issues here are monitored only by our few core maintainers.

Since this issue doesn't represent a specific bug or feature request, I'm going to close it. Please do feel free to ask your question in the community forum. Thanks!

[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 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.