如何使用 phusion passenger

Phusion Passenger是一个流行的Web应用服务器，它最初是针对Ruby的，现在也支持Node.js应用。在今年的早些时候该功能被引入了Passenger的企业版中，但是现在已经开源并随着最近的4.0.21免费版发布。

创新互联是一家集网站建设,偏关企业网站建设,偏关品牌网站建设,网站定制,偏关网站建设报价,网络营销,网络优化,偏关网站推广为一体的创新建站企业，帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿，时刻以成就客户成长自我，坚持不断学习、思考、沉淀、净化自己，让我们为更多的企业打造出实用型网站。

Passenger能与Apache或者Nginx Web服务器集成，旨在成为一个服务、监控和扩展Web应用程序的完整解决方案。Phusion公司的 总部位于荷兰 ，他们宣称在Passenger中运行 Node.js 应用的好处包括：

多租户——通过最小的配置运行一些应用的能力

监控——自动启动Node.js进程、如果进程崩溃了则重启它们

扩展——根据要处理的请求的数量增加或者减少进程的数量

统计——帮助显示运行中进程的状态的工具

Passenger的作者 还指出 ，与Apache/Nginx集成还带来了其他的好处，例如：加速了静态文件服务，阻止了很多常见的攻击和慢客户端。

该公告标志着Phusion向自己宣称的让Passenger最终成为一个多语言应用服务器的目标更进了一步。去年，Passenger对 Python的支持到达了beta状态 ，并于最近完成。紧跟着发布了支持Node.js的公告，Phusion还 推出 了 Meteor （一个基于Node的应用框架）支持。

Passenger本身是用C++编写的，它没有和Ruby或者任何其他的语言紧耦合。版本4中的一些架构发生了一些变化。Passenger内部的I/O处理器现在是事件驱动的，和Node.js的工作原理相似，同时企业版支持混合多进程和多线程执行，这是为了在支持通过WebSockets进行流媒体直播这样的功能时最大化资源利用率。

Passenger还为Ruby应用提供了“带外（out of band）”执行这样的功能，用户能够利用它们做其他的事情，例如：将垃圾收集延迟到请求期间，与Phusion的 Union Station产品 （一个订阅式应用监控和分析服务）集成。

在流行的Ruby应用服务器中，Puma和Passenger相似，它们都喜欢使用线程而不是Thin和Unicom这样的服务器所使用的事件架构。Phusion团队最近发布了 一篇文章比较了Passenger和Puma ，而Puma的作者Evan Phoenix则在HackerNews上对此 做出了回应 。

InfoQ和Phusion的CTO Hongli Lai进行了一次谈话以讨论Passenger最近的更新：

Passenger 为 Ruby 用户提供了不寻常的特性，例如带外执行，它和语言运行时紧密集成。那么对于 Node.js 和 Python 用户而言有相似的功能么？

大部分功能所有支持的语言都可以使用，包括Node.js和Python。从第一天开始，我们就一直在尽量减少对Ruby的依赖。虽然我们并没有积极的推广，但是事实是在第一个版本发布几个月之后我们就已经支持Python。 我们现在还计划在下一次发布时支持 Meteor 。

Node.js和Python不能使用的功能只有很少几个，或者是因为它们对这些语言没有意义，或者是因为它们需要简单的语言特定的支持代码，而这些代码还没有被编写。Node和Python的垃圾收集器通常并不会忍受像Ruby那样的长时间的GC暂停，所以我们期望Node.js和Python用户不需要带外工作。

你认为现在的 Node.js 支持有多稳定？

我们认为它非常稳定。所有的应用程序测试都通过了，所有测试人员的应用程序都工作良好且没有已知的问题。

Passenger 最初的目标是让 Ruby 部署和 PHP 部署一样简单，仅需要用户将他们的应用丢放到正确的目录即可。你认为 Passenger 现在已经完成这一目标了么？

部署一个应用涉及到很多事情，从操作系统和语言运行时的配置到类库依赖的管理和应用程序进程的监控。PHP的部署之所以容易的原因之一是，Web服务器能够通过mod_php模块自动地处理运行的PHP应用程序。

在最初开发Passenger的时候，我们的主要计划是运行、监控和管理Ruby应用程序。你必须运行多个应用程序服务器进程，让它们监听一个本地socket，设置Web服务器反向代理这簇sockets，并且设置进程监控工具重启崩溃的进程。而在Passenger中，我们开发了一个类似于mod_php的机制解决了这些问题。因此在版本1.0中我们已经实现了自己的目标：通过将一个Ruby应用程序丢放到正确的目录运行它。

PHP生态系统依然被认为更容易部署的原因是，许多流行的PHP应用程序能自动地处理除了应用程序运行之外的其他事情。例如， Wordpress 没有依赖，不需要用户编辑配置文件或者通过漂亮的图形用户界面征求数据库凭证。但是如果你编写自己的PHP应用，那么你将会遇到和Ruby、Node或者Python应用开发人员相同的问题。

有没有托管公司真正地提供开箱即用的 Passenger 支持？

提供开箱即用的Passenger支持的知名托管公司有 Amazon Elastic Beanstalk 和Red Hat OpenShift 。许多其他的提供商（例如 Heroku ）对应用程序服务器的选择往往不可知，但是它们依然允许用户很容易地使用Passenger。还有很多较小的托管公司默认使用Passenger，例如 BrightBox 和 SpeedyRails 。

在 Ruby 应用程序服务器领域有一些强有力的竞争者（ Thin 、 Unicorn 和 Puma ）。那么你认为目前 Passenger 在这个生态系统中处于什么位置？

其他的Ruby应用程序服务器比Passenger有更多的范围限制。它们需要用户启动一个或者多个进程，将它们设置为监听sockets，配置反向代理规则等。对于想要严格控制整个系统的专家而言这并不一定是错误的方法，但是却不同于我们的哲学。我们希望软件易于安装、使用和管理，同时依然可以保持稳定性和灵活性。

但是话说回来，我们都互相学习了很多内容。例如，Passenger的“智能产卵（smart spawning）”功能在日期上要早于Unicorn，但是Passenger的带外工作功能借鉴了Unicorn的，尽管我们对该功能做了改进。每一种服务器都有它自己的优势和劣势。

转载

如何理解LXC与Docker之间的主要区别

Docker不是lxc的一个替代方案。“lxc”是指linux内核（尤指命名空间以及Cgroup）的一个特性，它允许其他一些沙盒进程运行在一块相对独立的空间，并且能够方便的控制他们的资源调度。而基于底层的内核特性的基础上，Docker在上层构建了一个更高层次的具备多个强大功能的工具集：可移植的跨机器部署。Docker定义了一个将应用打包的规范，而它的所有依赖都被封装到了一个简单对象里，它可以被传输到任意一台能运行Docker的机器，并且在这里启动Docker的实例之后，它能够确保承载应用的执行环境将会与之前所定义的完全一致。Lxc实现了进程级的沙盒封装，它是可移植部署的一个重要前提，但是要想实现可移植部署，仅仅是这样可还不够。如果你发送给我一份安装到一个自定义LXC配置下的应用副本，那么几乎可以肯定的是，它在我的机器上运行的结果不会跟你的完全一样，因为它绑定了你机器的一些特殊配置：网络，存储，日志，Linux发行版本等等。Docker为这些机器的特定配置定义了一个抽象层，所以它使得这些相同的Docker容器能够一成不变的运行在多个不同的主机上，甚至带上各种不同的配置。以应用为中心。相对于机器而言，Docker被用于优化应用的部署过程。这可以从它的API，UI，设计理念还有文档里得到体现。反之，lxc的辅助脚本专注在把容器作为一个轻量级的机器使用——基本上就是一堆启动更快并且内存需求更小的服务器。我们认为容器技术的内容远远不止这些。自动构建。Docker为开发人员引入了一个可以用来把他们的源代码自动打包到容器里的工具，并且他们能够对于应用的依赖，构建工具，打包服务等有着完全的自主掌控能力。他们能够自由的使用make，maven，chef，puppet，salt，debian包，rpm包，源码包，或者任意以上的结合，而无需关心机器本身的配置。版本化。Docker引入了一个类似git的特性来完成一个容器的连续版本追踪，版本之间的差异diff，新的版本的提交，回滚等。历史记录信息里也包含了容器的用户信息以及他是如何构建它的，因此生产环境的服务器你都有充足的手段去一步步的定位到最上游的开发人员。Docker也实现了一个增量上传和下载功能，类似于gitpull，所以更换到新版本的容器只需要传输增量部分就行。组件的重用。任意容器都能用作“基础镜像”来创建更特定的组件。这可以手工完成也可以做成自动构建的一部分。例如，你可以准备一个理想的python环境，并且把它用作10个不同的应用的基础镜像。你所定义的标准postgresql设置可以被将来你手上的所有项目重用。诸如此类。共享。Docker有权访问一个公共的注册中心（/）而这里有数以千计的业界人士上传各种各样有价值的容器：任一从redis，couchdb，postgres到ircbouncers再到rails应用服务器，Hadoop甚至是多个发行版本的基础镜像。该注册中心也包含了一个官方的“标准库”，这里提供了一些由Docker官方团队维护的实用容器。注册中心本身也是开源的，所以任何人都能部署他们自己的私有注册中心来存储和下发私有容器，例如用于内网服务器的部署。工具生态圈。Docker定义了一个API来自动化和个性化的创建和部署容器。也因此催生了众多的工具集成到Docker，为之提供一些扩展特性。类PaaS的部署（Dokku，Deis，Flynn），多节点编排（maestro,salt,mesos,openstacknova），管理看板（docker-ui,openstackhorizon,shipyard），配置管理（chef,puppet)，持续集成（jenkins,strider,travis）等等。Docker正在迅速的建立以它本身为标准的基于容器的工具生态圈。

如何理解 LXC 与 Docker 之间的主要区别

两者的概述

容器技术独立运行并且从主机系统上封装应用程序工作量。把容器想象成可以安装和运行应用程序的主机操作系统里面的操作系统，从实用目的来讲，它就像一个虚拟机。

LXC项目给不同配置和用户空间应用提供最小的容器操作样本来管理容器生命周期， LXC项目的这个特性和Linux内核使模仿机制能够正常启用。

便携性

容器技术将应用从主机操作系统上解耦下来，摘录该程序并且使之在任意支持LXC的系统上都实现轻便化。低调的说法就是：非常好用。用户在这样一个原始和最小库的Linux操作系统上可以在容器里运行任何程序（就像是在容器里运行LAMP堆栈）。

因为应用程序和工作量是相对独立的，所以用户可以运行多版本的语言，比如PHP，Python，Ruby，Apache，这些语言都可以共存，隐藏在容器里。实现云计算，就好比是这些例子和工作量都可以灵活的被移动到别的系统，复制，以及快速配置。

难道虚拟技术就做不到吗？

不不不，虚拟技术也可以做到，但是会有一定程度的性能损失，灵活度也会下降。容器技术不是模仿硬件层次，而是在Linux内核里使用cgroup和namespaces来打造轻便的、将近裸机速度的虚拟技术操作系统环境。因为不是虚拟化存储，所以容器技术不会管底层存储或者文件系统，而是你放哪里，它操作哪里。

这从根本上改变了我们如何虚拟化工作负载和应用程序，因为容器速度比硬件虚拟化技术更快，更加便捷，弹性扩容的更加高效，只是它的工作负载要求操作系统，而不是Linux或特定的Linux内核版本。

那VMWare就这样玩完了？

没那么快！虚拟技术相对成熟，又有广泛的工具，还有生态系统来支持它在不同环境下的配置。至于工作负载，它要求非Linux操作系统，或者只能使用特定的核心虚拟化技术。

LXC

LXC起源于cgroup和namespaces在Linux内核方面的发展，它支持轻便的虚拟技术操作系统环境（容器技术），Daniel Lezcano和Serge Hallyn做了一些它的早期工作，这个可以追溯到2009年在IBM的时候。

LXC系统提供工具来管理容器，先进的网络和存储支持，还有最小容器操作系统模板的广泛选择。它目前由一个两人的团队领导：来自Ubuntu的Stephane Graber和Serge Hallyn。LXC是由Ubuntu支持的。

如何区分他们

生产Docker的目的是为了尽可能减少容器中运营的程序，减少到只运营单个程序，并且通过Docker来管理这个程序。

有了Docker，可以从底层应用程序通过Docker来配置，网络，存储和编排。

LXC用正常操作系统环境回避那个问题，并且因此可以快速兼容所有应用程序和工具，以及任意管理和编制层次，来替代虚拟机。

除此之外，Docker使用层次，禁用存储持久性。LXC支持AUFS层次和覆盖，对COW克隆和用brtfs、ZFS、LVM Thin快照广泛支持，并且将选择留给用户。LXC容器技术里的分散存储是绑定安装的，来为用户达到主机或者另一个容器。

Docker和LXC都设置了一个默认的NAT网络。另外，Docker设置一个端口转发到主机上，就会有一个－p标记，比如“－p80:80”就是80从主机转发到容器。有NAT，本地主机就可以直接通过IP访问容器，外部服务需要的时候可以通过IPtable规则来简单完成，当外部服务被消耗的时候，只需要端口转发就可以。至于为什么需要这么做，原因目前还不是很明确。

要把事项复合起来，Docker只给了很少的IP和主机文件控制权，所以不能给容器设置静态IP，这对于IP的分配任务来说有点让人疑惑。我们需要使用“－－Links”标记来连接容器，这个容器中要在被连接的容器中加一个入口在／etc／主机上。

有了LXC，分配静态IP，动态IP，使用多网络设备就简单多了，可以使用／etc／hosts文件，基本上使用Linux网络全栈是没有限制的。您希望在主机上连接容器吗？用户使用GRE，L2TPV3或者VXLAN来快速设置层次，或者是任意的在使用的网络技术。

LXC容器技术可以无缝运行虚拟机运行的一切。

Docker

Docker是dotCloud也就是现在的Docker公司在2013年3月发布的，一开始是基于LXC项目来创建单个应用程序容器。Docker现在已经开发了他们自己的直接使用核心namespaces和cgroup的工具：libcontainer。

分层容器

Docker最开始是基于LXC对Aufs的支持来建立分层容器，因为Aufs可能无法被合并到核心中，所以现在对Brtfs、设备映射和覆盖也添加支持，

Docker容器技术是由基底镜像构成，当提交变成Docker镜像的时候会再加上一个分层面板。当运行一个镜像的时候，它的复本就作为容器被启动了，在提交之前，它的任何数据都只是暂时的。每一个提交都是一个独立的镜像，所以可以从镜像开始。

我们在《如何用LXC覆盖》里有一个指导说明，它给用户描述了分层结构是如何工作的。有了像Aufs或者覆盖（他们在实施上、性能上有区别，而且支持一定数量的低一点的层次）这样的文件系统的联合，较低一点的层次是只读的，而较高一点的层次是在运行的时候是可读可写的。在容器内容中通常是基底操作系统，但是也不是很必要，而上层的图层面板则是由你来修改。

虽然图层面板的想法听起来很不错，但是分层文件系统在技术上仍然是不成熟的，在使用图层面板的时候，还有有一个固有的复杂性和性能的损失。《陷入图层面板》是一个真实的冒险实例，大家不妨看看。

单个应用程序容器

Docker将容器技术限制到只能运行单个进程。Docker的底层镜像操作系统模版不是为运行多个应用程序，进程设计，也不是为像init，cron，syslog，ssh等服务而设计。

我们来看早期的东西，它介绍了日复一日的用户场景有一定的复杂性。因为目前的架构，应用程序和服务是为正常的多程序操作系统环境设计的，所以需要去寻找一种以Docker的方式来工作或使用工具来支持Docker。

拿一个简单的应用程序举个例子，比如WordPress。你可能需要建立3个容器来互相消耗服务。PHP容器，Nginx容器和MySQL容器加上2个分别用来放MysqlDB和WordPress文件持久性数据的容器。然后通过适当的权限将WordPress文件安装成PHP－FPM和Nginx两种语言都可用，然后为了把东西弄得更加让人兴奋，找出一种能够让容器在本地网络上可以互相交流的方法，不需要对网络不定时的控制，也不需要Docker后台程序设置IP！但是我们还没有计算WordPress账户管理的cron和Email。哎！

为了在Docker里运行多个程序，你需要shell 脚本，或者是一个分开的程序管理，比如runit或者管理器。但是Docker生态系统会将之视为“反模式“，而且Docker的整个架构是建立在运行单个程序的容器上的。

代码库

Docker为用户提供公共或者个人push和pull镜像的数据库。这个跟Flockport app Store为用户使用容器做好准备有点相似。这样做，对用户来说，分享和分布应用程序就很简单了。

Dockerfile

Dockerfile是一个告诉Docker如何从镜像用特定的应用程序来创建容器的脚本。跟使用特定的安装好的应用程序通过bash脚本来创建一个LXC容器相似。

跟LXC拉开距离

LXC的特点需要通过Docker团队来重载实现，使之在Docker中可用，比如LXC现在支持让非根用户创建和配置容器的未经授权容器，LXC现在还致力于实时迁移和多主机管理。这些对容器来说都是很大的进步，也为更好的安全性，多租户工作量以及虚拟平价铺平了道路。

Docker还不支持这些。随着最近的libcontainer声明，推测两者间的差距还将增大。

运行容器的方法没有对错之分，容器怎么用主要取决于用户，docker方法是独特的，而且还将在每个阶段自定义途径成为必须途径，并以此来找到Docker的方法从安装和运行应用程序来完成任务，完成弹性扩容。

本文名称：wordpress多租户 wordpress多站点saas
本文来源：http://myzitong.com/article/doidjeo.html