去年，CloudBees团队参加了第一届DockerCon Hackathon年度竞赛，并获得了前三名。今年，我和尼基尔又参加了一个更大、更糟糕的黑客竞赛，这是多克巨大发展的证据。工作原理40多个由1-10名黑客组成的团队花了24小时从无到有地完成一个项目。提交类别：使用Docker构建、发布和运行酷应用程序管理和操作：日志记录、监视、UI/Kitematic、开发工具、部署、CI/CD、统计信息等编排：组合、调度、集群、服务发现、高可用性、负载平衡等安全性、法规遵从性和治理：授权、来源、分发等资源：网络、存储API等每个人都提交了一段2分钟的视频，并选出了10支参赛队伍，评委们选出了前3名作为获奖者我们的计划CloudBees的存在是为了帮助人们更快地交付更好的软件。我们想展示Docker如何与软件交付生态系统中的其他工具相配合。作为我们自己软件的专家，我们决定使用CloudBees产品将所有东西联系在一起—加速端到端连续交付，使用：cloudbeesflow–一个编排工具，从提交到生产充当单一的玻璃面板CloudBees Accelerator—一种加速工具，通过将构建和测试分布在一个CPU集群中，极大地加快了构建和测试的速度去年的项目集中在持续交付管道的构建阶段，而今年，我们关注的是集成阶段。我们构建了一个部署流程：在EC2或OpenStack上动态启动VM运行Docker Bench进行安全测试从Bintray和Docker Hub检索工件建立运行应用程序的链接MySQL和Wildfly容器运行分布在集群中的Selenium测试将一些统计数据推送到仪表板如果测试成功，则自动关闭虚拟机。部署过程和各种技术需要在24小时内完成！但是我们已经准备好去完成这项任务了，因为这张不太漂亮的图表在一张纸上划过，我们就要开始工作了！ 我们建造了什么我们选择了一个名为Heat Clinic的示例web应用程序，因为它有两个活动部件（应用服务器和数据库），这使它成为一个比较现实的示例。在CloudBees Flow中定义的连续交付管道对于这个hackathon，我们关注的是集成阶段。不过，了解管道是什么是很重要的，确保自动化部分是可重用的，知道它们如何被重用是关键。记住这一点，我们构建的所有东西都可以轻松地插入到生产（或任何其他阶段）。下一步是对应用程序进行建模。Heat Clinic应用程序有两层，一层用于web应用程序，另一层用于数据库。每一层都有一些不同的组件（构件）——Docker Hub的Wildfly/MySQL容器、web应用程序的WAR文件、配置文件、SQL初始化脚本，我们定义了层、组件和部署或取消部署每个组件的过程CloudBees Flow中定义的应用程序模型下一步，我们定义了协调一切的部署过程，这个过程与前面所示的图表非常一致：启动动态环境，运行安全测试，检索所有工件，建立容器（按正确的顺序），运行Selenium测试，然后撕裂如果一切都成功的话。在CloudBees Flow中定义的部署过程—我们组装起来的Selenium套件需要很长时间才能运行，我们意识到这对于Selenium来说并不少见。因此，我们使用CloudBees Accelerator加快了Selenium测试套件的速度。通过将101个测试分发到两个4核虚拟机上，Accelerator使用其专利的秘密酱汁对单个核心进行并行化和运行测试，将总时间从>27分钟降到