安装Gitlab Runner

Gitlab CI 简介

Gitlab中集成了CI (Continuous Integration:持续集成) 和CD (Continuous Delivery:持续交付) 来方便用户测试、构建、部署代码。它是Gitlab的一部分,用户可以在 Gitlab.com 上免费使用,同时也包含在了开源的Gitlab社区版和付费的Gitlab企业版中。

Gitlab CI具有如下特性:

  • 多平台:您可以在任何支持Go语言的平台上运行,例如:Unix、Windows、OSX等。
  • 多语言:构建脚本是通过命令行驱动的,可以支持诸如Java、PHP、Ruby、C等任何语言。
  • 稳定:您的构建操作可以运行在其他机器上,而不是Gitlab上。
  • 并行构建:为了加快构建速度,Gitlab CI将任务分别运行在多个不同机器上。
  • 实时日志:可以通过链接查看到实时更新的构建日志。
  • 版本化的测试:每个人都可以对.gitlab-ci.yml文件提交修改以确保每个分支都能够得到所需要的测试。
  • 管道:您可以为每个阶段定义多个任务并且触发其他构建操作。
  • 弹性运行:可以自动增加或者减少虚拟机的数量以保证所有的构建操作都立即执行并且代价最小。
  • 编译好的文件:您可以上传二进制代码以及其他编译好的文件,并且能够浏览以及下载他们。
  • 本地测试:Gitlab中有多个线程池,您可以利用它们运行本地测试。
  • Docker支持:您可以很容易的将其他的Docker容器服务集成进来作为测试的一部分,并且能够构建docker镜像。

Gitlab CI是Gitlab的一部分,它是一个带有api的web应用程序,可以将运行状态都保存在数据库中,除了Gitlab的功能外,它也能管理项目的构建过程,并且提供了一个很友好的用户界面。

Gitlab Runner是一个执行构建操作的应用程序,他能够被单独部署到其他机器上,通过API与Gitlab CI协作运行。Gitlab Runner可以被部署到任何支持Go语言二进制文件运行的环境中,例如Linux、OSX、Windows、FreeBSD以及Docker。它也能够测试任何编程语言书写的代码,例如.Net、Java、Python、C、PHP等等。

为了运行测试功能,您需要至少一个Gitlab实例和一个Gitlab Runner。

安装Gitlab Runner

安装Gitlab Runner可以有三种方法,通过Docker安装、下载二进制文件手动安装以及使用Gitlab提供的rpm/deb包通过包管理系统进行安装。我们使用第三种方式,也是Gitlab官方推荐的安装方式,目前Gitlab支持Debian、Ubuntu、RHEL以及CentOS的包管理工具安装。

如果您想使用Docker runner,那么必须要在安装Gitlab Runner之前安装它。

1
curl -sSL https://get.docker.com/ | sh

通过 apt-get 或者 yum 添加Gitlab官方软件源。

1
2
3
4
5
# For Debian/Ubuntu
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bash
# For RHEL/CentOS
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash

覆盖APT设置-仅Debian系统

自从Debian Stretch开始,Debian维护者添加了一个和我们软件包具有相同名称的一个他们的官方软件包,并且默认情况下官方的软件仓库拥有优先权,如果您想使用Gitlab的软件包,那么必须手动设置软件包的安装源,最佳方法就是添加一个额外的配置文件覆盖掉原来的配置。接下来的每一个版本的更新,无论是手动更新还是自动更新,都将会使用同样的软件源。

1
2
3
4
5
6
cat > /etc/apt/preferences.d/pin-gitlab-runner.pref <<EOF
Explanation: Prefer GitLab provided packages over the Debian native ones
Package: gitlab-ci-multi-runner
Pin: origin packages.gitlab.com
Pin-Priority: 1001
EOF

#

安装gitlab-ci-multi-runner

1
2
3
4
5
# For Debian/Ubuntu
sudo apt-get install gitlab-ci-multi-runner
# For RHEL/CentOS
sudo yum install gitlab-ci-multi-runner

注册runner

此处需要使用一个token,使用管理员账号登陆gitlab并到http://gitlab.exmaple.com/admin/runners 可以查到,详细的说明可以通过查阅 runner文档 学习。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
sudo gitlab-ci-multi-runner register
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )
https://gitlab.com
Please enter the gitlab-ci token for this runner
xxx
Please enter the gitlab-ci description for this runner
my-runner
INFO[0034] fcf5c619 Registering runner... succeeded
Please enter the executor: shell, docker, docker-ssh, ssh?
docker
Please enter the Docker image (eg. ruby:2.1):
ruby:2.1
INFO[0037] Runner registered successfully. Feel free to start it, but if it's
running already the config should be automatically reloaded!

执行完上述命令之后,使用管理员账号登陆gitlab并到http://gitlab.exmaple.com/admin/runners即可查看到已经注册好的gitlab runner。

关于Gitlab服务器的搭建

Gitlab简介

Gitlab 是一个用于管理GIT代码库的项目,提供权限管理、代码review、问题跟踪、wiki以及持续集成等多种功能,Gitlab 一共提供四种版本可供用户选择,分别是

  • Gitlab Community Edition (CE):社区版,免费,用户自行托管,通过社区提供技术支持
  • Gitlab Enterprise Edition (EE):企业版,付费,用户自行托管,提供附加的功能以及技术支持
  • Gitlab.com:免费的SaaS服务,可以创建共有以及私有的版本库,可以购买额外的技术支持
  • GitHost.io:由Gitlab提供的用户私有的独享服务

我们使用的是Gitlab CE版本。

Gitlab安装

Gitlab的安装非常简单,首先访问下载地址:https://about.gitlab.com/downloads/,选择对应的操作系统类型,我们使用的是Ubuntu 16.04,也就是Gitlab官方推荐的运行环境,然后就会跳转到对应的安装说明,按照说明一步一步安装即可。

安装所需要的依赖项

1
sudo apt-get install curl openssh-server ca-certificates postfix

添加gitlab源并安装

目前最新的版本是8.13.11

1
2
curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
sudo apt-get install gitlab-ce

如果不想通过脚本进行安装,也可以直接下载gitlab的deb包,通过dpkg命令进行安装

1
2
curl -LJO https://packages.gitlab.com/gitlab/gitlab-ce/packages/ubuntu/xenial/gitlab-ce-XXX.deb/download
dpkg -i gitlab-ce-XXX.deb

配置并启动gitlab

1
sudo gitlab-ctl reconfigure

执行完上述命令后,即可通过IP或者域名访问Gitlab,初次访问,会提示用户设置一个至少八位的管理员密码,用户名为root,今后这就是本系统的第一个用户,拥有最高的管理员权限。使用用户名root和刚刚设置的密码登陆之后,就可以进行一系列的设置了。

Gitlab 配置

以上只是Gitlab的默认配置,如果需要更加自定义的配置Gitlab,就需要执行以下操作了。

配置外部访问URL

为了能够正确显示代码库的下载地址,Gitlab需要知道用户使用的是什么地址来进行访问的,例如:http://gitlab.example.com,在/etc/gitlab/gitlab.rb中添加或者编辑如下参数:

1
external_url "http://gitlab.example.com"

运行sudo gitlab-ctl reconfigure使更改生效。

配置URL相对路径

注意:相对路径的特性是在8.5版本才加入的,目前处于实验状态。

尽管Gitlab推荐用户将其安装在独有的域名之下,但是由于种种原因,这种做法并不一定总是可行,所以,Gitlab可以安装在相对路径之下,例如:http://exmaple.com/gitlab

需要注意的是,修改了URL之后,所有的远程地址都会改变,所以您必须要在所有的本地版本库中手动修改指向您gitlab实例的所有远程地址。

相对路径的系统需求

由于Gitlab安装包内含有已经编译好的资源文件(CSS、JavaScript、字体等),如果您配置Gitlab的相对路径,这些资源都需要被重新编译,这项任务将耗费相当一部分CPU和内存资源,为了避免资源耗尽导致出错,您的系统必须拥有至少2GB的可用内存,当然,Gitlab推荐至少要有4GB的内存和4核或者8核的CPU。

启动Gitlab的相对路径

启动相对路径功能需要按照以下步骤进行操作:

  • 1.(可选)如果系统资源不足,可以通过以下命令关闭Unicorn和Sidekiq来释放一部分内存。

    1
    2
    sudo gitlab-ctl stop unicorn
    sudo gitlab-ctl stop sidekiq
  • 2.在/etc/gitlab/gitlab.rb中设置external_url参数。

    1
    external_url "https://example.com/gitlab"

在本例中,Gitlab将会运行在相对路径/gitlab下,用户可以根据自己的需求进行设置。

  • 3.重新运行配置命令使更改生效

    1
    sudo gitlab-ctl reconfigure
  • 4.如果您在第一步中关闭了Unicorn和Sidekiq,此处需要重启。

    1
    sudo gitlab-ctl restart

关闭Gitlab的相对路径

关闭相对路径功能,只需要按照以上的操作一步一步进行即可,并且将external_url设置为不包含相对路径即可,当配置完成之后,您可能需要单独运行以下命令重启Unicorn。

1
sudo gitlab-ctl restart unicorn

使用非root用户调用外部配置文件

Gitlab从/etc/gitlab/gitlab.rb处加载配置文件,该文件仅能够被root用户访问,但是在特定情况下,是允许用户以非root形式访问配置文件的,那么就需要在/etc/gitlab/gitlab.rb中配置如下的路径:

1
from_file "/home/admin/external_gitlab.rb"

需要注意的是,如果是以root权限运行的sudo gitlab-ctl reconfigure,那么,任何/etc/gitlab/gitlab.rb文件中from_file之后的配置项将会覆盖外部配置文件中的配置。

在其他位置保存Git数据

默认情况下,Gitlab会将所有数据保存在/var/opt/gitlab/git-data,所有的版本库会保存在其中的一个子目录repositories,我们可以通过修改/etc/gitlab/gitlab.rb中的git-data来改变其保存位置。

1
git_data_dirs({"default" => "/mnt/nas/git-data"})

自从Gitlab 8.10版本以来,也可以通过修改/etc/gitlab/gitlab.rb来将Git数据保存在不止一个目录中。

1
2
3
4
git_data_dirs({
"default" => "/var/opt/gitlab/git-data",
"alternative" => "/mnt/nas/git-data"
})

注意:所有的目录以及子目录都不能是软连接。

运行sudo gitlab-ctl reconfigure来使配置生效。

如果之前在/var/opt/gitlab/git-data中已经有版本库,需要按照如下操作将其移动到新的位置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# Prevent users from writing to the repositories while you move them.
sudo gitlab-ctl stop
# Note there is _no_ slash behind 'repositories', but there _is_ a
# slash behind 'git-data'.
sudo rsync -av /var/opt/gitlab/git-data/repositories /mnt/nas/git-data/
# Start the necessary processes and run reconfigure to fix permissions
# if necessary
sudo gitlab-ctl upgrade
# Double-check directory layout in /mnt/nas/git-data. Expected output:
# repositories
sudo ls /mnt/nas/git-data/
# Done! Start GitLab and verify that you can browse through the repositories in
# the web interface.
sudo gitlab-ctl start

启用HTTPS

默认情况下,Gitlab并未启用HTTPS,如果需要使用HTTPS,那么首先要修改/etc/gitlab/gitlab.rb

1
2
# note the 'https' below
external_url "https://gitlab.example.com"

由于主机名是’gitlab.exmaple.com’,Gitlab将会搜索/etc/gitlab/ssl/gitlab.example.com.key/etc/gitlab/ssl/gitlab.example.com.crt两个文件作为证书和加密密钥,相应的,我们要创建目录/etc/gitlab/ssl并将证书文件复制到此处。

1
2
3
sudo mkdir -p /etc/gitlab/ssl
sudo chmod 700 /etc/gitlab/ssl
sudo cp gitlab.example.com.key gitlab.example.com.crt /etc/gitlab/ssl/

现在即可运行sudo gitlab-ctl reconfigure,当配置结束,即可通过https://gitlab.example.com访问gitlab。

如果您正在运行防火墙,则必须要启用443端口以便HTTPS流量可以通过。

1
2
3
4
5
6
7
8
9
# UFW example (Debian, Ubuntu)
sudo ufw allow https
# lokkit example (RedHat, CentOS 6)
sudo lokkit -s https
# firewall-cmd (RedHat, Centos 7)
sudo firewall-cmd --permanent --add-service=https
sudo systemctl reload firewalld

默认情况下,当external_url配置以https开头的时候,Nginx便不再监听HTTP的80端口,如果想要将所有的HTTP请求都重定向给HTTPS,那么需要使用redirect_http_to_https配置:

1
2
external_url "https://gitlab.example.com"
nginx['redirect_http_to_https'] = true

Gitlab的备份与迁移

备份Gitlab

Gitlab的备份非常简单,只需要一条命令即可:

1
sudo gitlab-rake gitlab:backup:create

使用以上命令,会在/var/opt/gitlab/backups目录下创建一个名称1484626546_2017_01_17_gitlab_backup.tar的压缩包,这就是Gitlab的完整备份文件,文件名开头的1484626546为精确到秒的时间戳。

Gitlab的备份文件存放位置可以通过修改/etc/gitlab/gitlab.rb文件来配置:

1
gitlab_rails['backup_path'] = '/some/path/backups'

将Gitlab备份文件上传至云存储中

从Gitlab 7.4开始,可以使用备份脚本将其创建的’.tar’文件进行上传,其使用Fog Library来执行上传操作,在下面的例子中,我们使用Amazon S3作为存储,但是Fog也可以同时使用其他存储提供商的服务。

/etc/gitlab/gitlab.rb文件中添加以下命令:

1
2
3
4
5
6
7
8
9
10
gitlab_rails['backup_upload_connection'] = {
'provider' => 'AWS',
'region' => 'eu-west-1',
'aws_access_key_id' => 'AKIAKIAKI',
'aws_secret_access_key' => 'secret123'
# If using an IAM Profile, leave aws_access_key_id & aws_secret_access_key empty
# ie. 'aws_access_key_id' => '',
# 'use_iam_profile' => 'true'
}
gitlab_rails['backup_upload_remote_directory'] = 'my.s3.bucket'

将备份文件上传至本地挂载的存储中

您也可以通过Fog将备份文件上传至本地挂在的存储设备中,例如NFS、CIFS、SMB等,由于Gitlab的备份服务是运行在Git用户下的,所以挂载点必须是以git用户作为owner。

除了local_root之外,必须还要backup_upload_remote_directory参数,这个参数指明了备份文件将要复制到您所挂在的目录中的哪个子目录,如果目录不存在,将会自动创建,如果要将备份文件复制到您所挂在的那个根目录中,则该值只需要设置为.即可。

1
2
3
4
5
6
7
8
gitlab_rails['backup_upload_connection'] = {
:provider => 'Local',
:local_root => '/mnt/backups'
}
# The directory inside the mounted folder to copy backups to
# Use '.' to store them in the root directory
gitlab_rails['backup_upload_remote_directory'] = 'gitlab_backups'

保存配置文件

需要注意的是,备份文件中并没有保存您的配置信息,一方面的原因是您的数据库中保存有加密的两步验证信息,讲加密信息和密钥保存在同一个位置违背了使用储存加密信息的原则。

至少需要备份的文件是/etc/gitlab/gitlab.rb/etc/gitlab/gitlab-secrets.json以保存数据库的加密密钥。

恢复以前创建的备份文件

您只能将备份文件恢复到完全相同的Gitlab版本中。

在执行恢复操作之前,您必须要拥有一个能够正常运行的Gitlab实例,同时在执行恢复操作的时候,该实例上原来运行的所有数据都将会被清空,被恢复的数据所替代。

在启用了两步验证(2FA)的Gitlab中,您必须要确保将/etc/gitlab/gitlab.rg/etc/gitlab/gitlab-secrets.json同时恢复,并且在恢复之后要运行sudo gitlab-ctl reconfigure使修改生效。

执行以下恢复步骤的过程中我们假设:

  • 必须安装了与创建备份所用Gitlab完全相同的版本。
  • 必须执行了sudo gitlab-ctl reconfigure至少一次。
  • 如果Gitlab没有在运行中,则必须要执行sudo gitlab-ctl start

首先,确保备份的tar文件被放置在了gitlab.rb文件中gitlab_rails['backup_path']中所配置的路径下,默认值是/var/opt/gitlab/backups

1
sudo cp 1484626546_2017_01_17_gitlab_backup.tar /var/opt/gitlab/backups/

停止连接到数据库的进程,只剩Gitlab在运行

1
2
3
4
sudo gitlab-ctl stop unicorn
sudo gitlab-ctl stop sidekiq
# Verify
sudo gitlab-ctl status

接下来,恢复备份文件,指定您想要恢复的文件的时间戳

1
2
# This command will overwrite the contents of your GitLab database!
sudo gitlab-rake gitlab:backup:restore BACKUP=1484626546_2017_01_17

重启并确认Gitlab运行状态

1
2
sudo gitlab-ctl start
sudo gitlab-rake gitlab:check SANITIZE=true

如果备份和恢复所用的Gitlab版本不符,在恢复过程中会报错,您只需要重新安装正确的Gitlab版本并重试即可。

设置定时任务保证每日备份

为了添加每日定时备份任务,需要使用root用户添加cron定时任务:

1
2
sudo su -
crontab -e

然后添加如下命令使其每日凌晨两点钟执行一次定时备份:

1
0 2 * * * /opt/gitlab/bin/gitlab-rake gitlab:backup:create CRON=1

同时,为了避免备份文件过多占用磁盘空间,我们需要为备份文件设置一个生命周期,只需要在/etc/gitlab/gitlab/rb中设置以下参数并执行sudo gitlab-ctl reconfigure即可:

1
2
# limit backup lifetime to 7 days - 604800 seconds
gitlab_rails['backup_keep_time'] = 604800

注意:backup_keep_time仅对本地备份有效。

WebSocket的实现以及通过Nginx进行反向代理

什么是Websocket

Websocket 是HTML5开始推出的一种新的协议,实现了浏览器与服务端的全双工通信,在使用WebSocket时,,只要和服务端做一个握手(handshaking)动作,浏览器首先要向服务端发起一个特殊的HTTP请求,其头部附加了信息Upgrade: WebSocket,表明这是一个申请协议升级的HTTP请求,服务端解析出来这些信息后,产生一个应答给客户端,这样双方的WebSocket连接就建立起来了,即可形成一条全双工的数据通道,两者之间可以进行互相通信,直到客户端和服务端中的某一方主动关闭连接。

WebSocket出现之前,为了解决浏览器和服务端之间的实时推送问题,采取了很多解决方案,通常使用的是轮询(Polling)和Comet技术,这些方案带来很明显的缺陷就是需要由浏览器主动发出HTTP Request,大量消耗服务器的带宽和资源,所以为了解决这些问题,HTML5推出了WebSocket。

Socket.io 是WebSocket协议的一个拓展,由于浏览器端对WebSocket的支持程度不一,为了能够兼容不同的浏览器,提升用户体验,简化程序员编写代码时的复杂度,Socket.io封装了以上几种不同的实时通讯机制,并实现了统一的接口,在实际应用的过程中,如果浏览器支持WebSocket,就会以WebSocket方式与服务端进行实时数据交互,如果浏览器端不支持WebSocket特性,那么Socket.io会主动进行降级,使用轮询等其他方式。以下为Socket.io兼容的几种不同机制:

  • Adobe® Flash® Socket:通过将Flash插件嵌入到浏览器中而实现的一种Socket通信模式,由于是第三方实现,不在W3C规范内,并且绝大部分手机端浏览器不支持这种方式,所以在逐渐淘汰中。
  • AJAX Long Polling: 所有浏览器都支持,定时向服务器端发送HTTP请求,兼容性广,但是会给服务器带来很大压力,并且不能保证数据的及时更新。
  • AJAX multipart streaming: 在XMLHttpRequest对象上,使用某些浏览器(比如FireFox)支持的multi-part标志,Ajax请求发送给服务端并保持挂起状态,每次需要向客户端发送信息的时候,就寻找一个挂起的HTTP请求进行响应,并且所有的响应请求都会通过统一的连接来写入。
  • Forever Iframe: 该技术设计了一个置于页面中的隐藏Iframe标签,该标签的src属性指向返回服务器端事件的servlet路径,每次在事件到达时,servlet写入并刷新一个新的script标签,该标签内部带有Javascript代码,iframe的内容被附加上这一script标签,标签中的内容就会得到执行,这种方式的缺点是连接和数据都是有浏览器通过HTML标签处理的,你无法知道连接何时在哪一端已经被断开了,并且Iframe标签在浏览器中将逐步被取消。
  • JSONP Polling: JSONP轮询基本上与HTTP轮询一样,不同之处是JSONP可以发出跨域请求。

WebSocket 简单demo(Socket.io实现)

简单客户端:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<head>
<meta charset="UTF-8">
<title>WebSocket Demo</title>
<script src="//cdn.bootcss.com/socket.io/1.7.2/socket.io.min.js"></script>
</head>
<body>
<h1>WebSocket Demo</h1>
<script>
var io = io.connect('http://127.0.0.1:3000');
io.on('data', function (data) {
console.log('on server data: ' + data);
});
</script>
</body>
</html>

简单服务端:

1
2
3
4
5
6
7
var app = require('koa')();
var server = require('http').createServer(app.callback());
var io = require('socket.io')(server);
io.on('connection', function (client) {
client.emit('data', 'Hello WebSocket.');
});
server.listen(3000); //监听3000端口

我们打开控制台,访问html页面,即可在控制台看到输出的Hello WebSocket字样,即表明服务端已经具备向客户端推送数据的能力。

Nginx反向代理WebSocket

反向代理(Reverse Proxy)是指代理服务器接受互联网上的请求,将请求转发给内部服务器并将结果返回给外部客户端,使用反向代理服务器,有以下几点好处:

  • 可以保护网站安全,所有的访问请求都是先经过代理服务器,然后才到达真正的服务器,如果有网络攻击,可以直接在代理服务器上进行屏蔽,不影响后端真正服务器的运行。
  • 可以将后端服务器上的资源进行缓存,实现某些静态资源的加速访问,减轻后端服务器的负载压力。
  • 充当负载均衡服务器,将访问请求平均地分发给后端服务器,同时自动剥离故障服务器,保证服务平稳运行。

Nginx是一款优秀的轻量级网页服务器,同时也支持反向代理服务器功能,在这里,我们将使用Nginx作为HTTP和WebSocket的反向代理服务器,只要在Nginx的配置文件中添加以下项目即可。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
server {
listen 80;
server_name localhost;
#access_log logs/host.access.log main;
location / {
proxy_pass http://127.0.0.1:3000/;
proxy_set_header Host $http_host;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Read-IP $remote_addr;
}
#error_page 404 /404.html;
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}

至此,我们只要通过80端口即可访问我们的WebSocket demo了。

使用Gitlab Pages建立个人博客

关于Gitlab Pages

与Github Pages相似,Gitlab Pages也是一个用来托管静态文件的服务,由Gitlab提供,通过与Gitlab CI和Gitlab Runner集成,将用户个人、组织以及项目的页面部署到静态文件服务当中。

Gitlab Pages是从Gitlab EE 8.3版本才引入的,自定义CNAME和TLS支持是从Gitlab EE 8.5版本中引入的,由于我们没有Gitlab EE 环境,此处我们使用Gitlab.com提供免费服务。

开始使用Gitlab Pages

通常来说,有两种类型的pages

  • 用户页面(username.exmaple.io)或者组织页面(groupname.exmaple.io)
  • 项目页面(username.exmaple.io/projectname)或者(groupname.exmaple.io/projectname)

在一个Gitlab实例中,用户名或者组织名是唯一的,所以我们可以将其当作命名空间使用,下面表格展示了不同类型的Gitlab Pages与他们的项目名称的关系以及最终URL的展现形式:

Gitlab Pages类型 Gitlab中的项目名称 网站URL
用户页面 username.exmaple.io http(s)://username.exmaple.io
组织页面 groupname.exmaple.io http(s)://groupname.exmaple.io
用户项目页面 projectname http(s)://username.exmaple.io/projectname
组织项目页面 projectname http(s)://groupname.exmaple.io/projectname

使用Gitlab Pages的基本流程

简单的说,使用Gitlab Pages 需要以下几步:

  • 从管理员处得到Gitlab Pages的域名(gitlab.com的对应域名为gitlab.io),这一步非常重要,所以您必须确保首先获得正确的域名。
  • 创建一个项目。
  • 向该工程根目录中推送一个.gitlab-ci.yml文件。
  • 建立一个Gitlab Runner用来构建您的服务。

搭建个人博客

下面要在Gitlab.com上搭建免费的个人博客,由于我的用户名是mlei,所以建立一个工程,名为mlei.gitlab.io。并将此工程克隆至本地。

将github pages工程的hexo分支内源码复制到该工程目录下,然后新建一个.gitlab-ci.yml文件,其内容如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
image: node:4.2.2
pages:
cache:
paths:
- node_modules/
script:
- npm install hexo-cli -g
- npm install
- hexo generate
artifacts:
paths:
- public
only:
- master

提交所有更改,然后将代码库push到远程,Gitlab会自动识别.gitlab-ci.yml中的配置并执行其中的操作,执行完毕后,访问http://mlei.gitlab.io即可访问我的博客。

同步Github Pages内容

每次提交Github Pages之后都要将博客源代码文件复制到Gitlab Pages的工程下面,然后再提交,显然这种重复的体力劳动是不需要人力去完成的,我们可以在travis CI中设置相应的操作,让其自动将代码提交至Gitlab版本库中,但是Gitlab提供了一个更加简便快捷的方法:镜像版本库(Mirror repository)。

点击工程的设置按钮,找到Mirror Repository菜单栏,点击进入,一共提供了两种选择,一共是将该版本库当作其他项目的镜像,每小时同步一次内容,另一种是将该版本库当作主版本库,每次提交之后,将其内容同步至其他版本库,我们此处用的是前者。

只要将Mirror repository的复选框勾选,然后填入我的Github pages的地址,确认即可,此时,自动同步功能已经开启。

Use Hexo With Travis Ci

Travis CI 简介

Travis CI是一个分步式的开源持续构建项目,只需要通过配置.travis.yml文件,即可将Github上的项目进行持续的编译、测试等工作,以便尽早发现错误,尽早改正,并减少人工的重复劳动。同时,也可以通过travis ci完成很多有趣的工作。

通过Travis CI自动发布hexo博客

我们建立的hexo博客,每次写完一篇,都要执行 hexo generatehexo deploy 等命令,将博客生成的HTML静态文件部署到Github的版本库上,同时,也会将源代码保存一份到Github的另一个分支,每次都要执行很多重复操作,在此,我们可以通过Travis CI来帮我们完成这些重复劳动。

为项目启用Travis CI功能

首先打开https://travis-ci.org并选择使用Github授权登陆,登陆成功之后,进入https://travis-ci.org/profile/,可以看到用户Github账户下的所有公开的版本库,如果没有显示,就点击右上角“Sync account”按钮,将项目列表同步过来,我们选择github page所在的版本库(本人的为:leim/leim.github.io),点击左侧的toggle button即可启用。

此时我们再回到Github的leim/leim.github.io版本库下,点击Settings->Integrations & services,即可看到Travis CI已经在列表中了,表明Travis CI功能已经成功启用。

Github Personal Access Token

在Github点击右上角头像,然后点击Settings,进入个人设置,点击Personal access token,然后点击Generate new token,我们需要生成一个具有push权限的access token,所以选择讲repo下的public_repo前面打勾,同时将此token备注为public_repo_deploy,表明其作用,确认之后牢记此token,因为它只会显示这一次,一旦忘记只能进行重置,无法找回。

配置Travis CI

再次回到Travis CI,可以看到列表中的leim\leim.github.io已经在那里了,我们点击右侧More options -> Settings,可以看到设置页面,有一些配置选项:

  • Build only if .travis.yml is present:表示只有在.travis.yml文件存在的分支发生变更才开始运行构建。
  • Build pushes:表示push事件可以触发构建。
  • Limit concurrent jobs:限制同时运行的构建数。
  • Build pull request:表示pull事件可以触发构建。
  • Environment Variables:配置所需的环境变量,主要是一些保密信息。
  • Cron Jobs:除了按照特定事件触发构建外,也可以根据设置定时触发构建任务。

我们讲上一步得到的 personal access token复制到 Environment Variables中,并命名为deploy_github_public_repo然后保存。

至此所有的设置工作全部完成。

编写.travis.yml文件

.travis.yml文件是Travis CI的所有动作的描述文件,当然我们也要将所需要做的工作写在该文件中。其主要内容如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
language: node_js //构建环境
node_js: stable //版本
install: //安装依赖
- npm install hexo -g
- npm install
script: //执行脚本
- hexo g
after_script: //脚本执行成功之后,部署代码
- cd ./public
- git init
- git config user.name "leim"
- git config user.email "[email protected]"
- git add .
- git commit -m "auto update docs by travis ci"
//${deploy_github_public_repo}为设置在环境变量中的access token,此处通过https提交更改到master分支
- git push --force --quiet "https://${deploy_github_public_repo}@github.com/leim/leim.github.io.git" master:master
branches:
only:
- hexo //仅hexo分支触发该构建

到这一步,所有的工作就全部完成了,接下来,我们可以新建一篇文章,然后将整个博客的代码部分commit 并 push 到hexo分支,即可自动触发travis CI的持续构建服务,自动生成HTML静态文件并提交到master分支,此时博客网站即自动更新完毕。

MkDocs备忘

MkDocs

MkDocs(官网Github)是一款使用python开发的轻量级静态站点生成器,主要用于生成api文档,使用markdown撰写,使用yaml作为配置文件。

安装

首先需要安装python以及pip,然后使用pip即可安装MkDocs。

1
2
3
sudo apt-get install python
sudo apt-get install python-pip
sudo pip install mkdocs

安装完成之后,可以执行命令mkdocs --version查看所安装版本。

开始使用

执行以下命令新建一个工程。

1
2
mkdocs new demo
cd demo

生成的目录里结构如下:

1
2
3
4
.
├── mkdocs.yml
└── docs
└── index.md

其中包含了 mkdocs.yml 工程配置文件以及源文件目录:docs,在源文件目录docs下有一个文件index.html,是一个默认的首页文件。

控制台进入到与 mkdocs.ymldocs 同一级的目录中,运行 mkdocs serve,启动内置的http服务器,在浏览器中打开 http://127.0.0.1:4000 ,就会看到docs/index.md渲染之后的页面。内置的http服务器会在我们修改工程内的任意文件的时候检测变化,自动刷新并载入修改后的文件。

详细配置

所有的配置可以在 mkdocs.yml 文件中编辑,默认 mkdocs.yml 中只有一个字段 site_name 是必填的,其余字段均为选填。各个字段的详细说明如下:

site_name

文档的主标题,配置文件 mkdocs.yml 中唯一的必填字段。

site_url

站点的URL,渲染后的HTML头部会带有包含该URL的link标签。默认null。

repo_url

版本库的URL,如果设置该项,每页都会添加一个版本库的URL链接。默认null。

repo_name

版本库的名字,如果设置的话,会在每个页面显示一个指向github或者bitbucket的链接。如果repo_url符合对应规则,会默认显示 Github 或者 Bitbucket,否则会是null。

edit_url

编辑链接,如果设置,会在每个页面显示一个链接,点击链接会直接指向修改页面的地址。默认null。

site_description

站点的描述,如果设置该项,渲染后的HTML头部会带有包含该描述的meta标签。

site_author

站点的作者,如果设置该项,选然后的HTML头部会带有包含该项的meta标签。

site_favicon

站点的favicon相对docs目录的路径。

站点的版权信息。

docs_dir

源文件所在目录相对 mkdocs.yml 的路径,默认 docs

site_dir

生成的HTML文件相对 mkdocs.yml 的路径,默认 site

theme

站点生成HTML所用的主题,内置主题有mkdocs、readthedocs,默认mkdocs。

pages

站点的目录结构。

1
2
3
4
pages:
- 'Introduction': 'index.md'
- 'User Guide': 'user-guide.md'
- 'About': 'about.md'

use_directory_urls

站点的链接类型。

Source file Generated HTML use_directory_urls=true use_directory_urls=false
index.md index.html / /index.html
api-guide.md api-guide/index.html /api-guide/ /api-guide/index.html
about.md about/index.html /about/ /about/index.html

关于代理服务器的一些备忘

Node.js代理服务器

出于信息安全的需求,很多公司对于员工电脑访问外网都会有很多特别的限制,比如某国内大型上市IT解决方案供应商,所有的员工电脑必须通过某个指定的HTTP代理服务器访问互联网资源,并且还要进行用户名密码的验证,导致很多无法设置代理服务器的软件以及仅支持socks5代理的软件都无法使用,甚至想要在调试应用的时候调用一些第三方api都需要做很多特殊设置。

比如正常的Node.js在做HTTP请求的时候,代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
var http = require('http');
var opt = {
host: 'api.example.com', //要访问的服务器地址或者域名
port: 8080, //要访问的服务器端口
method: 'POST', //方法
path: '/api', //路径
headers: { //请求headers
//request headers
}
}
var req = http.request(opt, function(res){
var body = '';
res.on('data', function(buf){
body += buf;
}).on('end', function(){
console.log(body); //print response
});
}).on('error', function(err){
console.log('err: ' + err.message);
});
req.end('request payload');

如果请求需要经过代理进行访问的时候,代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
var http = require('http');
var username = ''; //proxy username
var password = ''; //proxy user password
var opt = {
host: '127.0.0.1', //代理服务器地址
port: 8080, //代理服务器端口
method: 'POST',
path: 'http://api.exmaple.com:8080/api', //真实请求URL
headers: {
'Proxy-Authentication': 'Base ' + new Buffer(username + ':' + password).toString('base64'), //如果代理服务器需要用户名密码,就加上这一行
//其他的请求header
}
};
//其余部分和之前相同,没有变化

NPM代理服务器

由于众所周知的原因,国内的网络,你懂的,有时候访问npm的时候就会抽风,造成一些意想不到的麻烦,不过还好,国内的淘宝团队建立了一个npm的镜像,地址是 https://npm.taobao.org/,国内的开发者可以访问这里地址,速度非常快,同时可以使用以下命令,将npm的安装源替换为淘宝提供的源,加速模块的安装:

1
npm config set registry = 'https://registry.npm.taobao.org'

如果只是想在安装某一个模块的时候临时需要使用淘宝的源,可以按照以下操作,单次安装有效:

1
npm install [email protected] --registry=https://registry.npm.taobao.org

同样,对于像某大型上市IT解决方案供应商的网络那样,只有经过代理才能访问外网的情况,则需要按照以下方法来设置代理服务器,这样执行之后,所有执行npm安装模块的时候,都会通过该代理服务器访问外网进行下载,只需要执行 npm config get proxy 即可查看设置的代理服务器是否正确:

1
npm config set proxy = 'http://username:[email protected]:8080'

CCproxy 与 Proxifier 代理

由于某些特殊的应用程序可能并不支持代理服务器的设置,或者设置的代理服务器不支持输入用户名密码,或者仅支持socks5代理,对于这些特殊情况,可以考虑使用ccproxy或者proxifier解决。

CCproxy是一款国人开发的代理服务器软件,免费版支持三用户同时在线使用,对于一般个人用户来说完全足够,该软件支持二级代理功能,可以在软件内设置上级代理的地址与用户名密码,同时转为本机的一个无用户名密码的代理,此时,本机上的无法设置代理用户名密码的软件就可以使用ccproxy进行代理上网了。

Proxifier是国外开发的一款全局代理软件,在该软件中设置好上级代理的信息,运行之后,会抓取本机的所有访问流量,同时将流量直接转发至代理服务器,无论软件是否设置代理与否,这样就保证了很多无法设置代理服务器的软件也可以访问外网。同时,启用proxifier之后,上面的Node.js和NPM在访问外网的时候就无需再进行其余设置了,proxifier会直接抓取其访问流量并转发至代理服务器。同时该软件还可以进行代理规则的配置,可以设置指定名称的软件访问网络不经过代理,或者设置多个代理,对于不同的目标,走不同的代理服务器,功能非常强大。

关于Shadowsocks

略。。。

Hexo搭建备忘

关于Hexo

Hexo是一款轻量级的HTML静态博客生成器,由Node.js编写,支持Markdown撰写,运行速度快,可以一键部署到Github Pages等托管网站,同时支持插件,可以通过编写插件支持更加丰富的功能。

安装Hexo

Hexo基于Node.js编写,安装Hexo之前,需要首先确保正确安装了Node.js、npm和Git(参见Node.js官网Git官网),只要运行以下命令即可将Hexo安装到电脑中:

1
npm install hexo-cli -g

初始化

安装Hexo成功后,即可创建Hexo工程目录,执行以下命令:

1
2
3
hexo init demo
cd demo
npm install

创建成功后,所包含的目录结构以及功能说明如下:

  • _config.yml:网站配置信息。
  • packages.json:node_modules模块配置信息。
  • scaffolds:模板配置文件夹。
  • sources:用户资源,markdown和html会被render并保存至public文件夹供访问,其余文件被直接copy。其中_post文件夹中保存已发布的文章,_draft文件夹中保存草稿。
  • themes:主题文件夹。

配置

网站的所有配置信息保存在_config.yml文件中,可以视情况进行修改。

具体的配置说明可参见:https://hexo.io/zh-cn/docs/configuration.html。

申请Github Pages空间

在github上面创建一个和repository,名称为 .github.io,进入settings,选择options,下面有Github Pages的设置区域,可以选择默认的分支,并且能够自定义域名,这里我们将默认分支设置为master,同时添加自定义域名 menglei.tk ,添加自定义域名之后,下方 enforce https选项变得不可选,因为github无法对自定义域名提供https证书,此处我们可以通过其他方式来对https进行支持。这里填写完自定义域名之后,需要到域名的控制台,为其添加A记录,分别对应IP地址为 192.30.252.153 和 192.30.252.154 。

这样,所有访问自定义域名都会直接请求到该repo的master分支内根目录下的index.html文件。

部署

Hexo可以支持git、heroku、Rsync、OpenShift、FTPSync等多种部署方式,如果这里没有提供您所需要的部署方式,可以直接将生成的public文件夹中所有的文件复制到所需要的server root文件夹。

我们这里采用的是git部署方式,首先需要添加 hexo-deployer-git ,执行以下命令:

1
npm install hexo-deployer-git --save

然后在根目录下的_config.yml文件后面,增加以下配置信息:

1
2
3
4
5
6
7
deploy:
- type: git
repo: <repo url> //远程repo地址
branch: <branch name> //通过git提交到远程repo的分支
message: <push message> //提交信息
- type: git
repo: <repo url2> // 可以支持同时部署到多个远程repo

这里可以同时支持将其部署到多个repo中,也可以同时支持多种不同的repo类型。

Sitemap:

为了让搜索引擎更好的抓取网站内容,我们这里可以生成sitemap,首先需要执行:

1
2
npm install hexo-generator-baidu-sitemap --save //生成百度sitemap
npm install hexo-generator-sitemap --save //生成google sitemap

然后在根目录_config.yml文件末尾,添加以下配置信息:

1
2
3
4
sitemap:
path: sitemap.xml
baidusitemap:
path: baidusitemap.xml

这样,就可以通过 http://url/sitemap.xmlhttp://url/baidusitemap.xml 访问到网站的sitemap了,只要将以上地址提交到google和百度,即可加速搜索引擎抓取,优化网站的收录。

Feed

为了给用户提供订阅,可以生成Feed文件,首先要执行:

1
npm install hexo-generator-feed --save

然后在根目录_config.yml文件中,添加以下配置信息:

1
2
3
4
5
feed:
type: atom
path: atom.xml
limit: 50
hub:

这样,就可以通过 http://url/atom.xml 访问到网站的订阅Feed了。

HTTPS配置

如果申请了Github Pages空间只好没有设置自定义域名,那么可以直接使用.github.io访问网站,并且可以启用enforce https选项强制所有用户使用https访问。但是设置自定义域名之后,必须采用一些其他方式,这里我们采用的是cloudflare免费CDN功能。

CloudFlare提供用户免费的CDN加速功能,并且支持HTTPS加速,所以,我们先申请一个cloudflare的账号,添加域名,然后到原域名供应商处将其dns服务器设置为cloudflare的dns服务器:kai.ns.cloudflare.com 和 naomi.ns.cloudflare.com 。然后将原来的dns record全都转移过来,同时,对于指向github pages的域名对应的两条A记录,启用CDN功能,这样,所有访问您github pages网站的请求,都会被cloudflare中转加速,免费的账户支持添加三条page rules,我们添加一条即可,配置域名,选择always use https,同时启用该条规则,这样,所有访问http的请求,都会被强制转向https,此处的https证书是cloudflare免费提供的,用户不必担心使用有效期,也不必承担费用。

同时,cloudflare还有很多高级功能可以免费使用,比如访问统计,防火墙,数据分析等,大家可以慢慢摸索。

Ending

至此,所有的配置工作都已经完成,可以愉快的进行写作了。

Nginx安装配置备忘

Nginx是一个俄罗斯开发的高性能HTTP服务器和反向代理服务器,功能丰富、性能强悍、运行稳定、应用广泛,完全使用C语言编写,可运行于各种Unix Like OS,并有Windows移植版本(不推荐用于生产环境)。

安装

在Ubuntu中,可以直接使用sudo apt-get install nginx 命令安装nginx,安装之后,默认的配置文件保存在 /etc/nginx 文件夹内,默认提供http服务的目录位置在 /usr/local/nginx/html

配置

nginx的主配置文件是:nginx.conf

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
user www-data; #用户与用户组
worker_processes 4; #对外提供服务的worker进程数量,取值取决因素包括(但不限于)CPU核的数量、存储数据的硬盘数量及负载模式。默认可设置为CPU内核数或者可设置为“auto”。
worker_rlimit_nofile 30000; #worker进程最大打开文件数量限制
pid /var/run/nginx.pid; #pid文件保存位置
events {
worker_connections 10000; #单个worker可以最大打开的连接数
# multi_accept on; #收到一个新连接通知后是否接受尽可能多的连接
}
http {
##
# Basic Settings
##
sendfile on; #sendfile特性,提高文件访问的效率
tcp_nopush on; #在一个tcp数据包里发送所有的头文件
tcp_nodelay on; #不要缓存数据,立即发送
keepalive_timeout 65; #客户端keep-alive连接的超时时间
types_hash_max_size 2048;
# server_tokens off; #是否关闭错误页面中的nginx版本显示
# server_names_hash_bucket_size 64;
# server_name_in_redirect off;
include /etc/nginx/mime.types; #特定后缀使用mime types的配置
default_type application/octet-stream; #默认文件mime types
client_max_body_size 200m; #上传文件最大体积
##
# Logging Settings
##
access_log off; #访问日志记录文件路径
error_log /var/log/nginx/error.log; #错误日志记录文件
##
# Gzip Settings
##
gzip on; #是否启用gzip压缩(可减少流量,增大服务器负载)
gzip_disable "msie6"; #指定客户端禁用gzip
gzip_vary on;
gzip_proxied any; #允许或者禁止压缩基于请求和响应的响应流。设置为any,意味着将会压缩所有的请求。
gzip_comp_level 6; #压缩等级
# gzip_buffers 16 8k;
# gzip_http_version 1.1;
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; #设置需要压缩的数据格式
server{ #服务器配置
listen 80; #端口
server_name example.com; #域名
location / {
root /usr/local/nginx/html; #根目录
index index.html index.htm index.php; #默认主页文件
}
}
##
# Virtual Host Configs
##
include /etc/nginx/conf.d/*.conf; #配置
include /etc/nginx/sites-enabled/*; #virutal host配置
}

virutal host 配置

nginx作为反向代理服务器,可以根据域名不同将用户的请求分发给不同的后端服务器,配置文件放置在site-available目录中,如果要启用某一个特定的配置文件,需要在site-enabled目录中建立一个对应的软连接。

我们想要配置一个api.example.com的虚拟服务器,将特定/api路径下的所有请求转发到后端的api服务器,其他请求直接访问对应的静态文件目录,同时支持HTTP和HTTPS访问,配置如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
server {
server_name api.example.com; #域名,只有访问这个域名的请求才会被转发到这里
listen 80; #监听端口
listen 443 ssl; #HTTPS监听端口
ssl on; #是否启用HTTPS
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; #HTTPS证书公钥地址,此处为Let's Encrypt申请的证书
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; #HTTPS证书私钥地址,此处为Let's Encrypt申请的证书
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; #HTTPS协议版本
ssl_prefer_server_ciphers on; #服务器加密优先于客户端加密
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH'; #加密算法
location ^~ /api/ { #所有匹配到/api路径下的访问,全部转发
proxy_pass http://127.0.0.1:8051/rest/;
proxy_set_header Host $http_host; #转发的请求,HOST取值为客户端访问的host值
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; #增加x-Forwarded-for
proxy_set_header X-Real-IP $remote_addr; #增加x-real-ip,取值为访问用户的真实IP,供后端获取客户IP使用
}
location = /upload { #只有访问路径等于 /upload 的请求,才会转发到这里
proxy_pass http://127.0.0.1:8052/upload/;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
client_max_body_size 200m; #设置最大上传文件体积,单位可以是k、m、g
}
location ~ /.well-known { #letsencrypt申请证书验证域名使用的配置目录
root /usr/share/nginx/.well-known;
index index.html;
}
location / { #所有不匹配上面各种条件的请求,都转发到这里
root /var/webroot;
index index.html index.htm;
}
}

将以上配置保存为 /etc/nginx/sites-available 目录中的 api.example 文件,然后进入site-enabled目录,执行 ln -s ../sites-available/api.example api.example 在sites-enabled中建立其对应的软连接,然后执行 service nginx reload 重新加载nginx的配置,即可生效。

nginx配置强制跳转HTTPS

很多网站都要求所有HTTP的访问都强制跳转到HTTPS,其配置方法有很多种,可以按照以下配置思路:

我们有一个仅支持HTTPS访问的配置好的virtual host:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
server {
server_name www.example.com;
listen 443 ssl;
ssl on;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
location / {
root /var/webroot;
index index.htm index.html;
}
}

新建一个配置文件www.redirect:

1
2
3
4
5
6
7
8
9
10
11
12
13
server {
server_name www.example.com;
listen 80;
location ~ /.well-known { #letsencrypt申请证书验证域名使用的配置目录
root /usr/share/nginx/.well-known;
index index.html;
}
location / { #默认请求
root /noexists; #一个不存在的目录
index index.html;
}
error_page 404 https://www.example.com/; #访问文件不存在时,跳转的链接
}

在sites-enabled 目录中为以上配置文件设置一个软链接,然后reload nginx即可。

其思路主要是利用了nginx的404页面,我们为http server配置了一个不存在的路径,这样在访问http服务器的时候,其index.html文件是不存在的,这样nginx就会给用户返回特定的404 Not Found 页面,我们将对应的HTTPS链接指定为其对应的404页面,这样在访问http server的时候,就会被自动redirect到相应的HTTPS页面了。

Let's Encrypt 配置过程记录

Let’s Encrypt 是一个免费的SSL证书机构,可以通过Certbot工具进行申请。

Let’s Encrypt 网站: https://letsencrypt.org/

Certbot 网站: https://certbot.eff.org/

Certbot Github: https://github.com/certbot/certbot

测试环境: Ubuntu 14.04, python 2.7, nginx 1.4.6

申请过程

1.安装

首先要保证电脑中已经安装了git和nginx,并且能够正确运行。

安装certbot可以从github上面clone,或者直接从官方提供的下载地址进行下载。

1
2
wget https://dl.eff.org/certbot-auto
chmod a+x certbot-auto

2.配置

上面下载到的是一个自动安装脚本,运行这个脚本,会自动下载并安装所需要的各种依赖,下载完成之后,我们可以再次运行这个脚本进行证书的申请。但是,此时可以先创建一个配置文件,省去每次都要输入一长串命令的麻烦。Certbot的配置文件默认存放位置是/etc/letsencrypt/,默认的文件名是cli.ini,所以我们创建一个文件/etc/letencrypt/cli.ini,内容如下:

1
2
3
4
5
6
7
8
9
10
rsa-key-size = 2048 //密钥长度,2048足够
email = [email protected] //您的邮箱地址
domains = example.com, www.example.com //要申请证书的域名,多个域名用逗号分隔
text = True //是否使用文字交互,如果选false,将使用ncurses交互
authenticator = webroot //域名的验证方式
webroot-path = /usr/share/nginx/html //指定http服务器的root文件夹

3.申请

只要执行 certbot --config /etc/letsencrypt/cli.ini 即可按照cli.ini中的配置内容进行申请证书的操作,申请成功之后,证书文件会存放在 /etc/letsencrypt/archive/example.com 文件夹中,同时,在 /etc/letencrypt/live/example.com/ 中,会有相应的软连接,我们在使用的时候,可以直接利用软连接即可,避免续期之后的证书文件名变更导致nginx配置出错。

4.使用

在nginx的ssl配置时,按照如下配置即可。

1
2
ssl_certificate /etc/letsencrypt/live/appinn.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/appinn.com/privkey.pem;

5.续期

由于Let’s Encrypt 证书的有效期只有三个月,我们必须在到期之前对其进行续期。续期的操作是执行命令行 certbot-auto renew。我们可以创建定时任务,保证服务可以一直有效。

运行 crontab -e ,同时在下面加入一行:

1
2
00 3 * * 0 certbot-auto renew
01 3 * * 0 service nginx reload

每周日凌晨三点钟运行续期服务,如果证书即将到期,即可自动对证书进行续期三个月,同时三点零一分会自动重新加载nginx,使得新申请的证书生效。

这样,HTTPS部分就已经配置完成并且不需要任何操作了,只要服务器一直在运行并且Let’s Encrypt 服务没有出意外,我们的HTTPS就会一直有效下去。