在Centos7下源代碼安裝配置Nginx

1.安裝前準備開發環境
安裝pcre開發包：yum install -y pcre-devel

安裝編譯源碼所需的工具和庫：yum install gcc gcc-c++ ncurses-devel perl

安裝cmake：yum -y install make gcc gcc-c++ ncurses-devel

安裝ssl功能須要openssl庫：yum -y install openssl-devel

安裝壓縮包：yum -y install zlib zlib-devel

 

系統信息：

CentOS Linux release 7.2.1511 (Core)

Kernel: Linux 3.10.0-327.el7.x86_64

 

Nginx安裝包：

Nginx-1.11.1.tar.gz

下載地址：http://nginx.org/en/download.html

 

參考文檔:

http://nginx.org/en/docs/http/load_balancing.html

 

 2.安裝過程
2.1.解壓文件

進入到nginx文件在所在目錄下，對nginx文件包進行受權。Chmod 766 nginx-1.11.1.tar.gz

 

輸入tar –zxvf nginx-1.11.1.tar.gz進行解壓文件。

 

輸入ls –l查看目錄下的文件。

 

輸入mv nginx-1.11.1 nginx1.11就行修改文件夾名稱。

 

2.2.初始化配置

 

輸入cd nginx進入到nginx1.11目錄下，而後輸入./configure（或者設置./configure --prefix=/usr/local/nginx 指定安裝的URL地址）後，進行編譯安裝。

 

編譯成功。目錄在/usr/local/nginx下。

2.3編譯安裝文件

 

輸入make&&make install進行編譯安裝。

 

編譯安裝成功後，輸入whereis nginx查看nginx路徑。

 

輸入cd /usr/local/nginx查看nginx目錄下的文件

2.4 配置Nginx

進行配置Nginx以前，先對輸入cp nginx.conf nginx.conf.bak命令，對nginx.conf文件進行備份。

 

輸入vi nginx.conf對文件進行編輯。

 

 

配置以下：

 upstream www.copp.com {
        server 10.190.130.70:8850 weight=3;
        server 10.190.130.71:8850 weight=1; 
    }

    server {
       listen 8007;
       server_name  10.190.130.73;
       location / {
         proxy_pass http://www.copp.com;
      }
    
    }

進行配置COPP項目的負載均衡，採用權重方式均衡。

2.5運行Nginx

 

保存nginx.conf文件，輸入cd ..，回到/usr/local/nginx/sbin目錄下輸入./nginx啓動nginx服務。輸入ps –ef |grep nginx查看運行的進程。

運行nginx：./nginx

重啓nginx：./nginx -s reload

中止nginx：./nginx -s stop

 

輸入netstat –ntlp | grep nginx查看nginx的通訊端口。

 

輸入wget htt:\\10.190.130.78:8007就測試到配置是否成功。

2.6.在Firewall啓動狀態下運行Nginx

 

在Firewall啓動的狀況下，其餘客戶端沒法訪問到htt:\\10.190.130.78:8007。

 

 

在Firewall中添加8007端口，firewall-cmd –permanent–add-port=8007/tcp，而後在輸入firewall-cmd –reload，重載成功事後，
在輸入firewall-cmd –list-all，可顯示添加的8007端口。

輸入netstat -ntlp | grep nginx查看nginx的佔用端口

在其餘客戶端中輸入wget http://10.190.130.78:8007就能夠訪問成功。

 

3.設置自定義開機系統服務
CentOS 7 使用systemd替換了SysV。Systemd目的是要取代Unix時代以來一直在使用的init系統，兼容SysV和LSB的啓動腳本，並且夠在進程啓動過程當中

更有效地引導加載服務。

systemd的特性有：

支持並行化任務

同時採用socket式與D-Bus總線式激活服務；

按需啓動守護進程（daemon）；

利用 Linux 的 cgroups 監視進程；

支持快照和系統恢復；

維護掛載點和自動掛載點；

各服務間基於依賴關係進行精密控制。

 

檢視和控制systemd的主要命令是systemctl。該命令可用於查看系統狀態和管理系統及服務。詳見man 1 systemctl。

 

輸入vim /usr/lib/systemd/system/nginx.service進入文件編輯。

將如下內容拷貝到nginx.service文件中，而後保存。

 

[Unit]

Description=nginx servicedaemon

After=network.target

 

[Service]

Type=forking

PIDFile=/usr/local/nginx/logs/nginx.pid  #nginx安裝路徑下的nginx.pid文件

ExecStart=/usr/local/nginx/sbin/nginx

ExecReload=/usr/local/nginx/sbin/nginx-s reload

ExecStop=/usr/local/nginx/sbin/nginx-s stop

PrivateTep=true

 

[Install]

WantedBy=multi-user.target

 

保存文件後，啓動nginx服務器會出現錯誤。必需要輸入systemctl daemon-reload，重載後臺服務。

 

 

輸入systemctl daemon-reload，重載後臺服務。可使用systemctl命令對nginx進行操做

若是須要更詳細的配置，請參考：

https://www.freedesktop.org/software/systemd/man/systemd.service.html

使用單元

一個單元配置文件能夠描述以下內容之一：系統服務（.service）、掛載點（.mount）、sockets（.sockets）、系統設備（.device）、交換分區（.swap）、文件路徑（.path）、啓動目標（.target）、由 systemd 管理的計時器（.timer）。詳情參閱 man 5 systemd.unit。

使用 systemctl 控制單元時，一般須要使用單元文件的全名，包括擴展名（例如 sshd.service）。可是有些單元能夠在systemctl中使用簡寫方式。

若是無擴展名，systemctl 默認把擴展名看成 .service。例如 netcfg 和 netcfg.service 是等價的。

掛載點會自動轉化爲相應的 .mount 單元。例如 /home 等價於 home.mount。

設備會自動轉化爲相應的 .device 單元，因此 /dev/sda2 等價於 dev-sda2.device。

注: 有一些單元的名稱包含一個 @ 標記， (e.g. name@string.service): 這意味着它是模板單元name@.service 的一個實例。 string 被稱做實例標識符, 在 systemctl 調用模板單元時，會將其看成一個參數傳給模板單元，模板單元會使用這個傳入的參數代替模板中的 %I 指示符。在實例化以前，systemd 會先檢查 name@string.suffix 文件是否存在（若是存在，應該就是直接使用這個文件，而不是模板實例化了）。大多數狀況下，包換 @ 標記都意味着這個文件是模板。若是一個模板單元沒有實例化就調用，該調用會返回失敗，由於模板單元中的 %I 指示符沒有被替換。

例如：systemctl start <單元>

 

編寫單元文件

systemd單元文件的語法來源於 XDG桌面入口配置文件.desktop文件，最初的源頭則是MicrosoftWindows的.ini文件。單元文件能夠從兩個地方加載，優先級從低到高分別是：

/usr/lib/systemd/system/: 軟件包安裝的單元

/etc/systemd/system/: 系統管理員安裝的單元

注意: 當systemd運行在用戶模式下時，使用的加載路徑是徹底不一樣的。

 

處理依賴關係

使用systemd時，可經過正確編寫單元配置文件來解決其依賴關係。典型的狀況是，單元A要求單元B在A啓動以前運行。在此狀況下，向單元A配置文件中的 [Unit] 段添加 Requires=B 和 After=B 便可。若此依賴關係是可選的，可添加 Wants=B 和 After=B。請注意 Wants= 和 Requires= 並不意味着 After=，即若是 After= 選項沒有制定，這兩個單元將被並行啓動。

依賴關係一般被用在服務（service）而不是目標（target）上。例如， network.target 通常會被某個配置網絡接口的服務引入，因此，將自定義的單元排在該服務以後便可，由於 network.target 已經啓動。

服務類型

編寫自定義的 service 文件時，能夠選擇幾種不一樣的服務啓動方式。啓動方式可經過配置文件 [Service] 段中的 Type= 參數進行設置。

Type=simple（默認值）：systemd認爲該服務將當即啓動。服務進程不會fork。若是該服務要啓動其餘服務，不要使用此類型啓動，除非該服務是socket激活型。

Type=forking：systemd認爲當該服務進程fork，且父進程退出後服務啓動成功。對於常規的守護進程（daemon），除非你肯定此啓動方式沒法知足需求，使用此類型啓動便可。使用此啓動類型應同時指定 PIDFile=，以便systemd可以跟蹤服務的主進程。

Type=oneshot：這一選項適用於只執行一項任務、隨後當即退出的服務。可能須要同時設置 RemainAfterExit=yes 使得 systemd 在服務進程退出以後仍然認爲服務處於激活狀態。

Type=notify：與 Type=simple 相同，但約定服務會在就緒後向 systemd 發送一個信號。這一通知的實現由 libsystemd-daemon.so 提供。

Type=dbus：若以此方式啓動，當指定的 BusName出如今DBus系統總線上時，systemd認爲服務就緒。

Type=idle: systemd會等待全部任務(Jobs)處理完成後，纔開始執行idle類型的單元。除此以外，其餘行爲和Type=simple 相似。

type的更多解釋能夠參考systemd.service(5)。

3.1.設置開機服務

 

輸入systemctl start nginx啓動nginx服務，在輸入systemctl enable nginx 設置nginx服務爲開機啓動服務，最後，輸入systemctl status nginx查看nginx的運行狀態。

3.2.中止開機服務

 

輸入systemctl disable nginx中止開機啓動nginx服務，輸入systemctlstop nginx中止nginx服務，輸入systemctl status nginx查看nginx的運行狀態。

4.負載均衡策略
在nginx中支持的負載均衡策略以下：

輪詢加權策略（Round-Robin）：在輪詢模策略中，要求應用服務器是分佈式的

最少鏈接策略（Least-Connected）：下一個請求是分配給最少的活動鏈接數服務器。

IP哈希策略（IP-Hash）：一個哈希函數用來決定那個服務器被選擇做爲下一個請求處理的服務器（基於客戶端的IP地址）。

4.1.輪詢策略
http {

   upstream myapp1 {           #服務器組，組名：myapp1

       server srv1.example.com;  #web應用服務器1

       server srv2.example.com;  #web應用服務器2

       server srv3.example.com;  #web應用服務器3

    }

 

   server {

       listen 80;

 

       location / {

           proxy_pass http://myapp1;          #客戶端訪問的URL

       }

    }

}

以上是最簡單的Nginx負載均衡配置。在upstream myapp1中有3個應用服務器實例，當負載均衡中沒有指定配置負載策略時，默認是使用輪詢權重策略。全部請求都是代理給服務器組myapp1，Nginx應用http負載均衡到分佈式請求中。

在Nginx反向代理負載均衡的擴展包括：http，https，FastCGI，uwsgi，SCGI和緩存。

配置負載均衡

配置https負載均衡代替http，只使用「https」做爲協議就能夠了。

當設置負載均衡爲FastCGI，uwsgi，SCGI，或緩存，指令分別使用fastcgi_pass，uwsgi_pass，scgi_pass，和memcached_pass。

若是能夠把加權輪詢算法分爲先深搜索和先廣搜索，那麼nginx採用的是先深搜索算法，即將首先將請求都分給高權重的機器，直到該機器的權值降到了比其餘機器低，纔開始將請求分給下一個高權重的機器；第二，當全部後端機器都down掉時，nginx會當即將全部機器的標誌位清成初始狀態，以免形成全部的機器都處在timeout的狀態，從而致使整個前端被夯住。

4.2.最少鏈接策略
upstream myapp1 {                     #服務器組，組名：myapp1

       least_conn;                  #least_conn;最少鏈接策略

       server srv1.example.com;       #web應用服務器1

       server srv2.example.com;       #web應用服務器2

       server srv3.example.com;       #web應用服務器3

}

最少鏈接容許控制加載應用實例，更多適合在一些花費比較長時間去完成請求的一個場景中。

用最少鏈接負載均衡，Nginx會盡可能不要求過載繁忙的應用服務器去執行請求，分配新的請求給一個不太忙碌的服務器代替執行。

最少鏈接負載均衡在Nginx中被激活時，least_conn指令被用來做爲服務器羣組配置的一個部分。

4.3.IP哈希策略
配置IP哈希負載均衡，只須要添加ip_hash指令指向服務器(uptream) 組配置：

upstream myapp1 {

   ip_hash;

   server srv1.example.com;

   server srv2.example.com;

   server srv3.example.com;

}

每一個客戶端請求都有可能發送到不一樣的服務器，不能保證同一個客戶端老是指向同一個服務器。若是一個客戶端必需要跟服務器的會話關聯在一塊兒的時候，可使用IP哈希負載均衡緩存策略。

經過獲取客戶端額IP地址，通過哈希函數的計算獲得一個值，利用該值對服務器的列表大小進行取模運算，獲得的值就是處理客戶端請求的服務器序號。採用IP哈希負載均衡策略，的優勢是，同一個客戶端的IP地址，每次發送的請求都是指向同一臺服務器進行處理。這種方式確保來自同一個客戶端請求老是指向同一個服務器除非這個服務是無效的。

舉例子說明：

例如一個系統的會話存儲用戶信息，每次將請求發送到服務器，服務器都會從會話中獲取數據。但在負載均衡環境中，每次客戶端的每次請求均可能由不一樣的服務器處理，因此可能出現沒法獲取的到客戶端的會話數據（因爲會話數據是保存在服務器的內存中）。

4.4.權重策略
使用服務器權重策略，它也有可能影響到Nginx負載均衡算法。

在上面的例子中，服務器權重沒有配置，意味着全部指定的服務器都被視爲同等資格的一個特定負載均衡策略。尤爲是輪詢策略，它也意味着差很少平等地分配請求給服務器，而且快速平均地處理請求。

 

當權重參數被指定在一個服務器時，權重做爲負載均衡決策的部分。

upstream myapp1 {

       server srv1.example.com weight=3;

       server srv2.example.com;

       server srv3.example.com;

}

在這個配置中，每5個請求都分配給應用服務器實例以下：

3個請求將分配到serv1中，1個請求分配給srv2中，而另外1個請求則分配個srv3中。

在最近的Nginx版本中，它一樣能夠與最少鏈接和IP哈希策略同樣去使用權重策略。

4.5.總結
輪詢策略：

優勢：若是但願每一個服務器都能平均處理客戶端請求可以使用輪詢策略。

缺點：不支持會話管理，另外，假設有5個客戶端請求，有2臺服務器處理請求，某一臺服務器處理請求時消耗資源比較大，每次都接到消耗資源比較大的請求，那麼該服務器處理能力就會降低。

 

IP哈希策略：

缺點：使用該策略，服務器可能不會平均處理每一個請求。假設有5個客戶端請求，那麼經過計算出哈希值後，可能都是由一臺服務器處理。其它的服務器可能沒有請求須要處理。

優勢：支持會話管理，若是系統中使用會話處理數據，該策略比較適合。

 

最少鏈接策略：

優勢：系統把新鏈接分配給當前鏈接數目最少的服務器。該算法在各個服務器運算能力基本類似的環境中很是有效。此負載均衡策略適合請求處理時間長短不一形成服務器過載的狀況。

缺點：雖然某個服務器的鏈接數較少，但處理請求時間較長，這時候再接受請求處理，可能影響到時間效率的問題。

 

權重策略：

優勢：若是服務器的硬件等級差異比較大，那麼配置高的服務器可分配較高權重，以便處理更多的請求。而配置低的服務器可接受少許請求。

缺點：若是服務器的硬件等級同樣不太適合使用該策略。
5.健康檢查
在Nginx反向代理中實現主動或被動健康檢查，若是指定的響應服務器出現錯誤，Nginx將標記該服務器爲失敗，將盡可能去避免爲後續的請求選擇該服務器。

設置發生在超時失敗期間連續不成功的服務器通訊的max_fails指令。默認max_fails設置是1，當設置爲0次時，這臺服務器的檢查檢查不啓用。Fail_timeout參數定義服務器多長時間將被標記爲失敗。在服務器fail_timeout期間，Nginx不會立刻將該服務器標記爲失敗的服務器，而是模擬想客戶端請求去偵查服務器，若是偵查成功，該服務器標記爲在線服務器。

關於健康檢查的的插件須要花錢購買，更多的信息請參考：

https://www.nginx.com/products/application-health-checks/

https://www.nginx.com/resources/admin-guide/installing-nginx-plus/

6.附錄
6.1.systemctl命令指南
Systemctl是一個systemd工具，主要負責控制systemd系統和服務管理器。

Systemd是一個系統管理守護進程、工具和庫的集合，用於取代System V初始進程。Systemd的功能是用於集中管理和配置類UNIX系統。

在Linux生態系統中，Systemd被部署到了大多數的標準Linux發行版中，只有爲數很少的幾個發行版還沒有部署。Systemd一般是全部其它守護進程的父進程，

但並不是老是如此。使用Systemctl管理Linux服務

6.1.1.Systemd初體驗和Systemctl基礎
6.1.1.1.1.檢查systemd安裝版本
1. 首先檢查你的系統中是否安裝有systemd並肯定當前安裝的版本

# systemd –version

 

6.1.1.1.2.檢查systemd和systemctl的二進制文件和庫文件的安裝位置

# whereis system

# whereis systemctl

6.1.1.1.3檢查systemd是否運行

 

# ps -eaf | grep system

6.1.1.4.分析systemd啓動進程

 

# systemd-analyze

6.1.1.5.分析啓動時各個進程花費的時間

#systemd-analyze blame

6.1.1.6.分析啓動時的關鍵鏈

 

# systemd-analyze critical-chain

重要：Systemctl接受服務（.service），掛載點（.mount），套接口（.socket）和設備（.device）做爲單元。

Systemctl是一個systemd工具，主要負責控制systemd系統和服務管理器。

Systemd是一個系統管理守護進程、工具和庫的集合，用於取代System V初始進程。Systemd的功能是用於集中管理和配置類UNIX系統。

在Linux生態系統中，Systemd被部署到了大多數的標準Linux發行版中，只有爲數很少的幾個發行版還沒有部署。Systemd一般是全部其它守護進程的父進程，

但並不是老是如此。

 

 

使用Systemctl管理Linux服務

本文旨在闡明在運行systemd的系統上「如何控制系統和服務」。

Systemd初體驗和Systemctl基礎

1. 首先檢查你的系統中是否安裝有systemd並肯定當前安裝的版本

# systemd--version
systemd 215
+PAM +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP-APPARMOR

上例中很清楚地代表，咱們安裝了215版本的systemd。

2. 檢查systemd和systemctl的二進制文件和庫文件的安裝位置

# whereissystemd
systemd:/usr/lib/systemd /etc/systemd /usr/share/systemd/usr/share/man/man1/systemd.1.gz
# whereis systemctl
systemctl:/usr/bin/systemctl /usr/share/man/man1/systemctl.1.gz

3. 檢查systemd是否運行

# ps -eaf | grep[s]ystemd
root 10016:27?00:00:00/usr/lib/systemd/systemd --switched-root --system--deserialize 23
root 4441016:27?00:00:00/usr/lib/systemd/systemd-journald
root 4691016:27?00:00:00/usr/lib/systemd/systemd-udevd
root 5551016:27?00:00:00/usr/lib/systemd/systemd-logind
dbus 5561016:27?00:00:00/bin/dbus-daemon --system --address=systemd:--nofork--nopidfile --systemd-activation

注意：systemd是做爲父進程（PID=1）運行的。在上面帶（-e）參數的ps命令輸出中，選擇全部進程，（-a）選擇除會話前導外的全部進程，並使用（-f）參數輸出完整格式列表（即 -eaf）。

也請注意上例中後隨的方括號和例子中剩餘部分。方括號表達式是grep的字符類表達式的一部分。

4. 分析systemd啓動進程

#systemd-analyze
Startup finished in487ms(kernel)+2.776s(initrd)+20.229s(userspace)=23.493s

5. 分析啓動時各個進程花費的時間

#systemd-analyze blame
8.565s mariadb.service
7.991s webmin.service
6.095s postfix.service
4.311s httpd.service
3.926s firewalld.service
3.780s kdump.service
3.238s tuned.service
1.712s network.service
1.394s lvm2-monitor.service
1.126s systemd-logind.service
....

6. 分析啓動時的關鍵鏈

#systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@"character.
The time the unit takes to start is printed after the "+" character.
multi-user.target @20.222s
└─mariadb.service @11.657s+8.565s
└─network.target @11.168s
└─network.service @9.456s+1.712s
└─NetworkManager.service @8.858s+596ms
└─firewalld.service @4.931s+3.926s
└─basic.target @4.916s
└─sockets.target @4.916s
└─dbus.socket @4.916s
└─sysinit.target @4.905s
└─systemd-update-utmp.service @4.864s+39ms
└─auditd.service @4.563s+301ms
└─systemd-tmpfiles-setup.service @4.485s+69ms
└─rhel-import-state.service @4.342s+142ms
└─local-fs.target @4.324s
└─boot.mount @4.286s+31ms
└─systemd-fsck@dev-disk-by\x2duuid-79f594ad\x2da332\x2d4730\x2dbb5f\x2d85d19608096
└─dev-disk-by\x2duuid-79f594ad\x2da332\x2d4730\x2dbb5f\x2d85d196080964.device@4

重要：Systemctl接受服務（.service），掛載點（.mount），套接口（.socket）和設備（.device）做爲單元。

6.1.1.7.列出全部可用單元

 

# systemctl list-unit-files

6.1.1.8.列出全部運行中單元

 

# systemctl list-units

6.1.1.9.列出全部失敗單元

 

# systemctl –failed

6.1.1.10.檢查某個單元是否啓用

 

# systemctl is-enabled nginx.service 

6.1.1.11.檢查某個單元或服務是否運行

 # systemctl status nginx.service

 

實戰備註：

 

第一步：wget http://nginx.org/download/nginx-1.11.1.tar.gz

 

//nginx須要分組獲取權限，否則php-fpm啓動不了

useradd -s /sbin/nologin -M nginx

 

nginx加入到開機自動啓動

到這裏咱們的nginx尚未實現開機自動啓動 那麼咱們就把他加入到開機自動啓動服務中！咱們先編輯系統啓動腳本vi /etc/rc.local 這個文件是系統啓動後會自動執行的,咱們就將啓動命令加入到這個文件中

/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf &

若是咱們不在nginx程序的目錄中沒法使用nginx的命令 會提示找不到nginx

 

下面咱們將nginx的位置加入到環境變量中

vi /etc/profile

更新環境變量

export PATH="$PATH:/usr/local/nginx/sbin;"

source /etc/profile

 

啓動nginx服務並將其設爲開機啓動：

systemctl   start   nginx

systemctl   enable   nginx

 

運行nginx：./nginx

重啓nginx：./nginx -s reload

中止nginx：./nginx -s stop

server{
    location   /   {
        root /data/www;
        index index.php  index.html  index.htm;
    }
    location   ~   \.php$  {
        root /data/www;
        fastcgi_indexindex.php;
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_param   SCRIPT_FILENAME    $document_root$fastcgi_script_name;
        include  fastcgi_params;
    }
}