nginx服务器的基本安装和配置方法

Nginx 安装和基本操作

安装
yum install nginx
启动
servic nginx start
停止
service nginx stop
重载
servic nginx reload

安装

安装前可以查询是否已经安装过

sudo yum search nginx

如果需要安装,为了更快安装, 需要将镜像的源添加进来

$ sudo rpm -Uvh http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm

$ yum install nginx

就很快安装好了, 大小2.5m

clipboard.png

和重启restart不同(杀死进程并重新启动), reload 在运行状态下就可以进行服务的重载

运维常用!!! 不会杀死进程就可以更新配置

查看服务状态

clipboard.png

查看Nginx的欢迎页面

clipboard.png

配置

查看配置文件

 [delucia@www modules]$ vim /etc/nginx/nginx.conf

 user nginx;
 worker_processes 1;

 error_log /var/log/nginx/error.log warn;
 pid    /var/run/nginx.pid;

 events {
   worker_connections 1024;
 }

 http {
   include    /etc/nginx/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 /var/log/nginx/access.log main;
   sendfile    on;
   #tcp_nopush   on;
   keepalive_timeout 65;
   #gzip on;
   include /etc/nginx/conf.d/*.conf;
 }

这个主要配置文件

配置了日志存放的位置等信息

也会加载 /etc/nginx/conf.d/*.conf 这些配置文件, 这里默认只有一个default.conf 的文件存在 如下

[delucia@www conf.d]$ vim default.conf 

server {
  listen    80;
  server_name localhost;

  #charset koi8-r;
  #access_log /var/log/nginx/host.access.log main;

  location / {
     root  /usr/share/nginx/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  /usr/share/nginx/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;
  #}
}

可以尝试修改index.html让引导页变得不一样

clipboard.png

拓展

虚拟主机

复制一份detault.conf 重命名为niit.conf

$ sudo cp default.conf niit.conf

$ sudo vim niit.conf

server {
    listen 80;
    server_name www.niit.test;

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

保存, 访问页面:

clipboard.png

页面并没有发生变化, 这是因为修改配置后需要重启或者重载服务

$ sudo service nginx reload

然后访问 首页就是/data/www/index.html的内容了

clipboard.png

按F12打开调试信息:

clipboard.png

这个服务器版本明文显示出来是有安全风险的

如果黑客知道某个版本的容器有漏洞那么就会增加他攻击你的概率

可以通过配置屏蔽掉

多端口

多端口也很容易配置

clipboard.png

保存并重载nginx服务

clipboard.png

多域名

配置多域名也很容易

clipboard.png

修改hosts文件

clipboard.png

然后重载nginx服务就可以这样访问了

clipboard.png

伪静态

NGINX 的伪静态 也就是 重写功夫是默认开启的, 修改 /etc/nginx/conf.d/niit.conf

clipboard.png

这样只要路径符合*.htmp都会指向index.html

clipboard.png

日志格式

nginx 的自定义 日志格式

clipboard.png

main是日志格式的命名空间, 也就是可以允许定义多个格式

当前格式下的日志信息如下:

sudo tail -f /var/log/nginx/access.log

clipboard.png

tailftail-ftail-F三者区别

  • taill -f 等同于--follow=descriptor,根据文件描述符进行追踪,当文件改名或被删除,追踪停止

  • tall -F 等同于-follow=name--retry,根据文件名进行追踪,并保持重试,即该文件被删除或改名后,如果再次创建相同的文件名,会继续追踪

  • tailf 等同于tail -f -n10(貌似tail-f域-F默认也是打印最后10行,然后追踪文件),与tail-f不同的是,如果文件不增长,它不会去访问磁盘文件,所以tailf特别适合那些便携机上跟踪日志文件,因为它减少了磁盘访问,可以省电

自定义日志格式也很简单, 修改nginx.conf文件 增加niit的命令空间

clipboard.png

重载服务后 , 查看日志格式变成

clipboard.png

也可以针对不同虚拟主机设置 不同的日志保存位置

clipboard.png

浏览网页后日志变成

clipboard.png

还有error_log 主要是记录报错信息的

也是一样可以配置的

clipboard.png

反向代理和负载均衡

反向代理

中间的机器就是反向代理, 将local机器的请求代理了,实际请求是发向右边三台服务器其中之一

image-20240317235041317

比如要将我的本地虚拟机的nginx容器反向代理到我的博客地址

clipboard.png

可以通过这个网站查询我的博客域名的实际ip, 然后配置反向代理如下

clipboard.png

这样访问域名www.niit.test时就会被nginx重写请求并指向到我的博客网站了

clipboard.png

F12查看网路

clipboard.png

负载均衡

当一台服务器无法承受请求量, 可以配置多台服务器

负载均衡就是在配置中配置多个主机, 假设我的博客已经部署到了2个不同主机上

 upstream  niit_hosts  {
   server  119.23.14.201:80  weight=5;
   server  119.23.14.301:80  weight-1;
 }

 server  {
   listen  80;
   listen  8080;
   server_name  www.niit.test  www.niit2.test;
   root  /data/www;
   index  index.html  index.htm;
   access_log  /var/log/nginx/access_niit.log   niit;
   location  /  {
     proxy_set_header  Host  www.delucia.cn;
     proxy_pass  http://niit_hosts;
   }
 }

其中weight表示使用权重随机算法作为负载均衡的策略, weight的值代表权重

这样会有5/6的请求被随机转发到第一个server

其他1/6的请求会被随机转发到第二个server

除了权重随机算法之外, 还有线性轮询(默认), 公平(fair)等负载均衡算法可以配置.

调试

 server {
    ...
    add_header Content-Type "text/plain;charset=utf-8";
    return 200 "$http_host";
 ...
 }

注意其中新加入的 add_header ... utf-8return 200 ...

目的是让满足请求条件的页面输出一个$http_host 即请求域名

而utf-8的作用是使输出能够正确显示在页面上

如果不添加这个header则会默认显示下载保存成文件(不推荐)

Views: 90

大厂的 Git 代码管理规范

大厂的 Git 代码管理规范是怎样的?

以下文章来源于码农参上 ,作者Dr Hydra

分支命名

master 分支

master 为主分支,也是用于部署生产环境的分支,需要确保 master 分支稳定性。master 分支一般由 release 以及 hotfix 分支合并,任何时间都不能直接修改代码。

develop 分支

develop 为开发环境分支,始终保持最新完成以及 bug 修复后的代码,用于前后端联调。一般开发新功能时,feature 分支都是基于 develop 分支创建的。

feature 分支

开发新功能时,以 develop 为基础创建 feature 分支。

分支命名时以 feature/ 开头,后面可以加上开发的功能模块, 命名示例:feature/user_module、feature/cart_module。

test 分支

test 为测试环境分支,外部用户无法访问,专门给测试人员使用,版本相对稳定。

release 分支

release 为预上线分支(预发布分支),UAT 测试阶段使用。一般由 test 或 hotfix 分支合并,不建议直接在 release 分支上直接修改代码。

hotfix 分支

线上出现紧急问题时,需要及时修复,以 master 分支为基线,创建 hotfix 分支。修复完成后,需要合并到 master 分支和 develop 分支。

分支命名以hotfix/ 开头的为修复分支,它的命名规则与 feature 分支类似。

分支与环境对应关系

在系统开发过程中常用的环境:

  • DEV 环境(Development environment):用于开发者调试使用。
  • FAT 环境(Feature Acceptance Test environment):功能验收测试环境,用于测试环境下的软件测试者测试使用。
  • UAT 环境 (User Acceptance Test environment):用户验收测试环境,用于生产环境下的软件测试者测试使用。
  • PRO 环境(Production environment):生产环境。

对应关系:

分支 功能 环境 可访问
master 主分支,稳定版本 PRO
develop 开发分支,最新版本 DEV
feature 开发分支,实现新特性
test 测试分支,功能测试 FAT
release 预上线分支,发布新版本 UAT
hotfix 紧急修复分支,修复线上bug

分支合并流程规范

业界常见的两大主分支(master、develop)、三个辅助分支(feature、release、hotfix)的生命周期:

图片

以上生命周期仅作参考,不同开发团队可能有不同的规范,可自行灵活定义。

例如我们团队在开发时,至少需要保证以下流程:

  • develop 分支和 hotfix 分支,必须从 master 分支检出。
  • 由 develop 分支合并到 test 分支。
  • 功能测试无误后,由 test 分支合并到 release 分支。
  • UAT 测试通过后,由 release 分支合并到 master 分支。
  • 对于工作量小的功能开发(工时小于 1 天),可以直接在 devolop 分支进行开发,否则由 develop 分支检出 feature 分支进行开发,开发完后合并到develop 分支。

Git Commit Message 规范

Git Commit Message 规范指提交代码时编写的规范注释,编写良好的 Commit Message 可以达到 3 个重要的目的:

  • 加快代码 review 的流程。
  • 帮助我们编写良好的版本发布日志。
  • 让之后的维护者了解代码里出现特定变化和 feature 被添加的原因。

Angular Git Commit Guidelines

业界应用的比较广泛的是 Angular Git Commit Guidelines:

[type]([scope]): [subject]
[BLANK LINE]
[body]
[BLANK LINE]
[footer]
  • type:提交类型。
  • scope:可选项,本次 commit 波及的范围。
  • subject:简明扼要地阐述下本次 commit 的主旨,在Angular Git Commit Guidelines中强调了三点。使用祈使句,首字母不要大写,结尾无需添加标点。
  • body:同样使用祈使句,在主体内容中我们需要把本次 commit 详细地描述一下,比如此次变更的动机。
  • footer:描述下与之关联的 issue 或 break change。

简易版

项目中实际可以采用简易版规范:

[type]([scope]):[subject]

type 规范

Angular Git Commit Guidelines中推荐的 type 类型如下:

  • feat:新增功能。
  • fix:修复 bug。
  • docs:仅文档更改。
  • style:不影响代码含义的更改(空白、格式设置、缺失分号等)。
  • refactor:既不修复 bug 也不添加特性的代码更改。
  • perf:改进性能的代码更改。
  • test:添加缺少的测试或更正现有测试。
  • chore:对构建过程或辅助工具和库(如文档)的更改。

除此之外,还有一些常用的类型:

  • delete:删除功能或文件。
  • modify:修改功能。
  • build:改变构建流程,新增依赖库、工具等(例如 webpack、gulp、npm 修改)。
  • test:测试用例的新增、修改。
  • ci:自动化流程配置修改。
  • revert:回滚到上一个版本。

单次提交注意事项

  • 提交问题必须为同一类别。
  • 提交问题不要超过 3 个。
  • 提交的 commit 发现不符合规范,git commit --amend -m "新的提交信息"git reset --hard HEAD 重新提交一次。

配置 .gitignore 文件

.gitignore是一份用于忽略不必提交的文件的列表,项目中可以根据实际需求统一.gitignore文件,减少不必要的文件提交和冲突,净化代码库环境。

通用文件示例:

target/
!.mvn/wrapper/maven-wrapper.jar
!**/src/main/**/target/
!**/src/test/**/target/
### STS ###
.apt_generated
.classpath
.factorypath
.project
.settings
.springBeans
.sts4-cache
### IntelliJ IDEA ###
.idea
*.iws
*.iml
*.ipr
### NetBeans ###
/nbproject/private/
/nbbuild/
/dist/
/nbdist/
/.nb-gradle/
build/
!**/src/main/**/build/
!**/src/test/**/build/
### VS Code ###
.vscode/
# Log file
*.log
/logs*
# BlueJ files
*.ctxt
# Mobile Tools for Java (J2ME)
.mtj.tmp/
# Package Files #
*.jar
*.war
*.ear
*.zip
*.tar.gz
*.rar
*.cmd

其他

此外,还有一些其他建议:

  • master 分支的每一次更新,都建议打 tag 添加标签,通常为对应版本号,便于管理。
  • feature 分支、hotfix 分支在合并后可以删除,避免分支过多,管理混乱。
  • 每次 pull 代码前,提交本地代码到本地库中,否则可能会出现合并代码出错,导致代码丢失。

Views: 40