Some thoughts before I jump into implementation.

Goal: Allow users to inject non-sensitive information, such as configuration files, into running services (containers) without the need to rebuild the containers images.

The configs feature (not to be confused with docker compose config command) implemented in Docker Compose and Docker Swarm seems like a decent interface to implement, which is in line with our current goal of maintaining compatibility with Compose.

Configs in Docker

A few hard facts about “configs” feature in Docker first:

config is a first-class object in docker, but proper docker config management is only available in Swarm mode (docs about configs for Swarm).

✘ $ docker config 
Usage:  docker config COMMAND

Manage Swarm configs

Commands:
  create      Create a config from a file or STDIN
  inspect     Display detailed information on one or more configs
  ls          List configs
  rm          Remove one or more configs

Run 'docker config COMMAND --help' for more information on a command.

✘ $ docker config ls
Error response from daemon: This node is not a swarm manager. Use "docker swarm init" or "docker swarm join" to connect this node to swarm and try again.

It’s still possible to use the config feature with Compose. On standalone Docker Compose, configs are not centrally managed nor versioned as in Swarm – instead, the file (or inline content, or environment variable contents) is simply mounted when you run docker compose up, basically behaving like a read-only file bind mount.
- Configs top-level field docs: https://docs.docker.com/reference/compose-file/configs/
- Service-level field docs: https://docs.docker.com/reference/compose-file/services/#configs
Configs content is not encrypted

Our options

Option 1: Implement “config” as a first-class entity (similar to volumes), including its own subcommands (uc config create/inspect/ls/rm) and gRPC methods. UX-wise, this will be similar to how Swarm lets you manage configs. When creating a config — either via CLI or via the Compose file — a separate (decoupled) config object is created in the cluster that can later be mounted by services.
Option 2: Implement the configs interface (by extending ServiceSpec), but not provide dedicated commands for config management. The config content will be part of the service specification, transferred to the cluster via uc deploy , and if necessary — replicated via the existing replication logic (inspect service → rebuild the spec → deploy to another machine).

In both cases, on the machines the configs are mounted as read-only files; if a config is changed on the control node — a redeploy of the corresponding service(s) will be required.

I’m currently leaning towards option 2, because I don’t see a lot of value right now in making configs a bigger feature than it should be. That said, if we decide to treat them more seriously, we can build the proper config management described in option 1 on top later.

Notes

Naming: Feature name (configs) might be confusing because it’s pretty generic and may conflict e.g. with cluster config. We may want to come up with a more ergonomic name (at least in the documentation), while at the same time preserving the Compose interface.
Secrets: secrets are pretty similar to configs in terms of interface and functionality: docker secret and docker config have the same sub-commands in Swarm, and e.g. under the hood they reuse the same underlying struct. We can probably assume for now that the implementation and limitations for configs and secrets will be similar (at least in the first iteration).

@psviderski thoughts?

Uh oh!

Add support for Compose configs #43

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions