运维

当一个新盘挂载的 linux 上，可以通过 fdisk -l 指令，查看挂载的磁盘信息，此时虽然已经挂载到主机上，但是主机还不能正常使用。 要想使用新磁盘，需要经过如下几步： 磁盘分区 磁盘格式化 挂载分区到某个目录 经过上面三部后，就可以使用上新的磁盘了，接下来讲解每一步具体应该如何操作 磁盘分区 $ fdisk -l #查看主机所有的磁盘列表 如上图可以看出 /dev/vda 是新的磁盘并且没有进行分区操作，接下来对 /dev/vda 磁盘进行分区操作 $ fdisk /dev/vda // 进入分区操作，这里要填写你的新磁盘信息，不一定和示例一致 $ m //查看帮助 上图为分区对应的各个操作 $ p #输入 p 查看分区列表 目前并没有划分分区，接下来进行第一个分区的划分 $ n #输入 n 划分分区 $ p # 输入 P 划分为主要分区 接下来需要填写编号（1-4之间）和 磁盘的开始扇区和结束山区 这里由于磁盘不大就没有进行过于细的划分，将所有磁盘容量全部划分到主分区1中 $ w # 输入 w 保存 到此磁盘的划分就已经全部完成，再次输入 fdisk -l 可以看到新划分的主分区 /dev/vda1 格式化磁盘 磁盘划分好后，继续要格式分区，这里使用 ext4 进行格式化 $ mkfs.ext4 /dev/vda1 # 用 ext4 扩展文件系统进行格式化 输入完上述命令后，就可以完成格式化了，如果有报错，请参考常见问题章节解决。...

所谓"公钥登录"，原理很简单，就是用户将自己的公钥储存在远程主机上。登录的时候，远程主机会向用户发送一段随机字符串，用户用自己的私钥加密后，再发回来。远程主机用事先储存的公钥进行解密，如果成功，就证明用户是可信的，直接允许登录shell，不再要求密码。 要实现公钥登陆的前提是需要用户端需要先生成公/私钥对，正常情况下都是有的，目录为：用户目录下的 .ssh 文件夹，私钥没有后缀，公钥后缀为 .pub。 如果没有公私密钥的话可以使用 ssh-keygen 进行生成. 复制代码 ssh-keygen -f test // -f 制定公司钥名称，回车进入下一步 Enter passphrase (empty for no passphrase): // 这里是密钥口令，如果担心私钥安全可以设置一下 Enter same passphrase again: // 确认密钥口令，回车后完成生成 服务器导入公钥 命令行导入 3ssh-copy-id -i ~/.ssh/test.pub user@host 手动导入 通过账号密码登陆服务器，将公钥复制到 ~/.ssh 目录下,执行下方命令: cat RemotePPK.pub >> authorized_keys xshell 使用公钥登陆演示 输入用户名 选择公钥登陆 导入密钥 选择导入好的密钥点 Ok 点击OK 完成登陆

关于 Jenkins 的环境变量，可以分为系统内置环境变量和自定义环境变量。系统内置环境变量是 Jenkins 内部定义的环境变量。自定义环境变量是用户自己定义的环境变量 系统环境变量 jenkins 的内置环境变量的查看方式有两种，一种是通过 web url 地址查看，另一种是通过 shell 命令 printenv 查看 方式一:通过地址访问 直接在浏览器中访问 ${YOUR_JENKINS_HOST}/env-vars.html 页面就可以，比如 http://localhost:8080/env-vars.html ，每个变量的用途写的都很清楚 方式二：printenv 通过 shell 命令printenv 获取 pipeline { agent any stages { stage("Env Variables") { steps { sh "printenv" } } } } 通过执行上述 pipeline 的构建，就可以打印出系统内置的环境变量 自定义环境变量 在内置环境变量的基础上，有事我们也需要定义我们自己的的环境变量来方便开发和部署，自定义环境变量的设置分为三种，分别是：声明式，脚本式，内置函数式，接下来分别讲解一下三种方式各是如何设置的。 声明式 声明式定义结构如下： environment { key = value } 声明式可以在 pipeline 的任意阶段声明，看如下示例 pipeline { agent { label any } environment { //全局环境变量 NAME = "zhangsan" } stages { stage('Build') { environment { // 仅在 Build 阶段下有效的环境变量 NAME = "Andy" } steps { sh 'printenv' } } } } 脚本式 脚本式基本结构如下:...

随着 nodejs 的兴起，前端开发也进入了 新的时代，webpack 的诞生，更是让其如虎添翼，构建出欣欣向荣的前端生态. 然而事物的发展总是在：发现问题->解决问题->引入新问题中往复。 webpack 给前端带来了一个新的高频操作就是打包，高频的打包会带来如下问题： 阻塞前端工作：前端必须等到打包完成，才能 进入后续工作,如果打包时间过长，这中间就会阻塞就会更加明显。 影响团队协作：当功能点开发完成后，未避免频繁打包，会将多个功能点合并在 一起打包，这样就会导致测试没有办法提前介入测试，如果测试出问题的功能点是在几天前开发的，对于代码已经有所遗忘，还需要阅读代码帮助找回记忆gg。 打断专注时间：如果前端正在专注的解决一个复杂问题,此时出现紧急问题需要打包，使得前端不得不从当前工作中抽身出来进行打包，打包完成后将需要一段时间的预热才可以像之前一样 专注的处理未完成的问题。 对于上述 问题完全可以通过工具构建出一套 CI/CD 方案交由计算机来解决，让前端工程师从打包解放出来。 工具 jenkens: 是一款由 JAVA 编写的开源的持续集成工具. gogs: 轻量级代码仓库 jenkins 与 gogs 的通讯是通过 Gogs plugin 通过 webhook 来通讯的。 方案 方案设计大致如下： 方案执行步骤： 前端工程师往代码仓库 push 代码 gogs 会调用 jenkins 的 webhook 地址触发 jenkins 工作流 jenkins 会将前端代码从代码仓库中拉取最新的代码，并执行构建流程 将构建好的代码上传到 dist 仓库(如果存在 CDN 则清除 CDN 缓存) push dist 仓库到 gogs 远程仓库 gogs 触发 dist 仓库的 webhook,将服务器代码更新到最新的打包文件 完成部署 测试人员执行测试用例（如果由缺陷，将缺陷反馈给前端开发人员） 好处 完成上述方案，前端工程师只需要将前端代码 push 到远程仓库，服务器会自动构建响应的包，并部署到测试服务器上供测试测试,前端可以缩小提交粒度并更快的将功能交付测试，也可以将问题尽早暴露尽早解决。...