FID on EKS using Terraform
Amazon Elastic Kubernetes service is a managed Kubernetes service provided by AWS. EKS is a certified Kubernetes Conformant, so existing applications that run in Kubernetes are compatible with EKS. Amazon EKS automatically manages the availability and scalability of the Kubernetes control plane nodes and also provides advantages like performance, scaling, reliability and, availability Integration with other AWS services like networking, security, IAM and, VPC is also supported making EKS suitable for cloud applications and services.
Learn more about EKS here
Terraform is an open-source infrastructure as code software tool that provides a consistent CLI workflow to manage hundreds of cloud services. Terraform codifies cloud APIs into declarative configuration files. Terraform must be installed, refer to documentation for more details.
- Terraform (terraform CLI)
- AWS CLI configured
- Machine with kubectl installed
- Valid FID License (if you do not have a valid license please contact [email protected])
- Helm installed (optional)
Terraform connects to AWS using the configuration details provided (either through a tfvars file or configured in the cli where terraform commands will be run) to deploy the necessary resources in a highly configurable manner
Components that will be created and deployed
- Security Groups
- Worker Nodes
- NAT Gateway
- EKS Cluster
- FID using Helm Charts
NOTE: Navigate to the location where you have either cloned or downloaded the terraform files.
The terraform init command is used to initialize a working directory containing Terraform configuration files. This is the first command that should be run after writing a new Terraform configuration or cloning an existing one from version control. It is safe to run this command multiple times.
terraform init [options]
The terraform validate command validates the configuration files in a directory, referring only to the configuration and not accessing any remote services such as remote state, provider APIs, etc.
Validate the terraform configuration and existing file
terraform validate [options]
The terraform plan command creates an execution plan. By default, creating a plan consists of:
- Reading the current state of any already-existing remote objects to make sure that the Terraform state is up-to-date.
- Comparing the current configuration to the prior state and noting any differences.
- Proposing a set of change actions that should, if applied, make the remote objects match the configuration.
Create the execution file
terraform plan [options]
The terraform apply command executes the actions proposed in a Terraform plan.
The most straightforward way to use terraform apply is to run it without any arguments at all, in which case it will automatically create a new execution plan (as if you had run terraform plan) and then prompt you to approve that plan, before taking the indicated actions.
Another way to use terraform apply is to pass it the filename of a saved plan file you created earlier with terraform plan -out=..., in which case Terraform will apply the changes in the plan without any confirmation prompt. This two-step workflow is primarily intended for when running Terraform in automation
Apply the execution (plan file) file created
terraform apply [options] [plan file]
The terraform destroy command is a convenient way to destroy all remote objects managed by a particular Terraform configuration.
While you will typically not want to destroy long-lived objects in a production environment, Terraform is sometimes used to manage ephemeral infrastructure for development purposes, in which case you can use terraform destroy to conveniently clean up all of those temporary objects once you are finished with your work.
terraform destroy [options]
Name of the namespace that will be created in kubernetes environment
Name of the EKS cluster. Also used as a prefix in names of related resources
Kubernetes version to use for the EKS cluster
Override default values for target groups. See workers_group_defaults_defaults in local.tf for valid keys
A list of subnets to place the EKS cluster and workers within
A list of maps defining worker group configurations to be defined using AWS Launch Configurations. See workers_group_defaults for valid keys
The type of instance to start
Depicts if the instance is a spot instance
Controls if VPC should be created (it affects almost all resources)
Name to be used on all the resources as identifier
The CIDR block for the VPC. Default value is a valid CIDR, but not acceptable by AWS and should be overridden
A list of public subnets inside the VPC
A list of private subnets inside the VPC
Should be true if you want to provision NAT Gateways for each of your private networks
Should be true if you want to provision a single shared NAT Gateway across all of your private networks
Should be true to enable DNS hostnames in the VPC
Should be true to enable only one NAT gateway per availability zone
Additional tags for the public subnets
Additional tags for the private subnets
Name of the application
EKS cluster ID
Endpoint for EKS control plane
Security group ids attached to the cluster control plane
kubectl config as generated by the module
A kubernetes configuration to authenticate to this EKS cluster.
Kubernetes Cluster Name