❶ 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頁面。