Version control config


#1

What are the best practices around storing the config in version control and deploying config updates as part of the CD pipeline?

What I want to achieve is a way for any dev to make changes to the configuration and for that change to be reviewed before being released.

I’ve seen a lot about using the backup and sharing the artifact but this doesn’t let us review the changes.

The main problem I see with just storing the config yaml is the paths of service accounts. Is there a solution to this problem?


#2

Hi Jamie

Thanks for reaching out! A couple of questions to make sure I’m understanding your use case correctly:

  • Are you looking to use/using Halyard? If so, is this about storing the Halyard config?
  • Are the “paths of service accounts” you’re referring to file paths to credential files?
  • Is the configuration you’re looking to allow devs to change the configuration of Spinnaker itself, or of a service/application that is deployed using Spinnaker? If the former, what kinds of changes to you anticipate developers needing to make?

Regards

ap


#3

Ideally I’d like to use Halyard but I’m not against setting up Spinnaker manually.

Yes I am referring to the credential file paths.

Allow devs to change the configuration of Spinnaker itself. Changes might be adding new environments as different teams have different requirements such as GCP/AWS or VMs/K8s and these requirements are changing all the time.

Thanks
Jamie


#4

Thanks for clarifying! In that case, you may want to consider the following ideas. There’s certainly still parts there that can be improved (suggestions or PRs welcome, of course!), but hopefully they’ll at least get you started…

If you’re already using Helm for other services and have found a way to handle sensitive input to Helm charts that you’re happy with, you may want to look at the lastest Spinnaker Helm chart, which uses Halyard internally.

Otherwise, you could:

  • Keep your halconfig in a code repository, using password files rather than passwords to avoid leaking credentials
    • A small number of Spinnaker account types don’t support password files as yet; that’s being worked on. A workaround for now is “patch” the halconfig just before it’s applied - see below
  • Optionally, configure a build job to run on pull requests that runs “hal config” against the proposed halconfig, with (potentially dummy) password files at the locations referenced in halconfig
  • On merge to master, a build job runs “hal deploy apply” using the updated halconfig, this time using password files containing the correct values, mounted at the locations referenced in the halconfig
  • You may still want to consider making a backup TAR of the halconfig after it’s successfully applied, since that archive is not dependent on any external files (such as the password files) and is thus slightly safer for emergency restores and audit purposes. The backup should be stored in a locked-down location.
  • The repository containing your halconfig could also include definitions of Applications, or other configuration items in Spinnaker that are part of your standard setup
  • You can use the spin CLI to create or update these in the same build job that runs on merge to master, after “hal deploy apply”
    • If you’re using Fiat, we recommend that you create a robot account for this, store its credentials in a password file as for Halyard, and mount this file as “~/.spin/config” when running the build job

Regards

ap