DockerHub基于Github自己主动化构建

Docker Hub上的自己主动化构建

关于自己主动化构建

自己主动化构建是一个特殊的功能,它同意您在 Docker Hub 上使用构建集群,依据指定的 Dockerfile 或者 GitHub 、 BitBucket 仓库(或环境)来自己主动创建镜像。该系统将从仓库复制一份,并依据以仓库为环境的 Dockerfile 的描写叙述构建镜像。

由此产生的镜像将被上传到注冊表,而且自己主动生成标记。

自己主动化构建有很多优势:

  • 你的自己主动化构建项目一定是准确依照预期构建的
  • 在 Docker Hub 注冊表上,不论什么拥有你仓库訪问权限的用户都乐意浏览 Dockerfile
  • 自己主动化构建保证了你的仓库总是最新的

自己主动化构建支持 GitHub 和 BitBucket 的私有和公有的仓库。

要使用自己主动化构建,你必须拥有经过验证有效的 Docker Hub 账户和 GitHub/Bitbucket 账户。

设置GitHub自己主动化构建

首先,你须要将 GitHub 账户链接到你的 Docker Hub 账户,以同意注冊表查看你的仓库。

注:眼下我们须要有读写权限以建立 Docker Hub 和 GitHub 的挂钩服务。这是GitHub管理权限的方式,我们别无选择。抱歉!我们将保护您的账户及隐私,确保不会被他人非法获取。

開始构建!登录到你的 Docker Hub 账户。点击屏幕右上方的 "+ Add Repository" button,选择自己主动化构建

选择GitHub服务

然后依照说明授权和连接你的 GitHub 账户到 Docker Hub。

连接成功后,你就能够选择用来自己主动化构建的仓库了。

创建一个自己主动化构建项目

你能够用你的 Dockerfile 从你的公共或者私有仓库创建一个自己主动化构建项目

GitHub子模块

假设你的 GitHub 仓库包括了私有子模块的连接,你须要在 Docker Hub 上加入部署秘钥。

部署秘钥位于自己主动化构建主页的 “Build Details” 菜单。訪问设置 GitHub 仓库的页面,选择 “Deploy keys” 来加入秘钥。

Step Screenshot Description
1. 你的自己主动化构建部署秘钥位于 “Build Details” 菜单的 “Deploy keys” 下。

2. 在你的 GitHub 子模块仓库设置页。加入部署秘钥。

GitHub组织

一旦你的组织成员身份设置为公开,相应的 GitHub 组织状态便会被公开在你的 GitHub 上。

为了验证。你能够查看 GitHub 上你的组织的成员选项卡。

GitHub服务挂钩

依照下面步骤配置自己主动化构建的 GitHub 服务挂钩:

Step Screenshot Description
1. 登录到 GitHub.com,并转到您的仓库页面,点击右側页面“Settings”。

运行该操作要求你有该仓库的管理员权限。

2. 点击页面左側的“Webhooks & Services”。
3. 找到 "Docker" 并点击它.
4.

============================================================================

最后一步

相信非常多新手看完上面的指南仍然云里雾里,留了最后一层窗户纸:在Github项目顶层文件夹加入配套的Dockerfile

FROM ubuntu

MAINTAINER Wei Zhou <[email protected]>

RUN apt-get update;     apt-get -y upgrade

RUN apt-get -y install g++ cmake git subversion

RUN mkdir /home/git;     cd /home/git;     sudo git clone https://github.com/cszhouwei/cmake_demo.git -b master;     cd cmake_demo;     mkdir build;     cd build;     cmake -DCMAKE_BUILD_TYPE=Release ../;     make

CMD ["/home/git/cmake_demo/buld/module_xxx/module_xxx", "--config", "/etc/module_xxx.conf"]

上述Dockerfile位于我的cmake_demo演示样例项目。有兴趣的读者请自取!

Github:https://github.com/cszhouwei/cmake_demo.git

DockerHub:docker pull cszhouwei/cmake-demo

參考文献

https://github.com/widuu/chinese_docker/blob/master/SUMMARY.md

时间: 2024-08-27 13:46:59

DockerHub基于Github自己主动化构建的相关文章

Android自己主动化构建之Ant多渠道打包实践(下)

前言 上一篇(Android自己主动化构建之Ant多渠道打包实践(上))已经介绍了Android的apk是怎样构建的,本篇博客继续Ant打包的实践过程. 集成友盟统计SDK 这里以友盟统计为例,对各个渠道进行统计.我们须要先集成它的SDK 配置权限 <!-- 权限 --> <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" > </uses-permission&g

DockerHub基于Github自动化构建

Docker Hub上的自动化构建 关于自动化构建 自动化构建是一个特殊的功能,它允许您在 Docker Hub 上使用构建集群,根据指定的 Dockerfile 或者 GitHub . BitBucket 仓库(或环境)来自动创建镜像.该系统将从仓库复制一份,并根据以仓库为环境的 Dockerfile 的描述构建镜像.由此产生的镜像将被上传到注册表,并且自动生成标记. 自动化构建有许多优势: 你的自动化构建项目一定是准确按照预期构建的 在 Docker Hub 注册表上,任何拥有你仓库访问权限

基于反射实现自己主动化restful开发

[Author]: kwu 基于反射实现自己主动化restful开发,通用的仅仅须要写查询数据库的sql.并增加相应的javabean实现的高速restful服务的开发. 1.编写数据库的查询sql.相应sql.properties daily = DailyReport;select t.day,t.cnt,t.type from (select day,cnt,type From dailyreport where type=? order by day desc limit ? ) t o

【金阳光測试】基于控件核心技术探讨---Android自己主动化系列(2)---2013年5月

第一讲分享了下安卓自己主动化一些概况和一些自己主动化框架现状和技术可以解决什么样的问题. 这次课就深入到android世界里面.遨游.翱翔.深入了解自己主动化測试核心技术. 搞过编程开发的同学听到instrumentation这个东西一定不陌生.在android架构里面分四层(最以下是硬件驱动相关抽象层.不是笔者讨论的内容范围),往上面一点是协议栈.也不是讨论的核心,都和c语言相关.一直到第三层框架层(framework). 细分有二: A.   android的改良虚拟机dalvik和Runt

【前端福利】用grunt搭建自己主动化的web前端开发环境-完整教程

jQuery在使用grunt,bootstrap在使用grunt,百度UEditor在使用grunt,你没有理由不学.不用! 1. 前言 各位web前端开发者.假设你如今还不知道grunt或者听说过.可是不会熟练使用grunt,那你就真的真的真的out了(三个"真的"反复.表示重点). 至于grunt的作用,这里不具体说了.总之你假设做web前端开发,你一定要用grunt.另一点,它全然免费,没有盗版.既强大又免费的东西.为何不用? 当然了,你假设你能找到更好的替代grunt的其它工具

Mock+Proxy在SDK项目的自己主动化測试实战

项目背景 广告SDK项目是为应用程序APP开发者提供移动广告平台接入的API程序集合,其形态就是一个植入宿主APP的jar包.提供的功能主要有以下几点: - 为APP请求广告内容 - 用户行为打点 - 错误日志打点 - 反作弊 团队现状 在项目推进的过程中.逐渐暴露了一些问题: 1. 项目团队分为上海团队(服务端)和北京团队(client),因为信息同步,人力资源等其它原因.服务端与client的开发进度非常难保持同步,经常出现client等着和服务端联调的情况 2. 接口文档不稳定,理解有偏差

Selenium2 Python 自己主动化測试实战学习笔记(五)

7.1 自己主动化測试用例 无论是功能測试.性能測试和自己主动化測试时都须要编写測试用例,測试用例的好坏能准确的体现了測试人员的经验.能力以及对项目的深度理解. 7.1.1 手工測试用例与自己主动化測试用例 手工測试用例是针对手工測试人员.自己主动化測试用例是针对自己主动化測试框架.前者是手工測试用例人员应用手工方式进行用例解析,后者是应用脚本技术进行用例解析. 前者具有较好的异常处理能力,并且可以基于測试用例,制造各种不同的逻辑推断,并且人工測试步步跟踪,可以仔细定位问题.后者全然依照測试用例

带有机器人框架的.NET自己主动化測试

Clayton Neal在软件測试和质量保证方面有超过13年的经验,当中有八年的Windows, web,和移动应用程序的測试自己主动化经验.他在測试领域的全部等级都工作过.近期他在Bloomberg and Misys担任QA经理.同一时候他还是Sogeti的自己主动化測试顾问.Clayton对自己主动化測试超迷恋,还见识了怎样亲自成功实施測试自己主动化. ? 測试自己主动化的优点我们都非常清楚,更快地反馈问题,降低手工測试,持续集成就是当中随口可举的.測试团队成员越多,公司使用自己主动化越多

web的自己主动化公布

</pre>基于眼下业务的版本号.使用的maven 及tomcat <p></p><p>假设我们使用 Jenkins 公布是比較好的,可是存在一定的问题,就是须要学习时间,</p><p>基于我们的项目.我使用python 自己主动构建公布环境</p><p>脚本例如以下:</p><p></p><pre code_snippet_id="498203"