Error - Jenkins detected running multiple instances

我使用的 Jenkins 放在 kubernetes 中运行。今天出现了漂移的现象,因为没有做共享存储,运行时数据全都没有了。二话不说把数据迁移了过来,没想到运行时在web界面上显示了以下错误:

Jenkins detected that you appear to be running more than one instance of Jenkins that share the same home directory '’. This greatly confuses Jenkins and you will likely experience strange behaviors, so please correct the situation.

This Jenkins: 17485453 contextPath="" at 1264@< MachineName >
Other Jenkins: 15621395 contextPath="" at 13424@< MachineName >

原因是我在转移数据的时候没有重启服务,导致系统运行前后数据不一致,重启容器即可解决 。

参考资料


使用 docker 部署 jekyll 本地开发环境

自从使用上 docker,安装软件环境再也不是一件痛苦的事。以下是我在 Windows 下运行 Jekyll 的 docker-compose.yml 文件:

version: '2'
services:
  site:
    network_mode: "host"
    command: jekyll serve
    image: jekyll/jekyll:latest
    volumes:
      - D:\GitHub\kelvinblood.github.com:/srv/jekyll
      - D:\GitHub\kelvinblood.github.com/vendor/bundle:/usr/local/bundle

只需要在当前目录下运行

docker-compose up -d

即可。

参考资料


api 使用 session 与 token 的利弊

转自 cipchk - segmentfault

在存储过等同的情况下,在只是简单运用上,我只能说session与token没有本质的区别,二者不都是一串被加密过的字符串,拿他来做校验都一样。

以上,是因为你把token拿来当作用户是不是当事人做这么一个简单的校验的情况下。

当然,如果我们抛开一些比较极端的操作,token比session也有很大的区别:

  • token可以存在任何位置(cookie、local storage)
  • token比session更容易跨域。
  • CORS预检查时token比较更简单。
  • token有更多的控制权,比如当token过期时,你可以拿通过刷新token,让用户一直保持有效登录。

等……其实如果你只是单纯拿着token做一下自己网站内用户登录检验的话是无太多区别的。

但假如token指的是OAuth Token提供认证和授权这类机制的话,那么就可以把session甩开N条街了,甚至是已经完全是两种不同的概念。

假设有这么一个场景,你们用户在你们网站产生的订单,而另一家公司是专业ERP公司;而你的用户希望他的订单同时授权给这家ERP公司使用的情况下,难道你希望用户拿在你家网站的用户名和密码给这家ERP公司吗?

这时候OAuth Token就有意义了,OAuth Token的授权大概是这样的:

  • ERP需要调用我们提供的登录界面。
  • 用户输入用户名和密码后,我们再向ERP发送一个TOKEN。
  • ERP拿TOKEN换数据。

总之,如果你只是在自己网站内部上使用二者没有什么太多区别。而如果你的API是在不同终端上使用,token会更方便。

参考资料


laravel 中使用 nodejs + socket.io + redis 构建即时应用

目前已经在后台运行通过,

主要参考以下四篇文章,更详细的流程今后再总结。

参考资料


数据库优化尝试

最近个人网站的流量开始多了起来,以前写的代码比较粗放,目前同时在线人数不足30人,就有一些吃力了,1c的机器负载常年为1.5~2。优化有两个方向,一个是数据库优化,查找费时的语句,以此为基础进行优化,同时还可以做分库等高级方式;二是使用 redis 等内存数据库,将常用数据全部放到缓存中,加快系统速度。

目前只做了最基础的数据库优化,便将负载降到了0.2。已经满足了当前的需求了。这篇文章记录下整个过程。

1 开启慢查询语句跟踪

在配置文件 postgresql.conf 简单设置以下参数,当然还有错误级别等要设置。

vi /etc/postgresql/9.4/main/postgresql.conf

# 以log_开头的配置都可以关注一下,主要是下面几个要配置好
logging_collector = on
log_destination = 'stderr'
log_rotation_age = 1d
log_rotation_size = 10MB
log_min_duration_statement = 1000
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'

log_statement: 设置跟踪的语句类型,有4种类型:none(默认), ddl, mod, all。跟踪所有语句时可设置为 “all”。

log_min_duration_statement: 跟踪慢查询语句,单位为毫秒。如设置 5000,表示日志将记录执行5秒以上的SQL语句。

当 log_statement=all 和 log_min_duration_statement 不能同时开启,只设置一个即可。

2 代码逻辑中删除不必要的数据

一个临时表一样的数据表,应该定期删除数据。当时发现一个数据表存有上百万条数据,而这张表只是临时表,1小时后便没有了用处。这种表应当在代码逻辑中及时删除。

对于常用的数据,则可以考虑将其放入内存中,减少数据库读取。这部分内容未来再开新文章记录。

3 根据日志为数据库添加索引

对于一些 Where 的语句,注意 where 使用到的项,出现次数多的,将他们加入索引。

总结

目前通过以上三个步骤,基本解决了我小网站的负载问题。

除此外,还可以将数据表按年月日归档、专门建立统计表等方式,进一步优化。目前还不紧急,待未来再实践。

参考资料