?经过一周的尝试，终于让gitlab-ci从0到1，彻底抛弃travis-ci。最大的坑就是墙外的东西太慢了，老是超时。整个过程分为以下几个步骤：HowtoBuildgitlabona1-core2Gcloudserver:使用gitlab-runner十分钟搭建Gitlab，并选择正确的执行器Howtobuildafront-endimageHowtobuilda后端镜像编写gitlab-ci.yml实现一个完整的前后端分离工程构建部署1.使用gitlab-runnergitlab-runner和gitlab-ci是连体婴，主要是为gitlab-ci工作，安装使用镜像的方法如下：dockerrun-d--namegitlab-runner--restartalways\-v/srv/gitlab-runner/config:/etc/gitlab-runner\-v/var/run/docker.sock:/var/run/docker.sock\gitlab/gitlab-runner:latest挂载volume/srv/gitlab-runner/config/config.toml包含所有runner的配置信息。通过挂载/var/run/docker.sock:/var/run/docker.sock，容器中的进程可以通过它与Dockerdaemon通信1.1选择Docker作为runner的执行者。启动gitlab-runner容器后，执行如下命令进入容器，注册runnerdockerexec-itgitlab-runner/bin/bashroot@492ce6ab72f9:/#gitlab-runnerregister接下来需要填写的信息如下:Pleaseenterthegitlab-cicoordinatorURL:你的Gitlabaddress:http(s)://gitlab.xxx.comPleaseenterthegitlab-citokenforthisrunner:thetokeninyourGitlabadmin/runnerspagePleaseenterthegitlab-ci对此r的描述unner:填写描述，没关系Pleaseenterthegitlab-citagsforthisrunner(commaseparated):填写标签，没有标签任何人都可以使用它，它是一个shared-runner，它是可用的只有有tags，回车输入executor:docker-ssh,ssh,docker+machine,kubernetes,docker-ssh+machine,docker,parallels,shell,virtualbox:chooseyourexecutor:Docker应该是最常用的我观察到的一个。PleaseenterthedefaultDockerimage(e.g.ruby??:2.6):选择默认镜像：例如docker:stable-alpine不出意外，在gitlab中可以看到1.2为什么要用docker作为executor参考官方文档-executorshellexecutor:the最简单的执行器，所有的依赖都必须手动安装。不能保证每次构建都是同一个环境。迁移需要手动配置VirtualMachineExecutor：创建用于构建的虚拟机。如果你想在不同的操作系统上构建，你可以选择它来占用大量资源。debugbuild问题难迁移不方便DockerExecutor：最佳选择QAQDockerMachine：Docker的扩展，工作方式与Docker类似，但需要额外安装一些步骤最后只尝试了Docker和Docker+Machine，但是Docker+Machine的runner一直是1.3Docker中的Docker是什么（dind）参考官方文档-dind使用dind的背景是：需要在容器中执行docker命令。在1.1注册一个dockerexecutor后，只需要完成两个操作，即可以在gitlab-ci.yml中添加：imgage:docker:stableservice:-docker:dind#testbefore_script:-dockerinfo保证config中的ru.tomlsetprivileged=true1.4innner可能的问题：拉取镜像比较慢也是合理的，我在官方文档中没有找到：Whenusingdockerastherunnerexecutor,howtosetregistry-mirrorIfyouusedocker+machine,可以在config.toml中设置：经测试，这个配置显然对docker无效。。。最终使用的方法是：1.5Buildstage1：打包上传前端代码镜像：docker:stableservices:-docker:dindstages：-构建-make_image-deploycache：未跟踪：真实路径：-后端/节点模块/-前端/节点模块/-前端/dist/upload_to_oss：图像：节点：lts-alpine阶段：构建脚本：-cd前端-npm安装-registryhttps://registry.npm.taobao.org-npmrunbuild通过在gitlab-ci控制台配置一些上传OSS的环境变量，现阶段可以实现以下两个功能：打包前端代码和构建前端镜像准备好架构的webpack插件，静态资源打包后上传到OSS2。如何搭建前后端镜像2.1搭建前端镜像对于前后端分离的项目，往往有一个特点：需要通过nginx进行反向代理。因此，前端镜像是以NGINX为核心，需要准备2~3个文件dist目录：前端静态资源xxx.conf：nginx的部分配置，例如：历史路由的处理，端口转发Dockerfile如下：FROMnginx:stable-alpineLABELmaintainer=CaaalabashEXPOSE800COPYxxx.conf/etc/nginx.conf.dCOPYdist/etc/nginx/dist/CMDnginx-g"daemonoff;"xxx.配置如下：server{listen800;服务器名称本地主机；根目录/etc/nginx/dist；位置/{try_files$uri$uri/@router;索引index.html；}location@router{重写^.*$/index.htmllast;}#这里直接使用localhost转发与后面采用的network_mode有关location/api{proxy_passhttp://localhost:3000/api;}}可以看到xxx.conf只是业务相关，没有https处理，这部分应该由宿主机的nginx来处理，示例代码如下：宿主机nginx配置：server{listen80;服务器名称xxx.xxx.xxx；返回301https://$server_name$request_uri;}server{listen443sslhttp2default_server;服务器名称xxx.xxx.xxx；SSL开启；ssl_certificate证书/blog.pem；ssl_certificate_key证书/博客.key；ssl_session_timeout5m；:!NULL:!aNULL:!MD5:!ADH:!RC4;ssl_protocolsTLSv1TLSv1.1TLSv1.2；ssl_prefer_server_ciphers开启；#所有请求都交给前端容器处理location/{proxy_passhttp://127.0.0.1:8888;}}反映在gitlab-ci.ymlmake_fe:stage:make_imagescript:-dockerlogin-u="$DOCKER_USERNAME_ALI"-p="$DOCKER_PASSWORD_ALI"$DOCKER_REPOSITORY_ALI-dockerbuild-t$DOCKER_REPOSITORY_ALI/calabash/blog:$CI_COMMIT_SHORT_SHA-FE./前端-dockerpush$DOCKER_REPOSITORY_ALI/calabash/blog:$CI_COMMIT_SHA-frontdockerpush./$DOCKER_REPOSITORY_ALI/calabash/blog:$CI_COMMIT_SHA-FE镜像仓库、构建镜像、上传镜像2.2.构建后端镜像比前端简单，是构建节点镜像的常用流程~FROMnode:lts-alpineLABELmaintainer=CaaalabashWORKDIR/appCOPYpackage.json/appRUNnpminstall--registryhttps://registry.npm.taobao.orgCOPY./appENVNODE_ENV=productionEXPOSE3000CMD["npm","run","online"]反映在gitlab-ci.ymlmake_be:阶段:make_image脚本:-dockerlogin-u="$DOCKER_USERNAME_ALI"-p="$DOCKER_PASSWORD_ALI"$DOCKER_REPOSITORY_ALI-dockerbuild-t$DOCKER_REPOSITORY_ALI/calabash/blog:$CI_COMMIT_SHORT_SHA-BE./backend-dockerpush$DOCKER_REPOSITORY_ALI/calabash/COMMCISIT:$.使用docker-compose在服务器上部署。镜像构建完成后，进入最后阶段：部署的核心是：将相关文件复制到服务端，比如一个启动脚本，一个docker-compose.yml执行服务端脚本。在gitlab-ci.yml中是：deploy_test:image:caaalabash/alpine-ssh:lateststage:deploybefore_script:-echo"$SSH_PRIVATE_KEY">id_rsa_2048-chmod0600id_rsa_2048-eval$(ssh-agent)-ssh-addid_rsa_2048脚本：-scp-Pde$ploy_PORT/*root@$DEPLOY_SERVER:$SERVER_FOLDER/deploy-ssh-p$SSH_PORTroot@$DEPLOY_SERVER"chmod+x$SERVER_FOLDER/deploy/startup.sh"-ssh-p$SSH_PORTroot@$DEPLOY_SERVER"$SERVER_FOLDER/deploy/startup.sh$CI_COMMIT_SHORT_SHA"构建脚本就是：stop/deleteoldcontainer/images，docker-composeup3.1简化版docker-compose.yml的配置如下：version:"3"services:backend:image:calabash/blog:${VUE_BLOG_TAG}-BEcontainer_name:blog-backend#只需要暴露前端端口ports:-8888:800network_mode:bridgerestart:unless-stopped#Mongodbredis服务使用external_links:-myMongoDB-myRedis前端：image:calabash/blog:${VUE_BLOG_TAG}-FEcontainer_name:blog-frontendrestart:unless-stoppednetwork_mode:"service:backend"core核心在于前端的配置：network_mode:"service:backend"通过这个配置，和后端容器共享同一个网络，所以在nginx的配置文件中，可以直接使用localhost进行转发，但是需要保证后端容器就绪然后启动前端容器3.2确保后端容器启动后才知道前端容器，docker-compose没有这个能力TAT，最常用的方案是启动容器单独wait-for-it.sh这里使用wait-for-it.sh的简化版修改前端Dockerfile为：FROMnginx:stable-alpineLABELmaintainer=CaaalabashEXPOSE800COPYwait-for-it.shwait-for-it.shRUNchmod+xwait-for-it.shCOPYblog.conf/etc/nginx/conf.dCOPYdist/etc/nginx/dist/CMD["./wait-for-it.sh"]添加等待-for-it.sh#!/bin/shwhile!nc-z-vlocalhost3000doecho"waitbackend"sleep3doneecho"done"nginx-g"daemonoff;"可以结束。这一波折腾虽然麻烦，但是还是彻底实现了一个前后端分离项目的Gitlab-ci配置，达到了预期的目标，虽然gitlab-ci.yml配置非常好用，在除了体验一波使用私有镜像仓库的gitlab-ci+gitlab-runner连体婴！练习wait-for-it控制启动流程方案没想到试错了90+次...实在不适合编程仓库地址
