CyberCoveLLC/threshold
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fix wording on HA doc (client -> host) (#803)

Browse Source
This commit is contained in:
Jeff Mitchell authored and GitHub committed 2020-11-30 12:35:40 -05:00
1 parent af2d9dfe90
commit 1189ebdfc6
1 file changed
+1 -1
Download Patch File Download Diff File Expand all files Collapse all files
website/content/docs/installing/high-availability.mdx
+1 -1
View File
@@ -33,7 +33,7 @@ needs:
As shown above, Boundary is broken up into its controller and worker server components across 3 [EC2 instances](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/instance), in
3 separate [subnets](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/subnet), in three separate [availability zones](), with the controller API and UI being publically exposed by an [application load balancer (ALB)](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/lb). The worker and controller VM's are in independant [auto-scaling groups](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/autoscaling_group), allowing them to maintain their exact capacity.
The workers must be able to establish a connection to clients which they interact. In the architecture above, we place them in the public subnet so our remote client can establish a session between them and the target VM.
The workers must be able to establish a connection to the hosts with which they interact. In the architecture above, we place them in the public subnet so our remote client can establish a session between them and the target VM.
Boundary requires an external [Postgres](https://www.postgresql.org/) and [KMS](https://aws.amazon.com/kms/). In the example above, we're using AWS managed services for these components. For Postgres, we're using [RDS](https://aws.amazon.com/rds/) and for KMS we're using Amazon's [Key Management Service](https://aws.amazon.com/kms/).