Time to verify the configurations. First up to bat, I had a trailing comma in an array of objects. Shame on me; or possible the parser for not being more lax. Misleading error too: complaining about a ( at the end of the input. JSONLint was helpful here. Provided the actual location of the erro.

Next up: the IAM policy didn’t include the namespace of the actions on the CI worker’s policy. Simplying adding an ecr helped there. Remember to be carefal about your multiline string liteerals boys and girls. I forgot a C in CFG which resulted in another bad error message from AWS. Last error standing: Error decoding JSON: json: cannot unmarshal object into Go value of type []*ecs.KeyValuePair. This is one is on the role for the updater. Not even sure what is going on here.

After some playing around it maybe a problem with the "environment" : { "orc_sqs_intake" : "${aws_sqs_queue.orc-updates-queue.name}" }, line in my json. That is great news and sad news at the same time. At least I konw where the problem is. For some reason I kept seeing Key and ignoring the ecs part. I was totally thinking it had to do with KMS. Sigh. If I had RTFMed the first time then my brain would have picked up on the following structure for the environment key for a container:

{
	"environment" : [
		{ "name" : "some-env-var", "value" : "realy!  why? we already have dictionaries?  I guess for duplicates?" }
	]
}

Following the stream down the path of execution I get InvalidParameterException: A role was passed, but no load balancers were present. next. Unless I’m excersizing my reality filter again this task has no need for a load balancer. boto3 has a similar problem. Looks to be an Amazon AWS error since we actually have a real use case for accessing this resource :-/. Well that throws a horrible wrench in my plan.

So it looks like I maybe able to finish the process after all. Service as a term is so overloaded in the computer space. I can’t even define it, or at least I feel like I can’t. The traditional definition meant a network program which opens a port and listens. It’s risen in programming parlance to mean some sort of unit which is tied the encapsulating component’s life time. For the purposes of ECS a service is something load balancable. Fair enough. A task is what I’m actually looking for here.

Anyway, I think I found a way to launch a service. Or rather, I’ve set the variable and the task failed to assume the role, so step in the correct direction anyway. task_role_arn key of your aws_ecs_task_definition should make it work. Terraform will create the instance however the ECS service fails to start the container because it doesn’t have permission. Looks like the root of my problem is the ECS servers themselves can’t attach this policy to themselves. Don’t believe this guy AWS is a valid principal either. Maybe he was right. Unforunately the parser keeps rejecting the role for the AWS IAM Role I am trying to specify. The ansewr? Turns out the person was probably correct.

ECS runs under the service name ecs-tasks.amazonaws.com. Was it documented some where? Yes it was. Although it escapes me what one would use to search for this little snippet of information. Most of the documentation out there doesn’t seem to directly reference the AWS documentation. I guess I need to level up my AWS knowledge.

Logging

Now that I have the ECS system spinning up the application it’s now time to get the logging on-line. Perhaps this is the next stpe because the contianer immediately exits. The manual claims this should be fairly straight forward. Let’s see if this holds up. Actually fairly painless.

        "logConfiguration" : {
                "logDriver" : "awslogs",
                "options" : {
                        "awslogs-group" : "${aws_cloudwatch_log_group.orc-updater-logs.name}",
                        "awslogs-region" : "${var.aws_region}"
                }
        }

The next exciting chapter

From here I’ve got most of the components in place. The next step is to begin on containizering the applications for development purprose.