linuxea:如何单单修改docker容器的系统时间 一般情况下，我们仅仅需要修改容器的时间与我们宿主机的实际实际一致即可，我们知道，默认情况下docker容器是不允许访问系统时钟，但是有一款开源的软件使这样的需求变成了可能。此lib拦截用于检索当前时间和日期的所有系统调用，完成了容器内时间的修改。阅读此篇文章，你将了解在容器内修改时间的方法。使用以alpine为例，我们进行编译安装，并挑选几个简单的使用方法来进行演示这个时间调整git clone https://github.com/wolfcw/libfaketime.git cd libfaketime/src make install他的使用非常简单，只需要设置环境变量即可，如下bash-4.4$ date Fri Mar 8 15:17:52 CST 2019修改天数bash-4.4$ LD_PRELOAD=/usr/local/lib/faketime/libfaketime.so.1 FAKETIME="-2d"bash-4.4$ date Wed Mar 6 15:28:03 CST 2019修改分钟bash-4.4$ LD_PRELOAD=/usr/local/lib/faketime/libfaketime.so.1 FAKETIME="-70m"bash-4.4$ date Fri Mar 8 14:18:45 CST 2019虚拟时间的默认规范是缓存的，时间为10秒钟FAKETIME_NO_CACHE =1是禁用缓存，但这可能带来性能影响嵌入docker基础镜像中使用此前的基础镜像。在启动脚本中添加TIME_OFFSET变量，顺便修改启动容器进程的id和用户名#!/bin/bash ######################################################################### # File Name: entrypoint.sh # Author: www.linuxea.com # Created Time: Tue 05 Mar 2019 03:59:05 PM CST ######################################################################### USER_ID=${USER_ID:-1101} USER_NAME=${USER_NAME:-www} TIME_OFFSET=${TIME_OFFSET:-FAKETIME_NO_CACHE=1 FAKETIME=""} echo "Starting with UID : $USER_ID And user $USER_NAME" addgroup --gid $USER_ID $USER_NAME adduser -u $USER_ID -S -H -s /bin/bash -g $USER_NAME -G $USER_NAME $USER_NAME -D # useradd --shell /bin/bash -u $USER_ID -o -c "" -m user export HOME=/home/$USER_NAME export LD_PRELOAD=/usr/local/lib/faketime/libfaketime.so.1 $TIME_OFFSET exec /usr/local/bin/gosu $USER_NAME "$@"这样以来，在下次启动的时候，传递环境变量就达到了修改容器时间的办法我将次镜像构建为marksugar/alpine:3.9-time-gosu，你可以下载进行使用[root@linuxea.com /opt/2019/djd/jj]# docker build -t marksugar/alpine:3.9-time-gosu .现在我们进行测试这个时间修改挂载/etc/localtime让容器时间与机器时间一致，而后在进行传递$TIME_OFFSET修改时间的偏移量docker run \ --rm \ -v /etc/localtime:/etc/localtime \ -e TIME_OFFSET=FAKETIME="-10m" \ -e USER_ID=1101 \ -e USER_NAME=linuxea.com \ -it marksugar/alpine:3.9-time-gosu \ date +%F" "%T我们先取出时间[root@linuxea.com ~]# date +%F" "%T 2019-03-08 15:54:11而后修改分钟，减去10分钟，-10m[root@linuxea.com ~]# docker run \ > --rm \ > -v /etc/localtime:/etc/localtime \ > -e TIME_OFFSET=FAKETIME="-10m" \ > -e USER_ID=1101 \ > -e USER_NAME=linuxea.com \ > -it marksugar/alpine:3.9-time-gosu \ > date +%F" "%T Starting with UID : 1101 And user linuxea.com 2019-03-08 15:44:16时间从2019-03-08 15:54:11变成2019-03-08 15:44:16修改天数，减去3天，-3d[root@linuxea.com ~]# docker run \ > --rm \ > -v /etc/localtime:/etc/localtime \ > -e TIME_OFFSET=FAKETIME="-3d" \ > -e USER_ID=1101 \ > -e USER_NAME=linuxea.com \ > -it marksugar/alpine:3.9-time-gosu \ > date +%F" "%T Starting with UID : 1101 And user linuxea.com 2019-03-05 15:57:43或者这样docker run \ --rm \ -v /etc/localtime:/etc/localtime \ -e TIME_OFFSET=FAKETIME="-10m" \ -e USER_ID=1101 \ -e USER_NAME=linuxea.com \ -it marksugar/alpine:3.9-time-gosu \ date +%F" "%TFAKETIME_NO_CACHE=1[root@DT_Node-172_17_0_1 ~]# date +%F" "%T 2019-03-08 16:03:18[root@DT_Node-172_17_0_1 ~]# docker run \ > --rm \ > -v /etc/localtime:/etc/localtime \ > -e TIME_OFFSET="FAKETIME_NO_CACHE=1 FAKETIME="-10m"" \ > -e USER_ID=1101 \ > -e USER_NAME=linuxea.com \ > -it marksugar/alpine:3.9-time-gosu \ > date +%F" "%T Starting with UID : 1101 And user linuxea.com 2019-03-08 15:53:18更多阅读linuxea:docker卷和文件系统权限linuxea:docker容器中程序不应该以root用户身份运行linuxea:变量实值与文件变量替换学习更多学习如何使用Docker CLI命令，Dockerfile命令，使用这些命令可以帮助你更有效地使用Docker应用程序。查看Docker文档和我的其他帖子以了解更多信息。docker目录白话容器docker-compose

linuxea:Docker多阶段构建与- target和--cache-from 在这篇文章中，我描述了在无法提供任何层缓存的无服务器主机上构建时，我如何提高容器的构建性能。我使用多阶段构建和远程存储库缓存的组合来避免重复性工作来提高性能。阅读本篇，你将了解--target的使用和--cache-from的使用，更好理解多阶段构建和缓存的利用。我将会在文章末尾放置多阶段构建使用的本站链接note使用--target来构建多级建立的特定阶段，并推动这些镜像传输到远程存储库。在后续构建中，拉出这些镜像并使用作为构建缓存--cache-from我们先来看，一个普通的构建脚本## 镜像版本号 DOCKER_IMAGE_VERSION=20190305_addpjp ## 构建镜像 docker build \ -t marksugar/test:$DOCKER_IMAGE_VERSION \ -t marksugar/test:latest \ -f "./Dockerfile" \ "." ## 推送到仓库 docker push marksugar/test:$DOCKER_IMAGE_VERSION docker push marksugar/test:latest 此bash脚本基于Dockerfile构建docker镜像，使用特定的版本号$DOCKER_IMAGE_VERSION和latest标记镜像tag，而后推送到仓库中，完成构建过程。事实上我们在实际生产中的构建脚本远比这要复杂的多。为此，学习利用--target和--cache-from能提高时间效益--target创建多阶段构建时候，可以为每个构建阶段提供名称，例如，我此刻命名的createfile和linuxea，分别在(准备阶段createfile和最终阶段linuxea)：FROM marksugar/alpine:3.9-time-gosu as createfile MAINTAINER www.linuxea.com LABEL maintainer="www.linuxea.com" RUN mkdir /data/ && touch /hello.txt WORKDIR /data FROM marksugar/go:alpine-go1.12 as linuxea MAINTAINER www.linuxea.com LABEL maintainer="www.linuxea.com" COPY linuxea.go /data/linuxea.go WORKDIR /data CMD ["go","run","linuxea.go"] COPY --from=createfile /data/ .通过阶段的名称，可以在后续中引用，并且复制到最后的容器中。为了更好的解释这个，我们还是进行一次构建docker build -t test:1 .并运行[root@linuxea.com /opt/2019/djd/go/go2]# docker run -d -p:1818:8080 test:1 01e07ddc26daf94bc57ddc7d61d5cbe0f530c85792e045126dc501e67e047ac8运行正常，可以被访问[root@linuxea.com /opt/2019/djd/go/go2]# curl 127.0.0.1:8080 20190303 欢迎来到 www.linuxea.com但是，这仅仅只是多阶段构建。此刻，我只想构建其中一个阶段，--target就派上用途了。只构建某个阶段，如linuxea或者createfile，并不全部构建只构建linux的阶段[root@linuxea.com /opt/2019/djd/go/go2]# docker build --target linuxea -t test:linuxea -f "$PWD/Dockerfile" "." [root@linuxea.com /opt/2019/djd/go/go2]# docker run --rm -it test:1 bash Starting with UID : 1101 And user www bash-4.4$ ls linuxea.go bash-4.4$ 只构建createfile阶段[root@linuxea.com /opt/2019/djd/go/go2]# docker build --target createfile -t test:2 -f "$PWD/Dockerfile" "." [root@linuxea.com /opt/2019/djd/go/go2]# docker run --rm -it test:2 bash Starting with UID : 1101 And user www bash-4.4$ pwd /data bash-4.4$ ls /hello.txt /hello.txt如上所示中，两个阶段的构建结果仅限于Dockerfile中的多阶段构建的名称下的内容。我们在往下看。--cache-from默认情况下，在构建Docker镜像时，Docker使用它的构建缓存来检查它是否可以跳过Dockerfile中的任何步骤。该--cache-from参数告诉docker，可用缓存的镜像是什么。如果提供的镜像和当前版本具有相同的图层，则可以获得与在同一台计算机上构建镜像时以相同层构建出更快的速度。例如，简单地想象我们没有使用多阶段构建，因此推送到远程存储库的最终镜像包含所有构建层。不使用--cache-from我们的构建脚本总是必须执行Dockerfile中的每个命令，因为构建缓存将为空：docker build -t marksugar/test:01相反，我们可以--cache-from结合使用docker pull，大概如下：docker pull IMAGES1 || true docker build \ --cache-from IMAGES1 \ -t IMAGE2:Version \ -t IMAGE2:latest \ -f "PATH/Dockefile" \ "." docker push IMAGES2:latest docker push IMAGES2:Version为了更好的测试，我们手动进行build两个镜像做一个简单的测试第一个DockerfileFROM marksugar/alpine:3.9-time-gosu as createfile MAINTAINER www.linuxea.com LABEL maintainer="www.linuxea.com" RUN apk add nginx php RUN mkdir -p /data/wwwroot WORKDIR /data/wwwrootdocker build marksugar/test:01第二个Dockerfile在第二个dockerfile中，我们主要看两层，如下：RUN apk add nginx php RUN mkdir -p /data/wwwrootDockerfile。在dockerfile中的这两层与上一个dockerfile的层是相同的FROM marksugar/alpine:3.9-time-gosu MAINTAINER www.linuxea.com LABEL maintainer="www.linuxea.com" RUN apk add nginx php RUN mkdir -p /data/wwwroot RUN echo '\n\ server {\n\ listen 1080;\n \ root /data/wwwroot;\n \ index index.html;\n \ }\n'\ >> /etc/nginx/conf.d/default.conf \ && echo "hello www.linuxea.com" >> /data/wwwroot/index.html WORKDIR /data/wwwroot CMD ["nginx","-g","'daemon off;'"]builddocker build \ --cache-from marksugar/test:01 \ -t marksugar/test:02 \ -f "$PWD/Dockerfile" \ "."如下：[root@linuxea.com /opt/2019/djd/go/go3]# docker build --cache-from marksugar/test:01 -t marksugar/test:02 -f "$PWD/Dockerfile" "." Sending build context to Docker daemon 2.048kB Step 1/8 : FROM marksugar/alpine:3.9-time-gosu ---> 69cd7c6d7a86 Step 2/8 : MAINTAINER www.linuxea.com ---> Using cache ---> 45e40729aaae Step 3/8 : LABEL maintainer="www.linuxea.com" ---> Using cache ---> 5f10b4ec6e3e Step 4/8 : RUN apk add nginx php ---> Using cache ---> 0fd71721e8ff Step 5/8 : RUN mkdir -p /data/wwwroot ---> Using cache ---> 07066ac12068 Step 6/8 : RUN echo '\nserver {\n listen 1080;\n root /data/wwwroot;\n index index.html;\n }\n'>> /etc/nginx/conf.d/default.conf && echo "hello www.linuxea.com" >> /data/wwwroot/index.html ---> Running in 1aaa3449af16 Removing intermediate container 1aaa3449af16 ---> 434c3dee5d37 Step 7/8 : WORKDIR /data/wwwroot ---> Running in 2ed3ce787ab0 Removing intermediate container 2ed3ce787ab0 ---> 078644925acb Step 8/8 : CMD ["nginx","-g","'daemon off;'"] ---> Running in 065aa5b66fe8 Removing intermediate container 065aa5b66fe8 ---> 81adb261a754 Successfully built 81adb261a754 Successfully tagged marksugar/test:02我们在来对比一下层，你会发现这俩个镜像对于上述相同的RUN命令层，公用一个ID，这将减少我们的构建时间如果你的最终构建的镜像包含所有的docker构建层，这个简单的方法很有效。但在多阶段中可能会出现问题，我们可以使用--target和--cache-from一起使用--target And --cache-from倘若此时，在多构建的基础之上，我们需要重新构建准备阶段和最终的运行阶段我们可能使用这种方式，如下：DOCKER_IMAGE_VERSION=VERSION # 拉取最新的镜像 docker pull marksugar/base:1 || true # 使用最新拉取的镜像作为缓存层 docker build \ --target builder \ --cache-from marksugar/base:1 \ -t marksugar/base:1 \ -f "path/Dockerfile" \ "." # 在拉一个最终的镜像 docker pull marksugar/web:latest || true # 不指定target（构建整个Dockerfile） ＃ 使用刚构建的构建器镜像和拉出的运行时候镜像作为缓存 docker build \ --cache-from marksugar/base:1 \ --cache-from marksuagr/Web:latest \ -t marksugar/web:$DOCKER_IMAGE_VERSION \ -t marksugar/Web:latest \ -f "path/Dockerfile" \ "." # 重新推送 docker push marksugar/Web:$DOCKER_IMAGE_VERSION docker push marskugar/Web:latest docker push marksugar/base:1延伸阅读linuxea:Distroless与多阶段构建linuxea:docker多阶段构建Multi-Stage与Builder对比总结学习更多学习如何使用Docker CLI命令，Dockerfile命令，使用这些命令可以帮助你更有效地使用Docker应用程序。查看Docker文档和我的其他帖子以了解更多信息。docker目录白话容器docker-compose

linuxea:尽可能不在docker镜像中嵌入配置或者密码 切勿将配置或机密信息嵌入Docker镜像中。相反，在构建Docker镜像时，期望使用业务流程运行时将配置和机密的信息提供给容器，这些包含：Kubernetes Secrets，Docker Secrets。而外部工具或环境变量（对于非敏感性）用于非敏感数据。但仍需注意，不要无意中在镜像层的隐藏层中包含机密信息。概述容器镜像应该是可重用且安全的。当镜像层包含嵌入式配置或机密信息时，它违反了此规则，并且不可重用或不安全。这些值不属于镜像，它们仅属于正在运行的容器中。当凭据保留在Docker镜像中时，可能会出现未知的安全隐患。在生产中运行Docker容器应该是具有各种配置和密码信息的镜像的组合。如果你在Docker，Kubernetes，Swarm或其他业务流程层中运行此容器并不重要，编排平台应负责通过将这些部件组装到正在运行的容器中来创建容器。如我上述所提到的，secrets，configmap等。Docker镜像的类型Component imageDocker镜像通常是可重用的组件，可与不同的基础架构共享，并可在各种环境中运行。这种类型的image的一个例子是Postgres，Redis或NSQ。这些组件通常需要一些凭证来引导。凭证应由容器提供，而不是内置于镜像中。官方MySQL镜像就是一个很好的例子。如果你运行MySQL Docker镜像而不为某些配置提供初始值，则容器将退出：[root@linuxea.com ~]# docker run mysql error: database is uninitialized and password option is not specified You need to specify one of MYSQL_ROOT_PASSWORD, MYSQL_ALLOW_EMPTY_PASSWORD and MYSQL_RANDOM_ROOT_PASSWORDMySQL镜像可以很好地显示缺少的值并给出建议，查看docker-entrpoint.sh脚本。再试一次，键入密码：MYSQL_ROOT_PASSWORD=www.linuxea.com[root@linuxea.com ~]# docker run -e MYSQL_ROOT_PASSWORD=www.linuxea.com mysql Initializing database 2019-03-04T07:53:38.390516Z 0 [Warning] [MY-011070] [Server] 'Disabling symbolic links ...... Warning: Unable to load '/usr/share/zoneinfo/zone1970.tab' as time zone. Skipping it. 2019-03-04T07:54:19.457699Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.15) MySQL Community Server - GPL. MySQL init process done. Ready for start up. 2019-03-04T07:54:19.847135Z 0 [Warning] [MY-011070] [Server] 'Disabling symbolic links using --skip-symbolic-links (or equivalent) is the default. Consider not using this option as it' is deprecated and will be removed in a future release. .... 2019-03-04T07:54:20.734608Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.0.15' socket: '/var/run/mysqld/mysqld.sock' port: 3306 MySQL Community Server - GPL. 2019-03-04T07:54:20.756534Z 0 [System] [MY-011323] [Server] X Plugin ready for connections. Socket: '/var/run/mysqld/mysqlx.sock' bind-address: '0.0.0.0' port: 33060这一次，提供了一些配置选项，它可以工作。MySQL镜像是可重用且安全的，因为它可以配置为在大多数环境中工作，并且没有嵌入到镜像中的密码。Application image镜像可以包含应用程序。应用程序镜像的示例是静态站点或API。这些镜像旨在为用户而非其他组件提供请求。通常，这些应用程序镜像需要认证，例如API密钥或数据库凭证，或者这些需要特定于环境的数据，例如要连接的其他端点。除了dev模式默认值之外，在镜像本身中存储这些认证是一种不好的做法，应该避免使用。认证信息应始终由容器提供，而不是内置于镜像中。如：ELK的前段是Kibana，Kibana容器需要一些配置， 至少它必须能够找到要连接的Elasticsearch服务器。elastic.co团队认为默认链接端口9200上名为elasticsearch的主机，并理所当然的为此配置了默认密码，因为这在docker-compose（dev）环境中运行良好。但希望没有人使用用户名“elastic”和密码“changeme”在生产中运行Elasticsearch集群！隐藏层最后，重要的是不要在镜像的隐藏层中包含机密的信息。如果Dockerfile配置不正确，则在创建镜像时可能会发生这种情况。当删除Dockerfile中的内容时（秘密，文件，源代码，等），并不总是意味着这个密码没有被包含在最终图像中。它可能存在于父层中，但仍可访问。当用户运行docker pull命令时，将传递所有基础层。FROM marksugar:nginx RUN git clone http://USERNAME:PASSWORD@git.linuxea.com -o /usr/local/www WORKDIR /usr/local/www RUN go build -o /data/wwwroot/ RUN rm -rf /usr/local/www ENTRYPOINT [/data/wwwroot]这个Dockerfile的开发人员希望在Docker构建过程中创建一个特殊的构建环境。在构建时，需要将源代码添加到image中，构建二进制文件然后删除源代码。问题是Dockerfile中的每一行都会生成一个新层，每当拉出最终镜像时候时都会pull该层。创建此Dockerfile的过程也会将源代码泄漏给任何提取此镜像的人。为什么这些很重要？Docker镜像应该功能齐全，一致，可重用（可共享和可发现），小巧，安全，可在企业环境中工作并可调试可重复使用应用程序可移植性是部署容器的最大好处之一。当应用程序组件可移植时，可以更轻松地跨各种云提供程序和环境部署不可变基础结构。具有内置配置和包含机密的信息的容器不可移植，它们可能需要为每个环境提供不同的镜像。安全嵌入密码的镜像不安全。任何有权访问镜像的人都可以拉动和查看密码信息，即使它们处于不可见面图层中。这是未经审计的密码信息查看方式，应该避免。企业兼容一个好的的容器镜像包含运行组件时的所有最佳实践。从容器镜像中删除配置将允许企业用户从容器中包含的最佳实践中受益，并且仍然与其审计和安全策略及其工作流程兼容。内置配置将要求企业使用创建私有镜像并失去原始镜像中已有的最佳实践的大部分好处。可调试具有嵌入式配置的镜像调试起来要困难得多。如果镜像具有嵌入式配置，则通过简单docker run命令从镜像启动可调试容器通常更加困难。建议有许多方法可以在运行时为容器提供机密的信息和配置：环境变量配置文件etcd或其他配置管理服务Docker的secrets个config(依赖于swarm)外部secret管理解决方案即使构建的image仅在内部使用且仅在单个服务器上使用，也应该使用一种更好的方式创建镜像。切勿在镜像中提供默认的硬密码，也不要添加其他的机密信息，而是在运行容器时为它们提供。而这些方式参考以上5种，而最常见的是环境变量和配置文件。更多阅读有关如何将密码信息传递到容器的更多信息的一些建议是：linuxea:docker config配置使用linuxea:变量实值与文件变量替换linuxea:compose中的变量传递与docker-createrepo构建linuxea:kubernetes secret简单用法(25)linuxea:kubernetes 介绍ConfigMap与Secret(23)学习更多学习如何使用Docker CLI命令，Dockerfile命令，使用这些命令可以帮助你更有效地使用Docker应用程序。查看Docker文档和我的其他帖子以了解更多信息。docker目录白话容器docker-compose

linuxea:docker config的配置使用 使用Docker Config而不是使用嵌入式配置创建镜像怎么样？在镜像中嵌入配置？我们经常看到Dockerfile如下所示，其中创建新镜像只是为了将配置添加到基本镜像。$ cat Dockerfile FROM marksugar：redis:5.0.0 RUN curl http:/xx/x/xredis.conf -o /etc/redis/redis.conf在上述中，是将最新的redis.conf文件放到/etc/redis/redis.conf中除此之外，我们还可以使用变量替换的方式进行处理。变量替换意味着需要设计模板和参数，如果参数过多，配置和替换起来将会耗费更多的时间，也较为复杂，并不是最好最安全的方式。当然，我们可以直接挂载文件到容器中，那并不优雅，但的确能解决一部分问题。如果需要频繁的修改文件，且变量替换也无法满足，也不想挂载文件，那现在就可以参考本节的docker config。阅读本章，你将了解docker config的简单使用和docker swarm的简单使用。使用场景有一个配置redis.conf的配置文件在容器内，现在我将容器内的配置文件修改后重新附加到容器内。我修改了密码字段：masterauth "OTdmOWI4ZTM4NTY1M2M4OTZh.com" requirepass "OTdmOWI4ZTM4NTY1M2M4OTZh.com"config创建现在，使用Docker CLI，我们可以从此配置文件创建配置redis.conf（redis.conf文件此前准备好的配置），我们将此配置命名为redis。[root@linuxea.com /opt/2019/redis]# docker config create redis redis.conf 269yklanwzva9yk74n6b3j9dk然后我们可以检查配置，就像我们对其他任何Docker一样：[root@linuxea.com /opt/2019/redis]# docker config inspect redis [ { "ID": "269yklanwzva9yk74n6b3j9dk", "Version": { "Index": 24 }, "CreatedAt": "2019-03-02T02:36:19.257840639Z", "UpdatedAt": "2019-03-02T02:36:19.257840639Z", "Spec": { "Name": "redis", "Labels": {}, "Data": "YmluZCAwLjAuMC4wDQpwcm90ZWN0ZWQtbW9kZSB5ZXMNCnBvcnQgNjM3OQ0KdGNwLWJhY2tsb2cgNTExDQp0aW1lb3V0IDANCnRjcC1rZWVwYWxpdmUgMzAwDQpkYWVtb25pemUgbm8NCnN1cGVydmlzZWQgbm8NCnBpZGZpbGUgL3Zhci9ydW4vcmVkaXNfNjM3OS5waWQNCmxvZ2xldmVsIG5vdGljZQ0KbG9nZmlsZSAiL2RhdGEvbG9ncy9yZWRpc182Mzc5LmxvZyINCmRhdGFiYXNlcyAxNg0KYWx3YXlzLXNob3ctbG9nbyB5ZXMNCnNhdmUgOTAwIDENCnNhdmUgMzAwIDEwDQpzYXZlIDYwIDEwMDAwDQpzdG9wLXdyaXRlcy1vbi1iZ3NhdmUtZXJyb3IgeWVzDQpyZGJjb21wcmVzc2lvbiB5ZXMNCnJkYmNoZWNrc3VtIHllcw0KZGJmaWxlbmFtZSBkdW1wLnJkYg0KZGlyICIvZGF0YS9yZWRpcyINCnJlcGxpY2Etc2VydmUtc3RhbGUtZGF0YSB5ZXMNCnJlcGxpY2EtcmVhZC1vbmx5IHllcw0KcmVwbC1kaXNrbGVzcy1zeW5jIG5vDQpyZXBsLWRpc2tsZXNzLXN5bmMtZGVsYXkgNQ0KcmVwbC1kaXNhYmxlLXRjcC1ub2RlbGF5IG5vDQpyZXBsaWNhLXByaW9yaXR5IDEwMA0KbGF6eWZyZWUtbGF6eS1ldmljdGlvbiBubw0KbGF6eWZyZWUtbGF6eS1leHBpcmUgbm8NCmxhenlmcmVlLWxhenktc2VydmVyLWRlbCBubw0KcmVwbGljYS1sYXp5LWZsdXNoIG5vDQphcHBlbmRvbmx5IG5vDQphcHBlbmRmaWxlbmFtZSAiYXBwZW5kb25seS5hb2YiDQphcHBlbmRmc3luYyBldmVyeXNlYw0Kbm8tYXBwZW5kZnN5bmMtb24tcmV3cml0ZSBubw0KYXV0by1hb2YtcmV3cml0ZS1wZXJjZW50YWdlIDEwMA0KYXV0by1hb2YtcmV3cml0ZS1taW4tc2l6ZSA2NG1iDQphb2YtbG9hZC10cnVuY2F0ZWQgeWVzDQphb2YtdXNlLXJkYi1wcmVhbWJsZSB5ZXMNCmx1YS10aW1lLWxpbWl0IDUwMDANCnNsb3dsb2ctbG9nLXNsb3dlci10aGFuIDEwMDAwDQpzbG93bG9nLW1heC1sZW4gMTI4DQpsYXRlbmN5LW1vbml0b3ItdGhyZXNob2xkIDANCm5vdGlmeS1rZXlzcGFjZS1ldmVudHMgIiINCmhhc2gtbWF4LXppcGxpc3QtZW50cmllcyA1MTINCmhhc2gtbWF4LXppcGxpc3QtdmFsdWUgNjQNCmxpc3QtbWF4LXppcGxpc3Qtc2l6ZSAtMg0KbGlzdC1jb21wcmVzcy1kZXB0aCAwDQpzZXQtbWF4LWludHNldC1lbnRyaWVzIDUxMg0KenNldC1tYXgtemlwbGlzdC1lbnRyaWVzIDEyOA0KenNldC1tYXgtemlwbGlzdC12YWx1ZSA2NA0KaGxsLXNwYXJzZS1tYXgtYnl0ZXMgMzAwMA0Kc3RyZWFtLW5vZGUtbWF4LWJ5dGVzIDQwOTYNCnN0cmVhbS1ub2RlLW1heC1lbnRyaWVzIDEwMA0KYWN0aXZlcmVoYXNoaW5nIHllcw0KY2xpZW50LW91dHB1dC1idWZmZXItbGltaXQgbm9ybWFsIDAgMCAwDQpjbGllbnQtb3V0cHV0LWJ1ZmZlci1saW1pdCByZXBsaWNhIDI1Nm1iIDY0bWIgNjANCmNsaWVudC1vdXRwdXQtYnVmZmVyLWxpbWl0IHB1YnN1YiAzMm1iIDhtYiA2MA0KaHogMTANCmR5bmFtaWMtaHogeWVzDQphb2YtcmV3cml0ZS1pbmNyZW1lbnRhbC1mc3luYyB5ZXMNCnJkYi1zYXZlLWluY3JlbWVudGFsLWZzeW5jIHllcw0KbWF4bWVtb3J5LXBvbGljeSBhbGxrZXlzLWxmdQ0KbGZ1LWxvZy1mYWN0b3IgMTANCmxmdS1kZWNheS10aW1lIDENCm1heGNsaWVudHMgNjAwDQptYXhtZW1vcnkgNDA5Nk0NCm1hc3RlcmF1dGggIk9UZG1PV0k0WlRNNE5UWTFNMk00T1RaaC5jb20iDQpyZXF1aXJlcGFzcyAiT1RkbU9XSTRaVE00TlRZMU0yTTRPVFpoLmNvbSINCg==" } } ]数据仅为base64编码，可以轻松解码。[root@linuxea.com /opt/2019/redis]# docker config inspect -f '{{json .Spec.Data}}' redis|cut -d '"' -f2 |base64 -d bind 0.0.0.0 protected-mode yes port 6379 .... masterauth "OTdmOWI4ZTM4NTY1M2M4OTZh.com" requirepass "OTdmOWI4ZTM4NTY1M2M4OTZh.com"我修改了密码字段: OTdmOWI4ZTM4NTY1M2M4OTZh.com根据定义，配置中的数据不是机密的，因此不加密。docker-compose config配置注意：由于配置是在运行应用程序之前创建的，因此在此文件中将其定义为external。如下：version: '3.7' services: redis: image: marksugar/redis:5.0.0 container_name: redis restart: always network_mode: "host" privileged: true environment: - REDIS_CONF=off - REQUIRE_PASS=OTdmOWI4ZTM4NTY1M2M4OTZh - MASTER_AUTH=OTdmOWI4ZTM4NTY1M2M4OTZh - MAXCLIENTS_NUM=600 - MAXMEMORY_SIZE=4096M volumes: - /etc/localtime:/etc/localtime:ro - /data/redis-data:/data/redis:Z - /data/logs:/data/logs configs: - source: redis target: /etc/redis/redis.conf configs: redis: external: true其中configs引用如下：target： 配置文件在容器中的位置configs： 全局调用和局部调用version: '3.7' services: redis: image: .... configs: - source: redis target: /etc/redis/redis.conf configs: redis: external: true config的名称为redis，在全局配置中则填写redis，在局部配置中附加配置即可docker swarm 使用然后可以使用以下命令运行该应用程序：[root@linuxea.com /opt/2019/redis]# docker stack deploy -c ./docker-compose.yaml redis Ignoring unsupported options: network_mode, privileged, restart Ignoring deprecated options: container_name: Setting the container name is not supported. Creating network redis_default Creating service redis_redis验证[root@linuxea.com /opt/2019/redis]# docker exec -it redis_redis.1.s6f35kwutld2d7oc80e4531rp cat /etc/redis/redis.conf bind 0.0.0.0 protected-mode yes port 6379 ... masterauth "OTdmOWI4ZTM4NTY1M2M4OTZh.com" requirepass "OTdmOWI4ZTM4NTY1M2M4OTZh.com" ...info信息[root@linuxea.com /opt/2019/redis]# docker exec -i redis_redis.1.s6f35kwutld2d7oc80e4531rp redis-cli -a OTdmOWI4ZTM4NTY1M2M4OTZh.com info|grep cpu Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. used_cpu_sys:1.445721 used_cpu_user:1.499864 used_cpu_sys_children:0.000000 used_cpu_user_children:0.000000删除命令[root@linuxea.com /opt/2019/redis]# docker stack rm redis Removing service redis_redis Removing network redis_defaultupdate当需要修改配置的内容时，创建新配置（使用docker config create）然后更新服务以删除先前配置的config，并添加对新配置是一种常见模式。服务命令--config-rm和--config-add是我们修改配置文件的密码，而后重新创建一个redis1的config文件masterauth "OTdmOWI4ZTM4NTY1M2M4OTZh.com" requirepass "OTdmOWI4ZTM4NTY1M2M4OTZh.com.cn"创建redis1的config[root@linuxea.com opt/2019/redis]# docker config create redis1 redis.conf a4soto5rw4if4h7ir8jfrasyv更新配置文件先删除掉redis的config，而后添加redis1，这个过程会更新redis容器[root@linuxea.com /opt/2019/redis]# docker service update --config-rm redis --config-add src=redis1,target=/etc/redis/redis.conf redis_redis redis_redis overall progress: 1 out of 1 tasks 1/1: running [==================================================>] verify: Service converged 查看更新[root@linuxea.com /opt/2019/redis]# docker exec -it redis_redis.1.5qpc63nvm75w03v3ihk17hgie cat /etc/redis/redis.conf bind 0.0.0.0 protected-mode yes .... masterauth "OTdmOWI4ZTM4NTY1M2M4OTZh.com" requirepass "OTdmOWI4ZTM4NTY1M2M4OTZh.com.cn"

linuxea:缩减docker镜像大小的5个步骤 docker容器的应用程序易于部署管理是基于docker镜像，一个优良的docker镜像是非常有必要的。在多数情况下，我们处于无状态应用的快速部署，这个过程中，且不管你在dockerhub使用还是本地镜像仓库使用，合理的镜像的大小也是有必要的。除此之外，我们应该考虑那些？Docker镜像大小的重要性？网络带宽导致的空闲等待除了镜像大小外，我们还需要考虑更新迭代的问题，更大的基础镜像意味着需要更多的开发时间。这里必然少不了网络带宽的问题，上传下载的等待时间问题。磁盘空间问题当然，镜像大小不单单影响了上传下载操作人员等待的时间。如果你留意过磁盘的使用，你会发现磁盘空间也是一个非常吃紧的事情。安全问题事实上，磁盘并不会耗费太多的金钱。在内网来讲，带宽也不是一个特别大的问题。更多的需要注意的是容器的安全性的问题。太大的镜像往往意味着有更大的攻击面缩减镜像5个步骤在开始之前，我想复述一个重要的问题：你应该妥善考虑将要部署的应用的语言，框架，扩展，工具和第三方包。因为所有安装的内容都会增加镜像大小，docker镜像只需要运行应用所需的环境足以，其他的能少尽量的减少。安装适合的依赖工具包对于从0构建来说，生产的镜像仅仅配置有必要的程序以来包，对于一些不必要的包应该全部删除。如：curl,wget等等。更小的基础镜像假如你要从0开始构建，通常，常见的基础镜像是ubuntu和centos以及debian，除此之外，我们可以考虑使用alpine，alpine的大小仅仅只有5M。使用alpine减小了镜像的大小，但是alpine和centos，debian有一定的差别如果你之是运行一个python程序，或者php程序，你应该考虑使用官方的镜像，比如 : ptyhon:2.7-alpine3.8，这仅仅几十兆。你可以进行自己构建，假如你掌握了这些知识更少的层docker的层也决定了镜像的大小，我们应该尽可能的使用更少的层来构建。更少的层可能意味着更少的dockerfile命令，比如run命令，阅读dockerfile中的RUN指令对镜像大小的影响有助于你深入了解。同时，在很多时候，更少的层解决不了过于繁琐复杂的镜像构建，这时候就需要多阶段构建来解决。使用.dockerignore文件.dockerignore在构建的时候，控制构建的上下文中的内容，对一些内容进行忽略，从而达到想要的预期效果。对于一些特别不需要的文件这特别有用，你可以参考linuxea:docker不能忽视的.dockerignore用法深入了解压缩镜像docker-squash最后一个方式是压缩镜像，docker-squash是一个实用程序，用于将多个层压缩成一个，以便创建具有更少和更小层的镜像。它保留了Dockerfile命令，如PORT，ENV等。这样压扁镜像的工作方式与最初构建时相同。此外，后续图层中删除的文件实际上是在压缩时从镜像中清除的。延伸阅读linuxea:docker不能忽视的.dockerignore用法linuxea:docker多阶段构建Multi-Stage与Builder对比总结docker-squashlinuxea:dockerfile中的RUN指令对镜像大小的影响学习更多学习如何使用Docker CLI命令，Dockerfile命令，使用这些命令可以帮助你更有效地使用Docker应用程序。查看Docker文档和我的其他帖子以了解更多信息。docker目录白话容器docker-compose