Here are a few Q/A pairs that come up fairly frequently.
I want to expose LocalDebian Spinnaker on a public IP address, but it always binds to localhost
First off, on a local deployment Spinnaker binds to
Your Spinnaker instance has the ability to deploy and destroy a lot of
infrastructure in whatever accounts it manages, and opening it to the public is
not a good idea without authentication enabled. With that in mind, there are
Once you enable an authentication mechanism, Spinnaker will bind the UI and API servers to
0.0.0.0automatically. This is configurable if you prefer to bind a specify address instead. Regardless, you still need to set the API & UI baseUrls so CORS and login redirects happen correctly, this is done with the commands
hal config security ui edit --override-base-url <full ui url>and
hal config security api edit --override-base-url <full api url>.
If you don’t want to rely on authentication, you can follow this guide. This makes sense if you’re running Spinnaker in a private network, or have another form of authentication fronting Spinnaker.
I want to expose the distributed, Kubernetes hosted Spinnaker publicly
There is a guide for doing this using
Google’s authentication & domain registrar. If this doesn’t match your
environment, it may still be helpful to read. The key point is, Halyard does
not touch any of the Kubernetes Service objects once they are created. You
can change their type to
LoadBalancer, front them with Ingress
resources, or manage them like any other Kubernetes service and expose them
however you like.
Halyard times out during a config change
Odds are Halyard can’t connect to the configuration & version bucket (in Google
Cloud Storage) it uses to determine if the configuration you’ve provided works
for the version of Spinnaker you want to install. The bucket is
gs://halconfig, see if you can reach it locally using the
The remediation will depend on your local network. You can also always omit
validation with the
Halyard times out during a deployment
If this happens, there are one of two causes:
- The services that haven’t become healthy are misconfigured. Run
hal deploy collect-logsto collect service logs, which will be placed in
~/.hal/default/service-logs. Check for any obvious errors.
- You do not have enough resources in your environment to run Spinnaker, and the deployer is waiting for some to become available. This varies from environment to environment.
I want to configure a service beyond what Halyard exposes
First, please read the custom configuration
documentation. With that in mind, if you’re configuring any of Spinnaker’s
services (everything but deck and spinnaker-monitoring), you’re
best off providing a
-local.yml profile for the service in mind. For example,
say you are configuring the Halyard
default, and the service
gate, you can write the following file:
example: property: value
and the properties generated by Halyard will be overwritten by those provided
If the service you want to configure does not rely on Spring, you will need to
wholesale overwrite the config in the
I don’t want to rely on any of the configuration generated by Halyard
You have two options here:
- Provide custom configuration for any services whose config you prefer to override.
- Deploy Spinnaker with the
--omit-configflag. In the Local installation, this will pin & download validated debian packages at their respective versions without providing any configuration. In a Distributed installation, you will need to provide your own mechanisms for loading configuration for each subservice.
I’m seeing duplicate/bad infrastructure entries in the UI after deploying config changes
Spinnaker’s cloud provider integration point (clouddriver) does not clean out
cache entries that may be left around after reconfiguring existing
accounts. The best way to get around this is to supply the
--flush-infrastructure-caches to a
hal deploy apply. This may cause
jittering in the UI as the caches are repopulated.
I want to decouple my Halyard configuration from a single machine
Please read the backup documentation.
Halyard produces a lot of ugly ANSI escape sequences making it frustrating to automate
You can supply the flags
-q -log=info to any Halyard command to get more
digestable log messages.
-q suppresses the ANSI pretty-printing, and
-log=info enables info-level logs in the CLI.
I don’t want to use a bunch of CLI commands to configure Spinnaker; I prefer my text editor
Anything in the
~/.hal/config can be edited by hand at any time. You can
validate what you provide there by running
hal config, and deploy it as you
hal deploy apply. For more service-specific edits, please read
the custom configuration docs.
I only want to deploy a subset of Spinnaker’s services
You can run
hal deploy apply --service-names <service1> <service2...> to
deploy only the services you care about. Be careful, if you have sidecars like
monitoring-daemon or the
consul-client for a VM based distributed
deployment, you will have to supply those as well.
This can be coupled with
--omit-config in a local installation to provide a
taylored way of deploying & configuring only the services you want on the
machines you care about.
I want to run Halyard behind a proxy
In the file under
/opt/halyard/bin/halyard, add the necessary proxy
configuration to the variable
DEFAULT_JVM_OPTS as described