通过CI ci设计案例( 三 ) _云知道

注册后，我们直接start
CONFIG_FOLDER=/tmp/gitlab-runner-configdocker run -d \ --name gitlab-runner \ --restart always \ -v $CONFIG_FOLDER:/etc/gitlab-runner \ -v /var/run/docker.sock:/var/run/docker.sock \ gitlab/gitlab-runner:latest
一旦start成功，我们就会在gitlab上看到项目的信息:

当研发把代码提交到gitlab上， runners会一次执行:测试、构建、部署等在.gitlab-ci.yml里面定义好的操作。
· 测试阶段运行一些预检查以确保events. json文件格式正确并且images完整。
· 构建阶段构建image并将其推送到GitLab registry。
· deploy阶段通过发送到Portainer的webhook触发服务的更新。WWW_WEBHOOK变量在GitLab.com项目页面的CI/CD设置中定义。

注:
这个runners在swarm的容器中运行。我们可以使用一个共享的runner——他们可以在托管的主机上共享资源——但是,runner需要访问Portainer endpoint (发送webhook),因为我不希望Portainer被玩不访问。
此外，因为运行器在容器中运行，所以它将webhook发送到Docker0桥接网络的IP地址，以便通过它在主机上公开的端口9000与Portainer联系。因此， webhook的格式如下:http://172.17.0.1:9000/api[…]a7-4af2-a95b-b748d92f1b3b
部署过程回顾网站新版本的更新工作流程如下:

1. 开发人员将一些更改推给GitLab 。这些更改基本上涉及事件中的一个或多个新事件。json文件加上一些额外的赞助商的标志。
2. GitLab运行器执行. GitLab -ci.yml中定义的操作。
3. GitLab运行器调用Portainer中定义的webhook 。
4. 在webhook接收端， Portainer部署了www服务的新版本。它这样做，调用Docker Swarm API 。Portainer可以作为套接字/var/run/ dockerr访问API 。袜子启动时是绑定安装的
5. 然后用户就可以在web上看到最新的信息了。
小案例
修改一些配置，然后push到gitlab 。
$ git commit -m 'Fix image'$ git push origin master
下面的截图显示了GitLab.com项目页面中的提交触发的信息

在Portainer端，接收webhook并执行服务更新。我们无法在这里清楚地看到它，但是已经更新了一个副本，使web站点可以通过第二个副本访问。然后，几秒钟后，第二个副本被更新。

总结
即使对于这个小项目，设置一个CI/CD管道也是一个很好的练习，尤其是要更加熟悉GitLab 。这是一个优秀的产品。这也是使用期待已久的Portainer(1.19.2)最新版本的webhook特性的好机会。另外，对于像这样的一个小项目，使用Docker Swarm是很简单的——它很酷，而且很容易使用!
[1]:https://gitlab.com/lucj/sophia.events
[2]:https://gitlab.com/lucj/sophia.events/blob/master/index.mustache