请选择 进入手机版 | 继续访问电脑版

ITIL,DevOps,ITSS,ITSM,IT运维管理-ITIL先锋论坛

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 1181|回复: 0

我们是这样落地 DevOps 的

[复制链接]
发表于 2021-12-25 00:11:31 | 显示全部楼层 |阅读模式
本帖最后由 FYIRH 于 2021-12-25 00:16 编辑 : i+ x( l$ e8 Q; d1 {: |1 }
( t: n/ o/ A- ~. c# u; b
一、DevOps 的理解
DevOps 的概念在软件开发行业中逐渐流行起来。越来越多的团队希望实现产品的敏捷开发,DevOps 使一切成为可能。有了 DevOps ,团队可以定期发布代码、自动化部署、并将持续集成 / 持续交付作为发布过程的一部分。一句话概括就是提高生产力,快速交付。

* K" y4 [" q: w5 i9 u
二、引入 DevOps 的背景
7 D- ?; O8 h- K+ V1 J3 g8 n( G# z5 m" V1 J2 o, ^- z6 F) G8 ^
4 [% }4 Z$ j# i/ ~
2.1 福禄技术栈介绍. n: `2 w( l3 r. c) t0 b+ p
  • 后端开发框架:基于C#的.netCore和Java的SpringCloud,少部分项目采用 Python 和 Go 开发
  • 前端开发框架:vue、react
  • 服务部署:前端站点基于 ECS 的 Nginx 部署 ,后端服务统一部署在 Kubernetes上
  • 代码仓库:Gitlab
  • 项目环境:目前有6套,开发、测试、压测、集成、PRE 和生产

    * t9 M$ a/ z& ]- Z- c: [
2.2 后端服务的 CICD 现状
. K, {6 m" W# Q: |, C, ~+ t0 Q% s4 |1 ^; \, Z" z$ ?
粘贴上传202112250003563063..png
9 O$ y7 }( r+ M, _) p8 K

. B$ ]( _% `; K9 P) F
CICD 流程说明

. A' Y% A! f# X3 D* f5 @
每一次的代码 push,根据创建的分支,根据在 Gitlab 的 CICD 文件 gitlab.yml 定义构建步骤,触发 runner,从单元测试、通过 dockerfile 进行编译和生成镜像版本、将新镜像部署到 K8S 生成 pod,然后触发接口自动化测试任务的执行

4 [& f3 y1 R5 U/ y: Z4 E
!!#00ffff 好像缺了点什么 !!

4 C+ |% a. ]: F" W6 @% g
  • 初次部署应用到 Kubernetes 怎么做的?
  • 服务的 configmap 在哪里维护的?
  • 每个服务的 gitlab.yml 文件都不一样,如何维护的?
  • 应用的域名解析怎么做?' S: R  x4 K. u; {4 k% R9 O' H
* u$ q! e0 }, W2 `8 V7 d
目前有6套环境进行管理,其中开发、测试、集成、压测都是测试人员维护,预发布和生产运维人员维护;这也就要求每一个测试人员都必须对整个cicd流程和配置绝对掌握;所以当新人入职,需要掌握整个流程才能进入项目测试中,这是一个学习成本;
  g* j! F" O. Z
" ?/ y* A7 ^& d. q' O
9 c# O; \; R; u$ _/ d! I4 {% e# |
预发布和生产的 Kubernetes 只有运维能够操作,当有新的服务需要上线上述环境,或者 configmap 有变动,或者有时候排查问题需要查看容器日志,我们只能通过运维的工单系统描述作业操作,中间文字描述可能存在理解差异,沟通成本和时间成本很大;8 Y) L! O9 o3 }- P1 e1 i5 y
7 W4 n) A# H5 u' X2 m* c
$ n) Z5 B9 P+ F9 H% q$ Y7 ^
有的新应用我们去设置 CICD 的相关文件,比如 dockerfile,我们发现应用的代码目录结构各种各样,这样往往就没法套用一个模板快速配置完成。
& U9 Y& R& R, j+ d+ u
! E) b( H$ H+ G2.3 前端站点的 CICD 现状
. T9 A  G+ A. @! m3 D+ p* ], L: \" p$ P
粘贴上传202112250004197941..png

; O  i' P0 f1 v6 i0 |) Z
: S% L; l& k, D! K- m' B
前端 CICD 流程说明

+ }% o# U& e  o
开发人员 push 代码到 Gitlab,测试人员通过 Jenkins 拉取最新的代码到 Jenkins 本地,然后通过 Jenkins 与服务器之间的传输管道,将要部署的文件更新到目标服务器,并触发 UI 自动化的 Job
% h' b. S9 I: m, a+ h+ s; }8 f
# U( J$ M* F/ R6 A, s; M
2 B# o2 I% \& T2 {3 F: J4 m- K0 ~3 Y
完整的过程来看,也缺点内容
8 R  y0 P$ Q- z# J$ m  C( E* r5 L0 w4 A, Y, ?, E- Y4 H5 U
  • 一个新的站点部署,Nginx 需要做一些配置初始化工作,比如域名、路径的配置
  • 前端的配置文件是如何管理的3 |8 y9 ?, `9 D; R5 ~9 _7 B

2 j/ M# Z" P  v/ e, h) Q: W! r
跟后端应用一样,前端的 PRE 和生产环境也是运维处理,所以当一个新的应用上线我们也需要发工单,描述具体操作,然后运维执行工单;配置文件一般不会变更,所以我们在 Jenkins 推送更新文件到目标服务器的时候,将配置文件做了过滤处理。后续需要变更通过工单执行
4 t* U  H9 u, }! V% K
2.3 痛点你看到了吗
7 W, h# I% M2 M& `6 v8 i4 b9 I, c0 c% ?9 ~
2.3.1 安全管控缺位
; u$ M* _( X2 L* T1 t6 @/ _
  • 代码安全:CICD 的起点在 Gitlab 里面,所以大家都有 Gitlab 的账号,代码安全管控缺位
  • 线上安全:线上项目部署也是通过 Gitlab 的 CICD 直接触发,审批流程缺失

    / r4 k7 x* u5 o2 C9 F$ Z
2.3.2 管理成本
  • 维护账号多:Gitlab账号、Jenkins 账号、Kubernetes 账号(本地和阿里云),每一个人员都需要上述账号,运维管理麻烦,大家每个平台维护自己的账号也麻烦
  • 工单沟通:工单编写、沟通过程花费时间较多
  • 代码规范:项目组多,微服务也多,代码框架各自发挥,无论是流程维护还是问题排查都增加了难度& m. o3 h! f" _3 r* q
; C' g# r2 S; v. Z7 o
三、研发管理平台(RDMS)应运而生4 ~; l! j( a. B! J
% J" k" ~' H/ K0 Y
3.1 如何理解这个平台! Q$ V/ ~6 V  m7 ~7 l- a& [# r, |0 L  @
!!#ff0000 工具链到平台的转变 !!
. K/ ?$ U% h0 \  G# Z& }0 Y) j
当前的 CICD 是对工具链进行了打通,但需要大家登录各个工具平台操作,我们希望对工具集进行功能整合,打造一个系统平台,并且将 CICD 的技术细节进行屏蔽,开发人员能够专心进行业务需求的开发,测试人员能够专注到需求测试任务中,而运维人员能够解放繁重的工单内容,投入到服务高可用的建设上!9 ^5 ?, [1 }9 h; P& i* b

! G6 }) u$ E# y% e5 \& h. U' }3.2 业务功能设计
; T4 |/ y2 F9 @1 P( c) N$ R8 d# z) Q2 F. r7 _# q1 f
粘贴上传202112250004399520..png
" f$ x( c8 Q8 o( ~8 C

, y8 N, K1 q8 N7 u3 g$ m6 x3.2.1 功能说明
  • 项目管理:项目的创建和维护,默认提供了.netcore 的 API 和控制台,Java 的 API 和前端站点的应用初始化代码框架,开发人员开发新的应用直接根据应用类型选择对应的模板就可以在 Git 默认创建代码仓库和初始化框架代码,并自动生成应用的 http 和 https 的域名
  • 构建记录:获取 Gitlab 的 pipeline,展示所有分支的构建记录信息,可以一键跳转到 Git 仓库
  • 部署管理:部署构建的镜像到指定的环境,提供实时部署和定时部署功能
  • 容器管理:提供容器的查看功能,可以看到容器的存活状态和容器实时日志
  • 配置字段权限申请:针对 PRE 和生产环境查看配置,需要先走钉钉审批申请流程
  • 配置信息:进行配置的维护,包括新增、编辑、删除,PRE 和生产环境操作需要钉钉流程审批
  • 操作日志:针对应用的操作日志记录
  • 用户设置:在使用 rdms 前,需要先将用户 git 仓库的 token 设置在 rdms 上,这样用户在 rdms 操作与 Gitlab 相关的业务才能正常使用9 g6 T  p1 ]- l# t2 b/ u

; k) R& {3 b) C2 L9 Y3.2.2 RDMS 几个核心页面的展示* Y+ o: V5 G( W: M: e
首页-创建应用

1 G) i0 m$ e( M: E- e/ n
粘贴上传202112250004576856..png
$ N$ b' ?0 X9 w  O& e
构建记录

- I( F3 G8 M& R1 O
粘贴上传202112250005122170..png
7 I5 z. C9 D4 k0 M& t+ J& v
部署管理
2 O  U# s' \2 u& Q
粘贴上传202112250005296557..png
6 R- ^6 ~  z4 Z8 k& l7 q  I  H
容器管理

! O1 a/ v1 K2 A5 V3 G1 u' Y3 c
粘贴上传202112250005494344..png

  B: B# {$ S2 i  \: D

. e: _2 t8 t6 O4 r- }* d1 \3.3 技术架构
) _# H" R9 T8 s7 O$ e* x
( [1 ?- q% @- H
粘贴上传202112250006076138..png
% V# _+ \+ _5 b8 e  \4 F5 _
' J" e$ q$ Z% I2 ]4 O0 U4 M/ P1 N6 [
对接系统的说明
. j7 i7 r, a. p& Y* f1 b- Z
  • 通行证:RDMS 的目标用户是研发中心人员,这些人员在通行证中都有默认的账户信息,与通行证打通,可以直接登录使用
  • GitlabAPI:目前 RDMS 的 CI 还是采用的 gitlab 的 ci 支撑,包括新应用在 rdms 的创建到 git 仓库的代码初始化等,都需要调用 gitlab 的 api 接口
  • 钉钉 flow:安全管控的原因,PRE 和生产的任何操作都会触发钉钉审批流,所属项目的项目经理审批通过后才会获取到数据或者执行操作指令
  • 福禄开放平台:提供了网关相关的功能和菜单、角色等维护功能,公司所有后端服务都需要入驻开放平台
  • 蜂巢:公司的调度作业平台,rdms 的定时部署功能依赖该服务的支撑
  • 运维工单系统:rdms 的 CD 流程没有直接与 Kubernetes 进行交互,而是通过运维的工单系统包装了运维底层的 shell 脚本层,然后提供给 rdms 相关的 api 接口,也是基于安全控制的考虑
  • shell 脚本层:shell 脚本层会调用 Kubernetes 的 API 进行 Kubernetes 的相关操作(部署、配置更新、容器重启、日志查看等);调用阿里云的 dns 解析接口,对应用的域名自动解析;调用 oss 的接口,进行前端站点文件目录的维护$ f0 H' K4 W& f5 ^0 [& D, \, R) g) N
* G, j6 \: C% s) T  r' J
3.4 后端应用的 DevOps 实现详解% H" o2 z) T" Q9 `& @8 n! P" Q" b
5 R% v7 H' P& \7 v' D# @0 I
粘贴上传202112250006309540..png

$ O7 H+ a  B; q$ i" [9 @4 r: A

* D4 O+ P; R; g$ P* B' t8 K4 w
举个栗子进行介绍

  g; r; G2 ^) r4 u
根据模板,创建一个应用

) n* {- a' a% q5 k1 l1 f' R$ Z
粘贴上传202112250006495112..png

$ I; K& `! f4 J) O, H; ~$ n
根据名称默认生成域名

. }: o6 w0 Z' k9 U$ A) u/ e
粘贴上传202112250007088679..png

  d  o/ j0 t9 C- z' q) O+ h* n8 F" R7 \
初始化代码仓库,默认生成 Develop 分支

* _: L+ {7 V" _! [$ A
粘贴上传202112250007439869..png

# d3 O) ^, d7 c( `
在 rdms 第一次部署到对应环境(开发、测试、生产等)时,会默认读取 appsettings.Development.json 的文件,并写入 kubernets 的 configmap
( v8 @, W6 Y; q. x! U  f2 o
构建完成,进行部署
+ W7 W" J' q. h' {5 |
粘贴上传202112250007591562..png
! i* t, U# [4 }; U4 m  ]8 B4 R4 z

- ~3 C0 A2 m/ G

0 Z) S+ k" m8 P+ B. W' p
在 kubernets 生成 pod

" y. A% H# m8 S- M! |" G
粘贴上传202112250008142339..png
% v. b% u- O3 A0 y7 y: @& @" l
( j' l  c( k: d# J. M0 m
通过域名访问接口文档
/ ^% F4 h8 A7 b& y
  O! @3 k5 A- ?6 [7 G6 L  Y
粘贴上传202112250008302889..png
8 t: i% Z$ `) w- f* u) @% D( R( p' ?

: s: w+ @5 W( E4 Z2 I3 I  R% I* P1 j- S! S' E, \
3.5 前端站点的 DevOps 实现详解

, }7 \* S1 ]$ e# E& Y1 ~( E( A
5 g  u- |4 ~; g0 D
+ B6 B/ ^+ S5 g7 P3 k4 g. v
粘贴上传202112250008519925..png

" P$ N, V: g) y
7 C9 W( j# T2 j- m* L3 g
同样的,举个栗子介绍

7 H; G. k0 c/ K3 Z) E
首页-创建前端站点
! W; J. c/ H7 Y+ @; r& L
粘贴上传202112250009084511..png
& h7 |5 c: N7 [" u# C8 f
根据名称生成域名
- F$ K, W8 k- a
粘贴上传202112250009435970..png

: i3 Y2 `: d! y. F' u8 _, \
初始化代码仓库,默认生成 Develop 分支

/ j, a. z. Q/ _- j" m5 ~0 d' X" ^
粘贴上传202112250010031677..png

" ?0 Z) s# D: S8 ^# H; o4 r' |9 |" i* ?+ h0 u  _

9 d$ n. H1 I; M: x' d. l
配置文件,默认生成几套环境的配置文件,站点的配置维护就是维护这几个文件

3 N& i+ Q, t; k& a1 k0 f* @2 N/ R
粘贴上传202112250010209497..png

9 o( i- N9 P+ [+ f6 j8 Z$ @, A9 l7 r9 C  s+ {

+ l- ?2 f- ~/ i; {部署应用
( W+ a) ^7 g: x* C! ~5 _. o
0 g. W2 G: w, j9 g' J% u# z/ d0 o
粘贴上传202112250010369871..png

4 v# n& k: q3 K# B6 f
" w1 A  F% G7 R: A6 A" b
- ]2 ?5 b6 ~/ cKubernetes 的 nginx 容器内可以看到部署的文件,实际就是挂载的 oss 到该 pod 上
% e+ y; A& G" C  z. P1 L, H" d# n
9 _/ O. t+ c7 y0 I
粘贴上传202112250010538240..png

1 I4 J4 \9 z! E7 x) H4 N* ~9 z9 s0 j6 q

& r) l8 q% o/ a2 l* a* C(转自福禄渣渣辉)
* o! f# T, G0 e; [8 L
3 s$ g" E) U# @4 U6 ~" E7 ?. C- l5 i; `9 Z4 z% _* ?
1 J7 e: q- T: D' f

. V6 Z2 Y8 \. y. B5 o/ p
2 O2 W7 z& c8 ~9 L0 \
( ~) b8 t& q, _9 Q, `4 X




上一篇:数字化转型中的 DevOps :左移能力
下一篇:数字化转型中的 DevOps:弹性合作
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 ITIL 4 基础和专家认证、长河ITIL实战沙盘、DevOps基础级认证、ITSS服务经理认证报名
ITIL(R) is a registered trademark of AXELOS Limited, used under permission of AXELOS Limited. The Swirl logo is a trademark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.

QQ|ITIL ( 粤ICP备11099876号 )|appname

GMT+8, 2022-12-7 18:26 , Processed in 0.986264 second(s), 35 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表