search

m-adawi / swarm-cd

SwarmCD: Declarative GitOps and Continuous Deployment tool for Docker Swarm.
GNU General Public License v3.0
73 stars 2 forks source link

feature request: management API #46

Open capcom6 opened 2 months ago

capcom6 commented 2 months ago

Overview

It would be beneficial to have an API to manage (add, edit, delete) repositories and stacks dynamically. This approach is more convenient than editing configuration files manually and could serve as the foundation for a fully-featured UI.

Inspiration

This feature is inspired by Portainer, which offers similar functionality for managing Docker environments.

Implementation Details

  1. State Management:

    • This feature will require storing state.
    • Options include using existing config files or creating separate "dynamic" versions.
    • We can implement separate files to define: a. Static stacks/repos (unchangeable via API) - existing ones b. Dynamic stacks/repos (fully manageable by API)

  2. Future Enhancements:

    • Implement storage adapters (e.g., Redis)

Related Issues

sanzoghenzo commented 1 month ago

This is my own personal opinion, but I turned to SwarmCD exactly because I wanted a declarative, git-focused workflow instead of an API/Web UI to manage my deployments.

It seems to me that you want a Portainer clone, why not just use that?

capcom6 commented 1 month ago

The availability of an API doesn't contradict a declarative, git-focused workflow. For example, Kubernetes has an API as its main communication method, yet it still uses a declarative style for describing resources.

The current version of SwarmCD is great for mono-repos or static environments. The request for stacks discovery (https://github.com/m-adawi/swarm-cd/issues/23) will improve the situation, but not for multi-repo projects.

My use case: I have a project based on microservices. Each microservice is located in its own repository, and there's an infrastructure stack that's common to all microservices (reverse-proxy, DB, cache, etc.). Sometimes I want to add or remove a microservice from the system. With the current version of SwarmCD, I have to redeploy SwarmCD itself with changed config files, or at least SSH into the manager node, edit mounted files, and restart the service. It would be more reliable if I could achieve the same result with a single API call.

Regarding Portainer: You're partially right. I use it now, but I don't need many of its features. That's why I'm searching for lightweight alternatives. SwarmCD is close to meeting my requirements. Another option would be to create my own tool.

sanzoghenzo commented 1 month ago

I see your point and I agree with you.

A simple CRUD API for stacks and repos could be easily implemented. One of my main concerns, though, is that along with the API there's the need to implement auth and RBAC right away to avoid security issues. And to my eyes this will complicate things for a one-man (plus 2 contributors) project. I like this project because it is simple, lightweight and I can do RBAC based on permissions set in the git repository instead.

For your use case: why not move the stacks to a separate, single repository, so that you have clear distinction between code and deployment? The CI in the code repo will build and push container images to a registry and optionally make a PR in the deployment repo to update the stack (or you can leverage tools like renovate to do it in a pull based fashion). while SwarmCD only monitors the deployment repo (and with #23 it would be as simple as a single stack with wildcards in the path). The only thing that it cannot be done yet is to detect removed stacks - it will need the state storage as you mentioned.

capcom6 commented 1 month ago

I don't think that auth and RBAC are necessary, at least for now. These can be implemented by an API gateway, which is usually already in place to provide access to other services in the cluster. Since adding or removing stacks is not frequently needed, the stacks API can be provided only to the cluster admin, which might even be a single person. Therefore, auth, RBAC, etc., would be over-engineering at this stage.

The problem with a mono-repo for deployments is access control. Every developer works on their own microservice (or group of microservices), and if we have the compose file in the same repository, there's no problem with access - the developer already has the necessary privileges. With a mono-repository, all developers would need access to it. This makes access control difficult and error-prone, as developers should only be allowed to change deployments related to their own microservices.

Of course, there are many ways to achieve the same result, but I'm looking for a tool that will make my life easier)

m-adawi commented 1 month ago

With the current version of SwarmCD, I have to redeploy SwarmCD itself with changed config files, or at least SSH into the manager node, edit mounted files, and restart the service. It would be more reliable if I could achieve the same result with a single API call.

Maybe we can add a feature that makes SwarmCD watch a repo for its own configurations, similar to #54. This way you would only modify the stacks file in your swarmcd-config repo and it would automatically apply the changes.

m-adawi commented 1 month ago

I also agree with @sanzoghenzo that this is a GitOps project and any changes that aren't version-controlled in Git shouldn't be encouraged