Skip to content

Instantly share code, notes, and snippets.

@zlanich
Last active August 5, 2016 02:06
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save zlanich/dd2626f10b9db837b597eae8a40fa91b to your computer and use it in GitHub Desktop.
Save zlanich/dd2626f10b9db837b597eae8a40fa91b to your computer and use it in GitHub Desktop.
- A profile for both my Staging and Production servers (for now, just single webservers, but later optional H/A)
- Environment Map for my Staging server(s)
- Environment Map specifically for my Production servers that each host a "Site"
- Pillars that apply to all servers, but "Site" specific pillars as well, each in their own SLS file
- States that apply to their relevant servers (Web, Database, etc)
- Orchestration file that basically heads up the "Applying" of my entire infrastructure state when things change, like adding a new site, re-syncing my connection between Staging/Prod sites for Database migrations, etc
For now, I would write these SLS and Map files by hand, but when I finally write my own GUI for managing these "Sites", I can create the objects, use a YAML encoder and write the YAML files programmatically
The other option down the road would be to write my own connector that delivers Salt Pillar Data, etc in the same way "Reclass" does.
I'd like your thoughts on my approach and if there are any red flags that you see.
P.S. I'm not using Peer to Peer Communication anymore. Hemebond, you're correct, I felt that was too direct too. I'm going to attempt to use a Orchestration to do a top-down overall state and then run the commands to get/set the Secret Keys for database migrations that way.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment