Nginx安装与使用 及在redhat 中的简单安装方式

时间:2023-12-12 11:35:44

首先说下在redhat中的安装方法,

正常安装nginx 需要安装很多的依赖,最后再安装nginx,而且很容易出错。

在nginx官方上有这么一段描述:

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:

[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.

直译为下:

在 /etc/yum.repos.d/ 目录下新建 nginx.repo 文件 内容如下:

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

然后 执行  yum install nginx 命令

nginx 就安装好了

安装在 /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

  8. 获取openssl编译安装包,在http://www.openssl.org/source/上可以获取当前最新的版本。
  9. 解压缩openssl-xx.tar.gz包。
  10. 进入解压缩目录,执行./config。
  11. make & make install
  12. 1.3.安装zlib

  13. 获取zlib编译安装包,在http://www.zlib.net/上可以获取当前最新的版本。
  14. 解压缩openssl-xx.tar.gz包。
  15. 进入解压缩目录,执行./configure。
  16. make & make install
  17. 1.4.安装nginx

  18. 获取nginx,在http://nginx.org/en/download.html上可以获取当前最新的版本。
  19. 解压缩nginx-xx.tar.gz包。
  20. 进入解压缩目录,执行./configure
  21. 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的错误

可能的原因:1、nginx 安装目录下  html 的权限不够 添加  读取 写入 执行  相关权限

      2、网站根目录不包含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中,那么可能会有以下两种情况发生:

1、主服务器转发到了其它IP上,其它IP服务器正常处理;

2、主服务器转发到了自己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看看会不会分配到主服务器上。

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

最后
一、负载均衡不是nginx独有,著名鼎鼎的apache也有,但性能可能不如nginx。

二、多台服务器提供服务,但域名只解析到主服务器,而真正的服务器IP不会被ping下即可获得,增加一定安全性。

三、upstream里的IP不一定是内网,外网IP也可以。不过经典的案例是,局域网中某台IP暴露在外网下,域名直接解析到此IP。然后又这台主服务器转发到内网服务器IP中。

四、某台服务器宕机、不会影响网站正常运行,Nginx不会把请求转发到已宕机的IP上