Skip to content

Commit 69e99f6

Browse files
committed
feat(aws): auto-scaled AWS deployment
Restructure AWS deployment to use load balancers and auto-scaled service instances. - This deployment requires a domain to be registered in Route53. - TLS is relegated to the load balancers. This requires for a certificate associate with the registered domain to be created inside ACM. - RDS and EC2 instances now run inside private subnets and are not directly accessible by the outside world. A sentinel instance exists to provide indirect access, e.g. when setting up the databases. Signed-off-by: Sergei Trofimov <[email protected]>
1 parent d8916d3 commit 69e99f6

29 files changed

+2520
-1284
lines changed

.gitignore

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -35,3 +35,9 @@ management/cmd/management-service/management-service
3535
tags
3636

3737
.ipynb_checkpoints
38+
39+
# these are created as part of the build process
40+
deployments/aws/keycloak/keycloak.conf
41+
deployments/aws/keycloak/providers
42+
deployments/aws/keycloak/Dockerfile
43+

deployments/aws/Makefile

Lines changed: 1 addition & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -14,14 +14,9 @@ deploy:
1414
echo "ERROR: please define AWS_ACCOUNT_CFG (see README)"; \
1515
exit 1; \
1616
fi
17-
source $(THIS_DIR)/env/env.bash && source $(AWS_ACCOUNT_CFG) && $(SCRIPT) bringup
17+
source $(THIS_DIR)/env/env.bash $(AWS_ACCOUNT_CFG) && $(SCRIPT) bringup
1818

1919
.PHONY: really-clean
2020
really-clean:
2121
source $(THIS_DIR)/env/env.bash
2222
$(SCRIPT) -N teardown
23-
24-
.PHONY: redeploy-stack
25-
redeploy-stack:
26-
source $(THIS_DIR)/env/env.bash
27-
$(SCRIPT) redeploy-stack

deployments/aws/README.md

Lines changed: 222 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -41,15 +41,32 @@ make bootstrap
4141

4242
### AWS account
4343

44-
Finally, you need an existing AWS account, that has at least one VPC with at
45-
least two subnets (at least one of which is public) configured.
44+
You need an existing AWS account, that has at least one VPC with at least two
45+
subnets (at least one of which is public) configured.
4646

4747
Please see [boto3
4848
documentation](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/credentials.html)
4949
for how to configure `aws` CLI to access this account.
5050

51+
### Domain and certificate
5152

52-
## Working with the deployment
53+
Finally, you need a domain registered in Route53, with a corresponding
54+
certificate created in ACM. If you already have a domain with a different
55+
registrar, your will need to transfer it to Route53.
56+
57+
The certificate MUST cover subdomains as well. For example, if you have
58+
registered `my-domain.com` in Route53, the certificate should have
59+
`*.my-domain.com` in its Subject Alternative Names.
60+
61+
For creating a new domain, please see [Register a new
62+
domain](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-register.html)
63+
or [Transferring registration for a
64+
domain](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-transfer-to-route-53.html).
65+
For information on setting up certificate in ACM please see [AWS Certificate
66+
Manager](https://docs.aws.amazon.com/acm/latest/userguide/gs.html)
67+
68+
69+
## Quickstart
5370

5471
Before creating a deployment, you need to provide account-specific
5572
configuration that specifies the IDs of the VPC and subnets that will be used
@@ -65,6 +82,10 @@ export AWS_ACCOUNT_CFG=misc/arm.cfg # replace with path to your config
6582
make deploy
6683
```
6784

85+
> [!NOTE]
86+
> This could take a while -- in the order of 45 minutes, depending on how
87+
> responsive AWS is.
88+
6889
Deployment can be accessed via CLI front end:
6990

7091
```bash
@@ -93,3 +114,201 @@ Finally, to remove the deployment, you can run
93114
```bash
94115
make really-clean
95116
```
117+
118+
## Deployment overview
119+
120+
![deployment diagram](misc/deployment-diagram.drawio.png)
121+
122+
Veraison is deployed into a dedicated VPC created within the AWS region
123+
specified by `VERAISON_AWS_REGION` inside `deployment.cfg` (the region must
124+
contain at least two availability zones). The address space for the VPC is
125+
determined by `VERAISON_VPC_CIDR`. It must be large enough to accommodate four
126+
subnets of equal size, with a subnet being large enough to hold the expected
127+
number of instances (at least `/16` CIDR is recommended).
128+
129+
The VPC spans two availability zones, each containing a public and a private
130+
subnet. The public subnets host load balancers for Veraison services and
131+
Keycloak. The first public subnet also hosts the sentinel EC2 instance which is
132+
used to configure RDS database. The private subnets host auto-scaled service
133+
instances, keycloak instance, and the RDS instance.
134+
135+
The deployment adds three subdomains to the domain registered in route 53 --
136+
one each for the services load balancer, keycloak load balancer, and the
137+
sentinel instance.
138+
139+
## Deployment bring up and tear down
140+
141+
`make` calls shown above just invoke `deployment.sh` with an appropriate
142+
command. `make bootstrap` calls `deployment.sh bootstrap`, `make deploy` calls
143+
`deployment.sh bringup`, and `make really-clean` calls `deployment.sh teardown`.
144+
145+
`deployment.sh` loads the environment from `deployment.cfg` and the additional
146+
file specified by `AWS_ACCOUNT_CFG`, and executes the function associated with
147+
the specified command, which, in turn, calls through to the `bin/veraison`
148+
script.
149+
150+
The first time `veraison` script is invoked, `--deployment-name` should be
151+
specified before the subcommand to indicate which deployment the script's
152+
subcommand should apply to. The script will remember it for future invocations,
153+
so there is no need to specify it again unless you want to switch the current
154+
deployment. `deployment.sh` take the value for this flag from
155+
`VERAISON_AWS_DEPLOYMENT` environment variable (specified inside
156+
`deployment.cfg`).
157+
158+
### Bring up
159+
160+
The bring up function creates the deployment. The deployment is created in
161+
stages, with each stage corresponding to a subcommand of the `veraison` script.
162+
The bring up stages are:
163+
164+
```bash
165+
veraison configure --init [...]
166+
veraison create-deb
167+
veraison create-key-pair
168+
169+
veraison create-vpc-stack
170+
171+
veraison create-sentinel-image
172+
veraison create-rds-stack
173+
veraison update-security-groups
174+
veraison setup-rds
175+
176+
veraison create-services-image
177+
veraison create-keycloak-image
178+
179+
veraison create-services-stack
180+
```
181+
182+
#### configure
183+
184+
`configure` command is used to configure the deployment. It has optional
185+
arguments to specify individual configuration points for the deployment. (use
186+
`veraison configure --help` to list them). Configuration will be cached locally
187+
and used by subsequent commands.
188+
189+
The `--init` flag indicates that this is an initial configuration for the
190+
deployment. Any arguments not specified by this command will be set to default
191+
values (or an error will be raised if no defaults exist). Without `--init` flag,
192+
only the specified parameters will configured (this can be used to update an
193+
existing configuration).
194+
195+
#### create-deb
196+
197+
This is used to create a Debian package for Veraison services using the [debian
198+
deployment](../debian). This is used to create the services image later.
199+
200+
#### create-key-pair
201+
202+
This creates an AWS key pair that will be used to configure access to EC2
203+
instances.
204+
205+
#### create-sentinel-image
206+
207+
Creates an AMI image for the sentinel instance. The instance will be
208+
provisioned with its own version of `veraison` script which can be found
209+
[here](misc/sentinel-commands). The sentinel will be used to mediate access to
210+
the RDS instance, which will not be directly accessible outside the VPC.
211+
212+
#### create-rds-stack
213+
214+
This creates the RDS and sentinel instances via a CloudFormation stack.
215+
216+
#### update-security-groups
217+
218+
This updates the sentinel instance's security group with your current public IP
219+
address, which will enable SSH access to the instance. If your current address
220+
is covered by `VERAISON_AWS_ADMIN_CIDR`, then this can be skipped.
221+
222+
If your ISP periodically changes your IP address, you may need to re-run this
223+
command in the future.
224+
225+
#### setup-rds
226+
227+
This initializes the RDS instance for use by Veraison services.
228+
229+
230+
#### create-services-image and create-keycloak-image
231+
232+
This creates AMI images that will be used by the various EC2 instances in the
233+
deployment. Both of these need configuration for connecting to the RDS
234+
instance, which is why the must be created after `setup-rds`.
235+
236+
#### create-services-stack
237+
238+
Finally, this creates the load balancers, auto-scaling groups, etc to complete
239+
the deployment. This also creates CNAME records for subdomains under the Route
240+
53 domain associated with the deployment.
241+
242+
### Teardown
243+
244+
Teardown, like bring up, invokes a number of `veraison` subcommands:
245+
246+
```bash
247+
veraison delete-stack services
248+
veraison delete-stack rds
249+
veraison delete-stack vpc
250+
251+
veraison delete-image keycloak
252+
veraison delete-image services
253+
veraison delete-image sentinel
254+
255+
veraison delete-key-pair
256+
veraison delete-deb
257+
```
258+
259+
This is more-or-less a reverse of what was done during bring up and should be
260+
self-explanatory.
261+
262+
263+
### Managing the deployment
264+
265+
In addition to containing the commands used during deployment bring up and
266+
teardown, `veraison` script also acts as a CLI front-end for the deployment.
267+
268+
```bash
269+
veraison status
270+
```
271+
272+
This shows a brief overview of the current state of the deployment -- which
273+
images have been created, which stacks have been deployed, and the currently
274+
running instances.
275+
276+
```bash
277+
veraison cache
278+
```
279+
280+
This dumps the local cache associated with the deployment. This includes the
281+
settings configured earlier using `veraison configure`, as well as various
282+
outputs from bring up stages. Notably this contains `keycloak_admin_password`,
283+
which will allow you to log into the Keycloak web interface.
284+
285+
```bash
286+
veraison stores
287+
```
288+
289+
This shows the contents of the K-V stores used by the services. This includes
290+
endorsements and trust anchors provisioned via the provisioning API, and
291+
policies uploaded via the management API.
292+
293+
```bash
294+
veraison clear-store
295+
```
296+
297+
This will empty the stores of all existing values. This can be useful during
298+
testing.
299+
300+
```bash
301+
veraison shell
302+
```
303+
This opens an interactive shell on the sentinel instance. This can be used to
304+
examine and debug the internal state of the deployment (aside from the API
305+
endpoints, the sentinel is the only thing accessible outside the VPC).
306+
307+
```bash
308+
veraison dbshell
309+
```
310+
311+
This opens an interactive Postgres shell on the RDS instance (via the
312+
sentinel). The instance is used both for the Veraison services' K-Stores
313+
(`veraison` database -- should be the default), and for Keycloak (`keycloak`
314+
database).

0 commit comments

Comments
 (0)