随着OpenStack等IaaS平台在按需提供计算和存储资源方面获得发展，我们看到电信和企业IT客户越来越关注“按需软件”。通常，现有的软件交付流程过于冗长，无法充分利用云的“即时启动”特性。最终用户需要能够选择并即时配置软件和应用程序，并在不再需要时将其停用。因此，这引发了许多问题：如何将应用程序部署到IaaS平台？如果其他人作为应用商店的一部分提供应用程序，如何确保软件治理？如何随着时间的推移构建和维护软件镜像，从而使云部署具有可预测性和一致性？
如今，软件镜像通常是手动构建的，使其难以随着时间的推移进行更新和维护。云用户现在意识到需要使用透明的镜像模板，这些模板能够让他们追踪单个软件组件、版本和许可证。他们将这些模板与自动化的软件交付流程相结合，使用API来工业化镜像的创建和维护。这使他们能够轻松跟踪组件、自动添加或更新软件，并生成到单个或多个云。无论镜像仅在私有云中使用，还是作为混合模型的一部分用于爆发到Amazon等平台，镜像始终保持一致且可预测。
客户可以采用不同的方法来构建和部署这些镜像。首先，DevOps模型使用一个仅包含基本软件包的镜像作为基础，以启动操作系统。安装完成后，一个“回传”功能使DevOps平台能够安装特定服务所需的所有软件包。这对于许多客户来说是一个很好的模型。然而，其他人意识到，如果您要从外部仓库安装例如400个虚拟机，则服务启动需要很长时间。在云模型中，您还需要为此期间支付带宽和其他资源费用。
其次，客户可以使用更完整的镜像，这些镜像不仅包含操作系统软件包，还包含中间件和应用程序。然后，他们可以将这些镜像与DevOps平台结合使用进行配置，这是一种非常灵活的方式，可以在不产生我们之前讨论的一些缺点的情况下推送配置信息。
最后，存在“完全烘焙”的自包含镜像，其中包含所有软件组件以及配置逻辑。这些镜像可用于在私有或公有云中启动特定的解决方案，而无需大量的专业知识，并且通常被ISV用于在客户现场快速启动POC，例如。
无论您采用哪种方法，都必须记住，所有三种方法都需要控制和维护基础镜像。您必须能够跟踪您使用的软件包和组件，即使是在DevOps基础镜像中，否则您很快就会得到大量难以管理的镜像。
易于追溯性和维护也将帮助您过渡到云软件部署的下一阶段：从用于小型部署或测试目的的单体镜像，到用于预生产和生产部署的大规模多层镜像。您将能够更轻松地组合多个虚拟机，配置、维护和停用跨多个云节点的完整解决方案。
James Weir
CTO，UShareSoft
发表评论