multi-env-deploy VS terraform-aws-eks

I have used CodePipeline/CodeBuild, CodeDeploy, and CodeCommit quite a bit. You can see an example of it all working together with Terraform here: https://github.com/cogini/multi-env-deploy

Parameter Store is a good place to store things. ECS can read from it and set variables. This is a complete example of using Terraform to manage infrastructure with EC2 or ECS: https://github.com/cogini/multi-env-deploy Here is an app that runs in ECS: https://github.com/cogini/phoenix_container_example This task file sets env vars based on parameter store: https://github.com/cogini/phoenix_container_example/blob/master/ecs/taskdef.json

AWS has a fine stack for deploying "cloud native" apps on top of EC2 instances.

Build a base AMI using Packer and launch it to an Auto Scaling Group behind a load balancer. Deploy code to the ASG using CodeDeploy. Use RDS for the database.

This is a good match for languages that have good concurrency like Elixir. They benefit from deploying to big machines that have a lot of CPU cores, and keeping a common in-memory cache on the EC2 instance is more efficient than using an external cache like Elasticache. It also works well for resource-hungry systems with poor concurrency like Ruby on Rails. Putting these kinds of apps into big containers is just a waste of money.

Here is a complete example of that architecture using Terraform: https://github.com/cogini/multi-env-deploy

Similarly, bare metal can be really cost-effective. For $115/month, I can get a dedicated server with 24 VCPU cores (2x Intel Hexa-Core Xeon E5-2620 CPU), 64 GB RAM, 4x8 TB SATA, 30 TB traffic (see https://www.leaseweb.com/dedicated-servers#NL). That would be an order of magnitude more expensive on AWS with containers.

Here is how I did it with Terraform: https://github.com/cogini/multi-env-deploy/blob/master/terraform/modules/iam-codepipeline-app/main.tf

The AWS components are managed via Terraform: https://github.com/cogini/multi-env-deploy

A fully featured infrastructure using terraform with terragrunt can be found in this repo: https://github.com/cogini/multi-env-deploy/tree/master/terraform

You might like this full-featured example of using Terraform to set up the infrastructure for an application using EC2 instances in an autoscaling group or ECS containers. https://github.com/cogini/multi-env-deploy

Here is a set of hand-coded modules I wrote that handle deploying real world complex apps to AWS: https://github.com/cogini/multi-env-deploy

cloudposse module was popular but most have moved to https://github.com/terraform-aws-modules/terraform-aws-eks also eks blueprints will be moving to this module. use eks blueprints v5

That's a very simplistic view. Let's do a small thought exercise. Is this module not infrastructure?

I think there is an issue with the module eks : https://github.com/terraform-aws-modules/terraform-aws-eks

module "eks" { source = "terraform-aws-modules/eks/aws" cluster_name = var.cluster_name cluster_version = var.kubernetes_version cluster_endpoint_private_access = true cluster_endpoint_public_access = true cluster_addons = { coredns = { most_recent = true timeouts = { create = "2m" # default 20m. Times out on first launch while being effectively created } } kube-proxy = { most_recent = true } vpc-cni = { most_recent = true } aws-ebs-csi-driver = { most_recent = true } } vpc_id = module.vpc.vpc_id subnet_ids = module.vpc.private_subnets # Self managed node groups will not automatically create the aws-auth configmap so we need to create_aws_auth_configmap = true manage_aws_auth_configmap = true aws_auth_users = var.aws_auth_users enable_irsa = true node_security_group_additional_rules = { ingress_self_all = { description = "Node to node all ports/protocols" protocol = "-1" from_port = 0 to_port = 0 type = "ingress" self = true } egress_all = { # by default, only https urls can be reached from inside the cluster description = "Node all egress" protocol = "-1" from_port = 0 to_port = 0 type = "egress" cidr_blocks = ["0.0.0.0/0"] ipv6_cidr_blocks = ["::/0"] } } self_managed_node_group_defaults = { # enable discovery of autoscaling groups by cluster-autoscaler autoscaling_group_tags = { "k8s.io/cluster-autoscaler/enabled" : true, "k8s.io/cluster-autoscaler/${var.cluster_name}" : "owned", } # from https://github.com/terraform-aws-modules/terraform-aws-eks/issues/2207#issuecomment-1220679414 # to avoid "waiting for a volume to be created, either by external provisioner "ebs.csi.aws.com" or manually created by system administrator" iam_role_additional_policies = { AmazonEBSCSIDriverPolicy = "arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy" } } # possible values : https://github.com/terraform-aws-modules/terraform-aws-eks/blob/master/node_groups.tf self_managed_node_groups = { default_node_group = { create = false } # fulltime-az-a = { # name = "fulltime-az-a" # subnets = [module.vpc.private_subnets[0]] # instance_type = "t3.medium" # desired_size = 1 # bootstrap_extra_args = "--kubelet-extra-args '--node-labels=node.kubernetes.io/lifecycle=normal'" # } spot-az-a = { name = "spot-az-a" subnet_ids = [module.vpc.private_subnets[0]] # only one subnet to simplify PV usage # availability_zones = ["${var.region}a"] # conflict with previous option. TODO try subnet_ids=null at creation (because at modification it fails) desired_size = 2 min_size = 1 max_size = 10 bootstrap_extra_args = "--kubelet-extra-args '--node-labels=node.kubernetes.io/lifecycle=spot'" use_mixed_instances_policy = true mixed_instances_policy = { instances_distribution = { on_demand_base_capacity = 0 on_demand_percentage_above_base_capacity = 0 spot_allocation_strategy = "lowest-price" # "capacity-optimized" described here : https://aws.amazon.com/blogs/compute/introducing-the-capacity-optimized-allocation-strategy-for-amazon-ec2-spot-instances/ } override = [ { instance_type = "t3.xlarge" weighted_capacity = "1" }, { instance_type = "t3a.xlarge" weighted_capacity = "1" }, ] } } } tags = local.tags }

If you want somewhat viable setup - I'd go for terraform-aws-modules (Anton did an awesome job), and aws-ia blueprints, especially those multi-tenant ones.

‏https://github.com/terraform-aws-modules/terraform-aws-eks

I tried using explicit depends_on between my modules but this practise is not recommended since it cause issues during planning.

If you use https://github.com/terraform-aws-modules/terraform-aws-eks it is designed to upgrade the components in the correct order when the cluster version is changed