...
Open an entry in the Platform AWS Log. It is helpful to think though exactly what you are going to do and write it down. Then as you execute the change, if you deviate from the steps you wrote in the log, change the log. In the end when you haven't made any mistakes and everything has gone smoothly you will think this was a waste of time. It wasn't. The closer you are to a big demo the more true this will be.
Crowd (skip if using existing crowd deployment)
In most cases you should be re-using existing Crowd instances. We currently have two crowd servers running:
prod: https://dev-crowd.sagebase.org:8443/crowd/console
staging + test (shared): https://prod-crowd.sagebase.org:8443/crowd/console
If setting up a new Crowd server or for help troubleshooting see: Setting Up Production Crowd
If you just need to point a stack at a particular crowd instance, you do this by setting the org.sagebionetworks.crowd.endpoint in the stack.properties file (URLs as above minus the /crowd/console bit)
...
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:
...
See the page on Repository Administration for instructions on how to backup and restore data from Synapse schemas. To migrate data from one instance to another in a stack the current procedure is to take a back up of the old stack, shut the stack down, and then copy the data to the new stack. Note there is a small risk of data changed in the old stack being lost if somebody adds something to the repository after the backup process has completed. This will be addressed by PLFM-404 404 . (Even if you shut down the Synapse web portal before you take the backup, changes can still come in via the repo API, which must be up to take the backup.) In meantime, workaround by communicating with team members and our small user base.
...
Once you have CNAMES pointed to the new stack, update stackInstance-stack.properties file, upload to S3, and restart the app servers to apply the change. Having our components talk to each other via the public aliases avoids security exceptions. See PLFM-506 506 .
Deploy From Artifactory
Create an IAM credentials file, using the platform credentials, per http://stackoverflow.com/questions/5396932/why-are-no-amazon-s3-authentication-handlers-ready
...
In trunk\tools\SynapseDeployer\main.py
set the following
- version = '0.8' # set to the actual version to be deployed
- isSnapshot = True
- beanstalk_application_name =
set to 'Synapse-Staging' for staging, 'Synapse' for Synapse
- componentsToUpgrade: set to the target stack, e.g. 'prod-b-auth' for stack 'b' of alpha/prod
- make sure deploymentBucket=elasticbeanstalk-us-east-1-325565585839
Run the python deployment scriptIn the directory trunk\tools\SynapseDeployer, start the python interpreter, then type:
| Code Block |
|---|
import sys
sys.path.append("boto-2.1.1")
import main
|
...
You can find the code for this script here clinicalVariableDescriptionsLoader.py
How to run the Data Loader (Deprecated)
We should be migrating data and maintaining it between version upgrades now.
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
...
...
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.