Saltstack (vi) Case exercise

Salt Exercise 1, modify the host name of one of the servers. Failure problem:

What happens if you do not follow the essentials?
1, the original hostname will exist/etc/salt/minion_id this file, so the new host name will not be recognized. minion_id files can be emptied
2, the PKI file holds the master side of the key and the Minion side of the public and private keys, the Minion side of the public and private key is based on the hostname of the server generated, Minion side change the hostname, matching is not, the Minion process will automatically kill.

Skills:

To enable master to still control the minion,minion to modify the hostname, first delete the Minion-side minion_id and PKI directory: rm-rf/etc/salt/minion_id/etc/salt/pki/, Any restart of the Minion-side service

2, master Migration requirements:

Modify Master to a higher configuration without modifying any information on the Minion side.
Smooth migration in the event that the Minion end is not hung

Failure problem:

The salt principle is if the master rejects the Minion end, Minion will automatically kill the service process, if there are 200 servers, all the Minion services are hung up, then work is big.

Skills:

The principle is: in Minion, master key and Minion can not conflict, if the conflict minion will kill themselves.

Method:

1, first prepare the new master key, the original master key directly packaged, the Salt directory under the PKI directory all packaged, and then uploaded to the new master. Before this new master does not start the service. Place the original master key in the Salt directory of the new master and start the Salt service
2, first in the original master batch will all the machine's designated master IP modification (that is, the configuration of the hosts point), modify the hosts to use the Cmd.run module, and then restart the Minion side, available Cmd.run, can also directly use the salt provided by the module slat ' * ' Service.restart slat-minion

3, Returnner (log output)

By default, the command that is sent to salt Minion results in an interface that is returned to the salt master,saltstack returner allows the results to be sent to any system
Can do minion monitoring use,

List of built-in Returnner modules

            Carbon_return       Returns the result to the carbon receiver            Cassandea_return    Returns the result to Cassandra Columnfamily            local               Returns the result to the local test returner interface, which prints the current result            Mongo_future_return Returns the result to MongoDB            Mongo_return        Returns the result to MongoDB            MySQL returns the results to MySQL Postgres and returns the results to            postgres            Redis_return        Returning the results to Redis            Sentry_return Return       The result to Sentry            Smtp_return return         the salt data via email            syslog_return return the       result to the operating system Syslog facility

4, grains

Grains with Puppet's facter function, mainly responsible for collecting some basic information of the client, this can also be fully customizable, can be customized in the client, and then automatically reported up, can also be defined from the server and pushed down, after the acquisition, in the report Pillar is more flexible than grains.

Grains use

View Grains Salt'salt-clinet'Grains.ls Salt'salt-clinet'Grains.items Salt'salt-clinet'grains.item Regular matching salt-G'Os:centos'test.ping Salt-G'cpuarch:x86_64'Grains.item Num_cpus Salt-G'ec2_tags:environment:*production*'custom grains is configured on Minion grains Grains:roles:-webserver-memcache deployment:datacenter4 cabinet:13Cab_u:14-15

5, States

The core of the salt State system is SLS, or **s**altstate file. SLS indicates what kind of state the system will be and includes it in a very simple format, which is often called configuration management.
SLS files are actually just some: dictionary dictionaries, list lists, string str, and numeric int

Yaml
Indent: Yaml represents a data-tier structure relationship using a fixed indentation style, which requires each indentation level to consist of two spaces, which cannot be a tab
The Python dictionary is naturally a simple key-value pair, and the dictionary's keys in Yaml are represented by a colon-based string. Alues the representation of a colon below each line, separated by a space.
Example: My_key:my_value
To represent a list item, use a short slash and a space, and multiple items use the same indentation level as part of the same list.

Http://docs.saltstack.cn/topics/yaml/index.html

6. List of State modules

Http://docs.saltstack.com/en/latest/ref/states/all/index.html

7, Salt-call (Minion)

Go to Minion on the corresponding method

8, Pillar

Pillar is an important component of salt, which is used to define any data you need for a specific minion, which can be used by other components of the salt.
Salt introduced pillar in version 0.9.8.
Pillar after parsing is completed, is a nested DICT structure, the topmost key is the Minion ID, whose value is the pillar data owned by the minion, each value is also key/value. Here you can see a feature of pillar, pillar data is associated with a specific minion, that is, each minion can only see their own data, so pillar can be used to transfer sensitive data (in the salt design, Pillar uses a separate encryption session to ensure the security of sensitive data). Pillar can be used in those places?

1, sensitive data such as SSH key, encryption certificate, etc., because Pillar uses a separate encryption session, you can ensure that these sensitive data are not seen by other minion. 2, variables can handle platform differences in pillar, such as setting the name of a package for different operating systems, and then referencing it in state. 3, any other data can be used in pillar to add any data needed, such as the definition of user and UID correspondence, Minion role and so on. 4, used in targetting pillar can be used to select Minion, use-l option By default, all data in the master profile is added to pillar and available to all Minion, and if you want to disable this default, you can add the following data to the master configuration file and take effect after restarting the service. Pillar Sample http:docs.saltstack.cn/topics/jobs/schedule.html Salt'*'Saltutil.refresh_pillar#Refresh Configurationpillar Define timed tasks synchronize Nginx configuration files every minute [email protected]-server Pillar]#Cat Top.slsBase:'*':                    -Nginx [[email protected]-server Pillar]#Cat Nginx.slsSchedule:nginx:function:state.sls minutes: 
    1#per minuteargs:-'Nginx'Salt'*'Saltutil.refresh_pillar#Refresh the pillar on all machinesSalt'*'Pillar.data#view pillar on all machines

9. Proxy

The

            Salt Syndic Interface is a powerful tool that allows the creation of a salt command extension structure, The basic setting for salt is a salt master directing a set of salt minion. The
            Syndic interface is a special pass-through Minion, He allows a master to connect to another master and then Syndic Minion connected to master to control the Minion
on the master that is running Syndic              
            
            
            

salt-syndic Agent directly installed master,            Salt-syndic do not need any additional plug-ins, directly start/etc/init.d/salt-Syndic can.            the configuration file is /etc/salt/master            directly configured in three places.                syndic_master: The IP address of the higher-level master                syndic_log_file:syndic the path to the log file (absolute path is good)                order_masters:true  confirm the forwarding mechanism. 

Saltstack (vi) Case exercise