相关博文:
由于题目字符的限制,本文的题目本应该是:Ubuntu & GitLab CI & Docker & ASP.NET Core 2.0 自动化发布和部署(上)
Ubuntu 简单安装和配置 GitLab
Ubuntu 简单安装 Docker
Ubuntu Docker 简单安装 GitLab
Ubuntu Docker 安装和配置 GitLab CI 持续集成
服务器版本 Ubuntu 16.04 LTS。
经过上面四篇博文中的相关安装和配置,我们主要完成了两个容器的创建和运行:gitlab和gitlab-runner(GitLab 站点和 GitLab CI 服务):
$ docker ps
CONTAINER>
696d559ce382 gitlab/gitlab-runner:latest "/usr/bin/dumb-ini..." 5 days ago Up 25 minutes gitlab-runner
ff95f354200d gitlab/gitlab-ce:latest "/assets/wrapper" 7 days ago Up 6 days (healthy) 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp, 0.0.0.0:8888->22/tcp gitlab
本篇博文目的:使用 GitLab CI 脚本编译 ASP.NET Core 2.0 程序,然后将编译后的文件传输到服务器上,最后使用 SSH 连接服务器,并运行程序,完成发布和部署。
简单来说,就是我们每次使用git push提交完代码,自动完成发布和部署。
我们再理一下实现上面目的关键点:
创建一个 ASP.NET Core 2.0 示例程序
完善并正确的.gitlab-ci.yml文件配置
GitLab CI 服务器使用ssh连接到测试服务器(在 Docker 中)
使用scp进行服务器之间的文件传输
使用supervisor进行站点程序的进程管理
我花了很长时间配置第三步,其实最后解决也很简单,当然都是马后炮的结论,下面我们分别来进行操作。
创建 ASP.NET Core 2.0 示例程序
我自己创建示例程序:http://40.125.206.47/team/hwapp
注:服务器快过期了,大家可以随便搞。
自己创建的话,也很简单,官方教程:https://www.microsoft.com/net/core#linuxubuntu
我再搬运下命令(安装 .NET Core 2.0,并创建 ASP.NET Core 2.0 示例程序):
before_script:
# Install ssh-agent if not already installed, it is required by Docker.
# (change apt-get to yum if you use a CentOS-based image)
- 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
# Run ssh-agent (inside the build environment)
- eval $(ssh-agent -s)
# Add the SSH key stored in SSH_PRIVATE_KEY variable to the agent store
# error: https://gitlab.com/gitlab-examples/ssh-private-key/issues/1
# - echo "$SSH_PRIVATE_KEY_DEV"
- ssh-add <(echo "$SSH_PRIVATE_KEY_DEV")
# For Docker builds disable host key checking. Be aware that by adding that
# you are suspectible to man-in-the-middle attacks.
# WARNING: Use this only with the Docker executor, if you use it with shell
# you will overwrite your user's SSH config.
- mkdir -p ~/.ssh
- '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'
上面是我最终调试成功后的.gitlab-ci.yml文件配置,其实整个的构建和发布流程,从上面的配置中都可以看出。
这里记录下一些东西:
配置一开始的image,设置的是我们用于构建的镜像(也就是说后面所有的脚本执行,都是在基于这个镜像创建的容器中),如果不设置的话,默认使用的是我们一开始配置 GitLab CI 填写的 Docker Image,也可以手动编辑vim /srv/gitlab-runner/config/config.toml进行修改,我这里使用的是microsoft/aspnetcore-build镜像,只用于 ASP.NET Core 应用程序的编译和构建。
stage可以理解为台阶,每走一步相当于job,当然,这里的台阶可以走很多步,需要注意的是,每上一个台阶或者每走一步,都必须基于上一个台阶或上一步执行成功,before_script执行在这些步骤之前,可以理解为准备工作。
environment将执行的job归纳为哪一种执行环境,你可以设置开发环境和正式环境,我们可以通过通过后台进行查看:
GitLab CI 服务器使用 SSH 连接到测试服务器
什么意思呢?就是我们需要在 GitLab CI 构建环境中,使用 SSH 连接到测试服务器,这样我们才可以做接下来的一些操作。
官方配置:SSH keys when using the Docker executor
.gitlab-ci.yml示例配置:
before_script: # Install ssh-agent if not already installed, it is required by Docker.
# (change apt-get to yum if you use a CentOS-based image)
- 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
# Run ssh-agent (inside the build environment)
- eval $(ssh-agent -s)
# Add the SSH key stored in SSH_PRIVATE_KEY_DEV variable to the agent store
- ssh-add <(echo "$SSH_PRIVATE_KEY_DEV")
# For Docker builds disable host key checking. Be aware that by adding that
# you are suspectible to man-in-the-middle attacks.
# WARNING: Use this only with the Docker executor, if you use it with shell
# you will overwrite your user's SSH config.
- mkdir -p ~/.ssh
- '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'
# In order to properly check the server's host key, assuming you created the
# SSH_SERVER_HOSTKEYS variable previously, uncomment the following two lines
# instead.
# - mkdir -p ~/.ssh
# - '[[ -f /.dockerenv ]] && echo "$SSH_SERVER_HOSTKEYS" > ~/.ssh/known_hosts'
在进行配置之前,我们需要理一下这个步骤,要不然思路容易混乱,会造成一些问题,可以参考这篇文章:Fixing 'Enter passphrase for /dev/fd/63' in a Gitlab CI job
需要强调一点:别在 GitLab CI 容器中进行 SSH 配置,因为 CI 构建脚本执行在另外的容器中,并且这个容器是动态进行创建的,也没办法在这个动态容器中进行配置(指的是手动生成 RSA 密钥)。
所以,我们只能手动生成 RSA 密钥,然后强制添加到容器中的 SSH 配置中(通过 RSA 密钥内容)。
配置步骤:
首先,在任何一台服务器上,创建 RSA 无密码的密钥:
结语:
GitLab CI & ASP.NET Core 2.0 发布和部署(完成):使用 CI 脚本编译程序,然后将编译后的文件传输到服务器上,最后运行程序,完成发布和部署。
GitLab CI & ASP.NET Core 2.0 & Docker 发布和部署(下篇):项目中添加Dockerfile文件,使用 CI 脚本构建自定义镜像,然后在服务器上拉取并创建相应容器,最后启动容器,完成发布和部署。