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

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

 找回密码
 微信、QQ、手机号一键注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 1759|回复: 0

从一张图看Devops全流程

[复制链接]
发表于 2020-1-22 08:53:54 | 显示全部楼层 |阅读模式
本帖最后由 adminlily 于 2020-1-22 09:02 编辑
! @& L, s3 ^( h7 V; _/ O
5 M0 Q+ H5 |' |

一、持续交付工具链全图


$ ]; g( ^2 _% G# i$ S$ Z! b. i

: X3 B. `, O5 p, y6 W

上图源自网络。上图很清晰地列出了CD几个阶段使用的工具。


9 f7 I) B: I( a" S  q: ?: U, t

CD的工具链很长,但并不是每个模块所有工具都那么流行;换言之,我们在每个模块用好一种工具就足够了。

) r; q' n) ^: N3 S1 _7 e# F% i) T

Build


3 a  w( }1 V1 R& i7 t

在SCM的模块中:Git系列用的比较多,如Gitlab;

9 b/ W" l4 d8 t( P- N

在CI模块中:Jenkins显然是最流行的;


9 t3 g3 _8 x& K

在Build模块中:Maven、docker用的较多;

2 d# t) v. ]/ n! p0 ?

Test

在Testing模块中:Junit、Jmeter用的较多;

0 Y/ W, H  q& a, Y; D0 i/ j& P% b

Deploy

在配置管理模块中:前些年Puppet比较火,这两年Ansible用的比较多;、

在Artifact管理中:Dockerhub是在线的,docker registry是离线的。Openshift的集成镜像仓库用的就是docker registry技术。Quay是CoreOS的镜像仓库工具,有在线也有离线的,相信后续会被整合到Openshift中。

1 Q/ w2 l4 u. ^: o& y+ \8 x. ~

Run

在Cloud/IaaS/PaaS模块中:这两年PaaS的活跃程度超过IaaS,我接触比较多的是其中的Openshift。

) T: ^6 n, W) v1 B


; Z. i& C0 T; p! Q% B

在编排模块中:K8S目前是主流,无可争议。


7 D* f( ~5 C7 D) a6 [4 L6 P

在BI/Monitoring/Logging中:EFK之前用的比较多,但大家普遍看好普罗米修斯。


% F- j3 h" T1 y, y5 E+ O3 V


$ ^+ U# T( d# }$ Y5 {- ]/ u

二、红帽的DevOps全图


7 |( T! j7 J& t& Y5 z  \4 H


+ J; o6 p, X( N4 m' D/ k

上图是一个比较典型的Devops流程。包括产品立项、需求分析、应用设计、开发、测试、持续发布、生产运维、回顾阶段。


' G+ s- M# `" [, ~

其中,Openshift可以涵盖中间5个阶段,CloudForms可以覆盖第七个阶段。只有第一个阶段目前红帽产品堆栈无法覆盖。


2 Q' S' H+ X1 {7 V1 M( x$ x( x7 a

我们将整个流程进一步技术细节化:


& Q/ ]. f$ x5 X

4 Z) g% `5 t+ l8 I: C

Eclipse IDE工具红帽官网可以下载;Gitlab、Nexus、Jenkins、Openscap、EFK这些工具,红帽官网提供安加固过的容器镜像。


& f* g- C' J! ^7 w6 I) r

而整个流程串起来,可以通过Jenkins和S2I一起完成的。关于这方面,主要有两种方式:在源码外构建pipeline部署、在源码中构建pipeline部署。


, B6 Z4 S2 ^' S- Y$ I


" Y# k; Y7 Q/ F  L/ t. k

三、在源码外构建pipeline部署应用--流程说明

3 h6 e  }8 {2 ]

在源码外构建pipeline的方式,是jenkins的pipeline调用Openshift的S2I、BC、DC等。代码构建是在Openshift中完成;


) E4 t! C/ L, X% A9 j1 z


3 {, v* k2 j/ u1 Z

本实验是根据EAP的基础镜像,构建一个基于Maven编译的应用,编译成功后,生成应用镜像,并在OCP中部署这个应用。


1 l" o4 }( `6 |  `2 U, k5 z

在在本实验中,应用代码地址库链接、应用名称的变量,通过OCP的应用模板导入;bc和dc的操作,均由ocp完成。在bc阶段,项目中会有build pod,

: @* H5 A4 b/ E# q; Q4 W! w# [4 u

3 a7 R1 a% Y: N0 x4 H9 ^

在dc阶段,项目中会有deploy pod。


7 B9 D' d$ G" d


% T; w) j* b3 P' [

为了能够通过pipeline显示阶段,在OCP中引入jenkins plugin,jenkins plugin的脚本定义了build和deploy两个阶段。而两个阶段的任务执行,分别是调用bc和dc。

+ ^' f' o6 f7 P- N


- x. x- C$ x+ K- q$ ^

因此,整个代码构建和部署,实际上均由OCP完成。Jenkins只是用来显示执行阶段。也可以根据需要,增加审批流。


6 _$ s" ~- F, X  m! }$ b0 a% D" u  I

两个yaml文件


$ V" ]4 Z/ z: o. A7 Y

创建两个yaml文件,一个是openshift-tasks-no-trigger.yaml,一个是pipeline-bc.yaml。

( J: Y; b* m! O" ~

第一个文件创建jkp-tasks引用的bc、dc、routes、rc等资源。

& p+ Y1 t- d: t2 P2 e; K& t

第二个文件创建一个pipeline,定义应用的build和deploy阶段。


+ t- }& p7 o4 Z( @2 y, [

第一个文件:

3 w& d) y& {( b; ?! w. j  Y7 O3 q

apiVersion: v1

kind: Template

labels:

template: openshift-tasks-no-trigger


, s! O+ f/ G$ w6 C1 u9 x

模板名称

metadata:

name: openshift-tasks-no-trigger

objects:

- apiVersion: v1

kind: ImageStream

metadata:

labels:

application: ${APPLICATION_NAME}

name: ${APPLICATION_NAME}


! q1 C, j  ]2 w8 q/ N; @! o, t

创建的应用image stream名称

- apiVersion: v1

kind: Service

metadata:

annotations:

description: The web server's http port.

labels:

application: ${APPLICATION_NAME}

name: ${APPLICATION_NAME}

spec:

ports:

- port: 8080

targetPort: 8080

selector:

deploymentConfig: ${APPLICATION_NAME}

- apiVersion: v1

id: ${APPLICATION_NAME}-http

kind: Route

metadata:

annotations:

description: Route for application's http service.

labels:

application: ${APPLICATION_NAME}

name: ${APPLICATION_NAME}

spec:

to:

name: ${APPLICATION_NAME}

- apiVersion: v1

kind: BuildConfig

metadata:

labels:

application: ${APPLICATION_NAME}

name: ${APPLICATION_NAME}

spec:

output:

to:

kind: ImageStreamTag

name: ${APPLICATION_NAME}:latest

将build成功的镜像打成latest的image stream tag。

source:

git:

ref: ${SOURCE_REF}

uri: ${SOURCE_URL}

type: Git

strategy:

sourceStrategy:

forcePull: true

from:

kind: ImageStreamTag

name: jboss-eap70-openshift:1.4

namespace: openshift

! q) {: Z) L% H. j

构建应用的基础镜像

type: Source

triggers:

- github:

secret: kJZLvfQr3hZg

type: GitHub

- generic:

secret: kJZLvfQr3hZg

type: Generic

- imageChange: {}

type: ImageChange

- type: ConfigChange

- apiVersion: v1

kind: DeploymentConfig

metadata:

labels:

application: ${APPLICATION_NAME}

name: ${APPLICATION_NAME}

spec:

replicas: 1

selector:

deploymentConfig: ${APPLICATION_NAME}

strategy:

resources: {}

rollingParams:

intervalSeconds: 1

maxSurge: 25%

maxUnavailable: 25%

timeoutSeconds: 600

updatePeriodSeconds: 1

type: Rolling

template:

metadata:

labels:

application: ${APPLICATION_NAME}

deploymentConfig: ${APPLICATION_NAME}

name: ${APPLICATION_NAME}

spec:

containers:

- env:

- name: MY_POD_IP

valueFrom:

fieldRef:

apiVersion: v1

fieldPath: status.podIP

- name: OPENSHIFT_KUBE_PING_LABELS

value: application=${APPLICATION_NAME}

- name: OPENSHIFT_KUBE_PING_NAMESPACE

valueFrom:

fieldRef:

fieldPath: metadata.namespace

- name: HORNETQ_CLUSTER_PASSWORD

value: kJZLvfQr3hZg

- name: JGROUPS_CLUSTER_PASSWORD

value: kJZLvfQr3hZg

image: ${APPLICATION_NAME}

imagePullPolicy: Always

livenessProbe:

failureThreshold: 3

httpGet:

path: /ws/demo/healthcheck

port: 8080

scheme: HTTP

initialDelaySeconds: 45

periodSeconds: 45

successThreshold: 1

timeoutSeconds: 1

name: ${APPLICATION_NAME}

ports:

- containerPort: 8778

name: jolokia

protocol: TCP

- containerPort: 8080

name: http

protocol: TCP

- containerPort: 8888

name: ping

protocol: TCP

readinessProbe:

failureThreshold: 3

httpGet:

path: /ws/demo/healthcheck

port: 8080

scheme: HTTP

initialDelaySeconds: 20

periodSeconds: 5

successThreshold: 1

timeoutSeconds: 1

terminationGracePeriodSeconds: 60

triggers:

- type: ConfigChange

parameters:

- description: The name for the application.

name: APPLICATION_NAME

required: true

value: tasks

: \# p( N1 d7 B

提示输入应用名称

- description: Git source URI for application

name: SOURCE_URL

required: true

value: https://github.com/lbroudoux/openshift-tasks

. i7 L: ~8 X3 v5 h4 u# i

提示输入源码地

- description: Git branch/tag reference

name: SOURCE_REF

value: master


2 O4 ~* b# [" p+ X. w% }

提示输入源码 branch地址

5 D% s$ w5 ?7 O1 W7 J5 t

  x1 G3 t# s) p9 x5 y" Y7 R9 b

第二个文件

  M+ `0 C1 Y; }& R! ~( n

apiVersion: v1

kind: BuildConfig

metadata:

annotations:

pipeline.alpha.openshift.io/uses: '[{"name": "jkp-tasks", "namespace": "", "kind": "DeploymentConfig"}]'

labels:

name: jkp-tasks-pipeline

name: jkp-tasks-pipeline

spec:

strategy:

jenkinsPipelineStrategy:

jenkinsfile: |-

node('maven') {

stage 'build'

openshiftBuild(buildConfig: 'jkp-tasks', showBuildLogs: 'true')

定义构建阶段,构建阶段是触发应用的buildConfig

stage 'deploy'

openshiftDeploy(deploymentConfig: 'jkp-tasks')

定义构建阶段,构建阶段是触发应用的deploymentConfig

}

type: JenkinsPipeline

triggers:

- github:

secret: CzgPZAZ5m2

type: GitHub

- generic:

secret: CzgPZAZ5m2

type: Generic

7 x3 d8 e0 x+ s  C# X5 C7 s6 o. A' Z

; ?* X& W- e  ~, A3 b8 X1 b

实验验证


/ |" H9 l$ Q. D

根据yaml文件创建应用模板:


1 ^- N0 s( z( C% R$ Z7 M) l+ b

% D3 e3 E4 v# X. N3 W

模板执行成功以后,应用的bc、dc、rc、vip、routes、is等资源就已经创建好了:

6 {, K4 y+ p( ?

[root@master ~]# oc get all

NAME TYPE FROM LATEST

buildconfigs/jkp-tasks Source Git@master 1

NAME TYPE FROM STATUS STARTED DURATION

builds/jkp-tasks-1 Source Git@bd32abb Running 2 minutes ago

NAME DOCKER REPO TAGS UPDATED

imagestreams/jkp-tasks docker-registry.default.svc:5000/ocp-tasks/jkp-tasks

NAME REVISION DESIRED CURRENT TRIGGERED BY

deploymentconfigs/jkp-tasks 1 1 1 config

NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD

routes/jkp-tasks jkp-tasks-ocp-tasks.apps.example.com jkp-tasks <all> None

NAME READY STATUS RESTARTS AGE

po/jkp-tasks-1-build 1/1 Running 0 2m

po/jkp-tasks-1-deploy 1/1 Running 0 2m

po/jkp-tasks-1-kj8ds 0/1 ImagePullBackOff 0 2m

NAME DESIRED CURRENT READY AGE

rc/jkp-tasks-1 1 1 0 2m

NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE

svc/jkp-tasks 172.30.58.78 <none> 8080/TCP 2m


9 E. D$ C" g- T2 e

接下来,创建jenkins pipeline:


3 X3 B( _- k. L0 E$ \


# n, A6 `/ _# {4 G. l

pipeline创建成功以后,触发pipeline执行:

Pipeline已经启动:


, Z2 S: J5 B/ b# U


% w( }" i. d/ Z

此时会生成bc pod。查看build pod的log,build pod会先拉build image的镜像,再拉代码,然后进行build,成功以后push到OCP的内部镜像仓库。


- o3 o3 K$ a8 X  R9 S( B

  @2 r' D! `' `1 O- e

pom和jar包下完完毕以后后,开始build:


+ Q0 x- d$ A' q

& f! R8 s* p1 y6 ]: ]' [

然后将成功的war包拷贝到EAP的部署目录中:


# m2 }1 I7 c, y6 C6 _

; q& |# W# Z: j' S

最后将build成功的应用镜像推送到集成镜像库:

  @* c$ W7 K5 M* b0 E


2 C! x# Y0 L$ L6 e

至此,build阶段完成。


7 ?9 p; C) v# [; X' s. H. r% ~* ?( b

- o, \( {$ z4 y* b

接下来,启动deploy过程:


; I8 n. e  }5 M; K) F1 b

4 M8 t% H2 ^1 c2 [/ X

查看jenkins的日志,deploy的阶段,就是触发dc,很快,dc执行完毕,应用部署成功。

: c; U% X( ]0 ]4 h( Y+ a. m7 }

6 i; P* ?3 V* @9 n4 b% b

查看maven的日志,maven pod在此流程中,并不做编译工作,只是监听(该pod是为了pipeline的执行为存在):

: m# T  N  B) B" X


1 _9 d9 ]% U/ H/ \; d& q

应用部署成功以后,查看routes:

" U. r. C- D) y( V* B3 W8 Q

( E: I2 {4 t( d* S' v# r

通过浏览器,可以访问部署好的镜像:


/ Z+ y( M! Q  ?4 n" F* A  V9 _


/ ?6 {' D3 A" ?$ @1 }6 b$ h


/ b0 Q  e! f! ]- q/ b

方法总结

& p4 e3 h/ r- n# r

此种武器主要利用OCP的S2I进行构建,只是通过Jenkins进行阶段显示。Jenkins的build调用OCP应用的bc、deploy调用的OCP应用的dc。当然,我们也可以根据需要增加审批流程,或者将pipeline做得更复杂。

! d5 X" C2 W* f( L* ~" z6 S

此这种方法的好处在于配置灵活。支持多用开发语言(在base image中增加不通的编译器即可)。通常情况下,红帽Openshift的CI/CD会推荐使用这种方式。


# Z  y9 X* O0 Z, J2 l' S" |

但是对于在很早以前就已经使用Jenkins做CI/CD的客户,可能会有一些学习成本。


( D6 N+ V7 N/ w8 d7 t' M1 i* v, `

2 ?! X$ W1 H2 s5 [4 y

四、在源码内构建pipeline

! F" M& @9 M, h/ q3 N5 [1 S

实验中,我们部署的是一个基于JBoss EAP base image的应用,应用代码位于git代码库。

* |. r+ K! h6 J& k" h/ z) f; D


8 g6 k9 l1 z! _3 n" U* h" p

在上图中,jenkins贯穿整个CI/CD,其中包括:

% E+ q4 f2 h# U+ l; x6 Y

获取源码----->编译----->生成应用(war包)---->拉取base image---->将应用(war包)与base image合并---->生成App Image---->部署App image。

1 d9 j, _, m: R

在本实验中,涉及两个重要的配置文件:openshift-tasks-jenkinsfile和Jenkinsfile。

( Y9 V7 i: V/ ~! ]2 D

openshift-tasks-jenkinsfile是创建Jenkins master(执行openshift-tasks-jenkinsfile的模板时,如果项目中没有jenkins的master,会自动触发部署)。

' \; l2 Z" y# f1 \) H! m- m. H* ]

! ~* b  x. V6 o0 |$ j9 ~% H1 @

- i8 Q6 a$ l4 b+ y* T# D/ t) n

而部署openshift-tasks-jenkins file模板的时候,会提示输APPLICATION_NAME、DEV_PROJECT、SOURCE_URL、SOURCE_REF这几个变量,这些变量会被注入到模板中的BuildConfig部分,并进行覆盖。


/ o* c1 N8 z, s* d


+ M8 E% N2 [6 w6 M- y' X

openshift-tasks-jenkinsfile的BuildConfig部分定义了Jenkins file的地址。

7 W6 T7 z! z0 b( H. R- c* d

7 v3 J8 y# ?0 V

openshift-tasks-jenkinsfile带着这几个参数,继续触发Jenkin file并注入参数。Jenkins file第一行注明了调用maven,因此会触发部署jenkins maven slave pod。


' p0 A$ N! S/ V4 u- b

5 w. U8 a+ L( l! D: l  @7 ]9 e6 V! ^

接下来,在jenkins slave pod中,根据Jenkins file定义的应用的'build'、test、deployInDev三个阶段进行执行,应用的bc和dc也在Jenkins File中生成,最终完成一应用的构建。


3 s, X" w$ L  G* p- z" q


& K  i3 {! c( N3 ^, o

接下来,我们先看:openshift-tasks-jenkinsfile完整的文件内容:

$ O7 W" n, s5 R: t

apiVersion: v1

kind: Template

labels:

template: openshift-tasks-jenkinsfile

metadata:

name: openshift-tasks-jenkinsfile

9 |; q0 k, P! r. P* O

模板的名称


# c+ G8 Z2 X2 F! D

objects:

- apiVersion: v1

kind: BuildConfig

BC阶段的定义

metadata:

annotations:

pipeline.alpha.openshift.io/uses: '[{"name": "jkf-tasks", "namespace": "", "kind": "DeploymentConfig"}]'

labels:

application: ${APPLICATION_NAME}-jenkinsfile

name: ${APPLICATION_NAME}-jenkinsfile

spec:

source:

git:

ref: ${SOURCE_REF}

uri: ${SOURCE_URL}

type: Git

strategy:

jenkinsPipelineStrategy:

jenkinsfilePath: Jenkinsfile

type: JenkinsPipeline

type: Generic

截至到目前,Jenkinsfile的bc定义完成。jenkinsPipelineStrategy和 jenkinsfilePath指定了这个bc阶段会调用的jenkins file的路径。

triggers:

- github:

secret: kJZLvfQr3hZg

type: GitHub

- generic:

secret: kJZLvfQr3hZg

type: Generic

parameters:

- description: The name for the application.

name: APPLICATION_NAME

required: true

value: jkf-tasks

通过模板部署应用的时候,提示输入应用的名称,默认名称是jkf-tasks

- description: The name of Dev project

name: DEV_PROJECT

required: true

value: ocp-tasks

通过模板部署应用的时候,提示输入Dev project的名称,默认名称是ocp-tasks

- description: Git source URI for application

name: SOURCE_URL

required: true

value: https://github.com/lbroudoux/openshift-tasks

通过模板部署应用的时候,提示输入SOURCE_URL的名称,默认名称是https://github.com/lbroudoux/openshift-tasks

- description: Git branch/tag reference

name: SOURCE_REF

value: master 通过模板部署应用的时候,提示输入SOURCE_REF的名称,默认名称是master。

接来下,查看Jenkins file完整的文件内容:

node('maven') {

代码构建调用maven

// define commands

def mvnCmd = "mvn"

// injection of environment variables is not done so set them here...

在此阶段注入参数变量对以下默认参数数值进行覆盖(从openshift-tasks-jenkinsfile template部署的时候,输入的参数变量带过来):

def sourceRef = "master"

def sourceUrl = "https://github.com/lbroudoux/openshift-tasks"

def devProject = "ocp-tasks"

def applicationName = "jkf-tasks"

以上代码定义了编译方式,使用maven、定义了源码的地址、在Openshift上的项目(构建在哪发生)、生成应用的名称。

stage 'build'

git branch: sourceRef, url: sourceUrl

sh "${mvnCmd} clean install -DskipTests=true"

以上代码定义了pipeline的构建阶段。调用mvn clean先清理编译环境,然后用mvn install进行构建。

stage 'test'

sh "${mvnCmd} test"

以上代码定义了代码测试阶段

stage 'deployInDev'

sh "rm -rf oc-build && mkdir -p oc-build/deployments"

sh "cp target/openshift-tasks.war oc-build/deployments/ROOT.war"

// clean up. keep the image stream

以上代码定义了在dev阶段部署操作:将编译好的war包,拷贝到 oc-build/deployments目录下

sh "oc project ${devProject}"

以上代码调用oc client,切换项目。

sh "oc delete bc,dc,svc,route -l application=${applicationName} -n ${devProject}"

// create build. override the exit code since it complains about existing imagestream

以上代码清空项目中的内容。

sh "oc new-build --name=${applicationName} --image-stream=jboss-eap70-openshift --binary=true --labels=application=${applicationName} -n ${devProject} || true"

// build image

以上代码根据jboss-eap70-openshift的base image,创建bc

sh "oc start-build ${applicationName} --from-dir=oc-build --wait=true -n ${devProject}"

以上代码执行构建,即根据上一步指定的base image,加上本地oc-build目录下的内容(ROOT.war),生成应用的镜像。

// deploy image

sh "oc new-app ${applicationName}:latest -n ${devProject}"

sh "oc expose svc/${applicationName} -n ${devProject}"

}

以上代码根据上一步生成的镜像,部署应用,并为应用创建root。

当然,在做maven编译的时候,需要用到pom文件,由于内容较多,不再贴出来,地址:https://github.com/stonezyg/openshift-tasks/blob/master/pom.xml

方案验证

为了方便理解,将所有操作步骤贴出:

首先,根据yaml文件创建openshift-tasks-jenkins file模板。

#oc create -f https://raw.githubusercontent.co ... te-jenkinsfile.yaml -n ocp-tasks

; o3 z, \' N: ^( }. s( r! S0 J

接下来,通过模板部署jenkins master:


: J/ W- h& l# U; Y3 ~3 d/ E

/ X% g( F0 ]2 \8 z

! |, j% b3 d+ p0 s

提示输入参数变量,这些参数,就是最终会传到Jenkinsfile的jenkins slave pod中的。这里,我们使用默认参数值。


$ G- m3 [' F1 a9 u; _+ A


! Y2 V. A' L- C/ i/ q/ P

接下来,在项目中,会部署一个Jenkins的 master pod:

5 {& Q6 T& y3 x0 e/ I

  C( C$ O9 P8 q

我们可以设置Jenkins Master所指向的slave pod的地址:registry.access.redhat.com/openshift3/jenkins-slave-maven-rhel7

4 ~7 z7 B! u5 c* r/ c. j, ^0 Q


9 u6 |9 A4 D0 g3 {3 T

而Pipeline也被创建成功(根据jenkins file中的定义)


+ g1 u6 |7 f+ ^% M) R  `( _5 j


3 q0 i" {! `3 M# d7 l

接下来,手工触发Pipeline:

: g& [4 S6 R2 n


1 c3 ~1 M% y3 c# ?* p/ U0 i

接下来,我们关注Jenkins上的日志输出,由于信息较多,我只列出关键内容:


6 ?; v4 Y& S. `  @2 U

获取代码:

. g! s* ]3 P1 J  s, @" W3 ^: r


# x$ a* \  k/ F$ w

下载maven相关的pom文件:


2 M0 Q  p: Q$ E8 p, r


- `1 m+ q, @2 _1 c6 X+ K

下载构建需要的jar包:

$ M5 T% L- y% D3 v

. ^5 i2 |- a2 @% f8 ?1 _6 D$ r- t

下载完所需内容以后,进行Build,我们可以看一下build主任务:


9 W" ^2 K+ y! x# n( b

! k3 z2 M' }+ \9 g

Build成功:

  k" @/ J5 Q' [4 _  u


8 @- t0 k+ v' s) t& ?

接下来进入test阶段,下面内容可以看出,test阶段是调用mvn test的命令:


$ A- t' S: g9 v+ ^0 `) K# Y


; E9 d' h6 _$ p4 `2 j2 E6 X

test成功:

5 C1 ~7 H% A! X

1 n1 |2 v& m+ r9 b8 S- u

接下来是的devInDev阶段:

% ^% q" x9 B- [5 {


7 g8 S$ {8 s4 t

在这个阶段,Jenkins会调用openshift的命令,创建bc和dc:

; t. g1 D$ k8 r


2 N2 B# u8 W4 J: D* h

部署应用并为应用创建routes:

/ C. V* T  z4 K


# c  W/ Q/ h% c. L% Z  P

截至到目前,pipeline执行完毕,应用也部署成功。

我们将视角切换到Openshift的界面,pipeline已经执行成功。


( Z- k7 v* J' E7 \5 C

0 J; \2 I  a  W6 d4 \& ]

接下来,我们通过浏览器访问应用的routes:

/ t6 S2 }) M; L. V9 H* J


% J! I; t7 Q5 m3 n5 c! L

可以看到应用部署已经成功:


5 {# T! {; I. m$ T

" {* n5 c" d" @( d" w6 a


  I3 o  R& P' I! k. J

方法总结


2 x, _- B: R7 `( N' Q) n

此种武器主要利用Jenkins进行代码的构建、应用的部署。对于较为复杂的应用编译,使用此种方法较为合适。另外,很多IT程度较高的客户,在docker大火之前,就已经基于Jenkins实现CI/CD了。这种情况下,如果新引入Openshift平台,使用此方法较可以延续以前的IT运维习惯,学习成本也相对较低(不需要大量修改现有的Jenkins)。

4 F9 k4 y0 U! x3 N( M

此这种方法的劣势在于对于Slave Pod有一定要求,不同于开发语言,需要使用不同的slave pod。此外,很多时候,我们也需要对slave pod的镜像做一定的定制,如增加一些rpm包等。


. ^* t, ]  N! o. `$ L* t




上一篇:两则DevOps咨询顾问招聘信息,年薪50W
下一篇:云会“杀死”运维吗?解读运维的刺激 2019

本版积分规则

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

QQ|小黑屋|手机版|Archiver|艾拓先锋网 ( 粤ICP备11099876号-1 )|网站地图

Baidu

GMT+8, 2021-4-13 18:51 , Processed in 0.208769 second(s), 30 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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