发表于

2018年6月份时基于Docker搭建了一个Gitlab，最近由于机器升级，需要迁移到新机器。那么问题来了？

  • Gitlab如何备份？
  • Gitlab如何完整的迁移？

废话不多说，直接上命令吧：（假设运行Gitlab的的Docker容器名字为gitlab）

Gitlab备份

都说云主机很安全，但是总觉得没个备份心里不踏实。之前Gitlab的运行命令如下：

1
sudo docker run --detach     --hostname gitlab.xxx.com     --publish 443:443 --publish 80:80 --publish 1024:1024     --name gitlab     --restart always     --volume /srv/gitlab/config:/etc/gitlab     --volume /srv/gitlab/logs:/var/log/gitlab     --volume /srv/gitlab/data:/var/opt/gitlab     docker.io/gitlab/gitlab-ce:latest

数据挂载在/srv/gitlab目录下。

备份命令：

1
docker exec -t gitlab gitlab-rake gitlab:backup:create

创建Gitlab的备份，备份文件位于/srv/gitlab/data/backups目录下，生成的文件名如1548648399_2019_01_28_11.0.1_gitlab_backup.tar，其中11.0.1是当前gitlab的版本号，恢复时使用的gitlab必须是同样的版本号，否则没法进行恢复。该文件里面包含了所有user、group、git repository数据。

Gitlab迁移

1> 准备好新机器、安装docker

2> 拉相应版本的gitlab-ce镜像

1
docker pull gitlab/gitlab-ce:11.0.1-ce.0

3> 运行全新Gitlab容器

1
sudo docker run --detach     --hostname gitlab.xxx.com     --publish 443:443 --publish 80:80 --publish 1024:1024     --name gitlab     --restart always     --volume /srv/gitlab/config:/etc/gitlab     --volume /srv/gitlab/logs:/var/log/gitlab     --volume /srv/gitlab/data:/var/opt/gitlab     docker.io/gitlab/gitlab-ce:11.0.1-ce.0

4> 复制备份文件到backups目录

1
2
3
4
5
6
7
8
# 停掉gitlab容器
docker stop gitlab

# 复制备份文件
cp 1548648399_2019_01_28_11.0.1_gitlab_backup.tar /srv/gitlab/data/backups/

# 重启gitlab容器
docker start gitlab

5> 进入gitlab容器，恢复Gitlab数据

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# 进入GITLAB
docker exec -it gitlab /bin/bash

# 停止数据服务
gitlab-ctl stop unicorn
gitlab-ctl stop sidekiq

# 检查状态
gitlab-ctl status

# 数据恢复
sudo gitlab-rake gitlab:backup:restore BACKUP=1548648399_2019_01_28_11.0.1

# 重启并验证

sudo gitlab-ctl restart
sudo gitlab-rake gitlab:check SANITIZE=true

至此，完成数据迁移，恢复到和之前一模一样。记录一下迁移过程，以备后用！

发表于

Telegraf是一个用Golang写的开源数据收集Agent，基于插件驱动。本身提供的输入和输出插件非常丰富，当然有需求也可以自行编写（需要重新编译）。Telegraf是influxdata公司的时间序列平台TICK技术栈中的“T”，主要用于收集时间序列型数据，比如服务器CPU指标、内存指标、各种IoT设备产生的数据等等。后面抽空会介绍TICK栈中的其他技术及其应用。

Telegraf

阅读全文 »

发表于

补丁（Patch）是软件生命周期管理的一部分，当软件有BUG需要进行修复，或者新增特性时都可以通过打补丁的形式更新到用户手里。补丁按照作用可以分为N种：修复BUG的叫BUGFIX、解决安全问题的叫安全补丁、等等。软件更新中的补丁文件类型主要是二进制的，补丁也大量用于代码开发过程中，想当年Linux内核的代码主要就是靠社区开发者把修改制作成补丁发给Linus大佬，据说Apache服务器的名字就来自“A Patch”，如今的版本控制软件SVN、Git虽说可以自动完成修改的合并，但其原理也是基于差异和补丁的思想。

补丁流程

补丁是软件、代码、各种更新中非常重要的手段，废话不多说，今天主要介绍一下Linux生成补丁的差异工具（Diff）和打补丁的工具（Patch）：

  • 历史悠久的diff 和 patch，主要用于制作文本类型的补丁。
  • 二进制差异和补丁工具bsdiff 和 bspath
  • Google的小胡瓜Courgette。
阅读全文 »

发表于

经常我们会做各种优化，神马程序性能优化，编译效率优化，开发流程优化，产品功能优化，等等，试问有啥不可以优化的，包括我们自己本身在各个方面也可以进行优化。怎么进行优化，优化什么，有没有大的指导逻辑了？

最近看了一篇文章受益匪浅，计算机科学家阿姆达尔给出一个做优化的大逻辑。说白了，道理很简单，也很符合我们的直觉，科学家为啥牛逼，就是可以把一些浅显的道理构建一个数学模型，进行量化，让你举棋不定的时候，给出选择。（PS.懒得看公式的同学，直接跳到末尾看结论）

阿姆达尔（Amdahl）何许人也？IBM大型机系统System/360之父，在做大型机这么复杂的系统的时候，在不断对系统进行性能提升时，总结出来一个经验公式：

Amdahl

其中：

  • S - 性能提升（加速）
  • s - 系统中某一项指标的提升
  • p - 这项指标在整个系统/流程被用到的占比

考虑一下极限情况（假设该项指标可以被提升到无限大），结果如下：

Amdahl

公式看完，我们来考虑一个老爷子老本行的一个例子：

要做一个计算机系统的优化，简单点只涉及到内存和CPU，假设执行一些任务时，CPU用到90％，内存10％。

对CPU进行多核化，假设分别为4核、8核、32核、128核、512核，来通过阿姆达尔公式计算下加速比：

  • S(4) = 1/(1-0.9 + 0.9/4) = 3.08
  • S(8) = 1/(1-0.9 + 0.9/8) = 4.71
  • S(32) = 1/(1-0.9 + 0.9/32) = 7.80
  • S(128) = 1/(1-0.9 + 0.9/128) = 9.34
  • S(512) = 1/(1-0.9 + 0.9/512) = 9.83

曲线可以参考下面紫色那条：

Amdahl

可以看到开始多增加几个核心，效率线性提升，但是随着核心超过128，效率提升就非常不明显，就算你很牛逼，把无穷个核心都挂上去，效率提升也就那样了，趋近极限值：1/(1-0.9）= 10。（这也是为啥这几年摩尔定律失灵之后，计算机采用多核CPU技术提升效率，但是靠多核也是有极限的，现在很少有64核心以上的机器吧？为啥，加再多CPU核心，毛用都没）

难道计算机系统就这样了没有提升空间了吗？当然不是，问题的关键点就转移到CPU用到的百分比了，假设去优化内存，把内存做的存取速度超过，执行某些任务的时候，内存用的比例低了，CPU的比例提上去了，假设为95%，看下上图绿色和紫色的对比就知道效率的差异了。

此刻，把老爷子的公式推及到所有要做优化的事情，把刚才的例子和我们要做的优化做类比，你会发现，我去，还真就是那么回事。

假设要做开发流程的优化，第一个要优化的是什么？假设程序猿有下面三个活动要进行优化：编译、部署、测试。编译要用60分钟，部署20分钟，测试40分钟。假设把编译时间和部署时间缩小到一半要花的成本相同，那么选择优化编译肯定是没错的。根据阿姆达尔公式进行计算，提升编译速度效率可以提升1.4倍=1/(1-0.6 + 0.6/2)，而去优化部署则只能提升1.11倍=1/(1-0.2 + 0.2/2)。和我们的直觉是一致的：同等成本的提升，优化当然要找占比大的了。

下面这个就不太好根据直觉判定了，假设编译时间减半和部署优化到0.2分钟（效率100倍提升），花费的代价是一样的，这个时候怎么选择？我们直觉往往会选择一些看似提升比例很大，或者容易做的事情，结果会是怎样了？部署效率提升100倍，总的提升是1.24倍=1/(1-0.2 + 0.2/100)，比起编译速度减半的提升1.4还是要少一些的。

综上，根据阿姆达尔定律，我们可以得出一些做优化的大逻辑：

  • 做优化，你首先得分解，找到可以优化的点，分析各个点相对于整个系统的占比。
  • 花费同等时间和精力，选择占比最大的点去优化。
  • 对于系统来说，某个点的优化是有极限的，到了一定程度，再多努力都是无用功。
  • 仔细评估各个点优化的代价，选择性价比最高的（Amdahl定律），而不是挑软柿子捏，否则自我感觉良好，屁用没有。
  • …

可以试着把阿姆达尔提供的这个大逻辑，类比到自我提升、程序性能优化等等。大道至简，好玩！

发表于   |   分类于

常言道：工欲善其事，必先利其器；能用键盘坚决不用鼠标；能敲一下搞定坚决不敲多次。作为一个变态的程序猿，都是这么要求自己的。之前也收集了许多效率工具，很有必要拿出来分享一下。今天介绍一个本地文件搜索工具：Everything，对于那些桌面和磁盘文件经常乱七八糟的，找个东西花半天的同学特别适用。Everything这个工具，当你第一次启动它的时候，它会快速地把你磁盘里面所有文件根据文件名生成索引，当然也可以根据需要，可以指定要查找的目录或者排除掉一些目录，然后可以根据文件名精确、模糊去匹配，快速定位到想要的文件。

阅读全文 »

发表于   |   分类于

读万卷书，行万里路！作为游戏开发者，我才刚上路！

无意中通过关注的公众号看到腾讯游戏开发者大会（TGDC），也就信手报个名。一个人封闭太久了，是需要出来转转才能知道世界有多大。说实在话，自己一直从事的是游戏后端开发，TGDC关于技术的内容，完全是硬着头皮听下来的，但同时也算是一扇大门像自己敞开了，游戏前端技术博大精深，有兴趣深入研究，必大有可为。

游戏做为一门技术活的同时，又是门艺术活，需要各个专业团队的紧密协作才能成功。

TGDC

下面就把每一场演讲我所获得的知识和思考记录下来。（注意：不是完整内容，全凭记忆和自己理解了）

阅读全文 »