CODEWITHSUNDEEP
gitsalt-project
dtoux
dtoux

Reputation: 1884

Repository structure for a saltstack project

I'm starting on a new project and I'd like to use SaltStack for managing a large deployment spanning several datacenters. Everything runs on Linux. I had previous experience with Chef but I relatively new to SaltStack. My goal is to keep the entire project in a single git repository and make SaltStack to pull configurations from this repository and apply it to minions. It seems that SaltStack have no notion of versioning but serving content from different branches in the repository would work even better. So, I was thinking to create a git repository of the following structure:

salt -+- config (for salt-master config files)
      +- states
      +- pillars
      +- reactors
      +- formulas

and use different branches for dev, qa and prod environments. I also would like to use pillars for providing datacenter specific configuration and I was thinking to use GitFS to glue everything together.

However, there are those pesky top.sls files that handled in a very peculiar way, do not fit in this picture and eventually break this concept.

There also configuration files that I'd like to keep in this repository but I have no better idea for now other then manually copy or symlink them to under /etc/salt from the config directory.

I went through documentation several times and did some experimentation in a simulation environment but I couldn't come up with any sensible project layout yet, so I'm reaching to the stackoverflow community.

My questions are:

  1. Could anybody share a repository structure and configuration they successfully used for managing a similar environment?
  2. Have anybody figured out a good way for maintaining configuration files?

Upvotes: 11

Views: 2299

Answers (2)

Eric_H
Eric_H

Reputation: 35

I'm working in AWS, and am using the boto_* suite to provision my machines. Their userdata scripts set grains to aid the top file, then install, configure, and start salt minion, which then asks the master for highstate execution.

I have a similar repository structure to you, except that I've broken my state dirs into 'provision' and 'config'.

I'm on my phone at the moment, but let me know if the approach sounds at all relevant, and I can further flesh it out once I'm back on my laptop.

Upvotes: 0

David Eyk
David Eyk

Reputation: 12521

It sounds like you're headed in a reasonable direction. We don't have quite as large an operation as you (e.g. we don't use multiple environments as yet, just base; we don't use reactors, etc.), but we've got a similar layout to our main states repo.

Here are a few practices we've adopted:

Self-deploying

We use a Fabric script to deploy configuration and updated states/pillars from the repository to the salt-master. The Fabric script also has tasks to bootstrap a new machine w/ salt-minion and automate the key exchange w/ the master.

We could use GitFS, I suppose, but I had some trouble getting it set up and applying updated changesets reliably. In theory, you could bootstrap salt to deploy itself, but in practice a separate, limited deployment process has been good enough.

Segregated secrets

We keep all "secrets" in separate repositories as pillar files, to keep them out of our main repository. Our deploy script checks these out and deploys them to the correct place in our /srv/pillar tree on salt-master. This allows us to keep sensitive data (passwords, key pairs, etc.) out of our main repository. We use salt to provision Vagrant VMs on developer machines, so "development secrets" are stored in the main repository.

Upvotes: 2

Related Questions