Deployed Stacks

We now have the following CNAMEs for Synapse in the sagebase.org domain:

• synapse.sagebase.org – for the demo version of the web app (Sprint 3) -> synapse-sagebase-org.elasticbeanstalk.com
• repositoryservice.sagebase.org – for the demo version of the repo' svcs (Sprint 3) -> repositoryservicea.elasticbeanstalk.com

• synapse-alpha.sagebase.org – for the web app (Sprint 4) -> prod-synapseweb.elasticbeanstalk.com
• reposvc-alpha.sagebase.org – for the repo svcs (Sprint 4) -> prod-reposervice.elasticbeanstalk.com
• auth-alpha.sagebase.org – for the auth svcs (Sprint 4) -> prod-auth.elasticbeanstalk.com

We have two Crowd instances, one for production and one for development/testing:

• crowd-dev.sagebase.org – for the dev/test Crowd instance, the default for our code base (-> elastic IP 50.17.192.58)
• crowd.sagebase.org – for the production Crowd instance, specified in Synpase via a system property, as documented on Synapse Stack Deployment (-> elastic IP 50.17.212.74)

Current Beanstalk Resources LAST UPDATED: 20Jun2011

Synapse Deployment Instructions

Note that all Synapse resources should be created in US East, as Beanstalk is not yet available everywhere.

Crowd (skip if using existing crowd deployment)

If necessary, the instructions are here:

[http://sagebionetworks.jira.com/wiki/display/PLFM/Setting+Up+Production+Crowd|http://sagebionetworks.jira.com/wiki/display/PLFM/Setting+Up+Production+Crowd]

Restarting Crowd

If the server goes down:

To check if Crowd is up, in web browser go to
[https://crowd.sagebase.org:8443/crowd|https://crowd.sagebase.org:8443/crowd]
You should see Crowd log-in page.  If not then ssh in to crowd.sagebase.org  as ec2-user, using the standard key for 'platform' owned ec2 instances, PlatformKeyPairEast

At the unix prompt:
      ps -a

Should show one java process, if not
      cd /usr/local/atlassian-crowd-2.2.7/

     ./start_crowd.sh

Now verify that the log-in page appears in your web browser.

The above instructions apply to 'crowd-dev.sagebase.org' as well as 'crowd.sagebase.org'.

Get the built artifacts from Artifactory

You should not be deploying anything you built yourself on your local machine.  Only deploy build artifacts generated by Bamboo and stored in Artifactory.  See Branching and Tagging for information about managing the build, branch, and tag process.  You will need 3 .war files out of artifactory for a deployment: services-repository-<version>.war, services-authentication-<version>.war, and portal-<version>.war.  Each must go into its own Beanstalk environment.

Create Beanstalk Environments (Skip this section if using existing Environments.)

log in to AWS

http://aws.amazon.com/console/

as platform@sagebase.org (get the password frome someone in the Platform department).

Click "Launch New Environment"

set environment name, e.g. "Prod-Auth"

choose or upload an "application version" (which is a WAR file)

Default AMI (32 bit Linux server running Tomcat v 7)

Instance type: t1.micro

Key Pair: PlatformKeyPairEast

email: platform@sagebase.org

Create two more, so that there is one for Auth services, one for Repo services, and one for SynapseWeb

Create Host Name

Sign in to GoDaddy, select sagebase.org,  and launch Domain Manager. 

Create synapse-prod (.sagebase.org) and point it to prod-synapseweb.elasticbeanstalk.com

Ditto for auth-prod and reposvc-prod

Create or Configure MySQL RDS Service

If necessary, create a new schema in the AWS RDS, e.g. using MySQL Workbench.

The schema name, for example, might be 'prodRepositoryDb'

Note that we have two different database users that we use to give access to RDS to our services tier: beans-staging for the staging stack and beans-production for the alpha/production stack.  If you create a new schema you must grant all permissions except GRANT_OPTIONS on the new schema to the appropriate user.  Please do not give the platform/root db user to the service tier, it is for admin use only.

Note that all stacks share access to idGeneratorDB, which is a separate schema used to generate unique IDs within the sagebase.org domain.  However, the stack db users should only have INSERT and SELECT access to this schema.

Configure Environments

The configuration of all environments for all Synapse components should be the same, with the exception that we leave port 80 on the web app load balancer open and closed everywhere else.

Configure Server

Click on 'edit configuration' in the Beanstalk UI, start on 'Server' tab:

EC2 Instance Type=t1.micro

EC2 Security Groups=elasticbeanstalk-default

Existing Key Pair=PlatformKeyPairEast

Monitoring Interval=5 minute

Custom AMI ID=ami-524db23b

Configure Load Balancer

Click on 'Load Balancer' tab

For 'HTTP Listener port' choose 'OFF' for the repo and auth services, choose '80' for the portal.

For 'HTTPS Listener port' choose '443'. 

For 'SSL Cert' choose arn:aws:iam::325565585839:server-certificate/SynapseCert

Configure Notifications

Click on 'Notifications' tab

Set Email Address to 'platform@sagebase.org'

Configure Container

Click on 'container.'

In the JVM Command Line Options For a production deployment:

-Dorg.sagebionetworks.stack=alpha 

For a non-production deployment:

-DACCEPT_ALL_CERTS=true -Dorg.sagebionetworks.stack=staging

For all deployments:

AWS_ACCESS_KEY_ID = <<aws access key id>>

AWS_SECRET_KEY = <<aws secret key>>

PARAM1 = <<url to .properties file in S3>>

PARAM2 = <<encryption key>>

This is the minimum information needed to bootstrap our system with the information needed to load a configuration via a .properties file.  Here, the actual .properties file should be loaded in S3 as described below

Setting up a Properties file in S3

For each stack, we have created a unique IAM User, encryption key, and configuration file.  These values are passed into the container of the environments as described above.  AWS access key ids, secret keys, encryption keys, and the url for an environment can be found on sodo at /work/platform/PasswordsAndCredentials/StackCredentials/IAMUsers in the appropriate .csv file.  All stack environments run under this IAM User, and have permission to access their configuration file from S3.  Configuration files can be loaded / updated in S3 under the elasticbeanstalk-us-east-1-325565585839 bucket (this is the same place the .war files are deployed).  This will give URLs of the form https://s3.amazonaws.com/elasticbeanstalk-us-east-1-325565585839/beanstalk-<stack-name>-stack.properties  If you are creating a new stack, you will have to create the IAM user and grant that user access to access the configuration file using the IAM tab of the AWS console.  In most cases you should be able to keep the configuration the file the same, or replace it with a new file of the same name.

Note that if you are setting up a .properties file, any field that is a password should be encryped.  You can encrypt strings by running StringEncrypter, passing in two arg's: (1) the string to be encoded, (2) the aforementioned encryption key.

How to run the Data Loader

Once environments are running, you can populate the system with a set of starting data.  On one of the local servers, goto /work/platform/DatasetMetadataLoader and execute the following:

# Make sure you have the latest version
svn up
# Execute the loader
# Replace <repo_instance> and <auth_instance> by the repository and authentication instances.
# Either make sure that <platform_admin_email> is a Synapse administrator on crowd, or replace it by a Synapse administrator account
python datasetCsvLoader.py -e http://<repo_instance>/repo/v1 
-a http://<auth_instance>/auth/v1  -u <platform_admin_email>  -p <platform_admin_pw>

This will create a publicly-accessible project called Sage BioCuration, and populate it with curated data from Sage's repository data team.

If you need to repopulate the data in S3, pass the -3 argument to the data loader. It upload the data in serial right now so it takes an hour or two. We really should only need to do this if we've messed up our S3 bucket.

Verify Deployment

To verify deployment, run top-level queries against the repository instances from an authenticated account.

Make sure you can download the MSKCC clinical data layer from S3.

TODO: Add queries and expected counts returned.