ISD Architecture
Last updated
Last updated
This is an older version of the document. To view the most recent version of the document, click here.
The figure below depicts the component view of the ISD architecture. As mentioned earlier, it consists of two modules, Orchestration and the Data & Intelligence module.
ISD consists of the following services.
Autopilot = Verification service
SAPOR = connect with Spinnaker and git/S3 Repo for updating dynamic accounts
Visibility = implementation of approval service
Dashboard = Collate data for graphical presentation of applications and pipelines
OES-Gate = Authentication gateway
Sapor-gate = OPTIONAL: spin-gate with basic-auth for Sapor communication
Controller = OPTIONAL: remote deployments (Not shown in the Schematic below)
OES-UI = Serves the UI elements (Not shown in the Schematic below)
These services also use two databases:
OES-db : Postgres DB customized for OES
OES-redis : Used by OES-gate
Apart from these, OES includes all the Spinnaker components, configured in HA mode. Spinnaker services functional roles are as follows:
Deck (GUI)
Gate (API)
Clouddriver (Deployments)
Orca (Orchestrator)
Echo (Notifications)
Front50 (DB Frontend)
Redis (Execution cache)
Key communication paths in the ISD:
SAPOR Service communicates with the Spinnaker Gateway and makes API calls to retrieve data, update pipelines, etc.
SAPOR can also be configured to use Sapor-gate which uses Basic Authentication. This is useful in cases where Spinnaker is configured with 2-factor authentication.
Application is designed based on API-gateway architecture. All data from the web-browser goes through:
OES-gate or
Spin-gate
ISD requires 5 ingress points:
Spinnaker UI : spin-deck service on port 9000
Spinnaker Gate: spin-gate service on port 8084
OES UI: OES-UI service on port 8080
OES gate: OES-API service on port 8084
Controller: For an agent to contact the controller, we need an ingress/LB. Note that TLS + gRPC traffic needs to be routed to the controller, shown in red.
