Nginx 配置虚拟主机

阅读本文需要安装Nginx:https://www.cnblogs.com/huangyi-427/p/9229645.html

一、什么是配置虚拟主机

就是在一台服务器启动多个网站

二、通过端口区分虚拟主机

复制一份静态页面

cd /usr/local/nginx

cp -r html html81

修改部分内容以示区分

vim /usr/local/nginx/html81/index.html

未分类

查看配置文件

more /usr/local/nginx/conf/nginx.conf
#user  nobody;
worker_processes  1;

#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

#pid        logs/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       mime.types;
    default_type  application/octet-stream;

    #log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
    #                  '$status $body_bytes_sent "$http_referer" '
    #                  '"$http_user_agent" "$http_x_forwarded_for"';

    #access_log  logs/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;

    #gzip  on;

    server {
        listen       80;
        server_name  localhost;

        #charset koi8-r;

        #access_log  logs/host.access.log  main;

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

        #error_page  404              /404.html;

        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }

        # proxy the PHP scripts to Apache listening on 127.0.0.1:80
        #
        #location ~ .php$ {
        #    proxy_pass   http://127.0.0.1;
        #}

        # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
        #
        #location ~ .php$ {
        #    root           html;
        #    fastcgi_pass   127.0.0.1:9000;
        #    fastcgi_index  index.php;
        #    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
        #    include        fastcgi_params;
        #}

        # deny access to .htaccess files, if Apache's document root
        # concurs with nginx's one
        #
        #location ~ /.ht {
        #    deny  all;
        #}
    }


    # another virtual host using mix of IP-, name-, and port-based configuration
    #
    #server {
    #    listen       8000;
    #    listen       somename:8080;
    #    server_name  somename  alias  another.alias;

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


    # HTTPS server
    #
    #server {
    #    listen       443 ssl;
    #    server_name  localhost;

    #    ssl_certificate      cert.pem;
    #    ssl_certificate_key  cert.key;

    #    ssl_session_cache    shared:SSL:1m;
    #    ssl_session_timeout  5m;

    #    ssl_ciphers  HIGH:!aNULL:!MD5;
    #    ssl_prefer_server_ciphers  on;

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

}

未分类

可以通过配置多个server来配置多个虚拟主机

添加虚拟主机 将下面配置拷贝进去(与原有的server节点同级)

vim /usr/local/nginx/conf/nginx.conf
    server {
        listen       81;
        server_name  localhost;

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

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }

进入sbin目录

cd /usr/local/nginx/sbin

开机状态刷新配置文件

./nginx -s reload

未分类

未分类

三、通过域名区分虚拟主机

域名: 域名就是网站

DNS服务器: 把域名解析为IP地址 保存的就是域名和IP的映射关系

注意: 一个域名对应一个IP地址 一个IP地址可以被多个域名绑定

这里我准备了2个域名

www.hb218.cn  www.hdcpa.cn

在阿里云上购买的 只有3-5天的使用期(可以续费) 总共花了2个大洋

买好域名之后需要在阿里云控制台 -> 云解析DNS -> 配置2个域名指向同一台nginx服务器(IP)

这里赞一下 马爸爸的阿里云平台啥都有 挺方便的

复制一份显示www.hb218.cn的静态页面

cd /usr/local/nginx

cp -r html html-hb218

修改部分内容以示区分

vim /usr/local/nginx/html-hb218/index.html

未分类

复制一份显示www.hdcpa.cn的静态页面

cd /usr/local/nginx

cp -r html html-hdcpa

修改部分内容以示区分

vim /usr/local/nginx/html-hdcpa/index.html

未分类

查看配置文件

more /usr/local/nginx/conf/nginx.conf
#user  nobody;
worker_processes  1;

#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

#pid        logs/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       mime.types;
    default_type  application/octet-stream;

    #log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
    #                  '$status $body_bytes_sent "$http_referer" '
    #                  '"$http_user_agent" "$http_x_forwarded_for"';

    #access_log  logs/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;

    #gzip  on;

    server {
        listen       80;
        server_name  localhost;

        #charset koi8-r;

        #access_log  logs/host.access.log  main;

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

        #error_page  404              /404.html;

        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }

        # proxy the PHP scripts to Apache listening on 127.0.0.1:80
        #
        #location ~ .php$ {
        #    proxy_pass   http://127.0.0.1;
        #}

        # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
        #
        #location ~ .php$ {
        #    root           html;
        #    fastcgi_pass   127.0.0.1:9000;
        #    fastcgi_index  index.php;
        #    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
        #    include        fastcgi_params;
        #}

        # deny access to .htaccess files, if Apache's document root
        # concurs with nginx's one
        #
        #location ~ /.ht {
        #    deny  all;
        #}
    }


    # another virtual host using mix of IP-, name-, and port-based configuration
    #
    #server {
    #    listen       8000;
    #    listen       somename:8080;
    #    server_name  somename  alias  another.alias;

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


    # HTTPS server
    #
    #server {
    #    listen       443 ssl;
    #    server_name  localhost;

    #    ssl_certificate      cert.pem;
    #    ssl_certificate_key  cert.key;

    #    ssl_session_cache    shared:SSL:1m;
    #    ssl_session_timeout  5m;

    #    ssl_ciphers  HIGH:!aNULL:!MD5;
    #    ssl_prefer_server_ciphers  on;

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

}

未分类

可以通过配置多个server来配置多个虚拟主机

添加虚拟主机 将下面配置拷贝进去(与原有的server节点同级)

vim /usr/local/nginx/conf/nginx.conf
    server {
        listen       80;
        server_name  www.hb218.cn;

        location / {
            root   html-hb218;
            index  index.html index.htm;
        }

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }

    server {
        listen       80;
        server_name  www.hdcpa.cn;

        location / {
            root   html-hdcpa;
            index  index.html index.htm;
        }

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }

进入sbin目录

cd /usr/local/nginx/sbin

开机状态刷新配置文件

./nginx -s reload

大功告成 浏览器分别访问www.hb218.cn  www.hdcpa.cn

详解:配置启用NGINX状态页面

Nginx是一款免费的开源,高性能,可靠,可扩展且可完全扩展的Web服务器,负载均衡器和反向代理软件。 它有一个简单和易于理解的配置语言。 它还支持多种静态模块(自第一个版本开始就存在于Nginx中)和动态模块 (在1.9.11版本中引入 )。

Nginx中的一个重要模块是ngx_http_stub_status_module模块,它通过“ 状态页面 ”提供对基本Nginx状态信息的访问。 它显示活动客户端连接总数,接受和处理的总数,请求总数以及读取,写入和等待连接数等信息。

在大多数Linux发行版上, Nginx版本随ngx_http_stub_status_module启用。 您可以使用以下命令检查模块是否已启用。

# nginx -V 2>&1 | grep -o with-http_stub_status_module

检查Nginx状态模块

如果在终端中看到–with-http_stub_status_module作为输出,则表示状态模块已启用。 如果上述命令没有返回任何输出,则需要使用-with-http_stub_status_module作为配置参数从源代码编译NGINX ,如图所示。

# wget http://nginx.org/download/nginx-1.13.12.tar.gz
# tar xfz nginx-1.13.12.tar.gz
# cd nginx-1.13.12/
# ./configure --with-http_stub_status_module
# make
# make install

在验证模块之后,您还需要在NGINX配置文件/etc/nginx/nginx.conf中启用stub_status模块,以便为该模块设置一个本地可访问的URL(例如http://www.example.com/nginx_status )状态页面。

location /nginx_status {
stub_status;
allow 127.0.0.1;    #only allow requests from localhost
deny all;       #deny all other hosts   
}

启用Nginx状态页面

确保将127.0.0.1替换为服务器的IP地址,并确保只有您可访问此页面。

更改配置后,请确保检查nginx配置是否有任何错误,并使用以下命令重新启动nginx服务以实现最近的更改。

# nginx -t
# nginx -s reload 

检查Nginx配置

重新加载nginx服务器后,现在您可以使用curl程序访问下面的URL中的Nginx状态页面来查看您的指标。

# curl http://127.0.0.1/nginx_status
OR
# curl http://www.example.com/nginx_status

检查Nginx状态页面

重要说明 : ngx_http_stub_status_module模块已被Nginx 1.13.0版本中的ngx_http_api_module模块取代。

nginx配置location总结及rewrite规则写法

1. location正则写法

一个示例:

location  = / {
  # 精确匹配 / ,主机名后面不能带任何字符串
  [ configuration A ]
}

location  / {
  # 因为所有的地址都以 / 开头,所以这条规则将匹配到所有请求
  # 但是正则和最长字符串会优先匹配
  [ configuration B ]
}

location /documents/ {
  # 匹配任何以 /documents/ 开头的地址,匹配符合以后,还要继续往下搜索
  # 只有后面的正则表达式没有匹配到时,这一条才会采用这一条
  [ configuration C ]
}

location ~ /documents/Abc {
  # 匹配任何以 /documents/Abc 开头的地址,匹配符合以后,还要继续往下搜索
  # 只有后面的正则表达式没有匹配到时,这一条才会采用这一条
  [ configuration CC ]
}

location ^~ /images/ {
  # 匹配任何以 /images/ 开头的地址,匹配符合以后,停止往下搜索正则,采用这一条。
  [ configuration D ]
}

location ~* .(gif|jpg|jpeg)$ {
  # 匹配所有以 gif,jpg或jpeg 结尾的请求
  # 然而,所有请求 /images/ 下的图片会被 config D 处理,因为 ^~ 到达不了这一条正则
  [ configuration E ]
}

location /images/ {
  # 字符匹配到 /images/,继续往下,会发现 ^~ 存在
  [ configuration F ]
}

location /images/abc {
  # 最长字符匹配到 /images/abc,继续往下,会发现 ^~ 存在
  # F与G的放置顺序是没有关系的
  [ configuration G ]
}

location ~ /images/abc/ {
  # 只有去掉 config D 才有效:先最长匹配 config G 开头的地址,继续往下搜索,匹配到这一条正则,采用
    [ configuration H ]
}

location ~* /js/.*/.js
  • 已=开头表示精确匹配
    如 A 中只匹配根目录结尾的请求,后面不能带任何字符串。
  • ^~ 开头表示uri以某个常规字符串开头,不是正则匹配
  • ~ 开头表示区分大小写的正则匹配;
  • ~* 开头表示不区分大小写的正则匹配
  • / 通用匹配, 如果没有其它匹配,任何请求都会匹配到

顺序 no优先级:

(location =) > (location 完整路径) > (location ^~ 路径) > (location ~,~* 正则顺序) > (location 部分起始路径) > (/)

上面的匹配结果
按照上面的location写法,以下的匹配示例成立:

  • / -> config A
    精确完全匹配,即使/index.html也匹配不了

  • /downloads/download.html -> config B
    匹配B以后,往下没有任何匹配,采用B

  • /images/1.gif -> configuration D
    匹配到F,往下匹配到D,停止往下

  • /images/abc/def -> config D
    最长匹配到G,往下匹配D,停止往下
    你可以看到 任何以/images/开头的都会匹配到D并停止,FG写在这里是没有任何意义的,H是永远轮不到的,这里只是为了说明匹配顺序

  • /documents/document.html -> config C
    匹配到C,往下没有任何匹配,采用C

  • /documents/1.jpg -> configuration E
    匹配到C,往下正则匹配到E

  • /documents/Abc.jpg -> config CC
    最长匹配到C,往下正则顺序匹配到CC,不会往下到E

实际使用建议

所以实际使用中,个人觉得至少有三个匹配规则定义,如下:

#直接匹配网站根,通过域名访问网站首页比较频繁,使用这个会加速处理,官网如是说。
#这里是直接转发给后端应用服务器了,也可以是一个静态首页
# 第一个必选规则
location = / {
    proxy_pass http://tomcat:8080/index
}
# 第二个必选规则是处理静态文件请求,这是nginx作为http服务器的强项
# 有两种配置模式,目录匹配或后缀匹配,任选其一或搭配使用
location ^~ /static/ {
    root /webroot/static/;
}
location ~* .(gif|jpg|jpeg|png|css|js|ico)$ {
    root /webroot/res/;
}
#第三个规则就是通用规则,用来转发动态请求到后端应用服务器
#非静态文件请求就默认是动态请求,自己根据实际把握
#毕竟目前的一些框架的流行,带.php,.jsp后缀的情况很少了
location / {
    proxy_pass http://tomcat:8080/
}

http://tengine.taobao.org/boo…
http://nginx.org/en/docs/http…

2. Rewrite规则

rewrite功能就是,使用nginx提供的全局变量或自己设置的变量,结合正则表达式和标志位实现url重写以及重定向。rewrite只能放在server{},location{},if{}中,并且只能对域名后边的除去传递的参数外的字符串起作用,例如 http://seanlook.com/a/we/index.php?id=1&u=str 只对/a/we/index.php重写。语法rewrite regex replacement [flag];

如果相对域名或参数字符串起作用,可以使用全局变量匹配,也可以使用proxy_pass反向代理。

表明看rewrite和location功能有点像,都能实现跳转,主要区别在于rewrite是在同一域名内更改获取资源的路径,而location是对一类路径做控制访问或反向代理,可以proxy_pass到其他机器。很多情况下rewrite也会写在location里,它们的执行顺序是:

  1. 执行server块的rewrite指令
  2. 执行location匹配
  3. 执行选定的location中的rewrite指令

如果其中某步URI被重写,则重新循环执行1-3,直到找到真实存在的文件;循环超过10次,则返回500 Internal Server Error错误。

2.1 flag标志位

  • last : 相当于Apache的[L]标记,表示完成rewrite
  • break : 停止执行当前虚拟主机的后续rewrite指令集
  • redirect : 返回302临时重定向,地址栏会显示跳转后的地址
  • permanent : 返回301永久重定向,地址栏会显示跳转后的地址

因为301和302不能简单的只返回状态码,还必须有重定向的URL,这就是return指令无法返回301,302的原因了。这里 last 和 break 区别有点难以理解:

  1. last一般写在server和if中,而break一般使用在location中
  2. last不终止重写后的url匹配,即新的url会再从server走一遍匹配流程,而break终止重写后的匹配
  3. break和last都能组织继续执行后面的rewrite指令

2.2 if指令与全局变量

if判断指令
语法为if(condition){…},对给定的条件condition进行判断。如果为真,大括号内的rewrite指令将被执行,if条件(conditon)可以是如下任何内容:

  • 当表达式只是一个变量时,如果值为空或任何以0开头的字符串都会当做false
  • 直接比较变量和内容时,使用=或!=
  • ~正则表达式匹配,~*不区分大小写的匹配,!~区分大小写的不匹配

-f!-f用来判断是否存在文件
-d!-d用来判断是否存在目录
-e!-e用来判断是否存在文件或目录
-x!-x用来判断文件是否可执行

例如:

if ($http_user_agent ~ MSIE) {
    rewrite ^(.*)$ /msie/$1 break;
} //如果UA包含"MSIE",rewrite请求到/msid/目录下

if ($http_cookie ~* "id=([^;]+)(?:;|$)") {
    set $id $1;
 } //如果cookie匹配正则,设置变量$id等于正则引用部分

if ($request_method = POST) {
    return 405;
} //如果提交方法为POST,则返回状态405(Method not allowed)。return不能返回301,302

if ($slow) {
    limit_rate 10k;
} //限速,$slow可以通过 set 指令设置

if (!-f $request_filename){
    break;
    proxy_pass  http://127.0.0.1;
} //如果请求的文件名不存在,则反向代理到localhost 。这里的break也是停止rewrite检查

if ($args ~ post=140){
    rewrite ^ http://example.com/ permanent;
} //如果query string中包含"post=140",永久重定向到example.com

location ~* .(gif|jpg|png|swf|flv)$ {
    valid_referers none blocked www.jefflei.com www.leizhenfang.com;
    if ($invalid_referer) {
        return 404;
    } //防盗链
}

全局变量

下面是可以用作if判断的全局变量

  • $args : #这个变量等于请求行中的参数,同$query_string
  • $content_length : 请求头中的Content-length字段。
  • $content_type : 请求头中的Content-Type字段。
  • $document_root : 当前请求在root指令中指定的值。
  • $host : 请求主机头字段,否则为服务器名称。
  • $http_user_agent : 客户端agent信息
  • $http_cookie : 客户端cookie信息
  • $limit_rate : 这个变量可以限制连接速率。
  • $request_method : 客户端请求的动作,通常为GET或POST。
  • $remote_addr : 客户端的IP地址。
  • $remote_port : 客户端的端口。
  • $remote_user : 已经经过Auth Basic Module验证的用户名。
  • $request_filename : 当前请求的文件路径,由root或alias指令与URI请求生成。
  • $scheme : HTTP方法(如http,https)。
  • $server_protocol : 请求使用的协议,通常是HTTP/1.0或HTTP/1.1。
  • $server_addr : 服务器地址,在完成一次系统调用后可以确定这个值。
  • $server_name : 服务器名称。
  • $server_port : 请求到达服务器的端口号。
  • $request_uri : 包含请求参数的原始URI,不包含主机名,如:”/foo/bar.php?arg=baz”。
  • $uri : 不带请求参数的当前URI,$uri不包含主机名,如”/foo/bar.html”。
  • $document_uri : 与$uri相同。

例:http://localhost:88/test1/test2/test.php

$host:localhost
$server_port:88
$request_uri:http://localhost:88/test1/tes...
$document_uri:/test1/test2/test.php
$document_root:/var/www/html
$request_filename:/var/www/html/test1/test2/test.php

2.3 常用正则

  • . : 匹配除换行符以外的任意字符
  • ? : 重复0次或1次
  • + : 重复1次或更多次
  • * : 重复0次或更多次
  • d :匹配数字
  • ^ : 匹配字符串的开始
  • $ : 匹配字符串的介绍
  • {n} : 重复n次
  • {n,} : 重复n次或更多次
  • [c] : 匹配单个字符c
  • [a-z] : 匹配a-z小写字母的任意一个

小括号()之间匹配的内容,可以在后面通过$1来引用,$2表示的是前面第二个()里的内容。正则里面容易让人困惑的是转义特殊字符。

2.4 rewrite实例

例1:

http {
    # 定义image日志格式
    log_format imagelog '[$time_local] ' $image_file ' ' $image_type ' ' $body_bytes_sent ' ' $status;
    # 开启重写日志
    rewrite_log on;

    server {
        root /home/www;

        location / {
                # 重写规则信息
                error_log logs/rewrite.log notice;
                # 注意这里要用‘’单引号引起来,避免{}
                rewrite '^/images/([a-z]{2})/([a-z0-9]{5})/(.*).(png|jpg|gif)$' /data?file=$3.$4;
                # 注意不能在上面这条规则后面加上“last”参数,否则下面的set指令不会执行
                set $image_file $3;
                set $image_type $4;
        }

        location /data {
                # 指定针对图片的日志格式,来分析图片类型和大小
                access_log logs/images.log mian;
                root /data/images;
                # 应用前面定义的变量。判断首先文件在不在,不在再判断目录在不在,如果还不在就跳转到最后一个url里
                try_files /$arg_file /image404.html;
        }
        location = /image404.html {
                # 图片不存在返回特定的信息
                return 404 "image not foundn";
        }
}

对形如/images/ef/uh7b3/test.png的请求,重写到/data?file=test.png,于是匹配到location /data,先看/data/images/test.png文件存不存在,如果存在则正常响应,如果不存在则重写tryfiles到新的image404 location,直接返回404状态码。

例2:

rewrite ^/images/(.*)_(d+)x(d+).(png|jpg|gif)$ /resizer/$1.$4?width=$2&height=$3? last;

对形如/images/bla_500x400.jpg的文件请求,重写到/resizer/bla.jpg?width=500&height=400地址,并会继续尝试匹配location。

例3:

见 ssl部分页面加密http://seanlook.com/2015/05/28/nginx-ssl/

如何为多个PHP-FPM容器构建单一的Nginx Docker镜像

在使用 Docker 容器来开发 PHP 微服务套件的过程中,作者遇到了容器数量过多的问题。

最近,我一直在使用 Docker 容器来开发 PHP 微服务套件。一个问题是 PHP 应用已经搭建,可以与 PHP-FPM 还有 Nginx(取代了简单的 Apche/PHP 环境)一起工作,因此每个 PHP 微服务需要两个容器(以及两个 Docker 镜像):一个 PHP-FPM 容器和一个 Nginx 容器。
这个应用运行了 6 个以上的服务,做个乘法就知道,在开发和生产之间会有约 30 个容器。于是我决定构建一个单独的 Nginx Docker 镜像,它可以使用 PHP-FPM 的主机名作为环境变量并运行单独的配置文件,而不用为每个容器构建单独的 Nginx 镜像。

未分类

在本文中,我介绍了自己从上图中的方法 1 到方法 2 的转换,最后采用的方案中采用了一种新的定制 Docker 镜像。该镜像的代码是开源的,如果读者碰到类似问题,可以提供给大家参考。

为什么用 Nginx?

Nginx 和 PHP-FPM 配合使用能使 PHP 应用的性能更好,但不好的地方在于,和 PHP Apache 镜像不同,PHP-FPM Docker 镜像默认不是和和 Nginx 绑定在一起的。如果需要通过 Nginx 容器和 PHP-FPM 连接,需要在 Nginx 配置里为该后端增加 DNS 记录。比如,如果名为 php-fpm-api 的 PHP-FPM 容器正在运行,Nginx 配置文件应该包含下面部分:

location ~ .php$ {
        fastcgi_split_path_info ^(.+.php)(/.+)$;
        # This line passes requests through to the PHP-FPM container
        fastcgi_pass php-fpm-api:9000;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }

如果只服务于单独的 Nginx 容器,Nginx 配置中容器名字写死还可以接受,但如上所述,需要允许多个 Nginx 容器,每个对应于一个 PHP 服务。创建一个新的 Nginx 镜像(以后需要进行维护和升级)会有些痛苦,即使管理一批不同的数据卷,仅仅改变变量名看起来也有很多工作。

第一种方案: 使用 Docker 文档中的方法

最初,我认为这会很简单。Docker 文档中有少许的几个章节讨论如何使用 envsubst 来完成该工作,但不幸的是,在我的 Nginx 配置文件中,这种方法不奏效。

vhosts.conf

server {
    listen 80;
    index index.php index.html;
    root /var/www/public;
    client_max_body_size 32M;
    location / {
        try_files $uri /index.php?$args;
    }
    location ~ .php$ {
        fastcgi_split_path_info ^(.+.php)(/.+)$;
        fastcgi_pass ${NGINX_HOST}:9000;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }
}

该vhosts.conf文件使用了 Nginx 内置变量,因此当依照文档运行 Docker 命令 (/bin/bash -c “envsubst < /etc/nginx/conf.d/mysite.template > /etc/nginx/conf.d/default.conf && nginx -g ‘daemon off;’”) 时,得到错误提示$uri和$fastcgi_script_name没有定义。这些变量通常通过 Nginx 传入,因此不能简单的识别出他们是什么并传给自身,而且这样会影响容器的动态配置。

使用另一个 Docker 镜像,差点成功

接下来,我开始研究不同的 Nginx 镜像。找到的有两个,但它们都在随后的几年中都没有任何更新。我开始使用 martin/nginx,试图找到可以工作的原型。

Martin 的镜像和其它镜像有点不一样,因为它要求特定的文件夹结构。在 root 下增加Dockerfile:

FROM martin/nginx

接下来,我添加了一个app/空目录和conf/目录,conf/目录下只有一个文件
vhosts.conf:

server {
    listen 80;
    index index.php index.html;
    root /var/www/public;
    client_max_body_size 32M;
    location / {
        try_files $uri /index.php?$args;
    }
    location ~ .php$ {
        fastcgi_split_path_info ^(.+.php)(/.+)$;
        fastcgi_pass $ENV{"NGINX_HOST"}:9000;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }
}

这个文件和之前的配置文件几乎一样,除了有一行的改动:
fastcgi_pass $ENV{“NGINX_HOST”}:9000;。现在想要启动带命名为 php-fpm-api 的 PHP 容器的 Nginx 容器,就可以构建一个新的镜像,让它在以下环境变量下运行:

docker build -t shiphp/nginx-env:test .
docker run -it --rm -e NGINX_HOST=php-fpm-api shiphp/nginx-env:test

它可以正常工作了。但是,这种方法有两个困扰的地方:
正在使用的基础镜像已经有两年了。这会引入安全和性能风险。
有个空的/app目录看起来并不必需,因为文件会被存储在一个不同的目录中。

最终解决方案

我认为作为定制解决方案,从 Martin 镜像开始比较好,因此我给项目建了分叉,创建了新的 Nginx 基础镜像并修复了上述两个问题。现在,如果要在 Nginx 容器中允许动态命名的后端,可以参照:

# 从 Docker Hub 得到最新版本
docker pull shiphp/nginx-env:latest
# 运行名为"php-fpm-api"的 PHP 容器 
docker run --name php-fpm-api -v $(pwd):/var/www php:fpm
# 允许链接到 PHP-FPM 容器的 NGinx 容器
docker run --link php-fpm-api -e NGINX_HOST=php-fpm-api shiphp/nginx-env

如果想增加自己的文件或 Nginx 配置文件,来定制镜像,用Dockerfile来扩展它就可以:

FROM shiphp/nginx-env
ONBUILD ADD <PATH_TO_YOUR_CONFIGS> /etc/nginx/conf.d/
...

现在所有的 PHP-FPM 容器都能使用单个Docker镜像中自己的实例,这样在升级 Nginx,改变权限或做某些调整时,就变得非常轻松了。

所有的代码都在 Github 上,如果你看到任何问题或有改进建议,可以直接创建 issue。

GitHub 项目链接:https://github.com/shiphp/nginx-env

nginx 和 frp共用80端口

之前用frp做内网穿透,把内网的服务器开放到外网。

如果是http服务的话,80端口的做法是使用二级域名xxx做个A记录指一台没有nginx 之类的服务器IP,然后用浏览器打开xxx.example.com就打开了。其他端口是在frpc.ini里指定的,就加个端口号如xxx.example.com:1234就打开了,这种情况用于外网服务器已经有nginx在运行占用了80端口, 这时如果不想用端口号来打开,就要做三级域名解析,同时nginx做反向代理,把这个1234端口代理到80.

其实只要给 nginx 增加一个简单的配置,就可以将某个域名的流量转发给 frp 了,还可以通过泛解析来映射不同的网站。

配置 nginx:

server {
    listen 80;
    server_name *.frp.example.com;
    location / {
        proxy_pass http://127.0.0.1:8081;
        proxy_set_header    Host            $host:80;
        proxy_set_header    X-Real-IP       $remote_addr;
        proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_hide_header   X-Powered-By;
    }
}

上面这段写入/etc/nginx/sites-avaliable/default的最后面,监听*.frp.example.com, 并转发给127.0.0.8081, 接下来只要将frp默认监听 80 端口改成 8081 端口就好了.

配置 frp 服务端:

[common]
bind_port = 8787
vhost_http_port = 8081
token = passwd
max_pool_count = 100
subdomain_host = frp.example.com

[xxx]
type = http
subdomain = xxx

重点在于将 vhost_http_port 设为 8081, 还可以在common下加上dashboard相关的端口,用户,密码等信息。

配置 frp 客户端:

[common]
server_addr = exampel.com 
server_port = 8787 
token = passwd
login_fail_exit = false 

[xxx]
type = http
local_port = 80
subdomain = xxx

域名设置:

1, 增加二级域名frp的A解析,到外网服务器IP.

  1. 增加三级域名泛解析*.frp的CNAME解析,到frp.example.com.

这时要做完这2个域名解析就可以用xxx.frp.example.com访问了。

参考:http://www.miss.cat/frp-use-80-port-with-nginx/

https://blog.csdn.net/qq_36560161/article/details/79646523

如果是ssh,frpc如下面配置的话,还是一样的,跟http上面讲的东西没有关系:

[common]
server_addr = example.com 
server_port = 8787 
token = passwd
login_fail_exit = false 

[ssh-xxx]
type = tcp
local_ip = 127.0.0.1
local_port = 22
remote_port = 5000

还是这样登录:

ssh [email protected] -p5000

他们将生产环境从 nginx 迁移到 envoy

导读:随着Service Mesh在最近一年进入人们的视野,Envoy 作为其中很关键的组件,也开始被广大技术人员熟悉。本文作者所在公司已经从 nginx 迁移到 Envoy。

随着我们下一代产品发布,我们将代理软件从 nginx 切换到 Envoy 。

我们很早就开始关注 Envoy。 公司的一些人之前在 Twitter 工作,其中一些人和 Matt Klein 一起组建了 Twitter 的边缘代理 TFE。 我们知道 Lyft 正在计划建立一个基于 TFE 的开源代理模型,我们对此很感兴趣。 不幸的是,我们刚开始做自己产品的时候它还没有准备好,所以起初我们还是使用 nginx。

我们很高兴看到 Envoy 的最初功能集合中包含了大量灵活运用微服务的想法。 我们更加兴奋地看到它的社区已经成型并且技术已经成熟。 现在 Envoy 提供的功能(相比于 nginx)可以使我们能够更快地为客户提供新功能。当然,Envoy 的功能路线图也非常令人兴奋。

选择代理

在启动Turbine Labs时,我们就知道负载均衡将成为我们基础架构的关键组成部分。

在2015年秋季的时候,代理软件并不是我们今天看到的样子。

我们选择 nginx 是因为它轻巧,经过大量生产环境测试,开源,相对来说易于扩展,并且拥有蓬勃发展的用户群体。然而我们必须做很多额外的工作才能在 nginx 之上构建一个全功能的流量管理解决方案。

服务发现,统计管理和更细粒度的负载均衡是现代基础架构的关键特性。 我们在 nginx 之上来实现这些功能,虽然已经花了很长时间,但仍有很多工作要做。

相比之下,Envoy 有很多非常有用功能(如 gRPC,tracing 等等),同时提供类似(或更好)的性能,稳定性和社区。

克服反对意见

采用任何新技术都需要考虑相反的意见。 由于我们已经部署了代理服务,不仅需要考虑到自己的问题,还需要考虑到客户提出的问题。 对于开源项目,这些问题通常分为以下几类:

我们一直密切关注 Envoy 的开发进展,并对它的成熟速度感到惊讶。已经有不少公司在生产环境使用 Envoy。Envoy 现在是一个 CNCF 项目,这意味着社区是透明和开放的。 代码贡献者来自很多公司,我们也在其中。

成本也是需要考虑的因素。随着 sidecars 成为更普遍的部署方式,代理会得到更广泛的应用。 虽然许多客户将继续集中式运行负载均衡,但我们希望代理软件可以优雅地支持边车部署模型。

Envoy 采用 C++ 11 编写,运行时占用的内存很少,与依赖较重运行时的代理相比,显着减少了 sidecars 部署的负担。

服务提供方的好处

应始终谨慎对待技术堆栈的大型更改。我们没有轻易转向 Envoy,但我们获得的好处以及我们可以传递给我们客户的好处非常显著。

可管理性

从一开始,Envoy 就被设计为可以大规模管理。 我们已经做了很多工作来使我们的基于 nginx 的代理可管理,但是这个配置接口不太容易地暴露给其他工具。

Envoy 数据平面 API 为其集中管理提供了一个开放标准。 我们可以提供一个集中的,开放的控制点,而不是复制配置文件。

可扩展性

nginx 是一个非常成功,稳定的开源项目。 其配置文件和模块生态系统具有较大的外围应用,并有大量现有用户支持。 给 nginx 贡献核心代码是非常有挑战性的,这导致在许多情况下需要编写自定义模块或 Lua 脚本以扩展其功能。

Envoy 更为聚焦,使用更为现代的语言支持改变代理行为。过去几个月中,我们向 Envoy 提交了超过 30 个功能,其中包括 OSX 构建 ,子集负载均衡和 upstream 日志记录等主要功能。

服务使用方的好处

更丰富的群集模型

我们在 nginx 上做了一些扩展,从而增强其 upstream 模型并添加更多细节。在同时部署同一服务的多个版本时,仅仅了解实例的主机和端口是不够的。

Envoy(通过我们贡献的补丁)允许将任意元数据附加到服务实例,以及定义基于该元数据定义路由规则。这使先进的流量管理技术成为可能,例如增量发布, 蓝/绿版本,无缝整体分解和生产测试 。

多协议支持

NGINX支持很多协议。 Envoy 的架构可以轻松地添加对新协议的支持,并且它也提供了多种协议支持。 虽然 HTTP 占据了互联网流量的很大一部分,但增加对 Redis,Mongo,Dynamo,websockets 和 gRPC 流量的可见性也是非常重要的。

动态服务发现

随着微服务,容器变得越来越流行,服务拓扑变得更加动态。配置文件中的服务器列表很快就会过时。 Envoy 使用一种最终一致的模型来进行 API 驱动的服务发现,并且能够很好地处理变化频繁的实例。

我们目前从各种平台收集数据,而 Envoy 的群集发现服务(CDS)为我们提供了比固定配置文件更自然的抽象。 Envoy 通过支持监听器发现服务(LDS)和路由发现服务(RDS)支持路由拓扑发现,从而进一步加强了这一点。 最终允许从中央控制点动态重新配置大部分服务拓扑,这非常有用。

网络策略

微服务意味着网络更加依赖于服务抽象边界。 随着相互依赖的服务数量日渐增长,系统100%没问题的时间会变少,整个系统经常有部分功能处于降级状态。

管理网络策略(如重试,超时和速率限制)对于在面对系统健康问题时保持顺畅的客户体验至关重要。Envoy 允许在代理(每个路由) 和客户端(每个请求的基础上)配置这些策略。 这可以灵活地实现(难以用 nginx 实现的)极细粒度弹性策略。

监测

Envoy 使用行业标准的请求日志,还提供与各种监测系统的集成。 它还提供对 Zipkin 和 Lightstep 的原生支持,以便追踪整个请求链。

如何更快迁移

我们对迁移到 Envoy 的过程非常满意。 它稳定,快速,轻便,并拥有一个伟大的社区。 它的架构使其非常适合微服务,但它同样适合做边缘代理。 作为基础服务,使用配置API而非静态配置文件真是太棒了。

如果你已经开始使用 Envoy,或者正在考虑迁移到 Envoy,那就可以考虑使用我们的服务。凭借广泛的服务发现和卓越的管理界面,我们可以帮助您快速,平稳地部署和运营 Envoy。

英文原文:

https://blog.turbinelabs.io/our-move-to-envoy-bfeb08aa822d

更多 Envoy 介绍:

https://www.envoyproxy.io/

Nginx利用fastcgi_cache缓存php页面

前言

fastcgi_cache是一个nginx的插件,用于缓存fastcgi接口的执行结果,例如缓存php的执行结果。特别是php网站的首页与一些非交互页面,利用fastcgi_cache可以大幅度提升访问速度,并且降低php的执行压力。

配置

1. 在nginx的主配置文件

在主配置文件(nginx.conf)中添加缓存域

fastcgi_cache_path /dev/shm/nginx-cache levels=1:2 keys_zone=cgi_wpcache:200m inactive=1d;

fastcgi_cache_path:缓存文件的路径,/dev/shm/为tmfs缓存文件系统,

实际储存在内存中,所以读写IO性能更高。
levels:缓存目录的结构层次,例如1:2,缓存文件会就生成在指定目录的再下两层目录中。
keys_zone:缓存域名称,在vhost内进行缓存时需要调用。
inactive:缓存不活动时间,若缓存内容在指定时间内未被访问将会被清理出缓存域。

2. 站点配置

location /archives/ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME /data/webroot/$fastcgi_script_name;
include fastcgi_params;
  fastcgi_cache cgi_wpcache;
  fastcgi_cache_methods GET HEAD;
  fastcgi_cache_key $request_method$host$request_uri;
  fastcgi_cache_valid 200 2d;
  fastcgi_ignore_headers Cache-Control Expires Set-Cookie;
  add_header X-Cache “$upstream_cache_status”;
}

fastcgi_cache:指定缓存域
fastcgi_cache_methods:指定缓存的请求方式
fastcgi_cache_key:指定缓存文件的标识,这个标识会MD5转码存储在缓存域的目录下
fastcgi_cache_valid:指定缓存状态,例如上文中只缓存响应状态码为200的请求所产生的返回页面两天
fastcgi_ignore_headers:默认情况下fastcgi_cache会忽略有特殊header的请求,并不进行缓存,官网说明。但当我们添加这个参数后,这些限制将不在存在。
add_header 将会在返回请求的response的header中添加一个X-Cache字段表示是否进行了缓存。如果需要也可以在nginx日志中通过log_format添加$upstream_cache_status字段

  • ·MISS 未命中,请求被传送到后端
  • ·HIT 缓存命中
  • ·EXPIRED 缓存已经过期请求被传送到后端
  • ·UPDATING 正在更新缓存,将使用旧的应答
  • ·STALE 后端将得到过期的应答

3.验证

配置完成后重新加载nginx后通过curl -I 访问如下:

[root@localhost local]# curl -I localhost/archives/1.php
HTTP/1.1 200 OK
Server: nginx/1.14.0
Date: Mon, 25 Jun 2018 06:48:05 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: PHP/7.0.30
Expires: Tue, 26 Jun 2018 06:48:05 GMT
Cache-Control: max-age=86400
X-Cache: MISS

第一次访问 X-Cache: MISS 说明还未进行缓存。

[root@localhost local]# curl -I localhost/archives/1.php
HTTP/1.1 200 OK
Server: nginx/1.14.0
Date: Mon, 25 Jun 2018 06:50:57 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: PHP/7.0.30
Expires: Tue, 26 Jun 2018 06:48:05 GMT
Cache-Control: max-age=86400
X-Cache: HIT

第二次访问发现X-Cache: HIT,表明/archives/1.php这个url已经被缓存,再下次访问nignx将不再会去请求php-fpm进行执行,而会直接从缓存中读取并返回,能够大大提高网站速度。

4. 遇到问题

a)访问空白
配置完毕后发现时常会出现页面访问空白的情况,再清空缓存目录后重新访问就恢复了。
经过测试发现是由于第一次使用HEAD方式访问,返回一个body为空的响应并被缓存了,所以之后再次访问就获取到了空白的页面。
这是由于fastcgi_cache_key中没有设置$request_method,将GET和HEAD的请求存储到了同一个key中。

b)页面缓存失败,一直MISS
默认情况下,请求的header中包含“Expires”, “Cache-Control”, “Set-Cookie”等,页面将不会被缓存,所以添加fastcgi_ignore_headers Cache-Control Expires Set-Cookie;即可。

nginx下禁止访问.git等隐藏文件夹

今天进腾讯云的控制台 偶然发现腾讯云一直给我提示的漏洞 其中有一个挺为严重的 汗.png

未分类

我的网站配置下并没有屏蔽隐藏文件夹例如.git等文件夹的访问 甚至可以直接下载隐藏文件夹的内容
确实是我没有想到的 如果你也有这种情况 就需要进行配置服务器来禁止敏感文件的访问了 否则就直接暴露在大庭广众之下了…

nginx的配置很简单

在server{}段内增加
代码如下:

location ~ /.
{
deny all;
}

这样就把所有的隐藏文件夹给屏蔽访问了 如果想单独屏蔽某一隐藏文件夹的访问只需要

location ^~ /.git
{
return 444;
}

阿里云DOCKER标准日志采集(NGINX)

部署Logtail容器

1. 拉取Logtail镜像

docker pull registry.cn-hangzhou.aliyuncs.com/log-service/logtail

2. 启动Logtail容器

docker run -d -v /:/logtail_host:ro -v /var/run/docker.sock:/var/run/docker.sock --env ALIYUN_LOGTAIL_CONFIG=/etc/ilogtail/conf/${your_region_name}/ilogtail_config.json --env ALIYUN_LOGTAIL_USER_ID=${your_aliyun_user_id} --env ALIYUN_LOGTAIL_USER_DEFINED_ID=${your_machine_group_user_defined_id} registry.cn-hangzhou.aliyuncs.com/log-service/logtail

参数说明

参数                                  参数说明

${your_region_name}                 region名,请替换为您创建的日志服务project所在Region。Region名称请从Logtail安装参数列表中选择。
${your_aliyun_user_id}                  用户标识,请替换为您的阿里云主账号用户ID。主账号用户ID为字符串形式。
${your_machine_group_user_defined_id}   您集群的机器组自定义标识。如您尚未开启自定义标识,请参考自定义机器组的步骤一,开启userdefined-id。

示例:docker run -d -v /:/logtail_host:ro -v /var/run/docker.sock:/var/run/docker.sock –env ALIYUN_LOGTAIL_CONFIG=/etc/ilogtail/conf/cn-hangzhou_internet/ilogtail_config.json –env ALIYUN_LOGTAIL_USER_ID=1473463995701522 –env ALIYUN_LOGTAIL_USER_DEFINED_ID=aliyun-sunaiwen-machine registry.cn-hangzhou.aliyuncs.com/log-service/logtail

查看lables配置信息

docker inspect 3fb1dd4bd2c7

logtail配置

未分类

未分类

Nginx和Apache如何设置ajax跨域

关于ajax跨域的就不过多的介绍,可以参考改文章http://www.qqdeveloper.com/a/75.html

方式一:在被请求的应用程序中添加一个允许请求跨域

1.apache

1.在httpd.conf文件中加载
    LoadModule headers_module modules/mod_headers.so模块
2.在被请求文件头部添加:
header("Access-Control-Allow-Origin: *");

2.nginx

1.在被请求文件头部添加:
    header("Access-Control-Allow-Origin: *");

方式二:在配置文件中允许跨域

1.apache的配置文件httpd.conf

    Options +Indexes +FollowSymLinks +ExecCGI
    AllowOverride All
    Order allow,deny
    Allow from all
    Require all granted
    Header set Access-Control-Allow-Origin * #此行代码即是需要添加的代码2.nginx

2.在被请求的域名nginx配置文件中增加配置,配置位置和root的配置等级一致

add_header Access-Control-Allow-Origin *;
add_header Access-Control-Allow-Headers X-Requested-With;
add_header Access-Control-Allow-Methods GET,POST,OPTIONS;

该方式配置参考链接:http://www.nginx.cn/4592.html