search

tinkerbell / playground

Example deployments of the Tinkerbell Stack for use as playground environments
Apache License 2.0
127 stars 85 forks source link

Kubernetes Resource Model - docker-compose extension #131

Closed micahhausler closed 1 year ago

micahhausler commented 2 years ago

I'm looking to add support in the sandbox for running Tinkerbell components using the Kubernetes Resource Model (KRM) as outlined in tinkerbell/proposals#46. I was thinking of adding docker-compose support, but wanted to get some input on approach.

Currently there is a single docker-compose.yml in deploy/compose, however with KRM, there are some services/containers that won't be needed (database, tink-cli, etc). Given the overlap, could we have 3 compose files since compose supports combining multiple files? The result would be something like a docker-compose.base.yml, docker-compose.k8s.yml and docker-compose.db.yaml. In order to run the existing stack, you'd have to run:

docker-compose -f docker-compose.base.yml -f docker-compose.db.yml up -d

and for the KRM stack:

docker-compose -f docker-compose.base.yml -f docker-compose.k8s.yml up -d

This gets away from the simplicity of docker-compose up -d, but enables reuse of services like registry, and common config on services like boots, hegel, tink-server, and nginx.

The only alternative I see is to have a separate, largely duplicated compose file.

Any opinions here?

jacobweinstock commented 2 years ago

I think the user experience for the docker-compose quickstart would change most with this. I do like the very simple experience of docker-compose up -d.

What about doing something to define either the "existing stack" or the "KRM stack" as the default. So we still get the nice docker-compose up -d for the default and then with an additional -f we could get the non-default version? Would this add too much complexity to the non-default compose file?