4 ms·

So it's a kind of better Docker Swarm? It's interesting, but honestly I'd rather have something declarative, so I can use it with Pulumi, would it be complicate

by oulipo2 11mo ago

So it's a kind of better Docker Swarm? It's interesting, but honestly I'd rather have something declarative, so I can use it with Pulumi, would it be complicated to add a declarative engine on top of the tool? Which discovers what services are already up, do a diff with the new declaration, and handles changes?

psviderski 11mo ago
This is exactly how it works now. The Compose file is the declarative specification of your services you want to run. When you run 'uc deploy' command: - it reads the spec from your compose.yaml - inspects the current state of the services in the cluster - computes the diff and deployment plan to reconcile it - executes the plan after the confirmation Please see the docs and demo: https://uncloud.run/docs/guides/deployments/deploy-app https://uncloud.run/docs/guides/deployments/deploy-app The main difference with Docker Swarm is that the reconciliation process is run on your local/CI machine as part of the 'uc deploy' CLI command execution, not on the control plane nodes in the cluster. And it's not running in the loop automatically. If the command fails, you get an instant feedback with the errors you can address or rerun the command again. It should be pretty straightforward to wrap the CLI logic in a Terraform or Pulumi provider. The design principals are very similar and it's written in Go.
- snthpy 11mo ago
  That's really interesting and cool. In that case calling it imperative rather than declarative is underselling it imho. I haven't worked that much with Terraform but in my usage from the cli, that is how it works too and I consider that declarative. I get that putting the declarative spec in the control plane and having the service autoreconcile continuously is another layer but this is great as a start. In fact could you not just cron the cli deployment command on the nodes and get an effective poor man's declarative layer to guard against node failures if your ok with a 1 min or 1 sec recovery objective?
  - jabr 11mo ago
    > In fact could you not just cron the cli deployment command on the nodes and get an effective poor man's declarative layer In the project discord, a user recently experimented with a custom setup that sounds very similar to what you describe. In fact, a big part of uncloud’s appeal to me is that it also provides powerful building blocks for more complex, custom systems like this, not just the streamlined workflow for simpler, standard cases.
  - psviderski 11mo ago
    > In fact could you not just cron the cli deployment command on the nodes and get an effective poor man's declarative layer to guard against node failures if your ok with a 1 min or 1 sec recovery objective? Yeah, you absolutely could and someone on our Discord has written a 30-line bash script that essentially runs a reconciliation loop with the CLI. Thanks for the point on underselling by calling it imperative rather than declarative!

by oulipo2 11mo ago

psviderski 11mo ago

This is exactly how it works now. The Compose file is the declarative specification of your services you want to run. When you run 'uc deploy' command: - it reads the spec from your compose.yaml - inspects the current state of the services in the cluster - computes the diff and deployment plan to reconcile it - executes the plan after the confirmation Please see the docs and demo: https://uncloud.run/docs/guides/deployments/deploy-app https://uncloud.run/docs/guides/deployments/deploy-app The main difference with Docker Swarm is that the reconciliation process is run on your local/CI machine as part of the 'uc deploy' CLI command execution, not on the control plane nodes in the cluster. And it's not running in the loop automatically. If the command fails, you get an instant feedback with the errors you can address or rerun the command again. It should be pretty straightforward to wrap the CLI logic in a Terraform or Pulumi provider. The design principals are very similar and it's written in Go.

snthpy 11mo ago
That's really interesting and cool. In that case calling it imperative rather than declarative is underselling it imho. I haven't worked that much with Terraform but in my usage from the cli, that is how it works too and I consider that declarative. I get that putting the declarative spec in the control plane and having the service autoreconcile continuously is another layer but this is great as a start. In fact could you not just cron the cli deployment command on the nodes and get an effective poor man's declarative layer to guard against node failures if your ok with a 1 min or 1 sec recovery objective?
- jabr 11mo ago
  > In fact could you not just cron the cli deployment command on the nodes and get an effective poor man's declarative layer In the project discord, a user recently experimented with a custom setup that sounds very similar to what you describe. In fact, a big part of uncloud’s appeal to me is that it also provides powerful building blocks for more complex, custom systems like this, not just the streamlined workflow for simpler, standard cases.
- psviderski 11mo ago
  > In fact could you not just cron the cli deployment command on the nodes and get an effective poor man's declarative layer to guard against node failures if your ok with a 1 min or 1 sec recovery objective? Yeah, you absolutely could and someone on our Discord has written a 30-line bash script that essentially runs a reconciliation loop with the CLI. Thanks for the point on underselling by calling it imperative rather than declarative!