开发者社区> 晚来风急> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

中小企业基于云的自动化运维实践二则

简介:
+关注继续查看

案例1:基于云的运维自动化

我们是小规模的公司,搭建在 AWS 上的服务,主要使用 Ruby on Rails,并实现了应用的水平扩容。

在专案一开始的时候只有一台 EC2 就可以跑了,后来因为专案越做越大,开始做平行扩充以及 SOA,因此我们导入了 Chef 做自动化运营,主要使用 Chef 做机器的安装及部署,使用 Cloud Watch 做机器与 Application 的效能监控,在每次 deploy 的时候做AMI,当资源负担到达设定值时,Chef 会使用最新的 AMI 开一台新的机器加入 ELB,这个过程大约是 5 分钟,于此我们做到了 Application 面的平行扩展。

数据库的部分,我们使用 PostgreSQL 做集群,一台 Master + 多台 Slave 加上 AWS 本身的 muti-AZ 机制,可以动态加开 slave 以及 load balance;Redis 的部分亦同。

现在我们使用 Jenkins 做 CI,每次跑完 CI 会包一个 Docker 版本来跑 staging 环境,staging 环境现在跑 docker,但现在还不敢放到 production 环境中。

案例2:关于自动化部署

我从多个方面来描述下我们广告公司运维自动化的实施情况。

编译:

我们这边RTB是用linux下的C++开发的,部署的过程中需要依赖一些特定版本的linux的运行库,而编译本身需要的库和头文件会更多,所以我们是将编译和自动部署分开的,业务需求完成编码和测试后,会将可执行文件放在指定的位置,用jenkins来调用之前调试好的自动部署脚本来进行推送和启动运行,这样能保证编译的程序相关的功能都是测试通过,且经过验证的,自动化部署之后外围还有相应的监控系统会定时扫描端口开放情况以及程序运行情况。

商务平台:

这部分是用java开发的,包管理使用maven,已经做好了关联的特定版本的jar包的管理,这部分功能就是开发测试完毕,将验证没有问题的特定版本号的svn地址提交给系统部,通过jenkins从SVN拉代码,调用maven进行编译,部署和启动,相关功能都是在运行服务器上执行。

数据:

数据部分采用了redis和tair集群,用于存储人群属性和cookie映射数据,redis和tair是通过jenkins进行部署的,数据导入是每天定时跑完画像数据后自动导入的,而数据的迁移是通过人工触发的,当部分节点数据存在问题时,外部有系统监控,发现问题,人工触发数据迁移。人工触发数据迁移是一般是在发现数据分布不均衡,特定节点负载非常高的情况下,会在后半夜触发迁移操作。

流程规划:

业务相关的程序开发之后,默认是手动部署的,手动部署时会梳理相关的流程,形成脚本,后续jenkins的自动化脚本也是来源于手动部署的脚本。

Auto Scale:

集群是auto scale的,平时会有一个最基本的机器数量配置,部署相应的程序,部署完成后不存在减机器的情况,如果有流量突发高峰和广告投放高峰,有一部分备用的机器可以快速部署,然后把流量指到新部署的机器上

规模:

目前大概用于RTB的机器有40多台高配的服务器,每台服务器上会有20个左右的进程,商务平台和展现点击收集以及计费系统,服务器有20多台机器,而后端的日志存储和人群画像部分用到的hadoop有50多台机器。

精彩观点摘录

自动化运维的本质,个人愚见就是把人解放出来,人腾出来做更有价值的事,事不会少,但产生价值的事要越来越多,其实从某种程度上面来讲,对运维人员是一个悲剧,如果运维人员不提升自己的核心竞争力,那就面临着下岗,在老板心目中,机器能更快更好的做好,为什么需要人来做(慢,不能量化)。当然反过来说,运维人员就要在老板面前找到自己的价值。

自动化运维,我更关注人。

基于公司实际情况,制定完善的流程,把重复的工作工具化,有挑战的工作简单化,相应的流程及工具文档化。总之尽可能不需要人为干预,即便需要人操作,懂点技术的员工按流程和文档即可完成操作。

Q & A

Q1:数据集群采用Jenkins部署是否存在不妥,是否违背了编译和部署分开的原则?

其实数据集群用jenkins部署主要是编译的基础环境是一定的,可以在使用jenkins部署之前完成机器系统安装之后会将相关的编译环境也批量安装好,所以用jenkins部署是没有问题的。

Q2:Jenkins在里面用得太重了,不知道会不会导致CI慢或其它问题?

其实不会,因为子系统划分是将对比较轻的,不会有非常复杂和耗时的编译。


本文作者:董伟/付海军

来源:51CTO

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
10分钟手把手教你用Android手撸一个简易的个人记账App(二)
接下来就来讲解,如何从0到1实现一个简易的个人记账系统。
51 0
网易云音乐基于 Flink + Kafka 的实时数仓建设实践
本文由网易云音乐实时计算平台研发工程师岳猛分享,主要从以下四个部分将为大家介绍 Flink + Kafka 在网易云音乐的应用实战: 背景、Flink + Kafka 平台化设计、Kafka 在实时数仓中的应用、问题 & 改进。
21498 0
基于OpenStack构建企业私有云(4)Nova
Nova是OpenStack最早的两个模块之一(另一个是对象存储)。在OpenStack体系中是计算资源虚拟化的项目。同时Nova也是OpenStack项目中组件最多的一个项目。
417 0
基于OpenStack构建企业私有云(4)Nova
Nova是OpenStack最早的两个模块之一(另一个是对象存储)。在OpenStack体系中是计算资源虚拟化的项目。同时Nova也是OpenStack项目中组件最多的一个项目。
319 0
Unity 捏脸整理及基于骨骼的捏脸功能实现
目前实现捏脸功能的方式主要有两种。一个是Blendshape(融合变形),一个是基于骨骼驱动的方式,通过修改骨骼矩阵(bindpose)来影响SkinMesh。这两种方式的最终原理都是在shader 生效之前修改顶点。
3164 0
新功能-负载均衡SLB推出API Inspector功能,力助快速实现运维自动化
随着云计算如火如荼的蓬勃发展,越来越多的用户开始投入云计算的怀抱。用户们会发现相比传统的IT基础设施,云计算通过SDx(Software Defined Everything)技术,提供了大量传统IT基础设施无法想象的神奇能力,这些能力都构建在API基础上。
1485 0
《UNIXLinux程序设计教程》一1.9 思考与练习
本节书摘来自华章出版社《UNIXLinux程序设计教程》一 书中的第1章,第1.9节,作者:赵克佳 沈志宇,更多章节内容可以访问云栖社区“华章计算机”公众号查看。
856 0
《UNIXLinux程序设计教程》一2.10 思考与练习
本节书摘来自华章出版社《UNIXLinux程序设计教程》一 书中的第2章,第2.10节,作者:赵克佳 沈志宇,更多章节内容可以访问云栖社区“华章计算机”公众号查看。
1111 0
半自动化搭建Data Guard的想法和实践(二)
关于半自动化搭建Data Guard,自己花了一些时间,总算是把这件事情继续推进了一下,还是再啰嗦一句,为什么不自动化,因为安全。主库就是主库,任何变更都要手工检查审核,自动化的工作在备库和中控端来完成。
857 0
+关注
文章
问答
文章排行榜
最热
最新
相关电子书
更多
云上自动化运维(CloudOps)白皮书
立即下载
企业级基础设施专场-飞天基础设施智能运维_何诚
立即下载
企业级基础设施专场-实现规模化、自动化的云上IT管理_张子轩周剑
立即下载