所谓"公钥登录"，原理很简单，就是用户将自己的公钥储存在远程主机上。登录的时候，远程主机会向用户发送一段随机字符串，用户用自己的私钥加密后，再发回来。远程主机用事先储存的公钥进行解密，如果成功，就证明用户是可信的，直接允许登录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 完成登陆

日常开发中经常会遇到单例模式的使用场景，单例模式可以保证我们初始化出来的结构体只有一个，在一些请求上下文，mysql 连接池..场景经常有着不可估量的作用。 在 golang 开发中，我们应当如何去设计单例模式呢？ 常见的错误书写方式 相信如果你对 PHP 写的比较多的情况下经常会写出下面代码一样的单例模式 package main type Singleton struct { } var ins *Singleton func GetIns() *Singleton { if ins == nil { ins = &Singleton{} } return ins } 那上述代码，在正常开发存在什么样的问题呢？上述代码如果用于 PHP 项目是没有任何问题的，因为 PHP 本事是请求隔离的，因而也不会存在并发的问题，但是如果放在常驻内存类型的语言中就会出现并发性不安全问题。 接下来考虑一个场景，在高并发场景下，同时又两个业务都执行到 ins == nil 而此时的 ins 确实没有实例化，那程序将会如何执行呢？答案显而易见，两个业务都会实例化出自己的 ins 结构体，这显然不符合我们的程序预期。 如何解决 golang 标准库sync中找到了Once类型。它能保证某个操作仅且只执行一次。有了他我们就可以很方便的解决并发的问题了接下看看代码示例： package main import "sync" type Singleton struct { } var ins *Singleton var once sync.Once func GetIns() *Singleton { once....

最近开发中，将一个 php 算法，移植到 golang 中，发现 base64 算法生成的字符串不一致，经过排查发现是由于 ASCII 控制字符导致的原因，加下来看代码 <?php $asciiArr =[10, 187, 217, 12, 207, 183, 184, 231, 184, 149, 118, 151]; $str = ''; foreach ($asciiArr as $ascii) { $str .= chr($ascii); } echo base64_encode($str); 上述代码输出： CrvZDM+3uOe4lXaX package main import ( "encoding/base64" "fmt" ) func main() { res := []int{10, 187, 217, 12, 207, 183, 184, 231, 184, 149, 118, 151} var str string var b []byte for _, v := range res { str += string(v) b = append(b, byte(v)) } byteCode := base64....

关于 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' } } } } 脚本式 脚本式基本结构如下:...

location 优先级介绍 location 匹配方式有以下几种 location = /path/a/exact.png {}: 精确匹配 location ^~ /path/a/ {}: 优先前缀匹配（符合最长匹配原则） location ~ /Path?/ {} ： 区分大小写正则匹配（首次匹配原则） location ~* /path?/ {} : 不区分大小写正则匹配（首次匹配原则） location /path/a/test.png {} : 前缀匹配（符合最长匹配原则） location 优先级匹配与配置的先后顺序无关，优先级排列顺序如下 精确匹配 > 优先前缀匹配 > 区分大小写正则匹配=不区分大小写正则匹配 > 前缀匹配 实例说明 location = /path/a/exact.png { [ configuration A ] } location ~ /Path?/ { [ configuration B ] } location ~* /path?/ { [ configuration C ] } 如果理解了优先级，将很容易得出如下结论: www.web.com/path/a/exact.png => 匹配 configuration A...