SaltStack Use Cases
-
@scottalanmiller said in SaltStack Use Cases:
@aaronstuder said in SaltStack Use Cases:
@scottalanmiller said in SaltStack Use Cases:
@DustinB3403 said in SaltStack Use Cases:
What I feel like would be useful would be PDQ Deploy / GPO - Godmode all in one solution. But every time someone explains their use of SaltStack I immediately think to my self that it is not what I need.
So I use it for every time that I need to deploy a new module or piece of software. Someone needs something, just stick it in the salt file. I do this constantly. I'm on my laptop and I have the state files locally. They are in a directory that opens all at once in Atom (my editor of choice.) All I do is add that software item to the right state file and save... done.
I have it set to upload the state files to GitLab, which is free, and my Salt Master pulls updates from GitLab every fifteen minutes or so. So my laptop changes flow straight to the servers, automatically.
Very Nice Setup
It's new, and I love it.
You should share
-
Will be monitoring this thread like:
http://cdn.bloody-disgusting.com/wp-content/uploads/2015/12/halloween_1978_still.jpg
Also does it really work in Windows environments like it does on Linux, it seems like SaltStack and its brothers (Chef, Ansible, I forgot one) are tailored for Linux, and I dont want the master/server to be on Windows, that will be redundant I mean passing commands to Windows agents, and is their template library with commands where we can see what we can do under Windows.
-
@msff-amman-Itofficer said in SaltStack Use Cases:
is their template library with commands where we can see what we can do under Windows.Link?
-
@msff-amman-Itofficer said in SaltStack Use Cases:
Will be monitoring this thread like:
Also does it really work in Windows environments like it does on Linux, it seems like SaltStack and its brothers (Chef, Ansible, I forgot one) are tailored for Linux, and I dont want the master/server to be on Windows, that will be redundant I mean passing commands to Windows agents, and is their template library with commands where we can see what we can do under Windows.They do work for windows, the don't have all the modules for Windows yet but they have a pretty good selection.
win_acl - Set file/directory permissions for a system user or group. win_acl_inheritance - Change ACL inheritance win_chocolatey - Installs packages using chocolatey win_command - Executes a command on a remote Windows node win_copy - Copies files to remote locations on windows hosts. win_disk_image - Manage ISO/VHD/VHDX mounts on Windows hosts win_dns_client - Configures DNS lookup on Windows hosts win_domain - Ensures the existence of a Windows domain. win_domain_controller - Manage domain controller/member server state for a Windows host win_domain_membership - Manage domain/workgroup membership for a Windows host win_dotnet_ngen - Runs ngen to recompile DLLs after .NET updates win_environment - Modifies environment variables on windows hosts. win_feature - Installs and uninstalls Windows Features on Windows Server win_file - Creates, touches or removes files or directories. win_file_version - Get DLL or EXE file build version win_find - return a list of files based on specific criteria win_firewall_rule - Windows firewall automation win_get_url - Fetches a file from a given URL win_group - Add and remove local groups win_iis_virtualdirectory - Configures a virtual directory in IIS. win_iis_webapplication - Configures IIS web applications. win_iis_webapppool - Configures an IIS Web Application Pool. win_iis_webbinding - Configures a IIS Web site. win_iis_website - Configures a IIS Web site. win_lineinfile - Ensure a particular line is in a file, or replace an existing line using a back-referenced regular expression. win_msg - Sends a message to logged in users on Windows hosts. win_msi - Installs and uninstalls Windows MSI files win_nssm - NSSM - the Non-Sucking Service Manager win_owner - Set owner win_package - Installs/Uninstalls an installable package, either from local file system or url win_path - Manage Windows path environment variables win_ping - A windows version of the classic ping module. win_psexec - Runs commands (remotely) as another (privileged) user win_reboot - Reboot a windows machine win_reg_stat - returns information about a Windows registry key or property of a key win_regedit - Add, change, or remove registry keys and values win_region - Set the region and format settings win_regmerge - Merges the contents of a registry file into the windows registry win_robocopy - Synchronizes the contents of two directories using Robocopy. win_say - Text to speech module for Windows to speak messages and optionally play sounds win_scheduled_task - Manage scheduled tasks win_service - Manages Windows services win_share - Manage Windows shares win_shell - Execute shell commands on target hosts. win_shortcut - Manage shortcuts on Windows win_stat - returns information about a Windows file win_tempfile - Creates temporary files and directories. win_template - Templates a file out to a remote server. win_timezone - Sets Windows machine timezone win_unzip - Unzips compressed files and archives on the Windows node win_updates - Download and install Windows updates win_uri - Interacts with webservices. win_user - Manages local Windows user accounts win_webpicmd - Installs packages using Web Platform Installer command-linesalt.states.win_certutil module salt.states.win_dacl salt.states.win_dism module salt.states.win_dns_client salt.states.win_firewall salt.states.win_iis module salt.states.win_lgpo module salt.states.win_license module salt.states.win_network salt.states.win_path salt.states.win_pki module salt.states.win_powercfg salt.states.win_servermanager salt.states.win_smtp_server module salt.states.win_snmp module salt.states.win_system salt.states.win_updateSpeaking about ansible and saltstack the master/control node only runs on Linux.
-
So I can't answer for Salt since I don't use it, but I use Ansible for everything. For example, I have a separate DHCP and DNS server. Records are held in a YAML dictionary and when I need to add a machine, I add the DNS info and mac address and Ansible sets up the DHCP reservation on one machine and the DNS record in the other.
I also use it for kickstart configs. Instead of Foreman or Cobbler, Ansible has a Jinja2 kickstart template. When I run the playbook, Ansible creates all of the kickstart configs for all of the machines in the same dictionary as above and then creates PXE boot files based on the MAC address for each machine.
Ansible is pretty awesome with cloud services also. Dynamic inventories means you don't need to keep track of static inventories for your playbooks. Ansible can use any kind of script to get an inventory from AWS, DO, OpenStack, etc. As long as it returns JSON, your inventory is now the actual machines in your provider.
-
@msff-amman-Itofficer said in SaltStack Use Cases:
Will be monitoring this thread like:
http://cdn.bloody-disgusting.com/wp-content/uploads/2015/12/halloween_1978_still.jpg
Also does it really work in Windows environments like it does on Linux, it seems like SaltStack and its brothers (Chef, Ansible, I forgot one) are tailored for Linux, and I dont want the master/server to be on Windows, that will be redundant I mean passing commands to Windows agents, and is their template library with commands where we can see what we can do under Windows.
Not tailored for any specific OS. Windows works fine.
-
@fuznutz04 said in SaltStack Use Cases:
So this could also be useful for copying files to many servers at once from the central master I assume. For example, all minions need to have copies of source files that are updated from a central point. This could be used to push updates to all minions at once. Correct?
Yes. Or to tell them to all grab updates from somewhere.
-
Interesting thanks...
-
Generic answer:
basically Ansible, Salt, etc... are configuration managers. To understand when to use them, let say this:you want to deploy a machine (VM/physical, even a desktop)
a) you do it. so ok, next time you have to do the same task you have to remember what you did - and if the platform will change (run a web server on a different OS/distribution) you have to deal with the differences time per time.
b) as above, but you write all the steps (especially the tricky ones) on a file, so next time you have just to follow instructions and everything should be in place. Still OS is a matter but you can follow the quirks in your paperwrites.
c) you go over and you "drop" the minutes in favour of a script (shell/powershell etc...) which - if well laid out, will automagically re-deploy the machine again and again and again with a lot of custom if/else logic...or...
d) as above, but you do it with a CM script.
It is all about how much reproducibility, automation and platform independence(°) and standardization is a requisite for your job.
(°) you have to deal with platform at writing time, not at run time. Also idempotency is not always attained with windows PS things.Personal example:
Recently, I've migrated my VMs from KVM to hyper-v, rather than do anything else, I've used the existent VMs as a target and I've tried to reach the same objective by using fresh installs on hyper-v and Ansible scripts for deployments. My playbooks (ansible code) are still rude but I push them on bitbucket with git and I will be sure that next time I'll need a VM (even for testing) I will be able to fire a script and get exactly the same env. -
also related: CM vs GPO comparison for Windows. Here the CM is DSC.
-
-
@scottalanmiller Why not just rsync directly to the master? You want versioning?
-
@aaronstuder said in SaltStack Use Cases:
@scottalanmiller Why not just rsync directly to the master? You want versioning?
Yes, and multiple users, and a central repository.
