Nginxを使用して静的ページをデプロイする方法-PHPチュートリアル-php.cn

この記事では、主に Nginx を使用して静的ページをデプロイする方法を紹介します。これは、必要な友達と共有します。

Nginx は、ロシア人非常に軽量な HTTP サーバーである Nginx (「エンジン X」と発音) は、高性能 HTTP およびリバースプロキシサーバーであり、IMAP/POP3/SMTP プロキシサーバーでもあります。 Nginx は、ロシアで 2 番目にアクセス数の多い Rambler.ru サイト用にロシアの Igor Sysoev によって開発され、2 年半以上運営されています。 Igor Sysoev は BSD ライセンスに基づいてプロジェクトを構築しました。 Nginx は、HTTP サーバーとして、次の基本機能を備えています:

静的ファイル、インデックスファイルの処理、およびファイル記述子のバッファリングの自動有効化。

キャッシュレスリバースプロキシアクセラレーション、シンプルなロードバランシング、フォールトトレランス。
高速CGI、シンプルな負荷分散、フォールトトレランス。
モジュール構造。 gzip 圧縮、バイト範囲、チャンク応答、SSI フィルターなどのフィルターが含まれます。 1 つのページ内に複数の SSI が存在し、Fast CGI または別のプロキシサーバーによって処理される場合、この処理はお互いを待たずに並行して実行できます。
SSLとTLSSNIをサポートします。
Nginx の利点: 軽量、高性能、強力な同時実行性。静的ページを展開する場合にも非常に便利です。
この高いパフォーマンスは、Nginx フレームワークによるものです。 Nginx が起動すると、マスタープロセスと複数のワーカープロセスが存在します。マスタープロセスは主にワーカープロセスの管理に使用されます。これには、外部からのシグナルの受信、各ワーカープロセスへのシグナルの送信、ワーカープロセスの実行ステータスの監視、ワーカープロセスの終了時に新しいワーカープロセスを自動的に再起動するなどが含まれます。異常事態）。基本的なネットワークイベントはワーカープロセスで処理されます。複数のワーカープロセスは互いに同等であり、クライアントからのリクエストを平等に競合し、各プロセスは互いに独立しています。リクエストは 1 つのワーカープロセスでのみ処理でき、ワーカープロセスは他のプロセスからのリクエストを処理できません。ワーカープロセスの数は、通常、マシンの CPU コア数と一致するように設定します。これは、Nginx のプロセスモデルとイベント処理モデルに関係します。

Nginxを選ぶ理由

Nginxと言えば、最初に思い浮かぶのはリバースプロキシとロードバランシングでしょう。では、リバースプロキシとは何ですか、ロードバランシングとは何ですか?
リバースプロキシ

まず、フォワードプロキシとは何かを理解しましょう。プロキシはネットワークプロキシとも呼ばれ、特別なネットワークサービスです。一般に、クライアントとターゲットサーバーの間の仲介者として機能し、クライアントのリクエストを受信し、クライアントのリクエストに基づいてターゲットサーバーへの対応するリクエストを開始します。 . ターゲットサーバーから指定されたリソースをリクエストして取得し、クライアントに返します。また、プロキシサーバーは、ターゲットサーバーのリソースをローカルキャッシュにダウンロードできます。クライアントが取得したいリソースがプロキシサーバーのキャッシュにある場合、プロキシサーバーはターゲットサーバーへのリクエストを開始せず、直接返します。キャッシュされたリソース。

実際、プロキシサーバーは非常に一般的です。たとえば、GWF のために存在する一部の科学インターネットエージェントは、ドメイン名を正しく解決して科学インターネットアクセスを実現するために外部サーバーをプロキシサーバーとして使用します。プロキシサーバーは実際の IP を隠すこともできます。たとえば、有名な Tor (Onion Router) は、複数のプロキシといくつかの暗号化テクノロジを使用して匿名通信を実現します。

リバースプロキシは、クライアントではなくサーバー側のプロキシとして使用されます。つまり、フォワードプロキシは、内部ネットワークユーザーがインターネット上のサーバーの接続要求にアクセスするためのプロキシであり、リバースプロキシは、プロキシサーバーを使用してインターネット上の接続要求を受け付け、その要求を転送します。内部ネットワーク上のサーバーにリクエストを転送し、得られた結果をインターネット上の接続を要求しているクライアントに返します。このとき、プロキシサーバーは外部のサーバーとして認識されます。

負荷分散

リバースプロキシ負荷分散技術は、インターネットからの接続要求をリバースプロキシ方式で内部ネットワーク上の複数のサーバーに動的に転送して処理することで、負荷分散の目的を達成します。

なんという偶然でしょう、Nginx がすべてを実現しました

優れたプロキシサーバーとしての Nginx には、リバースプロキシとロードバランシングが必要です。この知識と使用法について詳しく知りたい場合は、記事の最後にある参考資料「Nginx 入門ガイド」を参照してください。

Nginx のインストール

私は Tencent Cloud サーバーを使用しています。バージョンは: Ubuntu Server 14.04.1 LTS 32 ビットです。

$ apt-get install nginx

ログイン後にコピー

Mac OS システムでは、この記事を参照します: Mac OS に Nginx をインストールするそしてこれがこの記事の焦点です。

Nginx 的配置系统由一个主配置文件和其他一些辅助的配置文件构成。这些配置文件均是纯文本文件，一般地，我们只需要配置主配置文件就行了。例如在我的服务器上是在：/etc/nginx/nginx.conf 。

指令上下文

nginx.conf 中的配置信息，根据其逻辑上的意义，对它们进行了分类，也就是分成了多个作用域，或者称之为配置指令上下文。不同的作用域含有一个或者多个配置项。

其中每个配置项由配置指令和指令参数构成，形成一个键值对，# 后面地为注释，理解起来也非常容易。

一般配置文件的结构和通用配置如下：

user www-data;  # 运行 nginx 的所属组和所有者
worker_processes 1;  # 开启一个 nginx 工作进程,一般 CPU 几核就写几
pid /run/nginx.pid;  # pid 路径

events {
    worker_connections 768;  # 一个进程能同时处理 768 个请求
    # multi_accept on;
}

# 与提供 http 服务相关的配置参数，一般默认配置就可以，主要配置在于 http 上下文里的 server 上下文
http {
    ##
    # Basic Settings
    ##

    ... 此处省略通用默认配置

    ##
    # Logging Settings
    ##
    ... 此处省略通用默认配置

    ##
    # Gzip Settings
    ##

    ... 此处省略通用默认配置

    ##
    # nginx-naxsi config
    ##

    ... 此处省略通用默认配置

    ##
    # nginx-passenger config
    ##

    ... 此处省略通用默认配置

    ##
    # Virtual Host Configs
    ##

    ... 此处省略通用默认配置

    # 此时，在此添加 server 上下文，开始配置一个域名，一个 server 配置段一般对应一个域名
    server {
        listen 80;        # 监听本机所有 ip 上的 80 端口
        server_name _;      # 域名：www.example.com 这里 "_" 代表获取匹配所有
        root /home/filename/;  # 站点根目录

        location / {       # 可有多个 location 用于配置路由地址
            try_files index.html =404;
        }
}

# 邮箱的配置，因为用不到，所以把这个 mail 上下文给注释掉
#mail {
#    # See sample authentication script at:
#    # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
#    
#    # auth_http localhost/auth.php;
#    # pop3_capabilities "TOP" "USER";
#    # imap_capabilities "IMAP4rev1" "UIDPLUS";
#   
#    server {
#        listen   localhost:110;
#        protocol  pop3;
#        proxy    on;
#    }
#
#    server {
#        listen   localhost:143;
#        protocol  imap;
#        proxy    on;
#    }
#}

ログイン後にコピー

这里需要注意的是 http 上下文里的 server 上下文。

server {
    listen 80;        # 监听本机所有 ip 上的 80 端口
    server_name _;      # 域名：www.example.com 这里 "_" 代表获取匹配所有
    root /home/filename/;  # 站点根目录

    location / {       # 可有多个 location 用于配置路由地址
      try_files index.html =404;
    }
}

ログイン後にコピー

这里的 root 字段最好写在 location 字段的外边，防止出现无法加载 css、js 的情况。因为 css、js 的加载并不是自动的，nginx 无法执行，需要额外的配置来返回资源，所以，对于静态页面的部署，这样做是最为方便的。

这里对 root 作进一步解释，例如在服务器上有 /home/zhihu/ 目录，其下有 index.html 文件和 css/ 以及 img/ ， root /home/zhihu/; 就将指定服务器加载资源时是在 /home/zhihu/ 下查找。

其次， location 后的匹配分多种，其各类匹配方式优先级也各不相同。这里列举一精确匹配例子：

server {
    listen 80;        
    server_name _;      
    root /home/zhihu/;  

    location = /zhihu {
      rewrite ^/.* / break;
      try_files index.html =404;
    }
}

ログイン後にコピー

此时，访问 www.example.com/zhihu 就会加载 zhihu.html 出来了。由于 location 的精确匹配，只有访问 www.example.com/zhihu 这个路由时才会正确响应，而且此时要通过 rewrite 正则匹配，把 /zhihu 解析替换成原来的 / 。关于更多 location 字段用法，可以在文章最后给出的参考资料中查看。

关于使用 nginx 部署静态页面，最简单便捷的配置方法

上面说了挺多关于配置的说明，下面推荐一种个人认为最为便捷的配置方法。（特此感谢 guyskk 学长的答疑解惑）

首先创建一个目录，例如： /home/ubuntu/website 然后在这个 website 文件夹下可以放置你需要部署的静态页面文件，例如 website 下我有 google、zhihu、fenghuang 这三个文件夹，其中 server 字段配置如下：

server {
    listen 80;
    server_name _;
    root /home/ubuntu/website;
    index index.html;
}

ログイン後にコピー

这里每个文件夹下面的静态页面文件名都是 index.html ，我以前有个很不好的习惯，比如 zhihu 页面就喜欢命名为 zhihu.html ，但就从前端来看，这也是不符合规范的。

这样配置的话，例如当你访问 www.showzeng.cn/google/ 时，nginx 就会去 website 目录下的 google 文件夹下寻找到 index.html 并把 google 页面返回，同理，访问 www.showzeng.cn/zhihu/ 时，会寻找到 zhihu 文件夹下的 index.html 并把 zhihu 页面返回。

而在 zhihu、google 、fenghuang 文件夹的同级目录上，再添加你的域名首页 index.html 时，访问 www.example.com 时就会返回了。

这里唯一美中不足的是，访问域名中 www.showzeng.cn/zhihu 末尾会自动加上 / ，在浏览器中按 F12 调试会发现 www.showzeng.cn/zhihu 为 301 状态码，因为 index.html 是在 zhihu/ 文件夹下，所以在搜索过程中会重定向到 www.showzeng.cn/zhihu/ ，起初我是接受不了的，那一 / 看起来太难受了，但是只要一想到要一个一个 location 字段去匹配，我一下子就接受了。不知道你怎么看，反正我是接受了。

Nginx 启动运行