Install and Configure Spinnaker on Spinnaker

Choose your Environment

Mon, 01 Jan 0001 00:00:00 +0000

In this step, you choose where to install Spinnaker. The recommended path is an installation into a Kubernetes cluster

Kubernetes installation

Each of Spinnaker’s microservices services are deployed separately. This is highly recommended for use in production.
Local installations of Debian packages

You can also install on a single local machine, or for Spinnaker development, making sure you have the 4 cores and 16GB in each case.

Spinnaker is deployed on a single machine. This is ok for smaller Spinnaker deployments, but Spinnaker will be unavailable when it’s being updated. Note it’s often better to use a microk8s/k3s installation to deploy rather than try to deploy a local debian.

Deploy Spinnaker and Connect

Mon, 01 Jan 0001 00:00:00 +0000

Now that we’ve enabled one or more Cloud Providers , picked a Deployment Environment , and configured Persistent Storage , we’re ready to pick a version of Spinnaker, deploy it, and connect to it.

Pick a version

See the available versions on the versions page

You can follow the links to the versions’ respective changelogs to see what features each adds.
Set the version you want to use: Set this on the kustomize image tag configuration . All spinnaker versions since the monorepo use the same image tags, e.g. 2025.3.2.

Storage

Mon, 01 Jan 0001 00:00:00 +0000

Spinnaker requires a database for persisting your Application settings and configured Pipelines as well as execution history. A database is used for a few services (clouddriver, front50, orca). Because this data can be sensitive and can be costly to lose, we recommend you use a hosted storage solution you are confident in.

Supported databases

Spinnaker recommends MySQL/MariaDB or Postgresql. It’s recommended for most users to start with MariaDB/MySQL.

Services ship with mysql-connector-java by default. You can provide additional JDBC connectors on the classpath if desired. MySQL/MariaDB is reported to work all the way up to version 10 of MariaDB and the latest Aurora MySQL engines.

Configuration

Mon, 01 Jan 0001 00:00:00 +0000

There are a number of other things you can configure in your Spinnaker installation enumerated below. At any point in time, you can apply your configuration by deploying Spinnaker services:

kubectl kustomize -o spinnaker.yml
kubectl apply -f spinnaker.yml

Deploy to more cloud accounts

Documentation

You can add as many target accounts as you want. There is nothing preventing you from deploying to two Kubernetes clusters, one Google Compute Engine project, and an App Engine application all at once.

Setup FAQ

Mon, 01 Jan 0001 00:00:00 +0000

CAUTION

Halyard is deprecated and no longer supported. MANY FAQs here around halyard no longer work or are no longer relevant. See a Spinnaker Kustomize based installation for a current deployment of spinnaker. Halyard FAQs and information will be removed on an ongoing basis

I can’t load the Applications screen

After installing Spinnaker and navigating to the Applications screen, you may see one of following issues:

The following error message is displayed:

Error fetching applications. Check that your gate endpoint is accessible. Further information on troubleshooting this error is available here

The most common cause of this error is that your browser can’t communicate with your Gate endpoint. (This endpoint defaults to http://localhost:8084, but can be customized.)

Migrating from Operator/Halyard to Kustomize Deployment

Mon, 01 Jan 0001 00:00:00 +0000

Migrating to a Kustomize Deployment

Thank you to harness spinnaker team for the script and automation to enable migration to kustomize easily. This is a mirror from their documentation on migration off of operator and though operator specific in many aspects, this should work just as well for halyard deployments

Introduction

This document provides step-by-step instructions for migrating your Spinnaker installation from using the Armory Operator deployment method OR a halyard deployment to a native Kubernetes deployment using Kustomize. This approach gives you more direct control over your Spinnaker resources and removes the dependency on halyard

Component Sizing

Mon, 01 Jan 0001 00:00:00 +0000

CPU & Memory requests/limits

Container requests and limits for cpu and memory can be specified in the spinnaker-kustomize/base/*/deployments.yml files. Watch for OutOfMemory exceptions and monitor JVM Memory, CPU usage, and similar metrics to keep spinnaker up and running.

Limits and requests can be set per kubernetes documentation .

Updating JAVA_OPTS

All JVM-based services have the following JAVA_OPTS that can be set to adjust things like memory or additional flags. You can add these to the deployment ENV variables:

High Availability

Mon, 01 Jan 0001 00:00:00 +0000

Warning this is an advanced that most basic users never need to worry about

This page describes how you can configure a Spinnaker deployment to increase the availability/performance of specific services beyond simply horizontally scaling the services.

This is done by splitting the functionalities of a service into separate logical roles. The benefits of doing this is specific to the service that is being sharded. These deployment strategies are inspired by Netflix’s large scale experience .

Deprecated - Halyard

Mon, 01 Jan 0001 00:00:00 +0000

This documentation is deprecated as halyard is deprecated and no longer supported. This is left here for historical purposes

Halyard is a command-line administration tool that manages the lifecycle of your Spinnaker deployment, including writing & validating your deployment’s configuration, deploying each of Spinnaker’s microservices, and updating the deployment.

All production-capable deployments of Spinnaker require Halyard in order to install, configure, and update Spinnaker. Though it’s possible to install Spinnaker without Halyard, we don’t recommend it, and if you get stuck we’re just going to tell you to use Halyard.