Nginx安裝與使用 及在redhat 中的簡單安裝方式

時間  2019-12-01
標籤 nginx 安裝 使用 redhat 簡單 方式 欄目 Nginx 简体版
原文   原文鏈接

首先說下在redhat中的安裝方法，

正常安裝nginx 須要安裝不少的依賴，最後再安裝nginx，並且很容易出錯。php

在nginx官方上有這麼一段描述：html

Pre-Built Packages for Mainline version

To set up the yum repository for RHEL/CentOS, create the file named /etc/yum.repos.d/nginx.repo with the following contents:java

[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/mainline/OS/OSRELEASE/$basearch/
gpgcheck=0
enabled=1

Replace 「OS」 with 「rhel」 or 「centos」, depending on the distribution used, and 「OSRELEASE」 with 「6」 or 「7」, for 6.x or 7.x versions, respectively.linux

 

直譯爲下：nginx

在 /etc/yum.repos.d/ 目錄下新建 nginx.repo 文件 內容以下：c++

[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/mainline/rhel/7/$basearch/
gpgcheck=0
enabled=1apache

 

 

而後 執行  yum install nginx 命令 ubuntu

nginx 就安裝好了  windows

安裝在 /etc/nginx 下 只須要修改配置文件就行了 後端

 啓動：service nginx start

從新加載配置文件：nginx -s reload

 

好吧 今天配置新環境時， 執行  yum install nginx 命令   報錯了   提示找不到  /mnt/cdrom/repodata/repomd.xml  這個文件，

網上扒了 一下午  又是 在 /etc/yum.repos.d/ 下加   CentOS-Base.repo  又是 刪除 安裝 什麼  yum- *  扒拉扒拉一大堆，都沒用 

最後找到一個很簡單的方法 ：

/etc/yum.repos.d/   這個目錄下有個   redhat 默認的 repo 文件 叫 ：rhel.repo

這個文件裏默認的內容是：

 

[rhel]
name=Red Hat Enterprise Linux packages
baseurl=file:///mnt/cdrom/
enabled=1
gpgcheck=0

改後爲：

[rhel]
name=Red Hat Enterprise Linux packages
baseurl=baseurl=http://mirrors.163.com/centos/7/os/x86_64/
enabled=1
gpgcheck=0

 

而後再 執行  yum install nginx 命令  就能夠了  

 

 

============分割線========================分割線=============================分割線============================

 

 

前言

Nginx是一款輕量級的Web 服務器/反向代理服務器及電子郵件（IMAP/POP3）代理服務器，並在一個BSD-like 協議下發行。由俄羅斯的程序設計師Igor Sysoev所開發，供俄國大型的入口網站及搜索引擎Rambler（俄文：Рамблер）使用。其特色是佔有內存少，併發能力強，事實上nginx的併發能力確實在同類型的網頁服務器中表現較好。（百度百科- http://www.dwz.cn/x32kG）

1.Nginx安裝

我使用的環境是64位 Ubuntu 14.04。nginx依賴如下模塊：

l  gzip模塊須要 zlib 庫

l  rewrite模塊須要 pcre 庫

l  ssl 功能須要openssl庫

1.1.安裝pcre

  1. 獲取pcre編譯安裝包，在http://www.pcre.org/上能夠獲取當前最新的版本
  2. 解壓縮pcre-xx.tar.gz包。
  3. 進入解壓縮目錄，執行./configure。
  4. make & make install  

     

  5. 注：  若是  執行 ./configure 時 報錯  configure: error: You need a C++ compiler for C++ support
  6. 輸入  yum install -y gcc gcc-c++    能夠解決

  7. 1.2.安裝openssl

  9. 獲取openssl編譯安裝包，在http://www.openssl.org/source/上能夠獲取當前最新的版本。
  10. 解壓縮openssl-xx.tar.gz包。
  11. 進入解壓縮目錄，執行./config。
  12. make & make install

  13. 1.3.安裝zlib

  14. 獲取zlib編譯安裝包，在http://www.zlib.net/上能夠獲取當前最新的版本。
  15. 解壓縮openssl-xx.tar.gz包。
  16. 進入解壓縮目錄，執行./configure。
  17. make & make install

  18. 1.4.安裝nginx

  19. 獲取nginx，在http://nginx.org/en/download.html上能夠獲取當前最新的版本。
  20. 解壓縮nginx-xx.tar.gz包。
  21. 進入解壓縮目錄，執行./configure
  22. make & make install

若安裝時找不到上述依賴模塊，使用--with-openssl=<openssl_dir>、--with-pcre=<pcre_dir>、--with-zlib=<zlib_dir>指定依賴的模塊目錄。如已安裝過，此處的路徑爲安裝目錄；若未安裝，則此路徑爲編譯安裝包路徑，nginx將執行模塊的默認編譯安裝。

啓動 nginx

nginx的啓動命令是：

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

-c制定配置文件的路徑，不加-nginx會自動加載默認路徑的配置文件。

 

linux 64位安裝nginx後啓動出錯報如下錯誤

[root @localhost nginx- 1.3 . 0 ]# /usr/local/nginx/sbin/nginx
error while loading shared libraries: libpcre.so. 1 :
cannot open shared object file: No such file or directory
從錯誤看出是缺乏lib文件致使，進一步查看下
[root @localhost nginx- 1.3 . 0 ]# ldd $(which /usr/local/nginx/sbin/nginx)
linux-vdso.so. 1 =&gt; ( 0x00007fff4d5ff000 )
libpthread.so. 0 =&gt; /lib64/libpthread.so. 0 ( 0x00007fea7e357000 )
libcrypt.so. 1 =&gt; /lib64/libcrypt.so. 1 ( 0x00007fea7e120000 )
libpcre.so. 1 =&gt; not found
libz.so. 1 =&gt; /lib64/libz.so. 1 ( 0x00007fea7df09000 )
libc.so. 6 =&gt; /lib64/libc.so. 6 ( 0x00007fea7db76000 )
/lib64/ld-linux-x86- 64 .so. 2 ( 0x00007fea7e57d000 )
libfreebl3.so =&gt; /lib64/libfreebl3.so ( 0x00007fea7d913000 )
libdl.so. 2 =&gt; /lib64/libdl.so. 2 ( 0x00007fea7d70f000 )
 
能夠看出 libpcre.so.1 => not found 並無找到，進入/lib64目錄中手動連接下
 
[root @localhost /]# cd lib64/
[root @localhost lib64]# ln -s libpcre.so. 0.0 . 1 libpcre.so. 1
而後啓動nginx就ok了

啓動nginx以後，瀏覽器中輸入http://localhost能夠驗證是否安裝啓動成功。

若是頁面顯示  403 forbidden的錯誤

可能的緣由：一、nginx 安裝目錄下  html 的權限不夠 添加  讀取 寫入 執行  相關權限

　　　　　　二、網站根目錄不包含index指令設置的文件。 　　

　　 location / {
            root   html;
            index  index.html a.htm;
        }

即 以上配置節點 中 的  index.html 不在 安裝目錄  usr/local/nginx/html/ 這個目錄下

 

2.Nginx配置

安裝完成以後，配置目錄conf下有如下配置文件，過濾掉了xx.default配置：

tyler@ubuntu:/opt/nginx-1.7.7/conf$ tree |grep -v default

.

├── fastcgi.conf

├── fastcgi_params

├── koi-utf

├── koi-win

├── mime.types

├── nginx.conf

├── scgi_params

├── uwsgi_params

└── win-utf

除了nginx.conf，其他配置文件，通常只須要使用默認提供便可。

2.1.nginx.conf

nginx.conf是主配置文件，默認配置去掉註釋以後的內容以下圖所示：

l  worker_process表示工做進程的數量，通常設置爲cpu的核數

l  worker_connections表示每一個工做進程的最大鏈接數

l  server{}塊定義了虛擬主機

n  listener監聽端口

n  server_name監聽域名

n  location{}是用來爲匹配的 URI 進行配置，URI 即語法中的「/uri/」。location  / { }匹配任何查詢，由於全部請求都以 / 開頭。

u  root指定對應uri的資源查找路徑，這裏html爲相對路徑，完整路徑爲/opt/ opt/nginx-1.7.7/html/

u  index指定首頁index文件的名稱，能夠配置多個，以空格分開。若有多個，按配置順序查找。

 

從配置能夠看出，nginx監聽了80端口、域名爲localhost、跟路徑爲html文件夾（個人安裝路徑爲/opt/nginx-1.7.7，因此/opt/nginx-1.7.7/html）、默認index文件爲index.html， index.htm、服務器錯誤重定向到50x.html頁面。

能夠看到/opt/nginx-1.7.7/html/有如下文件：

tyler@ubuntu:/opt/nginx-1.7.7/html$ ls

50x.html  index.html

這也是上面在瀏覽器中輸入http://localhost，可以顯示歡迎頁面的緣由。實際上訪問的是/opt/nginx-1.7.7/html/index.html文件。

2.2.mime.types

文件擴展名與文件類型映射表，nginx根據映射關係，設置http請求響應頭的Content-Type值。當在映射表找不到時，使用nginx.conf中default-type指定的默認值。例如，默認配置中的指定的default-type爲application/octet-stream。

    include       mime.types;

    default_type  application/octet-stream;

默認

下面截一段mime.types定義的文件擴展名與文件類型映射關係，完整的請自行查看：

 

2.3.fastcgi_params

nginx配置Fastcgi解析時會調用fastcgi_params配置文件來傳遞服務器變量，這樣CGI中能夠獲取到這些變量的值。默認傳遞如下變量：

 

這些變量的做用從其命名能夠看出。

 

2.4.fastcgi.conf

對比下fastcgi.conf與fastcgi_params文件，能夠看出只有如下差別：

tyler@ubuntu:/opt/nginx-1.7.7/conf$ diff fastcgi.conf fastcgi_params

2d1

< fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;

即fastcgi.conf只比fastcgi_params多了一行「fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;」

本來只有fastcgi_params文件，fastcgi.conf是nginx 0.8.30 (released: 15th of December 2009)才引入的。主要爲是解決如下問題（參考：http://www.dwz.cn/x3GIJ）：

本來Nginx只有fastcgi_params，後來發現不少人在定義SCRIPT_FILENAME時使用了硬編碼的方式。例如，fastcgi_param SCRIPT_FILENAME /var/www/foo$fastcgi_script_name。因而爲了規範用法便引入了fastcgi.conf。

不過這樣的話就產生一個疑問：爲何必定要引入一個新的配置文件，而不是修改舊的配置文件？這是由於fastcgi_param指令是數組型的，和普通指令相同的是：內層替換外層；和普通指令不一樣的是：當在同級屢次使用的時候，是新增而不是替換。換句話說，若是在同級定義兩次SCRIPT_FILENAME，那麼它們都會被髮送到後端，這可能會致使一些潛在的問題，爲了不此類狀況，便引入了一個新的配置文件。

所以再也不建議你們使用如下方式（搜了一下，網上大量的文章，而且nginx.conf的默認配置也是使用這種方式）：

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

include fastcgi_params;

而使用最新的方式：

include fastcgi.conf;

 

2.5.uwsgi_params

與fastcgi_params同樣，傳遞哪些服務器變量，只有前綴不同，以uwsgi_param開始而非fastcgi_param。

2.6.scgi_params

與fastcgi_params同樣，傳遞哪些服務器變量，只有前綴不同，以uwsgi_param開始而非fastcgi_param。

2.7.koi-utf、koi-win、win-utf

這三個文件都是與編碼轉換映射文件，用於在輸出內容到客戶端時，將一種編碼轉換到另外一種編碼。

koi-win： charset_map  koi8-r < -- > windows-1251

koi-utf： charset_map  koi8-r < -- > utf-8

win-utf： charset_map  windows-1251 < -- > utf-8

koi8-r是斯拉夫文字8位元編碼，供俄語及保加利亞語使用。在Unicode未流行以前，KOI8-R 是最爲普遍使用的俄語編碼，使用率甚至起ISO/IEC 8859-5還高。這3個文件存在是由於做者是俄國人的緣由。

 以上均親測

Nginx負載均衡配置實例詳解

測試環境
因爲沒有服務器，因此本次測試直接host指定域名，而後在VMware裏安裝了三臺CentOS。

測試域名  ：a.com

A服務器IP ：192.168.5.149 （主）

B服務器IP ：192.168.5.27

C服務器IP ：192.168.5.126

部署思路
A服務器作爲主服務器，域名直接解析到A服務器（192.168.5.149）上，由A服務器負載均衡到B服務器（192.168.5.27）與C服務器（192.168.5.126）上。


域名解析

因爲不是真實環境，域名就隨便使用一個a.com用做測試，因此a.com的解析只能在hosts文件設置。

打開：C:WindowsSystem32driversetchosts

在末尾添加

192.168.5.149    a.com

保存退出，而後啓動命令模式ping下看看是否已設置成功

 

從截圖上看已成功將a.com解析到192.168.5.149IP

A服務器nginx.conf設置
打開nginx.conf，文件位置在nginx安裝目錄的conf目錄下。

在http段加入如下代碼

upstream a.com {
      server  192.168.5.126:80;
      server  192.168.5.27:80;
}
 
server{
    listen 80;
    server_name 192.168.5.149 a.com;
    location / {
        proxy_pass         http://a.com;
        proxy_set_header   Host             $host;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
    }
}

保存重啓nginx

B、C服務器nginx.conf設置
打開nginx.confi，在http段加入如下代碼

server{
    listen 80;
    server_name a.com;
    index index.html;
    root /data0/htdocs/www;
}

保存重啓nginx

測試
當訪問a.com的時候，爲了區分是轉向哪臺服務器處理我分別在B、C服務器下寫一個不一樣內容的index.html文件，以做區分。

打開瀏覽器訪問a.com結果  若是頁面 出現 錯誤 504 timeout 等  查看 A 服務器 安裝目錄下的 log/error.log

若是有 鏈接超時的錯誤 提示 須要加上如下配置  ip 地址 根據本身的實際狀況 修改

A：服務器以下

upstream abc.com {
        server   192.168.3.129:80;
        server   192.168.3.130:80;
    }
    server
    {
        listen 80;
        server_name 192.168.3.127 abc.com;    

        large_client_header_buffers 4 64k;
        client_max_body_size 300m;
        client_body_buffer_size 128k;   
                proxy_connect_timeout 600;
            proxy_read_timeout 600;
            proxy_send_timeout 600;
            proxy_buffer_size 64k;
            proxy_buffers   4 32k;
            proxy_busy_buffers_size 64k;
            proxy_temp_file_write_size 64k;
        location / {        
            
            proxy_connect_timeout 600;
            proxy_read_timeout 600;
            proxy_send_timeout 600;
            proxy_buffer_size 64k;
            proxy_buffers   4 32k;
            proxy_busy_buffers_size 64k;
            proxy_temp_file_write_size 64k;

             proxy_pass         http://abc.com;
            proxy_set_header   Host             $host;
            proxy_set_header   X-Real-IP        $remote_addr;
            proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
         }
    }

B C 服務器以下：

server{
        listen 80;
        server_name abc.com;

        large_client_header_buffers 4 64k;
        client_max_body_size 300m;
        client_body_buffer_size 128k;   
                proxy_connect_timeout 600;
            proxy_read_timeout 600;
            proxy_send_timeout 600;
            proxy_buffer_size 64k;
            proxy_buffers   4 32k;
            proxy_busy_buffers_size 64k;
            proxy_temp_file_write_size 64k;

        index index.html;
        root /data0/htdocs/www;
    }

若是A 服務器error.log  裏有 這個報錯   connect() failed (113: No route to host)

則 執行這個命令 iptables -I INPUT -p tcp --dport 80 -j ACCEPT

打開 設置 防火牆 容許 訪問 80 端口

若是A 服務器error.log  裏有 這個報錯    no live upstreams while connecting to upstream

正在 嘗試 解決

如今的 問題是  直接訪問abc.com  頁面提示 404

若是直接訪問 A 服務器ip 192.168.3.127  則能夠看到服務器B 或者C 的頁面   刷新頁面 會不停切換

 ip 訪問正常 域名訪問不了 這個應該是域名解析的問題  和nginx 自己無關 不整了 

nginx 和tomcat 整合  轉了一篇文章  不錯  沒有親測

打開瀏覽器訪問a.com結果，刷新會發現全部的請求均分別被主服務器（192.168.5.149）分配到B服務器（192.168.5.27）與C服務器（192.168.5.126）上，實現了負載均衡效果。

B服務器處理頁面

 

C服務器處理頁面

 

假如其中一臺服務器宕機會怎樣？
當某臺服務器宕機了，是否會影響訪問呢？

咱們先來看看實例，根據以上例子，假設C服務器192.168.5.126這臺機子宕機了（因爲沒法模擬宕機，因此我就把C服務器關機）而後再來訪問看看。

訪問結果：

 

咱們發現，雖然C服務器（192.168.5.126）宕機了，但不影響網站訪問。這樣，就不會擔憂在負載均衡模式下由於某臺機子宕機而拖累整個站點了。

若是b.com也要設置負載均衡怎麼辦？
很簡單，跟a.com設置同樣。以下：

假設b.com的主服務器IP是192.168.5.149，負載均衡到192.168.5.150和192.168.5.151機器上

現將域名b.com解析到192.168.5.149IP上。

在主服務器(192.168.5.149)的nginx.conf加入如下代碼：

upstream b.com {
      server  192.168.5.150:80;
      server  192.168.5.151:80;
}
 
server{
    listen 80;
    server_name b.com;
    location / {
        proxy_pass         http://b.com;
        proxy_set_header   Host             $host;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
    }
}
保存重啓nginx

在192.168.5.150與192.168.5.151機器上設置nginx，打開nginx.conf在末尾添加如下代碼：

server{
    listen 80;
    server_name b.com;
    index index.html;
    root /data0/htdocs/www;
}

保存重啓nginx

完成之後步驟後便可實現b.com的負載均衡配置。

主服務器不能提供服務嗎？
以上例子中，咱們都是應用到了主服務器負載均衡到其它服務器上，那麼主服務器自己能不能也加在服務器列表中，這樣就不會白白浪費拿一臺服務器純當作轉發功能，而是也參與到提供服務中來。

如以上案例三臺服務器：

A服務器IP ：192.168.5.149 （主）

B服務器IP ：192.168.5.27

C服務器IP ：192.168.5.126

咱們把域名解析到A服務器，而後由A服務器轉發到B服務器與C服務器，那麼A服務器只作一個轉發功能，如今咱們讓A服務器也提供站點服務。

咱們先來分析一下，若是添加主服務器到upstream中，那麼可能會有如下兩種狀況發生：

一、主服務器轉發到了其它IP上，其它IP服務器正常處理；

二、主服務器轉發到了本身IP上，而後又進到主服務器分配IP那裏，假如一直分配到本機，則會形成一個死循環。

怎麼解決這個問題呢？由於80端口已經用來監聽負載均衡的處理，那麼本服務器上就不能再使用80端口來處理a.com的訪問請求，得用一個新的。因而咱們把主服務器的nginx.conf加入如下一段代碼：

server{
    listen 8080;
    server_name a.com;
    index index.html;
    root /data0/htdocs/www;
}
 
重啓nginx，在瀏覽器輸入a.com:8080試試看能不能訪問。結果能夠正常訪問

 

既然能正常訪問，那麼咱們就能夠把主服務器添加到upstream中，可是端口要改一下，以下代碼：

upstream a.com {
      server  192.168.5.126:80;
      server  192.168.5.27:80;
      server  127.0.0.1:8080;
}

因爲這裏能夠添加主服務器IP192.168.5.149或者127.0.0.1都可以，都表示訪問本身。

重啓Nginx，而後再來訪問a.com看看會不會分配到主服務器上。

 

 

主服務器也能正常加入服務了。

最後
1、負載均衡不是nginx獨有，著名鼎鼎的apache也有，但性能可能不如nginx。

2、多臺服務器提供服務，但域名只解析到主服務器，而真正的服務器IP不會被ping下便可得到，增長必定安全性。

 

3、upstream裏的IP不必定是內網，外網IP也能夠。不過經典的案例是，局域網中某臺IP暴露在外網下，域名直接解析到此IP。而後又這臺主服務器轉發到內網服務器IP中。

4、某臺服務器宕機、不會影響網站正常運行，Nginx不會把請求轉發到已宕機的IP上

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程