uc down or uc undeploy would be nice

[miekg]

I think I'm missing the opposite of uc deploy to stop a previous started deployment. compose has down, but then again it also has up...

think deploy should be an alias of up and we should implement a down as well

[jabr]

Perhaps uc undeploy? 😄

[psviderski]

Wil throw some ideas that may influence the design. I've been thinking of adding a new Application (app) concept. A compose file defines an app that consists of several services. This introduces a namespace and grouping for services.

The top-level name attribute in Compose can define the name of the app (defaults to the working dir name).

uc app ls
uc app rm
uc app inspect

when working with services, we should likely start specifying what app we want to use:

uc service ls -a app
uc service -a app rm SERVICE

Having to specify -a is a bit annoying. Maybe all shortcut uc commands should only work with the app defined in the local Compose file. If no compose, -a is required.

I think this is closer to Docker Swarm's docker stack deploy/rm than to docker compose up/down.

[miekg]

oh yes! The namespace bit is really nice to have, never used swarm, but to have uc ls include a namespace, i.e.

monitoring/prometheus
monitoring/alertmanager

would also be a cool to exactly see what belongs together.

Adding the namespace in dns is then also in the cards? prometheus.monitoring.internal ? Together with everything under monitoring.internal.

[psviderski]

I'm thinking of apps as not generic namespaces like in k8s but as 1:1 mapping to what you define in the Compose file - typically related services that comprise an "app". I've never liked specifying -n NAMESPACE with kubectl so that's why some defaults would be helpful when working on a particular app.

Adding the namespace in dns is then also in the cards? prometheus.monitoring.internal ?

Yeah, I think this is necessary to do as well.

[miekg]

yep, totally agree. It only is a namespace, I'm now mimicking it in compose with an un prefix for our stuff. Was hoping un/xxxx was allowed, but no. Namespaces would fix this.

Volumes (and maybe other things) are excluded from this?

[psviderski]

Volumes (and maybe other things) are excluded from this?

That's an interesting one. On the one hand it seems volumes can live in a single global namespace. But on the other hand, we should make it relatively easy to deploy two copies of the same app and this is where it will get in the way as one might want a separate set of volumes for another copy.

Maybe they should be namespaced as well. Oh, this may become complex pretty quickly. We need to think everything through carefully

[miekg]

regardless of namespacing. I miss these operations and will propose a PR to add them at some point, little ease of life things

[joeblew999]

+1, with a concrete use case for the app-scoped variant. We run a set of single-compose recipes (Moltis, a Windows desktop via dockur, WordPress, …) on shared uncloud nodes — each recipe is exactly the "one compose file = one app" you describe.

Today the only teardown we have is whole-node (tofu destroy of the box), so there's no clean "remove just the Moltis recipe, keep the node and its other services." A per-app uc app rm (or uc undeploy scoped to the local compose) would cover that nicely, and uc app ls showing services grouped by app would make a shared node much easier to reason about.

The "default to the app in the local Compose file, -a only when there's no compose" ergonomics sound right to us — that matches how we invoke recipes (always from the recipe's compose dir). 👍

[iRazvan2745]

+1

[miekg]

new-ish idea from discard: support name this labels the deployment and can be used for destroy and deploy to see what to tear down. It's just a label, which makes this nice and easy

[psviderski]

Starting with a label sounds good as the full app namespace implementation will anyway need this to derive the (app, service) tuple from the Docker container labels.

Deploy can then even see if it needs to remove containers if you removed them from the compose.yaml

This could be a bit tricky one as uc deploy also supports positional arguments and --profile to selectively deploy services. In these cases we should probably still compare deployed services to all services defined in Compose.
I think docker compose doesn't automatically remove services and has a flag:

 --remove-orphans               Remove containers for services not defined in the Compose file

But I'm not yet sure if I'd prefer this behaviour to be the default and maybe have an option to not remove orphans if desired (need to think about a valid use case for this).

[miekg]

Starting with a label sounds good as the full app namespace implementation will anyway need this to derive the (app, service) tuple from the Docker container labels.

ack, i'll start something (after I cleaned/closed a few other PRs/issues)

Note that we also need some kind of syntax, say we have uc rm removing a namespace labelled deployement:

• uc rm service -> remove service
• uc rm app/ -> remove service(s) labelled by app? And use a trailing slash consistently, e.g. in uc inspect, etc.

also note we would be using name: differently than how it's used in docker compose, in there it's just to override the default project name (I don't mind - just mentioning it)

[psviderski]

I can also think of one case for which this will be a breaking change. I've seen people organise compose.yaml files in nested directories and then have a parent compose.yaml that includes them:

include:
  - ./myapp/compose.yaml
  - ./anotherapp/compose.yaml
  - ./monitoring/compose.yaml

At the moment they can run uc deploy at the parent directory and run the deploy for all apps or cd into individual dir and run the deploy only for it.
With the introduction of app/stack label, the parent deployment labels all nested apps with the same app label. Then uc deploy in a nested directory will face a conflict: the service name is the same but the app name is different.

Thinking of the fully-implemented app concept that introduces a namespace, I think we will introduce this breaking change anyway. One Compose spec = open application, no matter from how many partial files it's composed. So I guess we will need to address the problem of deploying multiple apps separately. This could be an extension to the Compose spec, a new CLI command or flag, or maybe we shouldn't even solve it in uc.

[miekg]

yes, but this feature would gated behind a name: xxx in your compose file(s), if you don't have it, it would work like it does now ?

[psviderski]

name: xxx overrides the default project name which is the directory name by default so the compose project struct always has a name, even now. We just don't use it in uncloud-specific structs. But after introducing the logic to map it to a container label, uc deploy will start setting it to the directory name, even if a user didn't explicitly specify name: in compose.