本周，我有幸与当地维加斯码头工人社区闲逛，并在拉斯维加斯码头工人会议上发表了讲话。离开湾区，在光明之城与开发人员、运营人员和DevOps从业人员共度时光，真是令人耳目一新。感谢InfoSiftr的人培养了这样一个协作和开放的社区（当我演示Kubernetes而不是Docker Swarm时，他们甚至没有退缩！）我演讲的目的是讨论容器和容器驱动的体系结构（如microservices）对持续交付可能带来的一些挑战，并演示CloudBees Flow中针对这些问题的一些很酷的特性。等等……挑战？容器？我认为容器、库伯内茨和微服务等新技术是一颗银弹！？嗯，正如人们常说的那样，一件事的最大力量也可能是它最大的力量弱点。为什么容器有利于CI/cd容器的好处是显而易见的，尤其是在与一个满是Docker用户的房间交谈时。容器提供了比vm或传统应用程序更快、更便携的部署应用程序的方法。它们还确保了跨环境的更高一致性，使部署更加可靠和可重复。像Kubernetes、Docker Swarm和Mesos这样的容器协调器提供了额外的负载平衡、网络和服务发现功能，这些功能进一步增强了容器的好处。所有这一切意味着开发人员和架构师可以在诸如微服务这样的新体系结构的基础上创建更细粒度、分布式、冗余和基于服务的应用程序。很明显，我不必花太多时间向码头工人爱好者兜售集装箱的好处。但是CI/CD的好处（我们如何构建和发布代码）有时很少被讨论。一些关键好处环境一致性使左移和释放更可靠代码。更多细粒度应用程序可以促进更小、更自主的团队，这通常会提高生产率。其中一位与会者指出，开发人员更喜欢关注他们最擅长的（编码）和他们需要完成的工作（用Jira解决一个故事）。他们不喜欢担心其他系统会分散他们对眼前代码的想法。他们必须"考虑如何构建、测试和发布代码的全局"的程度可能是一个时间消耗和分散注意力。更多粒度应用程序还可以促进将单个发布管道与每个微服务或容器相关联，允许团队设计特定于发布的单个组件的管道工具。这使得每个管道在确保应用程序组件能够成功部署到生产。It但是，需要注意的是，迁移到容器和微服务并不是一个灵丹妙药-对许多团队来说，建立和管理一堆大便有时比管理几百个微型计算机要容易得多-大便。四挑战和如何应对这些挑战正如我所说，我的真正目标是讨论一些挑战以及我们如何应对这些挑战。具有讽刺意味的是，大量数据，许多这些挑战都来自容器和微服务的优势。这里有四个关键的挑战和cloudbeesflow中一些很酷的新特性，它们可以解决它们集装箱上挑战1：应用程序复杂。整体应用程序很复杂，但微服务应用程序很复杂。复杂和复杂有什么区别？最值得注意的是，复杂系统通常不太确定，数据分析平台，这使得它们更难调试。虽然单个微服务确实更容易进行单元测试，但是基于微服务的应用程序中的故障很难修复，因为很难确定故障的来源。有一条很好的推特已经流传了一段时间，它将修复基于微服务的应用程序中的故障比作解决谋杀案的谜团。为了解决这个问题，cloudbeesflow最近添加了一个名为"智能地图拓扑"的功能，它提供了一个可视化的microservices应用程序（Kubernetes cluster等）的可视化表示，这在当今任何管理软件中都是不可能的。它显示了所有应用程序集群、pod、服务、容器的实时视图，最独特的是，每个应用程序部署到了哪些特定环境中。它还提供实时反馈，包括部署问题。这对于管理复杂性非常有帮助，因为您可以查看单个应用程序，查看其部署的环境（例如QA、Staging和Prod）以及可能存在部署问题的位置。事实上，在我最近开发一个演示应用程序时，我的web前端容器的部署仍然出现错误。直到我打开智能地图，数据中心解决方案，点击无法部署的容器，大数据时代是什么意思，查看容器详细信息窗格，我才发现出了什么问题，我前面有一个服务发现的环境变量，我忘了在部署代码中设置。简单的编辑，快速的重新部署，一切都很顺利。没有什么比用你自己的产品来解决你自己的问题更好的了问题。集装箱挑战2：管道复杂性。如果您遵循为每个微服务构建单独管道的最佳实践，然后管道的数量和复杂性将以与应用程序相同的速度增长。虽然单元测试和其他管道阶段可以保持独立，但是向左移动并在管道中更早地引入更复杂的测试和集成意味着您也将把依赖关系左移。cloudbeesflow支持管道之间复杂关系的能力有助于管理这种管道复杂性。此外，如果你允许你的团队为每一个微服务使用他们已经知道并喜爱的工具，那么你需要管理的工具将远远超过你使用一个单一应用程序所需要的工具。在这一点上，拥有一个可扩展/自适应的平台是至关重要的，它可以集成现有（和未来）工具，以增强开发人员的能力，并使您的团队跟上并利用新的趋势和技术（例如，向您的管道添加TwistLock），而不会中断其他团队的工作-流。容器挑战#3：支持传统应用程序第三个挑战是如何与基于容器/微服务的应用程序一起支持传统应用程序。大多数企业的现实是，在支持传统的、遗留的"单一"应用程序的同时，还必须实现容器和微服务的发展。管理不同的工具来构建、测试和发布这些相互依赖的应用程序不仅是一项挑战，而且将它们组成的"系统"作为一个可交付实体来管理就更困难了。这就是为什么有一个CI/CD平台非常重要，它允许您将混合应用程序与传统的和基于容器/微服务的应用程序并排抽象和建模。cloudbeesflow的应用程序模型和"管道即代码"提供了一个强大的抽象层，使之成为可能。每个应用程序组件都有特定的部署和配置自动化，但所有组件都共享一个通用的数据模型，数据更新，该模型简化了依赖关系映射，并允许复杂的部署流易于一起管理。例如，上面的电子商务web应用程序有部署为微服务的前端和后端组件以及传统的数据库组件，所有这些组件作为单个实体一起管理。当您开始查看具有数百或数千个微服务的系统时，能够安全地"放大"到系统级视图并知道"整个应用程序已成功部署"将成为一种有用的抽象。同样，能够将部署和发布目标定位到其他平台（例如，从GKE迁移到azureaks，或AWS-ECS），无需重新编写特定于平台的部署脚本，就成为确保业务灵活性和成本的有用工具管理。集装箱挑战4：将传统迁移到集装箱最后一个挑战是如何将传统应用程序分解为基于容器的微服务，这本身就是一个很重要的话题。然而，将容器快速移动到单个容器中可以为企业提供快速和快速的优势。cloudbeesflow提供了一个"提升和转移"功能，它可以从JAR和WAR文件等遗留/传统组件智能地构建容器映像。这使得团队可以利用容器化应用程序的运行时可移植性和伸缩性，而无需进行任何代码更改或重新架构工作。要实现这一点，只需创建一个新的微服务组件，并在部署阶段添加对提升和转移工具的调用。在这里，您只需指定要容器化的遗留工件（例如我的前线。战争，它可以在工件存储库中）、要针对的基本Docker映像（例如Jetty或Tomcat）以及要将新容器映像发布到的容器repo的名称/位置（例如，DockerHub-myImages/myWebFrontend），cloudbeesflow将完成剩下的工作，包括创建和构建Dockerfile，并将新图像推送到容器repo！新的基于微服务的应用程序可以将遗留组件作为新构建的容器映像部署到您选择的容器平台（如Kubernetes、OpenShift、AWS ECS、Google或Azure）。Meetup上的许多人都赞同采用分段方法实现应用程序现代化并迁移到容器。很高兴能走出去，与维加斯当地的码头工人社区接触，享受一些便宜的披萨，花时间和人们聊聊他们在DevOps旅行中的位置。要了解CloudBees如何帮助您完成DevOps之旅以及容器和微服务的采用，请查看此博客或联系我们以安排演示。