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
•   评论
•   963 次浏览

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
•   评论
•   1314 次浏览

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
•   评论
•   969 次浏览

ansible简介

使用python开发，以playbook作为基础部署架构 特点：仅依靠SSH协议通讯就可以完成全平台，无需编译，模块化的部署管理 作用：推送playbook进行远程节点快速部署 ansible与chef/saltstack的不同：
chef： 使用ruby 语言编写，C/S架构，配置需要git依赖（实现版本控制功能） pipline脚本编写规范，需要编程经验 saltstack： 使用python语言编写，C/S架构，模块化配置管理 YAML脚本编写规范，适合大规模集群部署 （含有异步文件服务器，为客户端加快文件服务速度） ansible： python语言编写，无client，模块化配置管理 playbook脚本编写规范，易于上手，适合中小规模快速部署 优势： 1. 轻量级无客户端（agentless），SSH连接，无形中减少了客户端资源的占用，安全问题。 2. 开源免费，学习成本低，快速上手 3. 使用playbook作为核心的配置架构，统一的脚本格式批量户部署 4. 完善的模块化扩展，支持目前主流的开发场景 5. 强大的稳定性和兼容性 6. 活跃的官方社区问题讨论，方便Troubleshooting与DEBUG问题 在部署ansible环境时，避免python模块的冲突，保证部署的模块只会应用于ansible，而不会影响到其他工具的使用，将ansible与其他系统工具隔离开，使用python内置的virtualenv命令隔离python3.6语言环境，单独划分一个环境给ansible使用 ansible的部署： yum包管理安装 ansible成为系统全局下的工具，系统下任意的用户都可以使用，但是如果当前系统下的其他用户安装了其他的python模块，这里就会与ansible下的模块造成潜在的冲突。 因为在全局状态下，Python的模块安装后都会保存在Python的同一个Python扩展目录下，当ansible用到的模块与其他工具用到的模块一致时，但是调用模块的版本不同，这样势必会造成Python模块的管理混乱，最终影响产品部署交付。 我们可以clone ansible的源码至主机中，配合virtualenv实现ansible特定版本独立环境的创建，保证ansible在一个独立的python环境下运行。 ansible2.5+Python3.6部署： ``` 1. 安装python3.6版本,以及pip3 ~]# wget http://www.python.org/ftp/python/3.6.5/python-3.6.5.tar.xz ~]# tar -xvf python-3.6.5.tar.xz ~]# cd python-3.6.5 ~]# ./configure --prefix=/usr/local/ --with-ensurepip=install --enable-shared LDFLAGS=”-wi,-rpath /usr/local/lib” --prefix=/usr/local/ #指定安装目录 --with-ensurepip=install #安装pip包管理工具 --enable-shared LDFLAGS=”-wi,-rpath /usr/local/lib” #用来配置python3.6匹配当前系统的参数值 ~]# make ~]# make altinstall #~]# make && make altinstall #需要root权限执行 ~]# whitch pip3.6 ~]# ln -s /usr/local/bin/pip3.6 /usr/local/bin/pip #给pip3.6做软链接 2. 安装virtualenv，用于隔离python与ansible环境 ~]# pip install virtualenv 3. 创建ansible账户病安装python3.6版本env实例 ~]# useradd deploy && su - deploy #创建一个名为.py3-a2.5-env的实例目录 ~]# virtualenv -p /usr/local/bin/python3 .py3-a2.5-env 4. git源代码安装ansible2.5 #安装git环境及依赖 ~]# yum -y install git nss curl ~]# cd /home/deploy/.py3-a2.5-env ~]# git clone https://github.com/ansible/ansible.git ~]# cd ansible && git checkout stable-2.5 5. 加载python3.6 virtualenv环境 ~]# source /home/deploy/.py3-a2.5-env/bin/activate 6. 安装ansible依赖包 ~]# pip install paramiko pyYAML jinjia2 7. 在python3.6环境下加载ansible2.5（虚拟环境） ~]# source /home/deploy/.py3-a2.5-env/ansible/hacking/env-setup -q 8. 验证ansible2.5 ~]# ansible --version ``` ansible playbook入门和编写规范 playbooks表层目录结构： inventory/ testenv roles/ testbox/ tasks/ main.yml deploy.yml ``` 1. inventory/ #存放一个或多个server清单，用来保存目标部署主机的相关域名或者IP地址，以及该主机的变量参数。 #通常可以使用具体部署环境的名称给server清单进行命名，如devlop开发环境、UAT测试环境、production生产环境，对应保存在清单下的主机地址具体部署到哪个环境当中。 testenv文件结构： [testservers] #server组标列表标签，可以保存一个或者多个目标主机（IP或域名） test.example.com #目标部署服务器主机名 [testserver:vars] #server组列表参数（变量） #目标主机key:value键值对参数作为server组的变量声明 server_name=test.example.com user=root output=/root/test.txt 2. roles/ #用来保存我们需要部署的详细任务列表，可以存放一个或多个role，通常会命名为项目名称。 tasks/ #用于保存项目的主任务文件：main.yml main.yml任务文件 #文件位于roles目录下的项目目录下的tasks目录中，用来保存特定role下面要执行的具体任务乐章，文件中会有一个或多个task作为音符 #task一般由两部分组成 - name: print server name and user to remote testbox #任务名称，用于识别不同的task的作用 shell: “echo Currently {{user}} is logining {{server_name}} >{{output}}” #具体要执行的任务，通常会调用ansible内建的模块来编排我们的任务逻辑，此处调用的是inventory中定义的键值对参数。 3. deploy.yml #playbooks任务入口文件，它将调度我们roles/下需要去部署的项目，以及该项目下所有的任务，最终将任务部署到我们在inventory/中定义的目标主机中。 #核心文件，用来直接和ansible playbook命令直接对话，它将playbook下的编排内容展示给ansible命令，进行最终的演奏，将项目部署到对应的目标主机当中。 - hosts: "testserver" #调用对应server列表中的主机，inventory/testenv文件中的server组标签 gather_facts: ture #获取server基本信息 remote_user: root #目标服务器系统用户指定 roles: -testbox #指定roles/下的任务目录进行任务执行 ``` SSH免密认证 ``` 1. ansible服务器端创建SSH本地秘钥 ~]# ssh-keygen -t rsa #在本地创建rsa格式的公钥与私钥 2. ansible服务器端建立与目标部署机器的秘钥认证 ~]# ssh-copy-id -i /home/deploy/.ssh/id_rsa.pub root@test.example.com #将公钥传输到目标机器，实现ansible服务器端免密访问目标服务器 ``` 执行playbooks，将对应项目进行部署 ``` ~]# ansible-playbook -i inventory/testenv ./deploy.yml playbooks执行结果字段含义： PLAY RECAP #playbooks执行总结 主机名：test.example.com ok=2 #成功执行2个task changed=1 #有一个task有变动，对目标主机进行了修改 unreachable=0 #无法到达的主机数为0 filed=0 #语法结构没有错误 ``` ansible常用的模块： ``` file模块：在目录主机创建文件或目录，并赋予其系统权限 - name: create a file file: 'path=/root/foo.txt state=touch mode=0755 owner=foo group=foo’ #任务 copy模块：实现ansible服务端到目录主机的文件传递 - name copy a file copy: 'remote_src=no src=roles/testbox/files/foo.sh dest=/root/foo.sh mode=0664 force=yes’ remote_src=no #声明将ansible主机的文件传送到目标主机中 src=roles/testbox/files/foo.sh #源文件路径 dest=/root/foo.sh #目标路径 mode=0664 #指定目标主机copy的文件权限 force=yes #强制执行，同名覆盖 stat模块：用于获取远程文件状态信息，并将其信息保存在一个环境变量下供随后使用。 - name: check if foo.sh exists stat: 'path=/root/foo.sh’ register: script_stat Debug模块：打印到ansible执行输出，与stat结合使用 - debug: msg='foo.sh exists' #输出内容为:foo.sh exists when: script_stat.stat.exists #判断语句 command/shell模块：用来执行Linux目标主机命令，推荐使用shell模块 #shell环境会调用Linux环境下的/bin/bash，因此可以使用系统变量，重定向符、管道符等 #command不能使用特殊的用法 - name: run the script command: "sh /root/foo.sh" #执行目标主机上的指定目录下的脚本 - name: run the script shell: "echo 'test' > /root/test.txt" template模块：实现ansible服务端到目标主机jinja2模板传送 - name: write the nginx config file template: src=roles/testbox/templates/nginx.conf.j2 dest=/etc/nginx/nginx.conf Packaging模块：调用目标主机系统包管理工具（yum|apt）进行安装 - name: ensure nginx is at the latest version yum: pkg=nginx state=latest #CentOS|RedHat pkg=nginx #指定安装包的名称 state=latest #保证为最新的版本 - name: ensure nginx is at the latest version apt: pkg=nginx state=latest #Debian|Ubuntu service模块：管理目标主机系统服务，调用service或systemctl - name: start nginx service service: name=nginx state=started ```

•   Ansible
•   2019-05-04
•   评论
•   541 次浏览

持续集成工具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
•   评论
•   705 次浏览

VLAN&VXLAN简介

Vlan： 在较大的局域网内，存在多台交换机，多个网段，交换机下的所有主机都处于广播域中，会造成广播风暴，浪费宝贵的带宽资源，通过vlan标签对逻辑子网隔离，划分从逻辑上广播域。 Vlan允许的子网数量为2^12=4096 VLAN环境下不同网段的主机通信必须要经过路由或三层交换来实现。 在云环境中，多租户的场景下VLAN的子网往往是不够使用的，而且VLAN能够解决二层网络中主机之间信道的争抢，但是不能解决三层IP地址的冲突。 因此，为了解决多租户网络重叠（IP地址冲突），产生了VXLAN技术。 VXLAN是一种基于IP网络且采用MAC地址封装在UDP报文中的VPN技术。 VXLAN技术可以通过建立VXLAN隧道，在现有网络架构上建立大量的虚拟可扩展局域网，不同的虚拟可扩展局域网使用VNI（VXLAN Network Identifiler，虚拟可扩展局域网网络标识符）进行标识。 VXLAN提供和VLAN相同的2层网络服务，但相比VLAN拥有更大的扩展性和灵活性，优点如下： 多租户的网络在整个数据中心更具灵活性：VXLAN提供了一个在可靠的共享网络设施上扩展二层网络的解决方案，从而租户的负载（tenant workload）可以在数据中心跨physical pods。 VXLAN提供更多的二层网段，VLAN使用12bit的VLAN_ID表示网段名，从而网段数被限制在4096个，而VXLAN使用24bit作为VXLAN标识符（VNID），使得VXLAN的个数扩展到2^24个。 更好的在基础设施中利用网络路径（Network path）：VLAN使用STP（spanning Tree Protocol）协议防止路由环路，最终不使用网络中的网络连接半阻塞冗余路径。VXLAN数据包基于三层报头，可以完整的利用三层路由，ECMP路由以及链路聚合协议来使用所有可用的路径。 传统三层网络： 核心层：核心交换机负责骨干网络传输，对外提供业务。 汇聚层：降低核心交换机的压力，ACL、划分VLAN，控制等都是在汇聚层进行。 接入层：接入到底层的终端服务器。 在南北流量大的场景下，如果东西向流量增多（主机之间通过的层数多），会导致南北向流量拥堵。 VLAN是为解决以太网的广播问题和安全性而提出的一种协议，它在以太网帧的基础上增加了VLAN头，用VLAN ID把用户划分为更小的工作组，限制不同工作组间的用户互访，每个工作组就是一个虚拟局域网。虚拟局域网的好处是可以限制广播范围，并能够形成虚拟工作组，动态管理网络。 GRE VPN（Generic Routing Encapsulation）即通用路由封装协议，是对某些网络层协议（如IP和IPX）的数据报进行封装，使这些被封装的数据报能够在另一个网络层协议（如IP）中传输。 GRE是VPN（Virtual Private Network）的第三层隧道协议，即在协议层之间采用了一种被称之为Tunnel（隧道）的技术。

•   随手笔记
•   2019-04-27
•   评论
•   668 次浏览

1. « 前一页
2. 后一页 »