#airship (2020-03)
Home of Airship ECS Modules ( https://github.com/blinkist/terraform-aws-airship-ecs-service / https://github.com/blinkist/terraform-aws-airship-ecs-cluster )
Archive: https://archive.sweetops.com/airship/
2020-03-02
hey peeps, i’m looking at the ecs module - it looks like it’s not 0.12 compatible, but someone has started work on that
what’s the policy around supporting 0.12? are you going to switch over at some point or maintain two releases?
or NOT
if i make it work for 0.12 will it be merged?
Hi @Jan Szumiec It will be merged, I’m also happy to pair on it, and/or help out. I suggest to have a chat with @Mads Hvelplund as well to see where he left it and to understand what his thoughts are.
all right, from where i sit it looks like all modules need to be migrated to 0.12 - do you know if there’s a tool that’d do the translation? you could maintain two branches with minimum cost for a bit
i reckon most people would be on 0.11, we certainly were at my previous workplace
Let me respond tomorrow, there are some actual developments at the moment.
It looks I have another project with airship it seems.. so this will def. bring it forward.
On 0.12 here and started looking at Mads branch. Currently trying to address the envvars issue.
Still trying to unwind how the map ends up with different type keys as the initial var def just sets type to map and defaults to {}
2020-03-04
2020-03-11
2020-03-12
Hey All, looking at the Full Example documented. Trying to piece together how I can pass in my locals map for env vars.
Is the documentation correct for this example:
# Initial ENV Variables for the ECS Task definition
container_envvars {
TASK_TYPE = "web"
}
or should it be:
container_envvars = { TASK_TYPE = "web" }
When I use it as documented I’m getting:
Error: Argument or block definition required
on compute-ecs.tf line 204, in module "airship_test":
204: container_envvars { local.airship_test_svc.env_vars }
An argument or block definition is required here. To set an argument, use the
equals sign "=" to introduce the argument value.
If I try container_envvars = local.airship_test_svc.env_vars
(the value is a k/v map) I get:
Error: ECS Task Definition container_definitions is invalid: Error decoding JSON: json: cannot unmarshal array into Go struct field ContainerDefinition.Environment of type ecs.KeyValuePair
on .terraform/modules/airship_test/modules/ecs_task_definition/main.tf line 5, in resource "aws_ecs_task_definition" "app":
5: resource "aws_ecs_task_definition" "app" {
hm nevermind, it appears I get the json: cannot unmarshal array into Go struct field ContainerDefinition.Environment
error even if I don’t specify envvars. This is probably part of the work to migrate to 0.12
I wish there were better debug tools for TF. console is pretty limited
2020-03-13
2020-03-27
Hi, I’m working on porting to 0.12, and when I try to run the example from here https://airship.tf/getting_started/airship.html I get this error when trying to start the task:
ClientException: hostname is not supported on container when networkMode=awsvpc.
any idea?
Flexible Terraform templates help setting up your Docker Orchestration platform, resources 100% supported by Amazon
maybe you can post me your containerdefintion code
Flexible Terraform templates help setting up your Docker Orchestration platform, resources 100% supported by Amazon
Adding @discourse_forum bot
@discourse_forum has joined the channel
2020-03-28
2020-03-30
Hi, I’ve also ported a fair chunk of this to 0.12, building off of what @Mads Hvelplund and @maarten started. I’ve got it working for my use cases, although I haven’t tested things like load balancers and scheduled tasks. Sounds like there are a few 0.12 efforts going, but I’d be happy to open up a PR or something if this would make for a useful starting point. https://github.com/Genomenon/terraform-aws-airship-ecs-service/tree/terraform12
Very cool Clayton, I’m diving in it tomorrow. For another customer I was splitting the lookup lambda and will put the scheduled task in a different module. This would help to not have 40 lambda’s when we have 20 services. PR is good, but we can also go through it first a bit, whatever you like.
Sounds good! I didn’t see your earlier commit a01717b for that right away, so some of my 0.12 work wound up being redundant with that. I think I’ll rebase my branch and try to include all of your commit so it’s got the load balancer stuff too.