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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 1803|回复: 0

从一张图看Devops全流程

[复制链接]
发表于 2020-1-22 08:53:54 | 显示全部楼层 |阅读模式
本帖最后由 adminlily 于 2020-1-22 09:02 编辑 , Z1 r' T, u7 I) s
! D( }7 Y  k+ Q  E$ ]$ L, `8 ?5 G

一、持续交付工具链全图

7 c6 Z# H. A' `1 h, `1 l2 _


' I! S3 K; L, ^; B7 s+ h

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


* d2 ~- h; h, r2 ^

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


3 j% _% L9 h: |* w! t

Build

* H6 U7 L- w/ \

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


$ y3 @* L) L% F5 Z$ i

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


( ]1 |  @" b, F" G  F" U( _- m

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


; J# N$ z+ }, \

Test

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


* h2 L- c( b. w* u! x7 {

Deploy

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

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


2 z" }4 a0 y# J) _$ w8 m

Run

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

+ X( k5 Q, z* s8 S5 q# U


3 E. b8 Y. _# J  z' e6 O' C

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

! N, P: P% o# j* W+ a

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

" M' c& }1 Z2 c$ y6 ^2 a


! t; a. K* D/ T7 h$ y0 g; Z

二、红帽的DevOps全图


% m6 W4 b$ Z! G6 s6 s4 D- z  M4 o


8 X# d6 s6 E7 }2 o# ~

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


+ y* G% L* \- L) x" m( `

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

4 M3 V5 L" m) B8 |$ i; \

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

3 C4 |- j( F$ c: ~. i2 L- V. S) O

( k7 B8 ^! ^3 S8 P* t5 p$ b

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

, I7 Y, B) H5 x% k  v

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


, T4 T6 w: J% [8 m% \

+ @9 k7 A# j0 B: B& z1 y9 K

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


" G3 Y' p7 i2 u* K1 j6 h

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

& A# w. t- V/ w' r, r1 o


  ?5 m' u7 h7 |4 m) u, @

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

1 b9 o( z0 E& h3 B% H

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

* R9 j- F8 p- K: A

/ W4 c% D, W1 ?

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

4 @/ h9 c* U' P/ Q$ Y* l! w


$ R  \/ o( r0 ]# C

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

1 Z3 Z; D, O3 }; s; i

7 X4 I" w5 D, t# S; P

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

. v0 L8 z1 @8 [4 D: F

两个yaml文件


" J9 B3 h& R  Z' v) P

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


: N; i4 {- l. e# O; y

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


2 D: |' D' ^7 `) d9 ?

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

$ i; ^- \8 a* W2 F+ P3 Q

第一个文件:

9 Y8 L# U2 N8 F6 t6 J

apiVersion: v1

kind: Template

labels:

template: openshift-tasks-no-trigger

0 o! t5 m3 C9 W: D" H- I. C

模板名称

metadata:

name: openshift-tasks-no-trigger

objects:

- apiVersion: v1

kind: ImageStream

metadata:

labels:

application: ${APPLICATION_NAME}

name: ${APPLICATION_NAME}

$ f+ q7 t' ~" K& A5 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

9 d, q) U9 T& k

构建应用的基础镜像

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

" Y1 n0 K9 @4 x3 b

提示输入应用名称

- description: Git source URI for application

name: SOURCE_URL

required: true

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


$ O. W8 E; b$ Z5 Z) \( N  k8 B

提示输入源码地

- description: Git branch/tag reference

name: SOURCE_REF

value: master

  u2 |0 U. U: @0 P3 n

提示输入源码 branch地址


( j8 |! I# D; }0 ]" b. }/ K! y

; g; F$ b: @3 {: @8 t' Z9 a$ B

第二个文件


; ~; S; m+ H( H+ f

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

/ u/ M+ X1 V  W. o! [& d- [% Y

% g$ `0 V4 J, G

实验验证


3 D. f. [, s$ l  W& p: |2 X" e

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

# U$ h! O# \+ J' y' ~( |" b7 Y( V

/ e; V  }7 A% A0 j

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

$ L% c1 W" w9 l3 M

[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


& Y5 U2 A& o! e- d) o% m& t

接下来,创建jenkins pipeline:


$ d+ N1 V0 R' z' Q, |

" e6 h7 X% r% [" }8 u2 h6 L" w! E

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

Pipeline已经启动:

! F0 f+ Z# {/ t4 n8 t  I

% r+ T' y1 K' @# @- Q. _& X/ s7 _2 L1 B

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


1 h. C& T: T5 x6 s4 E8 B


- ]5 X3 M+ c4 P8 ?/ [

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


# X1 C7 j) d1 H( Y, ]9 ?/ N


7 p* w- c! r7 b9 {% e

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


$ c) \% M. z5 @; e# o


: y9 y' F! ^- D

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


5 y( o8 G" Y' J- e. D


0 |1 ^' T0 b" }' j

至此,build阶段完成。


2 v6 E) p8 ^4 `1 ~9 D" E) U


& w3 A" {# Z; X

接下来,启动deploy过程:


. X  T4 ~% s6 J1 F


7 {, h; ~' z) J! q- J; H

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


7 l5 y+ ~5 }+ T3 S8 H


5 w) F9 `4 t" [# J/ r7 M1 W

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


' E* T1 f9 d* R0 b  j: n

7 M1 N- C4 h" x+ V7 y9 E) ?( ^7 J

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


2 |6 h( F4 \* x: X- e

$ [; C/ d2 ~3 m2 ^! M

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


2 j: I) `; {5 }. G! U) I# k. K2 S


! ]  k- Z3 A" T7 Y$ [$ `6 s& t

6 u/ Z4 e4 ?# Z3 o. w

方法总结

  Q; @. R- k& x( m" `( y8 X

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


+ p  }7 w+ Z  V9 `# s' i

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

# G$ H! b1 _% X, J' P) ]

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


. i5 s: k! F& B5 J/ n3 i" D


4 B8 [2 x$ ]" o7 Z

四、在源码内构建pipeline

, h2 ~( U- G. u: a" s

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

/ O2 {) x+ w; n% B5 v' a9 l

0 `4 @# P8 a5 k! e& r! L

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


. ]% h5 p, Z' l2 a

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


/ B3 p5 D/ F! `, R5 i& V

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

. ]2 e5 \0 V, ^: ?$ m8 ]

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


! Y" J/ k, i/ u. u4 y+ B


' M7 e/ k2 U* ]2 r4 d) |% C: I$ a


7 e# I/ G) a5 Y$ W; i. R4 Q5 B3 _! b

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


* Z8 X2 C7 q% [( F' u3 v* T* }

7 h9 f4 i. o. r( j+ W; G

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

4 J1 t0 b' ]. |1 i  }) T+ @


& e# [9 i% X# |3 q; c

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


/ }9 L5 |% b0 k( A* q5 {1 x


5 M/ K: v# z7 u% w8 z5 F

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


  t' q: a' v3 t+ n


" N4 u* a4 l1 U

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


% W& j( G, ~& v2 f

apiVersion: v1

kind: Template

labels:

template: openshift-tasks-jenkinsfile

metadata:

name: openshift-tasks-jenkinsfile


9 E( z, ]6 n. F4 ~

模板的名称

0 [/ }$ @4 I$ G8 Q; [: k

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


& W$ `. w' q/ M2 j( Y, E

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

% u# R3 e- M8 f

7 x" D! O. F1 g

: ]& y7 \& a  o: l

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

& G) j6 k7 ~) r+ D


7 I' M$ k9 T: I* n4 d  }7 `; _

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


* ?3 k4 [3 |: T) F8 a4 _  P5 W

8 Q- a2 C8 |! P, k1 o

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


( S! [3 F. g1 {0 _! u

, n3 g# g3 T1 r+ D4 g3 @% ~

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


$ p/ ]* e: G/ Z$ R, S

: b8 j$ v8 n, V* P3 R8 Q

接下来,手工触发Pipeline:


+ B# C/ \$ }. E( ~+ o# t+ D


9 Y5 {' _* C' M. d9 R

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

- n" Z+ m! r% l& R

获取代码:


" s1 n8 l6 x. R* i

+ d3 V5 [8 E# o+ H

下载maven相关的pom文件:

7 {6 H5 W" u1 i, P


5 h. `& W8 J  @$ o% u2 p) `5 ]/ p

下载构建需要的jar包:

6 K9 u( R  d" Y% B( [( m

$ C. X8 N0 b4 l; L$ O- w+ a

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

' h' o! J' A0 k% u/ @- _  L5 v6 ]4 \

9 \- F; `8 N, F$ P

Build成功:

0 c0 H% z+ N1 f8 H( d9 a" B

5 I0 J& g( B/ B6 u- Q5 `8 k3 x! w

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


1 s" X8 A7 R7 s; R  {& L


% R, }5 r: z$ y2 }. s

test成功:


) q5 G) p: K' c% E


; l( A) Q# g+ T+ g! Z6 ~

接下来是的devInDev阶段:

( e" D7 k! A- e( B  h  e" Z- L


9 D7 F# X$ Q4 I( a

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


4 n) b5 f6 ?# U" `- `1 ~+ {/ j


* M  I% G: A% j# m$ b

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


7 @" P+ j0 @5 i( g9 `6 P


: m* z, f3 |4 v! Y9 c

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

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


/ q7 N8 t' N! A' `+ _4 q

: r' l/ |! W4 q

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

% a1 r" q0 F* A1 w0 T0 j

# N$ E" c/ L% n) b7 ~8 n

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

9 M  R/ w6 f+ h$ d+ ?

& ?2 V2 t' N6 i" c

: k: g* o& Q7 F: x' Z

方法总结

1 N& E. L/ I" b

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


9 [2 u7 J/ y( @. t9 g/ N$ L% R* ?! c

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

7 o8 b1 u; D/ V! D




上一篇:两则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-5-7 01:57 , Processed in 0.232313 second(s), 30 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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