terraform-aws-elastic-beanstalk-environment
terraform-aws-dynamic-subnets
terraform-aws-elastic-beanstalk-environment | terraform-aws-dynamic-subnets | |
---|---|---|
1 | 1 | |
299 | 187 | |
0.7% | 1.1% | |
5.3 | 5.4 | |
8 days ago | 9 days ago | |
HCL | HCL | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
terraform-aws-elastic-beanstalk-environment
-
Ask HN: Heroku to Beanstalk?
- If your instance health checks are too stringent, it can become frustrating to try and get your application back in the healthy state. Consider a scenario where your health check page (e.g. /health) pings a non-essential cache database. If your cache database goes offline, EB will treat your application as unhealthy. I recommend keeping the health check page very simple, and setting up separate alarms for other services.
To add to/counteract some points seen in another comment:
Cloudposse has modules that make beanstalk quite manageable with Terraform: https://github.com/cloudposse/terraform-aws-elastic-beanstal...
"Hard to attract talent": I'm skeptical this is an issue in most cases. After all, EB exists so that you don't have to think too much about the infra. For simple use cases, a general understanding of the infra components (not EB-specific) will go a long way. However I can understand talent/developer time could be an issue you're doing something really fancy with EB, such as making heavy use of EB extensions.
"Not the future": This sounds like another way of saying "it's not trendy". Whilst I agree, this point doesn't weigh heavily for me, as I'd try to focus on doing what's right for the application and the team.
terraform-aws-dynamic-subnets
-
Best tips for reducing cloud costs?
I actually mashed together cloudposse/terraform-aws-dynamic-subnets (which has an option to use NAT instances instead of gateways) and joshuamkite/terraform-aws-ssh-bastion-service. That allowed for even cheaper setups where your bastion jump-host (the host you proxy through to get to the private subnets) is also the NAT gateway. I quite liked this setup because the bastion sessions were sufficiently sandboxed in a ephemeral container, and we didn't need twice the number of hosts to have both NAT instances and bastions.
What are some alternatives?
terraform-aws-elastic-beanstal
terraform-aws-tfstate-backend - Terraform module that provision an S3 bucket to store the `terraform.tfstate` file and a DynamoDB table to lock the state file to prevent concurrent modifications and state corruption.
terraform-aws-ec2-instance - Terraform module for provisioning a general purpose EC2 host
terraform-aws-multi-az-subnets - DEPRECATED (use cloudposse/terraform-aws-dynamic-subnets instead): Terraform module for multi-AZ public and private subnets provisioning