CDK API stack with Fargate / ALB

[chriswilty]

Description

Fargate-managed resources defined as CDK constructs, written in typescript. https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html

Resolves #385

Notes

• CDK generates some stuff for us when we run cdk init, such as a cdk.json config file. All you need to know about that file right now is, it includes a heap of settings to ensure we have sensible protections and defaults on our deployed resources.
• Our entire "application" is defined in bin/cloud.ts and it uses "stacks" to define its resources. Although it is common to have just one, you can actually define as many different applications as you wish, e.g. linux vs windows stacks, or maybe you want to introduce a feature in an experimental stack that won't interfere with your stable deployments. By convention these all sit in the bin/ directory.
• All resource stacks sit in the lib/ directory. A stack is simply a collection of resources deployed to AWS together; stacks tend to contain related resources, but more generally they are a way to organise your resources into groups. CDK works out any dependencies between stacks so that they are deployed in the correct order. For example, in a later PR I will add the UI stack, which defines a URL on which the UI is available; we need to tell the API stack that URL, so it can be added to allowed origins in CORS configuration. This means that the UI stack will be deployed first, followed by the API stack, regardless of the order they are defined in bin/cloud.ts.
• Our API stack is defined in lib/api-stack.ts. Observe that we define a docker Image, a VPC (virtual private cloud) with all its networking resources, and a Fargate service with cluster and load-balancer, all in a handful of lines of code; this produces over a thousand lines of CloudFormation template code! We also define an integration to AWS Secrets Manager to access API key and secret, and we pass those values to our docker container as env vars, so that they are available to our express server on startup. That happens within AWS at deployment time, so we don't need to store those values locally, nor send them over the network.
• Finally, note we are making use of our server healthcheck endpoint. This is how we tell Fargate if the server within each container is up and running, and Fargate will automatically kill and recreate nodes that are unhealthy, up to our desired minimum number of nodes (in our case, just one). @pmarsh-scottlogic This is why I wanted to remove the session cookie from that endpoint, because Fargate will ping the server regularly (every 30secs by default), and if every time we initiated a new session, that would be one of them dreaded resource leaks 😰

Checklist

Have you done the following?

• [x] Linked the relevant Issue
• [ ] Added tests
• [ ] Ensured the workflow steps are passing

[chriswilty]

Will replace with new PR, to see if github workflow is triggered correctly...