[raphinou]

I'm a docker swarm user, and this is the first alternative that looks interesting to me!

Some questions I have based on my swarm usage:

- do you plan to support secrets?

- with swarm and traefik, I can define url rewrite rules as container labels. Is something equivalent available?

- if I deploy 2 compose 'stacks', do all containers have access to all other containers, even in the other stack?

[psviderski]

>with swarm and traefik, I can define url rewrite rules as container labels. Is something equivalent available?

Yep, you define the mapping between the domain name and the internal container port as `x-ports: app.example.com:8000/https` in the compose file. Or you can specify a custom Caddy config for the service as `x-caddy: Caddyfile` which allows to customise it however you like. See https://uncloud.run/docs/concepts/ingress/publishing-service...

>if I deploy 2 compose 'stacks', do all containers have access to all other containers, even in the other stack?

Yes, there is no network isolation between containers from different services/stacks at the moment. Here is an open discussion on stack/namespace/environment/project concepts and isolation: https://github.com/psviderski/uncloud/discussions/94.

What's your use case and how would you want this to behave?

[raphinou]

My personal preference is to have the different stack isolated by default (+ intra-stack isolation possibility using networks).

I'm deploying Swarm and traefik as described here: https://dockerswarm.rocks/traefik/#create-the-docker-compose...

I like that I can put my containers to be exposed on the traefik-public network, and keep others like databases unreachable from traefik. This organisation of networks is very useful, allowing to make containers reachable across stacks, but also to keep some containers in a stack reachable only from other containers on the same network in that same stack.

[tontony]

Secrets -- yes, it's being tracked here: https://github.com/psviderski/uncloud/issues/75 Compose configs are already supported and can be used to inject secrets as well, but there'll be no encryption at rest there in that case, so might not be ideal for everyone.

Regarding questions 2 and 3, the short answers are "not at the moment" and "yes, for now", here's a relevant discussion that touches on both points: https://github.com/psviderski/uncloud/discussions/94

Speaking of Swarm and your experience with it: in your opinion, is there anything that Swarm lacks or makes difficult, that tools like Uncloud could conceptually "fix"?

[raphinou]

Swarm is not far from my dream deploy solution, but here are some points that might be better, some of them being already better in uncloud I think:

- energy in the community is low, it's hard to find an active discussion channel of swarm users

- swarm does not support the complete compose file format. This is really annoying

- sometimes, deploys fail for unclear reasons (eg a network was not found, but why as it's defined in the compose file?) and work the next try. This is never lead to problems, but doesn't feel right

- working with authenticate/custom registries is somewhat cumbersome

- having to work with registries to have the same image deployed on all nodes is sometimes annoying. It could be cool to have images spreading across nodes.

- there's no contact between devs and users. I've just discovered uncloud and I've had more contact with its devs here than in years of using swarm!

- the firewalling is not always clear/clean

- logs accessibility (service vs container) and containers identification: when a container fails to start, it's sometimes harder than needed to debug (esp when it is because the image is not available)

[tontony]

Thanks for the detailed overview!