当您从事 IT 工作时，您会开始注意到系统有自己的特点。 他们可以灵活、沉默、古怪、严厉。 它们可以吸引或排斥。 不管怎样，你必须与他们“谈判”，在“陷阱”之间周旋，并建立他们的互动链条。
因此，我们有幸构建了一个云平台，为此我们需要“说服”几个子系统与我们合作。 幸运的是，我们有“API 语言”、直接的双手和很大的热情。
这篇文章不会在技术上硬核，但会描述我们在构建云时遇到的问题。 我决定以轻松的技术幻想的形式来描述我们的道路，讲述我们如何寻找系统的通用语言以及从中得到的结果。
欢迎来到猫。
开始的旅程
前段时间，我们团队的任务是为客户推出一个云平台。 我们拥有管理支持、资源、硬件堆栈以及选择技术来实现服务的软件部分的自由。
还有一些要求：
- 该服务需要方便的个人账户；
- 该平台必须集成到现有的计费系统中；
- 软件和硬件：OpenStack + Tungsten Fabric (Open Contrail)，我们的工程师已经学会“烹饪”得很好。
如果 Habra 社区感兴趣的话，我们将在下次告诉您团队是如何组建的、个人帐户界面是如何开发的以及设计决策是如何制定的。
我们决定使用的工具：
- Python + Flask + Swagger + SQLAlchemy - 完全标准的Python集合；
- Vue.js 前端；
- 我们决定使用 Celery over AMQP 来进行组件和服务之间的交互。
关于选择 Python 的预期问题，我将进行解释。 该语言在我们公司找到了自己的定位，并围绕它发展了一种虽小但仍然存在的文化。 因此，决定开始在其上构建服务。 而且，此类问题的发展速度往往是决定性的。
那么，让我们开始我们的认识吧。
静音账单 - 计费
我们认识这个人很久了。 他总是坐在我旁边，默默地数着什么。 有时他会将用户请求转发给我们、开具客户发票和托管服务。 一个普通的努力的人。 确实，有困难。 他沉默寡言，时而深思熟虑，时而独处。
计费是我们尝试与之交朋友的第一个系统。 我们遇到的第一个困难就是处理服务的时候。
例如，当创建或删除任务时，任务将进入内部计费队列。 这样就实现了一个与服务异步工作的系统。 为了处理我们的服务类型，我们需要将我们的任务“放入”这个队列中。 在这里我们遇到了一个问题：缺乏文档。
从软件API的描述来看，这个问题还是有可能解决的，但是我们没有时间做逆向工程，所以我们把逻辑拿到外面，在RabbitMQ之上组织了一个任务队列。 对服务的操作由客户从其个人帐户发起，变成后端的 Celery“任务”，并在计费和 OpenStack 端执行。 Celery 使得管理任务、组织重复和监控状态变得非常方便。 您可以阅读有关“芹菜”的更多信息，例如， .
此外，计费并没有阻止资金耗尽的项目。 通过与开发人员的沟通，我们发现在计算统计数据时（我们需要准确地实现这种逻辑），存在着复杂的停止规则的相互关系。 但这些模型不太符合我们的现实。 我们也是通过Celery上的任务来实现的，将服务管理逻辑带到了后端。
上述两个问题都导致代码变得有点臃肿，将来我们将不得不进行重构，以便将处理任务的逻辑移至单独的服务中。 我们还需要在表中存储一些有关用户及其服务的信息来支持此逻辑。
另一个问题是沉默。
Billy 对某些 API 请求默默地回答“好的”。 例如，当我们在测试期间支付承诺的付款时就是这种情况（稍后会详细介绍）。 请求已正确执行，我们没有看到任何错误。
我必须在通过用户界面使用系统时研究日志。 事实证明，计费本身执行类似的请求，将范围更改为特定用户，例如 admin，并将其传递到 su 参数中。
总的来说，尽管文档存在缺陷并且 API 存在一些小缺陷，但一切都进展顺利。 如果您了解日志的结构以及要查找的内容，即使在重负载下也可以读取日志。 数据库的结构很华丽，但很有逻辑性，在某些方面甚至很有吸引力。
所以，总结一下，我们在交互阶段遇到的主要问题与具体系统的实现特性有关：
- 以某种方式影响我们的未记录的“功能”；
- 闭源（计费是用 C++ 编写的），因此，除了“反复试验”之外，不可能以任何方式解决问题 1。
幸运的是，该产品具有相当广泛的 API，我们已将以下子系统集成到我们的个人帐户中：
- 技术支持模块 - 来自您个人帐户的请求将被“代理”以透明地为服务客户计费；
- 财务模块 - 允许您向当前客户开具发票、核销并生成付款文件；
- 服务控制模块 - 为此我们必须实现我们自己的处理程序。 系统的可扩展性对我们有利，我们“教”了比利一种新型服务。
虽然有点麻烦，但无论如何，我想比利和我会相处得很好。
漫步钨田 – 钨布
钨场上散布着数百根电线，通过它们传递数千位信息。 信息被收集到“数据包”中，进行解析，构建复杂的路线，就像魔术一样。
这是我们必须与之交朋友的第二个系统的领域 - Tungsten Fabric (TF)，以前称为 OpenContrail。 它的任务是管理网络设备，为我们用户提供软件抽象。 TF - SDN，封装了与网络设备一起工作的复杂逻辑。 有一篇关于技术本身的好文章，例如， .
该系统通过 Neutron 插件与 OpenStack（下面讨论）集成。
OpenStack 服务的交互。
运营部门的人向我们介绍了这个系统。 我们使用系统的 API 来管理我们服务的网络堆栈。 它还没有给我们带来任何严重的问题或不便（我不能代表 OE 的人说话），但在交互中出现了一些奇怪的情况。
第一个看起来像这样：通过 SSH 连接时需要向实例控制台输出大量数据的命令只是“挂断”连接，而通过 VNC 一切正常。
对于那些不熟悉这个问题的人来说，它看起来很有趣： ls /root 工作正常，而例如 top 完全“冻结”。 幸运的是，我们之前也遇到过类似的问题。 这是通过调整从计算节点到路由器的路由上的 MTU 来决定的。 顺便说一句，这不是 TF 问题。
下一个问题即将来临。 在一个“美丽”的时刻，路由的魔力就这样消失了。 TF 已停止管理设备上的路由。
我们从管理员级别开始使用 Openstack，然后转移到所需的用户级别。 SDN 似乎“劫持”了执行操作的用户范围。 事实上，连接 TF 和 OpenStack 使用的是同一个管理员帐户。 在切换到用户的步骤中，“魔力”消失了。 决定创建一个单独的帐户来使用该系统。 这使我们能够在不破坏集成功能的情况下工作。
硅生命体 - OpenStack
一种形状怪异的硅胶生物生活在钨矿区附近。 最重要的是，它看起来就像一个长大的孩子，一挥就能把我们压扁，但他身上并没有明显的攻击性。 它不会引起恐惧，但它的大小会激发恐惧。 周围发生的事情的复杂性也是如此。
OpenStack 是我们平台的核心。
OpenStack有几个子系统，其中我们目前使用最活跃的是Nova、Glance和Cinder。 他们每个人都有自己的 API。 Nova 负责计算资源和实例的创建，Cinder 负责管理卷及其快照，Glance 是管理操作系统模板及其元信息的映像服务。
每个服务都运行在一个容器中，消息代理就是“白兔”——RabbitMQ。
这个系统给我们带来了最意想不到的麻烦。
当我们尝试将额外的卷连接到服务器时，第一个问题很快就出现了。 Cinder API 断然拒绝执行此任务。 更准确地说，如果您相信OpenStack本身，连接已建立，但虚拟服务器内部没有磁盘设备。
我们决定绕道而行，并请求 Nova API 执行相同的操作。 结果是设备连接正确并且可以在服务器内访问。 看来问题是在块存储不响应 Cinder 时发生的。
使用磁盘时还有另一个困难等待着我们。 系统卷无法与服务器断开连接。
同样，OpenStack 本身“发誓”它已经破坏了连接，现在您可以单独正确地使用卷。 但该 API 断然不想在磁盘上执行操作。
在这里我们决定不再特别去战斗，而是改变我们对服务逻辑的看法。 如果有实例，则还必须有系统卷。 因此，用户在不删除“服务器”的情况下还无法删除或禁用系统“磁盘”。
OpenStack 是一组相当复杂的系统，有自己的交互逻辑和华丽的 API。 我们得到了相当详细的文档的帮助，当然还有反复试验（没有它我们会怎样）。
测试运行
我们去年XNUMX月进行了一次测试发射。 主要任务是从技术方面和用户体验方面在战斗模式下测试我们的项目。 有选择地邀请观众并关闭测试。 但是，我们还保留了请求访问我们网站上的测试的选项。
当然，测试本身也并非没有有趣的时刻，因为这是我们的冒险才刚刚开始。
首先，我们在某种程度上错误地评估了对该项目的兴趣，并且必须在测试期间快速添加计算节点。 这是集群的常见情况，但这里也存在一些细微差别。 特定版本 TF 的文档指示了测试 vRouter 的工作的特定内核版本。 我们决定启动具有更新内核的节点。 结果，TF没有收到来自节点的路由。 我不得不紧急回滚内核。
另一个好奇心与个人帐户中“更改密码”按钮的功能有关。
我们决定使用 JWT 来组织对我们个人帐户的访问，以免使用会话。 由于系统多种多样且分散，我们管理自己的令牌，其中我们“包装”来自计费的会话和来自 OpenStack 的令牌。 当密码更改时，令牌当然会“变坏”，因为用户数据不再有效，需要重新颁发。
我们忽视了这一点，而且根本没有足够的资源来快速完成这篇文章。 我们必须在启动测试之前删除该功能。
目前，如果密码已更改，我们会注销用户。
尽管存在这些细微差别，测试还是进展顺利。 几周内，大约有 300 人前来参观。 我们能够通过用户的眼睛来看待产品，在行动中测试它并收集高质量的反馈。
待续
对于我们许多人来说，这是第一个如此规模的项目。 我们学到了许多关于如何团队合作以及做出架构和设计决策的宝贵经验。 如何用很少的资源集成复杂的系统并将其投入生产。
当然，无论是在代码方面，还是在系统集成的接口方面，都还有一些工作要做。 该项目还很年轻，但我们充满雄心，希望将其发展成为可靠、便捷的服务。
我们已经能够说服系统。 比尔尽职尽责地处理他衣柜里的计数、计费和用户请求。 钨磁场的“魔力”为我们提供了稳定的通讯。 只有 OpenStack 有时会变得反复无常，大喊“‘WSREP 尚未准备好节点供应用程序使用’”。 但这是一个完全不同的故事......
我们最近推出了这项服务。
您可以在我们的网站上找到所有详细信息 .
CLO开发团队
有用的链接
OpenStack的
钨丝布
来源： habr.com