You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+133-8Lines changed: 133 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,14 +1,17 @@
1
1
2
2
# AWS CDK app
3
3
4
-
AWS CDK app for deploying Agora.
4
+
A Github template using the AWS CDK to create an ECS infrastructure project for deploying Agora.
5
5
6
6
# Prerequisites
7
7
8
8
AWS CDK projects require some bootstrapping before synthesis or deployment.
9
9
Please review the [bootstapping documentation](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html#getting_started_bootstrap)
10
10
before development.
11
11
12
+
> [!Note]
13
+
> Sage IT deploys this CDK bootstrap upon creation of every AWS account in our AWS Organization.
14
+
12
15
# Dev Container
13
16
14
17
This repository provides a [dev container](https://containers.dev/) that includes all the tools
@@ -80,7 +83,12 @@ Please install pre-commit, once installed the file validations will
80
83
automatically run on every commit. Alternatively you can manually
81
84
execute the validations by running `pre-commit run --all-files`.
82
85
83
-
Create a [GitHub classic PAT](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic) with `read:packages` access, then create a .env file using .env.example as a template.
86
+
Create a [GitHub classic personal access token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic) with `read:packages` access. The token is used to authenticate with the GitHub API and access the packages endpoint to look up the latest image version for each service. Create an `.env` file with the following variables:
87
+
88
+
```
89
+
GITHUB_TOKEN="your-token-here"
90
+
ENV="dev"
91
+
```
84
92
85
93
Verify CDK to Cloudformation conversion by running [cdk synth]:
86
94
@@ -99,7 +107,7 @@ python -m pytest tests/ -s -v
99
107
```
100
108
101
109
102
-
# Environments
110
+
##Environments
103
111
104
112
An `ENV` environment variable must be set when running the `cdk` command tell the
105
113
CDK which environment's variables to use when synthesising or deploying the stacks.
@@ -110,7 +118,7 @@ Set environment variables for each environment in the [app.py](./app.py) file:
(You would also replace `DnTDevAccount` with the name of the account in which the application is deployed.)
225
+
226
+
> [!NOTE]
227
+
> Setting up the DNS cname should be done at the very end of this infra setup
228
+
229
+
230
+
## Debugging
231
+
232
+
Generally CDK deployments will create cloudformation events during a CDK deploy.
233
+
The events can be viewed in the AWS console under the cloudformation service page.
234
+
Viewing those events will help with errors during a deployment. Below are cases
235
+
where it might be difficult to debug due to misleading or insufficient error
236
+
messages from AWS
237
+
238
+
### Missing Secrets
239
+
240
+
Each new environment (dev/staging/prod/etc..) may require adding secrets. If a
241
+
secret is not created for the environment you may get an error with the following
242
+
stack trace..
243
+
```
244
+
Resource handler returned message: "Error occurred during operation 'ECS Deployment Circuit Breaker was triggered'." (RequestToken: d180e115-ba94-d8a2-acf9-abe17a3aaed9, HandlerErrorCode: GeneralServiceException)
245
+
new BaseService (/private/var/folders/qr/ztb40vmn2pncyh8jpsgfnrt40000gp/T/jsii-kernel-4PEWmj/node_modules/aws-cdk-lib/aws-ecs/lib/base/base-service.js:1:3583)
246
+
\_ new FargateService (/private/var/folders/qr/ztb40vmn2pncyh8jpsgfnrt40000gp/T/jsii-kernel-4PEWmj/node_modules/aws-cdk-lib/aws-ecs/lib/fargate/fargate-service.js:1:967)
247
+
\_ new ApplicationLoadBalancedFargateService (/private/var/folders/qr/ztb40vmn2pncyh8jpsgfnrt40000gp/T/jsii-kernel-4PEWmj/node_modules/aws-cdk-lib/aws-ecs-patterns/lib/fargate/application-load-balanced-fargate-service.js:1:2300)
The source code for the application lives in the [sage-monorepo](https://github.com/Sage-Bionetworks/sage-monorepo). When a new git tag is added in the monorepo, images are published to [GHCR](https://github.com/orgs/Sage-Bionetworks/packages?tab=packages&q=agora). These images are deployed with GHA to AWS Fargate using infrastructure code in this repo.
357
+
358
+
### Dev
359
+
360
+
||
361
+
| :---: |
362
+
| Tags on latest image published by sage-monorepo |
363
+
364
+
The development environment was created so that we can redeploy easily. Whenever code in the sage-monorepo is merged after PR was reviewed and all checks approved, a GHA job publishes new images tagged with `edge` and the commit SHA for each service in the stack that changed (e.g. see screenshot of [agora-app package](https://github.com/sage-bionetworks/sage-monorepo/pkgs/container/agora-app) above). The dev infra stack points at the `edge` image tag. So we can rerun the latest `deploy-dev` GHA job to redeploy the latest app code, by looking up the SHA of the most recent image using the `edge` tag and the GitHub API.
365
+
366
+
So, the footer of the dev site will only show the image tag of the `agora-app` package, which in this case is the commit SHA.
367
+
368
+
### Stage/Prod
369
+
370
+
||
371
+
| :---: |
372
+
| git tag on image published by sage-monorepo |
373
+
374
+
Stage and prod environments point at a specific git tag that is manually added. As described below, when a new git tag is manually created for this app in the sage-monorepo, a GHA job publishes new images tagged with that git tag (see screenshot above). Then, the stage or prod environment variavles in the infra repo can be updated to point at that tag. When the changes are merged to the `stage` or `prod` branch, a GHA job will run the `deploy-stage` or `deploy-prod` job accordingly, which will deploy the images tagged with the git tag.
375
+
376
+
## Dev Deployment
377
+
378
+
1. When a PR that affects this app is merged to `main` in the sage-monorepo, wait for the [ci job](https://github.com/Sage-Bionetworks/sage-monorepo/actions/workflows/ci.yml) to finish building and publishing images for the affected projects to GHCR.
379
+
2. Rerun the last [deploy-dev job](https://github.com/Sage-Bionetworks-IT/agora-infra-v3/actions/workflows/deploy-dev.yaml) and wait for the job to successfully update dev deployment. Deployment can be monitored in AWS console in AWS ECS.
380
+
3. Confirm that [dev site](https://agora-dev.adknowledgeportal.org/) shows changes from last merged PR.
381
+
382
+
## Staging Deployment
383
+
384
+
1. Review the list of existing tags [here](https://github.com/Sage-Bionetworks/sage-monorepo/tags). Identify the next `agora` tag. For example, if the last `agora` tag is `agora/v4.0.0-rc2`, then the next tag will be `agora/v4.0.0-rc3`. If the last `agora` tag doesn’t have a release candidate suffix (e.g. `agora/v4.0.0`), then the next tag will be the first release candidate of a new version (e.g. `agora/v4.0.1-rc1`). This follows the convention found at [semver.org](https://semver.org/).
385
+
2. Create a new git tag in the sage-monorepo:
386
+
- Open devcontainer
387
+
- Checkout the main branch: `git checkout main`
388
+
- Fetch latest changes: `git fetch upstream`
389
+
- Rebase: `git rebase upstream/main`
390
+
- Tag the commit: `git tag agora/v4.0.0-rc3`
391
+
- Push the tag: `git push upstream tag agora/v4.0.0-rc3`
392
+
3. Wait for sage-monorepo [release GHA job](https://github.com/Sage-Bionetworks/sage-monorepo/actions/workflows/release.yml) to successfully build, tag, and push images to GHCR.
393
+
4. Create PR in this repo **to the dev branch** that sets `GHCR_PACKAGE_VERSION` for stage and prod environments to the new version number in `app.py`, since the images are only tagged with the version number (e.g. `4.0.0-rc3`) rather than the full tag name (e.g. `agora/v4.0.0-rc3` ).
394
+
5. Merge PR. Wait for [deploy-dev job](https://github.com/Sage-Bionetworks-IT/agora-infra-v3/actions/workflows/deploy-dev.yaml) to successfully update dev deployment. Deployment can be monitored in AWS console in AWS ECS.
395
+
6. Create PR in this repo **to merge dev into the stage branch**.
396
+
7. Merge PR. Wait for [deploy-stage GHA job](https://github.com/Sage-Bionetworks-IT/modeladexplorer-v3/actions/workflows/deploy-stage.yaml) to successfully update staging deployment. Deployment can be monitored in AWS console in AWS ECS.
397
+
8. Confirm that [staging site](https://agora-stage.adknowledgeportal.org/) shows new version’s tag in the app footer.
398
+
399
+
## Production Deployment
400
+
401
+
1. Go to the staging site and note the tag in the app footer. Identify the `agora` release tag. For example, if the staging site tag is `agora/v4.0.0-rc3`, then the release version will be `agora/release/v4.0.0`.
402
+
2. Create a new git tag in the sage-monorepo:
403
+
- Open devcontainer
404
+
- Checkout the main branch: `git checkout main`
405
+
- Fetch latest changes: `git fetch upstream`
406
+
- Rebase: `git rebase upstream/main`
407
+
- Tag the commit: `git tag agora/release/v4.0.0`
408
+
- Push the tag: `git push upstream tag agora/release/v4.0.0`
409
+
3. Create a PR in this repo **to merge the stage branch into the prod branch**.
410
+
4. Merge PR. Wait for the [deploy-prod GHA job](https://github.com/Sage-Bionetworks-IT/modeladexplorer-v3/actions/workflows/deploy-prod.yaml) to successfully update prod deployment. Deployment can be monitored in AWS console in AWS ECS.
411
+
5. Confirm that [production site](https://agora.adknowledgeportal.org/) shows the same tag in the app footer as the staging site.
0 commit comments