从前慢现在也慢

这个屌丝很懒，什么也没留下！

热门标签

[GitOps] 白嫖神器Github Actions，构建、推送Docker镜像一路畅通无阻_github action 发布docker

作者：从前慢现在也慢 | 2024-04-10 21:17:07

踩

github action 发布docker

[GitOps] 白嫖神器Github Actions，构建、推送Docker镜像一路畅通无阻

引言

当你没找到合适的基础的Docker镜像时，是否会一时冲动，想去自己构建。然而因为网络问题，各种软件官方源、镜像源（包括但不限于apt、pip、maven，npm），不但编译奇慢无比，还时常出错白白浪费几十个G的网络流量；硬件问题，爱用Windows但装WSL开了Hyper-V玩不了模拟器，用虚拟机又觉得麻烦占磁盘空间，还没钱续期云服务器……
我的朋友，如果你还在为以上种种问题而苦恼，那么我很荣幸为你推荐~~Nuget~~ GitOps，Github Actions!
GitOps，作为一种现代化的运维理念，强调通过版本控制系统来管理基础设施和应用配置，提高可维护性和可靠性。在这个背景下，Github Actions作为一项强大的CI/CD工具，为我们提供了优雅的解决方案。本文将深入探讨如何充分利用Github Actions服务，白嫖其强大的构建能力，实现Docker镜像的自动构建与推送，确保网络畅通无阻。
【不得不说同样是官方源，Nuget就极少像前面几个源出问题，.net yyds！】

Github Actions简介

Github Actions是Github提供的一项持续集成和持续交付服务，与仓库无缝集成，可通过简单的YAML配置文件定义工作流程。这使得我们能够轻松地在代码仓库中管理和执行CI/CD任务，提高开发和部署的效率。借助Github Actions，我们可以构建、测试和部署项目，将整个开发周期变得更加流畅。
GitHub可以提供 Linux、Windows 和 macOS 虚拟机来运行你的工作流程，在使用Github Actions之前，你需要了解以下前置知识:

Yaml基础语法
Linux（或Windows或macOS）脚本相关知识
Git及Github的相关知识

什么是Yaml

当创建Github Actions时，会在代码库.github/workflows目录下，创建一个.yml 文件，每个yml对应一个工作流。
YAML（YAML Ain’t Markup Language或YAML是一个人类可读的数据序列化格式）是一种简洁且易读的数据标记语言。它常被用于配置文件和数据交换格式，以人类可读的方式表示数据结构，有以下几个特点:

大小写敏感。
使用缩进表示层级关系。
缩进只能使用空格，不能用 TAB 字符。
缩进的空格数量不重要，只要层级相同的元素左对齐即可。
#表示注释。

Github Actions的Yaml结构

name：workflow名称
on：触发器
env：自定义的环境变量
job：一个workflow可以有多个job，每个job包含多个step
runs-on：任务容器，如ubuntu-latest，windows-latest，macos-latest
step：任务步骤
action：每个步骤可以执行多个命令

Github Actions的使用限制

Github Actions可以免费使用，也可以付费使用，其中免费用户有以下限制：

使用时长
可以每月使用2000分钟，存储500MB（应该是指仓库大小），其中不同容器时间系数是不同的，Linux是1，Windows是2（1000分钟），MacOS是10（200分钟）；
并发作业数20
作业执行时间最长6小时
工作流运行时间每次工作流运行时间限制为 35 天
（笔者没看懂这项目）

更详细内容可以在官网中找到usage-limits-billing-and-administration

Docker镜像的构建

在Github Actions中配置Docker镜像构建的过程非常简单。通过定义workflow，我们可以指定触发条件、构建步骤和依赖关系。配置一个构建步骤，执行Docker镜像的构建，确保在每次代码推送时触发自动构建流程。这种自动化的构建流程不仅提高了效率，还减少了人为出错的可能性。

新建workflow

首先打开你的Github 代码库，点击Actions

点击New workflow按钮

搜索Docker，会有很多workflow模板，其中Docker Image是非常简洁的模板，适合笔者我这种简约主义者，以下将使用它作为教程示例。
顺带一提，隔壁那个模板很复杂……英文好的人可以研究研究
点击Configure，进入编写yml，编写任务

官方默认模板内容如下，功能是当push或者pull master分支时，触发构建流程

name: Docker Image CI
on:
  push:
    branches: [ "master" ]
  pull_request:
    branches: [ "master" ]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Build the Docker image
      run: docker build . --file Dockerfile --tag my-image-name:$(date +%s)
1
2
3
4
5
6
7
8
9
10
11
12
13

而run标签，就是linux下的shell脚本，既然是shell，那么就可以做很多事情了。
比如说你原本已有一套构建脚本(build.sh)，那么可能稍作修改，就能用着Github Actions中，run改为sh build.sh即可。
yml可以在线编辑，也可以保存后pull到本地代码库。

示例代码库

回到前言所说的内容，笔者痛点是希望找一个人工智能的运行环境镜像，但没有整合的，人工智能的镜像一般又很大，各环境单独一个镜像下载慢又占空间，在whl包不冲突的情况下，装在一起能省很多控件，于是乎就诞生了本项目：Wlkr.DockerBuild
注意，本项目目的是编译基础环境的镜像，没有什么代码，可能常见的项目开发有所出入，请自行甄选。

观察Wlkr.AiRuntime项目，会见到有多个 Dockfile，此举是为了避免编译失败，导致漫长的构建过程又要重新编译。
比如Ubuntu镜像默认没有python，除了python还有其他一些深度学习所需的基础组件也没有，当你编译通过python后，安装pytorch报错缺失组件，规划不好又要从python那个步骤开发编译，非常浪费时间。
在分而治之的思想指导下，最终镜像构建分为了7个Dockerfile。

触发器

修改工作流的yml，改为监听这7个Dockerfile和一个python文件

name: Docker Image CI
on:
  push:
    # 监听的分支
    branches:
      - master
    # 监听的文件
    paths:
      - 'Wlkr.AiRuntime/Dockerfile*'
      - 'Wlkr.AiRuntime/model_init.py'
1
2
3
4
5
6
7
8
9
10

如果你在自己的linux服务器下编译过docker镜像，Dockerfile中编译成功的步骤会有一个缓存layer，减少编译的所需时间。
但是在Github Actions中，每次执行工作流，均没有缓存。
同时笔者所编译的镜像是环环相扣的，上一层镜像有改动时，下层的所有镜像也应该重新编译。

优化构建流程

有没有优化的可能？答案是有的！
先定义7个flag变量

env:
  flag_python: 0
  flag_pytorch: 0
  flag_modelscope: 0
  flag_modelscope_cv: 0
  flag_mscv_pd: 0
  flag_mscv_pdocr: 0
  flag_mscv_pdocr_mdl: 0
  flag_done: 0
1
2
3
4
5
6
7
8
9

修改拉取代码的action，默认会带上参数–dept=1，无法满足后续的操作

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout Code
      uses: actions/checkout@v3
      with:
        fetch-depth: 2 #加上这个参数
1
2
3
4
5
6
7
8
9

在上面监听文件中，我们监听了所有Dockerfile，显然没有变动的Dockerfile，是不需要重新编译重新构建的。
那么怎么知道哪些文件有变动，哪个镜像需要重新编译？答案就是commit后产生的sha id。

利用git diff命令，检查上一次commit与本次commit的文件是否不同，如果不容，则修改flag，标记为需要编译。

    - name: Check Modify
      run: |
        echo "previous_sha=${{ github.event.before }}"

        cd Wlkr.AiRuntime
        # python
        if [ -n "$(git diff --name-only ${{ github.event.before }} HEAD -- Dockerfile.python)" ]; then
          echo "flag_python=1" >> $GITHUB_ENV
        fi
        # 其他flag省略
1
2
3
4
5
6
7
8
9
10

在构建的action中，加上添加if: env.flag_python == 1，来确定是否要执行编译，如果要则将下一步骤的flag也改为1。

    - name: Build python
      if: env.flag_python == 1
      run: |
        cd Wlkr.AiRuntime
        # 基础
        docker build -f Dockerfile.python -t dimwalker/wlkr.python .
        echo "flag_pytorch=1" >> $GITHUB_ENV
1
2
3
4
5
6
7

至此，编译的优化已完成。
需要注意，每个action都是独立的，也就是说工作目录cd Wlkr.AiRuntime要在每个step中先运行一次。

Docker镜像的推送

Docker Hub作为一个广泛使用的Docker镜像仓库，为开发者提供了便捷的镜像存储和分享平台。通过Github Actions，我们可以配置自动将构建好的Docker镜像推送到Docker Hub。这一步骤使得我们的应用在构建完成后，能够迅速被部署和共享，为团队协作和持续集成提供了更多可能性。
在构建和推送Docker镜像的过程中，网络通信可能会成为一个潜在的问题。为了确保畅通无阻，我们可以采取一系列措施，如配置合适的网络代理、优化镜像构建步骤、以及合理选择构建和推送的时机。这些措施将有助于提高构建成功率，确保整个流程的顺畅进行。
但在大局域网中，依然寸步难行。而你只需将构建步骤移到Github Actions中，一切问题都能迎刃而解，真香！

有一点需要注入，虽然Github和Docker Hub很香，但是Docker Hub的镜像时开源的！有商用、涉密等使用要求的人，请谨慎使用。

登录Docker Hub

现在先回到Github Actions的workflow编辑页面，它的右边也是有很多action模板的！

把Docker login的代码复制进你的workflow yml中，放在steps靠前的位置

保留示例中的三个参数即可
其中在env节点加上变脸REGISTRY，留空是将镜像推送到docker hub中，如果是其他库则填相应的地址

    - name: Docker Login
      uses: docker/login-action@v3.0.0
      with:
        registry: ${{ env.REGISTRY }}
        username: ${{ secrets.DOCKERACC }}
        password: ${{ secrets.DOCKERPWD }}
1
2
3
4
5
6

DOCKERACC和DOCKERPWD则需要在代码库中的settings里设置。
按照docker官网说法，这的PWD也可以是你设置的一个token，多人协作就不怕密码泄露的风险

推送Docker镜像

很简单，稍微修改构建的步骤，增加依据push命令即可

    - name: Build & Push python
      if: env.flag_python == 1
      run: |
        cd Wlkr.AiRuntime
        # 基础
        docker build -f Dockerfile.python -t dimwalker/wlkr.python .
        docker push dimwalker/wlkr.python:latest
        echo "flag_pytorch=1" >> $GITHUB_ENV
1
2
3
4
5
6
7
8

完整的yml

你没猜错，这段就是用来水字数的。

name: Docker Image CI

on:
  push:
    # 监听的分支
    branches:
      - master
    # 监听的文件
    paths:
      - 'Wlkr.AiRuntime/Dockerfile*'
      - 'Wlkr.AiRuntime/model_init.py'
env:
  # Use docker.io for Docker Hub if empty
  REGISTRY: ''
  flag_python: 0
  flag_pytorch: 0
  flag_modelscope: 0
  flag_modelscope_cv: 0
  flag_mscv_pd: 0
  flag_mscv_pdocr: 0
  flag_mscv_pdocr_mdl: 0
  flag_done: 0

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout Code
      uses: actions/checkout@v3
      with:
        fetch-depth: 2

    - name: Docker Login
      uses: docker/login-action@v3.0.0
      with:
        registry: ${{ env.REGISTRY }}
        username: ${{ secrets.DOCKERACC }}
        password: ${{ secrets.DOCKERPWD }}

    - name: Check Modify
      run: |
        echo "previous_sha=${{ github.event.before }}"

        cd Wlkr.AiRuntime
        # python
        if [ -n "$(git diff --name-only ${{ github.event.before }} HEAD -- Dockerfile.python)" ]; then
          echo "flag_python=1" >> $GITHUB_ENV
        fi
        # pytorch
        if [ -n "$(git diff --name-only ${{ github.event.before }} HEAD -- Dockerfile.pytorch)" ]; then
          echo "flag_pytorch=1" >> $GITHUB_ENV
        fi
        # modelscope
        if [ -n "$(git diff --name-only ${{ github.event.before }} HEAD -- Dockerfile.modelscope)" ]; then
          echo "flag_modelscope=1" >> $GITHUB_ENV
        fi
        #
        if [ -n "$(git diff --name-only ${{ github.event.before }} HEAD -- Dockerfile.modelscope_cv)" ]; then
          echo "flag_modelscope_cv=1" >> $GITHUB_ENV
        fi
        # mscv_pd
        if [ -n "$(git diff --name-only ${{ github.event.before }} HEAD -- Dockerfile.mscv_pd)" ]; then
          echo "flag_mscv_pd=1" >> $GITHUB_ENV
        fi
        # mscv_pdocr
        if [ -n "$(git diff --name-only ${{ github.event.before }} HEAD -- Dockerfile.mscv_pdocr)" ]; then
          echo "flag_mscv_pdocr=1" >> $GITHUB_ENV
        fi
        # mscv_pdocr_mdl
        if [ -n "$(git diff --name-only ${{ github.event.before }} HEAD -- Dockerfile.mscv_pdocr_mdl)" ]; then
          echo "flag_mscv_pdocr_mdl=1" >> $GITHUB_ENV
        fi
        if [ -n "$(git diff --name-only ${{ github.event.before }} HEAD -- model_init.py)" ]; then
          echo "flag_mscv_pdocr_mdl=1" >> $GITHUB_ENV
        fi

    - name: Print Env
      run: |
        echo "flag_python: ${{ env.flag_python }}"
        echo "flag_pytorch: ${{ env.flag_pytorch }}"
        echo "flag_modelscope: ${{ env.flag_modelscope }}"
        echo "flag_modelscope_cv: ${{ env.flag_modelscope_cv }}"
        echo "flag_mscv_pd: ${{ env.flag_mscv_pd }}"
        echo "flag_mscv_pdocr: ${{ env.flag_mscv_pdocr }}"
        echo "flag_mscv_pdocr_mdl: ${{ env.flag_mscv_pdocr_mdl }}"

    - name: Build & Push python
      if: env.flag_python == 1
      run: |
        cd Wlkr.AiRuntime
        # 基础
        docker build -f Dockerfile.python -t dimwalker/wlkr.python .
        docker push dimwalker/wlkr.python:latest
        echo "flag_pytorch=1" >> $GITHUB_ENV

    - name: Build & Push pytorch
      if: env.flag_pytorch == 1
      run: |
        cd Wlkr.AiRuntime
        # 基础
        docker build -f Dockerfile.pytorch -t dimwalker/wlkr.pytorch .
        docker push dimwalker/wlkr.pytorch:latest
        echo "flag_modelscope=1" >> $GITHUB_ENV

    - name: Build & Push modelscope
      if: env.flag_modelscope == 1
      run: |
        cd Wlkr.AiRuntime
        # 基础
        docker build -f Dockerfile.modelscope -t dimwalker/wlkr.modelscope .
        docker push dimwalker/wlkr.modelscope:latest
        echo "flag_modelscope_cv=1" >> $GITHUB_ENV

    - name: Build & Push modelscope_cv
      if: env.flag_modelscope_cv == 1
      run: |
        cd Wlkr.AiRuntime
        # 基础
        docker build -f Dockerfile.modelscope_cv -t dimwalker/wlkr.modelscope_cv .
        docker push dimwalker/wlkr.modelscope_cv:latest
        echo "flag_mscv_pd=1" >> $GITHUB_ENV

    - name: Build & Push mscv_pd
      if: env.flag_mscv_pd == 1
      run: |
        cd Wlkr.AiRuntime
        # 基础
        docker build -f Dockerfile.mscv_pd -t dimwalker/wlkr.mscv_pd .
        docker push dimwalker/wlkr.mscv_pd:latest
        echo "flag_mscv_pdocr=1" >> $GITHUB_ENV

    - name: Build & Push mscv_pdocr
      if: env.flag_mscv_pdocr == 1
      run: |
        cd Wlkr.AiRuntime
        # 基础
        docker build -f Dockerfile.mscv_pdocr -t dimwalker/wlkr.mscv_pdocr .
        docker push dimwalker/wlkr.mscv_pdocr:latest
        echo "flag_mscv_pdocr_mdl=1" >> $GITHUB_ENV

    - name: Build & Push mscv_pdocr_mdl
      if: env.flag_mscv_pdocr_mdl == 1
      run: |
        cd Wlkr.AiRuntime
        # 基础
        docker build -f Dockerfile.mscv_pdocr_mdl -t dimwalker/wlkr.mscv_pdocr_mdl .
        docker push dimwalker/wlkr.mscv_pdocr_mdl:latest
        echo "flag_done=1" >> $GITHUB_ENV

    - name: Print Env End
      run: |
        echo "flag_python: ${{ env.flag_python }}"
        echo "flag_pytorch: ${{ env.flag_pytorch }}"
        echo "flag_modelscope: ${{ env.flag_modelscope }}"
        echo "flag_modelscope_cv: ${{ env.flag_modelscope_cv }}"
        echo "flag_mscv_pd: ${{ env.flag_mscv_pd }}"
        echo "flag_mscv_pdocr: ${{ env.flag_mscv_pdocr }}"
        echo "flag_mscv_pdocr_mdl: ${{ env.flag_mscv_pdocr_mdl }}"
        echo "flag_done: ${{ env.flag_done }}"
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160

Well Done！

总结

在本文中，我们深入探讨了如何充分发挥 GitHub Actions 在 GitOps 中的作用，特别是在构建和推送 Docker 镜像方面。通过 GitHub Actions，开发者能够充分利用云端资源，轻松实现 CI/CD 流程。
通过配置 GitHub Actions 的工作流程，我们可以确保构建和推送 Docker 镜像的流程畅通无阻。这不仅提高了开发团队的效率，还降低了出错的可能性，使整个开发过程更加可靠和可预测。
总的来说，GitHub Actions作为一个集成于GitHub平台的CI/CD工具，为开发者提供了强大而灵活的工具，支持他们构建出高质量的软件。尤其是对于 Docker 镜像的构建和推送，GitHub Actions 提供了简单易用的方式，使开发者能够专注于代码本身而不必过多关心底层的部署细节。
除了Github Actions，笔者以往还使用过Webhooks+Jenkins的方式，在自己的云端服务器编译镜像。未来，我们可以期待 GitOps 在持续集成、持续部署领域的进一步演进。随着云原生技术的不断发展，这些工具将更加贴近开发者的需求，提供更多创新的功能，帮助开发团队更好地应对快速变化的软件交付需求。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/从前慢现在也慢/article/detail/401014