Question

在任意云服务上部署代码的“零配置”（意味着最小配置）有哪些选项？

我意识到有数千个云平台，每个平台都支持一组特定的语言，一组特定的软件包，并且运行特定的工作流程，通常使用一套专有的命令行工具来减轻部署压力。

但是，如果我不想了解有关特定云平台的任何信息，我想编写将在未来几年内轻松部署在云中的代码，该怎么办？

显然，最具体的答案很简单：用你想要的任何东西构建一个虚拟机映像然后在云上运行（这种方式几乎是零配置，我们可以期待我今天构建的虚拟机映像仍然有效在10年内的大多数VM主机上。）

所以我的问题是：从VM映像理想的下一层是什么？什么是最开放和广泛接受的标准，以机器可读的形式封装任意软件堆栈的完整描述，这样我就可以将我的软件堆栈扔到任何通用的类似云的托管服务，而无需考虑特定于该托管的任何配置服务？

Answer 1

如果“云”是指 IaaS （基础架构即服务提供商），例如EC2等 - 反对 PaaS （ Google App Engine，Heroku等），那么这些天的趋势似乎是Infrastructure-as-Code和DevOps。这不是'零配置';它更像是配置一次，并在DSL中描述整个堆栈的配置，可以用来构建或重建整个堆栈，除了一组在任何云上运行的新启动的虚拟机

因此，您拥有配置管理系统，以及配置管理系统可以理解的一系列机器可读“配方”。虽然确实存在语言实际上是XML的系统，但通常会在某种自定义DSL中表达这些配方。

此类配置管理系统的一些着名示例包括：

Chef
Puppet

还有很多其他人;但我没有经验（CFEngine，bcfg2（使用XML））

这些工具幂等。这意味着，您可以根据需要多次重新运行配置，并且只需要完成以满足配方指定的描述所需的操作。如果您已将某些文件指定放置在具有特定内容的某些目录中，则只有在需要时才会创建（或修改）它们。只有在需要时，或者如果它们的版本与配方指定的版本不同时，才会安装软件包。

例如，在Chef中，指定必须存在用户tomcat，并且必须安装某个版本的Java，并且该postfix应该正在运行，并且某个XML文件必须在在给定的位置，你会有一个看似如下的食谱：

user "tomcat"

package "java" do
  version "1.6.0_u27"
end

directory "/etc/yourapp" do
  owner "tomcat"
end

package "postfix"
# Ensure that postfix is installed and running.
service "postfix" do
  action [:enable, :start]
end

tempate "/etc/yourapp/config.xml"
  source "config.xml.erb"   # This will be a template file that references variables
  variables(
    :db_server => '10.1.2.4' #just an example; there will be ways to automate this
  )
  mode "0755"
end

Chef for one，提供一系列预先编写的食谱或“烹饪书”，您只需下载，包含和使用作为基础架构的一部分。在Chef中，您可以根据服务器的内容编写烹饪书 - 然后定义角色，指定将哪些烹饪书应用于构成堆栈的服务器类。您只需将角色分配给您的实例，启动它们，然后观察整个堆栈自我启动。

我会说这已经成为维护基础架构的全栈可执行描述的标准方法（不一定只是云 - 我在VMWare和/或VirtualBox上测试，但是部署到多个公共云供应商相同的食谱。）

缺点是你需要学习DSL。并且可能会对您的工作流程进行重大更改。这些系统也各有利弊。但是，以这种方式做事肯定是维护定制虚拟机映像的下一层，并且在许多方面更灵活。例如，如果每个云提供商都为您提供NTP服务器地址以使您的实例保持同步，则必须根据提供商更改映像。使用Chef / Puppet，可以自动化并抽象地整理出来。

虽然VM映像是所需“配置”的冻结副本，但它们并不捕获每个组件 - 堆栈中的每个实例 - 如何相互交互。例如，应用程序服务器需要知道数据库服务器，它的地址，各种连接参数 - 数据库服务器需要知道可能要连接到它的所有应用程序服务器（在云环境中，应用程序服务器甚至可能数量随时间增长或缩小）。这是一个动态的东西，很容易使用像Chef这样的系统自动化。

Answer 2

我认为你问题的答案是Jelastic。为了使您的应用程序保持在云端并让其他人查看它，您将完全符合http协议，至少我认为PHP在那里作为一种语言获胜。如果这是真的，那么市场上现在只有平台，而且是Jelastic。试试自己，让我知道。零配置和供应商锁定免费与优秀的Web控制台，它是最好的。我可能听起来像一个传播者，但我是他们的堆栈满意的客户（我使用Java作为编程语言，并有一个初创公司），真的很喜欢他们的平台

苏里亚

Answer 3

零配置更可能是“平台即服务”中的特征，而不是“基础架构即服务”。也许我们应该说“最小配置”而不是“零”。 PAAS为您提供半固定的体系结构，并在其中提供一些杠杆来配置事物。使用IAAS，您可以使用某些工具完成所有工作。

我可以谈谈我使用Google App Engine的经验，您可以在本地开发代码，使用描述符文件将其打包，然后将其部署到App Engine。你不应该关心底层机器，也不关心如何扩大或缩小流量等。平台会为你处理这些东西，无论它是好还是坏。这个想法是你只关注你的应用程序。虽然实际上，您仍然必须了解一些基础架构，以便做出正确的设计决策。

AppEngine支持Java，Python和Go。

Heroku和Engine Yard也是PAAS，最初支持Ruby。 Heroku现在也支持Java，Python和Node.js.

还有Rackspace的Open Stack计划，它与定义您可以在其中居住的架构相关，但让它可以“移植”到各种IAAS提供商。伟大的概念，但我不相信很多人已采用它。 http://www.openstack.org/software/

Answer 4

我认为应用程序长寿的最直接的答案是抽象。

以抽象和简单的术语描述您的应用程序需求，构建或使用支持它的应用程序框架，并仔细隔离特定于您的应用程序需求的部分。

在python中，这可以转化为在Google App Engine上构建一些东西。脱离这一点的核心思想是，您（或谷歌）始终能够在不触及应用程序的情况下改进底层基础架构，因为它描述了它的操作，而不会对其进行任何假设。如果这种方法定义了应用程序的内容和方式的成本可以用抽象和可移植的方式来描述，但是如果你做对了，你唯一应该担心的是你使用的核心语言的变化。 / p>

现在缺少这个问题的一个重要方面是改变是好的。你永远不应该害怕废弃整个应用程序堆栈。事实上，技术今天变化如此之快，以至于需要保持领先和相关性。出于这个唯一的原因，您甚至不太可能希望在未来几年以相同的方式编写应用程序。

Answer 5

每个云平台都可以回答您的问题，并说＃34;我拥有最好的通用解决方案＆＃34;但只有开发者选择的标准才会存在。所以当然你可以建立你自己的虚拟机模板并使用它多年 - 问题是，你的操作系统将失去支持，有些日子会折旧和不安全。因此，您将不得不更新您的模板，但您的整个应用程序基础架构（如果您不经常这样做）。所以VM是可以的，但我认为这不是一个答案...... 另一方面，您拥有云提供商解决方案，如Jelastic部署脚本或Azure Cloud Service部署（手动或通过IDE）。但是到目前为止，这些解决方案可能在未来发生变化，您将无法在不重构的情况下使用您的脚本。第三种方法是使用一些devops机制，如Chef，Puppet，docker或其他任何开发的机制，从今天或将来我们都不知道。他们中的大多数都非常强大和伟大。他们中的许多人都将云实施作为亚马逊或Azure的Chef插件，Azure上的Puppet服务器，亚马逊或Azure上的docker等等。问题是，我们今天不知道，未来将是标准。所有这些都是一个非常年轻的解决方案，并且（说实话）不那么受欢迎，也不那么容易学习。最后一个 - 标准化，受开发者喜爱，深受管理员和devops的喜爱 - GIT和持续的开发/持续集成。 GIT是一个标准，将来会因为它被商业和教育很好地采用。许多公共云提供商（以及私有云提供商）都可以将带有git的应用程序直接部署到云平台。我使用Azure PaaS解决方案来处理我的Python代码。我需要做的就是创建部署槽并推送我的代码。 Azure Web App平台中有持续的集成机制，我提交几秒后，我的代码就被部署了。你可以在很少的云中找到这样的解决方案，但不是到处都可必须有PaaS才能做到这一点，不仅仅是IaaS，因为它存在于许多公共云中。

零配置云部署

5 个答案: