ripple.fm helm charts

This repo contains the helm charts and helmfile used to deploy ripple.fm and other required services on a kubernetes cluster.

The master branch reflects the current state of the cluster running ripple.fm in production

Table of Contents

• Prerequisites
• Technologies
• Development
  • Initializing helm on the cluster
  • Setting up helm secrets
  • Setting chart values
  • Changing secret values
• Deployment
  • Travis CI
  • Manual

Prerequisites

• kubernetes cluster (minikube works)
• helm installed locally with the helm-diff and helm secrets plugins
• helmfile

Technologies

• helm
• helm secrets to encrypt and decrypt helm values. Allows us to keep encrypted secrets and keys in version control
• helmfile to easily configure and manage multiple helm charts
• traefik as an ingress controller for ripple.fm services

Development

Initializing helm on the cluster

If you have helm properly installed on your cluster you can skip this step.

We must first initialize helm to work with our cluster. We defined RBAC resources for tiller here which we apply to our cluster using the following command:

$ kubectl create -f tiller-rbac.yaml

Now that the cluster knows about the roles we can tell helm to install tiller with the correct service account:

$ helm init --service-account tiller

Setting up helm secrets

Helm secrets uses PGP keys to encrypt sensitive values in our yaml files. We can import a PGP key using the following command:

$ gpg --import key.asc

Setting chart values

The majority of the coniguration for ripple.fm services is located here. The default values should work fine but you'll probably want to change url.protocol and url.baseDomain.

Secrets

Sensitive values are stored in the encrypted file values/secrets.yaml. We can create our own secret values by renaming the values/secrets.example.yaml file to values/secrets.yaml and providing our values. After we provide our secrets we must encrypt the values/secrets.yaml file so that changes can be tracked in version control:

$ helm secrets enc values/secrets.yaml

SSL Keys

The configuration for ripple.fm also requires a public and private RSA key pair, an example is provided here.

We'll rename this file to values/ssl.yaml and change the values for the keys (generate and paste (or paste existing) the RSA keys into values/ssl.yaml). After changing the values we must encrypt the file so that it can be tracked in version control:

$ helm secrets enc values/ssl.yaml

Station Templates

We then

ripple.fm also allows for providing templates for stations to be seeded and started with autoplayers. The station_templates.example.yaml provides a basic example file which we must rename to values/station_templates.yaml. After renaming (and optionally editting) the file we must encrypt it:

$ helm secrets enc values/station_templates.yaml

The example templates file provides a few stations that can be seeded but you may edit it to add more custom stations.

Changing secret values

Secrets are stored as encrypted files in version control (example). If you need to update or add values to the secret files follow these steps:

1. Ensure you have the correct PGP keys configured
2. Decrypt the secret file you wish to work with:

   $ helm secrets dec values/$MY_FILE.yaml

3. The file will be decrypted and available as values/$MY_FILE.yaml.dec. Edit the .yaml.dec file and make the required changes
4. Encrypt the updated file:

   $ helm secrets enc values/$MY_FILE.yaml

5. Commit the newly encrypted file to version control

Deployment

Travis CI

The state declared in the master branch of this repository reflects the state on the production Kubernetes cluster. Whenever a pull request is made travis-ci will run a build which will log the output of helmfile diff and show the comparison of the declared state and the production state.

Once a pull request is merged into the master branch, travis-ci will run a build which executes helmfile apply and updates the desired cluster state.

Manual

Although it is not recommended, we can manually view or change the state of the cluster:

1. Ensure your kubeconfig is pointed to the desired cluster and you can succesfully run kubectl get nodes
2. Compare declared state with existing cluster state:

   $ helmfile diff

3. Apply changes from above step to cluster state:

   $ helmfile apply

More information on manual deployment available here.