Docker制作自己的dockerimage
制作自己的dockerimage
我们再新建一个文件,用来生成dockerimage,文件名随便,比如我的就叫dockerfile,没有任何后缀名,要和jar包在同一个目录下
ZHR:dockerfilefile zc$ ls
crud-0.0.1-SNAPSHOT.jar dockerfile logs volumeone
ZHR:dockerfilefile zc$ pwd
/Users/zc/Desktop/md/dockerfilefile
dockerfile内容
FROM java:8
VOLUME /Users/zc/Desktop/md/dockerfilefile/volumeone
ADD crud-0.0.1-SNAPSHOT.jar demo.jar
EXPOSE 8082
ENTRYPOINT ["java","-jar","demo.jar"]
from java:8
拉取一个jdk为1.8的docker image(可以理解为一个有java8环境的linux系统)
VOLUME /Users/zc/Desktop/md/dockerfilefile/volumeone
请参考这位大佬的讲解
简单摘要
1.什么是数据卷volume
为了了解什么是Docker Volume,首先我们需要明确Docker内的文件系统是如何工作的。Docker镜像被存储在一系列的只读层。当我们开启一个容器,Docker读取只读镜像并添加一个读写层在顶部。如果正在运行的容器修改了现有的文件,该文件将被拷贝出底层的只读层到最顶层的读写层。在读写层中的旧版本文件隐藏于该文件之下,但并没有被不破坏 - 它仍然存在于镜像以下。当Docker的容器被删除,然后重新启动镜像时,将开启一个没有任何更改的新的容器 - 这些更改会丢失。此只读层及在顶部的读写层的组合被Docker称为Union File System(联合文件系统)。
为了能够保存(持久)数据以及共享容器间的数据,Docker提出了Volumes的概念。很简单,volumes是目录(或者文件),它们是外部默认的联合文件系统或者是存在于宿主文件系统正常的目录和文件。
2.为什么使用数据卷volume
Docker的镜像是由一系列的只读层组合而来,当启动一个容器的时候,Docker加载镜像的所有只读层,并在最上层加入一个读写层。这个设计使得Docker可以提高镜像构建、存储和分发的效率,节省了时间和存储空间,然而也存在如下问题。
(1)容器中的文件在宿主机上存在形式复杂,不能在宿主机上很方便的对容器中的文件进行访问
(2)多个容器之间的数据无法共享
(3)当删除容器时,容器产生的数据将丢失
为了解决这些问题,Docker引入了数据卷(volume)机制。volume是存在一个或多个容器中的特定文件或文件夹,这个目录能够独立于联合文件系统的形式在宿主机中存在,并为数据的共享与持久提供一下便利。
(1)volume在容器创建时就初始化,在容器运行时就可以使用其中的文件
(2)volume能在不同的容器之间共享和重用
(3)对volume中的数据的操作会马上生效
(4)对volume中数据操作不会影响到镜像本身
(5)volume的生存周期独立于容器的生存周期,即使删除容器,volume仍然会存在,没有任何容器使用的volume也不会被Docker删除
ADD crud-0.0.1-SNAPSHOT.jar demo.jar
这里的crud-0.0.1-SNAPSHOT.jar就是我们自己打包的jar包,demo.jar就是将crud-0.0.1-SNAPSHOT.jar以demo.jar的名字放到了jdk为1.8的docker image中。
EXPOSE 8082
该容器暴露的端口是多少,就是jar在容器中以多少端口运行
ENTRYPOINT [“java”,"-jar",“demo.jar”]
entrypoint 容器启动之后执行的命令,java -jar demo.jar 即启动jar包
然后就是构建dockerimage了,用下面的命令
docker build -f dockerfile -t crud1.0 .
-f 指定生成dockerimage的文件,我们的文件名就叫dockerfile
-t 其实是为我们生成的dockerimage指定了名字
一定要注意最后还有一个“.”,表示 dockerfile 文件在当前目录下
但是第一次执行应该是不会成功的,因为docker默认的镜像地址太慢了,mac电脑的可以看我的另一篇博客
ZHR:dockerfilefile zc$ docker build -f dockerfile -t crud1.0 .
[+] Building 54.9s (7/7) FINISHED
=> [internal] load build definition from dockerfile 0.0s
=> => transferring dockerfile: 37B 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [internal] load metadata for docker.io/library/java:8 53.6s
=> [internal] load build context 0.8s
=> => transferring context: 50.20MB 0.7s
=> [1/2] FROM docker.io/library/java:8@sha256:c1ff613e8ba25833d2e1940da0940c3824f03f802c449f3d1815a66b7f8c0e9d 0.2s
=> => resolve docker.io/library/java:8@sha256:c1ff613e8ba25833d2e1940da0940c3824f03f802c449f3d1815a66b7f8c0e9d 0.0s
=> => sha256:c1ff613e8ba25833d2e1940da0940c3824f03f802c449f3d1815a66b7f8c0e9d 2.00kB / 2.00kB 0.0s
=> => sha256:d23bdf5b1b1b1afce5f1d0fd33e7ed8afbc084b594b9ccf742a5b27080d8a4a8 4.73kB / 4.73kB 0.0s
=> [2/2] ADD crud-0.0.1-SNAPSHOT.jar demo.jar 0.2s
=> exporting to image 0.2s
=> => exporting layers 0.2s
=> => writing image sha256:47cfd312159405bf42e3854b25ceabe4cd7e099f91893aab5ff791412bd5231d 0.0s
=> => naming to docker.io/library/crud1.0 0.0s
Use 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them
检查生成的dockerimage
ZHR:dockerfilefile zc$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
crud1.0 latest 47cfd3121594 24 hours ago 693MB