Puppet deployment application
Skill goal
- Familiar with the working principle of Puppet
- Master the configuration method of Puppet deployment application
Case 1 Analysis
Case overview
As a system administrator, maintaining the normal operation of the server is the most basic responsibility. When managing several to dozens of servers, most administrators like to write their own gadgets to maintain. However, with the increase of the number of servers, the number of tasks also increases gradually. At this time, a concise and powerful framework is needed to complete the system management task.
To achieve this goal, a number of tools are introduced. These tools are "programmable". The system administrator only needs to write a few lines of "code" for these tools, and it will automatically complete all work. Puppet is one of these operation and maintenance automation tools. In some large Internet enterprises, puppet operation and maintenance automation tool manages hundreds or even thousands of servers. It can carry out unified operation for multiple servers, such as deploying unified software and unified on-line maintenance, and can quickly complete on-line deployment, reduce manpower and reduce the risk of manual misoperation.
Case pre knowledge points
1. Working principle of puppet
The purpose of puppet is to let the administrator focus only on the objectives to be managed and ignore the details of implementation. Puppet can be used either on a single machine or in C/S structure. In the case of large-scale use of puppet, C/S structure is usually used. In this structure, the Puppet Client only runs Puppet Client, and the puppet server only runs Puppet Master.
The workflow of Puppet management tool is shown in the figure below.
(1) The client puppet calls the factor tool (factor is a tool for collecting, detecting and analyzing client configuration information through SSL encryption). Factor detects some variables of the host, such as host name, memory size, IP address, etc. Puppet sends this information to the server through SSL connection.
(2) The Puppet Master on the server side analyzes and detects the host name of the client through the factor tool, then finds the corresponding node configuration in the main configuration file manifest of the project, and parses this part of the content. The information sent by factor can be processed as variables. Only the code involved in node is parsed, and other codes not involved are not parsed. Parsing is divided into several stages. First, check the syntax. If the syntax is correct, continue parsing. The result of parsing generates an intermediate "pseudo code", and then sends the pseudo code to the client.
(3) The client receives the "pseudo code" and executes it. The client sends the execution result to the server.
(4) The server writes the execution result of the client to the log
2. Precautions in puppet work
During the work of Puppet, the following two points deserve attention.
(1) In order to ensure security, the Client and the Master are based on SSL and certificate. Only the Client authenticated by the Master certificate can communicate with the Master.
(2) Puppet will keep the system in a state that people expect and maintain it all the time. For example, detect a file and ensure that it always exists, and ensure that the SSH service is always enabled. If the file is deleted or the SSH service is closed, the file will be re created or the SSH service will be started the next time puppet executes (30 minutes by default).
Case environment
1. Experimental environment of this case
host name | IP address | to configure | Main software |
---|---|---|---|
master | 192.168.10.101 | 2C/2G | Puppet-server |
client1 | 192.168.10.102 | 2C/2G | Puppet |
client2 | 192.168.10.103 | 2C/2G | Puppet |
2. Case requirements
Batch modify the client SSH service port with Puppet
3. Case realization ideas
(1) Environmental preparation;
(2) Install Puppet Master and Puppet Client;
(3) Configure test nodes;
(4) The client actively pulls and the server actively pushes.
Case 1 implementation
Puppet installation and deployment
1. Modify the server host name
In the small-scale Puppet environment, it is generally to modify the / etc/hosts file to realize the service communication through the host name. However, thousands of servers need to build their own DNS server to realize the service communication through the host name. This experiment is realized by modifying the / etc/hosts file.
192.168.10.101 Host operation hostnamectl set-hostname master su 192.168.10.102 Host operation hostnamectl set-hostname client1 su 192.168.10.103 Host operation hostnamectl set-hostname client2 su
2. Turn off the firewall kernel security mechanism and all host operations
systemctl stop firewalld systemctl disable firewalld setenforce 0 sed -i "s/^SELINUX=.*/SELINUX=disabled/g" /etc/selinux/config
3. Install and start the time synchronization server and all host operations
yum -y install chrony systemctl start chronyd systemctl enable chronyd chronyc sources -v
4. Add hosts resolution and all host operations
cat >> /etc/hosts << EOF 192.168.10.101 master 192.168.10.102 client1 192.168.10.103 client2 EOF
Puppet installation and deployment
1. Install puppet server and master host operation
From the official website https://yum.puppetlabs.com/el/7/products/x86_64/ Download puppetlabs-release-7-12 noarch. RPM package and upload it to the master server.
#Unzip the source package rpm -ivh puppetlabs-release-7-12.noarch.rpm #Install and start puppet server yum install -y puppet-server systemctl start puppetmaster systemctl enable puppetmaster
2. Install Puppet and operate two client hosts
#Upload the puppetlabs source to the client host and install the puppetlabs source rpm -ivh puppetlabs-release-7-12.noarch.rpm #Install puppet yum install -y puppet
3. Modify the configuration files of the two clients
vim /etc/puppet/puppet.conf #Add the "server = master" configuration field under the [main] heading in the file to set the domain name of puppet server server = master #master host name. If there is a DNS server, you can write the domain name
4. Apply for registration on two clients
#client1 host registration puppet agent --server=master --no-daemonize --verbose #client2 host registration puppet agent --server=master --no-daemonize --verbose #Wait a moment, and then you can press Ctrl+C to end
5. View the clients applying for registration on the master side
puppet cert --list "client1" (SHA256) 1D:D4:FE:81:C7:C3:98:1C:53:28:86:49:6E:1C:FF:13:7F:61:D3:0C:DC:2F:94:51:49:18:8E:EB:C8:24:1A:1C "client2" (SHA256) 02:3D:64:24:56:42:F4:CE:46:B5:96:91:06:CF:E9:E9:FB:1D:CD:BC:CB:CF:CA:CD:55:27:A1:7F:17:9E:72:29
6. Register all unregistered clients on the master side
puppet cert sign --all Notice: Signed certificate request for client1 Notice: Removing file Puppet::SSL::CertificateRequest client1 at '/var/lib/puppet/ssl/ca/requests/client1.pem' Notice: Signed certificate request for client2 Notice: Removing file Puppet::SSL::CertificateRequest client2 at '/var/lib/puppet/ssl/ca/requests/client2.pem' #If you want to allow a single client to register, you can use the following command puppet cert sign Client host name or domain name #After successful registration, you can view the registered clients through the directory ll /var/lib/puppet/ssl/ca/signed/ Total consumption 12 -rw-r--r--. 1 puppet puppet 1931 5 March 31-17:20 client1.pem -rw-r--r--. 1 puppet puppet 1931 5 March 31-17:20 client2.pem -rw-r--r--. 1 puppet puppet 1927 5 March 31-15:53 master.pem
Configuration instance
In order to protect the ssh port of Linux, modify the client ssh port in batch, change the default port 22 to 9922, and restart. Create an ssh module on the Master side. The module directory is ssh. There are three subdirectories under the module Directory: manifests, templates and files.
-
The manifest must contain an init pp file, which is the initial (entry) file of the module. When importing a module, it will start from init pp start execution. You can write all the code to init pp can also be divided into multiple pp files. Init contains other files. ssh must be used to define the class name in order to realize the call.
-
The files directory is the file distribution directory of the module. Puppet provides a file distribution mechanism, similar to the rsync module.
-
The templates directory contains erb model files, which are related to the template attribute of the file resource (rarely used).
Configure the test node and operate on the master side
The Master needs to use the following configuration files:
-
Node information: in / etc / puppet / manifest / nodes/
-
Module information: in / etc/puppet/modules/
(1) Create the required directory on the Master
cd /etc/puppet/ mkdir -p modules/ssh/{manifests,templates,files} mkdir manifests/nodes mkdir modules/ssh/files/ssh chown -R puppet modules/ #Modify permissions ll modules/ssh #Check the structure in / etc/puppet/modules/ssh directory Total consumption 0 drwxr-xr-x. 3 puppet root 17 5 March 31-17:31 files drwxr-xr-x. 2 puppet root 6 5 March 31-17:31 manifests drwxr-xr-x. 2 puppet root 6 5 March 31-17:31 templates
(2) Create the module configuration file install pp
vim /etc/puppet/modules/ssh/manifests/install.pp #Enter the following information (make sure the client installs SSH service first) class ssh::install{ package{ "openssh": ensure => present, } }
(3) Create module configuration file config pp
vim /etc/puppet/modules/ssh/manifests/config.pp #Enter the following information to configure the files to be synchronized class ssh::config{ # Configure the files that the client needs to synchronize file { "/etc/ssh/sshd_config": # Make sure the client file exists ensure => present, # User to which the file belongs owner =>"root", # Group to which the file belongs group =>"root", # File properties mode =>"0600", # Synchronize files from the server source =>"puppet://$puppetserver/modules/ssh/ssh/sshd_config", # Call install PP make sure ssh is installed require => Class["ssh::install"], # If config Notify service when PP changes pp notify => Class["ssh::service"], } }
(4) Create module configuration file service pp
vim /etc/puppet/modules/ssh/manifests/service.pp class ssh::service { service {"sshd": ensure=>running, #Confirm ssh operation hasstatus=>true, #puppet this service supports the status command, which is similar to service sshd status hasrestart=>true, #Puppet this service supports the restart command, which is similar to service sshd restart enable=>true, #Whether the service is started require=>Class["ssh::config"] #Confirm config PP call } }
(5) Create module master configuration file init pp
vim /etc/puppet/modules/ssh/manifests/init.pp class ssh{ include ssh::install,ssh::config,ssh::service #Load the above configuration file } #At this time, there are four files in the / etc / puppet / modules / SSH / manifest directory ll /etc/puppet/modules/ssh/manifests/ Total consumption 16 -rw-r--r--. 1 root root 628 5 March 31-17:46 config.pp -rw-r--r--. 1 root root 63 5 March 31-17:47 init.pp -rw-r--r--. 1 root root 79 5 March 31-17:45 install.pp -rw-r--r--. 1 root root 186 5 March 31-17:46 service.pp
(6) Establish server-side ssh unified maintenance file
Copy server side / etc / SSH / sshd_ Default path from config file to module.
cp /etc/ssh/sshd_config /etc/puppet/modules/ssh/files/ssh/ chown -R puppet /etc/puppet/modules/ssh/files/ssh/
(7) Create test node profile
Create a test node configuration file and load SSH.
vim /etc/puppet/manifests/nodes/ssh.pp node 'client1'{ #Note that node is followed by the host name or domain name of the client include ssh } node 'client2'{ include ssh }
(8) Load the test node into the Puppet, that is, modify the site pp
vim /etc/puppet/manifests/site.pp import "nodes/ssh.pp"
(9) Modify the sshd maintained by the server_ Config configuration file
vim /etc/puppet/modules/ssh/files/ssh/sshd_config Port 9922 #Uncomment and change to 9922
(10) Restart the puppet master service
systemctl restart puppetmaster tree /etc/puppet /etc/puppet ├── auth.conf ├── environments │ └── example_env │ ├── manifests │ ├── modules │ └── README.environment ├── fileserver.conf ├── manifests │ ├── nodes │ │ └── ssh.pp │ └── site.pp ├── modules │ └── ssh │ ├── files │ │ └── ssh │ │ └── sshd_config │ ├── manifests │ │ ├── config.pp │ │ ├── init.pp │ │ ├── install.pp │ │ └── service.pp │ └── templates └── puppet.conf 12 directories, 11 files
Client active pull
On one of the client1 clients, perform the following operations to actively pull the configuration from the server.
puppet agent -t netstat -tunlp | grep ssh #Check the TCP/UDP port number and filter out the ssh port number tcp 0 0 0.0.0.0:9922 0.0.0.0:* LISTEN 19797/sshd tcp6 0 0 :::9922 :::* LISTEN 19797/sshd #The ssh port number turned out to be 9922
Active push of server
In large-scale deployment, it is impossible to use pull action on each client, but it is more reasonable to use server push mode at this time. Make changes on client client2.
(1) Modify the puppet configuration file and add the following in the last line.
vim /etc/puppet/puppet.conf #Add on the last line of the file listen = true #Listen port 8139
(2) Modify the authentication configuration file auth Conf defines some authentication information and access rights, and the last line is added as follows.
vim /etc/puppet/auth.conf #Add the following to the last line allow * #Allow any server push
(3) Start the Puppet Agent client.
systemctl start puppetagent
(4) Modify / etc / SSH / sshd of client client2_ Config file, restore Port 9922 to its initial state, and then restart the sshd service.
vim //etc/ssh/sshd_config #Port 22 systemctl restart sshd netstat -tunlp | grep ssh tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 18913/sshd tcp6 0 0 :::22 :::* LISTEN 18913/sshd
(5) Push the configuration to the client2 node, and operate the master host
puppet kick client2
If the "error: host client 2 fails: connection rejected - connection (2)" appears, go to the client to check the status of the following puppetagent
Client view status
Directly put / var / run / puppet / agent PID file deletion
cd /var/run/puppet/ rm -rf agent.pid #Then restart the puppetagent systemctl restart puppetagent systemctl status puppetagent
Then go to the master host to push again, and there will be no errors
(6) Check results, client2 host operation
At this time, you can see that the SSH port has been changed to 9922 on the client2 host.
cat /etc/ssh/sshd_config | grep Port #Port 9922 #GatewayPorts no netstat -tunlp | grep sshd tcp 0 0 0.0.0.0:9922 0.0.0.0:* LISTEN 19158/sshd tcp6 0 0 :::9922 :::* LISTEN 19158/sshd
Extension: puppet kick -p 10 -host client #-p means that a batch of 10 clients are pushed -- to whom is the host pushed