terraform-aws-tfstate-backend
terraform-aws-elastic-beanstalk-environment
terraform-aws-tfstate-backend | terraform-aws-elastic-beanstalk-environment | |
---|---|---|
1 | 1 | |
382 | 299 | |
1.0% | 0.7% | |
6.3 | 5.3 | |
7 days ago | 6 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-tfstate-backend
-
Infrastructure as Code with terraform for multiple environments
This can be done manually in the AWS Console or by using a terraform module, such as cloudposse/terraform-aws-tfstate-backend.
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.
What are some alternatives?
terraform-aws-dms - Terraform module to create AWS DMS (Database Migration Service) resources πΊπ¦
terraform-aws-dynamic-subnets - Terraform module for public and private subnets provisioning in existing VPC
terraform-cost-estimation - Anonymized, secure, and free Terraform cost estimation based on Terraform plan (0.12+) or Terraform state (any version)
terraform-aws-elastic-beanstal
infrastructure-modules - Terraform modules for infrastructure
terraform-aws-ec2-instance - Terraform module for provisioning a general purpose EC2 host
terraform-multienv - A template for maintaining a multiple environments infrastructure with Terraform. This template includes a CI/CD process, that applies the infrastructure in an AWS account.
terraform-aws-sns-lambda-notify-slack - Terraform module to provision a lambda function that subscribes to SNS and notifies to Slack.
terraform-kubestack - Kubestack is a framework for Kubernetes platform engineering teams to define the entire cloud native stack in one Terraform code base and continuously evolve the platform safely through GitOps.
sidekiq - Sidekiq worker on Render
terraform-aws-ecs-container-definition - Terraform module to generate well-formed JSON documents (container definitions) that are passed to the aws_ecs_task_definition Terraform resource
terraform-aws-jenkins - Terraform module to build Docker image with Jenkins, save it to an ECR repo, and deploy to Elastic Beanstalk running Docker stack