8月 152016
 

https://coreos.com/etcd/docs/latest/auth_api.html

auth enable 之前必须添加root用户,添加时设置密码:

开启认证:

添加一个非特权账号:(注意,这时候就需要有权限的用户来操作了)

查看有哪些账号:

添加角色:

给角色添加能力:

通过 –help 查看用法:

注意,这里只添加了 /test1 的读写权限,不包含其子目录(文件),如果需要包含,请这么写:

查看有哪些角色了:

查看指定角色的权限:

将用户添加到角色:

查看用户拥有哪些角色:

列出etcd中的所有key:(-p 选项在目录的后面添加 /)

关于用户的更多操作:

 

 

 

 

 Posted by at 上午 1:33
7月 212016
 

什么是http隧道代理?(自己搜吧)

haproxy的经典逻辑是:每个请求都分配给所配置的后端(backend)来处理;对于connect请求,原则上不需要添加配置backend的,但是这不符合haproxy的规则;测试+跟踪源代码发现: haproxy根本不能实现http隧道代理,之于option http-tunnel 配置也不过是生命不要解析第一个请求之后的数据而已,connect请求还是要原样转发给backend的

 Posted by at 下午 7:38
7月 202016
 

配置:

其中:

  1. check 说明要开启健康检查
  2. fall 100 rise 1: 失败100次才会被自动摘掉,对于被摘掉的机器,成功1次就能挂回来
  3. resolvers dns: 使用指定的dns 进行解析; 如果为开启健康检查(即: check) 则该配置将不生效(这叫什么逻辑?),参考: http://cbonte.github.io/haproxy-dconv/configuration-1.6.html#5.2-resolvers
  4. resolve-prefer ipv4: 参考ipv4地址,这个配置避免解析没有必要的ipv6, 参考: http://cbonte.github.io/haproxy-dconv/configuration-1.6.html#5.3.2

    字面意思来看:DNS总是会解析ipv4和ipv6的,只是Haproxy优先参考哪一个。
    实测的结果是:指定了ipv4后,就不会再去解析ipv6地址了(这样效率更好)
    或许dns类库也可以一下子解析出来ipv4和ipv6的

 

 Posted by at 下午 4:40
7月 192016
 
  1. mode health
    该模式用于健康检查,tcp层面的,只返回OK,如下:
  2. stats
    1. 通过http页面查看状态:
    2.  通过tcp socket查看状态:


      这个socket也可以是一个unix socket:(或者同时写两个都是可以的)


      使用nc也行:

      tcp(或unix模式)有很多命令可以使用
    3. 一个一般的配置

       

 

 

 

 

参考资料: http://www.ttlsa.com/linux/haproxy-study-tutorial/

 Posted by at 下午 12:12
6月 142016
 

源码: https://github.com/coreos/etcd

说明:

  1. master分支可能还不稳定,使用最新的release分支(下面测试的是2.3.6)
  2. 源码编译需要下载100MB左右的源文件,包含依赖文件(如果是在新的golang环境上编译的话)
  3. 如果在etcd目录下go install的话,只编译安装etcd,不编译etcdctl;需要进入ectdetl目录下go install,才会有etcdctl; 基本上就这两个二进制文件了
  4. 直接下载编译的文件比较快捷,而且这里有最新的release的二进制文件: https://github.com/coreos/etcd/releases/
  5. https://github.com/coreos/etcd 下面有一些参考文档的链接

 

集群配置:

https://github.com/coreos/etcd/blob/master/Documentation/op-guide/clustering.md

 

集群实现方式有三种:

今天了解了DNS Discovery,其中:

  1. DNS server使用的是dnsmasq
  2. DNS配置
    添加文件: /etc/dnsmasq.d/etcd.srv.conf

    其中:_etcd-server._tcp.        _etcd-client._tcp.  都是etcd自动添加的
    _etcd-server._tcp.    用于server之间交互,使用 2380 端口
    _etcd-client._tcp.     用于client(如: etcdctl )发现server,使用 2379端口

问题:

上面的dns配置基本是可用的,目前发现的唯一问题是: etcdctl –discovery-srv  etcd.i.beebank.com 来工作时,期望srv记录中拿到的是域名,而不是ip;不过etcd –discovery-srv  etcd.i.beebank.com 却没有这种苛求; 解决办法,把上面的IP换成域名,然后对域名做解析,而且,同一个域名解析出来多个IP也是不错的

 

修改如下:

/etc/hosts

/etc/dnsmasq.d/etcd.srv.conf

 

今天的测试没有涉及认证,server端启动参数:

其中:

–discovery-srv: 用于服务发现

–initial-advertise-peer-urls: 告诉其他成员,通过这个地址来联系我(对于服务发现的时候似乎用途不大,因为dns上已经注册了呀)

–initial-cluster-token: 应该是加群的暗号,暗号对不上是不让进群的

 

测试点:

  1. 通过proxy进行读写
  2. 同时通过单个实例进行读写
  3. 通过etcdctl的–discovery-srv进行读写
  4. 其中一个实例死掉一会儿,重启后依然能读到死后写入的数据
  5. 集群中一个节点到另一个节点之间都不止一个长连接
  6. 稍后测试一个全新的节点接入会是什么样子

======= v3.0.4 试用 ======

server端通过srv记录发现时,如果srv记录中解析到的是域名,则不会发现该域名下的所有IP (这个行为和v2.3.6不一致)

client端通过srv记录发现时,如果srv记录中解析到的是多个IP:PORT, 则etcdctl会试图解析已解析到的IP而报错

所以配置可修改成这样:

看起来好恶心

 Posted by at 下午 6:38
3月 282016
 

脚本:

 

阿里云的1G标准的redis,当同时40个这样的PHP进程压测的话,会有8个进程最终出现select时 1s 超时异常; 但是人家给的指标是支持 300并发的

 Posted by at 下午 3:25
3月 202016
 

在mac上,beyond compare默认没有安装命令行,需要通过如下方式安装命令行:

其中,命令行有两个命令,如下:

/usr/local/bin/bcomp:
Launches comparison and waits for it to complete.

/usr/local/bin/bcompare:
Launches comparison and returns immediately.

 

配置diff工具和配置merge工具几乎没有太大差别,这里以diff为例

首先,看看git支持哪些diff工具:

其中:

  1. 后面的工具能用,但是当前不可用;大概意思是,下面这些工具都是图形化的,需要窗口环境,但是,当前是一个terminal-only的会话,他们会失败的。 (但是,我下面要使用的bc就是图形化的呀?)
  2. bc是啥? 就是 beyond compare; 为啥还分bc和bc3?(估计是参数定义不同吧,我们配置工具的时候也不需要指定参数,肯定是git已经帮我们配置好了)
  3. git没有内置这些工具,只是默认有这些工具的相关配置
  4. 我们可以直接通过命令行参数指定使用哪个工具,如下,指定vimdiff:
    git difftool -t vimdiff
  5. 我们可以通过 -x 选项指定自定义的命令,参数就是要比较的两个文件,这样我可以使用git没有内置支持的一些工具了

配置方法, git difftool –help

参考:https://gist.github.com/jfromaniello/9207698

 Posted by at 上午 12:41
3月 162016
 

ldap有几个slap* 命令,与ldap* 命令不同的是,前者直接操作库文件,不涉及密码问题。

导出:

导入:

注意: 导入时,slapd不能是启动状态,至少使用bdb存储时如此,因为slapd启动后会对数据文件加锁;毕竟slapadd也不是通过slapd写入文件的,所以slapd没必要启动

参考资料:

http://www.361way.com/openldap-bak-imp-move/2366.html

http://www.cnblogs.com/ccdc/p/3356518.html

 

 Posted by at 下午 11:41