Easier guide to setup Salt Stack/Ansible for Windows environment ?
-
Salt has no interface. Running a Salt state file is as simple as...
salt '*' state.apply -
It's all about the text files
-
@scottalanmiller said in Easier guide to setup Salt Stack/Ansible for Windows environment ?:
Salt has no interface. Running a Salt state file is as simple as...
salt '*' state.applyI see.
-
@StrongBad said in Easier guide to setup Salt Stack/Ansible for Windows environment ?:
It's all about the text files
@StrongBad @scottalanmiller
So maybe I am not looking for something I need to play with Text files or Command lines only
Do we have any GUI (web or desktop app) option is this category ?
-
@openit said in Easier guide to setup Salt Stack/Ansible for Windows environment ?:
@StrongBad said in Easier guide to setup Salt Stack/Ansible for Windows environment ?:
It's all about the text files
@StrongBad @scottalanmiller
So maybe I am not looking for something I need to play with Text files or Command lines onlyDo we have any GUI (web or desktop app) option is this category ?
I know of a developer here in Dallas that is working on a Salt GUI. Ansible has Tower, which I have not used but I know of people who really like... I'll tag @stacksofplates here.
-
A GUI for this sort of thing is a bit difficult because you have to figure out what you would want a GUI to do. Certainly GUIs are possible, but the nature of state systems makes GUIs both difficult and not as useful as with many other things. For example, a task like state.apply is so trivial at the command line that sure, you could make a button for that, and I know people who have, but it's not very valuable. I keep that command in my command history and have it run before a GUI would even load - so the GUI isn't useful enough there and would take too much effort to install or access.
For other tasks, like package lists, what value would a GUI bring? Would it list millions of possible packages that you have to scroll through to check box? Would it be GUI that just makes you type in the list the same as you would without a GUI? The GUI could make a check box list for your machines to which to apply the packages, but the same issues would apply - either the list is super short and the GUI pointless or the list is long and the GUI cumbersome.
Don't get me wrong, there are reasons for a GUI, but I think any really powerful GUI, beyond some really basic functionality, will end up dictating how and what you can do and become a platform of its own.
-
@scottalanmiller said in Easier guide to setup Salt Stack/Ansible for Windows environment ?:
A GUI for this sort of thing is a bit difficult because you have to figure out what you would want a GUI to do. Certainly GUIs are possible, but the nature of state systems makes GUIs both difficult and not as useful as with many other things. For example, a task like state.apply is so trivial at the command line that sure, you could make a button for that, and I know people who have, but it's not very valuable. I keep that command in my command history and have it run before a GUI would even load - so the GUI isn't useful enough there and would take too much effort to install or access.
For other tasks, like package lists, what value would a GUI bring? Would it list millions of possible packages that you have to scroll through to check box? Would it be GUI that just makes you type in the list the same as you would without a GUI? The GUI could make a check box list for your machines to which to apply the packages, but the same issues would apply - either the list is super short and the GUI pointless or the list is long and the GUI cumbersome.
Don't get me wrong, there are reasons for a GUI, but I think any really powerful GUI, beyond some really basic functionality, will end up dictating how and what you can do and become a platform of its own.
Ya I can't speak for the Salt GUI but Tower doesn't write your playbook for you. It's just a GUI for scheduling runs, adding extra variables, auditing, etc. You can run ad-hoc commands from it so you only need one audit location and one user on remote machines.
But with tower-cli, I think most people that use the GUI are auditors.
-
@stacksofplates said in Easier guide to setup Salt Stack/Ansible for Windows environment ?:
@scottalanmiller said in Easier guide to setup Salt Stack/Ansible for Windows environment ?:
A GUI for this sort of thing is a bit difficult because you have to figure out what you would want a GUI to do. Certainly GUIs are possible, but the nature of state systems makes GUIs both difficult and not as useful as with many other things. For example, a task like state.apply is so trivial at the command line that sure, you could make a button for that, and I know people who have, but it's not very valuable. I keep that command in my command history and have it run before a GUI would even load - so the GUI isn't useful enough there and would take too much effort to install or access.
For other tasks, like package lists, what value would a GUI bring? Would it list millions of possible packages that you have to scroll through to check box? Would it be GUI that just makes you type in the list the same as you would without a GUI? The GUI could make a check box list for your machines to which to apply the packages, but the same issues would apply - either the list is super short and the GUI pointless or the list is long and the GUI cumbersome.
Don't get me wrong, there are reasons for a GUI, but I think any really powerful GUI, beyond some really basic functionality, will end up dictating how and what you can do and become a platform of its own.
Ya I can't speak for the Salt GUI but tower doesn't write your playbook for you. It's just a GUI for scheduling runs, adding extra variables, auditing, etc. You can run ad-hoc commands from it so you only need one audit location and one user on remote machines.
But with tower-cli, I think most people that use the GUI are auditors.
And that is the kind of stuff that I think is being worked on for Salt. You could have a handy web editor for the files or something. You could maybe have it automatically make folder hierarchies for you and auto-sync to GIT and stuff like that, but it would be pretty basic.
I use an Atom editor and a one line GIT commit command and the combination makes a GUI pretty much unneeded. The whole Salt hierarchy is presented in a GUI on the left and I have a modern editor for complex files.
-
@scottalanmiller said in Easier guide to setup Salt Stack/Ansible for Windows environment ?:
@stacksofplates said in Easier guide to setup Salt Stack/Ansible for Windows environment ?:
@scottalanmiller said in Easier guide to setup Salt Stack/Ansible for Windows environment ?:
A GUI for this sort of thing is a bit difficult because you have to figure out what you would want a GUI to do. Certainly GUIs are possible, but the nature of state systems makes GUIs both difficult and not as useful as with many other things. For example, a task like state.apply is so trivial at the command line that sure, you could make a button for that, and I know people who have, but it's not very valuable. I keep that command in my command history and have it run before a GUI would even load - so the GUI isn't useful enough there and would take too much effort to install or access.
For other tasks, like package lists, what value would a GUI bring? Would it list millions of possible packages that you have to scroll through to check box? Would it be GUI that just makes you type in the list the same as you would without a GUI? The GUI could make a check box list for your machines to which to apply the packages, but the same issues would apply - either the list is super short and the GUI pointless or the list is long and the GUI cumbersome.
Don't get me wrong, there are reasons for a GUI, but I think any really powerful GUI, beyond some really basic functionality, will end up dictating how and what you can do and become a platform of its own.
Ya I can't speak for the Salt GUI but tower doesn't write your playbook for you. It's just a GUI for scheduling runs, adding extra variables, auditing, etc. You can run ad-hoc commands from it so you only need one audit location and one user on remote machines.
But with tower-cli, I think most people that use the GUI are auditors.
And that is the kind of stuff that I think is being worked on for Salt. You could have a handy web editor for the files or something. You could maybe have it automatically make folder hierarchies for you and auto-sync to GIT and stuff like that, but it would be pretty basic.
I use an Atom editor and a one line GIT commit command and the combination makes a GUI pretty much unneeded. The whole Salt hierarchy is presented in a GUI on the left and I have a modern editor for complex files.
Ya I use Atom with Git-Plus. Less typing for commits and I don't have to leave the app. The project directory is set up in Atom. Ansible has a tool called galaxy that will create the folder structure and files automatically. Then I have a Gitlab runner that does syntax checks and then runs the playbook. Gitlab let's me know whether everything passes or fails and then I can push to master. Then have tower run the playbook. The other advantage to tower is what Scott mentioned. It will do either a pull or fetch before the run. You don't have to do that manually like if you were just running from anAnsible server.
-
@stacksofplates said in Easier guide to setup Salt Stack/Ansible for Windows environment ?:
The other advantage to tower is what Scott mentioned. It will do either a pull or fetch before the run. You don't have to do that manually like if you were just running from anAnsible server.
We use a cron job for that.
-
@scottalanmiller said in Easier guide to setup Salt Stack/Ansible for Windows environment ?:
@stacksofplates said in Easier guide to setup Salt Stack/Ansible for Windows environment ?:
The other advantage to tower is what Scott mentioned. It will do either a pull or fetch before the run. You don't have to do that manually like if you were just running from anAnsible server.
We use a cron job for that.
Ya you can do that. This is nice though because you don't have to add the logic to keep runs from bumping into each other. And it all goes into the auditing system built into Tower.
