Southclaws
commented
4 years ago The API is first on my list. And I think the UI can be a simple React single-page application served from the same process - keeping it simple.
Though I do want to avoid re-making some features of existing tools like Portainer, which already provides a way to perform common administration tasks such as listing containers, restarting and executing commands.
I think at first it'll serve as a simple read-only log of events received and which ones have succeeded/failed.
This also means data needs to be persisted at some point - maybe not the MVP but eventually. I think a nice simple embedded database would do that job nicely. There are plenty in the Go ecosystem and I'd prefer to avoid anything involving SQL to keep it simple.
In the future it would be nice to have a web ui, that can is present on a master server, it would be interesting to have a master to slave relationship in the future that isn't a requirement, but if you are running multiple services across multiple servers, it might be nice to have a single interface for monitoring them.
The site should really provide statistics, logs, and health checks of services. There should be a way to set off manual events such as stopping/restarting/starting repo's at will. A good example of this is, if a bad commit is pushed to a repo, and it gets deployed, it could leave that system vulnerable to an attack, and it would make sense to stop the repo that is affected. So having a new UI to be able to do that would make sense.
Though not a requirement, it might be a nice idea to provide a way to access a containers cli from the ui. Security would need to be in-check for this sort of stuff, to prevent insecurely leaking the access of the container to the outside world. I could think that vault integration could be used for it's token regeneration to provide security here too.
There should also be an API, that can be exposed to grab data about the services being ran, the statuses, health status, logs, etc.