写给前端的nginx配置指南基于docker所有配置秒级运行(最新讲解)

目录
  • 通过 docker 高效学习 nginx 配置
  • root 与 index
  • location
    • location 修饰符验证
    • location 优先级验证
  • proxy_pass
  • add_header
    • Cache
    • CORS
    • HSTS
    • CSP
  • 作业

三年经验的前端或多或少与 nginx 配置打过交道。

nginx 的重要性不言而喻。

本篇文章以前端的视角,介绍下 nginx 的常见配置。

通过 docker 高效学习 nginx 配置

推荐一种高效学习 nginx 的方法: 在本地使用 nginx 镜像并挂载 nginx 配置启动容器

通过以下 docker-compose 可秒级验证 nginx 配置,无疑是学习 nginx 的绝佳利器。

我将所有关于 nginx 的配置放置在 simple-deploy,并且每一份配置对应 docker compose 中的一个 service,如以下 nginx、location、order1 就是 service

version: "3"
services:
  # 关于 nginx 最常见配置的学习
  nginx:
    image: nginx:alpine
    ports:
      - 8080:80
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf
      - .:/usr/share/nginx/html
  # 关于 location 的学习
  location: ...
  # 关于 location 匹配顺序的学习
  order1: ...

每次修改配置时,需要重启容器,可根据服务名学习指定内容。

$ docker-compose up <service>
# 学习 nginx 最基础的配置
$ docker-compose up nginx
# 学习关于 location 的配置
$ docker-compose up location

本篇文章所有的 nginx 配置均可以通过 docker 来进行学习,并附全部代码及配置。

root 与 index

rootindex 为前端部署的基础,在默认情况下 root 为 /usr/share/nginx/html,因此我们部署前端时,往往将构建后的静态资源目录挂载到该地址。

server {
    listen       80;
    server_name  localhost;
    root   /usr/share/nginx/html;
    index  index.html index.htm;
}

location

location 用以匹配路由,配置语法如下。

location [ = | ~ | ~* | ^~ ] uri { ... }

其中 uri 前可提供以下修饰符

  • = 精确匹配。优先级最高
  • ^~ 前缀匹配,优先级其次
  • ~ 正则匹配,优先级再次 (~* 只是不区分大小写,不单列)
  • / 通用匹配,优先级再次

为了验证所匹配的 location,我会在以下示例中添加一个自定义响应头 X-Config,可通过浏览器控制台网络面板验证其响应头。

add_header X-Config B;

注意,我所有配置文件中的链接可直接点击,避免了在 compose 配置文件中寻找映射端口号的不方便

location 修饰符验证

对于此四种修饰符可以在我的 nginx 下进行验证。

由于此处使用了 proxy_pass,因此需要 location2api 两个服务一起启动,在 location2 服务中,可直接通过 service 名称作为 hostname 即 http://api:3000 访问 api 服务。

而 api 服务,为我自己写的一个 whoami 服务,用以打印出请求路径等信息,详见 shfshanyue/whoami。

$ docker-compose up location2 api

以下是关于验证 location 的配置文件,详见 shfshanyue/simple-daploy:learn-nginxs

server {
    listen       80;
    server_name  localhost;
    root   /usr/share/nginx/html;
    index  index.html index.htm;
    # 通用匹配,所有 /xxx 任意路径都会匹配其中的规则
    location / {
        add_header X-Config A;
        try_files  $uri $uri.html $uri/index.html /index.html;
    }
    # http://localhost:8120/test1           ok
    # http://localhost:8120/test1/          ok
    # http://localhost:8120/test18          ok
    # http://localhost:8120/test28          not ok
    location /test1 {
        # 可通过查看响应头来判断是否成功返回
        add_header X-Config B;
        proxy_pass http://api:3000;
    }
    # http://localhost:8120/test2           ok
    # http://localhost:8120/test2/          not ok
    # http://localhost:8120/test28          not ok
    location = /test2 {
        add_header X-Config C;
        proxy_pass http://api:3000;
    }
    # http://localhost:8120/test3           ok
    # http://localhost:8120/test3/          ok
    # http://localhost:8120/test38          ok
    # http://localhost:8120/hellotest3      ok
    location ~ .*test3.* {
        add_header X-Config D;
        proxy_pass http://api:3000;
    }
    # http://localhost:8120/test4           ok
    # http://localhost:8120/test4/          ok
    # http://localhost:8120/test48          ok
    # http://localhost:8120/test28          not ok
    location ^~ /test4 {
        # 可通过查看响应头来判断是否成功返回
        add_header X-Config E;
        proxy_pass http://api:3000;
    }
}

location 优先级验证

在我配置文件中,以 order 打头来命名所有优先级验证的 nginx 配置,此处仅仅以 order1 为例进行验证。

配置如下:

# 以下配置,访问以下链接,其 X-Config 为多少
#
# http://localhost:8210/shanyue,为 B,若都是前缀匹配,则找到最长匹配的 location
server {
    root   /usr/share/nginx/html;
    # 主要是为了 shanyue 该路径,因为没有后缀名,无法确认其 content-type,会自动下载
    # 因此这里采用 text/plain,则不会自动下载
    default_type text/plain;
    location ^~ /shan {
        add_header X-Config A;
    }
    location ^~ /shanyue {
        add_header X-Config B;
    }
}

启动服务:

$ docker-compose up order1

curl 验证:

当然也可以通过浏览器控制台网络面板验证,由于此处只需要验证响应头,则我们通过 curl --head 只发送 head 请求即可。

# 查看其 X-Config 为 B
$ curl --head http://localhost:8210/shanyue
HTTP/1.1 200 OK
Server: nginx/1.21.4
Date: Fri, 03 Jun 2022 10:15:11 GMT
Content-Type: text/plain
Content-Length: 15
Last-Modified: Thu, 02 Jun 2022 12:44:23 GMT
Connection: keep-alive
ETag: "6298b0a7-f"
X-Config: B
Accept-Ranges: bytes

proxy_pass

proxy_pass 反向代理,也是 nginx 最重要的内容,这也是常用的解决跨域的问题。

当使用 proxy_pass 代理路径时,有两种情况

  • 代理服务器地址不含 URI,则此时客户端请求路径与代理服务器路径相同。强烈建议这种方式
  • 代理服务器地址含 URI,则此时客户端请求路径匹配 location,并将其 location 后的路径附在代理服务器地址后。
# 不含 URI
proxy_pass http://api:3000;
# 含 URI
proxy_pass http://api:3000/;
proxy_pass http://api:3000/api;
proxy_pass http://api:3000/api/;

再举一个例子:

location /api3 {
    add_header X-Config C;
    # http://localhost:8300/api3/hello -> proxy:3000/hello/hello
    proxy_pass http://api:3000/hello;
}

有点拗口,在我们试验环境有多个示例,使用以下代码启动可反复测试:

$ docker-compose up proxy api

由于 proxy_pass 所代理的服务为 whoami,可打印出真实请求路径,可根据此进行测试

server {
    listen       80;
    server_name  localhost;
    root   /usr/share/nginx/html;
    index  index.html index.htm;
    # 建议使用此种 proxy_pass 不加 URI 的写法,原样路径即可
    # http://localhost:8300/api1/hello -> proxy:3000/api1/hello
    location /api1 {
        # 可通过查看响应头来判断是否成功返回
        add_header X-Config A;
        proxy_pass http://api:3000;
    }
    # http://localhost:8300/api2/hello -> proxy:3000/hello
    location /api2/ {
        add_header X-Config B;
        proxy_pass http://api:3000/;
    }
    # http://localhost:8300/api3/hello -> proxy:3000/hello/hello
    location /api3 {
        add_header X-Config C;
        proxy_pass http://api:3000/hello;
    }
    # http://localhost:8300/api4/hello -> proxy:3000//hello
    location /api4 {
        add_header X-Config D;
        proxy_pass http://api:3000/;
    }
}

add_header

控制响应头。

由于很多特性都是通过响应头控制,因此基于此指令可做很多事情,比如:

  • Cache
  • CORS
  • HSTS
  • CSP
  • ...

Cache

location /static {
    add_header Cache-Control max-age=31536000;
}

CORS

location /api {
    add_header Access-Control-Allow-Origin *;
}
复制代码

HSTS

location / {
    listen 443 ssl;
    add_header Strict-Transport-Security max-age=7200;
}

CSP

location / {
    add_header Content-Security-Policy "default-src 'self';";
}

作业

  • 初阶: 基于 docker 学习 nginx 配置,并可配置 index.html 强缓存 60s 时间
  • 高阶: 基于 docker 学习 nginx 配置,并可配置 gzip/brotli
  • 面试: brotli/gzip 有何区别

到此这篇关于写给前端的nginx配置指南基于docker所有配置秒级运行的文章就介绍到这了,更多相关docker  nginx 配置内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • Docker部署nginx并修改配置文件的实现方法

    docker 部署个nginx,简直太简单了好吧 直接一行命令搞定: docker run \ --name nginx-health-web-pc \ -d -p 6800:80 \ -v /usr/docker/nginx/html:/usr/share/nginx/html \ nginx 运行启动不亦乐乎~~~~~这时候忽然前端过来说:"你的nginx里得加一个配置",顺带还告诉你:"某某某以前就是这样配的", 此时好胜的你当然不能拒绝,但是真正配置起来还是

  • docker安装nginx并配置通过https访问的方法

    1. 下载最新的nginx的docker image $ docker pull nginx:latest 2. 启动nginx容器 运行如下命令来启动nginx container docker run --detach \ --name wx-nginx \ -p 443:443\ -p 80:80 \ -v /home/evan/workspace/wxserver/nginx/data:/usr/share/nginx/html:rw\ -v /home/evan/workspace/w

  • docker安装nginx并配置ssl的方法步骤

    最近想在吃灰了一年多的服务器上,安装一下docker,结果始终找不到合适的yum源,后来经过一番百度才知道,原来centos8要凉了,所以好多镜像站都移除了CentOS 8的源. 没办法,短暂的思考之后,决定重装一下操作系统,换成centos7.9,好在服务器上没啥重要东西,只要给blog挪个窝就行了. 重装系统之后,安装docker过程非常顺利. 开始安装nginx. 1.直接拉取最新的nginx镜像 docker pull nginx 2.新建一些目录,把nginx容器内的相关文件夹挂载到宿

  • docker完整配置nginx+php+mysql的方法步骤

    首先了解一个方法: 使用docker exec进入Docker容器 docker在1.3.X版本之后还提供了一个新的命令exec用于进入容器,这种方式相对更简单一些,下面我们来看一下该命令的使用: sudo docker exec --help 接下来我们使用该命令进入一个已经在运行的容器 $ sudo docker ps $ sudo docker exec -it 775c7c9ee1e1 /bin/bash 一. 配置nginx 查找Docker Hub上的 nginx 镜像 runoob

  • Docker nginx安装与配置挂载的方法

    在Docker下载Nginx镜像 docker pull nginx docker images 创建挂载目录 mkdir -p /data/nginx/{conf,conf.d,html,logs} 编写nginx,conf配置文件,并放在文件夹中 # For more information on configuration, see: # * Official English Documentation: http://nginx.org/en/docs/ # * Official Rus

  • Docker部署Nginx并配置反向代理

    准备工作 在docker内部署任何应用,都需要先下载对应的镜像:下载镜像之前,需要先搜索镜像来确认该镜像是否存在: docker search nginx 从列表可以看到,docker已经有了nginx的镜像,名称是“nginx”,接下来下载镜像: docker pull nginx 下载完成后,查看一下本地镜像: 如果在列表中看到nginx,镜像下载就已经成功了. 容器设置 在docker中,真正运行的是容器,镜像在我理解中是一种环境.我们在指定的镜像中运行某个容器,然后编辑和配置这个容器,从

  • nginx在docker容器中自动生成配置文件

    公司在搭建docker自动化部署时,需要制作一个nginx镜像在其docker run时通过外部指定环境变量使得容器中的配置文件自动生成,不需要再到容器里改配置文件. 实现思路 最后运行的命令大概是这样: docker run -d -p 80:80 -e xxx=xx 镜像名称 镜像中脚本路径 这里的脚本会代替dockerfile中的CMD指令,所以我们要构建一个自动生成且启动nginx的shell脚本. #!/bin/bash #从环境变量里面获取lt开头,为了与其他环境变量区别开,例如lt

  • 写给前端的nginx配置指南基于docker所有配置秒级运行(最新讲解)

    目录 通过 docker 高效学习 nginx 配置 root 与 index location location 修饰符验证 location 优先级验证 proxy_pass add_header Cache CORS HSTS CSP 作业 三年经验的前端或多或少与 nginx 配置打过交道. nginx 的重要性不言而喻. 本篇文章以前端的视角,介绍下 nginx 的常见配置. 通过 docker 高效学习 nginx 配置 推荐一种高效学习 nginx 的方法: 在本地使用 nginx

  • 基于docker安装zabbix的详细教程

    目录 基于docker安装zabbix 1.zabbix配置 2.存储配置 格式化磁盘 创建pv 创建vg 创建lv 创建文件系统 创建挂载目录 挂载分区 写入启动项 3.安装docker 4.修改docker存储路径 5.创建专用于 Zabbix 组件容器的网络: 6.创建mysql库 [废弃]6.docker安装mysql 拉取mysql镜像 创建mysql容器 添加防火墙端口 7.安装zabbix-java-gateway 8.安装zabbix-server 安装zabbix-server

  • 基于Docker、Nginx和Jenkins实现前端自动化部署

    目录 前期准备 部署目标 Dcoker环境的搭建 连接云服务器 安装Docker环境 Docker安装Docker Compose Docker安装Nginx和Jenkins服务 安装Nginx和Jenkins Nginx和Jenkins目录编写 docker-compose.yml文件配置 nginx.conf文件配置 安装Jenkins插件 关联Jenkins和GitLab 生成密钥 新建项目 源码管理 构建触发器 结束语 前期准备 基于CentOS 7系统云服务器一台. 基于Vue-CLI

  • 前端云原生之微信小程序云服务配置指南

    目录 前言 创建使用云开发项目 搭建云环境 测试云服务 1. 获取openid(上传本地login云函数) 2. 自定义sum函数并创建部署 3. 上传图片 4. 前端操作数据库 5. 即时通信demo 总结 前言 如今云原生已经非常火热,很多伙伴说我们前端领域涉及到云原生么?当然了!今天就来为大家介绍我们最直白的涉及到的云原生,就是我们微信小程序开发中的云函数云存储 创建使用云开发项目 将AppID填入 选择小程序云开发 创建即可 成功后会为我们呈现一个实例 刚刚创建的云服务项目中 测试器中有

  • 一篇文章快速掌握Nginx部署前端项目(Nginx安装配置及部署都非常详细!)

    目录 前言: Nginx的三个作用: 负载均衡: 反向代理: 动静分离: Nginx的下载安装(Linux环境下) Nginx的使用 三.部署前端项目 总结 前言: 之前在Linux系统中部署了后端项目,今天继续来给大家分享如何部署前端项目. 涉及到了Nginx的简单介绍以及Nginx如何安装及配置并且能够部署前端项目 Nginx是一个轻量级的反向代理web服务器,在当今应用地非常广泛,特别是前后端分离的情况下. Nginx的三个作用: 负载均衡: 当我们的单个项目访问量达到了单个tomcat无

  • Nginx服务器初期基本配置指南

    一.准备 pcre,有关正则表达式匹配:zlib,用于压缩.这些就不细说了,如果要安装最简版的nginx,记得准备好这两样东西就好了. 用root账户启动服务是比较危险的!  前段时间,测试服务器被黑掉了,终归到底是通过一个root启动的服务上传了木马,最后连ssh都屏蔽了,活生生成为一台肉鸡... 所以,惨痛的经验告诉我,一定要为服务建立对应的组和用户,限制访问权限,降低风险!  这里为nginx建立一个www组,并建立一个不登录的账户nginx: #追加一个www组 groupadd -f

  • 基于Tomcat安全配置与性能优化详解

    Tomcat 是 Apache软件基金会下的一个免费.开源的WEB应用服务器,它可以运行在 Linux 和 Windows 等多个平台上,由于其性能稳定.扩展性好.免费等特点深受广大用户喜爱.目前,很多互联网应用和企业应用都部署在 Tomcat 服务器上,比如我们公司,哈. 之前我们 tomcat 都采用的是默认的配置,因此在安全方面还是有所隐患的.上周对测试环境的所有服务器的tomcat都做了安全优化,其间也粗略做了一些性能优化,这里就简单记录分享下! 一.版本安全 升级当前的tomcat版本

  • Python基于Flask框架配置依赖包信息的项目迁移部署

    一般在本机上完成基于Flask框架的代码编写后,如果有接口或者数据操作方面需求需要把代码部署到指定服务器上. 一般情况下,使用Flask框架开发者大多数都是选择Python虚拟环境来运行项目,不同的虚拟环境中配置依赖包信息不同.如果重新迁移到一个新的虚拟环境后,又重新来一个一个的配置依赖包,那将会很浪费时间. 下面介绍一个简单易用的技巧,也是我自己在书本上看到的,以防每次配置需要翻阅书籍的麻烦,所以单自写一篇文章作记录,方便自己以后查看,也希望给其他学习的同学有点帮助. 完成项目相关代码编写后,

  • vue history 模式打包部署在域名的二级目录的配置指南

    最近在做项目,需要把项目部署在域名下的二级目录,并且是在用vue-router的history 模式. 我们都知道vue-router 的两种前端基本访问模式 hash 和history .hash 模式后面带#,打包的时候只需要把绝对路径(/)换成相对对路径(./),就可以部署在任何地方,不需要服务器配合,但是不好看,所以我们一般选择history 模式,但是history 模式需要配合服务器的部署. 本文主要是在vue-cli3版本下,对部署在域名的二级目录下做四处的配置: 1. vue-r

  • 详解Nginx反向代理跨域基本配置与常见误区

    跨域是指a页面想获取b页面资源,如果a.b页面的协议.域名.端口.子域名不同,所进行的访问行动都是跨域的,而浏览器为了安全问题一般都限制了跨域访问,也就是不允许跨域请求资源.注意:跨域限制访问,其实是浏览器的限制.理解这一点很重要!!! 最近公司前后端分离,前端独立提供页面和静态服务很自然的就想到了用nginx去做静态服务器.同时由于跨域了,就想利用nginx的反向代理去处理一下跨域,但是在解决问题的同时,发现网上有些方案的确是存在一些问题,在这里总结一下基本配置,也聊一下常见的配置问题. Ng

随机推荐