Open thaJeztah opened 4 years ago
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);
name
(already mentioned above), revision
, created
, modified
could be good candidates for labels (com.docker.app.<property>
)Possibly;
com.docker.app.kubernetes-namespace
?)com.docker.app.parameters.<name-of-parameter>
/cc @chris-crone @silvin-lubecki
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?
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
------
@thaJeztah your last result is weird, status
should have failed, not being able to reach the rm
ed stack.
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.
Ah! Gotcha š Guess having a GUID
stored somewhere would work for IDs
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.
Apps that were installed with
docker app install
show up both as app, and as stack;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;
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
.