Skip to content

Commit

Permalink
docs(md): Monitoring Daemon is deprecated (#188)
Browse files Browse the repository at this point in the history
  • Loading branch information
@kskewes-sf
kskewes-sf committed Mar 18, 2022
1 parent df43255 commit 086ef13
Show file tree
Hide file tree
Showing 5 changed files with 125 additions and 123 deletions.
1 change: 0 additions & 1 deletion content/en/docs/community/contributing/code/build-statuses/index.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,6 @@ services:
- kork
- orca
- rosco
- spinnaker-monitoring
supporting:
- halyard
- keel
Expand Down
94 changes: 47 additions & 47 deletions content/en/docs/reference/halyard/custom.md
View file
Original file line number Diff line number Diff line change
@@ -1,11 +1,10 @@
---
title: Custom Settings
description: >
description: >
"While Halyard handles the majority of Spinnaker configuration, there will always be feature flags and properties either too new or niche to be supported by Halyard."
---


Furthermore, some users will be more comfortable forgoing Halyard's
Furthermore, some users will be more comfortable forgoing Halyard's
configuration generation, or will want to port their old Spinnaker
configuration into Halyard. For these users & use-cases, Halyard supports
custom [Profiles](/docs/reference/halyard/#profiles), and custom [Service
Expand All @@ -15,7 +14,7 @@ Settings](/docs/reference/halyard/#service-settings).

The two most common ways of customizing your Spinnaker installation is through the use of either a custom profile, for example `clouddriver-local.yml`, or a service setting, for example `clouddriver.yml`. Each of these is created in separate subfolders inside the main Halyard deployment profile folder. In a `default` Halyard profile, this means profiles go in `.hal/default/profiles/` while service settings go in `.hal/default/service-settings`.

Custom profiles are configuration files that override the default configuration files for each Spinnaker Service. Service-Settings are used by Halyard to determine how to build the Spinnaker deployment and contain information specific to how each Spinnaker Service will be deployed.
Custom profiles are configuration files that override the default configuration files for each Spinnaker Service. Service-Settings are used by Halyard to determine how to build the Spinnaker deployment and contain information specific to how each Spinnaker Service will be deployed.

For example, if you want to substitute which image file will be used for a Spinnaker service, or what environment variables the service will be run with, then you'll need to modify the service settings for that service.

Expand Down Expand Up @@ -54,9 +53,10 @@ Deck UI, you can place them in a file called `settings-local.js`. For
example, to enable the `chaosMonkey` feature flag, you can create the
following file:

__`~/.hal/default/profiles/settings-local.js`:__
**`~/.hal/default/profiles/settings-local.js`:**

```js
window.spinnakerSettings.feature.chaosMonkey = true;
window.spinnakerSettings.feature.chaosMonkey = true
```

## Custom Service Settings
Expand All @@ -67,16 +67,18 @@ as found in `~/.hal/$DEPLOYMENT/history/service-settings.yml`. For example, if
you wanted Echo to listen on port 443 with the `JAVA_OPTS="-Xms256m -Xmx512m"`
environment variables set, you create the following file:

__`~/.hal/default/service-settings/echo.yml`:__
**`~/.hal/default/service-settings/echo.yml`:**

```yaml
port: 443
env:
JAVA_OPTS: "-Xms256m -Xmx512m"
JAVA_OPTS: '-Xms256m -Xmx512m'
```
If you wanted to specify a secure connection to redis, you would create the following file:
__`~/.hal/default/service-settings/redis.yml`:__
**`~/.hal/default/service-settings/redis.yml`:**

```yaml
overrideBaseUrl: redis://someuser:somepassword@localhost:6379
```
Expand All @@ -88,49 +90,47 @@ generated by Halyard are generally best and are all that we test, so there is
no guarantee making changes to these will result in a working Spinnaker
cluster.

| Value | Description |
| ----- | ----------- |
| `address` | The address other services will use to lookup this service; e.g. `localhost` or `redis.service.spinnaker.consul`. |
| `artifactId` | A fully-qualified identifier for the Artifact this service is to run - see your Service Settings output path for examples, since this varies by platform/deployment environment. |
| `basicAuthEnabled` | Whether or not to enable HTTP basic auth for this service. |
| `enabled` | Whether or not this service is enabled. Be careful, since disabling critical services like `consul-client` can make your entire installation unusable and un-upgradable. |
| `env` | Environment variables to make available to this Service. Supplied as YAML key-value pairs. |
| `healthEndpoint` | The HTTP endpoint that can be queried for health status. Leave empty if you want Halyard to simply check that a TCP connection is openable. This information is typically transmitted to the platform's discovery system. |
| `host` | The host that this service will bind to. `0.0.0.0` will always work, but more restrictive bindings may be more secure. |
| `kubernetes` | You can add Kubernetes specific service settings, see details below. |
| `location` | The Spinnaker "location" this will be installed in. This is a namespace in Kubernetes, and a zone in GCE. |
| `monitored` | Whether or not this has monitoring endpoints exposed and understood by `spinnaker-monitoring`. |
| `overrideBaseUrl` | The baseURL this service is reachable on. This is already made configurable for Deck & Gate via `hal config security`, since these are both public-facing and may service from different hosts than they are discoverable on internal to Spinnaker. |
| `port` | The port number this service is bound to, and will accept requests on. |
| `safeToUpdate` | Whether or not this service can be shutdown, and spun on a new VM/container. This protects datastores like Vault & Redis from being taken down from Halyard. |
| `scheme` | The URI scheme for addressing this service, e.g. `http` vs. `https`. |
| `skipLifeCycleManagement` | Whether or not Halyard should skip managing a service's life cycle. |
| `targetSize` | The initial number of nodes this service will be created with. This is only respected on the initial deployment, and further edits will be rejected in favor of the prior service version's size. |

| Value | Description |
| ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `address` | The address other services will use to lookup this service; e.g. `localhost` or `redis.service.spinnaker.consul`. |
| `artifactId` | A fully-qualified identifier for the Artifact this service is to run - see your Service Settings output path for examples, since this varies by platform/deployment environment. |
| `basicAuthEnabled` | Whether or not to enable HTTP basic auth for this service. |
| `enabled` | Whether or not this service is enabled. Be careful, since disabling critical services like `consul-client` can make your entire installation unusable and un-upgradable. |
| `env` | Environment variables to make available to this Service. Supplied as YAML key-value pairs. |
| `healthEndpoint` | The HTTP endpoint that can be queried for health status. Leave empty if you want Halyard to simply check that a TCP connection is openable. This information is typically transmitted to the platform's discovery system. |
| `host` | The host that this service will bind to. `0.0.0.0` will always work, but more restrictive bindings may be more secure. |
| `kubernetes` | You can add Kubernetes specific service settings, see details below. |
| `location` | The Spinnaker "location" this will be installed in. This is a namespace in Kubernetes, and a zone in GCE. |
| `monitored` | Whether or not this has monitoring endpoints exposed. |
| `overrideBaseUrl` | The baseURL this service is reachable on. This is already made configurable for Deck & Gate via `hal config security`, since these are both public-facing and may service from different hosts than they are discoverable on internal to Spinnaker. |
| `port` | The port number this service is bound to, and will accept requests on. |
| `safeToUpdate` | Whether or not this service can be shutdown, and spun on a new VM/container. This protects datastores like Vault & Redis from being taken down from Halyard. |
| `scheme` | The URI scheme for addressing this service, e.g. `http` vs. `https`. |
| `skipLifeCycleManagement` | Whether or not Halyard should skip managing a service's life cycle. |
| `targetSize` | The initial number of nodes this service will be created with. This is only respected on the initial deployment, and further edits will be rejected in favor of the prior service version's size. |

### Kubernetes

Inside the `kubernetes` item at the top level you can add a number of custom service settings that impact how the Spinnaker services are deployed onto a Kubernetes cluster. This lets you partially configure how the Kubernetes `Deployment`, `Service`, `Pods` and other Kubernetes resources are deployed by Halyard. This allows you to do things like add a Kubernetes `secret` or `emptydir` to be mounted as a `Volume` and `VolumeMount`, change the default Kubernetes deployment strategy and more.
Inside the `kubernetes` item at the top level you can add a number of custom service settings that impact how the Spinnaker services are deployed onto a Kubernetes cluster. This lets you partially configure how the Kubernetes `Deployment`, `Service`, `Pods` and other Kubernetes resources are deployed by Halyard. This allows you to do things like add a Kubernetes `secret` or `emptydir` to be mounted as a `Volume` and `VolumeMount`, change the default Kubernetes deployment strategy and more.

At a high level, the configurable items inside the Kubernetes service settings are:

| Item | Details |
| ----- | ----------- |
| `deploymentStrategy` | Defines either `RollingUpdate` or `Recreate` deployment strategy, including setting `MaxSurge` and `MaxUnavailable` See [Deployment Strategy](#deployment-strategy) below. |
| `imagePullSecrets` | Define secrets to use to pull a custom artifact when using an artifactId to swap out docker image. More details can be found in the [Image Pull Secrets section](#imagepullsecrets). |
| `nodePort` | When using a serviceType of NodePort, this provides the NodePort value. |
| `nodeSelectors` | Provide a list of `nodeSelectors` key-value pairs to add to the pod specification. See [Node Selectors](#nodeselectors) below. |
| `affinity` | Provide a list of `affinity` rules applied to a Spinnaker component's pod specification. See [Affinity](#affinity) below. |
| `podAnnotations` | Provide a list of annotations to put on the deployed pods. See [Annotations and Labels](#podannotations-podlabels-and-serviceannotations-servicelabels) below. |
| `podLabels` | Provide a list of labels to put on the deployed pods. See [Annotations and Labels](#podannotations-podlabels-and-serviceannotations-servicelabels) below. |
| `securityContext` | Set the securityContext that the Spinnaker services should run using in Kubernetes |
| `serviceAnnotations` | Provide a list of annotations to put on the deployed services. See [Annotations and Labels](#podannotations-podlabels-and-serviceannotations-servicelabels) below. |
| `serviceLabels` | Provide a list of labels to put on the deployed services. See [Annotations and Labels](#podannotations-podlabels-and-serviceannotations-servicelabels) below. |
| `serviceAccountName` | Provide a default `serviceAccount` under which to run Spinnaker services. |
| `serviceType` | Define a specific serviceType for deployed services, `ClusterIP` (Default) or `NodePort` |
| `useExecHealthCheck` | Disable the exec-based healthcheck if necessary. See [useExecHealthCheck](#useexechealthcheck) for details. |
| `volumes` | Define a set of `Volume` and `VolumeMount` items to be attached to the Pods through the Deployment. See [Custom Volumes](#using-custom-volumes) |

| Item | Details |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `deploymentStrategy` | Defines either `RollingUpdate` or `Recreate` deployment strategy, including setting `MaxSurge` and `MaxUnavailable` See [Deployment Strategy](#deployment-strategy) below. |
| `imagePullSecrets` | Define secrets to use to pull a custom artifact when using an artifactId to swap out docker image. More details can be found in the [Image Pull Secrets section](#imagepullsecrets). |
| `nodePort` | When using a serviceType of NodePort, this provides the NodePort value. |
| `nodeSelectors` | Provide a list of `nodeSelectors` key-value pairs to add to the pod specification. See [Node Selectors](#nodeselectors) below. |
| `affinity` | Provide a list of `affinity` rules applied to a Spinnaker component's pod specification. See [Affinity](#affinity) below. |
| `podAnnotations` | Provide a list of annotations to put on the deployed pods. See [Annotations and Labels](#podannotations-podlabels-and-serviceannotations-servicelabels) below. |
| `podLabels` | Provide a list of labels to put on the deployed pods. See [Annotations and Labels](#podannotations-podlabels-and-serviceannotations-servicelabels) below. |
| `securityContext` | Set the securityContext that the Spinnaker services should run using in Kubernetes |
| `serviceAnnotations` | Provide a list of annotations to put on the deployed services. See [Annotations and Labels](#podannotations-podlabels-and-serviceannotations-servicelabels) below. |
| `serviceLabels` | Provide a list of labels to put on the deployed services. See [Annotations and Labels](#podannotations-podlabels-and-serviceannotations-servicelabels) below. |
| `serviceAccountName` | Provide a default `serviceAccount` under which to run Spinnaker services. |
| `serviceType` | Define a specific serviceType for deployed services, `ClusterIP` (Default) or `NodePort` |
| `useExecHealthCheck` | Disable the exec-based healthcheck if necessary. See [useExecHealthCheck](#useexechealthcheck) for details. |
| `volumes` | Define a set of `Volume` and `VolumeMount` items to be attached to the Pods through the Deployment. See [Custom Volumes](#using-custom-volumes) |

### imagePullSecrets

Expand Down Expand Up @@ -205,7 +205,6 @@ See [the Kubernetes affinity documentation](https://kubernetes.io/docs/concepts/
By default halyard deploys services with an `exec`-based health check in order to improve compatibility with Istio. This however can break functionality for implementations of Load Balancer service types and Ingress Controllers that rely on having an http health check to validate. Setting `kubernetes.useExecHealthCheck: false` will switch the check method to be http based for such use cases.
### Using Custom Volumes
You can define a set of custom volumes for a particular service that will become `Volume` and `VolumeMount` items in the generated pod specifications when Halyard deploys Spinnaker on Kubernetes. This can be useful if you need to add custom CA Certificates or other files to Spinnaker service consistently.
Expand All @@ -225,6 +224,7 @@ kubernetes:
type: emptyDir
mountPath: /path/to/location/of/emptyDir
```
Make sure that the `id` field matches the `name` of the existing `secret` or `configmap` resource in Kubernetes that you need mounted.
### Deployment Strategy
Expand Down
Loading

0 comments on commit 086ef13

Please sign in to comment.