wormbase / wormbase-architecture Goto Github PK

This will enable us to version control the CloudFormation JSON template.
See the following for an example of this can be done.

The cloudformation configured Datomic transactor would benefit from enabling cloudwatch metrics.

These metrics are usually written to $DATOMIC_HOME/log/%Y-%m-%d.log.
e.g if events omitted with Alarm.* should be looked at immediately.

This is more useful for the build transactor, since it's more likely to have "interesting" metrics during the import, but as more is done with the website, then it'll probably useful to configure them for the website transactor too.

Requirements for enabling:

• Attaching two policies to the IAM transactor role (either manually in the IAM console for the role or preferably with a cli script).

See section "Using S3 log storage and CloudWatch metrics" about adding the two policies.

Pre-requisites

• Installation of the AWS command line tools
• Configuration of AWS credentials via the command line client, abiding by WormBase AWS policy. (all script usuage of aws client should use --profile ${AWS_USERNAME}) see top comment here

The script should accept the following variables as input, or perhaps read from the environment:

• $release_name (used to name a new dynamodb table and in resource ARNs
• $datomic_license_key_file (path to a file containing the datomic license)
• $datomic_version the datomic version to use for deployment
• $region (optional, default to us-east-1)

Tasks

• Create a role "wb-datomic-transactor" if one does not exist
• Configure the role to support writing transactor log metrics to CloudWatch.
• Create a dynamodb table for the release, named identically as the data release version code.
  e.g: WS255
• If a CloudFormation stack for the datomic transactor does not exist,
  • then:
    Create a cf-stack using a templated properties file via a bash HERE doc (or the like), populating it with the datomic license key.
  • otherwise:
    Create a changeset from an existing template and push via aws cli command.
• Tag the cloud formation resource using the aws cli tool according to WormBase policy.

This feature/script should be split up into multiple smaller scripts that take the appropriate arguments,
such that they can be run in isolation.

Using our own startup.sh would allow us to use cfn-signal to signal stack shutdown,
for compliance with cfn-init tools, as opposed to the current scheme which uses the vanila datomic AMI's approach of running the shutdown command when the tranasctor fails.

Current transactor deployment and autoscaling is not idempotent:

• CF name-service transactor stack parameters DatomicExtClasspathScript and DatomicTransactorDepsScript need to be updated to use a permalink value (e.g. https://raw.githubusercontent.com/WormBase/names/<commit-sha>/scripts/install_transactor_deps.sh instead of https://raw.githubusercontent.com/WormBase/names/master/scripts/install_transactor_deps.sh)
• A branch-URL to download the startup script (which handles datomic transactor startup at CLI level), is hard-coded into the CF template. This should be update to:
  • Get its URL through a stack parameter rather than a hard-coded value
  • Use a permalink URL as parameter value analogous to the stack-parameters described above (uses a non-permanent, hard-coded branch URL atm)
  • When using bin/manage to update/create the transactor, default the CF parameter to use the current git commit at HEAD in the executors working-dir

These changes need to be made to make the CF stack idempotent, in order to prevent new transactors being started with a different configuration compared to the original transactors that were started at the last update of the CF stack.