我是靠谱客的博主 无聊大炮,最近开发中收集的这篇文章主要介绍Resin部署,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述


部署


OverView  概述
      Resin .war应用程序部署可以作为一个简单的.war 文件发布到  webapps/目录下在本机上,也能以作为云部署
存档,分段运输,反转,云部署,Resin云部署将分配一个新的web应用程序给所有在云的服务,使用了一个相互作用的
仓库以确保它的一致性,激活控制:部署和激活能够独立的管理,允许应用程序被部署和验证在所有的服务上
存档和反转:部署web应用可以被快速的存档和反转,当然如果部署需要被反转的话
分段运输:一个应用被部署到这个群作为一个视图显示。那么仅仅会作为一个预演的服务
graceful version upgrading:稳定的版本更新
 web应用程序版本部署,让那个当前用户继续带有老的版本并且可以转移到新的版本上
command-line:命名行
        web应用程序从命名行部署到云上
浏览:为了更加方便,应用也可以总一个浏览器使用resin-admin site进行部署

 


Basic Deployment Methods 基本的开发方式
     对于简单的部署,你可以复制一个包含你的应用程序的.war文件到webappls目录,Resin会去发现这个.war的存档文件
伸展它并开始服务请求
     
     这个webapps目录配置和使用根据resin.xml文件中的<web-app-deploy>标签
例如:在resin.xml的web-app-deploy
     <resin xmlns="
http://caucho.com/ns/resin">
  <cluster id="">
     ...
             <host id="">

                 <web-app-deploy path="webapps" expand-preserve-fileset="WEB-INF/work/**">

              </host> 
 </cluster> 
   
      <resin/>

expand-preserve-fileset 属性让你把保存文件为了以后的从新发布,并且可以提高重新开始的时间,一般来说
对于更新来说resin会删除所有的文件,包括被编译的jsp文件,迫使Resin重新编译JSP文件,甚至如果在更新中它们没有
被改变,如果你添加这个expand-preserve-fileset,当改变的时候Resin将只会重新编译这个JSP文件

 

Command-Line-Deployment 命名行部署
  命名行部署同样适用了resin.xml<web-app-deploy>配置作为一个webapps部署和扩展这个存档文件到同样的目录,替代了
在目录下寻找这个.war文件,Resin将会在内置的仓库中寻找适用这个web-app的标示符(identifier)

实例:命名行部署
  unix>bin/resin.sh deploy test.war
默认部署到默认的主机上,并且将war的name作为前缀(prefix)

 

命名行对比目录的优点 vs versus比,比较

 命名行部署优先于目录部署,因为一个部署到一个群,确保这个应用所有服务有同样版本,这意味着你不必从命名行部署一个
web-app,如果你决定去改变(从命名行到目录部署)
 
 案例:
     unix>bin/resin.sh undeploy test.war
     unix>cp test.war webapps

 


Cloud Deployment云部署

    当你使用命名行或者浏览器部署的时候,Resin部署一个web-application给所有服务在这个群中,这个过程(process)自动发生
并且不要求任何在ResinDe normal cluster以外的配置
    当你使用系统文件在webapps目录下配售一个.war,这个云部署不存在,云部署只能存在(occur)命名行和浏览器上
   
    Resin复制这个部署应用给所有的three triad servers,或者给所有可用的(available)服务,如果你至少有三个服务,任何服务超过
the triad 将会从这个traid复制这个部署应用,一般来说,这个triad你不需要去了解,除非为了至少去确保三个服务中的第一个是一直可用的

    当你添加一个新的动态(dynamic)服务或者重新开始一个服务,这个服务会检测这个traid,并且更新大部分最近复制的应用,这个系统是
可靠的(reliable可信赖的),如果服务crash(突然失败,倒闭),即使一个服务突然失败或者network(网络)outage(断供)发生在发布的时候,
自从部署相互作用,在服务器上新的版本只能当每一个文件被复制和验证的时候被激活
  

 

    Archiving(存档) and Rollback
    存档和反转


    Resin的部署支持存档和反转作为系统基本的(underlying)一部分,像 Subversion(颠覆) version(版本)管理系统(control system),你可以从一个应用复制便签
给一个唯一的名字,因此你可以permanently(永久的)保存你的webapp作为 “archive/webapp/foo/20105-19”,之后反转到那个版本,如果有这个必要的话
  
    部署系统每一个.war存档文件携带一个tag,一个部署应用可能看起来像 “production/webapp/myhost.com/my-app”,这个标签名是和WebApp的名字一样在这个Resin的日志中
存档一个应用,复制这个tag到一个存档名,就像"archive/webapp/my-app/2011-05-09"
    反转一个版本,只需要复制这个存档tag到这个web-app tag中
   
  案例:存档发布和更新  archive deply and update
      unix>bin/resin.sh deploy -stage archive -version 1.2.13 foo.war
Deployed archive/webapp/default/foo-1.2.13 from /tmp/caucho/qa/foo.war
to
http://127.0.0.1:8087/hmtp
     
      unix>bin/resin.sh deploy -copy
  -source-stage archive -source-version 1.2.13 -source foo
  -target foo

  存档war文件存放一个不同tag名,在先前的案例,这个仓库也许包含三个标签:存档 foo-1.2.12 存档 foo-1.2.13,和产品webapp,复制了foo-1.2.13
案例:对于存储的仓库标签
   archive/webapp/default/foo-1.2.12       ------存档foo.war内容
   archive/webapp/default/foo-1.2.13       ------存档foo.war内容
   production/webapp/default/too           ------生产 foo.war(是1.2.13的复制文件)

 
  当前web-app production/webapp-default/foo  被回滚复制从先前的版本
案例:rolling back to foo.1.2.12  回滚到foo.1.2.12
   unix>bin/resin.sh deploy-copy
     -source-stage archive -source-version 1.2.12 -source foo
     -target foo


   分段运输(staging)
   
      在进行一个部署之前作为一个最后的质量检查(quality check),你可以部署这个应用为一个分段运输 "preview(预展)"服务,在这个部署群,这个预展版本将只会显示在预展的是服务上
直到你复制它到一个可以用的机器上
      案例:发布一个预演舞台 deploying a preview stage
     unix>bin/resin.sh deploy -stage preview foo.war
     unix>bin/resin.sh -stage preview -server dynl -join -cluster app-tier start

  通常,Resin存储这个preview stage 作为一个仓库tag preview/webapp/default/foo,当你部署这个.war为stage preview的时候,Resin保存这个部署在这个preview(预展)tag名,当你开始Resin跟stage preview,
你请求它在预展环境标签寻找这个web-app

   案例:对于分段运输的仓库
       preview/webapp/default/foo    --preview foo.war content
       production/webapp/default/foo    --production foo.war contents

 在你已经验证这个预展应用工作之后,你可以部署它生产使用这个deploy-copy
   案例:deploying a preview as production
       unix>bin/resin.sh deploy-copy
           -source-stage preview -source foo
           -target foo

 


    Activating(活动的) deployed applications
    
    它们部署应用可以独立的活动,让你向云上传一个新的部署,然后一旦所有服务活动或者引起一个不稳定的激活
  
    默认,激活时自动的,当你的应用被部署,它自动的被激活,对于这个web-app-deploy你可以改变这个默认的行为去设置startup-mode 和
redeploy-mode
   
    startup-mode and redeploy modes    启动和重新部署的方式

 

 

versioning and Granceful Upgrades

     Resin会部署一个web-app同时多个版本,简化任意的版本升级,老版本的web-app将继续接收老版本,然而新版本将得到这个新的请求,所以任何用户将会看一个符合的版本作为这个web site更新
,这个版本需求<web-app-deploy>,i.e,它工作在webapps目录,版本是以数字为基础的,

 

 

     Deployment  Methods
Filesystem deployment:Custom web-app with .war file

     scenairo(描述,纲要),
    在这个方案中,你要配置一个web-app具有一个特定的root-directory和这个位置指定的.war文件,像往常一样,当Resin看到在这个.war文件中发现任何改变的时候,它就会去扩展延伸新的数据到这个roo-directory并且重新开始这个web-app,        
这种能力,给网站更多的灵活性


 

最后

以上就是无聊大炮为你收集整理的Resin部署的全部内容,希望文章能够帮你解决Resin部署所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(61)

评论列表共有 0 条评论

立即
投稿
返回
顶部