Docker使用心得

1.tag使用

慎重latest

在正式环境中应该避免使用latest标签的Docker镜像版本。原因在于latest标签代表镜像的最新版本，而这个版本是不断变化的。因此，在线上应用中使用latest标签可能导致以下问题：

• 环境不稳定性：由于latest标签的基础镜像可能随时更新，线上应用在不同时间构建时可能依赖不同的环境，可能引入未知的问题和不稳定性。
• 版本控制困难：使用latest标签使得难以追踪应用程序依赖的确切环境版本。在调试和排查问题时，确定使用的确切镜像版本非常重要。

版本控制困难：使用latest标签或不指定具体版本的镜像，应用程序在构建时会使用最新的镜像版本。这样一来，开发者和运维团队难以追踪应用程序确切依赖的环境版本。因为在应用程序的不同构建或部署阶段，可能使用了不同版本的基础镜像，而这些版本之间可能存在差异。

调试和排查问题时的重要性：在应用程序出现问题、需要调试或排查 bug 时，了解确切的镜像版本非常关键。不同版本的基础镜像可能包含不同的库、依赖项或配置，这些差异可能导致应用程序在不同环境下的行为不一致。确定确切的镜像版本可以帮助开发者在相同的环境中重现问题，更容易定位和解决 bug。

• 安全性风险：如果基础镜像的新版本包含安全漏洞修复，应用程序可能会受到威胁，而无法准确追踪到使用的镜像版本可能导致安全问题。

新版本的基础镜像可能包含安全漏洞修复：软件厂商经常发布新的版本来修复已知的安全漏洞。当基础镜像发布了新版本，这个版本可能包含了先前版本中存在的安全漏洞的修复。这些漏洞修复是为了提高系统的安全性。

无法准确追踪使用的镜像版本：使用latest标签或不明确指定版本号的镜像，可能导致无法确定当前应用程序所依赖的确切镜像版本。如果发现应用程序受到威胁，无法准确追踪使用的镜像版本会使得难以确认是否受到了已知漏洞的影响。

综合来看，如果基础镜像的新版本包含了安全漏洞修复，但应用程序没有及时升级到修复了漏洞的镜像版本，那么应用程序就可能受到威胁。为了确保系统的安全性，推荐在构建镜像时明确指定所使用的镜像版本，并且定期更新到包含最新安全修复的镜像版本。

为了避免这些问题，推荐在正式环境中使用具体的版本号或者带有特定标签的镜像，以确保每次构建使用的都是相同的环境。这样可以提高应用程序的稳定性、可维护性，同时确保版本控制和安全性。

tag指定具体版本

主版本号（X）：主版本号通常在软件整体重写或出现不向后兼容的重大改变时增加。当主版本号增加时，通常意味着软件发生了重大变化，可能包括不兼容的 API 变动、架构重构等。X为0时，表示软件还在开发阶段。

次版本号（Y）：次版本号在一般的系统 release 中增加。当次版本号增加时，表示软件经历了一些功能性的增强或改进，但这些改变是向后兼容的，不会破坏现有的 API。

修订号（Z）：修订号主要用于修复 bug 和进行小的改进。修订号的增加表示发布了针对已知问题的修复，以及可能包含了小的性能改进或其他调整。

在使用镜像标签时，应该尽量指定到具体的修订号（Z版本）。因为指定到具体的修订号可以确保使用的镜像版本是一个已经经过测试和验证的稳定版本。指定到修订号可以增加镜像的稳定性和可预测性，避免了不必要的不稳定因素，确保应用程序在不同环境中的一致性。

2.安全性实践

base 镜像最小原则

使用的基础镜像可能存在安全问题。类比程序员开发中的情况，就像代码写得越多，可能存在的bug就越多一样。同样，基础镜像的体积越大，就越容易暴露安全问题。

为了应对这个问题，可以考虑在基础镜像中只安装应用程序运行所必需的依赖。这种做法有几个优势：

• 减小潜在攻击面：减少镜像中不必要的组件和依赖，可以减小潜在的攻击面，降低被攻击的风险。不使用或不需要的组件不应该包含在镜像中。
• 降低安全漏洞风险：较小的基础镜像通常有更少的预装软件，因此减少了可能存在的安全漏洞。精简的镜像意味着减少了被黑客利用的机会。
• 提高镜像构建速度：由于安装较少的依赖，构建镜像的速度可能会更快，这在持续集成和持续部署中非常重要。

综上所述，避免使用过大的基础镜像，并且只安装应用程序运行所需的必要依赖，是一种有效的Docker安全实践，可以降低潜在的安全风险。

最小用户权限原则

如果在Dockerfile中没有指定USER，Docker容器默认以root用户权限启动。这意味着在容器内部的进程以root权限运行，同时映射到宿主机上的也是root权限，这可能带来潜在的安全隐患。

使用root权限运行应用程序可能会导致容器内部的进程拥有系统级别的权限，这样一旦应用程序受到攻击，攻击者可能获得对宿主机系统的控制权，造成严重的安全问题。

为了解决这个问题，推荐的做法是在Dockerfile中指定一个特定的用户。可以先在Dockerfile中添加用户，然后使用USER指令显式地指定容器内部进程以哪个用户身份运行。这样，应用程序将以非root用户权限运行，减小了潜在的攻击面，提高了容器的安全性。

通过明确指定用户权限，可以限制容器内部进程的权限，减少了攻击者利用潜在漏洞获得系统权限的机会，从而提高了Docker容器的安全性。

如下，创建了一个基于Ubuntu镜像的Docker容器，并配置了一个非特权用户（lirantal）来运行应用程序。

FROM ubuntu
RUN mkdir /app
RUN groupadd -r lirantal && useradd -r -s /bin/false -g lirantal lirantal
WORKDIR /app
COPY . /app
RUN chown -R lirantal:lirantal /app
USER lirantal
CMD node index.js

FROM ubuntu：指定基础镜像为Ubuntu。

RUN mkdir /app：在容器中创建一个名为/app的目录。

RUN groupadd -r lirantal && useradd -r -s /bin/false -g lirantal lirantal：创建一个没有密码、没有home目录、没有shell的系统用户lirantal。-r标志表示创建系统用户，-s /bin/false标志表示该用户没有登录shell，-g lirantal表示将用户加入到名为lirantal的用户组中。

WORKDIR /app：设置当前工作目录为/app，后续的命令将在这个目录下执行。

COPY . /app：将主机上的当前目录中的所有文件和文件夹复制到容器的/app目录中。

RUN chown -R lirantal:lirantal /app：修改/app目录及其下所有文件的所有者和所属组为lirantal。

USER lirantal：指定容器启动时的用户为lirantal，即应用程序将以lirantal用户权限运行。

USER lirantal是Dockerfile中的一条指令，用于指定容器启动时所使用的用户。在这个例子中，lirantal是一个在Docker镜像中事先创建好的用户。

应用程序将以lirantal用户权限运行：一旦容器启动，并且进入到USER lirantal指令所定义的阶段，所有在这之后的命令和应用程序将以lirantal用户的权限来运行。这意味着，容器内的所有操作、文件读写等都将受限于lirantal用户的权限。这种做法有助于限制应用程序的权限，提高容器的安全性。

总之，通过USER指令，我们可以为Docker容器内的应用程序指定一个特定的用户，避免使用root用户权限，降低潜在的安全风险，提高容器的安全性。

CMD node index.js：在容器启动时运行node index.js命令，启动应用程序。

这个Dockerfile中的操作创建了一个没有特权的用户，并将应用程序运行在这个用户的权限下，提高了容器的安全性，避免了使用root用户权限引发的潜在安全问题。

docker secrect的使用

在Docker中，secret是一个相对较新的功能，用于处理敏感数据，比如数据库密码、API密钥等敏感信息。它的目的是为了提供一种安全的方式，将敏感数据传递给应用程序，而不会将这些数据暴露在镜像或环境变量中，从而提高容器化应用的安全性

以下是关于Docker secret的一些重要特性和用法：

• 安全性：使用secret可以确保敏感数据在Docker的整个生命周期中都得到保护。这些数据在内存中以密文形式存在，只有授权的容器可以访问它们。
• 用法：secret可以被挂载到容器中，应用程序可以在指定的路径下读取它们。在容器内，secret以文件的形式存在，应用程序可以像读取普通文件一样读取其中的敏感数据。
• 创建和管理：可以使用Docker CLI或Docker Compose来创建和管理secret。通过docker secret create命令，可以从文件或标准输入中创建secret。而在Docker Compose文件中，可以使用secrets字段来定义secret。
• 容器中的路径：在容器内，secret以文件的形式存在于/run/secrets/目录下。应用程序可以在该目录下找到并读取相应的secret文件。
• 多服务共享：一个secret可以被多个服务共享，确保各个服务都可以访问相同的敏感数据，而无需将这些数据暴露在环境变量中。

通过使用secret，Docker提供了一种安全且方便的方式，让开发者可以更好地管理和保护容器化应用中的敏感数据，提高了应用程序的安全性和可维护性。

# syntax = docker/dockerfile:1.0-experimental
FROM alpine

# shows secret from default secret location
RUN --mount=type=secret,id=mysecret cat /run/secrets/mysecre

# shows secret from custom secret location
RUN --mount=type=secret,id=mysecret,dst=/foobar cat /foobar

syntax = docker/dockerfile:1.0-experimental：这是使用Docker BuildKit的语法声明。1.0-experimental指定了Docker BuildKit的版本，允许使用实验性的特性，例如secret的支持。

FROM alpine：指定了基础镜像为Alpine Linux。

RUN --mount=type=secret,id=mysecret cat /run/secrets/mysecret：--mount=type=secret,id=mysecret：这部分指令告诉Docker在构建时使用类型为secret的挂载，使用ID为mysecret的secret。

cat /run/secrets/mysecret：在容器中运行cat命令，将mysecret文件的内容输出。mysecret是一个secret，它从默认的secret位置/run/secrets/中读取。这个命令演示了如何从默认的secret位置读取敏感数据。

RUN --mount=type=secret,id=mysecret,dst=/foobar cat /foobar：

--mount=type=secret,id=mysecret,dst=/foobar：这部分指令指定了secret的自定义挂载路径，将mysecret挂载到容器内的/foobar路径。

cat /foobar：在容器中运行cat命令，将/foobar路径下的文件内容输出。这个命令演示了如何将secret挂载到自定义的路径，并从该路径中读取敏感数据。

总的来说，这段Dockerfile代码展示了如何在构建时使用Docker BuildKit的--mount选项，通过两个RUN指令演示了如何从secret中读取敏感数据，并且展示了默认和自定义的secret挂载路径。