Category: saltstack

SaltStack – Configuration Management ”; Previous Next Configuration management is one of the most significant concept in SaltStack. It is used to create a reusable configuration template, called a state. The state describes everything required to put a system component or an application into a known configuration. Salt State Salt state is a reusable configuration for a specific part of a system. States are easier to understand and described using a simple YAML. Create a Salt State Salt states are easy to create. Let us create a simple state in this chapter. Move to the directory “salt-vagrant-demo/saltstack/salt/” and create a file named samples.sls and add the following lines in it. samples.sls install_network_packages: pkg.installed: – pkgs: – rsync – lftp – curl Now, save the file and run the following command in the Salt master. root@saltmaster:/home/vagrant# salt ”minion1’ state.apply samples Here, we installed rsync, lftp and curl through the pkg.installed module using the Salt state in a salt minion, minion1. If it works properly, you could see the response as shown below. It will produce the following output − minion1: ———- ID: install_network_packages Function: pkg.installed Result: True Comment: All specified packages are already installed Started: 08:08:48.612336 Duration: 545.385 ms Changes: Summary for minion1 ———— Succeeded: 1 Failed: 0 ———— Total states run: 1 Total run time: 545.385 ms Apply Salt State Now that we have created a state using the ‘.sls’ file and applied it by specifically calling it. Salt has a default state file called as the top.sls file. The top file is used to apply multiple state files to Salt minions. The top file describes where states should be applied. Well, States and the Top file work together to create the core of SaltStack’s configuration management capability. Let us now create a simple top.sls file in the directory saltstack/salt and add the following. top.sls base: ”*”: – common ”minion1”: – samples Here, the state, commonly applies to all system state, samples applies to minion1. Next, run the Salt master and apply the state as shown below. root@saltmaster:/home/vagrant# salt ”*” state.apply It will produce the following output − minion1: ———- ID: common_packages Function: pkg.installed Result: True Comment: All specified packages are already installed Started: 09:33:35.642355 Duration: 588.21 ms Changes: Summary for minion1 ———— Succeeded: 1 Failed: 0 ———— Total states run: 1 Total run time: 588.210 ms minion2: ———- ID: common_packages Function: pkg.installed Result: True Comment: All specified packages are already installed Started: 09:33:35.890331 Duration: 602.79 ms Changes: Summary for minion2 ———— Succeeded: 1 Failed: 0 ———— Total states run: 1 Total run time: 602.790 ms Apply Batch Size If you have a large number of connected minions, then you can limit how many systems are updated at once. It is performed by using the –batch-size option, which is defined below. root@saltmaster:/home/vagrant# salt –batch-size 5 ”*” state.apply It will produce the following output − Executing run on [”minion2”, ”minion1”] jid: 20170314094638482664 minion1: ———- ID: common_packages Function: pkg.installed Result: True Comment: All specified packages are already installed Started: 09:46:41.228519 Duration: 582.24 ms Changes: Summary for minion1 ———— Succeeded: 1 Failed: 0 ———— Total states run: 1 Total run time: 582.240 ms retcode: 0 jid: 20170314094638482664 minion2: ———- ID: common_packages Function: pkg.installed Result: True Comment: All specified packages are already installed Started: 09:46:41.153609 Duration: 605.235 ms Changes: Summary for minion2 ———— Succeeded: 1 Failed: 0 ———— Total states run: 1 Total run time: 605.235 ms retcode: 0 Salt State Functions Salt state functions are used to install and configure applications on your remote system. Let us install a “Vim” package using the Salt state function. Create and Apply State Function Create a file named “sample.sls” under the directory “salt-vagrant-demo/saltstack/salt/sample.sls” and add the following − sample.sls install vim: pkg.installed: – name: vim Once, Vagrant environment is up, run the salt master and apply the sample.sls by running the following command. root@saltmaster:/home/vagrant# sudo salt ”minion2’ state.apply sample It will produce the following output − minion2: ———- ID: install vim Function: pkg.installed Name: vim Result: True Comment: Package vim is installed Started: 15:07:45.752764 Duration: 553.506 ms Changes: Summary for minion2 ———— Succeeded: 1 Failed: 0 ———— Total states run: 1 Total run time: 553.506 ms Now, we have added a package “Vim”. Let us now test the package using the Salt testing method. Salt State Testing The test run is mandated by adding the “test = True” option to the states. The return information will show states that will be applied in yellow and the result is reported as ‘None’. The following command is used to test the state − root@saltmaster:/home/vagrant# sudo salt ”minion2’ state.apply sample test = True It will produce the following output − minion2: ———- ID: install vim Function: pkg.installed Name: vim Result: True Comment: Package vim is already installed Started: 15:07:45.752764 Duration: 553.506 ms Changes: Summary for minion2 ———— Succeeded: 1 Failed: 0 ———— Total states run: 1 Total run time: 553.506 ms SaltStack ─ Pillar Component Pillar is an essential component to make Salt states reusable. It is used to define secure data for minions assigned using targets. Salt pillar data stores values such as ports, file paths, configuration parameters and passwords. Pillar config File The configuration for the pillar_roots in the master config file is shown below − pillar_roots: base: – /srv/pillar Here, the file is in the “/srv/pillar” directory. Consider, the top file located in /srv/pillar/top.sls has the following structure − base: ”*”: – default Now, move to the default.sls file located in /srv/pillar/default.sls and add the following code. # Default pillar values apache git After saving the file, refresh the pillar to update all the changes. Refreshing the Pillar You can refresh the pillar using the following command. root@saltmaster:/home/vagrant# salt ”*” saltutil.refresh_pillar The above command is used to refresh the Salt pillar data on all the minions. List Pillar Data To list out the pillar data, you can use the command given below. root@saltmaster:/home/vagrant# salt ”*” pillar.ls It will produce the following output − minion2: – apache – git minion1: – apache –

SaltStack – Quick Guide ”; Previous Next SaltStack – Overview In this chapter, we will learn the basics of SaltStack. SaltStack’s remote execution capabilities allow administrators to run commands on various machines in parallel with a flexible targeting system. Salt configuration management establishes a master-minion model to quickly, very easily, flexibly and securely bringing infrastructure components in line with a given policy. What is SaltStack? Salt is a very powerful automation framework. Salt architecture is based on the idea of executing commands remotely. All networking is designed around some aspect of remote execution. This could be as simple as asking a Remote Web Server to display a static Web page, or as complex as using a shell session to interactively issue commands against a remote server. Salt is an example of one of the more complex types of remote execution. Salt is designed to allow users to explicitly target and issue commands to multiple machines directly. Salt is based around the idea of a Master, which controls one or more Minions. Commands are normally issued from the Master to a target group of Minions, which then execute the tasks specified in the commands and then return the resulting data back to the Master. Communications between a master and minions occur over the ZeroMQ message bus. SaltStack modules communicate with the supported minion operating systems. The Salt Master runs on Linux by default, but any operating system can be a minion, and currently Windows, VMware vSphere and BSD Unix variants are well supported. The Salt Master and the minions use keys to communicate. When a minion connects to a master for the first time, it automatically stores keys on the master. SaltStack also offers Salt SSH, which provides an “agent less” systems management. Need for SaltStack SaltStack is built for speed and scale. This is why it is used to manage large infrastructures with tens of thousands of servers at LinkedIn, WikiMedia and Google. Imagine that you have multiple servers and want to do things to those servers. You would need to login to each one and do those things one at a time on each one and then you might want to do complicated things like installing software and then configuring that software based on some specific criteria. Let us assume you have ten or maybe even 100 servers. Imagine logging in one at a time to each server individually, issuing the same commands on those 100 machines and then editing the configuration files on all 100 machines becomes very tedious task. To overcome those issues, you would love to update all your servers at once, just by typing one single command. SaltStack provides you exactly the solution for all such problems. Features of SaltStack SaltStack is an open-source configuration management software and remote execution engine. Salt is a command-line tool. While written in Python, SaltStack configuration management is language agnostic and simple. Salt platform uses the push model for executing commands via the SSH protocol. The default configuration system is YAML and Jinja templates. Salt is primarily competing with Puppet, Chef and Ansible. Salt provides many features when compared to other competing tools. Some of these important features are listed below. Fault tolerance − Salt minions can connect to multiple masters at one time by configuring the master configuration parameter as a YAML list of all the available masters. Any master can direct commands to the Salt infrastructure. Flexible − The entire management approach of Salt is very flexible. It can be implemented to follow the most popular systems management models such as Agent and Server, Agent-only, Server-only or all of the above in the same environment. Scalable Configuration Management − SaltStack is designed to handle ten thousand minions per master. Parallel Execution model − Salt can enable commands to execute remote systems in a parallel manner. Python API − Salt provides a simple programming interface and it was designed to be modular and easily extensible, to make it easy to mold to diverse applications. Easy to Setup − Salt is easy to setup and provides a single remote execution architecture that can manage the diverse requirements of any number of servers. Language Agnostic − Salt state configuration files, templating engine or file type supports any type of language. Benefits of SaltStack Being simple as well as a feature-rich system, Salt provides many benefits and they can be summarized as below − Robust − Salt is powerful and robust configuration management framework and works around tens of thousands of systems. Authentication − Salt manages simple SSH key pairs for authentication. Secure − Salt manages secure data using an encrypted protocol. Fast − Salt is very fast, lightweight communication bus to provide the foundation for a remote execution engine. Virtual Machine Automation − The Salt Virt Cloud Controller capability is used for automation. Infrastructure as data, not code − Salt provides a simple deployment, model driven configuration management and command execution framework. Introduction to ZeroMQ Salt is based on the ZeroMQ library and it is an embeddable networking library. It is lightweight and a fast messaging library. The basic implementation is in C/C++ and native implementations for several languages including Java and .Net is available. ZeroMQ is a broker-less peer-peer message processing. ZeroMQ allows you to design a complex communication system easily. ZeroMQ comes with the following five basic patterns − Synchronous Request/Response − Used for sending a request and receiving subsequent replies for each one sent. Asynchronous Request/Response − Requestor initiates the conversation by sending a Request message and waits for a Response message. Provider waits for the incoming Request messages and replies with the Response messages. Publish/Subscribe − Used for distributing data from a single process (e.g. publisher) to multiple recipients (e.g. subscribers). Push/Pull − Used for distributing data to connected nodes. Exclusive Pair − Used for connecting two peers together, forming a pair. ZeroMQ is a highly flexible networking tool for exchanging messages among clusters, cloud and other multi system environments. ZeroMQ is

SaltStack – Python API ”; Previous Next Salt provides programmatic access to all of its commands. Salt provides different modules for every section of the Salt system. Let us learn the basics of the python API and about how to run the basic salt commands in this chapter. Configuration The salt.config module is used to access Salt configuration details. import salt.config opts = salt.config.client_config(”/etc/salt/master”) Here, the client_config reads the salt configuration file and returns the configuration details as dictionary. Loader The salt.loader module is used to load each modules in Salt such as grains, minions, etc. import salt.loader opts = salt.config.minion_config(”/etc/salt/minion”) grains = salt.loader.grains(opts) Here, grains reads the details of the grains in the Salt system and returns it. Client Module The salt.client module is used to execute salt, salt-call and the salt-SSH commands programmatically. The most important python classes are as follows − salt.client.LocalClient salt.client.Caller salt.client.ssh.client.SSHClient The main function provided by most of the client module is cmd. This function wraps the CLI options and executes it, which is similar to the command line and returns the results as python data structures. LocalClient The LocalClient is used to send commands from the master to the salt minions and return the results to the master. import salt.client local = salt.client.LocalClient() local.cmd(”*”, ”test.ping”) It will produce the following output − {”minion1”: True, ”minion2”: True } Caller The Caller is used to run salt-call programmatically and return the results. import salt.client caller = salt.client.Caller() caller.cmd(”test.ping”) It will produce the following output − True SSHClient The SSHCient is used to run the salt-ssh programmatically and return the results. import salt.client.ssh.client ssh = salt.client.ssh.client.SSHClient() ssh.cmd(”*”, ”test.ping”) It will produce the following output − {”minion1”: True, ”minion2”: True } CloudClient The salt.cloud module is used to execute the salt-cloud commands programmatically. client = salt.cloud.CloudClient(path = ”/etc/salt/cloud”) Cloud module provides functions to create VMs (create), to destroy VMs (destroy), list images provided by a cloud provider (list_images), list locations of a cloud provider (list_locations), list machine sizes of a cloud provider (list_sizes), etc. Print Page Previous Next Advertisements ”;

Discuss SaltStack ”; Previous Next SaltStack is an open-source configuration management and remote execution engine. It remotely executes commands across all machines. It is a python based software. Thomas S Hatch is the creator and the principal architect of SaltStack. SaltStack uses the ZeroMQ messaging library to process high-speed requirements for all networking layers. Salt is simple, scalable and fast. This tutorial will explore the basic principles of SaltStack, SaltStack setup, Minion file system and then walk through with remote execution steps, configuration management, cloud management, Python API operations and finally conclude with a complete working example. Print Page Previous Next Advertisements ”;

SaltStack – Orchestration ”; Previous Next In general, orchestration is an automated coordination and arrangement of systems. Orchestrate runner is used to perform the orchestration in SaltStack. Orchestrate Runner he Orchestrate Runner offers all the functionality of the OverState (previous system). It is originally called as the state.sls runner. This orchestrate runner is used to generalize the Salt state system to a Salt master context. The state.sls and the state.highstate functions are executed on each Salt minion, but the state.orchestrate runner is executed on the master. The state.orchestrate runner allows you to manage your entire infrastructure as state fully. Let us understand how to go through a simple execution process. Simple Execution The Orchestrate Runner command is same as the state.sls function, but you can execute it with the “salt-run” instead of salt. Assume that you have a sample.sls file located at /srv/salt/orch/samples.sls. Add the following code in that file. sample.sls install_nginx: salt.state: – tgt: ”web*” – sls: – nginx The following command is used to run on the master and it will apply the states defined in that file. salt-run state.orchestrate orch.sample It will produce the following output − saltmaster.local_master: ———- ID: install_nginx Function: salt.state Result: True Comment: States ran successfully. Started: 11:54:56.308078 Duration: 63.401 ms Changes: Summary for saltmaster.local_master ———— Succeeded: 1 Failed: 0 ———— Total states run: 1 Total run time: 63.401 ms root@saltmaster:/home/vagrant# Here, according to the Current Version, the runner function was renamed to state.orchestrate. This will be helpful to avoid confusion with the state.sls execution function, but the previous versions of state.sls must be used. Execute Function To execute a function, you should use the salt.function. Consider a file data.sls located at /srv/salt/orch/data.sls. Now, add the following changes in that file. data.sls cmd.run: salt.function: – tgt: ”*” – arg: – rm -rf /tmp/data The following command is used to execute the Salt function. root@saltmaster:/home/vagrant# salt-run state.orchestrate orch.data It will produce the following output − saltmaster.local_master: ———- ID: cmd.run Function: salt.function Result: True Comment: Function ran successfully. Function cmd.run ran on minion1, minion2. Started: 12:14:54.791635 Duration: 234.615 ms Changes: minion1: minion2: Summary for saltmaster.local_master ———— Succeeded: 1 (changed = 1) Failed: 0 ———— Total states run: 1 Total run time: 234.615 ms Print Page Previous Next Advertisements ”;

SaltStack – Working Example ”; Previous Next In this working example, we will create a Salt formula that will configure the apache web server along with the PHP software. Salt is a great way to execute ad-hoc commands, but you would not really want to continually configure your infrastructure this way. By creating a set of Salt formulas, you can reliably reproduce any configuration over. Salt Formulas are simple YAML text files and by default reside on your Salt Master in /srv/salt/*. Let us start by creating a Salt Formula to install the Apache web server and PHP at the same time. Create a file named “websetup.sls” under /srv/salt/ directory and add the following code. websetup.sls websetup: pkg: – installed – pkgs: – apache2 – php5 – php5-mysql In this example, notice the “- pkgs:” argument. Each item in the list below “- pkgs:” will be passed together to OS”s package manager to be installed together. Whenever you have a large list of packages to install this is the most efficient way to install them. Apply this Formula to Salt master using the following command. root@saltmaster:/home/vagrant# salt ”minion2” state.sls websetup Now, you will see the following output − minion2: ———- ID: websetup Function: pkg.installed Result: True Comment: 3 targeted packages were installed/updated. Started: 01:50:53.978396 Duration: 86738.132 ms Changes: ———- apache2: ———- new: 2.4.7-1ubuntu4.13 old: apache2-api-20120211: ———- new: 1 old: apache2-bin: ———- new: 2.4.7-1ubuntu4.13 old: apache2-data: ———- new: 2.4.7-1ubuntu4.13 old: libapache2-mod-php5: ———- new: 5.5.9+dfsg-1ubuntu4.21 old: libapr1: ———- new: 1.5.0-1 old: libaprutil1: ———- new: 1.5.3-1 old: libaprutil1-dbd-sqlite3: ———- new: 1.5.3-1 old: libaprutil1-ldap: ———- new: 1.5.3-1 old: php5: ———- new: 5.5.9+dfsg-1ubuntu4.21 old: php5-cli: ———- new: 5.5.9+dfsg-1ubuntu4.21 old: php5-common: ———- new: 5.5.9+dfsg-1ubuntu4.21 old: php5-json: ———- new: 1.3.2-2build1 old: php5-mhash: ———- new: 1 old: php5-mysql: ———- new: 5.5.9+dfsg-1ubuntu4.21 old: php5-readline: ———- new: 5.5.9+dfsg-1ubuntu4.21 old: phpapi-20121212: ———- new: 1 old: ssl-cert: ———- new: 1.0.33 old: Summary for minion2 ———— Succeeded: 1 (changed = 1) Failed: 0 ———— Total states run: 1 Total run time: 86.738 s Now, you have installed the packages in minion2. Highstate A “highstate” is a way for Salt to determine which of the Salt Formulas should be applied to a certain minion. Execute a “highstate” using the following command. root@saltmaster:/home/vagrant# salt <targets> state.highstate top.sls When the minion request to execute a highstate, as mentioned before, the minion requests the top.sls from the Salt master and searches for formulas that it matches. By default, this file is located at /srv/salt/top.sls. Let us add our formula to the top.sls file and set minion2 as target. base: ”*”: – common ”minion2’: – websetup Now, execute the highstate targeting minion2 as shown below. root@saltmaster:/home/vagrant# salt ”minion2” state.highstate After applying this, you could see the following output − minion2: ———- ID: common_packages Function: pkg.installed Result: True Comment: All specified packages are already installed Started: 01:55:17.998824 Duration: 461.615 ms Changes: Summary for minion2 ———— Succeeded: 1 Failed: 0 ———— Total states run: 1 Total run time: 461.615 ms Now, Apache web server and PHP is installed in the minion2. In this way, we have to target minions using both top.sls and highstate and install the required software with minimal work and maximum flexibility. Print Page Previous Next Advertisements ”;

SaltStack – Using Cron with Salt ”; Previous Next Salt can be used along with the Cron application. Using both applications together provides a great opportunity to automate Salt. While Salt provides an option to execute commands remotely, Cron enables it to run in a pre-scheduled or automated manner. Let us learn how to use Cron and Salt together in this chapter. What is Cron? Cron is very useful application in the Linux Environment. It enables to preset a command or script to run in a specific date and time. It also enables to run an application in a regular interval, say daily, weekly or every first day of the month. Cron starts when the system starts and check the /etc/crontab file for configuration details. The /etc/crontab has every application and its schedule in a separate line as shown below. 15 * * * * root echo “This command runs at 15 minutes past every hour” 15 10 * * * root echo “This command is run daily at 10:15 am” Every line has the following seven entry points, which are separated by space and they are as follows − minute − minute of the hour and is between ‘0’ and ‘59’. hour − hour and is specified in the 24-hour clock. day_of_month − Day of the Month and is between 1 and 31. For example, the 10th of each month is 10. month − A month specified and is specified numerically (0-12), or as the name of the month (e.g. May). day_of_week − Day of the week is specified numerically (0-7) or as the name of the day (e.g. Sun). user − User account under which the command runs. cmd − The actual command and its arguments. Here, * replaces, if nothing is assigned. Salt Caller (salt-call) Salt provides a CLI (Command Line Interface), salt-call to run the modules in the local minion system itself instead of from the master server using the salt command. The salt call CLI supports all the options supported by salt command, but run locally. Salt Caller was initially designed to support debugging, but now, it can be used as a standalone application. salt-call test.ping Using salt-call in cron The salt-call CLI is useful to schedule salt operation using Cron. For example, to check the state of the minion every day at midnight, we can use salt-call along with the option – state.apply as shown below. /etc/crontab PATH = /bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/opt/bin 0 0 * * * salt-call state.apply Here, The state.apply function will check the salt configuration file for the minion and check whether all action defined for the minion is properly configured. Setting the path is a good practice because sometimes the salt command may not be available in the system path. In the next chapter, we will learn Remote Execution, which is a core concept of Salt. Print Page Previous Next Advertisements ”;

SaltStack – Using MinionFS as the File Server ”; Previous Next The MinionFS is a special file server provided by Salt for the minions to exchange the files between them. The files served by the MinionFS are the files intentionally shared by minions. To share the files, a Minion has to follow steps given below. Source minion has to push the file to the salt master using the cp.push function. Once the files are pushed by the source minion, the deployed files can be accessed by any other minion using the MinionFS file server. Enable Pushing By default, pushing the files by minions to a master is disabled. To accept the files from minions, the master needs to have the “file_recv” option in the config file and its value must be set to True. By default, the value if “file_recv” is false. file_recv: True Once the option is enabled, restart the master service. Pushing Files Minions can push the files to the master. It is performed by the cp.push function. This cp.push function provides an easy mechanism to push the files by minion using the minion id. salt ”minion-id” cp.push /path/to/the/file Here, the minion-id is used to identify which minion is pushing the file. This command will store the file in a subdirectory named minions under the master”s cachedir. Usually, the path is – /var/cache/salt/master/minions. For minion, m1 and the file – /var/log/mylog.txt, the file will be stored in the – /var/cache/salt/master/minions/m1/var/log/mylog.txt. Enable MinionFS To enable the MinionFS, simply add minion in the fileserver backend setting as shown in the following code block. fileserver_backend: – roots – minion Once MinionFS is enabled, the minion pushed files are available as − salt://<minion-id>/path/to/pushed/file For minion, m1 and the pushed file – /var/log/mylog.txt, the pushed file will be served from salt://m1/var/log/mylog.txt. This minionFS can be mounted in a special directory using the following configuration. It will separate the minionFS files from other files and will help in organizing the minion files. minionfs_mountpoint: salt://minionfs For the above configuration, the file will available under the minionfs directory as – salt://minionfs/m1/var/log/mylog.txt MinionFS Advanced Options The MinionFS also provides an option to enable / disable the availability of pushed files from a certain minion. The options are minionfs_whitelist, to enable minions and minionfs_blacklist, to disable the minions. minionfs_whitelist: – webserver – develop* – ‘maild+.mysite.com” minionfs_blacklist: – testing In the above configuration, all minions except testing are allowed to share the file using minionFS. Webserver1 Minions whose ids matches the regular expression develop * Minions whose ids matches the regular expression maild+.mysite.com. Testing In the next chapter, we will learn how to use Cron with Salt. Print Page Previous Next Advertisements ”;

SaltStack – Salt File Server ”; Previous Next The Salt file server is a stateless ZeroMQ server. It is built into the Salt master. A Salt file server is used for distributing files from master to minions. It contains different modules. Let us understand the salt file server, its configuration, modules related to the salt file server, how to access the salt file server in python, etc., in this chapter. File Server Backend The file server backend allows the Salt file server to act as a transparent interface to other file server like a local file system, Git version control system, etc. A Git file server backend can be enabled by using the following configuration in the master file. fileserver_backend: – git To enable multiple backend file system, we can use the following configuration. fileserver_backend: – roots – git We can also specify the additional option for a different backend server using the specific section of the corresponding backend server. Local File System For using this system, we have to use the following code. file_roots: base: – /srv/salt/prod Git File System For using this system, we have to use the following code. gitfs_remotes: – https://github.com/sample/sample1.git Requesting Files Salt has the option to request files for specific environments. salt://path/to/file?saltenv = base Here, the environment is defined using the roots option. File Server Configuration Salt files can be allocated within many root directories and accessed by specifying both the file path and the environment to search. The individual environments can span across multiple directory roots. Environment The default environment is base. This environment is defined and is used to download files when no other environment is specified. file_roots: base: – /srv/salt/base You can also use multiple environments as shown in the code below. file_roots: base: – /srv/salt/base dev: – /srv/salt/dev – /srv/salt/base CP Module The CP module is the main module to manipulate the Salt file server. The salt-cp command can also be used to distribute files presented by the Salt file server. GET_FILE The cp.get_file function can be used on the minion to download a file from the master. It is defined as shown in the following code block. salt ”*” cp.get_file salt://vimrc /etc/vimrc The above command instructs all Salt minions to download the vimrc file and copy it to /etc/vimrc. Enable Template You can enable template option in get_file as follows − salt ”*” cp.get_file “salt://vimrc” /etc/vimrc template = jinja Apply Compression To use compression, use the gzip named argument. The valid values are integers from 1 to 9, where 1 is the minimum compression and 9 is maximum value. The command is defined as follows − salt ”*” cp.get_file salt://vimrc /etc/vimrc gzip = 5 GET_DIR The cp.get_dir function can be used on the minion to download an entire directory from the master. It is defined in the following code block. salt ”*” cp.get_dir salt://etc/mysql /etc The cp.get_dir supports template rendering and gzip compression arguments. If you want, you can assign as well. FILECLIENT Module Salt provides a python module that helps to access the salt file server. The salt/fileclient.py module is used to set up the communication from the minion to the master. The sample code to get files is as follows − import salt.minion import salt.fileclient def get_file(path, dest, saltenv = ‘base”): client = salt.fileclient.get_file_client(__opts__) return client.get_file(path, dest, true, saltenv) Here, opts is available when the module is run in the salt environment. Otherwise, we should provide the configuration path – /etc/salt/minion. path refers to the path of the source file in salt file server. dest refers the destination path of the file. saltenv refers to the environment In the next chapter, we will understand how to use Git as the file server. Print Page Previous Next Advertisements ”;

SaltStack – Remote Execution ”; Previous Next One of the core concepts of Salt is remote execution. Salt can execute commands across thousands of systems in a matter of seconds. Salt uses its own command to do this functionality. Let us now understand the different Salt commands for remote execution in the chapter. Salt Command Salt command enables the Salt master to communicate with one or more Salt minions. The basic syntax is as follows, salt ”<target>” <module.function> [arguments] The above command syntax consists of the following three main components. target − It determines which systems is applied by the command. module.function − It is a command. Commands consists of a module and function. arguments − Additional data needed for calling the function. Let us understand each of the components in detail. What is the Target Component? Target is a component, which allows you to filter minions (managed system) to run the function. A simple command using the target component is defined below. salt ”*” test.ping It will produce the following output − minion2: True minion1: True Here, the target ‘*’ represents all the managed systems. The ‘test’ here is a module and ping is a function. This is used to test the ping service in the remote system. We will learn about the different modules and its functions in subsequent chapters. Targets using ID (minion) You can send a command to a specific minion using its id in the target. Instead of using ”*”, you can replace it using minion id. It is defined below. salt ”minion1’ test.ping It will produce the following output − minion1: True Targets using Regular Expression Targets can be filtered by specific regular expression. It is defined below. salt -E ”minion[0-9]” test.ping It will produce the following output − minion2: True minion1: True Targets using List Targets can be explicitly specified in a list. It is defined in the following code block. salt -L ”minion1,minion2” test.ping It will produce the following output − minion2: True minion1: True Targets by Condition Targets can be combined in one command as shown in the code block below. salt -C ”G@os:Ubuntu and minion* or [email protected].*” test.ping It will produce the following output − minion1: True minion2: True Module and Functions (module.function) Salt can execute shell commands; update packages and distribute files, etc., in all of its managed systems simultaneously. Salt does these operations using modules. Salt has special modules for all the available functionalities. Let us understand the different Salt modules using some simple example in this chapter. Shell Command Salt executes shell commands remotely across multiple systems using the cmd.run command. The cmd is the main module and run is one of the function available in the cmd module. The run function enables any shell command to be executed in the remote system as shown in the code block below. salt ”*” cmd.run ”ls -l /etc” It will produce the following output − minion2: total 868 drwxr-xr-x 7 root root 4096 Jan 26 22:10 X11 drwxr-xr-x 3 root root 4096 Jan 26 21:02 acpi -rw-r–r– 1 root root 2981 Jan 26 20:48 adduser.conf -rw-r–r– 1 root root 10 Jan 26 21:04 adjtime drwxr-xr-x 2 root root 4096 Jan 26 22:10 alternatives drwxr-xr-x 3 root root 4096 Jan 26 20:53 apm drwxr-xr-x 3 root root 4096 Jan 26 21:02 apparmor drwxr-xr-x 9 root root 4096 Jan 26 21:02 apparmor.d drwxr-xr-x 3 root root 4096 Jan 26 21:02 apport drwxr-xr-x 6 root root 4096 Jan 29 07:14 apt drwxr-xr-x 2 root root 4096 Jan 26 22:10 at-spi2 …………… …………… minion1: total 868 drwxr-xr-x 7 root root 4096 Jan 26 22:10 X11 drwxr-xr-x 3 root root 4096 Jan 26 21:02 acpi -rw-r–r– 1 root root 2981 Jan 26 20:48 adduser.conf -rw-r–r– 1 root root 10 Jan 26 21:04 adjtime drwxr-xr-x 2 root root 4096 Jan 26 22:10 alternatives drwxr-xr-x 3 root root 4096 Jan 26 20:53 apm drwxr-xr-x 3 root root 4096 Jan 26 21:02 apparmor drwxr-xr-x 9 root root 4096 Jan 26 21:02 apparmor.d drwxr-xr-x 3 root root 4096 Jan 26 21:02 apport drwxr-xr-x 6 root root 4096 Jan 29 07:09 apt drwxr-xr-x 2 root root 4096 Jan 26 22:10 at-spi2 -rw-r—– 1 root daemon 144 Oct 21 2013 at.deny -rw-r–r– 1 root root 2177 Apr 9 2014 bash.bashrc -rw-r–r– 1 root root 45 Mar 22 2014 bash_completion …………… …………… Show Disk Usage Salt provides a special module, disk to get the complete disk details of the managed system. The diskmodule has a usage function to query the details. salt ”*” disk.usage It will produce the following output − minion1: ———- /: ———- 1K-blocks: 41251136 available: 37852804 capacity: 5% filesystem: /dev/sda1 used: 1662420 /dev: ———- 1K-blocks: 503908 available: 503896 capacity: 1% filesystem: udev used: 12 /run: ———- 1K-blocks: 101780 available: 101412 capacity: 1% filesystem: tmpfs used: 368 /run/lock: ———- 1K-blocks: 5120 available: 5120 capacity: 0% filesystem: none used: 0 /run/shm: ———- 1K-blocks: 508884 available: 508872 capacity: 1% filesystem: none used: 12 /run/user: ———- 1K-blocks: 102400 available: 102400 capacity: 0% filesystem: none used: 0 /sys/fs/cgroup: ———- 1K-blocks: 4 available: 4 capacity: 0% filesystem: none used: 0 /vagrant: ———- 1K-blocks: 303114632 available: 252331440 capacity: 17% filesystem: none used: 50783192 minion2: ———- /: ———- 1K-blocks: 41251136 available: 37852804 capacity: 5% filesystem: /dev/sda1 used: 1662420 /dev: ———- 1K-blocks: 503908 available: 503896 capacity: 1% filesystem: udev used: 12 /run: ———- 1K-blocks: 101780 available: 101412 capacity: 1% filesystem: tmpfs used: 368 /run/lock: ———- 1K-blocks: 5120 available: 5120 capacity: 0% filesystem: none used: 0 /run/shm: ———- 1K-blocks: 508884 available: 508872 capacity: 1% filesystem: none used: 12 /run/user: ———- 1K-blocks: 102400 available: 102400 capacity: 0% filesystem: none used: 0 /sys/fs/cgroup: ———- 1K-blocks: 4 available: 4 capacity: 0% filesystem: none used: 0 /vagrant: ———- 1K-blocks: 303114632 available: 252331440 capacity: 17% filesystem: none used: 50783192 Network Interfaces Salt provides a separate module, network and function, interfaces inside the module to query the network interface information about the managed systems. salt ”*” network.interfaces It will produce the following output − minion1: ———- eth0: ———- hwaddr: 08:00:27:04:3e:28