Skip to content

Commit b896b3d

Browse files
mattdean3-nhsmattdean3-nhs
authored
Merge branch 'develop' into feature/axkr1-NRL-817-permissions-cache
2 parents c6ea1f4 + c77609e commit b896b3d

File tree

3 files changed

+37
-32
lines changed

3 files changed

+37
-32
lines changed

‎README.md‎

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -465,3 +465,12 @@ Once your new release has been created, you can then deploy this release through
465465
If the Consumer API has changed, or the documentation for that API has changed, you will also need to release (NRL Consumer API)[https://github.com/NHSDigital/nrl-consumer-api].
466466

467467
If the Producer API has changed, or the documentation for that API has changed, you will also need to release (NRL Producer API)[https://github.com/NHSDigital/nrl-producer-api].
468+
469+
### Deploying releases
470+
471+
Once you have a new release version ready, you can deploy it through our environments as follows:
472+
473+
1. Use the "Persistent Environment Deploy" Github Action workflow to deploy the release tag to `dev`, `dev-sandbox`, `qa`, `qa-sandbox`, `int` and `int-sandbox` environments.
474+
2. If any issues arise in the deployment, fix the issues, create a new release version and start this process again.
475+
3. Once the deployments are complete, use the "Persistent Environment Deploy" Github Action workflow to deploy the release version to `ref`.
476+
4. Once that is complete, use the "Persistent Environment Deploy" workflow to deploy the release version to `prod`.

‎terraform/infrastructure/README.md‎

Lines changed: 20 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -2,24 +2,26 @@
22

33
This directory contains terraform to build the main NRLF api infrastructure.
44

5-
NRLF project uses terraform workspaces to handle multiple "environments". Environments are identified by their workspace id. Resources in each environment will contain workspace id in its name. (e.g. nhsd-nrlf--dev-pointers-table or nhsd-nrlf--469d5da6-pointers-table)
5+
NRLF project uses terraform workspaces to handle deploying multiple NRLF stacks to each of our environments. NRFL stacks are identified by their TF workspace id. Resources in each stack will contain the workspace id in its name. (e.g. nhsd-nrlf--dev-pointers-table or nhsd-nrlf--469d5da6-pointers-table).
66

7-
Each developer/QA can create their own instance of NRLF infrastructure. These are deployed to the dev AWS account and use variables in `etc/dev.tfvars`
7+
Each developer/QA can create their own ephemeral instance of the NRLF infrastructure. These are deployed as isolated NRLF stacks into the dev AWS account and use variables in `etc/dev.tfvars`.
88

9-
This project also uses "persistent environments". These are equivalent to traditional dev, ref and prod environments. The persistent environments are deployed as follows:
9+
This project has a number of "persistent environments", similar to traditional dev, ref and prod environments. Each of these environments will typically contain multiple NRLF stacks, allowing for blue/green style deployment, and have shared storage infrastructure like DynamoDB tables and S3 buckets. The persistent environments are deployed as follows:
1010

11-
| Environment | TF Workspace | TF Config | AWS Account | Internal Domain | Public Domain |
12-
| ------------ | ------------ | ----------------- | ----------- | ------------------------------------ | ----------------------------------------- |
13-
| internal-dev | dev | `etc/dev.tfvars` | dev | `record-locator.dev.national.nhs.uk` | `internal-dev.api.service.nhs.uk` |
14-
| dev-sandbox | dev-sandbox | `etc/dev.tfvars` | dev | `record-locator.dev.national.nhs.uk` | `internal-dev-sandbox.api.service.nhs.uk` |
15-
| internal-qa | qa | `etc/qa.tfvars` | test | `qa.record-locator.national.nhs.uk` | `internal-qa.api.service.nhs.uk` |
16-
| qa-sandbox | qa-sandbox | `etc/qa.tfvars` | test | `qa.record-locator.national.nhs.uk` | `internal-qa-sandbox.api.service.nhs.uk` |
17-
| int | int | `etc/int.tfvars` | test | `record-locator.int.national.nhs.uk` | `int.api.service.nhs.uk` |
18-
| sandbox | int-sandbox | `etc/int.tfvars` | test | `record-locator.int.national.nhs.uk` | `sandbox.api.service.nhs.uk` |
19-
| ref | ref | `etc/ref.tfvars` | test | `record-locator.ref.national.nhs.uk` | `ref.api.service.nhs.uk` |
20-
| prod | prod | `etc/prod.tfvars` | prod | `record-locator.national.nhs.uk` | `api.service.nhs.uk` |
11+
| Environment | TF Workspace | TF Config | AWS Account | Internal Domain | Public Domain |
12+
| ------------ | ------------- | ----------------- | ----------- | ------------------------------------ | ----------------------------------------- |
13+
| internal-dev | dev-N | `etc/dev.tfvars` | dev | `record-locator.dev.national.nhs.uk` | `internal-dev.api.service.nhs.uk` |
14+
| dev-sandbox | dev-sandbox-N | `etc/dev.tfvars` | dev | `record-locator.dev.national.nhs.uk` | `internal-dev-sandbox.api.service.nhs.uk` |
15+
| internal-qa | qa-N | `etc/qa.tfvars` | test | `qa.record-locator.national.nhs.uk` | `internal-qa.api.service.nhs.uk` |
16+
| qa-sandbox | qa-sandbox-N | `etc/qa.tfvars` | test | `qa.record-locator.national.nhs.uk` | `internal-qa-sandbox.api.service.nhs.uk` |
17+
| int | int-N | `etc/int.tfvars` | test | `record-locator.int.national.nhs.uk` | `int.api.service.nhs.uk` |
18+
| sandbox | int-sandbox-N | `etc/int.tfvars` | test | `record-locator.int.national.nhs.uk` | `sandbox.api.service.nhs.uk` |
19+
| ref | ref-N | `etc/ref.tfvars` | test | `record-locator.ref.national.nhs.uk` | `ref.api.service.nhs.uk` |
20+
| prod | prod-N | `etc/prod.tfvars` | prod | `record-locator.national.nhs.uk` | `api.service.nhs.uk` |
2121

22-
CI pipeline creates infrastructure in the test AWS account. These will have workspace id of `<first six char of commit hash>-ci` and use variables in `etc/test.tfvars`
22+
The `N` in the TF workspace name repesents the stack id in that environment. So, for example, the internal-dev environment might have two stacks, `dev-1` and `dev-2` with TF workspace names matching their stack names. All resources for the `dev-1` stack will be contained within the `dev-1` TF workspace.
23+
24+
CI pipeline creates infrastructure in the dev AWS account. These will have workspace id of `nrl<jira-id>-<first six char of commit hash>` and use variables in `etc/dev.tfvars`
2325

2426
## Table of Contents
2527

@@ -65,12 +67,12 @@ If you want to use an existing workspace, or if you want to use the workspace of
6567
$ make ENV={ENV_NAME} TF_WORKSPACE_NAME={WORKSPACE_NAME} init
6668
```
6769

68-
replacing `{ENV_NAME}` with the environment name (e.g. `dev`, `qa`, `qa-sandbox` etc) and `{WORKSPACE_NAME}` with the name of the workspace you want to use.
70+
replacing `{ENV_NAME}` with the environment name (e.g. `dev`, `qa`, `qa-sandbox` etc) and `{WORKSPACE_NAME}` with the name of the workspace/stack you want to use.
6971

70-
So, for example, if you want to use the `qa` environment, you'd do you the following:
72+
So, for example, if you want to use the `qa` environment and deploy to the `qa-1` stack, you'd do the following:
7173

7274
```shell
73-
$ make ENV=qa TF_WORKSPACE_NAME=qa init
75+
$ make ENV=qa TF_WORKSPACE_NAME=qa-1 init
7476
```
7577

7678
If your Terraform provider config changes, you may need to reinitialise your workspace.
@@ -117,4 +119,4 @@ To teardown the infrastructure, do the following:
117119
$ make ENV={ENV_NAME} TF_WORKSPACE_NAME={WORKSPACE_NAME} init destroy
118120
```
119121

120-
replacing `{ENV_NAME}` with the environment name (e.g. `dev`, `qa`, `qa-sandbox` etc) and `{WORKSPACE_NAME}` with the name of the workspace you want to destroy.
122+
replacing `{ENV_NAME}` with the environment name (e.g. `dev`, `qa`, `qa-sandbox` etc) and `{WORKSPACE_NAME}` with the name of the workspace/stack you want to destroy.

‎terraform/infrastructure/locals.tf‎

Lines changed: 8 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -1,25 +1,17 @@
11
locals {
22
region = "eu-west-2"
33
project = "nhsd-nrlf"
4-
environment = terraform.workspace
4+
stack_name = terraform.workspace
55
deletion_protection = var.deletion_protection
6-
prefix = "${local.project}--${local.environment}"
7-
shared_prefix = "${local.project}--${var.account_name}"
6+
prefix = "${local.project}--${local.stack_name}"
7+
88
kms = {
99
deletion_window_in_days = 7
1010
}
1111

12-
# TODO - Remove once all environments are on new domain structure
13-
env_on_new_dns_zone = ["qa", "qa-sandbox"]
14-
new_domain_map = {
15-
"qa" : "api.${var.domain}",
16-
"qa-sandbox" : "sandbox-api.${var.domain}",
17-
}
18-
1912
apis = {
20-
zone = var.domain
21-
# TODO - Move all other environments onto new domain structure
22-
domain = contains(local.env_on_new_dns_zone, local.environment) ? local.new_domain_map[local.environment] : "${terraform.workspace}.${var.domain}"
13+
zone = var.domain
14+
domain = "${terraform.workspace}.${var.domain}"
2315
consumer = {
2416
path = var.consumer_api_path
2517
}
@@ -29,8 +21,10 @@ locals {
2921
}
3022
dynamodb_timeout_seconds = "3"
3123

32-
is_sandbox_env = length(regexall("-sandbox-", local.environment)) > 0
24+
is_sandbox_env = length(regexall("-sandbox-", local.stack_name)) > 0
3325

26+
environment = local.is_sandbox_env ? "${var.account_name}-sandbox" : var.account_name
27+
shared_prefix = "${local.project}--${local.environment}"
3428
public_domain = local.is_sandbox_env ? var.public_sandbox_domain : var.public_domain
3529

3630
# Logic / vars for splunk environment

0 commit comments

Comments
 (0)