Deploying Your Cloud Sites

Initial Deployment - hostingStack

run: cdktf deploy hostingStack --auto-approve follow DNS instructions in the TerraformOutput under “rout53HostedZone”. You will see it at the end of the cli output in the terminal when the deployment has successfully complete. (copy the Hosted Zone SN records into your domain name host DNS, if you do not do this the next stack deployment will fail).

** You may get an error regarding S3 ACL permissions Just try to deploy the hosting stack again after a minute or two since deployment timing on AWS can be out of sync.

** If you get an error “from Amazon SES when attempting to send email”, you may have Amazon SES identity status verification pending. This verification may take up to an hour. Check verification status here (verify your region in the url): https://us-west-1.console.aws.amazon.com/ses/home?region=us-west-1#/identities
Before deploying the dataStacks, you need to complete the business profile in the Stripe Dashboard. Otherwise, the terraform commands will not have access to the live site, only the sandbox site and you will get errors. The only way to fix the errors is to cd into the cdktf.out/stacks/{your stack in question} and run these commands to pull, edit the state file directly (remove the json block in question) and push. See: https://developer.hashicorp.com/terraform/cli/commands/state/push
run cdktf deploy dataStackDev --auto-approve --ignore-missing-stack-dependencies
After deployment has completed, populate the following Parameter Store parameters from step 10 using the TerraformOutput displayed in the terminal: The following will be listed under the dataStackDev TerraformOutput: In the terminal, look for dataStackDev Outputs: dataStackDev_CognitoClientId_XXXXXX = “value-to-copy-here” and copy the value to this parameter:
```
/global/parameters/testCognitoClientId = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
```
the value for dataStackDev_IdentityPoolId_XXXXXX goes here:
```
/global/parameters/testIdentityPoolId = "{region-name}:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
```
the value for dataStackDev_UserPoolId_XXXXXX goes here:
```
/global/parameters/testUserPoolId = "{region-name}_xxxxxxxxx"
```

Initial Deployment - dataStacks (dev/live)

run cdktf deploy dataStackDev dataStackLive --auto-approve --ignore-missing-stack-dependencies

Once Deployment is complete, find the stripe api tokens here: https://dashboard.stripe.com/test/apikeys . Toggle Test Mode to “on” to get the dev token and populate the parameters below in Parameter Store:
```
/global/parameters/stripeToken-dev = "sk_test_xxxxxxxxxxxxxxxxxxxxxxxxxxxx"
```
Toggle Test Mode to “off” to get the live token (if you do not have live mode set up yet, you can use the test key here also):
```
/global/parameters/stripeToken-live = "sk_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
```
Goto your stripe webhooks here : https://dashboard.stripe.com/test/webhooks/ click the https://webhookdev.yourdomain and look for the “signing secret” and click “Reveal”. enter that value in the parameter:
```
/global/parameters/stripeWebhookSigningSecret-dev = "whsec_xxxxxxxxxxxxxxxxxxxxxxxxxxxx"
```
if you do not have live mode set up yet, you can use the test key here as well
```
/global/parameters/stripeWebhookSigningSecret-live = "whsec_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
```

Email Verification with AWS SES

You will receive an email sent to the address defined in the config.HostingStack.yaml under the parameters: sesEmailIdentityAddress and sesEmailIdentityDomain. These values need to be an email address that is accessable so that you can click the link in that email to verify the email identity. This can be an email from a different domain (eg: eg@gmail.com). Look for the email subjkect line: Amazon Web Services – Email Address Verification Request
You can now request to SES production access to AWS here. This will allow you to send emails to any email address.

Initial Deployment - webStacks (dev/blue/green)

run cdktf deploy webStackDev --auto-approve --ignore-missing-stack-dependencies
run cdktf deploy webStackBlue webStackGreen --auto-approve --ignore-missing-stack-dependencies
run cdktf deploy blueGreenToggleStack --auto-approve --ignore-missing-stack-dependencies
if you toggle your blue/green stack, just running: cdktf deploy blueGreenToggleStack --auto-approve --ignore-missing-stack-dependencies may give you cross-stack-output errors, so just deploy the stack you are toggling to (eg: if blue then deploy webStackBlue first) and it will update the cross-stack-output data and then NOT throw an error.

Possible Deployment Issues

Running the installation commands above reduce fatal errors related to service start up timing. Sometimes a service depends on another and it may not be ready yet. If an error does occur, simply wait a few minutes and run the command again and it should work. Most errors have been reported in the cdktf github repo. Below is a list of known errors:

hostingStack: SES Error: Error setting MAIL FROM domain: InvalidParameterValue: Identity <identity_here> does not exist. SES identity is still creating, wait a minute and run the deploy command again,=.
blue/green/devStack: AWS/ACM Error: error creating Appsync Domain Name: BadRequestException: Certificate is invalid Certificate is waiting to be issued. Wait a few minutes ant deploy again.
blue/green/devStack,finalizationStack: Appsync Error: error creating Appsync Domain Name API Association: NotFoundException: Domain name not found. Appsync Custom Domain Name is still creating. Wait 5 or so minutes and try again.

Post Deployment setup requirements

“Request SES Production Access” from your SES Account Dashboard Page and/or add any test email addresses to the “verified identities” page. (see app/tests/user_test.go for updating email addresses to verified email addresses). Otherwise addAdminUser and addStandardUser unit tests will fail

Multiple deployments

within main.ts you can see how multiple deployments can be created with seperate config files for each. This is useful for setting up development/production environments. It is defaulted to the “Blue/Green” developlent strategy, but symply changing the config yaml file names and variable names you can achieve essentially any development/production environment strategy.