cloud - Zero Configuration cloud deployment

Question

What are the options out there for "zero configuration" (meaning minimal configuration) deployment of code on an arbitrary cloud service?

I realize that there are thousands of cloud platforms, each supporting a particular set of languages, a particular set of packages, and sporting a particular workflow, often with proprietary set of commandline tools to make deployment less painful.

But what if I don't want to know anything about particular cloud platforms, and I want to write code that will be easy to deploy in a cloud for years to come?

Obviously the most concrete answer would be simply: build a virtual machine image with whatever you want and then run that on the cloud (this way is pretty much zero-configuration and we can expect a VM image I build today to still work on most VM hosts in 10 years).

So my question is: What is the next tier down from the VM image ideal? What are the most open and widely-accepted standards for encapsulating a complete description of an arbitrary software stack in machine-readable form such that I can throw my software stack at any generic cloud-like hosting service without thinking about any configuration specific to that hosting service?

score 2 · Accepted Answer

如果“云”是指IaaS （基础架构即服务提供商），例如 EC2 等，而不是PaaS（Google App Engine、Heroku 等），那么这些天的趋势似乎是基础架构-代码和DevOps。这不完全是“零配置”；它更像是 configure once，并在 DSL 中描述整个堆栈的配置，它可用于从任何云上运行的一组新启动的 VM 构建或重建整个堆栈。

所以你有一个配置管理系统，以及一堆配置管理系统理解的机器可读的“食谱”。尽管确实存在语言实际上是 XML 的系统，但配方通常以某种自定义 DSL 来表达。

这种配置管理系统的一些众所周知的例子包括：

还有很多其他的；但我对它们没有经验（CFEngine，bcfg2（使用 XML））

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

例如，在 Chef 中，要指定用户tomcat必须存在、必须安装某个版本的 Java、应该运行该后缀以及某个 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。并且可能对您的工作流程进行重大更改。这些系统也有各自的优缺点。但是，以这种方式做事肯定是维护自定义 VM 映像的下一层，并且在许多方面更加灵活。例如，如果每个云提供商都为您提供一个 NTP 服务器地址以使您的实例保持同步，则必须根据提供商更改图像。使用 Chef/Puppet，这可以自动化并巧妙地抽象出来。

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

score 2 · Accepted Answer

我认为您的问题的答案是Jelastic。为了让您的应用程序留在云中并让其他人查看它，您将至少符合 http 协议，至少我认为 PHP 作为一种语言赢得了那里的手。如果这是真的，那么现在市场上只有一个平台可用，那就是 Jelastic。试试自己，让我知道。零配置和供应商锁定免费使用一流的 Web 控制台，这简直是最好的。我可能听起来像一个传道者，但我对他们的堆栈感到满意（我使用 Java 作为编程语言并有一家初创公司）并且真的很喜欢他们的平台.

苏里亚

score 1 · Accepted Answer

零配置更可能是“平台即服务”中的特征，而不是“基础设施即服务”中的特征。也许我们应该说“最小配置”而不是“零”。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/

score 1 · Accepted Answer

我相信对病房应用寿命最直接的答案是抽象。

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

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

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

score 0 · Accepted Answer

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

cloud - Zero Configuration cloud deployment

5 回答 5

Related

Reference