早在去年夏天，Zac向我提出建设现代化，最基础的裸机的云托管平台。花了我的绝大多工作时间建设，支持或采用可扩展的基础设施服务，我很好奇，但问自己 - 这是真的需要吗？ 周围是不是有很多好的IaaS服务？   随着进一步交谈，我最终同意，许多公共云服务不是用户友好的并且有过高的限制去使用。此外，我是一个早期的采用Docker的用户，知道的容器驱动应用的发展浪潮将使高品质的裸机服务器在DevOps工具箱中呈指数级得实用。同时，虚拟化的具体公共云和传统的专用托管服务提供商没有很好的定位，以满足灵活的物理硬件不断增长的需求。我认为有工作需要我完成 - 所以我的旅程开始了，我跳上这艘包Packet快递！  

在安装平台方面......

  当我一头扎进Packet，我花了一些时间审视了一番部署技术和云自动化的当前状态。我检查了定制安装，所有的开源云平台以及从头开始建造自己的一整套服务需要什么。 我在Voxel的时候，从INTERNAP取得的云托管平台，我们已经建立了很多软件栈和经历了拥有我们自己的软件平台的成果和后果。安装服务器看上去似乎很简单 - 你做对了一次就会了，是吧？错！有无数的网络“陷阱”，不断变化的硬件和无数操作系统差异需要解决，为客户提供真正的自动化服务层。安装，管理和规模化确保数千台服务器并达到Zac的要求（“每一次5分钟或更短！”），我不能对这些掉以轻心。   为了帮助Packet实现全天候进行数以千计的安装和在短短的几个月内运行的目标，我对于利用OpenStack的创新技术的到基础设施的管道对我们的服务添砖加瓦产生了兴趣：网络自动化，知识产权管理，安装例程硬件的生命周期，和安装。如果我可以依靠OpenStack的这些核心组件，那么我和我的团队可以集中更多的精力对用户增值，像硬件分析和容器的支持。   我一直被人告诫一些OpenStack的陷阱 -还花了几个星期阅读最新信息，看成一堆的官方IRC频道，并运行DevStack。我对于OpenStack的核心项目越来越放心，该项目已在过去2年大大成熟。此外，时机也不错。 Rackspace公司最近发布的OnMetal并在博客公开谈论他们是如何在他们的裸机云服务器和一个重要的发布Juno运行Ironic(dbDao)。   所以我就开始和团队借力OpenStack的为我们的裸机服务器部署。  

故事

  我知道OpenStack将是一条陡峭的学习道路，我需要知道每个项目的工作guts，而不是简单地安装它们。我一个接一个投入OpenStack的项目，努力了解Nova的准确状态，Ironic驱动程序和特别是Neutron。我们不仅要充分利用Ironic进行裸机安装中，我们还需要支持Packet的主机级别的网络模型，其避免了Layer2和VLAN网络并支持直接把Layer3放到每个主机。   你可以说我的看法是，“朋友，这会有很多文档的阅读和很多东西要学！”。在一个月的学习过程中，我越来越发现大量我阅读的文件不是过时就是完全不准确。这迫使我在更大的图书馆，维基文章，IRC日志中筛选文件，并提交信息找到“真理之源”。学完了基础知识后，我需要大亮点调试时间，只是为了在各种相互矛盾的说法证明特定功能，如 “X行得通啊？”。这使我进展缓慢。   值得一提的是，有一个个人和企业的大型生态系统有OpenStack的经验，与Nova和标准Neutron的实施有关。然而，几乎没有任何在生产水平人有运作Ironic的经验。而且即使那里的社区相比许多其他OSS项目大了很多，我也经常碰见一些情况下，一些核心开发人员不能回答我们的实施问题，和谷歌搜索产生不到一打结果的错误消息。  

教程＃1 - OpenStack大，年轻，灵活。一旦你学会了基础知识，文档是易操作的。

  我进一步研究Ironic，让我的一个同事研究Neutron。事实是（每个教程＃1），我们需要为每个OpenStack的组件找一个专门开发者的只是为了了解代码库，并​​与项目进度保持速度，知道我们会如何根据需求适当地应用。所以我集中了我的注意，与Rackspace OnMetal出色的团队通过IRC，电子邮件和OpenStack的开发者论坛度过许多漫长的夜晚。我敢肯定我读过谷歌能搜索到的关于Ironic的每一篇文档，论坛发帖和调试输出！   虽然大量的工作已经能把Nova baremetal驱动程序分成Ironic项目的一级，OpenStack的设计仍然是极度以虚拟为中心。仍然有许多功能和文档在Nova “baremetal”和Ironic与Nova Ironic驱动之间变化。我遇到了这个Ironic有限网络支持的square。由于Ironic你被约束在有模块层2“ML2”插件的op​​envswitch和linuxbridge代理。我们的网络模型很大程度上和这个抵触，因为我发现，Neutron缺乏在它供应商特定的switch支持以及到不同的网络模式的延伸能力。   更大的玩家（Rackspace，最显著）具有对核心OpenStack代码更深的理解，已经高度定制大多数个体Openstack组件，以便能够部署于实际物理网络的物理服务器。其中一些补丁已经提供给公众，但许多重要的补丁都没有，并且需要被从头写入，并进行挑选到即将到来的版本进行维护。  

教程＃2：OpenStack都是关于VM。如果你没有，祝你好运！

  在这一点上，我仔细想过给我们的产品用OpenStack的安装服务。资源，它需要理解，并保持每个项目的同步的资源量是巨大的 – 并且我开始觉得，我们需要做的Nova和Ironic项目的定制的水平将是不小的，并抵消了OSS的好处，这个好处是我们在OpenStack项目及其开发势头中正在寻找的。   不过，我认为完全理解Neutron的细节是很重要的，这使我的个人遗愿清单中最后的关键项目之一。   在物理交换机和服务器的世界里，安装服务器不是特别困呐。而可靠地安装，是困难的。自动化需要一套工具来工作，在我看来，大多数基础设施的部署系统中最容易出错的部分是网络自动化。物理交换机的操作系统留下许多支持现代自动化和API交互项有待改进的地方（Juniper网络即将推出的14.2 JUNOS更新提供了一些令人耳目一新的REST API’s！）。事实上，我对与其他网络自动化工具的失望经历是我选择了在OpenStack的投入时间的主要原因之一 - Neutron项目具有相当真棒使命：“为了实现服务和相关的库来提供按需的，可扩展的，和与技术无关的网络抽象。“我要报名！   然而，现实是不理想的。所有软件定义网络的谈话，大部分是关于有虚拟网络在虚拟机管理程序之上，而不是与实际交换机。不仅我们的交换机供应商（Juniper）的Neutron驱动远远落伍，甚至我们把它移植到最新的OpenStack Juno发布，它的支持也是最小的。此外，Neutron利用一个内部，基本的IP地址管理器（IPAM），并对于任何本身外分配任务，报告或提供关于IP地址资产的权限的没有什么概念。降低我们的用户体验以适应Neutron的有限能力是不可接受的。  

教程＃3：Neutron的支持是相当分散的。首先检查你的交换机！

  所以，我们做了什么？ 长话短说，我们在圣诞节前的一个星期抛开OpenStack，花了接下来的三个星期开发自定义部署自动化平台。在十二月初建立我们自己的IP manager之后，团队team被鼓励energized建立在定制工具之上。当每一个新的软件项目创建其自己的传统责任，我们公司有了100％的前瞻性，并且认为在探索和部署OpenStack的，我们填补了大部分的漏洞：一个灵活的，服务提供商级的IPAM（我们把它叫做万能的IP），这是一个由我们的SWITCH OSS支持和把我们的设施管理平台和我们的物理基础设施之间整合更紧密的集成用户和权限模型。   有时，总有一些不够好或达不到你需求的，而这显然是与OpenStack的情况和我们在Packet在做的。虽然我们期待着发布我们的Neutron插件到社区并且保持当下OpenStack的项目的发展，但是现在我们要继续前进。   当我们在下周完成了CoreOS的安装设置（在艰难地完成Ubuntu，Debian和CentOS之后）我很高兴我们如何精简，快速，认证的系统将让我们在不影响用户体验来支持先进的功能和高可用性。我敢说：吸取的教训和特派团（几乎）实现的吗？