Stormdriver Installation
Last updated
Was this helpful?
Last updated
Was this helpful?
Stormdriver is a Clouddriver aggregator. It sits between other Spinnaker components and looks like a Clouddriver to those components. Stormdriver maintains a list of all known accounts on Clouddrivers it is configured to monitor and routes requests to the proper Clouddriver.
This allows Clouddriver sharding, among other features.
When combined with the OpsMX Agent, Stormdriver can securely cross security boundaries, allowing users to run their Clouddriver for their accounts, while a centralized Spinnaker install can use any of them.
No external database is needed, and multiple Stormdrivers can be run with the same configuration, behind a load balancer or Kubernetes service, for Spinnaker to use.
Spinnaker components assume Clouddriver knows about all configured accounts. While a high-availability configuration is available, each Clouddriver component still requires full knowledge of all accounts.
Stormdriver allows running multiple Clouddriver instances with a partial list of the total accounts, sharding along any axis desired. Stormdriver communicates with these Clouddriver shards and presents a single, large all-accounts view to the remainder of Spinnaker.
Stormdriver can be used with SaaS-hosted environments as well as larger customers, where teams run their own Clouddriver + agent installations to isolate credentials or to provide a self-registration of their accounts with a shared Spinnaker.
Stormdriver has a list of known Clouddrivers. It constantly polls the /credentials and /artifact/credentials endpoints on a timer, currently every 10 seconds.
Using the results, it maintains a list of account names for the Clouddriver handling that account.
It also uses which instances reply with a successful HTTP status code for scatter-gather operations, discussed later.
Stormdriver polls frequently for new accounts and artifact accounts and maintains a map of account-name to Clouddriver URL. See the priority setting on a Clouddriver for details on how this is created.
When a request includes an account scope, the request is forwarded to a single Clouddriver instance which we know handles that account, and the entire response is sent back to the client. If no route exists, Stormdriver will return HTTP status 503 Service Unavailable.
For ISD 4.0 installation steps, refer here. The Stormdriver flag is set to false by default in the values.yaml.
By using the OpsMx-helm chart one should be able to deploy ISD 4.0 along with Stormdriver by setting the above flag to true.
Refer to the following sample values.yaml: https://github.com/OpsMx/enterprise-spinnaker/blob/v4.0/charts/oes/values.yaml
Install ISD 4.0 with Stormdriver by using the following helm install command
After the initial installation of ISD 4.0 is complete, if the user wants to enable or disable StormDriver configuration, they must modify the values.yaml for stormdriver: true/false depending on the requirement and run the following command to update.
Can connect to your cluster where ISD 4.0 is installed and running.
Sufficient RAM and CPU for Stormdriver. Stormdriver uses very little ram and CPU. It is expected to use around 30 MB of ram and 5% of CPU typically but this may increase depending on the number of accounts in use across all Clouddriver instances and the size of responses to queries.
Stormdriver acts as a frontend to the Clouddriver service. For example, if you have a single instance of Clouddriver service running in non-HA mode, it will be front-ended by one Stormdriver service.
If you have Clouddriver running in HA mode, which means it is segregated into four services ro,rw,ro-deck, and caching. Then you will have four HA Clouddriver services connecting to each of the four segregated services: Stormdriver-ro,rw,ro-deck, and caching.
The below example assumes that the Clouddriver is running in non-HA mode and there are two instances of the Clouddriver running that is, clouddriver-1 and clouddriver-2 both having different clouddriver-local.yml files as well as go-clouddriver running in parallel to them.
Refer to the following sample-config.yaml:
Clouddrivers are defined using the following fields:
name (optional) is the internal name used for printing debugging messages. It can be anything but should be unique. It is optional, and if not defined, one will be created.
url (required) is the endpoint URL to use to contact that Clouddriver, and should not end with a slash.
healthcheck (optional) default value is ${url}/health, but it can be overridden. A status code of 200 to 399 indicates "healthy," while anything else, or a timeout, indicates "unhealthy."
priority (optional) default value is 0. If set, it establishes a priority for accounts when merging results from each Clouddriver. Higher numbers indicate a higher priority. Generally, this is not for production use, but for migration from a single monolithic Clouddriver install to a sharded system with minimal loss of service.
Installation Validation:
Expected functionality:
The pipeline should get successful and be able to deploy the nginx application without any issues.
The user should see calls to Stormdriver services instead of calls to Clouddriver.
In addition to all of the currently supported Clouddriver URL paths, three additional endpoints are included for Stormdriver monitoring and debugging.
/_internal/accounts returns the list of currently known accounts, both for cloud providers and artifacts.
/_internal/accountRoutes shows the currently known accounts, and which Clouddriver they will be forwarded to.
/health indicates the health of a Stormdriver. This also includes the status of each Clouddriver connection in its JSON response. While included, if any specific Clouddriver is down or unreachable, it will be reported here, but will not affect the health indicator reported by Stormdriver. The /health endpoint is suitable for use in a Kubernetes or other liveness probe. It will return 200 if all the required health checks pass, or a 4xx code if it is unhealthy.
