|
1 | | -# EKS Terraform |
| 1 | +## Guidelines & Style Convention Summary |
2 | 2 |
|
3 | | -AWS Resources created: |
| 3 | +- All Terraform configuration should be formatted with `terraform fmt` before being accepted into this repository. |
| 4 | +- This repository is Terraform version >= 0.12, as such, leverage features from this release whenever possible. |
| 5 | + See https://www.terraform.io/upgrade-guides/0-12.html for more information. |
| 6 | +- Leverage community-maintained Terraform modules whenever possible. |
| 7 | +- Attempt to minimize duplication whenever possible, but only within reason -- sometimes duplication is an acceptable solution. |
| 8 | +- Follow style conventions described in `docs/guide.pdf` whenever possible. |
| 9 | +- Whenever possible, inject resources down versus referencing resources across modules. This has been made easier with new features in v0.12. |
| 10 | +- Whenever possible, define the types of variables. |
4 | 11 |
|
5 | | -- EKS Cluster: AWS managed Kubernetes cluster of master servers |
6 | | -- AutoScaling Group containing 2 m4.large instances based on the latest EKS Amazon Linux 2 AMI: Operator managed Kubernetes worker nodes for running Kubernetes service deployments |
7 | | -- Associated VPC, Internet Gateway, Security Groups, and Subnets: Operator managed networking resources for the EKS Cluster and worker node instances |
8 | | -- Associated IAM Roles and Policies: Operator managed access resources for EKS and worker node instances |
| 12 | +### Module Conventions |
9 | 13 |
|
10 | | -## Pre-requisites |
| 14 | +- All modules should contain the following: |
11 | 15 |
|
12 | | -- Setup the [AWS credentials](https://www.terraform.io/docs/providers/aws/index.html#environment-variables) for terraform |
| 16 | + `README.md`: A description of the module. |
| 17 | + `main.tf`: Module entrypoint where instantiation of resources happens. |
| 18 | + `variables.tf`: Module variables. |
| 19 | + `outputs.tf`: Output values (optional). |
| 20 | + `files/`: Any / all files required by the module. |
13 | 21 |
|
14 | | -## Spin up cluster |
| 22 | +- All module variables must have a description. |
| 23 | +- Again, leverage community-maintained Terraform modules whenever possible. |
| 24 | +- Avoid writing a module that is simply a wrapper of a Terraform resource unless absolutely necessary. |
15 | 25 |
|
16 | | -```shell |
| 26 | +### Environment Conventions |
17 | 27 |
|
18 | | -terraform plan |
19 | | -terraform apply |
| 28 | +- All environments should contain the following: |
| 29 | + |
| 30 | + `main.tf`: Toplevel terraform configuration file that instantiates the `environment` module. |
| 31 | + |
| 32 | +- Configuration should be pushed "top->down" from the `environment` module to it's submodules. |
| 33 | + |
| 34 | +### The Environment Module |
| 35 | + |
| 36 | +- The `environment` module can be considered the top-level module, all other modules are imported from this module. |
| 37 | +- Environment-specific variables should be exposed via the `variables.tf` file in this module, where they will be set from within the appropriate environment in the `environments/` directory. |
| 38 | +- The `environment` module contains the following: |
| 39 | + |
| 40 | + `main.tf`: Module entrypoint where instantiation of resources happens. |
| 41 | + `backend.tf`: Terraform remote state configuration. |
| 42 | + `provider.tf`: Provider configuration. |
| 43 | + `variables.tf`: Environment-specific variables are desclared here. |
| 44 | + `versions.tf`: Terraform version information. |
| 45 | + `files/`: (DEPRECATED) |
| 46 | + |
| 47 | +## Directory Structure |
20 | 48 |
|
21 | 49 | ``` |
| 50 | + README.md |
| 51 | + environments/ |
| 52 | + production/ |
| 53 | + main.tf |
| 54 | + staging/ |
| 55 | + main.tf |
| 56 | + development/ |
| 57 | + main.tf |
| 58 | + docs/ |
| 59 | + guide.pdf |
| 60 | + modules/ |
| 61 | + environment/ |
| 62 | + ... |
| 63 | + <module-a>/ |
| 64 | + files/ |
| 65 | + scripts/ |
| 66 | + main.tf |
| 67 | + outputs.tf |
| 68 | + variables.tf |
| 69 | + <module-n>/ |
| 70 | + ... |
| 71 | +``` |
| 72 | + |
| 73 | +## AWS Guidelines |
| 74 | + |
| 75 | +- TODO: Identity/Access Management (IAM) Guidelines |
| 76 | + |
| 77 | +## Kubernetes Guidelines |
| 78 | + |
| 79 | +- When to use the Terraform Kuberenetes Provider and when to use manifests? |
| 80 | + |
| 81 | + - Use the Terraform Kubernetes Provider (`provider "kubernetes"`) whenever you are provisioning a resource that could be considered relatively static (think Ingress, RoleBinding, CluterRoleBinding, etc). |
| 82 | + |
| 83 | + - Use conventional Kubernetes manifests / `kubectl` when provisioning resouirces that could be considered dynamic (think Deployments). |
| 84 | + |
| 85 | +## Application |
| 86 | + |
| 87 | + 1. Set up a profile for your project with your credentials in a specific profile in `~/.aws/credentials` and then export the following env var: |
| 88 | + `export AWS_PROFILE=<project_name>` |
22 | 89 |
|
23 | | -### Connect to cluster |
24 | | -The EKS service does not provide a cluster-level API parameter or resource to automatically configure the underlying Kubernetes cluster to allow worker nodes to join the cluster via AWS IAM role authentication. |
| 90 | + 2. Run the following from the appropriate environment directory under `environments/`: |
25 | 91 |
|
26 | | -- Run `aws eks update-kubeconfig --name staging` to configure `kubectl` |
27 | | -- Run `terraform output config_map_aws_auth` and save the configuration into a file, e.g. config_map_aws_auth.yaml |
28 | | -- Run `kubectl apply -f config_map_aws_auth.yaml` |
29 | | -- You can verify the worker nodes are joining the cluster via: `kubectl get nodes --watch` |
| 92 | + ``` |
| 93 | + environment/development$ terraform init |
| 94 | + environment/development$ terraform plan |
| 95 | + ``` |
0 commit comments