Welcome to your CDK TypeScript project

This is a blank project for CDK development with TypeScript.

The cdk.json file tells the CDK Toolkit how to execute your app.

Useful commands

• npm run build compile typescript to js
• npm run watch watch for changes and compile
• npm run test perform the jest unit tests
• npx cdk deploy deploy this stack to your default AWS account/region
• npx cdk diff compare deployed stack with current state
• npx cdk synth emits the synthesized CloudFormation template

Local setup

AWS CLI

Follow these steps to setup the AWS CLI in order to run CDK commands

aws configure sso --profile glicogh-uat

This will prompt you to enter further details. Here's an example

SSO session name (Recommended): isa
SSO start URL [None]: https://glicogh.awsapps.com/start/
SSO region [None]: us-east-1
SSO registration scopes [sso:account:access]:

This will open up the sso URL in a browser for you to auhtorize the CLI. After the authorization, the CLI will present all the AWS accounts (available to your user account) for you to make a selection. Here's an example of the prompt

There are 4 AWS accounts available to you.
> GLICO-Ghana, [email protected] (169555392631)
  Healthcare Microservices Dev, [email protected] (640168444097)
  Healthcare Microservices Prod, [email protected] (273354667305)
  Healthcare Microservices UAT, [email protected] (825765383017)

Select the account that best suits the environment you're trying to build in. Once you make a selection, there will be a confirmation and another prompt that looks like the following

Using the account ID 825765383017
The only role available to you is: AdministratorAccess_
Using the role name "AdministratorAccess_"
CLI default client Region [None]: eu-west-2
CLI default output format [None]: json

To use this profile, specify the profile name using --profile, as shown:

aws s3 ls --profile glicogh-uat

CDK CLI

npm install -g aws-cdk

Testing setup

Run the following to list available stack

cdk --profile glicogh-uat --context env=uat ls

The output looks like this

MicroserviceNetwork
MicroserviceRedis
MicroserviceMySQL

Running the CDK

Shared stack

The following stack are meant to be deployed once and shared across the microservices. These would typically be deployed from a local machine as opposed to within a CI/CD pipeline

• MicroserviceNetwork
• MicroserviceInfraAuth
• MicroserviceRedis
• MicroserviceMySQL

The only required option for these stack is env. For example, to deploy MicroserviceNetwork in the UAT environment, you would run the command

cdk --profile glicogh-uat --context env=uat deploy MicroserviceNetwork

Pipeline-based stack

The following stack on the other hand, are meant to deploy a new set of resources on each CDK deployment. These can also be thought of as the stack that have a GIT repository.

• MicroserviceApiGateway
• MicroservicePortal
• MicroserviceLaravelBased
• MicroserviceNotificationService

These are typically microservice stack and will be triggered each time code is merged into a specified branch of a microservice repo. These stack will not be ran directly in this project, but rather from within each microservice project as a dependency. For example, to deploy the account microservice in the UAT environment, you would run the command

cdk --profile glicogh-uat --context env=uat --context version=1.0.1 --context build=101 --context service=account deploy

Options

• env (required): This determines the configuration to be applied to target the appropriate deployment environment. For example, if this value is uat, the env file .env.uat (which must exist in the dependant project) will be applied. The .env.x file determines the AWS account, region, ec2 configuration, etc
• service (required): This determines the microservice that is being targeted. It also determines the CDK stack to apply.
• build (required): This identifies the version of the code that is being deployed. If this value is unique, a new Cloudformation stack will be deployed with each CDK deployment, which will result in new resources (such as EC2 instances) being deployed every time. For example, in a Github actions, this could be the commit hash. If the value is static, the same Cloudformation stack will be updated on each deployment.
• version (optional)
• branch (optional): This determines the branch to be deployed to EC2 instances. If this option is not supplied, a default branch will be used depending on the env option

The service option can also be passed in a .env

The above command is what you would run in the CDK CLI. However, you would typically be running the deployment in a CI/CD pipeline such as Github Actions, in which case the command may be different. You would have to refer to the CI/CD platform's documentation for how to achieve this.

Using as dependency

Follow these steps to setup CDK in a repository.

This assumes you are in the root of the project

# delete CDK folder if it already exists
rm -rf .infra/cdk
# create CDK folder
mkdir -p .infra/cdk
# change working directory to the CDK directory
cd .infra/cdk
# initialize CDK
cdk init app --language typescript
# install package as a dependency
npm i @glicogh/healthcare-cdk
# copy env
cp node_modules/@glicogh/healthcare-cdk/.env.example .env.example
# copy CDK initialization file
cp node_modules/@glicogh/healthcare-cdk/cdk.example.ts bin/cdk.ts

Now you can clone the file .env.example for each of the target environments (for example, .env.uat) and edit the variables appropriately for the target environment.

For the laravel-based projects, the package is able to perform all the steps/commands for you by running php artisan glico:healthcare:microservice:cdk