您当前的位置: 首页 >  docker

寒冰屋

暂无认证

  • 1浏览

    0关注

    2286博文

    0收益

  • 0浏览

    0点赞

    0打赏

    0留言

私信
关注
热门博文

如何为Docker项目创建持续集成持续部署 (CI-CD)解决方案

寒冰屋 发布时间:2021-07-05 21:57:37 ,浏览量:1

目录

目标

发布Release 版本

发布Beta版

总结

我不是Docker高手,但我知道它非常有用,我喜欢在一些项目中时不时地使用它。我喜欢的另一件事是DevOps和自动化,在我拥有的一个项目中,我错过了这一点。在之前的设置中,容器以日期作为标签构建并发布到DockerHub。很好,但不是很容易知道哪些版本是“稳定的”,哪些版本是“进行中”的。

这篇文章是关于我如何为我的Docker项目构建持续集成和持续部署解决方案。所有代码都在GitHub和Docker Hub 上。我正在分享我的经历,以便其他人可以享受这种自动化,而不用花一个周末来构建它。

目标

在此构建结束时,将有两个GitHub Actions用于在Docker Hub上构建和发布不同版本的应用程序。

发布版本:每次在GitHub上发布发布时,都会构建并发布具有匹配版本号的容器标签。(例如:myapp:v1)

测试版:每次推送到我在GitHub上的分支时,都会发布一个带有特定标签的容器。该标签将与草稿版本号匹配。(例如:-beta)myapp:v2-beta。

在这篇文章中,应用程序是一个Node.js Twitch聊天机器人。应用程序的类型并不重要——文章侧重于交付。

发布Release 版本

每次在GitHub上发布版本时,都会触发工作流。它将首先检索“发布版本”,然后使用它构建和标记容器,最后将其发布(也称为推送)到Docker Hub上。因为“发布”也是一个“稳定”版本,它也会更新容器标签latest。

让我们看一下GitHub Action的完整YAML定义,之后我将对其进行分解。

name: Release Docker Image CI

on:
  release:
    types: [published]
jobs:
  update:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Set outputs
      id: vars
      run: echo ::set-output name=RELEASE_VERSION::$(echo ${GITHUB_REF:10})
    - name: Publish to Registry
      uses: elgohr/Publish-Docker-Github-Action@master
      with:
        name: ${{secrets.DOCKER_USER}}/cloudbot
        username: ${{ secrets.DOCKER_USER }}
        password: ${{ secrets.DOCKER_PASSWORD }}
        tags: "latest,${{ steps.vars.outputs.RELEASE_VERSION }}"

为了限制触发工作流的次数,我使用了on: release和type: published,根据需要进行调整。

下一个有趣的部分是 step中的行vars。

- name: Set outputs
    id: vars
    run: echo ::set-output name=RELEASE_VERSION::$(echo ${GITHUB_REF:10})

在这里,我使用环境变量GITHUB_REF(第10个字符的条纹包含“refs/tags/ ”)来初始化一个局部变量RELEASE_VERSION。该值可从该步骤的输出中获得,例如YAML的最后一行。

tags: "latest,${{ steps.vars.outputs.RELEASE_VERSION }}"

从步骤被id vars标识,我从outputs检索到RELEASE_VERSION的值。

在这个GitHub Action中,我使用了elgohr/Publish-Docker-Github-Action@master,因为它很简单,并且正在做我需要的事情。如果您喜欢或使用docker/github-actions ,您可以直接执行docker命令。

GitHub marketplace提供了许多选项。

发布Beta版

每次在GitHub上进行推送时,都会触发工作流。它将首先以草稿模式检索最新版本的“发布版本” 。工作流将发生-beta到检索到的版本上,并使用它来标记容器。最后,将其发布(也称为推送)到Docker Hub上。

再一次,这里是完整的YAML,之后我会分解它。

name: Build Docker Images
on: [push]
jobs:
  build:
    name: cloudbot-beta
    runs-on: ubuntu-latest
    steps:
    - id: last_release
      uses: InsonusK/get-latest-release@v1.0.1
      with:
          myToken: ${{ github.token }}
          exclude_types: "release, prerelease"
          view_top: 1  
    - uses: actions/checkout@v2
    - name: Publish to Registry
      uses: elgohr/Publish-Docker-Github-Action@master
      with:
        name: ${{secrets.DOCKER_USER}}/cloudbot
        username: ${{ secrets.DOCKER_USER }}
        password: ${{ secrets.DOCKER_PASSWORD }}
        tags: "${{ steps.last_release.outputs.tag_name }}-beta"

在这里,困难在于我想从“未来”版本创建一个标签。我决定使用草案版本,因为它们不是每个人都能看到的,因此它们看起来像未来。

如果您的上一个版本是版本1 (v1.0),为了使此工作流程成为可能,您需要创建一个新版本并将其保存在Draft中。

就像在发布工作流程中一样,我需要检索版本。因为草稿只对某些人可见,所以我们需要获得访问权限。这可以通过使用github.token.。这些是在GitHub操作启动时自动创建的。

然后使用步骤InsonusK/get-latest-release,我们将检索版本。

- id: last_release
    uses: InsonusK/get-latest-release@v1.0.1
    with:
        myToken: ${{ github.token }}
        exclude_types: "release, prerelease"
        view_top: 1

这次传递标签的值时,我们将连接“-beta”。

tags: "${{ steps.last_release.outputs.tag_name }}-beta"

总结

瞧,这是一个非常简单且易于为容器项目实现的ci-cd。有许多不同的选择,期待了解您是如何做到的?

https://www.codeproject.com/Articles/5298765/How-to-Create-a-Continuous-Integration-Continuous

关注
打赏
1665926880
查看更多评论
立即登录/注册

微信扫码登录

0.0478s