TNO:CI/CD与微服务架构

Rancher大大减少了TNO用于管理容器和开发代码的时间,从而让TNO可以将更多的时间用在那些造福于社会的研究项目上。

关于TNO

TNO(荷兰应用科学研究组织)是一个独立组织,它旨在连接人与知识,创造能够以可持续的方式提升社会福祉的创新项目。TNO雇佣了2600多名专家,研究领域涵盖城市化中的工业和能源、健康生活以及安全。

势在必行的容器使用

TNO的研究人员与其他公司、政府和研究机构的利益相关者都需密切合作。TNO做项目的时候,团队成员经常使用他们自己偏爱的工具和编程语言,早期工作阶段也是使用他们自己的原型设计和开发环境。在使用容器之前,TNO的研究人员发现把团队成员的开发工作转移到生产环境中是件非常麻烦的事儿。

“我们发现和虚拟机不同,如果我们使用微服务架构和Docker容器,我们就能确保我们的软件不论是在研究人员自己的机器上还是在生产机器上都能以完全相同的方式工作。”TNO的创新科学家Johan van der Geest解释说。“将东西打包并且将其从开发环境转移至生产环境有着极大的好处。”TNO的创新家Mark Bastiaans。

一个更全面的容器管理解决方案

TNO刚开始使用容器的时候,研究人员发现他们需要更多与容器相关的功能,包括跨主机网络、集群管理和服务编排。“偶然发现Rancher是因为我当时正在寻找一个可以跨主机工作的容器管理解决方案,” Bastiaans说,“然后我们发现了Rancher,它真的让我眼前一亮,印象深刻。”对于那些需要多主机、在一个服务链中设置几个微服务的项目,“我们需要看它如何伸缩,而Rancher漂亮地填补了其间的缺口。”

随着Rancher的容器管理解决方案不断发展,“我们一直保证我们的Rancher环境是最新版本,因为它的功能总能给我们带来很多好处。应用服务目录加进来了,还有负载均衡,这些都被用于了我们的项目中,” van der Geest说。而今天,“Rancher对不同编排工具的支持——Kubernetes, Swarm, 还有Mesos——让我们得以选择能满足某个特定项目的需求的框架。

Rancher的自动化CI/CD

“在使用Docker之前,我们已经在项目中应用CI/CD了,”van der Geest解释道,“但Rancher真的是在持续集成开发方面给了我们很大的帮助。我们可以将开发环境与生产环境隔离,并且。我们利用Rancher API来自动启动升级服务,开发人员只需把代码推送到Git中央仓库,几分钟之后它就被自动创建、发布并活跃起来了。”

TNO的研究科学家Edwin Harmsma说:“Rancher让我们可以实现完全自动化的集成测试,并且通过命令行界面,将自动化堆栈从源代码转变到部署。” van der Geest补充说:“我们现在可以非常迅速地将持续集成应用到新的和现有的项目。创建开发和生产环境,以及在这些环境中升级服务所需要花费的时间被大大减少了。”

“下一步我们要在更多的项目中使用我们的解决方案,并且展示我们在持续集成方面的真正能力。” van der Geest如是说。

微服务,和更快的研究速度

“Rancher非常棒的一点在于,微服务的整体概念都被很好地可视化了,这对于尚不熟悉它、又想要开始使用它的开发者来说非常的好,” Bastiaans说道,“研究人员在选择什么工作语言方面是很固执的,但如果你向他们展示了完整的堆栈,你就能让他们愿意打包他们在容器中做完的东西,这也会让他们更加清楚地体会到微服务的好处。”

“有了Docker和Rancher,我们可以让更多的研究人员开始使用微服务,并且让他们可以用他们最喜欢的语言做开发工作,” Van Der Geest说,“我认为这是一件非常有益的事儿。” Van Der Geest还对将现有软件容器化、以及用Rancher的catalog功能在不同环境中快速部署软件很感兴趣,

“对我来说,整个‘容器变革’就是关于如何在更短的时间内完成更多的东西,” Bastiaans说,“作为一个研究机构,我们一直都主张要尝试新鲜事物。如今我们已经有足够多的信心,将容器运用到生产环境中的更多项目里去。”

原文来源:Rancher Labs

时间: 2024-08-25 06:37:21

TNO:CI/CD与微服务架构的相关文章

微服务架构的优势与不足-1(转)

「Chris Richardson 微服务系列」微服务架构的优势与不足 Posted on 2016年5月4日 编者的话|本文来自 Nginx 官方博客,是微服务系列文章的第一篇,主要探讨了传统的单体式应用的不足,以及微服务架构的优势与挑战. 转自http://blog.daocloud.io/microservices-1/ 作者介绍:Chris Richardson,是世界著名的软件大师,经典技术著作<POJOS IN ACTION>一书的作者,也是 cloudfoundry.com 最初

微服务架构设计

微服务 软件架构是一个包含各种组织的系统组织,这些组件包括 Web服务器, 应用服务器, 数据库,存储, 通讯层), 它们彼此或和环境存在关系.系统架构的目标是解决利益相关者的关注点. Conway’s law: Organizations which design systems[...] are constrained to produce designs which are copies of the communication structures of these organizati

微服务架构(Microservices)

说在前面 好久没写博文了,心里痒痒(也许是换工作后,有点时间了吧).最近好像谈论微服务的人比较多,也开始学习一下,但是都有E文,看起来半懂不懂的. Martinfowler的<微服务>,也算是入门必读了.有人翻译过,但是只有一半.还是自己练练手吧. 微服务 "微服务架构"一词在过去几年里广泛的传播,它用于描述一种独立部署的软件应用设计方式.这种架构方式并没有非常准确的定义,但是在业务能力.自动部署.端对端的整合.对语言及数据的分散控制上,却有着显著特征. "微服务

MicroService 微服务架构模式简述

原文是 Martin Flower 于 2014 年 3 月 25 日写的<Microservices>. 本文内容 微服务 微服务风格的特性 组件化(Componentization )与服务(Services) 围绕业务功能的组织 产品不是项目 强化终端及弱化通道 分散治理 分散数据管理 基础设施自动化 容错性设计 设计改进 微服务是未来吗 其它 微服务系统多大 微服务与SOA 多语言多选择 实践标准和强制标准 让做对事更容易 断路器circuit breaker和产品中现有的代码 同步是

net的微服务架构

net的微服务架构 眼下,做互联网应用,最火的架构是微服务,最热的研发管理就是DevOps, 没有之一.微服务.DevOps已经被大量应用,它们已经像传说中的那样,可以无所不能.特来电云平台,通过近两年多的实践,发现完全不像大家说的那样简单,大家是报喜不报忧,实在是水太深,谁做谁知道.今天就与大家分享一下在微服务架构+DevOps下,开发测试环境的一些运维痛点问题和解决方法. 架构的复杂度直接决定了运维的工作量,架构不是越复杂越好,而是适合最好.下面简单说说几种架构的优缺点.基于.net在搭建应

基于.net的微服务架构下的开发测试环境运维实践

眼下,做互联网应用,最火的架构是微服务,最热的研发管理就是DevOps, 没有之一.微服务.DevOps已经被大量应用,它们已经像传说中的那样,可以无所不能.特来电云平台,通过近两年多的实践,发现完全不像大家说的那样简单,大家是报喜不报忧,实在是水太深,谁做谁知道.今天就与大家分享一下在微服务架构+DevOps下,开发测试环境的一些运维痛点问题和解决方法. 架构的复杂度直接决定了运维的工作量,架构不是越复杂越好,而是适合最好.下面简单说说几种架构的优缺点.基于.net在搭建应用时,最常用的方法就

为什么Docker适合微服务架构?

微服务架构日益成熟,不但得到了初创公司和创新型公司的认可,一些传统企业也在逐步接受微服务架构.我们仍然在学习如何利用其在扩展性,易于维护和构建等方面的优势.当然我们也必须承担微服务增加的成本,比如从SOA架构的迁移,编排,备份,以及对技能提升的需求等等. 一个典型的微服务架构可能是这样的: Touchbase,一个Node.js写的应用作为技术栈的核心: Nginx,作为Touchbase节点的负载均衡: Couchbase,作为数据层: Consul,服务发现: Containerbuddy,

从 Spring Cloud 开始,聊聊微服务架构实践之路

[编者的话]随着公司业务量的飞速发展,平台面临的挑战已经远远大于业务,需求量不断增加,技术人员数量增加,面临的复杂度也大大增加.在这个背景下,平台的技术架构也完成了从传统的单体应用到微服务化的演进. 系统架构的演进过程 单一应用架构(第一代架构) 这是平台最开始的情况,当时流量小,为了节约成本,并将所有应用都打包放到一个应用里面,采用的架构为 .NET SQL Server: 表示层:位于最外层(最上层),最接近用户.用于显示数据和接收用户输入的数 据,为用户提供一种交互式操作的界面,平台所使用

百度“百老汇”架构师深刻透视微服务架构

首先解释这个"百老汇"=百度老年架构师活动中心.......什么是微服务首先微服务并没有一个官方的定义,想要直接描述微服务比较困难,我们可以通过对比传统WEB应用,来理解什么是微服务.传统的WEB应用核心分为业务逻辑.适配器以及API或通过UI访问的WEB界面.业务逻辑定义业务流程.业务规则以及领域实体.适配器包括数据库访问组件.消息组件以及访问接口等.一个打车软件的架构图如下: 尽管也是遵循模块化开发,但最终它们会打包并部署为单体式应用.例如Java应用程序会被打包成WAR,部署在T