Linux系统运维日志

这里说的自动布署是两方面的，第一部分是脚本自动布署服务器环境，第二部份是自动布署代码，完成这两部分，在我理解，就算是完成自动部署了。

我们要做的，就是本地写完代码提交 git 后，使用git push 自动将代码推送到测试或生产环境的站点目录。 好的，开工吧！

LNMP线上环境自动布署脚本

使用 此脚本 可在一台全新的 Ubuntu 14.04 LTS 或者 Ubuntu 16 上自动部署适合 Laravel 使用的 LNMP 生产环境。 按照此 文档 安装即可。

但是此方法在使用中会有一些小问题

1、网易镜像加速后会出现一些安装错误 可能是网易镜像没有更新完全。 需要将网易镜像地址更新为其它地址，可以参考 Ubuntu 官方模版 来更新镜像。 我使用的是阿里云的镜像替换了网易的镜像。

vi /etc/apt/sources.list

更新为

deb http://mirrors.aliyun.com/ubuntu/ xenial main restricted universe multiverse
deb http://mirrors.aliyun.com/ubuntu/ xenial-security main restricted universe multiverse
deb http://mirrors.aliyun.com/ubuntu/ xenial-updates main restricted universe multiverse
deb http://mirrors.aliyun.com/ubuntu/ xenial-backports main restricted universe multiverse
##測試版源
deb http://mirrors.aliyun.com/ubuntu/ xenial-proposed main restricted universe multiverse
# 源碼
deb-src http://mirrors.aliyun.com/ubuntu/ xenial main restricted universe multiverse
deb-src http://mirrors.aliyun.com/ubuntu/ xenial-security main restricted universe multiverse
deb-src http://mirrors.aliyun.com/ubuntu/ xenial-updates main restricted universe multiverse
deb-src http://mirrors.aliyun.com/ubuntu/ xenial-backports main restricted universe multiverse
##測試版源
deb-src http://mirrors.aliyun.com/ubuntu/ xenial-proposed main restricted universe multiverse
# Canonical 合作夥伴和附加
deb http://archive.canonical.com/ubuntu/ xenial partner
deb http://extras.ubuntu.com/ubuntu/ xenial main

2、正常安装后Nginx 启动前需要把 apache 卸载掉，然后再启动 Nginx .

apt-get purge apache2
service nginx restart

3、redis 默认没有启动

service redis-server start  // 启动 redis
service redis-server status  // 查看 redis
service redis-server  stop  // 停止 redis

配置Git自动部署

创建Git远程仓库

我们用一个独立的路径来做远程仓库。 然后在仓库的路径下，创建一个git裸仓库：

cd /home/ubuntu/repo/
git init --bare blog.git

git 默认是禁止 push 的，所有要设置允许 push：

vi config

修改或添加如下内容：

[receive]
        denyCurrentBranch = ignore

编辑自动部署脚本

自动部署用到 git hooks ，在 git 路径下有个 hooks 文件夹，里面有一些示例。我们把 post-update.sample 重命名为 post-update ，并进行编辑：

mv post-update.sample post-update
vi post-update

#!/bin/sh
#
# An example hook script to prepare a packed repository for use over
# dumb transports.
#
# To enable this hook, rename this file to "post-update".

#exec git update-server-info

unset GIT_DIR

NowPath=`pwd`

DeployPath="/home/ubuntu/www/blog"

cd $DeployPath
git pull origin master
composer install

cd $NowPath

echo 'deploy success'
exit 0

这样每当 push master 分支到服务器时，都会自动切换到 DeployPath ，也就是 Nginx root 路径，执行 git pull origin master 从仓库拉去最新 master 分支，并执行 composer install ，如果项目 composer 有变更则安装，没有变更则不会安装。

部署路径初始化

先把空的仓库克隆到 home/ubuntu/www/ 路径下 ：

git clone  /home/ubuntu/repo/blog.git

服务器的配置就级别完成了，此 blog 即为你的站点目录

推送git仓库

进入本地共享文件夹，执行

git clone root@server_ip:/home/ubuntu/repo/blog.git blog_back

将远程的空仓库克隆下来。名称为 blog_back，防止与本地 blog 目录冲突。 ok,现在我们来创建一个项目

本地创建项目并提交 Git

composer create-project --prefer-dist laravel/laravel blog
mv blog_back/.git  blog/.git  //将 .git 目录拷贝过来即可在此目录操作 git
cd  blog
git add -A
git commit -m 'init'
git push origin master //此时输入服务器密码即可将本地项目推送到服务器上

这里我使用的是默认的 root 用户，我们可以单独设置一个 git 用户，也可以使用公钥的形式，类似于 github 的方式。

安装 Composer

打开命令行并依次执行下列命令安装最新版本的 Composer：

php -r "copy('https://install.phpcomposer.com/installer', 'composer-setup.php');"
//下载安装脚本 － composer-setup.php － 到当前目录。
php composer-setup.php //执行安装过程。
php -r "unlink('composer-setup.php');"  //删除安装脚本

执行第一条命令下载下来的 composer-setup.php 脚本将简单地检测 php.ini 中的参数设置，如果某些参数未正确设置则会给出警告；然后下载最新版本的 composer.phar 文件到当前目录。 打开命令行窗口并执行如下命令将前面下载的 composer.phar 文件移动到 /usr/local/bin/ 目录下面：

sudo mv composer.phar /usr/local/bin/composer

进程监控器 Supervisor 配置

项目中有些脚本需要在后台运行，比如队列、Horizon ，Supervisor可以监控后台脚本的运行，再产生异常或是停止后自动重启，保证了脚本不会被异常中断。定时任备也可以直接用 Supervisor 来执行，Supervisor 还可以写入执行成功或失败的日志，方便查看。 此脚本默认安装了 supervisor ，我们只需设置好启动即可。

配置

在 /etc/supervisor/conf.d/ 下新建一个配置文件 horizon.conf,写入以下内容

[program:horizon]
process_name=%(program_name)s_%(process_num)02d
command=php /home/ubuntu/www/site/artisan horizon  //启动脚本命令。
autostart=true  //随着supervisord的启动而启动
autorestart=true //自动重启
user=ubuntu  // 用户组
numprocs=1 // 启动进程，根据脚本决定
redirect_stderr=true  //重定向stderr到stdout
stdout_logfile=/var/log/supervisor/horizon.log  //日志 注意日志目录的权限

接下来就可以启动 supervisord 了。

supervisord -c /etc/supervisord.conf  //启动
supervisorctl shutdown //关闭
supervisorctl reload  //重新载入配置

好了。到这里自动布署就完成了，接下来就是尽情的敲代码吧！

由于 git rebase 命令的存在，强制将提交推送到远端仓库似乎也有些必要。不过都知道 git push –force 是不安全的，这让 git rebase 命令显得有些鸡肋。

本文将推荐 –force-with-lease 参数，让我们可以更安全地进行强制推送。

–force-with-lease 参数自 Git 的 1.8.5 版本开始提供，只在解决 git push –force 命令造成的安全问题。

那么 git push –force 命令有什么安全问题？

–force 会使用本地分支的提交覆盖远端推送分支的提交。也就是说，如果其他人在相同的分支推送了新的提交，你的这一举动将“删除”他的那些提交！就算在强制推送之前先 fetch 并且 merge 或 rebase 了也是不安全的，因为这些操作到推送之间依然存在时间差，别人的提交可能发生在这个时间差之内。

–force-with-lease 将解决这种安全问题

使用了 –force-with-lease 参数之后，上面那种安全问题就没有那么危险了。

使用此参数推送，如果远端有其他人推送了新的提交，那么推送将被拒绝，这种拒绝和没有加 –force 参数时的拒绝是一样的。

walterlv$ git push --force-with-lease
To https://github.com/walterlv/walterlv.github.io.git
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'https://github.com/walterlv/walterlv.github.io.git'

请特别注意——如果你 fetch 之后在本地的 origin 相关分支上已经看到了别人的提交，依然进行强制推送，你还是会覆盖别人的提交。也就是说，–force-with-lease 解决的是本地仓库不够新时，依然覆盖了远端新仓库的问题，如果你执意想要覆盖远端提交，只需要先 fetch 再推送，它也不会拒绝的。

在使用 git push –force-with-lease 命令被拒绝时，你需要 fetch 仓库，然后确认其他人是否对此分支有新的修改，如果没有，你才可以继续强制推送。

walterlv$ git fetch
remote: Counting objects: 46, done.
remote: Compressing objects: 100% (29/29), done.
remote: Total 46 (delta 21), reused 40 (delta 15), pack-reused 0
Unpacking objects: 100% (46/46), done.
From https://github.com/walterlv/walterlv.github.io
   e75edf0..217a49d  master     -> origin/master

在 fetch 完毕之后，请一定检查此分支是否已经被其他人修改，如果有新的提交，你应该进行一次 merge 或者 rebase。

walterlv$ git rebase
First, rewinding head to replay your work on top of it...
Applying: Add post "safe push using force with lease".

此后，再次进行推送或强制推送即可。

walterlv$ git push --force-with-lease
Counting objects: 4, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 363 bytes | 363.00 KiB/s, done.
Total 4 (delta 3), reused 0 (delta 0)
remote: Resolving deltas: 100% (3/3), completed with 3 local objects.
To https://github.com/walterlv/walterlv.github.io.git
   219a6d5..dff94a5  master -> master

额外的问题：为什么推送到远端的提交还依然要用 rebase？

Git 官方文档对 rebase 有如下描述：

▲ 如果你想吐槽那段中文翻译，我只想说——那是 Git 的官方中文文档

既然已经推送的提交不应该再进行 rebase，那本不应该会遇到本文提到的问题。但是——GitHub 的工作流或者 GitLab 的工作流中，都有一种行为是 rebase 自己的分支到 origin/master 上，以保证 master 分支上的提交是纯粹的干净的。也就是说，本意是禁止对合并到 master 或 develop 分支上的提交进行 rebase；但对于自己的 temp 分支或者 feature 分支，因为提交还没有合并到主干中，随时删除掉或者将历史进行美化也不会造成太大的问题。

▲ 这是 GitLab 上的设置，可以要求提交者必须进行 rebase 才允许合并。