ISD Architecture
Architecture
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 Services
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
Ingress
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.
Last updated