search

EDITD / kubetools

:nut_and_bolt: Kubetools is a tool and processes for developing and deploying microservices to Kubernetes.
MIT License
13 stars 2 forks source link

ktd over multiple repositories #16

Closed chrissinclairedited closed 4 years ago

chrissinclairedited commented 5 years ago

Increasingly I'm finding that I'm having to track logs across multiple repos (at the moment mercury, highstreet, drawbridge, and wardrobe). Whilst I can work with having multiple windows tracking the logs for each webserver individually, it means I struggle after the fact to know the order that events have happened in, particularly in noisy output (a-la mercury).

I've used foreman in the past with a good load of success, and it kinda works by creating a Procfile like so:

mercury: cd ./mercury && ktd start && ktd logs webserver
highstreet: cd ./highstreet && ktd start && ktd logs webserver
wardrobe: cd ./wardrobe && ktd start && ktd logs webserver
drawbridge: cd ./drawbridge && ktd start && ktd logs webserver

This works reasonably well, in that only one terminal is needed (ignoring npm for now) and the logs are in order. It falls down however with restarting those services for example, where the logs will exit for the service being restarted, causing the whole lot to fail. Anything that could be done here to help?

Fizzadar commented 5 years ago

@chrissinclairedited interesting! It's v.annoying when the logs exit on container exit. I think we should start there - a wrapper around the log following command to re-try until the user requests exit. Would then make it easy to restart containers/etc while following the logs elsewhere.

I think using foreman/honcho w/Procfile is a reasonable solution to cross-repo logs - think we should avoid implementing such functionality into ktd or things could get messy. That said - doing ktd up over multiple repos in parallel would be pretty cool.

chrissinclairedited commented 5 years ago

Agreed that ktd is designed around being used in a single repo, so it makes sense to keep that. There'd still be a bit of nuance around the propagation of environment variables to configure using the local version of each service, something which feels a little bit off at the moment.

ktd up over multiple repos should be pretty straightforward with foreman / honcho, but definitely cool to do.

Fizzadar commented 5 years ago

Just tested this - if you ktd logs for the whole environment it does stay alive; so only when reading logs from a single container that gets shut down does this happen.

chrissinclairedited commented 5 years ago

Oh that's interesting - I tend to focus on the webserver in most of the repos as noise from redis / mariadb / memcached tends to be unnecessary. Would definitely be good to replicate the persistent log connection on a per-container basis if possible!

Fizzadar commented 4 years ago

Going to close this in favor of #17 which will allow Procfile example.