Introduction

WEB 服务的配置总步骤说明, 避免无端的时间浪费, 在系统配置方面, 某一方面的小失误可能会带来极大的时间消耗.

WEB Server的配置步骤主要包括如下几个部分:

  • 应用本身的配置和运行(比如django服务)
  • 介于WEB Server和 APP 之间的”WSGI-网关接口”的配置(比如gunicorn)
  • WEB Server本身的配置
  • WEB Server和 WSGI 网关的联调配置

以下的所有都是基于如下需求而说明: NGINX <----> gunicorn <----> django

在这之前, 首先确保域名解析, 安全组策略等通过, 见dig笔记

Configure

Intro

该步骤的配置非常简单, 利用virtualenvwrap就可以快速的完成部署, 配置所需包一般和开发环境保持一致.

Running

这一步算是”月球的一小步”, 利用简单服务器启动命令: python manage.py runserver 检查应用本身是否存在问题,
最好进行适当的 API 调用, 如果直接运行测试用例那就更加完美.

否则, 该步骤积累的错误会影响后面的其他配置, 浪费配置时间.

Testing

在2.2节中已经说明, 每一个步骤的完成都需要一些测试以便支持该项”科学研究成果”, 不然 N 年之后有人质疑你当初的”登月事迹”就是扯淡,那不就 GG 了.

WSGI Server

Configure

Function: 该步骤的配置需要结合APP, 一般通过一个可配置的脚本(当然得你自己写啦)完成.

Reference: WSGI

Role: Web服务器端–Server/Gateway, 应用程序端–application/Framework

Running

正常情况下, 通过 WSGI Server启动 APP 时, Daemon进程以及衍生的线程都是直接跑在后台,
但是在”初始情况, 确定以及肯定有很多问题的时候”该情况就非常不利于环境的步骤.

修改配置, 让WSGI Server在前台运行并查看报错信息, 以便快速的调整配置.

Testing

测试是一个亘古不变的逻辑.

WEB Server

Configure

WEB Server, 或者静态服务器, 其本身可以完全独立存在(在 HTTP 协议层面), 在该步骤中, 应该将其与其他任何应用分离开来, 确保其本身的配置是正确的:

  • 简单配置
  • 从http->https的配置
  • 测试基本页面

Web Server仅仅作为内容的分发者.

Running

启动静态服务器并查看该SERVER 本身的日志信息

Testing

访问静态 URL 资源即可.

Join WEB Server with WSGI Server

Configure

这才是配置的重点, 比如 nginx配置

Running

测试启动运行

Testing

最后的总攻, “百万雄师过大江”.

Gateway Interface Example

CGI

CGI说明: CGI

Function: 1993年, 通用网关接口, 保证Web Server传递过来的数据是标准格式, 方便 CGI程序的编写者, 另见HTTP 权威指南.

Disadvantage: 针对每一个HTTP请求都fork一个新的进程来进行处理.

FastCGI

Function: FastCGI, CGI的加强版, 使用类似nginx的进程管理机制, 使用连续的进程(本身维护一个进程池)来处理一连串的请求.

PHP-FPM: 一个实现了FastCGI协议的程序, 被 PHP 官方支持(PHP原有的解释器为phpcgi, 使用 CGI 协议), 内置到 PHP 内核中. Php-fpm是用来管理fastcgi进程的.

Servlet[‘sɜːvlət]

Function: 运行在Java环境, 扩展 HTTP 协议的网关接口.

JSP: Java Server Page是HttpServlet的扩展, 使用HTML 的书写格式, 在适当的地方加入Java代码片段, 将后端从复杂的HTML 中解放, 专注于Servlet本身.

WSGI

Function: Web Server Gateway Interface, python环境.