Production Deployment

Deploying Tibanna requires a few environment variables, including:

  • AWS_ACCESS_KEY_ID and SECRET + SESSION_TOKEN (if using Okta)
  • ACCOUNT_NUMBER
  • S3_ENCRYPT_KEY
  • S3_ENCRYPT_KEY_ID (if deploying to an encrypted environment)
  • GLOBAL_ENV_BUCKET
  • TIBANNA_VERSION

You must also have an existing network (VPC) with subnets to target and a security group to associate with Tibanna. Tibanna takes these arguments directly from the command line. Note that if using a Sentieon license server you may need to add some rules to the default application security group.

4dn-dcic

Deploy Tibanna to the main account with:

  • Your AWS_ACCESS_KEY_ID/SECRET with appropriate permissions
  • ACCOUNT_NUMBER=643366669028
  • S3_ENCRYPT_KEY=<key from environment GAC you are deploying>
  • S3_ENCRYPT_KEY_ID unset since Fourfront is not encrypted
  • GLOBAL_ENV_BUCKET=foursight-prod-envs
  • TIBANNA_VERSION=<version of Tibanna to use in the lambdas, e.g. 2.1.0>
  • -e <env_name>, for valid names see s3://foursight-prod-envs/main.ecosystem, typically “data” or “fourfront-webdev”
  • –subnets subnet-006dce98b4b349b90 (C4NetworkMain Public Subnet A)
  • -r sg-04b9d1a18fd086f33 (C4NetworkMain Application Security Group)

For example: tibanna_4dn deploy_pony -e fourfront-webdev --subnets subnet-006dce98b4b349b90 -r sg-04b9d1a18fd086f33

CGAP Isolated Accounts

Deploy Tibanna to isolated accounts with:

  • Your Okta credentials for the account, ID/Secret/Session Token
  • ACCOUNT_NUMBER=<isolated account number, see envs Confluence page>
  • S3_ENCRYPT_KEY=<key from environment GAC you are deploying>
  • S3_ENCRYPT_KEY_ID=<key ID from environment GAC you are deploying, if applicable>
  • GLOBAL_ENV_BUCKET=<Get this value from the GAC as well>
  • TIBANNA_VERSION=<version of Tibanna to use in the lambdas, e.g. 2.1.0>
  • -e <env_name>, for valid names see main.ecosystem in $GLOBAL_ENV_BUCKET
  • –subnets <subnetA>,<subnetB>
  • -r <application security group>

For example: tibanna_cgap deploy_zebra --subnets subnet-07bac0312de6cff43 subnet-0d4a7670776d7c823 --env cgap-dbmi -r sg-033046050ef0b02c1

Debugging Tips

Tibanna consists of a step function with 4 lambda functions. Each Lambda function has it’s own associated CloudWatch log which can be directly reached from the Lambda console. Typically when an issue occurs the step function will fail and one of the steps will show up as red. First, use tibanna log --job-id <jid> to see if the job failed in execution. If at the end you can see a successful run, or if no log is generated, you will want to investigate the CW logs. First check the Lambda that failed, then follow the traceback to see which Lambda was the source. You may need to navigate timestamps and make use of the search functionality within log groups to find the correct events. Using the job ID as a search query (can be acquired from the input JSON) is usually a quick way to locate the relevant events and timestamps.