Ubuntu & GitLab CI & Docker & ASP.NET Core 2.0 自动化发布和部署(2)

简介:
  • GitLab Runner 不运行在 Docker 容器中:Executor 选择shell(本地运行),然后在本服务器上安装 .NET Core 和 Docker 环境,.gitlab-ci.yml中执行dotnet编译发布和docker构建发布脚本,将构建的镜像推送到 Docker 私有仓库,然后 SSH 连接到服务器,拉取镜像并创建相应容器,最后启动容器,完成发布和部署。
  • GitLab Runner 运行在 Docker 容器中:Executor 选择shell(GitLab Runner 容器中运行),然后进入 GitLab Runner 容器,在上面安装 .NET Core 和 Docker 环境,.gitlab-ci.yml中执行dotnet编译发布和docker构建发布脚本,后面同上操作。
  • GitLab Runner 运行在 Docker 容器中:Executor 选择docker(指定镜像容器中运行),需要自定义构建一个包含 .NET Core 和 Docker 环境的镜像,构建脚本执行在自定义镜像容器中,.gitlab-ci.yml中执行dotnet编译发布和docker构建发布脚本,后面同上操作。

上面三种方式,最简单的是第一种,第二种和第三种比较类似,实现稍微复杂点,我也没有配置成功,下面分别说下。

1. GitLab Runner 运行在 Docker 容器中

第二种和第三种实现方式,放在一块说,如果 Executor 选择shell,然后我们需要在 GitLab Runner 容器中配置编译环境,但这样会产生一个问题,就是如果我们是升级 GitLab Runner 的时候,需要重新配置编译环境,实际情况是,我进入容器docker exec -it gitlab-runner bash,并没有安装成功 .NET Core 和 Docker 环境(各种服务器中没出现的问题,而且速度非常慢),其实,还有一种方式,就是在.gitlab-ci.yml中执行安装 .NET Core 和 Docker 环境的脚本(检查是否安装),不过,编写是有些问题,这个我没进行尝试。

如果 Executor 选择docker,其实,这样会嵌套很多容器,首先服务器上运行 GitLab Runner 容器,然后在此容器内,运行另外一个构建容器,然后在此容器内,执行构建和发布操作,因为 GitLab Runner 在每次构建的时候,会创建和运行一个新的构建容器,所以,我们不能直接在这个容器中,配置 .NET Core 和 Docker 环境,也不能在.gitlab-ci.yml中执行安装,因为每次都会覆盖之前的操作,唯一的解决方式,就是自定义构建一个包含 .NET Core 和 Docker 环境的镜像文件,然后每次构建使用它进行创建对应容器,执行构建和发布脚本即可。

这里说下,自定义构建一个包含 .NET Core 和 Docker 环境的镜像文件,两种方式:

  • docker build -t 139.219.65.81:5000/xishuai-gitlab-ci-build .:在Dockerfile文件编写安装环境脚本。
  • docker commit microsoft-aspnetcore 139.219.65.81:5000/xishuai-gitlab-ci-build:使用一个容器,然后在容器中安装环境,最后基于这个容器,创建一个自定义镜像文件

第一种方式,我没有进行尝试,第二种方式尝试了下,我使用microsoft/aspnetcore镜像作为基础镜像(800M 左右),然后在其创建的容器中安装 Docker 环境,速度非常慢,而且有时候报各种奇怪的错误,如果安装成功了,左右构建的自定义镜像文件,也非常的大。

这两种方式,我最后都没有采用,最后使用的是下面最简单的方式。

2. GitLab Runner 不运行在 Docker 容器中(Executor 选择 Shell)

如果我们不使用 Docker 安装和运行 GitLab Runner,就得手动进行安装和配置下 GitLab Runner。

安装命令:

$ sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-ci-multi-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-ci-multi-runner-linux-amd64

然后进行给予其权限:

$ sudo chmod +x /usr/local/bin/gitlab-runner

接着就可以进行注册 GitLab Runner 了,命令:

$ sudo gitlab-runner register

示例配置:

配置好之后,我们需要添加一个用于跑 GitLab Runner 的gitlab-runner用户,命令:

$ sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash

然后指定 GitLab Runner 执行的用户和工作目录,命令:

$ sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner

配置好之后,我们可以从配置文件中,查看相关配置信息:

$ cat /etc/systemd/system/gitlab-runner.service 
[Unit]
Description=GitLab Runner
After=syslog.target network.target
ConditionFileIsExecutable=/usr/bin/gitlab-ci-multi-runner

[Service]
StartLimitInterval=5
StartLimitBurst=10
ExecStart=/usr/bin/gitlab-ci-multi-runner "run" "--working-directory" "/home/gitlab-runner" "--config" "/etc/gitlab-runner/config.toml" "--service" "gitlab-runner" "--syslog" "--user" "gitlab-runner"





Restart=always
RestartSec=120

[Install]
WantedBy=multi-user.target

上面工作完成之后,就可以启动 GitLab Runner 了,命令:

$ sudo gitlab-runner start

然后,我们就可以在项目中看到 GitLab Runner 了,示例:

另外,我们还需要做一些其他工作,来保证 GitLab Runner 可以正常运行。

两台服务器需要配置的环境:

  • GitLab Runner 服务器:.NET Core 2.0、Docker、Docker 私有仓库(或者其他服务器)、SSH
  • 测试服务器:Docker

首先,我们需要创建一个 Docker 私有仓库,用于存放程序生成的镜像,这个最好是配置在一个单独的服务器,配置详见:Ubuntu Docker Registry 搭建私有仓库

通过下面两个连接,查看 Docker 私有仓库中的镜像:

然后,我们需要把 GitLab Runner 服务器中的gitlab-runner账户,添加到docker用户组中,命令:

$ sudo usermod -aG docker gitlab-runner

否则会报如下错误:

然后,我们在 GitLab Runner 服务器中,切换到gitlab-runner用户下,配置 SSH,命令:

$ su gitlab-runner
$ ssh-keygen -t rsa -P ''
$ ssh-copy-id root@139.219.69.172

139.219.69.172是测试服务器的 IP 地址,如果不进行这样配置,SSH 连接的时候,会报如下错误:

原因是,GitLab Runner 在执行脚本的时候,会切换到gitlab-runner用户下,我们在root账户下配置 SSH,是无效的。


以上工作完成之后,GitLab Runner 执行编译脚本,基本上执行是没有问题了,我们在示例项目中添加.gitlab-ci.yml配置文件,示例:

stages:
  - build
  - deploy_dev
build_job:
  stage: build
  only:
    - master
  script:
    - dotnet restore
    - dotnet build
deploy_dev_job:
  stage: deploy_dev
  environment:
    name: development
  only:
    - master
  script:
    # 发布程序并部署运行
    - dotnet publish -c Release --output bin/publish
    - docker build -t $GITLAB_SERVER:5000/hwapp .
    - docker push $GITLAB_SERVER:5000/hwapp
    - ssh root@$DEPLOY_SERVER_DEV "docker pull $GITLAB_SERVER:5000/hwapp && docker run -d -p 5001:5001 $GITLAB_SERVER:5000/hwapp"

build_job执行效果:

deploy_dev_job执行效果:


然后,我们在测试服务器上,就可以看到创建和运行的容器了:

浏览器打开http://139.219.110.30:5001/api/values,查看效果:








本文转自田园里的蟋蟀博客园博客,原文链接:http://www.cnblogs.com/xishuai/p/ubuntu-gitlab-ci-docker-aspnet-core-part-2.html,如需转载请自行联系原作者

相关文章
|
6月前
|
人工智能 Ubuntu 前端开发
Dify部署全栈指南:AI从Ubuntu配置到HTTPS自动化的10倍秘籍
本文档介绍如何部署Dify后端服务及前端界面,涵盖系统环境要求、依赖安装、代码拉取、环境变量配置、服务启动、数据库管理及常见问题解决方案,适用于开发与生产环境部署。
1343 1
|
6月前
|
弹性计算 Devops Shell
用阿里云 DevOps Flow 实现 ECS 部署自动化:从准备到落地的完整指南
阿里云 DevOps Flow 是一款助力开发者实现自动化部署的高效工具,支持代码流水线构建、测试与部署至ECS实例,显著提升交付效率与稳定性。本文详解如何通过 Flow 自动部署 Bash 脚本至 ECS,涵盖环境准备、流水线搭建、源码接入、部署流程设计及结果验证,助你快速上手云上自动化运维。
547 0
|
7月前
|
运维 Prometheus 监控
3 年部署经验总结:用自动化工具轻松管理 300+ 服务器开源软件
三年前接手公司IT部门时,我满怀信心,却发现部署效率低下。尽管使用了GitLab、Jenkins、Zabbix等100+开源工具,部署仍耗时费力。文档厚重如百科,却难解实际困境。一次凌晨三点的加班让我下定决心改变现状。偶然看到一篇国外博客,介绍了自动化部署的高效方式,我深受启发。
294 0
|
9月前
|
存储 文字识别 自然语言处理
通义大模型在文档自动化处理中的高效部署指南(OCR集成与批量处理优化)
本文深入探讨了通义大模型在文档自动化处理中的应用,重点解决传统OCR识别精度低、效率瓶颈等问题。通过多模态编码与跨模态融合技术,通义大模型实现了高精度的文本检测与版面分析。文章详细介绍了OCR集成流程、批量处理优化策略及实战案例,展示了动态批处理和分布式架构带来的性能提升。实验结果表明,优化后系统处理速度可达210页/分钟,准确率达96.8%,单文档延迟降至0.3秒,为文档处理领域提供了高效解决方案。
913 1
|
5月前
|
开发框架 .NET C#
ASP.NET Core Blazor 路由配置和导航
大家好,我是码农刚子。本文系统介绍Blazor单页应用的路由机制,涵盖基础配置、路由参数、编程式导航及高级功能。通过@page指令定义路由,支持参数约束、可选参数与通配符捕获,结合NavigationManager实现页面跳转与参数传递,并演示用户管理、产品展示等典型场景,全面掌握Blazor路由从入门到实战的完整方案。
503 6
|
5月前
|
弹性计算 人工智能 前端开发
在阿里云ECS上部署n8n自动化工作流:U2实例实战
本文介绍如何在阿里云ECS的u2i/u2a实例上部署开源工作流自动化平台n8n,利用Docker快速搭建并配置定时任务,实现如每日抓取MuleRun新AI Agent并推送通知等自动化流程。内容涵盖环境准备、安全组设置、实战案例与优化建议,助力高效构建低维护成本的自动化系统。
1362 5
|
6月前
|
jenkins Java 持续交付
使用 Jenkins 和 Spring Cloud 自动化微服务部署
随着单体应用逐渐被微服务架构取代,企业对快速发布、可扩展性和高可用性的需求日益增长。Jenkins 作为领先的持续集成与部署工具,结合 Spring Cloud 提供的云原生解决方案,能够有效简化微服务的开发、测试与部署流程。本文介绍了如何通过 Jenkins 实现微服务的自动化构建与部署,并结合 Spring Cloud 的配置管理、服务发现等功能,打造高效、稳定的微服务交付流程。
769 0
使用 Jenkins 和 Spring Cloud 自动化微服务部署
|
8月前
|
运维 监控 持续交付
还在为部署开源工具烦恼?自动化部署工具 Websoft9一键部署 300+ 开源应用
在数字化时代,开源工具因免费、灵活、可定制等特性广受欢迎,但其部署过程却常因环境配置复杂、依赖繁琐、耗时长等问题令人头疼。本文介绍了传统部署的三大难点,并提出两种解决方案:传统手动部署与集成化控制台部署。
还在为部署开源工具烦恼?自动化部署工具 Websoft9一键部署 300+ 开源应用
|
9月前
|
人工智能 搜索推荐 测试技术
通义灵码 Agent+MCP:打造自动化菜品推荐平台,从需求到部署实现全流程创新
通过通义灵码编程智能体模式和 MCP 的集成,开发者可以高效构建在线菜品推荐网站。智能体模式大幅提升了开发效率,MCP 服务则为功能扩展提供了无限可能。