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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 136|回复: 0

我们是这样落地 DevOps 的

[复制链接]
发表于 2021-12-25 00:11:31 | 显示全部楼层 |阅读模式
本帖最后由 FYIRH 于 2021-12-25 00:16 编辑 1 R6 P. f) Y- A; ~4 i: k  I; ~

, S# J' L5 O3 e4 o! b一、DevOps 的理解
DevOps 的概念在软件开发行业中逐渐流行起来。越来越多的团队希望实现产品的敏捷开发,DevOps 使一切成为可能。有了 DevOps ,团队可以定期发布代码、自动化部署、并将持续集成 / 持续交付作为发布过程的一部分。一句话概括就是提高生产力,快速交付。

  a. y; N: S9 g& Q6 [4 t' v
二、引入 DevOps 的背景7 ?1 F) O/ a+ ?5 F2 A, Q, S
$ P5 o9 }, h9 ?/ O7 n$ Y  x  s

4 c8 O5 |! b, L, U' ^6 W: X2.1 福禄技术栈介绍
0 r: ]3 O' z8 m# [1 h
  • 后端开发框架:基于C#的.netCore和Java的SpringCloud,少部分项目采用 Python 和 Go 开发
  • 前端开发框架:vue、react
  • 服务部署:前端站点基于 ECS 的 Nginx 部署 ,后端服务统一部署在 Kubernetes上
  • 代码仓库:Gitlab
  • 项目环境:目前有6套,开发、测试、压测、集成、PRE 和生产
    3 V. w1 ~6 p* M, W  }
2.2 后端服务的 CICD 现状. ?) o2 R0 ]' H- r
; g* W! i  k  v0 U6 L' ]! ]
粘贴上传202112250003563063..png

' I* q4 e/ y1 x
2 U3 d$ T8 T$ U: v
CICD 流程说明

+ g- w5 c& Y3 M, Q- e9 U
每一次的代码 push,根据创建的分支,根据在 Gitlab 的 CICD 文件 gitlab.yml 定义构建步骤,触发 runner,从单元测试、通过 dockerfile 进行编译和生成镜像版本、将新镜像部署到 K8S 生成 pod,然后触发接口自动化测试任务的执行

- N; V+ Q# L# j4 ?
!!#00ffff 好像缺了点什么 !!

7 }' t; i9 Y# T/ g% m
  • 初次部署应用到 Kubernetes 怎么做的?
  • 服务的 configmap 在哪里维护的?
  • 每个服务的 gitlab.yml 文件都不一样,如何维护的?
  • 应用的域名解析怎么做?
    . q6 l7 ~- O$ ^- X3 A/ Y4 P
6 t. t* ~% f; P5 f- r8 Q6 V
目前有6套环境进行管理,其中开发、测试、集成、压测都是测试人员维护,预发布和生产运维人员维护;这也就要求每一个测试人员都必须对整个cicd流程和配置绝对掌握;所以当新人入职,需要掌握整个流程才能进入项目测试中,这是一个学习成本;
7 q+ M2 A0 u0 Z7 [) {+ N1 ?0 S& O7 y3 l% g: P' J8 s1 F* H3 c1 ]

" T9 n) G  V5 y6 h0 r, I% E预发布和生产的 Kubernetes 只有运维能够操作,当有新的服务需要上线上述环境,或者 configmap 有变动,或者有时候排查问题需要查看容器日志,我们只能通过运维的工单系统描述作业操作,中间文字描述可能存在理解差异,沟通成本和时间成本很大;( Z* ?3 a( ^: K& S# u$ _( G8 `
3 t! a& B* C) t% E

" r) e7 ?# ~! ]9 {有的新应用我们去设置 CICD 的相关文件,比如 dockerfile,我们发现应用的代码目录结构各种各样,这样往往就没法套用一个模板快速配置完成。! A# l: d4 J1 c6 |
, K. @  l+ f! a6 w1 j) A1 Q; D/ Q- f
2.3 前端站点的 CICD 现状& b$ D: o; l- Z4 [4 @: H% ?0 }
. _- [0 b# T6 Q- U) k
粘贴上传202112250004197941..png
9 ^9 n2 d) t. `% n" p' D1 Q5 X
8 |6 {, P! Y+ ], p; P6 @  s$ K, m/ g& Z
前端 CICD 流程说明

5 t& ^% N* D: h" _
开发人员 push 代码到 Gitlab,测试人员通过 Jenkins 拉取最新的代码到 Jenkins 本地,然后通过 Jenkins 与服务器之间的传输管道,将要部署的文件更新到目标服务器,并触发 UI 自动化的 Job
; j  d3 U5 M; ~" e* J  M- R9 E9 ~

0 c, V2 }: P. v9 P7 `# [& I3 g完整的过程来看,也缺点内容& C* r$ E0 c1 }7 s9 o9 e7 R

4 ]3 s0 l4 Z( k7 w  r1 a$ j' t
  • 一个新的站点部署,Nginx 需要做一些配置初始化工作,比如域名、路径的配置
  • 前端的配置文件是如何管理的
    / X+ `3 ~/ t* v% J1 p7 \1 |
/ W) l; E2 ^& h3 C  c- T
跟后端应用一样,前端的 PRE 和生产环境也是运维处理,所以当一个新的应用上线我们也需要发工单,描述具体操作,然后运维执行工单;配置文件一般不会变更,所以我们在 Jenkins 推送更新文件到目标服务器的时候,将配置文件做了过滤处理。后续需要变更通过工单执行
; r/ s' f' X& C. m) w$ Y/ Y
2.3 痛点你看到了吗' w$ y( G; r" T! m9 o* r  f

- k7 [% T# A+ [! ~! a' w. p2.3.1 安全管控缺位
3 X" y# R) R8 x" z7 v, k
  • 代码安全:CICD 的起点在 Gitlab 里面,所以大家都有 Gitlab 的账号,代码安全管控缺位
  • 线上安全:线上项目部署也是通过 Gitlab 的 CICD 直接触发,审批流程缺失

    # I. p+ T* `. s# s: L
2.3.2 管理成本
  • 维护账号多:Gitlab账号、Jenkins 账号、Kubernetes 账号(本地和阿里云),每一个人员都需要上述账号,运维管理麻烦,大家每个平台维护自己的账号也麻烦
  • 工单沟通:工单编写、沟通过程花费时间较多
  • 代码规范:项目组多,微服务也多,代码框架各自发挥,无论是流程维护还是问题排查都增加了难度, d" `" K; O4 w$ E6 A
( Y" s1 }0 W7 _: T& l
三、研发管理平台(RDMS)应运而生
2 s7 f  P8 y% w& [8 ~2 |9 N, v" @1 M8 M4 R
3.1 如何理解这个平台
. u$ j; O6 a/ {6 Q8 ?) o( D
!!#ff0000 工具链到平台的转变 !!

" @% [7 O# t! q2 U3 m
当前的 CICD 是对工具链进行了打通,但需要大家登录各个工具平台操作,我们希望对工具集进行功能整合,打造一个系统平台,并且将 CICD 的技术细节进行屏蔽,开发人员能够专心进行业务需求的开发,测试人员能够专注到需求测试任务中,而运维人员能够解放繁重的工单内容,投入到服务高可用的建设上!6 r+ K1 \/ P3 v1 D; X

$ p/ ]- ~( g& M( S3.2 业务功能设计* V5 s+ ]) k/ B& H
1 H  k0 l$ V3 q2 V) q/ B5 _
粘贴上传202112250004399520..png

$ u1 s! ?1 E0 l4 r# O" q
# ?, u3 a$ w+ G0 [6 x2 ^$ \
3.2.1 功能说明
  • 项目管理:项目的创建和维护,默认提供了.netcore 的 API 和控制台,Java 的 API 和前端站点的应用初始化代码框架,开发人员开发新的应用直接根据应用类型选择对应的模板就可以在 Git 默认创建代码仓库和初始化框架代码,并自动生成应用的 http 和 https 的域名
  • 构建记录:获取 Gitlab 的 pipeline,展示所有分支的构建记录信息,可以一键跳转到 Git 仓库
  • 部署管理:部署构建的镜像到指定的环境,提供实时部署和定时部署功能
  • 容器管理:提供容器的查看功能,可以看到容器的存活状态和容器实时日志
  • 配置字段权限申请:针对 PRE 和生产环境查看配置,需要先走钉钉审批申请流程
  • 配置信息:进行配置的维护,包括新增、编辑、删除,PRE 和生产环境操作需要钉钉流程审批
  • 操作日志:针对应用的操作日志记录
  • 用户设置:在使用 rdms 前,需要先将用户 git 仓库的 token 设置在 rdms 上,这样用户在 rdms 操作与 Gitlab 相关的业务才能正常使用
    ' Q# D+ n9 Z# l) P4 s6 t
5 i9 i, @/ X+ ^5 k, Z+ O
3.2.2 RDMS 几个核心页面的展示+ X% r( k* R2 T6 [- d( A
首页-创建应用
. o$ w0 {, T& w: `8 S! ^, j0 r
粘贴上传202112250004576856..png
6 @3 d# [$ Y: S" k; c& x1 u
构建记录
, g! N& m- V0 D2 v) _2 M; @( h
粘贴上传202112250005122170..png
$ h" ?0 M% t( [3 K4 g
部署管理
6 `2 f/ _4 x; O. c+ I2 U. Y
粘贴上传202112250005296557..png

6 D8 @+ ~. }  M% K' L/ N# q  Q
容器管理
  o0 l$ q) V/ B! r* z: V, J
粘贴上传202112250005494344..png
" x1 ~' \+ o! k% B9 U  Z2 n6 W. d
2 y$ b6 B/ q# d2 ]& Q2 R- M
3.3 技术架构
3 ~, G% f. J  r' T2 c
. \! @1 g5 v9 [- F; h
粘贴上传202112250006076138..png

/ d" ?0 Y  _; z" T* X
, n7 f2 l2 M4 B7 Y! g
对接系统的说明
- c( C4 l# M( a  D
  • 通行证: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 的接口,进行前端站点文件目录的维护+ C& Z2 X+ r: q% z" G9 [) ^. c
  o' C- Z5 t  c  T9 w
3.4 后端应用的 DevOps 实现详解+ d% o# ]) p9 O9 _5 u2 x

6 I' M  \" ~& R0 p
粘贴上传202112250006309540..png
5 l. Q+ s6 T/ V; o1 z$ ~. k

1 I, ]$ S6 U( v1 c/ H  T, p& m  ^  U
举个栗子进行介绍

1 v# N; M: h) k) A
根据模板,创建一个应用

3 X+ v- i3 r- a8 S9 i
粘贴上传202112250006495112..png
' T2 L* X$ l; j1 A
根据名称默认生成域名

* ~( @0 r4 _2 I- ]# F( A! R9 X4 l
粘贴上传202112250007088679..png
! V% |, r* S7 V- P; A$ a" @
初始化代码仓库,默认生成 Develop 分支
/ L7 d( n- n2 P: H3 y
粘贴上传202112250007439869..png
; l, \5 i9 ]" L( I8 X* h
在 rdms 第一次部署到对应环境(开发、测试、生产等)时,会默认读取 appsettings.Development.json 的文件,并写入 kubernets 的 configmap

: Q% o  e' c3 |2 u+ X, z5 G' Y! c
构建完成,进行部署
; Q8 J0 j& U' P& x
粘贴上传202112250007591562..png

3 n' n+ \9 O5 o' L
0 m1 m) P& M! o9 U" G

0 U) p! ]3 Q( k
在 kubernets 生成 pod

+ }, [" Y9 J) y: M) Z& b) e: T
粘贴上传202112250008142339..png
2 g: S6 M5 p9 r& _1 ]3 k7 t

3 i% V9 W5 l6 u5 K" ]通过域名访问接口文档0 L- t% a* @8 p% }8 O$ o; G  J
! ?5 G0 l6 H) E( F6 p" _+ ^, l( \
粘贴上传202112250008302889..png

6 N' i9 H( W+ o9 l- m' O& U5 ]7 `5 ^7 u$ B

0 V* D$ Z3 |) M0 r3.5 前端站点的 DevOps 实现详解
  R9 Z  e, |3 v0 m# T: s0 r

& J% S' b$ `& Q6 y+ o/ N; J& `. }
8 s$ V$ @- {! I* J, D
粘贴上传202112250008519925..png
0 I! ?. d7 i) `& P4 m" V  F0 W% ~

) |  F  B+ i! j' z3 r; u
同样的,举个栗子介绍
5 x& W# P% V& a) @2 I4 n  m. e2 m$ w
首页-创建前端站点

8 i$ Q7 f1 Y" S  K. F1 K
粘贴上传202112250009084511..png

9 j! ?6 T  U6 h+ ~( \
根据名称生成域名

0 ^3 X& y3 w. F6 Q, [
粘贴上传202112250009435970..png
" F4 L7 ~+ I, U3 r3 `
初始化代码仓库,默认生成 Develop 分支
2 n2 |# t6 v/ \& b: R
粘贴上传202112250010031677..png
4 K# ?5 F+ C, @* V$ t5 R3 V  j

8 b4 d) Y7 ?& O6 ]7 O& \, u
- f+ x) l: o0 ^3 I
配置文件,默认生成几套环境的配置文件,站点的配置维护就是维护这几个文件

% F% `* i# n8 k# m" A! H
粘贴上传202112250010209497..png

) I# _; X2 u) o0 u$ ~. S8 A, ?' H9 ^& E5 R9 \# h. o
( S; V0 c4 d% j$ Y3 m3 c
部署应用8 O8 ]; E: {- x+ `
" x4 i! s5 j0 {; ~
粘贴上传202112250010369871..png
/ D* r+ \1 K& U7 w  P

, g5 c% ]* s9 g3 N" j- u, `* R) o8 I( Y& G" r" ~& u5 _
Kubernetes 的 nginx 容器内可以看到部署的文件,实际就是挂载的 oss 到该 pod 上
6 [4 p% N& h% _  u& U
& g4 ~5 w+ O/ Z$ _# |4 v
粘贴上传202112250010538240..png

. P# \, X2 X- c5 R& w' }
1 _  V+ R  P! R2 n' x6 y/ H/ n' \& ^: I2 ^8 W
(转自福禄渣渣辉)
. ~! h8 k+ m: B/ L' ^1 O+ I
9 y# r3 N" \. i7 `, H$ \% C  Y# ^7 a) r) W# V
  g% g9 u( z  d4 B! `! \

' u! q3 L3 [( F$ H
. m# P3 C# W9 i
0 H# Q$ R% I2 H0 x) M0 N, N




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

本版积分规则

参加 ITIL 4 基础和中级专家认证、v3专家升级、DevOps专家认证、ITSS服务经理认证报名
本站关键字: ITIL| ITSM| ISO20000| ITIL培训| ITIL认证| ITIL考试| ITSS| ITSS培训| ITSS认证| IT运维管理| DevOps| DevOps培训| DevOps认证| itop| itil4| sre| 开源ITSM软件

QQ|ITIL先锋论坛 ( 粤ICP备11099876号 )|appname

Baidu

GMT+8, 2022-1-20 19:19 , Processed in 0.113148 second(s), 31 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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