Terraform-aws-eks: Worker AMI ID is always the latest. Should be possible to pin it to a version

[max-rocket-internet]

Currently the LC of worker groups will be automatically updated with new AMIs when they are released by AWS: https://github.com/terraform-aws-modules/terraform-aws-eks/blob/master/data.tf#L24

This is great most of the time but sometimes we don't want this to be done automatically when terraform is run. For example when we want to be double sure the new AMI is stable in a test environment.

I proposed we add a new variable, e.g. ami_version_filter, that defaults to v*. This could be optionally set to a release from amazon-eks-ami, e.g. v20190220, to pin the version.

Any thoughts or objections?

[dpiddockcmp]

You can achieve this pinning by setting ami_id in var.workers_group_defaults or var.worker_groups[*]

I don't know if the module needs more complexity when there is already a way to achieve the result

[max-rocket-internet]

Yes but this problem with that is that you need to look up the AMI ID and it's different for every region. It's also impossible to know what version the AMI ID is for at a glance.

[max-rocket-internet]

I don't know if the module needs more complexity when there is already a way to achieve the result

You could be right here. My assumption is that 95% of people are using the AWS AMI and therefore this change makes sense. But if it's considerably less than that then this change would be needless complexity...

[skang0601]

I'd very much would support this feature, we just had some issues last Friday with one of our cluster breaking due to a new AMI release.

[diversario]

I've pinned mine like so:

  worker_template_defaults = {
    subnets = "${join(",", module.vpc.private_subnets)}"
    ami_id  = "${coalesce(var.ami_id, lookup(local.region_to_ami_id, var.region))}"
  ...

  # Available k8s 1.11 AMIs per region. This is to avoid accidental upgrade.
  # Not all regions support EKS
  # Source: https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html
  region_to_ami_id = {
    "us-west-2"      = "ami-0c28139856aaf9c3b"
    "us-east-1"      = "ami-0eeeef929db40543c"
    "us-east-2"      = "ami-0484545fe7d3da96f"
    "eu-central-1"   = "ami-032ed5525d4df2de3"
    "eu-north-1"     = "ami-0154b2479ba20f8bb"
    "eu-west-1"      = "ami-098fb7e9b507904e7"
    "eu-west-2"      = "ami-0d69ab00cb41d6eda"
    "eu-west-3"      = "ami-018ebb030cf6ae00b"
    "ap-northeast-1" = "ami-07fdc9272ce5b0ce5"
    "ap-northeast-2" = "ami-091e0e1906e653417"
    "ap-south-1"     = "ami-0b6f791fc54125a8a"
    "ap-southeast-1" = "ami-038d55c26bf01998f"
    "ap-southeast-2" = "ami-0e07b5081bb77d540"
  }

Clunky but works.

[max-rocket-internet]

Clunky but works.

Exactly. With my idea we can just pin based on the Github release from AWS and not have to worry about AMI ID and region etc.

[dpiddockcmp]

Having now seen a working example, I change my mind. I like Max's idea.

[max-rocket-internet]

PR: https://github.com/terraform-aws-modules/terraform-aws-eks/pull/296

Please have a look 🙂

[brandonjbjelland]

This is great! A complex module is difficult to manage and understand but I think the alternative of forcing consumers to accrue their own complexity as a cost of not doing it here (see @diversario 's solution), is a worse outcome.

Merged in your work @max-rocket-internet . Closing this out. Thanks for the input, All.

[leonmax]

why not just have ami_id? I need EKS-opitmized-ami with GPU support which can't be matched with the filter.

[max-rocket-internet]

why not just have ami_id?

You can: https://github.com/terraform-aws-modules/terraform-aws-eks/blob/master/workers.tf#L42

[leonmax]

Thanks, I've seen your comment in the other issue.

[gregswift]

FWIW we had to do this in 2 places to prevent breaking(?) runs.

Simplified for brevity sake:

local {
  workers_group_defaults = [
    {
      ami_id                                   = "ami-0200e65a38edfb7e1"
    }
  ]

  worker_groups_launch_template = [
    {
      ami_id                                   = "ami-0200e65a38edfb7e1"
    },
  ]
}

module "eks" {
  worker_groups_launch_template        = "${local.worker_groups_launch_template}"
  workers_group_defaults               = "${local.workers_group_defaults}"
}

The filter map is still a good idea, just wasnt needed for this example.