-
Notifications
You must be signed in to change notification settings - Fork 37
Creating staging instances on Amazon
Adam Hooper edited this page Dec 7, 2015
·
61 revisions
To save costs, we don't keep our staging system online all the time. Instead, we make it reasonable to be able to spin it up through scripts.
It's a one-liner.
./script/launch-conglomerate.sh staging
And test away, at https://staging.overviewdocs.com
Run script/staging-stop.sh
.
This will terminate all staging instances and associated volumes.
Hehe. There are a few.
- You must be in the latest checkout of
aws-overview-tools
. - You need to set some environment variables:
AWS_ACCESS_KEY_ID
,AWS_SECRET_ACCESS_KEY
,AWS_KEYPAIR_NAME
,AWS_DEFAULT_REGION
andOVERVIEW_MANAGE_HOST
. You should have a script somewhere that sets all five, and you should source it whenever you're about to interact with Overview. - The
manage
andlogstash
instances must exist. - There must be snapshots called
[database] Daily backup
and[searchindex] Daily backup
. - There must be the security group
staging-conglomerate
. - There must be secrets in the
overview-staging-secrets
S3 bucket, and thestaging-conglomerate
role must be able to read them. - There must be a
staging.zip
in theoverview-builds
S3 bucket. (Useoverview-manage publish
to create it.)
- The cookie domain is different. We don't have any cookies on
overviewdocs.com
: we only have them onwww.overviewdocs.com
andstaging.overviewdocs.com
. That ensures no overlaps. - API keys to external services (Google Analytics, Intercom) are different.
- Production uses the "official"
production-database
andproduction-searchindex
volumes. Staging loads their latest snapshots. - Production reads
production.zip
and Staging readsstaging.zip
from theoverview-builds
S3 bucket.
- Our users' sensitive data is on the
database-staging
instance. If that database is hacked, we expose real data.
Shut down the staging
environment when it isn't in use with script/staging-stop.sh