New to salt and looking for some guidance on best practices for workflows

[Brandon Kearns]

I am pretty new to SaltStack, but so far I think it is pretty awesome/powerful stuff. The issue I have now is sort of tying everything together in a maintainable/well-structured way, so I am hoping to get some insight and/or references regarding this. Here is some background info on my environment and what I want to achieve:

I have a Web application built on a number of servers/services - 3 MongoDB servers, 2 Java application servers, 1 NodeJS server, 1 ELK log server, and 1 Nginx server - all running in a VPC on AWS. So far I am able to use salt-cloud with map/profiles/provider to successfully create all those servers, and bootstrap them as salt-minions, even receive the "created" event using reactor.
What I need is to instruct the minions to update, install packages, setup RAID arrays, and manage some config files, etc.. right after creation, but only once. If I set all of that up in state files and have my reactor "created" event call highstate on all minions then it works, but calling highstate a second time would trigger those processes again.
I am sure I am missing something fundamental here, but I guess I am just confused if I should expect to maybe handle my state files in git repo and pull a different branch of state files down after the initial run (and each time I need to manage my minions)? Do I set a file on my minions to track that the initial run has been completed (if file exists don't do XYZ)? Any help pointing me in the right direction is very much appreciated here.

[Shane Gibson]

Brandon - we don't use Saltstack much for configuration management - but a couple of suggestions from my experience are as follows...

* insure all of your states you write are idempotent - if they change something - they *only* change it and then enforce *that one change* - this applies to installation/configuration tasks as well - it takes some careful work to insure your write states in an idempotent manner (true with all config management tools)

* instead of putting everything in your "top.sls" - you can create an "install.sls" or "prep.sls" (or whatever...) - and not include that in your top.sls - that way on highstate changes, it won't be invoked - then to simply invoke it - you can run it (any number of ways) via a direct call like: 

  salt '*' state.install_services

IN this vaguely crafted example ... "install_services" would be an SLS in the root named "install_services.sls".

There currently is the "overstate" system that was designed for setup/install purposes - but is being deprecated - VERY soon now.  I believe the methodologies and capabilities in "overstate" have been subsumed in to the general framework.  I'm not certain how you can utilize the "overstate" mechanisms going forward with "overstate" itself being deprecated ....

~~shane

[Brandon Kearns]

Shane,

Thanks for the response. I think that definitely adds some insight into how I need to approach my setups here. Again, I was at a point where I _could_ think of various ways to sort of make-it-work, but I wanted to get a feel for the best practices and suggestions - so I appreciate your input. I think what I really need to do is write all this out and re-plan what my requirements are moving forward. I think it comes down to (if I'm reading into your suggestions correctly) is separating my initial configurations as 1-off *.sls configurations that are invoked manually and only add things to the top.sls that I plan to be repeated in more of an automated manner with highstate triggers (and/or ensuring they are idempotent in nature)?

Thanks again.

--
You received this message because you are subscribed to a topic in the Google Groups "Salt-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/salt-users/1vl758KDr0s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to salt-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Colton Myers]

Yep, sounds like you're definitely on the right track. Another common workflow is using the state.orchestrate runner for initial setup and the highstate for maintenance. But yes, highstate should definitely be limited to idempotent, "can run any time to ensure status", states.

--

Colton Myers

Platform Engineer, SaltStack

@basepi on Twitter/Github/IRC

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.

[Brandon Kearns]

Colton,

Thanks for the reply. You pretty much just confirmed and validated what I have been working on recently which is to move all initial configuration over to the Reactor + Orchestration workflow and then use HighState or directly calling SLS states on minions for more passive management/maintenance workflows.