Overview
The following section provides an overview of the Styra Self-Hosted DAS Installation Guide, Styra DAS, Styra DAS architecture, and the microservices used with Styra DAS.
Document Overview and Audience
The Self-Hosted Styra DAS Installation Guide contains information on configuring and installing Styra DAS on a wide selection of cloud infrastructure providers. The contents of the Infrastructure Configuration and the Cloud Agnostic Infrastructure sections are not, however, meant to be a comprehensive guide to cloud infrastructure. The infrastructure sections of this document are intended to provide guidance specific to configuring and instantiating infrastructure for use with Styra DAS. Accordingly, this document assumes the customer is familiar with managing their own infrastructure and defers to provider-specific documentation wherever possible.
Styra DAS can also run on self-managed or non-cloud infrastructure. Such setups, however, tend to require customized support and compatibility patterns. If you cannot utilize any of the providers described in this document, we recommend working with Styra’s Sales and Solutions Architecture teams to determine the best method of deploying Styra DAS on your infrastructure.
Styra DAS Microservices
The following table describes the Styra DAS microservices used in Self-Hosted Styra DAS.
Styra DAS Microservice | Styra Description |
---|---|
activity | Provides user activity log APIs. |
agentbundle | Responsible for /v1/bundles API and ad-hoc bundle compilation when bundle registry is disabled. |
agentloader | Loads decision logs from OPA to Elasticsearch for indexing. |
agentstatus | APIs for OPAs to send status updates and decision logs. |
agentstatusstore | Caches OPA status updates for quick retrieval. |
analysis-api | APIs to search decision logs. |
blueprints | Required to enable mock-opa sandbox environments. |
bundleregistry | Builds and serves bundles from the bundle registry. |
coordinator | Shards work across service replicas. |
datasources | Executes Data Sources that require pulling data. |
elasticsearch | Search engine for decision logs. |
environment-configurator | Manages storage resources for the environment. |
fetchdb | Configuration management APIs. |
gateway | API gateway. All API requests are routed through the gateway. It enforces authentication and authorization and records user activity. |
gateway-secondary | Optional second API gateway. |
inspector | Optional telemetry reporting service. |
job-bundles | Kubernetes Job service for building bundle registry bundles. |
job-compliance | Kubernetes Job service for compliance violation checks. |
logreplay | APIs to assess the impact of a policy change on previous decisions. |
metrics-exporter | Enables the monitoring integrations described in Monitoring Integrations. |
mock-opa | Decision mocking for sandbox environments. |
policies | APIs for policy management. |
postgres | PostgreSQL for all internal, persisted states. |
stacks | Stack configuration and management APIs. |
systems | System configuration and management APIs, OPA configuration bundle APIs used for discovery. |
tenants | Configures and manages the tenant's internal state. |
timeseries | Computes metrics over decision log APIs |
ui | Serves HTML and JavaScript for the Styra DAS UI. |
web | Enables distributed in-memory storage for horizontal communication between service instances, data sharing, and event notifications. |
Important Microservice Information
- The
coordinator
service cannot be vertically scaled. The work it performs cannot be split, and it must remain as one pod. - Every microservice registers itself with the
coordinator
pod. If a microservice comes up beforecoordinator
it will error and restart untilcoordinator
is up. The error message is similar tofailed to start <link> not found: member <member_id> is unknown