You can use jobs in Automation Config to simplify and automate common configuration management tasks and procedures that you or your team performs on a regular basis.
What are jobs in Automation Config?
Jobs are used to run remote execution tasks or apply state files to the nodes (minions) that are managed by Automation Config. Jobs are generally intended for system operations that need to be automated and run many times. You can create jobs to automate common tasks that you perform regularly as you provision, configure, deploy, monitor, and manage nodes in your system. You can also set up jobs to run on a regular schedule, such as jobs that regularly check for and prevent configuration drift.
You can save commonly repeated jobs and gradually build out a rich library of jobs for future reuse by your team. Using jobs for configuration management reduces the time your team spends manually installing, configuring, deploying, updating, and maintaining the nodes in your system.
Examples of common jobs
You could potentially run thousands of different kinds of jobs in Automation Config depending on your intended goals and purpose. After you identify what task you want to accomplish or what problem you need to solve, you can search the available Salt modules to find which modules perform the function you need.
Jobs in Automation Config usually incorporate one or more of the execution modules or state modules that have been developed by the Salt open source community. Salt execution modules are small programs containing Python code that can run on a Salt minion and perform a specific task. Salt state modules are similar to execution modules. Salt state modules are programs containing Python code that can be used inside Salt state files to manage the application of a state to a minion.
The following table shows some of the most commonly used execution and state modules:
| Salt module | Description |
|---|---|
| A module that applies a state file to a minion. When the state file runs, it checks to see if the minion is in the current desired state. If the minion is not in the current desired state, it runs the commands and modules to put that minion into the desired state. A highstate applies all states defined in the top file. See state.highstate for more information. |
|
| A state module (meaning it is used in state files) that checks whether the correct version of a package is installed. If it is not installed, it installs a package and ensures that it is the correct version of that package. See salt.states.pkg for more information about installing packages with certain operating systems. |
|
| A state module (meaning it is used in state files) that downloads a file from the Salt master and places that file on the targeted minions for later use. See salt.states.file for more information about managing files with Salt. |
|
| A state module (meaning it is used in state files) that checks whether a service is running. If the service is not running, it starts the service. See salt.states.service for more information about starting or restarting services with Salt. |
See the Salt module index for more a comprehensive list of Salt execution and state modules.
If Salt doesn't have a module that you need, you can extend Salt by writing your own custom modules in Python. If desired, you can also submit that module upstream to the Salt Project. Officially sponsored by VMware, the Salt Project community includes more than 3,000 contributors working in IT and system administration roles. The Salt community extends Salt by creating a variety of execution and state modules to accomplish the most common tasks or solve the most important problems that system administrators face.
Overview of the jobs workflow
In general, a senior system administrator creates, configures, and saves job settings for later reuse. Then, the senior administrator can authorize a junior administrator to run this job on any nodes (targets) that the junior administrator is authorized to access. When creating a job, the senior administrator defines the job inputs, which refers to the specific job settings or variables the junior administrator can change at runtime.
For example, a senior system administrator might build a job that creates and deploys a virtual machine and installs a base set of applications or services on that machine. This job could be run every time a new virtual machine needs to be deployed to ensure the same set of applications and configurations are applied to every deployment. After creating this basic job, the senior system administrator could give access to a junior administrator run this job on the targets (nodes) they have permission to access. Using the role-based access controls (RBAC) in Automation Config and guided by principle of least privilege, the senior administrator can determine which jobs a junior administrator can run and on which nodes (minions).
Creating and running jobs is a multi-step process that requires using a few different tools and workspaces in Automation Config. The following diagram provides an overview of the overall job workflow:
Each step is described in the following articles:
