Installed apps show up as stacks

[thaJeztah]

Apps that were installed with docker app install show up both as app, and as stack;

docker app ls
INSTALLATION   APPLICATION        LAST ACTION RESULT  CREATED    MODIFIED  REFERENCE
myinstallation myotherapp (0.1.0) upgrade     success 12 minutes 8 minutes 

docker stack ls
NAME                SERVICES            ORCHESTRATOR
myinstallation      1                   Swarm
mystack             1                   Swarm

Do we want stacks and apps to work in the same "namespace"? Or should we prevent users from interacting with apps through docker stack xxx commands (and vice-versa)?

I guess there's two possible angles;

1. apps and stacks are separate things
2. apps and stacks form a hierarchy; an app consists of 1 (or perhaps in future more than 1) stacks (and stacks consist of 1 or more services, volumes, etc.)

If 2., then stacks that are part of an app should likely show up under docker stack ls, but we should think how users can/are allows to interact with them.

I think in both cases, we should add additional metadata/labels to (both stacks, and) apps so that we can distinguish apps from stacks, allowing use to filter and/or provide info about the stack/app separate from the local storage in ~/.docker/apps.

[thaJeztah]

Note that adding additional metadata/labels to the deployed apps would also help with https://github.com/docker/app/issues/604

Looking at the information stored (~/.docker/app/installations/37a8eec1ce19687d132fe29051dca629d164e2c4958ba141d5f4133a33f0688f/myinstallation.json)

• 37a8eec1ce19687d132fe29051dca629d164e2c4958ba141d5f4133a33f0688f could be stored as ID (e.g. com.docker.app.id)
• myinstallation is the installation name, which is already stored as com.docker.stack.namespace, but we may want to store that as a "docker app" specific label as well (com.docker.app.name ?)

From the myinstallation.json (shown below, collapsed);

```json { "name": "myinstallation", "revision": "01DNS4S9HPYSTS1FCG77WVJCXT", "created": "2019-09-27T12:34:06.685081+02:00", "modified": "2019-09-27T12:38:08.950407+02:00", "bundle": { "name": "myotherapp", "version": "0.1.0", "description": "", "maintainers": [ { "name": "sebastiaan", "email": "sebastiaan@docker.com" } ], "invocationImages": [ { "imageType": "docker", "image": "myotherapp:0.1.0-invoc" } ], "images": { "hello": { "imageType": "docker", "image": "hashicorp/http-echo", "description": "hashicorp/http-echo" } }, "actions": { "com.docker.app.inspect": { "stateless": true }, "com.docker.app.render": { "stateless": true }, "com.docker.app.status": {} }, "parameters": { "com.docker.app.kubernetes-namespace": { "type": "string", "default": "", "metadata": { "description": "Namespace in which to deploy" }, "destination": { "env": "DOCKER_KUBERNETES_NAMESPACE" }, "apply-to": [ "install", "upgrade", "uninstall", "com.docker.app.status" ] }, "com.docker.app.orchestrator": { "type": "string", "default": "", "allowedValues": [ "", "swarm", "kubernetes" ], "metadata": { "description": "Orchestrator on which to deploy" }, "destination": { "env": "DOCKER_STACK_ORCHESTRATOR" }, "apply-to": [ "install", "upgrade", "uninstall", "com.docker.app.status" ] }, "com.docker.app.render-format": { "type": "string", "default": "yaml", "allowedValues": [ "yaml", "json" ], "metadata": { "description": "Output format for the render command" }, "destination": { "env": "DOCKER_RENDER_FORMAT" }, "apply-to": [ "com.docker.app.render" ] }, "com.docker.app.share-registry-creds": { "type": "bool", "default": false, "metadata": { "description": "Share registry credentials with the invocation image" }, "destination": { "env": "DOCKER_SHARE_REGISTRY_CREDS" } }, "hello.port": { "type": "string", "default": "8080", "destination": { "env": "docker_param1" } }, "hello.text": { "type": "string", "default": "Hello myotherapp!", "destination": { "env": "docker_param2" } } }, "credentials": { "com.docker.app.registry-creds": { "path": "/cnab/app/registry-creds.json" }, "docker.context": { "path": "/cnab/app/context.dockercontext" } } }, "result": { "message": "", "action": "upgrade", "status": "success" }, "parameters": { "com.docker.app.kubernetes-namespace": "default", "com.docker.app.orchestrator": "", "com.docker.app.render-format": "yaml", "com.docker.app.share-registry-creds": false, "hello.port": "8080", "hello.text": "Hello myapp!" }, "files": null } ```

• name (already mentioned above), revision, created, modified could be good candidates for labels (com.docker.app.<property>)

Possibly;

• store standard parameters as labels (com.docker.app.kubernetes-namespace ?)
• not sure about the custom parameters, as they may contain sensitive data. If not, they could be stored as com.docker.app.parameters.<name-of-parameter>

[thaJeztah]

/cc @chris-crone @silvin-lubecki

[thaJeztah]

Hm, actually, looks like the 37a8eec1ce19687d132fe29051dca629d164e2c4958ba141d5f4133a33f0688f is not an ID (or at least, the same ID is created when re-deploying the application after removing the local store); is it a hash of the name, not a UUID/random ID?

[thaJeztah]

So, looks like interacting through docker stack is indeed problematic, because docker app currently relies on the local store;

$ docker stack rm myinstallation
Removing service myinstallation_hello
Removing network myinstallation_default

$ docker app ls
INSTALLATION   APPLICATION        LAST ACTION RESULT  CREATED   MODIFIED       REFERENCE
myinstallation myotherapp (0.1.0) upgrade     success 7 minutes About a minute 

$ docker app status myinstallation
INSTALLATION
------------
Name:         myinstallation
Created:      10 minutes
Modified:     4 minutes
Revision:     01DNS7WG2EJP1Q1KTM1DATP5SD
Last Action:  upgrade
Result:       SUCCESS
Orchestrator: swarm

APPLICATION
-----------
Name:      myotherapp
Version:   0.1.0
Reference: 

PARAMETERS
----------
hello.port: 8080
hello.text: Hello myapp!

STATUS
------

[silvin-lubecki]

@thaJeztah your last result is weird, status should have failed, not being able to reach the rmed stack.

[silvin-lubecki]

37a8eec1ce19687d132fe29051dca629d164e2c4958ba141d5f4133a33f0688f could be stored as ID (e.g. com.docker.app.id)

Actually 37a8eec1ce19687d132fe29051dca629d164e2c4958ba141d5f4133a33f0688f is the id of the installation context 😅 The installation store is split by context ids, and inside you will find all the named installations.

[thaJeztah]

Ah! Gotcha 👍 Guess having a GUID stored somewhere would work for IDs

[kinghuang]

At a high level, I like the idea of 2 where an app consists of one or more stacks. But, I feel that might lead to confusion about apps vs stacks.

I think labeling app-based deployments so that existing stack/service commands can work with them would ease adoption, and make them interoperable with third-party tools like Portainer out of the box.

Perhaps a bigger gain for apps and stacks as a whole would be to create a resource type and APIs for it (as a combined entity). Right now, there is no actual stack resource in the Docker API. The concept of stacks only exist in the Docker CLI. A new resource type could hold the information that's currently being stored locally in ~/.docker/app/installations/, and finally provide an API that external tools can use.