You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, development happens mostly with minikube. This has a couple of differences from production:
Build host & run host are always the same, so it's much quicker than production
We don't use an image registry, so any bugs around that will be uncaught.
Locally developing binderhub only requires the following:
Access to a .kube/config file that knows how to connect to a kubernetes cluster
An appropriately configured JupyterHub
The easiest way to accomplish these is to have a 'dev' kubernetes cluster that's small, often destroyed, and has the following structure:
We give access to it liberally
Each person gets their own namespace to play with
We also have a central docker image repository with namespaces for each person
This also makes testing quicker, since the network over at GKE is probably faster than local computer networks (at least for those of us still in the land of the free). It shouldn't be too expensive either, and we can probably do this soon.
The text was updated successfully, but these errors were encountered:
(I work with the Telepresence team, and am not familiar with Jupyter and how it works). Hopefully the below info is helpful:
Telepresence code a service locally, while proxying that service to a remote K8S cluster. So if for dev you need to run multiple different services in a K8S cluster but want to use, say, the Flask auto reload functionality, Telepresence works well.
Telepresence doesn't alleviate the need to have a deployment system that builds your Docker image, pushes it to a repo, does a kubectl apply, etc. Given that you're in minikube, I'm guessing that you already have such a system. If not, you might want to look at https://forge.sh.
If there are specific enhancements or support you need if you want to try this, please feel free to hop on our Gitter (https://gitter.im/datawire/telepresence).
Right now, development happens mostly with minikube. This has a couple of differences from production:
Locally developing binderhub only requires the following:
The easiest way to accomplish these is to have a 'dev' kubernetes cluster that's small, often destroyed, and has the following structure:
This also makes testing quicker, since the network over at GKE is probably faster than local computer networks (at least for those of us still in the land of the free). It shouldn't be too expensive either, and we can probably do this soon.
The text was updated successfully, but these errors were encountered: