ECS deployments best practices

[Jason Marmon]

Terraform looks really cool but I can't for the life of me figure out a reasonable way to do deployments on elastic container service.

The standard setup with ECS is like so:

1. build new image of app with tag MYSHA1

2. push image

3. register a new task definition using myapp:MYSHA1

4. update the service managing this task to use the new definition

It seems the only way to perform the above with terraform is to update my terraform configuration and run terraform apply. It doesn't seem reasonable to run terraform apply for every deploy. Terraform is meant for infrastructure, not code deploys. I'd have to have my CI tool make commits to github with every new build...just doesn't seem right.

Is there some cleaner way I could handle this? Maybe with a reference to an s3 bucket object or something...

[Jason Marmon]

Not to mention having to update the state would mean I can never do parallel deploys in order to prevent state conflicts. Lots of issues with this strategy; really hoping someone has a better alternative

[Paul Hinze]

Hi Jason,

These are good questions! I have to admit we're not using ECS internally, so I can't speak with direct experience here. I _can_ however, provide a few points for your consideration:

 * Running `terraform apply` to effect a deploy is a fairly common pattern. It's how we do deploys for HashiCorp's production environments. A deploy can be thought of as an infrastructure change after all. :)

 * It's true that multiple copies of Terraform cannot be active simultaneously with the same state, but I wouldn't expect any of these `terraform apply` steps to be long running operations. As long as Terraform operations are performed with some sort of queue or locking mechanism to ensure only one runs at a time, there's nothing stopping plan/apply cycles from happening frequently.

 * Your example listed a tag of `myapp:MYSHA1` - is there a way to model your deployments using tags that move for each deployment so you don't need a task definition diff for every deploy? For example `myapp:staging`, `myapp:production` etc?

I wish I could give you a bit more specific ECS detail, but I hope the above is helpful to you!

Paul

 

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/terraform/issues
IRC: #terraform-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Terraform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to terraform-too...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/terraform-tool/e24cc9b8-9317-4303-b21d-d3783b86b499%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[jor...@getnotion.com]

If our task definitions are also managed by Terraform, it's fairly simple to taint the task definition to force a container update, as Terraform will create a new task definition version, which will also cause the service to update the version it uses. However, assuming that those definitions are managed by Terraform and committed to source control, updating the task definition version would result in a source control diff. So, if I perform a container update (which is managed by its own repository), is there a recommendation on how to tell Terraform to taint the resource, apply the change, and then include that in its own source control? 

Is there a better way to handle this? We have some solid CI/CD in place in our lower environments which are not currently managed by TF, but having TF manage the task definition on ECS seems to complicate this.

[Vikash Dat]

I am currently toying with utilizing terraform for infrastructure changes only, while using boto3 to register task definitions and create/update services. Sofar this has been working.

[Jordan Stone]

Yea I have been thinking about removing the task definitions from Terraform and maintaining some scripts to handle the task definition registration, and using the CLI to trigger new versions as we deploy new code.

> On Feb 8, 2016, at 8:27 PM, Vikash Dat <dat.v...@gmail.com> wrote:
>
> I am currently toying with utilizing terraform for infrastructure changes only, while using boto3 to register task definitions and create/update services. Sofar this has been working.
>

> --
> This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
>
> GitHub Issues: https://github.com/hashicorp/terraform/issues
> IRC: #terraform-tool on Freenode
> ---

> You received this message because you are subscribed to a topic in the Google Groups "Terraform" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/terraform-tool/-MUElwmCQno/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to terraform-too...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/terraform-tool/6e417e95-fa7e-4b93-bd78-96ced9198711%40googlegroups.com.

[Timothy Kimball]

Not completely related but we took the decision a while ago to decouple infrastructure (terraform) from configuration (ansible). A fuzzy line for sure - but we found it simplified development of new infrastructure and configuration changes.

We also have a separate test suite for each layer - allowing us to make infra changes and quickly validate w/o having to deploy ansible changes.

Not sure if this is best practice or not. All ears if there is a better way!

You received this message because you are subscribed to the Google Groups "Terraform" group.

To unsubscribe from this group and stop receiving emails from it, send an email to terraform-too...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/terraform-tool/92F5B6E1-8D58-43C0-802D-055D02E2BF38%40loopme.in.