使用 Dockerfile定制Java Web镜像
一、前言
对使用 Docker 搭建 Java Web 运行环境(利用 commit 理解镜像构成 来源:黄勇 )博文的归纳:
1、启动容器:
docker run <相关参数> <镜像 ID> <初始命令> -i:表示以“交互模式”运行容器 -t:表示容器启动后会进入其命令行 -v:表示需要将本地哪个目录挂载到容器中,格式:-v <宿主机目录>:<容器目录>进入容器,配置环境,exit
2、查看所有容器 :
docker container ls -a 或者 docker ps -a3、docker commit 的语法格式为:
docker commit [选项] <容器ID或容器名> [<仓库名>[:<标签>]]--author "wwx<wuweixiang.alex@gmail.com>" \ --message "修改了默认网页" \docker commit 57c312bbaad1 huangyong/javaweb:0.1
4、启动容器:
docker run <相关参数> <镜像 ID> <初始命令>
慎用 docker commit,利用 commit 镜像构成,意味着所有对镜像的操作都是黑箱操作,生成的镜像也被称为黑箱镜像。如果使用 docker commit 制作镜像,以及后期修改的话,每一次修改都会让镜像更加臃肿一次,所删除的上一层的东西并不会丢失,会一直如影随形的跟着这个镜像,即使根本无法访问到。这会让镜像更加臃肿。
二、使用 Dockerfile 定制Java Web镜像
Ⅰ、Dockerfile回顾
①Dockerfile简介
Dockerfile 是一个文本文件,其内包含了一条条的指令(Instruction),每一条指令构建一层,因此每一条指令的内容,就是描述该层应当如何构建。
②Dockerfile指令详解
#指定基础镜像 FROM Dockerfile中必备指令,并且必须是第一条指令 FROM scratch 不以任何镜像为基础,接下来的指令将作为镜像第一层开始存在 #指定维护者信息 MAINTAINER 格式: MAINTAINER <name> #执行命令行命令 RUN 定义每一层该如何构建(不是在写 Shell 脚本) 每一个 RUN = 启动一个容器、执行命令、然后提交存储层文件变更 两行 RUN 命令的执行环境不同 格式: 1) shell 格式: RUN <命令> #类似命令行输入 2) exec 格式: RUN ["可执行文件", "参数1", "参数2"] #类似函数调用 行尾 \ 换行 行首 # 注释 && 命令串联 #复制文件 COPY 格式: 1) COPY <源路径>... <目标路径> 2) COPY ["<源路径1>",... "<目标路径>"] <源路径> 可以是多个,甚至可以是通配符 #上下文路径的相对路径 <目标路径> 可以是容器内的绝对路径,也可以是相对于工作目录的相对路径(工作目录可以用 WORKDIR 指令来指定) #更高级的复制文件 ADD <源路径> 可以是一个 URL, 如果是gzip , bzip2 以及 xz 的情况下,ADD 指令将会自动解压缩这个压缩文件到 <目标路径> 去 所有的文件复制均使用COPY 指令,仅在需要自动解压缩的场合使用 ADD #容器启动命令 CMD 容器就是进程。 既然是进程,在启动的时候,需要指定所运行的程序及参数。 CMD 指令就是用于指定默认的容器主进程的启动命令 对于容器而言,其启动程序就是容器应用进程,容器就是为了主进程而存在的,主进程退出,容器就失去了存在的意义,从而退出,其它辅助进程不是它需要关心的东西。 格式: 1) shell 格式: CMD <命令> 2) exec 格式: CMD ["可执行文件", "参数1", "参数2"...] 一般推荐使用 exec 格式,这类格式在解析时会被解析为 JSON 数组,因此一定要使用双引号 " ,而不要使用单引号 CMD echo $HOME 在实际执行中,会将其变更为: CMD [ "sh", "-c", "echo $HOME" ] #入口点 ENTRYPOINT 和 CMD 一样,都是在指定容器启动程序及参数 实际执行时,将变为: <ENTRYPOINT> "<CMD>" #启动时,可再对可执行文件进行传参 ENTRYPOINT ["docker-entrypoint.sh"] #应用运行前的准备工作,指定了 ENTRYPOINT 为 docker-entrypoint.sh 脚本,并且可在镜像启动时候传入参数来服务脚本 #设置环境变量 ENV 格式: 1) ENV <key> <value> 2) ENV <key1>=<value1> <key2>=<value2>... #构建参数 ARG 和 ENV 所不同的是, ARG 所设置的构建环境的环境变量,在将来容器运行时是不会存在这些环境变量的。 格式: ARG <参数名>[=<默认值>] 可以在构建命令docker build 中用 --build-arg <参数名>=<值> 来覆盖 #定义匿名卷 VOLUME 为了防止运行时用户忘记将动态文件所保存目录挂载为卷(volume),指定某些目录挂载为匿名卷,这样在运行时如果用户不指定挂载,其应用也可以正常运行,不会向容器存储层写入大量数据 格式: 1) VOLUME <路径> 2) VOLUME ["<路径1>", "<路径2>"...] VOLUME /data 这里的 /data 目录就会在运行时自动挂载为匿名卷,任何向 /data 中写入的信息都不会记录进容器存储层 -v mydata:/data mydata 这个命名卷挂载到了 /data 这个位置,替代了Dockerfile 中定义的匿名卷的挂载配置 #声明端口 EXPOSE 声明运行时容器提供服务端口 #指定工作目录 WORKDIR 改变以后各层的工作目录 格式: WORKDIR <工作目录路径> 相当于 cd ... WORKDIR /a WORKDIR b WORKDIR c RUN pwd 则最终路径为 /a/b/c #指定当前用户 USER USER 指令和 WORKDIR 相似,都是改变环境状态并影响以后的层 USER 只是帮助你切换到指定用户而已,这个用户必须是事先建立好的,否则无法切换。 #健康检查 HEALTHCHECK 格式: 1) HEALTHCHECK [选项] CMD <命令> #设置检查容器健康状况的命令 2) HEALTHCHECK NONE #如果基础镜像有健康检查指令,使用这行可以屏蔽掉其健康检查指令 HEALTHCHECK 支持下列选项: --interval=<间隔> :两次健康检查的间隔,默认为 30 秒; --timeout=<时长> :健康检查命令运行超时时间,如果超过这个时间,本次健康检查就被视为失败,默认 30 秒; --retries=<次数> :当连续失败指定次数后,则将容器状态视为 unhealthy ,默认 3次。和 CMD , ENTRYPOINT 一样, HEALTHCHECK 只可以出现一次,如果写了多个,只有最后一个生效。 HEALTHCHECK --interval=5s --timeout=3s \ CMD curl -fs http://localhost/ || exit 1 #为他人做嫁衣裳 ONBUILD 当以当前镜像为基础镜像,去构建下一级镜像的时候才会被执行 格式: ONBUILD <其它指令> 做一个基础镜像,基础镜像更新,各个项目不用同步 Dockerfile 的变化,重新构建后就继承了基础镜像的更新
③构建镜像
#构建镜像 docker build [选项] <指定上下文路径/URL/-> 镜像并非在本地构建,而是在服务端,也就是镜像是在 Docker 引擎中构建的。那么在这种客户端/服务端的架构中,如何才能让服务端获得本地文件呢? 当构建的时候,用户会指定构建镜像上下文的路径, docker build 命令得知这个路径后,会将路径下的所有内容打包,然后上传给 Docker 引擎。 这样Docker 引擎收到这个上下文包后,展开就会获得构建镜像所需的一切文件。 初学者经常会问的为什么COPY ../package.json /app 或者 COPY /opt/xxxx /app 无法工作的原因,因为这些路径已经超出了上下文的范围,Docker 引擎无法获得这些位置的文件。 例如:COPY ./package.json /app/ 是复制 上下文(context) 目录下的package.json #COPY 这类指令中的源文件的路径都是上下文路径的相对路径 -f ../Dockerfile.php 参数指定某个文件作为Dockerfile 其它 docker build 的用法 直接用 Git repo 进行构建:Docker 就会自己去 git clone 这个项目、切换到指定分支、并进入到指定目录后开始构建 用给定的 tar 压缩包构建:Docker 引擎会下载这个包,并自动解压缩,以其作为上下文,开始构建
Ⅱ、Dockerfile的编写
1.0.0 Dockerfile
# 版本信息 FROM centos:7 MAINTAINER wuweixiang <wuweixiang.alex@gmail.com> # 设置工作目录 WORKDIR /var/ # 添加jdk、tomcat ADD jdk-8u191-linux-x64.tar.gz . #ADD http://mirrors.hust.edu.cn/apache/tomcat/tomcat-8/v8.5.35/bin/apache-tomcat-8.5.35.tar.gz . ADD apache-tomcat-8.5.35.tar.gz . # 设置环境变量 ENV JAVA_HOME /var/jdk1.8.0_191 ENV PATH $PATH:$JAVA_HOME/bin:$CATALINA_HOME/bin ENV TIME_ZONE Asia/Shanghai # 更改时区 RUN set -x \ && echo "${TIME_ZONE}" > /etc/timezone \ && ln -sf /usr/share/zoneinfo/${TIME_ZONE} /etc/localtime # 开启内部服务端口 EXPOSE 8080 # 启动tomcat服务器 CMD ["/var/apache-tomcat-8.5.35/bin/catalina.sh","run"] && tail -f /var/apache-tomcat-8.5.35/logs/catalina.out
Ⅲ、构建方式(镜像已push,此步可忽略)
①linux安装git
sudo yum install git
②克隆项目源码
git clone https://gitee.com/wuweixiang/javaweb-docker.git
③构建镜像
进入到/javaweb-docker/dockerfile-java8-tomcat8目录下:
docker build -t [<仓库名>[:<标签>]] . #创建镜像 仓库名:经常以 两段式路径 形式出现,比如 wuweixiang/javaweb:1.0.0,前者Docker账号用户名,后者则往往是对应的软件名。 标签:指定所需哪个版本的镜像,默认latest。
Ⅳ、使用方式
1、新购买的服务器,安装docker,执行以下指令:
curl -fsSL https://get.docker.com | bash -s docker --mirror Aliyun
2、创建/var/webapps/目录,并将war包放入该目录下
3、运行以下命令,即可实现部署。
docker run -d -p 80:8080 \ -v /var/webapps/:/var/apache-tomcat-8.5.35/webapps/ \ --name <容器名> \ wuweixiang/javaweb:1.0.0
注意:
挂载路径 /var/webapps/ 为当前war上传位置
Ⅴ、使用示例
1、下载一个war包到挂载路径/var/webapps/下:
可见,war包自动完成解压。
2、即可访问http://112.74.185.172/finder-web-2.4.9
Ⅵ、总结
该部署方式与之前的部署方式上,省去了jdk、tomcat环境的配置过程,只要上传war包即可。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Koa项目搭建过程详细记录
Java中的Spring MVC加MyBatis基本上已成为Java Web的标配。Node JS上对应的有Koa、Express、Mongoose、Sequelize等。Koa一定程度上可以说是Express的升级版。许多Node JS项目已开始使用非关系型数据库(MongoDB)。Sequelize对非关系型数据库(MSSQL、MYSQL、SQLLite)做了支持。 Koa项目构建 cnpm install -g koa-generator // 这里一定要用koa2 koa2 /foo Koa常用中间件介绍 koa-generator生成的应用已经包含常用中间件了,这里仅说它里面没有用到的。 koa-less app.use(require('koa-less')(__dirname + '/public')) 必须在static前use,不然会无效。 stylesheets文件夹下新建styles.less,并引入所有模块化less文件。 @import 'foo.less'; @import 'bar.less'; 这样所有的样式会被编译成一个style.css。在模板(pu...
- 下一篇
美团容器平台架构及容器技术实践
本文根据美团基础架构部/容器研发中心技术总监欧阳坚在2018 QCon(全球软件开发大会)上的演讲内容整理而成。 背景 美团的容器集群管理平台叫做HULK。漫威动画里的HULK在发怒时会变成“绿巨人”,它的这个特性和容器的“弹性伸缩”很像,所以我们给这个平台起名为HULK。貌似有一些公司的容器平台也叫这个名字,纯属巧合。 2016年,美团开始使用容器,当时美团已经具备一定的规模,在使用容器之前就已经存在的各种系统,包括CMDB、服务治理、监控告警、发布平台等等。我们在探索容器技术时,很难放弃原有的资产。所以容器化的第一步,就是打通容器的生命周期和这些平台的交互,例如容器的申请/创建、删除/释放、发布、迁移等等。然后我们又验证了容器的可行性,证实容器可以作为线上核心业务的运行环境。 2018年,经过两年的运营和实践探索,我们对容器平台进行了一次升级,这就是容器集群管理平台HULK 2.0。 把基于OpenStack的调度系统升级成容器编排领域的事实标准Kubernetes(以后简称K8s)。 提供了更丰富可靠的容器弹性策略。 针对之前在基础系统上碰到的一些问题,进行了优化和打磨。 美团的...
相关文章
文章评论
共有0条评论来说两句吧...