1. 授权认证
  2. 获取用户个人信息
  3. 项目协同
  4. 代码托管
  5. 持续集成
  6. 制品仓库
  7. 测试管理
  1. 项目协同
  2. 代码仓库
  3. DevOps 实践之旅
  4. 一分钟开始持续集成之旅
  5. 持续部署
  6. 制品库

构建基于 Tensorflow.js 的机器学习应用

近些年伴随着计算机算力的迅猛增长,机器学习应用也得到了飞速的发展。很多科技公司使用机器学习类的应用去解决了传统应用无法解决的问题。作为机器学习界的龙头,曾经开发出 AlphaGo 击败世界围棋名将李世石的软件公司 Google ,也早已封装出了一套十分易用的机器学习框架 Tensorflow 。今天我们就介绍一下一个基于 Tensorflow.js 开发的一款 logo 识别应用是怎样通过 CODING DevOps 平台去实现自动化构建的。

本文笔者会以一个前端开发者的视角,使用 CODING DevOps 平台,详细介绍此应用的代码编写,配置 CODING 持续集成,应用的使用这几个方面。

准备工作

环境

本文涉及到以下工具,请确认已存在,或者根据链接的文档进行安装。

另外,您还需准备一个 CODING 项目

初始化

本项目源代码存放在 CODING 开源仓库
您可以通过以下命令将代码仓库克隆到本地

git clone https://e.coding.net/coding-public/demo-tensorflowjs.git

安装依赖

进入项目目录, 安装项目所需 npm 包。

cd logo-reg
yarn install

本地构建

您可以通过以下命令验证本地构建

./build.sh --local

我们验证了本地构建成功之后就可以配置 CODING 持续集成以完成云上构建了,使用 CODING 持续集成的优点显而易见,可支持自动触发,节省计算资源,发布制品,通知等。

CODING 持续集成的配置与使用

步骤一 创建制品库

CODING 制品库是一个存放应用制品的平台, 方便用户推送并拉取制品, 其概念类似 npm , dockerHub 等,但支持多种制品的发布。我们在这里使用 CODING 制品库来存放和拉取制品。首先来配置一下。

从左侧栏打开制品库,新建类型为 docker 的制品库并取名为 build,权限范围为 公开

步骤二 创建并配置构建计划

从左侧导航栏打开 持续集成 --> 构建计划 页面,点击 新建构建计划配置 创建并配置新的构建计划。CODING 持续集成为用户提供了很多模版来满足大部分用户的需求, 在这里我们选择自定义构建过程。在弹出的页面中,输入构建计划名称,选择代码仓库, 配置来源 指的的该构建计划的构建脚本存放位置,对于简单的、变动不频繁的脚本可以使用静态配置的选项,否则更推荐使用代码仓库中的脚本,这样更加灵活,方便管理。在这里我们使用代码库中的 Jenkinsfile

步骤三 编写构建脚本

构建脚本定义构建过程的具体步骤,是构建计划的核心部分。CODING 平台提供了图形化编辑器方便您快速编写构建脚本。

CODING 持续集成底层基于开源 CI/CD 软件领导者 Jenkins 实现,完全兼容 Jenkins pipeline 构建脚本语法,根据 Jenkins 官方提供的脚本编写指南,可以实现更复杂的构建任务,CODING 也提供了文本编辑器方便您在线编辑。

修改 Jenkinsfile 为以下内容:

pipeline {
  agent any
  stages {
    stage('检出') {
      steps {
        checkout([$class: 'GitSCM',
        branches: [[name: env.GIT_BUILD_REF]],
        userRemoteConfigs: [[
          url: env.GIT_REPO_URL,
          credentialsId: env.CREDENTIALS_ID
        ]]])
      }
    }
    stage('构建') {
      steps {
        echo '显示环境变量'
        sh 'printenv'
        echo '构建中...'
        sh 'docker version'
        sh './build.sh'
        echo '构建完成.'
      }
    }
    stage('推送到 CODING Docker 制品库') {
      steps {
        script {
          docker.withRegistry(
            "${CCI_CURRENT_WEB_PROTOCOL}://${env.CODING_DOCKER_REG_HOST}",
            "${env.CODING_ARTIFACTS_CREDENTIALS_ID}"
          ) {
            docker.image("${env.CODING_DOCKER_IMAGE_NAME}:${env.GIT_COMMIT}").push()
          }
        }

      }
    }
  }
  environment {
    CODING_DOCKER_REG_HOST = "${env.CCI_CURRENT_TEAM}-docker.pkg.${env.CCI_CURRENT_DOMAIN}"
    CODING_DOCKER_IMAGE_NAME = "${env.PROJECT_NAME.toLowerCase()}/${env.DOCKER_REPO_NAME}/${env.DOCKER_IMAGE_NAME}"
  }
}

此流水线脚本大致分为三个阶段,检出阶段为拉取代码,构建阶段为运行构建脚本,推送阶段为把 docker 制品推送到制品库。构建阶段主要运行脚本文件 build.sh, 其主要内如下:

#!/bin/bash

docker build -t compiler -f Dockerfile.compile .

if [ "$1" = "--local" ]
then
    docker build -t logo-reg .
else
    docker build -f $DOCKERFILE_PATH -t $CODING_DOCKER_IMAGE_NAME:$GIT_COMMIT $DOCKER_BUILD_CONTEXT
fi

可以看出, 此脚本使用分阶段构建, 使用 Dockerfile.compile 作为构建基础镜像的构建文件 , 使用 Dockerfile 作为实际的运行镜像的构建文件,这样做的优势为实际运行的镜像不包含构建应用所需要的环境,可以大大减少镜像体积。经查看,构建后的镜像仅为 149 Mb。此外,此脚本通过 --push 参数来灵活的区分云上构建环境与本地构建环境。

步骤四 配置触发构建规则

CODING 持续功能支持多种触发方式包括代码源触发、定时触发、API 触发及手动触发,这几种触发方式可以同时配置互不冲突,其中代码源触发又可配置为推送到指定分支或标签触发,触发方式多样,可满足绝大部分场景需要。

如前言中所说,我们希望把更多的精力放在源代码上,尽量减少构建所带来的干扰,因此这里必不可少的是配置通过代码源触发,通过配置如下正则表达式,可以在推送代码到匹配的分支名时自动触发构建。

^refs/(heads/(release|release-.*|build-.*|feat-.*|fix-.*|test-.*|mr/.*))

步骤五 设置变量与缓存

流程环境变量是指在 pipeline 各个阶段可以使用的环境变量。这些变量往往是人为预先设置好的, 方便开发者使用。请填入以下环境变量并保存。

变量名 默认值
DOCKER_IMAGE_NAME logo-reg
DOCKER_BUILD_CONTEXT .
DOCKERFILE_PATH Dockerfile
DOCKER_IMAGE_VERSION ${GIT_LOCAL_BRANCH:-branch}-${GIT_COMMIT}
DOCKER_REPO_NAME build

步骤六 执行构建

在这里我们可以选择手动触发构建与自动触发构建

手动触发构建

自动触发构建

由于我们刚刚设置的触发规则是 ^refs/(heads/(release|release-.*|build-.*|feat-.*|fix-.*|test-.*|mr/.*)) ,说明了分支是以 build 开头的都可以触发自动构建, 我们新建并推送一个 build-ci-demo 到远程分支,触发构建

git checkout -b build-ci-demo
git push origin HEAD

触发后的效果图

步骤七 下载并运行制品

构建成功之后回到制品库页面, 会发现我们刚刚创建的制品库此时生成了一个制品, 根据指引拉取到本地。通常为 docker pull codingff-docker.pkg.coding.net/logo-reg/build/logo-reg:b0c4b897d175ec015e36db7caa390d55e401348f 制品版本名称哈希根据个人情况替换。

运行应用辨别 CODING, GitHub, GitLab Logo

docker run -p 8080:80 codingff-docker.pkg.coding.net/logo-reg/build/logo-reg:b0c4b897d175ec015e36db7caa390d55e401348f

浏览器打开 http://127.0.0.1:8080, 等待右下角训练损失几乎将为 0 即为训练完毕(若不为 0 ,说明训练过程收到不可逆干扰,请刷新页面即可重新训练),即可上传 CODING , GitHub, GibLab 的图标文件,此应用可准确的预测出图片属于哪个 logo。

预测 CODING logo

预测 GitLab logo

可以看出,此应用具有相当高的准确率!

总结

本文通过一个基于 Tensorflow.js 开发的商标识别应用项目讲解了 CODING 持续集成、制品库的简单使用。借用 CODING DevOps 平台的这些功能, 我们解放本地算力,省去了人为的不必要劳动, 提高了生产力。CODING 持续集成可以构建任何应用(无论是终端,后端,甚至机器学习应用), 如果你想,你甚至可以在 CODING 持续集成中训练机器学习模型, 这取决于你如何编写代码。借助 CODING DevOps 平台的能力, 我们可以快速开发并发布一款机器学习应用, 相信不久的将来, 机器学习又能作用于 CODING DevOps 平台,解决目前 DevOps 中的难题。使 CODING DevOps 平台更加智能,自动化。

上一篇在持续集成中使用 dotnet 工具
最近更新
感谢反馈有用
感谢反馈没用