静思学吧 - 关注Graphite,Puppet,saltstack, Zabbix
Overview
The Salt Syndic interface is a special passthrough minion, it is run on a master (maybe we can give this master a name SecondMaster) and connects to another master ( maybe we can give this master a name TopMaster. Through the Salt Syndic interface, TopMaster can control the minions that connect to SecondMaster.
When TopMaster have to control all the minions, if without Syndic, the TopMaster have to communicate with all minions, establish an connection with every minion, this will take a lot of host resource and network traffic, and if the TopMaster is not located in the same local network with minions, it will spend much time on network communication.
With Syndic, the TopMaster only need to establish a connection with SecondMaster and send the commands to SecondMaster. The SecondMaster is located in the same local network with minions, so the time spend on network communication can be very little.
Architecture Diagram
The architecture diagram with Syndic is as follows:
The architecture diagram without Syndic is as follows:
Configuring the Syndic
The master that the syndic connects to sees the syndic as an ordinary minion, and treats it as such. the higher level master will need to accept the syndic’s minion key like any other minion. This master will also need to set the order_masters value in the configuration to True. The order_masters option in the config on the higher level master is very important, to control a syndic extra information needs to be sent with the publications, the order_masters option makes sure that the extra data is sent out.
Note: The master sees the syndic as an ordinary minion. Thus the syndic don’t need to listen any port, it will connect to master’s 4505 or 4506. I’ll verify this later.
Follow these steps below:
- Change order_masters to True in configuration file /etc/salt/master On TopMaster
order_masters: True
- Install salt-syndic and setup syndic_master on SecondMaster
apt-get install salt-syndic # edit configuration file /etc/salt/master syndic_master: MasterOfMaster ip/address
- Start the salt-syndic on SecondMaster
service salt-syndic start
- Accept the key from SecondMaster’ Syndic service
salt-key -A -y
OK, all is done here. Let’s do some experiments and verify our guess.
Use Syndic
Here I make these assumptions:
I have three hosts, their roles is as follows:
- TopMaster( hostname: master) : 192.168.254.203
- SecondMaster( hostname and minion id: slave1 )or syndic: 192.168.254.204
- Minion of SecondMaster( hostname and minion id: slave2): 192.168.254.208
1. Syndic is a minion or not?
Let’s check the syndic daemon status:
Here we can see that the syndic daemon connect to TopMaster’s 4505 port as ordinary minion do.
2. Will the minion of syndic connect to the TopMaster straightly?
Let’s check the process when run some cmd using salt
Here, slave2 did not have any connection with master ( our TopMaster)
3. How the state will apply to minions?
First create an tmp.sls on TopMaster, the content is as follows:
/tmp/syndictest: file.managed: - contents: | this is from topmaster 192.168.254.203
Then create an tmp.sls on SecondMaster, the content is as follows:
/tmp/syndictest: file.managed: - contents: | this is from syndic 192.168.254.204
Last apply this tmp state
salt '*' state.sls tmp salt '*' cmd.run 'cat /tmp/syndictest'
So the result is obvious, slave2 connect to its master slave1, then it will apply the state defined in slave1, and slave1 host and master host’s master are master, so they will aplly the state defined in master host.
Conclusion: when salt do any operations, minion will only apply operations defined in this minion’s master. These operations are not related with syndics.
4. What job does syndics do?
I don’t know. there’s no documents about it in salt official websites( salt syndic ), maybe you can capture the packages of syndic daemon with tcpdump, then analysis these packages.
5. How to manage the syndics?
We can put all syndics into a nodegroup, create a nodegroup definition file on TopMaster:
cat >>/etc/salt/master.d/nodegroup.conf <<'EOF' nodegroups: syndics: 'slave1' EOF service salt-master restart salt -N syndics state.highstate
Reference
- salt syndic: official document
- saltstack(四) syndic : This article is written in Chinese. I think it’s not a good way to operate the minion on topmaster straightly, after all there’s a syndic across topmaster and minion, maybe we should see all minions which connect to syndics as a blackbox.
Note: this is my first english article, so maybe there are some grammatical errors, if you find any errors in this post, just point these errors out, I will correct them immediately and thank you.