如何在maven docker 容器间访问容器里访问私服

Docker 搭建maven私服
时间: 06:01:39
Docker 镜像docker-nexus3
1.创建data volume,用来持久化容器中的数据,保证容器删除后私服中的数据仍然存在
$ docker volume create --name nexus-data
2.启动nexus
$ docker run -d -p
--name nexus -v nexus-data:/nexus-data sonatype/nexus3
3.启动完成后可以通过host的ip:8081访问
maven-central是个代理,当我们需要的依赖在私服上不存在时,此仓库会直接从maven仓库中下载,并缓存到私服里面
maven-public是一个仓库组,里面包含maven- releases和maven- snapshots以及maven-central,我们自己新创建的仓库也可以加入到maven-public,这样使用这服的人配置一个maven-public的mirror就可以用私服里面的所有依赖
maven-releases和maven-snapshots分别对应着发布版和版
4.nexus默认用户是 admin/admin123,建议启动后修改密码,创建一个专门给开发人员用的用户,可以read、browse所有仓库的权限
5.使用maven私服
为了开发者的所有项目都自动采用搭建好的私服,需要在 .m2目录下如下配置文件
&?xml version="1.0" encoding="UTF-8"?&
&settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"&
&id&public&/id&
&username&dev&/username&
&password&dev222&/password&
&/servers&
&id&public&/id&
&mirrorOf&central&/mirrorOf&
&name&internal nexus repository&/name&
&url&http://IP:Port/repository/maven-public/&/url&
&/mirrors&
&profiles&
&id&jdk-1.8&/id&
&activation&
&activeByDefault&true&/activeByDefault&
&jdk&1.8&/jdk&
&/activation&
&properties&
&piler.source&1.8&/piler.source&
&piler.target&1.8&/piler.target&
&pilerVersion&1.8&/pilerVersion&
&/properties&
&/profile&
&/profiles&
&/settings&
注意dev是新创建的用户,此用户只有浏览,读取私服上依赖jar包的权限,对于需要上传文件到私服上的用户,需要用下面的配置
在.m2下的setting.xml文件的&servers&tag中追加如下配置段
&id&xxxxx-releases&/id&
&username&admin&/username&
&password&admin123&/password&
&id&xxxxx-snapshots&/id&
&username&admin&/username&
&password&admin123&/password&
其中xxxx-releases和xxxxx-snapshots是自己新创建的maven仓库,并且设置成可上传模式
上传到私服有两种格式
1.通过pom.xml上传&
在项目对应pom.xml 文件,追加如下配置段
&distributionManagement&
&repository&
&id&xxxxx-releases&/id&
&name&xxxxx-releases&/name&
&url&http://IP:Port/repository/xxxxx-releases/&/url&
&/repository&
&snapshotRepository&
&id&xxxxx-snapshots&/id&
&name&xxxxx-snapshots&/name&
&url&http://IP:Port/repository/xxxxx-snapshots/&/url&
&/snapshotRepository&
&/distributionManagement&
配置的id需要和setting.xml中server的id保持一致,之后就可以在工程目录下执行mvn deploy,将jar发布到私服的仓库中,jar以snapshots的会自动发布到xxxxx-snapshots里面,没有的会直接发布到xxxxx-releases中
2.利用命令行上传第三方jar
mvn -X deploy:deploy-file -DgroupId=com.chengf -DartifactId=test -Dversion=1.0.0 -Dpackaging=jar -Dfile=test.jar -Durl=http://IP:Port/repository/xxxxx-releases/ -DrepositoryId=xxxxx-releases
此处的repositoryId需要和setting.xml中server的id保持一致
$T.total > 0 && $T.page <= $T.pageNum}
{#foreach $T.data as r}
{$T.r.formt_tm}{#if $T.r.nickname}{#else}匿名{#/if}
{$T.r.content}
{#if $T.page > 1 && $T.pageNum > 1)
$T.s_num > 2}
{#for index = $T.s_num to $T.e_num}
$T.pageNum > $T.pageNavSize+ 2 && $T.s_num != $T.pageNum - $T.pageNavSize}
{#if $T.pageNum > 1}
{#if $T.pageNum != $T.page && $T.pageNum > 1}
<a href="javascript:void(0);" page="{$T.page 下一页
您的回应...
也许你感兴趣
(window.slotbydup=window.slotbydup || []).push({
id: '3465635',
container: s,
size: '120,240',
display: 'float'
(C)2012 本站提供的内容来源于广大网络用户,我们不保证内容的正确性。如果转载了您的内容,希望删除的请联系我们!案例 | 持续集成:Docker、Maven、Java_Docker_传送门
案例 | 持续集成:Docker、Maven、Java
在Alooma,我们非常非常非常喜爱Docker。真的, 我们想完全容器化我们的应用。 虽然容器化应用有非常多的好处,但在这里,我并不是要说服你用Docker。我们只是认为你和我们一样喜欢这东西。接下来,让我们谈谈Alooma是如何在生产环境使用Docker来精简开发流程并快速push代码的。概述Docker允许你把基础架构当作代码一样来对待。这个代码就是你的Dockerfile。像其它代码一样,我们想要使用一个紧密的改变->提交->构建->测试的周期(一个完整的持续集成解决方案)。为了实现这个目标,我们需要构建一个流畅的DevOps流水线。让我们把目标分解为更加详细的需求:在版本控制系统中管理Dockerfile在CI服务器上为每个commit构建Docker镜像上传构件并打标签(这个构件要能够简单的部署)我们的工作流我们的DevOps流水线围绕GitHub、Jenkins和Maven构建。下面是它的工作流程:GitHub将repo的每一个push通知给JenkinsJenkins触发一个Maven buildMaven 构建所有的东西,包括Docker镜像最后,Maven会把镜像推送到私有的Docker Registry。这个工作流的好处是它允许我们能够很容易的为每个发布版本打标签(所有的commit都被构建并且在我们的Docker Registry中准备好了)。然后我们可以非常容易地通过pull和run这些Docker镜像进行部署。事实上这个部署过程是非常简单的,我们通过发送一个命令给我们信任的Slack机器人:”Aloominion”(关于我们的机器人朋友的更多情况将在未来的文章中发表)开始这个过程。你可能对这个工作流中的其他元素非常熟悉,因为它们都很常见。所以,让我们来深入了解如何使用Maven构建Docker镜像。深入Docker 构建Alooma是一个Java公司。我们已经使用Maven作为我们构建流水线的中心工具,所以很自然的想到把构建Docker的过程也加入到我们的Maven构建过程中去。当搜索和Docker交互的Maven插件时,出现了3个选项。我们选择使用Spotify的maven-docker-plugin —— 虽然rhus的和alexec的同名插件看起来也是一个不错的选择。另一个我们的构建计划依赖的Maven插件是maven-git-commit-id-plugin。我们使用这个插件,所以我们的Docker镜像能使用git的commit ID来打标签 —— 这在部署过程中非常有帮助,我们可以了解运行的是哪个版本。给我看代码!每一个docker镜像有它自己的Maven模块(所有上面提到的docker-maven 插件在一个模块一个Dockerfile时都能顺利地工作)让我们从Spotify插件的一个简单配置开始:
com.spotify
docker-maven-plugin
${project.basedir}
alooma/${project.artifactId}
我们看到这里我们把插件的build目标和Maven的package阶段绑定,我们也指导它去在我们模块的根目录下来寻找Dockerfile(使用DockerDirectory 元素来指定),我们还把镜像名称用它的构件Id来命名(用”alloma/”做前缀)。我们注意到的第一件事情是这个镜像没有被push到任何地方,我们可以通过加入true到配置中来解决这个问题。但是现在这个镜像会被push到默认的Docker Hub Registry上。糟糕。为了解决这个问题,我们定义了一个新的Maven属性docker-registry.alooma.io:5000/并且把镜像名称imageName改为${docker.registry}alooma/${project.artifactId}。 你可能会想,“为什么需要为Docker Registry设置一个属性?”, 你是对的!但是有这个属性可以使我们在Regsitry URL改变的时候能够更方便的修改。有一个更重要的事情我们还没有处理——我们想让每一个镜像用它的git commit ID来打标签。这可以通过改变imageName为${docker.registry}alooma/${project.artifactId}:${mit.id.abbrev}来实现。${mit.id.abbrev}属性是通过我上面提到的maven-git-commit-id-plugin插件来实现的。所以,现在我们的插件配置看起来像下面这样:docker-maven-plugin
${project.basedir}
${docker.registry}alooma/${project.artifactId}:${mit.id.abbrev}
我们的下一个挑战是在我们的pom.xml中表达我们的Dockerfile的依赖。一些我们的Docker镜像在构建时使用了 FROM 其它的Docker 镜像作为基础镜像(也在同一个构建周期中构建)。例如,我们的webgate镜像(是我们的机遇Tomcat的WebApp)基于我们的base镜像(包含Java 8、更新到最新的 apt-get、等等)。这些镜像在同一个构建过程中构建意味着我们不能简单的使用FROM docker-registry.alooma.io/alooma/base:some-tag因为我们需要这个标签编程当前构建的标签(即 git commit ID)。为了在Dockerfile中获得这些属性,我们使用了Maven的resource filtering功能。这在一个资源文件中替换Maven 的属性。
${project.basedir}
**/Dockerfile
在Dockerfile的内部我们有一个这样的FROM:FROM ${docker.registry}alooma/base:${mit.id.abbrevs}一些更多的事情…….我们需要的是我们的配置来找到正确的Dockerfile(过滤过之后的),这可以在target/classes文件夹内找到,所以我们把dockerDirectory改为${project.build.directory}/classes。这意味着现在我们的配置文件长这样:
${project.basedir}
**/Dockerfile
${docker.registry}alooma/${project.artifactId}:${mit.id.abbrev}
此外,我们还要添加base构件作为webgate模块的一个Maven依赖来保证正确的Maven构建顺序。但是我们还有另一个挑战:我们如何把我们编译和打包了的源文件添加到我们的Docker镜像中呢?我们的Dockerfile依赖于很多其它文件,它们通过ADD或COPY命令插入。[你可以在这里(/reference/builder/)读到更多的关于Dockerfile的指导。]为了让这些文件可以被获取,我们需要使用插件配置的resources标签。
${project.basedir}
target/**/*
注意到我们排除了一些文件。记住这个resources标签不应该和通常的Maven resources标签弄混,看看下面的例子,它来自于我们的pom.xml的一部分:
**/Dockerfile
com.spotify
docker-maven-plugin
前一个添加在我们想添加一些静态资源到镜像时工作,但是如果我们想要添加一个在同一个构建中构建的构件时需要更多的调整。例如,我们的webgate Docker镜像包含了我们的webgate.war,这是由另一个模块构建的。为了添加这个war作为资源,我们首先必须把它作为我们的Maven依赖加进来,然后使用maven-dependency-plugin插件的copy目标来把它加到我们当前的构建目录中。
org.apache.maven.plugins
com.alooma
${project.parent.version}
${project.build.directory}
webgate.war
现在这允许我们简单的把这个文件加到Docker插件的resources中去。
**/Dockerfile
com.spotify
docker-maven-plugin
我们需要做的最后一件事情是让我们的CI服务器(Jenkins)真的将镜像push到Docker Registry上。请记住本地构件默认是不会push镜像的。为了push这些镜像,我们改变我们的标签的值从true变为${push.image}属性,这默认是被设置为false,并且只会在CI服务器上设置为true。译注:这里的意思是,由于开发人员也要在本地构建然后测试之后才会提交,而测试的镜像不应该被提交到Registry,所以应该使用一个属性,默认为false,在CI服务器上覆盖为true在构建后去push镜像。这就完成了!让我们看一下最终的代码:
${project.basedir}
**/Dockerfile
com.spotify
docker-maven-plugin
${project.build.directory}/classes
${push.image}
${docker.registry}alooma/${project.artifactId}:${mit.id.abbrev}
${project.basedir}
target/**/*
${project.build.directory}
webgate.war
性能这个过程有两个能够提高你的构建和部署的性能的改进地方:让你的基础的机器镜像(在EC2的例子下是AMI)包含一些你的Docker镜像的基础版本。这样会使得docker pull只去pull那些改变了的层,即增量(相对于整个镜像来说要小得多)。在Docker Registry的前端放一个Redis缓存。这可以缓存标签和元数据,减少和真实存储(在我们的例子下是S3)的回环。我们现在已经使用这个构建过程一段时间了,并且对它非常满意。然而仍然有提高的空间,如果你有任何关于让这个过程更加流畅的建议,我很乐意在评论中听到你的想法。DockOneDockOne,新圈子,新思路,新视野。
觉得不错,分享给更多人看到
Docker 微信二维码
分享这篇文章
Docker 最新头条文章
Docker 热门头条文章Docker持续部署图文详解
发表于 08:54|
作者萧田国、张春源
摘要:关于Docker的文章铺天盖地,但精品文章往往翻译居多。都说Docker天生适合持续集成/持续部署,但同样,可落地、实际可操作性的文章也很罕见。
JAVA项目如何通过Docker实现持续部署(只需简单四步),即: 开发同学通过git push上传代码,经Git和Jenkins配合,自动完成程序部署、发布,全程无需运维人员参与。
这是一种真正的容器级的实现,这个带来的好处,不仅仅是效率的提升,更是一种变革:&*&开发人员第一次真正为自己的代码负责——终于可以跳过运维和测试部门,自主维护运行环境(首先是测试/开发环境)。&本文是cSphere Docker实战视频第二讲的文字版,本文联合作者@张春源同学(任职希云cSphere)即为视频主讲人,关于更多系列视频,详见。福利:点击文末的“实战视频”即可手机欣赏本文对应的实战视频哦。
难者不会,会者不难。通过简单的4个配置,即可优雅地实现持续部署。本文依惯例放上目录, 1. 持续部署的技术思路 2. 效果展示 3. 配置Git和Jenkins联动
4. 配置Jenkins自动更新代码 5. 效果图文详解 6. FAQ
好吧,我们正式开始。
1. 持续部署的技术思路
在本例中,假设我们JAVA项目的名称为hello。简要的技术思路如下。
本案例中假设代码托管在上,Jenkins和Docker Registry(类似于yum源)各运行在一个Docker容器中。JAVA项目自己也单独运行在一个叫hello的容器中。 本文采取的持续部署方案,是从私有的Docker Reistry拉取代码。有些变通的方案,把代码放在宿主机上,让容器通过卷组映射来读取。这种方法不建议的原因是,将代码拆分出容器,这违背了Docker的集装箱原则:这也导致装卸复杂度增加。从货运工人角度考虑,整体才是最经济的。这样,也才能实现真正意义的容器级迁移。 或者说,容器时代,抛弃过去文件分发的思想,才是正途。本文最后的问答环节对此有更多阐述。 容器即进程。我们采用上述方案做Docker持续部署的原因和意义,也在于此。容器的生命周期,应该远远短于虚拟机,容器出现问题,应该是立即杀掉,而不是试图恢复。
2. 效果展示
本文最后实现的效果,究竟有多惊艳呢?且看如下的演示。
2.1 程序代码更新前的效果
我们以时间戳来简洁、显式的表述程序更新情况。
2.2 提交程序代码更新本例中,我们把首页的时间戳从,修改为(见如下)。2.3 上传新代码到Git顺序执行如下操作,输入正确的git账号密码。然后呢? 然后什么都不用做了。端杯茶(如果不喜欢咖啡的话),静静地等待自动部署的发生, 旁观一系列被自动触发的过程,机器人似的运转起来(请容稍候再加以描述)。为什么需要3~5分钟?只是因为本案例中的JAVA项目,需要从国外download Maven程序包,以供Jenkins调用和编译JAVA。正式应用环境中,可以把Maven源放在国内或机房。如果仅仅需要对PHP项目做持续部署,那就更快捷了。2.4 查看代码更新后的效果在静静地等待几分钟后,新的代码确实已经自动部署完毕。那么,这一切怎么实现的呢?很复杂么?不然。只要按照如下几步,便可快速实现哦。3. 配置Git和Jenkins联动这个过程也是难者不会,会者不难。主要分为如下三步。3.1 Jenkins配置Git源Jenkins中新建项目java-app,并配置从Git拉取程序代码。具体如下:3.2 Jenkins配置远程构建Jenkins中配置token,以供git远程调用时使用。3.3 Git开启钩子怎么让Git在接收到用户更新的代码后,把消息和任务传递给Jenkins呢?这借助于Git的hook功能,配置起来也非常简单,如下。4. 配置Jenkins自动更新代码Jekins在接收到Git传递过来的消息后,再触发一个远程构建(到目标服务器),按照预定义的任务列表,执行一系列的工作,重建容器等。详见如下:我们把其中最关键的Shell脚本内容摘抄出来。
5. 效果图文详解
在2.3这个章节中,我们当时的操作如下,这个目的是向Git提交更新代码。
当时并没有细说后续发生的事情,既然上面已经说清楚了原理,那我们就可以接下来说说实际发生的事情啦。5.1 上传代码到Git这里貌似整个过程已经完成并顺利退出。其实,后台的工作才刚刚开始哦。这时会触发Git服务器向相应的Jenkins服务器发出一个操作请求,此工作太过迅速,也没啥好说的,我们接下来看Jenkins都干啥子了。5.2 Jenkins进行的精彩互动1)Jenkins会自动"冒出来"一个构建任务。2)我们点进来,看看具体操作日志。是的,正在接受来自Git的任务。
3)下载Maven相关的软件包(就是这个过程慢)。
4)下载完成后,就开始利用maven BUILD 新的hello项目包。
5)然后重建Maven容器,构建新的Image并Push到Docker私有库中。
6)最后,重新把Docker容器拉起来。这样,又新生了。呵呵
问题1:采用这么相对复杂的办法(而不是把更新代码放在宿主机然后卷组映射),是因为项目基于JAVA么;是否PHP项目就可以采用更新代码放在宿主机然后卷组映射这种方式?
回答1:将代码拆分出容器,违背了集装箱原则。导致装卸复杂度增加。从货运工人角度考虑,整体才是最经济的。一切版本化。抛弃过去的文件分发。这是正途。至于文件大小,大的war包也就50M或100M,在现有网络下不成问题,性能问题最好优化。另外建议关注docker
2 docker,p2p传输。
问题2:如果整体代码超过500m或者1g以上,整体集装箱是否就不太好了?如果容器与代码分离,镜像就100m左右(2层,base+服务),然后代码的话,是放到共享存储里,每个代码有更新,比如svn的代码,可以直接在共享存储里进行svn update就可以控制版本&
回答2:如果你的代码500M,那只能说明业务开发该打板子了。
问题3:如果测试环境使用您提供的完整集装箱服务还行,但在生产环境,集群里运行docker做应用,如果每个容器都是有完整的代码,是否有点臃肿,不如每个集群节点里就运行基础服务镜像,通过卷组功能绑定共享存储里的代码,加上Crontab、Python和Shell脚本,这样每次代码更新就1次就行了。
回答3:环境一致性,在过去从来没有解决好。10年前我们做PaaS时,和这个做法类似。不是说不好,时代变了,用脚本东拼西凑,终究难有好的系统。不能只考虑现在的方便,容器技术和vm如果类比,我觉得会让自己下决定时很纠结。
补充3:脚本一般是典型的运维工程师思维,quick & dirty。一般很难做成一个产品或者系统。整体考虑和扩展性考虑都比较少。现在做docker的难点在于到底怎么看待它。到底是拿它做调度的基本单位,还是部署的基本单位考虑清楚,再聊方案。
备注:上述问题的回答,主要由王利俊@cSphere和陈尔冬@华为完成。作者简介:萧田国,男,硕士毕业于北京科技大学,触控科技运维负责人。拥有十多年运维及团队管理经验。先后就职于联想集团(Oracle数据库主管)、搜狐畅游(数据库主管)、智明星通及世纪互联等。从1999年开始,折腾各种数据库如Oracle/MySQL/MS SQL Server/NoSQL等,兼任数据库培训讲师若干年。张春源,目前任职希云cSphere,希云cSphere国际领先的docker管理平台。国内最早期的Docker实践者,在生产环境拥有一年多的Docker容器管理经历。深刻理解Docker对于开发、测试以及运维的价值。擅长利用Docker构建整个DevOps自动化平台。热爱专研Dockerfile这门艺术,并对CoreOS有深入研究。(责编/魏伟)
推荐阅读相关主题:
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号:CSDNnews
相关热门文章Maven Docker镜像使用技巧 - ilinux_one
Maven Docker镜像使用技巧 - ilinux_one
发布时间: 18:02:01
编辑:www.fx114.net
本篇文章主要介绍了"Maven Docker镜像使用技巧 - ilinux_one ",主要涉及到Maven Docker镜像使用技巧 - ilinux_one 方面的内容,对于Maven Docker镜像使用技巧 - ilinux_one 感兴趣的同学可以参考一下。
Maven是目前最流行的Java项目管理工具之一,提供了强大的包依赖管理和应用构建功能。Docker提供了可以用于管理和构建Java应用。与直接安装使用Maven工具相比,使用Docker镜像具有更好的可移植性,可以方便地进行版本切换,非常适合在持续集成过程中使用。关于Maven官方镜像的用法可以参考使用阿里云加速Maven官方仓库在国内网络下的下载速度实在是让人欲哭无泪,利用阿里云的Maven镜像可以大大提升软件包下载速度。我们可以在官方Maven镜像的基础之上添加阿里云镜像配置。其代码可以在&上获得它的配置文件settings.xml如下阿里云容器服务提供了预构建的Docker镜像可供直接使用<-/acs/maven,我们可以像使用mvn命令一样,直接在当前目录中执行如下命令来构建应用docker run -it --rm --name maven -v "$(pwd)":/usr/src/app -w /usr/src/-/acs/maven mvn clean install如果希望能够缓存下载的maven仓库,我们可以利用Docker的文件卷来实现首先执行如下命令创建一个名为“maven-repo”的文件卷docker volume create --name maven-repo在之后的调用中,将其挂载到maven镜像中仓库下载目录上docker run -it --rm --name maven -v "$(pwd)":/usr/src/app -v maven-repo:/usr/share/maven/ref -w /usr/src/-/acs/maven mvn clean install这样maven仓库就不会每次都下载一遍了。优化Dockerfile提升构建速度我们可以在Dockerfile中构建应用,并利用Docker构建时的分层缓存机制来提升构建速度下面是一个示例Dockerfile.build文件-/acs/maven:3-jdk-8ENV MY_HOME=/usr/src/appRUN mkdir -p $MY_HOMEWORKDIR $MY_HOMEADD pom.xml $MY_HOME其中的一个重要技巧就是先把pom.xml添加到工作目录,利用maven命令下载应用所需jar包之后,再添加应用源文件进行编译。这样只要pom.xml没有更新就不会重新下载所依赖的jar包,可以大大加快镜像构建速度。我们可以通过如下命令来编译应用docker build -t builder-应用编译与Docker镜像构建分离对于静态编译型语言,我们通常需要将应用编译过程与镜像构建过程分离。主要有以下两个考虑:最终生成的Docker镜像不应该包含源代码最终生成的Docker镜像应该最小化,不应该包含编译时工具我们可以将应用编译结果从Docker镜像中拷贝出来,方法如下docker build -t builder-img -f Dockerfile.build .docker create --name builder builder-imgdocker cp builder:/usr/src/app/target ./target这时maven构建的结果就被拷贝到当前目录的“target”子目录下面了。之后,我们可以利用另外一个Dockerfile来构建应用镜像了。篇幅有限不再赘述。总结本文以Maven为例介绍了Docker在应用构建中的一些常见技巧利用国内的镜像站点加速软件包下载:阿里云和阿里集团提供了大量开源项目的包管理镜像站点,阿里云容器服务开源项目&&中提供很多带加速能力的Ruby/Python/Node/Maven基础镜像可供参考。在Docker镜像构建过程中,为了防止由于代码变化反复下载软件包,可以先把应用配置文件加入Dockerfile,在编译之前提前下载软件包。比如Ruby的Gemfile, Python的requirements.txt,和NodeJs的package.json都可以采用类似方法。这样可以更好地利用Docker的分层缓存机制加速镜像构建过程。应用编译应该与Docker镜像构建分离
一、不得利用本站危害国家安全、泄露国家秘密,不得侵犯国家社会集体的和公民的合法权益,不得利用本站制作、复制和传播不法有害信息!
二、互相尊重,对自己的言论和行为负责。
本文标题:
本页链接:1001人阅读
java(20)
运维和中间件(18)
docker(2)
此前在一篇文章有讲到将maven项目部署至tomcat
本文就是将 maven-tomcat-plugins 和 Docker 结合起来,将web应用部署至Docker容器中正在运行的tomcat
在pom.xml加入
&org.apache.tomcat.maven&
&tomcat7-maven-plugin&
&http://192.168.1.106:8081/manager/text&
在maven的settings.xml加入
maven的settings.xml在$MAVEN_HOME/conf目录
下载docker的tomcat镜像
1、搜索Docker Hub里的tomcat镜像
docker search tomcat
部分搜索结果如下
DESCRIPTION
Apache Tomcat is an open source implementa...
dordoka/tomcat
Ubuntu 14.04, Oracle JDK 8 and Tomcat 8 ba...
cloudesire/tomcat
Tomcat server, 6/7/8
davidcaste/alpine-tomcat
Apache Tomcat 7/8 using Oracle Java 7/8 wi...
andreptb/tomcat
Debian Jessie based image with Apache Tomc...
可以看到,星数最高的是官方的tomcat,有关官方tomcat的镜像可以访问
上面 “7.0.73-jre7, 7.0-jre7, 7-jre7, 7.0.73, 7.0, 7”等等 是这个tomcat库支持的tag(标签),这里我们选用的是 “7” 这个标签
2、拉取Docker Hub里的镜像
3、拉取完成后查看本地的镜像
docker images
docker image tomcat:7
创建个人的Docker镜像
创建Dockerfile文件
mkdir -p /usr/local/dockerfile/massive
cd /usr/local/dockerfile/massive
touch Dockerfile
编辑Dockerfile
from tomcat:7
MAINTAINER massive
ADD tomcat-users.xml /usr/local/tomcat/conf/
注:tomcat-users.xml可以在tomcat/conf目录找到,拷贝一个到此目录
在tomcat-users.xml加入以下内容
rolename="manager-gui"/&
rolename="manager-script"/&
username="deploy" password="deploy" roles="manager-gui, manager-script"/&
build这个镜像
运行个人定制的Docker镜像
将web应用部署至容器里运行的tomcat
web应用会通过tomcat的部署机制拷贝至容器的 /usr/local/tomcat/webapps/${project} 下,当Docker容器关闭后,容器内的改动不会保存至镜像,也就是说拷贝至容器的web应用会在容器关闭后被删除。
&&相关文章推荐
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
访问:22954次
排名:千里之外
原创:31篇
(10)(11)(1)(1)(1)(8)(2)(1)

我要回帖

更多关于 docker 容器间访问 的文章

 

随机推荐