❶ linux部署web项目01 --创建创建用户
1.如果拿到的root 账号，应该先建立账户。因为在UNIX/Linux主机上，不要轻易使用root，权限太大，万一误操作不好修复
2.账户名称随意，UNIX/Linux的习惯，一般是专为应用开账户时，就用应用的名称或简称作为用户名
一：创建用户
1:查看系统版本，按照相应的版本做操作 我这是centos 所以cat /etc/redhat-release
顺便查看一下是不是x86_64 系统，这个就像window 32 和64一样
增加用户名为sucore用户：adser sucore
重置用户密码： passwd sucore
会让你输入俩次密码，跟其他创建密码一样，最后提示成功
注意：adser ,和 useradd 是一样的，只不过是有的发行版都有，有的发行版只有一个
然后是用户授权
用户授权在 sudoers 里面
有时候会找不到，就whereis sudoers查找一下 sudoers 文件位置
pwd 是查看当前你在哪个目录，cd ..是返回上一级目录
找到这个文件位置之后再查看权限：ls -l /etc/sudoers
找个这个文件，编辑 vim /etc/sudoers
但是如果第一个编辑错误，比如我第一个用这个可能会找不到怎么编辑等，出现错误。这时候就需要删除".sudoers.swp "的文件，把这个文件删除了，就是vi编辑了。但是如果你想找到这个问文件，你可以 whereis .sudoers.swp ,会告诉你文件位置，你就可以找到，
但如果你用ll ,或是ls 找到这个文件，你就会发现在xshell中看不见这个文件，因为linux凡是以“.”开头的文件都是隐藏文件，如果要用ls 看隐藏文件，需要用到选项a，就是ls -la 或者ls -a 都行。
直接rm就可以了，不过要加两个参数-rf 即：rm -rf 目录名字
-r 就是向下递归，不管有多少级目录，一并删除
-f 就是直接强行删除，不作任何提示的意思
wq 保存退出后，记得要将写权限收回，chmod -v u-w /etc/sudoers
❷ 如何搭建Web文件管理系统之elfinder
elfinder的安装极其的简易，只需要下载解压即可
将其解压放在服务器部署映射的目录下
将php文件夹下面的connector.minimal.php-dist重命名位connector.minimal.php
至此已经完成安装！
elfinder相关配置
(1)将默认语言设置位中文
引入js/i18n文件夹下的elfinder.zh_CN.js中文js文件即可，修改index.html【我将elfinder.html重命名位index.html】
<!-- elFinder translation (OPTIONAL) -->
//第一，引入elfinder.zh_CN.js文件。该处默认已经注释了
<script src="js/i18n/elfinder.zh_CN.js"></script>
<!-- elFinder initialization (REQUIRED) -->
<script type="text/javascript" charset="utf-8">
// Documentation for client options:
// https://github.com/Studio-42/elFinder/wiki/Client-configuration-options
$(document).ready(function() {
$('#elfinder').elfinder({
url : 'php/connector.minimal.php' // connector URL (REQUIRED)
, lang: 'zh_CN' // language (OPTIONAL)第二，默认已经注释了，语言选择说明
});
});
</script>
文／Alic灿（简书作者）
原文链接：http://www.jianshu.com/p/4ce6125434b3
着作权归作者所有，转载请联系作者获得授权，并标注“简书作者”。
❸ 如何在web服务器部署一个网站
1、双击IIS图标，运行IIS服务器。
❹ 一个Web应用部署到Tomcat服务器上之后的目录结构是怎样的
就是把你的Web-Root目录下的所有文件编译之后发布到Tomcat的webapps这个文件夹下面来了，其他的目录什么都不变的。项目src下面的java类文件会编译成为.class文件
❺ Java Web开发Tomcat中三种部署项目的方法
第一种方法 在tomcat中的conf目录中 在server xml中的 <host/>节点中添加
<Context path= /hello docBase= D:eclipse debug= privileged= true >
</Context>
至于Context 节点属性 可详细见相关文档
第二种方法 将web项目文件件拷贝到webapps 目录中
第三种方法 很灵活 在conf目录中 新建 Catalina（注意大小写）＼localhost目录 在该目录中新建一个xml文件 名字可以随意取 只要和当前文件中的文件名不重复就行了 该xml文件的内容为
<Context path= /hello docBase= D:eclipse debug= privileged= true >
</Context>
第 个方法有个优点 可以定义别名 服务器端运行的项目名称为path 外部访问的URL则使用XML的文件名 这个方法很方便的隐藏了项目的名称 对一些项目名称被固定不能更换 但外部访问时又想换个路径 非常有效
第 还有优点 可以定义一些个性配置 如数据源的配置等
还有一篇详细的
直接放到Webapps目录下
Tomcat的Webapps目录是Tomcat默认的应用目录 当服务器启动时 会加载所有这个目录下的应用 也可以将JSP程序打包成一个war包放在目录下 服务器会自动解开这个war包 并在这个目录下生成一个同名的文件夹 一个war包就是有特性格式的jar包 它是将一个Web程序的所有内容进行压缩得到 具体如何打包 可以使用许多开发工具的IDE环境 如Eclipse NetBeans ant JBuilder等 也可以用cmd 命令 jar cvf applicationname war package *
甚至可以在程序执行中打包
try{
string strjavahome = system getproperty（ java home ）
strjavahome = strjavahome substring（ strjavahome lastindexof（\））+ \bin\ ;
runtime getruntime（） exec（ cmd /c start +strjavahome+ jar cvf hello war c:\tomcat \webapps\root\* ）
}
catch（exception e）{system out println（e） }
webapps这个默认的应用目录也是可以改变 打开Tomcat的conf目录下的server xml文件 找到下面内容
<Host name= localhost debug= appBase= webapps unpackWARs= true autoDeloy= true xmlValidation= falase xmlNamespaceAware= false >
在server xml中指定
在Tomcat的配置文件中 一个Web应用就是一个特定的Context 可以通过在server xml中新建Context里部署一个JSP应用程序 打开server xml文件 在Host标签内建一个Context 内容如下
<Context path= /myapp reloadable= true docBase= D:myapp workDir= D:myappwork />
其中path是虚拟路径 docBase是JSP应用程序的物理路径 workDir是这个应用的工作目录 存放运行是生成的于这个应用相关的文件
创建一个Context文件
以上两种方法 Web应用被服务器加载后都会在Tomcat的confcatalinalocalhost目录下生成一个XML文件 其内容如下
<Context path= /admin docBase= ${catalina home}/server/webapps/admin debug= privileged= true ></Context>
可以看出 文件中描述一个应用程序的Context信息 其内容和server xml中的Context信息格式是一致的 文件名便是虚拟目录名 您可以直接建立这样的一个xml文件 放在Tomcat的confcatalinalocalhost目录下 例子如下
注意 删除一个Web应用同时也要删除webapps下相应的文件夹祸server xml中相应的Context 还要将Tomcat的conf
catalinalocalhost目录下相应的xml文件删除 否则Tomcat仍会岸配置去加载……
tomcat部署web应用主要有以下几种方式
）拷贝你的WAR文件或者你的web应用文件夹（包括该web的所有内容）到$CATALINA_BASE/webapps目录下
）为你的web服务建立一个只包括context内容的XML片断文件 并把该文件放到$CATALINA_BASE/webapps目录下 这个web应用本身可以存储在硬盘上的任何地方 这种context片断提供了一种便利的方法来部署web应用 你不需要编辑server xml 除非你想改变缺省的部署特性 安装一个新的web应用时不需要重启动Tomcat
）同方法 只是将context片断放在CATALINA_BASEconfCatalinalocalhost目录下 这种方法比方法 >要有效 笔者经过多次实验发现方法 不如后面这种方法好用 前者多次出现系统打不开的情况
）直接在server xml中</Host>前加上Context片断 使用这种方法时 tomcat会自动在CATALINA_BASEconfCatalinalocalhost目录下生成一个文件片断 方法同方法 具有同样效果 这种方式需要将ROOT目录删除才行
另外 为了让tomcat只运行conf/server xml中指定的web应用 可以有以下几种办法
实现一
）将要部署的WEB应用放在webapps以外的路径 并在server xml相应的context中的docBase指定
）删除webapps中的所有文件夹 以及conf/catalina/localhost下所有xml文件
注 webapps是server xml中的Host元素的appBase属性的值
实现二
）修改server xml中Host元素的属性 添加或修改 deployXML= false deployOnStartup= false autoDeploy= false
）含义
lishixin/Article/program/Java/ky/201311/28718
❻ web前端项目部署到服务器：
执行成功后会生成dist文件
4.1 进入到nginx配置目录：/usr/local/nginx/conf,对 nginx.conf 文件进行配置
使用include可以配置多个.conf文件，如一个项目一个配置文件。在同目录下创建demo文件夹，并创建demo.conf配置文件
下面使用是以ip地址的方式创建的的配置文件
访问地址：
其中dist名称时可以修改，保持与/usr/local/nginx/html下cp名称一致，否则会访问不到;并且/usr/local/nginx/html目录可存在同一ip下多个web项目。
域名与ip绑定
配置域名demo.conf
eg: 域名 - demo.cn
4.2阿里云配置域名前缀
阿里云->域名->域名列表—>域名 管理-> 域名解析->解析设置
如图：记录值 填写当前服务ip
学习过程中所记录，有问题或者有好的方式欢迎指点。不胜感激 🤗 🤗 🤗
❼ eclipse WEB项目开发时，项目文件组织结构是怎样的
按照 Java EE 规范的规定，一个典型的 Web 应用程序有四个部分：
1. 公开目录 ;
2. WEB-INF/web.xml 文件，发布描述符（必选） ;
3. WEB-INF/classes 目录，编译后的 Java类文件（可选） ;
4. WEB-INF/lib 目录，Java类库文件（*.jar） （可选） ;
公开目录存放所有可以被用户的访问的资源, 包括 .html, .jsp, .gif, .jpg, .css, .js, .swf 等等。
WEB-INF 目录是一个专用区域, 容器不能把此目录中的内容提供给用户。
这个目录下的文件只供容器使用，里面包含不应该由客户直接下载的资源，
例如： Servlet(这些组件包括应用程序逻辑以及对其他资源如数据库的可能访问), Web应用程序中servlet可直接访问的其他任何文件，在服务器方运行或者使用的资源(如 Java类文件和供 servlet 使用的 JAR文件)，由您的应用程序生成的临时文件,，发布描述符以及其它任何配置文件。
这些资源是专用的， 因此只能由它们自己的 Web应用程序及容器访问。
特别地，JSP/Servlet 程序文件也能通过 ServletContext 访问到这个目录下的文件，
例如 JSP 中可以通过application.getRealPath(“/WEB-INF/web.xml”) 访问到发布描述符文件的路径。
Web容器要求在你的应用程序中必须有 WEB-INF 目录。
注意： 如果你的 Web 应用程序中没有包含这个目录, 它可能将无法工作
WEB-INF 中包含着发布描述符, 一个 classes 目录和一个 lib目录, 以及其它内容。
发布描述符(deployment descriptors)是 J2EE Web 应用程序不可分割的一部分(也就是说是它的最小部分, 必不可缺的一部分)。
它们在应用程序发布之后帮助管理 Web 应用程序的配置。
对于Web 容器而言, 发布描述符是一个名为 web.xml 的 XML 文件, 存储在 Web 应用程序的 /WEB-INF目录下。
发布描述符有多种用途：
• 为 Servlet 和 Web 应用程序提供初始化参数 这使我们的Web应用程序中的硬性编写的代码的初始化值更少。 例如常见的 <param-name>, <param-value>标记, 就可以为Servlet 提供参数, 这个参数可以在 init() 方法中加载。
Struts 的 ActionServlet 也是通过这种方式来找到它们需要的配置文件 struts-config.xml 的位置, 从而加载并分析它,来初始化 Struts 框架用到的各种 FromBean, Action, Forward等。
• Servlet/JSP 定义 可以为 Web 应用程序中的每个 Servlet 或者预编译的 JSP 网页提供定义。
包括Servlet/JSP的名字, Servlet/JSP 的类以及一个可选的描述。
• Servlet/JSP 映射 Web容器使用这些信息把进入请求映射到 servlet 和 JSP 网页。
• MIME类型 由于每个 Web 应用程序可以包含多种内容类型, 因此我们可以在发布描述符中为每一种类型指定 MIME 类型。
• 安全性 我们可以使用发布描述符来管理应用程序的访问控制。 例如, 可以指定我们的Web应用程序是否需要登录, 如果需要的话, 应该使用什么登录页面, 以及用户会作为何种角色。
发布描述符还可以用来自定义其他元素, 包括欢迎网页, 出错网页, 会话配置等等。
classes 目录用于存储编译过的 servlet 及其它程序类, 例如 JavaBean。
如果一个程序有打包的 JAR 文件(例如一个第三方 API 打包成了一个 JAR 文件, 如 Struts 框架的类库struts.jar, Mysql 的数据库 JDBC 驱动程序文件 mysql-connector-java-3.1.11-bin.jar 等),
那么它们可以被复制到lib目录中(如果解压缩这些压缩包的话, 请将它们复制到classes目录中)。
Web 容器使用这两个目录来查找 servlet 及其他相关类, 也就是说, 容器的类装入器会自动查看 classes 目录, 以及 lib目录下的 JAR文件。
这就意味着你不需要明确的把这些类和 JAR文件添加到 CLASSPATH中。
Web容器自动将这两个目录中的文件加入 Web应用的类路径中。
❽ python web 怎么部署
学过PHP的都了解，php的正式环境部署非常简单，改几个文件就OK，用FastCgi方式也是分分钟的事情。相比起来，Python在web应用上的部署就繁杂的多，主要是工具繁多，主流服务器支持不足，在了解Python的生产环境部署方式之前，先明确一些概念！很重要！
CGI：
CGI即通用网关接口(Common Gateway Interface)，是外部应用程序（CGI程序）与Web服务器之间的接口标准，是在CGI程序和Web服务器之间传递信息的规程。CGI规范允许Web服务器执行外部程序，并将它们的输出发送给Web浏览器，CGI将Web的一组简单的静态超媒体文档变成一个完整的新的交互式媒体。通俗的讲CGI就像是一座桥，把网页和WEB服务器中的执行程序连接起来，它把HTML接收的指令传递给服务器的执行程序，再把服务器执行程序的结果返还给HTML页。CGI的跨平台性能极佳，几乎可以在任何操作系统上实现。
CGI方式在遇到连接请求（用户请求）先要创建cgi的子进程，激活一个CGI进程，然后处理请求，处理完后结束这个子进程。这就是fork-and-execute模式。所以用cgi方式的服务器有多少连接请求就会有多少cgi子进程，子进程反复加载是cgi性能低下的主要原因。当用户请求数量非常多时，会大量挤占系统的资源如内存，CPU时间等，造成效能低下。
CGI脚本工作流程：
浏览器通过HTML表单或超链接请求指向一个CGI应用程序的URL。
服务器执行务器收发到请求。所指定的CGI应用程序。
CGI应用程序执行所需要的操作，通常是基于浏览者输入的内容。
CGI应用程序把结果格式化为网络服务器和浏览器能够理解的文档（通常是HTML网页）。
网络服务器把结果返回到浏览器中。
Web Server启动时载入FastCGI进程管理器（PHP-CGI或者PHP-FPM或者spawn-cgi)
FastCGI进程管理器自身初始化，启动多个CGI解释器进程(可见多个php-cgi)并等待来自Web Server的连接。
当客户端请求到达Web Server时，FastCGI进程管理器选择并连接到一个CGI解释器。Web server将CGI环境变量和标准输入发送到FastCGI子进程php-cgi。
FastCGI子进程完成处理后将标准输出和错误信息从同一连接返回Web Server。当FastCGI子进程关闭连接时，请求便告处理完成。FastCGI子进程接着等待并处理来自FastCGI进程管理器(运行在Web Server中)的下一个连接。 在CGI模式中，php-cgi在此便退出。
打破传统页面处理技术。传统的页面处理技术，程序必须与 Web 服务器或 Application 服务器处于同一台服务器中。这种历史已经早N年被FastCGI技术所打破，FastCGI技术的应用程序可以被安装在服务器群中的任何一台服务器，而通过 TCP/IP 协议与 Web 服务器通讯，这样做既适合开发大型分布式 Web 群，也适合高效数据库控制。
明确的请求模式。CGI 技术没有一个明确的角色，在 FastCGI 程序中，程序被赋予明确的角色（响应器角色、认证器角色、过滤器角色）。
重写环境变量后，根据目标URL，将请求消息路由到不同的应用对象。
允许在一个进程中同时运行多个应用程序或应用框架。
负载均衡和远程处理，通过在网络上转发请求和响应消息。
进行内容后处理，例如应用XSLT样式表。
超快的性能。
低内存占用（实测为apache2的mod_wsgi的一半左右）。
多app管理。
详尽的日志功能（可以用来分析app性能和瓶颈）。
高度可定制（内存大小限制，服务一定次数后重启等）。
python有cgi模块可支持原生cgi程序
FastCGI：
FastCGI是一个可伸缩地、高速地在HTTP server和动态脚本语言间通信的接口。多数流行的HTTP server都支持FastCGI，包括Apache、Nginx和lighttpd等，同时，FastCGI也被许多脚本语言所支持，其中就有Python。FastCGI是从CGI发展改进而来的。传统CGI接口方式的主要缺点是性能很差，因为每次HTTP服务器遇到动态程序时都需要重新启动脚本解析器来执行解析，然后结果被返回给HTTP服务器。这在处理高并发访问时，几乎是不可用的。FastCGI像是一个常驻(long-live)型的CGI，它可以一直执行着，只要激活后，不会每次都要花费时间去fork一次(这是CGI最为人诟病的fork-and-execute 模式)。CGI 就是所谓的短生存期应用程序，FastCGI 就是所谓的长生存期应用程序。由于 FastCGI 程序并不需要不断的产生新进程，可以大大降低服务器的压力并且产生较高的应用效率。它的速度效率最少要比CGI 技术提高 5 倍以上。它还支持分布式的运算, 即 FastCGI 程序可以在网站服务器以外的主机上执行并且接受来自其它网站服务器来的请求。
FastCGI是语言无关的、可伸缩架构的CGI开放扩展，其主要行为是将CGI解释器进程保持在内存中并因此获得较高的性能。众所周知，CGI解释器的反复加载是CGI性能低下的主要原因，如果CGI解释器保持在内存中并接受FastCGI进程管理器调度，则可以提供良好的性能、伸缩性、Fail-Over特性等等。FastCGI接口方式采用C/S结构，可以将HTTP服务器和脚本解析服务器分开，同时在脚本解析服务器上启动一个或者多个脚本解析守护进程。当HTTP服务器每次遇到动态程序时，可以将其直接交付给FastCGI进程来执行，然后将得到的结果返回给浏览器。这种方式可以让HTTP服务器专一地处理静态请求或者将动态脚本服务器的结果返回给客户端，这在很大程度上提高了整个应用系统的性能。
FastCGI的工作流程:
FastCGI 的特点：
WSGI：
PythonWeb服务器网关接口（Python Web Server Gateway Interface，缩写为WSGI）是为Python语言定义的Web服务器和Web应用程序或框架之间的一种简单而通用的接口。自从WSGI被开发出来以后，许多其它语言中也出现了类似接口。WSGI是作为Web服务器与Web应用程序或应用框架之间的一种低级别的接口，以提升可移植Web应用开发的共同点。WSGI是基于现存的CGI标准而设计的。
WSGI区分为两个部份：一为“服务器”或“网关”，另一为“应用程序”或“应用框架”。在处理一个WSGI请求时，服务器会为应用程序提供环境上下文及一个回调函数（Callback Function）。当应用程序完成处理请求后，透过先前的回调函数，将结果回传给服务器。所谓的 WSGI 中间件同时实现了API的两方，因此可以在WSGI服务和WSGI应用之间起调解作用：从WSGI服务器的角度来说，中间件扮演应用程序，而从应用程序的角度来说，中间件扮演服务器。“中间件”组件可以执行以下功能：
以前，如何选择合适的Web应用程序框架成为困扰Python初学者的一个问题，这是因为，一般而言，Web应用框架的选择将限制可用的Web服务器的选择，反之亦然。那时的Python应用程序通常是为CGI，FastCGI，mod_python中的一个而设计，甚至是为特定Web服务器的自定义的API接口而设计的。WSGI没有官方的实现, 因为WSGI更像一个协议。只要遵照这些协议,WSGI应用(Application)都可以在任何服务器(Server)上运行, 反之亦然。WSGI就是Python的CGI包装，相对于Fastcgi是PHP的CGI包装。
WSGI将 web 组件分为三类： web服务器，web中间件,web应用程序， wsgi基本处理模式为 ： WSGI Server -> (WSGI Middleware)* -> WSGI Application 。
uwsgi：
uwsgi协议是一个uWSGI服务器自有的协议，它用于定义传输信息的类型（type of information），每一个uwsgi packet前4byte为传输信息类型描述，它与WSGI相比是两样东西。据称其效率是fcgi的10倍。具体的协议内容请参考：the uwsgi protocol
以上四者都可以理解为协议！协议！协议！实现了这样的协议，就可以实现Web服务器与Web应用程序相关联的web服务！
uWSGI：
uWSGI项目旨在为部署分布式集群的网络应用开发一套完整的解决方案。uWSGI主要面向web及其标准服务，已经成功的应用于多种不同的语言。由于uWSGI的可扩展架构，它能够被无限制的扩展用来支持更多的平台和语言。目前，你可以使用C，C++和Objective-C来编写插件。项目名称中的“WSGI”是为了向同名的Python Web标准表示感谢，因为WSGI为该项目开发了第一个插件。uWSGI是一个Web服务器，它实现了WSGI协议、uwsgi、http等协议。uWSGI，既不用wsgi协议也不用FastCGI协议，而是自创了上文说将的uwsgi协议。
uWSGI的主要特点如下：
Gunicorn：
和uWSGi类似的工具，从rails的部署工具(Unicorn)移植过来的。但是它使用的协议是前文所讲的WSGI，这是python2.5时定义的官方标准(PEP 333)，根红苗正，而且部署比较简单，详细的使用教程请点击这里。Gunicorn采用prefork模式，Gunicorn 服务器与各种 Web 框架兼容，只需非常简单的执行，轻量级的资源消耗，以及相当迅速。它的特点是与 Django 结合紧密，部署特别方便。 缺点也很多，不支持 HTTP 1.1，并发访问性能不高，与 uWSGI，Gevent 等有一定的性能差距。
1. Gunicorn设计
Gunicorn 是一个 master进程，spawn 出数个工作进程的 web 服务器。master 进程控制工作进程的产生与消亡，工作进程只需要接受请求并且处理。这样分离的方式使得 reload 代码非常方便，也很容易增加或减少工作进程。 工作进程这块作者给了很大的扩展余地，它可以支持不同的IO方式，如 Gevent,Sync 同步进程，Asyc 异步进程，Eventlet 等等。master 跟 worker 进程完全分离，使得 Gunicorn 实质上就是一个控制进程的服务。
2. Gunicorn源码结构
从 Application.run() 开始，首先初始化配置，从文件读取，终端读取等等方式完成 configurate。然后启动 Arbiter，Arbiter 是实质上的 master 进程的核心，它首先从配置类中读取并设置，然后初始化信号处理函数，建立 socket。然后就是开始 spawn 工作进程，根据配置的工作进程数进行 spawn。然后就进入了轮询状态，收到信号，处理信号然后继续。这里唤醒进程的方式是建立一个 PIPE，通过信号处理函数往 pipe 里 write，然后 master 从 select.select() 中唤醒。
工作进程在 spawn 后，开始初始化，然后同样对信号进行处理，并且开始轮询，处理 HTTP 请求，调用 WSGI 的应用端，得到 resopnse 返回。然后继续。
Sync 同步进程的好处在于每个 request 都是分离的，每个 request 失败都不会影响其他 request，但这样导致了性能上的瓶颈。
Tornado：
Tornado即使一款python 的开发框架，也是一个异步非阻塞的http服务器，它本身的数据产出实现没有遵从上文所说的一些通用协议，因为自身就是web服务器，所以动态请求就直接通过内部的机制，输出成用户所请求的动态内容。如果把它作为一个单独服务器，想用它来配合其他的框架如Flask来部署，则需要采用WSGI协议，Tornado内置了该协议，tornado.wsgi.WSGIContainer。
wsgiref：
Python自带的实现了WSGI协议的的wsgi server。wsgi server可以理解为一个符合wsgi规范的web server，接收request请求，封装一系列环境变量，按照wsgi规范调用注册的wsgi app，最后将response返回给客户端。Django的自带服务器就是它了。
以上都可以理解为实现！实现！实现！实现了协议的工具！
注：mod_wsgi（apache的模块）其实也是实现了wsgi协议的一个模块，现在几乎不废弃了，所以也不多说了，感兴趣的自己查一下吧。
所以如果你采用Django框架开发了应用之后，想部署到生产环境，肯定不能用Django自带的，可以用使用uwsgi协议的uWSGI服务器，也可以采用实现了WSGI协议的gunicorn或者Tornado，亦可以用FastCGI、CGI模式的Nginx、lighttpd、apache服务器。其他框架亦如此！明白了这些概念在部署的时候就可以做到心中有数，各种工具之间的搭配也就“知其然，并知其所以然”了。
在我们组的项目中有两种框架Django和Tornado，生产环境也用到了两种部署方式。uWSGI和Gunicorn：
Django项目用Nginx+uWSGI方式部署，Tornado项目用Nginx+Gunicorn方式部署：
Nginx都作为负载均衡以及静态内容转发。Tornado项目用supervisord来管理Gunicorn，用Gunicorn管理Tornado。众所周知，由于Python的GIL存在，所以Python的并发都采用多进程模式，所以我们部署的方式是一个核心两个进程。
❾ 怎么将web应用部署到tomcat中，tomcat是否需要配置环境变量
Tomcat部署Web应用方法总结
在Tomcat中部署Java Web应用程序有两种方式：静态部署和动态部署。
在下文中$CATALINA_HOME指的是Tomcat根目录。
一、静态部署
静态部署指的是我们在服务器启动之前部署我们的程序，只有当服务器启动之后，我们的Web应用程序才能访问。
以下3种方式都可以部署：（以PetWeb项目为例说明，PetWeb目录假设是F:/PetWeb）
1.利用Tomcat自动部署
将PetWeb目录拷贝到$CATALINA_HOME/webapps下，然后启动服务器就可以了，Tomcat启动时将自动加载应用。
访问地址如下：http://localhost:8080/PetWeb/
这种方式比较简单，但是web应用程序必须在webapps目录下。Tomcat的Webapps目录是Tomcat默认的应用目录，当服务器启动时，会加载所有这个目录下的应用。
2.修改Server.xml文件部署
这种方式可以不必将PetWeb目录拷贝到webapps下，直接在F:/部署。方法如下，更改$CATALINA_HOME/conf/server.xml文件，
找到以下内容：
Xml代码：
1. <Context path
="/Pet" reloadable ="false" docBase
="F:/PetWeb" workDir ="d:/Mywebapps/emp" />
path：是访问时的根地址，表示访问的路径；如上述例子中，访问该应用程序地址如下：http://localhost:8080/Pet/
reloadable：表示可以在运行时在classes与lib文件夹下自动加载类包。其中reloadable="false"表示当应用程序中的内容发生更改之后服务器不会自动加载，这个属性在开发阶段通常都设为true，方便开发，在发布阶段应该设置为false，提高应用程序的访问速度。
docbase：表示应用程序的路径，注意斜杠的方向“/”。
docBase可以使用绝对路径，也可以使用相对路径，相对路径相对于webapps。
workdir：表示缓存文件的放置地址
3.增加自定义web部署文件(推荐使用，不需要重启Tomcat
)
这种方式和方法2差不多，但不是在Server.xml文件中添加Context标签，而是在$CATALINA_HOME/conf/Catalina/localhost中添加一个xml文件，如Pet.xml.在Tomcat安装目录conf/Catalina
/localhost下，里面有Tomcat自带的三个应用，随意复制其中的一个XML文件，然后修改docbase指向你自己的应用程序，并把文件名改名，各参数参见方法2中的<Context>标签的参数，或者你也可以自己新建一个XML文件。(注意此文件名将作为Context中的path属性值,不管文件里的path属性值如何设置也是无效的
)，将以下内容复制过去，修改相应路径即可。
Xml代码：
1. <Context path
="/Pet" docBase ="F:/PetWeb"
2. debug ="0"
privileged ="true" reloadable ="false"
>
3. </Context>
访问地址如下：http://localhost:8080/Pet/
注： Web应用以.war文件的形式部署
可以将JSP程序打包成一个war包放在目录下，服务器会自动解开这个war包，并在这个目录下生成一个同名的文件夹。一个war包就是有特性格式的jar包，它是将一个Web程序的所有内容进行压缩得到。
我们刚才是将PetWeb文件夹部署在了服务器中，我们知道可以将Web应用程序的内容打成.war包，然后在部署在服务器上。打包请参考如下步骤：
1、打开命令提示符（cmd）
2、设置jdk环境变量
3、在命令提示符中进入项目文件夹F:/PetWeb后，键入如下命令：jar cvfPet.war */ .
（注意最后有个“. ”）。这样在F:/PetWeb下应该有Pet.war文件。（也可以打包到指定的地方，命令如下：jar
cvf d:/Pet.war */.）
部署Pet.war文件非常简单，将刚才xml文件中的docBase
="F:/PetWeb"更改为docBase ="F:/Pet.war"或者直接将其拷贝到webapps目录下就可以。然后重新启动服务器就可以将Pet.war部署为一个Web应用程序了。
如果你够细心的话你会发现，服务器将Pet.war文件解开，并且在webapps下面又生成了一个Pet文件夹，然后把Pet.war的内容拷贝到里面去了。我们可以通过以下方式取消自动解压缩，将xml配置文件中的unpackWAR属性设置为"false"
即可。
二、动态部署
动态部署是指可以在服务器启动之后部署web应用程序，而不用重新启动服务器。动态部署要用到服务器提供的manager.war文件，如果在$CATALINA_HOME/webapps/下没有该文件，你必须去重新下载tomcat，否则不能完成以下的功能。要想使用该管理程序必须首先编辑$CATALINA_HOME/conf/tomcat-users.xml文件，内容如下：（关于这个文件的更多内容，请参考
Java Web应用程序的安全模型二）
<tomcat-users>
<role rolename="tomcat"/>
<role rolename="role1"/>
<role rolename="manager"/>
<user username="coresun" password="coresun"roles="manager"/>
<user username="tomcat" password="tomcat"roles="tomcat"/>
<user username="both" password="tomcat"roles="tomcat,role1"/>
<user username="role1" password="tomcat"roles="role1"/>
</tomcat-users>
然后在浏览器中键入如下地址：http://localhost:8080/
，应该看到一个加菲猫了吧。点击左边的Tomcat Manager链接，提示输入用户名和密码，本文都是coresun，然后可以看到以下页面：
(1)Context Path(option):中输入/Pet
(2)XML Configration file URL中要指定一个.xml文件，比如我们在F:/下建立一个Pet.xml文件，内容如下：<Context reloadable
="false" / >。docBase不用写了，因为要在下一个文本框中填入。或者更简单点，这个文本框什么都不填。
(3)WAR or Directory URL:中键入F:/PetWet或者F:/Pet.war都可以，然后点击Deploy按钮，看看上面是不是已经看到了你web应用程序，名字就是你ContextPath(option):中的名字。
(4)如果你部署.war文件还有更加简单的方式，下面还有个Select WAR file upload点击浏览选择.war文件，然后点击Deploy也可以。
让tomcat只运行conf/server.xml中指定的web应用
可以有以下2种办法：
实现一:
1)将要部署的WEB应用放在webapps以外的路径,
并在server.xml相应的Context 中的docBase指定.
2)删除webapps中的所有文件夹,
以及conf/catalina/localhost下所有xml文件.
注: webapps是server.xml中的Host 元素的appBase属性的值.
实现二:
修改server.xml中Host 元素的属性,
添加或修改:
deployXML ="false"
deployOnStartup ="false"
autoDeploy ="false"
含义:
deployXML ="false"
: 不部署conf/catalina/localhost下的xml相应的WEB应用
deployOnStartup ="false"
:tomcat启动时,
不部署webapps下的所有web应用
autoDeploy ="false"
:避免tomcat在扫描改动时,
再次把webapps下的web应用给部署进来.
注：
Tomcat中webapps目录下不能直接存放网页格式的文件，否则无法访问到该文件，必须有子目录才能访问该网页文件。
例如：我们直接将index.html放在webapps目录中，通过浏览器http://localhost:8080/index.html是无法访问到index.html的。而必须要webapps/petweb/index.html才可以通过http://localhost:8080/petweb/index.html访问到index.html页面。