Blueprints for EKS cluster and workers

[mromaszewicz]

Simple blueprints to create an EKS cluster, and to create workers in an AutoScalngGroup which connect to that master.

[phobologic]

Hey @mromaszewicz - I did a quick run through this to update it to use some of the concepts we've been pulling into newer blueprints (things like properties for variables, using Sub) and removed the Mapping. Let me know what you think.

[mromaszewicz]

Looks good overall. I had the mapping so that the instance userdata that the stack created was the same as Amazon's CFN script for EKS workers.

I just checked - you can indeed launch a Cluster without a Name, and AWS assigns a random name - the name must be there. I think the stack should permit specifying the Name, at least optionally via argument, because downstream from the cluster, lots of things depend on the Name, not the Cluster ID or ARN. For example, creating the role which allows workers to join the cluster is one, but that's no biggie, you can use that as a reference from the stack. However, when you create your own kubeconfig, it would be nice to have a cluster named something like "prod-Cluster", instead of "Cluster-EKS1234567". I've got four clusters, and without meaningful names, it gets messy.

[phobologic]

So the allure of naming things is really dangerous - it's bitten me in the past a ton of times, so much so that I really think the benefits are not worth it.

You'll find that not using naming isn't all that difficult in the long run - the clusters aren't named totally randomly, they'll be named based on: <namespace>-<stack_name>-<resource_name><random>, so you'll find it's pretty easy to tell which is which.

Honestly, it's just the extension of the old "treat your servers like cattle, not pets" philosophy. I think in the public stacker_blueprints repo I want to avoid dangerous settings - so I think I'd prefer to keep the Name out of this (which we've done in most newer Blueprints, since it is so dangerous).

re: The mapping - the userdata, on the box, should end up the same. It'll just look different in cloudformation (it'll have a single value, rather than a map that you then have to go lookup). I've found with stacker (and other cloudformation tools) that it's actually worth getting away from some of the old cloudformation constructs (Parameters, for example), since they aren't actually used as they were intended (ie: meant to be filled in manually so you can re-use a cloudformation template - stacker doesn't need that, since it can already re-use the template via it's blueprints).

[phobologic]

BTW, an example of not using naming - at my new company, we setup ECS clusters with this. With these settings:

namespace: modsy-dev
stack_name: wrc-cluster
resource: Cluster

And our name ended up being: modsy-dev-wrc-cluster-Cluster-1IRSA68PZZ08K