Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: Add link to Postgres HA #5080

Merged
merged 3 commits into from
Sep 9, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ The following ports should be available:
- Clients must have access to the Controller's `api` port (default 9200)
- Clients must have access to the Worker's port (default 9202)
- Workers must have access to the Controller's `cluster` port (default 9201)
- Workers must have a route and port access to the hosts defined within the system in order to provide connectivity
- Workers must have a route and port access to the hosts defined within the system to provide connectivity

## Architecture

Expand All @@ -31,6 +31,14 @@ The workers must be able to establish a connection to the hosts with which they

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/).

### Database

Boundary controllers must be able to reach the PostgreSQL database.
If you use a [high availability](/boundary/docs/install-boundary/high-availability) (HA) configuration, then the controllers must have access to the PostgreSQL server infrastructure.

For more information about configuring the Postgres database for HA, refer to the [Postgres high availability, load balancing, and replication documentation](https://www.postgresql.org/docs/current/high-availability.html).
If you use a managed service, refer to your provider's PostgreSQL high availability documentation.

### API and console load balancer

Load balancing the controller allows operators to secure the ingress to the Boundary system. We recommend placing all Boundary servers in private networks and using load balancing techniques to expose services such as the API and administrative console to public networks. In the high availability architecture, we recommend load balancing using a layer 7 load balancer and further constraining ingress to that load balancer with layer 4 constraints such as [security groups](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) or [IP tables](https://wiki.archlinux.org/index.php/Iptables).
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -145,6 +145,9 @@ If you use a [high availability](/boundary/docs/install-boundary/high-availabili
In non-HA configurations, the Boundary servers must have access.
Worker nodes never need access to the database.

For more information about configuring the Postgres database for HA, refer to the [Postgres high availability, load balancing, and replication documentation](https://www.postgresql.org/docs/current/high-availability.html).
If you use a managed service, refer to your provider's PostgreSQL high availability documentation.

### Database users and roles

After the database has been initialized, the database user for a Boundary controller requires only permissions for [data manipulation](https://www.postgresql.org/docs/current/dml.html) operations (select, insert, update, and delete).
Expand Down
Loading