为什么需要DevOps
dveops的概念提出已经近十年,各种devops的实践方案已经陆续在各个开发团队应用,通过版本控制工具(Git、SVN) + 源代码仓库(Gitee、Github) +CI/CD平台(Jenkins、Github actions、Travis CI...)的DevOps方案使得开发人员的开发体验得到极大的提升,即减少了开发和运营的成本又提高了产品质量...
由于个人阅历不足无法继续详细阐述DevOps的优势和作用,所以我推荐了一篇blog
如何实践DevOps
废话说那么多,不如实践一下见好坏,以Jenkins、Github actions、Travis CI等等CI/CD平台为中心都可以很好的做到持续集成持续部署,在码云源代码仓库中我们可以看到如下流行的devops方案
以及在Github中集成的Actions
所以我们真正搭建这样一个流水线平台到底需要使用什么技术,掌握什么工具?
我总结如下:
- 掌握流行的版本控制工具(Git,SVN)基本使用方法
- 依托一个源代码仓库(Github、Gitee)
- 基本的linux运维技术(SSH远程、Docker)
- 一个CI/CD平台(Jenkins、Github Actions、Travis CI...)
就这么多,不需要掌握任何编程技巧!
以上每一个技术精通都是不容易的,但是我们只需要任选其一掌握基本方法,能串起来就行。
我根据自己的技术栈设计了这样一个DevOps的方案
为此我们需要按部就班做一些准备工作
版本控制工具(Git)
学习使用
学习使用方法,这里我推荐廖雪峰的Git学习网站,阮一峰-Git命令清单,阮一峰-Git原理
配置环境
-
安装软件git官网
-
检验安装
git --version
-
配置本地用户信息
git config --global user.name "Name" git config --global user.email "**.com" git config --list
源代码仓库
这里我就不赘述了,太简单了,搜索引擎找一找,如图所示,我在github上建了一个这样的仓库(空仓库就行,代码可以后加)
注意,本教程依托了Github Actions这样一个平台,必需使用Github,所以网络问题需要自己解决
我们准备了如下图所示目录结构的一个基于Asp .NET Core 6 的一个图书管理系统的项目。然后将源代码推送到远程代码仓库如上图所示。(推送指令就不在详细描述,掌握了git的基本使用就会明白)
一台配置好环境的云服务器
为此我准备了一台4g运行内存,8M带宽的腾讯云服务器。操作系统为ubuntu
SSH远程登录
你可以使用云服务器控制台提供的远程工具,也可以使用xshell之类的远程控制工具。为了之后的操作能够尽可能顺利进行,你需要会使用一些基本的linux指令,可以看看这个linux快速上手视频。
xshell有免费版,下载安装后如下新建一个会话
之后按照提示输入账户名和密码就好
在服务器上安装docker
docker技术准备工作
这里我随便找了个视频狂胜-docker详细教程,大致看一下就能对docker有一个了解
一篇博客为什么要使用docker
我们知道一个项目要想运行起来是需要运行环境的,为了运行一个java项目我们为服务器安装对应版本的Jdk或Jre, 一个.Net应用想要运行起来需要对应版本的.Net FrameWork 或者.Net Core 的SDK,比如我们日常使用的可执行程序qq,weixin等等都是需要运行环境的,只不过windows提前安装好了各种版本的.Net Framework,使得我们安装好应用后就能直接使用。又比如在服务器上安装相应的数据库(mysql,sqlserver),管理这些开发环境是相当烦人的,但是当我们使用了docker这样一个容器化技术后库,代码即环境,可以在任何一台装有docker的服务器上运行,不需要配置任何环境。
安装docker
使用docker安装mysql
有了docker我们安装mysql将变得easy
docker pull mysql
检查一下我们拉去下来的docker镜像
docker images
运行
docker run -d --name mysql3306 -p 3306:3306 -e MYSQL_ROOT_PASSWORD=******* mysql
查看一下正在运行的的服务
这样我们就创建按好了一个服务器上的数据库,这样的数据库不仅能用于生产环境,用来学习也是不错的,毕竟在笔记本上装数据库会比较占内存。
于是我就能在我的项目中配置数据库连接字符串使用这个数据库了
不管这个项目在哪台主机上启动,都是可以成功运行的,毕竟数据库的Ip, 密码都是固定的。
选择合适的CI/CD平台
如前文所说,我所用的是Github actions,最初我是在Asp .NET Core的官网文档上了解到的这个技术,自从github被微软收购后,Github actions就一直是微软推荐CI/CD技术。
想要真正理解这门技术,最好阅读一下英文版的文档,在看完“Understanding Github Actions"和”Finding and Customizing actions"这两栏的介绍后,基本上就可以上手Github Acitions了
推荐一篇blog,看完后你可以对其有个简单了解 阮一峰-github actions入门
在本地代码仓库中配置好dockerfile
在我的项目中实现如下
FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["BMS.csproj", "./"]
RUN dotnet restore "BMS.csproj"
COPY . .
WORKDIR "/src/."
RUN dotnet build "BMS.csproj" -c Release -o /app/build
FROM build AS publish
RUN dotnet publish "BMS.csproj" -c Release -o /app/publish
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "BMS.dll"]
尝试使用docker在本地打包构建部署
我们使用docker就可以根据这个文件将项目源码按照我们想要的方式打包构建好
这里我们简单演示一下,进行该测试需要在本地电脑安装docker,
切换到有dockerfile的项目目录下使用
docker build .
这个没有tag的镜像就是我们刚刚构建的
docker run -d --name bmstest -p 8080:80 7ab686d20640
打开游览器检查一下是否成功运行
成功了!
但是,还不够方便,虽然我们每次修改完代码运行几个命令就运行好了,别人也可以拿着我们的镜像去运行程序,但是执行的命令是固定的,我们能不能在修改完代码后就自动让其打包构建部署,事实证明是可以的,人类也是可以在偷懒中进步的。
使用Github Actions自动化打包构建
我们们在项目目录workflows下建立自己的workfile
name: .NET
env:
IMAGE_NAME: test
on:
push:
branches: [ master ]
pull_request:
branches: [ master ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Setup .NET
uses: actions/setup-dotnet@v1
with:
dotnet-version: 6.0.x
- name: Restore dependencies
run: dotnet restore
- name: Test
run: dotnet test --no-build --verbosity normal
- name: Docker Login
uses: docker/login-action@v1.10.0
with:
username: ${{ secrets.DOCKER_USERNAME }}
password: ${{ secrets.DOCKERHUB_TOKEN }}
- name: Build and Push
uses: docker/build-push-action@v2
with:
tags: horaoen/app:latest
push: true
context: ./BMS
- name: deploy
uses: appleboy/ssh-action@master
with:
host: ${{ secrets.HOST }}
username: ${{ secrets.HOST_USERNAME }}
key: ${{ secrets.HOST_SSHKEY }}
script: |
docker stop bms-container
docker rm bms-container
docker rmi horaoen/app:latest
docker pull horaoen/app:latest
docker run -d --name bms-container -p 8080:80 horaoen/app
可以看到这里的yml文件引用了几个变量,这些是有关用户安全的东西不能直接写在配置文件中,需要在github 的仓库中设置
添加自己需要的密钥
workfile详解
关于上面这个dotnet.yml的Github Actions的配置文件怎么写的需要先了解Github Actions的基本原理
然后掌握一下几个Actions的使用
其实这些actions用户下项目,基本格式是users/repository,是一些别人写好的脚本,通过重复利用别人写好的脚本,我们可以很方便的做许多事
actions/checkout@v2
这个是用于将远程仓库中的源代码拉取到workfile自动化构建脚本运行的服务器,在我们这里是github提供的ubutu latest(这在配置文件中写的有)
actions/setup-dotnet@v1
这个是用于搭建项目的基本环境
docker/login-action@v1.10.0
docke官方给的antion,用于登录docker以便我们后续上传docker镜像到自己的镜像仓库
docker/build-push-action@v2
构建docker镜像,推送到自己的docker镜像仓库,这个context参数是比较难理解的,实际上是相对以远程代码仓库的根路径的Dockerfile的路径
在这个aciton的官网文档中介绍到,Dockerfile的文件路径默认在context/Dockerfile 下,所以这个配置很重要不能配错。
appleboy/ssh-action@master
在我们成功将docker镜像推送到镜像仓库后,需要ssh连接我们自己要部署项目的服务器,然后在其上运行一系列docker commond去部署项目。
其它参数一目了然,唯独这个稍微麻烦,它是我们将要连接到的服务器的ssh私钥,在这个action的官网中给出了教程
可以照着教程,其实你已经看到这里就说明具备解决这个问题的能力,详细步骤可以查一下博客怎么配置ssh密钥。需要注意的是复制尽量用指令去复制,错一个字符都不行
私钥一定要把上下分割线也复制上,巨坑!!!
演示效果
查看项目
我们发现有乱码,这里正好模拟实际项目中的bug,现在我们修改代码修复bug
实际上改一下encoding就好了,然后重新提交代码
成功了!!
心得
显然从结果来看,这很方便,但是学习技术的过程是很痛苦的,如果把学习过程放到比较条件中去是不公平的,学习一次收益很久,但是不做改变就会一直麻烦。
评论区可以留言,我会尽力解答。