Giter VIP home page Giter VIP logo

amazon-ecs-deploy-task-definition's Introduction

Amazon ECS "Deploy Task Definition" Action for GitHub Actions

Registers an Amazon ECS task definition and deploys it to an ECS service.

Table of Contents

Usage

    - name: Deploy to Amazon ECS
      uses: aws-actions/amazon-ecs-deploy-task-definition@v1
      with:
        task-definition: task-definition.json
        service: my-service
        cluster: my-cluster
        wait-for-service-stability: true

See action.yml for the full documentation for this action's inputs and outputs.

Task definition file

It is highly recommended to treat the task definition "as code" by checking it into your git repository as a JSON file. Changes to any task definition attributes like container images, environment variables, CPU, and memory can be deployed with this GitHub action by editing your task definition file and pushing a new git commit.

An existing task definition can be downloaded to a JSON file with the following command. Account IDs can be removed from the file by removing the taskDefinitionArn attribute, and updating the executionRoleArn and taskRoleArn attribute values to contain role names instead of role ARNs.

aws ecs describe-task-definition \
   --task-definition my-task-definition-family \
   --query taskDefinition > task-definition.json

Alternatively, you can start a new task definition file from scratch with the following command. In the generated file, fill in your attribute values and remove any attributes not needed for your application.

aws ecs register-task-definition \
   --generate-cli-skeleton > task-definition.json

If you do not wish to store your task definition as a file in your git repository, your GitHub Actions workflow can download the existing task definition.

    - name: Download task definition
      run: |
        aws ecs describe-task-definition --task-definition my-task-definition-family --query taskDefinition > task-definition.json

Task definition container image values

It is highly recommended that each time your GitHub Actions workflow runs and builds a new container image for deployment, a new container image ID is generated. For example, use the commit ID as the new image's tag, instead of updating the 'latest' tag with the new image. Using a unique container image ID for each deployment allows rolling back to a previous container image.

The task definition file can be updated prior to deployment with the new container image ID using the aws-actions/amazon-ecs-render-task-definition action. The following example builds a new container image tagged with the commit ID, inserts the new image ID as the image for the my-container container in the task definition file, and then deploys the rendered task definition file to ECS:

    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: us-east-2

    - name: Login to Amazon ECR
      id: login-ecr
      uses: aws-actions/amazon-ecr-login@v1

    - name: Build, tag, and push image to Amazon ECR
      id: build-image
      env:
        ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
        ECR_REPOSITORY: my-ecr-repo
        IMAGE_TAG: ${{ github.sha }}
      run: |
        docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
        docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
        echo "image=$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG" >> $GITHUB_OUTPUT

    - name: Fill in the new image ID in the Amazon ECS task definition
      id: task-def
      uses: aws-actions/amazon-ecs-render-task-definition@v1
      with:
        task-definition: task-definition.json
        container-name: my-container
        image: ${{ steps.build-image.outputs.image }}

    - name: Deploy Amazon ECS task definition
      uses: aws-actions/amazon-ecs-deploy-task-definition@v1
      with:
        task-definition: ${{ steps.task-def.outputs.task-definition }}
        service: my-service
        cluster: my-cluster
        wait-for-service-stability: true

Credentials and Region

This action relies on the default behavior of the AWS SDK for Javascript to determine AWS credentials and region. Use the aws-actions/configure-aws-credentials action to configure the GitHub Actions environment with environment variables containing AWS credentials and your desired region.

We recommend following Amazon IAM best practices for the AWS credentials used in GitHub Actions workflows, including:

  • Do not store credentials in your repository's code. You may use GitHub Actions secrets to store credentials and redact credentials from GitHub Actions workflow logs.
  • Create an individual IAM user with an access key for use in GitHub Actions workflows, preferably one per repository. Do not use the AWS account root user access key.
  • Grant least privilege to the credentials used in GitHub Actions workflows. Grant only the permissions required to perform the actions in your GitHub Actions workflows. See the Permissions section below for the permissions required by this action.
  • Rotate the credentials used in GitHub Actions workflows regularly.
  • Monitor the activity of the credentials used in GitHub Actions workflows.

Permissions

This action requires the following minimum set of permissions:

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"RegisterTaskDefinition",
         "Effect":"Allow",
         "Action":[
            "ecs:RegisterTaskDefinition"
         ],
         "Resource":"*"
      },
      {
         "Sid":"PassRolesInTaskDefinition",
         "Effect":"Allow",
         "Action":[
            "iam:PassRole"
         ],
         "Resource":[
            "arn:aws:iam::<aws_account_id>:role/<task_definition_task_role_name>",
            "arn:aws:iam::<aws_account_id>:role/<task_definition_task_execution_role_name>"
         ]
      },
      {
         "Sid":"DeployService",
         "Effect":"Allow",
         "Action":[
            "ecs:UpdateService",
            "ecs:DescribeServices"
         ],
         "Resource":[
            "arn:aws:ecs:<region>:<aws_account_id>:service/<cluster_name>/<service_name>"
         ]
      }
   ]
}

Note: the policy above assumes the account has opted in to the ECS long ARN format.

AWS CodeDeploy Support

For ECS services that uses the CODE_DEPLOY deployment controller, additional configuration is needed for this action:

    - name: Deploy to Amazon ECS
      uses: aws-actions/amazon-ecs-deploy-task-definition@v1
      with:
        task-definition: task-definition.json
        service: my-service
        cluster: my-cluster
        wait-for-service-stability: true
        codedeploy-appspec: appspec.json
        codedeploy-application: my-codedeploy-application
        codedeploy-deployment-group: my-codedeploy-deployment-group

The minimal permissions require access to CodeDeploy:

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"RegisterTaskDefinition",
         "Effect":"Allow",
         "Action":[
            "ecs:RegisterTaskDefinition"
         ],
         "Resource":"*"
      },
      {
         "Sid":"PassRolesInTaskDefinition",
         "Effect":"Allow",
         "Action":[
            "iam:PassRole"
         ],
         "Resource":[
            "arn:aws:iam::<aws_account_id>:role/<task_definition_task_role_name>",
            "arn:aws:iam::<aws_account_id>:role/<task_definition_task_execution_role_name>"
         ]
      },
      {
         "Sid":"DeployService",
         "Effect":"Allow",
         "Action":[
            "ecs:DescribeServices",
            "codedeploy:GetDeploymentGroup",
            "codedeploy:CreateDeployment",
            "codedeploy:GetDeployment",
            "codedeploy:GetDeploymentConfig",
            "codedeploy:RegisterApplicationRevision"
         ],
         "Resource":[
            "arn:aws:ecs:<region>:<aws_account_id>:service/<cluster_name>/<service_name>",
            "arn:aws:codedeploy:<region>:<aws_account_id>:deploymentgroup:<application_name>/<deployment_group_name>",
            "arn:aws:codedeploy:<region>:<aws_account_id>:deploymentconfig:*",
            "arn:aws:codedeploy:<region>:<aws_account_id>:application:<application_name>"
         ]
      }
   ]
}

Troubleshooting

This action emits debug logs to help troubleshoot deployment failures. To see the debug logs, create a secret named ACTIONS_STEP_DEBUG with value true in your repository.

License Summary

This code is made available under the MIT license.

Security Disclosures

If you would like to report a potential security issue in this project, please do not create a GitHub issue. Instead, please follow the instructions here or email AWS security directly.

amazon-ecs-deploy-task-definition's People

Contributors

allisaurus avatar amazingandyyy avatar amazreech avatar andhikamaheva avatar clareliguori avatar dannyrandall avatar dependabot-preview[bot] avatar dependabot[bot] avatar ecs-github-actions-cicd-bot avatar efekarakus avatar egyptianbman avatar jamesiri avatar kollaadithya avatar lmller avatar lou1415926 avatar louisblack avatar omkhegde avatar paragbhingre avatar piradeepk avatar pjaudiomv avatar project0 avatar romankydybets avatar s3cube avatar singhprd avatar trivikr avatar yehudacohen avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

amazon-ecs-deploy-task-definition's Issues

Step fails with "Resource is not in the state servicesStable" but new task is running successfully in ECS

I've defined a aws-actions/amazon-ecs-deploy-task-definition@v1 step on my workflow file, and that step keeps failing:

Run aws-actions/amazon-ecs-deploy-task-definition@v1
  with:
    task-definition: /home/runner/work/_temp/task-definition-31660kV60ttYXRWu.json
    service: my-service-staging
    cluster: my-cluster
    wait-for-service-stability: true
  env:
    AWS_ACCESS_KEY_ID: ***
    AWS_SECRET_ACCESS_KEY: ***
    AWS_DEFAULT_REGION: us-east-2
    AWS_REGION: us-east-2
    JAVA_HOME: /opt/hostedtoolcache/jdk/8.0.242/x64
    JAVA_HOME_8.0.242_x64: /opt/hostedtoolcache/jdk/8.0.242/x64
##[error]Resource is not in the state servicesStable
##[error]Node run failed with exit code 1

The step hangs for a good 5-10 minutes meanwhile, in ECS I can verify that I have 2 tasks in the RUNNING state: the old one and the new one.

After a while, the step fails, but the application is successfully updated in ECS.

It seems that the step times out while waiting for the service to reach a stable state, which is a desired count of 1. But I'm not 100% sure.

Unexpected key 'valueFrom' found in params.containerDefinitions[2].environment[0]

Hello there,

In my "Deploy Amazon ECS task definition" stage, I get this error.

Unexpected key 'valueFrom' found in params.containerDefinitions[2].environment[0]

In my environment set I have this

"environment": [
      {
        "name": "ssm_test",
        "valueFrom": "arn:aws:ssm:us-xxxx-1:0000000000:parameter/test_name_v1"
      }
]

I am using this valueFrom as per reference of AWS Support for Specifying Sensitive Data Using system Manager Parameters Group

Is this action does not support valueFrom? If yes, is there any chance of future feature?

Thanks
Ariful

ECS deployment getting stucked at task-definition stage

Hi guys, I have an application on GitHub about to be pushed to ECs via github actions CI. After the image waps with the docker container then pushes to registry, the next thing is to deploy the task definition but it keeps building and never stops - sometimes it takes up to 30 minutes and still does not deploy

Could anyone advice if this is a bug from Github actions or an issue from my end?

run one-off task (e.g. migrations)

I'm using the render & deploy actions provided by github.com/aws-actions. The only thing missing is an option to run a one-off task after registering the new task definition and before deploying it. This would be useful for executing database migration scripts that the new service version requires.

GitHub action should fail if deployment circuit breaker / rollback is triggered

Problem statement

Right now, this action only waits for service stabilization (without regard to how that happens or what deployment actually becomes stable)

With the new deployment circuit breaker feature, it's possible that a deployment will fail, but the service will eventually become stable when the rollback deployment occurs.

This means that workflows may continue on to subsequent steps, even though the service deployment actually failed

What is the bug/problem behavior?

The GitHub action reports success in the case that the service stabilizes after a rollback is triggered by the circuit breaker

This is present in aws-actions/amazon-ecs-deploy-task-definition@v1

What is the desired/correct behavior

The GitHub action should be considered a failure if the deployment circuit breaker is triggered

Steps to reproduce

  1. Create an ECS service with deployment circuit breaker with rollbacks enabled
  2. Deploy a change with this action that's expected to fail and trigger the circuit breaker
  3. Observe that the action job is successful, despite the deployment failing.

Notes

Possible implementation details

Perhaps the action could, upon stabilization, describe the service and see that the expected task revision is contained in the active deployment.

Workarounds

A possible workaround is to add an additional step in your GitHub actions workflow to check the describe-services API response to see if the circuit breaker was triggered on the deployment and the expected taskDefinition revision (using the task definition ARN output) is present in the active deployment.

Unexpected key 'environmentFiles' : Failed to register task definition in ECS

Using aws-actions/amazon-ecs-deploy-task-definition@v1
I have added environmentFiles in my containerDefinitions of task-definition.json as:

"environmentFiles": [{
    "type": "s3",
    "value": "arn:aws:s3:::ltl-environments/.stg.env"
}],

Getting the following error:

##[error]Failed to register task definition in ECS: There were 5 validation errors:
* UnexpectedParameter: Unexpected key 'environmentFiles' found in params.containerDefinitions[0]
* UnexpectedParameter: Unexpected key 'environmentFiles' found in params.containerDefinitions[2]
* UnexpectedParameter: Unexpected key 'environmentFiles' found in params.containerDefinitions[3]
* UnexpectedParameter: Unexpected key 'environmentFiles' found in params.containerDefinitions[4]
* UnexpectedParameter: Unexpected key 'environmentFiles' found in params.containerDefinitions[5]```

Support waiting for deployment ready state for Blue/Green deployments

I am working on a CI/CD pipeline and I want to gate the Blue/Green deploy process on the results of integration tests against the test listener.

What I would love is for the aws-actions/amazon-ecs-deploy-task-definition action to wait until the CodeDeploy is in a "Ready" state and the listener is available to test. Then I can run Github Action run cypress integration tests against the testing listener and use the aws cli to tell the listener to continue the deployment.

Right now I am replicating this feature the following bash step:

- name: Wait until deployment is "Ready"
    run: | 
        # Try every 15 seconds
        maxRetries=40
        retryInterval=15
        echo "Waiting for the deployment to be ready for testing"
        retry=0
        until [ ${retry} -ge ${maxRetries} ]
        do
            status=`aws deploy get-deployment --deployment-id ${{ steps.ecs-deployment.outputs.codedeploy-deployment-id }} --region us-east-1 | jq '.deploymentInfo.status'`
            echo "::debug::The deployment is currently in the status $status"
            retry=$[${retry}+1]
            echo "::debug::Retrying [${retry}/${maxRetries}] in ${retryInterval}(s) "
            sleep ${retryInterval}
        done

        if [ ${retry} -ge ${maxRetries} ]; then
            echo "::warning::Deployment Ready Check Timed Out after ${maxRetries} attempts"
        fi

While this solves the problem it is a lot of boilerplate code that would need to be replicated or converted into a shared action. It would help if it was a built in feature to the action.

It looks like one problem with adding this in is that the AWSJavaScriptSDK CodeDeploy waiter only supports the deploymentSuccessful state so this would either need to be implemented in the action itself or added to the SDK.

Expected params.forceNewDeployment to be a boolean

Is this issue solved ? i'm still getting that with 1.4.1.

Run aws-actions/[email protected]
  with:
    task-definition: /home/runner/work/_temp/task-definition--435-nD4dXDjs371k-.json
    cluster: ef-stg-cluster
    service: ef-stg-service
    force-new-deployment: true
  env:
    AWS_DEFAULT_REGION: ***
    AWS_REGION: ***
    AWS_ACCESS_KEY_ID: ***
    AWS_SECRET_ACCESS_KEY: ***
Error: Expected params.forceNewDeployment to be a boolean

deploying existing/same version

Is there a way to skip running the step to deploy if the image tag is the same as currently deployed? Currently it looks like it still takes a few minutes to do the deployment even though there are no changes.

The reason for this is i have 2 clusters with approx 15 services. I have 1 deployment repo which will deploy all the services (via a version file which i can update the image tag). However I only want to deploy if the image has changed.

updateTaskSet to deploy schedule task

Hi, I'm trying to use github actions to deploy my change to ECS. Everything is awesome, but right now I can only deploy to ECS service, in my use case I also want to deploy ECS scheduled task.

Just force a new deployment

I don't want to store the task-definition.json in my repo, and the task definition is not changing for a deploy anyway because the tag is stable (production/staging).

It would be great to have an action to just restart the service as per the following command:

ecs update-service --cluster ff_prod --service ff_prod --force-new-deployment

The actions/aws-cli is deprecated, but is it going to be replaced with an action that provides the full power of the cli?

Feature request: add port as an input

Right now, I can change the service at the workflow level because it's listed as an input, but I have to use a different task definition to map a different host port. It would be convenient if I could define that at the workflow level, instead of at the task definition level.

Unable to deploy via Actions: Cannot read property 'name' of null

Trying to use this action in my personal project (private repo so far). YML file is as follows: https://gist.github.com/pvasilyev/ceaf81d6943464bf77ac2a6a0b7602ad

I've verified that my aws user has all permissions listed in the https://github.com/aws-actions/amazon-ecs-deploy-task-definition#permissions but still w/o luck.

Logs excerpt:

Run aws-actions/amazon-ecs-deploy-task-definition@v1
  with:
    task-definition: /home/runner/work/_temp/task-definition-3216nPr47VbD5lae.json
    service: tgbot-webhook-service
    cluster: tgbot-springboot-cluster
    wait-for-service-stability: true
  env:
    AWS_DEFAULT_REGION: us-east-1
    AWS_REGION: us-east-1
    AWS_ACCESS_KEY_ID: ***
    AWS_SECRET_ACCESS_KEY: ***
##[error]Cannot read property 'name' of null

* UnexpectedParameter: Unexpected key <name> errors

Workflow created using suggested AWS actions/starter-workflows

On this step:

    - name: Fill in the new image ID in the Amazon ECS task definition
      id: task-def
      uses: aws-actions/amazon-ecs-render-task-definition@v1
      with:
        task-definition: task-definition.json
        container-name: sample-app
        image: ${{ steps.build-image.outputs.image }}

I replaced the version to the last version

      uses: aws-actions/[email protected]

and I have the task-definition.json file on repository correctly (copied from json tab, this step works fine)

But on the following step, that uses amazon-ecs-deploy-task-definition, I get this error:

 Deploy Amazon ECS task definition0s
##[error]Node run failed with exit code 1
Run aws-actions/[email protected]
##[error]There were 5 validation errors:
* UnexpectedParameter: Unexpected key 'compatibilities' found in params
* UnexpectedParameter: Unexpected key 'taskDefinitionArn' found in params
* UnexpectedParameter: Unexpected key 'requiresAttributes' found in params
* UnexpectedParameter: Unexpected key 'revision' found in params
* UnexpectedParameter: Unexpected key 'status' found in params
##[error]Node run failed with exit code 1

This template uses ubuntu-latest, so I tried to update the awscli at the beginning

    steps:
    - name: Update
      run: |
        pip install wheel
        pip install --upgrade awscli

Got successfully executed:

Successfully installed awscli-1.17.0

But the error persists.

Cannot read property 'length' of undefined

Somewhere deep in this action there is a reference crash: https://github.com/webaverse/preview-backend/runs/2389708359?check_suite_focus=true

I'm not sure how to debug it other than forking this repo. Pointers would be appreciated.

Run aws-actions/amazon-ecs-deploy-task-definition@v1
  with:
    task-definition: /home/runner/work/_temp/task-definition--2103-koap3hNmf5z6-.json
    service: sample-app-service
    cluster: default
    wait-for-service-stability: true
  env:
    AWS_DEFAULT_REGION: us-west-1
    AWS_REGION: us-west-1
    AWS_ACCESS_KEY_ID: ***
    AWS_SECRET_ACCESS_KEY: ***
Error: Cannot read property 'length' of undefined

DockerTimeoutError: ECS Task definition run on EC2 Windows cluster

Receiving STOPPED (DockerTimeoutError: Could not tranisition to started; timed out after waiting 8m0s) error while running an ECS Task definition on an EC2 Windows + Networking cluster. I couldn't find any aws documentation for this error for EC2 Windows cluster.

I am not sure if this is the right forum for me to submit this issue, but I had tried several things and I kind of reached a dead-end on this, hence posting it here as a last resort. Could you please help with a resolution on this.

Question : For a Service running with multiple tasks inside different instances

When we have multiple instances and more than 1 tasks with ECS Classic Configuration.
The Actions are unable to deploy to propagate the tasks to all the instances and trying to deploy all the tasks in one container.
which results in the error "already using a port required by your task." and "was unable to place a task because no container instance met all of its requirements"

Do we have any fix for this scenario?

Deploy taking incredibly long suddenly.

How can I troubleshoot why the deploy is taking incredibly long all of a sudden?

my task definition


{
  "ipcMode": null,
  "executionRoleArn": "arn:aws:iam::185944984862:role/ecsTaskExecutionRole",
  "containerDefinitions": [
    {
      "dnsSearchDomains": null,
      "environmentFiles": null,
      "logConfiguration": {
        "logDriver": "awslogs",
        "secretOptions": null,
        "options": {
          "awslogs-group": "/ecs/identity-backend",
          "awslogs-region": "eu-west-2",
          "awslogs-stream-prefix": "ecs"
        }
      },
      "entryPoint": null,
      "portMappings": [
        {
          "hostPort": 3001,
          "protocol": "tcp",
          "containerPort": 3001
        }
      ],
      "command": null,
      "linuxParameters": null,
      "cpu": 1024,
      "environment": [],
      "resourceRequirements": null,
      "ulimits": null,
      "dnsServers": null,
      "mountPoints": [],
      "workingDirectory": null,
      "secrets": [
        {
          "valueFrom": "xxx",
          "name": "IoTBackend-Staging"
        }
      ],
      "dockerSecurityOptions": null,
      "memory": null,
      "memoryReservation": null,
      "volumesFrom": [],
      "stopTimeout": null,
      "image": "185944984862.dkr.ecr.eu-west-2.amazonaws.com/identity:4f177c4240adda5b3bf8f5f83f7b766e490e2775",
      "startTimeout": null,
      "firelensConfiguration": null,
      "dependsOn": null,
      "disableNetworking": null,
      "interactive": null,
      "healthCheck": null,
      "essential": true,
      "links": null,
      "hostname": null,
      "extraHosts": null,
      "pseudoTerminal": null,
      "user": null,
      "readonlyRootFilesystem": null,
      "dockerLabels": null,
      "systemControls": null,
      "privileged": null,
      "name": "identity-backend"
    }
  ],
  "placementConstraints": [],
  "memory": "2048",
  "taskRoleArn": "arn:aws:iam::185944984862:role/ecsTaskExecutionRole",
  "compatibilities": [
    "EC2",
    "FARGATE"
  ],
  "taskDefinitionArn": "arn:aws:ecs:eu-west-2:185944984862:task-definition/identity-backend:3",
  "family": "identity-backend",
  "requiresAttributes": [
    {
      "targetId": null,
      "targetType": null,
      "value": null,
      "name": "com.amazonaws.ecs.capability.logging-driver.awslogs"
    },
    {
      "targetId": null,
      "targetType": null,
      "value": null,
      "name": "ecs.capability.execution-role-awslogs"
    },
    {
      "targetId": null,
      "targetType": null,
      "value": null,
      "name": "com.amazonaws.ecs.capability.ecr-auth"
    },
    {
      "targetId": null,
      "targetType": null,
      "value": null,
      "name": "com.amazonaws.ecs.capability.docker-remote-api.1.19"
    },
    {
      "targetId": null,
      "targetType": null,
      "value": null,
      "name": "ecs.capability.secrets.asm.environment-variables"
    },
    {
      "targetId": null,
      "targetType": null,
      "value": null,
      "name": "com.amazonaws.ecs.capability.task-iam-role"
    },
    {
      "targetId": null,
      "targetType": null,
      "value": null,
      "name": "ecs.capability.execution-role-ecr-pull"
    },
    {
      "targetId": null,
      "targetType": null,
      "value": null,
      "name": "com.amazonaws.ecs.capability.docker-remote-api.1.18"
    },
    {
      "targetId": null,
      "targetType": null,
      "value": null,
      "name": "ecs.capability.task-eni"
    }
  ],
  "pidMode": null,
  "requiresCompatibilities": [
    "FARGATE"
  ],
  "networkMode": "awsvpc",
  "cpu": "1024",
  "revision": 3,
  "status": "ACTIVE",
  "inferenceAccelerators": null,
  "proxyConfiguration": null,
  "volumes": []
}

unable to prepare context: unable to evaluate symlinks in Dockerfile path

I was just following along with the tutorial here:
https://aws.amazon.com/blogs/opensource/github-actions-aws-fargate/

I seem to be running into an error on the build tag and push step, everything before is working. I have not pushed a new container image to ECR before so it could be something I don't understand about how that works but it appears the dockerfile does not exist?

image

console output for this step:

 # Build a docker container and
  # Build a docker container and
  # push it to ECR so that it can
  # be deployed to ECS.
  docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
  docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
  echo "::set-output name=image::$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG"
  shell: /bin/bash -e {0}
  env:
    AWS_ACCESS_KEY_ID: ***
    AWS_SECRET_ACCESS_KEY: ***
    AWS_DEFAULT_REGION: us-east-1
    AWS_REGION: us-east-1
    ECR_REGISTRY: ***.dkr.ecr.us-east-1.amazonaws.com
    ECR_REPOSITORY: my-ecr-repo
    IMAGE_TAG: 0653508e9470c725335afc5a5c61667211fe9cc8
unable to prepare context: unable to evaluate symlinks in Dockerfile path: lstat /home/runner/work/FargateActionDemo/FargateActionDemo/Dockerfile: no such file or directory
##[error]Process completed with exit code 1.

Question: Multiple container definitions

What would be the way to write yaml for multiple container definitions in one single taskdef ?
Taskdef.json

{
  ...,
  containerDefinitions:[
    {
      image: 'image1'
    },
    {
      image: 'image2'
    }
  ]
}
    - name: Fill in the new image ID in the Amazon ECS task definition
      id: task-def
      uses: aws-actions/amazon-ecs-render-task-definition@v1
      with:
        task-definition: Taskdef.json
        container-name: my-container
        image: ${{ steps.build-image.outputs.image }}

Container Definition Environment variables are being removed when empty

Problem statement

This action is removing environment variables with empty values inside the container definition.

What is the bug/problem behavior?

When deploying a new task definition version, the deployment process is removing container definition Environment variables which have empty values, causing the deploy to potentially fail due to the missing Environment variables.

This is present in aws-actions/amazon-ecs-deploy-task-definition@v1

What is the desired/correct behavior

Environment variables inside the container definition should remain unmodified.

Steps to reproduce

  • Create a dummy ECS service with a set of environment variables, and leave one empty.
  • Deploy a task definition with this action
  • New deployed task definition is missing the environment variable that is empty.

Notes

I tested this with the render task definition action and downloading the task definition with the cli using the describe-task-defintion command and I can confirm that just before the task definition is deployed, the Environment variables with empty values are still in the task definition json file.

Possible implementation details

Perhaps checking that the resulting task definition has the critical user provided settings unchanged (things like cpu, mem, Environment variables, volumes mapping, etc)

Workarounds

We need to manually add back the missing environment variable which will make our service stay in an inconsistent state while the missing environment variable is added.

Fargate deployment not working anymore as expected

Hello Guys,

We have been using this Github action for a couple of weeks now, and everything was good.
Since a few days, we are having issues deploying.

We have to manually delete the according running task from AWS ECS console for the job to succeed. Otherwise, deploy get stuck for minutes until an error spawns about a timeout and service stability.

Screenshot 2020-05-04 at 16 00 25

Is there something we have missed out during configuration?

We currently have 4 clusters:

  • Develop
  • Demo
  • Staging
  • Production

Each cluster run the 3 same tasks & use the same task-definition.json -> can it be the issue?

Thanks in advance

Ability to use ENV variables in definition

When you try to add an environmental variable in image or cluster you get the following error
Cluster must match ^[a-zA-Z0-9\-_]{1,255}$, but was $CLUSTER_NAME

Assuming you have the following workflow:

name: Some deployment workflow
on:
  push:
    branches:
      - master

env:
  CLUSTER_NAME: MyClusterName
  ECR_REGISTRY: ecr_registry
  REPO_ONE: repo_one
  REPO_TWO: repo_two
  IMAGE_TAG: sometag
jobs:
  deploy_task:
    name: Deploy The Task
    runs-on: ubuntu-latest
    steps:
      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: <key>
          aws-secret-access-key: <secret>
          aws-region: <region>

      - name: Login to AWS ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v1

      - name: Download Task Definition
        run: |
          aws ecs describe-task-definition \
          --task-definition <task-def-name> \
          --query taskDefinition > task-definition.json

      - name: Change image 1
        uses: aws-actions/amazon-ecs-render-task-definition@v1
        id: ch-task-def
        with:
          task-definition: task-definition.json
          container-name: <container-name>
          image: $ECR_REPOSITORY/$REPO_ONE:$IMAGE_TAG # This will fail with the message described in issue #49 

      - name: Deploy Task
        uses: aws-actions/amazon-ecs-deploy-task-definition@v1
        with:
          task-definition: ${{ steps.ch-task-def.outputs.task-definition }}
          service: <service-name>
          cluster: $CLUSTER_NAME # This will fail too with the message "Cluster must match ^[a-zA-Z0-9\-_]{1,255}$, but was $CLUSTER_NAME"

As you see in the code block comment, image: will throw the message described in #49 and cluster: the message already posted initially from me.
This happens when you use env variables

ps: This is issue was moved to the correct repository. @paragbhingre

Configuring the AppSpec.yaml during action?

I'm somewhat confused as to how to update the appspec.yaml file during the GH action since the task definition is continuously updated (is there a way to stop registering tasks if nothing changes? I just switched the IMAGE_TAG of the build image portion to "latest" instead of making newer images.).

For me, when using CodeDeploy in console and manually inputting my appspec file' contents, it was always rejected for some kind of parsing error when using * or simply omitting the account ID and such.

I've resorted to a full arn with an appspec file like this:

version: 0.0

Resources:
  - TargetService:
      Type: AWS::ECS::Service
      Properties:
        TaskDefinition: "arn:aws:ecs:us-region:0000000:task-definition/application-stack:6"
        LoadBalancerInfo:
          ContainerName: "nginx"
          ContainerPort: 80

But my issue is that last portion: the ":6". Whenever I replace it with *, it doesn't work. Whenever I have an arn that omits the region name or account ID, CodeDeploy errors saying the arn can't be parsed.

arn:aws:ecs:::task-definition/application-stack:*

(Any of those replacements in any combination would not work).

So I wonder what the typical appspec.yaml or just a complete repo with GH action integration would look like. And do task definitions incur charges??? I'm just mighty confused as no one online answer my AWS questions.

Multiple CodeDeploys/Environments

This action is what I've been looking for!

However, it is possible this can be extended to work with a strategy for deploying multiple apps from a singular deployment repo and/or work with the same app (same image) that would deploy to multiple environments in AWS.

If this is no applicable, is there any guidance for the intended usage beyond a simple and singular deployment?

Thanks!

Private repository credentials are not a supported authentication method for ECR repositories.

I am trying to learn more about AWS, and I really liked the idea of creating my own CI/CD pipeline using GithubActions.

I saw this video posted by AWS Events and wanted to do something similar on my own.

I am trying to use the prebuilt workflow to take a simple node.js api and build, tag, push, and deploy it to my AWS EC2 instance.

I feel like I set everything up as instructed, but I keep getting this error when triggering my workflow:

Screen Shot 2020-03-31 at 7 33 00 PM

I wrote down how I created my ECR repo and ECS cluster/task in the readme of my project here.
Here's what my cluster/tasks look like:

Screen Shot 2020-03-31 at 7 46 24 PM

Is there any additional setup I need to do to get this workflow working? Do I need to configure a secret?

Any help is appreciated.

Thanks :)

Cannot read property 'logDriver' of null

My task-definition.json contains containerDefinitions with container definition that has logConfiguration option set to null. I've copied this from JSON task definition from AWS Console so I guess that's valid value. This action doesn't behave like it is.

Stop tasks first then start new task to use full instance resource

In the pass, i used ecs-cli to deploy and via es_params i can config a task using full resource of EC2 instance.
EX: EC2 instance micro: 1GB, then memory on es params config around ~1000MB.

But since I use github workflow, i have to reduce memory to 500MB to make it works. Because always have a running task.
How can i make it 1000MB same with deploy via ecs-cli?

[warning ] Ignoring property 'compatibilities', 'taskDefinitionArn', 'requiresAttributes', 'revision', 'status' in the task definition file

Just noticed the following warnings started coming back (worked before)

 Deploy new ECS task definition
Deployment started. Watch this deployment's progress in the Amazon ECS console: https://console.aws.amazon.com/ecs/home?region=***#/clusters/stage/services/stage-web/events
Run aws-actions/amazon-ecs-deploy-task-definition@v1
##[warning]Ignoring property 'compatibilities' in the task definition file. This property is returned by the Amazon ECS DescribeTaskDefinition API and may be shown in the ECS console, but it is not a valid field when registering a new task definition. This field can be safely removed from your task definition file.
##[warning]Ignoring property 'taskDefinitionArn' in the task definition file. This property is returned by the Amazon ECS DescribeTaskDefinition API and may be shown in the ECS console, but it is not a valid field when registering a new task definition. This field can be safely removed from your task definition file.
##[warning]Ignoring property 'requiresAttributes' in the task definition file. This property is returned by the Amazon ECS DescribeTaskDefinition API and may be shown in the ECS console, but it is not a valid field when registering a new task definition. This field can be safely removed from your task definition file.
##[warning]Ignoring property 'revision' in the task definition file. This property is returned by the Amazon ECS DescribeTaskDefinition API and may be shown in the ECS console, but it is not a valid field when registering a new task definition. This field can be safely removed from your task definition file.
##[warning]Ignoring property 'status' in the task definition file. This property is returned by the Amazon ECS DescribeTaskDefinition API and may be shown in the ECS console, but it is not a valid field when registering a new task definition. This field can be safely removed from your task definition file.
Deployment started. Watch this deployment's progress in the Amazon ECS console: https://console.aws.amazon.com/ecs/home?region=***#/clusters/stage/services/stage-web/events

Here is the relevant config is the Github action .yaml:

   - name: Download current ECS task definition
      run: aws ecs describe-task-definition --task-definition stage-web --query taskDefinition > task-definition.json
    - name: Render new ECS task definition
      id: render-task-definition
      uses: aws-actions/amazon-ecs-render-task-definition@v1
      with:
        task-definition: task-definition.json
        container-name: stage-web
        image: ${{ env.GA_DOCKER_IMAGE }}

Add timeout option

wait-for-services-stable currently only waits 10 minutes, which might not be long enough for all deployments

Any way to use task definition defined by service?

Hi,
is there any way to skip creating task definition and use the one which is configured on the service level in AWS?

So far we used codeship with such configuration:

service: awsdeployment
command: aws ecs update-service --cluster my_cluster --service my_service --force-new-deployment

Thanks!

Expected params.forceNewDeployment to be a boolean

tried using force-new-deployment to true.

And I get error : Error: Expected params.forceNewDeployment to be a boolean

What am I missing? Here's the snippet from my yml

- name: Deploy Amazon ECS task definition
        uses: aws-actions/amazon-ecs-deploy-task-definition@v1
        with:
          task-definition: ${{ steps.task-def.outputs.task-definition }}
          service: some-service
          cluster: Some-cluster
          force-new-deployment: true
          wait-for-service-stability: true

Cannot read property 'type' of null

Followed all steps of the deployment process outlined in the default Github Actions yml. This step always ends in a null pointer exception, and since index.js is so massive, it's hard to debug anything. The error is also only as verbose as the title, no stacktrace, line numbers, anything.

GitHub job times out but task deployment completes successfully

I am running into an issue that causes my job to hang and fail after 10 minutes, however, the task deployment completes successfully. I set the wait-for-service-stability: true as part of the config options which I think may be causing the issue.

Error during deploy:

Run aws-actions/amazon-ecs-deploy-task-definition@v1
##[error]Resource is not in the state servicesStable
##[error]Node run failed with exit code 1

My environment includes the following components:
Private Fargate Service

I would like to use the wait-for-service-stability: true so please let me know if you have suggestions to debug or fix. Thanks

Does not stop an existing task

If I had not noticed this, the action would have waited forever, burning my action credits.

service xxx was unable to place a task because no container instance met all of its requirements. The closest matching container-instance xxx is already using a port required by your task. For more information, see the Troubleshooting section.

Is there a way to kill the existing task that it would be replacing first?

I also manually stopped the task and it deployed out, but the action kept on spinning like it was still waiting for a status update.

Script fails instead of waiting for service to become stable

Previous discussion on this issue in #2

I've got a deployment script that has been successfully deploying my application to ECS. However, this GHA script errors out with the following debug logs:

##[debug]Evaluating condition for step: 'Deploy Amazon ECS task definition'
##[debug]Parsing expression: <success()>
##[debug]Evaluating: success()
##[debug]Evaluating success:
##[debug]=> true
##[debug]Result: true
##[debug]Starting: Deploy Amazon ECS task definition
##[debug]Loading inputs
##[debug]Evaluating: steps.task-def.outputs.task-definition
##[debug]Evaluating Index:
##[debug]..Evaluating Index:
##[debug]....Evaluating Index:
##[debug]......Evaluating steps:
##[debug]......=> Object
##[debug]......Evaluating String:
##[debug]......=> 'task-def'
##[debug]....=> Object
##[debug]....Evaluating String:
##[debug]....=> 'outputs'
##[debug]..=> Object
##[debug]..Evaluating String:
##[debug]..=> 'task-definition'
##[debug]=> '/home/runner/work/_temp/task-definition-27961zBZiXxjdRic.json'
##[debug]Result: '/home/runner/work/_temp/task-definition-27961zBZiXxjdRic.json'
##[debug]Loading env
Run aws-actions/amazon-ecs-deploy-task-definition@v1
  with:
    task-definition: /home/runner/work/_temp/task-definition-27961zBZiXxjdRic.json
    service: ob-service
    cluster: ob-cluster
    wait-for-service-stability: true
  env:
    AWS_ACCESS_KEY_ID: ***
    AWS_SECRET_ACCESS_KEY: ***
    AWS_DEFAULT_REGION: us-west-1
    AWS_REGION: us-west-1
##[debug]Registering the task definition
::set-output name=task-definition-arn,::arn:aws:ecs:us-west-1:***:task-definition/ob-task-definition:4
##[debug]='arn:aws:ecs:us-west-1:***:task-definition/ob-task-definition:4'
##[debug]Updating the service
##[debug]Waiting for the service to become stable
##[error]Resource is not in the state servicesStable
##[error]Node run failed with exit code 1
##[debug]Finishing: Deploy Amazon ECS task definition

I tracked the deployment process, and this is what I found:

  • The script only waits a couple seconds to error out, even with wait-for-service-stability: true
  • The service deployed to is the only service in the cluster, and it's active
  • The service has a single deployment

I took a look at the event logs in the service, and found this too:

2019-11-17 12:43:39 -0800
service ob-service has started 1 tasks: task d0bbf143-4308-4c3f-ac1f-a7fc2b9f7b13.

followed by

2019-11-17 12:44:21 -0800
service ob-service has reached a steady state.

Is there an option to customize the wait time for stability? And if not, what is that timeframe supposed to look like?

Task definition deployment stuck

I'm not sure how to report it but I will try to explain it in detail
I'm Using GitHub action template for AWS ECS deployment.
Everything works fine as long as there is one service definition per cluster.

Enter the problem

I have a multi repo setup where I have defined service and task definitions per one cluster (Service definitions are deployed to ECS).
The first Task definition is deployed with no problems after there's commit to master. The second (different repository) one got stuck and nothing happens (waited at least 10 minutes)

EDIT:
After the second attempt - one service is deployed successfully, and the second deployment timedout after 10 minutes 21s with error ##[error]Resource is not in the state servicesStable

EDIT2:
Solved by following https://aws.amazon.com/premiumsupport/knowledge-center/cloudformation-ecs-service-stabilize/

Auto-assign public IP is disabled

I am using this action as part of the "Deploy to Amazon ECS" template offered by GitHub Actions but the workflow keeps pending at "Deploy Amazon ECS task definition" step.

After inspecting stopped tasks in my cluster I have found the error:

CannotPullContainerError: Error response from daemon: Get https://****.dkr.ecr.eu-west-1.amazonaws.com/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

I can see Public IP: -- under task details, while this article: https://aws.amazon.com/premiumsupport/knowledge-center/ecs-pull-container-api-error-ecr/ recommends setting Auto-assign public IP to ENABLED

Is there a way I can modify this GH action to pass enable public IP parameter?

Error: ProxyConfiguration properties value cannot be null

I'm trying to deploy a service that routes through App Mesh and properties is not null (debug shows the data is there) but I'm getting this error. I tried passing as an object instead of an array and got a different error, that it needs to be an array.

Sending the same json via the cli succeeds so I'm at a loss on what the problem may be.

##[debug]Registering the task definition
Error: Failed to register task definition in ECS: ProxyConfiguration properties value cannot be null.
...
##[debug]    "proxyConfiguration": {
##[debug]        "type": "APPMESH",
##[debug]        "containerName": "envoy",
##[debug]        "properties": [
##[debug]            {
##[debug]                "name": "ProxyIngressPort",
##[debug]                "value": "15000"
##[debug]            },
##[debug]            {
##[debug]                "name": "AppPorts",
##[debug]                "value": "1234"
##[debug]            },
##[debug]            {
##[debug]                "name": "EgressIgnoredIPs",
##[debug]                "value": "169.254.170.2,169.254.169.254"
##[debug]            },
##[debug]            {
##[debug]                "name": "IgnoredGID"
##[debug]            },
##[debug]            {
##[debug]                "name": "EgressIgnoredPorts"
##[debug]            },
##[debug]            {
##[debug]                "name": "IgnoredUID",
##[debug]                "value": "1337"
##[debug]            },
##[debug]            {
##[debug]                "name": "ProxyEgressPort",
##[debug]                "value": "15001"
##[debug]            }
##[debug]        ]
##[debug]    }
##[debug]}
Error: ProxyConfiguration properties value cannot be null.

Way to update image tag in latest task definition without needing to store whole task definition

I would be great if we could simply indicate the new container tag that we want to use without having to store the task definition json.

    - name: Build and Push Image to Amazon ECR
      run: |
        docker build -t ${{ secrets.ECR_REPOSITORY_URL }}:${{ github.sha }} .
        docker push ${{ secrets.ECR_REPOSITORY_URL }}
    - name: Update Amazon ECS service
      uses: aws-actions/amazon-ecs-deploy-task-definition@v1
      with:
        service: my-service
        cluster: my-cluster
        container-image-name-updates: container=my-conatiner,tag=${{ github.sha }}
        wait-for-service-stability: true

Maybe this can be an option in the render-task-definition action instead to pull the latest from aws.

What do you think? It avoids having to add a rogue task_definition.json in the repository that needs to be maintained alongside the running task definition.

Lamba Deployment Addition?

I wasn't sure where to ask a question about the future of https://github.com/aws-actions in general. Are there plans to add more actions to this suite? This CLI project appears to be deprecated, so I am wondering if there will be AWS-official actions added to do things like deploy Lambda zip packages? Or another project to support CLI in general?

Task definition with many different refs, secrets

Hey.

I have a problem with description of the task. I don't understand how it should work, example:

I deploy CloudFormation Stack where we dynamic create names, using refs, secret strings:
(example from our cloudformation template)

TaskDefinition:
    Type: AWS::ECS::TaskDefinition
    Properties:
      Family: !Join
        - '-'
        - - !Ref environment
          - !FindInMap [Cluster, Service, Name]
          - TaskDefinition

For env point

- Name: SOME_NAME
Value: !Join
    - ''
    - - '{{resolve:secretsmanager:'
    - !Ref some_ref
    - '-some_name:SecretString:****}}'

And now we want to use github actions for:

  1. Build the project (ok)
  2. Push into ECR (ok)
  3. Create new Task Definition with a new link of image from ECR (no)
  4. Deploy to ECR (clearly that no)

Point 3 from list: we should create the task-definition.json file as required by aws-actions/amazon-ecs-render-task-definition@v1. But how should we resolve problem with description of envs, names of cluster, container which are created dynamically using refs and secrets to generate right strings?

It is clear that a simple duplication of CloudFormation Template in JSON will not yield

I would be glad if you indicated the right direction to solve this problem.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.