未分类

centos用 yum 方式安装 nodejs 和 npm 要通过 yum 来安装 nodejs 和 npm 需要先给 yum 添加 epel 源， 添加方法在 centos 添加epel和remi源 中 安装完成后,执行

  注：centos 添加 epel 和 remi 源 添加 epel 源 64位:

32位:

导入 key:

添加 remi 源

  问题解决： yum 安装完node版本是6.17.1，通过npm install –registry=https://registry.npm.taobao.org 安装时会报以下错误： fetchMetadata: Read more…

安装ipa-client时， 遇到如下错误：

  执行kinit admin:

去ipa server端查询：

  原来是尝试次数过多（默认6次）被锁了 解锁一下：

再次安装ipa-client， 成功。

docker内置dnsserver工作机制 环境 测试环境为docker社区版本17.03。 docker容器的网络命名空间默认无法通过ip netns命令查询到，因此有两种办法。都需要通过docker inspect -f "{{.State.Pid}}" <container_id>找到容器的初始进程开始。 通过ln -s /proc/<pid>/ns/net /var/run/ns/<container_id>，将命名空间暴漏在ip netns下，继续后续操作。本文就采用这种办法，好处就是可以利用容器中没有而主机上有的命令行。 通过nsenter –target <pid> –mount –uts –ipc –net –pid进入容器命名空间，再执行操作。 原理介绍 容器的dns解析顺序 容器中的DNS名称解析优先级顺序为： ​ 内置DNS服务器127.0.0.11。 ​ 通过–dns等参数为容器配置的DNS服务器。 ​ docker守护进程的–dns服务配置（默认为8.8.8.8和8.8.4.4） ​ 宿主机上的DNS设置。 docker dns server工作机制 1）一般情况下，使用docker网络的容器的dns服务器是127.0.0.11。如下图所示： 2）通过命令查看容器内的iptables规则。如下图所示： 可以发现到127.0.0.11的53端口的dns请求，被转发到了43747端口。那么这个端口是被什么程序监听的呢？ 3）在容器的网络命令空间中，可以通过命令netstat -ntlp查到监听这个端口的程序，如下图所示： docker containerd进程上了，它会向内部存储做查询，返回dns的查询结果。 如果容器中有netstat命令行，由于进程空间隔离的原因，直接在容器中查询监听端口时，会出现对应进程为-的输出，只能在主机上执行才可以。

$# 传递到脚本的参数个数 $* 以一个单字符串显示所有向脚本传递的参数 $$ 脚本运行的当前进程ID号 $! 后台运行的最后一个进程的ID号 $@ 与 $* 相同，但是使用时加引号，并在引号中返回每个参数。 $- 显示Shell使用的当前选项，与set命令功能相同。 $? 显示最后命令的退出状态。0表示没有错误，其他任何值表明有错误。 $0 Shell本身的文件名 $1～$n 添加到Shell的各参数值。$1是第1参数、$2是第2参数…。 [ -f “somefile” ] ：判断是否是一个文件 [ -x “/bin/ls” ] ：判断/bin/ls是否存在并有可执行权限 [ -n “$var” ] ：判断$var变量是否有值 [ “$a” = “$b” ] ：判断$a和$b是否相等 -r file　　　　　用户可读为真 -w file　　　　　用户可写为真 -x file　　　　　用户可执行为真 -f file　　　　　文件为正规文件为真 -d file　　　　　文件为目录为真 -c file　　　　　文件为字符特殊文件为真 -b Read more…

spf13-vim编辑有些文件时颜色不高亮显示的解决办法: 方法一: 将~/.vimviews/文件夹下清空 方法二: 设置一下文件类型 :set filetype=sh

Recently， my VPS install shadowsocks and connected and throw a error 500 Internal Privoxy Error , thanks. The vps is Linode. 最近 shadowssocks 经常出现 500 Internal Privoxy Error 错误，怎么解决，谢谢。 解决： 关闭shadowsocks客户端，清空系统临时文件(ccleaner)，C:\Users\shang\AppData\Local/Temp   https://www.bountysource.com/issues/39146684-sometimes-500-internal-privoxy-error

1、业务架构：从单体式到微服务 K歌亭是唱吧的一条新业务线，旨在提供线下便捷的快餐式K歌方式，用户可以在一个电话亭大小的空间里完成K歌体验。K歌亭在客户端有VOD、微信和Web共三个交互入口，业务复杂度较高，如长连接池服务、用户系统服务、商户系统、增量更新服务、ERP等。对于服务端的稳定性要求也很高，因为K歌亭摆放地点不固定，很多场所的运营活动会造成突发流量。 为了快速开发上线，K歌亭项目最初采用的是传统的单体式架构，但是随着时间的推移，需求的迭代速度变得很快，代码冗余变多，经常会出现牵一发动全身的改动。重构不但会花费大量的时间，而且对运维和稳定性也会造成很大的压力；此外，代码的耦合度高，新人上手较困难，往往需要通读大量代码才不会踩进坑里。 鉴于上述弊端，我们决定接下来的版本里采用微服务的架构模型。从单体式结构转向微服务架构中会持续碰到服务边界划分的问题：比如，我们有user 服务来提供用户的基础信息，那么用户的头像和图片等是应该单独划分为一个新的service更好还是应该合并到user服务里呢？如果服务的粒度划分的过粗，那就回到了单体式的老路；如果过细，那服务间调用的开销就变得不可忽视了，管理难度也会指数级增加。目前为止还没有一个可以称之为服务边界划分的标准，只能根据不同的业务系统加以调节，目前K歌亭拆分的大原则是当一块业务不依赖或极少依赖其它服务，有独立的业务语义，为超过2个的其他服务或客户端提供数据，那么它就应该被拆分成一个独立的服务模块。 在采用了微服务架构之后，我们就可以动态调节服务的资源分配从而应对压力、服务自治、可独立部署、服务间解耦。开发人员可以自由选择自己开发服务的语言和存储结构等，目前整体上使用PHP做基础的Web服务和接口层，使用Go语言来做长连接池等其他核心服务，服务间采用thrift来做RPC交互。 2、系统架构的构思与解读 2.1 容器编排 唱吧K歌亭的微服务架构采用了Mesos和Marathon作为容器编排的工具。在我们选型初期的时候还有三个其他选择，Kubernetes、 Swarm、 DC/OS： DC/OS：作为Mesosphere公司的拳头产品，基本上是希望一统天下的节奏。所以组件很多，功能也很全面。但是对于我们在进行微服务架构初期，功能过于庞大，学习成本比较高，后期的生产环境维护压力也比较大。 Swarm：Docker公司自己做的容器编排工具，当时了解到100个以上物理节点会有无响应的情况，对于稳定性有一些担忧。 Kubernetes：Google开源的的容器编排工具，在选型初期还没有很多公司使用的案例，同时也听到了很多关于稳定性的声音，所以没有考虑。但是在整个2016年，越来越多的公司开始在线上使用Kubernetes，其稳定性逐步提高，如果再选型应该也是个好选择。 Mesos：因为了解到Twitter已经把Mesos用于生产环境，并且感觉架构和功能也相对简单，所以最后选择了Mesos+Marathon作为容器编排的工具。   2.2 服务发现 我们采用了etcd作为服务发现的组件，etcd是一个高可用的分布式环境下的 key/value 存储服务。在etcd中，存储是以树形结构来实现的，非叶结点定义为文件夹，叶结点则是文件。我们约定每个服务的根路径为/v2/keys/service/$service_name/，每个服务实例的实际地址则存储于以服务实例的uuid为文件名的文件中，比如账户服务account service当前启动了3个可以实例，那么它在etcd中的表现形式则如下图: 当一个服务实例向etcd写入地址成功时我们就可以认为当前服务实例已经注册成功，那么当这个服务实例由于种种原因down掉了之后，服务地址自然也需要失效，那么在etcd中要如何实现呢？ 注意，图中的每个文件有一个ttl值，单位是秒，当ttl的值为0时对应的文件将会被etcd自动删除。当每个服务实例启动之后第一次注册时会把存活时间即ttl值初始化为10s，然后每隔一段时间去刷新ttl，用来像向etcd汇报自己的存活，比如7s，在这种情况下基本啥上可以保证服务有效性的更新的及时性。如果在一个ttl内服务down掉了，则会有10s钟的时间是服务地址有效；而服务本身不可用，这就需要服务的调用方做相应的处理，比如重试或这选择其它服务实例地址。 我们服务发现的机制是每个服务自注册，即每个服务启动的时候先得到宿主机器上面的空闲端口；然后随机一个或多个给自己并监听，当服务启动完毕时开始向etcd集群注册自己的服务地址，而服务的使用者则从etcd中获取所需服务的所有可用地址，从而实现服务发现。 同时，我们这样的机制也为容器以HOST的网络模式启动提供了保证。因为BRIDGE模式确实对于网络的损耗太大，在最开始就被我们否决了，采用了HOST模式之后网络方面的影响确实不是很大。 2.3 监控，日志与报警 我们选择Prometheus汇总监控数据，用ElasticSearch汇总日志，主要的原因有： 生态相对成熟，相关文档很全面，从通用的到专用的各种exporter也很丰富。 查询语句和配置简单易上手。 原生具有分布式属性。 所有组件都可以部署在Docker容器内。 Mesos Exporter，是Prometheus开源的项目，可以用来收集容器的各项运行指标。我们主要使用了对于Docker容器的监控这部分功能，针对每个服务启动的容器数量，每个宿主机上启动的容器数量，每个容器的CPU、内存、网络IO、磁盘IO等。并且本身他消耗的资源也很少，每个容器分配0。2CPU，128MB内存也毫无压力。 在选择Mesos Exporter之前，我们也考虑过使用cAdvisor。cAdvisor是一个Google开源的项目，跟Mesos Exporter收集的信息八成以上都是类似的；而且也可以通过image字段也可以变相实现关联服务与容器，只是Mesos exporter里面的source字段可以直接关联到marathon的application id，更加直观一些。同时cAdvisor还可以统计一些自定义事件，而我们更多的用日志去收集类似数据，再加上Mesos Exporter也可以统计一些Mesos本身的指标，比如已分配和未分配的资源，所以我们最终选择了Mesos Exporter。 如下图，就是我们监控的部分容器相关指标在Grafana上面的展示： Node exporter，是Prometheus开源的项目，用来收集物理机器上面的各项指标。之前一直使用Zabbix来监控物理机器的各项指标，这次使用NodeExporter+Prometheus主要是出于效率和对于容器生态的支持两方面考虑。时序数据库在监控数据的存储和查询的效率方面较关系数据库的优势确实非常明显，具体展示在Grafana上面如下图： Filebeat是用来替换Logstash-forwarder的日志收集组件，可以收集宿主机上面的各种日志。我们所有的服务都会挂载宿主机的本地路径，每个服务容器的会把自己的GUID写入日志来区分来源。日志经由ElasticSearch汇总之后，聚合的Dashboard我们统一都会放在Grafana上面，具体排查线上问题的时候，会用Kibana去查看日志。 Prometheus配置好了报警之后可以通过AlertManager发送，但是对于报警的聚合的支持还是很弱的。在下一阶段我们会引入一些Message Queue来自己的报警系统，加强对于报警的聚合和处理。 ElastAlert是Yelp的一个Python开源项目，主要的功能是定时轮询ElasticSearch的API来发现是否达到报警的临界值，它的一个特色是预定义了各种报警的类型，比如frequency、change、flatline、cardinality等，非常灵活，也节省了我们很多二次开发的成本。 Read more…

公司的OpenVPN在win10上连不上了，在Mac上连接正常， 拨号成功后，OpenVPN 的日志中隔几秒就出现： Route: Waiting for TUN/TAP interface to come up… 一段时间后直接出现失败的提示，虽然OpenVPN会变成绿色，并且鼠标移上去会显示出10开头的内网IP，但是其实是不能访问公司内网的，VPN并没有成功拨号。 在网上搜了一下，最终解决方案如下： 使用管理员权限打开cmd窗口，然后输入： netsh winsock reset catalog netsh int ipv4 reset reset.log 重启电脑即可解决。  

添加新用户报错的解决方法 用ipa在添加一个新用户的时候， 报如下错误（在三台集群上都报同样的错误）： 放狗搜索， 查到如下文章：  ======================================================== https://blog-rcritten.rhcloud.com/?p=50 FREEIPA AND NO DNA RANGE JANUARY 5, 2015 RCRITTEN 3 COMMENTS Ok, so let’s say you have an initial IPA master and one more more additional masters (aka replicas). You’ve always done all administration on the first one and it is now temporarily or Read more…

MarkdownPad 2 在win10系统下报错html渲染错误 参考 MarkDownPad 的官方 faq LivePreview is not working – it displays an error message stating This view has crashed! This issue has been specifically observed in Windows 8. You may see an error message as shown here, and no HTML will be rendered when you type in the Read more…