AWS service can't start task, but starting task manually works

Question

Until now I had a backend running single tasks. I now want to switch to services starting my tasks. For two of the tasks I need direct access to them so I tried using ServiceConnect.

When I run this task standalone it starts. When I start a service without ServiceConnect with the same task inside it also starts. When I enable ServiceConnect I get this error message inside of the 'Deployments and events' tab in the service:

service (...) was unable to place a task because no container instance met all of its requirements. 
The closest matching container-instance (...) is missing an attribute required by your task. 
For more information, see the Troubleshooting section of the Amazon ECS Developer Guide.

When I check the attributes of all free containers with: ecs-cli check-attributes --task-def some-task-definition --container-instances... --cluster some-cluster I just get:

Container Instance  Missing Attributes
heyvie-backend-dev  None

My task definition looks like that:

{
  "family": "some-task-definition",
  "taskRoleArn": "arn:aws:iam::...:role/ecsTaskExecutionRole",
  "executionRoleArn": "arn:aws:iam::...:role/ecsTaskExecutionRole",
  "networkMode": "awsvpc",
  "cpu": "1024",
  "memory": "982",
  "containerDefinitions": [
    {
      "name": "...",
      "image": "...",
      "essential": true,
      "healthCheck": {
        "command": ["..."],
        "startPeriod": 20,
        "retries": 3
      },
      "portMappings": [
        {
          "name": "somePortName",
          "containerPort": 4321
        }
      ],
      "mountPoints": [
        {
          "sourceVolume": "...",
          "containerPath": "..."
        }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "...",
          "awslogs-region": "eu-...",
          "awslogs-stream-prefix": "..."
        }
      }
    }
  ],
  "volumes": [
    {
      "name": "...",
      "efsVolumeConfiguration": {
        "fileSystemId": "...",
        "rootDirectory": "/",
        "transitEncryption": "ENABLED"
      }
    }
  ],
  "requiresCompatibilities": ["EC2"]
}

My service definition looks like that:

{
  "cluster": "some-cluster",
  "serviceName": "...",
  "taskDefinition": "some-task-definition",
  "desiredCount": 1,
  "launchType": "EC2",
  "deploymentConfiguration": {
    "maximumPercent": 100,
    "minimumHealthyPercent": 0
  },
  "placementConstraints": [
    {
      "type": "distinctInstance"
    }
  ],
  "networkConfiguration": {
    "awsvpcConfiguration": {
      "subnets": [
        ...
      ],
      "securityGroups": ["..."],
      "assignPublicIp": "DISABLED"
    }
  },
  "serviceConnectConfiguration": {
    "enabled": true,
    "namespace": "someNamespace",
    "services": [
      {
        "portName": "somePortName",
        "clientAliases": [
          {
            "port": 4321
          }
        ]
      }
    ]
  },
  "schedulingStrategy": "REPLICA",
  "enableECSManagedTags": true,
  "propagateTags": "SERVICE"
}

I also added this to the user data of my launch template:

#!/bin/bash
cat <<'EOF' >> /etc/ecs/ecs.config
ECS_ENABLE_TASK_IAM_ROLE=true
ECS_CLUSTER=some-cluster
EOF

Did anyone experience something similiar or does know what could cause that issue?

Answer 1

I used ServiceDiscovery, I think, it's the easiest way to replace a dynamic ip address of a task in a service (on every restart the ip address changes and that's probably what you're trying to avoid?).

With ServiceDiscovery you are creating a new DNS record and instead of ip-address:port you can just use serviceNameOfNamespace.namespace. to connect to a task. ServiceDiscovery worked without any problem on an existing task.

Hope that helps, I don't really know if there are any benefits for ServiceConnect except for higher connection counts and retry functionalities, so if anybody knows more about differences between those I'm happy to learn.