-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
spike: Docker-compose for local setup #144
Comments
With more and more features being added to Starship helm charts, we need a way to have a complimentary solution for local environment.
Our main usecase of k8s at this point is around:
We should be able to replicate alot of the systems we have, and scripts we have for helm to be used for docker-compose creation. |
We would need something like: https://github.com/tiagomelo/golang-yaml-template-tutorial/blob/main/parser/parser.go |
Docker-compose yaml file output, can be less of a templating solution, and more of objects and structs that represent the final docker file, and based on some inputs, we create the final object, with dependency injection. That way we can move all the logic to custom go code, and deal with structs and go custom types instead of templates. Again just the output of this system needs to yaml, not the internal model of the system, which is not anyways. |
Overview
As a user, one does not care where and how the system is being run as long as it is consistent, locally, on the CI and in the cluster.
Running k8s locally is still a bit of a hassle with docker-desktop it becomes a little easy.
Proposal
What if we allow users to define a simple config file, but then still be able to run that with docker-compose. We will solve the local issues.
We can restrict the number of nodes to be spun as well as not allow multi-validator setup, but basically give users a development environment of there choices.
Design
We would have to redo alot of stuff that k8s provides for free, mostly around init-containers, templating with helm and more to get this to work. But this would be a good feature to have for local testing.
User inputs
Users still just needs to provide a simple config file as input, same configuration, and we can create a docker-compose template for running it, first via the Makefile, then via the cli.
Multiple backend supports would be really big for Starship, specially for the initial hurdle of onboarding users to Starship.
NOTE: We would need to restrict the features for docker-compose based on the limitations of the framework itself.
The text was updated successfully, but these errors were encountered: