Capsule：开源的JVM应用部署工具
编者按：本文作者Ron Pressler是Parallel Universe公司的创始人，拥有着丰富的高性能开发经验。通过这篇文章，Ron向大家详细介绍了全新的开源JVM部署工具——Capsule。
以下为译文：
现实世界中，应用程序部署过程可能没有想象中的那么简单。应用程序其实非常“敏感”，在部署过程中，它会发现自己身处一个陌生的环境中，并且在与不同硬件、不同基础设施软件，以及陌生的邻居（应用程序）行交互。如果期望应用程序正常地运行，编码和部署过程都是重中之重。两者之间的平衡常常依赖于程序的编写语言、程序构成的运行时和工具，因此，不同的技术栈可能需要不同的部署工具。
但JVM应用程序对环境的要求非常少——只需一个JVM和一个内核，然而意想不到是， 目前为止尚不存在一个通用的JVM应用部署工具/机制。Fat JARs并不总奏效，而且它们需要平台特定的脚本。最近有人使用Docker来部署Java应用，事实上Docker并不适用于这种任务：它的主要目的之一是提供通用的应用可移植性（类似JVM应用已经具备的特性），同时它也需要下载、部署并管理各种full-OS镜像和存repositories。作为运行时不可知工具，Docker也无法利用JVMs 的优势。
当下，经过一年的发展，Capsule 1.0正式发布——一个简单、健壮且灵活的JVM应用部署工具。Capsule迎合JVM应用的独特优势和需求，因此这里有理由相信这是最简单、最强大的JVM应用部署方式，不管是用于一个桌面应用、microservice或复杂的Web应用。Capsule不仅适用于Java应用程序，还能应用于所有JVM语言，从Jruby、Jython和Groovy，到Kotlin、Clojure和Scala，再到Frege和OCaml-Java。如果你在写JVM程序，给Capsule一个机会。
你可以这样来理解capsule，将它当作steroids上的1个fat JAR（在允许本地库的同时也不会干扰到依赖项）与1个声明式启动脚本的整合；另一个理解方式是，将其当作部署阶段的构建工具。正如构建管理工具一样， Capsule从构建到应用发布的各个环节都有全方位的管理。
Capsule在设计时一直遵循以下原则：
打包应该是轻量、可移植和便捷的。无论多么复杂，不管有多少JAR文件组成，或者有多少脚本语言的源文件还是本地库，Capsule都可以包装任何JVM应用到一个名为 Capsule的可执行JAR，并且可以在任何平台上运行。Capsule可以直接包含应用的所有依赖项，或简单地声明部分或者全部，一旦发布将会被完整的下载。这就是fat JAR的工作方式。如果愿意， capsules本身也可以置于Maven repositories，在发布时进行下载。
安装对主机系统的影响最小，并对更新选择性支持。在capsule首次安装时，其正常运行需要依赖在1个临时目录中生成的一些文件，随后用户可以在任何时刻删除这些文件，不会对capsule产生任何不良影响。capsule可以选择性地支持更新——不管是应用或者是其依赖关系——当启动时会自动下载。这些依赖关系——可以是语言运行时或者是Web容器——也可以被其他capsule共享。
发布必须是确定和灵活的，可能是安全的且有选择地限制。发布一个capsule不需要启动脚本。Capsules查找请求的JVM版本、设置classpath、必要的agents并设置JVM flags。Capsules在启动时也可以创建自己的容器（来限制资源使用，或使用已知的端口以避免对其他项目形成干扰），同时JVM应用可以在无特权的容器下运行，这些容器是安全的。另外，安全性由JVM提供的安全机制保证。此外， capsules只需要一个内核和一个JVM——甚至不需要shell，他们便能在JVM microkernels上运行，比如OSv。通过caplets和组件定制capsule的行为，所有这些功能都是完全可编程、可组合的。
当工具和标准已经存在时，不用再重造车轮。Capsule是用Java编写的，并可以通过Java扩展。它遵循JVM生态系统，而不是重造车轮，仅使用现有的工具和标准。capsule打包在一个可执行JAR，并将所有元数据存储为简单的JAR-manifest attributes中；并且可以根据需要，从Maven repositories中下载全部或者部分，并通过Maven、Gradle和Leiningen这些流行的JVM工具构建。Capsule本身是一个简单的Maven依赖，就像所有的构建工具插件，不需要再安装其他新工具。
Capsule Magic with Caplets
通过Caplets实现的Capsule魔法
Capsule之所以能保持简单还能提供这些功能主要归功于caplets，以模块化定制Capsule行为。Caplets可以嵌入到1个capsule，或者单独进行包装并使用命令行包装和修改现有capsule行为。
Capsule的第一个caplet是Maven caplet，允许开发者在manifest attributes中声明部分或全部的应用依赖关系，而不用嵌入到capsule JAR里。虽然这对许多应用来说并不必要，不妨通过以下两个用例来深入了解Capsule的潜力。
首先是一个简单的Hello World servlet。建成后，它将创建一个标准的WAR文件并部署到任何servlet容器。仔细观察后发现，WAR的确有点特别。其内容是:
如你所见， WAR包含Capsule 类，这意味着它是一个capsule，也是嵌入式JAR，而 capsule-maven-1.0.jar是Maven caplet。JAR manifest是这样的:
取代部署WAR到servlet容器，你可以直接执行 java -jar build/libs/capsule-runnable-war.war （或者，甚至简单的./capsule-runnable-war.war，如果capsule是“真正可执行”——见用户文档的指令），它会自动下载Jetty，并用Jetty来启动servlet。Jetty工件将被缓存，并可以共享到其他需要的caplets中。
当capsule发布，Avatar运行时——包括针对本地操作系统的本地库，将从Maven repository下载到本地并缓存，并与其他Avatar capsules共享。
其他caplets将包含：一个守护进程caplet， 作为Unix或Windows守护进程来发布capsule；一个安全caplet，会在Java沙箱（通过安全策略定义）内启动capsule；一个desktop caplet，会将包含了一个GUI应用程序的capsule转化为一个Windows、Mac或Linux的本地可执行程序；一个容器caplet，在一个或多个容器内运行capsule。
为Capsules设计的轻量级容器
容器对沙箱应用来说是一个有效方式，可以简化部署和巩固服务器，所以对任何的软件堆栈而言，它们都非常有利于dev-ops和安全。然而，由于JVM应用只有最小的环境需求 （即一个内核和一个JVM），它们通常是可移植的，使用一个像Docker的容器解决方案无疑是浪费时间和空间。另一方面，shield caplet创建了一个轻量级容器，无需创建大图像。
例如，可以通过简单地桥接网络在1个容器中方便地运行quasar-stocks Web应用。
随后就可以轻松地检索程序所运行的容器IP地址:
当一切如预期那样正常工作，无需任何复杂的操作，就可以在最终部署的服务器上（可能是一个守护进程）发布相同的命令来配置端口转发使服务公共可用，并通过沙箱保证了应用程序的强安全性。
Go with Capsule
是时间打开capsule.io并启动capsules了！
它们需要跟踪以避免冲突，甚至这样还不够，因为它们不支持本地库。
它们可能需要不可移植的发布脚本，以便于在操作系统shell命令下执行，并选择正确的JRE版本、设置类路径、代理和JVM参数。
所有平台都支持JVM，必要的脚本和本地构件可能也一样需要。
可能需要更长的启动时间，比如依赖项需要重新下载。
shield caplet使用LXC将capsule放于容器内。
本文为CSDN原创，点击“阅读原文”可查看完整文章并参与讨论。
如果您喜欢这篇文章，请点击右上角“…”将本文分享给你的朋友