RPM包制作

rpm包的制作是根据spec file来实现的，我们能够写spec file文件就能够实现制作rpm包了，spec file文件中都是一些命令，他告诉rpm包的制作工具rpmbuild，一步步如何解压一个软件包，如何去编译一个软件包，编译完成后如何做成不同的rpm包，rpm包之间有什么样的关系，每一个rpm包中应该包含什么样的文件。 spec file文件的语法 在各个段落中如何定义软件包的相关信息，如何控制编译，如何去列出包中所包含的文件，以及如何在spec file文件中使用宏（macro）。 #####一般来说制作一个rpm包大致包含以下几个方面的工作 ``` ============================================================= 1. 明确我们打算做的rpm包是什么东西 2. 收集制作软件包的原材料，最好是最原始的源码包 3. 收集软件包所需要的补丁 4. 制作rpm包是否适合老版本升级，是否需要执行一些清理旧包 5. 规划好rpm包的依赖关系，这个包依赖什么rpm包，这个rpm包向其他rpm包提供什么样的能力（capability） #编译依赖、安装依赖 6. 制作rpm包 7. 测试rpm包是否能够安装 ============================================================= ``` rpm包的制作需要有一个制作车间，需要有一定的目录结构 ！！制作rpm包一定不能使用root用户制作，使用普通用户来制作rpm包，因为在制作过程中如果某个命令写错了，root用户执行后的结果是灾难性的，且rpm包的制作过程中用不着root用户权限 将原材料放入规划好的目录结构中（特定目录） 创建spec file文件 编译源码生成rpm包 ``` 我们需要在特定的目录中提供5个子目录（目录名大写） BUILD：让源代码解压后存放的位置，但是我们不用管，只需要提供一个目录（真正制作过程在这个目录下） RPMS：制作完成后的RPM包存放位置（按照架构存放，例如i386目录，需为特定平台指定子目录），RPM包的编译可以实现交叉编译 SOURCES：所有收集的原材料存放在这里（conf文件，源码补丁文件等） SPECS：spec file文件，每个RPM包的制作必须要有一个spec file文件，作为rpm包制作过程中的指导文件，通常以软件包的名称命名，以spec结尾。 SRPMS：SRC格式的RPM包的存放路径 ``` redhat系统上，在/usr/src/redhat/目录下有Build RPM包的目录，权限为root，普通用户没有权限，多数情况下，我们不会在该目录下进行生成rpm包，在任何一个地方只要准备了这么几个目录都可以作为rpm包的制作车间，到底使用谁来作为当前用户rpm包的宏相关定义（rpm包为了工作有很多系统变量，和操作系统没有关系） ~]# rpmbuild --showrc #显示所有相关宏定义 宏的格式为：%{...} 名称为：_XX(一个下滑线的为定义spec文件本身环境的使用情况) 名称为：__XX(两个下划线定义的通常是命令) 定义宏的目的：在不同的系统上，路径很可能不一样，用以引用当前系统上的命令真正在什么地方。 macrofiles： 定义这些宏在什么文件中设定的（使用冒号隔开），生效的次序是自前而后的，如果配置文件中某个宏重复了，则以最后读取到的为准。 _topdir: 用于定义制作车间的路径 在家目录下创建文件~/.rpmmacros 写入%_topdir /RPM_BUILD_PATH #指定一个当前用户有权限访问的目录 spec file文件结构 intraduction section #介绍段，rpm -qi能够查询到的信息 prep section #准备阶段，解压缩源码包并cd进去 build section #编译阶段 install section #安装阶段（安装到某一个目录下，非当前系统） clean section #清理阶段 files section #文件段，列出收集的文件，打包到rpm包中 change log section #改变日志段（版本信息变更） spec文件语法 ``` ============================================================ #定义的标签（冒号前的顶格字段），在spec文件中可以使用%{name}的方式进行引用标签后（冒号）的值 #%{?dist},该处的问号能进行判断，存在就赋值，不存在则不填 #所有以"#"开头的为注释，但是注释中不能出现"%",非得出现可写为"%%" TagName: value #标签名称不区分大小写 %define macro_name value #用户自定义宏 #用户自定义宏的引用：%{macro_name} || %macro_name Name: name-version-release.rpm name-version-release.arch.rpm #name中一定不能出现短横线（dash），短横线有特殊意义 GROUP: 制作的软件包属于哪个组，可参考/usr/share/doc/rpm-version/GROUPS Vendor: 制作人 URL: rpm下载位置或网址 Packager: first name <mail> License: 一定要带上，看清楚源码包的授权，REDME/change logs Summary: 概述，尽量不要写太多 %description: 写大段的描述信息，建议一行不要太长，采取强制换行 #Define Package Dependencies 定义包的依赖（可省略） Requires: capability #安装rpm包时的依赖，可以出现多次 Povides: capability #该rpm包提供的能力 BuildRequires: capability #生成rpm包时的依赖，可出现多次 #设定build locations BUILD: 用于编译的目录 BuildRoot: 用于编译后安装的目录（假想根目录） %{buildroot} #假想根目录 $RPM_BUILD_ROOT #假想根目录 Source: 怎么命名源文件（如果只有一个使用source即可） #如果有多个则：source0、source1等等 #这些源文件必须位于source下，可以加http链接，但是它不回去下在，而是到SOURCE目录下去找 #通过source引入的文件通常不会自动安装到对应的buildroot路径下，需要手动进行安装 %{__install} -p -D -m 0755 %{SOURCE1} %{buildroot}/etc/rc.d/init.d/nginx #应用"SOURCE1"需大写 Patch: 补丁，如果有补丁，命名方式同source，命名patch是为了后面打补丁引用 %prep #将源代码解压到build路径下，设置环境变量并cd进去 %setup -q -n nagios #有些包解压后名称不带版本号，当cd时会报错，因此需要使用%setup的额外选项指定名称 -q #静默模式 -a #先进build目录再解压缩源文件 #-a 0 -a 1 展开source0、source1 -b #先解压缩，再进入build目录，当展开目录为多个且需要合为一个时 #-b 0 -b 1 展开source0、source1 #-b需要先使用-c，再解压缩之前创建目录，name-version %build #对于c语言，configure，make，make install #如果是perl程序，读帮助文档perl Makefile.PL %install #保留源文件时间戳 %clean #主要作用就是删除buildroot rm -rf %{buildroot} ~]# rpmbuild --clean nginx.spec Define installation Scripts %pre #安装前脚本 %post #安装后脚本 %preun #卸载前脚本 %postun #卸载后脚本 #脚本中有$1变量，指的是安装类型（处理类型） 判断 $1 == 1 安装 判断 $1 == 2 升级 #3-9都可以用，但是常用2 判断 $1 == 3 卸载 %files #任何包含进rpm包中的文件，都在这儿列出来必须在BuildRoot目录中安装生成，支持通配符、目录 %dir /PATH/TO/DIR #将指定目录当做空目录，不关心目录中内容 %doc File_Name #不写路径，在安装时放入/usr/local/share/doc/nginx-xxx %dirdoc /PATH/TO/DIR #将整个目录下的内容作为文档处理 %config /PATH/TO/FILE #指定配置文件 #noreplace,不替换以改变的文件 #*.rpm.new(新安装的配置文件) #*.rpmorig(不兼容时的新文件名称) %config(noreplace,missing ok) #missing ok，没有也没关系 %changelog * #以星号标识日期 #日期的格式为：星期，月份，日，年，制作者，邮件地址-版本号-release号 - #短横线标识注释，在这个版本里我们都干了什么事 %attr(mode,user,group) filename #给单个文件修改属主属组、权限，为横线时保留原有属性 %attr(-,user,-) filename %defattr(-,-,root,-) #默认权限定义 ============================================================ ``` ~]# ldconfig #重新读取动态链接库中的库文件 ~]# rpm -k *.rpm #检查rpm包的来源 使用gpg命令对rpm包进行签名 ~]# gpg --gen-key #生成秘钥 ~]# gpg --list-key #查看秘钥 ~]# gpg --ecport -a '...秘钥...' >RPM-GPG-KEY-* #将公钥提取出来，随安装包给用户 ~]# rpm --addsign *.rpm #对rpm包进行签名 ~]# rpm --import RPM-GPG-KRY-* #安装公钥 ~]# rpm --checksig *.rpm #验证RPM包 PGP: Pretty Good Privacy OpenPGP是一种规范： PGP是商业的软件，使用该软件加密的也得使用该软件进行解密，为了增强适用性，PGP公司写了open PGP规范，其他公司可以按照规范开发软件，以增强适用性，GNU组织根据该规范编写了一款软件，称为GNUPG-->GPG 制作RPM包时直接签名 ~]# vi ./rpmmacros %_signature %_GPG_Name

• CI/CD
• 2019-05-06
• 评论
•   3226 次浏览

Jenkins Job介绍

1. 有若干个job或project构成的庞大的开发平台系统，我们可以将开发测试，部署或基础运维相关任务通过创建一个任务或者项目，保存在jenkins任务列表中，方便日常的运维开发、维护工作。 2. 可以利用其内建模块或特定的脚本语法，将我们的工作内容抽象成jenkins job，这个任务里通过配置相关的参数及工具模块，从而作为一个可执行的任务，最终保存在jenkins平台下。 3. 每一次执行完一个任务成为一个build，可以通过查看这个build获取所需要的结果。 4. build构建信息会保存在jenkins上作为build log，可以通过查看不同时间点的log信息，从而debug任务中出现的各种问题。 5. jenkins下所有的任务构建后的所有项目相关文件，例如clone的仓库代码，maven打包生成的编译包，配置的参数文件，都会保存在jenkins的主目录workspace下，以我们当前任务名称命名的目录，作为这个job的workspace，可以查看这些工作空间中的文件，去定位无法在日志中无法定位的问题细节。 Jenkins freestyle与pipeline job的区别 freestyle job 1. 需要在界面添加模块配置项与参数完成配置 2. 每个job仅能实现一个开发功能 3. 所有的配置只能通过前台手动完成，无法将配置代码化，不利于job配置迁移与版本控制。 4. 逻辑相对简单，无需额外的学习成本 pipeline job ``` #匹配持续集成与持续交付的概念 1. 所有的模块、参数配置都可体现为一个pipeline脚本 2. 可以定义多个stage作为项目部署的每一个阶段，构建一个管道工作集串联所有的工作。 3. 所有的配置代码化，方便job配置迁移与版本控制，对有改动的部分进行版本控制，将脚本的改动定位到代码层面，方便后期的审计工作。 4. 需要学习pipeline脚本语法基础 ``` jenkins job构建配置 1. 配置jenkins server本地代码仓库 2. 安装gitclient，curl工具依赖 3. 关闭系统git http.sslVerify安全认证 4. 添加jenkins后台git client user与email 5. 添加jenkins后台git credential凭据 jenkins freestyle job构建配置 1. 在界面上创建一个freestyle project 指定任务名称 选择构建一个自由风格的软件项目 2. 编辑描述信息 写入对该任务的描述信息 3. 进行参数的配置 找到“参数化构建过程”并勾选 添加相应的参数值 4. 可添加一个文本参数并写入相应值 写在这里的参数最终最为我们预先build构建前项这个任务传送参数的接口 5. 先添加选项参数 名称：deploy_dev #作为部署环境的名称 选项： #作为任务构建前的参数选项，传入任务中 dev #开发环境 prod #生产环境 描述：Choose deploy envrionment #作为参数选项的描述任务 6. 添加文本参数 名称：version 默认值：1.0.0 描述：build version 通过传入一个预先设定好的默认参数或者自定义参数作为构建我们build这个任务前的参数值到job当中 7. 源代码管理 我们可以通过配置源代码管理选项，将git代码仓库的项目源代码clone到jenkins本地进行随后的项目部署工作。 在配置job的界面向下滑动，找到源代码管理 选择git Repository URL中输入仓库的URL地址 Credentials中选择在凭据中创建的git用户、密码 此时页面上的错误提示消失，表示git仓库认证成功 Branch Specifier */master #保证克隆的是master分支的代码 8. build配置 添加一个shell模块，编写我们的核心build任务，并最终完成我们的freestyle job配置内容 web界面向下拉动，找到“构建“，并增加构建步骤：执行shell ``` ============================================================= #!/bin/bash export PATH="/bin:/sbin:/usr/bin:/usr/sbin:usr/local/bin:/usr/local/sbin" #print env variable echo "Cuurent deployment environment is $deploy_env" >>test.properties echo "The build $version" >>test.properties echo "[INFO] Done..." #Check test properties echo "[INFO] Check test properties" if [ -s test.properties ]; then cat test.properties echo "[INFO] Done" else echo "test.properties is empty" fi echo "[INFO] build finished" =========================================================== #点击保存并推出当前配置界面 ``` 任务的构建 在jenkins界面上点击对应job的“build with parametes“ deploy env的参数选项：dev/prod version定义 点击build开始构建 点击左侧边栏中构建中的job，可查看构建的过程（点击圆球直接进入） jenkins pipeline job基础架构 ``` 1. 所有的代码包含在pipeline{}层内【第一层】 2. stages{}层用来包含该pipeline所有stage子层，将pipeline管道分为若干个管道块，每一个管道块够可以去干一件事情，而且彼此不受影响【第二层】 3. stage{}层用来包含具体的我们需要编写任务的steps{}子层，用于添加pipeline语法模块，利用模块进行业务逻辑的相关编写操作。 4. steps用于添加我们具体需要调用的模块语句，如shell模块等 ============================================================= pipeline{ agent any environment{ host='test.example.com' user='deploy' } stages{ stage{ sh "cat $host" echo $deploy } } } ============================================================= ``` agnet区域 定义pipeline在哪里运行，可以使用any，none或具体的jenkins node主机名等，例如我们要指定在node1上执行可以写成 agent{node {lable 'node1’}} any:随机在一台jenkins上执行该任务 envrionment区域 1. “变量=变量值“定义我们的环境变量，通常与stages平级 2. 可以定义全局环境变量（如PATH），应用于所有stages任务 3. 如果需单独定义一些仅应用到特定stage管道块中的环境变量，我们可以直接将envrionment写到该区域内 script区域（可选） 1. 定义在steps中 2. 编写grovy脚本语言 3. 用来进行脚本逻辑运算（具有grovy基础） steps区域 1. echo：打印输出静态、动态语句到build构建任务log输出中 echo $deploy 2. sh：调用Linux系统shell命令在pipeline下编写shell脚本 sh "cat 'test.properties'" 3. git url：调用git模块进行git相关操作 git url: "https://..." jenkins pipeline job构建配置 ``` 1. 创建一个pipeline project jenkins管理界面新建任务 键入pipeline job任务名称 选择pipeline流水线任务并确定 2. 添加描述信息 This is my first pipeline job 点击应用 3. pipeline脚本配置 找到pipeline任务栏 编写我们的pipeline脚本 ============================================================= #!groovy pipeline{ angen{node {lable 'master'}} environment{ PATH='/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin' } parameters{ choice( choices: "dev\prod" description: "choose deploy environment" name: "deploy_env" ) string(name: 'version', defaultValue: '1.0.0', description: 'build version') } stages{ stage("Checkout test repo") { steps{ sh 'git config --global http.sslVerify false' #关闭当前git的全部ssl认证 dir("${env.WORKSPACE}") { git branch: 'matser',CredentialsId: “需要到jenkins管理界面查看git凭据ID”, url: 'https://git repo address' #添加了一个checkout test repo的stage，将git仓库中的源代码clone到jenkins当前任务下的workspace工作区域内 } } } #接下来创建第二个stage区域，相当于这个管道流水线的第二个子任务，用来将我们的pipeline传入的参数写入到我们上一个stage子任务clone下来的test properties中。 stage("print env variable") { steps{ #当前所有模块调用以及任务执行都在我们定义的dir中运行 dir("$env.WORKSPACE") { sh """ #三引号内以shell的风格编写shell语句 echo "[INFO] Print env variable" echo "Current deployment environment is $deploy_env" >>test.properties echo "The build is $version" >> test.properties echo "[INFO] Done..." """ } } } stage("Checkout test properties") { steps{ dir("$(env.WORKSPACE)") { sh """ echo "[INFO] Check test properties" if [ -s test.properties ]; then cat test.properties echo "[INFO] Done..." else echo "test.properties is empty" fi """ } } } } } ============================================================= ``` 点击保存并退出 点击立即构建，首次构建会提示找不到deploy变量，因为在首次构建pipeline job的时候我们的参数没有引入到我们当前的pipeline job当中，此时构建的按钮变为了"Build with parameters"，点击它就可以看到我们在build之前需要添加的参数，点击build才能开始接下来的构建。 jenkins 应用 Jenkins 与Linux shell集成 ``` 1. 新建freestyle project 名称：shell_freestyle_job 选择freestyle_job并确定 2. 输入描述信息 在页面下找到"构建"，选择增加构建步骤：执行shell 在界面文本框中添加shell语句,此处为一些主机信息查看语句 ============================================================= #!/bin/bash user=$(whoami) if [ $user == 'deploy' ]; the echo "hello,my name is $user" else echo "sorry,i’m $user" fi ip addr cat /etc/system-release free -m df -Th py_cmd=$(which python) $py_cmd --version ============================================================= ``` Jenkins参数集成 ``` 1. 进入jenkins管理界面，新建freestyle job 名称：parameter_freestyle_job 选择构建一个freestyle job并确定 2. 输入描述信息 选择参数化构建过程复选框 添加"选择参数" 名称：deploy_env 选项：dev uat stage prod 描述：Choose deploy environment 添加文本参数 名称：version 默认值：1.0.0 描述：fill in build version 添加bool值参数 名称：bool 默认值勾选则默认为ture 描述：Choose bool value 添加密码参数 名称：pass 默认值：密码字符串（如果不输入，在构建时会手动输入，脚本中调用pass变量时） 描述：Type your password 3. 添加构建步骤 选择执行shell，添加一个shell模块 添加shell语句 ============================================================= #!/bin/bash echo "Current deploy environment is $deploy_env" echo "The build is $version" echo "The password is $pass" if $bool; then echo "REquest is approved" else echo "request is rejected" fi ============================================================= 保存并退出 点击构建，可以查看到添加的参数选项 ``` Jenkins与git集成 ``` 使用jenkins内建的git插件将gitlab仓库的代码clone到jenkins本地，准备随后的代码构建工具。 1. jenkins界面新建freestyle job任务 名称：git_freestyle_job 选择freestyle_job并确定 2. 填写描述信息：This is my first git 找到源码管理选择git 添加git仓库地址"https://..." 选择git用户名和密码（系统凭据）并确定 点击构建 Jenkins与ansible集成 使用shell模块调用本地的ansible命令，从而实现jenkins能够集成ansible工具进行远程服务器的部署管理功能。 ansible虚拟环境3.6配置以及配置jenkins主机下deploy用户到目标主机的秘钥认证。 1. jenkins界面新建freestyle job任务 名称：ansible_freestyle_job 选择freestyle job并确定 2. 填写描述 This is my first ansible job 3. 构建模块选择"执行shell" ============================================================= #!/bin/bash set +x source /home/deploy/.py3-a2.5-env/bin/activate source /home/deploy/.py3-a2.5-env/ansible/hacking/env-setup -q cd /home/deploy ansible --version ansible-playbook --version cat testserver #详细清单目录 ansible -i testservers.testserver -m command -a "ip addr" set -x ============================================================= 保存并退出 构建任务 ```

• CI/CD
• 2019-05-04
• 评论
•   3691 次浏览

Jenkins简介

Jenkins是一个开源持续集成工具，使用java语言开发 功能：提供软件开发的持续集成服务 特点：支持主流软件配置管理，配合实现软件配置管理持续集成功能。 Jenkins的优势和应用场景： 1. 主流的开发平台，兼容所有的主流开发环境。 2. 插件市场可与海量业务流开发工具实现集成 3. job为配置单位与日志管理，使运维与开发人员能协同工作的工具 4. 权限管理划分为不同job不同角色 5. 强大的负载均衡功能，保证我们项目的可靠性 jenkins的安装配置管理 ``` 1. 安装jenkins前的环境准备 #添加yum源 ~]# wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo #导入key，验证yum仓库的安全性 ~]# rpm -import https://pkg.jenkins.io/redhat-stable/jenkins.io.key 2. 保证系统java的版本为8.0或8.0以上，保证jenkins可以调用本地的java环境启动该服务 ~]# yum -y install java ~]# java -version #确定是否安装成功及版本是否匹配 3. 关闭系统防火墙 4. 关闭SELinux，并重启（强制访问控制策略） 5. yum源安装jenkins最新版本 ~]# yum -y install jenkins 6. 创建jenkins系统用户（服务） ~]# useradd jenkins 7. 更改jenkins启动用户与端口 ~]# vi /etc/sysconfig/jenkins JENKINS.USER=jenkins JENKINS.PORT=8080 8. 启动jenkins ~]# systemctl start jenkins 浏览器访问IP:8080 获取权限 安装推荐插件 创建管理员 ``` Jenkins管理界面 新建任务：新建一个jenkins job 用户：创建用户 构建历史：查看所有build构建的log记录 系统管理：配置管理系统相关配置选项 我的视图：创建自定义的dashboard界面 凭证：添加git密码，ssh key公钥 新建视图：创建自定义的dashboard界面 构建队列：build队列 构建执行的状态：所有build构建状态列表

• CI/CD
• 2019-05-04
• 评论
•   2950 次浏览

持续集成工具Jenkins

持续部署的关注点在于项目功能部署至服务器后可以运行，为下一步测试环境测试环节或最终用户正式使用做好准备。 经常性，频繁的吧所有的模块集成在一起进行测试，有问题尽早发现，这就是持续集成。 持续集成的关注点在于尽早发现项目整体运行问题，尽早解决。使用小版本不断进行快速迭代，不断收集用户反馈信息，用最快的速度改进优化。 持续交付的关注点在于研发团队的最新代码能够让最终用户体验到。 #####CI（持续集成） 持续集成是软件开发过程中的一种实现，通过将代码仓库与jenkins集成，是开发人员的每一次代码提交都能够在jenkins上自动进行任务的build构建，帮助开发团队第一时间发现问题并解决问题。 #####CD（持续交付） 在CI的基础上将构建好的软件版本通过jenkins的测试自动化部署，持续、安全、快速地交付到用户手中。 总体目标： 降低风险 减少重复过程 任何时间任何地点生成可部署软件 增强项目的可见性 建立团队对开发团队的信心 Jenkins可以整合GitHub和Subversion 自动化部署的实现：向版本库提交新的代码后，应用服务器上自动部署，用户或者测试员使用的马上就是最新的应用程序。 #####系统结构描述： 版本控制子系统 Subversion服务器 项目对应版本库 版本库中的钩子程序 持续集成系统 #####Jenkins 主体程序 SVN插件 Mavn插件 Deploy web container插件 #####应用发布子系统 JDK TomCat Jenkins使用天气来表示构建成功率 curl命令用来发送HTTP请求 ``` ～]# curl –X post –v [Jenkins_user_name]:[Jenkins_Password] –H“请求消息头信息” –http://[server_IP]:[Port]/Jenkins/job/[Jenkins_Project]/build?token=[身份验证令牌] ``` -X 指定请求方式 -v 显示响应结果 -u 携带用户名和密码 -H 携带请求消息头信息 Jenkins_URL/job/Project_Name/build?token=TOKEN_NAME Jenkins_URL http://Server_IP:8080/jenkins job 固定名称 Project_Name 自定义项目名称 build 固定名称 ?token=TOKEN_VALUE 值在jenkins界面自定义 当触发该触发器后会完成自动构建（浏览器访问该地址也会触发构建[代码提交通知jenkins的方法]）  Jenkins： Jenkins Build的版本比代码库晚一个版本的解决办法：在Jenkins源码管理工程配置中，Repository URL为URL@HEAD，“@HEAD”意思为指向最新版区下载代码，GitHub上使用的每个repository的WebHook方式远程触发Jenkins的构建。 GitLab：开源分布式版本控制系统，使用ruby开发，管理项目源代码，版本控制复用与查找。 GitHub：分布式在线代码托管仓库，个人版本可以直接在线免费使用，企业版本收费且需要服务器安装。 GitLab的优势和应用场景： 开源免费适合中小型公司将源代码放置在该系统中 差异化的版本管理，离线同步以及强大的分支管理功能 便捷的GUI操作界面以及强大的账户权限管理功能。 集成度很高，能够集成绝大多数的开发工具 支持HA，保证在高并发下仍旧实现高可用性。 GitLab主要服务构成 1. Nginx静态web服务器，GitLab的proxy处理所有HTTPS静态访问请求。 2. GitLab-workhorse 轻量级的反向代理服务器，处理较大文件的上传下载（如push操作） 3. GitLab-shell用于处理Git命令和修改authorized keys列表 4. Logrotate 日志文件管理工具，负责处理日志的切割/打包等操作 5. Postgre sql数据库，保存所有的gitlab数据信息 6. Redis缓存服务器，加快前台的访问速度 本地需安装gitclient，保证能够进行clone gitlab的工作流程（可使开发人员并行完成后自身的feature需求，而又不会对主分支代码产生影响）： 创建并clone项目 创建项目某Feature分支 编写代码并提交至该分支 （实际环境中，管理员会创建好项目仓库，并在该仓库下根据我们的业务需求去创建若干个feature特征分支，这些feature分支会以任务的形式分发给我们的开发） 推送该项目分支至远程Gitlab服务器 在Gitlab图形界面下找到自己的代码进行代码检查并提交master主分支合并申请 项目领导审查代码并确认合并申请 GitLab应用： Gitlab拥有强大的分布式版本控制系统，也有着出色的后台管理能力，后台的管理可以针对不同的项目/不同的用户去定制不同的访问策略。 GitLab运维需要获取的系统的关键值： CPU利用率/内存/磁盘使用率 保证在gitlab在一个高并发的情况下依旧能够快速稳定运转 admin需要分配不同的人对不同的项目拥有不同的权限 保证开发人员具有分支的克隆/删除/推送/提交/合并/创建分支等权限 保证项目领导在具有开发人员权限的基础的同时，具有检查项目用户/开启/禁用/保护分支/编辑项目信息/审核确认分支的申请的权限 ``` ～]# git -c http.sslVerify=flase clone CodeRepo_Addredd(仓库地址) #输入开发人员账号密码进行代码仓库的克隆 ～]# git check -b release-1.0 #创建名为release-1.0的分支并切换进该分支 #该分支下依旧存在clone的代码文件，在该分支下进行代码的编写 ～]# git add ~]# git commit -m “release-1.0” #本地提交feature更新 ~]# git -c http.sslVerify=flase push origin release-1.0 #将代码同步到远程的release-1.0的分支中 登陆到gitlab Dev账号，在界面上可以看到新提交的代码，点击create merge request将代码合并到master分支（申请） leader登陆gitlab界面通过合并申请 ```

• CI/CD
• 2019-05-04
• 1 条评论
•   6050 次浏览