Create non-default VPC in network layer

[lorenyu]

Ticket

Resolves #152

Changes

• Add network configuration object in project-config mapping network names to network-specific configs
  • Currently the only configurable thing is the name of the database subnet group. Everything else is hardcoded to use defaults
• Add infra/modules/network module that creates a nondefault VPC with a basic default configuration that contains:
  • 3 availability zones
  • 3 public subnets to be used by the load balancer
  • 3 private subnets to be used by the application layer
  • 3 database subnets to be used by the database layer
  • database subnet group containing the database subnets to be used by Amazon RDS Aurora
  • optional NAT gateway configurations
• Modify the network layer (infra/networks/main.tf):
  • Call infra/modules/network to create non-default VPC
  • Add VPC endpoints that are needed for ECS Fargate to be able to fetch ECR images and log to CloudWatch
• Add network_name property to the application environment config (env-config) to map environments to networks
• Modify database and service layers to reference the network given by environment_config.network_name. This is done using the network_name AWS tag. Also reference the appropriate subnets (public and private subnets for the service layer and database subnets for the database layer) by using the network_name and network_type tags.
• Modify infra/modules/service to accept two lists of subnets rather than one, a list of public subnets for the load balancer and a list of private subnets for the service
• Add egress rule from service to VPC endpoints

Context for reviewers

It turns out we needed nondefault VPC sooner than realized so this is a bit of a rushed implementation of nondefault VPC that follows the WIP VPC tech spec.

Notably, in the default implementation we added a single NAT Gateway which is needed by ECS Fargate to start up the ECS task. It might be possible to achieve this without a NAT Gateway but that will take additional investigation.

Testing

In order to not break dev, I did everything in a new staging environment since staging didn't exist. I followed these steps for testing:

1. I configured and created the network

   make infra-configure-network NETWORK_NAME=staging
   make infra-update-network NETWORK_NAME=staging
   

2. I deployed the database layer for the staging environment

   make infra-update-app-database APP_NAME=app ENVIRONMENT=staging
   

3. I ran the role manager to provision the database roles and ran the role checker as well

   make infra-update-app-database-roles APP_NAME=app ENVIRONMENT=staging
   

   

   make infra-check-app-database-roles APP_NAME=app ENVIRONMENT=staging
   

   

4. I pushed the branch and ran the build-and-publish workflow.
   See workflow run

5. I ran the deploy workflow from this branch, which runs migrations and deploys to the service layer
   See workflow run

6. I hit an endpoint that touches the database to see that it works: http://app-staging-701758158.us-east-1.elb.amazonaws.com/migrations

Note: I temporarily turned off CI Infra Service since that's destined to fail since the service layer no longer points to the default VPC

[lorenyu]

Done in navapbc/template-infra#496