Docker平台构成及执行流程

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/dylloveyou/article/details/53614304

1)平台构成
Docker 平台由三部分组成:
Client:用户使用 Docker 提供的工具(CLI 以及 API 等)来构建,上传镜像并发布命令来创建和启动容器
Docker HOST:从 Docker registry 上下载镜像并启动容器
Registry:Docker 镜像仓库,用于保存镜像,并提供镜像上传和下载

2)执行流程
输入以下命令:

docker run -it ubuntu:14.04  

会看到以下的命令提示符:

root@fb12e139cb8d:/#

执行几条命令然后终结这个容器:

root@fb12e139cb8d:/# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.5 LTS
Release:    14.04
Codename:   trusty
root@fb12e139cb8d:/# exit
exit

我们看到的是Ubuntu的一个bash shell,它运行于在主机上隔离的容器中。以下是上述动作的流程分解图。
这里写图片描述

1.输入一条Docker命令:
docker: 运行docker客户端
run: 该命令启动一个新的容器
-it: 是否启动交互式终端模式的可选项
ubuntu:14.04: 容器启动所基于的镜像名及版本号

2.在主机上运行的Docker的服务首先检查本地是否有所请求的镜像拷贝,没有的话则执行第3步,有的话执行第5步。

3.Docker服务检查镜像仓库是否有名字为ubuntu,版本号为14.04的镜像存在,如果找到执行第4步,没有找到返回报错 docker: Error: image xxx not found。

4.Docker服务下载镜像并存储于本地缓存中,以备下次使用。

5.Docker服务基于该镜像ubuntu 创建新的容器。

注:此文参考了网上的一些资料,但找不到具体地址了,如果谁清楚可以和我联系,多谢!

展开阅读全文

基于 jenkins 和 docker 的持续集成平台

09-17

软件开发过程中,开发成员经常需要把自己工作集成到项目中,通常每个成员每天至少集成一次。如果项目较小,对外部的依赖较小,那么软件集成可能不会是什么问题。但是目前很多软件项目特别是互联网项目面临着需求不明确,系统架构复杂,任务分配混乱等一系列问题,从而给持续集成带来许多麻烦。也给整个项目带来不必要的风险。因此一个有效的持续集成系统越来越重要。rnrn[img=https://img-bbs.csdn.net/upload/201509/17/1442457399_559829.jpg][/img]rnrn个推平台是一个极其复杂的分布式系统,整个系统包含了 RPC 调用,高速缓存,集群同步等各种复杂的场景。整个团队只有二十来个人却维护了近百个模块的开发和测试工作,如果没有一套有效的机制,很难想象如何完成这些任务。持续集成在其中扮演了非常重要的角色,借助于 Git、Docker、Jenkins 以及 Nexus 等工具,我们搭建了自己的持续集成环境,并一步一步的摸索出了自己的最佳实践,这篇文章将会和大家一起分享我们是如何利用这些技术提高团队的生产力的。rnrn个推持续集成系统的组成rnrn使用git作为版本控制库rn相比于同类项目版本系统,git有一项非常显著的优势,就是版本分支(branch)的合并(merge)十分方便。rn使用docker搭建测试环境rn作为一种新型的虚拟化方式,相对于传统的虚拟化方式有着众多的优势。例如,docker虚拟容器的启动可以在秒级实现,并且对系统资源的利用率很高。另外,docker的管理,迁移和扩展也更轻松有效。rn使用jenkins作为持续集成服务器rnJenkins为开发人员提供了非常有效的持续集管理。其强大的插件系统和明确的构建逻辑,使得构建流程的创建非常简便。rnrnDocker在持续集成系统中的作用rnrn测试作为软件项目重要的一环,一般都需要开发团队搭建一套独立的测试系统。但作为持续集成的一个环节,此测试系统又异于一般的测试系统。主要原因为,持续集成测试系统主要用来做回归测试,而且需要支持快速大量的代码升级。基于docker的特性,以及持续集成的需求,个推采用docker为持续集成搭建了一整套测试系统。rnrn镜像准备:docker 的运行基于镜像文件,而每个项目所需的镜像文件又不同。因此需要独立分析每个项目的需求以及未来扩展需要,创建出不同版本的镜像文件。目前,个推主要有4大类镜像,分别支持前端,后端,工具类等项目。以前端为例,个推采用了前后端分离的开发模式,因此此镜像主要用来支持web 前端的服务运行。rnrn服务包准备:为了能在docker里运行所需要的服务,需要docker实例中安装相应的服务包(service package)。 一般有两种方法,一种是将相应的服务包在镜像文件中安装,另一种以docker 卷的形式动态映射到docker实例。 两种方式有其优劣,第一种方式使得每次docker 容器的启动非常迅捷,而第二种方式则更为灵活。这个需要根据不同的需求选择合适的方式。rn下图为docker 在整个持续集成系统中的作用。Jenkins 作为主服务器将代码和docker 统一的管理起来。rnrn[img=https://img-bbs.csdn.net/upload/201509/17/1442457450_326463.png][/img]rnrn个推持续集成流程rnrn下面以user模块为例,对持续集成的流程进行阐述,如下图所示:rnrn[img=https://img-bbs.csdn.net/upload/201509/17/1442457506_60081.png][/img]rnrn从图中可以看出,我们系统的git分支包括dev,master两个分支:rnrndev:开发分支,开发人员维护,开发人员将最新代码提交到这个分支,Jekins监视这个分支,任何代码改变都会触发自动化测试rnmaster:发布分支,这个分支上的版本是自动化测试通过后的版本,且自动化打包监控这个分支rnrn图中的每个长方形代表一个Jenkins Job。下面将对每个Job进行说明:rn• user: 监控user代码库的dev分支,当每次有新的代码提交时,就会自动触发构建任务。编译代码,同时生成code style,测试覆盖率等关于代码质量的报表。成功后将触发user-docker任务。rn• user-docker: 打包user工程,重启user的docker实例以便于使用全新的user包。成功后将触发testcase任务rn• testcase: 验收测试,检测改变是否满足业务需求所定义的验收条件。成功后将触发marge任务rn• merge:将user的dev分支merge到master分支rn• user-pkg: 监控user代码库的master分支,当有代码改变时,执行mvn package打包操作rn经过上面的几个步骤,从代码提交到打包的整个过程就自动化起来了。rnrn总结rnrn目前越来越多的公司开始重视持续集成系统,但是缺乏定制化的系统真的能满足复杂的需求吗?当模块之间的联系越来越复杂,集成的频率越来越大,运行环境的不断升级 等等,缺乏定制的持续集成系统是否能达到预期,个推在docker 上找到了解决方案。 虽然仍然有许多挑战,但随着技术的升级和完善,我们终会越做越好。rn 论坛

没有更多推荐了,返回首页