Use Docker config to store data (1)
About configuration
Docker swarm service configuration allows us to store non-sensitive information, such as configuration files, outside of the service image or running containers. This allows you to keep your images as generic as possible without binding configuration files to containers or using environment variables.
Configurations operate similarly to keys, except that they are not encrypted at rest and are mounted directly into the container's filesystem without using a RAM disk. Configurations can be added or removed from services at any time, and services can share configurations. Configuration can even be combined with environment variables or labels for maximum flexibility. Configuration values can be generic strings or binary content (up to 500kb in size).
Note : Docker configuration only applies to swarm services, not standalone containers. To use this feature, consider adapting the container to run as a service of scale 1.
Both Linux and Windows services support configuration.
How Docker manages configuration
When we add a configuration to the cluster, Docker sends the configuration to the swarm manager over a mutual TLS connection. Configuration is stored in the Raft log, which is encrypted. The entire Raft log is replicated across other managers, ensuring the configuration has the same high availability guarantees as other swarm-managed data.
When we grant access to a configuration to a newly created or running service, the configuration is mounted as a file in the container. In Linux containers, the location of the mount point in the container defaults to /<config-name>. In a Windows container, the configuration is mounted into C:\ProgramData\Docker\configsand a symlink is created to the desired location, which defaults to C:\<config-name>.
uidOwnership ( and gid) can be set for configurations using a numeric ID or the name of a user or group . We can also specify file permissions ( mode). For Windows containers, these settings are ignored.
rootIf not set, the configuration is owned by the user running the container command (usually ) and that user's default group (often alsoroot).- 如果没有设置，则配置具有世界可读权限（模式
0444），除非在容器内设置了umask，在这种情况下，该模式会受到该umask值的影响。
我们可以随时更新服务，授予其对其他配置的访问权限或撤销对给定配置的访问权限。
只有当节点是集群的管理节点或正在运行已授予配置访问权限的服务任务时，节点才能访问配置。当容器任务停止运行时，与之共享的配置将从该容器的内存文件系统中卸载，并从节点的内存中刷新。
如果节点在运行可以访问配置的任务容器时失去与群的连接，则任务容器仍然可以访问其配置，但在节点重新连接到群之前无法接收更新。
我们可以随时添加或检查单个配置，或列出所有配置。但是无法删除正在运行的服务正在使用的配置。
要更轻松地更新或回滚配置，请考虑在配置名称中添加版本号或日期。由于能够在给定容器中控制配置的挂载点，这变得更加容易。
要更新堆栈，请更改您的Compose文件，然后重新运行docker stack deploy -c <new-compose-file> <stack-name>。如果在该文件中使用新的配置，集群服务将开始使用它们。
我们可以运行docker stack rm来停止应用程序并删除堆栈。这将删除由具有相同堆栈名称的docker stack deploy创建的任何配置。这将删除所有配置，包括服务未引用的配置和docker service update --config-rm后剩余的配置。
docker config命令的信息
例子
我们跟着以下的示例来了解配置相关指令，这些示例说明了Docker配置是如何使用的。
在编写文件中定义和使用配置
docker stack命令支持在Compose文件中定义配置。然而，docker compose不支持configs配置。
简单示例：开始配置m
这个简单的示例仅在几个命令中就显示了配置的工作原理。
-
向Docker添加配置。
docker config create命令读取标准输入，因为最后一个参数（表示要从中读取配置的文件）设置为-。echo "This is a config" | docker config create my-config - -
创建一个
redis服务，并授予它对配置的访问权限。默认情况下，容器可以在/my-config访问配置，但我们可以使用target选项自定义容器上的文件名。docker service create --name redis --config my-config redis:alpine -
使用
docker service ps验证任务是否正常运行。如果一切正常，输出看起来与此相似：docker service ps redis -
使用
docker ps获取redis服务任务容器的ID，以便您可以使用docker container exec连接到容器并读取配置文件数据文件的内容，该文件默认为可被所有人读取，并且与配置文件名称相同。下面的第一个命令说明了如何查找容器ID，第二个和第三个命令使用shell完成来自动执行此操作。docker ps --filter name=redis -q docker container exec $(docker ps --filter name=redis -q) ls -l /my-config docker container exec $(docker ps --filter name=redis -q) cat /my-config -
尝试删除配置。删除失败，因为
redis服务正在运行并可以访问配置。docker config ls docker config rm my-config -
通过更新服务，从正在运行的
redis服务中删除对配置的访问权限。docker service update --config-rm my-config redis -
再次重复步骤3和4，验证该服务不再有权访问配置。容器ID不同，因为
service update命令会重新部署服务。$ docker container exec -it $(docker ps --filter name=redis -q) cat /my-config cat: can't open '/my-config': No such file or directory -
停止并删除服务，并从Docker中删除配置。
docker service rm redis docker config rm my-config