<p>From what I see in your terraform plan, <code>terraform apply</code> will indeed set the latest task definition version and probably run redeploy of your ECS.</p>
<p>You can keep your state file up-to-date with <code>terraform plan --refresh-only</code> to see the possible changes in infrastructure done manually, and if you are ok with it, <code>terraform apply --refresh-only</code> will save those changes in your terraform state file.</p>
<p><a href="https://learn.hashicorp.com/tutorials/terraform/refresh" rel="nofollow noreferrer">Here</a> is some more info on that subject.</p>
<p>Hope it helps</p>

CC BY-SA 4.0
2022-06-03T08:26:51.663Z
2022-06-03T08:26:51.663Z
Darko Petrovic
<p>I would like your help on a situation that I'm facing with terrafom. My company recently launched a new website whose wordpress is hosted in an AWS ECS container. I had to make some adjustments to the site's infrastructure and I noticed that, when making the terraform plan, I get a message that there were changes outside the terraform, one of which is the revision number of the ECS Task Definition. But looking further down, when terraform plans the ECS Task Definition, instead of keeping the most recent revision number (31), he goes back to the last version that was applied by terraform (19). I suppose that this number is recorded in the TF state. My question is: is there any way (parameter or attribute) to perform the terraform plan and make it plan the ECS Task Definition with the latest active version deployed in the ECS container, in this case 31? The deployment is done through a bitbucket pipeline and the image is stored in the ECR.</p>
<p>This is the steps we run in bitbucket:</p>
<pre><code>- step:
      oidc: true
      name: Get task-definition
      image: amazon/aws-cli:2.5.0
      artifacts:
        - task-definition.json
      script:
        - yum install jq -y
        - export AWS_REGION=us-east-1
        - export AWS_ROLE_ARN=arn:aws:iam::my-account:role/ci-ecs
        - export AWS_WEB_IDENTITY_TOKEN_FILE=$(pwd)/web-identity-token
        - echo $BITBUCKET_STEP_OIDC_TOKEN &gt; $(pwd)/web-identity-token  
        - TASK_DEFINITION=$(aws ecs describe-task-definition --task-definition site-institucional-prd) 
        - ECR_IMAGE_TAG=145497587889.dkr.ecr.us-east-1.amazonaws.com/site-institucional-prd:${BITBUCKET_COMMIT}             
        - NEW_TASK_DEFINTIION=$(echo &quot;$TASK_DEFINITION&quot; | jq --arg IMAGE &quot;$ECR_IMAGE_TAG&quot; '.taskDefinition | .containerDefinitions[0].image = $IMAGE | del(.taskDefinitionArn) | del(.revision) | del(.status) | del(.requiresAttributes) | del(.compatibilities) | del(.registeredAt) | del(.registeredBy)')
        - echo $NEW_TASK_DEFINTIION &gt; task-definition.json

  - step:
      oidc: true
      name: Deploy to ECS
      script:
        - pipe: atlassian/aws-ecs-deploy:1.6.1
          variables:
            AWS_DEFAULT_REGION: 'us-east-1'
            AWS_OIDC_ROLE_ARN: 'arn:aws:iam::my-account:role/ci-ecs'
            CLUSTER_NAME: 'emprc-fgt-prd'
            SERVICE_NAME: 'site-institucional-prd-fgt'
            TASK_DEFINITION: 'task-definition.json'
</code></pre>
<p>I'm using the internal terraform module.</p>
<p>This is the part of my terraform where we provision the ECS Sevice based on the module we have created:</p>
<pre><code>################################################################################
# ECS FARGATE
################################################################################

module &quot;wp&quot; {
 source = &quot;git::git@bitbucket.org:my-repo//terraform/aws-ecs/modules/fargate-service&quot;

  environment = var.environment

  enabled = var.enabled

  // variables task definition

  container_name = var.container_name

  enable_execute_command = var.enable_execute_command

  task_container_image = var.task_container_image

  task_definition_cpu    = var.task_definition_cpu
  task_definition_memory = var.task_definition_memory

  task_container_environment = var.task_container_environment

  extra_container_defs = var.extra_container_defs

  // variables service

  vpc_id          = var.vpc_id
  subnet_ids      = var.subnet_ids
  security_groups = var.security_groups
  service_name    = var.service_name

  cluster_id = var.cluster_id

  desired_count = var.desired_count

  capacity_provider_strategy = var.capacity_provider_strategy

  target_groups = var.target_groups

  health_check = var.health_check

  http_header = var.http_header

  lb_arn       = var.lb_arn
  host_header  = var.host_header

  autoscale = var.autoscale

  tags = var.tags
}
</code></pre>
<p>Here is the result of my terraform plan with only the problem theme (I will mask some values ​​in the plan below):</p>
<pre><code>Terraform detected the following changes made outside of Terraform since the
last &quot;terraform apply&quot;:
 
# module.wp.aws_ecs_service.service[0] has been changed
  ~ resource &quot;aws_ecs_service&quot; &quot;service&quot; {
        id                                 = &quot;arn:aws:ecs:us-east-1:my-account:service/emprc-fgt-prd/my-name&quot;
        name                               = &quot;my-name&quot;
        tags                               = {
            &quot;Environment&quot; = &quot;prd&quot;
            &quot;Name&quot;        = &quot;my-name&quot;
            &quot;Owner&quot;       = &quot;Owner&quot;
            &quot;Project&quot;     = &quot;project-name&quot;
            &quot;Provider&quot;    = &quot;Terraform&quot;
        }
      ~ task_definition                    = &quot;arn:aws:ecs:us-east-1:my-account:task-definition/site-institucional-prd:19&quot; -&gt; &quot;arn:aws:ecs:us-east-1:my-account:task-definition/site-institucional-prd:31&quot;
        # (14 unchanged attributes hidden)

Unless you have made equivalent changes to your configuration, or ignored the
relevant attributes using ignore_changes, the following plan may include
actions to undo or respond to these changes.
───────────────────────

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create
  ~ update in-place
 &lt;= read (data resources)

Terraform will perform the following actions:
 # module.wp.aws_ecs_service.service[0] will be updated in-place
  ~ resource &quot;aws_ecs_service&quot; &quot;service&quot; {
        id                                 = &quot;arn:aws:ecs:us-east-1:my-account:service/emprc-fgt-prd/site-institucional-prd-fgt&quot;
        name                               = &quot;my-name&quot;
        tags                               = {
            &quot;Environment&quot; = &quot;prd&quot;
            &quot;Name&quot;        = &quot;my-name&quot;
            &quot;Owner&quot;       = &quot;Owner&quot;
            &quot;Project&quot;     = &quot;project-name&quot;
            &quot;Provider&quot;    = &quot;Terraform&quot;
        }
      ~ task_definition                    = &quot;arn:aws:ecs:us-east-1:my-account:task-definition/site-institucional-prd:31&quot; -&gt; &quot;arn:aws:ecs:us-east-1:my-account:task-definition/site-institucional-prd:19&quot;
        # (14 unchanged attributes hidden)
</code></pre>
<p>So new version deployment (wordpress) is always done by the bitbucket pipeline once the infrastructure is in place. In theory we do not change the infra, but when we need to change something on it, the task definition revision number is changed by terraform trying to assume the revision in TF state which is out dated. I understand that this is the correct behavior once the deployment is done by the bitbucket pipeline, but I would like to know if there is a way to keep the current revision active in ECS during the plan/apply.</p>
<p>Thank you for your time and support.</p>

<amazon-web-services><terraform><amazon-ecs><bitbucket-pipelines>
Terraform plan does not update AWS Task Definition with last active revision value
Anaue Curi
# Terraform plan does not update AWS Task Definition with last active revision value

(Asked by: username_0 on 2022-06-01)

I would like your help on a situation that I'm facing with terrafom. My company recently launched a new website whose wordpress is hosted in an AWS ECS container. I had to make some adjustments to the site's infrastructure and I noticed that, when making the terraform plan, I get a message that there were changes outside the terraform, one of which is the revision number of the ECS Task Definition. But looking further down, when terraform plans the ECS Task Definition, instead of keeping the most recent revision number (31), he goes back to the last version that was applied by terraform (19). I suppose that this number is recorded in the TF state. My question is: is there any way (parameter or attribute) to perform the terraform plan and make it plan the ECS Task Definition with the latest active version deployed in the ECS container, in this case 31? The deployment is done through a bitbucket pipeline and the image is stored in the ECR.
This is the steps we run in bitbucket:
- step:
      oidc: true
      name: Get task-definition
      image: amazon/aws-cli:2.5.0
      artifacts:
        - task-definition.json
      script:
        - yum install jq -y
        - export AWS_REGION=us-east-1
        - export AWS_ROLE_ARN=arn:aws:iam::my-account:role/ci-ecs
        - export AWS_WEB_IDENTITY_TOKEN_FILE=$(pwd)/web-identity-token
        - echo $BITBUCKET_STEP_OIDC_TOKEN > $(pwd)/web-identity-token  
        - TASK_DEFINITION=$(aws ecs describe-task-definition --task-definition site-institucional-prd) 
        - ECR_IMAGE_TAG=145497587889.dkr.ecr.us-east-1.amazonaws.com/site-institucional-prd:${BITBUCKET_COMMIT}             
        - NEW_TASK_DEFINTIION=$(echo "$TASK_DEFINITION" | jq --arg IMAGE "$ECR_IMAGE_TAG" '.taskDefinition | .containerDefinitions[0].image = $IMAGE | del(.taskDefinitionArn) | del(.revision) | del(.status) | del(.requiresAttributes) | del(.compatibilities) | del(.registeredAt) | del(.registeredBy)')
        - echo $NEW_TASK_DEFINTIION > task-definition.json

  - step:
      oidc: true
      name: Deploy to ECS
      script:
        - pipe: atlassian/aws-ecs-deploy:1.6.1
          variables:
            AWS_DEFAULT_REGION: 'us-east-1'
            AWS_OIDC_ROLE_ARN: 'arn:aws:iam::my-account:role/ci-ecs'
            CLUSTER_NAME: 'emprc-fgt-prd'
            SERVICE_NAME: 'site-institucional-prd-fgt'
            TASK_DEFINITION: 'task-definition.json'

I'm using the internal terraform module.
This is the part of my terraform where we provision the ECS Sevice based on the module we have created:
################################################################################
# ECS FARGATE
################################################################################

module "wp" {
 source = "git::git@bitbucket.org:my-repo//terraform/aws-ecs/modules/fargate-service"

  environment = var.environment

  enabled = var.enabled

  // variables task definition

  container_name = var.container_name

  enable_execute_command = var.enable_execute_command

  task_container_image = var.task_container_image

  task_definition_cpu    = var.task_definition_cpu
  task_definition_memory = var.task_definition_memory

  task_container_environment = var.task_container_environment

  extra_container_defs = var.extra_container_defs

  // variables service

  vpc_id          = var.vpc_id
  subnet_ids      = var.subnet_ids
  security_groups = var.security_groups
  service_name    = var.service_name

  cluster_id = var.cluster_id

  desired_count = var.desired_count

  capacity_provider_strategy = var.capacity_provider_strategy

  target_groups = var.target_groups

  health_check = var.health_check

  http_header = var.http_header

  lb_arn       = var.lb_arn
  host_header  = var.host_header

  autoscale = var.autoscale

  tags = var.tags
}

Here is the result of my terraform plan with only the problem theme (I will mask some values ​​in the plan below):
Terraform detected the following changes made outside of Terraform since the
last "terraform apply":
 
# module.wp.aws_ecs_service.service[0] has been changed
  ~ resource "aws_ecs_service" "service" {
        id                                 = "arn:aws:ecs:us-east-1:my-account:service/emprc-fgt-prd/my-name"
        name                               = "my-name"
        tags                               = {
            "Environment" = "prd"
            "Name"        = "my-name"
            "Owner"       = "Owner"
            "Project"     = "project-name"
            "Provider"    = "Terraform"
        }
      ~ task_definition                    = "arn:aws:ecs:us-east-1:my-account:task-definition/site-institucional-prd:19" -> "arn:aws:ecs:us-east-1:my-account:task-definition/site-institucional-prd:31"
        # (14 unchanged attributes hidden)

Unless you have made equivalent changes to your configuration, or ignored the
relevant attributes using ignore_changes, the following plan may include
actions to undo or respond to these changes.
───────────────────────

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create
  ~ update in-place
 <= read (data resources)

Terraform will perform the following actions:
 # module.wp.aws_ecs_service.service[0] will be updated in-place
  ~ resource "aws_ecs_service" "service" {
        id                                 = "arn:aws:ecs:us-east-1:my-account:service/emprc-fgt-prd/site-institucional-prd-fgt"
        name                               = "my-name"
        tags                               = {
            "Environment" = "prd"
            "Name"        = "my-name"
            "Owner"       = "Owner"
            "Project"     = "project-name"
            "Provider"    = "Terraform"
        }
      ~ task_definition                    = "arn:aws:ecs:us-east-1:my-account:task-definition/site-institucional-prd:31" -> "arn:aws:ecs:us-east-1:my-account:task-definition/site-institucional-prd:19"
        # (14 unchanged attributes hidden)

So new version deployment (wordpress) is always done by the bitbucket pipeline once the infrastructure is in place. In theory we do not change the infra, but when we need to change something on it, the task definition revision number is changed by terraform trying to assume the revision in TF state which is out dated. I understand that this is the correct behavior once the deployment is done by the bitbucket pipeline, but I would like to know if there is a way to keep the current revision active in ECS during the plan/apply.
Thank you for your time and support.

**Tags:** amazon-web-services, terraform, amazon-ecs, bitbucket-pipelines


---

## 1 answers

### Answer by username_1 on 2022-06-03. Score: 0

From what I see in your terraform plan, `terraform apply` will indeed set the latest task definition version and probably run redeploy of your ECS.

You can keep your state file up-to-date with `terraform plan --refresh-only` to see the possible changes in infrastructure done manually, and if you are ok with it, `terraform apply --refresh-only` will save those changes in your terraform state file.

[Here](https://learn.hashicorp.com/tutorials/terraform/refresh) is some more info on that subject.

Hope it helps


---

