Implementing in AWS

Setup and implementation is performed using Terraform, Helm, and AWS. Terraform is used to manage and provision infrastructure for the application. Helm is used to deploy and configure the component services.

Requirements

The following should be installed on your system for setup:

• AWS CLI
• Terraform
• GCLOUD CLI
• Prefect Provided GCP Service Account
• Helm
• kubectl

For specific details on a component, review the links below.

• ALB
• EKS
• Redis
• RDS
• Subnets
• Security Groups
• IAM Roles and Policies

Setup

Setting up Terraform Service Account

An account with sufficient administrative permissions is required to provision Terraform infrastructure. As VPC resources like NAT Gateways and subnets are created / destroyed, this should either be a designated service account, or an administrative user.

Authenticating AWS Profile

Configure your terminal session for the appropriate user via aws configure sso.

Due to a limitation of the terraform cli, do not set a SSO Session Name.

# Statically set your AWS Profile for all future commands
export AWS_PROFILE=<profile>

# or prepend for each command
AWS_PROFILE=<profile> terraform init

# Verify profile access
aws list-groups --profile <profile>

Terraform Deployment Overview

Terraform is the primary tool in which the Infrastructure for Self Managed Prefect will be created, updated, and destroyed.
Self Managed Prefect customers will be sent example Terraform modules to deploy the environment.
Note that this is a suggested baseline required to deploy the application, however, is not developed, designed, or intended to meet every requirement you might have in a production environment.

The first phase configures and provisions the state-storage bucket that will be used to configure and store all future terraform state. The second phase provisions and deploys all the necessary Prefect infrastructure, and stores the state to the bucket provisioned in the first phase.

These top level modules include, the following:

• A terraform file named terraform-state-storage.tf that can be used to build a S3 backend and DynamoDB table for terraform state storage.
• A terraform file named data.tf which will reference that generated state backend.
• A terraform file named main.tf used to build all necessary modules for Self Managed Prefect down to the VPC level.
• A terraform file named variables.tf with all passable variables used by the downstream Terraform modules, found in main.tf
• A versions file used to set up the kubernetes and aws related providers

For ease of deployment and re-deployment, update the supplied .auto.tfvars file based on the intended configuration.

Name	Description
Account ID	AWS Account ID
DB Instance Name	Name of Desired RDS / Aurora Instance
DB Subnet Group Name	Name of Desired RDS / Aurora Subnet
State Storage Bucket	Name of Desired S3 Bucket for Terraform State
VPC CIDR	The VPC Network to Deploy into
Subnet Prefix	AWS Account ID
Capacity Type	Type of Node to Deploy

An example of a configured .auto.tfvars is below:

capacity_type        = "ON_DEMAND"
account_id           = "12345678911"
db_instance_name     = "nebula-db"
db_subnet_group_name = "nebula-db-net"
state-storage-bucket = "acme-corp-state-bucket"
subnet_prefix        = "10.20"
vpc_cidr             = "10.20.0.0/16"

New Network Configuration

When deploying a new network for Self Managed Prefect set the following variables:

• var.vpc_cidr used to set the cidr block for the network
• var.subnet_prefix i.e 10.3 - should be equal to the first two numbers of var.vpc_cidr

Bring Your Own Network Configuration

When bringing your own network for usage, set the following variables:

• var.create_network to false
• var.subnet_ids These will be the subnets used to deploy all infra into (DB, EKS Cluster, Redis)
• var.vpc_id
• var.vpc_cidr
• var.vpc_name

Deploying

Running Terraform

Before running Terraform, ensure you have authenticated your AWS profile.

export AWS_PROFILE=<AWS ACCOUNT>

Once verified, ensure that .auto.tfvars for the Terraform modules have been provided and updated.

Setting Up Remote Terraform State

The Terraform state will be saved to the configured state-storage-bucket for future commands to modify / provision / de-provision infrastructure.

From the provided terraform-state directory, build the required resources used to store the state file and lock file. Variables should be appropriately set in variables.tf or in .auto.tfvars, and profile set in provider.tf.

terraform init
terraform plan
terraform apply -var-file="auto.tfvars"

Deploying the Self Managed Prefect Infrastructure

With the Remote Terraform State deployed, the remaining Terraform will be provisioned out of the infrastructure folder. Update data.tf file backend to reference the newly created s3 and dynamodb tables from the previous step. Ensure all .auto.tfvars have been set, then proceed:

terraform init
terraform plan
terraform apply -var-file="auto.tfvars"

Verify the deployment as run as expected and resources have been created. If Terraform throws an error, verify all needed variables have been provided and ensure proper authentication has been established. terraform apply may just need to be run again in case of a failure mid-deployment.

Connecting to EKS Cluster

Retrieve the newly configured cluster credentials to facilitate kubectl and helm commands.

# Retrieve the Config
aws eks update-kubeconfig --profile <aws profile> \
  --kubeconfig ~/.kube/<file name> --name <k8s cluster> \
  --region <region> --verbose

# Export your KUBECONFIG
export KUBECONFIG=~/.kube/<file name>

# Verify connectivity
kubectl get nodes

Deploying Prefect Services

The final step is to deploy the Prefect services which is done through Helm. Navigate to Prefect on the sidebar for instructions to install Prefect into the cluster.