Docker学习笔记(3)-- 如何使用Dockerfile构建镜像

Dockfile是一种被Docker程序解释的脚本,Dockerfile由一条一条的指令组成,每条指令对应Linux下面的一条命令。Docker程序将这些Dockerfile指令翻译真正的Linux命令。Dockerfile有自己书写格式和支持的命令,Docker程序解决这些命令间的依赖关系,类似于Makefile。Docker程序将读取Dockerfile,根据指令生成定制的image。相比image这种黑盒子,Dockerfile这种显而易见的脚本更容易被使用者接受,它明确的表明image是怎么产生的。有了Dockerfile,当我们需要定制自己额外的需求时,只需在Dockerfile上添加或者修改指令,重新生成image即可,省去了敲命令的麻烦。


1. Dockerfile的书写规则及指令使用方法


Dockerfile的指令是忽略大小写的,建议使用大写,使用 # 作为注释,每一行只支持一条指令,每条指令可以携带多个参数。
Dockerfile的指令根据作用可以分为两种,构建指令和设置指令。构建指令用于构建image,其指定的操作不会在运行image的容器上执行;设置指令用于设置image的属性,其指定的操作将在运行image的容器中执行。


(1)FROM(指定基础image)

构建指令,必须指定且需要在Dockerfile其他指令的前面。后续的指令都依赖于该指令指定的image。FROM指令指定的基础image可以是官方远程仓库中的,也可以位于本地仓库。
该指令有两种格式:
FROM <image>
指定基础image为该image的最后修改的版本。或者:
FROM <image>:<tag>
指定基础image为该image的一个tag版本。


(2)MAINTAINER(用来指定镜像创建者信息)

构建指令,用于将image的制作者相关的信息写入到image中。当我们对该image执行docker inspect命令时,输出中有相应的字段记录该信息。
格式:
MAINTAINER <name>


(3)RUN(安装软件用)

构建指令,RUN可以运行任何被基础image支持的命令。如基础image选择了ubuntu,那么软件管理部分只能使用ubuntu的命令。
该指令有两种格式:
RUN <command> (the command is run in a shell - `/bin/sh -c`)
RUN ["executable", "param1", "param2" ... ]  (exec form)


(4)CMD(设置container启动时执行的操作)

设置指令,用于container启动时指定的操作。该操作可以是执行自定义脚本,也可以是执行系统命令。该指令只能在文件中存在一次,如果有多个,则只执行最后一条。
该指令有三种格式:
CMD ["executable","param1","param2"] (like an exec, this is the preferred form)
CMD command param1 param2 (as a shell)
当Dockerfile指定了ENTRYPOINT,那么使用下面的格式:
CMD ["param1","param2"] (as default parameters to ENTRYPOINT)
ENTRYPOINT指定的是一个可执行的脚本或者程序的路径,该指定的脚本或者程序将会以param1和param2作为参数执行。所以如果CMD指令使用上面的形式,那么Dockerfile中必须要有配套的ENTRYPOINT。


(5)ENTRYPOINT(设置container启动时执行的操作)

设置指令,指定容器启动时执行的命令,可以多次设置,但是只有最后一个有效。
两种格式:
ENTRYPOINT ["executable", "param1", "param2"] (like an exec, the preferred form)
ENTRYPOINT command param1 param2 (as a shell)
该指令的使用分为两种情况,一种是独自使用,另一种和CMD指令配合使用。
当独自使用时,如果你还使用了CMD命令且CMD是一个完整的可执行的命令,那么CMD指令和ENTRYPOINT会互相覆盖只有最后一个CMD或者ENTRYPOINT有效。
# CMD指令将不会被执行,只有ENTRYPOINT指令被执行
CMD echo “Hello, World!”
ENTRYPOINT ls -l
另一种用法和CMD指令配合使用来指定ENTRYPOINT的默认参数,这时CMD指令不是一个完整的可执行命令,仅仅是参数部分;ENTRYPOINT指令只能使用JSON方式指定执行命令,而不能指定参数。
FROM ubuntu
CMD ["-l"]
ENTRYPOINT ["/usr/bin/ls"]


(6)USER(设置container容器的用户)

设置指令,设置启动容器的用户,默认是root用户。
# 指定memcached的运行用户
ENTRYPOINT ["memcached"]
USER daemon
或
ENTRYPOINT ["memcached", "-u", "daemon"]


(7)EXPOSE(指定容器需要映射到宿主机器的端口)

设置指令,该指令会将容器中的端口映射成宿主机器中的某个端口。当你需要访问容器的时候,可以不是用容器的IP地址而是使用宿主机器的IP地址和映射后的端口。要完成整个操作需要两个步骤,首先在Dockerfile使用EXPOSE设置需要映射的容器端口,然后在运行容器的时候指定-p选项加上EXPOSE设置的端口,这样EXPOSE设置的端口号会被随机映射成宿主机器中的一个端口号。也可以指定需要映射到宿主机器的那个端口,这时要确保宿主机器上的端口号没有被使用。EXPOSE指令可以一次设置多个端口号,相应的运行容器的时候,可以配套的多次使用-p选项。
格式:
EXPOSE <port> [<port>...]

# 映射一个端口
EXPOSE port1
# 相应的运行容器使用的命令
docker run -p port1 image

# 映射多个端口
EXPOSE port1 port2 port3
# 相应的运行容器使用的命令
docker run -p port1 -p port2 -p port3 image
# 还可以指定需要映射到宿主机器上的某个端口号
docker run -p host_port1:port1 -p host_port2:port2 -p host_port3:port3 image
端口映射是docker比较重要的一个功能,原因在于我们每次运行容器的时候容器的IP地址不能指定而是在桥接网卡的地址范围内随机生成的。宿主机器的IP地址是固定的,我们可以将容器的端口的映射到宿主机器上的一个端口,免去每次访问容器中的某个服务时都要查看容器的IP的地址。对于一个运行的容器,可以使用docker port加上容器中需要映射的端口和容器的ID来查看该端口号在宿主机器上的映射端口。


(8)ENV(用于设置环境变量)

构建指令,在image中设置一个环境变量。
格式:
ENV <key> <value>

设置了后,后续的RUN命令都可以使用,container启动后,可以通过docker inspect查看这个环境变量,也可以通过在docker run --env key=value时设置或修改环境变量。
假如你安装了JAVA程序,需要设置JAVA_HOME,那么可以在Dockerfile中这样写:
ENV JAVA_HOME /path/to/java/dirent


(9)ADD(从src复制文件到container的dest路径)

构建指令,所有拷贝到container中的文件和文件夹权限为0755,uid和gid为0;如果是一个目录,那么会将该目录下的所有文件添加到container中,不包括目录;如果文件是可识别的压缩格式,则docker会帮忙解压缩(注意压缩格式);如果<src>是文件且<dest>中不使用斜杠结束,则会将<dest>视为文件,<src>的内容会写入<dest>;如果<src>是文件且<dest>中使用斜杠结束,则会<src>文件拷贝到<dest>目录下。
格式:
ADD <src> <dest>

<src> 是相对被构建的源目录的相对路径,可以是文件或目录的路径,也可以是一个远程的文件url;
<dest> 是container中的绝对路径


(10)VOLUME(指定挂载点))

设置指令,使容器中的一个目录具有持久化存储数据的功能,该目录可以被容器本身使用,也可以共享给其他容器使用。我们知道容器使用的是AUFS,这种文件系统不能持久化数据,当容器关闭后,所有的更改都会丢失。当容器中的应用有持久化数据的需求时可以在Dockerfile中使用该指令。
格式:
VOLUME ["<mountpoint>"]

FROM base
VOLUME ["/tmp/data"]
运行通过该Dockerfile生成image的容器,/tmp/data目录中的数据在容器关闭后,里面的数据还存在。例如另一个容器也有持久化数据的需求,且想使用上面容器共享的/tmp/data目录,那么可以运行下面的命令启动一个容器:
docker run -t -i -rm -volumes-from container1 image2 bash
container1为第一个容器的ID,image2为第二个容器运行image的名字。


(11)WORKDIR(切换目录)

设置指令,可以多次切换(相当于cd命令),对RUN,CMD,ENTRYPOINT生效。
格式:
WORKDIR /path/to/workdir

# 在 /p1/p2 下执行 vim a.txt
WORKDIR /p1 WORKDIR p2 RUN vim a.txt


(12)ONBUILD(在子镜像中执行)

ONBUILD <Dockerfile关键字>
ONBUILD 指定的命令在构建镜像时并不执行,而是在它的子镜像中执行。
详细资料可参考 https://www.dockboard.org/docker-quicktip-3-onbuild


2. 创建Dockerfile,构建jdk+tomcat环境


Dockerfile文件

# Pull base image
FROM ubuntu:13.10

MAINTAINER zing wang "zing.jian.wang@gmail.com"

# update source
RUN echo "deb http://archive.ubuntu.com/ubuntu precise main universe"> /etc/apt/sources.list
RUN apt-get update

# Install curl
RUN apt-get -y install curl

# Install JDK 7
RUN cd /tmp &&  curl -L 'http://download.oracle.com/otn-pub/java/jdk/7u65-b17/jdk-7u65-linux-x64.tar.gz' -H 'Cookie: oraclelicense=accept-securebackup-cookie; gpw_e24=Dockerfile' | tar -xz
RUN mkdir -p /usr/lib/jvm
RUN mv /tmp/jdk1.7.0_65/ /usr/lib/jvm/java-7-oracle/

# Set Oracle JDK 7 as default Java
RUN update-alternatives --install /usr/bin/java java /usr/lib/jvm/java-7-oracle/bin/java 300   
RUN update-alternatives --install /usr/bin/javac javac /usr/lib/jvm/java-7-oracle/bin/javac 300   

ENV JAVA_HOME /usr/lib/jvm/java-7-oracle/

# Install tomcat7
RUN cd /tmp && curl -L 'http://archive.apache.org/dist/tomcat/tomcat-7/v7.0.8/bin/apache-tomcat-7.0.8.tar.gz' | tar -xz
RUN mv /tmp/apache-tomcat-7.0.8/ /opt/tomcat7/

ENV CATALINA_HOME /opt/tomcat7
ENV PATH $PATH:$CATALINA_HOME/bin

ADD tomcat7.sh /etc/init.d/tomcat7
RUN chmod 755 /etc/init.d/tomcat7

# Expose ports.
EXPOSE 8080

# Define default command.
ENTRYPOINT service tomcat7 start && tail -f /opt/tomcat7/logs/catalina.out

tomcat7.sh

export JAVA_HOME=/usr/lib/jvm/java-7-oracle/
export TOMCAT_HOME=/opt/tomcat7

case $1 in
start)
  sh $TOMCAT_HOME/bin/startup.sh
;;
stop)
  sh $TOMCAT_HOME/bin/shutdown.sh
;;
restart)
  sh $TOMCAT_HOME/bin/shutdown.sh
  sh $TOMCAT_HOME/bin/startup.sh
;;
esac
exit 0

我已经把这些文件上传到了Github https://github.com/agileshell/dockerfile-jdk-tomcat.git


3. 构建镜像

脚本写好了,需要转换成镜像:

docker build -t zingdocker/jdk-tomcat .
docker run -d -p 8090:8080 zingdocker/jdk-tomcat


默认情况下,tomcat会占用8080端口,刚才在启动container的时候,指定了 -p 8090:8080,映射到宿主机端口就是8090。

http://<host>:8090 host为主机IP


参考
Docker - Reference - Dockerfile http://docs.docker.com/reference/builder/
http://www.blogjava.net/yongboy/archive/2013/12/16/407643.html
一些例子
http://dockerfile.github.io/
https://github.com/Toub/toub-docker-tomcat8-java8-auto-deploy
https://github.com/eugeneware/docker-wordpress-nginx
https://github.com/gemnasium/rails-meets-docker

内容概要:本文围绕“基于线性决策规则的分布鲁棒机组组合研究”展开,提出了一种应对电力系统中不确定性因素(如风电出力波动)的先进优化建模方法。通过引入线性决策规则(Linear Decision Rules, LDR),将原本难以求解的分布鲁棒优化问题转化为具有较强计算可行性的数学形式,在保证调度方案经济性的同时显著提升了系统在不确定环境下的鲁棒性与可靠性。研究详细阐述了模型构建的关键环节,包括不确定集合的构造、决策变量对不确定参数的仿射依赖关系设计、目标函数与约束条件的精确数学表达,并依托Matlab平台完成了完整的代码实现与仿真验证,充分展示了该方法在计算效率与调度性能之间的良好平衡。; 适合人群:具备电力系统优化、运筹学与凸优化理论基础,熟悉Matlab编程语言,从事高比例可再生能源并网、鲁棒调度、电力系统规划与运行等方向研究的研究生、高校科研人员及电力行业工程技术专家。; 使用场景及目标:① 解决含大规模风电等波动性电源的机组组合问题,提升调度方案对出力不确定性的适应能力与系统安全性;② 深入学习和掌握分布鲁棒优化理论与线性决策规则在复杂电力工程问题中的建模思想、实现技巧与实际应用价值;③ 为现代电力系统的安全、经济、可靠运行提供先进的理论工具与技术支撑。; 阅读建议:建议读者结合Matlab代码实现部分,深入理解线性决策规则的数学原理、近似机制及其在降低问题复杂度方面的有效性,优先复现文中仿真结果,并可进一步探索不同类型的不确定集(如椭球集、多面体集)或更高阶决策规则对优化结果与计算负担的影响,以深化对该方法性能边界的认识。
内容概要:本文提出了一种面向综合能源系统的算力-电力-热力联合优化调度策略,旨在实现多能源耦合系统中的高效协同运行。研究通过构建涵盖算力负荷(如数据中心计算任务)、电力系统与热力系统的综合模型,利用Matlab进行仿真与优化求解,深入整合三者的能量流动关系与动态耦合特性。重点分析了算力负载的时空迁移特性及其对电力与热力供需平衡的影响机制,引入先进的优化算法实现系统经济性、能效性和可再生能源消纳能力的多目标协同优化。该方法有效提升了综合能源系统的资源综合利用效率,降低了运行成本,并增强了系统灵活性与可持续性。; 适合人群:具备电力系统、能源工程、自动化或相关领域背景,熟悉Matlab编程,从事综合能源系统、智能电网、数据中心能耗管理或能源互联网研究的研发人员与高校研究生。; 使用场景及目标:①应用于数据中心与区域能源系统协同调度的实际工程场景;②服务于科研中对多能耦合系统建模、优化算法设计与验证的需求;③实现节能减排、提升系统运行经济性与对可再生能源的高比例消纳目标。; 阅读建议:建议结合提供的Matlab代码深入理解模型构建、变量定义与求解流程,重点关注算力与能源系统间的耦合建模方法,可通过调整负荷参数、引入新的约束条件或更换优化算法进行二次开发与拓展研究。
内容概要:本文研究了基于Q-Learning自适应强化学习的PID控制器在自主水下航行器(AUV)中的应用,旨在提升其在复杂水下环境中运动控制的精度、稳定性和自适应能力。通过建立AUV的六自由度动力学模型,将Q-Learning算法与传统PID控制相结合,实现了对PID参数的在线自整定。文中详细设计了强化学习的状态空间、动作空间与奖励函数,构建了智能优化的控制框架。仿真结果表明,相较于传统固定参数PID控制器,该方法在轨迹跟踪精度、抗外部干扰能力和系统动态响应性能方面均有显著提升,有效解决了非线性、强耦合、时变参数等挑战,验证了智能控制策略在水下机器人系统中的可行性与优越性。; 适合人群:具备自动控制理论、强化学习基础或水下机器人建模相关知识,从事控制工程、自动化、海洋工程、机器人学等领域的科研人员及研究生。; 使用场景及目标:①应用于复杂海洋环境下AUV的高精度运动控制与自主导航;②为智能控制算法在非线性、强耦合动态系统中的工程实现提供技术参考;③推动强化学习与经典控制理论融合的创新研究与实际部署。; 阅读建议:建议读者结合提供的Matlab代码进行仿真实验,重点理解Q-Learning与PID参数调节之间的交互机制,深入分析状态定义、动作选择与奖励函数设计的合理性,从而掌握智能自适应控制系统的构建方法与优化思路。
随着区块链技术在金融、供应链、政务等领域的广泛应用,联盟链作为一种兼具去中心化特性与可控性的技术方案,已成为企业级区块链系统的主流架构。然而,联盟链的共识算法面临着安全性与性能之间的根本权衡问题:传统的实用拜占庭容错(PBFT)算法虽然能够提供强一致性保证,但在节点规模增大时会面临通信开销激增、共识延迟显著增加的挑战,限制了其在大规模网络中的应用。如何在保证系统安全性的前提下提升共识吞吐量,是当前联盟链技术发展亟待解决的核心问题。本研究围绕联盟链共识算法的安全性与性能权衡理论展开,以PBFT类共识算法为研究对象,深入分析了节点规模变化对共识安全性边界与性能指标的影响机制。研究首先构建了PBFT共识算法的形式化安全性模型,推导了不同故障节点比例下的共识正确性条件;随后建立了基于消息复杂度分析的性能模型,量化了节点数量与共识延迟、吞吐量之间的数学关系。基于上述理论分析,本研究提出了一种自适应共识阈值调整机制,该机制能够根据网络中的实际节点数量和故障节点比例动态调整共识所需的阈值参数,在保证系统安全的前提下优化共识性能。仿真实验设置了不同节点规模(10-100个节点)和不同故障节点比例(0%-33%)的场景,分别测试了传统PBFT算法与自适应阈值PBFT算法的共识延迟和吞吐量指标。实验结果表明,在相同安全保障下,自适应阈值机制能够将共识吞吐量提升30%-50%,同时将共识延迟降低20%-40%,尤其在大规模网络场景下性能优势更为显著。 【课程报告内容】 摘要 第1章 绪论 第2章 相关技术与理论基础 第3章 PBFT共识算法安全性分析 第4章 安全性与性能权衡模型 第5章 自适应共识阈值调整机制设计 第6章 仿真实验与结果分析 第7章 总结与展望 参考文献
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值