nginx一台服务器部署多个域名和证书

手头有俩域名，而且在某云可以拿到一年免费的域名证书。但是由于服务器比较贵，只有一台和对应的公网ip，想怎么支持https证书不会出错的情况下，两个域名都解析到同一个服务器。

所以找了如下的配置。 这里我加了个跳转，如果不需要的也可以不用加跳转。总结来说实现了在资源不够的情况下，稍微变通，同一个ip支持在不同域名下证书有效，即一个ip可以部署多个https网站。

配置就全部拿过来了，注意添加的注释。

以上就是本次的内容，简单做个记录。

如果是同域名，一般是借用sessionid(cookie)。

其实关键问题是session的数据保存的路径问题，在session里，可以设定N个tomcat，设定session保存的介质相同就可以了。 最好，可以考滤用数据库介质。

Nginx是一款自由的、开源的、高性能的HTTP服务器和反向代理服务器；同时也是一个IMAP、POP3、SMTP代理服务器；Nginx可以作为一个HTTP服务器进行网站的发布处理，另外Nginx可以作为反向代理进行负载均衡的实现。

1、全局块：配置影响nginx全局的指令。一般有运行nginx服务器的用户组，nginx进程pid存放路径，日志存放路径，配置文件引入，允许生成worker process数等。

2、events块：配置影响nginx服务器或与用户的网络连接。有每个进程的最大连接数，选取哪种事件驱动模型处理连接请求，是否允许同时接受多个网路连接，开启多个网络连接序列化等。

3、http块：可以嵌套多个server，配置代理，缓存，日志定义等绝大多数功能和第三方模块的配置。如文件引入，mime-type定义，日志自定义，是否使用sendfile传输文件，连接超时时间，单连接请求数等。

4、server块：配置虚拟主机的相关参数，一个http中可以有多个server。

5、location块：配置请求的路由，以及各种页面的处理情况。

6、缓存控制字段cache-control的配置说明 ( https://wwwcnblogscom/kevingrace/p/10459429html )

HTTP协议的Cache -Control指定请求和响应遵循的缓存机制。在请求消息或响应消息中设置 Cache-Control并不会影响另一个消息处理过程中的缓存处理过程。

请求时的缓存指令包括: no-cache、no-store、max-age、 max-stale、min-fresh、only-if-cached等。

响应消息中的指令包括: public、private、no-cache、no- store、no-transform、must-revalidate、proxy-revalidate、max-age。

no-cache: 数据内容不能被缓存, 每次请求都重新访问服务器, 若有max-age, 则缓存期间不访问服务器

no-store: 不仅不能缓存, 连暂存也不可以(即: 临时文件夹中不能暂存该资源)

private(默认): 只能在浏览器中缓存, 只有在第一次请求的时候才访问服务器, 若有max-age, 则缓存期间不访问服务器

public: 可以被任何缓存区缓存, 如: 浏览器、服务器、代理服务器等

max-age: 相对过期时间, 即以秒为单位的缓存时间

no-cache, private: 打开新窗口时候重新访问服务器, 若设置max-age, 则缓存期间不访问服务器

设置以分钟为单位的绝对过期时间, 优先级比Cache-Control低, 同时设置Expires和Cache-Control则后者生效 也就是说要注意一点: Cache-Control的优先级高于Expires

expires起到控制页面缓存的作用，合理配置expires可以减少很多服务器的请求, expires的配置可以在http段中或者server段中或者location段中 比如控制等过期时间为30天

客户端必须设置正向代理服务器，当然前提是要知道正向代理服务器的IP地址，还有代理程序的端口。

"它代理的是客户端，代客户端发出请求"，是一个位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。客户端必须要进行一些特别的设置才能使用正向代理。

正向代理的用途：

（1）访问原来无法访问的资源，如Google

（2） 可以做缓存，加速访问资源

（3）对客户端访问授权，上网进行认证

（4）代理可以记录用户访问记录（上网行为管理），对外隐藏用户信息

多个客户端给服务器发送的请求，Nginx服务器接收到之后，按照一定的规则分发给了后端的业务处理服务器进行处理了。此时~请求的来源也就是客户端是明确的，但是请求具体由哪台服务器处理的并不明确了，Nginx扮演的就是一个反向代理角色。

客户端是无感知代理的存在的，反向代理对外都是透明的，访问者并不知道自己访问的是一个代理。因为客户端不需要任何配置就可以访问。

反向代理，"它代理的是服务端，代服务端接收请求"，主要用于服务器集群分布式部署的情况下，反向代理隐藏了服务器的信息。

反向代理的作用：

（1）保证内网的安全，通常将反向代理作为公网访问地址，Web服务器是内网

（2）负载均衡，通过反向代理服务器来优化网站的负载

Nginx是一个HTTP服务器 ，可以将服务器上的静态文件（如HTML、）通过HTTP协议展现给客户端。

客户端本来可以 直接 通过HTTP协议访问某网站应用服务器，如果网站管理员在中间加上一个Nginx，客户端请求Nginx，Nginx请求应用服务器，然后将结果返回给客户端。

负载均衡： 将 相同的应用 部署在多台服务器上，将大量用户的请求分配给多台机器处理。同时带来的好处是， 其中一台服务器万一挂了，只要还有其他服务器正常运行 ，就不会影响用户使用。

虚拟主机： 如将 wwwaaacom 和 wwwbbbcom 两个网站部署在同一台服务器上，两个域名解析到同一个IP地址，但是用户通过两个域名却可以打开两个完全不同的网站，互相不影响，就像访问两个服务器一样，所以叫两个虚拟主机。

在服务器8080和8081分别开了一个应用，客户端通过不同的域名访问，根据server_name可以反向代理到对应的应用服务器。

动态静态资源分离：

之前开发web方面的程序时候我们习惯将 html、css等资源文件也放置于Tomcat中 ，用户访问后tomcat需要将请求的这些静态资源文件一并返回给用户。

再者如果有多台同业务逻辑的tomcat服务器的话，同样的资源还需要在每个服务器上放一份，同时也增加了tomcat服务器的网络IO。

如果我们只讲JSP之类的请求交给tomcat， 在代理服务器上存放静态资源 ，当用户的请求非动态资源的时候， 我们完全可以将代理服务器的静态资源直接返回给用户，而不去增大Tomcat的压力 ，

tomcat只需要 负责逻辑处理 和 动态资源的加载 就可以了。

Tomcat的高并发性能很弱 ，所以在处理 静态请求的时候，我们就抛给Nginx处理 ，而Tomcat专门处理动态请求。

Nginx和Tomcat结合方式 ：

WEB-INF

WEB-INF是Java的WEB应用的安全目录。所谓安全就是客户端无法访问， 只有服务端可以访问的目录 。

负载均衡

先来简单了解一下什么是负载均衡，单从字面上的意思来理解就可以解释N台服务器平均分担负载，不会因为某台服务器负载高宕机而某台服务器闲置的情况。那么负载均衡的前提就是要有多台服务器才能实现，也就是两台以上即可。

测试环境

在VMware里安装了三台。

A服务器IP ：1921680219 （主）

B服务器IP ：1921680119

C服务器IP ：1921680109

部署思路

A服务器做为主服务器，域名直接解析到A服务器（1921680219）上，由A服务器负载均衡到B服务器（1921680119）与C服务器（1921680109）上。

在A服务器上，upstream指令——分配负载

vi /etc/nginx/confd/defaultconf

upstream 1921680219 {

server 1921680119:80;

server 1921680109:80;

}

server {

listen 80;

server_name 1921680219;

charset utf8;

location / {

proxy_pass

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服务器上，

vi /etc/nginx/confd/defaultconf

server {

listen 80;

server_name 1921680219;

index indexhtml;

root /usr/share/nginx/html;

}

保存重启nginx

测试

当访问的时候，为了区分是转向哪台服务器处理我分别在B、C服务器下写一个不同内容的indexhtml文件，以作区分。

打开浏览器访问acom结果，刷新会发现所有的请求均分别被主服务器（1921685149）分配到B服务器（1921680119）与C服务器（1921680109）上，实现了负载均衡效果。

主服务器不能提供服务吗？

以上例子中，我们都是应用到了主服务器负载均衡到其它服务器上，那么主服务器本身能不能也加在服务器列表中，这样就不会白白浪费拿一台服务器纯当做转发功能，而是也参与到提供服务中来。

怎么解决这个问题呢？因为80端口已经用来监听负载均衡的处理，那么本服务器上就不能再使用80端口来处理1921680219的访问请求，得用一个新的。

于是我们在主服务器中编辑/etc/nginx/confd/defaultconf，添加以下内容

server {

listen 8080;

server_name 1921680219;

index indexhtml;

root /usr/share/nginx/html;

}

重启nginx

然后，再重新渡负载均衡。

更多Nginx相关教程见以下内容 ：

CentOS 62实战部署Nginx+MySQL+PHP

使用Nginx搭建WEB服务器

搭建基于Linux63+Nginx12+PHP5+MySQL55的Web服务器全过程

CentOS 63下Nginx性能调优

CentOS 63下配置Nginx加载ngx_pagespeed模块

CentOS 64安装配置Nginx+Pcre+php-fpm

Nginx安装配置使用详细笔记

Nginx日志过滤 使用ngx_log_if不记录特定日志

pod 是 kubernetes 中最小的编排单位，通常由一个容器组成 (有时候会有多个容器组成)

nginx-podyaml

将配置apply到k8s

kubectl apply -f nginxyaml

校验部署状态，此时 STATUS 为 Running 表明部署成功

获取 Pod 部署的状态，特别是 IP ,  -o wide 列出IP/Node等更多信息 

kubectl get pods nginx -o wide

获取更加详细的信息

kubectl describe pod nginx

使用 kubectl exec 进入 Pod 的内部容器。如果 Pod 中有多个容器，使用 kubectl exec -c 指定容器

kubectl exec -it nginx sh

在 Pod 容器中执行命令，校验其中的 socket 情况以及 nginx 服务

netstat -tan

wget -q -O - localhost

二、Deployment

在 k8s 中编排应用可以更好地做弹性扩容，负载均衡。既然要均衡，一个 Pod 肯定不能均衡，自然要部署多个 Pod

docker-compose 可以简单地通过 docker-compose scale 来扩容，现在用k8s扩容

在k8s中管理 Pod 的称作 Controller，我们可以使用 Deployment 这种 Controller 来为 Pod 进行扩容，当然它还可以滚动升级，回滚，金丝雀等等关于部署的事情

我们编写一个 Deployment 的资源配置文件

我们使用 kubectl apply 部署生效后查看 Pod 以及 Deployment 状态

kubectl get pods -o wide -l 'app=nginx'

三、 Service 

Service 做服务发现 指定 Deployment 或者特定集合 Pod 的网络层抽象

创建NodePort service时，用户可以指定范围为30000-32767的端口，对该端口的访问就能通过 kube-proxy 代理到service后端的pod中

我们使用 kubectl apply 部署生效后查看 Service 状态

kubectl get svc nginx-service -o wide

curl http://127001:31871

截图中源码文件地址： https://giteecom/pingfanrenbiji/study/blob/master/k8s/nginx/%E4%B8%80%E4%B8%AApod%E5%8D%95%E4%B8%AA%E5%AE%B9%E5%99%A8/

参考文章： https://juejinim/post/5db8c2b46fb9a020256692dc

在linux下安装nginx的时候，一般在/configure的阶段会要求通过prefix设置安装路径。因此，在/configure的时候指定不同的prefix就可以安装多个nginx啦。

值得注意的是，安装完之后，两个nginx的监听端口要设置成不同的监听端口。否则，会有一个nginx无法启动。

/configure --prefix=/home/work/nginx1 //第一个nginx的安装配置

make && make install/configure --prefix=/home/work/nginx2 //第二个nginx的安装配置

make && make installcd /home/work/nginx1/conf/nginxconf && 修改第一个nginx的监听端口

/home/work/nginx1/sbin/nginxcd /home/work/nginx2/conf/nginxconf && 修改第二个nginx的监听端口

/home/work/nginx2/sbin/nginx