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

简介:

相关博文:

服务器版本 Ubuntu 16.04 LTS。

经过上面四篇博文中的相关安装和配置,我们主要完成了两个容器的创建和运行:gitlabgitlab-runner(GitLab 站点和 GitLab CI 服务):

$ docker ps
CONTAINER ID        IMAGE                         COMMAND                  CREATED             STATUS                PORTS                                                            NAMES
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提交完代码,自动完成发布和部署。

我们再理一下实现上面目的关键点:

  1. 创建一个 ASP.NET Core 2.0 示例程序
  2. 完善并正确的.gitlab-ci.yml文件配置
  3. GitLab CI 服务器使用ssh连接到测试服务器(在 Docker 中)
  4. 使用scp进行服务器之间的文件传输
  5. 使用supervisor进行站点程序的进程管理

我花了很长时间配置第三步,其实最后解决也很简单,当然都是马后炮的结论,下面我们分别来进行操作。

1. 创建 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 示例程序):

$ curl https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.gpg
$ sudo mv microsoft.gpg /etc/apt/trusted.gpg.d/microsoft.gpg
$ sudo sh -c 'echo "deb [arch=amd64] https://packages.microsoft.com/repos/microsoft-ubuntu-xenial-prod xenial main" > /etc/apt/sources.list.d/dotnetdev.list'

$ sudo apt-get update
$ sudo apt-get install dotnet-sdk-2.0.0

$ dotnet new webapi -o hwapp
$ cd hwapp

最后,绑定下 ASP.NET Core 2.0 程序端口:

public class Program
{
    public static void Main(string[] args)
    {
        BuildWebHost(args).Run();
    }

    public static IWebHost BuildWebHost(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseKestrel() //add code
            .UseUrls($"http://*:8088") //add code
            .UseStartup<hwapp.Startup>()
            .Build();
}

2. .gitlab-ci.yml 文件配置

我的.gitlab-ci.yml文件配置(http://40.125.206.47/team/hwapp/blob/master/.gitlab-ci.yml):

image: microsoft/aspnetcore-build
stages:
  - build
  - deploy_dev
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'
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
    - scp -r bin/publish root@$DEPLOY_SERVER_DEV:/home/xishuai/wwwroot/hwapp
    - ssh root@$DEPLOY_SERVER_DEV "supervisorctl restart hwapp && curl http://localhost:8088/api/values"

上面是我最终调试成功后的.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归纳为哪一种执行环境,你可以设置开发环境和正式环境,我们可以通过通过后台进行查看:

3. 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 无密码的密钥:

$ ssh-keygen -t rsa -P ''
$ cat /root/.ssh/id_rsa

然后复制 RSA 密钥内容,添加到/Project/Settings/PipelinesSecret variables配置中(命名为SSH_PRIVATE_KEY_DEV):

这里需要特别注意,复制内容为(包含开头和结尾的注释信息):

-----BEGIN RSA PRIVATE KEY----- 
xxxxxxx 
-----END RSA PRIVATE KEY-----

我一开始复制没有包含注释信息,然后就一直报下面的错误:

错误代码:

$ ssh-add <(echo "$SSH_PRIVATE_KEY_DEV")
Enter passphrase for /dev/fd/63: ERROR: Job failed: exit code 1

这里的$SSH_PRIVATE_KEY_DEV,就是上面我们在Secret variables中,添加的 RSA 密钥内容。

错误信息就是说需要输入 RSA 密钥的密码,但我创建的确实是无密码的 RSA 密钥,也就是说这个密钥是无效的,我被这个问题折磨了好几天,其他人的记录:

配置好这一步之后,然后重新测试下,我们就可以看到下面的执行信息了:

$ ssh-add <(echo "$SSH_PRIVATE_KEY_DEV")
Identity added: /dev/fd/63 (/dev/fd/63)

接着我们需要将这个 RSA 密钥对应的公钥,上传到需要连接到的服务器(也就是我们的测试服务器),命令如下:

$ ssh-copy-id root@40.125.201.75

到此,GitLab CI 中 SSH 的配置基本上完成了,你可以在.gitlab-ci.yml中添加连接脚本,进行测试:

- ssh root@$DEPLOY_SERVER_DEV "ls && cd /"

一开始,我们说到使用scp进行服务器之间的文件传输,因为scp可以基于 SSH 连接进行传输文件,所以我们直接进行文件传输了,示例代码:

- scp -r bin/publish root@$DEPLOY_SERVER_DEV:/home/xishuai/wwwroot/hwapp

scp命令参考:http://www.runoob.com/linux/linux-comm-scp.html

4. 使用 Supervisor 进行站点程序的进程管理

可以参考之前的文章:Ubuntu 安装和使用 Supervisor(进程管理)

这里贴一下,supervisorctl的常用命令:

命令 说明
supervisorctl stop program_name 停止某个进程
supervisorctl start program_name 启动某个进程
supervisorctl restart program_name 重启某个进程
supervisorctl stop all 停止全部进程
supervisorctl reload 载入最新的配置文件,停止原有进程并按新的配置启动、管理所有进程
supervisorctl update 根据最新的配置文件,启动新配置或有改动的进程,配置没有改动的进程不会受影响而重启

5. 最终效果

Pipelines 管道(地址:http://40.125.206.47/team/hwapp/pipelines

Build_Job 构建任务(地址:http://40.125.206.47/team/hwapp/-/jobs/113

Deploy_Dev_Job 发布和部署任务(地址:http://40.125.206.47/team/hwapp/-/jobs/115


写在最后:

  • GitLab CI & ASP.NET Core 2.0 发布和部署(完成):使用 CI 脚本编译程序,然后将编译后的文件传输到服务器上,最后运行程序,完成发布和部署。
  • GitLab CI & ASP.NET Core 2.0 & Docker 发布和部署(下篇):项目中添加Dockerfile文件,使用 CI 脚本构建自定义镜像,然后在服务器上拉取并创建相应容器,最后启动容器,完成发布和部署。






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

相关文章
|
2月前
|
开发框架 .NET 开发者
简化 ASP.NET Core 依赖注入(DI)注册-Scrutor
Scrutor 是一个简化 ASP.NET Core 应用程序中依赖注入(DI)注册过程的开源库,支持自动扫描和注册服务。通过简单的配置,开发者可以轻松地从指定程序集中筛选、注册服务,并设置其生命周期,同时支持服务装饰等高级功能。适用于大型项目,提高代码的可维护性和简洁性。仓库地址:&lt;https://github.com/khellang/Scrutor&gt;
62 5
|
1天前
|
Kubernetes 持续交付 数据库
阿里云ACK+GitLab企业级部署实战教程
GitLab 是一个功能强大的基于 Web 的 DevOps 生命周期平台,整合了源代码管理、持续集成/持续部署(CI/CD)、项目管理等多种工具。其一体化设计使得开发团队能够在同一平台上进行代码协作、自动化构建与部署及全面的项目监控,极大提升了开发效率和项目透明度。 GitLab 的优势在于其作为一体化平台减少了工具切换,高度可定制以满足不同项目需求,并拥有活跃的开源社区和企业级功能,如高级权限管理和专业的技术支持。借助这些优势,GitLab 成为许多开发团队首选的 DevOps 工具,实现从代码编写到生产部署的全流程自动化和优化。
|
4月前
|
Java Maven Docker
gitlab-ci 集成 k3s 部署spring boot 应用
gitlab-ci 集成 k3s 部署spring boot 应用
|
4月前
|
存储 开发框架 JSON
ASP.NET Core OData 9 正式发布
【10月更文挑战第8天】Microsoft 在 2024 年 8 月 30 日宣布推出 ASP.NET Core OData 9,此版本与 .NET 8 的 OData 库保持一致,改进了数据编码以符合 OData 规范,并放弃了对旧版 .NET Framework 的支持,仅支持 .NET 8 及更高版本。新版本引入了更快的 JSON 编写器 `System.Text.UTF8JsonWriter`,优化了内存使用和序列化速度。
117 0
|
2月前
|
开发框架 算法 中间件
ASP.NET Core 中的速率限制中间件
在ASP.NET Core中,速率限制中间件用于控制客户端请求速率,防止服务器过载并提高安全性。通过`AddRateLimiter`注册服务,并配置不同策略如固定窗口、滑动窗口、令牌桶和并发限制。这些策略可在全局、控制器或动作级别应用,支持自定义响应处理。使用中间件`UseRateLimiter`启用限流功能,并可通过属性禁用特定控制器或动作的限流。这有助于有效保护API免受滥用和过载。 欢迎关注我的公众号:Net分享 (239字符)
65 1
|
3月前
|
开发框架 .NET C#
在 ASP.NET Core 中创建 gRPC 客户端和服务器
本文介绍了如何使用 gRPC 框架搭建一个简单的“Hello World”示例。首先创建了一个名为 GrpcDemo 的解决方案,其中包含一个 gRPC 服务端项目 GrpcServer 和一个客户端项目 GrpcClient。服务端通过定义 `greeter.proto` 文件中的服务和消息类型,实现了一个简单的问候服务 `GreeterService`。客户端则通过 gRPC 客户端库连接到服务端并调用其 `SayHello` 方法,展示了 gRPC 在 C# 中的基本使用方法。
65 5
在 ASP.NET Core 中创建 gRPC 客户端和服务器
|
2月前
|
开发框架 缓存 .NET
GraphQL 与 ASP.NET Core 集成:从入门到精通
本文详细介绍了如何在ASP.NET Core中集成GraphQL,包括安装必要的NuGet包、创建GraphQL Schema、配置GraphQL服务等步骤。同时,文章还探讨了常见问题及其解决方法,如处理复杂查询、错误处理、性能优化和实现认证授权等,旨在帮助开发者构建灵活且高效的API。
59 3
|
2月前
|
存储 测试技术 持续交付
Docker与CI/CD的集成策略及其对软件开发效率和质量的提升作用
本文探讨了Docker与CI/CD的集成策略及其对软件开发效率和质量的提升作用。首先介绍了CI/CD的基本概念,接着阐述了Docker在环境一致性、快速部署、资源隔离和轻量化方面的优势。文章还详细讨论了构建、测试和部署阶段的具体集成方法,以及集成后带来的效率提升、可靠性增强、加速交付和易于管理等好处。最后,通过案例分析展示了集成的实际效果,强调了Docker与CI/CD结合的重要性和未来前景。
61 2
|
4月前
|
jenkins 测试技术 持续交付
Docker最佳实践:构建高效的CI/CD流水线
【10月更文挑战第17天】在现代软件开发实践中,持续集成(Continuous Integration, CI)和持续部署(Continuous Deployment, CD)已成为提高开发效率和软件质量的重要手段。Docker作为一种容器技术,为构建一致且隔离的开发环境提供了强有力的支撑。本文将探讨如何利用Docker来优化CI/CD流程,包括构建环境的标准化、镜像管理以及与CI/CD工具(如Jenkins、GitLab CI)的集成。
145 5
|
4月前
|
缓存 监控 数据可视化
利用GitLab CI/CD自动化您的软件开发流程
【10月更文挑战第10天】GitLab CI/CD 是 GitLab 内置的持续集成和持续部署工具,通过编写 .gitlab-ci.yml 文件,可以自动化构建、测试和部署应用程序的过程。本文介绍 GitLab CI/CD 的核心优势、实施步骤及在现代开发中的应用,帮助您提高开发效率和软件质量。

热门文章

最新文章