容器世代下的DevOps
鲸🐋了
9102年你说你不认识这鲸鱼我是一万个不信~
容器给我们带来的不仅仅是干净且隔离的运行环境，更是轻量应用的最佳部署方案之一，在便捷的部署，快速的启停中，我们的开发与部署的模式已然发生变化。
于开发
如果我们简单谈外包项目或者需求明确的一次性交付的项目，自然用传统的瀑布模型管理软件过程即可，而对于抢占市场或者demo（甚至PPT）产品从预想->简单实现->产品落地这类周期的我们就需要谈Agile Development。
选好了软件开发模型，再对具体项目架构进行选型，而架构选型自然离不开传统的单体应用架构和如今的微服务架构的一番辩谈了。既然叫传统，自然要总结出个十个八个的缺点对其进行攻击，继而引申出微服务架构的万般好与千般妙处，但是筒子们，我们要正确意识到问题的根源，切合实际的对架构及现有应用需求进行思考并理智选型。
单体应用架构
微服务应用架构
而9102谈微服务，自然离不开容器的影响。在单一功能边界清晰的一个个应用中，需要提供的不仅仅是服务的拉起与状态的监控，容器因其提供完备的网络层及高速的启停从而解决了复杂部署的痛点，从而使开发能更加专注于业务与实现。
于运维
无论是应用承载量倒逼的服务拆分与分布式部署，还是梳理复杂业务进行逻辑清晰的应用边界划分而进行的架构迁移，在其中无可避免的都需要进行环境的迁移，而原生部署在linux主机上的应用可能存在：
- 环境清洁未知: 历史服务卸载残留文件
- 端口划分及服务上下游环境完全依赖管理手段
- 迁移服务过程需要启停
我们需要的是容器！是一个个沙盒！是用完就删的快感！是点一个按钮就能做流控、做扩容伸缩、做版本升级！是一个页面掌控全部生产状态的Paas平台！
DevOps
对于开发与运维的团队，渐渐的我们发现完全割离的组织架构及管理会给应用交付带来无尽的麻烦。软件的问题修复、应对市场添加的特性、整体优化及架构调整会带来无尽的版本发布任务并在这个过程中产生不可接受的沟通成本，而DevOps这一方法论其实更加符合敏捷软件的交付过程。
这里我们发现，DevOps是方法论，必然是通过了软件交付的考验形成的集体认知与经验总结，我们知道，如果Ops成天抱怨研发大爷而对应用架构无所了解，Dev不考虑环境成本天马行空随性架构，那么我们很难对市场交付甚至带领项目走向终结。我们需要Dev和Ops之间合作沟通成为惯例，通过构建与自动化工具使软件更新与交付更加快速、频繁与稳定，具体来说，就是如何解放在软件交付和部署过程中的效率问题，一定要拎清的是这并不是具体指选用什么工具或组合而在会议室里大打出手，而是大家实践、沟通而产出的工作习惯与方法。
而今天我们说Docker对DevOps，自然也不是布道而已，我们更多的是想知道如何去管理运营这个团队并结合工具链从而有自己的思考。
Docker于DevOps
那么容器的加入到底为我们的研发与运维带来了什么呢？
1. 更好的隔离环境
运维同志不用老是膈应研发大爷瞎用ubuntu，不懂任何线上linux环境调优一顿瞎用啦，让他自己写个Dockerfile乐意怎么弄怎么弄。
2. 随用随删
单元测试完了集成测试来一发？或者直接写ut连上数据库？不用烦恼，写上pipeline一个job一个环境，一个service一个数据库。
3. 快速启停
蓝绿发布用不起啊，50%的资源利用率，心疼啊！那怎么办？滚动发布啊，快速的容器启停配合容器集群工具实现服务持续可用的发布与升级。
4. 开箱即用的开源Paas平台
无论是kubernetes还是swarm都提供了容器管理及资源与服务监控，提供了可视化监控与页面运维，配合开源部署工具（jenkins/gitlab runner/github系列CI/CD工具）与git平台软件集成即可实现Paas平台的功能。
践行
我们生产中实现了以下工具链组成的CI/CD及Paas平台：
- 基础的docker-ce
- docker集群管理：kubernetes
- kubernetes部署、管理与监控：rancher
- 代码管理及CI/CD：gitlab + gitlab runner
以上工具链配合相应的管理及权限分配进行了敏捷迭代的软件过程实践，具体内容我们再开篇幅细细展开。
参考
DevOps漫谈之一：DevOps、CI、CD都是什么鬼？
Understanding Microservices
building microservices using an api gateway