Skip to content

Latest commit

 

History

History
171 lines (123 loc) · 6.29 KB

README.md

File metadata and controls

171 lines (123 loc) · 6.29 KB

Deployment

AWS Credentials

$ aws configure --profile echo-locator
AWS Access Key ID [None]: <your aws key>
AWS Secret Access Key [None]: <your aws secret>
Default region name [None]: us-east-1
Default output format [None]:

You will be prompted to enter your AWS credentials, along with a default region. These credentials will be used to authenticate calls to the AWS API when using Terraform and the AWS CLI.

Logs

  • LogRocket (Only client, Derek, and Bryan have access) - 1 month retention
  • Rollbar (if an error) - 180 day retention
  • AWS Cloudwatch - Django app - 1 month retention
  • AWS Cloudwatch - a lot of older logs that don't expire, and some logs from Realtor and other processes
  • AWS Builtin Logging - From ECS/RDS, using AWS defaults which is 35 days or less.
  • AWS S3 logs - New django style/Cloudfront - stored indefinitely, but not setup correctly
  • AWS S3 logs - old setup - stored indefinitely, can likely be deleted?

Personally Identifiable Information Collected

We are tracking this for housing searchers only and not for Azavea, BHA or other management accounts.

  • Emails
  • IP addresses (only in logs)
  • Budget for apartment
  • Information that could determine size of family or if person has or is planning to have kids
  • Common places visited. This is user customizable and can include any address.
  • Preferred travel mode (may mirror car ownership)

Most PII is stored in Local Storage, in the RDS database, or both. There is no expiration for Local Storage or database.

No usernames or passwords are stored for the Django version of this app, it uses email driven passwordless logins with 30 day session timeout. Login emails timeout after 1 hour.

Env File

A .env file should exist at the root of the source directory. That must be filled in with mapbox details before running cibuild so that the Django container can access external resources. The bootstrap script tries to get the correct .env for your environment from S3 but otherwise the .env file in S3 is not used.

Publish Container Images

Before we can deploy this project's core infrastructure, we will need to build a container image and publish it somewhere accessible to Amazon's services.

AWS Elastic Container Registry (ECR) is a good candidate because ECR authentication with AWS Elastic Container Service (ECS) is handled transparently.

To do this, we can use the cibuild and cipublish scripts:

$ ./scripts/cibuild
...
Successfully built cc2b35ef78c4
Successfully tagged echolocator:latest
$ export AWS_PROFILE=echo-locator
$ ./scripts/cipublish
...

It defaults to push to export ECHOLOCATOR_ENVIRONMENT="stgdjango". For production export ECHOLOCATOR_ENVIRONMENT=prddjango before cipublish.

Terraform

New Environment

First, we need to make sure there is a terraform.tfvars file in the project settings bucket on S3. The .tfvars file is where we can change specific attributes of the project's infrastructure, not defined in the variables.tf file.

Here is an example terraform.tfvars for this project:

project     = "echo"
environment = "prddjango"
aws_region  = "us-east-1"

r53_private_hosted_zone = "echo.internal"
r53_public_hosted_zone  = "app.echosearch.org"

rds_database_identifier = "echo-prddjango"
rds_database_name       = "echo"
rds_database_username   = "echo"
rds_database_password   =

fargate_app_cpu        = 1024
fargate_app_memory     = 2048
fargate_app_cli_cpu    = 256
fargate_app_cli_memory = 1024

rollbar_access_token =
django_secret_key =

default_from_email = "[email protected]"
aws_s3_photo_bucket="echo-locator-production-site-us-east-1"

There are a few manual steps for a brand new environment

  • Make NS Record with values from sub.domain.org in domain.org.
  • Manually Verify AWS Generated Cert by DNS method.

Current Environment

The following are possible ECHOLOCATOR_SETTINGS_BUCKET values:

export ECHOLOCATOR_SETTINGS_BUCKET=echo-locator-stgdjango-config-us-east-1  # Staging
export ECHOLOCATOR_SETTINGS_BUCKET=echo-locator-prddjango-config-us-east-1  # Production

To deploy this project's core infrastructure, use the infra wrapper script to lookup the remote state of the infrastructure and assemble a plan for work to be done:

$ docker-compose -f docker-compose.ci.yml run --rm terraform
$ export ECHOLOCATOR_SETTINGS_BUCKET line from above.
$ ./scripts/infra plan

Once the plan has been assembled, and you agree with the changes, apply it:

$ ./scripts/infra apply

This will attempt to apply the plan assembled in the previous step using Amazon's APIs.

Migrations

Staging

  1. Ensure you are setup with AWS CLI credentials and have the correct profile set with export AWS_PROFILE=echo-locator
  2. Install the Session Manager plugin for the AWS CLI.
  3. Use the following commands to get the cluster name/task id or use the AWS console to select the most recent running task for the ECS django staging cluster)
$ aws ecs list-clusters
...
......cluster/ecsechostgdjangoCluster
...
$ aws ecs list-tasks  --cluster ecsechostgdjangoCluster
...
......task/ecsechostgdjangoCluster/523612e9652b40dfae4e91e6e157c17b
...
  1. Run the following command:
$ aws ecs execute-command --cluster <name-of-django-staging-cluster> --task <current-task-id> --container django --command "/bin/bash" --interactive
  1. You should see something similar to the following to initiate the start of a session:
The Session Manager plugin was installed successfully. Use the AWS CLI to start a session.


Starting session with SessionId: ecs-execute-command-08e2295045096200d
root@ip-10-0-3-195:/usr/local/src/backend#
  1. Run python manage.py showmigrations
  2. Confirm migrations are up to date.
  3. Run python manage.py migrate
  4. Run exit to exit the session.
  5. Monitor the log output of the current task and confirm staging functions as expected.