Infrastructure Setup

1. Terraform

cd infra
cp terraform.tfvars.example terraform.tfvars  # fill in your values
terraform init
terraform apply

2. SSH Key

terraform output -raw ssh_private_key > everytab-key && chmod 600 everytab-key
terraform output ssh_command  # prints the ssh command

3. Bootstrap EC2

scp -i everytab-key ec2-userdata.sh ec2-user@<IP>:~
ssh -i everytab-key ec2-user@<IP> 'bash ~/ec2-userdata.sh'

4. Clone Repo on EC2

git clone <your-repo-url> ~/everytab
cd ~/everytab

5. Database Setup

On the EC2 instance:

# Add to .bashrc (get the URL from: terraform output -raw database_url)
echo "export DATABASE_URL='postgres://everytab:PASS@ENDPOINT:5432/everytab'" >> ~/.bashrc
source ~/.bashrc

# Test connection
psql $DATABASE_URL -c 'SELECT 1;'

# Create schema
psql $DATABASE_URL -f ~/everytab/pipeline/01_cc_index/schema.sql

Pinning the EC2 AMI

The data.aws_ami lookup fetches the latest Amazon Linux 2023 AMI. If Amazon publishes a new one between applies, Terraform will want to replace your EC2 instance.

To prevent this, pin the AMI after initial creation:

# Get the current instance's AMI
aws ec2 describe-instances --filters "Name=tag:Name,Values=everytab" \
  --query "Reservations[0].Instances[0].ImageId" --output text

# Add to terraform.tfvars
echo 'ec2_ami = "ami-XXXXXXXXXXXX"' >> terraform.tfvars

Now terraform apply won't replace the instance for non-EC2 changes (like adding CloudFront logging).

Remove the ec2_ami line from tfvars when you want a fresh instance with the latest AMI (e.g., after teardown).

Teardown (after backup)

Switch to serving-only mode (destroys EC2, RDS, icons bucket):

terraform apply -var="scanning=false"

Full destroy (including the live site):

terraform destroy

1.8 KiB Raw Blame History