We were not able to get the terraform module to wo...
# fleet
b
We were not able to get the terraform module to work (the way it was written) and ended up overhauling and want to bring it back to the product. Before we shoot a PR, can someone who worked on it hit me up for some q&a?
l
Hi Brandon!, feel free to write the questions here, I will send the team the link to this thread.
b
First one, was the intent to not make this a module that could be brought in directly to a terraform repo?
My other team mate is joining shortly and can add his thoughts
We are looking to publish a blog post on this and would love to collaborate @Rhys Davies
b
Hey we decide early on that we didn't want to make it a module because we wanted users to be able to bootstrap from scratch. We figured if you were savvy enough for modules, extracting the core concepts MySQL, Redis, and Fleet Service would be easy enough to tweak for your specific needs.
👍 1
r
Makes sense, yeah that’s what we ended up doing, removing the route53.tf and a few other things so we could plumb it into our VPC and networking
b
lol very fair and makes sense. Would you want a module contributed back to the repo or leave as is?
b
Contributing back would be awesome but I'd suggest you add it to a new directory somewhere in infrastructure dir called module.
👍 1
That way they can live side by side
Or we could even self adopt the module to bootstrap the rest of the reference arch.
r
we also nicely solved the problem of having to manually run the migration task separately by using ECS’
dependsOn
functionality, now our version runs migrations, waits for success then boots up fleet
b
Dogfood it if you will 😅
I believe dependsOn simply means that the container needs to be running, not that it has run and exited. One starts and then the dependent container starts. That doesn't exactly solve the problem we are trying to solve. We recommend that in large deployments there are no fleet instances running while the migrations are applied. With your solution I believe it's possible for the fleet web service to start before migrations have finished. Just something to keep in mind.
r
There’s a difference between the CloudFormation depends on and a containerDependency which you can define like this: https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDependency.html
with this object you can wait for a container to complete and exit 0, effectively.
so you can make the DB migrations happen first, also make that container not essential so it can exit without taking down the task
b
Yeah COMPLETE condition. Cool
r
its confusing because Cloudformation uses the same naming for things
r
There is a good chance that this will be turned into a module as part of future work as well, but it hasn't been done yet, so maybe there is some overlap here.
r
we’re gonna put together a branch and I’ll link it here when it’s ready to PR
👍 3