Issue #1 suggested that the right way to go about architecting this infrastructure was to use a Terraform module to provision an EKS cluster. This was done in #6, but it's unclear if this module structure was a good idea. In particular, because some of the steps to set up the infrastructure require the use of the kubernetes Terraform provider, and configuring that provider relies on the output of the EKS module, which creates a circular dependency when using the infrastructure module as currently set up, but not when the same code is inlined (for some idiosyncratic Terraform reason, no doubt), I had to separate the core into the 0-hardware and 1-services stages, rather than simply offer a core stage. This hasn't been and continues not to be a particularly big deal, but configuring IRSA for some core add-ons (notably EBS CSI, as introduced in #17 / #18) is now split across stages—the add-on is installed in 0-hardware and the IRSA role is attached in 1-services. This has a smell, and I think the better way might be to inline the infrastructure module code, and merge the two core deployment stages.
Issue #1 suggested that the right way to go about architecting this infrastructure was to use a Terraform module to provision an EKS cluster. This was done in #6, but it's unclear if this module structure was a good idea. In particular, because some of the steps to set up the infrastructure require the use of the
kubernetesTerraform provider, and configuring that provider relies on the output of the EKS module, which creates a circular dependency when using the infrastructure module as currently set up, but not when the same code is inlined (for some idiosyncratic Terraform reason, no doubt), I had to separate the core into the0-hardwareand1-servicesstages, rather than simply offer acorestage. This hasn't been and continues not to be a particularly big deal, but configuring IRSA for some core add-ons (notably EBS CSI, as introduced in #17 / #18) is now split across stages—the add-on is installed in0-hardwareand the IRSA role is attached in1-services. This has a smell, and I think the better way might be to inline theinfrastructuremodule code, and merge the two core deployment stages.