Top File, File Structure, & Pillar Data - Getting Started With Salt Project - Part 4
Vložit
- čas přidán 29. 08. 2024
- Learn how to use Salt Project (aka Salt Stack) in our getting started series. Salt Project is a great tool for DevOps and SysAdmin's that will help you with Configuration Management, Automation, CI/CD, and so much more.
Start learning Salt Project with a lab on Linode with $100 credit: bit.ly/3tTTeRU
* Sponsored by Linode
Getting Started With Salt Project - Part 4 - Top File, File Structure, & Pillar Data
In this video we learn how to:
- advanced minion targeting in top file
- file/folder structure
- pillar data
Getting Started with Salt Project Playlist - • Getting Started With S...
If you have comments or questions about this video, or if you would like some help with your own Salt configuration, please leave us a comment below.
Salt Project
Salt Stack
Automation
Agile
DevOps
Configuration Management
CI/CD
Continuous Integration
Continuous Delivery/Deployment
Continuous Testing
Immutable Infrastructure
Infrastructure As Code
These have been super helpful to jumpstart my lab, thank you!
Best tutorial for salt. Please create more such videos on salt.
This really helped me a lot to understand Salt and it's configurations. Thanks a lot!!!!
This short series with several create-and-extend approaches really helped me making my very first steps with salt‘s basic structure with the root_files directory, top.sls and its highstates and states. Especially in terms of filesystem hierarchy, .sls- and .conf-files. This was a great addition to the official documentation.
I was now able to set up the download and installation of a 3rd party monitoring rpm-file on debian and ubuntu. Unfortunately, I am stuck on the installation of a local rpm (CheckMK-agent, based on nagios) on opensuse/SLES systems. Diving deeper into the salt topic with this series would be appreciated.
I personally know that creating these videos is combined with a lot of effort but increasing the scope of these tutorials in this deep diving manner will surely pay off in the long run. I‘ve seen several other channels but for me this was still the most understable and value-adding path.
Dear devopsclinic, please continue producing. You are needed right here! :-)
BR from germany 🐧
Hoping for more such salt videos
Great video, keep them coming!
Hey just watched this through, was very helpful. Looking for best practices and how to run in an enterprise environment regarding state management.
For each distribution you make a folder. Some people put code in the state file and using "if" statements to check the Os family. What is the best practice?
Do we have to wait until the end to find out what Salt states had been run? In Ansible we see every step. This is easy to follow what the orchestration tool is doing.
How works top.sls? If a match is found, it runs those salt states and then continues with the next match? Or is the top.sls first being analyzed and then being executed in sequential way or some parts in parallel.
With "require" you can put some dependencies between Salt states. First install a web server, then install some files and at last start the web server daemon. Could you also put dependencies between minion's? ex. first install a database server and then the application server?
I like very much your explanations about Salt! I learned a lot. Thank you very much to spend your time in making them!!!!
If you have something that applies to all distributions, then I would put all the distro related items in that same folder. I use distro specific folders for things that only apply to that specific distro.
In all the companies I've worked for, when I haven't used formulas, we usually only ever run a single distro.
As for seeing the outcome as it's happening, I've never had an issue with having to wait for it to complete. If I've written all my states and tested them both in my local environment, plus dev, then qa, then finally prod. They rarely break at that point.
When you run a state.apply with a specific state, it will evaluate everything that needs to happen for that state that you called. So if you call roles.webserver, it's only going to evaluate the /srv/salt/roles/webserver/ or /srv/salt/roles/webserver.sls. Plus it will also evaluate anything that we have "included". Once it figures out all the dependencies, Grains, Pillar, etc and has a plan it will execute the state.
If you were to run a state.apply without a specific state it will start at the top.sls and figure out everything that applies to the specific minion. So if a specific minion has both a roles.webserver and roles.database assigned to it, it will figure out all the states, dependencies, Grains, Pillar, etc and once it's all resolved will execute everything. Doing this is called the High State, starting from the top.sls and working your way through everything that applies.
Now, let's say you want to install roles.wordpress, roles.nginx, and roles.mysql. But for you to install Wordpress, you need the mysql database installed before hand so you can import the database. You could have a require that makes sure the roles.mysql is always the installed before Nginx and Wordpress, and Nginx before Wordpress.
We'll be going through more of these scenarios shortly.
Amazing
Hey, I really liked this video. Its really amazing and help full. I just want to ask about the pillars part. What are these and how to use them??
is there any privilege escalation in saltstack. I want to run salt command as a different user not root. What is the way to do this?