Loading

docker-编写构建镜像关键字

Dockerfile reference

  • Docker build 命令根据 Dockerfile 文件和上下文构建一个映像。
  • 构建由 Docker 守护进程运行，而不是由 CLI 运行。构建过程要做的第一件事是将整个上下文(递归地)发送到守护进程。
  • 在大多数情况下，最好从一个空目录作为上下文开始，并将 Dockerfile 保存在该目录中。只添加构建 Dockerfile 所需的文件。

⚠️：Warning

不要使用根目录作为构建下文的 PATH -- 会导致构建过程中去传输硬件中的所有内容去 Docker daemon (守护进程)

Usage 用法

在 build context 使用文件，Dockerfile 引用指令中指定的文件

  • 例如 COPY 指令。若要提高生成的性能，添加 .dockerignore 文件(exclude file and directory)移到上下文件的目录

传统的，Dockerfile 位于上下文的根部。在 docker 构建中使用-f 标志指向文件系统中的任何位置的 Dockerfile。

  • docker build -f /path/to/a/Dockerfile .

根据 Dockerfile 文件构建镜像，同时指定 存储库和标签来保存新映像

  • docker build  -t shykes/myapp .

要在构建之后将图像标记为多个存储库，请在运行构建命令时添加 multiple-t 参数:

  • docker build -t shykes/myapp:1.0.2 -t shykes/myapp:latest .

在 Docker 守护进程运行 Dockerfile 中的指令之前，它会对 Dockerfile 进行初步验证，如果语法不正确，则返回一个错误:

例子：

 docker build -t test/myapp .
 [internal] load build definition from Dockerfile                       0.1s
 => transferring dockerfile: 60B                                        0.0s
 [internal] load .dockerignore                                          0.1s
 => transferring context: 2B                                            0.0s
 error: ......

Docker 守护进程逐条运行 Dockerfile 中的指令，在最终输出新映像的 ID 之前，必要时将每条指令的结果提交到新映像中。Docker 守护进程将自动清除您发送的上下文。

image-20210514115658168

请注意，每条指令都是独立运行的，并且会创建一个新映像（包括前一个映像的内容）——因此 RUN cd/tmp 不会对下一条指令产生任何影响。

只要有可能，Docker 就会使用一个构建缓存来显著加快 Docker 构建过程。这是由控制台输出中的缓存消息指出的。(有关更多信息，请参见 Dockerfile 最佳实践指南:)

# 加一层 存储库和标签 -- 将构建新的镜像
docker build -t svendowideit/ambassador .
 
# 从 Dockerfile 加载构建定义
 [internal] load build definition from Dockerfile                       0.1s
 => transferring dockerfile: 286B                                       0.0s
 [internal] load .dockerignore                                          0.1s
 => transferring context: 2B                                            0.0s
 [internal] load metadata for docker.io/library/alpine:3.2              0.4s
 # 构建缓存 - 构建新镜像时，从缓存读取前面的镜像层 - 耗费事件 0 s
 CACHED [1/2] FROM docker.io/library/alpine:3.2@sha256:e9a2035f9d0d7ce  0.0s
 CACHED [2/2] RUN apk add --no-cache socat                              0.0s
 exporting to image                                                     0.0s
 => exporting layers                                                    0.0s
 => writing image sha256:1affb80ca37018ac12067fa2af38cc5bcc2a8f09963de  0.0s
 => naming to docker.io/svendowideit/ambassador                         0.0s

默认情况，构建新的镜像都是基于缓存构建的(缓存指的是以前构建的镜像层)

-- cache-from 选项还允许您使用通过映像注册表(image registry)分发的构建缓存，该构建缓存引用了 docker build 命令引用中指定的外部缓存源部分。

完成构建后，就可以使用 docker scan 查看扫描图像，并将图像推送到 Docker Hub（pushing your image to docker hub ）。

(docker scan hello-world)

BuildKit

-- 构建工具包

Docker 18.09 版本以后，起一个新的后端(backend)执行所有由 moby/buildkit 项目提供的构建。

实验性，暂不考虑。。。。。。。

Format 格式

Dockerfile 格式：

# Comment
INSTRUCTION arguments

该指令大小写不敏感。但是，约定使用大写形式，以便更容易地与参数区分开。

Docker 按顺序在 Dockerfile 中运行指令。Dockerfile 必须以 FROM 指令开头。

This may be after parser directives(解析器指令), comments(注释), and globally scoped ARGs(用作 FROM 行的参数).

FROM 之前只能有一个或多个 ARG 指令，这些指令声明 Dockerfile 中 FROM 行中使用的参数。

Docker 将以 # 开头的行视为注释，除非该行是有效的解析器指令。一行中其他任何地方的 # 标记都被视为参数。这允许这样的陈述:

# Comment
RUN echo 'we are running some # of cool things'

RUN echo hello \
world

注释中不支持行继续 -- \

Parser directives 解析器指令

解析器指令是可选的，它影响 Dockerfile 中后续行的处理方式。解析器指令不向构建添加层，也不会显示为构建步骤。

解析器指令作为特殊类型的注释 以 # directive = value 的形式编写。单个指令只能使用一次。

处理完注释、空行或生成器指令后，Docker 不再查找解析器指令。相反，它将任何格式化为解析器指令的东西视为注释，如果它可能是解析器指令，则不尝试验证它。因此，所有解析器指令都必须位于 Dockerfile 的顶部。

💡：做完三个步骤后，即使遇到解析器指令格式，也会将其视作注释

各种无效指令例子

syntax 语法

# syntax=[remote image reference]

这个特性只有在使用 BuildKit 后端时才可用，而在使用经典的构建器后端时会被忽略。

Environment replacement

FROM busyboxENV FOO=/barWORKDIR ${FOO}   # WORKDIR /barADD . $FOO       # ADD . /barCOPY \$FOO /quux # COPY $FOO /quux

下面的 Dockerfile 中的指令列表支持环境变量:

  • ADD
  • COPY
  • ENV
  • EXPOSE
  • FROM
  • LABEL
  • STOPSIGNAL
  • USER
  • VOLUME
  • WORKDIR
  • ONBUILD (when combined with one of the supported instructions above) (当与上面支持的指令之一结合时)

环境变量替换将在整个指令中对每个变量使用相同的值。换句话说，在这个例子中:

ENV abc=helloENV abc=bye def=$abcENV ghi=$abc

将导致 def 的值是 hello，而不是 bye。然而，ghi 将有一个 bye 的值，因为它不是将 abc 设置为 bye 的同一个指令的一部分。

.dockerignore file 🔗

在 docker CLI 将上下文发送给 docker 守护进程之前，它会在上下文的根目录中查找一个名为 .dockerignore 文件。

如果此文件存在，CLI 将修改上下文以排除与其中模式匹配的文件和目录。

这有助于避免不必要地向守护进程发送大型或敏感的文件和目录，并可能使用 ADD 或 COPY 将它们添加到映像中。

这个 CLI (command-line) 将 .dockerignore 文件解释为 类似于 Unix shell 的 globs 文件的以行分隔的模式列表。

为了进行匹配，上下文的根目录被认为是工作目录和根目录。

例如： /foo/bar and foo/bar 排除来 PATH 的 foo 子目录中的一个名为 bar 的文件或目录

如果有一行。Dockerignore file 以第1列中的 # 开始，然后这一行被视为注释，在 CLI 解释之前被忽略。

例子：

# comment*/temp**/*/temp*temp?
Rule 规则 Behavior 行为
temp? 排除在根目录中 temp 一个字符扩展名的文件和目录，比如：tempa、tempb

匹配使用的是 Go 的 filepath.Match 规则，预处理步骤删除 leading and trailing whitespace and eliminates . and .. elements -- filepath.Clean

**/* 不是 Go 的匹配规则，规定 排除包括根目录在内的所有目录下的 .go 文件

！ 排除例外

*.md!README.md

效果：除 README.md 以外的所有文件都被排除在上下文之外。

! 的位置将影响这个行为(behavior)

*.md# 匹配规则 以 README开头，.md结果的文件 被排除!README*.mdREADME-secret.md

效果：除了 README*.md 文件，其他所有的 .md文件 + README-secret.md都将被排除 (exclude)

*.md# 无效README-secret.md# 此处匹配规则 匹配了上面这一行!README*.md

效果：所有的 README*.md 都将被包含在内，其他的 .md 文件被排除

甚至可以使用 .dockerignore 文件来排除 Dockerfile 和 .Dockerignore files 这些文件仍然被发送到守护进程，因为它需要这些文件来完成它的工作。但 ADD 和 COPY 指令不会将它们复制到镜像中。

FROM 🔗

FROM [--platform=<platform>] <image> [AS <name>]

Or

FROM [--platform=<platform>] <image>[:<tag>] [AS <name>]

Or

FROM [--platform=<platform>] <image>[@<digest>] [AS <name>]

FROM 指令初始化一个新的构建阶段，并为后续指令设置基本映像。因此，有效的 Dockerfile 必须以 FROM 指令开始。该镜像可以是任何有效的镜像——从公共存储库中提取镜像尤其容易。

  • ARG is the only instruction that may precede 是唯一的指示，可能先于FROM in the 在Dockerfile. see Understand how ARG and FROM interact

  • FROM可以在一个Dockerfile中多次出现，以创建多个映像或将一个构建阶段用作另一个构建阶段的依赖项。 在每个 FORM 指令之前，需要记录(make a note of)通过 commit 提交的最后一个镜像 ID 输出。FROM 指令清除由前面的指令创建的任何状态

  • 在 FROM 指令 增加 AS name ，命名新的镜像，这个名字可在之后的(subsequent) FROM 和 COPY --from=<name> instructions 中引用

  • tag and digest are optional. 忽略两者，默认指的是最新的镜像，若没找到该镜像返回 error

可选的 -- platform 标志可用于指定图像的平台，以防 FROM 引用多平台图像。例如，linux/amd64、 linux/arm64或 windows/amd64。

Understand how ARG and FROM interact(交互)

FROM 指令支持由第一个 FROM 之前的任何 ARG 指令声明的变量。

ARG  CODE_VERSION=latestFROM base:${CODE_VERSION}CMD  /code/run-appFROM extras:${CODE_VERSION}CMD  /code/run-extras

RUN

RUN 有两种形式：

  • RUN <command> (shell form, the command is run in a shell, which by default is /bin/sh -c on Linux or cmd /S /C on Windows)
  • RUN ["executable", "param1", "param2"] (exec form)

RUN 指令将在当前映像顶部的新层中执行任何命令并提交结果。生成的提交映像将用于 Dockerfile 中的下一步。

分层(layering) RUN 指令和生成提交符合(confirms to ) Docker 的核心概念(core concept)，其中提交很方便的，容器能从镜像历史的任何一点创建，就像源代码控制

The exec form 可以避免破坏 shell 字符串，并可以使用不包含指定 shell 可执行文件的基础镜像执行 RUN 命令。

In the shell form 可以使用(反斜杠)将单个 RUN 指令继续到下一行。例如，考虑这两行:

RUN /bin/bash -c 'source $HOME/.bashrc; \echo $HOME'

要使用不同的 shell (除了“/bin/sh”) ，可以使用 exec form 传递想要的(desired) shell。例如:

RUN ["/bin/bash", "-c", "echo hello"]

⚠️：

Exec form 被解析为(parsed as) JSON 数组，这意味着必须在单引号(‘)前后使用双引号(“)。

与 shell form 不同，exec form 不调用命令 shell。这意味着不会发生正常的 shell 处理。例如，RUN [“ echo”，“ $HOME”] 不会对 $HOME 进行变量替换。如果您想要 shell 处理，那么可以使用 shell form 或者直接执行 shell，例如: RUN [“ sh”,”-c”，“ echo $HOME”]。当使用 exec form 并直接执行 shell 时，就像 shell form 的例子一样，是 shell 在执行环境变量扩展，而不是 docker。

⚠️：

  • 在 JSON 格式中，有必要对反斜杠进行转义。这在 Windows 上尤其相关，因为反斜杠是路径分隔符。否则，下面的行将被视为 shell 表单，因为它不是有效的 JSON，并且以意外的方式失败:

    RUN ["c:\windows\system32\tasklist.exe"]

    The correct syntax for this example is:

    这个例子的正确语法是:

    RUN ["c:\\windows\\system32\\tasklist.exe"]

在下一次生成期间，RUN 指令的缓存不会自动失效。像 RUN apt-get dist-upgrade-y 这样的指令的缓存将在下一次构建期间重用。可以使用 -- no-cache 标志使 RUN 指令的缓存失效，例如 docker build -- no-cache。

CMD

CMD 指令有三种形式：

  • CMD ["executable","param1","param2"] (exec form, this is the preferred form)
  • CMD ["param1","param2"] (as default parameters to ENTRYPOINT)
  • CMD command param1 param2 (shell form)

一个 Dockerfile 中只能有一条 CMD 指令。如果您列出了多个 CMD，那么只有最后一个 CMD 才会生效。

CMD 的主要目的是为正在执行的容器提供缺省值。这些缺省值可以包括一个可执行文件，也可以省略可执行文件，在这种情况下，还必须指定 ENTRYPOINT 指令。

如果使用 CMD 为 ENTRYPOINT 指令提供默认参数，则应使用 JSON 数组格式指定 CMD 和 ENTRYPOINT 指令。

⚠️：

注意

The exec form is parsed as a JSON array, which means that you must use double-quotes (“) around words not single-quotes (‘).

Exec 表单被解析为 JSON 数组，这意味着必须在单引号(‘)前后使用双引号(“)。

在 shell 或 exec form 中使用时，CMD 指令设置运行映像时要执行的命令。

若使用 CMD 的 shell 形式，那么 将在 /bin/sh -c 中执行

FROM ubuntuCMD echo "This is a test." | wc -

如果您想在没有 shell 的情况下运行 < command > ，那么您必须将命令表示为 JSON 数组，并向可执行文件提供完整的路径。这种数组形式是 CMD 的首选格式。任何额外的参数都必须在数组中以字符串的形式单独表示:

FROM ubuntuCMD ["/usr/bin/wc","--help"]

如果希望容器每次都运行相同的可执行文件，那么应该考虑结合使用 ENTRYPOINT 和 CMD。参见 ENTRYPOINT。

如果用户指定参数 docker run，那么它们将覆盖 CMD 中指定的缺省值。

⚠️：

不要将 RUN 与 CMD 混淆。RUN 实际上运行一个命令并提交结果;

CMD 在构建时不执行任何内容，但是为映像指定预期的命令。

LABEL

LABEL <key>=<value> <key>=<value> <key>=<value> ...

LABEL 指令向映像添加元数据。LABEL 是键值对。若要在 LABEL 值中包含空格，请像在命令行解析中那样使用引号和反斜杠。一些用法例子:

LABEL "com.example.vendor"="ACME Incorporated"LABEL com.example.label-with-value="foo"LABEL version="1.0"LABEL description="This text illustrates \that label-values can span multiple lines."

一个镜像可以有多个标签

LABEL multi.label1="value1" multi.label2="value2" other="value3"

若要查看图像的标签，请使用 docker image inspect 命令。您可以使用 -- format 选项仅显示标签;

 docker image inspect --format='' myimage

EXPOSE

EXPOSE <port> [<port>/<protocol>...]

EXPOSE 指令通知 Docker 容器在运行时监听指定的网络端口。您可以指定端口是否侦听 TCP 或 UDP，如果没有指定协议，则默认为 TCP。

EXPOSE 指令实际上并不发布端口。它作为一种文档，介于构建映像的人和运行容器的人之间，关于打算发布哪些端口。要在运行容器时实际发布端口，可以使用 docker run 上的 -p 标志发布和映射一个或多个端口，或使用 -p 标志发布所有公开的端口并将它们映射到高阶端口。

默认情况下，EXPOSE 假设为 TCP。您也可以指定 UDP:

EXPOSE 80/udp

要在 TCP 和 UDP 上公开，包括两行：

EXPOSE 80/tcpEXPOSE 80/udp

记住，在这种情况下，如果对 docker 运行使用 -p，那么端口将对 TCP 公开一次，对 UDP 公开一次。请记住 -p 在主机上使用临时的高序主机端口，因此对于 TCP 和 UDP 端口不会相同。

不管 EXPOSE 设置如何，您都可以在运行时使用 -p 标志覆盖它们

 docker run -p 80:80/tcp -p 80:80/udp ...

若要在主机系统上设置端口重定向，请参见使用 -p 标志。Docker network 命令支持在容器之间创建通信网络，而不需要公开或发布特定的端口，因为连接到网络的容器可以通过任何端口彼此通信。有关详细信息，请参阅此特性的概述。

"9000:80" # 绑定容器的80端口到主机的9000

ENV

ENV <key>=<value> ...

例子：

ENV MY_NAME="John Doe"ENV MY_DOG=Rex\ The\ DogENV MY_CAT=fluffy

or

ENV MY_NAME="John Doe" MY_DOG=Rex\ The\ Dog \    MY_CAT=fluffy

当从结果映像运行容器时，使用 ENV 设置的环境变量将持久存在。您可以使用 docker inspect 查看这些值，并使用 docker run -- env < key > = < value > 更改它们。

环境变量的持续性会导致意想不到的副作用(side effects)。

For example, setting ENV DEBIAN_FRONTEND=noninteractive changes the behavior of apt-get(改变 apt-get 的行为), and may confuse users of your image.

如果在构建过程中只需要一个环境变量命令，在最后的镜像中不需要的话，可以考虑为单个命令设置一个值

RUN DEBIAN_FRONTEND=noninteractive apt-get update && apt-get install -y ...

或者使用 ARG，它不会持久化在最终的图片中：

ARG DEBIAN_FRONTEND=noninteractiveRUN apt-get update && apt-get install -y ...

💡：

上述两种写法：

DEBIAN_FRONTEND 变量都不会在镜像(images)中出现

替代语法：

# 可以省略 =，如：ENV MY_VAR my-value# 此语法不允许在单个 ENV 指令中设置多个环境变量，例如，下面设置一个值为“ TWO = THREE = world”的单个环境变量(ONE) :ENV ONE TWO= THREE=world# 有歧义

这种替代语法在向下兼容中得到了支持，但是由于上述原因不鼓励使用，并且可能会在以后的版本中被删除。

ADD

ADD 有两种形式:

ADD [--chown=<user>:<group>] <src>... <dest>ADD [--chown=<user>:<group>] ["<src>",... "<dest>"]

后一种形式是服务于包含空白的路径。

⚠️：

这个 --chown 特性只支持构建 Linux 容器的 Dockerfiles，不支持 Windows 容器。由于用户和组的所有权概念不能在 Linux 和 Windows 之间转换，因此使用/etc/passwd 和/etc/group 将用户和组名称转换为 id 限制了这一特性只适用于基于 Linux 的容器。

Add 命令从 路径复制 新的文件、目录或者远程文件 url，并将他们添加到位于 路径的镜像文件系统

可以指定多个 < src > 资源，但是如果它们是文件或目录，那么它们的路径将被解释为相对于构建上下文的源。

添加 hom 开头的所有文件

ADD hom* /mydir/

在下面的示例中，将? 替换为任何单个字符，例如“ home.txt”。

ADD hom?.txt /mydir/

< dest > 是一个绝对路径，或者相对于 WORKDIR 的路径，源文件将被复制到目标容器中。

下面的例子使用了一个相对路径，并将“ test.txt”添加到 < workdir >/relativeDir/:

ADD test.txt relativeDir/

当添加包含特殊字符(如[和])的文件或目录时，您需要转义遵循 Golang 规则的那些路径，以防止它们被视为匹配的模式。例如，添加名为 arr [0] .txt 文件，使用以下命令;

ADD arr[[]0].txt /mydir/

所有新的文件和目录都使用 UID 和 GID 为0创建，除非可选的 -- chown 标志指定给定的用户名、组名或 UID/GID 组合 来请求所添加内容的特定所有权。-- chown 标志的格式允许在任何组合中使用用户名和组名字符串或直接整数 UID 和 GID。提供不带组名或不带 GID 的 UID 的用户名将使用与 GID 相同的数字 UID。如果提供了用户名或组名，则将分别使用容器的根文件系统/etc/passwd 和/etc/group 文件执行从名称到整数 UID 或 GID 的转换。下面的示例显示了 -- chown 标志的有效定义:

ADD --chown=55:mygroup files* /somedir/ADD --chown=bin files* /somedir/ADD --chown=1 files* /somedir/ADD --chown=10:11 files* /somedir/

⚠️：

如果您通过 STDIN (docker build - < somefile)传递 Dockerfile 来构建，那么就没有构建上下文，因此 Dockerfile 只能包含基于 URL 的 ADD 指令。您还可以通过 STDIN 传递压缩的归档文件: (docker build - < archive.tar.gz) ，归档文件的根目录下的 Dockerfile 和归档文件的其余部分将用作构建的上下文。

如果您的 URL 文件使用身份验证来保护，那么您需要使用 RUN wget、 RUN curl 或者使用容器内的其他工具，因为 ADD 指令不支持身份验证。

ADD 遵守以下规则:

  • 路径必须位于构建的上下文中，不能 ADD ../something /something 因为 docker 构建的第一步是将上下文目录(和子目录)发送给 docker daemon。
    • 所以 docker daemon 只拥有 context 和 subdirectories ，没有 上下文目录上一级的内容
  • 如果 < src > 是一个 URL，而 < dest > 没有以斜杠结尾，那么文件将从 URL 下载并复制到 < dest > 。
  • 如果 < src > 是一个 URL，而 < dest > 确实以一个尾部斜杠结尾，那么文件名就会从 URL 中推断出来，文件就会被下载到 < dest >/< filename > 中。例如，ADD http://example.com/foobar /将创建文件/foobar。URL 必须有一个重要的路径，以便在这种情况下可以发现一个合适的文件名( http://example.com 文件不起作用)。
  • 如果 < src > 是一个目录，则复制该目录的全部内容，包括文件系统元数据。

⚠️：

不复制目录本身，只复制其内容。

COPY

ADD 命令是 COPY 命令的超集

注意事项：

ADD 是拷贝加 解压缩 + 解析

COPY 是只有拷贝

ENTRYPOINT

与 CMD 效果差不多

区别：

1. CMD - docker run 的参数会覆盖 CMD 指定的2. ENTRYPOINT - docker run 的参数会追加到 ENTRYPOINT 指定的参数

ENTRYPOING 有两种形式：

The exec form, which is the preferred form(首选的形式):

ENTRYPOINT ["executable", "param1", "param2"]

The shell form:

ENTRYPOINT command param1 param2

ENTRYPOINT 允许您配置 作为可执行文件运行的容器

例如，以下代码以 nginx 的默认内容开始，监听端口80:

 docker run -i -t --rm -p 80:80 nginx

docker run <image> 的命令行参数将会添加到 exec form ENTRYPOINT的所有元素之后，并将覆盖使用 CMD 指定的所有元素。这允许将参数传递到入口点，也就是说，docker run < image >-d 会将 -d 参数传递到入口点。您可以使用 docker run -- ENTRYPOINT 标志覆盖 ENTRYPOINT 指令。

Shell form 防止使用任何 CMD 或运行命令行参数，但缺点是 ENTRYPOINT 将作为 /bin/sh-c 的子命令启动，它不传递信号。这意味着可执行文件不会是容器的 PID 1-也不会接收 Unix 信号-所以你的可执行文件不会接收来自 docker stop < container > 的 SIGTERM。

只有 Dockerfile 中的最后一条 ENTRYPOINT 指令才会生效。

补充：

dockerfile为：

FROM centosCMD ["p in cmd"]ENTRYPOINT ["echo"]

如果run不带参数：

img

如果run带参数：

img

而且，确实entrypoint的中括号形式下，command是在shell环境下运行的，否则这里的echo是无法被执行的。

第二种是shell模式的。在这种模式下，任何run和cmd的参数都无法被传入到entrypoint里。官网推荐第一种用法。

FROM centosCMD ["p in cmd"]ENTRYPOINT echo
img

cmd的参数没有被打印。

VOLUME

💡：Dockerfile 方式创建 VOLUME ，对应的宿主机目录是自动创建

docker inspect containerID

​ -- 注意：Mounts 属性，可以找到

VOLUME ["/data"]

VOLUME 指令创建具有指定名称的挂载点，并将其标记为保存来自本机主机或其他容器的外部挂载的卷。这个值可以是 JSON 数组、 VOLUME [”/var/log/”] ，或具有多个参数的普通字符串，如 VOLUME /var/log 或 VOLUME /var/log/var/var/db。有关更多信息/示例和通过 Docker 客户端安装说明，请参阅通过卷文档共享目录。

docker run 命令使用 在基本镜像中指定的位置的所有数据初始化这新创建的卷。例如，考虑下面的 dockerfile 片段：

FROM ubuntuRUN mkdir /myvol# 覆盖写RUN echo "hello world" > /myvol/greetingVOLUME /myvol

EXAMPLE

build

FROM ubuntu:bionic-20210615.1 AS base
# install tools required
RUN su root && apt update
RUN apt install build-essential -y \
	&& apt install git -y && apt install vim -y && apt install wget -y && apt install cmake -y \
	&& apt install pkg-config -y && apt-get install libssl-dev -y\
	&& apt-get install libboost-system-dev libboost-thread-dev libboost-log-dev -y && apt install libexpat1-dev -y \
	&& apt-get install doxygen graphviz -y && apt install xsltproc -y

RUN mkdir /home/SomeIp && cd /home/SomeIp
# install cmake version >= 3.8
#RUN wget https://github.com/Kitware/CMake/releases/download/v3.21.0-rc2/cmake-3.21.0-rc2-linux-aarch64.tar.gz && tar -xf cmake-3.21.0-rc2-linux-aarch64.tar.gz -C . && cd cmake-3.21.0-rc2-linux-aarch64 && ln -sb /home/SomeIp/cmake-3.21.0-rc2-linux-aarch64/bin/cmake /usr/bin/cmake

# export RUNTIME_PATH=/home/SomeIp
ENV RUNTIME_PATH=/home/SomeIp
ENV PKG_CONFIG_PATH="/home/SomeIp/dbus-1.13.18"

# install vsomeip3
RUN git clone http://xxxx.git \
	&& apt install libboost-dev -y && cd vsomeip && mkdir build && cd build \
	&& cmake -DENABLE_SIGNAL_HANDLING=1 -DDIAGNOSIS_ADDRESS=0x10 .. && make && make install
# make install 
#
# install capicxx-core-runtime
RUN cd /home/SomeIp \
	&& git clone http://xxx.git \
	&& cd capicxx-core-runtime/ && mkdir build && cd build \
	&& cmake -D CMAKE_INSTALL_PREFIX=/usr/local .. && make && make install

# install capicxx-someip-runtime 
RUN cd /home/SomeIp \
	&& git clone http://xxx.git \
	&& cd capicxx-someip-runtime/ \
	&& mkdir build && cd build \
	&& cmake -DUSE_INSTALLED_COMMONAPI=OFF .. \
	&& make && make install
#make install

# install capicxx-dbus-runtime
RUN cd /home/SomeIp \
	&& git clone http://xxx.git \
	&& wget https://dbus.freedesktop.org/releases/dbus/dbus-1.13.18.tar.xz && tar -xf dbus-1.13.18.tar.xz -C . \
	&& cd dbus-1.13.18 && for i in ../capicxx-dbus-runtime/src/dbus-patches/*.patch; do patch -t -p1 < $i ; done \
	&& ./configure && make -C dbus && make -C dbus install && make install-pkgconfigDATA \
	&& cd /home/SomeIp/capicxx-dbus-runtime && mkdir build && cd build \
    && cmake -DUSE_INSTALLED_COMMONAPI=OFF -DUSE_INSTALLED_DBUS=OFF .. && make && make install

# install mqtt
RUN cd /home/SomeIp \
	&& git clone http://xxx.git && cd paho-mqtt-c \
	&& cmake -Bbuild -H. -DPAHO_ENABLE_TESTING=OFF -DPAHO_BUILD_STATIC=ON \
    -DPAHO_WITH_SSL=ON -DPAHO_HIGH_PERFORMANCE=ON \
    && cmake --build build/ --target install \
    && ldconfig \
    && cd /home/SomeIp \
    && git clone http://xxxx.git && cd paho-mqtt-cpp \
    && cmake -Bbuild -H. -DPAHO_BUILD_STATIC=ON \
    -DPAHO_BUILD_DOCUMENTATION=TRUE -DPAHO_BUILD_SAMPLES=TRUE \
    && cmake --build build/ --target install \
    && ldconfig

# install jsoncpp
RUN cd /home/SomeIp && git clone http://xxx.git \
	&& cd jsoncpp && mkdir build && cd build && cmake .. && make && make install

# install mqtt
#RUN cd /home/SomeIp
#	&& wget https://mosquitto.org/files/source/mosquitto-2.0.9.tar.gz && tar -xf mosquitto-2.0.9.tar.gz -C . && cd mosquitto-2.0.9 && mkdir build && cd build && cmake .. && make


# mkdir SOA_Client
RUN cd /home/SomeIp && mkdir SOA_Client && cd SOA_Client
# 谨记： COPY 是 moutn 的方式，即 SOA_Client 的内容就是 someIP 的内容
COPY ./someIP /home/SomeIp/SOA_Client

WORKDIR /home/SomeIp

ENTRYPOINT ["/bin/bash"]
posted @ 2021-08-17 20:34  zhixlin  阅读(331)  评论(0)  编辑  收藏  举报