本帖最后由 adminlily 于 2018-11-18 15:50 编辑 8 H, _9 P3 Z3 C: e8 {: `1 M
9 l2 q2 b0 _- }, e
) `! j0 e8 j, T) m4 ]9 G$ E6 \& O
武林前辈练就此功以克西毒蛤蟆功，小辈独自修行DevOps六脉神剑，只为在互联网圈求得一席之地，时而克制开发人员的挖坑综合征。 . c s9 O/ s' v) V% Q
\; {" p3 F* e+ @
此处的Devops六脉神剑就是鄙人自己理解的、我们自行研发一个具备物理部署和容器发布应用的双模式平台。从管理配置底层基础设施、到环境配置隔离、经过应用版本管理达到应用正常发布，到一体化监控整个系统正常运作。
5 l j5 @( L+ F% E# y0 S; J
5 n2 @/ f+ ` w+ Y/ l
第一脉 $ R/ i6 t2 m8 h
0 G2 L5 ^( U/ S9 s) U
混合模式核心经 ) C' [7 h3 Q6 j) O
$ H1 b- I9 L1 ~; o6 L
此乃神剑之核心思想，打通开发工程师任督二脉，有一个清晰轮廓，方便规划时间，制定开发工作计划。 , ?) v* ?0 {/ d. i
+ h7 n3 ^: N, M9 W" i# ?& ^
此脉起于物理机群，出属于一线运维，向上出发，到达我们的双模式应用管理平台管理领域。 & J2 ~" Y0 i8 c, ^- j( ^ o5 ]' p
0 c6 _' R, f, c1 P4 v# a6 P N
总体架构如下图所示： - H* K: b1 g( B& C0 M
! H3 Q6 P0 I) }4 j
+ Q9 {( F4 z0 k* z7 S, `+ P1 B6 \
) y8 y' X( v$ v' N0 l
在容器版本的基础之上基于Docker Build-Ship-Run的核心模型实现向物理部署模型映射，实现容器和物理的双模式管理。
8 {, U: Y/ ^5 l' T; L/ ^' o% g
/ {* X$ S5 p4 m. X2 d, p
第二脉
# @6 v0 n7 r% c! F1 T' D9 ~3 u J
( ?4 j% x) x6 ^4 S9 A% |, p基础设施管理经
7 ~1 ]6 t7 ?9 B' w0 `( N( C
. {% {+ R3 L# K! A- i
从核心经出发，了解底层物理主机的配置，做好环境准备工作。从双模式出发，将容器和物理部署通过分支实现过滤选择。如下图整体流向处理。容器模式则选择容器方式处理；物理方式即为物理部署模式。
6 I1 A: b. V: E8 e6 \: L- A ^
/ K9 ~" p# R; l. \+ h) x
: ^6 U# ^6 [4 I8 C3 @
7 i7 h- M! S; T
6 R: s; g7 {$ u# I& ~1 v( C第三脉
/ w! t. F, M' f, S" O& X1 D
9 y5 W8 i# u, _# } s5 h% l) D环境隔离经
* @. @- t# y3 D9 R4 V
/ g. q# A6 }% N% ~
无规矩不成方圆，环境隔离可以理解为不同生产之间都需要一个安静的空间自己运转。此脉可以引用博云公众号中“环境定义下，软件的生命在哪里？”来解释，一种独立物理（逻辑）分离。此处不是懒得写明，可以理解为另一种方式的宣传，这就是团队，从文章宣传做起。
* {2 q& p9 M% i. Y$ T k" w% m. H
! z3 q5 V( \ I# q% u" u2 \: K
第四脉 - `. A$ f& S/ b
/ }7 l- e d: M m$ H- A" `/ x/ D8 ^应用版本管理经
( G7 D6 y5 y: |
2 g, O( M8 z. v% q. b$ A, {" J
定义完物理和容器仓库之后，在应用版本管理时也按照两种部署方式来管理应用版本。不同模式下，使用不同的仓库来进行版本发布。 & P$ w2 J$ ?; S4 J' `
# H' N6 ?0 f0 V) N" c
r9 L2 `+ d: h, m5 v7 e
% I4 n* @, _; l. m$ F5 V: X3 y' D
第五脉
$ C" y' |& R9 P2 H3 q* l4 }1 g6 Z/ v0 r4 z, d& e: C
应用发布经
+ [/ ^! I/ ]' n6 u3 {" |! z
" d% J5 t' B( G- c- w6 ~4 ?/ d) [
前面基础部分做完之后，需要为应用做准备，这也是底层准备的终极目标——应用发布万无一失。混合模式下，如何将应用发布做到准确无误呢？依旧采用示意图的方式来做个说明。
0 [3 a8 V" Q1 d' l+ J' u% D4 F
( T" {5 Y: l' P5 T9 q6 l
0 G% I) M# d" T+ s7 W) G' a/ v! e+ A& u% g
8 F; \: X; |/ B3 V! [+ y- y' h% v. ]
正如上图所示，容器和物理模式下的发布要根据各自特色走不同的发布路线。 0 X' h; U6 N$ S* x/ f" m+ ~
2 S8 S/ n! Y* E! u
第六脉 ; G& w! a( E2 W# V8 A* `8 o9 Z. V& N
& W, c& U g" y" L, L4 D一体化监管经
- I8 z6 A( h# P2 p
$ R) v/ E/ W' l# |
前五脉打通之后，对整个系统进行监控这就是第六脉的精髓所在——zabbix。
1 Z R5 Z/ p+ x& p# t4 p
4 Q" W% d1 K9 k E' f1 b
Zabbix是一款规则驱动，具有数据过滤能力的开源企业级监控方案，此处主要围绕数据采集优化和Zabbix性能优化配置展开。
9 S2 J. r L% C# ~' f1 }: ~- k& l
, }1 t; p7 Q5 `; U! m+ L' h, {
% p4 q$ s7 F/ [" }$ j8 V& y1 B7 T; {! f$ ~- V& Q4 k; |9 {% J
优化配置操作系统和Zabbix参数可支撑不少于百台物理节点、万条级别监测项。其中，数据合并自主研发，采用Agent主动向Zabbix Server发送机制。 / L3 |0 I: c; G0 d/ B) l+ N+ a' z$ j; y
+ N5 W v$ s& |. h! d
q. a; S7 K( T, X/ W% o" n$ J; G
2 H5 I2 V/ y7 [& s
, G& u4 X3 A/ W& Z ^
Zabbix可监控物理机、容器、分布式系统和应用。其中，对容器、分布式系统（Redis、Zookeeper、ActiveMQ）监控采用数据合并优化策略。平台web界面监测显示通过后台获取zabbix监控数据来显示给用户。
3 l, R( P5 ^5 g) B
# j( F8 b! q. o7 Y
下图为Zabbix监控整体结构图：
& W2 a) f, u N5 W
. E! r# T( `, A3 ~% d% `+ o3 _
9 x4 m4 j) ]+ R
到此，六脉神剑讲解完毕，从最初的功能完成，通过测试，到最后和客户沟通，检验是否达到了DevOps的设计目标，才能算是完成“六脉神剑”的一轮修炼，而经过一轮轮的修炼，才能练就一套能够经受住实战考验的神功。 2 _% x2 i7 ?8 X8 E1 e: n( w% L2 _# V
$ f1 e# ^2 U$ w5 n; B* M0 h# p
此六脉只是个人疏浅的理解，还请各位IT大神赐教。另外，尤其感谢吴恒师兄的指导。 S9 V4 i+ U5 A8 @! [
+ l% _! n* y" d; R) R
原创： 王雪晴 ' C+ f5 j% a$ ^( Z# m8 B
| 
窥视卡
雷达卡
发表于 2018-11-18 15:47:57
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
显身卡
