Feature: add "docker context edit" function

[thaJeztah]

This is just a quick thought, but thought I'd write it down.

The next version of the docker cli adds a new docker context subcommand (#1501). With this subcommand, I can import, create, update, and export contexts.

The current set of options per context is limited, but may be extended in future (see
#1621 for a proposal).

Updating, or creating a context works for the current set of options, but likely doesn't scale well if there's many new options are to be added; at some point, people will have to resort to scripts to update, or create a context (docker context update --docker foo=bar,bar=baz --kubernetes foo=bar,bar=baz).

As an alternative, users can edit the files in the context storage directly, but this may not be desirable;

cd $(docker context inspect --format='{{.Storage.MetadataPath}}' mycontext)
vi meta.json

In addition, json works great for automation, and to serialize as a string, but does not allow comments, nor may it be very user-friendly to work with.

Proposal

Introduce a docker context edit subcommand.

The docker context edit command, using a similar approach as git commit, which (I think) works something like this;

• export the context to a temporary file (e.g. ~/.docker/context/CONTEXT_EDIT)
  • this file could be in JSON format (but pretty-printed), or
  • or use a user-friendly format (TOML?)
  • if we pick TOML or YAML, we can present an anotated version of the context
• open the file in the default editor
• when saving the file, the context is validated and updated; the temporary file is removed
• when exiting the editor without saving, the update is aborted (Aborting update.)
• if validation fails, the update is aborted as well.

docker context edit mycontext

Opens an editor with the context in pretty-print;

{
  "Name": "mycontext",
  "Metadata": {
    "Description": "this is my context"
  },
  "Endpoints": {
    "docker": {
      "Host": "unix:///var/run/docker.sock",
      "SkipTLSVerify": false
    }
  }
}

Or, in an annotated TOML format;

# Editing context "mycontext". Lines starting with '#' will be ignored,
# and exiting your editor without saving aborts the update.



# This is the name of the context. Changing the name will create a 
# copy of the existing context under the new name.
Name = "mycontext"

[Metadata]

# Description of this context.
Description = "this is my context"

[Endpoints]

  # Configuration for the Docker endpoint of this context
  [docker]
  # Address of the host of this endpoint.
  # 
  # Valid schemes are:
  # unix:///path/to/socket
  # tcp://host.example.com:1234
  # ssl://server1.cloud.example.com
  # ssl://user@server1.cloud.example.com
  Host="unix:///var/run/docker.sock"

  # Skip TLS verification (default: false)
  # Disable TLS verification for testing purposes, or when using
  # self-signed certificates.
  # SkipTLSVerify = true

After editing the file, and saving it:

succesfully updated "mycontext"

When trying to update a context while another context is already in progress, an error is shown:

docker context edit mycontext
Error: another edit is already in progress. Finish the existing edit, or abort using "docker context edit --abort"

[thaJeztah]

@simonferquel @chris-crone WDYT? 🤗

[simonferquel]

I love the idea. Toml seems particularly well suited for that.
We need to be careful about editing contexts containing endpoints created by plugins

[thaJeztah]

We need to be careful about editing contexts containing endpoints created by plugins

Good point; not fully up to speed on such cases; In that case the endpoint is managed by the plugin you mean?

FWIW, if we think this approach works, we could use docker context as a first "PoC" (as it's all client-side), but we could consider expanding this concept to other objects (docker service edit, docker container edit). Perhaps one day, stacks are moved server-side (moby/moby#26876, moby/moby#32781, moby/moby#35912), at which point docker stack edit would perhaps be possible as well.