【填坑日记8】Nginx(部署+负载均衡+缓存)

文章目录前言NGINXJenkinswebpack打包前言搞完日记7：http的session相关信息后，又去翻了翻http/https/http2的相关的内容，另外写了两篇文章。现在回到继续填坑的过程中来。前面已经完成了一个开发的基本流程，接下来，我需要把这样一个东西打包然后再发布到一台服务器上提供服务。开发模式下我们用的npm start对应的命令是："start": "npm run dev

新兴AI民工

14475人浏览 · 2020-06-15 14:58:22

新兴AI民工 · 2020-06-15 14:58:22 发布

文章目录

前言
NGINX

前言

搞完日记7：http的session相关信息后，又去翻了翻http/https/http2的相关的内容，另外写了两篇文章。
现在回到继续填坑的过程中来。
前面已经完成了一个开发的基本流程，接下来，我需要把这样一个东西打包然后再发布到一台服务器上提供服务。开发模式下我们用的npm start对应的命令是：

"start": "npm run dev",

这个是启动webpack-dev-server工具的http服务器进行调试工作，真正部署到服务器上肯定不能用这个玩意。我选择的是nginx做web服务器。
执行：

npm run build

对应的脚本为：

"build": "node build/build.js"

再看下build/build.js文件：

webpack(webpackConfig, (err, stats) => {
	...
}

就是用webpack进行打包操作。这个webpack相关的内容后续再写blog记录，先看看打包的结果：
生成了一个dist目录：

把项目里的所有JS/CSS/IMG等静态资源全部打包好了。直接把这个放到web服务器(容器)中就可以提供服务了。

NGINX

nginx可以起到下面几个作用

web 服务.
负载均衡（反向代理）
web cache（web 缓存）
先用上web服务再说。

安装

从官网上下载一个下来：nginx-1.16.1.tar.gz
tar zxvf nginx-1.16.1.tar.gz
configure之前，先安装几个依赖库。
```
 apt-get install libpcre3 libpcre3-dev  
 apt-get install zlib1g-dev
```
openssl一般有，就不记录了，安装openssl的教程也挺多的。
进入目录，./configure --prefix = /tools。不设置的话就安装在/usr/local/下面。我没有设置，测试用的。
make
make install
搞定。

配置 & 启动

cd /usrlocal/nginx
vim conf/nginx.conf

修改location:

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

将刚才打包的dist文件夹复制到/usr/local/nginx下
执行sbin/nginx即可，也可以先执行sbin/nginx -t来检查下配置文件是否OK。
nginx常用命令：
- nginx -s signal
- signal: stop — fast shutdown
- signal: quit — graceful shutdown
- signal: reload — reloading the configuration file
- signal: reopen — reopening the log files，用来打开日志文件，这样nginx会把新日志信息写入这个新的文件中
打开浏览器，输入localhost就可以看到成果了。

Nginx的一点技能点

进程

启动nginx后，我们使用

ps aux |  grep nginx

来查看：
Nginx进程
有两个进程：

nginx: master process nginx
nginx: worker process
原理，搬运一张图过来：
配置，在conf/ngin.conf文件里：worker_processes参数，直接改成二，再看下进程：

反向代理的配置

反向代理一般来说是为了实现负载均衡：

同一服务器上的不同路径提供了不同的静态资源，比如/image提供图像，/reports提供pdf文件等等，这些是存放在服务器上的不同路径。
不同服务器上的服务，一台服务器放不下的时候，这些资源和服务就会部署到其他的服务器上。

我准备了两台机器：

IP为114.116.112.50 / 114.116.115.110
两台机器上都启动nginx作为web容器
114.116.112.50的nginx还作为反向代理

114.116.112.50上本地放了三个静态资源，分别位于：
/tools/nginx/html
/tools/nginx/net1
/projects/html
三个目录，每个目录里都是一个文件：index.html。
内容分别为：

  <!--/tools/nginx/html/index.html -->
  < html >
  < head >
  < title>Welcome to nginx!< /title>
  </head>
  <body>
  <h1>I am root</h1>
  </body>
  </html>

  <!--/tools/nginx/net1/index.html -->
  <html>
  <head>
  <title>Welcome to nginx!</title>
  </head>
  <body>
  <p>I am n2</p>
  </body>
  </html>

  <!--/projects/html/index.html -->
  <html>
    <head>
      <title>Welcome to nginx</title>
    </head>
    <body>
      <p>I am n3</p>
    </body>
  </html>

另外一台机器上有一个路径：/tools/nginx/html，一个文件index.html

  <html>
  <head>
  <title>Welcome to nginx!</title>
  </head>
  <body>
  <p>I am n1</p>
  </body>
  </html>

在114.116.112.50的机器上配置conf/nginx.conf文件，在server块中添加三个location块：

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

  location /n1 {
    proxy_pass http://114.116.115.110/;  #point 1，以斜杠结尾
  }

  location /n2 {
    alias net1;    #point 2，使用alias，不使用root指令
    index index.html;
  }

  location /n3 {
    alias /projects/html;
    index index.html;
  }

浏览器访问结果：

搞定。
point1：前面代码里注释的部分，proxy_pass指令的URL部分必须以/结尾。在nginx中配置proxy_pass代理转发时，如果在proxy_pass后面的url加/，表示绝对根路径；如果没有/，表示相对路径，把匹配的路径部分也给代理走。
假设下面四种情况分别用 http://192.168.1.1/proxy/test.html 进行访问。

第一种：
location /proxy/ {
proxy_pass http://127.0.0.1/;
}
代理到URL：http://127.0.0.1/index.html

第二种（相对于第一种，最后少一个 / ）
location /proxy/ {
proxy_pass http://127.0.0.1;
}
代理到URL：http://127.0.0.1/proxy/test.html

第三种：
location /proxy/ {
proxy_pass http://127.0.0.1/aaa/;
}
代理到URL：http://127.0.0.1/aaa/test.html

第四种（相对于第三种，最后少一个 / ）
location /proxy/ {
proxy_pass http://127.0.0.1/aaa;
}
代理到URL：http://127.0.0.1/aaa/proxy/index.html
point2：什么时候用root，什么时候用alias。root与alias主要区别在于nginx如何解释location后面的uri，这会使两者分别以不同的方式将请求映射到服务器文件上。root的处理结果是：root路径＋location路径。alias的处理结果是：使用alias路径替换location路径。alias是一个目录别名的定义，root则是最上层目录的定义。
如果我们的代码里使用root /net1的话，会代理到 114.116.112.50/n1/net1上。如果是alias，直接替换location，就是代理到114.116.112.50/net1，就能找到资源。

nginx实现高可用-虚拟IP的使用

上面的反向代理应用的场景是负载均衡，比如每台服务器分担整个web应用的一部分。/data在server1，/image在server2，通过反向代理可以实现。
那么，当某一部分应用非常重要的时候，比如/data，我们想用两台服务器server1和server2同时为/data服务，如果其中的某一台server挂掉了，另外一台server还是可以对外提供服务(数据同步是另外的一个话题，不在这里讨论，这里只讨论请求能响应)。但是server1和server2是两个不同的IP：SIP1，SIP2。而对客户端提供的接口地址只能有一个(用户不能根据你的负载和宕机情况来手动调整ip的输入，那也太不友好了)，这是我们对外提供的访问IP一般就是VIP：Visual IP，虚拟IP。
对于实现基于虚拟IP的高可用，可以采用nginx + keepalive的组合还解决。
VIP对应两个SIP
Keepalived高可用服务对之间的故障切换转移，是通过VRRP (Virtual Router Redundancy Protocol，虚拟路由冗余协议) 来实现的。在keepalived服务工作时，主Master节点会不断地向备节点发送（多播的方式）心跳消息，用来告诉备Backup节点自己还活着。当主节点发生故障时，就无法发送心跳的消息了，备节点也因此无法继续检测到来自主节点的心跳了。于是就会调用自身的接管程序，接管主节点的IP资源和服务。当主节点恢复时，备节点又会释放主节点故障时自身接管的IP资源和服务，恢复到原来的备用角色。

实验环境
上手做个实验吧，上面我准备了两台服务器，每台服务器上都有了一个nginx的web服务器。
192.168.0.165为主节点
192.168.0.113为从节点
安装keepAlive
apt-get install keepalived，安装之后可以直接执行了(成了一个linux的服务)。
版本为v1.2.24

创建配置文件，基本配置
在/etc/keepalived目录下创建一个keepalived.conf(不带-f参数默认用这个，也可以用-f参数指定)
主节点 192.168.0.165的配置：

  ! Configuration File for keepalived
  global_defs {
  
     notification_email {
  
       acassen@firewall.loc
  
       failover@firewall.loc
  
       sysadmin@firewall.loc
  
     }
  
     notification_email_from Alexandre.Cassen@firewall.loc
  
     smtp_server 192.168.0.165
  
     smtp_connect_timeout 30
  
     router_id node1
  
  }
  
  
  
  vrrp_instance VI_1 {
  
      state MASTER
  
      interface eth0
  
      virtual_router_id 55
  
      priority 150
  
      advert_int 1
  
      authentication {
  
          auth_type PASS
  
          auth_pass 123456
  
      }
  
      virtual_ipaddress {
  
          192.168.0.77/24 dev eth0 label eth1:1
  
      }
  
  }

启动
先启动主节点的：
```
  service keepalived start
```
过一阵子就可以看到有一个虚拟IP生成了：

启动从节点的，从节点的不会出现虚拟IP，如果有就不对了，一个网络里出现两个相同的IP了。
停止主节点
在从节点上执行ip addr，可以看到多处一个虚拟IP来了。
重新启动主节点
在两边观察一下，VIP又重新回到了主节点上
使用，看下效果，在第三台服务器上使用curl命令访问VIP。

可以看到，此时访问的是主节点上的内容(特意分开的)

停掉主节点，再使用curl来访问，访问的就是从节点的内容了：
在这里插入图片描述

web缓存基本使用

暂时没有想到使用的场景，先搬运一篇文章放在这里。后续有用到的地方再说：
Nginx 缓存

向您推荐>>Eolink开发者社区

权威｜前沿｜技术｜干货｜国内首个API全生命周期开发者社区

更多推荐

ELK实现containerd的容器日志采集展示【基于logging的全栈监测】

企业级ELK Stack构建介绍

云原生

深入理解 Mocha 测试框架：从零实现一个 Mocha

前言什么是自动化测试自动化测试在很多团队中都是Devops环节中很难执行起来的一个环节，主要原因在于测试代码的编写工作很难抽象，99%的场景都需要和业务强绑定，而且写测试代码的编写工作量往往比编写实际业务代码的工作量更多。在一些很多业务场景中投入产出比很低，适合写自动化测试的应该是那些中长期业务以及一些诸如组件一样的基础库。自动化测试是个比较大的概念，其中分类也比较多，比如单元测试，端对端测试，集

云原生

(20200916 Solved)docker-compose up创建容器自动退出

问题描述如题，创建容器后自动退出了。并且docker start container无效解决方案原因是缺失了控制终端的配置，需要在docker-compose.yml中增加tty:true ，有时候这样也不行，需要再增加一个command:/bin/bash，命令不一定是这个，需要是一个不会退出的命令，然后用-d后台启动容器。Referencesdocker-compose启动容器后自动退出...